IT202100022919A1 - Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo - Google Patents

Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo Download PDF

Info

Publication number
IT202100022919A1
IT202100022919A1 IT102021000022919A IT202100022919A IT202100022919A1 IT 202100022919 A1 IT202100022919 A1 IT 202100022919A1 IT 102021000022919 A IT102021000022919 A IT 102021000022919A IT 202100022919 A IT202100022919 A IT 202100022919A IT 202100022919 A1 IT202100022919 A1 IT 202100022919A1
Authority
IT
Italy
Prior art keywords
messages
message
nodes
node
check
Prior art date
Application number
IT102021000022919A
Other languages
English (en)
Inventor
Christian Rosadini
Simona Chiarelli
Walter Nesci
Sergio Saponara
Alessio Gagliardi
Pierpaolo Dini
Original Assignee
Marelli Europe Spa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Marelli Europe Spa filed Critical Marelli Europe Spa
Priority to IT102021000022919A priority Critical patent/IT202100022919A1/it
Priority to EP22191648.9A priority patent/EP4145765A1/en
Priority to US17/929,370 priority patent/US20230080521A1/en
Priority to CN202211085952.9A priority patent/CN115776383A/zh
Publication of IT202100022919A1 publication Critical patent/IT202100022919A1/it

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416Event detection, e.g. attack signature detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84Vehicles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121Timestamp
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/146Tracing the source of attacks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Small-Scale Networks (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
  • Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

DESCRIZIONE dell?invenzione industriale dal titolo:
"Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo?
TESTO DELLA DESCRIZIONE
La presente invenzione riguarda tecniche di protezione da attacchi informatici in una rete di comunicazione, in particolare CAN (Controller Area Network), di un veicolo comprendente un bus, in particolare CAN e una pluralit? di nodi associati a detto bus in rapporto di scambio di segnale e associati almeno in parte a unit? di controllo di funzioni del veicolo.
Stato dell?arte
Il bus CAN, adottato come BUS di comunicazione negli autoveicoli, ? un mezzo di comunicazione di tipo seriale e multi-master, in cui ogni master, detto anche nodo connesso al bus ? in grado di inviare, ricevere e risolvere i conflitti di accesso contemporaneo in invio da parte di pi? nodi.
In figura 1 ? mostrato schematicamente un bus CAN 10, comprendente una pluralit? di nodi 11. In figura 1 sono indicati tre nodi 111?113. Un nodo 11 in grado di comunicare su bus CAN 10 comprende in generale, come mostrato in figura - un ricetrasmettitore CAN, o CAN Transceiver, 12, associato attraverso a una linea di trasmissione TT e una linea di ricezione TR al CAN bus 10 e configurato per gestire i livelli elettrici propri del bus CAN (livello Fisico del modello OSI);
- un controllore CAN, o CAN Controller, 13, che ? connesso attraverso rispettive linee di trasmissione CT e ricezione CR al ricetrasmettitore CAN 12, e configurato per gestire i livelli logici e la serializzazione del bus CAN 10 (livello Data link del modello OSI);
- un microcontrollore 14, che contiene la logica di invio e ricezione dei messaggi (gestione dei livelli OSI superiori al livello Data link).
Il bus 10 comprende due linee, con 10H ? indicata la linea alta del CAN bus 10, o CAN_High, con 10L la linea bassa o CAN_Low. Ai due capi del bus 10 le due linee 10H e 10L sono terminate da resistenze di terminazione 10R. In figura 1 le linee di trasmissione TT sono accoppiate alla linea alta 10H mentre le linee di ricezione TR sono accoppiate alla linea bassa 10L.
Dunque, il bus CAN 10 ? un bus differenziale, quindi ha una struttura a due linee, chiamate CAN-High 10H e CAN-Low 10R.
I procedimenti di individuazione di messaggi malevoli in un bus CAN che collega una pluralit? di nodi, ad esempio centraline, sono tesi a determinare quale messaggio ? malevolo, ma soprattutto da quale nodo o centralina esso proviene, in modo da poter risalire alla fonte stessa dell?attacco e prendere provvedimenti. I sistemi di Intrusion Detection attualmente implementati sui veicoli riescono a determinare la presenza del cyber-attacco, ma non prevedono un sistema di riconoscimento attaccante.
In Tabella 1 viene mostrata la struttura di un messaggio secondo il protocollo CAN, in particolare il messaggio di tipo Dato ? strutturato con sezioni S di bit contigue elencate di seguito nella Tabella 1:
Tabella 1
I campi di interesse del messaggio sono principalmente quello di arbitraggio S2 e quello di ACK (Acknowledge) S6. Il campo di arbitration ? costituito dall? identificativo ID (Identifier) del messaggio, che ne determina la priorit? e identifica il messaggio. Pi? piccolo ? il valore binario, maggiore ? la sua priorit?. Il bit di ACK, recessivo in origine (quindi un 1), viene sovrascritto dalle centraline o nodi 11 che ricevono correttamente il messaggio con un bit dominante. In questo modo ogni nodo riconosce l?integrit? del messaggio.
Riguardo a tale campo di arbitraggio S2, il CAN Controller 13 di un nodo 11 ricostruisce l?identificativo ID del messaggio dai segnali logici che gli arrivano (coerenti ovviamente con il livello fisico rilevato dal CAN Transceiver 12), mentre il microcontrollore 14 all?interno del nodo 11 stesso associa una ?variabile temporale?, detta Time Stamp, di arrivo a tale messaggio. Ogni nodo CAN 11 connesso alla rete 10 ? configurato con un set di identificativi ID che pu? trasmettere, dove ciascun identificativo ID in tale set pu? corrispondere ad un parametro di un sensore oppure ad una funzione specifica (diagnosi, ecc.). Tali identificativi ID di messaggio, seppur diversi fra diversi nodi 11, possono essere clonati da un possibile attaccante, se questo acquisisce il controllo di uno dei nodi della rete. I messaggi inviati attraverso la rete CAN 10 inoltre, possono avere una natura periodica, quindi trasmesse in un periodo ben preciso, oppure aperiodica, trasmessi al verificarsi di eventi.
Dunque sono note tecniche basate sulla deriva temporale, che sono orientate ai messaggi che in linea di principio sono pensati periodici, dunque, sfruttando la variabile temporale ? possibile risalire ad una stima di periodo tra due messaggi consecutivi con stesso identificativo ID. Se un messaggio ? periodico esso ? associato ad un Timestamp (tempo di ricezione) specifico, ma comunque costante nel periodo. Dunque, si assume che, e per quanto simili, bench? prodotte dalla stessa casa produttrice e anche con stessi componenti circuitali, due ECU distinte che rappresentano due nodi 11 abbiano due drift, o derive, temporali differenti. Ogni ECU infatti pu? funzionare grazie al rispettivo segnale di clock, e sebbene due ECU possano funzionare con un clock alla stessa frequenza, nella realt? ci? si traduce come un drift random nel periodo fra i due segnali che si ripercuote nella trasmissione di messaggi CAN. Dunque tale sfasamento rappresenta di fatto un fattore non riproducibile intrinseco di ciascun nodo ECU, che pu? essere stimato attraverso alcune tecniche.
Si descrivono qui ora alcuni tipici scenari di attacco. Un tipo di attacco ? detto attacco di fabbricazione. Attraverso una centralina del veicolo compromessa in modo tale da essere un aggressore forte, l'avversario fabbrica e inietta messaggi con ID (identificativo), DLC (Data Length Code) e dati falsificati. L'obiettivo di questo attacco ? quello di annullare qualsiasi messaggio periodico inviato da centraline legittime importanti per la sicurezza, in modo che le loro centraline riceventi si distraggano o diventino inutilizzabili. Ad esempio l?attaccante inietta diversi messaggi malevoli con un dato ID, ad esempio 0xB0, che di solito viene inviato da una centralina legittima, ad una frequenza elevata. Cos?, altri nodi che ricevono regolarmente il messaggio 0xB0 sono costretti a ricevere i messaggi di attacco fabbricati pi? spesso di quelli legittimi. In un tale caso, la centralina attaccante sta attuando un ?attacco di fabbricazione? sul messaggio 0xB0 e sul suo trasmettitore originale, la centralina legittima.
Un altro tipo di attacco ? detto attacco in sospensione. Per effettuare un attacco in sospensione, l'attaccante necessita di una sola centralina debolmente compromessa. Come nel caso di attacchi Denial-Of-Service (DoS), l'obiettivo di questo attacco ? quello di fermare/sospendere la trasmissione della centralina debolmente compromessa, impedendo cos? la consegna/propagazione di informazioni che viene acquisita da altre centraline sulla rete CAN. Questo perch? alcune centraline devono ricevere informazioni specifiche da altre centraline per un corretto funzionamento. Pertanto, l'attacco in sospensione pu? danneggiare non solo la centralina debolmente compromessa, ma anche altre ECU riceventi.
Un altro tipo di attacco ? detto attacco mascherato. Per effettuare un attacco mascherato, l'attaccante deve compromettere due centraline, una come attaccante forte e l'altra come attaccante debole. L?obiettivo di questo attacco ? quello di manipolare una centralina mentre si scherma la condizione che la centralina ? compromessa. Fino a un dato istante di mascheratura, l'avversario controlla e apprende quali messaggi vengono inviati con quale frequenza dal suo attaccante pi? debole, ad esempio l?attaccante debole invia il messaggio 0xB0 ogni 20ms. Poich? la maggior parte dei messaggi della rete sono periodici e trasmessi ad esempio via CAN, ? facile imparare i loro identificativi ID e gli intervalli di trasmissione. Una volta che ha appreso l'ID e la frequenza di un messaggio, all? istante di mascheratura l'avversario ferma la trasmissione del suo attaccante debole e utilizza il suo attaccante forte per fabbricare e iniettare messaggi di attacco con ID = 0xB0. Interrompere la trasmissione dell?attaccante debole e sfruttare l?attaccante forte per la trasmissione di messaggi malevoli serve a superare l'incapacit? dell'attaccante debole di iniettare messaggi. Dopo l?istante di mascheratura, il trasmettitore originale di 0xB0, l?attaccante debole, non invia quel messaggio, mentre l?attaccante forte lo invia invece alla sua frequenza originale. Quindi, quando si osserva il traffico del bus, ad esempio CAN, la frequenza del messaggio 0xB0 rimane la stessa, mentre il suo trasmettitore ? cambiato.
Da questi esempi risulta evidente l?importanza di riuscire a discriminare da quale centralina realmente provenga l?attacco, specialmente nel caso di attacco mascherato. A questo riguardo si nota che un inconveniente dei bus come il CAN ? la mancanza di un MAC-Address che permetta di risalire direttamente alla centralina/dispositivo 11 che ha inviato il messaggio in quel preciso momento sul bus, a differenza ad esempio del protocollo Ethernet in cui ? invece presente.
La presente invenzione si prefigge lo scopo di ottenere un procedimento di monitoraggio che permetta di identificare la centralina che trasmette un messaggio, in particolare un messaggio legato a un attacco.
Secondo la presente invenzione, tale scopo viene raggiunto grazie ad un procedimento di protezione nonch? a un corrispondente dispositivo di protezione aventi le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono.
L?invenzione verr? descritta con riferimento ai disegni annessi, forniti a puro titolo di esempio non limitativo, in cui:
- la Figura 1 ? gi? stata descritta in precedenza;
- la Figura 2 rappresenta uno schema che mostra un dispositivo che implementa il procedimento qui descritto;
- la Figura 3 rappresenta un diagramma temporale che mostra messaggi trasmessi sulla rete di comunicazione nell?ambito del procedimento qui descritto;
- la Figura 4 mostra un diagramma di flusso rappresentativo di fase di funzionamento del procedimento;
- la Figura 5 mostra un diagramma che rappresenta andamenti lineari calcolati da detta fase di funzionamento del procedimento;
- la Figura 6A e la Figura 6B sono diagrammi rappresentavi di funzioni di correlazione calcolate da detta fase di funzionamento del procedimento in diverse condizioni operative;
- la Figura 7 ? un diagramma schematico che rappresenta schematicamente una forma realizzativa del procedimento qui descritto;
- la Figura 8 ? un diagramma che rappresenta schematicamente fasi del procedimento qui descritto.
Secondo la soluzione qui descritta, ? previsto di inserire uno o pi? dispositivi di protezione da attacchi informatici all?interno della rete 10 del veicolo, in particolare BUS CAN, che implementa il procedimento di protezione da attacchi informatici qui descritto. Tale dispositivo di protezione da attacchi informatici pu? essere aggiuntivo rispetto alla topologia della rete esistente oppure compreso in uno dei nodi esistenti, in particolar configurando il microcontrollore 14.
Ognuno di tali dispositivi pu? essere responsabile dell?analisi del traffico dati per un numero finito di nodi della rete 10 del veicolo, che in generale descrivono una sottorete dell?intera architettura di comunicazione. Ad esempio, le sottoreti possono avere fino a 18 nodi.
Lo scopo del procedimento e dispositivo qui descritti ? quello di assicurarsi che la comunicazione sul bus CAN relativo ad una specifica sottorete non presenti anomalie come quelle precedentemente descritte.
In generale, il procedimento di protezione da attacchi informatici qui descritto prevede che per ogni rete 10 di veicolo sia resa disponibile o accessibile a un nodo di controllo (dispositivo 20) una lista di identificativi di messaggio ID, del tipo indicato in Tabella 1, da analizzare, detta lista contenendo l?informazione di quali messaggi sono periodici e quindi quali messaggi effettivamente vengono analizzati dal procedimento.
I messaggi periodici che appartengono alla lista dei messaggi fornita a priori, vengono raggruppati in base alla loro periodicit? per evitare errate classificazioni dovute al fatto che la deriva temporale di alcuni messaggi con diverso periodo ed identificativo ID (nonch? stesso nodo di provenienza) potrebbe essere la stessa. Dunque, avviene una prima operazione di clustering o raggruppamento per periodo a monte dell?analisi del drift temporale stesso.
In altre parole, il procedimento di protezione da attacchi informatici in una rete di comunicazione, in particolare CAN (Controller Area Network), di un veicolo comprendente
un bus di comunicazione, in particolare un bus CAN, una pluralit? di nodi associati a detto bus di comunicazione in rapporto di scambio di segnale e associati almeno in parte a unit? di controllo di funzioni del veicolo, detti nodi scambiando messaggi in transito fra nodi di detta pluralit? di nodi,
detti messaggi essendo contraddistinti da rispettivi identificativi di messaggio,
detto procedimento comprendendo, a un nodo di controllo (20) associato a detto bus di comunicazione,
selezionare fra i messaggi scambiati fra i nodi messaggi periodici aventi una periodicit? di trasmissione, raggruppare detti messaggi periodici in gruppi rispettivi secondo il rispettivo periodo,
eseguire una procedura di analisi messaggi dei nodi che scambiano detti messaggi periodici ricevuti comprendente, per ciascun gruppo di periodicit? di trasmissione,
ottenere tempi di arrivo ai rispettivi nodi di un insieme di messaggi periodici aventi medesimo identificativo di messaggio,
calcolare in funzione di detti tempi di arrivo valori di offset medio su sottoinsiemi successivi, di un determinato numero di messaggi, di detto insieme di messaggi ricevuti,
accumulare detti valori di offset medio per ogni identificativo rispetto a ciascun sottoinsieme successivo ottenendo valori di offset accumulato per ogni sottoinsieme successivo e un rispettivo identificativo,
identificare parametri lineari tramite calcolo di una regressione su detti valori di offset accumulato per ogni sottoinsieme successivo e rispettivo identificativo detto calcolo comprendendo calcolare un coefficiente angolare, o pendenza, della regressione, e un?intercetta, o errore di identificazione, calcolare, in base a valori di offset medio ottenuti al passo di calcolare (312) in funzione di detti tempi di arrivo valori di offset medio su sottoinsiemi successivi, un coefficiente di correlazione dell?offset medio di coppie di messaggi identificati come provenienti da uno stesso nodo, operare una prima verifica se il coefficiente di correlazione sia maggiore di una prima soglia determinata,
operare una seconda verifica se il coefficiente angolare fra due messaggi consecutivi con stesso identificativo sia maggiore di una seconda soglia determinata,
operare una terza verifica se l?intercetta fra due messaggi consecutivi sia maggiore di una terza soglia determinata,
fornire i risultati di detta prima, seconda e terza verifica a un?operazione di classificazione dei messaggi, configurata per fornire una conferma di classificazione dei messaggi secondo nodo trasmittente e identificativo di messaggio o un?indicazione di errore di classificazione in funzione di detti risultati.
Pi? in dettaglio, in figura 2 ? mostrato dunque un dispositivo 20 di protezione da attacchi connesso al CAN bus 10, insieme ai nodi 11, ossia un nodo di controllo per analizzare i messaggi scambiati sulla rete 10. Come detto, il dispositivo 20 ? un nodo di controllo della rete che ha disponibile o accessibile una lista di identificativi di messaggio ID, del tipo indicato in Tabella 1, da analizzare. Il dispositivo 20 comprende un blocco 200 rappresentativo di un?operazione di clustering e un blocco 300 rappresentativo di una procedura di analisi messaggi comprendente una procedura di fingerprinting 310, cio? di identificazione di nodi in base a rispettive impronte uniche, in particolare a impronte ottenute dalle rispettive derive temporali, e una procedura di rilevamento di anomalia 320, che in base alle identificazioni nodi rileva se un?anomalia, in particolare un attacco, ? in corso.
Come detto, preferibilmente tale dispositivo di protezione da attacchi a 20 ? compreso in un nodo con struttura analoga a quella dei nodi 11, quindi comprende un CAN transceiver 12 e un CAN controller 13 compreso in un microcontrollore 14. In figura 2, questi elementi non sono mostrati in dettaglio, il dispositivo 20 ? schematizzato al suo interno tramite blocchi che rappresentano operazioni o procedure del procedimento di attacchi qui descritto. Come detto tale procedimento pu? essere eseguito da un microcontrollore 14 configurato per eseguire tale procedimento, a valle della ricezione sul transceiver 12 dei messaggi e delle operazioni del controllore 13 (gestire i livelli logici e la serializzazione del bus CAN 10, per esempio).
Dunque, il procedimento eseguito nel dispositivo 20 comprende, una volta ricevuti messaggi, ad esempio attraverso i moduli 12 e 13, di effettuare la menzionata operazione preliminare di raggruppamento, nel blocco 200. In particolare i messaggi ricevuti, in base al loro identificativo ID e in base alla lista di identificativi di messaggio ID e relativi periodi T la cui informazione ? disponibile al dispositivo 20, vengono suddivisi in rispettivi gruppi per periodo T1?Tn.
Quindi, nel blocco 300, per ogni gruppo corrispondente a un rispettivo periodo T1?Tn ogni messaggio ricevuto al dispositivo 20 viene processato in modo da tener conto della deriva temporale.
Per ognuna delle ECU, cio? nodo 11, della rete CAN 10 a bordo veicolo, gli istanti di trasmissione di ogni messaggio periodico vengono determinati in base al segnale di clock imposto da un clock con cristallo al quarzo, presente nel nodo 11. Si indica qui, seguendo la convenzione NTP (Network Time Protocol), con il segnale di clock ?vero?, che rappresenta in ogni istante la variabile temporale vera e si indica con ?? un altro clock ?non vero? in modo da definire i termini Clock Offset, Clock Frequency e Clock Skew come segue:
Clock Offset: differenza tra le variabili temporali riportate da e In particolare, definiamo offset relativo come la differenza di due ?? consecutivi.
Frequenza di clock: la velocit? di variazione del segnale di clock vero In termini analitici altro non ? che la derivata temporale del segnale di clock non vero
Clock Skew: ? la differenza tra la frequenza associata al segnale di clock vero e quella associata a In particolare, si definisce skew relativo come la differenza di due frequenze associate a consecutive.
Se due segnali di clock hanno un offset relativo e uno skew di 0, allora si dice che sono sincronizzati. Altrimenti, sono considerati non sincronizzati. Poich? il bus CAN, come il bus 10, manca di sincronizzazione dei segnali di clock nei rispettivi nodi 11, ? considerato non sincronizzato. Gli offset e gli skew del clock dei nodi non sincronizzati dipendono esclusivamente dai loro clock locali, quindi sono distinti dagli altri.
In particolare, la ?firma temporale? (time-stamp) propria di ogni ECU 11, ? caratterizzata da un proprio skew del clock. Attraverso un'analisi approfondita dello skew per ogni ECU 11 ? possibile classificare le varie ECU in una rete CAN 10 con molti nodi.
Come riportato in Figura 3, considerando una ECU A che trasmette messaggi M0?M3 con periodo T, si assuma che qui T indichi anche il valore, di T millisecondi, e una ECU R, ECU Ricevitore, che riceve periodicamente tali messaggi M0?M3, dal punto di vista della ECU ricevitore R, poich? ? disponibile solo il suo time-stamp, si considera il suo clock come fosse quello ?vero?, A causa dell'asimmetria del clock, i messaggi periodici M0?M3 sono inviati in momenti con piccoli scostamenti dai valori ideali (ad esempio, T, 2T, 3T, ...). Si assume per semplicit? che un tempo t=0 sia il momento in cui il primo messaggio M0 ? stato inviato dall?ECU A, e sia l'offset del clock di A quando invia l'i-esimo messaggio Mi a partire da t=0. In relazione a Figura 3, l?indice indica il messaggio ricevuto. Quindi, dopo un ritardo di rete di l'ECU ricevitore R riceve quel messaggio e gli associa un time-stamp di arrivo di
dove denota il rumore nella quantizzazione del
timestamp dell?ECU ricevitore R. Cos?, gli intervalli tra ogni time-stamp di arrivo, dove con
essendo indicata la differenza della grandezza ad esempio o o di, tra il passo i e i-1, e O0=0.
Le ipotesi di lavoro sono che la variazione dell?offset
in un passo temporale ? trascurabile e il rumore ? un
termine di rumore gaussiano a media zero, cosi che un valore atteso degli intervalli di time-stamp di arrivo pu? essere stimato come:
Poich? le lunghezze dei dati dei messaggi periodici CAN, cio? i DLC (Data Length Code), sono costanti nel tempo, per ora si considera cio? la media delle differenze nei ritardi di ? considerata zero. Sulla base del time-stamp di arrivo del primo messaggio, e della media degli intervalli di time-stamp, si estrapola e determina l?istante di arrivo stimato del i-esimo messaggio come
mentre l'effettivo tempo di arrivo misurato ?
Poich? si stanno stimando i tempi di arrivo
successivi, il valore atteso ? determinato dalle misure passate. Dato che il periodo T ? costante nel tempo e quindi di nuovo il valore atteso approssima il periodo la differenza media tra i tempi stimati e misurati ? data da
Cio?, dalla periodicit? del
messaggio, possiamo stimare l'offset medio del clock,
che sar? effettivamente distinto per diversi trasmettitori.
Per stimare lo sfasamento (clock skew), i messaggi in arrivo sono processati in lotti (o batch) di dimensione N (ad esempio, N=20), su cui si calcola l?offset medio del kesimo lotto, Tale calcolo ? esplicitato tramite la seguente equazione in forma chiusa:
(1) dove ? il tempo medio di arrivo del lotto precedente, e la quantit? tra le parentesi quadre
? la differenza tra il tempo di arrivo misurato *? e il tempo di arrivo stimato per il messaggio i-esimo
Quando un valore medio di offset viene calcolato dal lotto corrente k, il suo valore assoluto viene aggiunto all'offset accumulato secondo l?equazione ricorsiva definita qui sotto:
<(2) >E? possibile utilizzare anche una diversa formulazione del clock offset medio come mostrato in Eq. 3:
(3)
in cui *? rappresenta il time-stamp misurato dell?ultimo lotto di messaggi che ? stato analizzato (cio? allo step k-1-esimo). Questo permette di ridefinire l?equazione ricorsiva che rappresenta l?evoluzione del clock offset accumulato ostante (4):
<(4) >Riprendendo a riferimento la situazione schematizzata in Figura 6, se l'ECU R dovesse determinare l'offset medio del clock per ogni N messaggi ricevuti, poich? ? derivato in riferimento al primo messaggio (di N messaggi), rappresenterebbe solo la media degli offset pi? recenti. Quindi, per ottenere l'ammontare totale dell'offset sostenuto, il clock offset accumulato i valori assoluti degli offset di clock medi devono essere sommati ed il valore assoluto dell'offset di clock medio
? pre-moltiplicato per il valore del numero di lotti
N e poi aggiunto al precedente valore di offset accumulato al passo k-1 della procedura di calcolo.
La pendenza del clock offset accumulato
rappresenta quindi il clock skew, che ? praticamente costante (per evidenza tecnica). Questo permette di stimare il clock skew dai time-stamp di arrivo e quindi di identificare il trasmettitore di messaggi per il rilevamento delle intrusioni. Per un dato identificativo ID del messaggio, si ricava il clock offset accumulato inerente ai time-stamp di arrivo. Poich? il clock skew ? costante, la dinamica del clock offset accumulato ? lineare, e pu? quindi essere ricorsivamente stimato con un modello di regressione lineare. Il problema di regressione lineare pu? essere impostato come di seguito.
<(5) >Al generico passo k-esimo della procedura di calcolo,
? l?offset accumulato sul k-esimo lotto di N messaggi
analizzati, S[k] ? il parametro di regressione, t[k] il tempo trascorso, ed e[k] l'errore di identificazione. Il parametro di regressione S[k] rappresenta la pendenza del modello lineare e quindi lo skew stimato dell'orologio. L'errore di identificazione, e[k], rappresenta il residuo che non ? spiegato dal modello (l?intercetta). Nella procedura di calcolo dei parametri S, t, O, ed e sono aggiornati ogni N messaggi, cio?, k*N messaggi sono esaminati fino al passo k. Per determinare il parametro sconosciuto, il parametro di regressione S, si usa un algoritmo ricorsivo di Minimi Quadrati Ricorsivi ?Istantaneo? (Recursive Least Square o RLS), che usa il residuo come funzione obiettivo per minimizzare la somma dei quadrati degli errori di modellazione.
Come mostrato nel diagramma di flusso di figura 4, che illustra in dettaglio la procedura 310 di fingerprinting, le equazioni (1)-(5) definiscono un?implementazione dell?operazione 310 di fingerprinting attraverso un algoritmo ricorsivo di Minimi Quadrati Ricorsivi ?Istantaneo? (Recursive Least Square o RLS), in cui in un passo 312, corrispondente all?implementazione dell?equazione (1), ? previsto di calcolare un valore di offset medio Oavg[k] per uno pi? intervalli di un numero N di messaggi ricevuti. Quindi in un passo 314, corrispondente all?implementazione dell?equazione (2), ? previsto di calcolare un valore accumulato di offset Oacc[k] corrente aggiungendo al valore precedente, calcolato all'istante precedente k-1, di valore accumulato il valore di offset medio Oavg[k] sull'intervallo corrente, k, moltiplicato per il numero N di messaggi ricevuti
In questo modo viene accumulata la deriva temporale, o clock offset, che ? indicata con Oacc[k].
Accumulando valori di Clock Offset come indicato nell?equazione 3, si ha un incremento di Clock Offset, cio? il clock offset accumulato che ? sostanzialmente lineare e quindi descrive graficamente una retta, che sostanzialmente ? unica per ognuno degli identificativi di messaggio di ogni cluster, calcolato in funzione del periodo T.
Al passo 316 dunque si risolve il problema di regressione come nell?equazione (5), calcolando in particolare il parametro di regressione S e l?errore di identificazione e relativi ai valori di clock offset accumulato ricavati ai passi precedenti.
Qui nel seguito ? riportato un esempio in pseudocodice utilizzato per il calcolo e l?aggiornamento ricorsivo dei parametri del modello lineare. Ai punti 23 e 24 sono presenti rispettivamente le equazioni (1) e (2) (passi 312-314) di calcolo del clock offset accumulato che viene inserito nella procedura 300 di analisi messaggi. Una funzione SKEWUPDATE (t,e) aggiorna i valori di skew (S[k]), in essa i passi 3-5 corrispondono all?algoritmo RLS. I passi 7-21 corrispondono al calcolo degli intervalli di timestamp Tn, dai tempi di arrivo an-an-1, il passo 22 corrisponde al calcolo dell?intervallo medio. Nel passo 25 si calcola l?errore di identificazione(k) come differenza fra l?offset accumulato e la retta con pendenza lo skew S[k-1] al passo k-1. Allo skew S[k], o parametro di regressione, ? associato il valore della funzione SKEWUPDATE (t,e) ai minimi quadrati.
1. Initialize: S[0]=P[0]=?I
2. Function SKEWUPDATE(t,e) ? algoritmo RLS
3.
4.
5. return
6. end function
7. for k-esimo step do
8. a0<-timestamp arrivo messaggio ricevuto pi? recente
9. n<- 1
10. while n? ( do
11. If tempo corrente >> an-1 then
12. /* non riceve pi? il messaggio */
13. an? aN<-valori significativamente elevati 14. Tn? TN<-valori significativamente elevati 15. break
16. else
17. an <-timestamp arrivo del messaggio n-esimo 18. Tn <- an - an-1 ? intervallo timestamp 19. n <- n+1
20. end if
21. end while
22. ? intervallo timestamp medio
23.
24. ? offset accumulato
25. ? errore di identificazione
26. S[k] <- SKEWUPDATE(t,e) ? clock skew
27. end for
Quello che si ottiene, in termini di Clock Offset accumulato ? riportato in Figura 6 dove ? schematizzato che per ogni ECU h, j, l ci sono tante rette quanti sono i messaggi periodici, cio? identificativi ID, che ? previsto che la rispettiva ECU invii sul bus di comunicazione. Dato che ogni periodicit? viene analizzata in modo separato dalle altre (nel senso che i messaggi a 10ms di periodo T sono analizzati separatamente da quelli con 20ms o altra periodicit?), dall?analisi del Clock Offset si ottiene il risultato schematizzato sotto. In Figura 6, con la notazione
si intende la retta costruita come descritto in
precedenza via RLS, relativamente all? identificativo ID
esimo inviata dalla ECU ?-esima con periodicit? cio? assegnato dal clustering 200 al gruppo con periodicit? . Per evitare qualsiasi classificazione errata nel caso in cui i fasci di rette siano troppo ravvicinati e quindi potrebbe esserci una qualche ambiguit? nella decisione del gruppo di appartenenza, si utilizza una analisi di correlazione (tramite coefficiente di Pearson), in quanto esiste l?evidenza tecnica che nonostante il Clock Offset accumulato possa essere molto vicino, la variabilit? con cui il drift temporale persiste rimane unica di quella specifica ECU.
La procedura 310 comprende inoltre, come mostrato in figura 4, di calcolare in un passo 318 un indice di correlazione ? del ritardo medio Oavg dei messaggi. A questo riguardo, in Figura 6A ? rappresentato un diagramma che in ascissa riporta il ritardo medio Oavg di messaggi con identificativo IDj inviati da una ECU h, e in ordinata l?offset medio Oavg di messaggi con diverso identificativo IDi, ma con una stessa periodicit?, inviati da una diversa ECU k. Nel caso in cui due messaggi abbiano stessa periodicit?, ma con provenienza differente, nonostante di fatto abbiano associato un Clock Offset simile, sono comunque distinguibili calcolandone l?indice di correlazione ? dell?offset medio Oavg in quanto la correlazione ? bassa in valore assoluto. Al contrario i messaggi provenienti dallo stesso dispositivo/nodo/ECU, come mostrato in figura 6B, dove l?identificativo ? diverso, IDi, IDj, la periodicit? uguale e la ECU la medesima, la ECU h, essi hanno un Clock Offset accumulato molto simile tra loro, presentano un indice di correlazione ? molto elevato (l?evidenza sperimentale indica un valore > 0.8).
Pertanto, al passo 318 vengono calcolati indici di correlazione ? di coppie di messaggi con simile periodo, che quindi appartengono a uno stesso gruppo ricavato dal clustering 200, con identificativi diversi IDi, IDj, che in ricezione risultano provenire da una stessa ECU o nodo 11 (ad esempio ECU h come in figura 6B), prelevandone i corrispondenti valori di offset medio Oavg calcolati al passo 312.
La successiva procedura di rilevamento anomalie 320 si basa sull?analisi del cambio di pendenza, cio? S[k] ed intercetta, cio? e[k], delle rette fornite al passo 316, a cui di fatto corrispondono le anomalie/attacchi descritti in precedenza. In particolare, un cambio di pendenza S[k] corrisponde ad una variazione della periodicit? del messaggio con quello specifico identificativo ID, cio? per la retta il messaggio Mr del gruppo con periodo Ti dal nodo o ECU h. Se il periodo aumenta (diminuisce la frequenza con cui viene inviato) allora la pendenza S[k] diminuisce (la retta ? meno ?inclinata?), viceversa se il periodo diminuisce (e la frequenza aumenta), la retta ha una pendenza S[k] maggiore.
L?analisi congiunta dell?accumulo di Clock Offset e quindi di pendenza S[k] e di intercetta e[k] della retta (fornito dal passo 316), e dell?indice di correlazione ? tra messaggi che apparentemente hanno la stessa provenienza, permette sia di capire se la rete di comunicazione ? sotto attacco, consistentemente con le definizioni precedenti di anomalia, sia da quale ECU (nodo 11) proviene un certo messaggio con uno specifico identificativo IDr, dove r ? l?indice degli identificativi di messaggio, a ogni valore di r corrisponde un identificativo diverso, in particolare nella lista degli identificativi ammessi accessibile al dispositivo 20.
In figura 7 ? mostrato dunque uno schema di una forma realizzativa del procedimento finora descritto.
Con il blocco 100 ? indicato un passo di white-listing, ossia di applicazione di un White List Filter, ossia un filtro che fa passare solo gli elementi indicati in una lista, la White List, come passo preliminare ai passi 200 e 300. Tale filtro consente di accettare solo gli identificativi ID di messaggio effettivamente presenti nella whitelist associata al nodo di controllo. Tipologie di ID estranei alla lista possono essere scartati, registrati in apposite strutture dati, ed eventualmente segnalati all?utente mediante segnali specifici.
Con 200 ? indicato quindi il passo di clustering che sui messaggi esegue la divisione per periodo, ottenendo i gruppi di messaggi IDr,h[T1)?IDr,h[Tn).
Tali gruppi di messaggi sono forniti alla procedura 300 di analisi messaggi che comprende la procedura di fingerprinting 310 e il rilevamento di anomalia 320.
Nella figura successiva ? mostrata pi? in dettaglio tale procedura 300 di analisi messaggi.
Come detto la procedura 310 ottiene dai tempi di arrivo ai dei gruppi di messaggi IDr,h[T1)?IDr,h[Tn) le rispettive pendenze e intercette, S[k], e[k] tramite le equazioni (1)-(2) (o alternativamente (3) e (4)) e il calcolo di una regressione (equazione (5)).
Nella procedura 320 di rilevamento anomalia successivamente ? previsto di operare, in base ai valori di pendenza S[k] e intercetta e[k], nonch? valori di correlazione ?, calcolati sui messaggi ricevuti, a valle del clustering 200 e del whitelisting 100, una classificazione, ad esempio attraverso un classificatore logico decisionale a tre livelli.
Dunque la procedura 320 comprende un passo di analisi di correlazione 350 su messaggi appartenenti a un medesimo gruppo di messaggi IDr,h[Ti). Come descritto in figura 11 in tale analisi di correlazione si calcola un indice di correlazione ? fra l?offset medio Oavg di coppie di messaggi provenienti da una medesima centralina h nel gruppo di messaggi con stesso periodo Ti.
Ottenuti i valori di correlazione ? al passo 350, quindi in un passo di test 355 si provvede a verificare se il valore di indice di correlazione ? ? maggiore di un valore, preferibilmente impostabile, ad esempio 0,8. Al classificatore 360 ? fornita l?informazione se il passo di test 355 ha esito positivo o negativo (es. s?/no, o pass/fail).
La procedura 320 comprende inoltre un passo 330 di paragone di pendenze S[k] associate a messaggi consecutivi appartenenti a un medesimo gruppo di messaggi IDr,h[Ti). In particolare, nel passo 330 vengono selezionati i valori di pendenza di due messaggi consecutivi. Quindi, nel passo 335 si verifica se la loro differenza ? maggiore di una soglia di pendenza STH impostata.
Al classificatore 360 ? fornita l?informazione se il passo di test 335 ha esito positivo o negativo (es. s?/no, o pass/fail).
La procedura 320 comprende inoltre un passo 340 di paragone di valori di intercetta e[k] associati a messaggi consecutivi appartenenti a un medesimo gruppo di messaggi IDr,h[Ti).
In particolare nel passo 340 vengono selezionati i valori di errore o intercetta e[k] di due messaggi consecutivi ricevuti, quindi nel passo di test 345 si verifica se la loro differenza ? maggiore di una soglia di pendenza ETH impostata.
Al classificatore 360 ? fornita l?informazione se il passo di test 345 ha esito positivo o negativo (es. s?/no, o pass/fail).
Il classificatore 360 ? di tipo euristico ed ? configurato ad tramite esempio regole di tipo logico di tipo IF?THEN. Altre forme alternative di classificatore per Pattern Recognition sono possibili, incluse reti neurali. In forme alternative, il classificatore 360 pu? comprendere una o pi? ulteriori grandezze o informazioni d?ingresso.
In una forma di realizzazione preferita, viene fornito al classificatore 360 per primo il risultato del test 355 sull?indice di correlazione, successivamente il risultato degli altri due test 335 e 345, preferibilmente prima il test 335 e 345. Si ? trovato che tale ordine dei test presenta vantaggi in termini di accuratezza di classificazione, ma ? chiaro che in forme varianti ? possibile ordinare i test diversamente.
Dunque, ad esempio il classificatore 360 se l?analisi di correlazione 350-355 d? risultato negativo, o se le pendenze di due rette nominalmente appartenenti alla stessa ECU sono molto diverse (passi 330-335), registra un errore di classificazione. Tale errore di classificazione pu? essere segnalato all?utente tramite uno specifico segnale, o registrata in strutture dati per generare altre tipologie di eventi.
Dunque, ? previsto di fornire i risultati di detta prima ,350, seconda, 330, e terza , 340, verifica a un?operazione di classificazione, eseguita dal classificatore 360, dei messaggi, configurata per fornire un risultato RC comprendente una conferma di classificazione dei messaggi secondo nodo trasmittente 11, ad esempio ECU h, e identificativo di messaggio, ID, o un?indicazione di errore di classificazione in funzione di detti risultati.
Se il coefficiente di correlazione ? nella verifica 350 risulta maggiore di una prima soglia determinata l?operazione di classificazione indica il nodo trasmittente i messaggi come corrispondente al nodo nominale, se ? minore indica errore di classificazione e il nodo trasmittente come differente dal nodo nominale.
Se la seconda verifica 330 ? negativa, cio? c?? un cambio di pendenza, l?operazione di classificazione 360 indica come risultato RC un attacco mascherato.
Se la terza verifica 340 ? negativa l?operazione di classificazione 360 indica come risultato RC un attacco di fabbricazione.
Come detto, preferibilmente tale operazione di classificazione 360 ? un?operazione di discriminazione logico decisionale in cui viene valutato per primo il risultato della prima verifica 350, ossia se il coefficiente di correlazione (?) sia maggiore di una prima soglia determinata, e i risultati della seconda e/o terza verifica vengono valutati se il risultato della prima verifica ? affermativo.
Il procedimento descritto quindi, sfrutta le informazioni note a priori, per verificare la correlazione fra identificativi ID appartenenti alla stessa ECU, o nodo 11. Per informazioni note a priori, in quanto immagazzinate nel dispositivo 20 o comunque ad esso accessibili, si intendono le informazioni riguardanti la topologia della rete, il numero di ECU, o pi? in generale nodi 11 trasmettenti, il numero e il tipo di identificativo ID trasmesso da ciascuna di queste ECU-Dunque, da quanto descritto sopra, sono chiari i vantaggi della soluzione proposta.
La soluzione descritta vantaggiosamente permette di operare come un MAC virtuale, riconoscendo il comportamento del dispositivo specifico a partire dal drift temporale dei messaggi periodici che esso stesso invia sul bus di rete.

Claims (9)

RIVENDICAZIONI
1. Procedimento di protezione da attacchi informatici in una rete di comunicazione, in particolare CAN (Controller Area Network), di un veicolo comprendente
un bus di comunicazione (10), in particolare un bus CAN,
una pluralit? di nodi (11) associati a detto bus di comunicazione (10) in rapporto di scambio di segnale e associati almeno in parte a unit? di controllo di funzioni del veicolo,
detti nodi (11) scambiando messaggi (M) in transito fra nodi di detta pluralit? di nodi (11),
detti messaggi (M) essendo contraddistinti da rispettivi identificativi di messaggio (ID),
detto procedimento comprendendo, a un nodo di controllo (20) associato a detto bus di comunicazione (10), selezionare fra i messaggi (M) scambiati fra i nodi messaggi periodici aventi una periodicit? di trasmissione, raggruppare (200) detti messaggi periodici in gruppi rispettivi secondo il rispettivo periodo (Ti),
eseguire una procedura (300) di analisi messaggi dei nodi (11) che scambiano detti messaggi periodici ricevuti comprendente, per ciascun gruppo di periodicit? di trasmissione,
ottenere tempi di arrivo (ai) ai rispettivi nodi (11) di un insieme di messaggi periodici aventi medesimo identificativo di messaggio (ID),
calcolare (312) in funzione di detti tempi di arrivo (ai) valori di offset medio (Oavg) su sottoinsiemi successivi, di un determinato numero (N) di messaggi, di detto insieme di messaggi ricevuti,
accumulare (314) detti valori di offset medio (Oavg) per ogni identificativo (ID) rispetto a ciascun sottoinsieme successivo ottenendo valori di offset accumulato (Oacc[k]) per ogni sottoinsieme successivo e un rispettivo identificativo (ID),
identificare (316) parametri lineari (e[k], S[k]) tramite calcolo di una regressione su detti valori di offset accumulato (Oacc[k]) per ogni sottoinsieme successivo e rispettivo identificativo (ID) detto calcolo comprendendo calcolare un coefficiente angolare, o pendenza, della regressione, e un?intercetta, o errore di identificazione, calcolare (318), in base a valori di offset medio (Oavg) ottenuti al passo di calcolare (312) in funzione di detti tempi di arrivo (ai) valori di offset medio (Oavg) su sottoinsiemi successivi, un coefficiente di correlazione (?) dell?offset medio (Oavg) di coppie di messaggi identificati come provenienti da uno stesso nodo,
operare una prima verifica (350) se il coefficiente di correlazione (?) sia maggiore di una prima soglia determinata,
operare una seconda verifica (330) se il coefficiente angolare (S[k]) fra due messaggi consecutivi con stesso identificativo sia maggiore di una seconda soglia determinata,
operare una terza verifica (340) se l?intercetta (e[k]) fra due messaggi consecutivi sia maggiore di una terza soglia determinata,
fornire i risultati di detta prima (350), seconda (330) e terza (340) verifica a un?operazione di classificazione (360) dei messaggi, configurata per fornire (RC) una conferma di classificazione dei messaggi secondo nodo trasmittente (11) e identificativo di messaggio (ID) o un?indicazione di errore di classificazione in funzione di detti risultati.
2. Procedimento secondo la rivendicazione 1, in cui se il coefficiente di correlazione (?) ? maggiore di una prima soglia determinata l?operazione di classificazione indica il nodo trasmittente i messaggi come corrispondente al nodo nominale, se ? minore indica errore di classificazione e il nodo trasmittente come differente dal nodo nominale.
3. Procedimento secondo una delle rivendicazioni precedenti, in cui se la seconda verifica (330) ? negativa l?operazione di classificazione (360) indica un attacco mascherato.
4. Procedimento secondo una delle rivendicazioni precedenti, in cui se la terza verifica (340) ? negativa l?operazione di classificazione (360) indica un attacco di fabbricazione.
5. Procedimento secondo una delle rivendicazioni precedenti, in cui detta operazione di classificazione (360) ? un?operazione di discriminazione logico decisionale in cui viene valutato per primo il risultato della prima verifica (350) se il coefficiente di correlazione (?) sia maggiore di una prima soglia determinata, e i risultati della seconda e/o terza verifica vengono valutati se il risultato della prima verifica ? affermativo.
6. Procedimento secondo una delle rivendicazioni precedenti, in cui informazioni note a priori, riguardanti la topologia della rete e/o i nodi (11) trasmittenti e/o il numero e il tipo di identificativo (ID) dei messaggi trasmessi da ciascuno di tali nodi sono accessibili per eseguire le operazioni del procedimento.
7. Procedimento secondo una delle rivendicazioni precedenti, che comprende un?operazione di filtraggio con White List, che accetta solo gli identificativi (ID) di messaggio effettivamente presenti in detta White List associata al nodo di controllo. Tipologie di ID estranei alla lista possono essere scartati, registrati in apposite strutture dati, ed eventualmente segnalati all?utente mediante segnali specifici.
8. Procedimento secondo una delle rivendicazioni precedenti, in cui detta operazione di misurare tempi di arrivo ? eseguita acquisendo il timestamp di arrivo dei messaggi.
9. Dispositivo (20) di protezione da attacchi informatici in una rete di comunicazione, in particolare CAN (Controller Area Network), di un veicolo comprendente
un bus di comunicazione (10), in particolare un bus CAN, e
una pluralit? di nodi (11) associati a detto bus di comunicazione (10) in rapporto di scambio di segnale e associati almeno in parte a unit? di controllo di funzioni del veicolo,
detti nodi (11) scambiando messaggi (M) in transito fra nodi di detta pluralit? di nodi (11),
detti messaggi (M) essendo contraddistinti da rispettivi identificativi di messaggio (ID), caratterizzato dal fatto di essere configurato per operare secondo il procedimento secondo una o pi? delle rivendicazioni da 1 a 8.
IT102021000022919A 2021-09-06 2021-09-06 Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo IT202100022919A1 (it)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IT102021000022919A IT202100022919A1 (it) 2021-09-06 2021-09-06 Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo
EP22191648.9A EP4145765A1 (en) 2021-09-06 2022-08-23 Method for protection from cyber attacks to a vehicle based upon time analysis, and corresponding device
US17/929,370 US20230080521A1 (en) 2021-09-06 2022-09-02 Method For Protection From Cyber Attacks To A Vehicle Based Upon Time Analysis, And Corresponding Device
CN202211085952.9A CN115776383A (zh) 2021-09-06 2022-09-06 基于时间分析的车辆网络攻击防护方法及相应装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102021000022919A IT202100022919A1 (it) 2021-09-06 2021-09-06 Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo

Publications (1)

Publication Number Publication Date
IT202100022919A1 true IT202100022919A1 (it) 2023-03-06

Family

ID=79019215

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102021000022919A IT202100022919A1 (it) 2021-09-06 2021-09-06 Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo

Country Status (4)

Country Link
US (1) US20230080521A1 (it)
EP (1) EP4145765A1 (it)
CN (1) CN115776383A (it)
IT (1) IT202100022919A1 (it)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116700110B (zh) * 2023-06-30 2024-03-26 中汽院新能源科技有限公司 基于多模块划分的分布式驱动新能源汽车控制方法
CN117240602B (zh) * 2023-11-09 2024-01-19 北京中海通科技有限公司 一种身份认证平台安全防护方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170286675A1 (en) * 2016-04-01 2017-10-05 The Regents Of The University Of Michigan Fingerprinting Electronic Control Units For Vehicle Intrusion Detection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170286675A1 (en) * 2016-04-01 2017-10-05 The Regents Of The University Of Michigan Fingerprinting Electronic Control Units For Vehicle Intrusion Detection

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DESAI DEEPAK ET AL: "Attacker Identification Using Low-Level Characteristics of Automotive ECUs", 13 October 2020 (2020-10-13), XP055912088, Retrieved from the Internet <URL:https://odr.chalmers.se/bitstream/20.500.12380/302217/1/CSE%2020-107%20Deepak%20Gunke.pdf> [retrieved on 20220412] *
HALDER SUBIR ET AL: "COIDS : A Clock Offset Based Intrusion Detection System for Controller Area Networks", PROCEEDINGS OF THE 21ST INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING AND NETWORKING, 4 January 2020 (2020-01-04), New York, NY, USA, pages 1 - 10, XP055911764, ISBN: 978-1-4503-7751-5, Retrieved from the Internet <URL:https://dl.acm.org/doi/pdf/10.1145/3369740.3369787> [retrieved on 20220412], DOI: 10.1145/3369740.3369787 *
KYONG-TAK CHO AND KANG G SHIN THE UNIVERSITY OF MICHIGAN { KTCHO ET AL: "Fingerprinting Electronic Control Units for Vehicle Intrusion Detection", 6 January 2017 (2017-01-06), pages 922 - 938, XP061025127, Retrieved from the Internet <URL:https://www.usenix.org/sites/default/files/sec16_full_proceedings_interior.pdf> [retrieved on 20170106] *
SAGONG SANG UK ET AL: "Cloaking the Clock: Emulating Clock Skew in Controller Area Networks", 2018 ACM/IEEE 9TH INTERNATIONAL CONFERENCE ON CYBER-PHYSICAL SYSTEMS (ICCPS), IEEE, 11 April 2018 (2018-04-11), pages 32 - 42, XP033391507, DOI: 10.1109/ICCPS.2018.00012 *

Also Published As

Publication number Publication date
EP4145765A1 (en) 2023-03-08
CN115776383A (zh) 2023-03-10
US20230080521A1 (en) 2023-03-16

Similar Documents

Publication Publication Date Title
US10986008B2 (en) Abnormality detection in an on-board network system
IT202100022919A1 (it) Procedimento di protezione da attacchi informatici a un veicolo basato su analisi temporale e corrispondente dispositivo
CN108885664A (zh) 信息处理方法、信息处理系统、以及程序
US10791129B2 (en) Unauthorized communication detection reference deciding method, unauthorized communication detection reference deciding system, and non-transitory computer-readable recording medium storing a program
US20210226872A1 (en) Abnormality detection method, abnormality detection apparatus, and abnormality detection system
CN112637137B (zh) 基于钟差动力学模型的光纤时间同步监控方法与系统
US11588827B2 (en) Attack communication detection device, attack communication detection method, and program
CN105519021B (zh) 测定通信网络中的频率偏差的位置的方法和设备
CN111357242A (zh) 异常通信探测装置、异常通信探测方法、程序
US20210105292A1 (en) Detector, detection method, and detection program
CN111311912B (zh) 车联网检测数据确定方法、装置及电子设备
CN105407496A (zh) 一种识别无线传感器网络中错误测量值的方法
CN116827641A (zh) 一种车载can总线异常流量检测溯源方法及系统
US20220394045A1 (en) Method For Protection From Cyber Attacks To A Vehicle, And Corresponding Device
CN105516164A (zh) 基于分形与自适应融合的P2P botnet检测方法
US11747790B2 (en) Method and system of providing process protocols for machine data
CN116980143A (zh) 一种车辆入侵检测方法及其车辆
WO2022049497A1 (en) Safety extension for precision time protocol (ptp)
US20230244785A1 (en) Method for protection from cyber attacks to a vehicle based upon time analysis, and corresponding device
CN113282520A (zh) Epa系统测试方法、epa系统测试设备和介质
Lei et al. DeviceNet reliability assessment using physical and data link layer parameters
Zhang et al. Data driven CAN node reliability assessment for manufacturing system
US20210064969A1 (en) Method for detecting a deterioration in a network
CN117527546B (zh) 一种车载can网络故障监测方法及系统
JP7182470B2 (ja) メッセージ処理装置およびメッセージ処理方法