Gli elementi Sicuri basati su hardware con provisioning preeseguito consentono di proteggere distribuzioni IoT di qualsiasi dimensione

Di Xavier Bignalet, Product Marketing Manager, Secure Product Group at Microchip Technology

Il panorama delle minacce alla sicurezza informatica si è notevolmente ampliato in tutti i segmenti di mercato con l’arrivo dell’Internet of Things (IoT). Ogni dispositivo IoT aggiunto alla rete introduce contemporaneamente anche un nuovo punto di attacco, non solo sui dispositivi stessi ma sui sistemi, sia locali che in Cloud, che vengono utilizzati per gestirli.

Gli attacchi possono avere gravi conseguenze perché il riuscire penetrare con successo in un dispositivo IoT consente di caricare nuovo firmware in esso, in modo che possa essere utilizzato in modo dannoso. Sebbene alcuni attacchi possano semplicemente interrompere il funzionamento del dispositivo in modo che possa essere utilizzato in una nuova modalità, come un nodo in una botnet utilizzato per eseguire attacchi di tipo denial-of-service, altri possono utilizzare il sistema compromesso per invadere la rete di un operatore di servizi.

Il panorama delle minacce alla sicurezza informatica si è notevolmente ampliato può avere gravi conseguenze perché l’atto di penetrare con successo in un dispositivo IoT consente di caricare nuovo firmware in esso in modo che possa essere utilizzato in modo dannoso. Sebbene alcuni attacchi possano semplicemente interrompere il funzionamento del dispositivo in modo che possa essere utilizzato in un modo nuovo, come un nodo in una botnet utilizzato per eseguire attacchi di negazione del servizio, altri possono utilizzare il sistema compromesso per invadere la rete di un operatore di servizi.

La violazione è facilitata nel caso siano in uso credenziali esclusivamente software, come le password. Utilizzando queste credenziali di base, un hacker che avesse successo nel compromette un dispositivo sarà in grado di utilizzare tali informazioni per accedere a servizi remoti e, potenzialmente, eseguire attacchi su di essi più facilmente. La sicurezza rafforzata da un hardware, unita all’identità sicura, fornisce un meccanismo più solido per impedire lo sfruttamento dei dispositivi e per rendere molto meno probabile il successo di quegli attacchi iniziali.

Con la sicurezza offerta dall’hardware, un’identità valida e codici di accesso per il dispositivo possono essere creati solo durante la produzione attraverso l’uso di meccanismi di public key infrastructure (PKI). In una PKI, ogni dispositivo ha una chiave privata univoca che è correlata matematicamente ad un certificato digitale valido noto che è tenuto al sicuro dal produttore. Questa chiave privata viene utilizzata per firmare una challenge per identificare il dispositivo in modo univoco per qualsiasi server che abbia accesso alla chiave pubblica corrispondente. La chiave pubblica è un set di informazioni visibili pubblicamente e che quindi non presenta rischio alcuno se tale chiave viene distribuita a utenti non autorizzati. Nel contesto di un dispositivo IoT, l’identità del dispositivo è dimostrata attraverso l’uso di una chiave privata. La chiave pubblica associata viene utilizzata nei protocolli che determinano la validità dell’identità dichiarata. Questa identità può essere utilizzata per tutto il ciclo di vita del dispositivo per autenticare eventuali aggiornamenti del firmware che potranno essere applicati, nonché l’identità del dispositivo quando si accede ai servizi remoti.

Dato il loro ruolo fondamentale in qualsiasi sistema crittografico, le chiavi private del dispositivo non devono essere vulnerabili né da attacchi fisici né verso la loro estrazione remota. Idealmente, le chiavi crittografiche sono conservate in un elemento sicuro che impone un confine isolato e sicuro in modo che le chiavi non vengano mai esposte. Questo non è un compito banale. L’intera progettazione richiede protezione da manomissioni e la protezione contro gli attacchi di intercettazione come side channel analysis. Il proteggere adeguatamente la chiave in questa modalità richiede un alto livello di competenza in materia di sicurezza. Inoltre, ciò estende i tempi di sviluppo della soluzione IoT.  Ma non è una responsabilità che si può evitare, proteggere la chiave è una pratica di sicurezza di vitale importanza ed è quindi da implementare. Fortunatamente, per i produttori sono disponibili elementi sicuri, come la tecnologia Microchip ATECC608, con i livelli di protezione richiesti.

