PROIECT DE LICENTA - cipsm.hpc.pub.rocipsm.hpc.pub.ro/documentation/Catalin_Gosman.pdf · In stiva...

Universitatea Politehnica Bucuresti

Facultatea de Automatica si Calculatoare

PROIECT DE LICENTA

Protocol de securitate pentru medii VANET

Student: Catalin Gosman

Coordonatori: Prof. Dr. Ing. Valentin Cristea, Sl. Dr. Ing. Ciprian Dobre

2

Abstract

Vehicular Ad-Hoc Networks (VANET) sunt un tip special de retele wireless ad-hoc ce

includ dispozitive de comunicare fara fir cu raza scurta de actiune, fiecare dintre ele reprezentand

un vehicul rutier sau un dispozitiv static. Retelele VANET (Vehicular Ad-Hoc Networks)

reprezinta un domeniu de cercetare de interes datorita avantajelor pe care le aduc in dezvoltarea

aplicatiilor de optimizare a traficului, cresterea sigurantei rutiere, diminuarea poluarii in marile

aglomeratii urbane si multe altele. Multi specialisti apreciaza ca aceasta forma de retea ad-hoc

mobila va deveni din ce in ce mai importanta in urmatorii ani.

Dezvoltarea de aplicatii si protocoale pentru retelele VANET pune probleme de

securitate unice, induse de dispozitivele utilizate, de conectivitatea sporadica a vehiculelor sau de

necesitatea protejarii identitatii participantilor la trafic. Informatia transmisa intr-o retea VANET

necesita adesea masuri sporite de asigurare a securitatii.

Lucrarea propune un protocol de asigurare a securitatii transmiterii informatiilor adecvat

caracteristicilor particulare ale sistemelor VANET. Protocolul de securitate a fost validat prin

intermediul unei implementari pilot realizata folosind simulatorul VNSim. In cadrul lucrarii sunt

prezentate o serie de rezultate experimentale ce vin sa demonstreze corectitudinea acestuia.

Astfel, solutia propusa se arata a fi adecvata protejarii mesajelor transmise intre participantii la

trafic. In ansamblu, lucrarea prezinta un experiment care vrea sa transforme compromisul dintre

avantaje si dezavantaje intr-un pas inainte in ceea ce priveste securitatea in retelele vehiculare

ad-hoc.

3

Cuprins

Abstract ......................................................................................................................................................... 2

Capitolul 1- Introducere ................................................................................................................................. 5

1.1 Concepte generale de securitate ............................................................................................................. 5

1.2 Securitatea in medii VANET .................................................................................................................... 6

1.3 Sumar al lucrarii ...................................................................................................................................... 7

Capitolul 2 – Abordari ale Securitatii in medii VANET ................................................................................... 8

2.1 Caracteristici VANET ................................................................................................................................ 8

2.2 Probleme de securitate specifice mediilor VANET ................................................................................ 10

2.3 Lucrari inrudite ...................................................................................................................................... 13

Capitolul 3 - Protocolul de asigurare a securitatii in medii VANET .............................................................. 17

3.1 Caracteristici generale ........................................................................................................................... 17

3.2 Starile protocolului ................................................................................................................................ 19

3.3 Entitati participante in protocol ............................................................................................................ 22

3.4 Mesajele existente in protocol............................................................................................................... 25

3.5 Securitatea mesajelor – Semnaturi digitale .......................................................................................... 26

Capitolul 4 – Implementare pilot in simulatorul VNSIM .............................................................................. 29

4.1 Simulatorul VNSim ................................................................................................................................. 29

4.1.1 Modulul de mobilitate ....................................................................................................................... 30

4.1.2 Modelul de comunicatie .................................................................................................................... 31

4.2. Detalii de implementare ....................................................................................................................... 33

4.3 Clasa SecCar .......................................................................................................................................... 34

4.4 SecCityTrafficLight ................................................................................................................................. 40

4.5 Clasa SecMessage.................................................................................................................................. 44

4.6. Clasa SecureGlobals .............................................................................................................................. 46

4.7 Detalii suplimentare privind implementarea protocolului .................................................................... 47

Capitolul 5 - Rezultate Experimentale ......................................................................................................... 48

5.1 Validarea parametrilor protocolului de securitate ................................................................................ 48

5.2 Performanta protocolului de securitate in conditii ce nu implica prezenta unor atacatori ................. 50

5.3 Scenariul 1 ............................................................................................................................................. 54

4

5.4 Scenariul 2 ............................................................................................................................................ 58

5.5 Scenariul 3 ............................................................................................................................................. 61

5.6 Scenariul 4 ............................................................................................................................................. 65

5.7 Scenariul 5 ............................................................................................................................................. 70

5.8 Scenariul 6 ............................................................................................................................................. 75

5.9 Analiza rezultatelor ............................................................................................................................... 77

Capitolul 6 – Concluzii.................................................................................................................................. 78

Bibliografie .................................................................................................................................................. 80

5

Capitolul 1- Introducere

1.1 Concepte generale de securitate

In primele decenii ale existentei lor, retelele de calculatoare au fost folosite de cercetatorii

din universitati pentru trimiterea postei electronice. In aceste conditii, securitatea nu atragea prea

mult atentia. Dar acum, cand milioane de utilizatori folosesc retelele pentru cele mai banale

lucruri de zi cu zi, securitatea retelei apare la orizont drept o problema stringenta.

Securitatea este un subiect amplu, care ridica o multime de semne de intrebare.

Problemele securitatii se refera la urmatoarele aspecte fundamentale:

� Confidentialitate (pastrarea secretului) – se refera la pastrarea informatiei departe de

utilizatorii neautorizati.

� Integritatea – informatia poate fi modificata doar de utilizatorii autorizati sau in

modalitate autorizata (asigura ca mesajul primit nu a fost modificat in tranzit sau

masluit). Integritatea acopera atat integritatea datelor, cat si integritatea originii

(verificata prin autentificare sau determinarea identitatii partenerului cu care schimbi

mesaje inainte de a dezvalui informatii importante)

� Disponibilitatea – accesul la informatie a utilizatorilor autorizati nu este ingradit (opusul

este denial of service).

Dintre problemele derivate mentionam:

� Controlul accesului – reprezinta protectia impotriva accesului ne-autorizat

� Non-repudierea – prin care se asigura ca transmitatorul nu poate nega transmiterea unui

mesaj pe care un receptor l-a primit deja.

In stiva de protocoale securitatea retelei nu se situeaza intr-un loc anume, ea fiind

aplicabila pe mai multe nivele [44]. La nivel fizic, ascultarea firelor poate fi limitata prin

incapsularea liniilor de transmisie in tuburi sigilate. La nivelul legatura de date, pachetele

transmise pe o linie punct-la-punct pot fi codificate cand parasesc una dintre masini si

decodificate cand intra in cealalta.Toate detaliile pot fi manipulate la nivelul legatura de date,

fara ca nivelurile mai inalte sa aiba cunostinta de ceea ce se petrece. La nivelul retea pot fi

instalate ziduri de protectie pentru a pastra pachetele in interiorul sau in afara acestora.

Securitatea IP functioneaza la acest nivel. La nivelul transport pot fi criptate conexiuni intregi, de

la un capat la celalalt, adica de la un proces la celalalt. In sfarsit, probleme cum sunt

autentificarea utilizatorilor si non-repudierea nu pot fi tratate decat la nivel aplicatie.

6

1.2 Securitatea in medii VANET

In retelele VANET (Vehicular Ad-Hoc Networks) o problema importanta care framanta

atat mediul academic cat si cel industrial este implementarea unui model de asigurarea a

securitatii.

Cercetarea in acest domeniu este intr-un stadiu incipient, pana in acest moment existand

doar cateva articole in care este dezbatuta problema securitatii pentru acest tip de retele.

Pana nu demult, automobilele au fost apogeul ingineriei mecanice. O data cu inovatiile

tehnologice a aparut si dorinta producatorilor de a creste siguranta in trafic, astfel incat

autovehiculele au devenit “calculatoare pe roti”, si chiar mai mult, ”retele mobile pe roti”. Spre

exemplu, o masina moderna are cateva zeci de procesoare interconectate; are de obicei un

computer central, precum si un sistem EDR (Event Data Recorder – dispozitiv de stocarea a

evenimentelor, asemanator cu “black box”-urile din avioane), un sistem GPS (Global Positioning

System), un sistem de navigare si multe alte sisteme electronice. Producatorii de automobile sunt

pe cale sa faca un pas major din punct de vedere informational, lasand masinile sa comunice

unele cu altele, precum si cu infrastructura rutiera; in acest fel, o masina va fi mult mai

constienta de mediul in care se afla, crescand implicit siguranta si optimizand traficul.

Avand in vedere beneficiile importante aduse de intercomunicarea dintre masini si

numarul mare de autovehicule existente (cateva sute de milioane la nivel mondial), este evident

ca acest tip de comunicatie este cel mai probabil sa devina cel mai relevant exemplu de retea ad-

hoc mobila. Una dintre provocarile care apar in aceste circumstante este securitatea; de exemplu,

este esential ca informatii de maxima importanta sa nu poata fi inserate sau modificate de un

atacator; de asemenea, sistemul ar trebui sa fie capabil sa poata stabili gradul de responsabilitate

al soferilor, si, in acelasi timp, sa proteje pe cat posibil identitatea conducatorilor si a pasagerilor.

Cu toate ca aceste probleme par similare cu cele intalnite in alte tipuri de retele de comunicatie,

ele au particularitati care le fac unice. Astfel, dimensiunea retelei, viteza autovehiculelor,

relevanta pozitionarii geografice, conectivitatea sporadica dintre masini fac din securitatea in

VANET o provocare ce isi cauta raspuns.

Solutia de securitate prezentata in lucrare se bazeaza pe pozitia vehiculelor in momentul

transmiterii mesajelor, momentul de timp la care se petrece emisia, autoritatile de certificare

existente in zona in momentul inceperii transmiterii de informatii in mediul VANET, urmarind

crearea unei posibilitati de securizare a transmiterii mesajelor.

7

1.3 Sumar al lucrarii

Pe parcursul capitolelor urmatoare vom prezenta in detaliu protocolul de securitate

propus pentru retele VANET.

Capitolul 2 prezinta abordarile existente in cadrul retelelor mobile de autovehicule cu

avantajele si limitarile aferente, dar si modul in care s-au exploatat ideile actuale in vederea

analizei si modelarii solutiei curente.

In Capitolul 3 prezentam solutia de securitate propusa, adecvata pentru medii VANET,

precum si motivatia alegerii acesteia.

Capitolul 4 prezinta implementarea pilot in simulare, punand accentul pe detaliile

specifice.

Capitolul 5 prezinta rezultatele experimentale pentru protocolul de securitate

implementat.

Capitolul 6 evidentiaza principalele concluzii, precum si eventuale imbunatatiri si

extinderi ulteriore.

8

Capitolul 2 – Abordari ale Securitatii in medii VANET

2.1 Caracteristici VANET

Nodurile comunicante in VANET sunt vehiculele sau statii emisie/receptie. Vehiculele

pot fi private (apartinand unor persoane sau companii) sau publice (exemplu: mijloacele de

transport in comun, masinile de politie, pompieri, etc). Statiile de emisie/receptie pot apartine

guvernului sau unor provideri din sectorul privat. Presupunem ca este suportat standardul IEEE

802.11.

Considerand ca majoritatea nodurilor din VANET vor consta din automobile, dinamica

retelei va fi caracterizata de mobilitate, viteza, conectivitate intre vecini.

Un avantaj al VANET-urilor spre deosebire de retelele ad-hoc clasice este ca vehiculele

furnizeaza o putere de calcul substantiala si au resurse de energie mari.

Dimensiunea retelelor VANET este o alta caracteristica ce trebuie luata in considerare.

Cu sute de milioane de noduri distribuite global, VANET-urile pot deveni cea mai mare retea ad-

hoc mobila existenta. Cu toate acestea, comunicatia se va desfasura pe plan local, astfel

partitionand reteaua si facand-o scalabila.

Fig 2.1.1 – Retea VANET

9

Aplicatiile care pot rula in VANET pot fi impartite in doua mari categorii:

i) Aplicatii corelate cu notiunea de siguranta, cum ar fi evitarea coliziunilor si sofatul intr-

un stil cooperativ. Caracteristica comuna a acestei clase de aplicatii este importanta in cazul

situatiilor critice cand existenta unui serviciu poate impiedica accidente mortale.

ii) Alte aplicatii, cum ar fi optimizarea traficului, servicii de plata, servicii bazate pe locatia

geografica, accesul la Internet etc. Evident, si in aceasta categorie este necesara implementarea

securitatii, in special in cazul serviciilor de plata.

Tipurile de mesaje care pot fi schimbate pot fi impartite in urmatoarele categorii:

i) Mesaje de informare in trafic – folosite pentru a instiinta soferii asupra conditiilor de

trafic dintr-o anumita regiune, astfel afectand in mod indirect siguranta conducatorilor.

ii) Mesaje generale legate de siguranta – folosite in cazul sofatului cooperativ in scopul

evitarii coliziunilor.

iii) Mesaje de responsabilizare – folosite in cazul unor situatii neplacute, cum ar fi

accidentele.

O proprietate comuna a acestor mesaje este faptul ca sunt de sine statoare si specifice

unei zone geografice (nu exista dependenta intre mesaje precum in cazul aplicatiilor de flux

media).

Un element cheie cand vorbim despre securitate este increderea. Datorita numarului mare

de membri dintr-o retea VANET si a prezentei factorului uman, este foarte probabil ca anumite

devieri de la cursul normal sa se intample. In plus, participantii sunt foarte interesati de gradul lor

de “privacy”. Drept consecinta, se presupune un grad diferentiat de incredere a autovehiculelor,

precum si a statiilor de emisie/receptie.

10

2.2 Probleme de securitate specifice mediilor VANET

Retelele mobile de automobile sunt supuse mai multor riscuri. Atacatorii pot fi clasificati

in mai multe categorii [4]:

i) Interni sau externi. Un atacator intern este un membru autentificat in retea care poate

comunica cu ceilalti membri ai retelei. Un atacator extern este considerat de membrii retelei un

intrus, astfel este limitat in posibilitatatile sale de agresiune asupra retelei.

ii) Malitios sau rational. Un atacator malitios nu cauta beneficii personale in urma atacului,

ci doar doreste sa afecteze functionalitatea retelei. In opozitie, un atacator rational urmareste

interese personale si este mai predictibil cand se gandeste ce va ataca si ce va obtine de pe urma

atacului.

iii) Activ sau pasiv. Un atacator activ poate genera pachete sau semnale, pe cand un atacator

pasiv se margineste la a asculta canalul wireless.

iv) Local sau extins. Un atacator poate fi limitat, astfel incat el va controla doar cateva

entitati (vehicule sau statii de emisie/receptive), ceea ce ii da un caracter local. Un atacator extins

nu se margineste local, ci isi coordoneaza atacurile in toata reteaua.

In cazul lucrarii de fata ne concentram asupra atacurilor ce exploteaza mesajele si nu

vehiculele din punct de vedere fizic, intrucat securizarea dispozitivelor electronice nu este tinta

lucrarii.

Tipuri de atacuri ce pot fi desfasurate in retelele VANET [4]:

� Bogus Information – Atacatorii sunt interni, locali, rationali, activi si difuzeaza in retea

informatii eronate pentru a afecta comportamentul celorlalti conducatori implicati in

trafic.

� Alterarea informatiilor de la senzori - Atacatorii sunt interni, locali, rationali, activi si

folosesc acest tip de atac pentru a altera informatii legate de pozitie, viteza, directie,

pentru a scapa de responsabilizare, in special in cazul unui accident.

� Evidenta ID-ului altor vehicule pentru a le urmari locatia - Pentru a le monitoriza,

observatorul global se bazeaza pe infrastructura rutiera si pe celelalte vehicule din jur.

� DoS (Denial of Service) – atacatorul este malitios, activ, local si poate afecta

functionalitatea retelei VANET producand un accident. Exemple de astfel de atacuri sunt

blocarea canalului si injectarea agresiva de mesaje “dummy”.

� Masquerading – atacatorul pretinde ca este alt autovehicul utilizand o identitate falsa.

11

Exista si variante mai elaborate de atacuri ce se bazeaza pe combinatii ale atacurilor

anterioare. Astfel de exemple pot fi [4]:

a) Vehicul ascuns

Fig. 2.2.1 Atac de tip vehicul ascuns.

Acesta este un exemplu concret de alterare a informatiilor privind locatia. Un vehicul

care trimite mesaje broadcast de avertizare va asculta feedback-ul de la vecini si se va opri din a

emite mesaje cand va observa ca un vehicul este mai bine amplasat pentru a trimite mesaje de

avertizare vecinilor . Astfel se reduce congestia de pe canalul wireless. In figura, se observa ca

vehiculul B pacaleste pe A in a considera ca el are o amplasare mai buna pentru a transmite in

continuare mesaje de avertizare.

b) Tunel

Fig 2.2.2 Atac tunel

Cum semnalele GPS dispar in tunel, un atacator poate exploata aceasta vulnerabilitate a

pierderii temporare a informatiilor de pozitionare injectand date false imediat ce tinta paraseste

tunelul dar inainte de a primi o actualizare de locatie.

12

c) Wormhole: Acest tip de atac consta in tunelarea pachetelor intre doua noduri remote.

Atacatorul controleaza doua entitati remote una fata de cealalta si creaza o legatura intre ele prin

care circula pachete cu informatii gresite in legatura cu locatia destinatie.

d) Bush telegraph: este un tip de atac derivat din atacul de tip Bogus Information. Atacul consta

in adaugarea de informatii eronate incremental la fiecare hop. Acumularea de date gresite poate

duce la luarea de decizii eronate la urmatorul hop.

Cerinte de securitate in cadrul retelelor VANET:

