Utilizzare un chip crittografico per aggiungere un boot sicuro ai progetti di dispositivi IoT

Nonostante i loro migliori sforzi, gli sviluppatori possono lasciare i progetti di Internet delle cose (IoT) esposti ad attacchi proprio con il codice che dovrebbe mantenere la sicurezza. Gli hacker spesso attaccano anche progetti apparentemente sicuri sostituendo il firmware con codice compromesso. Metodi di boot sicuri possono mitigare questi rischi, ma un'implementazione corretta può essere difficile.

Gli sviluppatori hanno bisogno di metodi più semplici per implementare il boot sicuro come parte di una strategia globale per garantire la sicurezza dei dispositivi IoT.

Questo articolo esamina molto brevemente le aree di attacco più comuni nei progetti IoT e il ruolo dei metodi di sicurezza di base, tra cui l'archiviazione sicura delle chiavi, la crittografia e l'autenticazione. L'articolo presenta poi un chip di sicurezza che consente agli sviluppatori di aggiungere il boot sicuro tra le altre caratteristiche necessarie in una strategia globale atta a garantire la sicurezza dei dispositivi IoT.

Vulnerabilità dei dispositivi IoT

Per gli hacker, i dispositivi IoT possono fornire un numero illimitato di punti di accesso per disturbare i dispositivi stessi, le loro reti e persino le loro applicazioni finali. Anche se gli sviluppatori possono utilizzare una varietà di tecniche per rafforzare la sicurezza della rete e delle applicazioni, quella dei dispositivi IoT rimane una sfida a causa della limitatezza della memoria e delle risorse di elaborazione disponibili su di essi.

Pur utilizzando la crittografia per proteggere i dati, molti dispositivi sono progettati senza le capacità di autenticazione sicura necessarie per impedire agli hacker di intercettare le comunicazioni presentandosi come server di autorizzazione, gateway o altri dispositivi IoT. In alcuni casi, i dispositivi che utilizzano metodi di autenticazione validi ma deboli possono comunque essere vulnerabili a sofisticati exploit che intercettano e riutilizzano chiavi di sicurezza altrimenti valide, utilizzate in sessioni di comunicazione apparentemente private.

Aggiornamento del dispositivo IoT

Una debolezza della sicurezza ancora più fondamentale riguarda l'uso delle capacità di aggiornamento via etere (OTA) integrate in un numero crescente di dispositivi IoT. Gli aggiornamenti OTA costituiscono una caratteristica importante nel settore in rapida evoluzione dell'Internet delle cose. Gli sviluppatori possono rispondere alle mutevoli richieste dei clienti di nuove funzionalità (o correggere i bug) aggiornando il firmware dei dispositivi distribuiti. In un tipico processo di aggiornamento OTA, il dispositivo IoT cercherà periodicamente gli aggiornamenti, scaricherà il nuovo codice quando sarà disponibile ed eseguirà una serie di chiamate di sistema per completare il processo di aggiornamento.

Per un dispositivo IoT basato su MCU come SAM D21 di Microchip Technology, ad esempio, il firmware del dispositivo include il codice di aggiornamento OTA che scarica l'immagine da endpoint preimpostati, verifica che la procedura sia riuscita, quindi passa al nuovo set di firmware (Listato 1). In questo listato proveniente dal pacchetto Advanced Software Framework di Microchip, dopo l'inizializzazione (m2m_ota_init()) del firmware OTA, una routine di callback, OtaUpdateCb(), passa al nuovo set di firmware (m2m_ota_switch_firmware()) dopo che il firmware OTA ha scaricato la nuova immagine del codice, quindi un reset del sistema riavvia l'MCU nel firmware aggiornato.

Copy

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

if(u8OtaUpdateStatusType == DL_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

//Passa al firmware aggiornato

m2m_ota_switch_firmware();

}

}

else if(u8OtaUpdateStatusType == SW_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

M2M_INFO("OTA riuscito");

//Avviare l'aggiornamento del software host, quindi eseguire un reset del sistema (reinizializzare il driver).

}

}

}

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

case M2M_WIFI_REQ_DHCP_CONF:

{

//Dopo aver effettuato con successo il collegamento, avviare l'aggiornamento OTA

m2m_ota_start_update(OTA_URL);

}

break;

default:

break;

}

int main (void)

