fbpx

software del veicolo

I sistemi di aggiornamento software, in particolare per i veicoli, possono fornire migliorie considerevoli, ma, se non implementati con cautela, potrebbero potenzialmente esporvi a gravi vulnerabilità di sicurezza. Le soluzioni precedenti adottate per la protezione degli aggiornamenti software si basano su attacchi semplici e gestiscono meccanismi di sicurezza ormai ampiamente conosciuti, come le firme digitali e i moduli di sicurezza hardware (HSM) per firmare gli aggiornamenti. Tuttavia, nessuna soluzione presentata considera obiettivi di sicurezza più avanzati, come la resilienza ad una compromissione delle repository, o freeze attacks al meccanismo di aggiornamento del veicolo o una compromissione al sito di un fornitore. Le soluzioni sviluppate per il mondo dei PC non si generalizzano a quello delle automobili per due motivi: in primo luogo, non risolvono problemi che sono unici per l’industria automobilistica, ad es. che ci sono vari tipi distinti di computer da aggiornare su un veicolo e, inoltre, non affrontano attacchi alla sicurezza che possono causare il guasto di un veicolo o che possono rendere precario un veicolo. In questo articolo, discuteremo ulteriormente del framework di aggiornamento software per automobili utilizzato per contrastare una vasta gamma di attacchi alla sicurezza e la sua parziale resistenza ad altri tipi di attacchi.L’esecuzione di valutazioni del rischio a livello di componente software dell’automobile è molto complessa per numerose ragioni. La quantità di code covers è sbalorditiva, l’autorizzazione all’accesso al codice può essere limitata e il processo complessivo di valutazione del rischio dipende da tutti gli attori della complessa supply chain dell’OEM automobilistico.

Considerazioni tecniche – In genere, le ECU critiche per la sicurezza possono essere basate su Classic AutoSAR, che comunica utilizzando il bus CAN, FlexRay o la maggior parte dei protocolli che sono ottimizzati per il settore automobilistico (ad eccezione delle connected ECU che in genere funzionano su Linux, sistemi Android. Classic AUTOSAR è di solito limitato in termini di funzionalità rispetto a Linux e altri sistemi operativi open source. Diverse vulnerabilità in Classic AutoSAR devono ancora essere scoperte e gli hacker potrebbero ottenerle relativamente facilmente. Lo sviluppo di protocolli a livello di rete orientati alle automobili comporta diversi problemi di sicurezza; l’utilizzo del bus CAN, ad esempio consente a qualsiasi ECU di inviare comandi ad un’altra ECU senza esserne autorizzata, consentendo agli hacker di controllare una ECU come se fossero una controparte autorizzata.

Considerazioni commerciali: gli OEM mirano principalmente ad integrare il maggior numero possibile di piattaforme di connettività al veicolo, tramite Bluetooth o Wi-Fi ai nostri smartphone e tramite committed protocols ad altre auto di una flotta e dintorni. I sistemi abilitati wireless lasciano l’auto e i suoi passeggeri esposti a un nuovo mondo di minacce e più il veicolo è connesso, maggiori sono i rischi.

Connettività ai più importanti standard wireless come Wi-Fi e Bluetooth che possono essere penetrati tramite smartphone. In altre parole, ogni nuovo know-how ha bisogno di tutta una nuova serie di considerazioni per fermare lo sfruttamento di vulnerabilità da parte degli hackers.

Impatto e complessità: ci sono implicazioni di vasta portata e pericolose per la vita che possono essere causate da una vulnerabilità invisibile nel processo di sviluppo del software. A differenza di vari altri settori, i rischi connessi richiedono che gli sviluppatori non commettano errori. Inoltre, non è ancora semplice aggiornare facilmente il veicolo nelle auto collegate, e quindi ogni sviluppo deve soddisfare standard di sicurezza pianificati con alcuni anni di anticipo.

Lascia un commento

Your email address will not be published. Required fields are marked *