L'aggiunta di un Secure Element garantisce una protezione edge-to-cloud ai progetti IoT

La sicurezza informatica rappresenta un problema universale per la progettazione e lo sviluppo di qualsiasi sistema connesso alla rete Internet pubblica. Nell'Internet delle cose (IoT) i problemi legati alla sicurezza sono particolarmente sentiti e gli utenti cominciano a dubitare della capacità dei dispositivi connessi di supportare le applicazioni presenti nelle case, nelle fabbriche e nelle città intelligenti senza esporli a rischi. Tuttavia, visti i tempi sempre più stretti, gli sviluppatori di dispostivi IoT hanno spesso la sensazione di non potersi permettere le risorse per il dispositivo e ancor meno il tempo richiesto in passato per implementare il set esteso di abilità necessarie per offrire una protezione efficace.

I fornitori di semiconduttori stanno cercando di riequilibrare questa situazione offrendo soluzioni di protezione semplici da implementare. In questo articolo affronteremo il tema della sicurezza prima di presentarvi una soluzione a questo problema tipo messa a punto da NXP Semiconductors, nello specifico il Secure Element (SE) EdgeLock SE050. Passeremo poi a mostrare agli sviluppatori come utilizzare questo dispositivo a chip singolo per implementare rapidamente nei loro dispositivi IoT una protezione edge-to-cloud.

Il problema della sicurezza dell'IoT

I dispositivi IoT con uno scarso livello di protezione hanno purtroppo dimostrato di essere un bersaglio interessante per gli attacchi informatici. Se compromessi, questi dispositivi possono rivelare dati riservati degli utenti e fornire informazioni preziose per costruire loro copie contraffatte. Gli hacker possono anche servirsi di questi dispositivi esposti per creare ancora maggior caos, penetrando più profondamente nelle reti per arrivare ad altri dispostivi connessi, sistemi e risorse aziendali. Perciò, le conseguenze della compromissione di un dispositivo IoT si propagano a tutti i livelli della gerarchia dell'IoT, arrivando persino a minacciare la sicurezza pubblica di applicazioni IoT che si stanno diffondendo come l'automazione degli edifici, gli impianti industriali, i trasporti e i dispositivi medici.

Per gli sviluppatori, a cui vengono chiesti progetti IoT più efficienti, la sicurezza può rappresentare un'altra sgradita voce da aggiungere a una lista di requisiti già dominata dalle esigenze di prestazioni più elevate e consumi più bassi. Una protezione efficace, infatti, si basa su una lista crescente di requisiti in grado di ridurre le minacce della rete, dai margini al cloud.

Da sole, anche tecniche familiari come la crittografia e l'autenticazione sono insufficienti. La sicurezza dell'IoT deve essere costruita su una root-of-trust progettata in modo da garantire che i meccanismi e i protocolli di protezione siano esenti da rischi. Contemporaneamente, occorre applicare i metodi di protezione a un livello di granularità più fine, per proteggere non solo i collegamenti tra i dispostivi IoT ma anche i collegamenti tra i componenti di un singolo progetto IoT.

Il Secure Element EdgeLock SE050 di NXP è stato progettato specificamente per offrire ai dispositivi IoT la serie di meccanismi di protezione e i protocolli necessari per la sicurezza edge-to-cloud.

Una solida soluzione per la sicurezza

Progettata come soluzione chiavi in mano per la protezione dei dispositivi IoT, SE050 di NXP, che si avvale della grande esperienza dell'azienda nel settore della sicurezza delle smart card, rappresenta una root-of-trust hardware per i progetti IoT. Il dispositivo abbina un microcontroller dedicato e la memorizzazione sicura delle credenziali con uno stack software costruito sul sistema operativo (OS) per le smart card Java Card OpenPlatform (JCOP). La piattaforma operativa di SE050, che ha ottenuto la certificazione indipendente Common Criteria (CC) Evaluation Assurance Level (EAL) 6 augmented (EAL 6+) sino al sistema operativo garantisce un grado di protezione inusitato in ambienti ad alto tasso di rischio (Figura 1).

Figura 1: Tra i prodotti certificati, la piattaforma SE050 offre un livello inusitato di affidabilità certificato CC EAL 6+ sino a livello del sistema operativo. (Fonte dati: Common Criteria)

