Deep Learning: La Nuova Frontiera per la Sicurezza del CAN Bus nelle Auto

Ciao a tutti! Oggi voglio parlarvi di qualcosa che riguarda da vicino le nostre auto, anche se magari non ce ne rendiamo conto tutti i giorni: la sicurezza della loro rete interna. Sì, perché le auto moderne sono veri e propri computer su ruote, pieni zeppi di centraline elettroniche (le famose ECU) che comunicano tra loro continuamente. E come comunicano? Principalmente attraverso un sistema chiamato CAN bus.

Ma cos’è questo CAN bus?

Immaginatelo come il sistema nervoso centrale del veicolo. È una rete che permette a tutte le componenti elettroniche – dal controllo motore al cambio, dai freni all’infotainment – di scambiarsi informazioni vitali. Grazie al CAN bus, tutto funziona in modo coordinato ed efficiente. È una tecnologia fantastica, affidabile, relativamente economica e facile da implementare, motivo per cui è diventata lo standard de facto nell’industria automobilistica. Permette di ridurre la complessità dei cablaggi e semplifica la progettazione.

Esistono bus CAN ad alta e bassa velocità, a seconda dell’urgenza dei dati da trasmettere (il controllo motore ha bisogno di più velocità rispetto ai controlli delle luci, per esempio). Ogni messaggio sulla rete ha un suo identificatore univoco (CAN ID), che ne stabilisce anche la priorità: ID più basso significa priorità più alta. Questo ID permette alle varie ECU di capire se un messaggio è rilevante per loro o meno.

La struttura di un messaggio CAN è ben definita:

• Start of Frame (SOF): Segnala l’inizio del messaggio (1 bit).
• Arbitration ID: L’identificatore che determina la priorità (11 o 29 bit).
• Data Length Code (DLC): Indica la lunghezza dei dati (fino a 4 bit).
• Data Field: Il contenuto effettivo del messaggio (fino a 64 bit, ovvero 8 byte).
• Cyclic Redundancy Check (CRC): Per verificare l’integrità del messaggio (16 bit).
• Acknowledge (ACK): Conferma di ricezione corretta (2 bit).
• End of Frame (EOF): Segnala la fine del messaggio (7 bit).

Il Tallone d’Achille: La Mancanza di Sicurezza

E qui arriva il punto dolente. Quando il protocollo CAN è stato sviluppato, la sicurezza informatica non era una preoccupazione primaria come oggi. Risultato? Il CAN bus, di base, non ha meccanismi di autenticazione né di crittografia. Questo significa che, se qualcuno riesce ad accedere alla rete (fisicamente tramite la porta OBD-II, quella usata per la diagnosi, o in modalità wireless tramite Bluetooth, Wi-Fi, 4G/5G), può potenzialmente ascoltare tutto il traffico e persino inviare messaggi falsi.

Questo apre le porte a una serie di attacchi piuttosto preoccupanti:

• Denial of Service (DoS): L’attaccante inonda il bus con messaggi ad alta priorità, impedendo alle comunicazioni legittime di passare. Immaginate se i freni non ricevessero più i comandi corretti!
• Fuzzy Attack: Vengono inviati messaggi con ID e dati casuali ad alta frequenza, mandando in tilt il sistema.
• Spoofing Attack: L’attaccante invia messaggi falsi fingendo che provengano da una centralina legittima (es. falsificando i dati del contagiri o dell’indicatore di marcia).
• Replay Attack: Vengono registrati messaggi validi (es. il comando di sblocco porte) e reinviati in un secondo momento.
• Masquerade Attack: Un nodo compromesso si finge un altro nodo legittimo, intercettando e sostituendo i suoi messaggi.

Questi attacchi non sono solo teorie; sono stati dimostrati e possono avere conseguenze gravissime sulla sicurezza dei passeggeri.

Le Difese Tradizionali Non Bastano

Certo, si potrebbe pensare di applicare le classiche tecniche di cybersecurity come la crittografia (PKI) o i codici di autenticazione dei messaggi (MAC). Il problema è che le ECU delle auto hanno spesso risorse computazionali limitate (potenza di calcolo, memoria) e il CAN bus deve garantire comunicazioni in tempo reale. Implementare algoritmi crittografici complessi sarebbe troppo pesante e lento, oltre a creare problemi di compatibilità con i sistemi esistenti.

