proiect de licenta - cipsm.hpc.pub.rocipsm.hpc.pub.ro/documentation/catalin_gosman.pdf · in stiva...
TRANSCRIPT
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
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
forma unui mesaj de difuzare (broadcast). In momentul receptionarii beaconului,
autovehiculul va transmite semaforului un pachet de date continand informatii ce trebuiesc
Luand in considerare mobilitatea specifica in retelele VANET si aria restransa de
transmitere pe care o are o masina, transmiterea mesajului pentru a fi semnat de catre semafor
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
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 zona sa de
broadcast). In momentul receptionarii beaconului,
autovehiculul va transmite semaforului un pachet de date continand informatii ce trebuiesc
in retelele VANET si aria restransa de
transmitere pe care o are o masina, transmiterea mesajului pentru a fi semnat de catre semafor
� 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
prin intermediul unor masini intermediare pana ajunge la semaforul care a emis beaconul.
Informatiile importante continute in pachet sunt amprenta de timp pentru momentul in
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
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
ie 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.2.2 Comunicatie masina – masina
In momentul in care mesajul ajunge la destinatie, masina destinatie trebuie sa valideze
l prelucra. Modalitatea prin care se poate verifica un mesaj la
destinatie este trimiterea acestuia la un semafor din imediata proximitate. Semafoarele pot
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
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,
prin intermediul unor masini intermediare pana ajunge la semaforul care a emis beaconul.
nt amprenta de timp pentru momentul in
care se transmite mesajul, locatia curenta si mesajul efectiv. Toate aceste informatii vor fi
In momentul in care masina primeste inapoi de la semafor mesajul impreuna cu
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
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
ie nu se afla in aria de acoperire a masinii emitente sursa, astfel mesajul
este rutat cu ajutorul masinilor intermediare existente catre destinatia finala
In momentul in care mesajul ajunge la destinatie, masina destinatie trebuie sa valideze
l prelucra. Modalitatea prin care se poate verifica un mesaj la
e. Semafoarele pot
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
(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
Validarea datelor se poate face doar la semafor, acesta verificand semnatura mesajului si
campurile aferente din care a fost constituita semnatura. Rezultatul verificarilor va fi transmis
masinii care a cerut validarea. In cazul in care raspunsul este afirmativ, mesajul poate fi prelucrat
in continuare; altfel, acesta este discardat.
Verificare unui mesaj de catre un secmafor securizat
Locatia este un camp foarte important care certifica faptul ca transmitatorul mesajului se
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
probeze amplasamentul. Cel mai simplu si mai sigur mod de a verifica aspectul ce priveste
locatia este infrastructura existenta. Masinile cer o validare a locatiei de la infrastructura
(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 pozitionarii geografice
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 acestei abordari, intrucat mesajele astfel semnate de
semafoarele securizate pot fi folosite intr-o multitudine de servicii.
In privinta performantelor protocolului, se observa o validare foarte riguroasa, atat la
sursa, cat si la destinatie pentru fiecare mesaj.
mai multe hopuri (masini intermediarea), in cazul in care nu
Validarea datelor se poate face doar la semafor, acesta verificand semnatura mesajului si
carilor va fi transmis
masinii care a cerut validarea. In cazul in care raspunsul este afirmativ, mesajul poate fi prelucrat
Verificare unui mesaj de catre un secmafor securizat
Locatia este un camp foarte important care certifica faptul ca transmitatorul mesajului se
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
probeze amplasamentul. Cel mai simplu si mai sigur mod de a verifica aspectul ce priveste
. Masinile cer o validare a locatiei de la infrastructura
(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
itionarii geografice.
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
stei abordari, intrucat mesajele astfel semnate de
In privinta performantelor protocolului, se observa o validare foarte riguroasa, atat la
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
Diagrama de transitii prin care poate trece o masina este prezentata mai jos:
.3.1 Stari specifice Masinii Securizate
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
Semafoarele securizate din retea transmit din secunda in secunda beaconuri periodice in
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 starea VERIFICARE_MESAJ nu se exclud,
Diagrama de transitii prin care poate trece o masina este prezentata mai jos:
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
a in secunda beaconuri periodice in
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,
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
dimpotriva, emiterea beaconurilor se face independent de faptul ca un mesaj a ajuns la semafor
In momentul in care semaforul se afla in starea VERIFICARE_MESAJ, el trebuie sa
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
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
dimpotriva, emiterea beaconurilor se face independent de faptul ca un mesaj a ajuns la semafor
In momentul in care semaforul se afla in starea VERIFICARE_MESAJ, el trebuie sa
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
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.
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 discrete. Colaborarea
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 GPS.
Fig 4.1.1 Arhitectura VNSIM
folosind limbajul de programare Java, prin
In cadrul capitolului se prezinta detalii privind extensiile si
Simulatorul de trafic VNSIM este un proiect dezvoltat in cadrul Universitatii Politehnica
din Bucuresti, fiind destinat aplicatiilor concentrate pe VANET (Vehicular Ad-Hoc Network).
discrete. Colaborarea
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
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
In cadrul implementarii propuse exista doua tipuri de entitati: entitatea SecCar (masina
securizata) si entitatea SecCittyTrafficLight (semafor securizat). Cele doua tipuri de entitati sunt
hoc: masinile securizate sunt noduri mobile, caracterizate de un
puternic dinamism, iar semafoarele securizate sunt noduri fixe, parte din infrastructura rutiera.
.1 Diagrama de pachete necesare protocolui de securitate
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.
In cadrul implementarii propuse exista doua tipuri de entitati: entitatea SecCar (masina
securizata) si entitatea SecCittyTrafficLight (semafor securizat). Cele doua tipuri de entitati sunt
hoc: masinile securizate sunt noduri mobile, caracterizate de un
puternic dinamism, iar semafoarele securizate sunt noduri fixe, parte din infrastructura rutiera.
Diagrama de pachete necesare protocolui de securitate
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.
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
primite. Pentru o mai clara intelegere a etapelor prin care trece masina, aceasta a fost
reprezentata diferit in mod grafic pe harta digitala din simulator.
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
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 semafor continand, printre altele, si cheia l
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
Diagrama de clasa pentru Masina Securizata SecCar
primite. Pentru o mai clara intelegere a etapelor prin care trece masina, aceasta a fost
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
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
lui publica.
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 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
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
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.
Alte metode auxiliare convertStringToByteArray(..) si convertByteArraytoString(…) fac
conversia directa si inversa intre un array de bytes si un string.
Digrama de clasa pentru Semaforul Securizat
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
Metoda createSignature(PrivateKey key, byte[] buffer) returneaza semnatura pentru
Metoda verifySignature(PublicKey key, byte[] buffer, byte[] signature) verifica
ul de bytes buffer folosind cheia publica a
care returneaza cheia publica
rizat curent sa le
Alte metode auxiliare convertStringToByteArray(..) si convertByteArraytoString(…) fac
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
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
Clasa SecMessage reprezinta clasa ce implementeaza mesajele specifice protocolului de
Clasa contine metode de tip setter si getter pentru toate atributele specifice mesajului.
Diagrama de clasa pentru clasa SecMessage
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 pana sa fie
acelasi timp, este mentinuta si o stampila de timp care ajuta la retransmisia unor mesaje in cazul
Clasa SecMessage reprezinta clasa ce implementeaza mesajele specifice protocolului de
Clasa contine metode de tip setter si getter pentru toate atributele specifice mesajului.
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
pana sa fie rejectat. In
acelasi timp, este mentinuta si o stampila de timp care ajuta la retransmisia unor mesaje in cazul
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 SecureGlobals reprezinta clasa ce contine constantele finale specific protocolului
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
Clasa SecureGlobals reprezinta clasa ce contine constantele finale specific protocolului
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
Experimentele au fost rulate pe simulatorul VNSim, descris in Capitolul 3 a lucrarii.
Rezultatele prezentate in continuare ofera indicatori care exprima fiabilitatea protocolului
Datele experimentale colectate au fost prelucrate folosind un scenariu urban, campusul
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
Experimentele au fost rulate pe simulatorul VNSim, descris in Capitolul 3 a lucrarii.
fiabilitatea protocolului
Datele experimentale colectate au fost prelucrate folosind un scenariu urban, campusul
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.
Fig 5.3.1 Numarul de mesaje aflate in tranzit generat de masini
Fig 5.3.2 Throughput-ul generat de vehiculele securizate
-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
Fig 5.3.3 Gradul de incarcare al semaforului raportat la conditiile de trafic
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
trimise de semaforul
securizat raportat la
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)
Variatia in timp a conexiunilor dintre
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 emise de semaforul securizat in timp
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%.
Indicatorii caracteristici protocolului de securitate implementat prezentati pentru
comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 2, facand observatiile de
riguroare specifice tipului de atac desfasurat in acest caz.
Fig 5.4.1 Raportul intre raspunsuri pozitive si negative emise
de acest Semafor Securizat
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.
Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise de
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.
Fig 5.4.2 Gradul de incarcare al semaforului raportat la conditiile de trafic
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
Numar de mesaje trimise de
semaforul securizat raportat la
numarul de masini
Numar de mesaje
trimise de semaforul
securizat raportat la
numarul de masini
60
Fig 5.4.3 Numarul de mesaje aflate in tranzit generat de masini
Fig 5.4.4 Throughput-ul generat de vehiculele securizate
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)
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 10000 20000 30000 40000
Nu
ma
r m
esa
je *
( D
ime
nsi
un
e
me
saj)
Timp(ms)
Throughput-ul generat de masini
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
Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa
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)
Variatia in timp a conexiunilor dintre
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%.
Indicatorii caracteristici protocolului de securitate implementat prezentati pentru
comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 3, facand observatiile de
riguroare specifice tipului de atac desfasurat in acest caz.
Fig 5.5.1 Numarul de mesaje aflate in tranzit generat de masini
Fig 5.5.2 Throughput-ul generat de vehiculele securizate
-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
generate de masini la
intervale periodice de
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
Throughput-ul generat
de masini
63
Fig 5.5.3 Gradul de incarcare al semaforului raportat la conditiile de trafic
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.
Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise de
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
Fig 5.5.4 Numarul de conexiuni stabilite pe intervale periodice de timp
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
de acest Semafor Securizat
0
2
4
6
8
10
12
14
16
0 10000 20000 30000 40000
Nu
ma
r co
ne
xiu
ni
Timp(ms)
Variatia in timp a conexiunilor dintre
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.
Fig 5.5.6 Depistare si contracarare atacuri
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.
Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa
rezista tipului de atac explicat in scenariul 3.
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%.
Indicatorii caracteristici protocolului de securitate implementat prezentati pentru
comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 4, facand observatiile de
riguroare specifice tipului de atac desfasurat in acest caz.
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
generate de masini la
intervale periodice de
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
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.
Fig 5.6.2 Numarul de conexiuni stabilite pe intervale periodice de timp
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.
Fig 5.6.3 Gradul de incarcare al semaforului raportat la conditiile de trafic
0
5
10
0 5000 10000 15000 20000
Nu
ma
r co
ne
xiu
ni
Timp(ms)
Variatia in timp a conexiunilor dintre
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
Numar de mesaje trimise de
semaforul securizat raportat la
numarul de masini
Numar de mesaje
trimise de semaforul
securizat raportat la
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.
Fig 5.6.4 Raportul intre raspunsuri pozitive si negative emise
de acest Semafor Securizat
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 emise de semaforul securizat in timp
Raspunsuri pozitive
Raspunsuri negative
69
Fig 5.6.5 Depistare si contracarare atacuri
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.
Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa
rezista tipului de atac explicat in scenariul 4.
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%.
Indicatorii caracteristici protocolului de securitate implementat prezentati pentru
comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 5, facand observatiile de
riguroare specifice tipului de atac desfasurat in acest caz.
O parte dintre parametrii colectati la masini pastreaza caracteristicile cazului normal de
functionare, unde nu exista atacatori.
Fig 5.7.1 Numarul de mesaje si throughtput-ul generat de masini
-500
0
500
1000
1500
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
generate de masini la
intervale periodice de
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
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).
Raportul intre numarul de automobile care fac diverse cereri si numarul de mesaje emise de
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.
Fig 5.7.2 Gradul de incarcare al semaforului raportat la conditiile de trafic
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.
Fig 5.7.3 Numarul de conexiuni stabilite pe intervale periodice de timp
0
10
20
0 20 40 60
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
0
10
20
30
0 10000 20000 30000 40000
Nu
ma
r co
ne
xiu
ni
Timp(ms)
Variatia in timp a conexiunilor dintre
masini
Variatia in timp a
conexiunilor dintre
masini
72
Fig 5.7.4 Raportul intre raspunsuri pozitive si negative emise
de acest Semafor Securizat
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 emise de semaforul securizat in timp
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.
Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa
rezista tipului de atac explicat in scenariul 5.
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.
Indicatorii caracteristici protocolului de securitate implementat prezentati pentru
comportamenul ideal (fara atacatori) vor fi expusi si pentru scenariului 6, facand observatiile de
riguroare specifice tipului de atac desfasurat in acest caz.
Fig 5.8.1 Numarul de mesaje si throughtput-ul generat de masini
0
500
1000
0 20000 40000 60000
Nu
ma
r 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
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
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.
Fig 5.8.2 Numarul de conexiuni stabilite pe intervale periodice de timp
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.
Fig 5.8.3 Numarul de conexiuni stabilite pe intervale periodice de timp
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
Numar de mesaje trimise de
semaforul securizat raportat la
numarul de masini
Numar de mesaje
trimise de semaforul
securizat raportat la
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.
Avand in vedere toate cele mentionate mai sus, ajungem la concluzia ca solutia propusa
rezista tipului de atac explicat in scenariul 6.
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.