È ufficiale: le auto connesse sono già qui e intendono rimanere anche per il futuro, ma gli hacker già festeggiano

Todd Slack – Product Manager – Automotive Security Products | Microchip Technology

Circa il 50% di tutti i nuovi veicoli venduti quest’anno saranno veicoli connessi, e molti tra gli osservatori di questo mercato hanno stimato che la cifra salirà a circa il 95% entro il 2030.
Tali connessioni via Bluetooth®, USB, LTE, 5G, Wi-Fi® e altr
o portano ai consumatori molta comodità. Tuttavia, gli hacker sono molto entusiasti delle possibili superfici di attacco, in drammatico aumento, che questa comodità aggiuntiva porta. Tutti i software possono essere soggetti a bug e i bug sono sfruttabili dagli hacker.

Un obiettivo comune per gli hacker è quello di ottenere accesso alla Controller Area Network (CAN) del veicolo. È stato dimostrato che gli hacker possono sfruttare un bug nella connessione Bluetooth, che consente loro di sfruttare un bug nel sistema operativo del veicolo, che a sua volta dà accesso remoto per manipolare i messaggi sul bus CAN. I moderni veicoli possono avere fino a 100 Electronic Control Unit (ECU), con molte di quelle ECU critiche per la sicurezza e che comunicano attraverso il bus.

Il bus CAN ha diversi vantaggi. Per esempio utilizza un protocollo semplice che è anche economico, estremamente robusto e relativamente immune ai disturbi elettrici, rendendolo affidabile per la comunicazione tra nodi critici per la sicurezza. Lo svantaggio però è che, per decenni, il protocollo non ha offerto alcuna sicurezza, il che significa che una volta che un hacker ottiene l’accesso, può liberamente inviare messaggi contraffatti che possono creare scompiglio nelle comunicazioni del veicolo. La buona notizia è che, con l’avvento di CAN FD, ci sono byte aggiuntivi disponibili nel payload del messaggio per aggiungere sicurezza. Ciò viene ottenuto includendo un codice MAC (Message Authentication Code) per verificare crittograficamente l’autenticità del messaggio e quindi filtrare eventuali messaggi falsificati.

Gli OEM sono stati impegnati nell’aggiornare le loro specifiche di sicurezza informatica in risposta al crescente numero di hackerazioni. Quasi tutti gli OEM richiedono l’aggiornamento delle ECU critiche per la sicurezza per implementare i loro nuovi requisiti di sicurezza informatica, con alcuni OEM che richiedono aggiornamenti per il 100% delle ECU connesse.

Questa necessaria base di sicurezza richiede ai progettisti l’implementazione di una funzione di secure boot, che comporta la verifica crittografica del fatto che sia il codice di avvio che l’applicazione in esecuzione su un controller host siano rimasti invariati, e che siano in uno stato sicuro al momento dell’accensione. Questa verifica viene spesso reimpostata e ripetuta a intervalli regolari una volta avviata.

Al secondo posto nell’elenco delle principali misure di sicurezza c’è il requisito di supportare aggiornamenti sicuri del firmware. Come sappiamo, tutti i software possono essere soggetti a bug, rendendo necessario creare patch per i bug del firmware che possono essere applicate sul campo. Questi aggiornamenti del firmware richiedono anche implementazioni di sicurezza crittografica, in genere richiedono che i payload del firmware in arrivo siano crittografati con una chiave simmetrica (AES) e firmati con una chiave privata asimmetrica, il più delle volte Elliptic Curve Cryptography (ECC).



 

In questo modo, quando un’immagine di aggiornamento viene presentata al controller host, non viene intrapresa alcuna azione fino a quando la firma del payload non sia stata verificata dalla chiave ECC pubblica incorporata nel controller. Una volta verificata la firma, l’immagine può essere decrittografata e il firmware del controller aggiornato con la patch del bug o per il miglioramento delle funzionalità. La terza aggiunta al miglioramento della sicurezza è l’autenticazione dei messaggi, come descritto sopra.

On die oppure off die, questo è il dilemma. Le soluzioni on-die come un MCU dual-core a 32 bit possono rivelarsi un costoso aggiornamento per una ECU di generazione precedente che potrebbe essere stata perfettamente servita in questo da una MCU standard prima che la vera sicurezza fosse richiesta da un OEM. Inoltre possono anche introdurre ritardi significativi nel time to market, a causa della necessità di riprogettare completamente il codice applicativo.

Può essere estremamente rischioso effettuare in-house lo sviluppo del codice di sicurezza ma molto costoso pagare una terza parte per fare il lavoro. È anche difficile per un fornitore Tier 1 condividere la soluzione su più tipi di ECU, date le diverse prestazioni e i diversi requisiti di periferiche per ciascun tipo.

È qui che gli Hardware Security Module (HSM) esterni o i sottosistemi sicuri possono ridurre significativamente il carico degli aggiornamenti di sicurezza per i fornitori Tier 1 . Possono essere aggiunti accanto a una MCU standard in un progetto esistente o inseriti in tutti i nuovi progetti con diversi requisiti di MCU host. HSM esterni come il TrustAnchor100 (TA100) di Microchip sono forniti con provisioning già effettuato, compresi tutti i codici di sicurezza, chiavi e certificati, il che riduce drasticamente il time-to-market. TA100 è facilmente portabile su qualsiasi MCU, dato che la libreria crittografica associata è MCU agnostica. Il rischio, il time to market e il costo complessivo sono ridotti, consentendo ai fornitori Tier 1 di battere nel business la concorrenza, che invece è costretta ad un percorso completamente ridisegnato.

Con la quantità attuale di auto connesse e l’intenso traffico di comunicazioni sulle reti a bordo veicoli, la necessità di sicurezza automobilistica è un fatto reale ed impellente. La sicurezza, ma anche la reputazione del marchio, sono in gioco rendendo più importante che mai il selezionare dispositivi veramente sicuri che siano stati controllati da terze parti durante l’aggiornamento delle ECU per soddisfare la pletora di nuove specifiche di sicurezza informatica OEM, SAE, standard ISO e normative di sicurezza di enti e governi locali.

www.microchip.com

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Main Menu