Documentul discută protocoalele de securitate, cu accent pe verificarea corectitudinii acestora, prin metode formale, inclusiv metoda inductivă utilizată în demonstrarea matematică a caracteristicilor protocoalelor bazate pe smart carduri. Se subliniază importanța securității comunicațiilor și a protejării datelor sensibile în fața atacurilor malițioase, evidențiind nevoia de a dezvolta metode de analiză corespunzătoare. În concluzie, documentul propune extinderea metodelor actuale pentru a răspunde provocărilor legate de securitatea protocoalelor moderne.

1. Cuprins
Introducere 3
Motiva¸ie
t 4
Contribu¸ii
t 6
Structura lucr˘ rii
a 7
Principii de construc¸ie si analiz˘ a protocoalelor de securitate
t ¸ a 8
Metoda Inductiv˘
a 11
2.1 Isabelle 12
2.2 Modelarea protocoalelor de securitate 13
2.2.1 Agen¸ii . . . . . . . . . . .
t . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Cheile criptografice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Mesajele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Evenimente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 Urme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.6 Modelul intrusului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.7 Operatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.8 Modelarea protocolului . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.9 Modelarea m˘ rcilor de timp .
a . . . . . . . . . . . . . . . . . . . . . . . . 18
1

2. 2.3 Modelarea protocoalelor bazate pe smart carduri 19
2.3.1 Smart Cardurile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1.1 Vulnerabilit˘¸i . . . . . . . . . . . . . . . . . . . . . . . . . .
at . . . . . 20
2.3.1.2 Utilizarea cardului . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1.3 Secrete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Evenimente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3 Cuno¸tin¸ele agen¸ilor . . . . . . . . . . . . . . . . . . . . . . . . . .
s t t . . . . . 23
2.3.3.1 Agen¸ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
t . . . . . 23
2.3.3.2 Cuno¸tin¸ele ini¸iale ale agen¸ilor . . . . . . . . . . . . . . . .
s t t t . . . . . 23
2.3.3.3 Cuno¸tin¸ele pe care agen¸ii le extrag din observarea traficului
s t t . . . . . 23
2.3.4 Modelul intrusului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.5 Modelarea formal˘ a protocolalelor . . . . . . . . . . . . . . . . . . .
a . . . . . 27
Protocolul KLOMP 28
Analiza protocolului KLOMP 32
4.1 Modelarea protocolului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Verificarea protocolului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Corectitudinea modelului pentru protocolul Klomp . . . . . . . . . . . . 40
4.2.2 Regularitate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Unicitate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.4 Integritate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.5 Autenticitatea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.6 Confiden¸ialitate . . . . . . . . . . . . . . . . . . .
t . . . . . . . . . . . . 49
4.2.7 Distribu¸ia cheilor . . . . . . . . . . . . . . . . . .
t . . . . . . . . . . . . 50
Concluzii 51
Bibliografie 53
Anexe 54
2

3. Introducere
t˘
Un protocol de securitate este un algoritm distribuit specificat printr-o secven¸a de pa¸i s
care descrie ac¸iunile, a dou˘ sau mai multe entit˘¸i, ce trebuie realizate pentru atingerea unui
t a at
anumit obiectiv de securitate. Obiectivele de securitate reprezint˘ o mul¸ime de propriet˘¸i
a t at
prin care se poate specifica gradul de securitate al comunica¸iilor dintre agen¸ii unei re¸ele.
t t t
Propriet˘¸ile esen¸iale pe care un protocol ar trebui s˘ le ofere sunt cele de confiden¸ialitate si
at t a t ¸
integritate a mesajelor dar si de autenticitate a celor care transmit aceste mesaje. Intrusul este
¸
agentul mali¸ios care poate intercepta si altera mesaje, sau poate crea alte mesaje false pe care
t ¸
s˘ le transmit˘ prin re¸ea.
a a t
Protejarea sesiunilor de comunicare pentru a împiedica furtul si alterarea informa¸iilor sen-
¸ t
sibile a devenit o problem˘ la nivel mondial. Smart cardurile au ap˘ rut ca o solu¸ie la acest˘
a a t a
problem˘ oferind securitate prin stocarea într-un mod sigur, pe termen lung, a datelor cu carac-
a
ter personal si a secretelor utilizate de c˘ tre primitivele criptografice. Datorit˘ cipului incorporat
¸ a a
cardul este capabil s˘ proceseze aceste date si s˘ ofere acces la ele doar în momentul în care
a ¸ a
anumite cerin¸e de securitate sunt îndeplinite.
t
Analiza protocoalelor de securitate este fundamental˘ înainte ca acestea s˘ fie utilizate în
a a
practic˘ , impunându-se considerarea mediului de execu¸ie si a intrusului. Datorit˘ num˘ rului
a t ¸ a a
mare de atacuri, singura metod˘ de a asigura c˘ un astfel de protocol este corect este demon-
a a
stra¸ia matematic˘ . O demonstra¸ie nu este altceva decât dovada c˘ fiecare pas din protocol
t a t a
p˘ streaz˘ o anumit˘ proprietate.
a a a
Ra¸ionamentul informal nu detecteaz˘ întotdeauna punctele slabe ale protocoalelor de secu-
t a
ritate de aceea de-a lungul timpului s-au dezvoltat metode formale. Cu ajutorul acestora putem
demonstra c˘ la nivel abstract protocoale sunt corecte într-un anumit model sau dac˘ au im-
a a
perfec¸iuni. Demonstra¸iile propriet˘¸ilor pentru protocoalele bazate pe smart carduri sunt mai
t t at
3

4. complexe decât pentru protocoalele clasice, iar metodele de analiz˘ formal˘ a acestora sunt în
a a
num˘ r limitat. Metoda Inductiv˘ este o tehnic˘ important˘ folosit˘ în demonstrarea formal˘
a a a a a a
a corectitudinii protocoalelor de securitate, ce poate fi utilizat˘ în cadrul demonstratorului de
a
teoreme Isabelle. Bazele acestei metode au fost puse Paulson în [3] iar Bella în [2] propune o
extensie pentru a putea verifica corectitudinea protocoalelor bazate pe smart carduri.
Motiva¸ie
t
Problema verific˘ rii corectitudinii protocoalelor este destul de veche, cercet˘ torii punându-
a a
si problema înc˘ din 1970 de a demonstra corectitudinea componentelor sistemelor, dar deabia
¸ a
în ultimul deceniu au ap˘ rut instrumente automate de verificare.
a
Smart cardurile au devenit o metod˘ comod˘ si sigur˘ de a stoca informa¸ii secrete pe ter-
a a¸ a t
men lung, de aceea nu ar trebui s˘ par˘ surprinz˘ tor faptul c˘ sistemele tradi¸ionale bazate pe
a a a a t
parole sunt înlocuite tot mai des cu cele bazate pe smart carduri. Noile protocoale de securitate
implementate pe baza acestor sisteme tind s˘ ating˘ propriet˘¸i mai tari dar acest lucru trebuie
a a at
demonstrat. Protocoale de securitate bazate pe smart carduri au nevoie de analiz˘ formal˘ care
a a
se bazeaz˘ pe principii matematice solide. Num˘ rul mare de vulnerabilit˘¸i posibile la nivel de
a a at
¸ t˘
protocol de securitate dar si de implementare a acestora scot în eviden¸a necesitatea dezvolt˘ rii a
metodelor formale de modelare si verificare prin care s˘ facilit˘ m în¸elegerea sistemului si prin
¸ a a t ¸
care s˘ ar˘ t˘ m c˘ aceste protocoale realizeaz˘ exact ceea ce trebuie, scopul pentru care au fost
a aa a a
proiectate.
Induc¸ia matematic˘ este considerat˘ suficient˘ pentru a modela si a crea ra¸ionamente refer-
t a a a ¸ t
itoare la obiectivele protocoalelor de securitate. În Metoda Inductiv˘ se folose¸te conceptul de
a s
urm˘ , o list˘ de evenimente ce au loc în re¸ea în timp ce un num˘ r nelimitat de agen¸i execut˘
a a t a t a
protocolul. Aceasta poate fi v˘ zut˘ ca o istorie a evenimentelor re¸elei care au loc în momen-
a a t
tul execu¸iei protocolului si se define¸te inductiv. Mul¸imea tuturor urmelor posibile reprezint˘
t ¸ s t a
modelul formal al protocolului. Propriet˘¸ile care pot fi demonstrate cu ajutorul Metodei In-
at
ductive sunt: cofiden¸ialitatea, integritatea, autenticitatea, distribu¸ia cheilor si diferite forme
t t ¸
de autentificare, si sunt exprimate prin teoreme. Demonstratorul de teoreme Isabelle poate fi
¸
utilizat pentru a demonstra aceste teoreme în mod semi-automat. Un alt concept important este
cel de punct de vedere care stabile¸te care din aceste teoremele sunt utile unui anumit agent,
s
adic˘ dac˘ agentul poate verifica ipotezele de la care se pleac˘ .
a a a
Pentru protocoalele de e-commerce în care sunt utilizate smart carduri este necesar˘ ex- a
tinderea Metodei Inductive, introducând elemente noi pentru modelarea cardurilor ¸inând contt
de riscurile clon˘ rii si de modul de interac¸iune a acestora cu agen¸ii. Pentru a stabili propri-
a ¸ t t
et˘¸ile unui protocol de securitate bazat pe smart carduri este foarte important s˘ stabilim în
at a
primul rând rolul pe care îl are cardul propriu-zis, dar si modul în care un atacator ar putea in-
¸
terveni. Extensia trebuie s˘ permit˘ modelarea interac¸iunii dintre carduri si posesorii acestora
a a t ¸
prin evenimente care marcheaz˘ transmiterea si recep¸ionarea de mesaje. Pentru cuno¸tin¸ele
a ¸ t s t
4

5. agen¸ilor, în special cele ale intrusului, trebuie propuse noi defini¸ii ¸inând cont c˘ toate cheile
t t t a
sunt stocate pe card, dar si mediul de execu¸ie, dac˘ atacatorul poate interveni sau nu în trans-
¸ t a
miterea informa¸iilor.
t
t˘ ¸
Pe parcursul lucr˘ rii vor fi scoase în eviden¸a si principiile generale care stau la baza pro-
a
tocoalelor corecte. Aceste principii contribuie la garan¸iile de securitate dar nu sunt suficiente.
t
Unul din principiile fundamentale în proiectarea protocoalelor de securitate conform [4] este
claritatea care sugereaz˘ c˘ fiecare mesaj ar trebui s˘ spun˘ exact ce înseamn˘ far˘ a crea ambi-
a a a a a a
guitate, iar alt principiu sugereaz˘ renun¸area la criptare atunci când nu este necesar˘ . G. Bella
a t a
în [5] dezvolt˘ ideea unui principiu de analiz˘ prudent˘ a protocoalelor de securitate numit prin-
a a a
cipiul utilit˘ ¸ii scopului care este respectat atunci când exist˘ garan¸ii c˘ din punctul de vedere
at a t a
al agentului obiectivul protocolului este atins. Aceste garan¸ii trebuie s˘ se bazeze pe ipoteze pe
t a
care agentul le poate verifica în practic˘ .a
Abord˘ ri cunoscute
a
Pentru analiza formal˘ a protocoalele de securitate de-a lungul timpului au fost propuse
a
numeroase abord˘ ri, iar odat˘ cu dezvoltarea sistemelor IT, calculatorul a început sa-¸i arate
a a s
utilitatea în automatizarea acestor analize. Metoda Inductiv˘ pare s˘ fie una din cele mai bune
a a
abord˘ ri având în vedere c˘ poate demonstra o gam˘ larg˘ de propriet˘¸i si este suportat˘ de
a a a a at ¸ a
demonstratorul de teoreme Isabelle.
Protocoalele pentru smart carduri tind s˘ aibe obiective mai tari decât cele tradi¸ionale dar
a t
acest lucru trebuie demonstrat formal. Pentru a analiza astfel de protocale trebuie dezvoltate noi
metode sau trebuie extise cele existente.
Abadi în [1] propune o extensie pentru logica BAN care permite modelarea protocoalelor de
securitate bazate pe smart carduri si prin care se poate demonstra autentificarea mutual˘ dintre
¸ a
agen¸i si sta¸iile de lucru. Abadi analizeaz˘ 3 protocoale de securitate bazate pe smart carduri
t ¸ t a
în care sunt necesare cerin¸e diferite. Ideea principal˘ a logicii BAN este s˘ reprezinte formal
t a a
încrederile pe care le au agen¸ii care execut˘ protocolul în diferite momente de execu¸ie. Fiecare
t a t
pas al protocolului este idealizat într-o formul˘ logic˘ si se realizeaz˘ o serie de deduc¸ii logice.
a a¸ a t
t˘
Din aplicarea regulilor de inferen¸a asupra încrederilor ini¸iale ale agen¸ilor si asupra deduc¸iilor
t t ¸ t
care reies din fiecare pas al protocolului se ajunge la scopul protocolului. Din p˘ cate logica BAN
a
nu ofer˘ o semantic˘ satisf˘ c˘ toare si este limitat˘ , ra¸ionamentul privind confiden¸ialitatea fiind
a a a a ¸ a t t
doar informal, intrusul nefiind modelat.
Securitatea demonstrabil˘ [10] este un studiu al teoriei complexit˘¸ii bazat pe probabilit˘¸i
a at at
despre confiden¸ialitatea cheilor de sesiune, dezvoltat si rafinat de Bellare and Rogway pentru
t ¸
protocoalele clasice. Ace¸tia au dezvoltat un protocol si au demonstrat c˘ este sigur în ipoteza
s ¸ a
în care exist˘ func¸ii pseudo-aleatoare. Propriet˘¸ile demonstrate au fost cele de distribu¸ie
a t at t
a cheii si confiden¸ialitatea cheii care reiese din probabilitatea mic˘ a adversarului de a g˘ si
¸ t a a
cheia. Mai târziu Shoup si Rubin au extins aceast˘ abordare si au creat un nou protocol bazat
¸ a ¸
5

6. pe smart carduri demonstrând c˘ este sigur. Acest protocol este unul de distribu¸ie a cheilor de
a t
sesiune într-un sistem cu trei agen¸i, fiecare de¸inând un card ideal ale c˘ rui func¸ii de criptare
t t a t
sunt pseudo-aleatoare. Autorii demonstreaz˘ c˘ agen¸ii partajeaz˘ o cheie la sfâr¸itul sesiunii
a a t a s
protocolului si c˘ exist˘ o probabilitate neglijabil˘ ca atacatorul s˘ înve¸e cheia de sesiune.
¸ a a a a t
Abordarea lui Bella în [2] se bazeaz˘ pe încrederile pe care fiecare agent le deriveaz˘ din
a a
observarea unor evenimente ale re¸elei. Singura strategie folosit˘ în demonstra¸ii este induc¸ia.
t a t t
Aceast˘ metod˘ poate fi aplicat˘ oric˘ rui protocol f˘ r˘ a necesita ajust˘ ri ale protocolului si
a a a a aa a ¸
poate ob¸ine o varietate de garan¸ii formale. Bella analizeaz˘ protocolul de distribu¸íe a cheilor
t t a t
propus de Shoup si Rubin în [7] care presupune c˘ mijloacele de comunicare dintre posesorul
¸ a
cardului si card sunt sigure si se iau în considerare carduri f˘ r˘ PIN. Studiul efectuat este realizat
¸ ¸ aa
asupra propriet˘¸ilor de autenticitate, unicitate, autentificare si distribu¸ia cheii si descoper˘ c˘
at ¸ t ¸ a a
este necesar˘ o clarificare în plus pentru dou˘ dintre mesajele protocolului.
a a
Contribu¸ii
t
Scopul acestei lucr˘ ri este de a prezenta o metod˘ de analiz˘ a protocoalelor de securitate
a a a
bazate pe smart carduri astfel încât ra¸ionamentele legate de gradul de securitate pe care acestea
t
îl ofer˘ s˘ aibe un suport formal. Aceast˘ metod˘ este o extensie a Metodei Inductive propus˘ de
a a a a a
Paulson în [3] si a metodei propus˘ de Bella în [2] pentru modelarea protocoalelor de securitate
¸ a
bazate pe smart carduri, dar care utilizeaz˘ elemente noi precum m˘ rcile de timp.
a a
Utilizând aceast˘ metod˘ am modelat si verificat protocolul Klomp propus de Bakker în
a a ¸
[8], protocol care nu a mai fost analizat formal pân˘ în acest moment. Protocolul este unul de
a
autentificare si distribu¸ie a cheilor de sesiune în cadrul tranzac¸iilor electronice. Pentru veri-
¸ t t
ficarea propriet˘¸ilor de securitate am utilizat demonstratorul de teoreme Isabelle care este un
at
instrument complex dar util în demonstra¸ii semi-automate. Fiecare proprietate este formalizat˘
t a
printr-o teorem˘ care este apoi demonstrat˘ pentru fiecare pas din protocol.
a a
În urma analizei am descoperit c˘ anumi¸i pa¸i ai protocolului încalc˘ unul din principi-
a t s a
ile fundamentale în construc¸ia protocoalelor de securitate si anume: comunicarea explicit˘ .
t ¸ a
Bakker propune ca în urma interog˘ rii smart cardurilor agen¸ii s˘ primeasc˘ o cheie temporar˘
a t a a a
creat˘ prin criptarea unor date furnizate de ace¸tia. Folosind aceste chei agen¸ii vor crea o cheie
a s t
de sesiune si certificate de autenticitate. Una din vulnerabilit˘¸ile posibile care trebuie consid-
¸ at
erate atunci când se face analiza protocoalelor bazate pe smart carduri este faptul c˘ acestea ar
a
putea s˘ nu func¸ioneze corect cum ar fi în cazul în care un atacator le-ar corupe magistralele
a t
de date în momentul fabric˘ rii astfel încât acestea s˘ furnizeze r˘ spunsuri într-o ordine gre¸it˘ .
a a a s a
În acest caz agentul primind doar cheia temporar˘ nu va putea face corect asocierea cu cel cu
a
care dore¸te s˘ stabileasc˘ un canal de comunicare sigur. Solu¸ia propus˘ se bazeaz˘ pe ideea
s a a t a a
c˘ agentul trebuie s˘ poat˘ verifica componentele din care este creat˘ cheia temporar˘ dar f˘ r˘
a a a a a aa
a cunoa¸te cheia cardului. Prin urmare mesajul returnat de smart card agentului va con¸ine atât
s t
cheia temporar˘ cât si rezumatul hash din care este construit˘ . În momentul recep¸iei mesajului
a ¸ a t
6