Entra in Scena l’Intelligenza Artificiale: L’IDS basato su Deep Learning

Allora come possiamo proteggere il CAN bus? Una soluzione promettente sono gli Intrusion Detection Systems (IDS), sistemi progettati per monitorare il traffico di rete e rilevare comportamenti anomali o sospetti. E qui, amici miei, entra in gioco la potenza del Deep Learning (DL).

Il Deep Learning, una branca dell’intelligenza artificiale, è incredibilmente bravo a identificare pattern complessi all’interno di grandi quantità di dati. E il traffico CAN bus è esattamente questo: un flusso enorme di dati sequenziali. L’idea è quindi quella di “insegnare” a un modello di Deep Learning come appare il traffico CAN normale, in modo che possa riconoscere quando qualcosa non va, quando c’è un’intrusione.

Nel nostro studio, abbiamo esplorato proprio questo: l’uso di diversi modelli di Deep Learning per scovare attacchi sul CAN bus. Abbiamo lavorato con alcune varianti delle Reti Neurali Ricorrenti (RNN), perfette per analizzare dati sequenziali nel tempo:

• LSTM (Long-Short Term Memory): Ottime per catturare dipendenze a lungo termine nei dati, superando alcuni limiti delle RNN tradizionali.
• GRU (Gated Recurrent Unit): Simili alle LSTM ma con una struttura un po’ più semplice, spesso altrettanto efficaci.
• Bi-LSTM (Bi-directional LSTM): Elaborano la sequenza in entrambe le direzioni (passato e futuro), ottenendo una comprensione contestuale ancora migliore.

Ma non ci siamo fermati qui. Abbiamo anche utilizzato un modello basato su Reti Neurali Convoluzionali (CNN), solitamente usate per le immagini:

• VGG-16: Abbiamo trasformato i dati sequenziali del CAN bus in una sorta di “immagine” per permettere a VGG-16 di analizzarne le caratteristiche “spaziali”, cioè le relazioni tra i diversi campi del messaggio visti come pixel.

Rispetto agli approcci tradizionali basati su regole fisse (che funzionano solo per attacchi già noti) o a metodi statistici di rilevamento anomalie (che possono generare molti falsi allarmi), i modelli DL offrono maggiore adattabilità e capacità di riconoscere anche attacchi nuovi o mascherati, imparando direttamente dai dati senza bisogno di definire regole manualmente.

Come Abbiamo Lavorato: Dati e Metodologia

Per addestrare e testare i nostri modelli, non ci siamo accontentati di un solo set di dati. Abbiamo utilizzato ben tre dataset pubblici, noti nel campo della ricerca sulla sicurezza automobilistica:

• Car Hacking Dataset (HCRL): Contiene attacchi DoS, Fuzzy, e Spoofing (RPM e Gear) registrati da un’auto reale.
• OTIDS Dataset: Include attacchi DoS, Fuzzy e Impersonation su una KIA SOUL.
• Survival Analysis Dataset: Si concentra su attacchi Flooding (simile a DoS), Fuzzy e Malfunction (attacco mirato a specifici ID) su tre auto diverse (Hyundai Sonata, Kia Soul, Chevrolet Spark).

La nostra mossa chiave è stata unire questi tre dataset. Perché? Per creare un set di dati più ricco e variegato possibile, che coprisse un’ampia gamma di attacchi e condizioni diverse. Questo aiuta i modelli a generalizzare meglio, cioè a riconoscere attacchi anche in scenari leggermente diversi da quelli visti durante l’addestramento.

Il processo è stato più o meno questo:
1. Preprocessing dei Dati: Abbiamo uniformato i nomi delle colonne, convertito i valori esadecimali (tipici del CAN) in decimali, gestito valori mancanti e normalizzato i dati. Per VGG-16, abbiamo trasformato sequenze di messaggi CAN in piccole immagini 9×9 pixel (poi ridimensionate a 224×224).
2. Etichettatura: Abbiamo etichettato ogni messaggio come “Benigno” o “Attacco” (per la classificazione binaria) oppure specificando il tipo di attacco (DoS, Fuzzy, Spoofing RPM, Spoofing Gear, Impersonation, ecc. – per la classificazione multiclasse).
3. Unione dei Dataset: Abbiamo combinato i dati preprocessati in un unico grande file, facendo attenzione a gestire correttamente i timestamp.
4. Addestramento e Test: Abbiamo diviso il dataset combinato (e anche quelli singoli per confronto) in un set di addestramento (80%) e uno di test (20%). Abbiamo addestrato i modelli LSTM, GRU, Bi-LSTM e VGG-16 e poi ne abbiamo valutato le performance sul set di test usando metriche standard come accuratezza, precisione, richiamo (recall) e F1-score.