Un'applet NXP dedicata per la sicurezza dell'IoT, ottimizzata per questa solida piattaforma di protezione, si avvale di una libreria crittografica incorporata che supporta un vasto insieme di algoritmi di crittografia tra cui:

• Crittografia simmetrica con algoritmi Advanced Encryption Standard (AES) e Data Encryption Standard (DES)
• Crittografia asimmetrica con algoritmi Rivest–Shamir–Adleman (RSA) e di crittografia ellittica (ECC) con il supporto per numerose curve ECC, tra cui le curve standard specificate dal National Institute of Standards and Technology (NIST)
• Numerose funzioni di hash per la costruzione di codici di autenticazione dei messaggi (MAC)
• Numerosi algoritmi di derivazione della chiave (KDF) per l'hash della password, la corrispondenza chiavi e il rafforzamento della chiave tra gli altri metodi.

Per velocizzare le prestazioni, il dispositivo SE050 incorpora acceleratori hardware per l'Advanced Encryption Standard (AES), il Data Encryption Standard (DES) e la crittografia Fast Attribute-based Message Encryption (FAME).

Per proteggere le credenziali utilizzate nelle operazioni di crittografia, il dispositivo fornisce sino a 50 KB di memoria utente flash sicura e viene fornito dotato di chiavi radice per il supporto di transazioni IoT tipiche. Gli sviluppatori che creano progetti per volumi elevati possono anche disporre di chiavi personalizzate e credenziali sicure assegnate da NXP o da terzi autorizzati.

Il dispositivo, oltre alla memoria flash embedded, supporta l'accesso alla memoria ad accesso casuale (RAM) per la memorizzazione di certificati pubblici, ad esempio, mentre le chiavi private associate rimangono nella memoria flash sicura. Oltre a ciò, l'applet SE050 per l'IoT dispone di capacità di importazione ed esportazione sicure che consentono gli sviluppatori di memorizzare chiavi o dati arbitrari in una memoria esterna senza correre rischi. Ciònonostante, il dispositivo si avvale di una unità di gestione della memoria che limita l'accesso a diverse parti della memoria alla sola applet per l'IoT, impedendo l'accesso non autorizzato attraverso il microcontroller. Per garantire ulteriore protezione contro le manomissioni e sofisticati attacchi al canale laterale, il dispositivo incorpora anche numerose barriere logiche e fisiche contro gli accessi non autorizzati.

Tuttavia, la protezione consiste sia nel concedere accesso ai dispositivi autorizzati sia nel costruire barriere contro gli accessi non autorizzati.

Autenticazione del dispositivo

In quanto root-of-trust per dispositivi IoT, il meccanismo di crittografia di SE050 e le capacità di memorizzazione sicura supportano direttamente i collegamenti protetti previsti nelle comunicazioni con host remoti autorizzati come i server cloud. Di fatto, queste stesse capacità consentono agli sviluppatori di garantire l'autenticità delle connessioni ai livelli più bassi della gerarchia IoT tra dispositivi IoT separati dotati dei Secure Element SE050.

Utilizzando un metodo simile all'autenticazione Internet convenzionale, un sensore intelligente dell'IoT può autenticarsi presso un dispositivo di comando IoT, ad esempio. Questo processo inizia con il dispositivo di rilevamento che invia il certificato salvato nella memoria sicura del suo SE050 al dispositivo di comando. Il dispositivo di comando a sua volta valida il certificato ricevuto con le funzionalità crittografiche di SE050. Se la validazione riesce, il dispositivo di comando risponde con alcuni valori casuali, chiamati la "sfida", al sensore. A sua volta il sensore utilizza il SE SE050 per firmare la sfida con la chiave privata associata allo stesso certificato che ha inviato precedentemente al dispositivo di comando. Visto che la sfida firmata può essere autenticata solo con la chiave pubblica associata, il dispositivo di comando ha la garanzia che il certificato inviato originariamente dal sensore è veramente del sensore. Di conseguenza, il dispositivo di comando può autenticare in modo affidabile il sensore.

Invertendo i ruoli nello stesso processo, il dispositivo di comando può a sua volta autenticarsi presso il sensore.