7. agentul va putea reconstrui rezumatul hash si va putea face asocierea dintre cheie si serverul cu
¸
care dore¸te s˘ comunice.
s a
Structura lucr˘ rii
a
Lucrarea este structurat˘ pe 6 capitole, primul având un caracter introductiv, identificând
a
direc¸iile de cercetare si principalele contribu¸ii aduse.
t ¸ t
În Capitolul 1, intitulat “Principii de construc¸ie si analiz˘ a protocoalelor de securitate",
t ¸ a
sunt descrise informal principiile fundamentale care stau la baza creerii unor protocoale sigure.
Pe parcursul lucr˘ rii voi ar˘ ta c˘ protocolul analizat în capitolul 4 încalc˘ unul din principiile
a a a a
de baz˘ enun¸ate de Abadi si Needham în [4], si anume comunicarea explicit˘ . Tot aici va fi
a t ¸ ¸ a
descris si principiul de analiz˘ propus de Bella în [5] care sugereaz˘ ca obiectivele de securitate
¸ a a
s˘ fie tratate din punctul de vedere al fiec˘ rui agent.
a a
Capitolul 2, intitulat “Metoda Inductiv˘ ", cuprinde o scurt˘ prezentare a demonstratorului
a a
de teoreme Isabelle si a elementelor acestei tehnici de modelare si verificare: tipurile agen¸ilor,
¸ ¸ t
modelul intrusului, chei criptografice, mesaje, evenimente, operatori. Metoda este prezentat˘ a
a¸a cum a fost propus˘ de Paulson în [3] pentru verificarea formal˘ a corectitudinii protocoalelor
s a a
de securitate clasice. Pentru a analiza cât mai realist protocoalele de securitate bazate pe smart
carduri, metoda trebuie adaptat˘ . Astfel partea a doua a acestui capitol va cuprinde descrierea
a
elementelor necesare extinderii Metodei Inductive.
În Capitolul 3, intitulat “Protocolul Klomp", este realizat˘ o scurt˘ descriere a protocolului
a a
propus de Bakker în [8]. Acesta este un protocol de autentificare si distribu¸ie de chei care
¸ t
utilizeaz˘ smart carduri, creat pentru a securiza tranzac¸iile comer¸ului electronic. De¸i Bakker
a t t s
a propus un prototip pentru implementarea protocolului care a fost testat pentru dou˘ tipuri de
a
carduri aflate în uz, pentru Metoda Inductiv˘ este necesar˘ doar descrierea la nivel opera¸ional.
a a t
Protocolul Klomp nu a mai fost analizat formal pân˘ în acest moment.
a
Capitolul 4, intitulat “Analiza protocolul Klomp", cuprinde descrierea modelului formal si ¸
a modului în care se realizat˘ verificarea modelului si a propriet˘¸ilor protocolului prezentat
a ¸ at
anterior. Modelul formal este descris inductiv cuprinzând atât pa¸ii protocolului cât si princi-
s ¸
palele vulnerabilit˘¸i posibile. Fiecare proprietate este specificat˘ printr-o teorem˘ care va fi
at a a
demonstrat˘ cu ajutorul demonstratorului Isabelle pentru fiecare pas din protocol.
a
Ultimul capitol, “Concluzii", face o trecere în revist˘ a con¸inutului lucr˘ rii, a contribu¸iilor
a t a t
aduse precum si a direc¸iilor de cercetare r˘ mase deschise.
¸ t a
Lucrarea va fi înso¸it˘ de un fi¸ier de teorii care cuprinde toate teoremele demonstrate în
t a s
capitolul 4 si care poate fi testat cu ajutorul demonstratorului de teoreme Isabelle.
¸
7

8. Capitolul 1
Principii de construc¸ie si analiz˘ a
t ¸ a
protocoalelor de securitate
Literatura de specialitate prezint˘ foarte multe exemple de protocoale de securitate care
a
con¸in erori. Aceste erori arat˘ necesitatea consider˘ rii unor reguli care s˘ ghideze construc¸ia
t a a a t
t˘
protocoalelor. Abadi si Needham în [4] enun¸a 11 principii informale, care nu sunt suficiente
¸
pentru demonstrarea corectitudinii protocoalelor de securitate, dar prin aplicarea lor se evit˘ a
suficient de multe erori.
Principiul 1: comunicarea explicit˘ .
a
Fiecare mesaj ar trebui s˘ spun˘ ceea ce înseamn˘ , interpretarea sa ar trebui s˘ depind˘ doar
a a a a a
de propriul con¸inut, astfel încât cel care îl recep¸ioneaz˘ s˘ -l în¸eleag˘ . Acest principiu spune
t t a a t a
c˘ într-o comunicare nu trebuie s˘ se presupun˘ c˘ anumite informa¸ii sunt deduse din context,
a a a a t
altul decât mesajul însu¸i, deoarece aceste informa¸ii ar putea fi înlocuite cu altele.
s t
Principiul 2: ac¸iune potrivit˘ .
t a
Acest principiu se refer˘ la un mod de a ac¸iona corespunz˘ tor unor condi¸ii. Condi¸iile
a t a t t
trebuie clar stabilite cu privire la ac¸iunile pe care agen¸ii le pot realiza. Pentru a ac¸iona asupra
t t t
unui mesaj nu este suficient numai s˘ fie în¸eles, sunt necesare si alte condi¸ii precum cele legate
a t ¸ t
de încrederea între agen¸i.
t
Principiul 3: ad˘ ugarea identit˘¸ii agen¸ilor în mesaj.
a at t
Uneori identitatea agen¸ilor poate fi dedus˘ din alte date sau din cheile de criptare folosite.
t a
Dac˘ identitatea agen¸ilor este esen¸ial˘ în semnifica¸ia mesajului, atunci identit˘¸ile trebuie
a t t a t at
men¸ionate explicit în mesaj.
t
8

9. Principiul 4: criptarea.
Scopul utiliz˘ rii cript˘ rii trebuie s˘ fie clar precizat. Criptarea nu este sinonim˘ cu securi-
a a a a
t˘ ¸
tatea, iar opera¸iile de criptare sunt costisitoare, conducând la redundan¸a si erori atunci când
t
se utilizeaz˘ necorespunz˘ tor. De obicei criptarea se folose¸te pentru asigurarea confiden¸ia-
a a s t
lit˘¸ii, garantarea autenticit˘¸ii, combinarea unor componente (în acest caz este suficient˘ doar
at at a
semnarea), si generarea de numere aleatoare.
¸
Principiul 5: semnarea informa¸iilor criptate.
t
Semn˘ tura se folose¸te pentru a indica care agent a criptat ultimul mesajul. Dac˘ un agent
a s a
semneaz˘ un mesaj deja criptat atunci nu ar trebui dedus c˘ agentul cunoa¸te con¸inutul mesa-
a a s t
jului. Se poate deduce c˘ agentul cunoa¸te con¸inutul mesajului doar dac˘ mai intâi semneaz˘
a s t a a
si apoi cripteaz˘ .
¸ a
Principiul 6: scopul utiliz˘ rii nonceurilor.
a
Motiva¸ia utiliz˘ rii nonceurilor ar trebui s˘ fie clar˘ . Acestea sunt utilizate fie pentru a ob¸ine
t a a a t
noutatea unui mesaj, fie pentru a face asocierea cu identitatea unui agent.
Principiul 7: nonceuri generate aleator vs nonceuri predictibile.
O valoare predictibil˘ (valoarea unui contor) poate fi utilizat˘ pentru ob¸inerea nout˘¸ii într-
a a t at
un schimb întrebare-r˘ spuns, îns˘ acest˘ cantitate trebuie protejat˘ astfel încât un atacator s˘ nu
a a a a a
poat˘ simula întrebarea si s˘ reia ulterior r˘ spunsul recep¸ionat.
a ¸ a a t
Principiul 8: utilizarea m˘ rcilor de timp.
a
a a at t˘
Dac˘ se folosesc m˘ rci de timp pentru garantarea nout˘¸ii unui mesaj prin referin¸a la timpul
absolut atunci diferen¸a de timp a ceasurilor agen¸ilor trebuie s˘ fie mai mic˘ decât intervalul de
t t a a
t˘
timp acceptat ca toleran¸a la recep¸ia mesajului. Sincronizarea ceasurilor acestor ma¸ini se va
t s
face de c˘ tre autoritatea de încrederea.
a
Principiul 9: diferen¸a între utilizarea recent˘ si generarea recent˘ .
t a¸ a
Utilizarea recent˘ a unei chei, în sesiunea curent˘ , nu înseamn˘ c˘ aceasta este recent˘ .
a a a a a
Principiul 10: recunoa¸terea mesajelor.
s
Dac˘ se utilizeaz˘ o codificare atunci trebuie s˘ fie u¸or pentru agen¸i s˘ recunoasc˘ me-
a a a s t a a
sajul si s˘ -l asocieze corect cu pasul din protocol corespunz˘ tor si eventual cu componentele
¸ a a ¸
corespunz˘ toare.
a
Principiul 11: încredere.
În construc¸ia protocoalelor de securitate este important s˘ se ia în calcul rela¸iile de încre-
t a t
dere de care depinde protocolul. Motivul pentru care o rela¸ie de încredere este acceptat˘ trebuie
t a
specificat˘ explicit de¸i se bazeaz˘ în general doar pe aprecieri si nu pe logic˘ .
a s a ¸ a
Bella în [5] propune un principiu pentru analiza protocoalelor de securitate care comple-
menteaz˘ principiile de construc¸ie prudent˘ amintite mai sus si care sugereaz˘ ca propriet˘¸ile
a t a ¸ a at
protocoalelor s˘ fie bazate pe ipoteze pe care participan¸ii le pot verifica. Acest principiu se
a t
nume¸te utilitatea scopului si recomand˘ dezvoltarea unor garan¸ii formale c˘ protocolul î¸i
s ¸ a t a s
9

10. realizeaz˘ obiectivele de securitate, care s˘ fie utilizate de c˘ tre participan¸i în practic˘ . În con-
a a a t a
t˘
secin¸a principiul spune c˘ trebuie s˘ c˘ ut˘ m garan¸ii formale bazate pe presupuneri care pot fi
a a a a t
verificate, altfel concluziile nu vor fi utile în lumea real˘ , pentru c˘ nu prezint˘ interes pentru
a a a
respectivii agen¸i.
t
Principiul utilit˘ ¸ii scopului
at
Un protocol de securitate trebuie sa-¸i fac˘ util scopul în practic˘ .
s a a
Informal, un obiectiv de securitate este util în practic˘ pentru un participant, dac˘ la un mo-
a a
ment dat în execu¸ia protocolului acesta poate beneficia de el. În modelul formal al protocolului,
t
trebuie s˘ existe o garan¸ie formal˘ care specific˘ faptul c˘ participantul ob¸ine o proprietate de
a t a a a t
securitate la un moment dat si care porne¸te de la presupuneri care pot fi verificate de c˘ tre res-
¸ s a
pectivul participant. Dac˘ nu exist˘ o astfel de garan¸ie atunci spunem c˘ protocol nu reu¸e¸te
a a t a s s
s˘ fac˘ util respectivul scop pentru participant. Este important ca aceste garan¸ii formale s˘ fie
a a t a
ob¸inute într-un model al intrusului realist. În continuare vor fi prezentate conceptele esen¸iale
t t
care stau la baza acestui principiu.
Defini¸ie: scop util
t
Fie P un protocol de securitate, P model formal pentruP, g un scop (obiectiv de securitate)
al protocoluluiP si A un agent. Spunem c˘ g este util pentru A în P dac˘ exist˘ o garan¸ie
¸ a a a t
formal˘ în P care confirm˘ g si aceasta este aplicabil˘ de A în P.
a a ¸ a
Defini¸ie: garan¸ie aplicabil˘
t t a
Fie P un protocol de securitate, P model formal pentruP si A un agent. Spunem c˘ o
¸ a
garan¸ie formal˘ în P este aplicabil˘ de A în P dac˘ este stabilit˘ pe baza unor ipoteze pe care A
t a a a a
le poate verifica în P folosindu-¸i încrederile minimale.
s
Defini¸ie: încrederi minimale
t
Fie P un protocol de securitate, P model formal pentruP si A un agent. Încrederile mini-
¸
male ale agentului A este mul¸imea tuturor faptelor formalizate în P a c˘ ror valoare de adev˘ r
t a a
trebuie s˘ fie cunoscut˘ de A dar care nu poate fi verificat˘ în practic˘ .
a a a a
10

11. Capitolul 2
Metoda Inductiv˘
a
Metoda Inductiv˘ poate fi folosit˘ pentru demonstrarea formal˘ a corectitudinii protocoalelor
a a a
de securitate. Aceast˘ metod˘ se afl˘ în clasa metodelor de demonstrare de teoreme si ofer˘
a a a ¸ a
rezultate valabile pentru toate comport˘ rile posibile ale protocolului de securitate studiat. Demon-
a
stratorul de teoreme Isabelle ofer˘ un foarte bun suport mecanic pentru aceast˘ metod˘ , fiind un
a a a
instrument semi-automat în care este necesar˘ ghidarea din partea celui care face demonstra¸ia
a t
pentru a ajunge la obiectivul protocolului.
Un protocol de securitate este un program concurent care este executat de un num˘ r in- a
definit de agen¸i si procesul tinde s˘ ating˘ dimensiuni foarte mari. Studierea unei propriet˘¸i a
t ¸ a a at
protocolului înseamn˘ derivarea unui ra¸ionament prin care s˘ se poat˘ demonstra c˘ to¸i pa¸ii
a t a a a t s
protocolului p˘ streaz˘ acea proprietate. În Metoda Inductiv˘ pentru a demonstra c˘ un protocol
a a a a
¸ t˘
de securitate este corect si nu este vulnerabil la noi amenin¸ari, odat˘ ce acestea sunt descoperite
a
vor fi modelate ca o mul¸ime definit˘ inductiv iar obiectivele protocolului vor fi demonstrate prin
t a
induc¸ie asupra întregului model. Modelul intrusului este Dolev-Yao si nu se impun restric¸ii
t ¸ t
asupra num˘ rului de agen¸i sau a num˘ rului de sesiuni.
a t a
De exemplu fie protocolul de securitate P, si un num˘ r nelimitat de agen¸i, printre care si
¸ a t ¸
intrusul care monitorizeaz˘ re¸eaua si cunoa¸te secretele agen¸ilor compromi¸i. Traficul re¸elei
a t ¸ s t s t
se dezvol˘ în func¸ie de ac¸iunile (evenimente de comunicare) pe care le efectueaz˘ agen¸ii
a t t a t
atunci când execut˘ diferite sesiuni ale protocolului P. Protocolul P este modelat ca un sistem
a
tranzi¸ional în care se surprinde evolu¸ia sistemului ar˘ tând cum se realizeaz˘ trecerea dintr-o
t t a a
stare în alta. O istorie a traficului re¸elei poate fi reprezentat˘ ca o list˘ de evenimente care au
t a a
loc în acea istorie. Aceast˘ list˘ este o urm˘ a protocolului si este de obicei construit˘ în ordine
a a a ¸ a
11