I Risultati: Chi Vince la Sfida?

E allora, cosa abbiamo scoperto? I risultati sono stati davvero interessanti!

Nella classificazione binaria (solo distinguere tra “normale” e “attacco”):

• LSTM si è dimostrato eccezionale sui singoli dataset, raggiungendo accuratezze altissime (fino al 99.89% sul Car Hacking Dataset). Tuttavia, sul dataset combinato, le sue performance sono calate un po’, faticando a generalizzare su tutti i tipi di attacco insieme.
• GRU ha ottenuto buoni risultati, ma generalmente inferiori a LSTM.
• Bi-LSTM ha offerto un buon bilanciamento, ma con qualche incertezza sul dataset combinato.
• VGG-16, pur essendo un modello “visivo”, ha sorpreso! Ha mostrato una grande capacità di generalizzazione, ottenendo l’accuratezza più alta (94.62%) e un buon bilanciamento generale proprio sul difficile dataset combinato.

Nella classificazione multiclasse (identificare il tipo specifico di attacco):

• Qui VGG-16 ha letteralmente dominato! Ha raggiunto un’accuratezza del 100% nel riconoscere specifici tipi di attacco su diversi dataset (es. DoS e RPM Spoofing sul Car Hacking; DoS e Impersonation su OTIDS; Flooding e Malfunction sul Survival Analysis). Anche sul dataset combinato, VGG-16 è risultato il migliore, identificando gli attacchi DoS con il 100% di accuratezza, precisione, recall e F1-score.
• Gli altri modelli (LSTM, GRU, Bi-LSTM) hanno mostrato buone performance su alcune classi ma sono stati meno consistenti e precisi di VGG-16 nell’identificare correttamente *tutti* i diversi tipi di attacco, specialmente quando messi di fronte alla varietà del dataset combinato.

Confrontando i nostri risultati (in particolare quelli di VGG-16) con lavori precedenti che utilizzavano machine learning tradizionale (come SVM o Decision Tree) sugli stessi dataset, abbiamo confermato la superiorità degli approcci basati su Deep Learning in termini di accuratezza e capacità di rilevamento.

Sfide Future e Prossimi Passi

Certo, non è tutto risolto. Anche se i risultati sono promettenti, ci sono ancora sfide da affrontare.
Una delle principali è il deploy in tempo reale. Questi modelli DL, specialmente VGG-16, possono essere computazionalmente intensivi. Farli girare su una ECU di un’auto, con le sue risorse limitate, mantenendo una latenza bassissima (fondamentale per reagire in tempo a un attacco) è complicato. Bisogna lavorare su tecniche di ottimizzazione (come pruning, quantizzazione) per rendere i modelli più leggeri ed efficienti.

Un’altra idea è quella di non integrare l’IDS direttamente nelle ECU esistenti, ma di introdurlo come un nodo dedicato sulla rete CAN, dotato di hardware specifico per l’intelligenza artificiale. Questo scaricherebbe il carico computazionale senza appesantire le altre centraline.

Inoltre, vogliamo esplorare ulteriormente la combinazione di caratteristiche temporali (quelle catturate da LSTM/GRU) e spaziali (quelle viste da VGG-16) per creare modelli ibridi ancora più potenti e robusti.

Insomma, la strada per rendere le nostre auto veramente a prova di hacker grazie al deep learning è ancora in corso, ma i progressi sono entusiasmanti. Stiamo sviluppando degli scudi digitali sempre più intelligenti per proteggere il cuore pulsante dei nostri veicoli. È un campo di ricerca affascinante e cruciale per la sicurezza di tutti noi sulla strada.

Fonte: Springer