Completato il security assessment del veicolo ed eseguito un vulnerability assessment e un penetration test, possiamo ora passare alla parte “dura” della cyber security in ambito automotive: la messa in sicurezza dei componenti che compongono il veicolo stesso.
Indice degli argomenti
Cyber security automotive: proteggere le funzioni e la connettività
Mentre nel mondo gestionale le entità da proteggere sono le informazioni (nell’ordine di importanza: riservatezza, integrità, disponibilità), nel mondo cosiddetto Embedded (IoT) la sicurezza si deve occupare di proteggere principalmente le funzioni (nell’ordine di: integrità, disponibilità e riservatezza) e la connettività.
Con i recenti sviluppi delle tecniche di hacking di questi sistemi cyber-fisici, (CPS=Cyber Physical Systems), anche la difesa si è concentrata sempre di più su aspetti strettamente legati all’hardware dei dispositivi: sentiamo spesso parlare di HSM (Hardware Security Modules) oppure SHE (Secure Hardware Extensions) oppure ancora di HTA (Hardware Trust Anchors) ed infine TPM (Trusted Platfrom Module).
Queste difese nel mondo automotive hanno acquisito di recente grande importanza grazie a standard di settore pubblicati o in via di pubblicazione come la ISO 21434, il SAE J3061, il progetto europeo EVITA del 2012, e ancora più di recente nuove linee guida SAE.
SAE International (Society of Automotive Engineers) è un ente di normazione nel campo dell’industria aerospaziale, automobilistica e veicolistica. Ha la sua sede centrale a Troy, nello stato del Michigan (USA). L’ente si occupa di sviluppare e definire gli standard ingegneristici per veicoli motorizzati di ogni genere, tra cui automobili, autocarri, navi e aeromobili.
Uno degli obiettivi principali dello standard è stabilire una comprensione comune delle caratteristiche e delle funzionalità di base di un ambiente di sicurezza protetto nell’hardware e garantire che le best practice siano applicate nella definizione e nell’implementazione di questi componenti.
La recente pubblicazione di documenti SAE mira proprio a definire linee guida per l’applicazione della cyber security a livello hardware dei componenti del veicolo.
Cyber security automotive: specifiche hardware di sicurezza
La specifica Secure Hardware Extension (SHE) sviluppata in Germania, è stata ora accettata come standard aperto e gratuito. La specifica SHE definisce un insieme di funzioni e un modello di programmazione (API) che consente a una zona sicura di coesistere all’interno di qualsiasi unità di controllo elettronica installata nel veicolo.
Le funzionalità più significative della zona protetta sono l’archiviazione e la gestione delle chiavi di sicurezza, oltre all’incapsulamento di algoritmi di autenticazione, crittografia e decrittografia a cui il codice dell’applicazione può accedere tramite l’API.
Il progetto EVITA (E-safety vehicle intrusion protected applications), finanziato dall’UE, ha sviluppato una serie di linee guida che descrivono in dettaglio la progettazione, la verifica e la prototipazione di una gamma di architetture di sicurezza HW per ECU automobilistiche.
Diverse aziende sono state attive nel progetto EVITA. EVITA definisce la funzionalità complessiva di tre diversi approcci per gli Hardware Security Modules (HSM): –full, medium e light. Inoltre, specifica un insieme elaborato di funzioni e relativi parametri per la gestione delle chiavi di sicurezza e delle operazioni di crittografia e decrittografia.
Un altro buon esempio di standard di sicurezza viene dal National Institute of Standards and Technology (NIST), che ha emesso lo standard FIPS (Federal Information Processing Standards) 140 sia per i componenti software che hardware. FIPS 140-2 definisce quattro livelli di sicurezza che vanno dal Livello 1 con una semplice funzione di sicurezza singola e nessun requisito di sicurezza fisica fino al Livello 4 che impone meccanismi di rilevamento delle manomissioni fisiche e protezione dagli attacchi ambientali, come tensione e temperatura.
Un’altra organizzazione che definisce standard in questo ambito è il Trusted Computing Group (TCG), che afferma di fornire standard aperti, interoperabili e internazionali per il trusted computing.
Una delle specifiche rilasciate da questa organizzazione è il Trusted Platform Module (TPM), pubblicato come ISO / IEC 11889 parti 1-4.
Come la specifica SHE, TPM supporta chiavi protette per le funzioni di autenticazione e crittografia.
Gli sviluppatori generalmente implementano TPM come una periferica esterna con un bus di comunicazione a un altro microcontrollore nel sistema. TPM specifica la memoria non volatile, l’archiviazione della chiave segreta, un generatore di numeri casuali, algoritmi come RSA, SHA, HMAC, AES.
Infine si parla in generale, specie nel mondo Internet of Things di Root of Trust, ovvero di un motore di elaborazione, un codice e possibilmente dei dati, tutti collocati nella stessa piattaforma; fornisce servizi di sicurezza molto generali (anche di tipo PKI – Public Key Infrastructure).
Un esempio di applicazione di questo concetto si può ritrovare nell’approccio per rilevare e mitigare l’infezione del codice di avvio (SecureBoot). Esso consiste nell’impostare un meccanismo di tipo Root of Trust che autentichi il codice di avvio prima che venga eseguito.
Standard di riferimento nel settore automotive
Esiste da tempo nel settore automobilistico l’esigenza di un documento che fornisca una base di due diligence nello sviluppo del prodotto anche a livello hardware.
Ebbene l’industria automobilistica ha sviluppato due importanti corpi di lavoro per affrontare la sicurezza dei veicoli. Un documento SAE (J3101) è diventato la linea guida per la sicurezza dell’hardware nelle applicazioni dei “veicoli terrestri”.
Questo documento descrive ad esempio le funzioni di Secure Boot, Secure Storage, Secure Execution Environment, nonché altre funzionalità hardware e meccanismi di autenticazione, aggiornamenti Over the Air (OTA) e gestione delle chiavi di crittografia.
I sistemi informatici automobilistici sono tenuti a stabilire l’affidabilità attraverso l’identità del dispositivo, il sigillo, l’autenticazione, l’integrità e disponibilità dei dati. Questi sistemi devono essere resistenti a un’ampia gamma di attacchi che non possono essere contrastati da meccanismi di sicurezza solo basati sul Software.
Serve una sicurezza basata su Hardware per soddisfare le richieste di veicoli connessi e altamente o completamente automatizzati. Questo documento fornisce una visione completa dei meccanismi di sicurezza supportati nell’hardware per casi d’uso automobilistici, insieme alle migliori pratiche di utilizzo di tali meccanismi.
Questo documento mira a diventare il riferimento delle best practice del settore relative alle aspettative minime dell’hardware in termini di sicurezza informatica.
Come esempi di requisiti comuni, derivati da casi d’uso, vediamo nel seguito quelli che rappresentano categorie di funzionalità dell’ambiente di sicurezza protetto dall’hardware:
Protezione della chiave crittografica e necessità di avere un’area di memorizzazione sicura
Requisiti di storage e gestione delle chiavi. Tutti i meccanismi e le funzionalità associati alla gestione delle chiavi crittografiche devono essere elementi di gestione sicura:
- algoritmi crittografici. Gli algoritmi crittografici sono destinati all’implementazione nell’hardware protetto di un ambiente di sicurezza al fine di mantenere la riservatezza, l’integrità e la disponibilità dei sistemi che ne fanno uso nonché le performances di elaborazione;
- generatore di numeri casuali Il generatore di numeri casuali crittografici (Random Numbers Generator – RNG) all’interno di un ambiente di sicurezza protetto dall’hardware è destinato a scopi crittografici. Gli standard NIST descrivono le proprietà che una sorgente di entropia deve avere per renderla adatta per l’utilizzo da parte di generatori di bit casuali crittografici, nonché i test utilizzati per valutare la qualità della sorgente di entropia. Fornisce indicazioni sui metodi per costruire, testare e convalidare le sorgenti di entropia;
- protezione dei dati non volatili. L’ambiente di sicurezza protetto dall’hardware deve essere in grado di garantire l’integritàe freschezza dei dati (attacchi a Replay). L’ambiente di sicurezza protetto dall’hardware deve essere in grado di garantire la riservatezza dei dati;
- agilità dell’algoritmo.Una proprietà importante dell’agilità degli algoritmi crittografici è la rimozione o la disabilitazione di algoritmi deprecati.
- ambiente di esecuzione sicuro. L’ambiente di esecuzione sicuro dell’ambiente di sicurezza protetto dall’hardware può fornire una protezione di servizi comuni, risorse utilizzate per elaborare i dati segreti e varie logiche crittografiche associate.
Riassumendo, i requisiti comuni che costituiscono una base fondamentale di qualsiasi ambiente di sicurezza protetto in hardware sono i seguenti:
- protezione della chiave crittografica;
- algoritmi crittografici;
- ambiente di esecuzione sicuro.
Infine, un’altra caratteristica importante della sicurezza a livello hardware è la definizione dei profili di sicurezza indipendenti. Ogni profilo è costituito da una serie di funzionalità di sicurezza scelte in base ai casi d’uso tipici dei sistemi automobilistici.
Alcuni esempi di profili degli ambienti di sicurezza protetti dall’hardware potrebbero essere i seguenti:
- riservatezza
- integrità
- disponibilità
- non ripudio
- controllo degli accessi
Conclusioni
Il proprio sistema Embedded sarà sotto attacco da una molteplice varietà di tecniche di hacking se si tratta di un prodotto di successo.
Forse gli attaccanti vorranno semplicemente duplicare il progetto, o forse vorranno anche decodificare e rubare le idee realizzative e gli algoritmi sottostanti per creare un vantaggio competitivo. Cercheranno anche di attaccare il sistema da remoto per rubare informazioni riservate o prendere il controllo dei componenti interni importanti.
È necessario essere preparati utilizzando una suite di tecniche anti-hacking appropriate per contrastare questi tipi di attacchi.
I sistemi spesso pensati come nascosti all’interno di un sistema industriale, automotive, di telecomunicazione o di rete, come se fossero nascosti al radar della maggior parte degli hacker, ha lasciato storicamente i dispositivi Embedded aperti a una nuova ondata di attacchi da parte di hacker che cercano nuove vie di intrusione come punto di accesso per acquisire ulteriori dati riservati e preziose informazioni.
Fortunatamente anche le tecniche di difesa si sono evolute nel tempo e oggi ad esempio ci sono vari modi per la protezione dell’hardware da manomissioni e tentativi di decodificare il progetto.
La protezione contro le manomissioni può coinvolgere sistemi complessi per coprire il progetto con un involucro resistente alle manomissioni, ma questi approcci sono forse troppo costosi e richiedono troppo spazio per la maggior parte dei progetti.
Un’alternativa consiste nell’aggiungere alcuni circuiti di rilevamento manomissione alla scheda in modo che l’hardware possa determinare quando vengono effettuate le rilevazioni esterne e le modifiche alla scheda.
I controlli si devono effettuare sia a livello fisico che logico, partendo dalla fase di concept e design fino alla validazione finale.
Integrare la cyber security nel ciclo di sviluppo di un prodotto automotive è essenziale per la difesa da possibili attacchi futuri. Anche la prossima Regulation UE sulla cyber security del settore Automotive (UNECE) richiederà la certificazione di un CSMS (Cybersecurity Management System) che indica un approccio sistematico basato sul rischio per tutti i processi organizzativi, tecnici e di governance volti a risolvere le minacce informatiche ai veicoli e proteggerli dai cyber-attacchi.