� Autentificare - vehiculele care reactioneaza la evenimente ar trebui sa se bazeze pe

mesaje legitime (generate de expeditori legitimi). Astfel, trebuie sa autentificam pe cei

care trimit mesajele.

� Verificarea consistentei datelor (validitate) – legitimitatea mesajelor incorporeaza si

consistenta lor cu altele similar (acele mesaje generate in imediata vecinatate si in

intervalul de timp curent), deoarece expeditorul mesajelor poate fi considerat legitim dar

mesajul poate contine date false.

� Disponibilitate – chiar daca consideram un canal robust de comunicatie, unele atacuri

(cum ar fi Dos) pot cu usurinta afecta functionalitatea retelei. Astfel, disponibilitatea

trebuie asigurata prin mijloace alternative.

� Nonrepudiere – conducatorii ce provoaca accidente trebuie identificati in mod sigur; unui

expeditor nu ar trebui sa i revoce dreptul de a transmite un mesaj (este posibil sa fie

crucial sa determinam secventa corecta si continutul mesajelor inainte de accident).

� Privacy – trebuie garantat “privacy” conducatorilor impotriva observatorilor neautorizati.

� Constrangeri real-time – la vitezele foarte mari specifice VANET-urilor, constrangerile

real-time trebuie respectate cu strictete.

13

2.3 Lucrari inrudite

Cercetarile privind securitatea in retelele VANET sunt de-abia la inceput. Car2Car

Communication Consortium [1] a facut cele mai semnificative eforturi in Europa, iar in Statele

Unite ale Americii s-a remarcat consortiul DSRC, in special grupul IEEE P1609.2.

In [7], Blum si Eskandarian descriu un model architectural de securitatea pentru VANET-

uri menit sa contraatace asa numitele “coliziuni inteligente” (adica coliziuni care au fost cauzate

intentionat). Acesta este un tip de atac, dar construirea unui arhitecturi necesita vizualizarea unor

masuri impotriva tuturor atacurilor posibile. Ei propun folosirea PKI (Public Key Infrastructure).

Gerlach [14] prezinta concepte de securitate in retelele de automobile. Hubaux [21] priveste

securitatea din alta perspectiva si se concentreaza mai mult pe conceptele de “privacy” si

pozitionare sigura. El puncteaza importanta compromisului dintre responsabilitate si anonimitate

si introduce notiunea de Electronic License Plates (ELP) (unice pentru vehicule). Parno si Perig

[29] explica cateva din atacurile ce pot aparea in VANET-uri. El Zarki [42] descrie infrastructura

specifica VANET-urilor si mentioneaza succinct cateva probleme de securitate si posibile solutii.

Folosirea semnaturilor digitale este discutata in [15]. Chestiuni strans corelate cu securitatea in

retelele VANET sunt problemele legate de securitatea sistemelor fizice electronice dintr-un

vehicul, sisteme care sunt responsabile pentru transportul sau generarea de date inainte ca acestea

sa fie transmise.

In cazul unor aplicatii nesigure in care vehiculele comunica cu infrastructura, schema

CARAVAN [34] da posibilitatea masinilor sa-si pastreze “privacy”-ul formand grupuri in care

fiecare lider se comporta ca un proxy pentru ceilalti membri din grup care acceseaza

infrastructura. Cand vehiculele nu au acces la infrastructura, ele raman “silentioase”, astfel

prevenind eventualii “ascultatori” in a le afla pseudonimele.

In [43], Stefan Sosoiu si Alec Wolman de la Microsoft Research prezinta o solutie pentru

problematica securitatii in retele mobile folosind “location proofs”- un mecanism prin care

aplicatiile mobile pot cere o “dovada” privind locatia unui anumit membru al retelei mobile.

Legitimitatea mesajelor este mandatorie pentru a proteja retelele VANET de atacatori

interni, cat si externi. Daca mesajele de siguranta nu contin informatie senzitiva,

confidentialitatea nu este necesara. Ca rezultat, schimbul de mesaje care sunt in corelatie cu

siguranta are nevoie de autentificare, dar nu neaparat si de criptare.

Un model de securitate este oferit de Matthias Gerlach, Andreas Festag, Tim Leinmuller,

Gabriele Goldacker and Charles Harsch de la Fraunhofer Institute for Open Communication

Systems (FOKUS) [45]. Arhitectura de securitate este bazata pe o structura ierarhica, pe mai

multe straturi. Cel mai de jos nivel se ocupa de inregistrarea nodurilor (maparea intre identitatea

proprietarului si identificatorul nodului). Practic, stratul cel mai de jos contine o baza de date cu

informatii referitoare la vehicul, cum ar fi numarul de identificare, tipul, etc. Nivelul superior

este responsabil in evaluarea corectitudinii operatiilor dintr-un nod; asigura faptul ca doar

nodurile cu anumite proprietati verificate pot participa in mod activ in procesul de comunicatie

14

(concepte: semnaturi digitale, autoritate de certificare). Un alt strat se ocupa de un nivel de baza

in privinta pastrarii anonimitatii prin intermediul pseudonimelor (acestea pot fi schimbate pentru

a asigura un grad de privacy pentru autovehiculele participante). Nivelul de revocare este

responsabil pentru excluderea nodurilor din sistem. Ultimul nivel este responsabil cu evaluarea

datelor si detectarea intruziunilor pentru a observa comportamente anormale si a le trata in

consecinta. Deciziile de ignorare a datelor sau revocare a nodurilor sunt luate la acest nivel.

Verificarile de validitate compara informatiile primite cu valorile asteptate prin

intermediul unor euristici. Se desfasoara in principal la nivel retea si la nivel aplicatie. Este

necesara o instanta in autovehicul care colecteaza cat de multe informatii este posibil de la toate

sursele disponibile. Din datele colectate se creaza o privire independenta care ne ajuta la

evaluarea mesajelor primite in concordanta cu estimarea anterior realizata.

Fiecare algoritm de securitate poate evalua datele si atasa o valoare ce reprezinta gradul

de incredere in respectivele informatii. (valoarea semnifica cat este de probabil ca informatia sa

reflecte starea reala). Datele sunt transmise in continuarea vecinilor, fiind atasat mesajului si

gradul de incredere, astfel incat vecinii, pe baza unor euristici, sa decida ce vor face cu mesajele

primite.

Schimbarea frecventa a pseudonimelor protejeaza identitatea vehiculelor. Astfel, un

vehicul poate fi urmarit atata timp cat nu isi schimba pseudonimul (exemplu: un nod isi va

schimba pseudonimul cand se va afla intr-o situatie ce necesita privacy). Un mod de a pastra un

grad ridicat de privacy este folosirea unui set de chei anonime care se schimba frecvent in functie

de viteza masinii. Aceste chei sunt preincarcate in echipamentul electronic al masinii pentru o

durata mai mare de timp (de exemplu intre doua revizii periodice). Certificarea cheilor de un CA

(Certificate Authority) permite maparea catre adevarata identitate a vehiculelor (in cazul unui

accident).

O alta abordare de securizare a retelelor VANET este data de School of Electrical

Engineering and Computer Science, University of Central Florida,Orlando, FL, USA [45].

Solutia se bazeaza pe o arhitectura distribuita de certificate. Certificatele sunt limitate

temporal/spatial, putand fi folosite intr-o anumita arie geografica sau pe un timp determinat.

Ideea principala este urmatoarea: daca un utilizator doreste sa participe in mod activ intr-o retea

VANET, trebuie sa posede un dispozitiv de payment-processing. Fiecare dispozitiv are asociat

un identificator si un certificat. In timpul initializarii, dispozitivul va fi inregistrat alaturi de

contul utilizatorului; informatiile utilizatorului vor fi mentinute la provider si nu vor fi stocate in

dispozitiv. Cand un utilizator intra intr-o regiune si doreste sa foloseasca servicii din aria

respectiva, se foloseste de dispozitivul mai devreme mentionat. Mesajul de cerere va fi criptat

folosind cheia publica a providerului, astfel ascunzand identitatea device-ului de catre eventuali

“ascultatori”. Utilizatorului ii sunt asignate un pseudonim si alte ID-uri necesare pentru servicii

de catre provider. Serverul in cauza este de asemenea instiintat de serviciile dorite si

credentialele temporare. Utilizatorul poate obtine doar credentiale temporare, in acest caz acestea

nu vor fi trimise catre server.

15

Fig. 2.3.1 Solutia oferita de University of Central Florida,Orlando

Utilizatorii iau un certificat doar atunci cand au nevoie de un serviciu. Revocarea

certificatelor se realizeaza automat la expirarea cuantei de timp sau in momentul cand ies din

zona geografica. Pentru fiecare certificat nou, providerul verifica daca certificatul anterior a fost

revocat. In caz afirmativ, certificatul va fi emis. Sistemul propus nu necesita centralizarea CA-

urilor; de asemenea, nu este necesar un grad de incredere intre CA-urile din diferite regiuni.

Fiecare provider lucreaza independent in aria sa de acoperire.

Un alt model arhitectural de securitate este oferit de Mario Gerlay, Roberto G. Cascella,

Zhen Caoy, Bruno Crispo and Roberto Battiti de la Computer Science Department, University of

California, Los Angeles [46]. Modelul se bazeaza pe procesarea si “poluarea” fisierului original

astfel incat doar destinatarii de drept, informati de blocurile corupte, sa poata recupera informatia

utila. In procedeul codificarii la nivel retea, un fisier F este divizat in n blocuri Fi de l biti stocati

la sursa. Fiecare bloc este format din m=l/q simboli definiti ca un vector �� . Inainte de fiecare

transmisie, un nod intermediar genereaza un nou pachet, care este rezultatul unei combinatii

lineare a blocurilor disponibile local. Nodul ofera aleator n coeficienti Ci=[c1,c2,…cn] ce apartin

�� . Astfel, o combinatie lineara a blocurilor este y=� �� ∗ �� , reprezentand noua data

codificata transmisa de nodul intermediar impreuna cu vectorul de coeficienti. Cand destinatia

primeste n blocuri independent lineare codificate, fisierul original poate fi refacut.

Fig. 2.3.2 Solutia propusa de University of California, Los Angeles

Figura 2.3.2. arata o sursa care imparte un fisier in blocuri si distribuie combinatii lineare

ale blocurilor la vecini. Masinile gri reprezinta nodurile intermediare care au rolul de a codifica

16

pachetele primite inainte sa le transmita mai departe propriilor vecini reprezentati de masinile

albe. Vehiculele intermediare sunt importante pentru a mentine topologia interconectata, dar si

pentru a distribui informatia intre autovehiculele care nu sunt in raza de comunicare.

Comunicatia este limitata la un singur hop; vecinii invata noile date disponibile verificand

vectorul codificat inainte de a-l descarca. Ideea principala in aceasta abordare este de a “polua”

continutul initial astfel incat doar destinatarii autorizati sa fie capabili sa inteleaga mesajul.

Philippe Golle, Dan Greene si Jessica Staddon de la Palo Alto Research Centre au

propus, de asemenea, un model de securitate pentru retelele VANET [16]. Ei au inaintat o

abordare generala de evaluare a validitatii datelor in VANET-uri. Astfel, un nod cauta explicatii

posibile pentru datele colectate avand in vedere ca exista posibilitatea ca in retea sa fie prezente

noduri malitioase. Explicatiile care sunt consistente cu modelul de VANET pe care il detine

nodul sunt notate cu un grad de incredere, astfel incat nodul primeste informatii de la cei mai de

incredere vecini. O componenta esentiala in acest model este faptul ca fiecare nod pastreaza o

“topologie” a VANET-ului ce contine toate datele pe care nodul le are despre retea. Astfel, in

momentul in care primeste informatii, verifica daca acestea sunt in concordanta cu baza sa de

cunostinte actuale. Daca datele sunt conforme cu modelul sau (cu o mare probabiliate), nodul

accepta datele si confirma validitatea acestora.

Maxim Raya, Adel Aziz and Jean-Pierre Hubaux de la Laboratory for Computer

Communications and Applications (LCA), School of Computer and Communication Sciences,

EPFL, Elvetia propun o solutie bazata pe agregarea mesajelor si comunicarea in grup [32].

Algoritmii prezentati se concentreaza asupra ideii ca informatiile se transmit intre grupuri mai

degraba decat intre vehicule individuale. Altfel spus, vehiculele sunt aranjate in grupuri. In

fiecare grup, unul sau mai multe autovehicule, alese pe baza pozitionarii lor, vor transmite datele

agregate vecinilor (care sunt tot grupuri). Un criteriu definitoriu in formarea grupurilor este

pozitionarea geografica. Astfel, considerand informatiile de la sistemul GPS si impartirea ariei in

celule, un vehicul poate determina carui grup ii apartine la un moment dat (impartirea ariei in

celule este predeterminata anterior). Pentru ca informatia sa fie generata si propagata de grup mai

degraba decat de entitati individuale, toate vehiculele care apartin unui grup ar trebui sa aiba o

privire comuna asupra mediului. Fiecare vehicul proceseaza local toate evenimentele, atat cele

direct observate cat si cele raportate de alte vehicule, inainte de a lua o decizie referitoare la

respectivul eveniment. In fiecare grup exista unul sau mai multi lideri care se ocupa cu distributia

mesajelor. O modalitate de a verifica datele primite este comparatia cu alte informatii

receptionate din alte surse despre respectivul eveniment. Altfel, pentru a testa validitatea

mesajelor, precum si sursa, este necesar ca pe parcursul rutarii mesajului, nodurile intermediare

sa semneze peste semnatura transmitatorului precedent. O semnatura invalida la orice moment de

timp va invalida mesajul ce ajunge la receptorul final.

Fig 2.3.3 Formatul si continutul mesajului de cerere dinamica de cheie

17

Capitolul 3 - Protocolul de asigurare a securitatii in medii VANET

3.1 Caracteristici generale

Protocolul de securitate este proiectat si implementat pentru retele vehiculare ad-hoc, cu

proprietatea ca masinile existente pot comunica intre ele, precum si cu infrastructura existenta. El

are in vedere asigurarea securizarii transmiterii mesajelor intre entitatile masini aflate in trafic.

Solutia este conceputa pentru medii puternic partitionate, suferind de o mare dinamicitate de

conectare a nodurilor in cadrul retelei.

Componentele principale avute in vedere in proiectarea protocolului sunt entitatea

Autovehicul ( SecCar) si entitatea Semafor (SecCittyTrafficLight). Transmiterea de mesaje

securizate intre masinile aflate in trafic se face in functie de existenta unei entitati de certificare

prezente in zona (un semafor sau access point securizat), de distanta dintre autovehiculele care

vor sa comunice, de traiectoria pe care acestea se deplaseaza, de faptul ca autovehiculul

destinatie este in raza de transmisie sau de necesitatea selectarii unei rute ce include mai multe

hopuri in vederea transmiterii mesajelor.

Comunicatia dintre vehicule intr-o retea caracterizata de un grad ridicat de dinamism,

pozitionare geografica, conectivitate sporadica intre automobile ridica probleme de securitate

unice. Protocolul implementat urmareste sa rezolve aceste chestiuni, acoperind urmatoarele

aspecte generale privitoare la securitate:

� Autentificare

� Confidentialitate

� Integritate

� Disponibilitate

� Non-repudiere

Entitatea Masina este considerata o entitate mobila, care schimba mesaje cu alte masini,

dar si cu infrastructura existenta (respectiv semafoarele securizate din intersectii). Scopul

protocolului este de a oferi o solutie de securizare a mesajelor dintre masini, astfel incat entitatea

destinatie sa poata verifica validitatea mesajelor primite. Semafoarele securizate (parte a

infrastructurii) au rolul unor entitati de certificare care ajuta la probarea autenticitatii mesajelor.

Autoritatile de certificare se vor cunoste una pe cealalta, putand comunica in cazul in care se

doreste validarea anumitor date.

Principalele aspecte pe care se bazeaza solu

momentul transmiterii mesajelor, momentul de timp la car

certificare existente in zona in momentul inceperii transmisiei.

Protocolului este modular, scalabil, fiind structurat

observa in figura de mai jos.

Fig 3.1.1 Protocol de securitate in medii VANET

18

Principalele aspecte pe care se bazeaza solutia expusa sunt pozitia vehicu

momentul transmiterii mesajelor, momentul de timp la care se petrece emisia, autoritati

certificare existente in zona in momentul inceperii transmisiei.

Protocolului este modular, scalabil, fiind structurat pe mai multe stari, asa cum se poate

Protocol de securitate in medii VANET

tia expusa sunt pozitia vehiculului in

e se petrece emisia, autoritatile de

pe mai multe stari, asa cum se poate

3.2 Starile protocolului

Protocolul este structurat pe mai multe stari.

desfasura doar in momentul in

proximitatea (aria de acoperire) a unui semafor. Raza de transmisie a unei masini este mai mica

decat raza de transmisie a semafo

Fig 3.2.1 Semnarea unui mesaj de catre un semafor securizat

In momentul in care un autovehicul doreste sa transmita informatii unui alt autovehicul,

prima data va astepta beaconul din partea semaforului in a carei arii de acoperire se afla.

Beaconul este transmis periodic de catre semafor tuturor masinilor din zo

acoperire sub forma unui mesaj de difuzare (

autovehiculul va transmite semaforului un pachet de date continand informatii ce trebuiesc

semnate de acesta.

Luand in considerare mobilitatea specifica

transmitere pe care o are o masina, transmiterea mesajului pentru a fi semnat de catre semafor

poate fi realizata in doua moduri:

19

Protocolul este structurat pe mai multe stari. Comunicatia masina

desfasura doar in momentul in care automobilul ce are de transmis un mesaj se afla in

aria de acoperire) a unui semafor. Raza de transmisie a unei masini este mai mica

decat raza de transmisie a semaforului securizat.

Semnarea unui mesaj de catre un semafor securizat



