Una soluzione più semplice per collegare in modo sicuro i dispositivi IoT al cloud

Malgrado siano sempre più consapevoli dell'importanza della sicurezza, gli sviluppatori troppo spesso prendono delle scorciatoie quando devono connettere dispositivi IoT al cloud. In molti casi, i conflitti tra la complessità di meccanismi di sicurezza idonei, la memoria e le risorse di elaborazione limitate disponibili in minuscoli dispositivi IoT alimentati a batteria e la necessità di completare il prodotto, sembrano insormontabili.

Per far fronte a questi problemi e semplificare l'implementazione delle funzionalità di sicurezza nei dispositivi IoT, Microchip Technology e Google hanno stretto una collaborazione per trovare un approccio che combini le capacità hardware sicure di Microchip con una struttura dei dati semplice chiamata JSON Web Token (JWT). Ne è nato un metodo facile per assicurare l'autenticazione reciproca tra i dispositivi IoT e i servizi Google Cloud IoT Core.

Questo articolo descriverà le minacce che incombono sulla sicurezza dei dispositivi IoT e presenterà i dispositivi utilizzati attualmente per contrastare tale minaccia. Identificherà quindi le falle nella sicurezza e illustrerà in che modo gli sviluppatori e i progettisti di sistemi embedded possono utilizzare JWT per chiuderle.

La vulnerabilità della sicurezza dei dispositivi IoT

Gli attacchi ai dispositivi IoT possono assumere molte forme e non si limitano affatto alle distribuzioni IoT su larga scala. Anche la più piccola rete IoT è un bersaglio allettante per gli hacker che cercano di sfruttare le risorse di molti singoli dispositivi in botnet destinati agli attacchi DDoS (Distributed Denial of Service) e ad altri. Di conseguenza, i progettisti di qualsiasi classe di dispositivi IoT sono inevitabilmente costretti a proteggere i loro sistemi con robusti meccanismi di sicurezza basati su hardware in grado di contrastare gli attacchi.

Ad esempio, l'utilizzo della memoria di sistema o della memoria flash per archiviare le chiavi private utilizzate per la crittografia e l'autenticazione, rende vulnerabile il dispositivo IoT. E, quel che è peggio, gli hacker possono rubare le chiavi e usarle per accedere alla rete IoT e alle risorse aziendali collegate.

CI di sicurezza

Dispositivi di sicurezza specializzati come i CI CryptoMemory e CryptoAuthentication di Microchip Technology sono dotati di meccanismi basati su hardware a protezione delle chiavi private e di altri dati che devono rimanere segreti. Un array EEPROM integrato in questi dispositivi provvede a un'archiviazione sicura raggiungibile solo tramite meccanismi crittograficamente sicuri ai quali si accede per mezzo dell'interfaccia SPI o I²C seriale del dispositivo (Figura 1). Questi dispositivi offrono pertanto un metodo semplice per aggiungere un'area di memorizzazione sicura e altre funzionalità di sicurezza a qualsiasi progetto di dispositivi IoT.

Figura 1: I dispositivi di sicurezza hardware di Microchip Technology, come il CI CryptoMemory AT88SC0204C, offrono un'area di memorizzazione sicura, grazie ai meccanismi crittografici integrati che proteggono l'accesso alla EEPROM su chip. (Immagine per gentile concessione di Microchip Technology)

Componenti della famiglia CryptoAuthentication di Microchip come ATECC608A rafforzano ulteriormente queste basi di sicurezza col supporto degli algoritmi di crittografia che vengono usati normalmente nei progetti sicuri. Il dispositivo vanta, fra le sue caratteristiche, l'accelerazione hardware per numerosi algoritmi, fra cui:

• Algoritmi di crittografia asimmetrica:
  • Algoritmo di firma digitale a curva ellittica (ECDSA) FIPS186-3
  • Diffie-Hellman a curva ellittica (ECDH) FIPS SP800-56A
  • Crittografia a curva ellittica (ECC) P256 standard NIST
• Algoritmi di crittografia simmetrica:
  • Crittografia hash SHA-256
  • Crittografia con codice di autenticazione basato su hash (HMAC)
  • Crittografia AES-128
  • Crittografia AES-GCM (moltiplicazione del campo di Galois)
• Funzioni di derivazione della chiave (KDF):
  • Funzione pseudocasuale KDF (PRF)
  • KDF a estrazione ed espansione basata su HMAC (HKDF)

Per gli esperti di crittografia, questa serie di funzionalità crittografiche rappresenta un elenco completo dei meccanismi richiesti per supportare protocolli di sicurezza di livello superiore per l'autenticazione e lo scambio sicuro di dati. Ad esempio, la capacità KDF fornisce i meccanismi essenziali richiesti per il protocollo TLS (Transport Layer Security) per l'autenticazione dei partecipanti alla sessione di scambio di dati prima che tale scambio inizi.