Sebbene tali componenti esistano, permangono problemi con l’uso della gestione delle identità offerta dall’hardware. La necessità di applicare l’identità sicura in modo tale che non possa essere compromessa da un utente malintenzionato dotato di risorse non è stata facile da raggiungere per la maggior parte dei produttori, integratori di sistemi e fornitori di servizi. L’approccio convenzionale consiste nel configurare un elemento sicuro nell’hardware durante la produzione con le chiavi private appropriate. Tuttavia, le considerazioni sulla logistica della supply-chain hanno generalmente limitato l’uso di questo approccio alle grandi implementazioni. Fornire a ciascun dispositivo un’identità sicura significa personalizzare il processo di produzione: un’impresa costosa a meno che la personalizzazione non venga ammortizzata su un volume di unità elevato in modo che il costo per dispositivo ne sia solo minimamente influenzato.

Tuttavia, ora è possibile fornire la configurazione degli elementi di sicurezza richiesta in modo conveniente anche con un MOQ (minimum order quantity) di sole dieci unità, preconfigurandoli ed eseguendo il pre-provisioning per i dispositivi IoT.

Con questo modello, che è supportato dalla Trust Platform di Microchip, anche una semplice telecamera di sorveglianza IoT di base, un gateway, un condizionatore d’aria o un’applicazione simile possono essere protetti da certificati device-generic pregenerati che vengono bloccati all’interno di un elemento sicuro per l’autenticazione Cloud autonoma all’on-boarding. Il costo totale per dispositivo, per la fornitura di questo archivio di chiavi sicure basato su hardware con un certificato generico è inferiore a quello che può offrire un qualsiasi fornitore di servizi PKI di terze parti e autorità di certificazione, e l’approccio riduce significativamente la complessità e il time to market.

Implementazione di una soluzione

Dato che anche per volumi medio-bassi ora si ha accesso ad un modo conveniente per inserire la gestione sicura dell’identità nei propri dispositivi, il passaggio successivo consiste nel configurare l’elemento di sicurezza nel modo più appropriato per i loro casi d’uso. Questo perché il dispositivo deve essere sottoposto a provisioning con le credenziali e altre risorse crittografiche utilizzate per il modello di autenticazione specificato. Oltre all’identità del dispositivo principale, potrebbero essere presenti chiavi private ed elementi segreti aggiuntivi che devono essere inseriti nell’elemento hardware. Ad esempio, quelli non derivati dalla root key potrebbero essere necessari per autenticare accessori, periferiche, contenuti di terze parti e host remoti in modo che le loro credenziali possano essere gestite separatamente.

Il principio che sta alla base dell’elemento sicuro è che controlla l’accesso alle risorse vitali e agisce come un controllo contro attività non autorizzate, per esempio i tentativi di sostituire il firmware approvato dal produttore con codice dannoso, e che potrebbero tentare di utilizzare le informazioni segrete che il dispositivo detiene per eseguire ulteriori attacchi.

Un requisito fondamentale per garantire che gli aggressori non possano penetrare e riprogrammare un dispositivo è l’utilizzo di una strategia di secure-boot che, a sua volta, sia protetta da un elemento sicuro. Il secure-boot garantisce che il dispositivo IoT possa eseguire solo codice autorizzato. In condizioni di secure-boot, il dispositivo può caricare solo blocchi di codice con hash e firma da una chiave privata di proprietà del produttore.

Quando il microcontroller deve caricare il codice dalla boot-ROM, il microcontroller richiede la verifica dalla truly immutable public key detenuta dall’elemento protetto. Solo se quella verifica viene superata, l’MCU tenta di caricare il codice. Se il dispositivo incontra un blocco di codice firmato in modo errato, interrompe il caricamento del software compromesso e tenta di ripristinare uno stato programmato in fabbrica o, se non è possibile, di disattivare. Finché il codice del MCU bootloader non può essere modificato, poichè inserito nella ROM o nella flash protetta, la funzione di controllo stessa non può essere aggirata.

Con le procedure di core security in atto, è possibile aggiungere facilmente altri casi d’uso, come il supporto per l’autenticazione basata su certificati sui server remoti, un ingrediente chiave questo per i dispositivi IoT. Questa autenticazione remota utilizza protocolli standard come Transport Layer Security (TLS) per la comunicazione crittografata e X.509, utilizzato per gestire i certificati digitali che dimostrano che un dispositivo o un servizio è autentico.

Con lo standard X.509, tutti i certificati digitali fanno riferimento a uno principale OEM tramite una gerarchia di certificati figlio. Le informazioni trasportate dai certificati forniscono i mezzi per identificare il legittimo proprietario di ciascun certificato e da questo ottenere la chiave pubblica del certificato più in alto nella gerarchia in modo che la firma del certificato dipendente possa essere convalidata.

