Elaborato Iandolo Luca N46001245

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori
Security e Trustiness in scenari di Smart
Mobility: il caso del progetto S2-Move
Anno Accademico 2012/2013
Candidato:
Luca Iandolo
matr. N46/1245
Indice
Introduzione
4
Capitolo 1. Sicurezza in scenari di Smart Moblity
6
1.1
1.2
1.3
Sicurezza
Privacy
Trust
6
7
8
Capitolo 2. Vehicular Ad-hoc Network
2.1
2.2
2.3
2.4
10
IEEE 1609.2
Pseudonimi e chiavi di gruppo
Trust models
Trusted routing
12
14
16
18
Capitolo 3. Wireless Sensor Networks
3.1
3.1.1
3.2
20
Protocolli di sicurezza
Protocolli di sicurezza a chiave asimmetrica
Trusted routing
21
24
24
Capitolo 4. S2-Move
4.1
27
Soluzione proposta
29
Conclusioni
Bibliografia
32
33
III
2
Security e Trustiness in scenari di Smart Mobility: il caso del progetto S -Move
Introduzione
Con il continuo evolversi delle tecnologie dell’informazione e della comunicazione (ICT)
è diventato possibile sviluppare tipologie di applicazioni innovative che hanno permesso
lo sviluppo delle cosiddette Smart City. L'espressione Smart City indica, in senso lato, un
ambiente urbano in grado di agire attivamente per migliorare la qualità della vita dei
propri cittadini grazie all'impiego diffuso e innovativo delle ICT, in particolare nei campi
della comunicazione, della mobilità, dell'ambiente e dell'efficienza energetica.
In questo lavoro di tesi ci si soffermerà sulla mobilità e sul concetto, quindi, di Smart
Mobility.
In ambienti Smart City il termine mobilità non si riferisce solamente alla capacità di
spostarsi da un punto all’altro della città, bensì include un nuovo insieme di servizi quali
applicazioni per la gestione del traffico, per lo smart parking, per la gestione dei trasporti
pubblici e così via, che possono offrire una migliore qualità del viaggio e una maggiore
sicurezza ai cittadini.
In uno scenario di Smart Moblity dunque, un cittadino alla guida di un auto potrà essere
avvertito della presenza di un ingorgo o di un incidente lungo la strada, potrà essere
aiutato nella ricerca e nel pagamento di un parcheggio, oppure si potrà salvaguardare la
sicurezza dei pedoni imponendo un limite di velocità alle auto in transito in zone sensibili
(come ad esempio nei pressi delle scuole).
Per rendere possibile tutto ciò c’è bisogno di tecnologie che permettano un efficiente
4
2
raccolta delle informazioni e la loro diffusione. Le auto verranno dunque dotate di
dispositivi che permettano la raccolta e la trasmissione di informazioni riguardanti le
condizioni della strada e la velocità, l’ accelerazione e la posizione del veicolo e queste
informazioni saranno raccolte anche da reti capillari di sensori inserite nel tessuto urbano.
Questo lavoro di tesi si occuperà principalmente degli aspetti di security e trustiness in
scenari di Smart Moblity. Dopo una breve panoramica generale sulle problematiche di
sicurezza che l’utilizzo di queste tecnologie comporta, si andranno dunque a esaminare
nello specifico gli aspetti di sicurezza e trustiness nell’ambito delle reti veicolari e in
quelle di sensori, per poi andare a esaminare una implementazione concreta di un sistema
di gestione del traffico, il progetto S2-Move, e come sia possibile rendere sicura questa
soluzione.
5
2
Capitolo 1
Sicurezza in scenari di Smart Moblity
Oggigiorno più del 50% della popolazione mondiale vive in arie urbane e questa
percentuale è destinata a salire fino al 70% nel 2050. Visto il ruolo centrale delle città
nell’economia, nella politica e nella vita sociale, garantire una mobilità innovativa,
efficiente e sicura è una sfida non da poco. In uno scenario di Smart Mobility le
informazioni che viaggiano nella rete contengono informazioni relative alla posizione e al
comportamento degli utenti della rete stessa, ed è necessario, dunque, assicurare, oltre ad i
soliti requisiti di sicurezza, quali confidenzialità, integrità, autenticazione e disponibilità,
anche la privacy degli utenti e bisogna introdurre dei meccanismi che permettano la
valutazione della trustiness delle informazioni ricevute e dei dispositivi che le inviano. In
scenari di Smart Mobility c’è bisogno di assicurare la sicurezza e la trustiness sia al
sistema visto come una scatola nera, sia ad ognuno dei singoli mattoni che compongono il
sistema [13] e si deve tener conto, dunque, della privacy degli utenti [23], della sicurezza
delle comunicazioni tra le diverse entità presenti, della sicurezza delle reti ad hoc e delle
reti veicolari e di attacchi malware, worms [24,25] e botnets. [26]
1.1 Sicurezza
Per assicurare la sicurezza in questo tipo di scenari è necessario stabilire una infrastruttura
a chiave pubblica o basata su algoritmi a chiave simmetrica, che renda possibile l’utilizzo
di meccanismi di crittografia e di autenticazione, anche per dispositivi con risorse limitate.
6
2
In realtà il requisito di confidenzialità non è sempre necessario, poiché le informazioni
necessarie per il funzionamento di un sistema di gestione del traffico, ad esempio, non
necessitano di essere occultate, anzi, l’eventuale utilizzo di algoritmi di cifratura potrebbe
solamente inserire dell’overhead che rallenterebbe la diffusione di informazioni critiche
quale ad esempio la segnalazione di un incidente lungo la strada, andando ad inficiare
sulla qualità del sistema. E’ di fondamentale importanza assicurare la confidenzialità,
invece, in applicazioni, come quelle di pagamento, in cui gli estremi di fatturazione
dell’utente non devono essere inviati in chiaro sulla rete. Garantire l’integrità, d’altro
canto, è di primaria importanza, in quanto un messaggio modificato, che trasporta quindi
informazioni fasulle, potrebbe mettere a repentaglio la sicurezza degli utenti, indicando
strada libera in presenza di incidenti o viceversa. Problemi di sicurezza potrebbero
derivare anche da una manomissione fisica dei dispositivi della rete, siano essi veicoli o
sensori, e bisogna dunque introdurre dei meccanismi che permettano la loro
individuazione e che permettano di escluderli dalla rete.
Un ulteriore aspetto da considerare per la sicurezza è la sicurezza dei cosiddetti smart
software, i software che regolano l’operato dei dispositivi. Poiché è necessario un continuo
scambio di dati, gli smart software devono essere perennemente connessi alla rete e, per
evitare a dei possibili hacker di accedere al dispositivo, tutte le attività devono svolgersi
sotto la protezione di un firewall. Ogni volta che il software accede ai dati del sistema,
infatti, gli hacker possono trovare una falla nel sistema e possono sfruttarla per farsi strada
e accedere alle funzionalità base del dispositivo e causare un malfunzionamento, o nel
caso peggiore potrebbero accedere ad aree critiche del dispositivo e causare danni ingenti
all’utilizzatore di quest’ultimo e ai suoi vicini, andando a modificare, ad esempio, la
velocità del veicolo su cui il software è situato. [3]
1.2 Privacy
Preservare la privacy degli utenti è forse il requisito fondamentale in ambienti smart. In
questo tipo di ambiente gli utenti generano dati o sono monitorati continuamente, spesso
anche inconsapevolmente. I dati generati dagli utenti saranno collezionati da sensori
7
2
intelligenti, dai veicoli elettrici ibridi connessi alla rete elettrica, dagli smartphone o
verranno inviati nella rete dal veicolo stesso rendendo dunque importante una gestione
efficace della privacy degli utenti. E’ possibile farlo utilizzando un sistema di pseudonimi,
così da poter separare i dati ricevuti da un utente che possono essere utili per offrire un
servizio agli altri utenti (ad esempio i dati relativi al traffico) dall’identità reale dell’utente
(è preferibile, quindi, non utilizzare come identificatori gli indirizzi IP o MAC). Inoltre
nuove tecniche di crittazione dovranno essere sviluppate per ridurre al minimo l’invio di
dati personali senza diminuire la qualità del servizio. [1] In particolare la privacy del
cittadino può essere violata nel momento in cui esso sottopone query al sistema oppure nel
momento in cui la sua posizione viene localizzata da servizi basati sulla localizzazione
(LBS). Ad esempio nel momento in cui un utente utilizza un sistema di smart parking per
trovare parcheggio dichiara la sua posizione per trovare il parcheggio più vicino e la sua
identità per prenotare un posto in quel parcheggio. Se l’identità non è celata, dunque, un
agente malevolo potrà studiare le abitudini dell’utente, monitorare le sue attività, e
calcolare la sua posizione. L’identità e la posizione di un utente possono essere celate
tramite l’utilizzo di Trusted-Third Parties (TTP), che possono celare l’identità, attraverso
pseudonimi come detto precedentemente, e la posizione attraverso l’uso di una cloaking
region, che verrà inviata agli LBS al posto della posizione precisa, in modo da non
permettere l’esatta localizzazione dell’utente, essendo le cloaking regions popolate da un
alto numero di utenti. [2]
1.3 Trust
Poiché in scenari di smart mobility le comunicazioni avvengono prevalentemente in reti
ad-hoc e non sempre sarà possibile accedere ad un’ infrastruttura di sicurezza che permetta
di riconoscere l’identità dei dispositivi sono necessari dei meccanismi che permettano ad i
singoli dispositivi di prendere autonomamente delle decisioni a riguardo. Oltre ai normali
meccanismi di sicurezza vanno dunque implementati dei trust model che permettano la
valutazione di un livello di trust da affidare ad un entità così da poter decidere se ritenere
valide o meno le informazioni ricevute da questa entità e se utilizzarlo come next hop in
8
2
comunicazioni multihop. Inoltre questi trust model dovranno essere creati appositamente
per questo tipo di scenario, dove, a causa della alta mobilità dei dispositivi, vi potranno
essere frequenti interazioni con dispositivi sconosciuti, per un breve lasso di tempo o per
un’unica volta.
9
2
Capitolo 2
Vehicular Ad-hoc Network
Per rendere possibile l’evoluzione della mobilità richiesta in scenari di Smart Mobility è
necessaria una partecipazione attiva da parte degli utenti, e quindi sarà necessario dotare i
veicoli di tecnologie che gli permettano di acquisire informazioni e renderle disponibili ad
altri utenti. Per raggiungere questo scopo i veicoli vengono dotati di On-Board Unit
(OBU) che comprendono sensori per raccogliere dati (velocità, accelerazione, posizione e
condizioni della strada), una unità di elaborazione e un trasmettitore wireless a corto
raggio e nascono le Vehicular Ad Hoc Network (VANET), un particolare tipo di Mobile
Ad Hoc Network (MANET) che presentano un’alta velocità dei nodi e una topologia di
rete soggetta a continui mutamenti, essendo esse formate da veicoli in movimento.
All’interno di una VANET i veicoli possono comunicare tra loro (V2V, Vehicle-toVehicle) o possono connettersi ad un’infrastruttura (V2I, Vehicle-to-Infrastructure)
attraverso le unità di supporto presenti a bordo strada (Road Side Units, RSU), per
segnalare eventuali ingorghi, incidenti, etc..
10
2
Nascono dunque nuove applicazioni per la gestione del traffico e per la salvaguardia della
sicurezza dei guidatori, ad esempio, le RSU potranno avvertire i guidatori di un eventuale
incidente nelle vicinanze, oppure eventuali atteggiamenti anomali di un veicolo, ad
esempio una brusca frenata, comporteranno l’invio da parte di quest’ultimo di un avviso a
tutte le auto vicine, per avvertirle del pericolo. Questi sono solo alcuni esempi di
applicazioni rese possibili dall’utilizzo delle VANET ma sono sufficienti a capire i
problemi che potrebbero derivare da eventuali attacchi alla rete, basti pensare ad esempio
se nella rete iniziassero a circolare falsi avvisi di ingorghi o ancora peggio se la strada
venisse segnalata libera in presenza di un incidente. Prima di vedere dunque come evitare
che situazioni del genere possano accadere andando a studiare la sicurezza delle VANET,
vediamo una veloce panoramica dei tipi di attacchi ai quali le VANET possono essere
soggette: [7,8]

