Come si gestiscono e si aggiornano via OTA le flotte di dispositivi IoT?

Mettere sul mercato un dispositivo connesso è l’inizio di una relazione che può durare dieci anni. In quel periodo il dispositivo avrà bisogno di nuovo firmware per correggere bug e vulnerabilità, di modifiche alla configurazione, di nuove credenziali quando le vecchie scadono e, alla fine, di un ritiro controllato. Farlo per dieci dispositivi in laboratorio è facile. Farlo per centomila dispositivi nelle case dei clienti e dentro le macchine, su reti che non controlli, è la gestione dei dispositivi.

La capacità che conta di più è l’aggiornamento OTA (over the air). Le normative sulla sicurezza che stanno entrando in vigore danno per scontato che i dispositivi possano ricevere patch da remoto, e una flotta che non si può aggiornare è una flotta la cui prima vulnerabilità seria resta aperta per sempre. Questa guida copre l’intero ciclo di vita del dispositivo e poi approfondisce come eseguire l’OTA in sicurezza.

Com’è fatto il ciclo di vita di un dispositivo?

Un dispositivo attraversa una sequenza prevedibile di stati, e ciascuno richiede strumenti.

Produzione. Il dispositivo riceve la sua identità: un numero di serie univoco e, idealmente, una coppia di chiavi crittografiche con un certificato firmato dalla PKI del produttore. Le chiavi generate dentro un secure element non lasciano mai il chip. Farlo sulla linea di produzione, anziché sul campo, è ciò che rende sicuri i passi successivi.

Provisioning. Il provisioning è il modo in cui il back end arriva a conoscere il dispositivo e a considerarlo affidabile. Con i certificati di fabbrica è automatico: il dispositivo si connette, presenta il certificato e la piattaforma lo registra nel registro dei dispositivi nella flotta giusta. Senza credenziali di fabbrica, un token di bootstrap viene scambiato con un’identità vera, un metodo più debole e più difficile da scalare.

Commissioning. Il commissioning, la messa in servizio, è la configurazione specifica del sito: assegnare il dispositivo a una posizione, collegarlo alla rete locale, calibrare i sensori, associarlo all’asset che monitora. App per installatori e codici QR sono gli strumenti abituali.

Esercizio. Il dispositivo invia i dati, riceve configurazioni e comandi e manda heartbeat perché la piattaforma sappia che è vivo. Le viste di gestione della flotta mostrano lo stato per gruppi, e i device shadow conservano la configurazione desiderata e quella riportata, così che le modifiche si applichino anche ai dispositivi in sleep.

Manutenzione. Aggiornamenti del firmware, rotazione dei certificati e modifiche alla configurazione, trattati più avanti.

Dismissione. Il dispositivo viene ritirato: credenziali revocate, politiche di conservazione dei dati applicate e memoria cancellata, così che un dispositivo rivenduto di seconda mano non porti con sé le chiavi del proprietario precedente. Questo passo viene regolarmente dimenticato.

Come si monitora la flotta?

La visibilità operativa è l’uso quotidiano della gestione dei dispositivi. I segnali di base sono lo stato della connessione, l’ora dell’ultimo contatto, la versione del firmware, l’autonomia della batteria, la qualità del segnale e i contatori di errore. I dispositivi diventati silenziosi sono la prima cosa da cercare, e solo il quadro d’insieme della flotta dice se la causa è un’interruzione di rete, un aggiornamento difettoso o un lotto hardware.

La diagnostica remota, come scaricare i log o eseguire un autotest, è fatta di comandi, e richiede la stessa disciplina di autorizzazione e di audit di qualsiasi altro comando.

Come funziona un aggiornamento over the air?

Un aggiornamento OTA sostituisce il firmware di un dispositivo senza accesso fisico: la piattaforma annuncia una nuova immagine, il dispositivo la scarica, la verifica, la scrive nella memoria flash e si riavvia con la nuova versione. Ogni passo nasconde un modo per rendere il dispositivo inutilizzabile (in gergo, “brick”), e la progettazione consiste nell’eliminare quei modi.

Verifica dell’immagine

Il dispositivo deve verificare l’immagine prima di installarla. L’immagine è firmata con la chiave privata del produttore; il dispositivo possiede la chiave pubblica corrispondente e controlla la firma e l’hash. Questo impedisce a un attaccante che controlla la rete, o persino il server di aggiornamento, di installare firmware malevolo. Insieme al secure boot, che verifica di nuovo l’immagine a ogni accensione, stabilisce una root of trust che va dall’hardware all’applicazione.