Beaconul este transmis periodic de catre semafor tuturor masinilor din zo

forma unui mesaj de difuzare (broadcast). In momentul receptionarii beaconului,


Luand in considerare mobilitatea specifica in retelele VANET si aria restransa de


poate fi realizata in doua moduri:

Comunicatia masina – masina se va

are de transmis un mesaj se afla in

aria de acoperire) a unui semafor. Raza de transmisie a unei masini este mai mica

Semnarea unui mesaj de catre un semafor securizat



Beaconul este transmis periodic de catre semafor tuturor masinilor din zona sa de

broadcast). In momentul receptionarii beaconului,


in retelele VANET si aria restransa de


� daca semaforul se afla in aria de acoperire a masinii, mesajul va fi transmis direct

semaforului pentru semnare

� daca semaforul nu se afla in aria de acoperire a masinii, mesajul va fi rutat, hop

prin intermediul unor masini intermediare pana ajunge la semaforul care a emis beaconul.

Informatiile importante continute in pachet su

care se transmite mesajul, locatia curenta si mesajul efectiv. Toate aceste informatii vor fi

semnate de catre semaforul ce a emis beaconul.

In momentul in care masina primeste inapoi de la semafor mesajul impreuna

semnatura aferenta, va transmite acest mesaj la destinatie.

Daca beaconul periodic emis de semaforul securizat este transmis sub forma de

broadcast, mesajul semnat ce urmeaza a fi expediat inapoi masinii este trimis sub forma de

unicast, intrucat masina se afla in raza de acoperire a semaforului.

Transmisia mesajului catre masina destinatie poate fi realizata in doua moduri:

� masina destinatie se afla in aria de acoperire a masinii emitente sursa, astfel mesajul este

rutat direct

� masina destinatie nu se afla in aria de acoperire a masinii emitente sursa, astfel mesajul

este rutat cu ajutorul masinilor intermediare existente catre destinatia finala

Fig 3

In momentul in care mesajul ajunge la destinatie, masina destinatie trebuie sa valideze

respectivul mesaj inainte de a-l prelucra. Modalitatea prin care se poate verifica un mesaj la

destinatie este trimiterea acestuia la un semafor din imediata proximitat

comunica intre ele astfel incat pot verifica semnatura din cadrul mesajului. Trimiterea mesajului

catre semaforul din proximitate se poate face direct, in cazul in care acesta este in raza de actiune

20

daca semaforul se afla in aria de acoperire a masinii, mesajul va fi transmis direct

semaforului pentru semnare

daca semaforul nu se afla in aria de acoperire a masinii, mesajul va fi rutat, hop


Informatiile importante continute in pachet sunt amprenta de timp pentru momentul in


semnate de catre semaforul ce a emis beaconul.

In momentul in care masina primeste inapoi de la semafor mesajul impreuna

semnatura aferenta, va transmite acest mesaj la destinatie.



masina se afla in raza de acoperire a semaforului.


masina destinatie se afla in aria de acoperire a masinii emitente sursa, astfel mesajul este

ie nu se afla in aria de acoperire a masinii emitente sursa, astfel mesajul


Fig 3.2.2 Comunicatie masina – masina


l prelucra. Modalitatea prin care se poate verifica un mesaj la

destinatie este trimiterea acestuia la un semafor din imediata proximitate. Semafoarele pot



daca semaforul se afla in aria de acoperire a masinii, mesajul va fi transmis direct

daca semaforul nu se afla in aria de acoperire a masinii, mesajul va fi rutat, hop-by-hop,


nt amprenta de timp pentru momentul in


In momentul in care masina primeste inapoi de la semafor mesajul impreuna cu




masina destinatie se afla in aria de acoperire a masinii emitente sursa, astfel mesajul este

ie nu se afla in aria de acoperire a masinii emitente sursa, astfel mesajul



l prelucra. Modalitatea prin care se poate verifica un mesaj la

e. Semafoarele pot



(transmisie) a masinii sau rutat prin

se afla in raza de actiune.

Validarea datelor se poate face doar la semafor, acesta verificand semnatura mesajului si

campurile aferente din care a fost constituita semnatura. Rezultatul verifi

masinii care a cerut validarea. In cazul in care raspunsul este afirmativ, mesajul poate fi prelucrat

in continuare; altfel, acesta este discardat.

Fig 3.2.3 Verificare unui mesaj de catre un secmafor securizat

Locatia este un camp foarte important care certifica faptul ca transmitatorul mesajului se

afla intr-o anumita regiune geografica. Atacuri des intalnite sunt bazate pe faptul ca utilizatorii

sunt tentati sa minta asupra locatiei geografice in care se afla

informatii. Amprenta privind pozitia (longitudine, latitudine) cere utilizatorilor din retea sa

probeze amplasamentul. Cel mai simplu si mai sigur mod de a verifica aspectul ce priveste

locatia este infrastructura existenta

(semafoarele securizate); astfel, in momentul in care un automobil primeste un mesaj, tot prin

intermediul infrastructurii, poate decide daca accepta sau nu mesajul avand drept criteriu locatia.

La nivel inalt, locatia este o metadata emisa de o componenta a infrastructurii wireless

(semafor securizat) pentru un dispozitiv mobil. Pentru a folosi amprenta de pozitionare, o

aplicatie trebuie sa aiba incredere in infrastructura in vederea validarii p

Pentru orice tip de comunicatie, masinile cer infrastructurii sa le semneze mesajele. Rolul

infrastructurii este doar de a semna si valida mesajele automobilelor din raza de transmisie. Se

poate deduce o flexibilitate crescuta a ace

semafoarele securizate pot fi folosite intr

In privinta performantelor protocolului, se observa o validare foarte riguroasa, atat la

sursa, cat si la destinatie pentru fiecare m

21

(transmisie) a masinii sau rutat prin mai multe hopuri (masini intermediarea), in cazul in care nu


campurile aferente din care a fost constituita semnatura. Rezultatul verificarilor va fi transmis


in continuare; altfel, acesta este discardat.

Verificare unui mesaj de catre un secmafor securizat


o anumita regiune geografica. Atacuri des intalnite sunt bazate pe faptul ca utilizatorii

sunt tentati sa minta asupra locatiei geografice in care se afla in momentul in care transmit

informatii. Amprenta privind pozitia (longitudine, latitudine) cere utilizatorilor din retea sa


locatia este infrastructura existenta. Masinile cer o validare a locatiei de la infrastructura





aplicatie trebuie sa aiba incredere in infrastructura in vederea validarii pozitionarii geografice



poate deduce o flexibilitate crescuta a acestei abordari, intrucat mesajele astfel semnate de

semafoarele securizate pot fi folosite intr-o multitudine de servicii.


sursa, cat si la destinatie pentru fiecare mesaj.

mai multe hopuri (masini intermediarea), in cazul in care nu


carilor va fi transmis


Verificare unui mesaj de catre un secmafor securizat


o anumita regiune geografica. Atacuri des intalnite sunt bazate pe faptul ca utilizatorii

in momentul in care transmit

informatii. Amprenta privind pozitia (longitudine, latitudine) cere utilizatorilor din retea sa-si


. Masinile cer o validare a locatiei de la infrastructura





itionarii geografice.



stei abordari, intrucat mesajele astfel semnate de


22

3.3 Entitati participante in protocol

Entitatile principale participante in protocol sunt :

� Entitatea Masina Securizata ( SecCar)

� Entitatea Semafor Securizat ( SecCittyTrafficLight)

Entitatea Masina este entitatea mobila din protocol. Rolul acesteia este de a comunica cu

restul de masini aflate in trafic, precum si cu infrastructura rutiera (semafoare). Pentru a reusi o

comunicatie sigura masina-masina, automobilul emitator comunica cu alte masini si cu

semafoarele din apropiere.

Pe parcursul comunicatiei masina-masina, emitatorul poate trece prin mai multe stari, ca

urmare a derularii mai multor evenimente asincrone.

In momentul in care masina apare la inceput in trafic, ea se afla intr-o stare LIBERA.

Masina nu a primit mesaje de la alti participanti la trafic si nu a transmis nici un mesaj.

In momentul in care se afla in proximitatea unui semafor securizat, masina va primi de la

acesta un beacon de recunoastere prin care semaforul isi face publica prezenta celorlalti

participanti in trafic. Astfel, masina va trece intr-o noua stare, BEACON_RECEPTIONAT.

In momentul in care entitatea autovehicul doreste sa comunice cu alte automobile

prezente in trafic trebuie sa trimita mesajul dorit la semnat la semaforul din proximitatea sa.

Poate face acest lucru direct sau prin intermediul altor masini. Astfel, se poate observa ca masina

poate trece intr-o stare MASINA_INTERMEDIARA ce ruteaza pachetele pentru alte masini, sau

in starea START_COMUNICATIE, in momentul in care a primit inapoi de la semaforul

securizat mesajul semnat. Starea de MASINA_INTERMEDIARA este indusa de fiecare data

cand o masina ruteaza pachete pentru alte masini participante in trafic.

In momentul in care o masina primeste un mesaj de la o alta masina, masina trece in

starea de MASINA_RECEPTIONAT_MESAJ. Un mesaj va fi validat de masina destinatie dupa

ce va primi raspunsul de la semafor. Trimiterea mesajului spre validare catre semafor poate fi

facuta direct, in cazul in care semaforul este in aria de acoperire a masinii, sau rutata prin

intermediul altor masini, in cazul in care semaforul nu este in zona de emisie a masinii. Se poate

observa din nou ca masinile pot trece in starea de MASINA_INTERMEDIARA. In momentul in

care se primeste raspunsul de verificare a mesajului de la semaforul securizat, masina va trece in

starea MASINA_RECEPTIONAT_VALIDARE_SEMAFOR.

Diagrama de transitii prin care poate trece o masina este prezentata mai jos:

Fig 3.3.1

Entitatea Semafor Securizat este entitatea fixa in cadrul protocolului. Rolul acesteia este

de a semna mesajele transmise de automobilele din retea si de a verifica validitatea mesajelor

atunci cand se cere acest lucru.

Semafoarele securizate din retea transmit din secund

toata aria lor de acoperire. Aceasta este starea de fapt a semaforului, EMIS_BEACON. In

momentul in care o masina cere validarea unui mesaj, semaforul va trece in alta stare,

VERIFICARE_MESAJ. Starea EMIS_BEACON si stare

23


.3.1 Stari specifice Masinii Securizate

Securizat este entitatea fixa in cadrul protocolului. Rolul acesteia este


Semafoarele securizate din retea transmit din secunda in secunda beaconuri periodice in



VERIFICARE_MESAJ. Starea EMIS_BEACON si starea VERIFICARE_MESAJ nu se exclud,


Securizat este entitatea fixa in cadrul protocolului. Rolul acesteia este


a in secunda beaconuri periodice in



a VERIFICARE_MESAJ nu se exclud,

dimpotriva, emiterea beaconurilor se face independent de faptul ca un mesaj a ajuns la semafor

pentru verificare.

In momentul in care semaforul se afla in starea VERIFICARE_MESAJ, el trebuie sa

verifice daca mesajul nu a fost corupt pe parcurs. Pentru aceasta va verifica campurile: mesaj,

amprenta de timp, longitudine, latitudine cu semnatura atasata mesajului. Cum exista

posibilitatea ca mesajul sa nu fi fost semnat de acest semafor, el trebuie sa comunice cu restul

semafoarelor din retea pentru a verifica validitatea mesajului.

In vederea crearii semna

cheie privata). Mesajul este semnat cu chei

publica. Perechea (cheie publica,

transmisa niciodata in timpul comunicatiei.

Diagrama de tranzitii prin care poate trece semaforul securi

Fig 3.3.2

24



fost corupt pe parcurs. Pentru aceasta va verifica campurile: mesaj,



foarelor din retea pentru a verifica validitatea mesajului.

aturii digitale, fiecare semafor poseda o pereche

. Mesajul este semnat cu cheia privata, verificarea semnaturii utilizand cheia

a,cheia privata) este specifica fiecarui semafor in parte, nefiind

transmisa niciodata in timpul comunicatiei.

de tranzitii prin care poate trece semaforul securizat este prezentata mai jos.:

.3.2 Stari specifice Semaforului Securizat



fost corupt pe parcurs. Pentru aceasta va verifica campurile: mesaj,