Denial of Service (DoS): Con questo tipo di attacco l’attaccante punta a
sovraccaricare la rete impedendo ai veicoli l’accesso a quest’ultima, inviando
numerosi messaggi in broadcast in un tempo limitato, generando interferenze o
compromettendo le RSU.

Fabrication attack: Con questo tipo di attacco l’attaccante invia informazioni
false nella rete.

Sybil Attack: Un attaccante effettua questo attacco inviando numerosi messaggi
nello stesso momento utilizzando per ognuno di essi una diversa identità creando
così l’illusione di un possibile ingorgo per avere la strada libera per sé.

Replay Attack: Un attaccante rinvia un messaggio ascoltato in precedenza e trae
beneficio dalla informazione contenuta nel messaggio al momento del rinvio, ad
esempio, per creare confusione nelle autorità e favorire la fuga dopo un incidente.

Message Suppression Attack: Un attaccante intercetta i pacchetti in transito e li
sopprime. Così facendo può evitare che le autorità ricevano messaggi riguardanti
incidenti causati dall’attaccante, oppure può evitare che un avviso di ingorgo
raggiunge la altre vetture costringendole ad aspettare nel traffico.
Risulta dunque necessario, per contrastare questi tipi di attacchi, un meccanismo di
11
2
identificazione dei veicoli, che devono poter certificare la propria identità senza che venga
intaccata la privacy del proprietario del veicolo. Saranno necessari, inoltre, meccanismi di
autenticazione e integrità dei messaggi per poter rilevare i messaggi generati o modificati
da degli attaccanti, un meccanismo che eviti il ripudio dei messaggi, così che un veicolo
non possa negare di aver inviato un dato messaggio e un meccanismo di gestione della
trustiness delle entità all’interno della rete.
Per soddisfare i requisiti di sicurezza appena elencati, i veicoli vengono dotati di alcuni
dispositivi quali gli Event Data Recorder (EDR), i Trusted Platform Module (TPM) e le
Electronic License Plate (ELP), e vengono usati dei protocolli di comunicazione che
offrono un alto livello di sicurezza e sono attenti alla salvaguardia della privacy degli
utenti. Gli EDR sono dei dispositivi a prova di manomissione che memorizzano tutte le
informazioni relative ad un dato evento, e che possono dunque tenere traccia delle
condizioni di un veicolo (velocità, posizione, etc.) in caso di incidente e dei messaggi di
avvertimento ricevuti in condizioni critiche. I TPM invece garantiscono uno stoccaggio
sicuro delle chiavi crittografiche, implementano i meccanismi crittografici e sono resistenti
a attacchi al software ma non a manomissioni fisiche. Le ELP, infine, forniscono un
identificativo unico ad ogni veicolo, e permettono quindi sia di identificare un veicolo
attraverso la tecnologia Radio Frequency IDentification (RFID), sia al veicolo stesso di
autenticarsi. Si potrà dunque salvaguardare la privacy del proprietario del veicolo, la cui
identità potrà essere scoperta solo dalle autorità competenti, ma il veicolo sarà comunque
tracciabile. [8]
2.1 IEEE 1609.2
Vediamo adesso quali sono le soluzioni in termini di protocolli ideati per le VANET.
Per le comunicazioni in reti VANET nasce la tecnologia Dedicated Short-range
Communications (DSRC) che utilizza vari protocolli differenti per i vari livelli della pila
protocollare. In particolare, per il livello fisico e quello MAC viene utilizzato il protocollo
IEEE 802.11p Wireless Access for Vehicular Environments (WAVE), una versione
modificata di IEEE 802.11 (WiFi) creata specificamente per le comunicazioni veicolari.
12
2
Per i livelli superiori, invece, viene usata una suite di protocolli sviluppati dal gruppo
IEEE 1609 e in particolare per quanto riguarda la sicurezza viene utilizzato il protocollo
IEEE 1609.2 che però non si preoccupa della salvaguardia della privacy, che andrà quindi
assicurata diversamente. La gestione della sicurezza viene affidata ai livelli superiori e non
al livello MAC, in quanto 802.11p prevede la comunicazione all’esterno del contesto di
una BSS, vista la difficoltà nel creare una BSS in un ambiente veicolare. Il protocollo
1609.2 prevede l’utilizzo di una Public Key Infrastructure (PKI). Questo tipo di
infrastruttura prevede che ogni veicolo possieda un certificato rilasciato da una entità
fidata, la Certificate Authority (CA), che attesti la sua identità. In particolare un certificato
digitale serve per verificare che una data chiave pubblica sia associata ad una particolare
identità. Dunque un veicolo che vuole inviare un messaggio nella rete lo firma con la
propria chiave privata e allega il certificato della CA, contenente la chiave pubblica
associata alla chiave privata utilizzata. Per firmare il messaggio e dimostrare così la
propria identità e l’integrità del messaggio, che non può essere modificato senza l’utilizzo
della chiave privata del mittente, si utilizza l’Elliptic Curve Digital Signature Algorithm
(ECDSA), un algoritmo di cifratura a chiave asimmetrica che utilizza chiavi a 224 o 256
bit, e che richiede un forte utilizzo di risorse computazionali che in ambiente veicolare non
rappresenta un problema visto che i veicoli possono essere dotati di hardware dedicato alla
crittografia (i TPM). Il destinatario del messaggio potrà risalire alla chiave pubblica del
mittente tramite il certificato allegato al messaggio. Per verificare l’autenticità del
certificato stesso il destinatario andrà a verificare, utilizzando la chiave pubblica della CA,
la firma contenuta nel campo autenticazione del certificato, firmato dalla CA con la
propria chiave privata. Nel caso in cui i messaggi contengano informazioni riservate, come
ad esempio informazioni per il pagamento per un servizio di smart parking, è necessario
garantire anche la confidenzialità dei dati trasmessi. Per farlo IEEE 1609.2 utilizza un
algoritmo di cifratura che è una combinazione tra crittografia simmetrica e asimmetrica,
che prevede che i dati vengano cifrati con l’algoritmo simmetrico e poi la chiave
simmetrica venga cifrata con l’algoritmo asimmetrico poiché la cifratura simmetrica
richiede meno calcolo di quella asimmetrica. L’algoritmo di crittografia simmetrica usato
13
2
è l’AES-CCM, mentre quello per la crittografia asimmetrica è l’Elliptic Curve Integrated
Encryption Scheme (ECIES). Per garantire una maggiore privacy, infine, ed evitare che gli
spostamenti del veicolo possano essere seguiti tramite i messaggi che esso invia in
broadcast, il veicolo possiede un elevato numero di certificati, ognuno valido solamente
per un breve periodo di tempo, e cambia certificato attualmente in uso molto spesso, più o
meno ogni 5-10 minuti. Rendere i certificati posseduti da un veicolo validi solamente in
una breve finestra temporale è fondamentale in quanto se un attaccante riuscisse a
prendere possesso delle informazioni crittografiche presenti nel TPM di un veicolo,
avrebbe accesso ad un gran numero di certificati tutti contemporaneamente validi(
nell’ordine dei 100000) e potrebbe condurre agevolmente un sybil attack. Un veicolo deve
essere quindi rifornito di nuovi certificati, tipicamente una volta all’anno durante la
revisione. [4]
E’ importante sottolineare che il possesso di un certificato da parte di un dispositivo non
implica necessariamente un comportamento corretto del dispositivo all’interno della rete.
Esso potrà comunque inviare false segnalazioni volontariamente oppure a causa di un
malfunzionamento ed è quindi necessario un sistema per permettere alle CA di revocare il
certificato a questi dispositivi. Per farlo la CA può inviare una Revocation of the Trusted
Component (RTC) al TPM con la quale gli impone la cancellazione di tutto il materiale
crittografico che esso conserva. Nel caso in cui questo messaggio non raggiunga la TPM
perché l’attaccante è in grado di bloccarlo, la CA ricorre alle Certificate Revocation List
(CRL), una lista inviata a tutti i veicoli attraverso le RSU contenente tutti i certificati
revocati. Visto l’enorme numero di dispositivi presenti nella rete e di conseguenza la
potenziale grandezza di queste liste si ricorre a dei filtri Bloom per creare delle liste
compresse. [9]
2.2 Pseudonimi e chiavi di gruppo
Per garantire l’anonimato ai veicoli è possibile utilizzare degli pseudonimi e associare i
certificati a questi ultimi, ma ogni pseudonimo deve essere comunque riconducibile al
veicolo per permettere alle autorità eventuali verifiche. Per garantire questa forma di
14
2
anonimato risolvibile, la PKI associa gli pseudonimi alla ELP, e le autorità saranno in
grado di risalire all’identità del proprietario del veicolo attraverso l’ELP. La creazione
degli pseudonimi e delle chiavi associate può avvenire sia da parte della CA che da parte
del veicolo stesso. Nel primo caso la CA creerà tutte le informazioni necessarie offline che
saranno poi trasferite nel veicolo durante le revisioni, mentre nel secondo caso sarà il
veicolo a creare tutte le informazioni necessarie grazie al TPM, che invierà lo pseudonimo
e la chiave pubblica alla CA, che risponderà inviando il certificato al veicolo. Il secondo
approccio è preferibile poiché gli pseudonimi potranno essere cambiati più frequentemente
e, in più, il grado di sicurezza offerto sarà maggiore poiché la chiave privata relativa allo
pseudonimo non verrà mai divulgata dal TPM. [7] Un altro metodo per garantire
l’anonimato consiste nell’utilizzo di firme di gruppo. I gruppi possono essere di due tipi:
dinamici, formati ad esempio dai veicoli in una determinata area geografica, o statici, in
cui i veicoli sono assegnati a dei gruppi in base a particolari attributi. Vediamo quindi
come funziona la comunicazione utilizzando i gruppi. I veicoli della rete vengono
suddivisi in gruppi e ogni membro del gruppo possiede una propria group member secret
key e la chiave pubblica del gruppo . Un veicolo del gruppo dunque, invece di autenticare
i propri messaggi utilizzando la propria chiave privata associata al certificato, utilizzerà la
sua group member secret key. Così facendo si garantisce l’anonimato ai membri del
gruppo, anonimato che deve essere comunque risolvibile dalle autorità competenti. Per
rendere l’anonimato risolvibile, si introducono delle entità chiamate Group Manager. I
Group manager possiedono una group manager secret key, che permette di risalire alla
vera identità del mittente di un messaggio. [8] Nella gestione della sicurezza delle
comunicazioni all’interno dei gruppi si può anche pensare di non utilizzare una struttura a
chiave asimmetrica. Si può pensare, allora, ad una soluzione che preveda una struttura a
chiave simmetrica per ridurre l’overhead dovuto agli algoritmi di crittografia asimmetrici
ed eliminare la necessità di dover contattare la CA per l’instaurazione di chiavi di gruppo
asimmetriche. In questo approccio il leader del gruppo (ad esempio il veicolo al centro
dell’area di copertura del gruppo) si occupa di generare una chiave simmetrica per il
gruppo e di distribuirla ad ognuno dei membri del gruppo cifrandola con le loro
15
2
corrispettive chiavi pubbliche (chiavi pubbliche che devono essere precedentemente
inviate in broadcast con il relativo certificato). Una volta che tutti i membri del gruppo
possiedono la chiave pubblica del gruppo possono firmare i messaggi con essa e rendere
confidenziali le comunicazioni all’interno del gruppo. Per permettere la propagazione dei
messaggi tra i gruppi e fornire un meccanismo per la verifica della validità delle
informazioni contenuta nel messaggio, è necessario che le aree geografiche dei gruppi si
sovrappongano. Così facendo un veicolo posizionato nell’area condivisa (il primo e
l’ultimo della flotta) possiede le chiavi di entrambi i gruppi e invierà il messaggio al
gruppo successivo usando la chiave di quest’ultimo. Questa soluzione a chiave simmetrica
non assicura quindi la non-repudiation dei messaggi né è finalizzata a salvaguardare la
privacy degli utenti in quanto permette la comunicazione solo all’interno del gruppo o di
gruppi adiacenti. Essa permette d’altro canto la gestione e la creazione dei gruppi senza la
necessità di contattare la CA garantendo comunque l‘autenticità e l’integrità dei messaggi.
Per garantire invece una non-repudiation dei messaggi, è necessario creare per la flotta una
coppia di chiavi di gruppo pubblica e privata unica per tutto il gruppo contattando la CA,
che si occuperà, inoltre, di assegnare ad ogni veicolo della flotta un ID di riconoscimento
che dovrà essere inserito nella firma dei messaggi. [17] Poiché l’ID viene inviato nella
firma del messaggio questo tipo di implementazione non garantisce la privacy agli utenti,
che potrà essere quindi garantita solo dall’approccio presentato precedentemente.
2.3 Trust models
Ogni dispositivo della rete deve essere in grado di capire se le informazioni inviate da un
altro dispositivo sono valide o meno, anche se questo possiede un certificato valido e
anche senza l’aiuto di un’infrastruttura. Esistono dei trust model che associano un livello
di fiducia alle entità della rete e che permettono quindi di fidarsi delle informazioni inviate
da queste entità, ma questi non sono i più performanti in ambienti VANET, in quanto, data
la natura della rete ed in particolare la mobilità dei veicoli, due nodi potrebbero essere
vicini anche solo una volta nella loro vita. Si preferisce allora usare dei trust model
orientati ai dati, che assegnano un valore di fiducia direttamente alle informazioni che si
16
2
stanno ricevendo, o dei trust model ibridi.
Anche se i trust model orientati alle entità sono sconsigliati, sono stati comunque
sviluppate alcune soluzioni specifiche per VANET. Una di queste prevede la creazione di
gruppi ai quali i veicoli vengono associati staticamente (ad esempio si possono prevedere
gruppi di studenti, ingegneri, dottori etc..) ed ai quali viene assegnato un livello di fiducia.
Ogni volta che un veicolo invia segnalazioni sullo stato di una strada alla rete lo fa a nome
del gruppo e chi riceve queste informazioni va a controllare se le varie segnalazioni
provenienti da uno stesso gruppo sono mediamente compatibili con le informazioni
prelevate da RSU sicure oppure con informazioni prelevate personalmente dal ricevitore e,
quindi, con il reale stato della strada. In base all’esattezza delle segnalazioni il valore di
fiducia assegnato al gruppo aumenterà o diminuirà. Questo approccio per quanto
effettivamente applicabile non permette l’assegnazione di un livello di fiducia alle singole
entità. [10]
Vediamo quindi l’approccio utilizzato dai trust model orientati ai dati. Essi, come detto,
assegnano un valore di fiducia ai messaggi ricevuti ed in particolare agli eventi che
vengono segnalati dai nodi della rete tramite questi messaggi. In particolare
nell’assegnazione di questo valore di fiducia si terrà conto di vari fattori, sia statici, come
ad esempio un valore di fiducia che è possibile attribuire a priori all’entità mittente in base
al tipo di veicolo (auto della polizia, bus, etc.), sia dinamici, come la vicinanza sia spaziale
che temporale all’evento registrato. Raggruppando segnalazioni differenti relative ad uno
stesso evento e applicando la teoria di Dempster-Shafer tenendo conto dei fattori prima
elencati, sarà possibile valutare il livello di fiducia dell’evento preso in esame. Il
considerare separatamente ogni evento rappresenta proprio il problema di questo
approccio, in quanto le relazioni di fiducia andranno valutate da zero per ogni evento e nel
caso in cui la rete sia poco popolata questo modello non funzionerà a dovere vista la
mancanza di segnalazioni. [11] E’ possibile altrimenti utilizzare dei trust model ibridi, che
prevedono quasi sempre un meccanismo di opinion piggybacking. Ogni veicolo che riceve
un messaggio vi allega un opinione sul valore di fiducia dell’informazione trasportata
prima di inoltrarlo. Questa opinione può dipendere sia da una conoscenza diretta
17
2
dell’evento di cui si parla nel messaggio, sia dalla conoscenza del mittente del messaggio
[12] Questi sono ovviamente solo alcuni esempi di trust model ma aiutano a capire la
differenza tra i tre tipi di modelli.
2.4 Trusted routing
Non resta che concludere la trattazione riguardante la sicurezza in ambienti VANET
andando a esaminare un protocollo di trusted routing che permetta un inoltro sicuro della
informazioni trasmesse nella rete.
Vista la velocità di cambiamento della topologia di rete in ambienti VANET, l’utilizzo dei
protocolli di routing classici per ambienti VANET come AODV o DSR non è consigliato,
e si utilizzano, invece, protocolli di routing geografici che inoltrano il pacchetto al nodo
geograficamente più vicino. Nodi maliziosi possono però attuare un attacco di tipo
position spoofing mentendo sulla loro attuale posizione. Bisogna quindi capire se i nodi
vicini sono nodi fidati o meno, e, per farlo, ogni nodo deve creare una tabella in cui, oltre
alla posizione dei vicini (che viene annunciata dai vicini tramite beacon frame), va ad
associare ad ogni vicino un valore di trust. Il valore di trust da associare ad un nodo vicino
viene determinato attraverso una procedura in due fasi. La prima fase consiste nell’invio di
un messaggio di sfida al vicino che, per costruire una risposta, deve svolgere delle
semplici attività computazionali. Il mittente calcola il tempo impiegato per ricevere la
risposta e, in base a questo, calcola la distanza del vicino. Alcuni semplici accorgimenti
evitano la possibilità di mentire da parte del vicino, in quanto, poiché c’è un limite al
raggio delle trasmissioni wireless, il vicino non potrà affermare di trovarsi troppo lontano,
e, poiché la velocità della luce è conosciuta, il vicino non potrà affermare di trovarsi più
vicino di quanto gli permetta la velocità di propagazione delle onde e, inoltre, essendo il
mittente provvisto di mappe, il vicino non potrà affermare di trovarsi al di fuori delle
strade.
Alla fine di questa prima fase si ha dunque una prima stima della posizione del vicino. Per
aumentare il grado di sicurezza si sceglie un vicino fidato (preferibilmente una RSU) e si
richiede anche a lei di verificare la posizione del vicino per vedere se il risultato è
18
2
corrispondente. Poiché le verifiche vengono effettuate appena si riceve una frame di
beacon, esse saranno sincronizzate e si è sicuri che il vicino non si sia spostato.
Completate le due fasi si potrà dunque capire se il nodo è malizioso o meno e assegnargli
un valore di fiducia e decidere se usarlo come next hop o meno durante le trasmissioni
multihop. [5]
Il livello di fiducia di un nodo può anche essere valutato molto banalmente andando a
vedere se esso partecipa attivamente all’inoltro di pacchetti. Può nascere, però, un
problema nella valutazione della fiducia di un vicino se questo è stato scelto come next
hop dal protocollo di routing geografico in quanto più vicino alla destinazione, ma esso
non inoltra il messaggio, non perché non voglia, ma perché non riceve il messaggio, in
quanto si è frapposto tra i due nodi un ostacolo (bus, autoarticolato) che ha creato una
situazione di Non Line of Sight (NLOS).
Anche in questo caso si può ricorrere all’aiuto di un terzo nodo per verificare la posizione
del vicino al di là dell’ostacolo per evitare di assegnare un basso valore di fiducia
erroneamente ad un vicino. [6]
19
2
Capitolo 3
Wireless Sensor Networks
La raccolta dei dati necessari per le applicazioni per la smart mobility, in particolare per la
gestione del traffico, può avvenire anche attraverso l’utilizzo di sensori, quali sensori
magnetici, ad infrarossi o per la rilevazione acustica dei veicoli. E’ necessaria quindi
un’infrastruttura di rete wireless che permetta la propagazione dei dati raccolti dai sensori
fino ad un’unità centrale di elaborazione, e non devono essere sottovalutati gli aspetti di
sicurezza per gli stessi motivi che sono stati già elencati per le VANET. Per le reti wireless
di sensori non si possono utilizzare le stesse soluzioni per garantire la sicurezza delle
trasmissioni usate nelle reti ad hoc tradizionali. I sensori infatti, a causa delle loro piccole
dimensioni e per questioni economiche, hanno capacità computazionali, energetiche e di
memoria limitate che rendono difficile l’utilizzo di algoritmi complessi per la sicurezza
delle trasmissioni, come ad esempio gli algoritmi a chiave pubblica (per quanto
un’implementazione di questi ultimi resta possibile). Sono stati quindi sviluppati dei
protocolli di routing e degli algoritmi di cifratura e autenticazione specifici per le reti
wireless di sensori.
Prima di presentare le soluzioni proposte andiamo a vedere, anche in questo caso, quali
sono i possibili tipi di attacco alle reti wireless di sensori:

