By Nicolas Demoulin, EMEA marketing manager del secure products group di Microchip Technology
Una legge approvata alla fine di settembre 2018 dal senato californiano che rappresenta uno dei tentativi dei governi di tutto il mondo di affrontare il problema della sicurezza dei dispositivi connessi è un'indicazione del modo in cui la società sta lentamente facendo i conti con una realtà di hackeraggio diffuso e di criminalità informatica. Ma passi obbligati come questi non abbatteranno il problema principale. Gli attacchi informatici stanno diventando più sofisticati e spesso pensati per sfruttare più dispositivi contemporaneamente in modo da poter essere
utilizzati come punti di accesso in attacchi DDoS (Distributed Denial of Service) o reclutati in botnet su larga scala per eseguire altre operazioni di criminalità informatica.
La capacità degli hacker di automatizzare gli attacchi per penetrare in più copie nello stesso dispositivo è spesso il risultato di una scarsa architettura di sicurezza e di una debole protezione delle credenziali di sicurezza. Molto spesso, il motivo per cui gli hacker trovano i sistemi così vulnerabili è perché i progettisti di prodotto hanno favorito la facilità di installazione anziché cercare di raggiungere un livello di sicurezza accettabile. Le password deboli, a volte semplici, come quattro zero di fila sono una scorciatoia facile, rendono facile agli utenti eseguire la configurazione iniziale. Persino le password complesse, se condivise tra dispositivi, minacciano l'intera popolazione di dispositivi installati. Una volta che gli hacker sono in grado di decifrare la password analizzando una singola unità, magari utilizzando sofisticati attacchi sul canale laterale, possono applicare la stessa password a qualsiasi unità di destinazione.
Nei dispositivi per utenti finali come i gateway domestici, una soluzione adottata dai produttori e che sarebbe accettabile ai sensi della legge sancita dalla California nell’atto “Information Privacy: Connected Devices”, legge sulla protezione delle informazioni nello specifico dei dispositivi connessi, consiste nel programmare una password univoca nel dispositivo e posizionare un adesivo sull'unità per informare il cliente o l'installatore. Tuttavia, questa non è una soluzione che si adatta bene nell'era dell'internet of things (IoT). Molte applicazioni richiedono commissioning e provisioning automatizzati. Anche quando è disponibile un installatore ci sono problemi di progettazione se viene utilizzata una protezione basata su password. Non solo la mancanza di un'interfaccia utente adatta all'inserimento delle password rende impraticabile questo approccio tradizionale alla protezione di un dispositivo IoT, ma attaccare una password visibile su qualsiasi dispositivo rischia di esporla ad una qualsiasi persona non autorizzata che abbia accesso all'unità.
Sebbene le singole password possano limitare l'estensione di un singolo attacco, sussiste un rischio elevato per la rete di dispositivi a cui questo accede e che viene riprogrammata in modo dannoso può quindi sfruttare altri punti deboli. Ciò che è richiesto è un modo automatizzato più semplice per distribuire credenziali sicure sul dispositivo. Dato che un dispositivo IoT ha bisogno di collegarsi ad un server per eseguire il suo set completo di funzioni, per un dispositivo è un semplice meccanismo connettersi ad una rete utilizzando un set standard di credenziali e un codice di identità digitale univoco utilizzato per identificare ogni singola unità. Una volta riconosciuto il codice di identità digitale del dispositivo, il server può impostare un canale crittografato e inoltrare le informazioni necessarie per consentire al dispositivo di accedere a un server sicuro e riportarne i dati.
C'è un grave difetto nella progettazione di questo semplice meccanismo. Tutto ciò che utenti malintenzionati devono fare è utilizzare tentativi ed errori per trovare codici di identità digitali, inutilizzati ma validi, o utilizzare schemi evidenti nel modo in cui i codici sembrano essere generati e quindi falsificarli utilizzando i propri strumenti. In alternativa, possono ottenere un elenco di codici di identità digitali validi attraverso tecniche di social engineering o intercettazione presso la fabbrica in cui i dispositivi sono programmati e utilizzarli per accedere alla rete. Ottenuto l’accesso ai gateway wireless, gli hacker possono anche intercettare le comunicazioni usando gli attacchi man-in-the-middle. Con i propri dispositivi dannosi installati dopo la messa in servizio, gli aggressori possono tentare di hackerare altre parti della rete o interrompere il servizio principale stesso. Ciò che è richiesto è un mezzo per identificare i dispositivi in modo affidabile utilizzando credenziali che non possono essere ottenute con altri mezzi. Ciò può essere ottenuto solo utilizzando adeguate pratiche di sicurezza e tenendo conto dell'intera catena di approvvigionamento.
Il primo problema è identificare se un dispositivo IoT è legittimo. Questo è un attributo che può essere ottenuto usando le chiavi, sia che si faccia riferimento alla tecnologia PKI (Public Key Infrastructure) e ai certificati digitali che contengono la chiave pubblica, sia che si tratti di una semplice coppia di chiavi pubblica/privata senza coinvolgimento del certificato. Sotto una PKI, ogni dispositivo ha una chiave privata univoca collegata matematicamente ad un certificato digitale valido noto che è tenuto in sicurezza dal produttore. Questa chiave privata viene utilizzata per creare una challenge di identificazione del dispositivo in modo univoco per qualsiasi server che abbia accesso alla chiave pubblica corrispondente. La chiave pubblica è un insieme di informazioni pubblicamente visibile e pertanto non presenta rischi se la chiave viene distribuita a utenti non autorizzati. I certificati digitali possono essere gestiti utilizzando protocolli standard come X.509. In base a questo standard, tutti i certificati digitali fanno riferimento a un certificato OEM principale attraverso una gerarchia di certificati figlio. Tramite il nome dell'emittente su ciascun certificato figlio, un cliente può ottenere la chiave pubblica del certificato più in alto nella gerarchia per verificare che la firma del certificato dipendente sia legittima.
Una gerarchia a tre livelli di certificati digitali è una scelta adatta per molte applicazioni IoT. In questo, il certificato OEM è detenuto dal produttore del prodotto finale. Ogni singolo cliente userebbe quindi un certificato a livello di firmatario derivato da quel certificato OEM per generare certificati a livello di dispositivo. Una volta che ogni dispositivo ha il proprio certificato, è possibile verificare le informazioni in esso contenute per assicurarsi che si tratti di un vero derivato del certificato OEM originale. X.509 fornisce un meccanismo per consentire di identificare i
dispositivi che siano legittimi. E non risente di sistemi in chiaro come i numeri di serie. Ma tutto ciò non è di per sé sufficiente a garantire che i certificati di livello intermedio o di dispositivo e la chiave privata associata non possano essere compromessi ad un certo punto della supply chain. In molti scenari della supply chain, i dati del certificato devono essere programmati in ciascun
dispositivo durante o dopo l'assemblaggio a livello di scheda. Un produttore potrebbe utilizzare un programmatore flash seriale per caricare i certificati e le chiavi private associate nella memoria non volatile su ciascuna unità della linea di produzione. Un cliente potrebbe utilizzare una porta seriale accessibile dall'esterno per caricare dispositivi vuoti con le chiavi e i certificati
appropriati al momento della consegna. Ma con questi approcci ci sono grandi rischi che sia possibile accedere alle chiavi private usando attacchi basati sulla rete o social engineering.
Un ulteriore problema è quello dell'intercettazione post vendita. Un hacker con accesso fisico o di rete potrebbe essere in grado di estrarre in seguito le chiavi private o corrompere i
dispositivi se la memoria non volatile non fosse protetta. Un requisito chiave per garantire che questi errori siano limitati è avere una root of trust imposta da hardware. La root of trust garantisce che non ci sia alcun meccanismo noto attraverso il quale le chiavi private o altre credenziali critiche possano trapelare attraverso il sistema embedded. Ciò implica sia la protezione
antimanomissione, sia la protezione dagli attacchi dei canali laterali, che il supporto per la validazione del firmware. Il secure boot garantisce che il dispositivo IoT possa eseguire solo codice
autorizzato. Qualsiasi tentativo di eseguire codice caricato da un hacker che possa agire in modo dannoso viene bloccato a livello hardware. Durante il funzionamento, il dispositivo può essere avviato solo da blocchi hash di codice e firmati con una chiave privata in possesso del OEM. Se il dispositivo rileva un blocco di codice firmato in modo errato, interrompe il caricamento del software compromesso e tenta di ripristinare lo stato programmazione di fabbrica o, se impossibile, di disattivarlo.
La validazione del firmware è anche fondamentale per consentire gli aggiornamenti firmware over the air (FOTA) ai dispositivi IoT senza rischiare che vengano compromessi. Gli aggiornamenti con firma digitale possono essere controllati in modo simile al codice di avvio per quanto riguarda l'autenticità prima che l'aggiornamento venga applicato. Una volta installato, il codice memorizzato all'interno dovrà superare test simili al secure-boot del firmware che sostituisce. Uno degli approcci per imporre secure boot e archiviazione delle chiavi consiste nell'incorporare tutti i blocchi richiesti in un microcontroller. Tuttavia, tali microcontroller sicuri non sono disponibili nelle molte varianti che i progettisti embedded potrebbero aspettarsi, il che può aumentare il costo del sistema. Un'alternativa scalabile è quella di utilizzare un elemento di sicurezza dedicato come l'ATECC608a. Questo dispositivo offre una combinazione di memorizzazione delle chiavi e funzioni di accelerazione crittografica che può integrare qualsiasi tipo di microcontroller e processore. Quando il microcontroller deve caricare il codice da bootROM, il microcontroller richiede la verifica dalla chiave pubblica realmente immutabile detenuta dal ATECC608a.
In modo complementare, le comunicazioni con un server remoto possono essere avviate utilizzando i protocolli PKI che derivano le chiavi effimere necessarie per le sessioni TLS dalla chiave privata memorizzata. La chiave privata stessa non lascia mai l'ATECC608a, poiché viene generata all'interno del dispositivo, dal dispositivo, all'interno delle Microchip secure factories
dotate di hardware secure modules (HSM). Inoltre, l'elemento secure utilizza una varietà di meccanismi per proteggere le chiavi dall'estrazione anche in caso di attacchi fisici come il decapping. Ad esempio, uno scudo metallico attivo sopra il dado disattiverà le funzioni del chip se un attaccante interferisce con lo scudo nel tentativo di sondare fisicamente il dispositivo. Le contromisure contro i canali di attacco laterale noti, così come gli attacchi glitch e l'analisi della potenza differenziale impediscono di ottenere i dati chiave utilizzando alcuni degli strumenti di test di penetrazione facilmente accessibili sul mercato. Contrariamente a molti processi produttivi, la progettazione e la fabbricazione dell'ATECC608a tengono conto della sfida della supply-chain che devono affrontare gli sviluppatori IoT e della complessità logistica della distribuzione delle chiavi. Invece di essere fornito vuoto per una successiva programmazione, l'elemento sicuro viene spedito dalle strutture sicure di Microchip al cliente o al produttore del contratto con le chiavi e certificati necessari già in atto. Ciò garantisce che le chiavi non vengano mai rivelate né esposte a terzi, in modo tale da ridurre significativamente al minimo il rischio di divulgazione.
Il collegamento finale nella supply chain avviene durante l'installazione e il provisioning. Il dispositivo deve essere sicuro di connettersi a un servizio legittimo nel cloud quando si
avvia e non falsificato da un attacco man-in-the-middle che potrebbe essere utilizzato per rivelare i segreti raccolti dal dispositivo stesso. Il dispositivo può garantire che stia parlando con un server autorizzato utilizzando le interazioni PKI. Per fornire al server un certificato o una chiave pubblica, Microchip invia al cliente certificati firmatari corrispondenti o chiavi pubbliche, che sono stati generati utilizzando la configurazione HSM prima della spedizione. Il cliente può scegliere di utilizzare questi certificati e chiavi pubbliche direttamente sul proprio server o di usarli su un fornitore third party di servizi cloud come Amazon Web Services (AWS) e Google Cloud Platform per gestire la chain of trust che garantisce che ogni dispositivo valido stia parlando direttamente con un server autorizzato. Una volta impostate le connessioni necessarie, il dispositivo IoT diventa un membro a pieno titolo della rete con un'identità unica, affidabile, protetta e gestita, utilizzando in modo sicuro protocolli crittografati come TLS.
Sebbene i certificati digitali e PKI forniscano l'accesso ad una vasta gamma di servizi Web, il sovraccarico sui nodi dei sensori più semplici può essere considerevole. I provider Cloud hanno sviluppato meccanismi che sfruttano l'infrastruttura PKI senza richiedere l'uso di certificati X.509 completi su ciascun dispositivo terminale. Google Cloud, ad esempio, lavorando in collaborazione con Microchip può offrire i vantaggi del provisioning e funzionamento sicuro anche sul più semplice dei dispositivi IoT. Google Cloud IoT core authorisation non richiede la creazione di certificati digitali completi. Al contrario, utilizza Web JSON Token (JWT) più semplici che vengono generati in base alla chiave privata contenuta nell'ATECC608a. Quando un dispositivo si connette per la prima volta alla rete, accede a Google Cloud all'indirizzo mqtt.google.com. Convenzionalmente, si tratta di un accesso basato su password. Tuttavia, Google Cloud accetta anche un JSON web token (JWT) al posto della password e utilizza questi dati sia per autorizzare un nuovo dispositivo sia per associarlo al suo gemello digitale nel cloud.
Il semplice protocollo consente l'implementazione su semplici microcontroller a 8 bit senza compromettere la sicurezza in alcun modo. La stretta collaborazione tra Microchip e Google garantisce la gestione sicura end-to-end delle credenziali del dispositivo. Attraverso servizi come Google Cloud Platform, gli utenti di ATECC608a ottengono l'accesso ai servizi cloud in modo sicuro praticamente da qualsiasi parte del mondo e senza l'onere di possedere server privati in modalità sicura. Il modello di end-to-end supply-chain offerto da Microchip per lavorare con servizi cloud come Google e AWS prevede che anche gli sviluppatori IoT non devono implementare le proprie tecnologie di provisioning, rischiando così di commettere errori che darebbero
agli hacker l'accesso ai loro dati principali. Il risultato è un approccio olistico alla sicurezza dei dispositivi connessi che è pronto per l'IoT presente e futuro.
