Non ci sono prodotti a carrello.
La sicurezza è ora un requisito fondamentale per i sistemi embedded. Il desiderio di connettere dispositivi a Internet per semplificare il controllo e l’estrazione di dati in tempo reale dai loro sensori comporta un alto rischio di hackeraggio. La pirateria informatica non mette a rischio solo i singoli dispositivi ma intere reti.
La direzione è chiara: i fornitori non possono arrivare sul mercato senza un prodotto IoT sicuro fin dalla progettazione. Il problema per i produttori di dispositivi che cercano di sfruttare la potenza dell’IoT per i loro sistemi è la complessità dell’implementazione di meccanismi di sicurezza efficaci e pertinenti. È facile vedere in questo la necessità fondamentale di autenticazione e crittografia per quei sistemi. Ma l’implementazione è stata molto più difficile da raggiungere.
Esistono più componenti, sia software che hardware, necessari per creare una base sicura per un sistema embedded. Una debolezza in ognuna di esse può facilmente portare ad un hardware compromesso e caricato con malware che viene utilizzato per attaccare la rete di un operatore o per trasferire dati sensibili ai criminali informatici. Allo stesso tempo, molti team di progettazione stanno affrontando per la prima volta le difficoltà di sviluppo rappresentate dai problemi di sicurezza.
Uno dei requisiti fondamentali per una efficace sicurezza è che ogni dispositivo distribuito deve avere una propria identità univoca. Un difetto comune sfruttato dagli hacker è che i dispositivi vengono forniti da parte di tecnici dell’assistenza e della manutenzione di una password o un login comuni per il loro utilizzo. I dettagli di questo login sono spesso facili da indovinare e, anche se non lo sono, di solito sono ugualmente e facilmente ottenibili da un hacker. Ottenuti i dati di login è quindi possibile accedere non solo a un solo dispositivo ma all’intera flotta.
I criminali informatici sono stati in grado di creare botnet (eserciti di computer identici utilizzati negli attacchi di tipo denial of service) mediante l’uso di semplici script automatici. Gli script hanno identificato e effettuato l’accesso in ciascun dispositivo di un determinato tipo aventi una connessione Internet.
Con un’identità unica, invece, è possibile assegnare a ciascun sistema le proprie credenziali di sicurezza e ridurre notevolmente la possibilità di offrire agli hacker un modo semplice per costruire botnet. Solo se un utente autorizzato ha le credenziali giuste per un determinato dispositivo potrà effettuare l’accesso. Tuttavia, questo livello di protezione aumentato ha conseguenze di ramificazione nei processi di progettazione, sviluppo e gestione dei servizi.
L’implementazione di una sicurezza efficace tale da facilitare piuttosto che ostacolare lo sviluppo implica scelte accurate. La prima scelta di base è l’hardware da utilizzare per proteggere l’integrità del dispositivo di destinazione. Questa base garantisce l’impossibilità non solo di accedere al core firmware del dispositivo senza autorizzazione, ma di garantire che le sue funzioni non possano essere sovvertite e che il dispositivo venga utilizzato per attaccare la rete. Ad esempio, se un hacker ha ottenuto le credenziali di accesso per un dispositivo, deve essere impossibile convertirne un altro affinché accetti quelle stesse credenziali al fine di formare, ad esempio, una botnet. Di conseguenza, identità e integrità sono strettamente legate. La public-key infrastructure (PKI) fornisce un mezzo per stabilire e provare un’identità affidabile univoca non solo all’interno del dispositivo stesso ma attraverso una rete. PKI si basa sul concetto di crittografia asimmetrica, una tecnica che collega matematicamente due chiavi numeriche. Una è una chiave pubblica, che viene generalmente utilizzata per verificare i messaggi. Come suggerisce il nome, questa chiave può essere ampiamente distribuita senza compromettere la sicurezza. La stessa fornisce a tutti un modo semplice di inviare messaggi sicuri a un dispositivo, purché sappia quale chiave pubblica usare. Il dispositivo necessita della chiave privata che consente di firmare i messaggi inviati che verranno verificati dalla chiave pubblica corrispondente. Dal funzionamento di base del PKI, è possibile costruire modelli di autenticazione più strutturati, come i certificati digitali che dimostrano l’identità di un dispositivo. Per creare un certificato digitale, un dispositivo firma un messaggio o challenge creando una firma mediante la chiave privata. La chiave pubblica corrispondente viene utilizzata dal destinatario per determinare la validità della firma.
La chiave privata richiede chiaramente una forte protezione. Non è sufficiente programmare una chiave nella memoria non volatile su un dispositivo prima che venga distribuito in quanto quella è facilmente accessibile. La chiave privata non deve mai essere divulgata. Se divulgata, gli hacker potrebbero costruire i propri dispositivi clone. Questi sono quindi in grado di impersonare e quindi fingersi il dispositivo autentico e quindi compromettere la sicurezza delle applicazioni di rete che dipendono dai dati inviati dal dispositivo.
Un problema per una progettazione convenzionale basata su microcontroller è che qualsiasi software crittografico in esecuzione sul core del processore deve accedere alla chiave privata per eseguire i calcoli necessari presupponendo che la chiave si trovi nel controller. Il requisito hardware di base è quindi un elemento sicuro utilizzato per racchiudere quelle operazioni crittografiche in un pezzo indipendente di hardware protetto insieme ad un archivio sicuro per le chiavi private. Poiché le chiavi e funzioni crittografiche sono memorizzate insieme all’interno dello stesso confine fisico sicuro, non è necessario inviare dati sensibili sul bus interno del sistema.
Figura 1 – Un elemento sicuro è come un caveau che protegge dati segreti, ed è un dispositivo complementare del microcontroller.
Al contrario, quando il sistema deve comunicare in modo sicuro o dimostrare la sua identità, fa appello all’elemento sicuro per rispondere a una random challenge. La risposta a questa challenge è un codice derivato aritmeticamente dalla parte casuale della challenge stessa e dalla relativa chiave privata memorizzata all’interno dell’elemento sicuro. In altre parole, la random challenge è firmata dalla chiave privata. In questo modo, l’elemento sicuro può dimostrare che detiene l’appropriato dato segreto ma non ha bisogno di rivelare quella chiave privata sensibile.
[boris]
L’elemento sicuro può anche proteggere il dispositivo da codice contraffatto che un utente malintenzionato potrebbe tentare di eseguire e utilizzare per compromettere il sistema. Il meccanismo di protezione necessario per impedire ciò è una verifica del codice, anche noto come secured boot o runtime code verification. In questo caso, la challenge inviata all’elemento sicuro è una firma ottenuta dall’immagine di boot firmata memorizzata sul dispositivo. Eventuali aggiornamenti al codice devono essere firmati dall’OEM utilizzando la sua chiave privata. Attraverso procedure di secured boot e runtime verification, il sistema può supportare gli aggiornamenti over-the-air forniti dal produttore senza il rischio di eseguire aggiornamenti forniti da una terza parte che usi un attacco man-in-the-middle o un approccio simile.
Questa chiave utilizzata per verificare la firma del codice è una credenziale sensibile che dovrebbe e quindi deve risiedere in una zona di memoria protetta e immutabile. Se la chiave può essere alterata, il sistema semplicemente non funzionerebbe. Se la coppia di chiavi può essere modificata, il codice può essere allo stesso modo manomesso.
Un esempio di protezione efficace può essere trovato nella tecnologia Microchip ATECC608A. Questo è un elemento sicuro che può essere utilizzato in qualsiasi sistema basato su microcontroller grazie all’utilizzo di comunicazione I²C standard o Single-wire. Il dispositivo combina una memoria non volatile con diversi acceleratori crittografici progettati per supportare algoritmi basati su algoritmi a curva ellittica, ad esempio in un silicio sicuro. Il dispositivo non rivela mai le chiavi private attraverso il collegamento di comunicazione e include una serie di funzionalità hardware anti-manomissione che rendono praticamente impossibile scoprire i suoi contenuti. Sebbene un elemento sicuro accoppiato a un microcontroller fornisca una base efficace per la creazione di dispositivi embedded connessi in grado di garantire un’elevata sicurezza, questa combinazione è solo una parte della soluzione complessiva. Esistono molti casi d’uso che implicano la costruzione di protocolli complessi nel software embedded al di fuori delle funzioni principali fornite da un elemento sicuro. Ad esempio, oltre al secure boot, un dispositivo IoT dovrà essere in grado di comunicare con host remoti utilizzando protocolli crittografati come TLS e generare certificati su richiesta che dimostrino che il dispositivo non è stato compromesso quando desidera connettersi ad un nuovo servizio. Quando il produttore o l’operatore del servizio desidera inviare un aggiornamento del codice, sarà necessario verificare la firma del firmware prima di aggiornare la memoria flash e riavviare il sistema. Un ulteriore requisito potrebbe essere la capacità di rilevare accessori di sistema o cartucce di materiali di consumo e determinare se sono autentici. Questa funzione può essere eseguita utilizzando protocolli simili a quelli utilizzati per creare l’esempio di verifica del codice, ma con alcune differenze chiave. Ad esempio, ogni periferica potrebbe avere il proprio elemento di sicurezza utilizzato per verificare che il sistema host a cui è collegato sia esso stesso autentico.
Sebbene i principi alla base di ciascuno dei protocolli che implementano queste funzioni siano ragionevolmente semplici, l’implementazione può essere difficile perché la capacità di eseguire il debug dei problemi è limitata dalla necessità per il sistema di obbedire ai protocolli sicuri.
Un presupposto comune durante lo sviluppo è che premendo il pulsante di ripristino o svuotando il contenuto della memoria si consentirà agli ingegneri di accedere a un dispositivo che non risponde. Le modalità di debug generalmente offrono allo sviluppatore un accesso privilegiato al sistema. Ma quando vengono introdotti i livelli più elevati di sicurezza richiesti per i sistemi che saranno connessi a Internet, alcuni di questi presupposti non si applicano più. La mancata implementazione nel modo corretto del software può portare il dispositivo prototipo a diventare irraggiungibile. Le parti più problematiche dello sviluppo di sistemi sicuri risiedono nel debug dei protocolli di base. Ad esempio, è facile introdurre bug nel codice utilizzato per elaborare passcode o certificati di sicurezza che possano impedire al dispositivo di rispondere a richieste valide. Se fosse possibile ripristinare il dispositivo per ottenere l’accesso, la struttura fornirebbe agli hacker una backdoor facilmente sfruttabile nel sistema. Di conseguenza, lo sviluppo incentrato sulla sicurezza introduce ostacoli nel processo di sviluppo. Sono difficili da gestire se il team non ha esperienza delle tecniche richieste.
Tuttavia, uno dei vantaggi dei sistemi basati su un’infrastruttura PKI è che le applicazioni possono essere costruite su core protocol e casi d’uso, come la verifica degli eseguibili firmati e la creazione di certificati, che possono essere riutilizzati in molti progetti. Tali intuizioni hanno contribuito a creare Trust Platform di Microchip. Questa piattaforma offre una suite di strumenti di configurazione, codice sorgente, strumenti hardware e software progettati per rendere facile ai clienti l’implementazione di una vasta gamma di casi d’uso in un flusso di lavoro che guida l’utente dall’ideazione fino all’implementazione e basato su hardware che include un elemento sicuro come l’ATECC608A.
Trust Platform è suddivisa in tre offerte principali. La più semplice è Trust&GO , che fornisce un set fisso di funzioni, come fornire a un dispositivo l’accesso ai servizi cloud ospitati su AWS, Google Cloud, Microsoft Azure o altro cloud privato. Un’altra configurazione supportata da Trust&GO è una completa soluzione di autenticazione sicura per i dispositivi che devono connettersi ad una rete wireless LoRaWAN .
TrustFLEX offre un ulteriore livello di personalizzazione con supporto per una vasta gamma di funzionamenti, dall’avvio sicuro alla generazione di certificati. La terza opzione, TrustCUSTOM, offre ai clienti la possibilità di ottimizzare la creazione e l’integrazione di elementi sicuri nel modello di sicurezza da loro desiderato.
Figura 2 – Flusso di sviluppo con Trust Platform di Microchip.
Un importante elemento di Trust Platform che facilita l’accesso alla sicurezza, rispetto ad altre offerte, è il modo in cui il servizio di provisioning delle chiavi sicure può essere implementato su applicazioni in piccole quantità. Con le supply chain di elementi sicuri concorrenti, la quantità minima dell’ordine può essere di 100.000 unità a causa delle spese generali legate alla configurazione dei certificati e delle chiavi iniziali che devono essere programmati nell’hardware nella linea di produzione sicura del fornitore. Con Trust&GO, i clienti possono acquistare elementi sicuri a partire da 10 unità per ordine e avere tutto il supporto dell’infrastruttura Trust Platform, incluso il provisioning. Per TrustFLEX, la quantità minima dell’ordine è di appena 2.000 unità, incluso il provisioning, ma fornisce comunque all’utente il maggior livello di controllo su certificati, chiavi e applicazioni che ci si potrebbe aspettare da soluzioni personalizzate di supply-chain sicure.
Nella Trust Platform di Microchip, i clienti hanno accesso a meccanismi di sicurezza altamente personalizzabili con un rischio di sviluppo e implementazione molto inferiore rispetto alle soluzioni esistenti. La combinazione di strumenti, codice sorgente e infrastruttura di fornitura fornisce agli sviluppatori di sistemi embedded un percorso per ottenere l’accesso a un sistema completo con provisioning sicuro, dall’ideazione fino alla distribuzione, riducendo il processo di sviluppo da mesi a giorni.
Figura 3 – Flusso ordini/consegne della Trust Platform di Microchip.
[/boris]
A cura di Nicolas Demoulin, EMEA Marketing Manager – Secure Products Group, Microchip Technology Inc.