{

tstrWifiInitParam param;

tstr1xAuthCredentials gstrCred1x = AUTH_CREDENTIALS;

nm_bsp_init();

m2m_memset((uint8*)&param, 0, sizeof(param));

param.pfAppWifiCb = wifi_event_cb;

//Inizializzare il driver WINC

ret = m2m_wifi_init(&param);

if (M2M_SUCCESS != ret)

{

M2M_ERR("Driver Init Failed <%d>\n",ret);

while(1);

}

//Inizializzare il modulo OTA

m2m_ota_init(OtaUpdateCb,NULL);

//Connettersi ad AP che fornisce la connessione al server OTA

m2m_wifi_default_connect();

while(1)

{

//Gestire la macchina a stati dell'applicazione più il gestore di eventi WINC

while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

}

}

}

Listato 1: In questo esempio di codice OTA (over-the-air) tratto dal pacchetto Advanced Software Framework di Microchip, il callback del gestore eventi Wi-Fi wifi_event_cb() avvia l'aggiornamento OTA m2m_ota_start_update(OTA_URL) usando URL e switch specificati indirizzati al nuovo firmware m2m_ota_switch_firmware() e a completamento riuscito esegue OtaUpdateCb(). (Fonte del codice: Microchip Technology)

Per verificare che il codice scaricato sia valido, gli sviluppatori hanno a lungo fatto affidamento sui certificati di firma del codice rilasciati da un'autorità di certificazione riconosciuta. Ciononostante, le debolezze nell'archiviazione sicura dei dati, nell'implementazione di tecniche di convalida e nella protezione dei certificati offrono agli hacker molteplici possibilità di prendere il controllo di un dispositivo IoT.

Anche con le tecniche di sicurezza convenzionali, il processo di aggiornamento del firmware di un dispositivo può essere ingannato sostituendo il codice valido con un codice compromesso. Al riavvio, il dispositivo diventa uno strumento che l'hacker può utilizzare per penetrare più profondamente nella rete o nell'applicazione IoT e persino nelle risorse interne dell'azienda.

In questo scenario, la capacità di effettuare il boot in sicurezza del dispositivo IoT serve come linea di difesa critica. Per lo sviluppatore, tuttavia, l'implementazione del boot sicuro comporta diversi requisiti per l'archiviazione sicura, la crittografia, l'autenticazione e i meccanismi di convalida del codice.

L'implementazione del boot sicuro nel software lascia il processo di aggiornamento esposto a metodi di attacco incentrati sul recupero di chiavi sicure dalla memoria dei dispositivi, tramite l'intercettazione di dati crittografati, lo spoofing dei meccanismi di autenticazione e la compromissione degli algoritmi di convalida del codice. In pratica, i progetti IoT sono in genere privi della memoria e della potenza di elaborazione sufficienti per una soluzione software per tutti gli eventi. Del resto, un'implementazione hardware non può sempre garantire sicurezza.

Per implementare il boot sicuro nell'hardware, i dispositivi IoT fino a poco tempo fa richiedevano una serie di dispositivi specializzati che aumentavano significativamente la complessità di progettazione e i costi. Anche se gli sviluppatori integrassero questi dispositivi separati, certi hacker potrebbero facilmente procurarsi un campione del dispositivo target IoT e attaccare i singoli dispositivi di sicurezza attraverso il loro bus e l'interconnessione dei segnali. Al contrario, ATECC608A di Microchip Technology è una soluzione a singolo chip che permette agli sviluppatori di implementare un boot sicuro senza esporre i segreti o i meccanismi di sicurezza sottostanti.

CI di sicurezza

ATECC608A è un dispositivo di sicurezza a 8 pin progettato per supportare un'unità MCU host con una serie di sofisticate funzioni di sicurezza complementari attraverso una semplice interfaccia seriale (Figura 1).

Figura 1: ATECC608A è un coprocessore crittografico a 8 pin con archiviazione sicura delle chiavi basata su hardware. (Immagine per gentile concessione di Microchip Technology)