Questo tipo di processo di autenticazione reciproca è fondamentale per la costruzione di reti IoT affidabili, specialmente alla luce dell'aumento degli strati intermedi, tra cui i dispositivi di edge computing. Sebbene il processo di autenticazione reciproca sia lineare, anche piccoli errori di implementazione o interpretazioni diverse del protocollo possono dare origine a gravi falle di sicurezza. Soprattutto nei progetti IoT con vincoli di risorse, le esigenze di memorizzazione sicura e di rapida esecuzione di complessi algoritmi di crittografia possono complicare ulteriormente l'affidabilità dell'implementazione. L'aggiunta di SE050 a qualsiasi progetto IoT offre la possibilità agli sviluppatori di implementare funzionalità critiche per la sicurezza come l'autenticazione reciproca senza compromettere le prestazioni complessive del progetto o la sua sicurezza.

Integrazione semplice e sicura

Alle funzionalità avanzate di SE050 si aggiunge la facilità di design-in. Gli sviluppatori possono facilmente integrare il dispositivo nei loro progetti hardware per l'IoT con un impatto minimo sulla complessità della progettazione o sull'ingombro. Progettato per fungere da dispositivo add-on, con i suoi 3 millimetri per 3 offre un insieme semplice di interfacce seriali (Figura 2).

Figura 2: Il Secure Element SE050 di NXP offre interfacce multiple, che ne consentono l'utilizzo come slave I²C per i collegamenti ai microcontroller host, come master I²C per le connessioni basate su ISO 7816 ai sensori digitali e come interfaccia senza contatto ISO 14443 NFC (Near Field Communication). (Immagine per gentile concessione di NXP)

Il dispositivo funge da slave I²C per comunicare con il microcontroller host. SE050 può anche fungere da master I²C per collegamenti basati su ISO 7816 con un altro dispositivo seriale come un sensore digitale. Il dispositivo supporta anche una terza interfaccia per la connettività ISO 14443 NFC senza contatto.

L'applet SE050 per l'IoT presiede al coordinamento delle chiavi sicure e delle regole di controllo degli accessi per la configurazione e la gestione delle sessioni di ciascuna connessione per tutti i suoi diversi collegamenti.

Nelle comunicazioni con l'host, SE050 fornisce un'autenticazione basata su sessione, al fine di impedire l'intercettazione di comandi e dati I²C e gli attacchi MIMT (Man-in-the-Middle). Per dare avvio a una sessione seriale di connessione, gli sviluppatori possono realizzare l'autenticazione con un ID utente che funziona come una password o un numero identificativo personale (PIN).

Una semplice autenticazione basata su password tra il microcontroller e SE050 potrebbe non essere sempre sufficiente per alcune applicazioni. Per le applicazioni critiche gli sviluppatori potrebbero aver bisogno di garantire che le comunicazioni tra il microcontroller host e il Secure Element SE050 rimangano riservate per prevenire attacchi che riproducono le sessioni, inviano frammenti di sessioni non funzionanti o sostituiscono algoritmi crittografici con versioni hackerate con lo scopo di estrarre dati riservati.

Transazioni sicure tramite bus

Con il Secure Element SE050 gli sviluppatori possono utilizzare metodi di autenticazione per creare un canale di comunicazione sicuro tra SE050 e il microcontroller host. In questo caso gli sviluppatori possono sfruttare il fatto che il CI di SE050 supporta lo standard SCP03 (Secure Channel Protocol) largamente utilizzato per proteggere comunicazioni bidirezionali tra un dispositivo Java Card e un host.

Nei progetti basati su microcontroller realizzati con il Secure Element SE050, l'utilizzo del protocollo SCP03 stabilisce fondamentalmente un legame tra il Secure Element SE050 e il microcontroller host durante l'autenticazione della sessione del bus I²C, consentendo l'ulteriore uso di messaggi crittografati durante la sessione. Nel protocollo SCP03, il messaggio di solo testo viene prima crittografato con l'algoritmo AES e viene poi generato un messaggio MAC. Inviando sia il messaggio crittografato sia il MAC associato, questo metodo, chiamato "encrypt-then-MAC", protegge il messaggio crittografato e consente al destinatario di individuare alterazioni del messaggio.