La protezione anti-rollback, con cui il dispositivo rifiuta un’immagine con versione inferiore a quella in esecuzione, impedisce a un attaccante di reinstallare un vecchio firmware con vulnerabilità note.

Sopravvivere ai guasti

La protezione classica è la memoria flash a doppio banco (A/B): il dispositivo mantiene due slot per il firmware, scrive la nuova immagine nello slot inattivo e il bootloader passa a quello al riavvio. Se il nuovo firmware non conferma di essere integro entro un tempo prestabilito, un watchdog timer forza un riavvio e il bootloader torna al vecchio slot. Questo raddoppia la flash necessaria, un costo reale sui piccoli microcontrollori, ed è il motivo per cui alcuni dispositivi a risorse limitate usano invece un singolo slot con una piccola immagine di ripristino.

La perdita di alimentazione durante la scrittura si gestisce scrivendo l’intera immagine prima di cambiare il puntatore di avvio, e le interruzioni del download con trasferimenti a blocchi riprendibili, con un checksum per ogni blocco. “Integro” va definito in modo concreto; una definizione comune è che il nuovo firmware si connetta alla piattaforma e riporti la propria versione entro pochi minuti.

Consegna dell’immagine

Il trasporto dipende dal collegamento. I dispositivi Wi-Fi e cellulari di solito scaricano via HTTPS da un URL fornito in un comando MQTT, con un URL firmato a breve scadenza perché l’archivio delle immagini non sia pubblico. Per i dispositivi dietro un gateway su Zigbee o Thread, il gateway scarica una volta sola e distribuisce in locale. Per LoRaWAN, dove la capacità in downlink è minuscola, gli aggiornamenti usano le estensioni multicast e di frammentazione della LoRa Alliance e richiedono molto tempo, un buon motivo per fare bene il firmware LoRaWAN la prima volta.

Gli aggiornamenti differenziali (delta), che inviano solo la differenza tra la vecchia e la nuova immagine, riducono drasticamente la dimensione del download e valgono la complessità aggiuntiva su collegamenti lenti o a consumo. LwM2M definisce un oggetto standard per gli aggiornamenti del firmware (Object 5, Firmware Update) che molti stack per dispositivi a risorse limitate implementano.

Rollout

Mai aggiornare l’intera flotta in un colpo solo. Un rollout graduale invia l’immagine prima a un piccolo gruppo canary, aspetta che confermi la propria integrità, poi si allarga a passi, con una pausa automatica se il tasso di guasti sale. I gruppi possono essere scelti per revisione hardware, regione o cliente. Un piano di rollback dovrebbe esistere prima che il rollout inizi, e la piattaforma dovrebbe poter puntare a una versione precedente con la stessa facilità di una nuova.

I dispositivi che hanno un compito da svolgere dovrebbero aggiornarsi durante una finestra di manutenzione, e quelli a batteria solo quando la carica è sufficiente per completare l’operazione.

Come si gestiscono configurazione e credenziali?

Non ogni modifica richiede un nuovo firmware. Intervalli di invio, soglie, endpoint e feature flag dovrebbero essere configurazione, consegnata tramite il device shadow o un oggetto di configurazione, così che il dispositivo la recuperi al prossimo contatto. Tenere la configurazione separata dal codice rende il firmware più semplice e gli aggiornamenti più rari.

I certificati scadono, e una flotta i cui certificati scadono tutti lo stesso giorno è un’interruzione del servizio annunciata. La rotazione dovrebbe essere automatizzata, scaglionata e testata, con una procedura di ripristino se fallisce a metà. La guida sull’identità dei dispositivi copre la gestione dei certificati.

Come si scelgono o si costruiscono gli strumenti?

La maggior parte delle piattaforme IoT offre registro, shadow, job e funzioni OTA, ed esistono framework di aggiornamento open source per i dispositivi basati su Linux. Conviene verificare che lo strumento supporti i rollout graduali con pausa automatica, gli aggiornamenti differenziali, il bootloader e il layout della flash del dispositivo in uso e la distribuzione mediata dal gateway. Costruire l’OTA da zero è ragionevole solo per team con competenze di sicurezza embedded.

Per continuare

• Le piattaforme IoT spiegate confronta le piattaforme che forniscono queste funzioni di gestione.
• Identità dei dispositivi, certificati e PKI per l’IoT copre le credenziali da cui dipendono provisioning e rotazione.
• Fondamenti di sicurezza IoT spiega perché contano secure boot e aggiornamenti firmati.
• Tipi di dispositivi IoT e i vincoli che ne determinano la progettazione descrive i limiti di flash e alimentazione che condizionano la progettazione dell’OTA.

Argomenti: gestione dei dispositivi, OTA, firmware, gestione della flotta, ciclo di vita