Il dispositivo fornisce una soluzione di sicurezza completa basata su hardware che combina i suoi acceleratori di crittografia integrati con la memorizzazione sicura su chip per supportare svariati algoritmi di crittografia tra cui SHA-256, AES-128 e robusti algoritmi basati su curve ellittiche tra cui Elliptic Curve Digital Signature (ECDSA), Elliptic Curve Diffie-Hellman (ECDH) e NIST Curve P-256. Oltre a questi meccanismi di crittografia, il dispositivo supporta protocolli TLS (Transport Layer Security) di livello superiore, tra cui TLS 1.3. A differenza dei dispositivi precedenti, ATECC608A è in grado di generare e archiviare in modo sicuro le chiavi di sessione, il che aiuta a mitigare una fonte comune di minacce riscontrate con l'uso dell'autenticazione TLS.

Tutte queste caratteristiche giocano un ruolo fondamentale nella sicurezza delle normali operazioni di un dispositivo IoT, ma il supporto di ATECC608A per il boot sicuro estende la sicurezza al fondamentale processo di aggiornamento del firmware. Infatti ATECC608A convalida il nuovo codice e restituisce un messaggio all'MCU che indica il successo o il fallimento. A quel punto, a seconda dei criteri di sicurezza esistenti, l'unità MCU può riprovare l'aggiornamento, inviare un messaggio di avviso a un endpoint di monitoraggio della sicurezza, interrompere o ignorare l'aggiornamento e riavviare il codice originale.

Integrazione hardware

Per lo sviluppatore, ATECC608A richiede relativamente pochi requisiti aggiuntivi per implementare il boot sicuro e le altre funzioni di sicurezza in un progetto basato su MCU. Per quanto riguarda l'hardware, il progettista deve occuparsi al massimo di quattro connessioni: V_CC, GND, ingresso di clock seriale (SCL) e dati seriali (SDA). I restanti quattro pin non sono collegati. A parte il collegamento V_CC ad una fonte di alimentazione da 2,0 V a 5,5 V, l'unica decisione che rimane è il collegamento seriale all'MCU.

I progettisti possono collegare i pin SCL e SDA del dispositivo all'MCU per la connettività convenzionale I²C. In alternativa, possono usufruire del supporto per il dispositivo per l'interfaccia a 1 filo di Microchip. In tal caso, gli sviluppatori collegano la porta SDA del dispositivo ad un pin GPIO dell'MCU e utilizzano il protocollo di sincronizzazione a 1 filo di Microchip per trasmettere i valori logici 0 e 1 (Figura 2).

Figura 2: Nel protocollo seriale a 1 filo di Microchip, una sequenza di transizioni di forme d'onda di durata specificata segnala una logica 0 o 1. (Immagine per gentile concessione di Microchip Technology)

In questo protocollo, la trasmissione di un valore logico tra ATECC608A e l'MCU inizia con un impulso di avvio (t_START) di durata specificata. Dopo l'impulso di avvio, il protocollo definisce una logica 0 come un ciclo di un impulso alto a trasmissione zero (t_ZHI) seguito da un impulso basso a trasmissione zero (t_ZLO) di durata specificata. Analogamente, un livello elevato sostenuto significa una trasmissione di logica 1.

In entrambi i casi, il protocollo si aspetta che il segnale si abbassi entro un tempo di bit specificato (t_BIT). Dopo una serie di trasmissioni in bit, se la linea seriale diventa inattiva dopo un tempo di timeout IO stabilito, il dispositivo può essere programmato per entrare automaticamente in modalità di sospensione. Per lavorare con ATECC608A, raramente occorre preoccuparsi dei dettagli di sincronizzazione di questo protocollo: Microchip ha definito i parametri chiave in modo che siano compatibili con UART standard a 230,4 Kbaud.

Configurazione del dispositivo

A livello di dispositivo, ATECC608A richiede impostazioni di configurazione minime. Utilizzando l'interfaccia seriale I²C o a 1 filo, gli sviluppatori possono caricare impostazioni come l'indirizzo I²C o impostare alcune funzioni come l'auto-test alla riattivazione o all'accensione. Il dispositivo fornisce un'impostazione di configurazione che potrebbe essere particolarmente interessante per progetti IoT a bassissimo consumo energetico.

In questi progetti, ATECC608A aggiunge relativamente poco al bilancio energetico complessivo nelle modalità standby o di sospensione che sono probabilmente gli stati più comuni in un tipico progetto IoT. In modalità standby, il dispositivo consuma circa 800 μA; in modalità di sospensione, il consumo energetico è di 150 nA o meno a seconda della configurazione. Quando l'MCU attiva il dispositivo per eseguire un processo di sicurezza, il suo consumo energetico non supera i 14 mA durante il funzionamento attivo. Nonostante questo risultato, i progetti con potenza disponibile molto ristretta possono richiedere livelli di potenza attiva ancora più bassi.