Il SE050 inoltre estende una forma di protezione ai dati del sensore. In questo caso, gli sviluppatori possono chiedere a SE050 di potenziare le risposte ai comandi dell'host con metadati di attestazione che comprendono un identificatore unico, informazioni sulla freschezza sotto forma di un valore casuale per ciascun istanza, un indicatore di data e ora e una firma. All'interno dell'host, il software può esaminare i dati di attestazione ricevuti da SE050 per validare la sorgente e la tempestività dei dati dei sensori collegati all'interfaccia master I²C di SE050.

Mentre i dati dei singoli sensori si uniscono in flussi procedendo lungo la gerarchia IoT, le applicazioni possono usare questi dati di attestazione per identificare la sorgente di schemi di dati insoliti che potrebbero indicare sensori danneggiati, guasti o compromessi. Grazie all'attestazione di SCP03 dei dati delle sessioni host e dei sensori, gli sviluppatori possono acquisire in modo affidabile e sicuro dati essenziali dei sensori per le applicazioni critiche.

Interfaccia funzionale

Le richieste e le risposte di attestazione, come tutte le interazioni tra il microcontroller host e il Secure Element SE050, passano attraverso uno stack di comunicazione definito negli standard per le interfacce funzionali ISO 7816 per lettori di smart card (Figura 3). Questo standard per le sequenze APDU (Application Protocol Data Unit) definisce il formato, il contenuto e il protocollo per lo scambio di messaggi tra un dispositivo host (HD) e un Secure Element.

Figura 3: Le comunicazioni tra un Secure Element SE050 di NXP e un HD passano attraverso uno stack conforme allo standard ISO 7816 per smart card, incluse le richieste e le risposte a livello di applicazione che utilizzano le sequenze APDU di ISO 7816, trasmesse da un livello di collegamento dati che utilizza il protocollo half-duplex T=1 di ISO 7816-3 su I²C. (Immagine per gentile concessione di NXP)

Partendo dallo strato fisico I²C, il livello di collegamento dati scompone le richieste e le risposte provenienti dal livello dell'applicazione in una sequenza di transazioni conformi al protocollo T=1 su I²C di ISO 7816-3 per la comunicazione half-duplex. In questo protocollo il livello di collegamento dei dati sull'HD e sul SE attende il riconoscimento successivamente a ciascuna trasmissione di una sequenza di transazioni.

Ad esempio, nel caso di una richiesta di lettura partita dall'applicazione host, il livello di collegamento dati dell'host prima interroga il Secure Element e attende la risposta di riconoscimento (ACK), che indica che il Secure Element è pronto all'invio (Figura 4).

Figura 4: Il livello di collegamento dati elabora le richieste dell'HD, tra cui la richiesta di lettura riportata qui, come una serie di transazioni conformi al protocollo T=1 su I²C, a partire da un anello di polling che ripete la richiesta sinché non riceve una risposta di ACK che indica che il Secure Element è pronto a trasmettere dati. (Immagine per gentile concessione di NXP)

In seguito alla risposta ACK = ready, il livello di collegamento dati del Secure Element invia dati all'host sotto forma di una sequenza di trasferimento di blocchi dati, attendendo un riconoscimento da parte del livello di collegamento dati dell'host per il trasferimento di ciascun blocco (Figura 5). Infine, la risposta completa viene consegnata all'applicazione host.

Figura 5: Dopo aver indicato di essere pronto a inviare dati, il Secure element invia una risposta dati sotto forma di blocchi di dati, in attesa di un riconoscimento da parte dell'HD prima di inviare il blocco successivo della sequenza. (Immagine per gentile concessione di NXP)

Implementazione del software

A livello applicativo, gli scambi tra il microcontroller host e il Secure Element SE050 avvengono tramite le sequenze APDU di ISO 7816. Per SE050, le sequenze APDU di comandi e risposte si basano sul formato TLV (Tag, Length, Value) definito in ISO 7816-4. Come minimo, ogni APDU comprende un byte CLA (un valore fisso per tutte le operazioni di SE050), un byte INS e due byte di parametro (P1, P2). Le richieste di dati e le risposte possono anche comprendere campi aggiuntivi per il numero di byte che devono essere letti (Le), la lunghezza del campo dati (Lc) e il campo dati.

