Fino ad una ventina di anni fa, la sicurezza nelle auto si limitava principalmente a soluzioni di carattere prevalentemente meccanico finalizzate ad impedirne il furto o, più raramente, la manipolazione dei tachigrafi o dei contachilometri. Tuttavia, a partire dagli anni ’90, con l’introduzione delle chiavi per l’apertura remota, dei connettori per la diagnostica di bordo (ad esempio il connettore standard OBD-II) e dei primi computer di bordo la situazione è cambiata radicalmente.
Da allora, l’auto, da sistema meccanico pressoché isolato qual era, si è trasformata in un sistema cyber-fisico costituito da una complessa rete di elaboratori interconnessi tra di loro e con il mondo esterno. Attualmente si stima che un’auto di fascia economica contenga più di 25 centraline elettroniche, dette electronic control unit (ECU) interconnessi da uno o più bus di comunicazione. Un’auto di lusso invece ne contiene da 50 a 70 per un totale di circa dieci milioni di linee di codice. Allo stesso tempo, la sopraggiunta disponibilità di interfacce di rete wireless come, ad esempio il bluetooth o telefonia cellulare, permette ad un’auto di connettersi con l’ambiente circostante trasformando così il veicolo in un nodo Internet praticamente sempre connesso.
Gli attacchi cyber alle auto
Sebbene l’informatizzazione delle auto abbia portato molti benefici, la ricerca, ma ormai anche la cronaca, ha mostrato che le auto moderne possono essere soggette ad una pluralità di attacchi informatici (attacchi cyber) dovuti, principalmente, alle vulnerabilità presenti nel software che hanno a bordo (vedi sicurezza auto connesse, la sfida delle regole). Un hacker che riesce ad “entrare” all’interno di una centralina sfruttando le vulnerabilità del software in esecuzione su di essa, da quel momento, può interferire con le altre centraline sfruttando l’elevata interconnessione sia a livello di rete sia a livello funzionale che esiste tra queste. Per esempio, la centralina che controlla il sistema di apertura delle portiere interagisce con quella che controlla gli airbag in modo da sbloccare le portiere in caso di incidente e quindi facilitare la fuga in caso di incidente. Oppure la centralina che controlla il freno di stazionamento elettrico interagisce con quella che controlla l’acceleratore per sbloccare il freno quando il veicolo riparte a seguito di una accelerata. La sempre più elevata connettività dell’auto con l’ambiente circostante non fa che aggravare questa situazione perché fa sì che questi attacchi possano essere lanciati anche dal remoto. Ne segue quindi che un’auto oggigiorno deve difendersi da attacchi di hacker piuttosto che dai tradizionali ladri o da meccanici infedeli che illegalmente cercano di alternarne le funzionalità.
Le organizzazioni hanno reagito a questa nuova situazione. Per esempio, dal 2008 al 2011, l’Unione Europea ha co-finanziato il progetto EVITA che aveva come obiettivo il progetto, la verifica e la prototipazione di un’architettura per la rete informatica di bordo che garantisse l’integrità delle componenti e delle comunicazioni intra-veicolo. Più recentemente invece, sono state rilasciate delle raccomandazioni, per lo più a livello di processo, per incrementare la cybersecurity nel settore automobilistico. Per esempio nel 2016 è stata rilasciata la guida J3061: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. Nello stesso anno, l’amministrazione statunitense ha rilasciato Cybersecurity Best Practices for Modern Vehicles.
Sicurezza delle auto connesse: le sfide delle regole in Italia
Sviluppo di software sicuro per le auto
In questo articolo richiameremo alcune raccomandazioni minime per sviluppo di software sicuro per il settore automobilistico dal momento che, come abbiamo appeno detto, le vulnerabilità presenti nel software sono le principali cause degli attacchi cyber alle auto. Si noti che già il SAE 30161 contiene raccomandazioni sullo sviluppo sicuro di software, tra cui l’utilizzo di strumenti per analisi statica del codice, l’impiego del fuzz testing per rilevare input non conformi alla specifica che possono causare bug nonché l’impiego di tecniche di partizionamento ed isolamento del software. Tutte queste raccomandazioni sono valide anche per altri settori e non solo per quello automobilistico.
La prima raccomandazione è quella di utilizzare una metodologia di programmazione memory-safe, cioè una metodologia che permetta di proteggersi da situazioni di errore nell’accesso alla memoria che possono trasformarsi in vulnerabilità di sicurezza. Il buffer overflow è forse la vulnerabilità più nota, scoperta nel 1972, si rivela ancora particolarmente efficace. Per esempio, degli attacchi scoperti da Checkoway et al.,[1] praticamente tutti si basano sul buffer overflow. Una metodologia di programmazione memory-safe può basarsi su una serie di linee guida e standard per rendere memory-safe linguaggi di programmazione standard come C e C++ che intrinsecamente non lo sono (ad esempio SEI CERT Coding Standards) oppure utilizzare direttamente linguaggi di programmazione “memory-safe” come ad esempio il Safe-C.
La seconda raccomandazione è quella di riconsiderare accuratamente il modello di sviluppo delle componenti software. L’industria automobilistica ha adottato un approccio di outsourcing dello sviluppo delle componenti software analogo a quello utilizzato per le componenti meccaniche: il costruttore fornisce la specifica della componente e poi la acquista già sviluppata da un qualche fornitore. Ne segue che il costruttore non sviluppa il codice sorgente delle componenti, che sono invece sviluppate da diversi fornitori, ma è solo responsabile della loro integrazione. Questo modello che è adeguato per le componenti meccaniche si rivela invece problematico per quelle software. Checkoway et al. hanno mostrato che questo approccio può creare due tipi di problemi. Il primo problema è che siccome dal fornitore di una componente riceve solo l’eseguibile, un costruttore non sa esattamente che cosa contiene quella componente e quindi qual è l’effettiva funzionalità di tale componente. Checkoway et al. hanno rilevato che certe componenti contenevano sistemi operativi completi, corredati di servizi come telnetd o ftp, inseriti durante lo sviluppo per semplificare il debugging ad esempio, ma che non avrebbero dovuto essere presenti nella versione finale rilasciata al cliente perché la loro presenza rendeva più facile il lavoro di un hacker (per esempio permettevano un attacco shell injection). Questi servizi dovrebbero essere rimossi prima che la componente venga rilasciata al cliente.
Il secondo problema nasce dal fatto che la maggior parte delle vulnerabilità nasce all’interfaccia tra componenti software scritte da organizzazioni. In altre parole spesso la vulnerabilità non sta in una componente ma nel modo con cui questa viene utilizzata dal software di altri fornitori. Il fornitore della componente può svolgere un adeguato test di unità ma solo il costruttore che assembla le componenti può svolgere un test di integrazione. Tuttavia questo test di integrazione risulta complicato dal fatto che il costruttore non dispone del codice sorgente delle componenti né conosce le esatte ipotesi sotto le quali queste componenti sono state sviluppate.
La terza ed ultima raccomandazione sta nel fornire al programmatore adeguati strumenti di supporto alla modellazione ed alla sintesi del codice che ne semplifichino il compito e quindi ne riducano la probabilità di errore. Per esempio, nell’ambito del progetto H2020 SAFURE, con riferimento allo standard AUTOSAR, abbiamo definito delle annotazioni di sicurezza che in fase di modellazione del software permettono di specificare sia il livello di trust di ciascuna componente sia il livello di sicurezza, in termini di confidenzialità ed integrità, delle connessioni tra le componenti stesse. Successivamente, a partire da queste annotazioni è possibile sintetizzare automaticamente il codice per la comunicazione sicura tra componenti allocate su centraline diverse utilizzando i “crypto services” offerti AUTOSAR. Inoltre, attraverso l’analisi statica del codice delle componenti è possibile determinare le relazioni ingresso-uscita di ciascuna componente e quindi determinare la consistenza di un determinato insieme di annotazioni.
Queste ed altre tecniche e raccomandazioni dovrebbero essere realizzate al fine di ottenere del software più sicuro. Tuttavia il processo di adozione potrebbe non essere breve a causa dei forti vincoli presenti nel settore automobilistico, inclusa l’elevata sensibilità ai costi, l’esigenza di mantenersi compatibili con soluzioni standard e legacy, i limiti di memoria presenti soprattutto in centraline scarse di risorse, ed i requisiti real-time che devono essere soddisfatti per garantire i requisiti di safety.
Checkoway, Stephen, et al. “Comprehensive Experimental Analyses of Automotive Attack Surfaces.” USENIX Security Symposium. 2011. ↑
