Sono cinque le principali considerazioni sul software di sistema che i costruttori, i fornitori di componentistica Tier-1 e i loro fornitori devono affrontare per rendere le proprie aziende, infrastrutture e prodotti software Adas di successo.
5 - Piano per gli aggiornamenti
I sistemi di assistenza alla guida tradizionali, come i semplici cruscotti elettronici, sono caratterizzati dalla presenza di applicativi software relativamente piccoli, sistemi operativi semplici (Osek, Autosar) e team di progettazione software esperti nei processi di sviluppo critici dal punto di vista della sicurezza. Gli Adas di nuova generazione impongono requisiti più stringenti, come l'elaborazione grafica in 3D, che sfrutta una base di software di grandi dimensioni ed eventualmente software di terze parti sviluppato da tecnici senza competenze specifiche sui processi di sviluppo di software sicuro. I progettisti devono prevenire i rischi legati a questi apparati sempre più complessi e costruire in essi un sistema affidabile e scalabile per l’aggiornamento/upgrade del software. L'industria dei dispositivi mobili ha dimostrato l'importanza e la praticità di un meccanismo di aggiornamento scalabile del software, dal firmware del bootloader di più basso livello fino a completi sistemi operativi e applicazioni per dispositivi mobili e i costruttori di dispositivi mobili hanno fatto un ottimo lavoro sviluppando e distribuendo queste funzioni. Anche se esistono standard aperti per le procedure di aggiornamento del software (in particolare, Open Mobile Alliance DM/Fumo), questi non considerano molti degli aspetti pratici legati agli upgrade, come la gestione della versione, la programmazione della loro distribuzione a un elevata quantità di sistemi remoti e l'ottimizzazione delle dimensioni delle patch in reti wireless confinate. Su questo punto, l'industria dell'autoveicolo deve rapidamente migliorare e far evolvere la tecnologia richiedendo un grado di affidabilità superiore nell'ambito della sicurezza fisica e informatica dell'infrastruttura di upgrade e delle patch. La sicurezza fisica delle procedure di aggiornamento sul campo richiede un'infrastruttura crittografica integrata nei dispositivi SoC e nel relativo software di sistema. In particolare, il software dovrà essere controllato in termini di integrità e di autenticità attraverso firme digitali, la cui chiave di verifica dovrà essere protetta da manomissioni (sia di tipo software che fisico). La chiave di verifica deve risiedere in un'area del chip a prova di manomissione o protetta da una chiave di tipo hardware. Anche il software di sistema utilizzato per la validazione deve essere protetto contro le manomissioni, combinando un avvio sicuro, una verifica di integrità dinamica e una conferma da remoto. La memorizzazione sicura nel chip e un firmware consolidato che non cambia possono essere considerati come le “radici” della fiducia praticamente per tutte le funzioni di sicurezza importanti del sistema.
4 - Conformità a Iso26262 Asil-D
Sebbene molti dei tradizionali sistemi elettronici di guida siano stati sviluppati da team specializzati di piccole dimensioni e di provata esperienza in grado di sviluppare software sicuro e affidabile, il passaggio a sistemi Adas sofisticati richiede un processo formale che garantisca che la sicurezza non venga lasciata per ultima: la cultura della sicurezza deve permeare l'intera organizzazione aziendale, comprendendo il progetto, la produzione e le operation, in un ciclo iterativo con i fornitori. Questa emanazione di una standardizzazione efficace del processo richiede non solo standard di qualità elevata ma anche l'obbligo di conformità agli standard stessi. Lo standard di sicurezza Iso26262, inizialmente pubblicato nel 2011, è stato concepito per fornire una guida ed è stato generalmente ben accettato dall'intera comunità delle case automobilistiche. Manca tuttavia la sua applicazione, dal momento che i governi devono ancora emettere un decreto attuativo per la Iso26262. Le aziende leader dell'industria automobilistica, tra cui alcuni produttori di sottosistemi e fornitori Tier-1 e Tier-2, considerano la conformità alla Iso26262 una regola interna e un obiettivo da raggiungere per soddisfare gli stringenti requisiti di sicurezza degli Adas e di altri sistemi. Come minimo, la competenza nella Iso26262 e la dimostrazione di saper soddisfare il livello di sicurezza più elevato (Asil D), oltre che la scelta di fornitori che facciano lo stesso, dà loro un vantaggio competitivo. Uno sviluppatore può anche scrivere del software perfetto e poi vederlo fallire se il compilatore non traduce correttamente il codice sorgente in codice macchina. La norma Iso26262 copre anche l'uso di tool di sviluppo software per la creazione di software safety-critical, richiedendo la qualifica dei tool tramite una combinazione di un comprovato pedigree, della valutazione del processo di sviluppo del fornitore del tool e della convalida della funzionalità del tool. Tool classificati al massimo livello di qualifica T3, generano codice fa parte dei programmi in esecuzione in un sistema con requisiti di sicurezza. Sebbene diversi fornitori di compilatori affermino di disporre di un compilatore certificabile o di un pacchetto di qualifica che può essere certificato dal costruttore, alla data di questo scritto solo i compilatori Green Hills e Arm C sono stati certificati in modo indipendente per l'uso in sistemi Iso26262 Asil-D (certificati in modo indipendente dall'ente Tuv).
3 - Seguire con cautela gli standard dell'elettronica di largo consumo
I sistemi Adas di nuova generazione utilizzano una grafica all'avanguardia, l'elaborazione dei segnali e altri algoritmi e software sofisticati. Essi sfruttano le innovazioni multimediali affermatesi nell'elettronica di largo consumo, come quelle delle macchine da gioco e dei dispositivi mobili, e i progettisti devono essere al passo con i relativi standard, come OpenGL, OpenVG, OpenVX e OpenCL.Un problema importante, tuttavia, è conciliare l'uso dei complessi pacchetti software per l'elettronica di largo consumo con i precedenti requisiti di sicurezza (alias Iso26262). Un modo di includere software di uso generale, anche open-source, in un sistema safety-critical è quello di usare la virtualizzazione di sistema per isolare i componenti critici dal punto di vista della sicurezza dai pacchetti più complessi che non soddisfano gli standard safety-critical. Grazie alla virtualizzazione, questi sottosistemi complessi possono anche essere dei completi sistemi operativi “guest”, che girano su una macchina virtuale sotto il controllo di un ipervisore classificato sicuro. A differenza degli ipervisori tradizionali, un ipervisore di livello automotive può offrire funzioni di sicurezza native in tempo reale, oltre che applicazioni guest. La rigorosa schedulazione delle risorse e i meccanismi di protezione dell'ipervisore fanno sì che la macchina virtuale e le applicazioni che ne fanno parte non ostacolino l'esecuzione delle applicazioni critiche. Sfortunatamente, nel caso dei sistemi Adas, spesso i sottosistemi complessi devono essere utilizzati in contesti critici per la sicurezza. Ad esempio, un display ricco di grafica in 3D può essere usato per informare il guidatore di un pericolo. Pochissime piattaforme software run-time al mondo possono affermare di essere conformi alla Iso26262 Asil-D e di supportare al contempo la grafica 3D. Ad esempio, il sistema operativo in tempo reale Integrity di Green Hills Software, piattaforma utilizzata nei sistemi di sicurezza per l'autoveicolo, supporta OpenGL, un software grafico (e relativi driver) che si prevede l’uso completo di acceleratori hardware per un'ampia varietà di comuni SoC automobilistici, come le serie Freescale i.MX, TI Jacinto, Renesas R-Car e Intel Atom processor E3800. I progettisti di sistemi devono considerare attentamente le architetture software di sistema per assicurarne la scalabilità e gestire praticamente qualsiasi combinazione di operazioni safety-critical e multimediali di fascia alta. Ritornando per un momento ai requisiti della Iso26262: anche se Asil D è il massimo livello di sicurezza definito dalla Iso26262, non è richiesto che ogni singolo componente e sottosistema di un'auto o apparato/SoC debba soddisfare questo livello. La Iso26262 introduce il concetto della decomposizione Asil tramite partizionamento del software. Ad esempio, un sottosistema Asil-C può essere composto da una partizione Asil-B e una partizione Asil-A, purché si riesca a verificare adeguatamente il partizionamento e la libertà da interferenza e purché si riesca a convalidare e a verificare l'intera funzione di sicurezza del sottosistema a livello Asil-C. In questo modo, un sistema operativo o ipervisore con partizionamento “high-assurance” (certificato Asil-D) può abbattere i costi generali di sistema riducendo i requisiti Asil dei componenti costituenti e permettendo un uso (attento) di pacchetti software complessi che non sarebbero praticabili agli alti livelli dello standard.
2 - Fiducia zero
Una delle discussioni dominanti nel 2014, che si protrae anche nel 2015, è il tema dell'automobile connessa e dei rischi intrinseci di sicurezza associati all'introduzione delle comunicazioni wireless (soprattutto Wan) nel veicolo. Idealmente, i sottosistemi safety-critical nell'auto sono fisicamente isolati (tramite separazione fisica) dai sottosistemi multimediali o telematici che possono sfruttare questa connettività. I progettisti di sistemi, tuttavia, sostituiscono sempre più la separazione fisica con una separazione logica, rinforzando l'isolamento del sottosistema con dei firewall di tipo software. Sfortunatamente, come dimostrato dalle ricerche, quando l’ahardware viene consolidato, le vulnerabilità dei diversi sottosistemi possono permettere di “penetrare” la barriera logica tra i sistemi safety-critical e quelli non safety-critical. Anche se il problema può sembrare semplice da risolvere (mantenendo la separazione fisica!), in pratica, vi sono numerose esigenze che rendono necessarie il consolidamento. Ad esempio, requisiti in termini di dimensioni, peso e costi richiedono una riduzione del cablaggio e dei componenti hardware. Questo consolidamento induce i progettisti a utilizzare un isolamento di tipo logico. Un'altra tendenza importante è stata già discussa sopra: l'aggiornamento sul campo. Per aggiornare un sottosistema a sicurezza critica, deve esistere un percorso completo dallo sviluppatore di patch che lavora in rete al sistema aggiornabile installato sull'autoveicolo. Ironicamente, si tratta del percorso di accesso remoto, per aggiornamenti software, diagnostica e altre funzioni critiche di raccolta dati, che ha permesso agli hacker di sfruttare l'ampia serie di vulnerabilità presenti nei prodotti ad alto contenuto software. In effetti, questo è oggi probabilmente il rischio di sicurezza dell'Internet of Things che fa più paura. Ancora una volta, un isolamento logico “high assurance” può risolvere molti di questi problemi. Ma “high assurance” è una caratteristica incredibilmente rara nell'elettronica moderna. Alla data di questo scritto, il governo statunitense è l'unico ad aver mai fornito una certificazione software “high assurance” nel rispetto dello standard di sicurezza Iso15408 Common Criteria (per un unico prodotto, Green Hills Software Integrity-178B) e il programma governativo per promuovere queste certificazioni “high assurance Common Criteria” è stato interrotto anni fa per esaurimento dei fondi e per aver superato i tempi massimi previsti (leggi “burocrazia governativa”). Ad oggi, quindi, i costruttori di automobili e i fornitori Tier-1 non possono che basarsi su accertamenti indipendenti da parte di consulenti di sicurezza e sulla comprovata esperienza “high assurance” dei fornitori. L'industria deve inoltre evolversi al fine di proteggere la privacy delle informazioni generate nei sistemi Adas e in altri sottosistemi intelligenti e distribuite nel cloud per analisi, monetizzazione etc. Anche se la proprietà di questi dati può essere difficile da stabilire, essa è nondimeno un bene di valore e la combinazione di queste informazioni di milioni di auto presenta un obiettivo allettante per hacker evoluti e ben finanziati. I proprietari dei dati devono adottare un atteggiamento a “fiducia zero” (zero trust) nel richiedere la proprietà e il controllo delle chiavi private utilizzate per proteggere tali informazioni. Affrontando la protezione dei dati in modo ortogonale rispetto alla scelta dei protocolli software di sistema e dei prodotti, il problema della privacy può essere risolto in modo scalabile. Il 2014 può essere ricordato come l'anno dell’imbarazzo Ssl dopo la serie incredibile di di disastri: Poodle, Heartbleed, l'errore di Apple “goto fail” e altri. Si spera che queste vulnerabilità siano state utili per mandare dei chiari messaggi all'industria, come: attivare l'Ssl (o altri protocolli data-in-transit) non è una strategia per la protezione dei dati IoT; l’open-source e assurance-level sono elementi ortogonali fra di loro; high-assurance è l'unica strada per prevenire le vulnerabilità.
1 - Non congelare l'hardware finché non sono stati analizzati i punti da 2 a 5
Troppo spesso, decisioni critiche e irreversibili sull'hardware vengono prese con poca o nessuna considerazione degli aspetti sopra discussi. Flop e distinte base continuano a dominare le decisioni di acquisto, con grande rammarico dei progettisti software e di sistemi. Verrà un giorno, si spera presto, in cui prima di scegliere un particolare SoC per Adas saranno prese in considerazione le caratteristiche di safety e security (TrustZone, estensioni di virtualizzazione Arm, Mmu, Iommu, memorizzazione protetta della chiave su chip, generazione sofisticata di numeri casuali, funzioni di debug come trace e altro) e l'ecosistema software disponibile per implementare tali caratteristiche, nei limiti della potenza di elaborazione del dispositivo per dollaro.