In questo protocollo, una sessione TLS inizia con un client che invia al server una richiesta per avviare una sessione sicura. Il server risponde con il suo certificato digitale, che il client utilizza per confermare l'identità del server. Una volta che il client ha autenticato il server in questo modo, la sessione procede con il client che genera una chiave di sessione utilizzando la chiave pubblica del server per crittografare un valore casuale creato tramite una KDF PRF o una HDKF più robusta.

Il protocollo di autenticazione TLS è fondamentale per la sicurezza Internet. Per supportare questa componente fondamentale delle comunicazioni sicure è nata un'intera industria di provider di certificati, chiamati autorità certificative (CA). Le aziende acquisiscono dalle CA certificati attendibili da installare sui propri server a supporto del protocollo di autenticazione del server TLS standard descritto sopra.

Per le applicazioni IoT, in cui le reti si collegano in modo ampio e profondo con le risorse aziendali, questo tipo di autenticazione unidirezionale non è sufficiente per garantire la protezione. Ad esempio, nel quadro di un attacco a più ampio raggio gli hacker con certificati fraudolenti potrebbero presentarsi come server legittimi ai dispositivi IoT.

Malgrado il rischio, gli sviluppatori IoT spesso incontrano difficoltà a implementare il protocollo di autenticazione reciproca TLS perché i certificati, le chiavi e il software necessari per implementare l'autenticazione del client con TLS possono andare oltre le capacità di molti dispositivi IoT. Insieme, Microchip Technology e Google hanno ideato un approccio alternativo che combina le capacità di ATECC608A con una struttura dei dati semplice chiamata JSON Web Token (JWT). Ne è nato un metodo facile per assicurare l'autenticazione reciproca tra i dispositivi IoT e i servizi Google Cloud IoT Core.

Autenticazione basata su JWT

JWT, specificata in RFC 7519, è un contenitore di standard industriale per le informazioni, chiamate claim, sull'entità che prepara e trasmette il JWT. La struttura del JWT comprende tre sezioni:

• Intestazione, che include coppie name:value JSON per il nome ("alg") dell'algoritmo di crittografia usato per firmare il token (ad esempio "EC256" per ECDSA utilizzando la curva P-256 NIST) e per il tipo ("typ") di token ("JWT" per questi token)
• Payload, che include coppie name:value JSON per ogni claim
• Firma, che utilizza l'algoritmo specificato nell'intestazione per codificare una chiave segreta insieme all'intestazione e alla serie di claim, ciascuna delle quali viene convertita separatamente in una rappresentazione codificata con URL base64 prima della crittografia

RFC 7519 offre moltissima flessibilità per specificare i claim nel payload o in altre sezioni. Lo standard consente anche JWT non protetti, creati senza firma o crittografia. In questo caso l'intestazione includerebbe la coppia name:value per l'algoritmo come {"alg":"none"}. Per i JWT usati con i servizi Google Cloud IoT Core, Google richiede la sezione della firma e un payload con tre claim obbligatori:

• "iat" - l'ora "issued at" in cui il token è stato creato in formato indicatore di data e ora UTC ISO 8601 in secondi da 1970-01-01T00:00:00Z (es., 1561896000 per 30 giugno 2019 12:00:00 PM GMT)
• "exp" - l'indicatore di data e ora UTC che specifica la scadenza del token con un massimo di 24 ore dopo il valore "iat" più un periodo di tolleranza di dieci minuti per lo skew (ritardo) del clock di sistema tra i vari client e server (ad esempio, 1561982400 per 1 luglio 2019 12:00:00 PM GMT)
• "aud" - una stringa contenente l'ID di progetto Google Cloud dello sviluppatore

Lo schema di Google per l'autenticazione del dispositivo IoT combina l'autenticazione normale del server basata su TLS con quella del dispositivo IoT utilizzando un JWT creato con questi claim relativamente semplici. Per avviare una nuova sessione, un dispositivo IoT apre un socket sicuro sul server e autentica il server utilizzando lo stesso protocollo TLS descritto in precedenza.

Il passaggio successivo in questo processo si basa sull'uso del leggero protocollo di comunicazione MQTT (Message Queueing Telemetry Transport) da parte del cloud IoT di Google per le transazioni di rete IoT. Utilizzando il socket sicuro per il server autenticato, il dispositivo IoT "accede" ai servizi host MQTT di quel server, utilizzando il suo JWT univoco come password di accesso (Listato 1).

