Come danno un'identità a un dispositivo IoT i certificati e la PKI?

Ogni controllo di sicurezza in un sistema IoT, prima o poi, pone la stessa domanda: quale dispositivo è questo? La cifratura è inutile se dall’altra parte c’è un impostore, l’autorizzazione non ha senso senza un soggetto, e un log di audit che dice “un sensore ha riportato questo valore” non vale nulla se qualsiasi sensore avrebbe potuto dirlo. L’identità del dispositivo è il fondamento su cui poggia tutto il resto.

La risposta matura è la stessa che usa il web: chiavi asimmetriche e certificati gestiti da un’infrastruttura a chiave pubblica (PKI). La versione IoT ha le sue complicazioni, perché i dispositivi vengono prodotti in fabbrica da terzisti, non hanno una tastiera, possono restare in servizio quindici anni e si contano a milioni.

Questa guida spiega cos’è un certificato di dispositivo, come caricarlo su un dispositivo senza far trapelare la chiave, come lo usano server e broker, e come mantenere il sistema funzionante per l’intero ciclo di vita del dispositivo.

Perché non password o segreti condivisi?

Una password o un token API è un segreto che entrambe le parti conoscono. Se il token di un dispositivo trapela, da un dump del firmware, da un file di log o da un ticket di assistenza gestito con leggerezza, un attaccante può impersonare quel dispositivo finché qualcuno non se ne accorge e lo ruota. Se tutta la flotta condivide lo stesso token, una sola fuga compromette ogni unità.

Una coppia di chiavi separa le due parti. La chiave privata viene generata sul dispositivo e non lo lascia mai. La chiave pubblica, racchiusa in un certificato, può essere diffusa liberamente. Il server verifica una firma prodotta con la chiave privata; non ha mai bisogno della chiave in sé. Un server compromesso non rivela nulla che permetta di impersonare un dispositivo, e un dispositivo compromesso compromette soltanto se stesso.

Cosa contiene un certificato di dispositivo?

Un certificato X.509 lega una chiave pubblica a un nome ed è firmato da un emittente. Per un dispositivo, il nome del soggetto contiene di solito un numero di serie o un identificativo hardware, l’emittente è l’autorità di certificazione (CA) del produttore o dell’operatore, e il periodo di validità può essere lungo, spesso anni, perché ruotare i certificati su dispositivi a risorse limitate è costoso.

Le chiavi a curva ellittica, in genere sulla curva P-256, sono la norma nell’IoT. Sono compatte, veloci da calcolare su un microcontrollore e supportate da ogni secure element e da ogni stack TLS che conti. Le chiavi RSA funzionano, ma su hardware a risorse limitate sono più lente e più ingombranti.

Una catena di certificati permette a un server di fidarsi di molti dispositivi fidandosi di una sola radice. Una struttura comune prevede una CA radice offline a lunga durata, una CA intermedia per linea di prodotto o per fabbrica, e certificati foglia per ogni dispositivo. La compromissione di una CA intermedia di fabbrica si contiene revocando quell’intermedia, non l’intera radice.

Cosa sono i certificati di nascita e i certificati operativi?

Uno schema utile, formalizzato in IEEE 802.1AR, distingue due tipi di identità. Il produttore installa in fase di produzione un’identità iniziale del dispositivo (un IDevID, a volte chiamato certificato di nascita). Dimostra che il dispositivo è un prodotto autentico di quel costruttore e non cambia mai. Quando il dispositivo viene messo in servizio, l’operatore emette un’identità a validità locale (un LDevID, o certificato operativo) che attesta l’appartenenza al sistema di quell’operatore e può essere ruotata o revocata secondo necessità.

Matter usa esattamente questa struttura: un certificato di attestazione del dispositivo rilasciato dal produttore, verificato durante il commissioning, seguito da un certificato operativo emesso dal controller della casa. Le piattaforme cloud come AWS IoT Core e Azure IoT Hub supportano flussi analoghi.

Come si caricano le chiavi sui dispositivi in sicurezza?

Il provisioning è il punto in cui la maggior parte degli schemi di identità si rompe. Le opzioni, dalla più debole alla più robusta:

• Iniettare una chiave e un certificato pregenerati durante il flashing. Semplice, ma la chiave esiste fuori dal dispositivo, su un PC di produzione o in un file inviato al terzista, e ogni copia è un rischio.
• Generare la chiave sul dispositivo al primo avvio e inviare una richiesta di firma del certificato (CSR) a una CA. La chiave privata non lascia mai il dispositivo, ma la prima connessione va autenticata in qualche modo, di solito con un token monouso o una credenziale di bootstrap precondivisa, e quel flusso iniziale va protetto dagli attacchi replay.
• Usare un secure element o un SoC con chiave e certificato già provisionati dal produttore del chip. Il produttore del silicio genera la chiave in una struttura sicura e consegna il chip con un certificato già firmato dalla propria CA. Il team di prodotto deve soltanto fidarsi di quella CA. Questo toglie del tutto la fabbrica dall’equazione della fiducia ed è l’opzione più robusta per i prodotti ad alti volumi.

Qualunque sia la via scelta, la chiave privata dovrebbe risiedere in hardware che non la consegnerà mai: un secure element, un TPM o l’archivio chiavi protetto del SoC. Una chiave in memoria flash non protetta se ne va con il primo dump del firmware.

Come si usa l’identità in esercizio?

Il dispositivo presenta il proprio certificato durante l’handshake TLS o DTLS, e il server fa lo stesso. Questa autenticazione reciproca è ciò che permette a un broker MQTT di associare una connessione a un dispositivo noto prima che arrivi qualsiasi messaggio. Le regole di autorizzazione del broker fanno poi riferimento al soggetto del certificato: il dispositivo 1234 può pubblicare su devices/1234/telemetry e sottoscrivere devices/1234/commands, e nient’altro.

La stessa chiave può firmare i dati a livello applicativo, cosa che conta quando i messaggi attraversano intermediari. Un gateway che inoltra le letture non può falsificarle se ciascuna è firmata dal dispositivo che l’ha prodotta, il che garantisce cifratura end-to-end e integrità anche attraverso nodi intermedi non fidati.

L’attestazione estende l’identità da “chi è questo dispositivo” a “cosa sta eseguendo”. Un dispositivo con una catena di avvio misurata può firmare un rapporto con gli hash del proprio firmware usando una chiave legata al suo root of trust, e un back end può negare il servizio ai dispositivi che eseguono codice sconosciuto o obsoleto.

Come si ruotano, revocano e ritirano i certificati?

I certificati scadono, ed è una caratteristica voluta: una credenziale scaduta obbliga a un controllo. La rotazione dovrebbe essere automatizzata attraverso il canale di gestione dei dispositivi, con una nuova CSR emessa ben prima della scadenza. I dispositivi che perdono la finestra hanno bisogno di un percorso di recupero, di solito ricadendo sull’identità del produttore per registrarsi di nuovo.

La revoca è più difficile nell’IoT che sul web. Le liste di revoca dei certificati crescono molto, e le verifiche OCSP sono costose su un collegamento a banda limitata. La maggior parte delle piattaforme gestisce invece la revoca nel registro dei dispositivi: un dispositivo revocato viene semplicemente disabilitato lì, e il broker ne rifiuta la connessione a prescindere dalla validità del certificato. Funziona solo se ogni servizio consulta il registro.

Alla dismissione, il certificato operativo del dispositivo viene revocato, la sua voce nel registro viene contrassegnata come dismessa e, idealmente, al dispositivo stesso viene ordinato di cancellare le proprie chiavi, così un’unità rivenduta non può riconnettersi.

Quando una PKI completa è eccessiva?

Un progetto hobbistico con una manciata di dispositivi dietro il router di casa può vivere con chiavi precondivise. Un prodotto venduto ai clienti no, perché il costo di un incidente di impersonificazione supera quello di progettare uno schema di identità come si deve. La via di mezzo praticabile per i team piccoli è usare i servizi di certificazione integrati in una piattaforma IoT cloud, che si occupano della CA, della rotazione e dell’integrazione con il registro, e mettere la chiave privata in un secure element fin dal primo giorno.

Per continuare

• Fondamenti di sicurezza IoT inquadra il panorama più ampio delle minacce di cui l’identità fa parte.
• Gestione dei dispositivi e aggiornamenti over the air spiega il canale attraverso cui si ruotano i certificati e si firma il firmware.
• MQTT spiegato mostra come l’autorizzazione del broker usa in pratica l’identità del certificato.

Argomenti: identità dei dispositivi, PKI, X.509, certificati, secure element, provisioning