Denial of Service, Replay Attack e Sybil Attack: Come sono già stati presentati
per le VANET.

Sinkhole Attack: Poiché nelle reti di sensori le informazioni viaggiano tutte verso
20
2
un’unità centrale, con un attacco sinkhole un attaccante può riuscire a attrarre tutto
il traffico verso un nodo maligno posto sufficientemente vicino all’unità centrale o
verso un nodo che si finge l’unità centrale stessa in modo da rendere inefficiente
l’intera rete non inoltrando i messaggi

Wormhole Attack: Un attacco wormhole consiste nell’instaurazione da parte di
un nodo compromesso vicino all’unità centrale di un tunnel a bassa latenza tra due
parti distanti della rete di sensori. Il nodo compromesso dunque inoltrerà i
pacchetti ricevuti ad un’estremità del tunnel all’altra estremità facendo credere alle
due parti di rete lontane di essere in realtà vicine. Così facendo i nodi sceglieranno
erroneamente il nodo compromesso come rotta migliore verso l’unità centrale
andando a creare un sinkhole o andando semplicemente a inficiare sulla qualità
della rete.

Attacchi fisici: Poiché i sensori per questioni di costi non vengono dotati di
dispositivi di sicurezza anti-manomissione, è anche possibile effettuare un attacco
fisico ad un nodo che può essere manomesso e possono essere rubate le
informazioni di sicurezza contenute in esso oppure può essere compromesso per
poi venire usato dall’attaccante per inviare messaggi fasulli nella rete.