Copy
/* Populate the buffer with the username */
int config_get_client_username(char* buf, size_t buflen)
{
    if(buf && buflen)
    {
        int rv = snprintf(buf, buflen, "unused");
 
        if(0 < rv && rv < buflen)
        {
            buf[rv] = 0;
            return 0;
        }
    }
    return -1;
}
 
/* Populate the buffer with the user's password */
int config_get_client_password(char* buf, size_t buflen)
{
    int rv = -1;
 
    if(buf && buflen)
    {
        atca_jwt_t jwt;
        
        uint32_t ts = time_utils_get_utc();
 
        rv = atcab_init(&cfg_ateccx08a_i2c_default);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        /* Build the JWT */
        rv = atca_jwt_init(&jwt, buf, buflen);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))
        {
            return rv;
        }
 
        rv = atca_jwt_finalize(&jwt, 0);
 
        atcab_release();
    }
    return rv;
}

Listato 1: Un modulo incluso nel repository di esempi software di Microchip Technology per la piattaforma Google Cloud IoT Core, fornisce routine per generare un nome utente fittizio e un oggetto JWT da utilizzare come password per l'autenticazione client con un host MQTT. (Fonte del codice: Microchip Technology)

Anche se il dispositivo IoT invia un nome utente come parte di questa sequenza di accesso, non è questo il nome che viene utilizzato per l'autenticazione. Quindi, viene trasmesso un nome utente fittizio (Listato 2). Invece, l'autenticazione del dispositivo IoT procede sulla base del JWT inviato come password di accesso. Dato che la firma JWT è una combinazione di intestazione, payload e chiave privata del dispositivo, i servizi Google Cloud IoT Core possono verificare che il JWT proviene effettivamente da un dispositivo autorizzato. Per questa verifica, i servizi Google Cloud IoT si servono della chiave pubblica del dispositivo archiviata in precedenza nel cloud Google dallo sviluppatore del dispositivo IoT utilizzando un processo di gestione delle chiavi che viene descritto sotto. Contrariamente all'uso del solo TLS, questo approccio assicura l'autenticazione reciproca attraverso un approccio ibrido che accelera il processo, riducendo allo stesso tempo i requisiti del dispositivo IoT in materia di risorse.

Copy
/* Connect the MQTT Client to the host */
static int client_connect(void* pCtx)
{
    MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;
    struct _g_client_context* ctx = (struct _g_client_context*)pCtx;
    size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;
 
    mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;
    mqtt_options.cleansession = 1;
 
    /* Client ID String */
    mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];
    if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Username String */
    mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);
    if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Password String */
    mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);
    if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    return MQTTConnect(&ctx->mqtt_client, &mqtt_options);
}

Listato 2: Questa funzione, che si trova nel repository degli esempi di software di Microchip, dimostra l'uso di un oggetto JWT come password che autentica il dispositivo IoT presso il server MQTT durante la fase di connessione iniziale. (Fonte del codice: Microchip Technology)

Fattori determinanti cruciali

Le capacità di ATECC608A e della sua supply chain sono i fattori determinanti cruciali di questo approccio. Sebbene qualsiasi MCU potrebbe alla fine generare una firma crittografata dall'intestazione e dal payload JWT, qualsiasi approccio eseguito unicamente con il software sarebbe comunque vulnerabile senza l'archiviazione sicura delle chiavi basata su hardware. Inoltre, il carico del processore e il ritardo di esecuzione richiesti per un'implementazione "esclusivamente software" potrebbero essere proibitivi per molti dispositivi o molte applicazioni IoT con limiti di risorse e requisiti rigidi in materia di tempo di risposta. Senza contare poi che gli sviluppatori privi di una vasta esperienza in algoritmi di sicurezza e protocolli di livello superiore difficilmente sarebbero in grado di implementare le funzionalità software richieste. Microchip ha affrontato questo problema con la sua libreria CryptoAuthLib (Figura 2).

Figura 2: Dato che CryptoAuthLib si serve di un Hardware Abstraction Layer (HAL) per separare le funzioni API e le primitive core dall'hardware sottostante, gli sviluppatori possono realizzare un software mirato per una vasta gamma di dispositivi di supporto. (Immagine per gentile concessione di Microchip Technology)

CryptoAuthLib di Microchip semplifica l'implementazione di funzioni IoT sicure come il protocollo di autenticazione JWT di Google, riducendo le complesse operazioni di sicurezza a una serie di chiamate di funzione fornite tramite l'API (Application Programming Interface) CryptoAuthLib. Forse la cosa più importante per gli sviluppatori IoT è il fatto che le funzioni core della CryptoAuthLib di Microchip sfruttano abbondantemente i CI di crittografia di Microchip come ATECC608A per accelerare l'esecuzione delle funzionalità di sicurezza in un progetto. Ad esempio, la chiamata ad atca_jwt_finalize() nel Listato 1 si serve di un dispositivo di crittografia disponibile come ATECC608A per creare il JWT usato come password nel Listato 2. In questo caso, ATECC608A accelera la crittografia della firma JWT, leggendo la chiave privata del progetto dal suo archivio di sicurezza integrato per completare il processo di creazione della firma descritto in precedenza.

