Le auto connesse e l’aumento del traffico sulla rete di comunicazione a bordo dei veicoli possono essere una seria difficoltà se si intende navigare in sicurezza: a che punto siamo nell'evoluzione dei requisiti della cybersicurezza e delle soluzioni ad essi associate? Ce ne parla Todd Slack, un esperto di Microchip Technology
Quando dico alle persone che lavoro nel settore dei semiconduttori, in particolare in quello della sicurezza automobilistica, in genere queste presumono che mi riferisca agli allarmi per auto e telecomandi a portachiavi. Sebbene il furto d'auto rimanga una preoccupazione legittima, esistono minacce alla sicurezza significativamente maggiori associate alle ECU (electronic control unit) e alle loro comunicazioni, all'interno del veicolo e con il mondo esterno. Circa il 50 percento di tutti i nuovi veicoli venduti quest'anno saranno veicoli connessi e molti stimano che lo saranno circa il 95 percento entro il 2030. Quelle connessioni tramite Bluetooth, USB, LTE, 5G, Wi-fi, è inevitabile, portano molta comodità al consumatore, ma anche gli hacker sono ugualmente entusiasti dell'enorme aumento delle possibilità di punti potenzialmente accessibili per i loro attacchi. Una rapida ricerca su Google sul tema dell'hacking dei veicoli restituirà un numero infinito di violazioni della sicurezza nel mondo reale che hanno portato a costosi richiami, azioni legali e reputazione dei marchi fortemente compromesse. Ora un importante fatto: il software può essere soggetto a bug, e i bug sono sfruttabili dagli hacker. Ci sono molte cose che puoi fare per ridurre al minimo i bug e intraprendere azioni correttive una volta rilevati, tuttavia, fintanto che gli esseri umani scriveranno nuovo codice, potranno sempre essere introdotti nuovi bug.
Controller Area Network
L'accesso alla Controller Area Network (bus CAN) del veicolo è un obiettivo piuttosto comune per gli hacker. Sono stati dimostrati casi in quel senso che hanno consentito agli hacker di sfruttare un bug nel Bluetooth, il quale ha permesso loro di sfruttare un bug nel sistema operativo del veicolo, che ha quindi fornito a sua volta l'accesso remoto per manipolare i messaggi sul bus CAN. I veicoli moderni possono avere fino a 100 ECU con molte ECU critiche per la sicurezza che comunicano sul bus. Il bus CAN ha diversi vantaggi, per esempio utilizza un protocollo semplice e poco costoso, ed è estremamente robusto e relativamente immune ai disturbi elettrici, il che costituisce un'opzione affidabile per la comunicazione tra i nodi critici per la sicurezza. Lo svantaggio però è che per decenni non c'è stata sicurezza nel protocollo, il che significa che una volta che un hacker ottiene l'accesso, può inviare messaggi contraffatti che possono letteralmente distruggere le comunicazioni a bordo del veicolo. Alcuni esempi di ciò includono l'attivazione o disattivazione dei tergicristalli, lo spegnimento dei fari, la distrazione del conducente mediante manipolazione dell'audio, o la creazione di falsi allarmi del quadro strumenti, la visualizzazione errata della velocità, lo spostamento dei sedili o persino impadronirsi della guida dell'auto portandola fuori strada. La buona notizia è che con l'avvento di CAN FD ci sono ulteriori byte disponibili nel payload del messaggio per aggiungere sicurezza includendo un Message Authentication Code (MAC) per verificare crittograficamente l'autenticità del messaggio filtrando così eventuali messaggi contraffatti. Esistono due tipi di MAC tra cui scegliere: un HMAC basato su hash o un CMAC basato su crittografia a blocchi di chiavi simmetriche AES. CMAC è implementato per la stragrande maggioranza dei casi.
Crittografia e cybersicurezza
Gli OEM sono sempre stati impegnati nell’aggiornare le loro specifiche di sicurezza informatica in risposta a tutti i tentativi di attacchi che hanno avuto luogo. Quasi tutti gli OEM richiedono l'aggiornamento delle ECU critiche per la sicurezza per implementare i loro nuovi requisiti di sicurezza informatica mentre alcuni OEM richiedono l'aggiornamento del 100% delle ECU collegate. Il blocco di sicurezza fondamentale consiste nell'implementare l'avvio sicuro, che implica la verifica crittografica che il codice di avvio e dell'applicazione in esecuzione su un controller host siano rimasti invariati e sia in uno stato attendibile all'accensione, ripristinato e spesso ripetuto ad una cadenza prescritta una volta avviato. Appena dopo questo, un secondo requisito prevede il supporto per aggiornamenti firmware sicuri. Ricordate sempre che tutto il software può essere soggetto a bug; pertanto, è spesso necessario creare patch di bug del firmware che possono essere applicate sul campo. Questi aggiornamenti del firmware richiedono anche implementazioni di sicurezza crittografica che in genere richiedono che i payloads del firmware in ingresso 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 eseguita alcuna azione fino a quando la firma del payload non viene verificata dalla chiave ECC pubblica integrata nel controller. Una volta verificata la firma, l'immagine può essere decifrata e il firmware del controller aggiornato con la patch prevista per il bug o per il miglioramento delle funzionalità. La terza aggiunta nell'evoluzione della sicurezza è l'autenticazione dei messaggi come descritto sopra.
Autenticazione dei sistemi d’alimentazione
Diffusa per i veicoli elettrici è la crescente necessità di autenticazione della batteria. La maggior parte dei pacchi batteria sono progettati con moduli sostituibili all'interno del pacco batteria più grande; quindi, quando un modulo si guasta può essere sostituito senza dover sostituire l'intero pacco o doversi accontentare di un pacco con prestazioni inferiori. I moduli mal progettati possono rappresentare un pericolo per la sicurezza con conseguenti incendi a bordo del veicolo; pertanto, è importante che gli OEM applichino la gestione dell'ecosistema, il che significa che ogni modulo deve essere autenticato crittograficamente verificando che la produzione del modulo sia stata controllata e approvata dall'OEM prima di poter funzionare all'interno di quel blocco. Un modulo che non provoca incendi, ma che ha prestazioni inferiori, può ugualmente danneggiare la reputazione del marchio OEM, il che può comportare commenti negativi da parte della stampa oltre alla perdita di entrate. C’è ancora un altro motivo per verificare crittograficamente la fonte del produttore dei moduli.
Cosa significa verificare crittograficamente un modulo? È qualcosa che si ottiene impostando chiavi per la firma, specifiche del cliente, da utilizzare per il provisioning di dispositivi con certificate chain x.509 specifiche del cliente e un certificato univoco a livello di dispositivo basato su una coppia di chiavi ECC univoca. Il dispositivo fornito è montato su ciascun modulo batteria. Quando un modulo batteria viene sostituito all'interno del pacco, il Battery Management System (BMS), noto anche come gateway della batteria, richiederà al modulo il suo certificato X.509 univoco e verificherà le signature chain fino ad una radice attendibile. Dopo la verifica della firma viene presentata una challenge al modulo da firmare con la chiave privata associata attestante la conoscenza di un dato segreto senza però trasmetterlo sul bus, in alcuni casi trasmesso via RF. Il caso d'uso a livello di modulo si ferma qui. All'interno del BMS, gli OEM richiedono spesso un caso d'uso più complesso. Poiché il BMS/Gateway è il punto di comunicazione con il mondo esterno che fornisce rapporti di routine sullo stato della batteria al cloud, il caso d'uso della sicurezza viene ampliato per includere l'avvio protetto, l'aggiornamento sicuro del firmware e Transport Layer Security (TLS) per stabilire un canale sicuro di comunicazione con il cloud.
Archiviazione in sicurezza
Tutte le implementazioni di sicurezza discusse richiedono l'archiviazione sicura delle chiavi che può essere realizzata solo con una vera sicurezza basata sull'hardware. Può essere facile estrarre chiavi da microcontroller standard e anche da quei molti che affermano di avere "microcontroller sicuri" eseguendo alcuni attacchi standard tramite micro-probing, fault injection, electromagnetic side channel attack, temperature/power cycling/supply glitching, e timing attack solo per citarne alcuni. È importante selezionare il dispositivo giusto per eseguire cryptographic heavy lifting e proteggere le chiavi da questo tipo di attacchi. I dispositivi di sicurezza specializzati sono disponibili in una varietà di architetture e sono referenziati da una terminologia diversa come Hardware Security Modules (HSM) sia on-die che esterni, elementi sicuri, sottosistemi di archiviazione sicuri, key vault, smartcard, ecc. Tali dispositivi devono prevedere protezioni antimanomissione contro i suddetti attacchi al fine di proteggere le chiavi nelle loro memorie sicure.
Ma come può un fornitore Tier 1 o un OEM verificare che la sicurezza implementata sia sufficientemente buona? Il modo migliore per un fornitore di elementi sicuri per dimostrare la propria idoneità nei confronti della sicurezza è inviare il dispositivo ad una terza parte perchè questa esegua una valutazione della vulnerabilità. La terza parte dovrebbe essere accreditata da una fonte affidabile, come il National Institute of Standards of Technology (NIST) riconosciuto in Nord America, il Federal Office for Information Security (BSI) riconosciuto in Germania o il Senior Officials Group Information Systems Security (SOGIS) riconosciuto a livello globale. I laboratori accreditati SOGIS utilizzano un sistema di valutazione della vulnerabilità JIL (Joint Interpretation Library) riconosciuto a livello mondiale che richiede una valutazione "scatola bianca", il che significa che il fornitore di circuiti integrati che ha presentato la richiesta deve fornire la documentazione del laboratorio sulla progettazione del dispositivo (flusso di dati, sottosistema, definizione della mappa di memoria), sequenza di avvio dell'hardware e del firmware, descrizione dei meccanismi di protezione della sicurezza, scheda tecnica completa, documentazione di orientamento sulla sicurezza e sul bootloader, tutto il codice disponibile (Livello RTL e C, libreria crittografica, FW), implementazioni di algoritmi, script di programmazione, protocollo di comunicazione, die layout e codice sorgente. Il laboratorio esamina quindi tutta la documentazione e traccia il piano di attacco contro i dispositivi campione presentati. Il sistema di punteggio assegna punti in base al tempo impiegato per estrarre una chiave segreta, al livello di competenza richiesto (laurea triennale fino a più esperti), alla conoscenza del target of evaluation (TOE), all'accesso al TOE (quanti campioni di dispositivi per eseguire con successo un attacco), la complessità e il costo delle apparecchiature di hacking e la facilità di accesso ai campioni. I punteggi JIL risultanti iniziano senza valutazione, quindi si passa a Basic, Enhanced Basic, Moderate, e High è il miglior punteggio ottenibile. Qualsiasi valore inferiore a JIL High significa che il laboratorio è stato in grado di estrarre chiavi private dal dispositivo. Dispositivi come l'HSM esterno CryptoAutomotive TrustAnchor100 (TA100) di Microchip che hanno ricevuto un punteggio di JIL High, sono in grado di resistere agli attacchi per più di 3 mesi, a quel punto il laboratorio dichiara il dispositivo "non pratico" da attaccare.
On die or off die
On die or off die, questo è il dilemma. Soluzioni on-die come MCU dual core a 32 bit possono rappresentare un costoso aggiornamento per una ECU di generazione precedente che potrebbe essere stata perfettamente servita da un MCU standard prima che la vera sicurezza fosse richiesta da un OEM. Possono anche introdurre ritardi significativi nel time-to-market data la necessità di riprogettare completamente il codice dell'applicazione.
Può essere estremamente rischioso occuparsi dello sviluppo del codice di sicurezza internamente e pagare un costo proibitivo a terzi. È anche difficile per un fornitore Tier 1 diffondere la soluzione su più tipi di ECU, date le prestazioni variabili e i requisiti periferici di ciascun tipo. È qui che gli HMS esterni o gli elementi di sicurezza complementari possono ridurre significativamente il carico di aggiornamento della sicurezza per i fornitori Tier 1. Possono essere aggiunti in seguito ad un MCU standard in un progetto esistente o previsti in tutti I nuovi progetti con requisiti di MCU host diversi. Gli HSM esterni come il TA100 sono forniti con provisioning eseguito, inclusi tutti i codici di sicurezza, le chiavi e i certificati, il che riduce drasticamente il time-to-market. È facilmente trasportabile su qualsiasi MCU data la libreria Crypto associata che è indipendente dall'MCU.
Rischi, time-to-market e costi complessivi vengono ridotti, offrendo ai fornitori Tier 1 un percorso agile per conquistare affari prima della concorrenza, seguendo un percorso completamente riprogettato.
Vista la presenza odierna di auto connesse e il pesante traffico di comunicazioni sulla rete a bordo dei veicoli, la necessità di sicurezza automobilistica va evidentemente ben oltre gli allarmi per auto. Con la sicurezza da garantire e la reputazione del marchio da proteggere, è più importante che mai 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 obblighi di sicurezza imposti dai vari governi nazionali.
