Tendenze in materia di sicurezza automobilistica:
l'attenzione alla sicurezza è aumentata anche grazie all'adozione di un'architettura zonale rispetto alla tradizionale architettura a domini. In un'architettura a domini, le centraline elettroniche (ECU) con funzioni simili sono interconnesse in una sottorete, dando luogo a numerosi domini indipendenti. Questi domini sono suddivisi in propulsione e trasmissione, controllo della carrozzeria, climatizzazione e così via, e ciascuno può essere sviluppato per soddisfare un diverso livello di sicurezza a seconda della sua rilevanza per il veicolo. Al contrario, nel concetto zonale, le ECU sono connesse a un controller di zona locale e a dei gateway. In un'architettura zonale, le funzioni di diversi controller di dominio sono concentrate in un controller centralizzato. Questa concentrazione riduce i costi e la complessità del sistema, motivo per cui l'architettura zonale viene sempre più spesso preferita all'architettura a domini. Uno svantaggio dell'architettura zonale è che richiede che le ECU di domini diversi condividano la rete di comunicazione, il che significa che tutte le ECU nell'architettura zonale devono adottare livelli di sicurezza più elevati.

Figura 1. Architettura di dominio rispetto all'architettura zonale.

Per affrontare il tema della sicurezza automobilistica, gli enti pubblici e gli istituti di standardizzazione internazionali richiedono ai produttori di adottare nuovi standard come ISO/SAE 21434 e regolamenti come UNECE (Commissione economica per l'Europa delle Nazioni Unite) WP.29 R155/R156, nonché normative simili applicabili in specifiche aree geografiche.
ISO 21434 è uno standard di cybersicurezza relativamente recente nel settore automobilistico. Si concentra sui requisiti ingegneristici e di processo lungo tutto il ciclo di vita del prodotto e include politiche organizzative, processi di sviluppo del prodotto e gestione delle problematiche di sicurezza durante tale ciclo. Affinché i veicoli siano conformi agli standard di cybersicurezza, questo standard deve essere adottato lungo tutta la catena di fornitura, dai produttori stessi, nonché dai fornitori diretti di software e componenti a semiconduttore.
UNECE R155 e R156 sono regolamenti di cybersicurezza adottati finora da 65 paesi. I produttori di automobili devono implementarli per commercializzare i propri veicoli in questi paesi e, da luglio 2024, la conformità è obbligatoria per tutti i nuovi veicoli in produzione.

La normativa UNECE fa riferimento alle specifiche tecniche della norma ISO 21434 e richiede l'implementazione di un Sistema di Gestione della Sicurezza Informatica (CSMS). Questo sistema deve coprire l'intero ciclo di vita del veicolo, dallo sviluppo alla dismissione. Durante tutto questo periodo, il CSMS deve monitorare le minacce informatiche e implementare un processo per mitigarle. In alcuni casi, la tecnica di mitigazione può consistere nell'applicazione tempestiva di patch al firmware di una centralina elettronica (ECU) vulnerabile. Pertanto, gli aggiornamenti del firmware via etere (over-the-air) sono diventati necessari in tutti i veicoli per conformarsi alle normative UNECE. Il sistema integrato della centralina elettronica deve incorporare l'avvio sicuro, gli aggiornamenti del firmware sicuri e la comunicazione sicura per garantire aggiornamenti del firmware via etere affidabili.
Un esempio di applicazione che richiede la capacità di aggiornamento via etere e un elevato livello di autenticazione è la ricarica wireless dei dispositivi personali nell'abitacolo del veicolo. Il Wireless Power Consortium (WPC), che gestisce le specifiche di ricarica wireless Qi®, è preoccupato per i caricabatterie dannosi che possono danneggiare telefoni e altri dispositivi. Gli standard Qi 1.3 e il più recente Qi 2.0 richiedono ai caricabatterie wireless di autenticarsi crittograficamente per la ricarica ad alta potenza. Per abilitare questa autenticazione, i caricabatterie wireless conformi a Qi devono avere certificati di unità prodotto (Product Unit Certificates) integrati nell'hardware del dispositivo. Questi certificati sono certificati a chiave pubblica che i produttori possono ottenere da autorità di certificazione autorizzate dal WPC (Wireless Physical Certification). I caricabatterie devono inoltre integrare hardware CC EAL (Common Criteria Evaluation Assurance Level) o JIL (Joint Interpretation Library) ad alta sicurezza, in grado di eseguire l'autenticazione basata su firma ECC, l'archiviazione sicura delle chiavi e l'archiviazione sicura del certificato X.509.

Sicurezza software e hardware:
la funzione di avvio sicuro è fondamentale per stabilire la radice di fiducia nella centralina elettronica (ECU), poiché il bootloader sicuro garantisce che il firmware in esecuzione sul dispositivo sia autentico e non sia stato manomesso durante o dopo la produzione in fabbrica. Pertanto, il bootloader è responsabile di garantire che il firmware utilizzato sia originale e provenga dal produttore o dal fornitore diretto. Il segmento di memoria dei controller che memorizza il bootloader sicuro deve essere immutabile (o non modificabile), quindi deve essere protetto da scrittura e programmabile una sola volta durante la programmazione iniziale in fabbrica. Nella sequenza di avvio, il controller di segnale digitale in tempo reale (RTS) esegue il bootloader sicuro per verificare l'autenticità e l'integrità delle immagini dell'applicazione. Sia l'autenticità che l'integrità possono essere verificate utilizzando l'algoritmo di firma digitale a curva ellittica (ECDSA) e gli algoritmi di hash. La Figura 2B illustra i passaggi per la creazione di un'applicazione con un'immagine firmata, mentre la Figura 2C mostra il processo di verifica dell'applicazione utilizzando un RTS integrato. La Figura 2C mostra l'utilizzo della funzione hash SHA-256 per ottenere una sintesi e verificare il passaggio utilizzando ECDSA e l'algoritmo ECDSA P-256.

Figura 2. Processo di avvio protetto, aggiornamento del firmware e mappa della memoria del controller.

La funzione di aggiornamento sicuro del firmware può essere una sezione immutabile del controller di segnale digitale in tempo reale ed è responsabile dell'interazione con il gateway centrale tramite la rete del veicolo per ricevere la nuova immagine dell'applicazione. Poiché l'immagine dell'applicazione incorpora l'indirizzo IP funzionale del nodo, i progettisti devono considerare l'utilizzo della crittografia e dell'autenticazione del nodo tramite l'interfaccia di comunicazione per evitare di esporre l'immagine del firmware. La Figura 2A mostra la mappa di memoria per un controller con una funzione di aggiornamento del firmware; in genere richiede tre sezioni applicative: una per l'immagine attualmente attiva, una per il download della nuova immagine e una sezione di ripristino delle impostazioni di fabbrica per memorizzare l'immagine predefinita come meccanismo di ripristino in caso di errore. L'aggiornamento del firmware deve anche verificare l'autenticità e l'integrità, nonché il processo di avvio sicuro, e deve implementare una politica di aggiornamento in modo che il firmware possa essere aggiornato solo a una versione più recente. L'aggiornamento del firmware deve anche implementare un metodo di ripristino del sistema che risulti utile in determinate situazioni, ad esempio quando l'immagine dell'applicazione attiva o l'applicazione scaricata non superano un controllo di autenticità.

Per implementare queste funzionalità di sicurezza, la tecnica consigliata è quella di utilizzare un modulo di sicurezza hardware (HSM) esterno in combinazione con un microcontrollore o un controller di segnale digitale (DSC) sicuro, oppure un microcontrollore/DSC con un HSM integrato nello stesso package. Un microcontrollore/DSC con HSM integrato è vantaggioso quando è richiesto un ingombro ridotto. Le soluzioni di sicurezza embedded che utilizzano il DSC dsPIC33, ad esempio, supportano sia HSM interni che esterni; entrambi sono ampiamente accettati dai produttori automobilistici. Gli HSM fungono da enclave di sicurezza quando l'area di memorizzazione delle chiavi sicure e i moduli crittografici sono separati dal sistema principale del microcontrollore/DSC. Ciò riduce il rischio per la sicurezza rispetto a un microcontrollore che memorizza le chiavi nella sua memoria interna. Il microcontrollore/DSC sicuro completa un HSM esterno con funzionalità quali memoria di avvio sicura immutabile, memoria Flash programmabile una sola volta e la possibilità di disabilitare l'accesso alla modalità di debug. Una piattaforma ECU basata su un HSM e una famiglia di microcontrollori sicuri è più adatta perché consente di selezionare il microcontrollore appropriato in base ai requisiti di memoria e funzionalità.
Lo sviluppo con un HSM esterno o integrato richiede una conoscenza approfondita della sicurezza e un'analisi completa delle numerose impostazioni di configurazione per soddisfare i requisiti di sicurezza specifici di ciascuna applicazione e i profili di sicurezza desiderati. Pertanto, è importante iniziare lo sviluppo con un ecosistema di strumenti che offra prototipazione hardware rapida e configuratori grafici. Un altro aspetto importante è la programmazione sicura di chiavi e dati segreti nell'HSM durante la fase di produzione, senza esporre informazioni sensibili. Questa preoccupazione è stata attenuata da alcuni fornitori di semiconduttori per HSM che offrono la fornitura sicura di HSM. Questi dispositivi semplificano notevolmente la produzione. Le
moderne ECU sono state sviluppate secondo AUTOSAR (Automotive Open System Architecture). Pertanto, lo sviluppo della sicurezza richiede un HSM e un microcontrollore/DSC sicuro compatibile con i componenti software AUTOSAR disponibili sul mercato. AUTOSAR supporta l'implementazione della sicurezza attraverso vari blocchi funzionali.

La Figura 3 mostra un diagramma concettuale dell'architettura AUTOSAR. In basso si trova un DSC, ovvero un microcontrollore fisico, e in alto il Basic Software (BSW). Il BSW è ulteriormente suddiviso in livello di servizio, livello di astrazione della centralina (ECU) e livello di astrazione del microcontrollore (MCAL). Al di sopra di questi si trova il livello Run-Time Environment (RTE), che fornisce un'interfaccia standardizzata per consentire alle applicazioni di accedere ai livelli sottostanti. Facilita inoltre la comunicazione tra i componenti applicativi di livello superiore, programma il BSW e gestisce le risorse e le istanze del BSW. In alto, il livello applicativo è segmentato in AUTOSAR Software Components (SW-C). Il livello applicativo è costituito da numerosi componenti software, ognuno dei quali contribuisce con una funzione specifica alla centralina.

Il BSW dispone di un'interfaccia standard per l'utilizzo di funzionalità di sicurezza come periferiche crittografiche, anchor di fiducia e moduli HSM. L'architettura AUTOSAR suddivide l'implementazione crittografica in tre livelli: un livello di servizio, un livello di astrazione hardware e MCAL. Il livello di servizio contiene il Crypto Service Manager (CSM). I componenti applicativi interagiscono con il CSM per accedere alla libreria crittografica sottostante, all'HSM e per programmare le funzioni crittografiche.
Lo stack crittografico può essere configurato per utilizzare le funzioni crittografiche hardware disponibili nel DSC o dispositivi crittografici esterni, come un HSM ausiliario esterno. Lo stack AUTOSAR può integrare l'utilizzo di un HSM esterno tramite l'interfaccia SPI (Serial Peripheral Interface) di MCAL e il driver crittografico appropriato fornito dal produttore dell'HSM.
La principale funzione di sicurezza è fornita dallo stack crittografico, che ha accesso alle primitive crittografiche e alla gestione delle chiavi. AUTOSAR supporta tre protocolli di comunicazione sicura: SecOC (Secure Onboard Communication), TLS (Transport Layer Security) e IPsec (Internet Protocol Security). SecOC è uno standard aperto definito dall'organizzazione AUTOSAR ed è preferito per la comunicazione sicura tra centraline elettroniche (ECU). Può essere utilizzato su reti CAN, Ethernet o LIN. Il software BSW di AUTOSAR integra funzionalità di diagnostica sicura e rilevamento delle intrusioni. Ulteriori funzioni, come gli aggiornamenti sicuri del firmware, possono essere implementate nello stack crittografico (Crypto Stack).

Figura 3. Funzioni crittografiche di AUTOSAR.

Conclusione:
Il trend del mercato delle auto connesse sta generando preoccupazioni in materia di privacy e sicurezza per enti pubblici, case automobilistiche e automobilisti. Pertanto, le nuove normative impongono alle auto di integrare la sicurezza informatica per proteggere la privacy dei dati e migliorare la sicurezza. La sicurezza informatica coinvolge l'intera catena di fornitura, dalle case automobilistiche ai fornitori di componenti. I progettisti possono utilizzare un modulo HSM insieme a un microcontrollore/DSC sicuro o un microcontrollore/DSC con un HSM integrato in un unico package. Inoltre, un ecosistema di strumenti di prototipazione rapida, librerie e configuratori grafici per HSM facilita lo sviluppo. La disponibilità di librerie e supporto AUTOSAR riduce anche lo sforzo di progettazione. L'ecosistema ideale per un DSC o un microcontrollore in un'auto deve essere pienamente conforme ad AUTOSAR, alla sicurezza funzionale ISO 26262, a ulteriori certificazioni di sicurezza funzionale e alle librerie di sicurezza. Consultare l' ecosistema automotive DSC dsPIC33 per ulteriori informazioni su AUTOSAR, sicurezza informatica automotive e sicurezza funzionale con ISO 26262.

Autore: Nelson Alexander, ingegnere capo e responsabile marketing di prodotto presso Microchip Technology.