Malgrado l'uso di software e dispositivi di sicurezza sofisticati, tuttavia, i dispositivi IoT possono rimanere vulnerabili a causa dei metodi tradizionalmente richiesti per gestire chiavi e certificati. In passato, le chiavi private dovevano essere generate esternamente e caricate in dispositivi di memorizzazione sicuri durante la produzione, la distribuzione o persino durante l'implementazione. Anche in presenza di moduli di sicurezza hardware e strutture protette, l'esistenza passeggera di questi segreti al di fuori dell'unico dispositivo che "deve sapere" rappresenta un punto debole della sicurezza che li espone per caso o intenzionalmente. Sfruttando le capacità di ATECC608A, Microchip e Google hanno in gran parte eliminato questo che è da sempre un punto debole della sicurezza.

Nel nuovo approccio, Microchip si avvale della capacità di ATECC608A di generare coppie di chiavi senza che le chiavi private escano mai dal dispositivo (Figura 3). Microchip firma le chiavi pubbliche generate dal dispositivo con un certificato intermedio fornito dal cliente e conservato in un server sicuro all'interno della struttura protetta di Microchip. Infine, Microchip trasmette in modo sicuro le chiavi pubbliche all'account del cliente in Google Cloud IoT Device Manager, in grado di contenere fino a tre chiavi pubbliche per ogni dispositivo per supportare le politiche di rotazione delle chiavi. Una volta implementato, un dispositivo IoT può utilizzare le funzionalità di sicurezza di ATECC608A per creare il JWT utilizzato nel processo di autenticazione reciproca descritto in precedenza.

Figura 3: I servizi di Microchip Technology e di Google Cloud IoT si alleano per semplificare la creazione di chiavi e certificati, offrendo un meccanismo protetto studiato per rafforzare la sicurezza per le applicazioni IoT. (Immagine per gentile concessione di Google)

Questa collaborazione tra Microchip e Google ha permesso di togliere agli sviluppatori il peso di questo processo cruciale di gestione delle chiavi. In caso di requisiti personalizzati, gli sviluppatori possono comunque implementare il proprio processo di gestione delle chiavi, utilizzando la funzione dell'API CryptoAuthLib atcab_genkey(), grazie alla quale ATECC608A genera una coppia di chiavi, archivia la chiave privata nella sua memoria protetta e restituisce la chiave pubblica associata.

Per rendersi conto delle capacità di generazione delle chiavi e di altre capacità di sicurezza di ATECC608A, gli sviluppatori possono creare rapidamente un ambiente di sviluppo completo costruito intorno al kit di valutazione SAM D21 Xplained Pro di Microchip. Basato sull'MCU Arm^® Cortex^®-M0+ a 32 bit ATSAMD21J18A di Microchip, il kit SAM D21 Xplained Pro mette a disposizione una piattaforma hardware completa supportata dall'Advanced Software Framework (ASF) di Microchip di driver e moduli di codice.

Per valutare dispositivi CryptoAuthentication come ATECC608A, gli sviluppatori possono semplicemente inserire una scheda supplementare CryptoAuth XPRO-B in una delle due basette di espansione della scheda Xplained Pro. Microchip fornisce un software di esempio per valutare le funzionalità di sicurezza di CryptoAuthLib con ATECC608A. Spingendosi oltre, gli sviluppatori possono inserire nell'altra basetta una scheda supplementare Wi-Fi ATWINC1500-XPRO di Microchip per eseguire il software di esempio di Microchip per dimostrare il flusso di autenticazione reciproca descritto in questo articolo, compresa l'autenticazione del server TLS e quella del dispositivo JWT.

Conclusione

Sebbene la sicurezza delle applicazioni IoT comporti diversi requisiti, spesso la sfida cruciale viene dall'implementazione dell'autenticazione reciproca per i dispositivi IoT e le risorse cloud. Nei sistemi IoT con risorse limitate, i protocolli convenzionali possono richiedere memoria e risorse di elaborazione superiori a quelle disponibili. L'uso della libreria CryptoAuthLib di Microchip Technology e del CI CryptoAuthentication ATECC608A permette agli sviluppatori di adottare un approccio più efficiente basato su JSON Web Token per collegare in modo sicuro i dispositivi IoT ai servizi Google Cloud IoT.