turii digitale, fiecare semafor poseda o pereche (cheie publica,

a privata, verificarea semnaturii utilizand cheia

este specifica fiecarui semafor in parte, nefiind

zat este prezentata mai jos.:

25

3.4 Mesajele existente in protocol

Formatul mesajului din protocolul de securitate propus este urmatorul:

Tip

protocol

Tip

mesaj

Sursa Dest. Timp Nr.

hops

Mesaj Long Lat Mesg

Signtr

Pub

Key

Resp. Res.

Sign

Tipurile de mesaje folosite in protocol sunt:

� BEACON

� CERERE_SEMNATURA_MESAJ

� MESAJ_SEMNAT

� MESAJ_EXPEDIAT

� CERERE_VALIDARE_MESAJ

� RASPUNS_MESAJ_VERIFICAT

Mesajele, indiferent de tipul acestora, contin campul numar de hopuri care impiedica

rutarea continua a mesajului. De asemenea, este tinut un contor intern care calculeaza timeout-ul

pentru mesajele care necesita acest lucru. Mecanismele de timeout si numar maxim de hopuri

posibile sunt necesare pentru a preveni fenomenul de buclare la infinit a mesajelor.

In implementarea protocolului, masinile contin cozi de mesaje care ajuta la o transmisie

cat mai sigura, iar in cazul in care acest lucru nu este posibil, la retransmisia mesajelor care nu au

ajuns la destinatie.Cozile de mesaje sunt necesare datorita proprietatii de dinamicitate specifica

retelelor VANET. De exemplu, semnarea mesajelor se face la semaforul din imediata

proximitate, dar in momentul in care masinile merg cu o viteza mare sau isi schimba ruta,

mesajul semnat nu va mai putea ajunge inapoi la masina care l-a emis intrucat aceasta a iesit din

raza de actiune. Totusi, mesajul se doreste a fi transmis, astfel incat va fi stocat intr-o coada de

mesaje, incercand ulterior sa-l expediem, atunci cand suntem in raza de acoperire a altui semafor

securizat.

Rutarea mesajului catre destinatie se poate face in doua moduri:

� direct, in cazul in care destinatia se afla in aria de acoperire a sursei

� prin intermediul unor masini intermediare, in cazul in care destinatia nu se afla in aria de

acoperire a sursei

Mesajele emise in cadrul protocolului sunt de tip unicast si de tip broadcast. Nu se pot

folosi doar mesaje de tip unicast, intrucat raza de acoperire a entitatilor prezente in protocol

poate fi uneori insuficienta, astfel incat mesajul nu poate ajunge printr-un singur hop la

destinatie.

26

3.5 Securitatea mesajelor – Semnaturi digitale

Criptografia cu cheie publica isi aduce o contribuite importanta in semnaturile digitale cu

chei publice. Fiecare semafor securizat din infrastructura are doua chei: o cheie publica, vizibila

tuturor, si o cheie privata, cu care semaforul semneaza mesajele. Algoritmii cu chei publice au

proprietatea ca sunt folosite diferite chei pentru criptare si decriptare si, de asemenea, cheia de

decriptare nu poate fi derivata din cheia de criptare.

Algoritmul DSA este standardul de facto utilizat de Agentia Federala a Statelor Unite

pentru semnaturi digitale. Propus de NIST (National Institute od Standards and Technology) in

august 1991, a fost adoptat si a devenit oficial in 1993. Standardul a mai cunoscut modificari in

anii 1996, 2000, ultima data fiind modificat in 2009.

Generarea cheilor are doua faze. Prima faza a algoritmului constituie in alegerea

parametrilor:

� se alege o functie de hash H. Outputul aplicarii functiei de hash poate fi trunchiat la

dimensiunea aleasa a perechilor de chei.

� se alege lungimea cheii L si N.

� se alege un numar prim q de N biti. N trebuie sa fie mai mic sau egal cu lungimea

rezultatului aplicarii functiei de hash.

� se alege un numar prim de L biti mod p astfel incat p-1 sa fie multiplu de q

� se alege g, un numar a carui ordin multiplicativ modulo p este q. Acesta este setat alegand

g=h(p-1)/q

mod p pentru un h arbitrar (1<h<p-1) ( se verifica din nou daca rezultatul este

egal cu 1). De obicei h=2.

A doua faza a algoritmului calculeaza cheia publica si cheiea privata pentru un utilizator

specific:

� se alege un numar aleator x cu proprietatea 0<x<q.

� se calculeaza y = gx

mod p

� cheia publica este (p, q, g, y).

� cheia privata este x.

27

Semnarea mesajului consta in urmatoarele:

� consider H functia de hash si m mesajul

� generez o valoare aleatoare K pentru fiecare mesaj 0<k<q

� calculez r = ( gk mod p) mod q

� calculez s= ( K -1

( H(m) +x*r)) mod q

� recalculez semnatura in cazul in care r=0 si s=0

� semnatura este (r,s)

Verificarea consta in urmatorii pasi:

� neacceptarea semnaturii in cazul in care cel putin una din conditiile 0<r<q sau 0<s<q nu

este satisfacuta

� calculez w= (s)-1

mod q

� calculez u1= (H(m)*

w) mod q

� calculez u2= (r* w) mod q

� calculez v= ((gu1

*yu2

) mod p) mod q

� semnatura este valida daca v=r.

Demonstratia de corectitudine a algoritmului se poate face dupa cum urmeaza: prima

data, daca g = h(p-1)/q

mod p atunci rezulta ca gq

≡h(p-1)

≡ 1 (mod p) conform Micii Teoreme a lui

Fermat. Cum g>1 si q este prim, g are acelasi ordin cu ordinul lui q.

Se calculeaza

28

Astfel

Cum g are acelasi ordin cu q avem ca

In final, corectitudinea algoritmului DSA rezulta dupa cum urmeaza

Capitolul 4 – Implementare pilot in simulatorul VNSIM

Implementarea protocolului este realizata

extinderea simulatorului VNSim

contributiile avute in cadrul lucrarii.

4.1 Simulatorul VNSim

Simulatorul de trafic VNSIM este un proiect dezvoltat in cadrul Universitatii Politehnica

din Bucuresti, fiind destinat aplicatiilor concentrate pe VANET (Vehicular Ad

Simulatorul este implementat in Java, avand la baza lucrul cu evenimente

dintre soferii din trafic, precum si schimbul de informatii dintre masinile ce poseda echipament

GPS sau intre dispozitivele capabile de comunicatie wireless sunt bazate pe urmatoarele clase

principale de evenimente: SEND, RECEIVE si

29

Implementare pilot in simulatorul VNSIM

Implementarea protocolului este realizata folosind limbajul de programare Java

extinderea simulatorului VNSim. In cadrul capitolului se prezinta detalii privind extensiile si

contributiile avute in cadrul lucrarii.


din Bucuresti, fiind destinat aplicatiilor concentrate pe VANET (Vehicular Ad

Simulatorul este implementat in Java, avand la baza lucrul cu evenimente discrete. Colaborarea



principale de evenimente: SEND, RECEIVE si GPS.

Fig 4.1.1 Arhitectura VNSIM

folosind limbajul de programare Java, prin

In cadrul capitolului se prezinta detalii privind extensiile si


din Bucuresti, fiind destinat aplicatiilor concentrate pe VANET (Vehicular Ad-Hoc Network).

discrete. Colaborarea



30

Lucrul cu evenimente discrete impune un timp al simularii care avanseaza regulat cu un

interval fix, avansare ce se manifesta o data cu executia a tot ceea ce este specific pentru

momentul de timp curent. In fiecare moment de timp din simulare, evenimentele sunt extrase din

coada si procesate de simulator. Evenimentul de tip SEND apeleaza metoda responsabila pentru

pregatirea unui mesaj si planifica evenimentul RECEIVE corespunzator destinatarului (sau

destinatarilor, in cazul unei difuzari). Astfel, evenimentul RECEIVE este asociat unuia sau mai

multor noduri din retea. Prin procedura de primire mesaj se va trata evenimentul corespunzator

in nodurile destinatie. Evenimentul GPS este declansat periodic pentru fiecare nod, cu scopul de

a simula date GPS primite din lumea reala.

VNSIM este un simulator dezvoltat la nivel microscopic ,utilizat in studierea retelelor de

vehicule, luand in considerare actiunile fiecarui masini, spre deosebire de un simulator

macroscopic, practic in cazul intelegerii dinamicii traficului si implementarii de infrastructura

rutiera.

4.1.1 Modulul de mobilitate

Modulul de mobilitate se ocupa de miscarea autovehiculelor pe traiectorii realistice.

Actualizeaza periodic pozitia fiecarui automobil conform modelului de miscare.

Principala componenta a simulatorului VNSIM este masina si mobilitatea acesteia,

implementare realizata in functia move() din obiectul CarInstance. Aceasta metoda calculeaza

noua pozitie pentru fiecare masina simuland miscarea in timpul unui frame. La fiecare frame,

aceasta metoda (move() ) este apelata de catre motorul simulatorului pentru fiecare autovehicul.

Modul in care o masina se misca depinde de sistemele de control a traficului, de restul

participantilor la trafic si de personalitatea soferului. Masinile iau decizii in concordanta cu

anumite conditii de trafic, cum ar fi prezenta lor intr-o intersectie. De asemenea, deplasarea

masinii este influentata de masinile adiacente.

Simulatorul VNSIM tine cont de atitudinea conducatorilor in timpul sofatului,

implementand patru modele comportamentale in trafic: approaching, following, free driving si

breaking.

Tipurile de personalitate pe care le pot avea soferii in trafic sunt: calm, regular si

aggressive.

Modelul “approaching” este caracterizat de prezenta in fata soferului a unui autovehicul

mai lent. In acest caz, atitudinea conducatorului auto este de a-si inceti viteza pana cand va avea

aceeasi viteza cu a masinii mai lente. Procesul de franare depinde de mai multi factori, printre

care enumar viteza de rulare, distanta dintre automobile etc.

31

Modelul “following” are la baza ipoteza ca atat conducatorul curent cat si automobilul

din fata ruleaza cu o viteza aproximativ egala, conducatorul curent mentinandu-si in continuare

viteza de drum constanta.

Modelul free driving nu impune restrictii conducatorului auto. Astfel, acesta nu este

influentat de masinile din fata lui, aflate pe aceeasi banda de circulatie. Soferul va incerca sa

obtina sau sa mentina viteza de rulare dorita, fiind influentat de temperamentul sau si conditiile

drumului.

Modelul breaking implica existenta foarte apropiata a unui vehicul in fata conducatorului

curent. Masura care se impune este de franare cat mai accentuata.

Stilurile comportamentale ale soferului implica si felul in care acesta va schimba benzile

de mers. De fiecare data cand soferul auto este in alt mod in afara de cel de free driving, va testa

daca trecerea pe o banda superioara ii va oferi o modalitate mai buna de condus. In caz afirmativ,

va schimba benzile. In modul breaking, se va testa daca trecerea pe o banda inferioara va oferi

cel putin aceleasi conditii de trafic; in caz afirmativ, se va schimba banda. Ordinea verificarilor

impune ca prim test acela ce verifica banda superioara. Astfel, daca soferul curent se apropie de

un vehicul mai lent, va verifica daca banda superioara (in cazul in care aceasta exista) este libera

(si ca nu exista alte automobile in spatele sau care circula aproape de el pe banda pe care

conducatorul doreste sa se mute). In caz afirmativ, se va deplasa pe aceasta banda.

4.1.2 Modelul de comunicatie

Motorul simulatorului (clasa Engine) are in vedere toate nodurile din retea si se ocupa de

livrarea mesajelor intre aceste noduri. Simulatorul ruleaza pe un singur thread, fiind un simulator

discret bazat pe evenimente. Nodurile sunt modelate de clasa SimulatedCarInfo care contine

doua metode importante: “onReceive” si “prepareMessage”. Metoda “onReceive” este apelata in

momentul in care un nod primeste un mesaj, iar metoda “prepareMessage” este apelata de

Engine in momentul in care nodul intentioneaza sa trimita mesaje. Mesajele, la acest nivel, sunt

vazute ca simple insiruiri de biti.

VITP – Vehicular Information Transfer Protocol

VITP este un protocol de comunicatie de nivel aplicatie, care specifica sintaxa si

semantica mesajelor dintre nodurille VITP. Este o infrastructura ad-hoc distribuita peste reteaua

VANET, cu scopul de a oferi servicii participantilor la trafic pe baza locatiei automobilului.

Informatiile despre pozitia curenta a vehiculelor vin de la sistemul de navigatie GPS si de la

senzorii automobilului.

32

Exista doua tipuri de mesaje VITP: GET si POST. Fiecare mesaj VITP are o sursa si o

destinatie, specificate din punct de vedere geografic.

Mesajul POST este difuzat periodic de catre masinile din regiune cu scopul de informare

asupra conditiilor de drum din acea zona.

Mesajul GET are scopul de a afla o informatie specifica despre o anumita zona destinatie.

O data solutionata cererea, pachetul se va intoarce la automobilul care l-a generat.

DSRC- Dedicated Short-Range Communications Protocol

DSRC este un protocol wireless pe mai multe canale, in faza de dezvoltare. Protocolul in

discutie se bazeaza pe nivelul fizic IEEE 802.11a si pe nivelul MAC legatura de date IEEE

802.11. Este operational intr-un spectru licentiat de peste 75 MHz in banda de 5.9 GHz alocata

de catre FCC pentru suportul comunicatiei inter-vehicule si vehicule-infrastructura de mica

latenta.

Stiva DSRC este implementata in clasa CarRunningDSRC, care extinde clasa

CarRunningVITP.

Nivelul fizic comunica cu rutina de trimitere pachete care ia pachetul, creeaza un nou

eveniment de trimitere SendEvent si il adauga in coada de evenimente. De asemenea, mai

comunica cu rutina de primire pachete, primeste pachetul prin evenimentul ReceiveEvent din

coada de evenimente si trimite mesajul la nivelul fizic.

4.2. Detalii de implementare

In cadrul implementarii propuse exista doua tipuri de entitati: entitatea SecCar (masina

securizata) si entitatea SecCittyTrafficLight (semafor securizat). Cele doua tipuri de entitati sunt

noduri in reteaua mobila ad-hoc: masinile securizate sunt noduri mobile, caracterizate de un

puternic dinamism, iar semafoarele securizate sunt noduri fixe, parte din infrastructura rutiera.

Fig 4.2.1

In continuare sunt prezentate detalii de implementare referitoare la clasele care au fost

adaugate sau au fost extinse in simulatorul VNSim pentru a proiecta protocolul de securitate.

33

4.2. Detalii de implementare



hoc: masinile securizate sunt noduri mobile, caracterizate de un


.1 Diagrama de pachete necesare protocolui de securitate





hoc: masinile securizate sunt noduri mobile, caracterizate de un


Diagrama de pachete necesare protocolui de securitate



34

4.3 Clasa SecCar

Clasa SecCar este clasa ce implementeaza o masina securizata in cadrul protocolului.

Clasa extinde CarRunningDSRC, care la randul ei extinde CarRunningVITP, clasa parinte (de

baza) fiind CarInfo. Pe langa metodele mostenite, clasa implementeaza metode noi sau

suprascrie metode ale claselor parinte. In afara de variabilele mostenite, clasa SecCar adauga noi

variabile care sunt folosite in implementarea protocolului de securitate propus.

Am optat pentru extinderea clasei CarRunning DSRC tinand cont de posibilitatile oferite

de tehnologia wireless Dedicated Short-Range Communications.

DSRC este un protocol multi-channel de comunicatie special conceput pentru a suporta

comunicatie vehicul – vehicul si vehicul – infrastructura. Principalul focus pentru DSRC este

suportul pentru aplicatii critice destinate sigurantei care reduc numarul de accidente rutiere si

imbunatatesc fluxul circulatiei automobilelor.

DSRC este similar standardului 802.11a, dar are anumite particularitati specifice:

� operararea in banda de frecventa - DSRC opereaza in spectrul de 75 MHz cu o banda

dedicata de 5.9 GHZ

� mediul de lucru - DSRC este proiectat sa functioneze in medii exterioare caracterizate de

un grad crescut de dinamism

� nivelul MAC – banda DSRC este divizata in 7 canale, cu posibilitatea de prioritizare a

traficului destinat sigurantei

� nivelul fizic – latimea de banda specifica unui canal DSRC este de 10 MHz

Pe langa atributele mostenite de la CarRunning DSRC, SecCar are o serie de atribute

particulare care individualizeaza protocolul de securitate:

� mesajul newMessage este folosit in comunicatia masina – masina, dar si in comunicatia

masina - semafor (este un mesaj particular, specific protocolului). Acesta va fi detaliat

intr-o sectiune ulterioara a lucrarii

� atributul sem_aproape indica cel mai apropiat semafor securizat care emite beaconuri

periodice

� atributul car_to_com indica o masina generata aleator careia autombilul curent ii va

comunica un mesaj

� atributul state codifica starea curenta in care se afla masina. Cum protocolul este unul

bazat pe stari, masina va executa diferite tranzitii, in functie de evenimentele (mesajele)

primite. Pentru o mai clara intelegere a etapelor prin care trece masina, aceasta a fost

reprezentata diferit in mod grafic pe harta

� flagurile flag_invite, flag_comun, flag_send_mes sunt indicatori interni specifici masinii

securizate pentru a marca diverse momente in evolutia protocolului de securitate.

� atributul waitingMessages reprezinta o coada de mesaje care, daca este necesar, vor fi

retransmise destinatiei

� atributul semPubKey reprezinta cheia publica a semaforului care a emis un beacon. In

momentul in care o masina intra in raza de actiune a unui semafor securizat, aceasta va

primi periodic beaconuri de la

� atributul relCarTime – hashtable care contine maparea intre masinile care au trimis

mesaje masinii curente si momentul de timp in care acestea au fost primite

� atributul confirmedMessages reprezinta coada de mesaje care au nevoie de confirmare

finala de la semafor inainte de a fi procesate de destinatie

Fig 4.3.1 Diagrama de clasa pentru Masina Securizata SecCar

35


reprezentata diferit in mod grafic pe harta digitala din simulator.

flag_comun, flag_send_mes sunt indicatori interni specifici masinii


atributul waitingMessages reprezinta o coada de mesaje care, daca este necesar, vor fi

atributul semPubKey reprezinta cheia publica a semaforului care a emis un beacon. In


primi periodic beaconuri de la semafor continand, printre altele, si cheia l

hashtable care contine maparea intre masinile care au trimis


atributul confirmedMessages reprezinta coada de mesaje care au nevoie de confirmare

finala de la semafor inainte de a fi procesate de destinatie

Diagrama de clasa pentru Masina Securizata SecCar


flag_comun, flag_send_mes sunt indicatori interni specifici masinii


atributul waitingMessages reprezinta o coada de mesaje care, daca este necesar, vor fi

atributul semPubKey reprezinta cheia publica a semaforului care a emis un beacon. In


lui publica.

hashtable care contine maparea intre masinile care au trimis


atributul confirmedMessages reprezinta coada de mesaje care au nevoie de confirmarea

Diagrama de clasa pentru Masina Securizata SecCar

36

Constructorul clasei SecCar suprascrie constructorul clasei CarRunningDSRC, marcand

suplimentar faptul ca masina este in starea libera (tocmai a fost introdusa pe harta).

Metoda init() suprascrie metoda parinte din clasa SimulatedCarInfo, la care adauga

functionalitati suplimentare. Astfel, in metoda init() se marcheaza faptul ca automobilul curent

va dori sa comunice securizat cu un alt autombilul dupa o perioada “timp”. Semnalizarea este

simulata sub forma unui tip de eveniment unicast ce va fi transmis vehiculului curent dupa

timpul “timp”.

Metoda “onReceive” marcheaza faptul ca obiectul SecCar a receptionat un eveniment de

la mediu. In cazul in care mesajul este nul, procesarea se opreste. Altfel, se verifica antetul

mesajului. Daca tipul de protocol inscriptionat in antet este PROT_SEC_PKI sau

PROT_SEC_CAR, mesajul este procesat. In cazul implicit, este apelata metoda default de

procesare a mesajului specifica claselor parinte.

Tipurile de evenimente specifice aplicatiei sunt Send, Receive si GPS. Un eveniment de

tip Send declanseaza metoda prepareMessage(int messageType) responsabila pentru pregatirea

unui mesaj. Metoda prepareMessage serializeaza mesajul intr-o secventa de biti care va fi

transmisa pe mediu, in functie de tipul de transmisie wireless utilizata. Ulterior, acest eveniment

Send este adaugat in coada de evenimente EventQueue. Clasa Engine a simulatorului verifica

coada de evenimente la interval regulate de timp, iar pentru fiecare eveniment de tip Send gasit

in coada creeaza un eveniment de tip Receive (sau mai multe evenimente in cazul unui mesaj de

dfiuzare). Evenimentele de tip GPS sunt programate la intervale fixe de timp pentru fiecare nod

ale retelei, in acest mod simuland cu acuratete felul in care aplicatia VANET culege periodic

date GPS.

Metoda updateWaitingQueue() se ocupa cu retransmisia de mesaje. Acest lucru se

intampla in cazul in care nu s-a primit raspunsul dorit (mesajul semnat) de la un semafor

securizat dupa un anumit interval de timp SecureGlobals.TIMEOUT. In vederea retransmisiei de

mesaje, este parcursa coada de mesaje waitingMessages, iar pentru fiecare mesaj se verifica daca

acesta a depasit perioada TIMEOUT inainte de a fi confirmat. In caz afirmativ, el este retrimis.

Metoda removefromWaitingQueue(SecMessage confirmat) sterge din coada de mesaje

securizate waitingMessages un mesaj intrucat acesta a fost confirmat de semaforul securizat din

imediata proximitate.

Metoda updateConfirmedQueue() are drept scop retransmisia de mesaje care au nevoie

de un raspuns in privinta validitatii si inca nu l-au primit. Retrimiterea unui mesaj se face daca

raspunsul de confirmare nu a ajuns la masina destinatie dupa SecureGlobals.TIMEOUT. In

vederea reprogramarii transmisiei de mesaje, am folosit tabelul de dispersie auxiliar relCarTime

(hashtable <masina,timp>) si lista confirmedMessages de mesaje pentru masina destinatie.

Metoda verifySignature(PublicKey key, byte[] buffer, byte[] signature) returneaza o

valoare booleana care confirma sau infirma validitatea semnaturii pentru un anumit mesaj.

37

In cadrul clasei SecCar, procesarea mesajelor se face doar pentru mesaje specifice

protocolului PROT_SEC_PKI sau PROT_SEC_CAR. In functie de tipul de mesaj primit,

automobilul securizat va face tranzitii intre mai multe stari.

Initial, toate masinile sunt in starea de masini LIBERE. Daca se primeste un mesaj nul,

acesta nu va fi procesat.

In momentul in care se masina primeste un semnal intern (mesaj unicast trimis spre ea

insasi) pentru a incepe comunicatia, verifica daca a primit anterior un beacon de la un semafor

securizat.

Daca nu a receptionat nici un beacon de la un semafor din apropiere, masina va

programa inceperea comunicatiei la un moment de timp ulterior.

Fig 4.3.2 Comunicatia intre doua masini securizate

In cazul in care a primit beacon de la un semafor din apropiere, automobilul poate incepe

comunicatia cu o alta masina. Inainte de a trimite mesajul unei masini destinatie, mesajul trebuie

securizat. Aceasta se face cu ajutorul infrastructurii din imediata apropiere, in speta cu un

38

semafor securizat. Mesajul este trimis prima data semaforului, care il semneaza, de-abia apoi

fiind expediat vehiculului destinatie. Semnatura apendata de semafor la sfarsitul mesajului

certifica faptul ca acesta nu va fi putea fi compromis, in caz contrar putand demonstra cu

usurinta acest lucru.

Trebuie luat in considerare faptul ca aria de acoperire pentru transmisie a unei masini

securizate este mai mica decat aria de acoperire a unui semafor securizat. Din acest motiv,

trimiterea unui mesaj pentru a fi semnat la semafor se poate face in doua moduri:

� direct, in cazul in care semaforul este in aria de acoperire a masinii care necesita

semnarea mesajului la entitatea de incredere

� rutat prin intermediul altor masini intermediare, in cazul in care semaforul securizat nu

este in aria de acoperire a masinii care necesita semnare mesajului la entitatea de

incredere.

O problema importanta specifica retelelor VANET este privacy-ul. Un emitator doreste

sa comunice cu altii, dar in acelasi timp nu doreste sa-si divulge identitatea. Acest aspect duce la

urmatoarele specificatii pentru protocolul de securitate implementat: semnarea mesajului se va

face pe campurile corespunzatoare mesajului propriu-zis, amprentei de timp si pozitiei

geografice (semnarea mesajului se face cu cheia privata a semaforului securizat din apropiere).

Pozitia geografica (latitudinea si longitudinea) sunt coordonate sigure care pot preciza cu

certitudine locatia unei masini la un moment dat de timp. Cum semafoarele securizate sunt

considerate puncte de incredere, care nu pot fi fraudate, latitudinea si longitudinea la care se afla

sunt nemodificabile si sigure. Astfel, identitatea unui vehicul nu se divulga, dar se poate atesta

faptul ca a fost acolo unde pretinde folosind ca dovada amprenta de loc si de timp.

In momentul in care un vehicul primeste de la semafor mesajul semnat, va verifica daca

acesta nu a fost fraudat pe drumul de intoarcere de la semafor catre masina. De exemplu, mesajul

poate fi fraudat printr-un atac de tip “man-in-the middle”. Presupunem ca un astfel de atac ar

avea loc. In acest caz, mesajul ar ajunge modificat la destinatie, dar cum destinatia are cheia

publica a semaforului din apropiere (aceasta este transmisa periodic catre toate masinile din aria

de acoperire a unui semafor securizat sub forma de beacon), se va observa ca semnatura nu este

valida conform campurilor din mesaj care au contribuit la crearea ei (se verifica acest lucru

folosind cheia publica a semaforului). In acest caz, mesajul nu va fi rutat in continuare catre

destinatie finala.

Daca mesajul este unul valid, masina il va trimite catre destinatia finala. In momentul in

care ajunge la destinatia finala, inainte de a fi procesat, acesta va trebui validat. Din nou,

validarea se va face la un semafor din apropiere. Astfel, daca semaforul este in raza de emisie

wireless a masinii, trimiterea mesajului se va face direct; altfel, expedierea mesajului pentru a fi

validat se va face prin intermediul unor masini existente pe ruta pana cand acesta ajunge la un

semafor securizat.

In momentul in care primeste mesajul de raspuns inapoi de la semafor, vehiculul va

verifica faptul ca mesajul raspuns pentru validare nu a fost compromis. Se verifica daca

39

semnatura atasata raspunsului de validare nu a fost fraudata (folosind cheia publica a semaforului

din apropiere). In cazul in care se confirma ca mesajul este valid, poate fi prelucrat in continuare.

Pe parcursul protocolului de securitate, se poate observa ca masina trece prin mai multe

stari (stari care nu se exclud reciproc una pe alta, ci se modifica in functie de tipul de eveniment

receptionat):

� LIBER

� BEACON RECEPTIONAT

� MASINA INTERMEDIARA

� START COMUNICATIE – dupa ce a primit mesajul inapoi semnat de un semafor

securizat

� MASINA RECEPTIONAT MESAJ

� MASINA RECEPTIONAT VALIDARE SEMAFOR

40

4.4 SecCityTrafficLight

Clasa SecCityTrafficLight reprezinta clasa ce implementeaza semaforul securizat in

cadrul protocolului. Clasa extinde CittyTrafficLight avand la baza drept clasa parinte pe clasa

Intersection. Pe langa metodele mostenite, clasa implementeaza metode noi sau suprascrie

metode ale claselor parinte. In afara de variabilele mostenite, clasa SecCittyTrafficLight adauga

noi variabile care sunt folosite in implementarea protocolului de securitate propus.

Pentru aplicatia in cauza am considerat ca semafoarele securizate existente pe harta sunt

semafoare inteligente. Ele dispun de capabilitati de comunicare si de putere de calcul. Astfel, pot

comunica intre ele si cu automobilele din jur. In mod uzual, intr-un oras, cele mai multe

semafoare sunt interconectate si corelate, iar instalarea unor echipamente de comunicare si de

procesare nu este dificila.

Pentru a putea face fata volumului de trafic, pe procesoarele semafoarelor nu se vor

executa algoritmi complecsi. Semafoarele securizate au rolul unor entitati de incredere, parte

componenta din infrastructura, care ajuta la semnarea si verificarea autentiticitatii mesajelor, in

cazul in care acest lucru este cerut.

Pe langa atributele mostenite de la CittyTrafficLight, SecCittyTrafficLight are o serie de

atribute particulare care individualizeaza protocolul de securitate:

� mesajul newMessage este folosit in comunicatia masina- semafor (este un mesaj

particular, specific protocolului). Acesta va fi detaliat intr-o sectiune ulterioara a lucrarii.

� lista “masini” – reprezinta o lista cu masinile care au trecut pe la acest semafor securizat

si au cerut semnarea sau autentificarea unui mesaj

� atributul id_sem – reprezinta identitatea semaforului securizat (parte a infrastructurii

rutiere)

� atributul publicKey – reprezinta cheia publica generata particular pentru acest semafor

securizat

� atributul privateKey – reprezinta cheia secreta generata particular pentru acest semafor

securizat

Constructorul clasei SecCittyTrafficLight suprascrie constructorul clasei

CittyTrafficLight si genereaza cheia publica si cheia privata particulara pentru semaforul

securizat curent. Algoritmul de semnare a mesajelor se bazeaza pe DSA, standardul de facto

utilizat de Guvernul Federal al Statelor Unite pentru semnaturi digitale.

Metoda createSignature(PrivateKey key, byte[] buffer) returneaza semnatura pentru

bufferul de bytes dat ca argument folosind cheia privata.

Metoda verifySignature(PublicKey key, byte[] buffer, byte[] signature) verifica

autenticitatea semnaturii signature pentru array

semaforului.

Metode auxiliare ajutatoare sunt getPublicKey si

a semaforului, respectiv numarul de masini care au cerut semaforului secu

semneze sau sa le autentifice un mesaj.

Alte metode auxiliare convertStringToByteArray(..) si convertByteArraytoString(…) fac

conversia directa si inversa intre un array de bytes si un string.

Fig 4.4.1 Digrama de clasa pentru

Metoda step(int crtTime) suprascrie metoda cu acelasi nume din clasa CittyTrafficLight,

dar implementeaza in acelasi timp si programarea unor beaconuri periodice pentru acest semafor

securizat.

41


bufferul de bytes dat ca argument folosind cheia privata.


semnaturii signature pentru array-ul de bytes buffer folosind cheia publica a

re ajutatoare sunt getPublicKey si getMasini care returneaza cheia publica

a semaforului, respectiv numarul de masini care au cerut semaforului securizat curent sa le

semneze sau sa le autentifice un mesaj.


conversia directa si inversa intre un array de bytes si un string.

Digrama de clasa pentru Semaforul Securizat





ul de bytes buffer folosind cheia publica a

care returneaza cheia publica

rizat curent sa le




42

Metoda scheduleSecureSendEvent(int delay, int messageType) adauga in coada de

evenimente de tip Send ale Engine-ului noi mesaje de tip beacon emise la interval de o secunda

de semaforul securizat. Mesajele de tip beacon contin in cadrul lor si cheia publica a semaforului

ce a emis beaconul respectiv.

Metoda upgradeToSecTL() upgradeaza toate semafoarele existente pe harta la semafoare

inteligente securizate. Tot in aceasta metoda se are in vedere setarea culorilor pentru semafor,

precum si timpul cat un semafor isi pastreaza o anumita culoare inainte de a o schimba cu alta.

Metoda “onReceive” marcheaza faptul ca obiectul SecCittyTrafficLight a receptionat un

eveniment de la mediu. In cazul in care mesajul este nul, procesarea se opreste. Altfel, se verifica

antetul mesajului. Daca tipul de protocol inscriptionat in antet este PROT_SEC_PKI, mesajul

este procesat. In cazul implicit, este apelata metoda default de procesare a mesajului specifica

claselor parinte.

Metoda chechSignature(…) verifica autenticitatea semnaturii pentru un anumit mesaj.

Metoda returneaza o valoare booleana reprezentand validitatea sau nelegitimitatea respectivului

mesaj. Este posibil ca mesajul sa nu fie semnat de acest semafor, din acest motiv semnatura

trebuie validata cu toate semafoarele de pe harta. Daca mesajul este validat cu unul din

semafoarele securizate existente pe harta, se intoarce o variabila booleana de adevar; in caz

contrar, se returneaza fals.

Procesarea mesajului apartinand PROT_SEC_PKI se face numai pentru anumite tipuri de

mesaje din cadrul protocolului de securitate. Mesajele prelucrate sunt de tip cerere de semnare a

unui mesaj sau verificare a validitatii pentru un anumit mesaj.

Mesajele trimise de semafoarele securizate SecCittyTrafficLight catre masinile securizate

SecCar sunt unicast. Motivatia acestei decizii consta in faptul ca aria de acoperire a semaforului

este mai mare decat aria de acoperire a masinii, astfel incat acesta are suficient timp pentru a

prelucra un mesaj primit si a-l trimite inapoi. In cazul in care masina ruleaza cu o viteza mare si

nu primeste raspunsul inapoi de la semaforul securizat, il va retrimite ulterior atunci cand va intra

in aria de acoperirea a altui semafor securizat.

Un eveniment de tip Send declanseaza metoda prepareMessage(int messageType)

responsabila pentru pregatirea unui mesaj. Metoda prepareMessage serializeaza mesajul intr-o

secventa de biti care va fi transmisa pe mediu, in functie de tipul de transmisie wireless utilizata.

In cazul in care se proceseaza un mesaj de tip cerere semnare, se prelucreaza campurile

referitoare la mesajul propriu-zis, locatie si amprenta de timp, toate acestea contribuind la

realizarea semnaturii digitale. De asemenea, se inregistreaza in lista de masini a semaforului

curent automobilul care a facut cererea de semnare.

In cazul in care se proceseaza o cerere de validitate privind un mesaj care a ajuns la o

anumita masina, se fac verificari pe campurile mesajului si semnatura atasata acestuia. Daca

mesajul a fost semnat de unul din semafoarele inteligente securizate in cadrul infrstructurii, se va

intoarce un raspuns masinii destinatie. In cazul in care semnatura este valida, raspunsul este unul

43

pozitiv; in caz contrar, raspunsul este negativ. Pentru a preveni un atac de tip “man – in – the –

middle”, acest mesaj de confirmare este de asemenea semnat de semaforul securizat. In cazul in

care un atacator ar frauda mesajul, masina destinatie poate observa acest lucru, verificarea

facandu-se cu cheia publica a semaforului pe semnatura raspunsului primit.

Mesajele de tip broadcast din cadrul protoculului PROT_SEC_PKI care nu sunt destinate

semafoarelor securizate sunt rejectate.

In timpul derularii protocolului de securitate, se poate observa ca semaforul trece prin

mai multe stari (stari care nu se exclude reciproc una pe alta, ci se modifica in functie de tipul de

eveniment receptionat):

� EMIS BEACON

� VERIFICARE MESAJ

4.5 Clasa SecMessage

Clasa SecMessage reprezinta clasa ce implementeaza mesajele specifice protocolului de

securitate implementat.

Clasa contine metode de tip setter si getter pentru toate atributele specifice mesajului.

Fig 4.5.1 Diagram

Tipurile de mesaje sunt setate in functie de starea in care se afla masina securizata SecCar

sau semaforul securizat SecCittyTrafficLight. Mesajele contin un camp intern numar de hopuri

care precizeaza numarul maxim de statii prin care poate trece un mesaj

acelasi timp, este mentinuta si o stampila de timp care ajuta la retransmisia unor mesaje in cazul

44



Diagrama de clasa pentru clasa SecMessage



care precizeaza numarul maxim de statii prin care poate trece un mesaj pana sa fie






pana sa fie rejectat. In


45

in care acest lucru este necesar. Mecanismele de timeout si numarul maxim de hopuri sunt

necesare pentru a preveni fenomenul de buclare la infinit a mesajelor.

Mesajele generate in cadrul protocolului de securitate de entitatea SecCar sau entitatea

SecCittyTrafficLight implica evenimente adaugate in coada EventQueue a clasei Engine.

Evenimentele generate sunt de tip unicast sau broadcast, in functie de starea in care se afla

obiectul emitator sau receptor de mesaje. Mesajele de tip broadcast sunt utile in cazul in care se

apeleaza la rutarea folosind mai multe hopuri (masini intermediare), iar mesajele de tip unicast

sunt folosite pentru comunicatia directa.

Alte campuri importante pentru acest protocol sunt campurile latitudine si longitudine,

care determina pozitia geografica a unei statii la un moment dat. De asemenea, campul Cheie

Publica ajuta masinile securizate sa verifice validitatea unor mesaje primite de la semafoarele

securizate.

Dimensiunea unui mesaj SecMessage variaza in functie de tipul acestuia. De exemplu, un

beacon emis de semafor va contine obligatoriu campul Cheie Publica, pentru a ajuta masina

securizata sa valideze veridicitatea mesajului semnat primit. Mesajele efective ce sunt

comunicate intre doua masini nu trebuie obligatoriu sa contina cheia publica, aceasta putand fi

obtinuta si retinuta usor la destinatie (care primeste de asemenea beaconuri). Pe langa campul

care contine semnatura raspunsului final de validate a unui mesaj dat de un semafor unei masini

securizate trebuie sa mai existe si cheia publica a semaforului pentru a preveni atacuri de tip

man-in-the-middle.

4.6. Clasa SecureGlobals

Clasa SecureGlobals reprezinta clasa ce contine constantele finale specific protocolului

de securitate implementat.

Clasa contine urmatoarele atribute particulare:

� constanta de timeout TIMEOUT

� constanta care reprezinta numarul maxim de h

� tipurile de mesaje specific

emise de entitatea SecCar sau SecCittyTrafficLight

� codificarea starilor prin care trece masina SecCar

Fig 4.6.1 Diagram

46


Clasa contine urmatoarele atribute particulare:

constanta de timeout TIMEOUT

constanta care reprezinta numarul maxim de hopuri admise in protocol MAX_HOPS

tipurile de mesaje specifice care sunt rulate in protocolul de securizate. Mesajele pot fi

emise de entitatea SecCar sau SecCittyTrafficLight

codificarea starilor prin care trece masina SecCar

Diagrama de clasa pentru clasa SecureGlobals


opuri admise in protocol MAX_HOPS

care sunt rulate in protocolul de securizate. Mesajele pot fi

47

4.7 Detalii suplimentare privind implementarea protocolului

In vederea implementarii protocolului de securitate propus am folosit si modificat o serie

de clase existente in simulatorul VNSim.

Clasa Engine face parte din pachetul vnsim.core si reprezinta motorul simulatorului.

Aceasta se ocupa cu transmisia si retransmisia de evenimente, incarcarea infrastructurii,

nodurilor retelei VANET (masinile din trafic) etc. Am extins clasa Engine in vederea crearii de

masini securizate SecCar si semafoare securizate SecCittyTrafficLight, specifice protocolului

implementat. De asemenea, am facut modificari in clasa Engine pentru a suporta mesaje de tip

Unicast si PeriodicalUnicastEvent.

In pachetul vnsim.gui am extins clasele ListBuilder, MapLoader, MapView si MapView

Panel. Pachetul vnsim.gui este responsabil pentru crearea interfetei grafice cu utilizatorul si

afisarea scenariilor rutiere selectate sau create. Pentru a realiza interfata grafica s-a folosit JOGL

si Java Swing.

In clasa ListBuilder am extins functionalitatile deja extinse cu noi metode necesare

reprezentarii grafice a masinilor securizate SecCar. In functie de starea in care o masina se afla,

aceasta va fi desenata cu o culoare diferita pe harta digitala. Astfel, cand masinile intra pe harta,

ele vor fi codificate in culoarea alb. In momentul in care primesc un beacon de la un semafor

securizat isi vor schimba culoarea in verde. Daca o masina ruteaza pachete pentru alte masini, ea

va fi reprezentata folosind culoarea albastru. In momentul in care o masina a primit inapoi de la

semaforul securizat mesajul semnat, ea va fi colorata in rosu. Cand un autombil primeste un

mesaj de comunicatie de la un alt automobil se va reprezenta folosind culoarea galbena. Primirea

confirmarii de la semafor referitoare la validitatea unui mesaj determina un vehicul sa fie

reprezentat in culoarea galben cu negru.

Clasa MapLoader se ocupa cu incarcarea hartilor in simulatorul VMSim. Am extins

functionalitatile adaugand in interfata grafica butoane specifice tipului de protocol de securitate

implementat, precum si posibilitatea selectarii tipului de semafor inteligent securizat propus.

Clasei MapView i-au fost extinse functionalitatile, adaugand in lista de stari posibile ale

masinii SimulatedCarInfo starile specifice masinii SecCar pentru protocolul de securitate

implementat.

In clasa MapViewPanel am extins metoda display_Cars (GL myGl), adaugand starile

particulare pentru automobilul securizat SecCar. In functie de starea in care se afla masina, se

face un apel pentru o reprezentare grafica corespunzatoare a automobilului pe harta.

Capitolul 5 - Rezultate Experimentale

5.1 Validarea parametrilor

Experimentele au fost rulate pe simulatorul VNSim, descris in Capitolul 3 a lucrarii.

Rezultatele prezentate in continuare ofera indicatori care exprima

implementat.

Datele experimentale colectate au fost prelucrate folosind un scenariu urban, campusul

Universitatii Politehnica Bucuresti.

cadrul simulatorului fiind variabi

in simulatorul anterior mentionat

Securizata si Semaforul Securizat.

principale ale protocolului de securitate

colectate atat la nodurile active (automobile securizate), cat si la nodurile pasive (

securizate).

48

Rezultate Experimentale

Validarea parametrilor protocolului de securitate


Rezultatele prezentate in continuare ofera indicatori care exprima fiabilitatea protocolului


Universitatii Politehnica Bucuresti. Harta contine 16 semafoare securizate, traficul generat in

bil, in functie de conditiile rutiere existente. Scenariul este generat

mentionat, entitatile principale existente in scenariu fiind Masina

Securizata si Semaforul Securizat. Indicatorii prezentati in continuare expun caracteristicile

de securitate propus. Informatiile pe baza carora sunt calculat

colectate atat la nodurile active (automobile securizate), cat si la nodurile pasive (

Fig 5.1.1 Harta digitala de simulare


fiabilitatea protocolului


Harta contine 16 semafoare securizate, traficul generat in

Scenariul este generat

, entitatile principale existente in scenariu fiind Masina

in continuare expun caracteristicile

pe baza carora sunt calculati sunt

colectate atat la nodurile active (automobile securizate), cat si la nodurile pasive (semafoare

49

Parametrii specifici considerati in analiza performantei aplicatiei implementate sunt

urmatorii:

� In cadrul entitatii semafor securizat (SecCityTrafficLight):

o Raportul intre numarul de raspunsuri pozitive si negative emise de un semafor

securizat. Comportamentul normal al protocolului (nu exista nici un atactor in

retea) impune ca numarul de raspunsuri negative emise de un semafor securizat sa

fie nul, intrucat nici un mesaj nu a fost modificat, astfel incat mesajul poate fi

confirmat la semafor.

o Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje

emise de acest semafor. Indicele caracterizeaza gradul de incarcare al semaforului

securizat raportat la conditiile de trafic. Se calculeaza astfel:

∆��∆�� .

� In cadrul entitatii masina securizata ( SecCar)

o Numarul de mesaje in trafic raportat la intervale periodice de timp. Indicatorul se

calculeaza astfel: ∆��

∆��

o Throughput-ul generat de masinile securizate in cadrul retelei VANET.

Indicatorul se calculeaza astfel: �( �� ∗ �� )

∆��

o Numarul de conexiuni – numarul curent de mesaje unice ce trebuie transmise intre

sursa si destinatie. Acesta creste o data cu posibilitatea unui automobil securizat

de a initia comunicatie si scade in momentul cand mesajul este confirmat la

destinatie.

In continuare vor fi expuse caracteristicile in conditii normale, urmate de analiza variatiei

parametrilor specifici ca urmare a efectuarii unor atacuri.

50

5.2 Performanta protocolului de securitate in conditii ce nu implica prezenta

unor atacatori

Rularea in conditii ideale ale protocolului de securitate nu implica existenta atacatorilor

in scenariul de test considerat. Datele colectate la entitatile participante in protocol constituie

fundamentul in vederea reprezentarii grafice a indicilor de performanta prezentati anterior.

Fig 5.2.1 Raportul intre raspunsuri pozitive si negative emise

de acest Semafor Securizat

Graficul 5.2.1 evidentiaza fiabilitatea protocolului de securitate implementat. Functia cu

albastru reprezinta numarul de raspunsuri pozitive emise o data cu trecerea timpului, iar functia

reprezentata cu rosu arata raspunsuri negative transmise de semaforul securizat. Se observa ca

numarul de mesaje confirmate creste pe masura ce aplicatia isi continua executia, in aria de

acoperire a acestui semafor ruland, o data cu cu trecerea timpului, mai multe masini care cer

confirmari in privinta veridicitatii mesajelor primite de la alte automobile. Raspunsurile negative

sunt egale cu zero, in acord cu implementarea expusa: cum nu exista atacatori in retea, nici un

mesaj nu este fraudat, tot traficul cu informatii ce necesita verificare fiind validat de semafoarele

securizate.

-2

0

2

4

6

8

10

12

14

16

18

0 10000 20000 30000 40000

Nu

ma

r ra

spu

nsu

ri

Timp(ms)

Raspunsuri emise de semaforul securizat in timp

Raspunsuri pozitive

Raspunsuri negative

51

Graficul 5.2.2 evidentiaza gradul de incarcare a semaforului raportat la conditiile de

trafic. Axa orizontala prezinta numarul de mesaje, iar axa verticala reprezinta numarul de masini

care au comunicat cu acest semafor. Se observa ca pe masura ce conditiile de trafic se intensifica

(mai multe masini trec prin aria de acoperire a entitatii pasive), numarul de mesaje emise de

semaforul securizat creste. Acest rezultat este in concordanta cu solutia propusa. Cu cat numarul

de masini care sunt in aria de acoperire a unui semafor creste, cu atat mai multe mesaje se vor

transmite.

Semaforul va trimite periodic beaconuri masinilor din aria sa de acoperire, masinile vor

trimite semaforului mesaje pentru a le semna sau verifica validitatea acestora. Mai mult, cum

raza de actiune a unei masini este mai mica decat raza de actiune a unui semafor securizat, este

posibil ca o masina sa trimita mesajul catre un semafor prin intermediul altor masini (prin

difuzare). De asemenea, semaforul trimite inapoi catre masinile securizate mesajele apendate cu

semnatura digitala si raspunsuri privind validitatea anumitor mesaje care necesita confirmare.

Observand panta functiei graficului, se observa un raport aproximativ liniar cu valoarea 1.25

intre numarul de mesaje si numarul de masini ce au comunicat cu acest semafor securizat.

Fig 5.2.2 Gradul de incarcare al semaforului raportat la conditiile de trafic

Valoarea pantei caracterizeaza o legatura aproximativa de 1:1 intre masina si semafor,

rezultat ce atesta faptul ca nu exista explozii de transmitere de mesaje in apropierea semaforului,

justificand corectitudinea implementarii.

0

5

10

15

20

0 10 20 30

Nu

ma

r d

e m

asi

ni

Numar mesaje

Numar de mesaje trimise de semaforul

securizat raportat la numarul de masini

Numar de mesaje

trimise de semaforul

securizat raportat la

numarul de masini

52

Reprezentarile urmatoare (fig. 5.2.3, 5.2.4) exprima parametri ai protocolului de

securitate calculati folosind date colectate de masinile securizate. Cele doua grafice de mai jos

caracterizeaza numarul de mesaje aflate in tranzit generate de masini si throughput-ul mediu

calculat pentru autombilele securizate la intervale periodice de timp.

Fig 5.2.3 Numarul de mesaje aflate in tranzit generat de masini

Fig 5.2.4 Throughput-ul generat de vehiculele securizate

Se observa o legatura proportionala intre numarul de mesaje generate de masini aflate in

tranzit si throughput-ul de comunicatie implicat. Se poate vedea ca fluctuatiile din reprezentare

-200

0

200

400

600

800

0 10000 20000 30000 40000

Nu

ma

r d

e m

esa

je

Timp(ms)

Numar de mesaje generate de masini la

intervale periodice de timp

Numar de mesaje

generate de masini la

intervale periodice de

timp

-200

0

200

400

600

800

0 10000 20000 30000 40000

Nu

ma

r M

esa

je*

(Dim

en

siu

ne

Me

sj)

Timp(ms)

Throughput-ul generat de masini

Throughput-ul generat de

masini

53

nu implica schimbari bruste si accentuate. Variatiile existente pe grafic sunt datorate dimensiunii

inegale a mesajelor, transmisiunilor de tip difuzare, cozilor de masini care se pot produce la

semafor, cererilor de semnare si validare a anumitor mesaje pentru masinile securizate. Se atesta

faptul ca incarcarea retelei este in concordanta cu numarul de mesaje aflate in tranzit in retea.

Fig 5.2.5 Numarul de conexiuni stabilite pe interval periodice de timp

Graficul 5.2.5 caracterizeaza variatia in timp a conexiunilor dintre vehiculele securizate.

Se observa cum graficul capata o panta ascendenta o data cu initierea de conexiuni intre diferite

automobile care isi transmit mesaje securizate. Pe masura ce conexiunile sunt confirmate la

semafoarele securizate si se primesc raspunsuri pozitive, numarul acestora scade, graficul trece

pe o panta descendenta. Fluctuatiile existente sunt datorate masinilor care incearca noi

transmisiuni cu restul vehiculelor din trafic, panta capatand aspect descendent in momentul in

care mesajele ajung la destinatie si sunt confirmate.

0

5

10

15

0 10000 20000 30000 40000

Nu

ma

r d

e c

on

ex

iun

i

Timp(ms)

Variatia in timp a conexiunilor dintre

masini

Variatia in timp a

conexiunilor dintre masini

54

5.3 Scenariul 1

Primul atac implementat consta in introducerea in reteaua VANET a unor masini

atacatoare care transmit mesaje direct catre destinatia finala, nemaiatasand semnatura digitala de

la semaforul securizat. Rata de atacatori infiltrati in reteaua ad-hoc vehiculara este de 35%.

Indicatorii caracteristici protocolului de securitate implementat prezentati pentru

comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 1, facand observatiile de

riguroare specifice tipului de atac desfasurat in acest caz.



-500

0

500

1000

0 20000 40000 60000 80000Nu

ma

r d

e m

esa

je

Timp(ms)

Numar de mesaje generate de

masini la intervale periodice de

timp

Numar de mesaje

generate de masini

la intervale periodice

de timp

-200

0

200

400

600

800

1000

0 20000 40000 60000 80000

Nu

ma

r M

esa

je *

(D

ime

nsi

un

e

Me

saj)

Timp(ms)

Throughput-ul generat de masini la

intervale periodice de timp

Throughput-ul

generat de masini la

intervale periodice

de timp

55


Cele trei grafice de mai sus (fig. 5.3.1, 5.3.2, 5.3.3) caracterizeaza urmatorii parametri ai

protocolului:

� Numarul de mesaje in trafic raportat la intervale periodice de timp.

� Throughput-ul generat de masinile securizate in cadrul retelei VANET.

� Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise

de acest semafor.

Comparand graficele in cazul primului atac (trimiterea de catre un atacator a unui mesaj fals,

nesemnat de catre o autoritate de certificare – semafor securizat) cu situatia normala de

functionare, se observa ca pararametrii mentionati nu sufera modificari semnificative.

In cazul gradului de incarcare determinat de traficul de informatie generat de masini, cum

atacatorul trece peste etapa de atasare a unei semnaturi digitale la sfarsitul mesajului, se constata

ca throughput-ul necesar comunicarii este mai mic decat in cazul ideal de functionare, deoarece

se trece peste faza in care un mesaj este posibil sa fie expediat catre un semafor prin intermediul

unor masini intermediare.

Coroborat cu throughput-ul este si numarul de mesaje generate de vehicule (cei doi indicatori

sunt in relatie de proportionalitate), care, analog cu cele mentionate anterior, este mai mic decat

in cazul ideal de functionare (fara atacatori).

Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise de

un semafor securizat nu se modifica, entitatea de incredere din infrastructura analizand mesajele

din partea atacatorilor in acelasi mod cu a unor pretendenti legitimi.

Graficul 5.3.4 ce caracterizeaza variatia in timp a conexiunilor dintre vehiculele securizate se

modifica semnificativ fata de situatia ideala. Dupa cum se observa, panta graficului mentine o

tendinta ascendenta, intrucat semaforele securizate recunosc faptul ca mesajele au fost

-20

0

20

40

-10 0 10 20 30Nu

ma

r m

asn

i

Numar mesaje

Numar de mesaje trimise de

semaforul securizat raportat la

numarul de masini

Numar de mesaje



numarul de masini

56

modificate de un atacator si trimit raspunsuri negative la automobilul destinatie final. Cu toate ca

unele mesaje sunt confirmate, avand in vedere gradul mare de atacatori prezenti in reteaua ad-

hoc vehiculara, numarul de conexiuni neconfirmate va mentine panta crescatoare.

Fig 5.3.4 Numarul de conexiuni stabilite pe intervale periodice de timp

In cazul raspunsurilor emise de semafor, se pot observa, din nou, schimbari radicale fata

de situatia ideala, cand in sistem nu existau atacatori. Graficul de mai jos (fig. 5.3.5) expune

comportamentul unui semafor securizat care prelucreaza cereri de la participantii din trafic

(automobile). Functia reprezentata cu albastru reprezinta numarul de raspunsuri pozitive emise o

data cu trecerea timpului, iar functia reprezentata cu rosu arata raspunsurile negative transmise

de semaforul securizat. Raspunsurile negative au o valoare diferita de zero, in acord cu

implementarea expusa: cum in retea exista atacatori, unele mesaje sunt fraudate, astfel incat o

parte din traficul ce necesita validare de la semafoare primeste raspuns negativ. Se poate constata

ca semafoarele securizate reusesc sa discerne intre un trafic autentic si unul nelegitim.

Fig 5.3.5Raportul intre raspunsuri pozitive si negative

emise de acest Semafor Securizat

0

10

20

30

40

50

0 20000 40000 60000 80000Nu

ma

r d

e c

on

ex

iun

i

Timp(ms)


masini

Variatia in timp a

conexiunilor dintre

masini

-0.5

0

0.5

1

1.5

2

2.5

3

3.5

0 20000 40000 60000 80000

Nu

ma

r ra

spu

nsu

ri

Timp(ms)


Raspunsuri pozitive

Raspunsuri negative

57

Urmatoarele doua grafice expun modalitatea in care atacurile declansate de intrusii din

sistem sunt contramandate de semafoarele securizate.

Fig 5.3.6 Depistare si contracarare atacuri

O data ajuns la destinatie, mesajul trebuie sa parcurga o ultima faza de validare cu un

semafor securizat din apropiere. Trebuie de asemenea amintit ca aria de transmisie a unei masini

este mai mica decat aria de transmisie a unui semafor. Astfel, unele mesaje fraudate vor fi

difuzate prin intermediul unor masini intermediare catre autoritatea de incredere, semaforul,

pentru validare finala. Rezulta, datorita fenomenului de difuzare, ca atacurile ajung multiplicat la

semafor, dar sunt contramandate cu succes de acesta.

Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa

rezista tipului de atac explicat in scenariul 1.

0

10

20

30

40

0 20000 40000 60000 80000

Nu

ma

r d

e a

tacu

ri g

en

era

te

de

ma

sin

ile

in

tru

e

Timp(ms)

Numarul de atacuri generat de

masinile intruse

Numarul de atacuri

generat de masinile

intruse

-50

0

50

100

150

60480 60500 60520 60540

Nu

ma

r d

e a

tacu

ri d

ep

ista

te

Timp(ms)

Numarul de atacuri depistate la

semaforul securizat

Numarul de atacuri

depistate la semaforul

securizat

58

5.4 Scenariul 2

Cel de-al doilea atac implementat consta in adaugarea in reteaua VANET a unor masini

atacatoare care, daca ajung in starea de MASINI_INTERMEDIARE, nu vor mai ruta mesajul in

continuare catre un semafor securizat, ci il vor rejecta. Rata de atacatori infiltrati in reteaua ad-

hoc vehiculara este de 35%.






Graficul 5.4.1 evidentiaza fiabilitatea protocolului de securitate implementat, precum si

rezistenta acestuia la atacul propus. Functia colorata cu albastru reprezinta numarul de raspunsuri

pozitive emise o data cu trecerea timpulu, iar functia reprezentata cu rosu arata raspunsurile

negative transmise de semaforul securizat. Se poate observa similitudinea cu graficul din cazul

ideal (unde nu exista atacatori). Raspunsurile negative sunt egale cu zero, in acord cu

implementarea expusa.

Exista atacatori in retea, care, atunci cand vor fi in starea de MASINI_INTEMEDIARE,

nu vor ruta mesajele catre semafoarele securizate. Totusi, rata atacatorilor nu este foarte ridicata,

astfel incat, cu toate ca o parte din mesaje vor fi rejectate, alte automobile legitime, o data ajunse

in starea de MASINA_INTERMEDIARA, vor trimite mesajele catre semafoarele securizate.

Chiar si in cazul in care toti vecinii unui automobil sunt atacatori (care rejecteaza informatia),

masina legitima va reusi comunicatia cu o alta. Daca un semafor se afla in aria ei de transmisie,

va comunica direct cu acest. In caz contrar, daca nu va primi un raspuns privind apendarea unei

-2

0

2

4

6

8

10

12

14

16

0 10000 20000 30000 40000

Nu

ma

r r

asp

un

suri

Timp(ms)

Raspunsuri emise de semaforul securizat in

timp

Raspunsui pozitive

Raspunsuri negative

59

semnaturi sau verificarea validitatatii pentru un mesaj pentru un timp TIMEOUT, va reincerca

transmisia. Eventual, va avea in aria de acoperire un semafor securizat cu care sa comunice sau

masini intermediare legitime care sa ruteze mesajul.


un semafor securizat (fig 5.4.2) nu se modifica, parametrul pastrandu-si o valoare aproximativ

egala cu scenariul ideal, unde nu existau masini atacatoare. Faptul ca o masina nu va mai ruta

mesaje pentru alti participanti la trafic nu influenteaza numarul de mesaje transmise de semaforul

securizat celorlate vehicule din proximitate.


In cazul gradului de incarcare determinat de traficul generat de masini (fig. 5.4.3), cum

atacatorul nu ruteaza mesaje pentru alte vehicule din apropiere, se constata ca throughput-ul

necesar comunicarii este mai mic decat in cazul ideal de functionare. Totusi, acest throughput

poate creste pana la o valoare aproximativ egala cu cea din cazul ideal, considerand faptul ca,

dupa un timp TIMEOUT, masina initiatoare va reincerca transmisia mesajului catre destinatie.

Coroborat cu throughput-ul este si numarul de mesaje generate de vehicule (fig. 5.4.4).

Luand in considerare relatia de proportionalitate directa intre cei doi indicatori, discutia pentru

throughput se face analog, ca in paragraful anterior.

0

5

10

15

0 10 20 30

Nu

ma

r m

asi

ni

Numar mesaje



numarul de masini

Numar de mesaje



numarul de masini

60



Graficul privind variatia in timp a conexiunilor dintre vehiculele securizate (fig. 5.4.5)

are aceleasi caracteristici cu cel din scenariul ideal.

Faptul ca exista masini intermediare care nu ruteaza mesajele pentru validare finala

privind legitimitatea mesajului nu influenteaza numarul de conexiuni care se vor stabili intre doi

participanti din reteau VANET. Argumentatia pentru aceasta afirmatia este aceeasi ca in cazul

-500

0

500

1000

0 10000 20000 30000 40000Nu

ma

r m

esa

je

Timp(ms)



timp

Numar de mesaje



timp

-200

0

200

400

600

800

1000

0 10000 20000 30000 40000

Nu

ma

r m

esa

je *

( D

ime

nsi

un

e

me

saj)

Timp(ms)


Throughput-ul

generat de masini

61

indicatorului “Raportul intre raspunsuri pozitive si negative emise de acest Semafor Securizat”

din scenariul curent.

Fig 5.4.5 Numarul de conexiuni stabilite pe interval periodice de timp


rezista tipului de atac desfasurat in scenariul 2.

0

2

4

6

8

10

12

14

0 10000 20000 30000 40000

Nu

ma

r co

ne

xiu

ni

Timp(ms)


masini

Variatia in timp a

conexiunilor dintre

masini

62

5.5 Scenariul 3

Cel de-al treilea atac implementat consta in introducerea in reteaua VANET a unor

masini atacatoare care modifica continutul unui mesaj dupa ce l-au primit inapoi apendat cu

semnatura digitala de la semaforul securizat si inainte de a-l expedia catre destinatia finala. Rata

de atacatori infiltrati in reteaua ad-hoc vehiculara este de 35%.






-500

0

500

1000

0 10000 20000 30000 40000Nu

ma

r m

esa

je

Timp(ms)

Numar de mesaje generate de masini

la intervale periodice de timp

Numar de mesaje



timp

-200

0

200

400

600

800

1000

0 10000 20000 30000 40000

Nu

ma

r m

esa

je*

(Dim

en

siu

ne

Me

saj)

Timp(ms)


Throughput-ul generat

de masini

63


Comparand graficele atacului curent (modificarea de catre un atacator a continutului unui

mesaj dupa ce l-a primit inapoi apendat cu semnatura digitala de la semaforul securizat si inainte

de a-l expedia catre destinatia finala) cu situatia normala de functionare, se observa ca

pararametrii mentionati nu sufera modificari semnificative.

In cazul numarului de mesaje generat de masini la interval periodice de timp, modificarea de

catre un atacator a continutului unui mesaj dupa ce l-a primit inapoi apendat cu semnatura

digitala de la semaforul securizat si inainte de a-l expedia catre destinatia finala nu influenteaza

cu nimic numarul de mesaje aflate in trafic la un moment dat de timp. In ansamblu, numarul de

mesaje aflate in tranzitie in reteaua VANET in cazul scenariului 3 este acelasi cu numarul de

mesaje aflate in tranzitie in cazul in care in mediu de functionare nu exista nici un atacator de

tipul scenariul actual.

Coroborat cu numarul de mesaje generate de vehicule este si throughput-ul (cei doi indicatori

sunt in relatie de proportionalitate), care, analog cu cele mentionate anterior, este aproximativ

egal cu cel calculat in cazul normal de functionare.


un semafor securizat nu se modifica, semaforul analizand mesajele din partea atacatorilor in

acelasi mod cu a unor pretendenti legitimi.

Graficul 5.5.4 ce caracterizeaza variatia in timp a conexiunilor dintre vehiculele securizate se

modifica semnificativ fata de situatia normala. Dupa cum se observa, panta graficului mentine o

tendinta ascendenta, intrucat semaforele securizate recunosc faptul ca mesajele au fost

modificate de un atacator si trimit raspunsuri negative la automobilul destinatie final.

-5

0

5

10

15

-5 0 5 10 15 20 25

Nu

ma

r M

asi

ni

Numar Mesaje

Numar de mesaje trimise de semaforul

securizat raportat la numarul de masini

Numar de mesaje trimise

de semaforul securizat

raportat la numarul de

masini

64


In cazul raspunsurilor emise de semafor, se pot observa diferente majore fata de situatia

ideala, cand in sistem nu existau atacatori. Graficul 5.5.5 expune comportamentul unui semafor

securizat care prelucreaza cereri de la participantii din trafic (automobile). Raspunsurile negative

au o valoare diferita de zero, in acord cu implementarea propusa: cum in retea exista atacatori,

unele mesaje sunt fraudate, rezulta ca o parte din traficul ce necesita validare de la semafoare

primeste raspuns negativ. Se poate constata ca semafoarele securizate reusesc sa discerne intre

un trafic autentic si unul nelegitim.

Fig 5.5.5Raportul intre raspunsuri pozitive si negative emise


0

2

4

6

8

10

12

14

16

0 10000 20000 30000 40000

Nu

ma

r co

ne

xiu

ni

Timp(ms)


masini

Variatia in timp a

conexiunilor dintre

masini

0

1

2

3

4

5

6

7

0 10000 20000 30000 40000

Nu

ma

r R

asp

un

suri

Timp(ms)

Raspunsuri pozitive

Raspunsuri negative

65

Urmatoarele grafice expun modalitatea in care atacurile declansate in sistem sunt evitate

cu ajutorul semafoarele securizate.


Se observa cum atacurile sunt anulate de semafoarele securizate. Verificand semnatura

apendata mesajului cu partile componente din mesaj care au contribuit la formarea acesteia se

valideaza sau se neaga veridicitatea mesajului primit la semaforul securizat.



0

1

2

3

4

5

6

7

8

9

0 10000 20000 30000 40000

Nu

ma

r a

tacu

ri g

en

era

te

Timp(ms)

Atacuri generate de masini intruse

Atacuri generate de

masini intruse

-2

0

2

4

6

8

10

12

0 10000 20000 30000 40000

Nu

ma

r a

tacu

ri s

top

ate

Timp(ms)

Atacuri stopate de Semafor

Atacuri stopate de

Semafor

66

5.6 Scenariul 4

Cel de-al patrulea atac implementat este o varianta a atacului de tip man-in-the-middle.

Masinile aflate in starea MASINA_INTERMEDIARA isi exercita functia lor de rutare mesaje

pentru alti participanti la trafic, dar modifica continutul pachetului. Cum semaforul nu poate sti

daca mesajul care a ajuns la el pentru a-i apenda semnatura digitala este acelasi cu cel care a

plecat de la sursa, nu poate “vedea” ca acesta a fost modificat. Astfel, singura modalitate de a

preveni situatia curenta este verificarea continutului si semnaturii mesajului la sursa, dupa ce

pachetul a fost reprimit inapoi si inainte de a fi expediat catre masina destinatie finala. Rata de

atacatori infiltrati in reteaua ad-hoc vehiculara este de 35%.




Fig 5.6.1 Numarul de mesaje si throughtput-ul generat de masini

-200

0

200

400

600

0 10000 20000 30000 40000

Nu

ma

r M

esa

je

Timp(ms)

Numar de mesaje generate de masini

la intervale periodice de timp

Numar de mesaje



timp

-200

0

200

400

600

0 10000 20000 30000 40000

Nu

ma

r M

esa

je *

(Dim

en

siu

ne

me

saj)

Timp(ms)


Throughput-ul generat

de masini

67

Numarul de mesaje in trafic raportat la intervale periodice de timp. Indicatorul se

calculeaza astfel: ∆�� ∆�� . Se constata o scadere a numarului de mesaje aflate in trafic

deoarece, in urma unor atacuri precum cele din scenariul actual, masinile nu vor mai putea

avansa in starea CERERE_CONFIRMARE. Acest lucru se datoreaza diferentelor intre textul

initial si continutul primit dupa apendarea semnaturii digitale la masina sursa. Cum mesajul nu se

mai propaga la destinatie, se elimina tot fluxul de mesaje necesare validarii finale.

Throughput-ul generat de masinile securizate in cadrul retelei VANET. Indicatorul de

calculeaza astfel:�( �� ∗ �� ) ∆�� . Acest parametru este direct proportional

cu numarul de mesaje generate de automobile aflate in tranzit, astfel incat acesta va scadea de

asemenea.


Numarul de conexiuni (fig 5.6.2) – numarul curent de mesaje unice ce trebuie transmise

intre sursa si destinatie. Valoarea pastreaza caracteristicile cazului ideal de testare, in care nu

exista atacatori. Argumentul consta in faptul ca atacul este stopat intr-un stadiu incipient, inainte

de a fi expediat de sursa catre destinatia finala.


0

5

10

0 5000 10000 15000 20000

Nu

ma

r co

ne

xiu

ni

Timp(ms)


masini

Variatia in timp a

conexiunilor dintre

masini

-10

0

10

20

-5 0 5 10 15 20 25

Nu

ma

r M

asi

ni

Numar Mesaje



numarul de masini

Numar de mesaje



numarul de masini

68

Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise

de acest semafor (fig 5.6.3). Valoarea raportului este proportionala cu cea din cazul ideal de

functionare (fara atacatori). Cum mesajul este verificat la sursa, in cazul in care este modificat,

va fi rejectat. Altfel, el va fi procesat pe parcursul protocolului in acelasi mod ca in cazul normal

de functionare. In situatia in care exista un atac de tipul scenariului 4, numarul de mesaje emise

de semafor scade deoarece exista mai putine cereri de validare mesaje; rezulta ca numarul de

masini care comunica cu semaforul securizat scade (masina nu va avansa in starea

CERERE_CONFIRMARE, intrucat nu a primit un mesaj, acesta fiind rejectat de sursa in

momentul in care se constanta discrepanta intre textul initial si continutul primit dupa apendarea

semnaturii digitale). In concluzie, raportul dintre numarul de mesaje emise de semafor si

numarul de masini care vor primi aceste mesaje este proportional cu raportul de functionare

ideala.



Raportul intre numarul de raspunsuri pozitive si negative emise de un semafor securizat (fig.

5.6.4). Cum mesajul a fost modificat de-a lungul rutei pana sa fie semnat, semaforul nu poate sti

daca pachetul a fost modificat, trimitand inapoi la sursa mesajul apendat la final cu semnatura

digitala. Daca nu s-ar face verificare cu mesajul initial la sursa inainte de expediere pentru a

verifica daca continutul a fost modificat destinatia va primi o informatie eronata. Informatia

eronata va fi perpetuata pentru validare finala la semafor securizat din apropiere. Cum campurile

falsificate au toate elementele valide (semnatura din final pentru mesajul modificat se potriveste

cu textul fals), mesajul neveridic va primi confirmare si va fi procesat. Ca urmare a celor

mentionate, inainte de a trimite mesajul la destinatia final, sursa face o verificare suplimentare

pentru a se asigura asupra faptului ca textul mesajului transmis spre semnare nu a fost inlocuit la

altul nou.

-2

0

2

4

6

8

10

12

14

16

0 10000 20000 30000 40000

Nu

ma

r R

asp

un

suri

Timp(ms)


Raspunsuri pozitive

Raspunsuri negative

69


Se observa ca atacurile sunt contramandate de vehiculele securizate. Motivatia faptului ca

numarul de atacuri solutionate la masina este mai mic decat numarul efectiv de atacuri din retea

este urmatoare: mesajele transmise de masinile aflate in starea MASINA_INTERMEDIARA

sunt propagate prin difuzare. Mesajul apendat cu semnatura este expediat de semaforul securizat

catre vehiculul sursa sub forma de unicast, o singura data, cu toate ca acesta a primit mai multe

cereri, numarul ridicat de cereri fiind datorat fenomenului de broadcast.



0

5

10

15

20

0 500 1000 1500

Nu

ma

r a

tacu

ri

Timp(ms)

Numar de atacuri generate de

man-in-the-middle car

Numar de atacuri

generate de man-in-

the-middle car

0

1

2

3

4

5

6

7

8

0 10000 20000 30000 40000

Nu

ma

r a

tacu

ri a

nu

late

Timp(ms)

Atacuri anulate de masinile

securizate

Atacuri anulate de

masinile securizate

70

5.7 Scenariul 5

Atacul implementat consta in adaugarea in reteaua VANET a unor masini atacatoare

aflate in strarea de MASINA_INTERMEDIARA care modifica mesajul inainte de a-l ruta catre

semaforul securizat pentru validarea finala. Rata de atacatori infiltrati in reteaua ad-hoc

vehiculara este de 35%.




O parte dintre parametrii colectati la masini pastreaza caracteristicile cazului normal de

functionare, unde nu exista atacatori.


-500

0

500

1000

1500

0 10000 20000 30000 40000

Nu

ma

r m

esa

je

Timp(ms)



timp

Numar de mesaje



timp

-500

0

500

1000

1500

0 10000 20000 30000 40000

Nu

ma

r M

esa

j*(D

ime

sniu

ne

Me

saj)

Timp(ms)


Throughput-ul

generat de masini

71

Numarul de mesaje generate de masini si throughput-ul determinat de acestea sunt intr-o

relatie de proportionalitate directa. Cum atacul consta doar in falsificarea unor informatii in

momentul in care un automobil se afla in starea de MASINA_INTERMEDIARA si ruteaza

mesaje la semaforul securizat pentru validare finala, rezulta ca numarul de mesaje aflate in trafic

nu se modifica fata de cazul normal de functionare (unde nu exista atacatori).


un semafor securizat (fig 5.7.2) nu sufera schimbari semnificative, semaforul analizand mesajele

din partea atacatorilor in acelasi mod ca si in cazul unor pretendenti legitimi.


Graficul ce caracterizeaza variatia in timp a conexiunilor dintre vehiculele securizate (fig

5.7.3) manifesta schimbari semnificative fata de situatia normala. Dupa cum se observa, panta

graficului mentine o tendinta ascendenta, intrucat semaforele securizate recunosc faptul ca

mesajele au fost modificate de un atacator si trimit raspunsuri negative la automobilul destinatie

final.


0

10

20

0 20 40 60

Nu

ma

r M

asi

ni

Numar mesaje



numarul de masini

Numar de mesaje



numarul de masini

0

10

20

30

0 10000 20000 30000 40000

Nu

ma

r co

ne

xiu

ni

Timp(ms)


masini

Variatia in timp a

conexiunilor dintre

masini

72



Verificarea in privinta legitimitatii unui mesaj nu se face doar la semaforul securizat, ci si

la vehiculul care a transmis mesajul pentru validare finala. Astfel, in momentul in care masina va

primi raspunsul final de la semafor, va compara continutul mesajului primit cu o tabela de

dispersie. Daca mesajul respectiv este gasit in tabela de dispersie, raspunsul va fi luat in

considerare, iar intrarea din tabela de dispersie va fi eliberata. O astfel de verificare in cadrul

automobilului securizat justifica si rezistenta in fata unui atac de tip man-in-the-middle, cand un

intrus reuseste sa preia raspunsul final de la semafor, modifica continutul, in cele din urma

expediind mesajul fals la destinatia legitima.

Fig 5.7.5 Atacuri generate de masini intruse

0

5

10

15

20

25

30

35

0 10000 20000 30000 40000

Nu

ma

r ra

spu

nsu

ri

Timp(ms)


Raspunsuri pozitive

Raspunsuri negative

0

500

1000

1500

2000

2500

3000

0 10000 20000 30000 40000

Nu

ma

r a

tacu

ri g

en

era

te

Timp(ms)

Atacuri generate de masini intruse

Atacuri generate de

masini intruse

73

Fig 5.7.6 Atacuri respinse de masinile securizate

Reprezentarile grafice anterioare (fig. 5.7.5, 5.7.6) expun rezistenta unui vehicul securizat

la atacul curent desfasurat. Diferenta intre numarul de atacuri respinse de o masina si numarul de

atacuri generate de un intrus are urmatoarea motivatie: atacul actual se desfasoara pentru

autovehicule aflate in starea de MASINA_INTERMEDIARA care ruteaza mesaje la semafor

pentru validare finala. Aceasta etapa din protocol este caracterizata de transmisiuni de tip

difuzare, astfel mesajul corupt generat de o masina va fi propagat si de vecinii acesteia,

multipland rata. Numarul mai mic de atacuri respinse de masina securizata este datorat faptului

ca masina primeste de la semafor un singur raspuns expediat unicast pe care va face verificarile

de riguroare mentionate anterior. Daca semaforul primeste aceeasi cerere de mai multe ori, el va

procesa doar una si va trimite un raspuns catre masina securizata o singura data.



0

200

400

600

800

0 10000 20000 30000 40000

Nu

ma

r a

tacu

i re

spin

se

Timp(ms)

Atacuri respinse de masinile

securizate

Atacuri respinse de

masinile securizate

74

5.8 Scenariul 6

Un alt tip de atac este Denial Of Sevice. Mai multi atacatori stabilesc o tinta spre care vor

indrepta tot traficul lor de date. Mesajele trimise de la sursele intrus catre tinta aleasa pot fi atat

unele legitime, cat si unele nelegitime.

Comportamentul protocolului in acest caz este urmatorul: masina securizata destinatie

mentine o tabela de dispersie continand sursa de la care a primit mesajele si coada de mesaje. In

cazul in care tabela de dispersie depaseste un anumit grad de incarcare, mesajele ulterior primite

vor fi rejectate pana cand se fac toate verificarile pentru mesajele curente din tabela. Pe masura

ce un mesaj este procesat, intrarea proprie acestuia va fi eliminata din tabela, in locul ei

adaugandu-se un nou mesaj ce trebuie prelucrat.





0

500

1000

0 20000 40000 60000

Nu

ma

r m

esa

je

Timp(ms)



timp

Numar de mesaje



timp

0

500

1000

1500

0 20000 40000 60000

Nu

ma

r m

esa

je*

(Dim

en

siu

ne

me

saj)

Timp(ms)


Throughput-ul

generat de masini

75

Numarul de mesaje generate de masini si throughput-ul sufera fluctuatii semnificative in

momentul in care atacul este in desfasurare. Masina destinatie va primi mesaje de la atacatori si

va incerca sa valideze respectivele pachete. In acel moment, traficul din retea se va intensifica,

existand prelucrari intensive atat la automobilul securizat, cat si la semaforul care verifica

legitimitatea mesajelor. Gradul limitat de saturare a tabelei de dispersie stopeaza explozia de

mesaje si niveleaza traficul. Cu toate ca o parte din mesaje vor fi rejectate, marea majoritate a

pachetelor destinate unui participant din trafic sunt prelucrate corespunzator.


Graficul 5.8.2 caracterizeaza variatia in timp a conexiunilor dintre vehiculele securizate.

Fluctuatiile existente in reprezentarea grafica sunt datorate masinilor care initiaza noi

transmisiuni cu restul vehiculelor din trafic, panta capatand aspect descendent in momentul in

care mesajele ajung la destinatie si sunt confirmate. Atacul de tip Denial of Service nu modifica

semnificativ variatia in timp a conexiunilor dintre masini, intrucat tipul de atac considerat este

exercitat doar asupra unui singur automobil tinta.


0

5

10

15

20

0 20000 40000 60000Nu

ma

r co

ne

xiu

ni

Timp(ms)

Variatia in timp a conexiunilor

dintre masini

Variatia in timp a

conexiunilor dintre

masini

0

10

20

30

0 10 20 30 40

Nu

ma

r m

asi

ni

Numar mesaje



numarul de masini

Numar de mesaje



numarul de masini

76

Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise

de un semafor securizat (fig 5.8.3) nu se modifica, semaforul analizand mesajele din partea

atacatorilor in acelasi mod ca si in cazul unor pretendenti legitimi.

Fig 5.8.4 Raportul intre raspunsuri pozitive si negative

emise de acest Semafor Securizat

Numarul de raspunsuri pozitive si negative (fig 5.8.4) flucteaza in functie de

legitimitatea mesajelor trimise de atacatori. Cum exista atacatori in sistem care vizeaza o singura

masina gazda si trimit mesaje nelegitime catre aceasta, in etapa de validare, semaforul va indica

vehiculului atacat raspunsuri negative.

Comportamentul unei masini tinta in cazul unui atac de tip Denial of Service este

urmatorul: masina securizata mentine o tabela de dispersie continand sursa de la care a primit

mesajele si coada de mesaje. In cazul in care tabela de dispersie depaseste un anumit grad de

incarcare, mesajele ulterior primite vor fi rejectate pana cand se fac toate verificarile pentru

mesajele curente din tabela. Pe masura ce un mesaj este procesat, intrarea proprie acestuia va fi

eliminata din tabela, in locul ei adaugandu-se un nou mesaj ce trebuie prelucrat.



0

5

10

15

20

0 20000 40000 60000

Nu

ma

r ra

spu

nsu

ri

Timp(ms)

Raspunsuri emise de semaforul securizat in

timp

Raspunsuri pozitive

Raspunsuri negative

77

5.9 Analiza rezultatelor

Analizand rezultatele prezentate anterior cu privire la functionarea protocolului intr-un

mediu ideal (fara intrusi), precum si intr-un mediu cu masini malitioase, se observa comportarea

corecta si in conditii diverse a protocolului implementat.

Realizand comparatia cu o transmisie simpla, nesecurizata de mesaje, protocolul

implementat impune o incarcare suplimentara a retelei.

Transmisia unui mesaj intre doua masini securizate impune un overhead in mediul

VANET fata de o transmisia normala. Incarcatura aditionala in cadrul protocolului securizat este

datorata apendarii la sfarsitul mesajului a semnaturii digitale.

Cum semnatura digitala se constituie doar pe baza campurilor mesaj, locatie, stampila de

timp, overheadul adaugat mesajului este urmatorul:

overhead = ��ℎ��_�� _�� ℎ��_�� _�� =

= ��ℎ�� (��ℎ�� + �� _�� )�

In urma testelor efectuate, valoarea determinata pentru acest parametru a fost de 28%.

Timpul de transmisie suplimentar alocat pentru comunicatia dintre masini, luand in

considerare semnarea unui mesaj la un semafor securizat inainte de transmisie si validarea

mesajului, la receptie, prin intermediul infrastructurii, este:

Timp_suplimentar = �� _�� _�� _�� _��

= �� !��!�� (�� !��!�� + 2 ∗ �� !��#� )�

In urma testelor efectuate, valoarea determinata pentru acest parametru a fost de 29%.

In concluzie, raportat la rezultatele experimentelor anterioare, se poate afirma ca solutia

de securitate propusa poate fi folosita cu succes pentru transmiterea sigura a mesajelor in medii

VANET in prezenta unor riscuri potentiale de securitate dintre cele mai variate. Pe langa

corectitudine, se poate observa ca protocolul propus conduce si la rezultate optime in ceea ce

priveste numarul de mesaje necesare, timpul de transmisie sau incarcarea retelei wireless si a

participantilor la trafic.

78

Capitolul 6 – Concluzii

Retelele de tip VANET (Vehicular Ad-Hoc Networks) sunt un caz particular al retelelor

wireless ad-hoc. Aceste retele se formeaza prin echiparea vehiculelor cu dispozitive cu raza mica

pentru comunicatie wireless. Dezvoltarea de aplicatii si protocoale pentru retele VANET pune

probleme de securitate unice, induse de dispozitivele utilizate, de conectivitatea sporadica a

vehiculelor, de gradul inalt de relevanta dat de descoperirea locatiei lor geografice.

In cadrul lucrarii a fost prezentat un protocol de asigurare a securitatii in cadrul retelelor

VANET (Vehicular Ad-Hoc Networks). Motivatia principala a proiectului este legata de lipsa

unor mecanisme adecvate standardizate de asigurare a proprietatii de securitate in mediile

vehiculare ad-hoc existente astazi. In acest moment se constata o grava lipsa de mecanisme de

detectie a unor posibile atacuri, precum si inexistenta mijloacelor de neutralizare a acestora.

Solutiile dezvoltate pana acum nu acopera toate aspectele specifice securitatii, nefiind inca

standardizate si acceptate in randul comunitatii stiintifice.

In acest context protocolul de securitate prezentat ofera o solutie pentru retelele VANET.

Modelul propus a fost implementat si testat folosind simulatorul VNSim, simulator dezvoltat in

cadrul Universitatii Politehnica Bucuresti, Facultatea de Automatica si Calculatoare.

Solutia pentru securitate expusa in cadrul lucrarii se bazeaza pe pozitia vehiculelor in

momentul transmiterii mesajelor, momentul de timp la care se petrece emisia, autoritatile de

certificare existente in zona in momentul inceperii transmiterii de informatii in mediul VANET

urmarind crearea unei posibilitati de securizare a transmiterii mesajelor.

Protocolul este conceput pentru medii puternic partitionate, suferind de o mare

dinamicitate de conectare a nodurilor in cadrul retelelor. Protocolul este modular, scalabil, fiind

structurata pe mai multe stari. Componentele principale participante sunt entitatea Autovehicul (

SecCar) si entitatea Semafor (SecCittyTrafficLight). Transmiterea de mesaje securizate intre

masinile aflate in trafic se face in functie de existenta unei entitati de certificare prezente in zona,

de distanta dintre autovehicule care vor sa comunice, de traiectoria pe care acestea se deplaseaza,

de faptul ca autovehiculul destinatie este in raza de transmisie sau de necesitatea selectarii unei

rute ce include mai multe hopuri in vederea transmiterii mesajelor.

Rezultatele obtinute in cadrul lucrarii demonstreaza corectitudinea si validitatea

protocolului de securitate propus. Scenariile de test executate au urmarit evaluarea diferitelor

aspecte ale securitatii. De altfel, prin rezultatele obtinute se reitereaza functionarea corecta a

protocolului prezentat si a implementarii acestuia.

Protocolul prezentat acopera urmatoarele aspecte generale privitoare la securitate:

� Confidentialitate (pastrarea secretului) – se refera la pastrarea informatiei departe de

utilizatorii neautorizati.

79

� Integritatea – informatia poate fi modificata doar de utilizatorii autorizati sau in

modalitate autorizata (asigura ca mesajul primit nu a fost modificat in tranzit sau

masluit). Integritatea acopera atat integritatea datelor, cat si integritatea originii

(verificata prin autentificare sau determinarea identitatii partenerului cu care schimbi

mesaje inainte de a dezvalui informatii importante)

� Disponibilitatea – accesul la informatie a utilizatorilor autorizati nu este ingradit (opusul

este denial of service).

� Controlul accesului – reprezinta protectia impotriva accesului ne-autorizat

� Non-repudierea – prin care se asigura ca transmitatorul nu poate nega transmiterea unui

mesaj pe care un receptor l-a primit deja.

Pe viitor se vor avea in vedere o serie de extinderi ale protocolului dezvoltat. Cel mai

important aspect care poate fi exploatat este incercarea reducerii comunicatiei intre masinile si

semafoarele securizare, mutand partea de semnare si validare a mesajelor specifica semafoarelor

securizate pe masinile securizate.

80

Bibliografie

[1] Proiectul CAR-2-CAR, accesibil la http://www.car-2-car.org/.

[2] Proiectul Secure Vehicular Communication accesibil la: http://www.sevecom.org/.

[3] Proiectul 5.9 GHz DSRC accesibil la :http://grouper.ieee.org/groups/scc32/dsrc/.

[4] Raya, M. and Hubaux, Securing vehicular ad hoc networks. J. Comput. Secur. 15, 1, pp. 39-

68, Jan. 2007.

[5] Trusted Platform Module (TPM) https://www.trustedcomputinggroup.org/groups/tpm/.

[6] Draft Standard for Wireless Access in Vehicular Environments – Security Services for

Applications and Management Messages, IEEE P1609.2/D2 , November 2005.

[7] J. Blum and A. Eskandarian, The threat of intelligent collisions, IT Professional 6(1), pp 24–

29, 2004.

[8] C. Boyd and A. Mathuria, Protocols for Authentication and Key Establishment, Springer,

2003.

[9] S. Duri, M. Gruteser, X. Liu, P. Moskowitz, R. Perez, M. Singh and J.-M. Tang, Framework

for security and privacy in automotive telematics, in: Proceedings of the 2nd International

Workshop onMobile Commerce, pp. 25–32, 2002.

[10] S. Eichler, J. Billion, R. Maier, H.-J. Voegel and R. Kroh, On providing security for an

open telematicsplatform, in: Proceedings of the 5th International Conference on ITS

Telecommunications, 2005.

[11] P. Enge, Retooling the Global Positioning System, Scientific American , May 2004.

[12] W. Enkelmann, FleetNet - Applications for inter-vehicle communication, in: Proceedings of

the IEEE Intelligent Vehicles Symposium, pp. 162–167, 2003.

[13] I. Furgel and K. Lemke, A review of the digital tachograph system, in: Proceedings of the

Workshop on Embedded Security in Cars , 2004.

[14] M. Gerlach, VaneSe, An approach to VANET security, in Proceedings of V2VCOM’05,

2005.

[15] L. Gollan and C. Meinel, Digital signatures for automobiles, in: Proceedings of Systemics,

Cybernetics and Informatics (SCI), 2002.

[16] P. Golle, D. Greene and J. Staddon, Detecting and correcting malicious data in VANETs,

in: Proceedingsof VANET, pp. 29–37, 2004.

[17] H. Harney and C. Muckenhirn, Group Key Management Protocol (GKMP) architecture,

RFC 2094, 1997.

[18] Y.-C. Hu and A. Perrig, A survey of secure wireless ad hoc routing, IEEE Security &

Privacy 2(3), pp. 28–39, 2004.

[19] Y.-C. Hu, A. Perrig and D. Johnson, Ariadne: a secure on-demand routing protocol for ad

hoc networks, in: Proceedings of Mobicom, pp. 12–23, 2002.

[20] Y.-C. Hu, A. Perrig and D.B. Johnson, Packet leashes: A defense against wormhole attacks

in wireless networks, in: Proceedings of IEEE Infocom’03, 2003.

[21] J.-P. Hubaux, S. Capkun and J. Luo, The security and privacy of smart vehicles, IEEE

Security and Privacy Magazine 2(3), pp. 49–55, 2004.

[22] M. Jakobsson, Privacy vs. Authenticity, PhD thesis, University of California at San Diego,

1997.

81

[23] D. Jungels, M. Raya, I. Aad and J.-P. Hubaux, Certificate revocation in vehicular ad hoc

networks, EPFL, 2006.

[24] M. Kuhn, An asymmetric security mechanism for navigation signals, in: Proceedings of the

6th Information Hiding Workshop, 2004.

[25] A.K. Lenstra and E.R. Verheul, Selecting cryptographic key sizes, Journal of Cryptology

14(4), pp 255–293, 2001.

[26] M. Lott, R. Halfmann, E. Schultz and M. Radimirsch, Medium access and radio resource

management for ad hoc networks based on UTRA TDD, in: Proceedings of Mobihoc, pp. 76–86,

2001.

[27] K. Matheus, R. Morich, I. Paulus, C. Menig, A. Lübke, B. Rech and W. Specks, Car-to-Car

Communication – Market introduction and success factors, in: Proceedings of ITS’05: 5th

European Congress and Exhibition on Intelligent Transport Systems and Services, 2005.

[28] M. Mauve, J. Widmer and H. Hartenstein, A survey on position-based routing in mobile ad

hoc networks, IEEE Network 15(6), pp. 30–39, 2001.

[29] B. Parno and A. Perrig, Challenges in securing vehicular networks, in: Proceedings of the

Workshop on Hot Topics in Networks (HotNets-IV), 2005.

[30] A. Perrig, R. Canetti, J.D. Tygar and D. Song, The TESLA broadcast authentication

protocol, in: Proceedings of RSA CryptoBytes’02, 2002.

[31] S. Rafaeli and D. Hutchison, A survey of key management for secure group communication,

ACM Computing Surveys 35(3), pp. 309–329, 2003.

[32] M. Raya, A. Aziz and J.-P. Hubaux, Efficient secure aggregation in VANETs, in:

Proceedings of VANET’06, 2006.

[33] M. Raya and J.-P. Hubaux, The security of vehicular ad hoc networks, in: Proceedings of

SASN’05, pp. 11–21, 2005.

[34] K. Sampigethaya, L. Huang, M. Li, R. Poovendran, K. Matsuura and K. Sezaki, CARAVAN:

providing location privacy for VANET, in: Proceedings of the Workshop on Embedded Security

in Cars(escar), 2005.

[35] P. Samuel, Of sticker tags and 5.9 GHz, in: ITS International, 2004.

[36] A. Shamir, How to share a secret, Communications of the ACM 22(11), pp. 612–613, 1979.

[37] D. Shaw and W. Kinsner, Multifractal modelling of radio transmitter transients for

classification,in Proceedings of WESCANEX’97: Communications, Power and Computing, 1997.

[38] J.S. Warner and R.G. Johnston, Think GPS cargo tracking = high security? Think again,

Technical report, Los Alamos National Laboratory, 2003.

[39] M. Wolf, A. Weimerskirch and C. Paar, Security in automotive bus systems, in: Proceedings

of the Workshop on Embedded Security in Cars (escar), 2004.

[40] Q. Xu, T. Mak, J. Ko and R. Sengupta, Vehicle-to-vehicle safety messaging in DSRC, in:

Proceedings of VANET’04, pp. 19–28, 2004.

[41] X. Yang, J. Liu, F. Zhao and N. Vaidya, A vehicle-to-vehicle communication protocol for

cooperative collision warning, in: Proceedings of MobiQuitous, 2004.

[42] Stefan Saroiu, Alec Wolman, Enabling New Mobile Applications with Location Proofs,

Proceedings of the 10th workshop on Mobile Computing Systems and Applications, California,

2009

[44] Andrew S. Tanenbaum – Computer Networks, fourth Edition - 2005

[45] Matthias Gerlach, Andreas Festag, Tim Leinmuller, Gabriele Goldacker,Charles Harsch -–

Security Architecture for Vehicular Communication - Fourth International Workshop on

Intelligent Transportation , WIT Hamburg, 2007

82

[46] Mario Gerlay, Roberto G. Cascella, Zhen Caoy, Bruno Crispo,Roberto Battiti, An efficient

weak secrecy scheme for network coding data dissemination in VANET, in Proceedings of the

IEEE 19th International Sympossium on Personal, Indoor and Mobile Radio Communications,

PIMRC, Cannes, France, 15-18 Septembre 2008.

Date post:	06-Feb-2018
Category:	Documents
Upload:	dangnga
View:	238 times
Download:	0 times

PROIECT DE LICENTA - cipsm.hpc.pub.rocipsm.hpc.pub.ro/documentation/Catalin_Gosman.pdf · In stiva...

Documents