Your SlideShare is downloading. ×
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Disertatie
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Disertatie

339

Published on

MODELAREA SI VERIFICAREA PROTOCOALELOR DE SECURITATE BAZATE PE SMART CARDURI

MODELAREA SI VERIFICAREA PROTOCOALELOR DE SECURITATE BAZATE PE SMART CARDURI

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
339
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CuprinsIntroducere 3Motiva¸ie t 4Contribu¸ii t 6Structura lucr˘ rii a 7Principii de construc¸ie si analiz˘ a protocoalelor de securitate t ¸ a 8Metoda Inductiv˘ a 112.1 Isabelle 122.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 . . . . . 27Protocolul KLOMP 28Analiza 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 . . . . . . . . . . . . 50Concluzii 51Bibliografie 53Anexe 54 2
  • 3. Introducere t˘ Un protocol de securitate este un algoritm distribuit specificat printr-o secven¸a de pa¸i scare descrie ac¸iunile, a dou˘ sau mai multe entit˘¸i, ce trebuie realizate pentru atingerea unui t a atanumit obiectiv de securitate. Obiectivele de securitate reprezint˘ o mul¸ime de propriet˘¸i a t atprin care se poate specifica gradul de securitate al comunica¸iilor dintre agen¸ii unei re¸ele. t t tPropriet˘¸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- ¸ tsibile a devenit o problem˘ la nivel mondial. Smart cardurile au ap˘ rut ca o solu¸ie la acest˘ a a t aproblem˘ oferind securitate prin stocarea într-un mod sigur, pe termen lung, a datelor cu carac- ater personal si a secretelor utilizate de c˘ tre primitivele criptografice. Datorit˘ cipului incorporat ¸ a acardul este capabil s˘ proceseze aceste date si s˘ ofere acces la ele doar în momentul în care a ¸ aanumite cerin¸e de securitate sunt îndeplinite. t Analiza protocoalelor de securitate este fundamental˘ înainte ca acestea s˘ fie utilizate în a apractic˘ , impunându-se considerarea mediului de execu¸ie si a intrusului. Datorit˘ num˘ rului a t ¸ a amare de atacuri, singura metod˘ de a asigura c˘ un astfel de protocol este corect este demon- a astra¸ia matematic˘ . O demonstra¸ie nu este altceva decât dovada c˘ fiecare pas din protocol t a t ap˘ streaz˘ o anumit˘ proprietate. a a a Ra¸ionamentul informal nu detecteaz˘ întotdeauna punctele slabe ale protocoalelor de secu- t aritate de aceea de-a lungul timpului s-au dezvoltat metode formale. Cu ajutorul acestora putemdemonstra c˘ la nivel abstract protocoale sunt corecte într-un anumit model sau dac˘ au im- a aperfec¸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 anum˘ r limitat. Metoda Inductiv˘ este o tehnic˘ important˘ folosit˘ în demonstrarea formal˘ a a a a a aa corectitudinii protocoalelor de securitate, ce poate fi utilizat˘ în cadrul demonstratorului de ateoreme Isabelle. Bazele acestei metode au fost puse Paulson în [3] iar Bella în [2] propune oextensie 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 asi 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 tmen lung, de aceea nu ar trebui s˘ par˘ surprinz˘ tor faptul c˘ sistemele tradi¸ionale bazate pe a a a a tparole sunt înlocuite tot mai des cu cele bazate pe smart carduri. Noile protocoale de securitateimplementate pe baza acestor sisteme tind s˘ ating˘ propriet˘¸i mai tari dar acest lucru trebuie a a atdemonstrat. Protocoale de securitate bazate pe smart carduri au nevoie de analiz˘ formal˘ care a ase 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 ametodelor 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 aproiectate. Induc¸ia matematic˘ este considerat˘ suficient˘ pentru a modela si a crea ra¸ionamente refer- t a a a ¸ titoare la obiectivele protocoalelor de securitate. În Metoda Inductiv˘ se folose¸te conceptul de a surm˘ , 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 aprotocolul. Aceasta poate fi v˘ zut˘ ca o istorie a evenimentelor re¸elei care au loc în momen- a a ttul execu¸iei protocolului si se define¸te inductiv. Mul¸imea tuturor urmelor posibile reprezint˘ t ¸ s t amodelul formal al protocolului. Propriet˘¸ile care pot fi demonstrate cu ajutorul Metodei In- atductive 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 estecel de punct de vedere care stabile¸te care din aceste teoremele sunt utile unui anumit agent, sadic˘ 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- atinderea Metodei Inductive, introducând elemente noi pentru modelarea cardurilor ¸inând conttde riscurile clon˘ rii si de modul de interac¸iune a acestora cu agen¸ii. Pentru a stabili propri- a ¸ t tet˘¸ile unui protocol de securitate bazat pe smart carduri este foarte important s˘ stabilim în at aprimul 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 asunt stocate pe card, dar si mediul de execu¸ie, dac˘ atacatorul poate interveni sau nu în trans- ¸ t amiterea informa¸iilor. t t˘ ¸ Pe parcursul lucr˘ rii vor fi scoase în eviden¸a si principiile generale care stau la baza pro- atocoalelor corecte. Aceste principii contribuie la garan¸iile de securitate dar nu sunt suficiente. tUnul din principiile fundamentale în proiectarea protocoalelor de securitate conform [4] esteclaritatea care sugereaz˘ c˘ fiecare mesaj ar trebui s˘ spun˘ exact ce înseamn˘ far˘ a crea ambi- a a a a a aguitate, 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 acipiul utilit˘ ¸ii scopului care este respectat atunci când exist˘ garan¸ii c˘ din punctul de vedere at a t aal agentului obiectivul protocolului este atins. Aceste garan¸ii trebuie s˘ se bazeze pe ipoteze pe t acare agentul le poate verifica în practic˘ .aAbord˘ ri cunoscute a Pentru analiza formal˘ a protocoalele de securitate de-a lungul timpului au fost propuse anumeroase abord˘ ri, iar odat˘ cu dezvoltarea sistemelor IT, calculatorul a început sa-¸i arate a a sutilitatea în automatizarea acestor analize. Metoda Inductiv˘ pare s˘ fie una din cele mai bune a aabord˘ ri având în vedere c˘ poate demonstra o gam˘ larg˘ de propriet˘¸i si este suportat˘ de a a a a at ¸ ademonstratorul de teoreme Isabelle. Protocoalele pentru smart carduri tind s˘ aibe obiective mai tari decât cele tradi¸ionale dar a tacest lucru trebuie demonstrat formal. Pentru a analiza astfel de protocale trebuie dezvoltate noimetode sau trebuie extise cele existente. Abadi în [1] propune o extensie pentru logica BAN care permite modelarea protocoalelor desecuritate bazate pe smart carduri si prin care se poate demonstra autentificarea mutual˘ dintre ¸ aagen¸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 tpas 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 ¸ tcare reies din fiecare pas al protocolului se ajunge la scopul protocolului. Din p˘ cate logica BAN anu ofer˘ o semantic˘ satisf˘ c˘ toare si este limitat˘ , ra¸ionamentul privind confiden¸ialitatea fiind a a a a ¸ a t tdoar informal, intrusul nefiind modelat. Securitatea demonstrabil˘ [10] este un studiu al teoriei complexit˘¸ii bazat pe probabilit˘¸i a at atdespre 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 ta cheii si confiden¸ialitatea cheii care reiese din probabilitatea mic˘ a adversarului de a g˘ si ¸ t a acheia. 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 tsesiune într-un sistem cu trei agen¸i, fiecare de¸inând un card ideal ale c˘ rui func¸ii de criptare t t a tsunt pseudo-aleatoare. Autorii demonstreaz˘ c˘ agen¸ii partajeaz˘ o cheie la sfâr¸itul sesiunii a a t a sprotocolului 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 aobservarea unor evenimente ale re¸elei. Singura strategie folosit˘ în demonstra¸ii este induc¸ia. t a t tAceast˘ 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 tpropus de Shoup si Rubin în [7] care presupune c˘ mijloacele de comunicare dintre posesorul ¸ acardului si card sunt sigure si se iau în considerare carduri f˘ r˘ PIN. Studiul efectuat este realizat ¸ ¸ aaasupra propriet˘¸ilor de autenticitate, unicitate, autentificare si distribu¸ia cheii si descoper˘ c˘ at ¸ t ¸ a aeste necesar˘ o clarificare în plus pentru dou˘ dintre mesajele protocolului. a aContribu¸ii t Scopul acestei lucr˘ ri este de a prezenta o metod˘ de analiz˘ a protocoalelor de securitate a a abazate 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 aPaulson în [3] si a metodei propus˘ de Bella în [2] pentru modelarea protocoalelor de securitate ¸ abazate 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 aautentificare si distribu¸ie a cheilor de sesiune în cadrul tranzac¸iilor electronice. Pentru veri- ¸ t tficarea propriet˘¸ilor de securitate am utilizat demonstratorul de teoreme Isabelle care este un atinstrument complex dar util în demonstra¸ii semi-automate. Fiecare proprietate este formalizat˘ t aprintr-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 aile fundamentale în construc¸ia protocoalelor de securitate si anume: comunicarea explicit˘ . t ¸ aBakker propune ca în urma interog˘ rii smart cardurilor agen¸ii s˘ primeasc˘ o cheie temporar˘ a t a a acreat˘ prin criptarea unor date furnizate de ace¸tia. Folosind aceste chei agen¸ii vor crea o cheie a s tde sesiune si certificate de autenticitate. Una din vulnerabilit˘¸ile posibile care trebuie consid- ¸ aterate atunci când se face analiza protocoalelor bazate pe smart carduri este faptul c˘ acestea ar aputea s˘ nu func¸ioneze corect cum ar fi în cazul în care un atacator le-ar corupe magistralele a tde 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 acare dore¸te s˘ stabileasc˘ un canal de comunicare sigur. Solu¸ia propus˘ se bazeaz˘ pe ideea s a a t a ac˘ agentul trebuie s˘ poat˘ verifica componentele din care este creat˘ cheia temporar˘ dar f˘ r˘ a a a a a aaa cunoa¸te cheia cardului. Prin urmare mesajul returnat de smart card agentului va con¸ine atât s tcheia 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 aStructura lucr˘ rii a Lucrarea este structurat˘ pe 6 capitole, primul având un caracter introductiv, identificând adirec¸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 ¸ asunt 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 ade baz˘ enun¸ate de Abadi si Needham în [4], si anume comunicarea explicit˘ . Tot aici va fi a t ¸ ¸ adescris si principiul de analiz˘ propus de Bella în [5] care sugereaz˘ ca obiectivele de securitate ¸ a as˘ fie tratate din punctul de vedere al fiec˘ rui agent. a a Capitolul 2, intitulat “Metoda Inductiv˘ ", cuprinde o scurt˘ prezentare a demonstratorului a ade teoreme Isabelle si a elementelor acestei tehnici de modelare si verificare: tipurile agen¸ilor, ¸ ¸ tmodelul intrusului, chei criptografice, mesaje, evenimente, operatori. Metoda este prezentat˘ aa¸a cum a fost propus˘ de Paulson în [3] pentru verificarea formal˘ a corectitudinii protocoalelor s a ade securitate clasice. Pentru a analiza cât mai realist protocoalele de securitate bazate pe smartcarduri, metoda trebuie adaptat˘ . Astfel partea a doua a acestui capitol va cuprinde descrierea aelementelor necesare extinderii Metodei Inductive. În Capitolul 3, intitulat “Protocolul Klomp", este realizat˘ o scurt˘ descriere a protocolului a apropus de Bakker în [8]. Acesta este un protocol de autentificare si distribu¸ie de chei care ¸ tutilizeaz˘ smart carduri, creat pentru a securiza tranzac¸iile comer¸ului electronic. De¸i Bakker a t t sa propus un prototip pentru implementarea protocolului care a fost testat pentru dou˘ tipuri de acarduri aflate în uz, pentru Metoda Inductiv˘ este necesar˘ doar descrierea la nivel opera¸ional. a a tProtocolul 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 ¸ atanterior. 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 ademonstrat˘ 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 taduse 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 scapitolul 4 si care poate fi testat cu ajutorul demonstratorului de teoreme Isabelle. ¸ 7
  • 8. Capitolul 1Principii de construc¸ie si analiz˘ a t ¸ aprotocoalelor de securitate Literatura de specialitate prezint˘ foarte multe exemple de protocoale de securitate care acon¸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˘ asuficient 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 ade propriul con¸inut, astfel încât cel care îl recep¸ioneaz˘ s˘ -l în¸eleag˘ . Acest principiu spune t t a a t ac˘ într-o comunicare nu trebuie s˘ se presupun˘ c˘ anumite informa¸ii sunt deduse din context, a a a a taltul 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 ttrebuie clar stabilite cu privire la ac¸iunile pe care agen¸ii le pot realiza. Pentru a ac¸iona asupra t t tunui mesaj nu este suficient numai s˘ fie în¸eles, sunt necesare si alte condi¸ii precum cele legate a t ¸ tde î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 aDac˘ identitatea agen¸ilor este esen¸ial˘ în semnifica¸ia mesajului, atunci identit˘¸ile trebuie a t t a t atmen¸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 tse utilizeaz˘ necorespunz˘ tor. De obicei criptarea se folose¸te pentru asigurarea confiden¸ia- a a s tlit˘¸ii, garantarea autenticit˘¸ii, combinarea unor componente (în acest caz este suficient˘ doar at at asemnarea), 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 asemneaz˘ un mesaj deja criptat atunci nu ar trebui dedus c˘ agentul cunoa¸te con¸inutul mesa- a a s tjului. Se poate deduce c˘ agentul cunoa¸te con¸inutul mesajului doar dac˘ mai intâi semneaz˘ a s t a asi 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 tnoutatea 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 atun schimb întrebare-r˘ spuns, îns˘ acest˘ cantitate trebuie protejat˘ astfel încât un atacator s˘ nu a a a a apoat˘ 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 timpulabsolut 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 sface 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 asajul 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 tdere de care depinde protocolul. Motivul pentru care o rela¸ie de încredere este acceptat˘ trebuie t aspecificat˘ 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 atprotocoalelor s˘ fie bazate pe ipoteze pe care participan¸ii le pot verifica. Acest principiu se a tnume¸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 tverificate, altfel concluziile nu vor fi utile în lumea real˘ , pentru c˘ nu prezint˘ interes pentru a a arespectivii 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 ament dat în execu¸ia protocolului acesta poate beneficia de el. În modelul formal al protocolului, ttrebuie s˘ existe o garan¸ie formal˘ care specific˘ faptul c˘ participantul ob¸ine o proprietate de a t a a a tsecuritate la un moment dat si care porne¸te de la presupuneri care pot fi verificate de c˘ tre res- ¸ s apectivul participant. Dac˘ nu exist˘ o astfel de garan¸ie atunci spunem c˘ protocol nu reu¸e¸te a a t a s ss˘ fac˘ util respectivul scop pentru participant. Este important ca aceste garan¸ii formale s˘ fie a a t aob¸inute într-un model al intrusului realist. În continuare vor fi prezentate conceptele esen¸iale t tcare 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 tformal˘ î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 ¸ agaran¸ie formal˘ în P este aplicabil˘ de A în P dac˘ este stabilit˘ pe baza unor ipoteze pe care A t a a a ale 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 atrebuie s˘ fie cunoscut˘ de A dar care nu poate fi verificat˘ în practic˘ . a a a a 10
  • 11. Capitolul 2Metoda Inductiv˘ a Metoda Inductiv˘ poate fi folosit˘ pentru demonstrarea formal˘ a corectitudinii protocoalelor a a ade securitate. Aceast˘ metod˘ se afl˘ în clasa metodelor de demonstrare de teoreme si ofer˘ a a a ¸ arezultate valabile pentru toate comport˘ rile posibile ale protocolului de securitate studiat. Demon- astratorul de teoreme Isabelle ofer˘ un foarte bun suport mecanic pentru aceast˘ metod˘ , fiind un a a ainstrument semi-automat în care este necesar˘ ghidarea din partea celui care face demonstra¸ia a tpentru a ajunge la obiectivul protocolului. Un protocol de securitate este un program concurent care este executat de un num˘ r in- adefinit de agen¸i si procesul tinde s˘ ating˘ dimensiuni foarte mari. Studierea unei propriet˘¸i a t ¸ a a atprotocolului înseamn˘ derivarea unui ra¸ionament prin care s˘ se poat˘ demonstra c˘ to¸i pa¸ii a t a a a t sprotocolului 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 avor fi modelate ca o mul¸ime definit˘ inductiv iar obiectivele protocolului vor fi demonstrate prin t ainduc¸ie asupra întregului model. Modelul intrusului este Dolev-Yao si nu se impun restric¸ii t ¸ tasupra 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 tse dezvol˘ în func¸ie de ac¸iunile (evenimente de comunicare) pe care le efectueaz˘ agen¸ii a t t a tatunci când execut˘ diferite sesiuni ale protocolului P. Protocolul P este modelat ca un sistem atranzi¸ional în care se surprinde evolu¸ia sistemului ar˘ tând cum se realizeaz˘ trecerea dintr-o t t a astare în alta. O istorie a traficului re¸elei poate fi reprezentat˘ ca o list˘ de evenimente care au t a aloc î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 tunde P este executat si este definit˘ inductiv prin reguli specificate de P. Evenimentele au loc ¸ aprin declan¸area acestor reguli. Din moment ce nici o regul˘ nu este for¸at˘ s˘ se declan¸eze, s a t a a snici 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 atde 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 tca urmare a recep¸iei mesajelor, dar propriet˘¸ile de securitate nu se mai refer˘ exclusiv la t at aautentificare. Semantica opera¸ional˘ este asem˘ n˘ toare cu cea a formaliz˘ rii CSP, cu excep¸ia t a a a a tfaptului c˘ modelele sunt nem˘ rginite. Tot în stil CSP este considerat˘ si no¸iunea de eveniment a a a¸ tdar si faptul c˘ propriet˘¸ile de securitate sunt exprimate ca predicate pe mul¸imea urmelor ¸ a at tprotocolului. Metoda Inductiv˘ poate fi folosit˘ în cadrul demonstratorului de teoreme Isabelle deoarece a aacesta ofer˘ un foarte bun suport pentru mul¸imile definite inductiv, simplific˘ ri eficiente prin a t areguli de rescriere condi¸ionale si împ˘ r¸iri automate pe cazuri pentru expresiile if-the-else. t ¸ at Figura 1: Metoda inductiv˘ a2.1 Isabelle Isabelle este un demonstrator de teoreme generic interactiv. Cea mai popular˘ versiune este aIsabelle/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 aa conduce demonstra¸iile. Acest instrument ofer˘ un simplificator puternic care este util în sim- t aplic˘ 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 tpropriet˘¸ile fiind demonstrate pentru toate urmele protocoalelor. at a ¸ a a t˘ Demonstrarea teoremelor este dificil˘ si necesit˘ mult˘ experien¸a din partea celui caredore¸te s˘ realizeze demonstra¸ia. Pentru a realiza o demonstra¸ie, utilizatorul trebuie s˘ apeleze s a t t ala anumite metode de induc¸ie si simplificare pentru subscopurile ob¸inute pentru a îndruma in- t ¸ tstrumentul cum s˘ procedeze pentru a ajunge la obiectivul final. Dac˘ au r˘ mas subscopuri a a anerezolvate atunci se poate apela la demonstratorul automat sau se pot reduce prin utilizareaunor leme. Dac˘ demonstra¸ia nu se poate realiza atunci înseamn˘ c˘ utilizatorul nu este destul a t a ade 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 tteorii 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 apentru analiza protocolului creat de Shoup si Rubin se g˘ sesc în ultima versiune în directorul ¸ aIsabelle2011/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 ¸ tcard.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 securitate2.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 tprotocol. Agen¸ii pot fi umani, ma¸ini sau procese. În modelarea formal˘ a protocoalelor vom t s autiliza 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 ava 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 scare î¸i dezv˘ luie secretele atacatorului chiar de la începutul protocolului, dar si ceea ce observ˘ s a ¸ ape parcursul protocolului. Aceast˘ mul¸ime va fi notat˘ cu bad si se consider˘ c˘ atacatorul face a t a ¸ a aparte 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 cheisimetrice, specificarea faptului c˘ fiecare agent are o cheie partajat˘ cu serverul se face printr-o a afunc¸ie: t shrK : agent → key În cazul sistemele cu chei asimetrice func¸ia se aplicat˘ pentru perechea de chei de criptare t apriEK 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 ¸ apentru 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 asunt simetrice, iar dac˘ sunt asimetrice va oferi cheia complementar˘ (priSK A = invKey(pubSK A)). a a2.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 constructoruluitCrypt folosind o cheie de criptare simetric˘ sau asimetric˘ . Criptarea se presupune a fi perfect˘ a a adeci 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 asitua¸ia când un agent memoreaz˘ por¸iuni dintr-un mesaj care vor putea fi utilizate ulterior. t a tAcesta ar putea înlocui evenimentul Gets deoarece un agent poate memora un mesaj doar dup˘ ace acesta a fost recep¸ionat, dar cele 2 evenimente sunt specificate separat pentru a modela mai tbine realitatea.2.2.5 Urme Urmele protocolului sunt liste de evenimente de lungime variabil˘ pe baza c˘ rora se va a aconstrui modelul protocolului si care vor fi utilizate în verifiarea propriet˘¸ilor. O urm˘ poate ¸ at afi utilizat˘ pentru a înregistra toate evenimentele care au loc de-a lungul unei istorii a re¸elei în a tcare se execut˘ protocolul. Urmele sunt create în ordine invers cronologic˘ , ultimul eveniment a afiind în capul listei. Un eveniment poate fi declan¸at de un num˘ r indefinit de ori într-o urm˘ . s a aExemplu 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 amodel realist pentru vulnerabilit˘¸i. În cazul Metodei Inductive se consider˘ modelul Dolev- at aYao, î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 sdecriptare. Atacatorul poate doar s˘ ob¸in˘ informa¸ii din mesajele criptate cu chei pe care le a t a tcunoa¸te, le poate descompune si poate crea alte mesaje din componentele ob¸inute. Un mesaj s ¸ tcare este transmis nu este în mod necesar recep¸ionat, iar cel care îl recep¸ioneaz˘ nu este în t t amod necesar cel c˘ ruia îi este destinat. De asemenea acest model presupune utilizarea de chei aperfecte care nu pot fi ghicite sau extrase din mesajele criptate si se consider˘ mecanisme de ¸ agenerare 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 tprotocol 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 ta 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 acheile 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 asale 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 turmelor protocolului func¸ia spies. Aceste cuno¸tin¸e sunt formate din starea sa ini¸ial˘ , toate t s t t amesajele 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 aDe exemplu Says A B X # evs simbolizeaz˘ urma a c˘ rui prim eveniment este transmiterea de la a aA 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 aurm˘ . a  {X} ∪ spies evs dac˘ A ∈ bad a spies ((Notes A X) # evs) spies evs altfel2.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 tde 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 tintrusul le poate deriva din observarea traficului din urma evs. Aceste componente se ob-¸in din descompunerea mesajelor concatenate si decriptarea celor criptate folosind chei caret ¸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. sDat˘ 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 tpoate 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 tsaje prin proiec¸ie si decriptare. Dat˘ H o mul¸ime de mesaje, atunci parts H se poate defini t ¸ a tinductiv 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 smesaj 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 aformalizarea acestui concept Metoda Inductiv˘ introduce func¸ia used care reprezint˘ mul¸imea a t a ttuturor componentelor care fac parte din cuno¸tin¸ele ini¸iale ale agen¸ilor împreun˘ cu toate s t t t acomponentele 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 aevenimente (urme ale protocolului), fiecare decriind o posibil˘ istorie a re¸elei în care protocolul a teste rulat. Pentru a modela formal un protocol trebuie s˘ specific˘ m regulile de construc¸ie a a a tacestei mul¸imi. Regula Nil define¸te cazul de baz˘ specificând faptul c˘ urma vid˘ apar¸ine t s a a a tmodelului. Fiecare pas din protocol este formalizat printr-o regul˘ inductiv˘ care specific˘ cum a a ase extinde o anumit˘ urm˘ prin evenimentul de tip Says care descrie acel pas din protocol. a aComportamentul unui posibil atacator este modelat printr-o alt˘ regul˘ numit˘ Fake, care for- a a amalizeaz˘ faptul c˘ acesta poate trimite orice mesaj pe care îl poate crea din componentele pe a acare le cunoa¸te. s2.2.9 Modelarea m˘ rcilor de timp a Bella în [5] propune o extensie a Metodei Inductive care permite modelarea m˘ rcilor de atimp (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, ¸ am˘ 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 tcu un nou constructor Number care are ca parametru un num˘ r natural, iar m˘ rcile de timp T vor a afi reprezentate într-un mesaj prin componenta Number T. Atacatorul poate ghici aceste numeresi 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 adintr-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 aevenimente au avut loc, ceea ce înseamn˘ c˘ timpul curent al urmei respective este exact n. a aAcest˘ formalizare ascunde problema sincroniz˘ rii ceasurilor care va face parte din încrederile a aminimale ale fiec˘ rui agent. a2.3 Modelarea protocoalelor bazate pe smart carduri Smart cardurile înt˘ resc obiectivele protocoalelor care le utilizeaz˘ , dar acest lucru trebuie a ademonstrat formal. Metoda Inductiv˘ propus˘ de Paulson în [3] poate fi adaptat˘ conform [2] a a apentru a verifica corectitudinea protocoalelor bazate pe smart carduri. Cardul va fi modelatprintr-un nou tip si poate interac¸iona cu cel care îl de¸ine prin mesaje. Fiecare card stocheaz˘ ¸ t t ao 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 det a t ¸calcul. În analiza acestor protocoale de securitate bazate pe smart carduri, diver¸i factori pot influ- sen¸a evolu¸ia protocolului, de aceea este important ca atunci când model˘ m s˘ lu˘ m în calcul t t a a atipul cardului, dac˘ este cu PIN sau far˘ , si mediul de execu¸ie adic˘ dac˘ intrusul poate inter- a a ¸ t a acepta 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 pentrua 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 ¸ toutputuri de la acestea. Outputurile vor fi considerate corecte deoarece modelul presupune c˘ asmart cardurile construiasc outputuri doar în cazul în care inputurile oferite sunt corecte, la felca în lumea real˘ . a2.3.1.1 Vulnerabilit˘ ¸i at Furtul. Cardurile care ajung pe mâna unor persoane r˘ uvoitoare, în urma pierderii sau aa furtului, si nu mai pot fi folosite de posesorii propriu-zi¸i vor fi modelate printr-o mul¸ime ¸ s tstolen ⊆ card. Clonarea. Intrusul nu poate utiliza cardurile furate dac˘ nu cunoa¸te PIN-ul, dar se poate a sfolosi de tehnicile moderne pentru a realiza atacuri fizice prin care s˘ ob¸in˘ informa¸ii din a t a tmemoria EEPROM unde sunt stocate secretele. Având aceste date, acesta poate crea o clon˘ a acardului 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 apoate fi folosit dup˘ aceea. Dar dac˘ atacatorul dup˘ ce descoper˘ secretele creeaz˘ 2 clone ale a a a a acardului, din care una o înapoiaz˘ posesorlui propriu-zis f˘ r˘ ca acesta s˘ -¸i dea seama atunci a aa ascardul 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 amodelat deoarece este în contradic¸ie cu presupunerea c˘ smart cardurile ofer˘ outputuri corecte t a asi 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 apersonalizate. 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 aprecondi¸iile sunt îndeplinite. Deasemenea regulile pot s˘ se declan¸eze în orice ordine, sau de t a smai 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 tastfel inactive temporal sau pot s˘ nu mai func¸ioneze deloc. Modelul formal va lua în calcul a taceste situa¸ii incluzând urme care dup˘ un anumit eveniment sau pentru un fragment finit dintr- t ao 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 arate sau clonate ilegal si propriul card în mod legal. A¸adar un card care nu este furat poate fi ¸ sutilizat 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 acepta mesajele transmise si poate afla PIN-urile în unele urme dup˘ care poate utiliza aceste ¸ acarduri în mod ilegal, chiar dac˘ nu are acces fizic la ele. Dac˘ cardurile sunt f˘ r˘ PIN atunci a a aaatacatatorul 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 aPIN-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 aaatunci 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 tnoi. 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 aipotezele care vor mai fi necesare, în af˘ r˘ de acestea care pot fi verificate, reprezint˘ încrederea aa aminimal˘ a modelului care este tolerat˘ de principiul utilit˘¸ii scopului propus de Bella în [5]. a a at2.3.1.3 Secrete Deoarece ne intereseaz˘ doar partea opera¸ional˘ , vom modela doar cum secretele sunt a t autilizate 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 adeclara¸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 t2.3.2 Evenimente Abordarea propus˘ de Bella în [2] extinde tipul de date pentru evenimente propus de Paul- ason 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 ¸ tmesaje. Ultimele 4 evenimente sunt ad˘ ugate pentru a modela interac¸iunea cu cardul. Agen¸ii a t tpot trimite inputuri c˘ tre card (Inputs) si cardurile s˘ le recep¸ioneze (CGets). Cardurile pot a ¸ a ttrimite outputuri c˘ tre agen¸i (Outputs) iar agen¸ii s˘ le recep¸ioneze (AGets). Mesajele de pe a t t a tre¸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 ¸ aCGets si AGets pot fi omise deoarece atacatorul nu poate împiedica recep¸ia mesajelor. Car- ¸ tdurile pot verifica dac˘ un eveniment Inputs A C X a avut loc iar agentul poate verifica dac˘ a aOutputs 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 tefectuat˘ la transmiterea acestuia. Dac˘ în protocolul analizat se consider˘ mijloace sigure de a a acomunicare î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 t2.3.3.1 Agen¸ii t La fel ca în cazul protocoalelor de securitate clasice, pentru protocoalele bazate pe smartcarduri vom nota agen¸ii one¸ti prin Friend i (i num˘ r natural), intrusul îl vom nota cu Spy, iar t s aserverul cu S sau Server. Agen¸ii compromi¸i care î¸i dezv˘ lui secretele atacatorului fac parte t s s adin mul¸imea bad. t2.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 acuritate care sunt analizate utilizeaz˘ carduri cu PIN atunci cuno¸tin¸ele ini¸iale ale agen¸ilor a s t t tpot 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 tale 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 sini¸ial doar cheile cardurilor si cheile care vor fi distribuite agen¸ilor în cazul protocoalelor de t ¸ tdistribu¸ie de chei, agen¸ii one¸ti nu au nici o informa¸ie ini¸ial˘ despre secrete, iar atacatorul t t s t t aare doar cuno¸tin¸ele ob¸inute din clonarea cardurilor. s t t2.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 asunt 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 tintrusului. Pentru a modela aceste cuno¸tin¸e trebuie s˘ lu˘ m în calcul mijloacele de comunicare dintre s t a aagent 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 sau 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 sagen¸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 tintrusului nu mai este extins˘ în cazul recep¸iei unui mesaj deoarece aceasta este actualizat˘ în a t amomentul î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 sinputurile 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 soutputurile 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 tcuno¸tin¸elor intrusului ca urmare a recep¸iei unui output din partea cardului nu trebuie extins˘ s t t adeoarece 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 tcare 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 ¸ aatacatorul 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 aul este s˘ -l cunoasc˘ ini¸ial prin intermediul unui agent compromis. Deasemenea atacatorul a a ttrebuie 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 aa2.3.4 Modelul intrusului Comportamentul ilegal al atacatorului este specificat pentru protocoalele clasice printr-osingur˘ regul˘ Fake care extinde modelul protocolului. Exemplu pentru un protocol teoretic a atrad_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 acelorlal¸i agen¸i. t t Pentru protocoalele bazate pe smart carduri, pe lâng˘ aceste mesaje false pe care le poate atrimite prin re¸ea, atacatorul trebuie s˘ poat˘ exploata utilizarea în mod ilegal a cardurilor atunci t a acând agen¸ii si cardurile comunic˘ prin mijloace nesigure. De exemplu s˘ poat˘ trimite inpu- t ¸ a a aturi false c˘ tre cardurile pe care le utilizeaz˘ în mod ilegal dar si outputuri false c˘ tre agen¸i a a ¸ a tpretinzâ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 ¸ aoutputuri 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 aName formalizeaz˘ cazul în care cardul este utilizat în mod legal, iar regula Name_Fake cel în acare cardul este utilizat ilegal de c˘ tre intrus, dar pentru a ob¸ine informa¸ii acesta trebuie s˘ a t t afalsifice 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_m2.3.5 Modelarea formal˘ a protocolalelor a Definirea modelului pentru protocoale bazate pe smart carduri necesit˘ reguli adi¸ionale de a trecep¸ie numai în cazul în care agen¸ii si cardurile comunic˘ prin mijloace nesigure. Aceste t t ¸ areguli nu sunt for¸ate s˘ se declan¸eze, deoarece atacatorul ar putea împiedica transmiterea t a smesajelor. Î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 3Protocolul KLOMP În contextul utiliz˘ rii tot mai accentuate a Internetului în activit˘¸ile comerciale, apare ca a atesen¸ial˘ stabilirea unui cadru robust de încredere pentru aplica¸iile care implementeaz˘ astfel t a t ade servicii. În general persoanele care intra în leg˘ tur˘ prin Internet pentru a realiza schimburi a ade bunuri, servicii sau informa¸ii nu se cunosc în prealabil, iar circula¸ia datelor se face liber t tf˘ r˘ un control si o cenzur˘ restrictiv˘ , de unde apare pericolul intercept˘ rii, modific˘ rii sau fal- aa ¸ a a a asific˘ rii acestora. Astfel cea mai important˘ provocare ce st˘ în fa¸a domeniului este asigurarea a a a tsecurit˘¸ii tranzac¸iilor. at t Bakker propune în [8] protocolul Klomp ca solu¸ie pentru securizarea acestor tranzac¸ii, fi- t tind un protocol de autentificare si distribu¸ie a cheilor bazat pe smart carduri si care utilizeaz˘ ¸ t ¸ atehnici 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 ttronic 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 ¸ atconfiden¸ialitate, integritate si non-repudiere nu fac scopul lucr˘ rii. Protocolul poate fi folosit în t ¸ asistemele de plat˘ online si sunt necesare 3 entit˘¸i: un consumator care va fi clientul, un server a ¸ atcare 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 ts˘ con¸in˘ un identificator, care poate fi num˘ rul de cont sau num˘ rul de membru, o cheie a t a a acare s˘ fie unic˘ pentru fiecare de¸in˘ tor de card si administrat˘ de autoritatea de încredere, a a t a ¸ asi s˘ ofere un mecanism provocare-r˘ spuns care s˘ utilizeze cheia unic˘ pentru a demonstra¸ a a a avaliditatea 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 asolu¸ie ar fi crearea unei baze de date cu toate cheile secrete de autentificare ale cardurilor la tfiecare terminal, dar aceast˘ nu este o solu¸ie indicat˘ deoarece în cazul sistemelor cu foarte a t amulte carduri acest˘ baz˘ de date ar atinge propor¸ii foarte mari. Solu¸ia practicat˘ este crearea a a t t acheii 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 as˘ cunoasc˘ doar cheia master dup˘ care poate calcula fiecare cheie de autentificare pe baza a a aidentificatorului furnizat de card. Astfel smart cardul va con¸ine doar cheia Kcard iar dac˘ cheia t amaster 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 asunt sigure deoarece cheile temporare care stau la baza cheii de sesiune sunt transmise în clar, iarsmart 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 aparametru de verificare V A , creat din aplicarea unei func¸ii hash asupra unui num˘ r aleator N A t aales de el concatenat cu un num˘ r de salt S A . Acest S A este folosit pentru a diminua posibili- atatea serverului de a deduce N A prin atacuri de tip dic¸ionar înainte ca acesta s˘ trimit˘ propriu t a anum˘ 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 ¸ aT care specific˘ o fereastr˘ de timp în care sesiunea de autentificare trebuie s˘ fie efectuat˘ . T a a a ava 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) asi va r˘ spunde cu identificatorul agentului A, tipul identificatorului IA , r˘ spunsul la provocare¸ a aKA∗ si op¸ional orice date utilizate în calculul r˘ spunsului la provocare DA . KA∗ va fi folosit ¸ t aca si cheie temporar˘ si va fi utilizat˘ în generarea cheii de sesiune KAB . Func¸ia de generare ¸ a¸ a tde chei va fi considerat˘ KAB = H(KA∗ //NA ). Dovada de autenticitate P AK este calculat˘ din a aA, 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 aB : PAK = PAB . Pasul 5. Clientul trimite to¸i parametrii (A, NA , IA , DA , PAK , B , NB , t T ) la server. B poateacum 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 atemporar˘ 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 apentru client în acest pas, deci poate calcula direct PBK folosind KB∗ . Serverul nu poate verificaP AK deoarece nu cunoa¸ te înc˘ cheia KAB deci va trimite to¸i parametrii la autoritatea de încre- s a tdere: (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 asesiune si o va cripa pentru server folosind func¸ia TBA =H(KB∗ //NB ) ⊕ KAB . Aceasta va fi ¸ ttrimis˘ 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 ¸ ¸ acalcula dovada P BA pentru client si o va trimite acestuia. În final clientul va verifica aceast˘ ¸ avaloare.Figura 2: Protocolul KLOMP (KryptoKnight-based Lightweight Open Mutual authentication Protocol) 31
  • 32. Capitolul 4Analiza protocolului KLOMP4.1 Modelarea protocolului Modelarea evenimentelor, a smart cardurilor si a intrusului este realizat˘ pe baza formalizarii ¸ acare a fost propus˘ în capitolul 3. Modelul formal al protocolului este o mul¸ime de liste de a tevenimente numit˘ klomp creat˘ pe baza protocolului Klomp propus de Bakker în [8]. În cele a ace 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 avocarile 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 autilizeaz˘ carduri f˘ r˘ PIN putem omite func¸ia pinK. Cuno¸tin¸ele ini¸iale ale serverului este a aa t s t tmul¸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 ssi 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 aaplica 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 timpult a tcurent 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 tde acesta perioad˘ de valabilitate si vor ignora mesajele care con¸in m˘ rci de timp expirate, a ¸ t afolosind 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 amentul î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- am˘ rul de card. Pentru fiecare input primit cardul va returna acest identificator. Pentru a specifica aidentificatorul unui agent vom utiliza o nou˘ func¸ie cardID care va asocia fiec˘ rui card un iden- a t atificator unic: cardID : card → nat4.1.1 Baza Urma vid˘ formalizeaz˘ scenariul ini¸ial în care nici o sesiune a protocolului nu a avut a a tloc. Regula Base pune bazele induc¸iei în care se specific˘ c˘ urma vid˘ este admis˘ în mo- t a a a adelul 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 adestinatari. Base [] ∈ klomp Reception [| evsR ∈ klomp; Says A B X ∈ set evsR|] =⇒ Gets B X # evsR ∈ klomp4.1.2 Pasul 1 Orice agent poate ini¸ia o sesiune a protocolului, în orice moment deci evenimentul cores- tpunz˘ tor pasului 1 - K1 poate extinde orice urm˘ . Ini¸iatorul trebuie s˘ genereze un rezumat a a t ahash 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 înt a a a apasul 5. Receptorul trebuie s˘ verifice c˘ acest Na a fost ales înainte ca el s˘ -i furnizeze propriul a a anum˘ 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 ∈ klomp4.1.3 Pasul 2 În urma recep¸iei unui mesaj format din dou˘ componente, un num˘ r de salt Sa care este t a apublic si un rezumat hash, cel care îl recep¸ioneaz˘ va genera un nonce nou Nb pe care îl va ¸ t afurniza ini¸iatorului mesajului împreun˘ cu identitatea sa B si un num˘ r care reprezint˘ timpul t a ¸ a as˘ 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 ∈ klomp4.1.4 Pasul 3 Ini¸iatorul unei sesiuni a protocololului dac˘ este onest, în urma recep¸iei datelor de la cel cu t a tcare dore¸te stabilirea leg˘ turii sigure: identitatea agentului B , un num˘ r aleator Nb si un num˘ r s a a ¸ acare reprezint˘ o marc˘ de timp Tk , le va trimite mai departe c˘ tre propriul card împreun˘ cu a a a anonceul 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 ∈ klomp4.1.5 Pasul 4 Dac˘ cardul agentului A este utilizat în mod legal, primind inputul format din 2 nonceuri, o amarc˘ 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 atemporar˘ K a∗ care reprezint˘ r˘ spunsul la provocare calculat cu cheia cardului crdK(Card A), a a asi pe care o va returna agentului împreun˘ cu identitatea de¸in˘ torului de card A, identificatorul¸ a t ade¸inut de acesta si eventual alte date care sunt utilizate în calculul r˘ spunsului Da. Cardul nu t ¸ ava 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 ∈ klomp4.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 tsi 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 sB . Folosind aceast˘ cheie A va crea un certificat care va fi folosit pentru a se autentifica în afa¸a serverului si a autorit˘¸ii de încredere. Acest certificat împreun˘ cu toate datele colectate t ¸ at apân˘ în acest moment sunt transmise c˘ tre server. Autoritatea de încredere verific˘ certificatul a a aprin recreerea cheii de sesiune K ab în pasul 9 iar serverul va putea verifica certificatul doar înmomentul î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 ∈ klomp4.1.7 Pasul 6 Dac˘ B este un server legitim atunci acesta i¸i utilizeaz˘ cardul în mod legal. Primind a s atoate 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 ade client Na nu este compromis (dac˘ a fost ales la începutul sesiunii). Verificarea se face prin acompararea verificatorului primit în pasul 1 si un rezumat hash calculat din num˘ rul de salt Sa ¸ aprimit în pasul 1 si nonce-ul Na primit în acest pas. Serverul trimite c˘ tre cardul s˘ u propriul ¸ a anonce 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 aautenticitatea 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 ∈ klomp4.1.8 Pasul 7 Fiind utilizat în mod legal, cardul serverului va genera un rezumat hash din datele primiteCb si va calcula o cheie temporar˘ K b∗ asem˘ n˘ tore cu cea din pasul 4. Împreun˘ cu aceast˘ ¸ a a a a acheie 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 ∈ klomp4.1.9 Pasul 8 Serverul B având toate datele, mai pu¸in cheia de sesiune, poate crea propiul certificat de tautenticitate 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 ∈ klomp4.1.10 Pasul 9 Autoritatea de încredere primind toate datele, verific˘ în primul rând dac˘ marca de timp a aeste valid˘ , dup˘ care verifica autenticitatea celor dou˘ entit˘¸i pe baza certificatelor si recreaz˘ a a a at ¸ acheia de sesiune pentru a o trimite c˘ tre B, criptat˘ cu o cheie ce poate fi construit˘ doar de a a acel care de¸ine cheia temporar˘ K b∗ . Pentru a verifica certificatul Pak autoritatea de încredere t atrebuie s˘ recreeze provocarea Ca si folosind cheia cardului A s˘ ob¸in˘ cheia temporar˘ K a∗ . a ¸ a t a aCu 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 acertificatul si verifica autenticitatea entit˘¸ii B . Dac˘ verificarea certificatelor a fost cu succes, ¸ at aautoritatea 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 ∈ klomp4.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 acheia de sesiune acesta poate verifica certificatul de autenticitate primit în pasul 5 de la clientPak 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 ∈ klomp4.1.12 Vulnerabilit˘ ¸i at Atacatorul se poate comporta atât legal urmând pa¸ii de mai sus sau ilegal folosind car- sdurile altor agen¸i, caz în care trebuie s˘ specific˘ m reguli suplimentare. Conform modelului t a aDolev-Yao acesta poate observa traficul de pe fiecare urm˘ , poate extrage toate componentele amesajelor si poate construi mesaje false pe care s˘ le transmit˘ în re¸ea sau ca input la cardurile ¸ a a tutilizate î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˘ aatacatorul poate s˘ ob¸in˘ outputuri de la cardurile utilizate în mod ilegal. Astfel regula K4_Fake a t ava 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 ∈ klomp4.1.13 Accidente Modelul trebuie s˘ permit˘ bre¸e de securitate pentru cheile de sesiune, caz în care acestea a a spot fi descoperite de atacator. De exemplu în pasul 9 al protocolului cheia Kab este transmis˘ ade c˘ tre autoritatea de încredere lui B iar atacatorul ar putea avea sansa s˘ descopere cheia de a ¸ asesiune. Oops [| evs0 ∈ klomp;Says Server B (Crypt K (Key sesK(Na, Ka∗)))∈ set evs0|] =⇒ Notes Spy {| Key sesK(Na, Ka∗)|}# evs0 ∈ klomp4.2 Verificarea protocolului Pentru a specifica si verifica propriet˘¸ile protocolului Klomp în cele ce urmeaz˘ se va utiliza ¸ at ao 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 a2 si demonstreaz˘ consisten¸a modelului, dar si înc˘ lcarea principiului comunic˘ rii explicite ¸ a t ¸ a aprezentat în capitolul 1 pentru pa¸ii 4 si 7 din protocol. Demonstra¸iile sunt simple: se aplic˘ s ¸ t ainduc¸ia dup˘ care se apeleaz˘ la simplific˘ ri. t a a a4.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 tacelui agent si este utilizat în mod legal ceea ce confirm˘ faptul c˘ agen¸ii one¸ti pot utiliza doar ¸ a a t spropriile 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 amod 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 ateoreme asupra evenimentelor de tip Output. Prima teorem˘ demonstreaz˘ faptul c˘ smart car- a a adurile 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 aforma 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 ac˘ A recep¸ioneaz˘ un mesaj con¸inând o cheie temporal˘ creat˘ pe baza unui rezumat hash a t a t a adar 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 aca fiecare mesaj s˘ spun˘ exact ceea ce înseamn˘ , iar interpretarea acestuia s˘ depind˘ doar a a a a ade con¸inut. Componentele rezumatului hash fac leg˘ tura cu cel cu care se dore¸te stabilirea t a sunei leg˘ turi sigure, iar cardul ar putea furniza outputuri într-o ordine gre¸it˘ . Agentul nu a s acunoa¸te cheia cardului pentru a putea inspecta rezumatul hash deci ar putea asocia gre¸it cheia s stemporar˘ .a Pentru a rezolva aceast˘ problem˘ indicat ar fi ca smart cardul s˘ furnizeze agentului pe a a alâng˘ cheia temporar˘ si rezumatul hash cu care a fost creat˘ cheia temporar˘ . Astfel în mo- a a¸ a amentul în care agentul prime¸te outputul, acesta poate recrea rezumatul hash pe baza datelor sfurnizate 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 aanumit 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- alui 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 averific˘ faptul c˘ agen¸ii produc inputuri folosind componente ale c˘ ror origine poate fi docu- a a t amentat˘ . 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 taleatoare, o marc˘ de timp si un nume de agent atunci poate fi demonstrat˘ originea acestor a ¸ adate. Dac˘ inputul este corespunz˘ tor mesajului 3 atunci primul num˘ r aleator a fost ales de a a aproprietarul cardului iar celelalte date au fost recep¸ionate de pe re¸ea. Dac˘ inputul corespunde t t amesajului 6 atunci primul num˘ r aleator a fost fost recep¸ionat de pe re¸ea iar celelalte date au a t tfost 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 aremei 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 atimp si numele unui agent. ¸4.2.2 Regularitate Lemele de regularitate exprim˘ fapte care pot fi demonstrate pentru mesajele care sunt trans- amise prin re¸ea. Lemele de regularitate pentru chei cuprind acele chei pe care protocolul nu le ttransmite în traficul de pe re¸ea. De exemplu dac˘ în urma evs a modelului apare una din cheile t asecrete ale unui agent atunci acest agent este compromis. Demonstra¸ia implic˘ faptul c˘ ata- t a acatorul este cel care a transmis cheia, folosind regula Fake, deoarece cel care de¸ine cheia nu o tva transmite niciodat˘ prin re¸ea în cadrul protocolului. Din ipotezele regulii Fake reiese faptul a tc˘ atacatorul cunoa¸te cheia doar dac˘ agentul este compromis. Utilizând defini¸iile initState, a s a tknows 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 acrdK 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 sniciodat˘ 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 atcheile 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¸aa 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 atului. 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 afaptul 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 aserverul 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 aurm˘ toarele teoreme. În Isabelle demonstrarea lor se face automat în urma aplic˘ rii induc¸iei. a a tIntegritatea mesajelor transmise între smart carduri si agen¸i reiese din demonstrarea teoremele ¸ tde 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 ¸ ade sesiune si nu cu o cheie stocata pe card, iar cheia de sesiune este creat˘ pe baza unei chei ¸ atemporare 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 ¸ aautorit˘¸ii de încredere este criptat întradev˘ r cu o cheie temporar˘ si nu cu o cheie stocat˘ pe at a a¸ acard. 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 ape care le pot verifica. Cheile temporare din protocolul Klomp sunt de fapt certificate criptate cucheia secret˘ a cardurilor care confirm˘ autenticitatea celor care le creeaz˘ . Cheile temporare a a asunt utilizate pentru a cripta certificate cu care agen¸ii si serverele se vor autentifica în fa¸a t ¸ tautorit˘¸ii de încredere. Pentru a demonstra c˘ aceste chei sunt create de agen¸i one¸ti în pa¸ii 4 at a t s ssi 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 anu pot fi falsificate de atacator decât dac˘ acesta cunoa¸te cheia. Dac˘ atacatorul nu cunoa¸te a s a scheia 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 ade 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 ateorema 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 acheii temporare pe baza c˘ reia a fost creat˘ cheia de sesiune nu poate fi verificat˘ de nici un a a aagent, deoarece ace¸tia nu cunosc cheile stocate pe carduri. În concluzie, aceast˘ garan¸ie ob¸i- s a t tnut˘ 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 aturm˘ 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 acunoa¸te cheia cu care a fost criptat, atunci A poate trage concluzia c˘ cel care l-a trimis cunoa¸te s a scheia 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 strage 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 apractic˘ . În aceast˘ lucrare am ar˘ tat c˘ Metoda Inductiv˘ poate fi utilizat˘ cu succes pen- a a a a a atru 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 adin lumea real˘ . Verificarea sistemelor în urma identific˘ rii unor noi vulnerabilit˘¸i nu nece- a a atsit˘ decât formalizarea acestora ca si reguli inductive adi¸ionale si redemonstrarea propriet˘¸ilor a ¸ t ¸ atprotocolului. Smart cardurile au ap˘ rut ca o solu¸ie pentru protejarea datelor transmise în cadrul sesiu- a tnilor de comunicare oferind un mod sigur de a stoca informa¸ii secrete pe termen lung. Uti- tlizâ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 ¸ tcarduri, propus de Bella în [8]. Protocolul a fost creat pentru a asigura tranzac¸iile comer¸ului t telectronic 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 aconstruc¸iei protocoalelor de securitate si anume: comunicarea explicit˘ . Aceast˘ vulnerabili- t ¸ a atate ar putea conduce la erori de asociere a cheilor dac˘ smart cardurile nu ar func¸iona corect, a tca de exemplu în cazul în care apar defecte ale magistralelor de date sau eventual coruperi aleacestora în faza de fabricare a cardului. În aceast˘ lucrare sunt prezentate elementele fundamentale ale model˘ rii si verific˘ rii smart a a ¸ acardurilor. O analiza complet˘ a unui protocol de securitate este dificil de realizat si necesit˘ a ¸ aconsiderarea unui num˘ r foarte mare de factori. În analiza protocolului Klomp am conside- arat aspectele esen¸iale care contribuie la asigurarea securit˘¸ii oferite de protocol, precum cele t atlegate 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 ttegritate si autenticitate a mesajelor, dar si cele de distribu¸ie a cheilor de sesiune. O parte din ¸ ¸ taceste propriet˘¸i au fost demonstrate ¸inând cont de principiul de analiz˘ a protocoalelor de at t asecuritate propus de Bella: utilitatea scopului. Consider c˘ analiza protocolului Klomp ar putea afi 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 trebuiverificate 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

×