Quando un dispositivo IoT adeguatamente protetto comunica con un server remoto, utilizza le informazioni nei certificati in suo possesso per dimostrare di essere un utente valido del servizio. Al contrario, il server utilizza il proprio set di certificati per confermare al dispositivo che anch’esso è autentico. Finché il dispositivo contiene i certificati richiesti, l’autenticazione bidirezionale può essere garantita.

Nel contesto dell’IoT, i certificati digitali possono essere utilizzati per semplificare il processo di onboarding dei dispositivi quando vengono alimentati per la prima volta e tentano di connettersi al loro fornitore di servizi su Internet. Ciò si ottiene inoltrando i certificati necessari ai server quando l’elemento protetto viene programmato per la prima volta e archiviando i certificati che il dispositivo utilizzerà per autenticare quei server nell’elemento insieme alla chiave privata principale del dispositivo. Come esempio di questo approccio, Microchip ha lavorato con le funzionalità di Amazon Web Services (AWS) per consentire a qualsiasi prodotto creato utilizzando la Trust Platform di essere integrato in questo modo nei servizi AWS IoT. Il supporto per protocolli standard e sistemi di certificazione si traduce nel fatto che le stesse tecniche possono essere utilizzate facilmente con altri servizi cloud, come Microsoft Azure, nonché infrastrutture cloud private e ibride.

Un altro caso d’uso chiave per l’IoT è quello degli aggiornamenti over-the-air (OTA) del firmware per i dispositivi IoT. Questi aggiornamenti offrono la possibilità di correggere le vulnerabilità della sicurezza, senza rischiare che i dispositivi vengano compromessi dal processo stesso di aggiornamento. Gli aggiornamenti firmati digitalmente inviati OTA possono essere controllati in modo simile al codice verificato durante il boot protetto per verificarne l’autenticità prima che l’aggiornamento possa essere applicato. Una volta posizionato, il codice memorizzato dovrà anche superare i test di avvio sicuro al riavvio del dispositivo.

Ulteriori casi d’uso includono la protezione IP, per verificare la validità di ricambi e accessori opzionali, nonché la protezione dei dati dell’utente, la rotazione delle chiavi e l’autenticazione LoRaWAN™. Alcuni produttori potrebbero aver bisogno di opzioni personalizzabili che vadano oltre questi servizi principali. Altri potrebbero aver bisogno di un approccio alla sicurezza con un sovraccarico inferiore laddove forniscono dispositivi IoT con risorse limitate. L’autorizzazione core di Google Cloud IoT, ad esempio, non richiede la creazione di certificati digitali completi. Il servizio utilizza “JSON web tokens” (JWT), che derivano dalla chiave privata principale contenuta all’interno dell’ATECC608B che sostituisce un accesso convenzionale basato su password.

La flessibilità di gestire questi vari casi d’uso con bassi costi di installazione è resa possibile dalla Trust Platform di Microchip e dal suo supporto per una serie di diversi modelli di coinvolgimento. Il primo modello offre ai clienti un percorso semplice per ottenere dispositivi con credenziali sicure, utilizzando un flusso predefinito. In questo modello, la chiave privata dell’elemento sicuro e i certificati generici vengono generati durante la produzione all’interno di una struttura Microchip sicura. La chiave e i certificati rimangono non esposti durante il processo di provisioning sicuro, bloccati all’interno dell’elemento protetto dove rimangono al sicuro durante la spedizione. Le relative credenziali pubbliche possono essere inoltrate ai servizi di onboarding nel cloud o ad un Join Server di rete LoRaWAN.

Poiché molti produttori desiderano la possibilità di avere un livello più elevato di flessibilità di autenticazione e avere la possibilità di creare e iniettare certificati in base alla propria catena di autenticazione, un secondo modello di coinvolgimento offre una serie di casi d’uso preconfigurati che forniscono la possibilità di eseguire queste azioni automaticamente. Modifiche più estese sono possibili nel terzo modello di coinvolgimento. In questo approccio, mostrato nella Figura 2, il cliente inizia con un ordine per un secure element vuoto e quindi utilizza gli strumenti forniti da Microchip che costruiscono le fasi di provisioning, incluso l’XML che viene utilizzato per controllare la consegna di chiavi private e certificati all’elemento sicuro, nelle strutture sicure di Microchip.

In conclusione, grazie ai più recenti sviluppi negli strumenti e nei componenti online per la sicurezza basata su hardware, le aziende con progetti di qualsiasi dimensione possono ora implementare un elemento sicuro con i loro dispositivi IoT. Le barriere che rendevano difficile e costosa la configurazione e il provisioning degli elementi protetti sono state rimosse. Il processo ha portato all’integrazione di una supply chain sicura, che consente di estendere i modelli di sicurezza delle migliori pratiche in tutto l’ecosistema IoT.