MODELAREA SI VERIFICAREA PROTOCOALELOR DE SECURITATE BAZATE PE SMART CARDURI

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