Extended Summary of "Automated Discovery of Denial-of-Service Vulnerabilities in Connected Vehicle Protocols"

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Elettronica e Informatica
Extended summary of “Automated
Discovery of Denial-of-Service
Vulnerabilities in Connected Vehicle
Protocols”
Tesi di Laurea Triennale
Laureando:
Filippo OLIVO
Relatore:
prof. Andrea DE LORENZO
_____________________________________
ANNO ACCADEMICO 2020-2021

2. Indice
1 Introduzione 2
2 Struttura CVAnalyzer 2
2.1 Modello (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Model Checker (2) e Probabilistic Model Checker (3) . . . . . . . . . . . . . . 3
3 Vunlerabilità 3
3.1 P2PCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Test e validazione risultati 6
5 Possibili soluzioni e conclusioni 6
6 Riferimenti bibliografici 7
1

3. 1 Introduzione
La tecnologia Connected Veichle (CV) permette le trasmissioni di importanti informazioni per
sicurezza e mobilità sia fra veicoli (V2V) sia fra veicolo e infrastruttura (V2I). Con l’aumento
di utilizzo delle tecnologie CV aumentano anche le possibilità di attacco. L’articolo propone,
quindi, un metodo di analisi rigorosa e automatizzata per l’ individuazione di attacchi DoS nei
protocolli di CV, più nello specifico nello standard IEEE 1609, responsabile della comunica-
zione tra dispositivi, e il PMP (Platoon Managment Protocol), responsabile della gestione dei
veicoli nella rete. A differenza di lavori precedenti viene prosposto un’analisi automatizzata
per l’individuazione e la valutazione delle vunlerabilità nelle versione più recenti del protocollo
IEEE 1609 e dei PMP
2 Struttura CVAnalyzer
Il CVAnalyzer viene realizzato al fine di individuare vulnerabilità sfruttabili per compromettere
la disponibilità dei servizi e valutare il loro impatto sulla sicurezza. Di seguito riportato la
struttura:
2.1 Modello (1)
Il modello è composto da alcune Protocol State Machines (PMS) identiche fra loro (una per ogni
dispositivo connesso) e da un ambiente controllato dall’attaccante. Quest’ultimo ha il compito
di gestire i pacchetti generati dalle PMS. L’attaccante è in grado sia di monitorare i pacchetti tra-
smessi nell’ambiente sia di inviare pacchetti al fine di farli processare dalle PMS. Una Protocol
State Machine è una macchina a stati finiti rappresentante un dispositivo della rete CV (compre-
sa una per l’attaccante). Per permettere la comunicazione tra le varie PMS viene implementato,
nell’ambiente, un canale di comunicazione composto dalle code chi,j (canale di comunicazione
fra il dispositivo i e il dispositivo j). Risulta quindi possibile, anche all’attaccante inviare pac-
chetti ad un singolo dispositivo. Nelle successive analisi le operazioni crittografiche vengono
considerate sicure e inviolabili dall’attaccante.
2

4. 2.2 Model Checker (2) e Probabilistic Model Checker (3)
Vengono implementati due tipi di model checker: un Model Checker tradizionale (MC) e un Pro-
babilistic Model Checker (PMC). Il model checker tradizionale viene utilizzato per indentificare
le vulnerabilità presenti nei protocolli analizzati. Dato il modello precedentemente descritto e
data una proprietà, il MC è in grado di identificare i casi nei quali la proprietà viene violata e di
fornire una procedura che porta a tale violazione.
Il CVAnayzer, in questo paper, viene utilizzato per analizzare le seguenti proprietà di disponibi-
lità:
1. Il livello di applicazione deve essere sempre in grado di processare pacchetti validi
2. Implicazione di 1: Tutti i dispositivi CV devono eventualmente essere in grado di appren-
dere certificati sconosciuti
Il PMC viene utilizzato per eseguire valutazione del rischio (probabilità di successo e costo in
termini di tempo per l’attacco) sulle vulnerabilità individuate dal MC. Nel PMC viene assegnata
una probabilità ad ogni transizione di stato.
3 Vunlerabilità
L’analisi è stata condotta sul protocollo di comunicazione IEEE 1609, più precisamente nel
P2PCD, dove sono state individuate 4 vulnerabilità, e su due PMP, PLEXE e VENTOS, dove
sono state individuate altre 15 vulnerabilità.
3.1 P2PCD
Nella versione IEEE 1609.2, viene introdotto l’utilizzo dei certificati digitali per permettere la
firma digitale al fine di garantire confidenzialità, autenticità e integrità dei pacchetti. Ricevuta
una SPDU (Secure Protocol Data Unit), il dispositivo costruisce una catena di certificati per col-
legare il certificato di firma della SPDU ad un ad un certificato noto, al fine di poter considerare
il dato ricevuto affidabile. Nel caso in cui un dispositivo non fosse in grado di generare tale ca-
tena di certificati, in quanto sconosciuta la Certification Autority che ha rilasciato il certificato
di firma, richiede agli altri dispositivi CV i certificati mancanti (richiesta in broadcast). Tale
richiesta avviene tramite la procedura P2PCD (Peer to Peer Certificate Distribution). Di seguito
riportati i passaggi principali della procedura P2PCD:
1. V1 invia una SPDU a V2 firmato col certificato ee1 rilasciato da ca1
2. V2, non conoscendo ca1, inserisce HashedId8 di ca1, presente nella SPDU ricevuta, nella
coda dei certificati sconosciuti e invia una learning request (in assenza di learning request
pendenti per lo stesso certificato) contenente HashedId3 di ca1
3. V1 verifica se HashedId3 corrisponde al hash a 3 byte di un certificato noto. In caso di
risposta affermativa genera la learning response, imposta un valore per il timer di backoff
e inizializza a 0 il valore del contatore delle learning response inviate da altri dispositivi
per lo stesso identificativo HashedId3
4. Se dopo lo scadere del timer di backoff il contatore ha valore minore del valore di soglia
V1 invia il certificato (tramite PDU non firmata)
3

5. L’obbiettivo dell’attaccante è quello di impedire il processo di apprendimento di un certificato
sconosciuto. Per far ciò può:
1. Impedire a V1 di inviare la learning response (N1)
2. Impedire a V2 di inviare la learning request (N2, N3, N4)
Per esempio, in N1 l’attaccante, dopo che il dispositivo V1 ha inizializzato il timer di backoff
per l’invio della learning response, invia un numero sufficiente di learning response malevo-
le (maggiore del valore di soglia, solitamente 3) tali per cui l’HashedId3 dei certificati creati
dall’attaccante corrisponde a HashedId3 di ca1 (collisione di hash, due dati deversi hanno il me-
desimo valore di hash). L’attaccante deve inviare le learning response nella finestra d’attacco
(da inizializzazione timer backoff alla sua scadenza) sconosciuta.
L’attacco N3, invece, richiede l’invio da parte dell’attaccante di una learning request al solo di-
spositivo V2. Infatti se, dopo che V2 ha ricevuto la SPDU e inserito HashedId8 di ca1 nella
coda dei certificati sconosciuti riceve una learning request per lo stesso certificato ca1 (medesi-
mo HashedId3 di ca1), elimina il valore appena inserito dalla coda e non invia alcune learning
request. Siccome la learning request malevola è stata ricevuta solo a V2, V1 non invierà alcuna
4

6. learning response.
Gli attacchi N1-4 hanno successo solo se l’attaccante invia il/i pacchetto/i malevoli nell’ esatta
finestra temporale di attacco, non nota ma stimabile. E’ stato, quindi, utilizzato il PMC valu-
tare la probabilità di successo: per l’attacco N1 questa si attesta al 99,47% mentre per gli altri
al 99,99%. Questa differenza è dovuta al fatto che per N1 l’attaccante deve inviare 3 pacchetti
mentre per gli altri è sufficiente 1 pacchetto.
3.2 PMP
L’analisi è stata condotta sui PMP VENTOS e PLEXE. I veicoli si organizzano in plotoni, com-
posti da veicoli che viaggiano lungo la stessa linea; ogni plotone ha un leader con Id 0 e dei
membri con profondità crescente. I PMP definiscono alcune manovre fondamentali:
1. Fusione: due plotoni che viaggiano sulla stessa linea possono unirsi per formare un plotone
unico (la dimensione dopo l’unione non deve superare la dimensione ottima)
2. Divisione: un plotone può dividersi in due plotoni più piccoli. Deve essere richiesta dal
leader del plotone attraverso SLIT REQ inviata al veicolo soggetto a divisione. Esso
risponderà al leader con una SPLIT ACCEPT
3. Abbandono: un membro o il leader può abbandonare il plotone quando giunge a de-
stinazione. Per abbandonare il plotone un membro dovrà inviarne richiesta al leader
(LEAVE REQ) che provvederà a dividere il plotone al veicolo successivo e al veicolo
precedente del richiedente
Il Model checker ha identificato ha identificato 15 vulnerabilità in VENTOS e PLEXE. Le vul-
nerabilità A1 e A2 permettono all’attaccante di unirsi al plotone rispettivamente come leader e
membro. Consideriamo V1 leader e V2 membro
1. Split trigger attack: comprende gli attacchi A3 e A4. Ci troviamo nella configurazione
come in figura.
Nello specifico l’attacco A3 prevede che l’attaccante invii ripetutamente LEAVE REQ
al leader, V2, con profondità 2 e successivamente, a fine manovra di abbandono, inviti
V2 ad unirsi al plotone, riducendo sicurezza ed efficienza. La vulnerabilità su cui si basa
l’attacco è legata al mancato controllo da parte del leader della corrispondenza di valore
di profondità e reale identità del dispositivo che richiede la divisione
2. Block attack: Attacchi più comuni e comprendono A5-A14. L’attacco A7, ad esempio, ha
l’intento di impedire una manovra di divisione. La configurazione iniziale è:
5

7. L’attaccante riceve una SPLIT REQ dal leader alla quale non risponde con SPLIT AC-
CEPT, causando cosı̀ l’impossibilità di portare a termine la manovra in modo sicuro. Tale
vulnerabilità è causata dall’assenza di meccanismi di ripristino di errori di comunicazione.
3. Inconsistency Attack: ha l’obbiettivo di assegnare ad un membro un valore di profondità
inconsistente rispetto al valore corrispondente allo stesso membro nella lista dei membri
detenuta dal leader.
4 Test e validazione risultati
Negli esperimenti condotti vengono utilizzati 3 dispositivi (OBU1, OBU2, OBU3) configurati
in modo tale che OBU2 non sia in grado di verificare i pacchetti ricevuti da OBU1 mentre sia
OBU1 che OBU2 siano in grado di verificare i pacchetti ricevuti da OBU3 (attaccante). Con
questa configurazione tutti gli attacchi sono risultati validi.
Per quanto riguarda il loro impatto sulla sicurezza è stato verificato che:
1. Gli attacchi al P2PCD eliminano completamente i benefici di sicurezza dati della comu-
nicazione V2V
2. Gli attacchi ai PMP possono compromettere la stabilità della velocità, riducendo efficienza
e sicurezza
5 Possibili soluzioni e conclusioni
Per prevenire gli attacchi dovuti alle vulnerabilità individuate vengono alcune possibili soluzioni:
1. Verificare le learning response in ingresso. Può essere elusa dall’attaccante se conosce
legittimamente il certificato
2. Aumentare dimensione dei valori di hash. Ciò comporterebbe un aumento della difficoltà
per generare una collisione di hash, ma anche un aumento delle dimensioni del pacchetto
e quindi una maggior latenza
3. Rendere proibite le comunicazioni in unicast
4. Verificare l’identità del mittente tramite certificato (piuttosto che dal solo valore di pro-
fondità), garanzia di indentità per ogni dispositivo CV
5. Tenere traccia delle configurazioni del plotone in remoto o in locale
6

8. 6. Prevedere un sistema di ripristino degli errori di comunicazione
Obbiettivo dei ricercatori è quello di poter, in successivi lavori, utilizzare il CVAnalyzer su altri
protocolli e per testare altre proprietà anche non riguardanti la disponibilità dei servizi.
6 Riferimenti bibliografici
[1]: IEEE 1609 WG. IEEE Standard for Wireless Access in Vehicular Environments–Security
Services for Applications and Management Messages. IEEE Std 1609.2-2016 (Revision of IEEE
Std 1609.2-2013), 2016.
7