Ad esempio una richiesta di lettura da parte dell'applicazione host userebbe una coppia di TLV per configurare l'interfaccia I²C di SE050 ed eseguire la richiesta di lettura (Listato 1). Come notato in precedenza, il livello di collegamento dati dell'host scomporrebbe questa richiesta in una serie di transazioni del bus I²C in conformità con il protocollo T=1.

Copy
static smStatus_t i2cm_Read(
    ex_sss_boot_ctx_t *pCtx, uint8_t *readbuf, uint32_t readLength)
{
    smStatus_t status;
    TLV[0].type = kSE05x_I2CM_Configure;
    TLV[0].cmd.cfg.I2C_addr = I2C_SENSOR_BUS_ADDRESS;
    TLV[0].cmd.cfg.I2C_baudRate = kSE05x_I2CM_Baud_Rate_400Khz;
 
    TLV[1].type = kSE05x_I2CM_Read;
    TLV[1].cmd.rd.readLength = readLength;
    TLV[1].cmd.rd.rdBuf = readbuf;
 
    status = Se05x_i2c_master_txn(&pCtx->session, &TLV[0], 3);
    return status;
}

Listato 1: Il middleware Plug & Trust di NXP contiene codice sorgente che illustra l'utilizzo del formato TLV di ISO 7816-4 nei comandi host, come questo comando elementare di lettura al Secure Element NXP SE050. (Codice per gentile concessione di NXP)

Come mostrato nel Listato 1, il codice usa una semplice struttura in C per codificare i TLV per la configurazione e le richieste di lettura. In questo caso, ogni TLV è istanziato tramite una struttura SE05x_I2CM_cmd_t (Listato 2).

Copy
typedef struct _SE05x_I2CM_cmd
{
    SE05x_I2CM_TLV_type_t type;
    SE05x_I2CM_INS_type_t cmd;
} SE05x_I2CM_cmd_t;
 
typedef enum _SE05x_I2CM_TLV_type
{
    kSE05x_I2CM_None = 0,
    kSE05x_I2CM_Configure,
    //kSE05x_I2CM_Security,
    kSE05x_I2CM_Write = 3,
    kSE05x_I2CM_Read,
    kSE05x_I2CM_StructuralIssue = 0xFF
} SE05x_I2CM_TLV_type_t;
 
typedef union _SE05x_I2CM_INS_type {
    SE05x_I2CM_configData_t cfg;
    SE05x_I2CM_securityData_t sec;
    SE05x_I2CM_writeData_t w;
    SE05x_I2CM_readData_t rd;
    SE05x_I2CM_structuralIssue_t issue;
} SE05x_I2CM_INS_type_t;
 
typedef struct _SE05x_I2CM_readData
{
    uint16_t readLength;
    SE05x_I2CM_status_t rdStatus;
    /* Output. rdBuf will point to Host buffer */
    uint8_t *rdBuf;
} SE05x_I2CM_readData_t;

Listato 2: La distribuzione del software Plug & Trust di NXP offre strutture per la definizione del tipo di richiesta (evidenziazione verde) e parametri per i comandi associati (evidenziazione blu). (Codice per gentile concessione di NXP)

All'interno di quella struttura SE05x_I2CM_cmd_t, il membro del tipo viene definito tramite un enumeratore C, SE05x_I2CM_TLV_type_t, che elenca i possibili valori, tra cui il valore standard 4 per una richiesta di lettura ADPU (kSE05x_I2CM_Read). Il membro cmd della struttura SE05x_I2CM_cmd_t viene definito in una unione di strutture. In questo caso, il membro cmd è una struttura rd, che a sua volta contiene membri che specificano la lunghezza dei dati richiesti (readLength) e il puntatore buffer del target (rdBuf).

Questo insieme di definizioni si compendia in poche righe di codice necessarie a impostare il membro del tipo di istanza TLV[1] del Listato 1 in modo che indichi una richiesta di lettura (kSE05x_I2CM_Read) e a impostare il valore desiderato per readLength e il puntatore buffer readBuf del membro cmd.

Supporto per lo sviluppo