Impersonation Attack: Un attaccante che è riuscito a rubare i dati identificativi di
un sensore, aggiunge un ulteriore nodo alla rete replicando i dati che ha rubato.
3.1 Protocolli di sicurezza
Vediamo
adesso
alcuni
protocolli
per
il
livello
data
link
che
permettono
l’implementazione di meccanismi crittografici e di autenticazione che tengano conto delle
limitazioni imposte dai sensori. Nelle reti di sensori vengono utilizzati protocolli di
sicurezza al livello data link poiché, mentre nelle reti normali i router devono essere in
grado di leggere soltanto l’header per instradare i pacchetti, nelle reti di sensori può essere
utile per un nodo accedere ai dati contenuti nel pacchetto per effettuare aggregazioni,
rimuovere i messaggi doppioni, evitando così di far viaggiare più pacchetti contenenti le
stesse informazioni nella rete, utilizzando dunque meno energia.
21
2
Poiché questi protocolli sono protocolli a chiave simmetrica è necessario introdurre prima
un protocollo che permetta lo scambio sicuro di chiavi. I protocolli di scambio delle chiavi
più usati nelle reti wireless di sensori sono protocolli probabilistici. Il protocollo più
famoso di questo tipo, che viene adesso presentato come esempio, prevede più fasi per lo
scambio di chiavi. Nella prima fase, quella di pre-distribuzione, ad ogni nodo viene
assegnato un certo numero di chiavi molto minore del numero complessivo di chiavi
disponibili. Nella seconda fase, quella di scoperta delle chiavi condivise, ogni nodo può
scoprire se ha ricevuto una chiave uguale ad un vicino in due modi differenti. Può
annunciare gli identificativi delle chiavi disponibili nel proprio keyring e ascoltare gli
annunci dei propri vicini per trovare una corrispondenza, oppure, per rendere privata
l’associazione, ogni nodo invia una lista contenente tanti testi di sfida quanti sono le chiavi
ed ognuno di essi sarà codificato con una chiave diversa. Solo chi è in possesso di una
chiave potrà rispondere al testo di sfida e creare così un associazione. [14]
Una volta che due entità vicine hanno una chiave comune esse potranno comunicare in
sicurezza. Presentiamo adesso brevemente due protocolli, Sensor Network Encryption
Protocol (SNEP) e TinySec, e successivamente, MiniSec che ottimizza i due approcci
precedenti garantendo dunque un miglior compromesso tra sicurezza e energia spesa dal
sensore nelle operazioni di cifratura.
Poiché questi tre algoritmi sono a chiave simmetrica sarà necessario per ogni messaggio
inviato generare un Initialization Vector (IV) da aggiungere alla chiave per far sì che non
tutti i messaggi vengano cifrati con la stessa chiave e sarà proprio nella scelta di questo IV
e della tecnica di cifratura utilizzata la differenza tra i tre protocolli.
SNEP punta a garantire confidenzialità, integrità e autenticità ai dati ed una protezione dai
replay attack. Per garantire la confidenzialità utilizza l’algoritmo RC5 mentre per
l’autenticità e l’integrità si aggiunge al messaggio un Message Autentication Code
(MAC). Per la confidenzialità si utilizza un cifratore a blocchi in modalità Counter (CTR)
che utilizza la stessa funzione sia per cifrare che per decifrare (la RC5). Per funzionare, la
modalità Counter necessita di un contatore (che verrà utilizzato come IV), che le due entità
che comunicano tra loro conserveranno e non invieranno insieme al messaggio, e che
22
2
verrà incrementato ad ogni messaggio inviato o ricevuto. Il MAC viene invece generato
tramite la funzione Cipher Block Chaining Message Authentication Code (CBC-MAC).
Le chiavi necessarie per applicare la CBC-MAC e la RC5 sono generate dalla chiave
simmetrica che condividono i due nodi. Questo protocollo garantisce dunque i tre requisiti
sopra riportati, aggiungendo “soltanto” 8 byte di overhead dovuti al MAC, in quanto
l’utilizzo di uno stream cipher garantisce la stessa lunghezza del messaggio cifrato e di
quello in chiaro. D’altro canto però possono nascere problemi da un’eventuale
desincronizzazione del contatore che non viene inviato insieme al messaggio. [18]
Per evitare i problemi derivanti dall’utilizzo di uno stream cipher con un IV che si ripete
(visto che utilizziamo il contatore), bisognerebbe utilizzare un IV più lungo, ma questo è
impossibile in questo tipo di scenario. La soluzione proposta da TinySec consiste allora
nell’utilizzare un cifrario a blocchi in modalita cipher block chaining che permette
l’utilizzo di IV più corti. Anche questa modalità può creare dei problemi con un IV che
aumenta linearmente il proprio valore, e per evitare problemi si è pensato di cifrare l’IV
prima di utilizzarlo. L’IV sarà formato nell’ordine dall’indirizzo del destinatario, il tipo di
messaggio, la lunghezza del payload, l’indirizzo del mittente e un contatore a 16 bit
relativo alla coppia sorgente-destinazione. Per garantire autenticità e integrità si usa
sempre il CBC-MAC che però crea un MAC di soli 4 byte a dispetto degli 8 byte di SNEP.
Questo tipo di protocollo prevede di inviare l’IV insieme al messaggio cifrato. I vantaggi
offerti da questo protocollo sono quindi evidenti. Da un lato non è possibile perdere la
sincronizzazione dei contatori visto che essi vengono inviati in chiaro, e dall’altro
l’overhead è minore. [19]
MiniSec punta quindi ad unire i vantaggi delle due soluzioni. Da un lato usa un IV lungo,
formato da 32 bit di contatore (come SNEP) e invia esplicitamente solo parte di questo IV
prendendo spunto da TinySec. In particolare vengono inviati solo gli ultimi 3 bits del
contatore dell’IV (e quindi del contatore) così che se il ricevitore non ha ricevuto solo gli
ultimi 23 pacchetti, può comunque decifrare il messaggio.
Inoltre MiniSec effettua in unico passo la cifratura e la firma del messaggio utilizzando
l’Offset CodeBook (OCB) garantendo un notevole vantaggio in termini di energia
23
2
utilizzata. [20]
3.1.1 Protocolli di sicurezza a chiave asimmetrica
Con la comparsa di nuovi meccanismi di cifratura quali ad esempio quelli basati su curva
ellittica che presentano dimensioni delle chiavi ridotte e meccanismi di cifratura più
leggeri, ma comunque performanti, è diventato possibile utilizzare dei meccanismi a
chiave pubblica o ibridi per assicurare la sicurezza nelle reti wireless di sensori.
Si può pensare, ad esempio, di utilizzare una cifratura a chiave pubblica per effettuare uno
scambio di chiavi sicuro tra due nodi, che poi effettueranno le trasmissioni con la chiave
simmetrica che hanno concordato.
Presupponendo che ogni nodo possegga una coppia di chiavi pubblica e privata, ed un
relativo certificato, prima di inviare dati i nodi inviano sulla rete in broadcast le proprie
chiavi pubbliche ed i certificati associati. Gli altri nodi conservano in memoria queste
informazioni e nel momento in cui un nodo vuole comunicare con un nodo di cui possiede
il certificato, inizia una fase di handshake simile a quella prevista dal Transport Layer
Security (TLS). Il nodo che vuole iniziare la comunicazione genera casualmente 128 bit e
li cifra con la chiave pubblica del nodo con cui vuole comunicare utilizzando l’Elliptic
Curve Integrated Encryption Scheme (ECIES) e lo firma con la propria chiave privata
utilizzando l’Elliptic Curve Digital Signature Algorithm (ECDSA). Se il nodo che riceve
questo messaggio ha abbastanza risorse e possiede il certificato del nodo mittente, decifra
e controlla l’identità del mittente e genera altri 128 bit che invia con le stesse modalità
all’altro nodo. Con le due stringhe di 128 bit e utilizzando la funzione di creazione di
chiavi ANSI-X9.63, i due nodi generano una chiave simmetrica e una chiave per calcolare
l’HMAC, permettendo così uno scambio sicuro di dati utilizzando le procedure di
crittografia simmetrica come RC5. [22]
3.2 Trusted routing
Avendo visto come due nodi vicini possono comunicare in sicurezza non resta che vedere
dei protocolli di trusted routing che permettano ad un nodo di comunicare solamente con
24
2
dei vicini fidati in quanto anche nodi maligni possiederanno delle chiavi e dunque, come
già detto per le VANET, il possesso di una chiave non implica il corretto comportamento
di un nodo.
Vedremo adesso dei protocolli che permettono di gestire il valore di fiducia dei nodi
vicini. Il primo protocollo fa parte del servizio μRacer ed è il Trust Aware Routing
Protocol (TARP), che evita di indirizzare le informazioni a nodi non fidati. Il calcolo della
fiducia di un nodo avviene attraverso due contributi, la reputazione diretta e quella
indiretta. La reputazione diretta del nodo A, così come è percepita dal nodo B, è la
reputazione che B assegna ad A in base alla loro interazione diretta. Nello specifico B
calcola questa reputazione in base al numero di pacchetti che A riceve da B ed inoltra,
tenendo conto che a volte dei falsi negativi possono accadere a causa delle condizioni del
canale. La reputazione indiretta del nodo A così come è percepita dal nodo B, invece,
dipende dal comportamento di A con i vicini di B, ovvero la reputazione diretta di A con i
vicini di B. B per conoscere questo valore di reputazione invia una reputation request per
un dato nodo e i nodi vicini che vogliono rispondere inviano un reputation report in
broadcast in modo che tutti possano aggiornare le proprie tabelle di reputazione. Sulla
base di questi due valori e del valore di fiducia precedentemente associato ad un nodo, il
nodo B calcola il nuovo valore di fiducia. Nel caso in cui questo valore sia al di sotto di
una soglia prefissata il nodo invierà in broadcast un reputation report per annunciare a tutti
la malignità del nodo. [15]
In caso di reti di sensori molto grandi questo tipo di approccio non è dei migliori in quanto
ogni sensore dovrebbe tenere memoria del valore di fiducia di molti nodi diversi andando
a pesare sulle limitate capacità di memoria disponibile ai sensori. Per risolvere questo
problema ed offrire altri servizi come l’aggregazioni di dati simili, si può organizzare la
rete di sensori in una rete clustered. I sensori possono essere raggruppati in gruppi
(cluster), all’interno dei quali i tutti i membri riescono a comunicare tra loro, che fanno
riferimento ad un capogruppo (cluster-head). Il protocollo Groupbased Trust Management
Scheme (GTMS) prevede a questo punto che la gestione della fiducia avvenga a tre diversi
livelli. Al livello dei nodi la gestione della fiducia avviene in modo simile al protocollo
25
2
TARP con un calcolo della reputazione diretta e indiretta, con l’unica differenza che per
tenere conto delle trasmissioni non andate a buon fine a causa delle condizioni del canale i
nodi utilizzano una finestra temporale scorrevole. Diviso il tempo in intervalli e fissato un
numero di intervalli, ogni nodo conserva per ogni membro del gruppo il numero di
interazioni andate a buon fine sul totale delle interazioni. Una volta riempita la finestra
essa scorrerà in avanti facendo posto al nuovo intervallo temporale cancellando il più
vecchio. Così facendo si riduce l’impatto delle condizioni del canale sul valore di fiducia.
Al livello dei cluster-head, ogni cluster-head calcola il valore di fiducia da assegnare al
proprio gruppo richiedendo ad ogni membro del gruppo i valori di fiducia da loro
assegnati agli altri membri del gruppo. Il cluster-head ne farà una media e assegnerà un
valore di fiducia ad ogni membro del gruppo. Inoltre il cluster-head va a calcolare il livello
di fiducia degli altri cluster. Al livello di unità centrale, infine, l’unità centrale tiene conto
di tutti i valori di fiducia dei vari cluster head. [16]
26
2
Capitolo 4
S2-Move
Dopo aver visto come rendere sicure le comunicazioni in scenari di Smart Mobility,
vediamo come le soluzioni proposte possono essere implementate all’interno di uno
scenario realmente esistente, come quello del progetto S2-Move.
Il progetto S2-Move, è un progetto di 36 mesi finanziato dal Ministro dell’Istruzione
dell’Università e della Ricerca (MIUR) e iniziato nel Giugno 2012. Questo progetto
presenta una concreta realizzazione di un sistema per la Smart Moblity che prevede una
raccolta di dati eterogenei dal territorio, quali condizioni della strada, velocità e posizione
dei veicoli, etc., attraverso l’utilizzo di vari dispositivi, quali smartphone, sensori o
direttamente dai veicoli. Sono proprio i veicoli i principali attori nella raccolta dei dati.
Essi vengono dotati di un’ OBU che si occupa di raccogliere i dati dalle varie Electronic
Control Unit (ECU) della vettura (come ad esempio il consumo di benzina, la pressione
sul pedale dl freno, le spie d’emergenza del cruscotto, etc..) attraverso il Controller Area
Network (CAN) bus. Attraverso l’analisi dei dati raccolti dalla vettura, è possibile
monitorare il veicolo e, incrociando i dati ottenuti, tutto l’ambiente urbano in maniera
indiretta. Oltre a raccogliere i dati l’OBU si occupa di comunicarli sia tramite trasmissioni
V2I che V2V.
I dati trasmessi dunque, vengono inviati sia ai veicoli vicini che possono usarli per rilevare
situazioni di pericolo, sia ad un’unità centrale il Central Processing System (CPS).
Il CPS è il cuore dell’architettura e si occupa di collezionare i dati dai dispositivi nella
27
2
rete, di elaborarli, e di offrirli all’utente finale attraverso una semplice mappa annotata del
tessuto urbano. Lo scopo ultimo, infatti, è collezionare sufficienti informazioni sulla
mobilità urbana e restituirle all’utente finale che, attraverso una mappa annotata, potrà
visionare informazioni sul traffico in tempo reale, effettuare segnalazioni e visualizzare
quelle fatte da altri veicoli, visualizzare e interagire con flotte di veicoli in movimento,
visualizzare e prenotare un parcheggio, etc..
Il CPS presenta una struttura multi-layer. Attraverso il Data Layer vengono memorizzati i
dati e viene utilizzato per la memorizzazione PostgreSQL con estensione PostGIS per
avere un completo supporto per i dati geospaziali, mentre tramite il Core Layer si
eseguono tutte le procedure che permettono di generare le mappe annotate tramite i dati
ricevuti, e per farlo si utilizza Geoserver, un applicazione Java open source per la
creazione di mappe annotate. Infine, mediante il Presentation Layer, reallizato usando il
Play! Java Framework, si offrono i dati processati al’utente finale sotto forma di mappa
annotata.
Le due principali applicazioni per il momento offerte dal progetto S2-Move, sono
un’applicazione per il monitoraggio del traffico ed una per la gestione delle flotte.
La prima è realizzata principalmente attraverso i dati ricevuti dalle OBU, in quanto
piazzare sensori sul manto urbano risulterebbe troppo costoso e non è neanche prevista la
presenza di RSU per lo stesso motivo.
In particolare il sistema preleva i dati relativi la posizione e la velocità dei veicoli per
segnalare la loro posizione sulla mappa (dopo averla perfezionata con algoritmi di map
28
2
matching) e capire attraverso la velocità se la strada su cui si trova il veicolo è trafficata o
meno.
La seconda prevede due operazioni, quella di monitoraggio e quella di controllo della
flotta. Tramite il monitoraggio si acquisisce la posizione della flotta sulla mappa e si
traccia il suo percorso. Tramite il controllo della flotta, invece, si permette ai veicoli che
formano la flotta, e che quindi si muovono nella stessa direzione, di muoversi alla stessa
velocità dettata dal primo veicolo della flotta, il leader, e di mantenere una determinata
distanza di sicurezza l’uno dall’altro attraverso la comunicazione V2V tra i veicoli
andando ad agire direttamente sugli attuatori della vettura (frenata, sterzata, etc.). [21]
E’ facile immaginare dunque, quali possono essere i problemi derivanti dalla presenza di
agenti maligni nella rete che generano informazioni fasulle, che modificano informazioni
in transito nella rete o che bloccano l’inoltro di pacchetti, soprattutto nelle operazioni di
controllo della flotta. Se, infatti, per quanto riguarda il sistema di monitoraggio del
traffico, non ci saranno conseguenze per la salute dei guidatori, ma soltanto conseguenze
sul piano della viabilità, nel caso del controllo della flotta, informazioni false potrebbero
creare degli incidenti poiché costringerebbero membri della flotta ad aumentare, ad
esempio, la propria velocità andando ad urtare i membri della flotta che li precedono.
Vediamo dunque come è possibile implementare i meccanismi di sicurezza proposti nei
capitoli precedenti in questo tipo di architettura.
4.1 Soluzione proposta
Per permettere solo ai veicoli autorizzati di partecipare alle comunicazioni nell’ambito del
nostro progetto, si dovranno implementare dei protocolli di sicurezza che permettano
l’autenticazione e il non ripudio dei messaggi. La soluzione proposta da [4] si rivela
dunque perfetta e si può pensare dunque di utilizzare il protocollo IEEE 1609.2 che andrà
ad “appoggiarsi” al protocollo IEEE 802.11p per la comunicazione V2V essendo questo
un protocollo per il livello data link. Come detto precedentemente il protocollo IEEE
1609.2 prevede l’instaurazione di una PKI e il possesso, dunque, da parte di tutti i veicoli
della rete, di un certificato rilasciato da una CA. E’ necessario dunque che su ogni veicolo
29
2
venga affiancata all’OBU anche un TPM per lo stoccaggio di questi certificati e per
implementare i meccanismi crittografici previsti dal protocollo IEEE 1609.2. Inoltre
essendo il CPS sempre disponibile, esso può essere usato oltre che come centro di raccolta
ed elaborazione dati, anche come certification server.
Il CPS si dovrà dunque occupare anche di revocare i certificati utilizzando le CRL
secondo le modalità previste in [9], ma poiché S2-Move è stato progettato in maniera tale
da rendere l'architettura indipendente dalla eventuale presenza delle RSU (ciò ha
comportato notevoli vantaggi per quanto riguarda l'estendibilità dei servizi offerti dalla
piattaforma svincolando l'interazione tra gli attori dello scenario urbano dalla presenza di
unità a bordo strada), le CRL non saranno distribuite alle RSU ma direttamente ai veicoli
stessi.
Poiché S2-Move prevede la visualizzazione della posizione dei veicoli sulla mappa è
fondamentale garantire l’anonimato (comunque risolvibile) a questi veicoli per
salvaguardare la privacy dei guidatori così che neanche il CPS possa risalire all’identità
dei guidatori delle vetture segnalate sulla mappa. Per farlo quindi i veicoli possono
utilizzare degli pseudonimi e numerosi certificati, come proposto in [4] e in [7], così che le
segnalazioni sembrino provenire da veicoli diversi.
Particolare attenzione va posta invece sulla gestione dei gruppi, sulle firme di gruppo e
sull’anonimato che esse garantiscono, in quanto le flotte rappresentano una componente
importante del progetto S2-Move.
Sono stati presentati precedentemente due approcci per la gestione della sicurezza
all’interno dei gruppi, uno a chiave simmetrica che assicurava la sicurezza all’interno di
un gruppo non permettendo a veicoli esterni al gruppo di partecipare alle comunicazioni
[17], e uno a chiave asimmetrica che oltre a garantire la sicurezza garantiva anche la
privacy dei membri del gruppo. [8]
Il secondo approccio, per funzionare necessita di un Group Manager (che non può
corrispondere con il leader di flotta, in quanto deve essere un’entità sicura), atto a gestire
molteplici chiavi di gruppo e gestire quindi più flotte presenti nella propria area di
riferimento (attraverso le RSU), permettendo l'instaurazione per ogni membro della flotta
30
2
della propria group member secret key.
Nell’ambito del nostro progetto, però, dove le RSU non sono presenti, si potrebbe pensare
di assegnare la responsabilità di Group Manager al CPS stesso. Non essendo presenti le
RSU l’unico tipo di comunicazione V2I è quella svolta con il CPS, però la connessione
con quest’ultimo potrebbe non essere costante a causa della disponibilità della rete
cellulare. Una implementazione di questo tipo di gestione dei gruppi potrebbe dunque
creare dei problemi nella gestione della sicurezza nelle flotte che potrebbero non riuscire
ad ottenere una coppia di chiavi valide non riuscendo a contattare il group manager. Una
soluzione potrebbe essere dunque la seguente.
Nel momento in cui la rete non è disponibile, si può usare il meccanismo con chiavi
simmetriche per garantire autenticità e integrità ai messaggi trasmessi all’interno della
flotta e non permettendo così a veicoli non appartenenti alla flotta di inviare informazioni
non valide ai veicoli della flotta. Nel momento in cui la rete torna disponibile, invece,
facendo coincidere il Group Manager con il CPS e di conseguenza con la CA del nostro
sistema, si può richiedere l’instaurazione di una chiave di gruppo e di chiavi private per i
membri del gruppo, garantendo così l’anonimato e la sicurezza nelle trasmissioni.
Per garantire invece la trustiness delle informazioni nel progetto S2-Move, si può pensare
di utilizzare un trust model orientato ai dati, come quello proposto in [11], nel caso di
comunicazioni tra un veicolo e il CPS, in quanto il CPS ricevendo le informazioni da molti
veicoli riuscirà a determinare se le informazioni ricevute sono valide o meno. Lo stesso
approccio può essere utilizzato anche per le comunicazioni V2V, in quanto un trust model
orientato alle entità potrebbe non essere efficiente, oppure un trust model ibrido potrebbe
essere la soluzione migliore.
Per quanto riguarda invece l’accesso alla mappa annotata da parte degli utenti tramite
smartphone o direttamente dal veicolo, è necessario anche in questo caso assicurare la
sicurezza delle comunicazioni, in quanto l’applicazione prevede l’autenticazione degli
utenti per effettuare ad esempio operazioni per prenotare un parcheggio. E’ necessario
dunque utilizzare un protocollo di sicurezza a livello applicativo quale HTTP Secure.
31
2
Conclusioni
In questo lavoro di tesi si è visto come sia possibile utilizzare le innovative applicazioni
offerte dalla Smart Mobility senza rischi per la privacy degli utenti e delle informazioni
trasmesse.
Si sono dunque studiati meccanismi di sicurezza per le tecnologie internet adoperate che
permettano l’utilizzo in sicurezza di applicazioni innovative (quali sistemi di gestione e
monitoraggio del traffico, smart parking e gestione di flotte) senza che i dati collezionati e
successivamente inviati potessero contenere informazioni sulla posizione o sulle abitudini
degli utenti. Sono stati poi presentati meccanismi per rendere confidenziali le
comunicazioni e permettere, dunque, l’utilizzo in sicurezza di servizi di pagamento on the
fly, e meccanismi per far sì che soltanto dispositivi autorizzati, siano essi veicoli o sensori,
possano partecipare attivamente alle comunicazioni evitando così che agenti maligni
possano perpetrare attacchi ai danni della rete.
Si è quindi visto come sia possibile utilizzare contemporaneamente questi meccanismi per
rendere effettivamente sicura un’applicazione per la Smart Mobility, quale il progetto S2Move.
Utilizzando dunque le soluzioni proposte, in futuro queste applicazioni per la Smart
Moblity potranno prendere sempre più piede favorendo la nascita di vere e proprie Smart
City che si andranno ad affiancare a quelle già esistenti come quelle di Amsterdam, Dubai
ed altre.
32
Bibliografia
[1]
A. Bartoli, J. Hernández-Serrano, M. Soriano, M. Dohler, A. Kountouris, D.
Barthel, 2011 “Security and Privacy in your Smart City”
[2]
A. Martínez-Ballesté, P. A. Pérez-Martínez, A. Solanas, 2012 “The Pursuit of
Citizens’ Privacy: A Privacy-Aware Smart City Is Possible”
[3]
M. Sen, A. Dutt, S. Agarwal, A. Nath, 2013 “Issues of privacy and security in the
role of software in smart cities”
[4]
J. B. Kenney, 2011 “Dedicated Short-Range Communications (DSRC) Standards in
the United States”
[5]
J. Wang, Y. Liu, X. Liu, and J. Zhang, 2009 “A trusted neighbor table based
location verification for VANET Routing”
[6]
O. Abumansoor, A. Boukerche, 2011 “Towards a Secure Trust Model for Vehicular
Ad Hoc Networks Services”
[7]
J. M. de Fuentes, A. I. González-Tablas, A. Ribagorda, 2010 “Overview of Security
issues in Vehicular Ad-hoc Networks”
[8]
L. Malina, J. Hajný, 2012
“Group Signatures for Secure and Privacy Preserving
Vehicular Ad Hoc Networks”
[9]
M. Raya, P. Papadimitratos, I. Aad, D. Jungels, J.-P. Hubaux, 2007 “Eviction of
Misbehaving and Faulty Nodes in Vehicular Networks”
[10] A. Tajeddine, A. Kayssi, A. Chehab, 2010 “A Privacy-Preserving Trust Model for
VANETs”
[11] M. Raya, P. Papadimitratos, V. D. Gligor, J. Hubaux, 2007 “On Data-Centric Trust
Establishment in Ephemeral Ad Hoc Networks”
33
[12] F. Dotzer , L. Fischer, P. Magiera, 2005 “VARS: A Vehicle Ad-Hoc Network
Reputation System”
[13] 4. A. Abdullahi, I. Brown, F. El-Moussa, 2012 “Privacy in the age of Mobility and
Smart Devices in Smart Homes”
[14] L. Eschenauer, V. D. Gligor, 2003 “A Key-Management Scheme for Distributed
Sensor Networks”
[15] R. Vasilache, I. Gavrila, A. Grigorescu, L. Gheorghe, 2013 “Comparative
Evaluation of Trust Mechanisms for Wireless Sensor Networks”
[16] R. A. Shaikh, H. Jameel, B. J. d’Auriol, H. Lee, S. Lee, Young-Jae Song, 2009
“Group-Based Trust Management Scheme for Clustered Wireless Sensor Networks”
[17] M. Raya, A. Aziz and J. Hubaux, 2006 “Efﬁcient Secure Aggregation in VANETs”
[18] A. Perrig, R. Szewczyk, J.D. Tygar, V. Wen, D. E. Culler, 2002 “SPINS: Security
Protocols for Sensor Networks”
[19] C. Karlof, N. Sastry, D. Wagner, 2004 “TinySec: A Link Layer Security
Architecture for Wireless Sensor Networks”
[20] M. Luk, G. Mezzour, A. Perrig, V. Gligor, 2007 “MiniSec: A Secure Sensor
Network Communication Architecture”
[21] P. Marchetta, A. Salvi, E. Natale, A. Tirri, M. Tufo, D. De Pasquale, 2012 “S2MOVE: Smart and Social Move”
[22] O. Alfandi, A. Bochem, A. Kellner, D. Hogrefe,2011 “Simple Secure PKI-based
Scheme for Wireless Sensor Networks”
[23] L. Armac, et al., 2009 “Privacy-friendly smart environments”
[24] A. Dainotti, A. Pescapé, G. Ventre, 2007 “Worm traffic analysis and
characterization”
[25] S. Colleen, D. Moore, 2004 “The spread of the witty worm”
[26] A. Dainotti, A. King, K. Clay, F. Papale, A. Pescapé, 2012 “Analysis of a stealth
scan from a Botnet”
34

Elaborato Iandolo Luca N46001245

Transcript

Documenti analoghi

L`experience delle tecnologie dei veicoli connessi nelle automobili

si è chiusa la prima giornata di smart mobility world,la più grande

La domotica per la tua casa subito nelle tue mani

Brochure

scarica presentazione - Circuito Green City Energy

Scarica il comunicato stampa in pdf

NeMo FVG - Regione FVG

Pag. 27 - Una City Car più piccola della Smart: la Gordon Murray T.25