Per supportarli, il dispositivo fornisce un'opzione di configurazione che consente agli sviluppatori di selezionare tre diverse modalità operative che bilanciano la velocità di esecuzione per un minore consumo energetico. In questo modo, è possibile ridurre il consumo di energia attiva da 14 mA alla massima velocità di esecuzione a 6 mA o 3 mA con velocità inferiori.

Oltre a varie voci di configurazione di basso livello, un dispositivo di sicurezza come ATECC608A è più efficace quando le sue informazioni sicure sono già presenti ben prima dello sviluppo. Errori o lo sfruttamento di chiavi sicure e certificati eseguiti durante lo sviluppo possono vanificare anche i migliori sforzi per la sicurezza. Per affrontare queste possibili minacce, il provider affidabile di Microchip carica dati sicuri, comprese chiavi e certificati, come parte del processo di produzione.

Dopo il caricamento in un ambiente sicuro in fabbrica, i dati rimangono protetti da esposizioni accidentali o intenzionali anche quando il dispositivo passa attraverso i normali processi di manipolazione nella supply chain. ATECC608A include una speciale funzione di blocco di trasporto che disabilita l'uso del dispositivo fino a quando non viene abilitato in modo crittografico utilizzando una chiave nota trasmessa dall'eventuale MCU host.

Una volta abilitato dall'MCU host, ATECC608A genera una chiave segreta casuale chiamata chiave di protezione IO che condivide con l'MCU. Le successive comunicazioni tra ATECC608A e l'MCU sono criptate con questa chiave di protezione IO: un meccanismo che fornisce un'ulteriore autenticazione durante il boot sicuro e altri processi sicuri.

Se gli hacker volessero alterare il processo di validazione tagliando la connessione ad ATECC608A e inviando il proprio segnale di "successo" all'MCU, grazie a questo meccanismo della chiave di protezione IO l'MCU ignorerebbe il segnale falso. Anche se un hacker compromettesse in qualche modo un dispositivo ATECC608A e tentasse di usarlo su un sistema diverso, il meccanismo della chiave di protezione IO ne impedirebbe efficacemente l'uso.

Integrazione software

Grazie a tutte le sue sofisticate caratteristiche e ai meccanismi di protezione, ATECC608A rimane semplice da applicare a un progetto basato su MCU. Oltre ad implementare la semplice interfaccia hardware e le impostazioni di configurazione menzionate in precedenza, gli sviluppatori lavorano con un'interfaccia di programmazione delle applicazioni (API) che riassume i dettagli delle operazioni di sicurezza. La libreria di autenticazione crittografica CryptoAuthLib di Microchip fornisce un pacchetto software completo con definizioni, strutture e chiamate API necessarie per sfruttare appieno le funzionalità di ATECC608A. La libreria funge da layer hardware super partes, operando attraverso l'API dell'Hardware Abstraction Layer (HAL) e driver per specifici target hardware (Figura 3).

Figura 3: La libreria CryptoAuthLib di Microchip fornisce un layer di servizi di crittografia tra un'applicazione e l'hardware sottostante a cui si accede attraverso un Hardware Abstraction Layer sopra i driver specifici dell'hardware, fornendo la portabilità tra set hardware diversi. (Immagine per gentile concessione di Microchip Technology)

Gli sviluppatori usano le routine API CryptoAuthLib come io_protection_set_key() per creare una chiave di protezione IO e atcab_secureboot() per eseguire il meccanismo di validazione del boot sicuro di ATECC608A a fronte del digest o della firma del codice incluso nei parametri di chiamata.

Anche se i comandi API sono semplici, la configurazione specifica, i passi amministrativi e operativi necessari per implementare la sicurezza possono essere impegnativi. Gli stessi meccanismi di sicurezza che si cerca di mettere in atto possono causare ritardi se i passaggi chiave sono mancanti o eseguiti fuori sequenza.