12. invers cronologic˘ . Mul¸imea P a tuturor urmelor posibile reprezint˘ modelul formal al re¸elei
a t a t
unde P este executat si este definit˘ inductiv prin reguli specificate de P. Evenimentele au loc
¸ a
prin declan¸area acestor reguli. Din moment ce nici o regul˘ nu este for¸at˘ s˘ se declan¸eze,
s a t a a s
nici un eveniment nu este for¸at s˘ aibe loc.
t a
Induc¸ia în faza de specificare permite definirea tuturor operatorilor de mesaje relevan¸i si a
t t ¸
modelului protocolului. În faza de verificare induc¸ia ofer˘ principiul demonstra¸iei prin care se
t a t
at at t˘
stabilesc propriet˘¸ile modelului. Propriet˘¸ile care pot fi verificate sunt doar cele de siguran¸a
(safety) care indic˘ c˘ niciodat˘ nu se va întâmpla nimic r˘ u, dar nu putem verifica propriet˘¸ile
a a a a at
de viabilitate (liveness) care afirm˘ c˘ ceva bun va avea loc.
a a
Abordarea propus˘ de Paulson preia de la logica BAN ideea ob¸inerii de noi informa¸ii
a t t
ca urmare a recep¸iei mesajelor, dar propriet˘¸ile de securitate nu se mai refer˘ exclusiv la
t at a
autentificare. Semantica opera¸ional˘ este asem˘ n˘ toare cu cea a formaliz˘ rii CSP, cu excep¸ia
t a a a a t
faptului c˘ modelele sunt nem˘ rginite. Tot în stil CSP este considerat˘ si no¸iunea de eveniment
a a a¸ t
dar si faptul c˘ propriet˘¸ile de securitate sunt exprimate ca predicate pe mul¸imea urmelor
¸ a at t
protocolului.
Metoda Inductiv˘ poate fi folosit˘ în cadrul demonstratorului de teoreme Isabelle deoarece
a a
acesta ofer˘ un foarte bun suport pentru mul¸imile definite inductiv, simplific˘ ri eficiente prin
a t a
reguli de rescriere condi¸ionale si împ˘ r¸iri automate pe cazuri pentru expresiile if-the-else.
t ¸ at
Figura 1: Metoda inductiv˘
a
2.1 Isabelle
Isabelle este un demonstrator de teoreme generic interactiv. Cea mai popular˘ versiune este
a
Isabelle/HOL, care permite specificarea si verificarea protocoalelor de securitate. Interactiv se
¸
refer˘ la faptul c˘ demonstratorul nu este complet automat, necesitând interven¸ia uman˘ pentru
a a t a
a conduce demonstra¸iile. Acest instrument ofer˘ un simplificator puternic care este util în sim-
t a
plic˘ rile anumitor informa¸ii si afirma¸ii iar cu ajutorul demonstra¸iilor automate putem rezolva
a t ¸ t t
12

13. diferite scenarii simple. Isabelle este foarte bun pentru a genera demonstra¸ii prin induc¸ie,
t t
propriet˘¸ile fiind demonstrate pentru toate urmele protocoalelor.
at
a ¸ a a t˘
Demonstrarea teoremelor este dificil˘ si necesit˘ mult˘ experien¸a din partea celui care
dore¸te s˘ realizeze demonstra¸ia. Pentru a realiza o demonstra¸ie, utilizatorul trebuie s˘ apeleze
s a t t a
la anumite metode de induc¸ie si simplificare pentru subscopurile ob¸inute pentru a îndruma in-
t ¸ t
strumentul cum s˘ procedeze pentru a ajunge la obiectivul final. Dac˘ au r˘ mas subscopuri
a a a
nerezolvate atunci se poate apela la demonstratorul automat sau se pot reduce prin utilizarea
unor leme. Dac˘ demonstra¸ia nu se poate realiza atunci înseamn˘ c˘ utilizatorul nu este destul
a t a a
de priceput sau modelul are contradic¸ii.
t
Analiza unui sistem în Isabelle începe cu dezvoltarea unei teorii care cuprinde specifica-
rea sistemului si teoremele necesare analizei. Aceste teorii sunt de fapt scripturi iar fiecare
¸
teorem˘ are în spate un astfel de script. Distribu¸iile de Isabelle cuprind o serie de astfel de
a t
teorii deja dezvoltate. De exemplu în fi¸ierul Message.thy sunt descrise formal mesajele si ope-
s ¸
ratorii care pot fi utiliza¸i de c˘ tre protocoalele de securitate. Scripturile create de G. Bella
t a
pentru analiza protocolului creat de Shoup si Rubin se g˘ sesc în ultima versiune în directorul
¸ a
Isabelle2011/src/HOL/Auth/Smartcard. Teoria EventSC.thy con¸ine o mul¸ime extins˘ de eve-
t t a
t˘
nimente fa¸a de cea creat˘ de Paulson si descrie interac¸iunea cu smart cardurile, iar în Smart-
a ¸ t
card.thy este descris formal cardul împreun˘ cu câteva specifica¸ii legate de secretele stocate si
a t ¸
vulnerabilit˘¸ile posibile cum ar fi furtul sau clonarea. Teoriile ShoupRubin.thy si ShoupRubin-
at ¸
Bella.thy con¸in specificarea protocolului si teoremele de verificare.
t ¸
2.2 Modelarea protocoalelor de securitate
2.2.1 Agen¸ii
t
Metoda Inductiv˘ nu are restristric¸ii referitoare la num˘ rul de agen¸i care pot executa un
a t a t
protocol. Agen¸ii pot fi umani, ma¸ini sau procese. În modelarea formal˘ a protocoalelor vom
t s a
utiliza 3 tipuri de agen¸i: cei one¸ti care vor fi nota¸i cu Friend i (i num˘ r natural), intrusul care
t s t a
va fi notat cu Spy si serverul notat S sau Server.
¸
datatype agent Server
Friend nat
Spy
Pentru a modela diferite vulnerabilit˘¸i trebuie introdus˘ si o mul¸ime de agen¸i compromi¸i
at a¸ t t s
care î¸i dezv˘ luie secretele atacatorului chiar de la începutul protocolului, dar si ceea ce observ˘
s a ¸ a
pe parcursul protocolului. Aceast˘ mul¸ime va fi notat˘ cu bad si se consider˘ c˘ atacatorul face
a t a ¸ a a
parte din aceast˘ mul¸ime.
a t
13

14. 2.2.2 Cheile criptografice
Pentru a modela formal cheile criptografice se introduce un nou tip key. În sistemele cu chei
simetrice, specificarea faptului c˘ fiecare agent are o cheie partajat˘ cu serverul se face printr-o
a a
func¸ie:
t
shrK : agent → key
În cazul sistemele cu chei asimetrice func¸ia se aplicat˘ pentru perechea de chei de criptare
t a
priEK si pubEK sau pentru perechea de chei folosit˘ la semn˘ turi priSK si pubSK.
¸ a a ¸
Pentru a face distinc¸ie între tipurile de chei, cele simetrice vor fi notate cu symKeys si vor fi
t ¸
parti¸ionate în chei partajate (shrK) si chei de sesiune. Pentru a modela faptul c˘ o cheie K este
t ¸ a
pentru o sesiune:
K ∈ symKeys si K ∈ range shrK
¸ /
O alt˘ func¸ie ce poate fi specificat˘ este invKey : key → key care nu modific˘ cheile dac˘
a t a a a
sunt simetrice, iar dac˘ sunt asimetrice va oferi cheia complementar˘ (priSK A = invKey(pubSK A)).
a a
2.2.3 Mesajele
Tipul de date pentru mesaje:
datatype msg Agent agent
Nonce nat
Key key
Mpair msg msg
Hash msg
Crypt key msg
Mesajele pot con¸ine nume de agen¸i, nonceuri si chei criptografice. Mesajele pot fi create
t t ¸
din concatenarea mai multor mesaje folosind constructorul MPair; rezumatul unui mesaj se ob-
¸ine cu ajutorul operatorului Hash, iar criptarea unui mesaj se va face cu ajutorul constructorului
t
Crypt folosind o cheie de criptare simetric˘ sau asimetric˘ . Criptarea se presupune a fi perfect˘
a a a
deci nu exist˘ nici o modalitate de a ob¸ine plaintextul dintr-un criptotext f˘ r˘ a sti cheia de
a t aa ¸
criptare.
2.2.4 Evenimente
Tipul de date pentru evenimente permite formalizarea evenimentelor de transmitere, re-
cep¸ie si memorare a mesajelor:
t ¸
14

15. datatype msg Says agent agent msg
Gets agent msg
Notes agent msg
Un mesaj poate fi recep¸ionat doar dup˘ de a fost transmis. Evenimentul Notes modeleaz˘
t a a
situa¸ia când un agent memoreaz˘ por¸iuni dintr-un mesaj care vor putea fi utilizate ulterior.
t a t
Acesta ar putea înlocui evenimentul Gets deoarece un agent poate memora un mesaj doar dup˘ a
ce acesta a fost recep¸ionat, dar cele 2 evenimente sunt specificate separat pentru a modela mai
t
bine realitatea.
2.2.5 Urme
Urmele protocolului sunt liste de evenimente de lungime variabil˘ pe baza c˘ rora se va
a a
construi modelul protocolului si care vor fi utilizate în verifiarea propriet˘¸ilor. O urm˘ poate
¸ at a
fi utilizat˘ pentru a înregistra toate evenimentele care au loc de-a lungul unei istorii a re¸elei în
a t
care se execut˘ protocolul. Urmele sunt create în ordine invers cronologic˘ , ultimul eveniment
a a
fiind în capul listei. Un eveniment poate fi declan¸at de un num˘ r indefinit de ori într-o urm˘ .
s a a
Exemplu de urm˘ : a
Notes Spy (Nonce Na )
Says A B {| Agent A, Nonce Na |}
Says A B {| Agent A, Nonce Na |}
Este foarte important ca modelul protocolului s˘ considere toate urmele posibile si doar
a ¸
acele urme pe care protocolul studiat le poate produce.
2.2.6 Modelul intrusului
Atunci când analiz˘ m protocoale de securitate este foarte important s˘ se considere un
a a
model realist pentru vulnerabilit˘¸i. În cazul Metodei Inductive se consider˘ modelul Dolev-
at a
Yao, în care modelarea si verificarea protocoalelor de securitate presupune ipoteza criptografiei
¸
perfecte. Conform acestei presupuneri atacatorul este înregistrat ca si un agent onest capabil
¸
s˘ controleze mediul, adic˘ poate intercepta toate mesajele si poate împiedica transmiterea lor
a a ¸
c˘ tre destinatar dar nu poate ob¸ine nici o informa¸ie dintr-un mesaj dac˘ nu cunoa¸te cheia de
a t t a s
decriptare. Atacatorul poate doar s˘ ob¸in˘ informa¸ii din mesajele criptate cu chei pe care le
a t a t
cunoa¸te, le poate descompune si poate crea alte mesaje din componentele ob¸inute. Un mesaj
s ¸ t
care este transmis nu este în mod necesar recep¸ionat, iar cel care îl recep¸ioneaz˘ nu este în
t t a
mod necesar cel c˘ ruia îi este destinat. De asemenea acest model presupune utilizarea de chei
a
perfecte care nu pot fi ghicite sau extrase din mesajele criptate si se consider˘ mecanisme de
¸ a
generare de numere aleatoare perfecte si func¸ii hash perfecte (one-way si f˘ r˘ coliziuni).
¸ t ¸ aa
Primitivile criptografice sunt considerate abstracte si sigure, si se presupun a fi injective ceea
¸ ¸
15

16. ce conduce la automatizarea verific˘ rii. Acest model este important pentru ob¸inerea erorilor de
a t
protocol si nu pentru cele care ¸in de implementarea acestora.
¸ t
Pentru a respecta aceste cerin¸e este necesar˘ formalizarea cuno¸tin¸elor atacatorului. Pentru
t a s t
a specifica cuno¸tin¸ele ini¸iale ale agen¸ilor Metoda Inductiv˘ include urm˘ toarea func¸ie:
s t t t a a t
initState : agent → msg set
Cuno¸tin¸ele ini¸iale trebuie formalizate diferit în func¸ie de tipul agentului.
s t t t
1. Mul¸imea cuno¸tin¸elor ini¸iale ale serverului este format˘ din toate cheile partajate, toate
t s t t a
cheile publice si cheile sale private.
¸
initState Server {Key(shrK A)}∪
{Key(priEK Server)} ∪ {Key(priSK Server)}∪
{Key(pubEK A)} ∪ {Key(pubSK A)}
2. Mul¸imea cuno¸tin¸elor ini¸iale ale unui agent onest const˘ din cheia sa partajat˘ , cheile
t s t t a a
sale private si toate cheile publice.
¸
initState(Friend i) {Key(shrK (Friend i))}∪
{Key(priEK (Friend i))} ∪ {Key(priSK (Friend i))}∪
{Key(pubEK A)} ∪ {Key(pubSK A)}
3. Mul¸imea cuno¸tin¸elor ini¸iale ale intrusului este format˘ din toate cheile partajate si
t s t t a ¸
private ale agen¸ilor compromi¸i, si toate cheile publice.
t s ¸
initState Spy {Key(shrK A)|A ∈ bad}∪
{Key(priEK A)|A ∈ bad} ∪ {Key(priSK A)|A ∈ bad}∪
{Key(pubEK A)} ∪ {Key(pubSK A)}
Paulson propune pentru formalizarea cuno¸tin¸elor pe care intrusul le ob¸ine din observarea
s t t
urmelor protocolului func¸ia spies. Aceste cuno¸tin¸e sunt formate din starea sa ini¸ial˘ , toate
t s t t a
mesajele trimise de orice agent si toate mesajele memorate de agen¸ii compromi¸i.
¸ t s
spies : event list → msg set
Ca nota¸ie se va utiliza operatorul # pentru delimitarea ultimului eveniment dintr-o urm˘ .
t a
De exemplu Says A B X # evs simbolizeaz˘ urma a c˘ rui prim eveniment este transmiterea de la
a a
A la B a mesajului X iar evs reprezint˘ suburma r˘ mas˘ . Func¸ia spies poate fi definit˘ recursiv:
a a a t a
0. Intrusul i¸i cunoa¸te starea ini¸ial˘ în orice urm˘ .
s s t a a
spies [] initState Spy
1. Orice mesaj transmis într-o urm˘ este cunoscut de intrus în acea urm˘ .
a a
16