Per semplificare lo sviluppo del software, NXP estrapola le interazioni dell'host con il Secure Element SE050 con il proprio middleware Plug & Trust e le API della libreria associata (Figura 6). Il pacchetto di distribuzione del middleware Plug & Trust di NXP associa il middleware e le API con un set di applicazioni di esempio realizzate con mbed TLS, OpenSSL e altri pacchetti. Inoltre, un'interfaccia basata sulla linea di comando Python (CLI) consente agli sviluppatori di utilizzare interattivamente le caratteristiche di SE050.

Figura 6: Oltre al software d'esempio, il pacchetto Plug & Trust di NXP include il middleware e le API associate che estrapolano i dettagli delle interazioni con SE050 attraverso lo stack basato su ISO 7816, che comprende lo strato applicativo della sequenza APDU, il livello di collegamento dati T=1 su I²C e lo strato fisico I²C. (Immagine per gentile concessione di NXP)

Oltre al software Plug & Trust di NXP, gli sviluppatori posso valutare velocemente SE050 con il kit di sviluppo OM-SE050ARD, che include un Secure Element SE050 e una semplice circuiteria di supporto con numerose basette. Oltre ai connettori per un'interfaccia esterna I²C e l'accesso diretto ai pin di SE050, la scheda OM-SE050ARD contiene una basetta Arduino-R3. Con la basetta Arduino-R3, gli sviluppatori possono facilmente collegare la scheda OM-SE050ARD a numerose schede di sviluppo tra cui la scheda di valutazione I.MX 6ULTRALITE e FRDM-K64F di NXP.

Con le schede di valutazione fornite, gli sviluppatori possono esplorare velocemente specifici utilizzi per la sicurezza sia a livello di codice attraverso gli esempi di software Plug & Trust oppure interattivamente attraverso l''interfaccia a riga di comando basata su Python. Tra le applicazioni di esempio della distribuzione del software Plug & Trust, il software di esempio illustra il processo completo per la lettura dei dati dei sensori attraverso l'interfaccia master I²C di SE050. Gli sviluppatori possono velocemente ricostruire questa applicazione di esempio in modo da sostituire le letture convenzionali I²C con letture di attestazioni. L'utilizzo di letture di attestazioni non richiede alcuna modifica alle impostazioni TLV illustrate nel Listato 1. Le modifiche consistono in gran parte nella sostituzione della funzione di lettura I2C Se05x_i2c_master_txn() mostrata nel Listato 1 con la versione della lettura attestata Se05x_i2c_master_attst_txn() oltre ai parametri delle funzioni associate.

Altre applicazioni di esempio illustrano la tappa finale della sicurezza edge-to-cloud: l'autenticazione e le comunicazioni sicure con i servizi cloud. Tra gli esempi di software di Plug & Trust, gli sviluppatori possono trovare istruzioni passo-passo per utilizzare SE050 per autenticare e fornire connessioni sicure ai servizi di cloud pubblico tra cui Microsoft Azure, IBM Watson, Amazon Web Services (AWS) e Google Cloud Platform (GCP). Gran parte del lavoro richiesto da questi esempi di connessioni al cloud consiste nella creazione di un account sui rispettivi servizi cloud e nel caricare le chiavi e i certificati (forniti anch'essi nelle routine di esempio). Il Secure Element SE050 si occupa del lavoro oneroso che gli sviluppatori generalmente devono sobbarcarsi per garantire una connettività sicura al cloud.

Grazie allo stack software Plug & Trust di NXP associato alle schede di sviluppo NXP, gli sviluppatori possono senza sprechi di tempo usufruire del supporto globale offerto dal Secure Element SE050 per la protezione edge-to-cloud dei dispositivi IoT.

Conclusione

Dispostivi IoT con uno scarso grado di protezione minacciano di divulgare grandi quantità di dati riservati e possono diventare il punto di accesso per altre risorse collegate. Gli sviluppatori devono costruire progetti IoT su fondamenta sicure che vanno dal dispositivo al cloud e supportano l'intero ciclo di vita del dispositivo IoT. Come vi abbiamo mostrato, questo risultato può essere raggiunto potenziando i progetti con SE050 di NXP. Con questo Secure Element gli sviluppatori sono in grado di rispondere alle esigenze, che si stanno facendo strada, di una protezione più efficace, che copra l'intero percorso dai margini della rete al cloud.