41
SAFETY E SECURITY SU RETI CAN E SU RETI HIGH SPEED PER IL MONDO MOBILE Luca Dariz Istituto per le Macchine Agricole e Movimento Terra IMAMOTER-CNR
SAFETY E SECURITY SU RETI CAN E SU RETI HIGH SPEED PER IL MONDO
MOBILE
Luca Dariz
Istituto per le Macchine Agricole e Movimento Terra
IMAMOTER-CNR
SAFETY
2
“Functional Safety is freedom from unacceptable risk of physical injury or of
damage to the health of people, either directly or indirectly (through damage to
property or to the environment)”
• Quali caratteristiche deve avere un canale di comunicazione per essere safe?
• Come si collocano i più comuni protocolli di comunicazione rispetto alla safety?
• Come si possono migliorare?
SAFETY
3
Canale di comunicazione safe
4
Quali caratteristiche sono necessarie perché una comunicazione sia
sicura (safe)?
Probabilità di errore sufficientemente bassa
In caso di errore singolo di trasmissione posso comunque ritrasmettere il
messaggio, in generale non ho mai una perdita della comunicazione ma
eventualmente una degradazione
Devo avere un’elevata diagnosticabilità del canale di comunicazione
In altre parole, devo poter rilevare gli errori di comunicazione, in modo da
poter reagire e portare il sistema in uno stato sicuro
Probabilità residua di errore
La probabilità residua di errore è la probabilità di NON rilevare la presenza
di un errore, quando invece questo sia effettivamente presente.
È indipendente dalla capacità di correggere un errore
Canale di comunicazione safe
5
3 sono i livelli di Safety Integrity Level (SIL) di interesse per le
applicazioni mobili safety critical, secondo quanto definito dalla norma
IEC61508, sulla base della frequenza di errore residua:
5
6
7
101
102
103
SIL
SIL
SIL
R(p) è la probabilità residua di errore per ogni messaggio
m è il numero di messaggi necessari per operare una funzione di sicurezza
v è la frequenza di trasmissione dei messaggi richiesta per ottenere il tempo di
reazione desiderato
[errori di trasmissione/ora] 100)(3600 mpR
Canale di comunicazione safe
6
Esistono altri parametri della comunicazione importanti
Maximum extension size – massimo numero di sorgenti e ricevitori dei
messaggi
Process safety time – è il periodo di tempo che intercorre tra il verificarsi di
un fault e il verificarsi di una situazione di rischio se non vengono prese
contromisure di sicurezza
Electrical reaction time – è il tempo tra il riconoscimento elettrico
dell’evento safety-related e l’inizio della reazione elettrica della strategia di
sicurezza.
Possibili errori di comunicazione
7
Perdita di un peer della comunicazione
Ripetizione di un messaggio, ad esempio perché viene inavvertitamente
inviato due volte
Perdita di singoli messaggi
Inserzione di un messaggio, ad esempio perché il ricevitore considera valido
un messaggio che non lo è
Cambio di sequenza, ovvero i dati sono ricevuti in un ordine diverso rispetto a
quello in cui sono inviati, ad esempio un cambio dell’ordine temporale di due o
piu messaggi durante la trasmissione
Possibili errori di comunicazione (2)
8
Corruzione di messaggi, ovvero uno o più bit vengono ricevuti diversamente
rispetto al messaggio originale, ad esempio dovuti ad un errore sul canale
fisico di trasmissione
Ritardo di messaggi che altrimenti sarebbero rivecuti correttamente,
rendendoli non più utili
Blocco dell’accesso alla rete (Denial of Service, DoS), ad esempio perché un
nodo malfunzionante non rispetta i protocolli/tempistiche di comunicazione,
impattando negativamente sulla possibilità di altri nodi di utilizzare la rete
Trasmissione costante di messaggi da parte di un nodo malfunzionante
(Babbling Idiot)
Interferenza tra messaggi safety-related (SR) e messaggi non-safety-related
(NSR)
Canale di comunicazione safe - CAN
9
Il CAN di per sé non è un bus di comunicazione sicuro
Non deterministico – il tempo di invio di un pacchetto dipende sia dalla priorità dello
stesso che dal carico della rete
Topologia planare (bus fisico condiviso) – non si possono fare reti a stella, per
separare il traffico devo fare reti separate e inserire un gateway
Payload ridotto (8 byte) – riduce la possibilità di aggiungere informazioni di sicurezza
Bit di ACK – non permette di sapere chi ha effettivamente ricevuto il messaggio
Come ci si protegge dagli errori di comunicazione?
Es. la norma ISO 15998 indica alcuni strumenti utili per i problemi piu
comuni
Tra
nsm
issi
on
err
or Measures per message
Ru
nn
ing n
um
ber
Tim
e st
amp
Tim
e ex
pir
atio
n
Rec
epti
on
Ack
no
wle
dg
emen
t
Iden
tifi
cati
on f
or
sen
der
an
d r
e-
ceiv
er
Dat
a in
teg
rity
assu
ran
ce
Red
und
ancy
wit
h
cro
ss c
hec
k
Dif
fere
nt
dat
a
inte
gri
ty a
ssu
ran
ce
syst
ems
of
SR
an
d
no
n-S
R
mes
sag
es
Repetition x x x
Loss x x x
Insertion x xa xb x
Incorrect
sequence
x x x
Message
falsification
x x xd
Retardation x xc
Coupling of SR
and non-SR
information
xa x x
a depends on application
b only for sender identification. Detects only insertion of an invalid source
c Required in all cases and can implemented in the sink of messages in case of a static map of messages to be received
d This measure is only comparable with a high quality data assurance mechanism if by calculation it can be proved that the residual error rate reaches the values according to in Paragraph “Data Integrity Assurance” if two messages are sent through independent networks or network addresses and hardware.
10
Come ci si protegge dagli errori di comunicazione?
11
Alcuni metodi possono essere già in parte implementati nella rete usata
Il CAN usa un CRC15 per rilevare errori di trasmissione
Inoltre si ha il bit di acknowledge
Alcuni stack protocollari (es. ISOBUS) includono ID sorgente e
destinazione nel CAN ID.
Ethernet usa un CRC32
Include ID sorgente e destinazione (MAC address)
Spesso i metodi già implementati sono troppo limitati per essere usati
L’ACK bit del CAN non mi dice chi ha ricevuto il messaggio
CRC15 o CRC32 potrebbero non essere sufficiente
Inoltre proteggono solo hop-to-hop, non end-to-end
Come ci si protegge dagli errori di comunicazione?
12
E’ necessario aggiungere un livello software per gestire la comunicazione
(Safety Layers)
NON esistenti
nello standard
CAN e neppure
nelle normali
applicazioni
Definiti nello
standard CAN
Architetture possibili (A)
13
Struttura a singolo canale trasmissivo, priva di ridondanza e con una
solo interfaccia al bus per ogni coppia di canali. i messaggi propri dei
canali 2 sono passati ai canali 1 prima di poter essere trasmessi sul bus.
Architetture possibili (B)
14
Struttura a doppio canale trasmissivo, ridondante e con due interfacce al
bus per ogni coppia di “channel”, uno per ogni canale. Tutti i safety layer
e i transmission layer sono doppi.
Architetture possibili (C)
15
Struttura a singolo canale trasmissivo, ridondante nelle interfacce al bus,
una per ogni “channel”, uno per ogni canale. Tutti i safety layer e i
transmission layer sono doppi. Ma non il transmission media.
Architetture possibili (D)
16
Struttura a singolo canale trasmissivo, non ridondante nelle interfacce al
bus, una per ogni coppia di “channel”. I safety layer sono raddoppiati ma
non i transmission layer. Ogni safety Layer ha un accesso indipendente
al canale trasmissivo.
Ridondanza
17
Oltre al canale di trasmissione, i safety e i transmission layer, posso
ridondare i messaggi trasmessi.
Così facendo diminuisco ulteriormente la probabilità residua di errore
della comunicazione
Come sono applicati questi metodi?
18
AntiSkid Bosch in applicazioni Automotive
N PTRR_MSB PTRR_LSB ~(PTRR_MSB)-N ~(PTRR_LSB)
0x14 0x01 0x2C 0xFE-0x14 0xD3
0x14 0x01 0x2C 0xEA 0xD3
Richiesta di riduzione percentuale di coppia (PTRR) dall’ASR al Controllo
Motore, messaggio inviato ogni 4 ms (Timeout implicito)
• esempio richiesta riduzione coppia del 30% e numero di messaggio 20
Rileva errori di perdita messaggi,
sequenza, inserzione, ripetizione Diversità nella codifica dei dati,
opera come un checksum
aggiuntivo
Come sono applicati questi metodi?
SAE J1939 sta introducendo meccanismi di controllo della trasmissione:
Es. Il messaggio TSC1 ora è così composto:
bit1 bit2 bit3 bit4 bit5 bit6 bit7 bit8
Byte1 Eng.Ov.Cntrl.Mode Eng.Req.Sp.Cntrl.Con Overr.C.ModePrio. EngineReqS./S.lim
Byte 2
Engine Requested Speed/Speed Limit (0,125 rpm/bit) (2 byte) Byte3
Byte 4 Engine requested Torque/Torque Limit (%) (1byte)
Byte5 TSC1 Transm. rate TSC1 Control Purpose
Byte6 Eng. Req. Torq. Fractional
Byte 7
Byte 8 Message Counter Message Checksum
Permette di gestire un
Timeout o rilevare
un ritardo Rileva errori di perdita messaggi,
sequenza, inserzione, ripetizione
Riduce ulteriormente la
probabilità di errore non rilevato,
detto anche «Safety code lenght»
19
Includendo un acknowledge esplicito dei messaggi
Permette al trasmettitore di rilevare errori del ricevitore
Rendendo indipendenti i canali di comunicazione SR da quelli non-SR
Evito Denial of Service (DoS)
Ridondando i messaggi e/o il canale di comunicazione
Consente grandi riduzioni della probabilità residua di errore
Come si possono migliorare?
20
Introducendo delle protezioni anche su altri messaggi, aumentando la
sicurezza della comunicazione
In molti messaggi standard però non c’è spazio negli 8 byte del CAN!
Per messaggi real-time dovrei aumentare il numero di byte trasmissibili
Per messaggi non real-time posso usare un protocollo di trasporto
Separando rete SR da rete NSR
Su CAN l’unica soluzione è avere due reti fisicamente separate
In generale, su CAN si devono fare interventi ad hoc sui singoli
messaggi
Non esiste un protocollo riutilizzabile cosi com’è per diversi messaggi
Per ogni messaggio si deve valutare cosa è essenziale mettere nei pochi
bit disponibili
Come si possono migliorare?
CAN bus
21
In futuro, si potrà pensare di usare uno stesso protocollo per
incapsulare diverse comunicazioni ed avere un’alta copertura
diagnostica
Maggiore overhead, ho bisogno di avere pacchetti più grandi per usarlo
efficacemente
Approccio usato in ambito industriale (openSAFETY - EPSG, Ethernet
POWERLINK Standardization Group)
Opportunità reti high speed
Più reti virtuali su un’unica rete fisica (es. VLAN), evito interferenze tra
dati safety e non safety
Posso aggiungere ulteriori protezioni con un calo di prestazioni minimo
Come si possono migliorare?
High-Speed
22
SECURITY
23
Insieme di misure attuate allo scopo di proteggere un sistema da comportamenti
o accessi non autorizzati
• Perché è necessario parlare di security nel mondo mobile?
• Quali sono gli strumenti base per poter implementare una rete sicura?
• Come si possono usare questi strumenti sulle reti attuali?
SECURITY
24
• Security
– Insieme di misure attuate allo scopo garantire l’integrità fisica e funzionale di un
sistema.
– E’ possibile un uso non autorizzato o previsto del sistema?
• Potenzialità
– C’è connettività locale (Telecomando chiavi, Bluetooth, Wifi, etc)
– C’è connettività remote (3G/4G,)
– Comunicazione diretta o indiretta con ECU sensibili (es. TECU in un trattore)
– CAN è un bus fisico, posso facilmente intercettare traffico
– Nessun supporto (ancora) per autenticazione crittografica (rete fidata)
Perché preoccuparsi di security?
C’è la potenzialità di attacco? (1)
25
• Impatto sulla safety
– Possibilità di modifiche non autorizzate (es. sblocco di funzionalità nascosta e/o non
prevista, modifica di lavorazioni in corso)
– Uso non autorizzato di funzioni critiche (es. guida remota)
– Inibizione di funzioni critiche (es. blocco del veicolo)
– Non c’è safety senza security!
Perché preoccuparsi di security?
26
Le funzioni critiche sono sempre
effettuate nel modo previsto dal
produttore?
• Rischi per il business
– Credibilità, Affidabilità e Sicurezza percepita dei prodotti
– Furto di proprietà intellettuale (algoritmi di controllo, tabelle, …)
– Furto di dati (navigazione, statistiche, task plan)
– Clonazione ECU
– Virus – Alcuni componenti sono dei veri e propri mini-pc
• E se succede qualcosa?
– Rischio di dover richiamare per aggiornamenti N*1000 macchine
– Potrebbe non essere più possibile effettuare aggiornamenti OTA (Over The Air)!
Perché preoccuparsi di security?
27
Nel mondo automotive, nel 2015..
28
Prima vulnerabilità grave pubblicata in dettaglio nel 2015
https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
I dettagli sono stati
completamente resi noti
È stato possibile controllare parti
critiche come motore e freni da
remoto
Tracciamento GPS di TUTTI i
veicoli in commercio con un
certo sistema di infotainment
Molte vulnerabilità sono state scoperte e divulgate, di severità diversa, su
veicoli di fascia e produttore diversi
…
– Ad esempio (24/02/2016) - Comunicazione non autenticata Nissan LEAF
http://www.troyhunt.com/2016/02/controlling-vehicle-features-of-nissan.html
– Il rischio è reale, anche secondo l’FBI (17/03/2016):
• FBI Internet Crime Compliant Center (IC3), Alert number I-031716, «Motor
vehicles increasingly vulnerable to Remote exploits»
http://www.ic3.gov/media/2016/160317.aspx
Nel mondo automotive, dal 2015 fino ad oggi
29
• Sniffing
• Ascolto tutti i dati che passano sul bus
• Spoofing
• Inganno altre ECU usando il Name ISOBUS di un’altra, o inviando messaggi con il
giusto CAN id.
• Replay
• Catturo dei messaggi (Sniffing) e li riproduco sulla rete (utile per reverse
engineering)
• Man in the Middle (MitM)
• Intervengo in maniera trasparente in una comunicazione, per rubare dati o alterarne
il risultato
• Denial of Service (DoS)
• Invio continuamente messaggi con ID CAN basso, al punto da impedire la
trasmissione di messaggi meno prioritari
• Message forging
• Creo dei messaggi validi pur non essendo autorizzato
Perché è possibile effettuare degli attacchi su CAN?
30
• In alcuni casi si fa affidamento sulla segretezza di un protocollo o
un’implementazione (Security through obscurity)
• Es. usare un messaggio proprietario per abilitare una funzione
– E se qualcuno lo sniffa al momento giusto?
– Soluzione vulnerabile, i metodi di reverse engineering e criptoanalisi permettono di
violare sistemi anche complessi in relativamente poco tempo
• Es. KW2000 e CCP usano il protocollo Seed & Key
– Ma non specificano che algoritmi usare!
– Esempi reali: xor, addizione, polinomio, …
• In molti casi il reverse engineering è addiritura alla portata degli hobbisti
– Seed & Key per Bosch MED9.1
http://nefariousmotorsports.com/forum/index.php?topic=4983.0
Come mi posso proteggere?
31
• Il tema della security è ben noto in ambito IT
• Quali sono gli strumenti base?
– Prevenzione
– Crittografia (Cifratura, Autenticazione, Integrità)
– Gestione delle chiavi
– Gestione autorizzazioni
– Policy adeguate (es. Least Privilege)
– Livelli multipli di protezione (sottoreti separate da gateway, separazione dei
task e dei dati, …)
• Security come requisito di progettazione
Come mi posso proteggere?
32
• Elemento base: crittografia
– Essenziale per implementare efficacemente molti (ma non tutti) livelli di
protezione
– Come si applica su CAN? E su una rete high-speed?
• Cifratura
– Nascondo i dati a chi non possiede una chiave segreta
• Autenticazione
– Mi assicuro che i dati sono generati dalla ECU corretta
• Integrità
– Mi assicuro che i dati non sono stati modificati intenzionalmente durante la
trasmissione
Come mi posso proteggere?
33
• Algoritmi di cifratura simmetrica a blocchi
Cosa posso fare su CAN? - cifratura
34
• Limite del CAN: 8 byte di payload
– In molti messaggi standard tutti già usati
– Limite sulla lunghezza chiavi -> limite sul tempo in cui posso considerare i
dati sicuri
• Limita l’efficacia della crittografia per messaggi real-time e periodici:
• L’algoritmo DES (56 bit chiave, 64 bit blocco) è stato violato in un paio
di giorni (con le dovute risorse) nel 1998, per forza bruta, oggi
probabilmente molto meno e con meno risorse (ore? minuti?)
• Come faccio a validare un messaggio dopo averlo decifrato?
– Devo poterlo distinguere da un messaggio casuale
Cosa posso fare su CAN? - cifratura
35
• Algoritmi di cifratura simmetrica di flusso
– Devo avere un’informazione tempo-variante condivisa, che manca nelle reti
attuali (es. running counter condiviso (1))
• Altrimenti uso un Transport Protocol
– Riuso algoritmi standard e validati (es. AES, Advanced Encryption Standard)
Non per dati real-time!
– Problema aperto in generale, esiste qualche soluzione sperimentale
– Rimane il problema della distribuzione delle chiavi
(1) C.-W. Lin and A. Sangiovanni-Vincentelli, “Cyber-security for the Controller Area Network (CAN)
communication protocol,” ASE International Conference on Cyber Security, pp. 344–350, 2012.
Cosa posso fare su CAN? – cifratura (2)
36
• Limite del CAN: bus condiviso e trusted
– Tutti possono comunicare con tutti
– Si assume che le ECU siano fidate (es. mi fido del NAME ISOBUS, o dell’ID
CAN)
• Richiede di aggiungere un MAC (Message Authentication Code),
Cosa posso fare su CAN? - autenticazione
37
• Su molti messaggi CAN non c’è spazio!
– Può essere difficile aggiungere un MAC per messaggi real-time
– Per messaggi non real-time, posso usare 2 pacchetti o un TP
• Un MAC presuppone in ogni caso una chiave segreta condivisa
– Problema della gestione delle chiavi
• Uno scambio di chiavi sicuro richiede l’uso di crittografia asimmetrica
– Su CAN ci può volere del tempo per completare lo scambio di chiavi
– Problema dell’end-of-line
• Sarebbe meglio precaricare delle chiavi segrete, gestione chiavi statica
• Bisogna però mantenere e proteggere un database di chiavi
Cosa posso fare su CAN? – autenticazione (2)
38
• A livello fisico il CAN ha un CRC
– Però il CRC non è un algoritmo robusto in questo senso, è pensato per
rilevare errori di trasmissione e non modifiche arbitrarie
– Un messaggio con CRC è facilmente falsificabile
Cosa posso fare su CAN? – integrità
39
• Algoritmi di hash
– Difficilmente usabile per singoli pacchetti, il CAN
limita la lunghezza dell’hash, ed è relativamente
facile trovare collisioni parziali (Paradosso del
compleanno)
• Spesso serve garantire autenticazione oltre ad
integrità
– Firme digitali (Hash + cifratura asimmetrica)
– HMAC (Hash + MAC)
• IL CAN pone vincoli sul grado di sicurezza ottenibile, limitando
l’efficacia della crittografia
– Dimensione pacchetto ridotta-> limita aggiunta di info di sicurezza
– Basso throughput -> limita l’uso di chiavi lunghe
• Una rete high-speed permette di superare questi limiti
– Vantaggi anche dal punto di vista architetturale nel caso di Ethernet
(segmentazione, VLAN)
• Il CAN potrebbe essere sufficiente nel breve periodo, o per alcuni
messaggi real-time
• Nel lungo periodo probabilmente no
– Architetture più evolute
– Security by design
– Reti ad alta velocità
Conclusioni
40
DOMANDE?
41