17. spies ((Says A B X) # evs) {X} ∪ spies evs
2. Orice mesaj memorat de un agent compromis într-o urm˘ este cunoscut de intrus în acea
a
urm˘ .
a

{X} ∪ spies evs dac˘ A ∈ bad
a
spies ((Notes A X) # evs)
spies evs altfel
2.2.7 Operatori
Pentru mul¸imile de mesaje se introduc trei operatori:
t
analz, synth, parts : msg set → msg set
Operatorul analz se folose¸te pentru a modela descompunerea mesajelor. Dat˘ H o mul¸ime
s a t
de mesaje, atunci analz H se poate defini inductiv prin:
0. X ∈ H ⇒ X ∈ analz H
1. {| X, Y |} ∈ analz H ⇒ X ∈ analz H
2. {| X, Y |} ∈ analz H ⇒ Y ∈ analz H
3. {| Crypt K X ∈ analz H; Key(invKey K) ∈ analz H|} ⇒ X ∈ analz H
Mul¸imea analz(spies evs ) reprezint˘ mul¸imea tuturor componentelor mesajelor pe care
t a t
intrusul le poate deriva din observarea traficului din urma evs. Aceste componente se ob-
¸in din descompunerea mesajelor concatenate si decriptarea celor criptate folosind chei care
t ¸
devin cunoscute recursiv. Confiden¸ialitatea unui mesaj în urma evs se reprezint˘ prin X ∈
t a /
analz(spies evs).
Operatorul synth se folose¸te atunci când se construiesc mesaje din componentele cunoscute.
s
Dat˘ H o mul¸ime de mesaje, atunci synth H se poate defini inductiv prin:
a t
0. X ∈ H ⇒ X ∈ synth H
1. Agent A ∈ synth H
2. X ∈ synth H ⇒ Hash X ∈ synth H
3. {| X ∈ synth H, Y ∈ synth H |} ⇒ {| X, Y |} ∈ synth H
4. {| Key K ∈ H, X ∈ synth H |} ⇒ Crypt K X ∈ synth H
Mul¸imea synth(analz(spies evs )) reprezint˘ mul¸imea tuturor mesajelor pe care intrusul le
t a t
poate crea prin concatenarea si criptarea componentelor derivate din observarea urmei evs.
¸
Operatorul parts se folose¸te pentru extragerea tuturor componentelor unei mul¸imi de me-
s t
saje prin proiec¸ie si decriptare. Dat˘ H o mul¸ime de mesaje, atunci parts H se poate defini
t ¸ a t
inductiv prin:
17

18. 0. X ∈ H ⇒ X ∈ parts H
1. {| X, Y |} ∈ parts H ⇒ X ∈ parts H
2. {| X, Y |} ∈ parts H ⇒ Y ∈ parts H
3. Crypt K X ∈ parts H ⇒ X ∈ parts H
Spre deosebire de func¸ia analz, parts nu necesit˘ cunoa¸terea cheii de decriptare. Dat un
t a s
mesaj X si urm˘ evs, X ∈ parts(spies evs) înseamn˘ c˘ X apare în acea urm˘ posibil ca si o
¸ a a a a ¸
component˘ a unui mesaj.
a
Noutatea este important˘ atunci când gener˘ m nonceuri sau chei de sesiune. Pentru a ajuta la
a a
formalizarea acestui concept Metoda Inductiv˘ introduce func¸ia used care reprezint˘ mul¸imea
a t a t
tuturor componentelor care fac parte din cuno¸tin¸ele ini¸iale ale agen¸ilor împreun˘ cu toate
s t t t a
componentele mesajelor care apar într-o urm˘ .
a
used : event list → msg set
Aceasta poate fi definit˘ inductiv prin:
a
0. used[] B.parts(initState B)
1. used((Says A B X) # evs) parts{X} ∪ used evs
2. used((Notes A X) # evs) parts{X} ∪ used evs
Noutatea unui mesaj m în urma evs poate fi modelat˘ prin m ∈ used evs.
a /
2.2.8 Modelarea protocolului
Modelarea formal˘ a unui protocol se face printr-o mul¸ime definit˘ inductiv de liste de
a t a
evenimente (urme ale protocolului), fiecare decriind o posibil˘ istorie a re¸elei în care protocolul
a t
este rulat. Pentru a modela formal un protocol trebuie s˘ specific˘ m regulile de construc¸ie a
a a t
acestei mul¸imi. Regula Nil define¸te cazul de baz˘ specificând faptul c˘ urma vid˘ apar¸ine
t s a a a t
modelului. Fiecare pas din protocol este formalizat printr-o regul˘ inductiv˘ care specific˘ cum
a a a
se extinde o anumit˘ urm˘ prin evenimentul de tip Says care descrie acel pas din protocol.
a a
Comportamentul unui posibil atacator este modelat printr-o alt˘ regul˘ numit˘ Fake, care for-
a a a
malizeaz˘ faptul c˘ acesta poate trimite orice mesaj pe care îl poate crea din componentele pe
a a
care le cunoa¸te.
s
2.2.9 Modelarea m˘ rcilor de timp
a
Bella în [5] propune o extensie a Metodei Inductive care permite modelarea m˘ rcilor de
a
timp (timestamps) în formalizarea mesajelor. M˘ rcile de timp sunt numere care marcheaz˘ o
a a
a t˘
anumit˘ instan¸a de timp si care permit evitarea atacurilor de tip reluare. Spre deosebire de non-
¸
ceuri care sunt numere aleatoare si pe care modelul presupune c˘ sunt imposibil de descoperit,
¸ a
m˘ rcile de timp pot fi ghicite de c˘ tre un atacator.
a a
18

19. Pentru a modela aceste numere avem nevoie de noi construc¸ii. Tipul de date msg este extins
t
cu un nou constructor Number care are ca parametru un num˘ r natural, iar m˘ rcile de timp T vor
a a
fi reprezentate într-un mesaj prin componenta Number T. Atacatorul poate ghici aceste numere
si poate crea alte mesaje utilizându-le, deci synth H trebuie extins˘ :
¸ a
5.Number N ∈ synth H
Regulile de rescriere pentru operatori trebuie actualizate:
parts({Number N} ∪ H) = {Number N} ∪ {parts H}
analz({Number N} ∪ H) = {Number N} ∪ {analz H}
Pentru a modela timpul curent trebuie specificat˘ o func¸ie care asigneaz˘ fiec˘ rui eveniment
a t a a
dintr-o urm˘ un num˘ r care va reprezenta normalizarea instan¸ei de timp când a avut loc.
a a t
CT : event list → nat
si vom defini
¸
CT evs lungime evs
O urm˘ a unui protocol care are lungimea n reprezint˘ o istorie a protocolului dup˘ ce n
a a a
evenimente au avut loc, ceea ce înseamn˘ c˘ timpul curent al urmei respective este exact n.
a a
Acest˘ formalizare ascunde problema sincroniz˘ rii ceasurilor care va face parte din încrederile
a a
minimale ale fiec˘ rui agent.
a
2.3 Modelarea protocoalelor bazate pe smart carduri
Smart cardurile înt˘ resc obiectivele protocoalelor care le utilizeaz˘ , dar acest lucru trebuie
a a
demonstrat formal. Metoda Inductiv˘ propus˘ de Paulson în [3] poate fi adaptat˘ conform [2]
a a a
pentru a verifica corectitudinea protocoalelor bazate pe smart carduri. Cardul va fi modelat
printr-un nou tip si poate interac¸iona cu cel care îl de¸ine prin mesaje. Fiecare card stocheaz˘
¸ t t a
o mul¸ime de secrete în func¸ie de aplica¸iile pentru care se utilizeaz˘ . Riscurile sunt modelate
t t t a
¸inând cont c˘ atacatorul poate clona cardurile altor agen¸i si le poate exploata resursele de
t a t ¸
calcul.
În analiza acestor protocoale de securitate bazate pe smart carduri, diver¸i factori pot influ-
s
en¸a evolu¸ia protocolului, de aceea este important ca atunci când model˘ m s˘ lu˘ m în calcul
t t a a a
tipul cardului, dac˘ este cu PIN sau far˘ , si mediul de execu¸ie adic˘ dac˘ intrusul poate inter-
a a ¸ t a a
cepta mesajele care sunt transmise între card si posesorul acestuia.
¸
19

20. 2.3.1 Smart Cardurile
Abordarea propus˘ presupune modelarea func¸ionalit˘¸ii smart cardurilor si nu a modului
a t at ¸
în care sunt implementate protocoalele. Pentru aceasta se introduce un nou tip card, iar pentru
a specifica c˘ fiecare agent de¸ine un card vom declara o func¸ie injectiv˘
a t t a
Card : agent → card
Agen¸ii interac¸ioneaz˘ cu propriile carduri prin transmiterea de inputuri si recep¸ionarea de
t t a ¸ t
outputuri de la acestea. Outputurile vor fi considerate corecte deoarece modelul presupune c˘ a
smart cardurile construiasc outputuri doar în cazul în care inputurile oferite sunt corecte, la fel
ca în lumea real˘ .
a
2.3.1.1 Vulnerabilit˘ ¸i
at
Furtul. Cardurile care ajung pe mâna unor persoane r˘ uvoitoare, în urma pierderii sau
a
a furtului, si nu mai pot fi folosite de posesorii propriu-zi¸i vor fi modelate printr-o mul¸ime
¸ s t
stolen ⊆ card.
Clonarea. Intrusul nu poate utiliza cardurile furate dac˘ nu cunoa¸te PIN-ul, dar se poate
a s
folosi de tehnicile moderne pentru a realiza atacuri fizice prin care s˘ ob¸in˘ informa¸ii din
a t a t
memoria EEPROM unde sunt stocate secretele. Având aceste date, acesta poate crea o clon˘ a a
cardului pe care s˘ o utilizeze. Aceste carduri vor fi modelate prin mul¸imea cloned ⊆ card.
a t
Clonare f˘ r˘ furt aparent. Tehnicile de atac la nivel fizic deterioreaz˘ cardul care nu mai
a a a
poate fi folosit dup˘ aceea. Dar dac˘ atacatorul dup˘ ce descoper˘ secretele creeaz˘ 2 clone ale
a a a a a
cardului, din care una o înapoiaz˘ posesorlui propriu-zis f˘ r˘ ca acesta s˘ -¸i dea seama atunci
a aa as
cardul va putea fi utilizat atât în mod legal cât si ilegal.
¸
Defec¸iuni ale magistralelor de date. Magistralele de date ale cardului pot fi corupte astfel
t
încât mesajele transmise c˘ tre CPU s˘ fie pierdute, modificate sau repetate. Acest lucru nu va fi
a a
modelat deoarece este în contradic¸ie cu presupunerea c˘ smart cardurile ofer˘ outputuri corecte
t a a
si c˘ majoritatea protocoalelor presupun mijloace de comunicare sigure între agent si smart card.
¸ a ¸
În cel mai r˘ u caz, atacatorul a modificat toate cardurile în acest mod înainte ca acestea s˘ fie
a a
personalizate. Inductiv aceast˘ situa¸ie va fi modelat˘ prin faptul c˘ evenimentele au loc doar în
a t a a
s˘
urma declan¸arii regulilor inductive, dar regulile nu trebuie for¸ate s˘ se declan¸eze chiar dac˘
t a s a
precondi¸iile sunt îndeplinite. Deasemenea regulile pot s˘ se declan¸eze în orice ordine, sau de
t a s
mai multe ori, iar fiecare din aceste posibilit˘¸i trebuie înregistrat˘ în urma corespunz˘ toare.
at a a
Defec¸iuni interne. La un moment dat smart cardurile pot avea anumite defec¸iuni devenind
t t
astfel inactive temporal sau pot s˘ nu mai func¸ioneze deloc. Modelul formal va lua în calcul
a t
aceste situa¸ii incluzând urme care dup˘ un anumit eveniment sau pentru un fragment finit dintr-
t a
o urm˘ aceste carduri nu mai sunt utilizate.
a
20

21. 2.3.1.2 Utilizarea cardului
Agen¸ii one¸ti pot utiliza propriile cardurile doar legal. Atacatorul utilizeaz˘ cardurile fu-
t s a
rate sau clonate ilegal si propriul card în mod legal. A¸adar un card care nu este furat poate fi
¸ s
utilizat de posesorul sau doar legal.
Definitia 1. legallyU(Card A) (Card A) ∈ stolen
¸ /
Atunci când agen¸ii comunic˘ cu cardurile prin mijloace nesigure, atacatorul poate inter-
t a
cepta mesajele transmise si poate afla PIN-urile în unele urme dup˘ care poate utiliza aceste
¸ a
carduri în mod ilegal, chiar dac˘ nu are acces fizic la ele. Dac˘ cardurile sunt f˘ r˘ PIN atunci
a a aa
atacatatorul le poate utiliza pe toate în mod ilegal. În cazul mijloacelor de comunicare sigure,
atacatorul nu poate monitoriza evenimentele care implic˘ smart cardurile, deci nu poate afla
a
PIN-urile interceptând mesajele. PIN-urile nu pot fi cunoscute decât ini¸ial si este necesar ca
t ¸
atacatorul s˘ aibe acces fizic la aceste carduri. Dac˘ protocolul presupune carduri f˘ r˘ PIN
a a aa
atunci este de ajuns s˘ se specifice doar accesul fizic. Modelarea acestor situa¸ii este specificat˘
a t a
în defini¸iile 2 si 3, ¸inând cont de cuno¸tin¸ele ini¸iale ale agen¸ilor.
t ¸ t s t t t
Atacatorul nu î¸i va utiliza cardul propriu în mod ilegal deoarece nu va ob¸ine informa¸ii
s t t
noi. La fel si în cazurile protocoalelor de securitate în care avem o entitate de încredere care
¸
de¸ine un card.
t
Card Spy ∈ stolen ∪ cloned
/ Card Server ∈ stolen ∪ cloned.
/
În cazul clon˘ rii f˘ r˘ furt aparent, cardurile pot fi utilizate atât în mod legal cât si ilegal.
a aa ¸
Fiecare agent poate verifica dac˘ este în posesia propriului card, adic˘ dac˘ nu este furat. Toate
a a a
ipotezele care vor mai fi necesare, în af˘ r˘ de acestea care pot fi verificate, reprezint˘ încrederea
aa a
minimal˘ a modelului care este tolerat˘ de principiul utilit˘¸ii scopului propus de Bella în [5].
a a at
2.3.1.3 Secrete
Deoarece ne intereseaz˘ doar partea opera¸ional˘ , vom modela doar cum secretele sunt
a t a
utilizate si cine le cunoa¸te. De obicei pe smart carduri se stocheaz˘ 2 chei simetrice: PIN-ul si
¸ s a ¸
cheia cardului. PIN-ul este stocat pe card dar este cunoscut si de agent.
¸
pinK : card → key pinK : agent →key crdK : card → key
În cazul protocoalelor de distribu¸ie de chei, fiecare card stocheaz˘ si o cheie a posesoru-
t a¸
lui, care nu este cunoscut˘ de acesta ca în cazul protocoalelor clasice dar totu¸i se p˘ streaz˘
a s a a
declara¸ia original˘ :
t a
shrK : agent → key
Modelul permite si includerea altor secrete în func¸ie de aplica¸iile în care va fi utilizat
¸ t t
s t˘
smart cardul. Formalizarea acestora se face cu u¸urin¸a prin includerea unor func¸ii potrivite si
t ¸
21

22. actualizarea cuno¸tin¸elor agen¸ilor.
s t t
2.3.2 Evenimente
Abordarea propus˘ de Bella în [2] extinde tipul de date pentru evenimente propus de Paul-
a
son cu 4 noi construc¸ii.
t
datatype event Says agent agent msg
Notes agent msg
Gets agent msg
Inputs agent card msg
CGets card msg
Outputs card agent msg
AGets agent msg
Primele 3 evenimente sunt pentru re¸ea respectiv trimiterea, memorarea si recep¸ionarea de
t ¸ t
mesaje. Ultimele 4 evenimente sunt ad˘ ugate pentru a modela interac¸iunea cu cardul. Agen¸ii
a t t
pot trimite inputuri c˘ tre card (Inputs) si cardurile s˘ le recep¸ioneze (CGets). Cardurile pot
a ¸ a t
trimite outputuri c˘ tre agen¸i (Outputs) iar agen¸ii s˘ le recep¸ioneze (AGets). Mesajele de pe
a t t a t
re¸ea sunt transmise pe alte canale decât cele pentru comunicarea dintre agen¸i si carduri, de
t t ¸
aceea se face distinc¸ia la recep¸ie.
t t
Dac˘ protocolul presupune c˘ agen¸ii si cardurile comunic˘ prin mijloace sigure atunci
a a t ¸ a
CGets si AGets pot fi omise deoarece atacatorul nu poate împiedica recep¸ia mesajelor. Car-
¸ t
durile pot verifica dac˘ un eveniment Inputs A C X a avut loc iar agentul poate verifica dac˘
a a
Outputs C A X a avut loc.
Noutatea este formalizat˘ de Paulson printr-o func¸ie:
a t
used : event list → msg set
care red˘ componentele st˘ rilor ini¸iale ale tuturor agen¸ilor si toate componentele mesajelor
a a t t ¸
care apar într-o anumit˘ urm˘ .
a a
0. used[] B.parts(initState B)
1. used((Says A B X) # evs) parts{X} ∪ used evs
2. used((Notes A X) # evs) parts{X} ∪ used evs
3. used((Gets A X) # evs) used evs
4. used((Inputs A C X) # evs) parts{X} ∪ used evs
5. used((CGets C X) # evs) used evs
6. used((Outputs C A X) # evs) parts{X} ∪ used evs
7. used((AGets A X) # evs) used evs
Func¸ia parts extrage toate componentele dintr-o mul¸ime de mesaje cu excep¸ia cheilor de
t t t
22

23. criptare. Recep¸ia unui mesaj nu extinde mul¸imea inductiv˘ deoarece aceast˘ opera¸ie este
t t a a t
efectuat˘ la transmiterea acestuia. Dac˘ în protocolul analizat se consider˘ mijloace sigure de
a a a
comunicare între agen¸i si smart carduri, atunci cazurile 5 si 7 pot fi omise.
t ¸ ¸
2.3.3 Cuno¸tin¸ele agen¸ilor
s t t
2.3.3.1 Agen¸ii
t
La fel ca în cazul protocoalelor de securitate clasice, pentru protocoalele bazate pe smart
carduri vom nota agen¸ii one¸ti prin Friend i (i num˘ r natural), intrusul îl vom nota cu Spy, iar
t s a
serverul cu S sau Server. Agen¸ii compromi¸i care î¸i dezv˘ lui secretele atacatorului fac parte
t s s a
din mul¸imea bad.
t
2.3.3.2 Cuno¸tin¸ele ini¸iale ale agen¸ilor
s t t t
Func¸ia initState formalizeaz˘ cuno¸tin¸ele ini¸iale ale agen¸ilor. Dac˘ protocoalele de se-
t a s t t t a
curitate care sunt analizate utilizeaz˘ carduri cu PIN atunci cuno¸tin¸ele ini¸iale ale agen¸ilor
a s t t t
pot fi definite dup˘ cum urmeaz˘ .
a a
1. Mul¸imea cuno¸tin¸elor ini¸iale ale serverului este format˘ din toate cheile secrete.
t s t t a
initState S {Key(pinK A)} ∪ {Key(crdK C)} ∪ {Key(shrK A)}
2. Agen¸ii one¸ti cunosc ini¸ial doar PIN-ul.
t s t
initState (Friend i) {Key(pinK (Friend i))}
3. Mul¸imea cuno¸tin¸ele ini¸iale ale intrusului este format˘ din toate cuno¸tin¸ele ini¸iale
t s t t a s t t
ale agen¸ilor compromi¸i si secretele cardurilor clonate.
t s ¸
initState Spy {Key(pinK A)|A ∈ bad ∨ (Card A) ∈ cloned}∪
{Key(crdK C)|C ∈ cloned}∪
{Key(shrK A)|(Card A) ∈ cloned}
Pentru protocoalele de securitate în care se utilizeaz˘ smart carduri f˘ r˘ PIN, serverul cunoa¸te
a aa s
ini¸ial doar cheile cardurilor si cheile care vor fi distribuite agen¸ilor în cazul protocoalelor de
t ¸ t
distribu¸ie de chei, agen¸ii one¸ti nu au nici o informa¸ie ini¸ial˘ despre secrete, iar atacatorul
t t s t t a
are doar cuno¸tin¸ele ob¸inute din clonarea cardurilor.
s t t
2.3.3.3 Cuno¸tin¸ele pe care agen¸ii le extrag din observarea traficului
s t t
Cuno¸tin¸ele pe care agen¸ii le pot extrage din observarea traficului de pe o anumit˘ urm˘
s t t a a
sunt formalizate prin func¸ia:
t
23

24. knows [agent, event list] → msg set
Aceast˘ func¸ie o extinde pe cea propus˘ de Paulson spies care specifica doar cuno¸tin¸ele
a t a s t
intrusului.
Pentru a modela aceste cuno¸tin¸e trebuie s˘ lu˘ m în calcul mijloacele de comunicare dintre
s t a a
agent one¸ti si smart card. Dac˘ se consider˘ c˘ aceste mijloace sunt nesigure si atacatorul poate
s ¸ a a a ¸
intercepta mesajele transmise atunci:
0. Un agent î¸i cunoa¸te starea ini¸ial˘ .
s s t a
knows A[] initState A
1. Un agent cunoa¸te ce mesaje a trimis într-o urm˘ . Intrusul cunoa¸te toate mesajele care
s a s
au fost trimise într-o urm˘ .
a

{X} ∪ knows A evs dac˘ A = A ∨ A = Spy
a
knows A((Says A B X) # evs)
knows A evs altfel
2. Un agent cunoa¸te ceea ce memoreaz˘ într-o urm˘ . Intrusul cunoa¸te ceea ce au memorat
s a a s
agen¸ii compromi¸i într-o urm˘ .
t s a

{X} ∪ knows A evs dac˘ A = A ∨ (A = Spy ∧ A = bad)
a
knows A((Notes A X) # evs)
knows A evs altfel
3. Un agent onest cunoa¸te ceea ce recep¸ioneaz˘ într-o urm˘ . Mul¸imea de cuno¸tin¸e ale
s t a a t s t
intrusului nu mai este extins˘ în cazul recep¸iei unui mesaj deoarece aceasta este actualizat˘ în
a t a
momentul în care mesajul este transmis si nu se mai pot ob¸ine alte informa¸ii noi
¸ t t
.

{X} ∪ knows A evs dac˘ A = A ∧ A = Spy
a
knows A((Gets A X) # evs)
knows A evs altfel
4. Un agent cunoa¸te ce inputuri a trimis cardului într-o urm˘ . Intrusul cunoa¸te toate
s a s
inputurile trimise într-o urm˘ .
a

{X} ∪ knows A evs dac˘ A = A ∨ A = Spy
a
knows A((Inputs A C X) # evs)
knows A evs altfel
5. Nici un agent nu î¸i poate extinde mul¸imea de cuno¸tin¸e în urma recep¸iei de c˘ tre smart
s t s t t a
24

25. card a unui mesaj, deoarece acestea deja au fost inputuri iar mul¸imile de cuno¸tin¸e actualizate.
t s t
knows ((CGets C X) # evs) knows A evs
6. Agen¸ii one¸ti nu cunosc outputurile cardurilor în nici o urm˘ . Intrusul cunoa¸te toate
t s a s
outputurile din moment ce controleaz˘ mijloacele de comunicare dintre carduri si agen¸i.
a ¸ t

{X} ∪ knows A evs dac˘ A = Spy
a
knows A((Outputs C A X) # evs)
knows A evs altfel
7. Agen¸ii one¸ti cunosc outputurile primite de la cardurile proprii într-o urm˘ . Mul¸imea
t s a t
cuno¸tin¸elor intrusului ca urmare a recep¸iei unui output din partea cardului nu trebuie extins˘
s t t a
deoarece aceasta a fost actualizat˘ în momentul trimiterii outputului conform 6.
a

{X} ∪ knows A evs dac˘ A = A ∧ A = Spy
a
knows A((AGets A X) # evs)
knows A evs altfel
Func¸ia analz extrage toate componentele mesajelor dintr-o mul¸ime de mesaje folosind chei
t t
care sunt descoperite recursiv.
Definitia 2. Presupunând mijloace de comunicare nesigure:
¸

Key (pinK A) ∈ analz (knows Spy evs) daca cardurile sunt cu PIN
˘
illegallyU(Card A) on evs
true ˘ ˘ ˘
daca cardurile sunt f ara PIN
Dac˘ se presupune c˘ mijloacele de comunicare dintre agen¸i si carduri sunt sigure, atunci
a a t ¸
cazurile 5 si 7 nu mai sunt necesare deoarece evenimentele nu mai sunt definite, iar atacatorul
¸
nu poate intercepta mesajele. Doar cazurile 4 si 6 trebuie modificate corespunz˘ tor astfel încât
¸ a
atacatorul s˘ nu poat˘ înv˘¸a nimic din evenimentele cardurilor.
a a at
4’. Un agent, inclusiv intrusul, cunoa¸te ceea ce trimite ca input unui card.
s

{X} ∪ knows A evs dac˘ A = A
a
knows A((Inputs A C X) # evs)
knows A evs altfel
5’. Un agent, inclusiv intrusul, cunoa¸te ceea ce recep¸ioneaz˘ ca output de la orice card
s t a
într-o urm˘ .
a

{X} ∪ knows A evs dac˘ A = A
a
knows A((Outputs C A X) # evs)
knows A evs altfel
Atacatorul poate utiliza un card doar dac˘ cunoa¸te PIN-ul. În acest caz în care ipotezele
a s
25

26. analizei presupun mijloace de comunicare sigure, singurul mod ca intrusul s˘ cunoasc˘ PIN-
a a
ul este s˘ -l cunoasc˘ ini¸ial prin intermediul unui agent compromis. Deasemenea atacatorul
a a t
trebuie s˘ aibe acces fizic la card.
a
Definitia 3. Presupunând mijloace de comunicare sigure:
¸

(Card A) ∈ cloned ∨ ((Card A) ∈ stolen ∧ A ∈ bad)





 dac˘ cardurile sunt cu PIN
a
ilegallyU(Card A) on evs
(Card A) ∈ cloned ∨ (Card A) ∈ stolen





 dac˘ cardurile sunt f˘r˘ PIN
a aa
2.3.4 Modelul intrusului
Comportamentul ilegal al atacatorului este specificat pentru protocoalele clasice printr-o
singur˘ regul˘ Fake care extinde modelul protocolului. Exemplu pentru un protocol teoretic
a a
trad_p:
Fake
[| evsF ∈ trad_p; X ∈ synth(analz(knows Spy evsF)) |]
=⇒ Says Spy B X # evsF ∈ trad_p
Operatorul analz permite extragerea componentelor din mul¸imea de cuno¸tinte a unui agent
t s
într-o anumit˘ urm˘ . Operatorul synth permite crearea de mesaje prin criptarea si concatenarea
a a ¸
componentelor. Cu ajutorul acestor operatori intrusul poate crea noi mesaje pe care s˘ le trimit˘
a a
celorlal¸i agen¸i.
t t
Pentru protocoalele bazate pe smart carduri, pe lâng˘ aceste mesaje false pe care le poate
a
trimite prin re¸ea, atacatorul trebuie s˘ poat˘ exploata utilizarea în mod ilegal a cardurilor atunci
t a a
când agen¸ii si cardurile comunic˘ prin mijloace nesigure. De exemplu s˘ poat˘ trimite inpu-
t ¸ a a a
turi false c˘ tre cardurile pe care le utilizeaz˘ în mod ilegal dar si outputuri false c˘ tre agen¸i
a a ¸ a t
pretinzând c˘ sunt din partea propriilor carduri.
a
Fake
[| evsF ∈ smart_p_insecure_m; illegallyU(Card A) on evsF;
X ∈ synth(analz(knows Spy evsF)) |]
=⇒ Says Spy B X # Inputs Spy (Card A) X # Outputs (Card Spy) C X
# evsF ∈ smart_p_insecure_m
Dac˘ agen¸ii si cardurile comunic˘ prin mijloace sigure atunci atacatorul nu poate trimite
a t ¸ a
outputuri false c˘ tre agen¸i.
a t
26

27. Fake
[| evsF ∈ smart_p_secure_m; illegallyU(Card A);
X ∈ synth(analz(knows Spy evsF)) |]
=⇒ Says Spy B X # Inputs Spy (Card A) X
# evsF ∈ smart_p_secure_m
Pentru a specifica c˘ intrusul ob¸ine informa¸ii din outputurile cardurilor care sunt utilizate
a t t
în mod ilegal atunci când acesta are acces fizic la ele, trebuie s˘ specific˘ m alte 2 reguli. Regula
a a
Name formalizeaz˘ cazul în care cardul este utilizat în mod legal, iar regula Name_Fake cel în
a
care cardul este utilizat ilegal de c˘ tre intrus, dar pentru a ob¸ine informa¸ii acesta trebuie s˘
a t t a
falsifice inputul.
Name
[| evsN ∈ smart_p_secure_m; legallyU(Card A);
Inputs A (Card A) X ∈ set evsN|]
=⇒ Outputs (Card A) A X # evsN ∈ smart_p_secure_m
Name_Fake
[| evsNF ∈ smart_p_secure_m; illegallyU(Card A);
Inputs Spy (Card A) X ∈ set evsNF|]
=⇒ Outputs (Card A) Spy X # evsNF ∈ smart_p_secure_m
2.3.5 Modelarea formal˘ a protocolalelor
a
Definirea modelului pentru protocoale bazate pe smart carduri necesit˘ reguli adi¸ionale de
a t
recep¸ie numai în cazul în care agen¸ii si cardurile comunic˘ prin mijloace nesigure. Aceste
t t ¸ a
reguli nu sunt for¸ate s˘ se declan¸eze, deoarece atacatorul ar putea împiedica transmiterea
t a s
mesajelor. În cazul mijloacelor de comunicare sigur˘ recep¸ia este garantat˘ .
a t a
CReception
[| evsRc ∈ smart_p_insecure_m; Inputs A (Card B) X ∈ set evsRc|]
=⇒ CGets (Card B) X # evsRc ∈ smart_p_insecure_m
AReception
[| evsRa ∈ smart_p_insecure_m; Outputs (Card A) B X ∈ set evsRa|]
Inputs Spy (Card A) X ∈ set evsNF|]
=⇒ AGets B X # evsRa ∈ smart_p_insecure_m
27

28. Capitolul 3
Protocolul KLOMP
În contextul utiliz˘ rii tot mai accentuate a Internetului în activit˘¸ile comerciale, apare ca
a at
esen¸ial˘ stabilirea unui cadru robust de încredere pentru aplica¸iile care implementeaz˘ astfel
t a t a
de servicii. În general persoanele care intra în leg˘ tur˘ prin Internet pentru a realiza schimburi
a a
de bunuri, servicii sau informa¸ii nu se cunosc în prealabil, iar circula¸ia datelor se face liber
t t
f˘ r˘ un control si o cenzur˘ restrictiv˘ , de unde apare pericolul intercept˘ rii, modific˘ rii sau fal-
aa ¸ a a a a
sific˘ rii acestora. Astfel cea mai important˘ provocare ce st˘ în fa¸a domeniului este asigurarea
a a a t
securit˘¸ii tranzac¸iilor.
at t
Bakker propune în [8] protocolul Klomp ca solu¸ie pentru securizarea acestor tranzac¸ii, fi-
t t
ind un protocol de autentificare si distribu¸ie a cheilor bazat pe smart carduri si care utilizeaz˘
¸ t ¸ a
tehnici de criptare care pot fi exportate legal. Acesta este derivat din familia de protocoale Kryp-
toKnight proiectat˘ de IBM si a fost testat pentru smart cardurile Dutch Chipper si ChipKnip
a ¸ ¸
care au deja func¸ia de portofel electronic implementat˘ , dar care este folosit˘ ca si sistem de
t a a ¸
plat˘ offline. Protocolul a fost dezvoltat pentru a fi utilizat în aplica¸iile Web de comer¸ elec-
a t t
tronic prin Internet, stabilind un canal sigur de comunicare între browserul clientului si serverul
¸
HTTP în urma autentific˘ rii mutuale si a negocierii cheilor de sesiune, dar properiet˘¸ile de
a ¸ at
confiden¸ialitate, integritate si non-repudiere nu fac scopul lucr˘ rii. Protocolul poate fi folosit în
t ¸ a
sistemele de plat˘ online si sunt necesare 3 entit˘¸i: un consumator care va fi clientul, un server
a ¸ at
care furnizeaz˘ serviciile si o autoritate de încredere, cea care emite smart cardurile, de obicei
a ¸
banca. În urma execu¸iei se va realiza:
t
• Autentificarea sursei. Protocolul va returna un identificator al entit˘¸ii care dore¸te s˘ se
at s a
autentifice, care poate fi persistent - un num˘ r de cont sau de membru, sau temporar - valid
a
28

29. doar pe durata sesiunii. Dac˘ este persistent atunci autoritatea de încredere garanteaz˘ c˘
a a a
acel ID este al participantului respectiv. Protocolul nu va mai continua dac˘ una din p˘ r¸i
a at
nu este autentificat˘ .
a
• Negocierea cheilor. Dac˘ autentifiticarea a fost cu succes atunci protocolul va returna
a
o cheie secret˘ partajat˘ ambilor participan¸i, care va fi utilizat˘ ca si cheie de sesiune
a a t a ¸
pentru a oferi autentificarea si integritatea mesajelor ulterioare si op¸ional pentru criptare.
¸ ¸ t
Sistemul poate utiliza aproape orice tip de smart card, cerin¸ele minimale fiind ca acesta
t
s˘ con¸in˘ un identificator, care poate fi num˘ rul de cont sau num˘ rul de membru, o cheie
a t a a a
care s˘ fie unic˘ pentru fiecare de¸in˘ tor de card si administrat˘ de autoritatea de încredere,
a a t a ¸ a
si s˘ ofere un mecanism provocare-r˘ spuns care s˘ utilizeze cheia unic˘ pentru a demonstra
¸ a a a a
validitatea identificatorului. Pentru a autentifica fiecare smart card, fiecare terminal de plat˘ a
(PTS - payment terminal system) trebuie s˘ cunoasc˘ cheile unice ale fiec˘ rui card. O prim˘
a a a a
solu¸ie ar fi crearea unei baze de date cu toate cheile secrete de autentificare ale cardurilor la
t
fiecare terminal, dar aceast˘ nu este o solu¸ie indicat˘ deoarece în cazul sistemelor cu foarte
a t a
multe carduri acest˘ baz˘ de date ar atinge propor¸ii foarte mari. Solu¸ia practicat˘ este crearea
a a t t a
cheii de autentificare pe baza unei singure chei master administrat˘ de banc˘ si identificatorul
a a¸
fiec˘ rui card: Kcard = EKm (IDcard ) sau Kcard = MACKm (IDcard ) , astfel încât terminalul trebuie
a
s˘ cunoasc˘ doar cheia master dup˘ care poate calcula fiecare cheie de autentificare pe baza
a a a
identificatorului furnizat de card. Astfel smart cardul va con¸ine doar cheia Kcard iar dac˘ cheia
t a
master este descoperit˘ în vreun fel atunci întreg sistemul va fi compromis.
a
Protocolul presupune c˘ mijloacele de comunicare dintre smart card si de¸in˘ torul de card
a ¸ t a
sunt sigure deoarece cheile temporare care stau la baza cheii de sesiune sunt transmise în clar, iar
smart cart cardurile nu utilizeaz˘ PIN-uri. Ordinea si direc¸ia fluxului de mesaje este prezentat˘
a ¸ t a
în Figura 2.
Descrierea protocolului
Pasul 1. Declan¸eaz˘ începerea protocolului de autentificare. Clientul trimite serverului un
s a
parametru de verificare V A , creat din aplicarea unei func¸ii hash asupra unui num˘ r aleator N A
t a
ales de el concatenat cu un num˘ r de salt S A . Acest S A este folosit pentru a diminua posibili-
a
tatea serverului de a deduce N A prin atacuri de tip dic¸ionar înainte ca acesta s˘ trimit˘ propriu
t a a
num˘ r aleator N B c˘ tre client.
a a
Pasul 2. Serverul r˘ spunde cu identificatorul s˘ u B , un num˘ r aleator N B si o marc˘ de timp
a a a ¸ a
T care specific˘ o fereastr˘ de timp în care sesiunea de autentificare trebuie s˘ fie efectuat˘ . T
a a a a
va fi verificat˘ de c˘ tre autoritatea de încredere deci trebuie s˘ existe o sincronizare a ceasurilor
a a a
între server si autoritatea de încredere.
¸
29

30. Pasul 3. Clientul trimite c˘ tre cardul s˘ u propriul nonce
a a NA , si datele primite de la server
¸
N B , T si B .
¸
Pasul 4. Cardul calculeaz˘ un rezumat hash CA din datele primite (provocarea clientului)
a
si va r˘ spunde cu identificatorul agentului A, tipul identificatorului IA , r˘ spunsul la provocare
¸ a a
KA∗ si op¸ional orice date utilizate în calculul r˘ spunsului la provocare DA . KA∗ va fi folosit
¸ t a
ca si cheie temporar˘ si va fi utilizat˘ în generarea cheii de sesiune KAB . Func¸ia de generare
¸ a¸ a t
de chei va fi considerat˘ KAB = H(KA∗ //NA ). Dovada de autenticitate P AK este calculat˘ din
a a
A, NA , NB si K AB folosind formula PAK = MACAB (NA //NB //A). Folosirea lui KAB în loc de
¸
KA∗ face ca dovada de la A pentru autoritatea de încredere s˘ fie identic˘ cu cea c˘ tre serverul
a a a
B : PAK = PAB .
Pasul 5. Clientul trimite to¸i parametrii (A, NA , IA , DA , PAK , B , NB ,
t T ) la server. B poate
acum verifica c˘ N A a fost ales înainte ca sa-¸i trimit˘ propiul nonce N B .
a s a
Pasul 6. Serverul trimite c˘ tre cardul s˘ u propriul nonce
a a NB , si datele primite de la client
¸
N A , T si A
¸
Pasul 7. Smart cardul serverului calculeaz˘ o provocare CB asem˘ n˘ toare cu cea calculat˘
a a a a
în pasul 4 de cardul clientului si r˘ spunde serv˘ rului cu B , IB , KB∗ , DB . KB∗ reprezint˘ cheia
¸ a a a
temporar˘ a serverului cu care acesta va crea certificatul de autenticitate pentru autoritatea de
a
încredere.
Pasul 8. Serverul nu trebuie s˘ genereze o cheie de sesiune si nici s˘ calculeze o dovad˘
a ¸ a a
pentru client în acest pas, deci poate calcula direct PBK folosind KB∗ . Serverul nu poate verifica
P AK deoarece nu cunoa¸ te înc˘ cheia KAB deci va trimite to¸i parametrii la autoritatea de încre-
s a t
dere: (A, NA , IA , DA , PAK , B , NB , IB , DB , PBK , T ).
Pasul 9. Autoritatea de încredere verific˘ to¸i parametrii primi¸i de la serverul B .
a t t
• Marca de timp T este valid˘ ?
a
• Este A un identificator valid al unui client activ?
• Este B un identificator valid al unui server activ?
• Corespunde dovada P AK valorii calculate cu cheia autentic˘ a clientului KA ?
a
• Corespunde dovada PBK valorii calculate cu cheia autentic˘ a serverului KB ?
a
30

31. În cazul în care verific˘ rile au fost cu succes, autoritatea de încredere va calcula cheia de
a
sesiune si o va cripa pentru server folosind func¸ia TBA =H(KB∗ //NB ) ⊕ KAB . Aceasta va fi
¸ t
trimis˘ c˘ tre B .
a a
Pasul 10. Serverul decripteaz˘ cheia de sesiune KAB si poate verifica P AK care este calculat
a ¸
din valoare secret˘ KAB si valorile publice NA , NB si A. Dac˘ verificarea a fost cu succes, B va
a ¸ ¸ a
calcula dovada P BA pentru client si o va trimite acestuia. În final clientul va verifica aceast˘
¸ a
valoare.
Figura 2: Protocolul KLOMP (KryptoKnight-based Lightweight Open Mutual authentication
Protocol)
31

32. Capitolul 4
Analiza protocolului KLOMP
4.1 Modelarea protocolului
Modelarea evenimentelor, a smart cardurilor si a intrusului este realizat˘ pe baza formalizarii
¸ a
care a fost propus˘ în capitolul 3. Modelul formal al protocolului este o mul¸ime de liste de
a t
evenimente numit˘ klomp creat˘ pe baza protocolului Klomp propus de Bakker în [8]. În cele
a a
ce urmeaz˘ clientul va fi notat cu A, serverul cu B iar autoritatea de încredere cu Server.
a
Protocolul construie¸te 2 tipuri de chei: chei temporare care de fapt sunt r˘ spunsuri la pro-
s a
vocarile agen¸ilor si chei de sesiune care sunt calculate din nonce-uri si aceste chei temporare.
t ¸ ¸
tempK : msg → key sesK : nat ∗ key → key
Cheile de sesiune vor fi generate de c˘ tre client.
a
Defini¸ia initState trebuie actualizat˘ în conformitate cu modelul protocolului. Deoarece se
t a
utilizeaz˘ carduri f˘ r˘ PIN putem omite func¸ia pinK. Cuno¸tin¸ele ini¸iale ale serverului este
a aa t s t t
mul¸imea format˘ din toate cheile secrete.
t a
initState S {Key(crdK C)} ∪ {Key(shrK A)}
Agen¸ii one¸ti nu cunosc nimic ini¸ial deci nu pot dezv˘ lui nimic ini¸ial atacatorului.
t s t a t
initState (Friend i) {}
32

33. Cuno¸tin¸ele ini¸iale ale intrusului sunt toate cuno¸tin¸ele ini¸iale ale agen¸ilor compromi¸i
s t t s t t t s
si secretele cardurilor clonate.
¸
initState Spy {Key(crdK C)|C ∈ cloned}∪
{Key(shrK A)|(Card A) ∈ cloned}
Ca urmare a utiliz˘ rii cardurilor f˘ r˘ PIN, în cazul utiliz˘ rii cardurilor în mod ilegal se va
a aa a
aplica defini¸ia 3:
t

(Card A) ∈ cloned ∨ ((Card A) ∈ stolen ∧ A ∈ bad)





 dac˘ cardurile sunt cu PIN
a
illegallyU(Card A) on evs
(Card A) ∈ cloned ∨ (Card A) ∈ stolen





 dac˘ cardurile sunt f˘r˘ PIN
a aa
Protocolul folose¸te m˘ rci de timp, deci timpul curent estedefinit prin func¸ia CT din sec-
s a t
¸iunea 2.2.7. Pentru a rezolva problema verific˘ rii unei marci de timp în func¸ie de timpul
t a t
curent si relativ la o durat˘ de via¸a specific˘ , vom specifica un num˘ r natural sesKlife care va
¸ a t˘ a a
t˘
formaliza durata de via¸a a cheii de sesiune. Agen¸ii vor verifica m˘ rcile de timp în func¸ie
t a t
de acesta perioad˘ de valabilitate si vor ignora mesajele care con¸in m˘ rci de timp expirate,
a ¸ t a
folosind predicatul:
expired : [nat, event list]
care este definit prin
expired T evs (CT evs) − T > sesKlife
Dac˘ are loc expired T evs atunci a trecut mai mult timp decât specific˘ sesKlife din mo-
a a
mentul în care T a ap˘ rut pentru prima dat˘ în urma evs, iar cheia de sesiune asociat˘ a expirat.
a a a
Fiecare card memoreaz˘ un identificator unic pentru proprietarul cardului, de exemplu nu-
a
m˘ rul de card. Pentru fiecare input primit cardul va returna acest identificator. Pentru a specifica
a
identificatorul unui agent vom utiliza o nou˘ func¸ie cardID care va asocia fiec˘ rui card un iden-
a t a
tificator unic:
cardID : card → nat
4.1.1 Baza
Urma vid˘ formalizeaz˘ scenariul ini¸ial în care nici o sesiune a protocolului nu a avut
a a t
loc. Regula Base pune bazele induc¸iei în care se specific˘ c˘ urma vid˘ este admis˘ în mo-
t a a a a
delul protocolului. Celelalte reguli vor fi pa¸ii induc¸iei specificând cum se extinde o anumit˘
s t a
33

34. urm˘ . Regula Reception formalizeaz˘ faptul c˘ mesajele trimise prin re¸ea pot fi primite de c˘ tre
a a a t a
destinatari.
Base
[] ∈ klomp
Reception
[| evsR ∈ klomp; Says A B X ∈ set evsR|]
=⇒ Gets B X # evsR ∈ klomp
4.1.2 Pasul 1
Orice agent poate ini¸ia o sesiune a protocolului, în orice moment deci evenimentul cores-
t
punz˘ tor pasului 1 - K1 poate extinde orice urm˘ . Ini¸iatorul trebuie s˘ genereze un rezumat
a a t a
hash pentru un nou num˘ r aleator Na si un num˘ r de salt public Sa astfel încât cel care recep-
a ¸ a
¸ioneaz˘ mesajul s˘ nu poat˘ descoperi în timp util num˘ rul aleator dar care poate fi verificat în
t a a a a
pasul 5. Receptorul trebuie s˘ verifice c˘ acest Na a fost ales înainte ca el s˘ -i furnizeze propriul
a a a
num˘ r aleator Nb în pasul 2.
a
K1
[| evs1 ∈ klomp; Nonce Na ∈ used evs1; A = Server|]
/
=⇒ Says A B {| Number Sa, Hash {|Number Sa, Nonce Na|} |} # evs1 ∈ klomp
4.1.3 Pasul 2
În urma recep¸iei unui mesaj format din dou˘ componente, un num˘ r de salt Sa care este
t a a
public si un rezumat hash, cel care îl recep¸ioneaz˘ va genera un nonce nou Nb pe care îl va
¸ t a
furniza ini¸iatorului mesajului împreun˘ cu identitatea sa B si un num˘ r care reprezint˘ timpul
t a ¸ a a
s˘ u curent. Receptorul nu poate verifica rezumatul hash deoarece nu cunoa¸te nonce-ul Na.
a s
K2
[| evs2 ∈ klomp; Nonce Nb ∈ used evs2; B = Server;
/
Gets B {| Number Sa, Verifier |} ∈ set evs2|]
=⇒ Says B A {| Agent B, Nonce Nb, Number (CT evs2) |} # evs2 ∈ klomp
4.1.4 Pasul 3
Ini¸iatorul unei sesiuni a protocololului dac˘ este onest, în urma recep¸iei datelor de la cel cu
t a t
care dore¸te stabilirea leg˘ turii sigure: identitatea agentului B , un num˘ r aleator Nb si un num˘ r
s a a ¸ a
care reprezint˘ o marc˘ de timp Tk , le va trimite mai departe c˘ tre propriul card împreun˘ cu
a a a a
nonceul generat la ini¸ializarea sesiunii.
t
34

35. K3
[| evs3 ∈ klomp; legallyU(Card A);
Says A B {| Number Sa, Hash {| Number Sa, Nonce Na |} |} ∈ set evs3;
Gets A {| Agent B, Nonce Nb, Number Tk |} ∈ set evs3 |]
=⇒ Inputs A (Card A) {| Nonce Na, Nonce Nb,
Number Tk, Agent B |} # evs3 ∈ klomp
4.1.5 Pasul 4
Dac˘ cardul agentului A este utilizat în mod legal, primind inputul format din 2 nonceuri, o
a
marc˘ de timp si numele unui agent va crea un rezumat hash din aceste date Ca care va repre-
a ¸
zenta provocarea de¸in˘ torului de card. Pe baza acestui rezumat hash cardul va genera o cheie
t a
temporar˘ K a∗ care reprezint˘ r˘ spunsul la provocare calculat cu cheia cardului crdK(Card A),
a a a
si pe care o va returna agentului împreun˘ cu identitatea de¸in˘ torului de card A, identificatorul
¸ a t a
de¸inut de acesta si eventual alte date care sunt utilizate în calculul r˘ spunsului Da. Cardul nu
t ¸ a
va re¸ine în memorie nici o dat˘ referitoare la provocare sau r˘ spunsul generat.
t a a
K4
[| evs4 ∈ klomp; legallyU(Card A); A = Server; ; Key Ka∗ ∈ symKeys;
Inputs A (Card A) {| Nonce Na, Nonce Nb,
Number Tk, Agent B |};
Ca = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent B |};
Ka∗ = tempK(Crypt (crdK(CardA)) {| Ca, Number Da |}) |]
=⇒ Outputs (Card A) A {| Agent A, Nonce (cardID(Card A)),
Key Ka∗, Number Da |} # evs4 ∈ klomp
4.1.6 Pasul 5
Dac˘ A este ini¸iatorul protocolului si a primit de la card un r˘ spuns con¸inând identitatea
a t ¸ a t
si identificatorul proprietarului cardului, o cheie temporar˘ si alte date utilizate în generarea
¸ a¸
r˘ spunsului, atunci A poate genera o cheie de sesiune folosind cheia temporar˘ si nonce-ul
a a ¸
utilizat în pasul 1 Na. Cheia de sesiune va fi partajat˘ la sfâr¸itul protocolului cu serverul
a s
B . Folosind aceast˘ cheie A va crea un certificat care va fi folosit pentru a se autentifica în
a
fa¸a serverului si a autorit˘¸ii de încredere. Acest certificat împreun˘ cu toate datele colectate
t ¸ at a
pân˘ în acest moment sunt transmise c˘ tre server. Autoritatea de încredere verific˘ certificatul
a a a
prin recreerea cheii de sesiune K ab în pasul 9 iar serverul va putea verifica certificatul doar în
momentul în care va fi în posesia acesteia, adic˘ în pasul 10.
a
35

36. K5
[| evs5 ∈ klomp;
Gets A {| Agent B, Nonce Nb, Number Tk |} ∈ set evs5;
Outputs (Card A) A {| Agent A, Nonce Ia, Key Ka, Number Da |} ∈ set evs5;
Kab = sesK(Na, Ka); Key Kab ∈ used evs5 ; Key Kab ∈ symKeys|]
/
=⇒ Says A B {| Agent A, Nonce Na, Nonce Ia, Number Da, Crypt Kab {|Nonce Na, Nonce Nb,
Agent A|}, Agent B, Nonce Nb, Number Tk |} # evs5 ∈ klomp
4.1.7 Pasul 6
Dac˘ B este un server legitim atunci acesta i¸i utilizeaz˘ cardul în mod legal. Primind
a s a
toate datele necesare de la ini¸iatorul unei sesiuni acesta poate crea o provocare Cb si o cheie
t ¸
temporar˘ folosind propiul card. În aces pas serverul poate verifica dac˘ num˘ rul aleator ales
a a a
de client Na nu este compromis (dac˘ a fost ales la începutul sesiunii). Verificarea se face prin
a
compararea verificatorului primit în pasul 1 si un rezumat hash calculat din num˘ rul de salt Sa
¸ a
primit în pasul 1 si nonce-ul Na primit în acest pas. Serverul trimite c˘ tre cardul s˘ u propriul
¸ a a
nonce Nb, nonceul primit de ini¸iatorul sesiunii Na, identitatea acestuia A si marca de timp Tk
t ¸
transmis˘ în pasul 2. Deoarece B nu este în posesia cheii de sesiune acesta nu poate înc˘ verifica
a a
autenticitatea clientului.
K6
[| evs6 ∈ klomp;legallyU(Card B);
Gets B {| Number Sa, Hash {| Number Sa, Nonce Na |} |} ∈ set evs6;
Says B A {| Agent B, Nonce Nb, Number Tk |} ∈ set evs6;
Gets B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Pak, Agent B, Nonce Nb, Number Tk |} ∈ set evs6 |]
=⇒ Inputs B (Card B) {| Nonce Na, Nonce Nb,
Number Tk, Agent A |} # evs6 ∈ klomp
4.1.8 Pasul 7
Fiind utilizat în mod legal, cardul serverului va genera un rezumat hash din datele primite
Cb si va calcula o cheie temporar˘ K b∗ asem˘ n˘ tore cu cea din pasul 4. Împreun˘ cu aceast˘
¸ a a a a a
cheie cardul va returna si identitatea si identificatorul de¸in˘ torului de card si eventual alte date
¸ ¸ t a ¸
utilizate în calculul r˘ spunsului.
a
36

37. K7
[| evs7 ∈ klomp; legallyU(Card B); B = Server; ; Key Kb∗ ∈ symKeys;
Inputs B (Card B) {| Nonce Na, Nonce Nb,
Number Tk, Agent A |};
Cb = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent A |};
Kb∗ = tempK(Crypt (crdK(CardB)) {| Cb, Number Db |}) |]
=⇒ Outputs (Card B) B {| Agent B, Nonce (cardID(Card B)),
Key Kb∗, Number Db |} # evs7 ∈ klomp
4.1.9 Pasul 8
Serverul B având toate datele, mai pu¸in cheia de sesiune, poate crea propiul certificat de
t
autenticitate Pbk care va fi verificat de c˘ tre autoritatea de încredere si pe care îl va trimite
a ¸
împreun˘ cu toate datele primite de la cardul s˘ u si de la client. Certificatul de autenticitate este
a a ¸
creat folosind cheia temporar˘ primit˘ de la card K b∗ .
a a
K8
[| evs8 ∈ klomp;
Gets B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Pak, Agent B, Nonce Nb, Number Tk |} ∈ set evs8;
Outputs (Card B) B {| Agent B, Nonce Ib, Key Kb, Number Db |} ∈ set evs8 |]
=⇒ Says B Server {| Agent A, Nonce Na, Nonce Ia, Number Da, Pak,
Agent B, Nonce Nb, Nonce Ib, Number Db, Crypt Kb
{|Nonce Na, Nonce Nb, Agent B|}, Number Tk |} # evs8 ∈ klomp
4.1.10 Pasul 9
Autoritatea de încredere primind toate datele, verific˘ în primul rând dac˘ marca de timp
a a
este valid˘ , dup˘ care verifica autenticitatea celor dou˘ entit˘¸i pe baza certificatelor si recreaz˘
a a a at ¸ a
cheia de sesiune pentru a o trimite c˘ tre B, criptat˘ cu o cheie ce poate fi construit˘ doar de
a a a
cel care de¸ine cheia temporar˘ K b∗ . Pentru a verifica certificatul Pak autoritatea de încredere
t a
trebuie s˘ recreeze provocarea Ca si folosind cheia cardului A s˘ ob¸in˘ cheia temporar˘ K a∗ .
a ¸ a t a a
Cu ajutorul acestei chei si folosind nonceul Na va recrea cheia de sesiune si va putea decripta
¸ ¸
si verifica certificatul Pak . Pentru a verifica certificatul Pbk autoritatea de încredere trebuie
¸
doar s˘ recreeze provocarea Cb si cheia temporar˘ K b∗ . Folosind aceast˘ cheie poate decripta
a ¸ a a
certificatul si verifica autenticitatea entit˘¸ii B . Dac˘ verificarea certificatelor a fost cu succes,
¸ at a
autoritatea de încredere va cripta cheia de sesiune cu o cheie pe care doar B o poate crea si va¸
trimite mesajul c˘ tre acesta.
a
37

38. K9
[| evs9 ∈ klomp;
Gets Server {| Agent A, Nonce Na, Nonce (cardID(Card A)), Number Da,
Crypt (sesK(Na, Ka)) {|Nonce Na, Nonce Nb, Agent A |},
Agent B, Nonce Nb, Nonce (cardID(Card B)), Number Db,
Crypt Kb {|Nonce Na, Nonce Nb, Agent B |}, Number Tk |} ∈ set evs9;
¬expired Tk evs9;
Ca = Hash {| Nonce Na, Nonce Nb , Number Tk, Agent B |};
Cb = Hash {| Nonce Na, Nonce Nb , Number Tk, Agent A |};
Ka = tempK(Crypt (crdK(Card A)) {| Ca, Number Da |});
Kb = tempK(Crypt (crdK(Card B)) {| Cb, Number Db |}) |]
=⇒ Says Server B (Crypt (sesK(Nb, Kb)) (Key (sesK(Na, Ka)))) # evs9 ∈ klomp
4.1.11 Pasul 10
Din cheia temporar˘ primit˘ de la card si nonceul propriu generat anterior serverul poate
a a ¸
crea cheia cu care este criptat˘ cheia de sesiune primit˘ de la autoritatea de încredere. Având
a a
cheia de sesiune acesta poate verifica certificatul de autenticitate primit în pasul 5 de la client
Pak si poate crea propriul certificat de autenticitate pentru A folosind cheia de sesiune Pba.
¸
K10
[| evs10 ∈ klomp;
Gets B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Crypt Kab {|Nonce Na, Nonce Nb, Agent A |},
Agent B, Nonce Nb, Number Tk |} ∈ set evs10;
Outputs (Card B) {| Agent B, Nonce Ib, Key Kb, Number Db |} ∈ set evs10;|]
Gets B (Crypt (sesK(Nb, Kb)) (Key Kab)) ∈ set evs10 |]
=⇒ Says B A (Crypt Kab {| Nonce Na, Nonce Nb |}) # evs10 ∈ klomp
4.1.12 Vulnerabilit˘ ¸i
at
Atacatorul se poate comporta atât legal urmând pa¸ii de mai sus sau ilegal folosind car-
s
durile altor agen¸i, caz în care trebuie s˘ specific˘ m reguli suplimentare. Conform modelului
t a a
Dolev-Yao acesta poate observa traficul de pe fiecare urm˘ , poate extrage toate componentele
a
mesajelor si poate construi mesaje false pe care s˘ le transmit˘ în re¸ea sau ca input la cardurile
¸ a a t
utilizate în mod ilegal. Acest comportament va fi modelat prin regula Fake.
Fake
[| evsF ∈ klomp; illegallyU(Card A);
X ∈ synth(analz(knows Spy evsF)) |]
=⇒ Says Spy B X # Inputs Spy (Card A) X # evsF ∈ klomp
38

39. Deoarece protocolul presupune mijloace de comunicare sigure, trebuie specificat faptul c˘ a
atacatorul poate s˘ ob¸in˘ outputuri de la cardurile utilizate în mod ilegal. Astfel regula K4_Fake
a t a
va modela cazul pentru pasul 4 iar regula K7_Fake pentru pasul 7.
K4− Fake
[| evs4F ∈ klomp; illegallyU(Card A); ; Key Ka∗ ∈ symKeys;
Inputs A (Card A) {| Nonce Na, Nonce Nb,
Number Tk, Agent B |};
Ca = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent B |};
Ka∗ = tempK(Crypt (crdK(CardA)) {| Ca, Number Da |}) |]
=⇒ Outputs (Card A) A {| Agent A, Nonce (cardID(Card A)),
Key Ka∗, Number Da |} # evs4F ∈ klomp
K7− Fake
[| evs7F ∈ klomp; illegallyU(Card B); ; Key Kb∗ ∈ symKeys;
Inputs B (Card B) {| Nonce Na, Nonce Nb,
Number Tk, Agent A |};
Cb = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent A |};
Kb∗ = tempK(Crypt (crdK(CardB)) {| Cb, Number Db |}) |]
=⇒ Outputs (Card B) Spy {| Agent B, Nonce (cardID(Card B)),
Key Kb∗, Number Db |} # evs7F ∈ klomp
4.1.13 Accidente
Modelul trebuie s˘ permit˘ bre¸e de securitate pentru cheile de sesiune, caz în care acestea
a a s
pot fi descoperite de atacator. De exemplu în pasul 9 al protocolului cheia Kab este transmis˘ a
de c˘ tre autoritatea de încredere lui B iar atacatorul ar putea avea sansa s˘ descopere cheia de
a ¸ a
sesiune.
Oops
[| evs0 ∈ klomp;Says Server B (Crypt K (Key sesK(Na, Ka∗)))∈ set evs0|]
=⇒ Notes Spy {| Key sesK(Na, Ka∗)|}# evs0 ∈ klomp
4.2 Verificarea protocolului
Pentru a specifica si verifica propriet˘¸ile protocolului Klomp în cele ce urmeaz˘ se va utiliza
¸ at a
o urm˘ generic˘ evs a modelului.
a a
39

40. 4.2.1 Corectitudinea modelului pentru protocolul Klomp
Aceste teoreme se bazeaz˘ pe ipotezele generale asupra sistemului prezentate în capitolul
a
2 si demonstreaz˘ consisten¸a modelului, dar si înc˘ lcarea principiului comunic˘ rii explicite
¸ a t ¸ a a
prezentat în capitolul 1 pentru pa¸ii 4 si 7 din protocol. Demonstra¸iile sunt simple: se aplic˘
s ¸ t a
induc¸ia dup˘ care se apeleaz˘ la simplific˘ ri.
t a a a
4.2.1.1 Corectitudinea model˘ rii serverului
a
Integritatea mesajelor trimise de autoritatea de încredere poate fi demonstrat˘ .
a
Teorema (Reli1)
Dac˘ evs con¸ine
a t
Says Server A (Tba)
atunci exist˘ Nb, Kab, Cb, Db astfel încât
a
T ba = Crypt (sesK(Nb, tempK(Crypt (crdK(Card B)) {|Nonce Na, Nonce Nb|})
4.2.1.2 Corectitudinea model˘ rii modului în care sunt utilizate cardurile
a
Dac˘ un agent onest trimite sau prime¸te un mesaj de la un card, atunci cardul apar¸ine
a s t
acelui agent si este utilizat în mod legal ceea ce confirm˘ faptul c˘ agen¸ii one¸ti pot utiliza doar
¸ a a t s
propriile carduri si doar în mod legal.
¸
Teorema (Reli2)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Inputs A C X sau Outputs C A Y
atunci
C = (Card A) si
¸ legallyU(Card A)
Dac˘ atacatorul utilizeaz˘ un card atunci acesta este ori propriul card, care este utilizat în
a a
mod legal, ori cardul altui agent, caz in care se comport˘ ilegal.
a
Teorema (Reli3)
Dac˘ evs con¸ine
a t
Inputs Spy C X sau Outputs C Spy Y
atunci
(C = (Card Spy) si
¸ legallyU(Card Spy)) sau
(∃A. C = (Card A) si
¸ illegallyU(Card A))
40

41. 4.2.1.3 Corectitudinea model˘ rii outputurilor cardurilor
a
Pentru a confirma faptul c˘ smart cardurile func¸ioneaz˘ corect trebuie s˘ demonstr˘ m dou˘
a t a a a a
teoreme asupra evenimentelor de tip Output. Prima teorem˘ demonstreaz˘ faptul c˘ smart car-
a a a
durile ofer˘ outputuri doar în momentul în care primesc un input corect.
a
Teorema (Reli4)
Dac˘ evs con¸ine
a t
Outputs (Card A) A {| Agent A, Nonce (cardID(Card A)),
Key (tempK(Crypt (crdK(Card A))
{| Hash {| Nonce Na, Nonce Nb, Number Tk, Agent B |},
Number Da |})), Number Da |}
atunci evs con¸ine si
t ¸
Inputs A (Card A) {| Nonce Na, Nonce Nb, Number Tk, Agent B |}
A doua teorem˘ demonstreaz˘ faptul c˘ smart cardurile produc outputuri corecte, adic˘
a a a a
forma componentelor poate fi dedus˘ .
a
Teorema (Reli5)
Dac˘ evs con¸ine
a t
Outputs (Card A) A {| Agent A, Nonce Ia, Key Ka∗, Number Da |}
atunci
Ia = (cardID(Card A)) si
¸
exist˘ input astfel încât
a
Ka∗ = tempK(Crypt (crdK(Card A)) {| Hash input, Number Da |}
Aceaste teoreme corespund pa¸ilor 4 si 7 din protocol. A doua teorem˘ indic˘ faptul
s ¸ a a
c˘ A recep¸ioneaz˘ un mesaj con¸inând o cheie temporal˘ creat˘ pe baza unui rezumat hash
a t a t a a
dar nu îl informeaz˘ de componentele utilizate pentru creearea rezumatului, de unde rezult˘
a a
înc˘ lcarea principiului 1 din capitolul 2: comunicarea explicit˘ . Acest principiu sugereaz˘
a a a
ca fiecare mesaj s˘ spun˘ exact ceea ce înseamn˘ , iar interpretarea acestuia s˘ depind˘ doar
a a a a a
de con¸inut. Componentele rezumatului hash fac leg˘ tura cu cel cu care se dore¸te stabilirea
t a s
unei leg˘ turi sigure, iar cardul ar putea furniza outputuri într-o ordine gre¸it˘ . Agentul nu
a s a
cunoa¸te cheia cardului pentru a putea inspecta rezumatul hash deci ar putea asocia gre¸it cheia
s s
temporar˘ .a
Pentru a rezolva aceast˘ problem˘ indicat ar fi ca smart cardul s˘ furnizeze agentului pe
a a a
lâng˘ cheia temporar˘ si rezumatul hash cu care a fost creat˘ cheia temporar˘ . Astfel în mo-
a a¸ a a
mentul în care agentul prime¸te outputul, acesta poate recrea rezumatul hash pe baza datelor
s
furnizate ca input si poate asocia cheia temporar˘ cu cel˘ lalt agent.
¸ a a
41

42. Formalizarea pasului 4 al protocolului va deveni astfel K4’.
K4
[| evs4 ∈ klomp; legallyU(Card A); A = Server;
Inputs A (Card A) {| Nonce Na, Nonce Nb,
Number Tk, Agent B |};
Ca = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent B |};
Ka∗ = tempK(Crypt (crdK(CardA)) {| Ca, Number Da |}) |]
=⇒ Outputs (Card A) A {| Agent A, Nonce (cardID(Card A)), Ca,
Key Ka∗, Number Da |} # evs4 ∈ klomp
Conform acestui output trebuie actualizat si K5 astfel încât în ipotez˘ s˘ se reg˘ seasc˘
¸ a a a a
Outputs (Card A) A {| Agent A, Nonce Ia, Hash {| Nonce Na,
Nonce Nb, Number Tk, Agent B |},
Key Ka∗, Number Da |} ∈ set evs5;
ceea ce îi permite agentului s˘ asocieze corect cheia temporar˘ cu datele furnizate de un
a a
anumit server.
Formalizarea pasului 7 a protocolului va deveni K7’.
K7
[| evs7 ∈ klomp; legallyU(Card B); B = Server;
Inputs B (Card B) {| Nonce Na, Nonce Nb,
Number Tk, Agent A |};
Cb = Hash {| Nonce Na, Nonce Nb, Number Tk, Agent A |};
Kb∗ = tempK(Crypt (crdK(CardB)) {| Cb, Number Db |}) |]
=⇒ Outputs (Card B) B {| Agent B, Nonce (cardID(Card B)), Cb,
Key Kb∗, Number Db |} # evs7 ∈ klomp
Serverul va putea asocia corect cheia temporar˘ cu un anumit client prin verificarea outputu-
a
lui care va fi de forma:
Outputs (Card B) B {| Agent B, Nonce Ib, Hash {| Nonce Na,
Nonce Nb, Number Tk, Agent A |},
Key Kb∗, Number Db |} ∈ set evs5;
În mod asem˘ n˘ tor sunt actualizate regulile K4_Fake si K7_Fake.
a a ¸
Teoremele Reli4 si Reli5 vor deveni:
¸
Teorema (Reli4’)
Dac˘ evs con¸ine
a t
42

43. Outputs (Card A) A {| Agent A, Nonce (cardID(Card A)),
Hash input, Key (tempK(Crypt (crdK(Card A))
{| Hash input, Number Da |})), Number Da |}
atunci evs con¸ine si
t ¸
Inputs A (Card A) (input)
Teorema (Reli5’)
Dac˘ evs con¸ine
a t
Outputs (Card A) A {| Agent A, Nonce Ia, Hash input, Key Ka∗, Number Da |}
atunci
Ia = (cardID(Card A)) si
¸
Ka∗ = tempK(Crypt (crdK(Card A)) {| Hash input, Number Da |}
4.2.1.4 Corectitudinea model˘ rii inputurilor agen¸ilor one¸ti
a t s
Teorema demonstreaz˘ c˘ agen¸ii one¸ti î¸i utilizeaz˘ cardurile într-o manier˘ corect˘ , adic˘
a a t s s a a a a
verific˘ faptul c˘ agen¸ii produc inputuri folosind componente ale c˘ ror origine poate fi docu-
a a t a
mentat˘ .
a
Teorema (Reli6)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Inputs A (Card A) {| Nonce Na, Nonce Nb, Number Tk, Agent B |}
atunci exist˘ Sa astfel încât evs con¸ine si
a t ¸
Says A B {| Number Sa, Hash {|Number Sa, Nonce Na|} |} si
¸
Gets A {| Agent B, Nonce Nb, Number Tk |} sau
exist˘ Ia, Da, Pak astfel încât evs con¸ine si
a t ¸
Says A B {| Agent A, Nonce Nb, Number Tk |} si
¸
Gets A {| Agent B, Nonce Na, Nonce Ia, Pak, Agent A, Nonce Nb, Number Tk |}
Dac˘ agen¸ii one¸ti trimit ca input propriilor carduri un rezumat hash con¸inând 2 numere
a t s t
aleatoare, o marc˘ de timp si un nume de agent atunci poate fi demonstrat˘ originea acestor
a ¸ a
date. Dac˘ inputul este corespunz˘ tor mesajului 3 atunci primul num˘ r aleator a fost ales de
a a a
proprietarul cardului iar celelalte date au fost recep¸ionate de pe re¸ea. Dac˘ inputul corespunde
t t a
mesajului 6 atunci primul num˘ r aleator a fost fost recep¸ionat de pe re¸ea iar celelalte date au
a t t
fost generate de proprietarul cardului într-un mesaj anterior.
43

44. Forma inputului unui agent care i¸i utilizeaz˘ propriul card poate fi verificat˘ conform teo-
s a a
remei urm˘ toare:
a
Teorema (Reli7)
Dac˘ evs con¸ine
a t
Inputs A (Card A) (input)
atunci exist˘ Na, Nb, T k, B astfel încât
a
input = {| Nonce Na, Nonce Nb, Number Tk, Agent B |}
Inputul trebuie s˘ fie format din 2 numere aleatoare, un num˘ r care reprezint˘ o marc˘ de
a a a a
timp si numele unui agent.
¸
4.2.2 Regularitate
Lemele de regularitate exprim˘ fapte care pot fi demonstrate pentru mesajele care sunt trans-
a
mise prin re¸ea. Lemele de regularitate pentru chei cuprind acele chei pe care protocolul nu le
t
transmite în traficul de pe re¸ea. De exemplu dac˘ în urma evs a modelului apare una din cheile
t a
secrete ale unui agent atunci acest agent este compromis. Demonstra¸ia implic˘ faptul c˘ ata-
t a a
catorul este cel care a transmis cheia, folosind regula Fake, deoarece cel care de¸ine cheia nu o
t
va transmite niciodat˘ prin re¸ea în cadrul protocolului. Din ipotezele regulii Fake reiese faptul
a t
c˘ atacatorul cunoa¸te cheia doar dac˘ agentul este compromis. Utilizând defini¸iile initState,
a s a t
knows si analz rezult˘ implica¸ia în sens invers.
¸ a t
În protocoalele bazate pe smart carduri, agen¸ii one¸ti nu transmit niciodat˘ cheile secrete
t s a
crdK si shrK stocate pe card prin re¸ea, deci atacatorul ar putea s˘ trimit˘ o astfel de cheie
¸ t a a
în cadrul protocolului doar dac˘ agen¸ii sunt compromi¸i. Cum aceste chei nu sunt transmise
a t s
niciodat˘ prin re¸ea implic˘ faptul c˘ atacatorul le cunoa¸te de la începutul protocolului. Agen¸ii
a t a a s t
s t t t˘
compromi¸i nu au cuno¸tin¸e ini¸iale, în consecin¸a, atacatorul poate înv˘¸a cheile cardurilor sau
s at
cheile secrete ale de¸in˘ torilor de carduri doar prin clonare (din defini¸ia initState).
t a t
Lema (Regu1)
(Key (shrK A) ∈ analz(knows Spy evs)) ⇔ (Card A ∈ cloned)
Lema (Regu2)
(Key (crdK C) ∈ analz(knows Spy evs)) ⇔ (C ∈ cloned)
4.2.3 Unicitate
t a a t˘
Protocoalele de distribu¸ie de chei genereaz˘ o nou˘ cheie de sesiune pentru fiecare instan¸a
a protocolului, ceea ce conduce la ipoteza c˘ o cheie de sesiune nu poate ap˘ rea decât o singur˘
a a a
44

45. dat˘ . În cazul protocolului Klomp fiecare cheie de sesiune este construit˘ pe baza unui nonce si
a a ¸
a unei chei temporare.
Unicitatea cheilor temporare se bazeaz˘ pe noutatea componentelor din care sunt create.
a
Teorema (Unic1)
Dac˘ evs con¸ine
a t
Outputs (Card A) A {| Agent A, Nonce Ia, Ca, Key Ka∗, Number Da |} si
¸
Outputs (Card A ) A {| Agent A , Nonce Ia , Ca , Key Ka∗, Number Da |}
atunci
A=A si
¸ Ia = Ia si
¸ Ca = Ca si
¸ Da = Da
Unicitatea outputurilor poate fi demonstrat˘ si în func¸ie de provocarea creat˘ pe baza inpu-
a¸ t a
tului.
Teorema (Unic2)
Dac˘ evs con¸ine
a t
Outputs (Card A) A {| Agent A, Nonce Ia, Ca, Key Ka∗, Number Da |} si
¸
Outputs (Card A ) A {| Agent A , Nonce Ia , Ca, Key Ka∗ , Number Da |}
atunci
A=A si
¸ Ia = Ia si
¸ Ka∗ = Ka ∗ si
¸ Da = Da
Demonstra¸iile se fac prin induc¸ie si simplificare, dup˘ care se apeleaz˘ la tacticile auto
t t ¸ a a
¸inând cont de forma outputului.
t
Unicitatea cheilor de sesiune reiese din demonstra¸ia teoremei urm˘ toare care se bazeaz˘ pe
t a a
faptul c˘ un agent onest va crea întotdeauna în pasul 5 o nou˘ cheie de sesiune.
a a
Teorema (Unic3)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Says A B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Crypt Kab X, Agent B, Nonce Nb, Number Tk |} si
¸
Says A B {| Agent A , Nonce Na , Nonce Ia , , Number Da ,
Crypt Kab X , Agent B , Nonce Nb , Number Tk |}
atunci
A=A si
¸ Na = Na si
¸ Ia = Ia si
¸ B = B si¸
Nb = Nb si
¸ Tk = Tk si
¸ X =X si
¸ Da = Da
Autoritatea de încredere recreeaz˘ cheia de sesiune pentru server si aceasta este unic˘ dac˘
a ¸ a a
serverul nu este corupt.
Teorema (Unic4)
Dac˘ B = Spy si evs con¸ine
a ¸ t
45

46. Says Server B (Crypt Kb∗ (Key Kab)) si
¸
Says Server B (Crypt Kb∗ (Key Kab))
atunci
B = B si
¸ Kb∗ = Kb ∗
4.2.4 Integritate
Integritatea mesajelor transmise prin re¸ea în cadrul protocolului poate fi demonstrat˘ prin
t a
urm˘ toarele teoreme. În Isabelle demonstrarea lor se face automat în urma aplic˘ rii induc¸iei.
a a t
Integritatea mesajelor transmise între smart carduri si agen¸i reiese din demonstrarea teoremele
¸ t
de corectitudine ale model˘ rii inputurilor si outputurilor. În continuare vor fi prezentate teore-
a ¸
mele care demonstreaz˘ integritatea pentru mesajele transmise prin re¸ea.
a t
Teorema (Int_msg1)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Says A B {| Number Sa, Verifier|}
atunci exist˘ Na astfel încât
a
Veri f ier = Hash {| Number Sa, Nonce Na |}
Teorema (Int_msg5)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Says A B {| Agent A, Nonce Na, Nonce Ia, Number Da, Pak,
Agent B, Nonce Nb, Number Tk |}
atunci
Ia = cardID(Card A) si
¸
Pak = Crypt (sesK(Na, tempK(Crypt (crdK(Card A)) {| Hash {| Nonce Na, Nonce Nb,
Number Tk, Agent B|}, Number Da|}))) {| Nonce Na, Nonce Nb, Agent A|}
Dac˘ clientul nu este atacatorul atunci reiese si faptul c˘ certificatul este criptat cu o cheie
a ¸ a
de sesiune si nu cu o cheie stocata pe card, iar cheia de sesiune este creat˘ pe baza unei chei
¸ a
temporare care de asemenea nu este una din cheile stocate pe card. Demonstra¸ia este prezentat˘
t a
în anex˘ .
a
Teorema (Int_msg8)
Dac˘ B = Spy si evs con¸ine
a ¸ t
Says B Server {| Agent A, Nonce Na, Nonce Ia, Number Da, Pak,Agent B, Nonce Nb,
Nonce Ib, Number Db, Pbk, Number Tk |}
atunci
46

47. Ib = cardID(Card B) si
¸
Pbk = Crypt (tempK(Crypt (crdK(Card B)) {| Hash {| Nonce Na, Nonce Nb,
Number Tk, Agent A |}, Number Db |})) {| Nonce Na, Nonce Nb, Agent B|}
Dac˘ serverul nu este atacatorul atunci se poate demonstra si faptul c˘ certificatul trimis
a ¸ a
autorit˘¸ii de încredere este criptat întradev˘ r cu o cheie temporar˘ si nu cu o cheie stocat˘ pe
at a a¸ a
card. Demonstra¸ia este prezentat˘ în anex˘ .
t a a
Teorema (Int_msg9)
Dac˘ evs con¸ine
a t
Says Server B (Tba)
atunci exist˘ Nb, Cb, Db, Kab astfel încât
a
T ba = Crypt (sesK(Nb, tempK(Crypt (crdK(Card B))
{| Cb, Number Db |}))) (Key Kab)
Autoritatea de încredere va trimite întotdeauna o cheie criptat˘ cu o cheie de sesiune.
a
Teorema (Int_msg10)
Dac˘ B = Spy si B = Server si evs con¸ine Says B A (Pba)
a ¸ ¸ t
astfel încât pentru oricare p ¸ i q, Pba = {| p, q |}
s
atunci exist˘ Na, Nb, Kab astfel încât
a
Pba = Crypt Kab {| Nonce Na, Nonce Nb |}
4.2.5 Autenticitatea
Agen¸ii au nevoie de garan¸ii care s˘ confirme c˘ certificatele sunt autentice bazate pe ipoteze
t t a a
pe care le pot verifica. Cheile temporare din protocolul Klomp sunt de fapt certificate criptate cu
cheia secret˘ a cardurilor care confirm˘ autenticitatea celor care le creeaz˘ . Cheile temporare
a a a
sunt utilizate pentru a cripta certificate cu care agen¸ii si serverele se vor autentifica în fa¸a
t ¸ t
autorit˘¸ii de încredere. Pentru a demonstra c˘ aceste chei sunt create de agen¸i one¸ti în pa¸ii 4
at a t s s
si 7, si nu de c˘ tre intrus care ar putea utiliza cardurile în mod ilegal, vom utiliza teorema:
¸ ¸ a
Teorema (Auth1)
Dac˘ A = Spy,B = Spy si ¬illegallyU(Card A) si în evs
a ¸ ¸
Key (tempK(Crypt (crdK(Card A)){| Hash {|Nonce Na, Nonce Nb, Number Tk,
Agent B |}, Number Da |})) ∈ parts(knows Spy evs)
atunci evs con¸ine
t
Outpts (Card A) A {| Agent A, Nonce (cardID(Card A)), Hash {| Nonce Na, Nonce Nb,
Number Tk, Agent B|}, Key (tempK(Crypt (crdK(Card A))
47

48. {| Hash {| Nonce Na, Nonce Nb, Number Tk, Agent B|},
Number Da |})), Number Da|}
Demonstra¸iile pentru autenticitatea certificatelor Pak si Pbk se bazeaz˘ pe faptul c˘ acestea
t ¸ a a
nu pot fi falsificate de atacator decât dac˘ acesta cunoa¸te cheia. Dac˘ atacatorul nu cunoa¸te
a s a s
cheia de sesiune atunci certificatul Pak a fost creat întradev˘ r de client si a fost transmis în pasul
a ¸
5.
Teorema (Auth2)
Dac˘ A = Spy si în evs
a ¸
Crypt (sesK(Na, K)) {|Nonce Na, Nonce Nb, Agent A|} ∈ parts(knows Spy evs) si
¸
Key sesK(Na, K) ∈ analz(knows Spy evs)
/
atunci evs con¸ine
t
Says A B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Crypt (sesK(Na, K)) {|Nonce Na, Nonce Nb, Agent A|},
Agent B, Nonce Nb, Number Tk |}
Dac˘ atacatorul nu cunoa¸te cheia temporar˘ a serverului atunci certificatul Pbk a fost creat
a s a
de server si a fost transmis în pasul 8.
¸
Teorema (Auth3)
Dac˘ A = Spy si în evs
a ¸
Crypt (tempK(K)) {|Nonce Na, Nonce Nb, Agent B|} ∈ parts(knows Spy evs) si
¸
Key tempK(K) ∈ analz(knows Spy evs)
/
atunci evs con¸ine
t
Says B Server {| Agent A, Nonce Na, Nonce Ia, Number Da Pak, ,
Agent B, Nonce Nb, Nonce Ib, Crypt (tempK(K))
{|Nonce Na, Nonce Nb, Agent B|}, Number Tk |}
Autenticitatea certificatului trimis de autoritatea de încredere în pasul 9 este demontrat˘ prin
a
teorema Auth4.
Teorema (Auth4)
Dac˘ în evs
a
Crypt (sesK(Nb, Kb)) (Key Kab) ∈ parts(knows Spy evs) si
¸
Kb = tempK(Crypt (crdK(Card B)) {| Cb, Number Db |}) si ¸
Key sesK(Nb, Kb) ∈ analz(knows Spy evs)
/
atunci evs con¸ine
t
Says Server B (Crypt (sesK(Nb, Kb)) (Key Kab))
48

49. În general autenticitatea cheii de sesiune poate fi demonstrat˘
a
Teorema (Auth5)
Dac˘ A = Spy si ¬illegallyU(Card A) si în evs
a ¸ ¸
Key Kab ∈ analz(knows Spy evs) si
¸
Kab = sesK(Na, tempK(Crypt (crdK(Card A)) {| Ca, Number Da |}))
atunci evs con¸ine
t
Notes Spy (Key Kab)
4.2.6 Confiden¸ialitate
t
Dac˘ cheia de sesiune nu a fost pierdut˘ accidental (Oops) atunci este confiden¸ial˘ . Forma
a a t a
cheii temporare pe baza c˘ reia a fost creat˘ cheia de sesiune nu poate fi verificat˘ de nici un
a a a
agent, deoarece ace¸tia nu cunosc cheile stocate pe carduri. În concluzie, aceast˘ garan¸ie ob¸i-
s a t t
nut˘ din demonstrarea teoremei urm˘ toare este util˘ doar autorit˘¸ii de încredere.
a a a at
Teorema (Conf)
Dac˘ A = Spy si ¬illegallyU(Card A) si evs nu con¸ine
a ¸ ¸ t
Notes Spy (Key Kab) si
¸
Kab = sesK(Na, tempK(Crypt (crdK(Card A)) {| Ca, Number Da |}))
atunci în evs
Key Kab ∈ analz(knows Spy evs)
/
Dac˘ se dore¸te specificarea confiden¸ialit˘¸ii din punctul de vedere al agentului A atunci
a s t at
urm˘ toarea teorem˘ ar fi util˘ .
a a a
Teorema (ConfA)
Dac˘ A = Spy si evs con¸ine
a ¸ t
Says A B {| Agent A, Nonce Na, Nonce Ia, Number Da,
Crypt (sesK(Na, Ka∗)) {|Nonce Na, Nonce Nb, Agent A|},
Agent B, Nonce Nb, Number Tk |}
si nu con¸ine
¸ t
Notes Spy (Key sesK(Na, Ka∗)
atunci în evs
Key Kab ∈ analz(knows Spy evs)
/
În mod asem˘ n˘ tor ar putea fi specificat˘ confiden¸ialitatea si din punctul de vedere al auto-
a a a t ¸
rit˘¸ii de încredere în urma recep¸iei mesajului din pasul 9 al protocolului.
at t
49

50. 4.2.7 Distribu¸ia cheilor
t
Teorema (KeyD_A)
Dac˘ A rece¸ioneaz˘ în urma pasului 10 un certificat pe care îl poate inspecta deoarece
a t a
cunoa¸te cheia cu care a fost criptat, atunci A poate trage concluzia c˘ cel care l-a trimis cunoa¸te
s a s
cheia de sesiune.
Dac˘ evs con¸ine
a t
Gets A (Crypt Kab {| Nonce Na, Nonce Nb|}) si
¸
Kab = sesK(Na, tempK(Crypt (crdK(Card A)) {| Ca, Number Da |}))
atunci în evs
Key Kab ∈ analz(knows B evs)
Dac˘ B recep¸ioneaz˘ o cheie criptat˘ cu o cheie pe care o cunoa¸te, atunci acesta poate
a t a a s
trage concluzia c˘ agentul A cunoa¸te cheia de sesiune.
a s
Teorema (KeyD_B)
Dac˘ B = Spy sievs con¸ine
a ¸ t
Gets B (Crypt sesK(Nb, Kb∗) (Key Kab)) si
¸
Kb = tempK(Crypt (crdK(Card B)) {| Hash {| Nonce Na,
Nonce Nb , Number Tk, Agent A |}, Number Db |})
atunci în evs
Key Kab ∈ analz(knows A evs)
50

51. Concluzii
Analiza protocoalelor de securitate este fundamental˘ înainte ca acestea s˘ fie utilizate în
a a
practic˘ . În aceast˘ lucrare am ar˘ tat c˘ Metoda Inductiv˘ poate fi utilizat˘ cu succes pen-
a a a a a a
tru demonstrarea formal˘ a corectitudinii protocoalelor de securitate. Aceast˘ metod˘ permite
a a a
s t˘
extinderea cu u¸urin¸a prin ad˘ ugarea de elemente noi necesare model˘ rii diferitelor sisteme
a a
din lumea real˘ . Verificarea sistemelor în urma identific˘ rii unor noi vulnerabilit˘¸i nu nece-
a a at
sit˘ decât formalizarea acestora ca si reguli inductive adi¸ionale si redemonstrarea propriet˘¸ilor
a ¸ t ¸ at
protocolului.
Smart cardurile au ap˘ rut ca o solu¸ie pentru protejarea datelor transmise în cadrul sesiu-
a t
nilor de comunicare oferind un mod sigur de a stoca informa¸ii secrete pe termen lung. Uti-
t
lizând Metoda Inductiv˘ si demonstratorul de teoreme Isabelle am modelat si verificat formal
a¸ ¸
propriet˘¸ile protocolulului Klomp, protocol de autentificare si distribu¸ie de chei bazat pe smart
at ¸ t
carduri, propus de Bella în [8]. Protocolul a fost creat pentru a asigura tranzac¸iile comer¸ului
t t
electronic si a fost testat pe dou˘ tipuri de carduri Dutch Chipper si ChipKnip.
¸ a ¸
În urma analizei am descoperit c˘ protocolul încalc˘ unul din principiile fundamentale ale
a a
construc¸iei protocoalelor de securitate si anume: comunicarea explicit˘ . Aceast˘ vulnerabili-
t ¸ a a
tate ar putea conduce la erori de asociere a cheilor dac˘ smart cardurile nu ar func¸iona corect,
a t
ca de exemplu în cazul în care apar defecte ale magistralelor de date sau eventual coruperi ale
acestora în faza de fabricare a cardului.
În aceast˘ lucrare sunt prezentate elementele fundamentale ale model˘ rii si verific˘ rii smart
a a ¸ a
cardurilor. O analiza complet˘ a unui protocol de securitate este dificil de realizat si necesit˘
a ¸ a
considerarea unui num˘ r foarte mare de factori. În analiza protocolului Klomp am conside-
a
rat aspectele esen¸iale care contribuie la asigurarea securit˘¸ii oferite de protocol, precum cele
t at
legate de mediul de execu¸ie dar si cele referitoare la intrus. Analiza a presupus verificarea
t ¸
51

52. propriet˘¸ilor de corectitudine ale modelului, verificarea propriet˘¸ilor de confiden¸ialitate, in-
at at t
tegritate si autenticitate a mesajelor, dar si cele de distribu¸ie a cheilor de sesiune. O parte din
¸ ¸ t
aceste propriet˘¸i au fost demonstrate ¸inând cont de principiul de analiz˘ a protocoalelor de
at t a
securitate propus de Bella: utilitatea scopului. Consider c˘ analiza protocolului Klomp ar putea
a
fi rafinat˘ si optimizat˘ în viitor conform acestui principiu si cred c˘ , m˘ car ca si studiu de caz,
a¸ a ¸ a a ¸
noile protocoale de securitate pentru e-commerce precum 3D-Secure sau Secure Code ar trebui
verificate cu Metoda Inductiv˘ .a
52

53. Bibliografie
[1] M. Abadi, M. Burrows, C. Kaufman, and B. Lampson. Authentication and
Delegation with Smart-cards. Research Report 125, Digital - Systems Research
Center, 1994.
[2] G. Bella. Inductive Verification of Smart Card Protocols. Journal of Computer
Security, 11(1):87-123,2003.
[3] L. C. Paulson. The Inductive Approach to Verifying Cryptographic Protocols.
Journal of Computer Security, 6:85-128, 1998.
[4] M. Abadi, R. M. Needham. Prudent engineering practice for cryptographic
protocols. IEEE Transactions on Software Engineering, 22(2):6-15, 1996.
[5] G. Bella. Formal Correctness of Security Protocols, Springer, 2007.
[6] M. Bellare and P. Rogaway. Provably Secure Session Key Distribution - the Three
Party Case. Proc. Of 27th ACM SIGACT Symposium on Theory of Computing,
57-66, ACM Press and Addison Wesley, 1995.
[7] V. Shoup and A. Rubin. Session Key Distribution using Smart Cards, In U.
Maurer, editor. Advanced in Cryptology - EuroCrypt’96, LNCS 1070, 321-331,
Springer-Verlag, 1996.
[8] B. Bakker. Mutual Authentication with Smart Cards. Proceedings of the USENIX
Workshop on Smartcard Technology on USENIX Workshop on Smartcard
Technology, Berkeley: USENIX Association, 1999.
53

54. Anexe
54