Utilizzando il kit di sviluppo ATSAMD21-XPRO di Microchip basato su MCU SAM D21 e la sua scheda aggiuntiva ATCRYPTOAUTH-XPRO-B dotata di ATECC608A, gli sviluppatori possono rapidamente acquisire esperienza di lavoro con questi meccanismi generali e con le capacità specifiche di ATECC608A. Microchip offre un ampio pacchetto software di boot sicuro progettato per funzionare su ATSAMD21-XPRO e ATCRYPTOAUTH-XPRO-B, utilizzando un suo ATOLED1-XPRO per fornire un'interfaccia di visualizzazione di base per applicazioni campione (Figura 4).

Figura 4: Gli sviluppatori possono valutare rapidamente il processo di boot sicuro utilizzando il software e il kit di sviluppo ATSAMD21-XPRO basato su MCU SAM D21 di Microchip, abbinati al componente aggiuntivo ATCRYPTOAUTH-XPRO-B dotato di ATECC608A e display aggiuntivo ATOLED1-XPRO. (Immagine per gentile concessione di Microchip Technology)

Inclusa nel pacchetto demo SAM D21, una routine di boot sicuro completa illustra i principali modelli di progettazione software utilizzati per impostare, eseguire e controllare lo stato di un'operazione di boot sicuro (Listato 2). Utilizzando questa piattaforma hardware e il pacchetto software dimostrativo, gli sviluppatori possono valutare rapidamente l'uso di ATECC608A per il boot remoto e modificare il software di esempio in base alle proprie esigenze.

Copy

/** \Gestisce la funzionalità di boot sicuro attraverso l'inizializzazione, l'esecuzione

* e la de-inizializzazione.

* \Restituisce ATCA_SUCCESS in caso di successo, altrimenti un codice di errore.

*/

ATCA_STATUS secure_boot_process(void)

{

ATCA_STATUS status;

secure_boot_parameters secure_boot_params;

uint8_t secure_boot_mode;

bool secure_boot_app_valid = false;

/*Inizializza il boot sicuro */

if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

{

return status;

}

do

{

.

.

.

#if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

.

.

.

/*Ottenere la chiave di protezione IO*/

if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

{

return status;

}

if ((status = atcab_secureboot_mac(secure_boot_mode,

(const uint8_t*)&secure_boot_params.app_digest,

(const uint8_t*)&secure_boot_params.memory_params.signature,

(const uint8_t*)secure_boot_params.randomnum,

(const uint8_t*)secure_boot_params.io_protection_key,

&secure_boot_app_valid)) != ATCA_SUCCESS)

{

break;

}

#else

if ((status = atcab_secureboot(secure_boot_mode,

0,

(const uint8_t*)&secure_boot_params.app_digest,

(const uint8_t*)&secure_boot_params.memory_params.signature,

NULL)) != ATCA_SUCCESS)

{

break;

}

secure_boot_app_valid = true;

#endif

/*Controllare se il comando di boot sicuro è stato eseguito con successo con il corretto ritorno mac */

if (!secure_boot_app_valid)

{

break;

}

.

.

.

}

while (0);

/* De-inizializza l'interfaccia di memoria e rilascia le sue risorse*/

secure_boot_deinit_memory(&secure_boot_params.memory_params);

return status;

}

Listato 2: Questo frammento del pacchetto demo SAM D21 di Microchip mostra i modelli di progettazione chiave per il boot sicuro, incluso il controllo di una chiave di protezione IO (io_protection_get_key()) e la validazione del firmware usando il digest, la firma e altri parametri (atcab_secureboot_mac() o atcab_secureboot() a seconda della configurazione selezionata). (Fonte del codice: Microchip Technology)

Conclusione

I dispositivi IoT presentano molteplici aree di minacce da parte degli hacker che intendono utilizzare dispositivi compromessi per accedere alle reti, alle applicazioni e alle risorse aziendali di Internet delle cose. Tra le tecniche di mitigazione, il boot sicuro si pone come elemento critico nell'ambito di una strategia di sicurezza più ampia. Tuttavia, l'implementazione del boot sicuro comporta un insieme di requisiti peculiari che possono lasciare il sistema esposto se non gestito correttamente.

La tecnologia di Microchip Technology basata sul CI di sicurezza ATECC608A fornisce una soluzione completa in un unico pacchetto che gli sviluppatori possono facilmente aggiungere a qualsiasi progetto basato su MCU. Utilizzando ATECC608A, gli sviluppatori possono migliorare notevolmente la sicurezza e garantire un boot sicuro nei loro progetti IoT.