Aggiornamenti firmware over-the-air per dispositivi IoT

Un aggiornamento via etere (OTA) installa il nuovo firmware su un dispositivo attraverso la sua rete radio. Un misuratore o un sensore rimane in servizio per dieci anni o più, e in quel periodo è probabile che si riscontrino guasti nello stack radio o nel codice dell'applicazione. Su un patrimonio di 400 dispositivi in 20 siti, una correzione applicata manualmente significa 20 visite al sito. La stessa correzione via radio è una campagna pianificata eseguita dal gateway.

Questa guida fa parte del percorso reti e architettura.

Perché i dispositivi da campo necessitano di aggiornamenti

Il caso Zigbee meglio documentato è l'attacco che Ronen, O'Flynn, Shamir e Weingarten hanno pubblicato nel 2016 contro le lampade Philips Hue. Il firmware delle lampade è autenticato con una chiave AES-CCM condivisa da ogni lampada dello stesso tipo. I ricercatori hanno estratto quella chiave analizzando la potenza, con apparecchiature che costavano poche centinaia di dollari. Con la chiave, potevano creare un firmware che ogni lampada di quel tipo accettava come autentico, e un bug nel codice Zigbee Light Link delle lampade permetteva all'immagine dannosa di diffondersi da una lampada all'altra. Philips ha corretto il bug di acquisizione e ha reso la correzione disponibile come aggiornamento OTA. L'estrazione della chiave ha mostrato perché un'immagine deve portare una firma che il dispositivo verifica con una chiave pubblica.

I bug contano tanto quanto gli attacchi. Un guasto che danneggia un contatore di impulsi o scollega un dispositivo dalla rete dopo il riavvio del router principale deve essere riparato su ogni unità interessata. NIST SP 800-82 Rev. 3, sezione 6.2.11, chiede agli operatori OT un processo documentato di gestione delle patch: come apprendere le patch, come testarle, quando applicarle e quali controlli di compensazione utilizzare mentre una patch è in ritardo. Dice anche di distribuire le patch durante le interruzioni pianificate. I passaggi della campagna riportati di seguito seguono questo schema.

Come funziona Zigbee

I dispositivi Zigbee utilizzano il cluster di aggiornamento OTA, ID cluster 0x0019, definito nel capitolo 11 della Zigbee Cluster Library (ZCL). Il gateway è il server OTA e contiene i file di immagine. Il dispositivo è il client OTA e guida il download.

Ogni file OTA inizia con l'identificatore 0x0BEEF11E e un'intestazione che indica il codice del produttore, il tipo di immagine, la versione del file e la dimensione totale dell'immagine. Può anche fornire una versione hardware minima e massima. Il server usa il codice del produttore e il tipo di immagine per selezionare un'immagine candidata. Verifica modello esatto, revisione hardware e file approvato dal produttore: la sola corrispondenza degli identificatori nell'intestazione non ne dimostra l'idoneità.

Lo scambio viene eseguito in questo ordine:

1. Il server può inviare Image Notify per annunciare un'immagine disponibile. Non può avvisare subito e in modo affidabile un dispositivo finale dormiente; questi client inviano quindi periodicamente Query Next Image Request, con codice del produttore, tipo di immagine e versione corrente.
2. Il server risponde con Query Next Image Response: la versione del file che offre e la dimensione dell'immagine.
3. Il client invia una Image Block Request con l'offset del file di cui ha bisogno e il blocco più grande che può accettare. Il server restituisce tali dati in Image Block Response. Il client lo ripete finché non ha l'intero file. Il client, non il server, tiene traccia dell'avanzamento, quindi il server mantiene poco stato per dispositivo.
4. Il client controlla l'immagine e invia Upgrade End Request con lo stato SUCCESS o INVALID_IMAGE.
5. Il server risponde con Upgrade End Response, che comporta un istante di aggiornamento. Il client passa alla nuova immagine in quel momento. Un valore di 0xFFFFFFFF gli dice di attendere un comando successivo, che consente al server di attivare insieme la nuova immagine su un gruppo di dispositivi.

La ZCL richiede un bootloader applicativo e memoria aggiuntiva per l'intera nuova immagine prima dell'attivazione. Ciò consente il download mentre è in esecuzione l'immagine precedente, ma non garantisce la continuità dell'applicazione o delle trasmissioni. Verifica l'implementazione del dispositivo e il carico di rete; il riavvio con la nuova immagine interrompe il servizio.

Tempo di aggiornamento Zigbee

La dimensione dei blocchi limita gli aggiornamenti di Zigbee. Il client imposta una dimensione massima dei dati in ogni richiesta. Lo ZCL consente al server di inviare meno di quello per tenere conto dell’overhead del routing quando il client è a diversi hop di distanza e le implementazioni dei server comuni inviano 50 byte di dati di immagine per blocco. Un'immagine da 200 kB è quindi composta da 4.000 blocchi e ogni blocco è una richiesta e una risposta che attraversa ogni hop. Se un viaggio di andata e ritorno attraverso due salti dura un quarto di secondo, il trasferimento dura circa 17 minuti. Ciò è coerente con i 10-20 minuti mostrati da Edge prima di un aggiornamento.

Due cose lo rendono più lungo. Il server può limitare la velocità di un client tramite l'attributo MinimumBlockPeriod, un ritardo minimo in millisecondi tra le richieste di blocco. Lo ZCL fornisce l'esempio di limitare ogni client a un blocco ogni 500 ms mentre più download procedono contemporaneamente, il che raddoppia i 17 minuti. E un dispositivo dormiente riceve i dati solo quando interroga il suo genitore. Lo ZCL consente di richiedere i blocchi più lentamente di quanto consentito dal server, per risparmiare batteria, quindi un sensore a batteria può richiedere ore.

Firma dell'immagine

La ZCL incoraggia fortemente una firma effettuata con la chiave privata del produttore, che il dispositivo verifica con la chiave pubblica corrispondente una volta completato il download (clausola 11.3.3.1). Non la richiede. Ciascuno standard applicativo stabilisce il proprio minimo. Smart Energy può utilizzare firme di immagini insieme alla crittografia di rete e APS, mentre altri standard possono utilizzare solo la crittografia di rete (clausola 11.3.2). Senza firma, un hash dell'immagine (clausola 11.3.3.2) mostra che il file è arrivato intatto, ma non chi lo ha creato. Alcuni produttori aggiungono il proprio controllo nel bootloader. Chiedi al produttore quale metodo utilizza il dispositivo. Una chiave simmetrica è sicura tanto quanto il dispositivo meno protetto che la contiene, come ha dimostrato l'attacco della lampada.

Come funziona LoRaWAN

I downlink LoRaWAN sono piccoli e scarsi, quindi la LoRa Alliance ha creato l'aggiornamento del firmware via etere (FUOTA) come un insieme di pacchetti a livello di applicazione. La sintesi del processo FUOTA, TR002, li mette insieme:

• TS003, sincronizzazione dell'orologio del livello applicativo, fornisce a ogni dispositivo l'ora della rete, in modo che una sessione multicast possa iniziare in un momento concordato.
• TS005, configurazione multicast remota, fornisce ai dispositivi un indirizzo multicast e chiavi condivisi e pianifica una sessione di Classe C o Classe B. Un dispositivo che esegue solo la Classe A non può prendere parte a una sessione multicast. Può ricevere frammenti solo tramite unicast, nelle finestre di ricezione successive ai propri uplink.
• TS004, trasporto di blocchi dati frammentati, divide l'immagine in frammenti e aggiunge la correzione degli errori in avanti. Con una ridondanza del 10%, un dispositivo può perdere circa il 10% dei frame e ricostruire comunque il file senza richiedere quelli mancanti. Una sessione può contenere al massimo 16.383 frammenti.
• TS006, il protocollo di gestione del firmware, segnala e controlla la versione del firmware sul dispositivo.

Quando un dispositivo ha abbastanza frammenti, ricostruisce l'immagine, controlla la sua firma digitale con la chiave pubblica del server di aggiornamento e controlla che l'intestazione corrisponda al suo hardware e al firmware corrente. Segna l'immagine pronta e si riavvia. Il bootloader lo installa quindi in una seconda area immagine o pagina per pagina con i suoi progressi memorizzati, in modo che un'interruzione di corrente durante la scrittura non lasci il dispositivo senza firmware. Questo è il processo raccomandato da TR002: il solo supporto al trasporto dei frammenti non dimostra la verifica delle firme né il recupero dopo un'interruzione di alimentazione. Verifica queste funzioni sul dispositivo e sul bootloader esatti.

Tempo di aggiornamento LoRaWAN

Prendi un'immagine da 100 kB inviata dal multicast di Classe C in EU868, sulla frequenza RX2 predefinita di 869,525 MHz a DR0 (SF12, 125 kHz):

• RP002 limita il payload dell'applicazione su DR0 a 51 byte. Il comando TS004 DataFragment ne utilizza 3, lasciando 48 byte di immagine per frame.
• 100 kB corrispondono a 2.084 frammenti. Con una ridondanza del 10% il server invia circa 2.300 frame.
• Ogni frame corrisponde a circa 2,8 s di tempo di trasmissione a SF12.
• La raccomandazione ERC 70-03 limita la banda da 869,40 a 869,65 MHz a un ciclo di lavoro del 10%. Il gateway può trasmettere per 360 secondi all'ora, ovvero circa 129 frame all'ora.

I frame utilizzano circa 1,8 ore di tempo di trasmissione del gateway, distribuite su circa 18 ore con un limite del ciclo di lavoro del 10%. Il gateway condivide tale quota con ogni altro downlink che invia su quel canale. Al DR5 (SF7), in ogni frame ci stanno 239 byte e la stessa immagine richiede circa 460 frame da 0,39 s: circa 30 minuti sotto lo stesso limite. Ma ogni dispositivo del gruppo deve ricevere SF7 in modo affidabile, e i dispositivi al limite della copertura spesso non lo fanno. L’invio unicast a un dispositivo di Classe A è ancora più lento. Con circa un frammento per ciascun uplink, un dispositivo che invia report ogni 15 minuti necessita di più di 3 settimane per gli stessi 2.300 frame.

Il supporto varia in base al modello. Controlla quali pacchetti FUOTA implementa il dispositivo, se può aprire una sessione di Classe B o Classe C e se ha lo spazio flash per contenere una seconda immagine.

Pianificare una campagna di aggiornamento

1. Elenca ciascun dispositivo con il modello, la revisione dell'hardware, il codice del produttore, il tipo di immagine e la versione corrente del file.
2. Leggere le note sulla versione. Verificare se l'aggiornamento modifica un valore, un'unità, un fattore di scala o un registro letto dal sistema. Un fattore di scala modificato fornisce letture che sembrano valide e che sono errate.
3. Chiedi al produttore se l'immagine è firmata, se il dispositivo accetta una versione di file precedente e se il suo bootloader mantiene l'immagine precedente.
4. Aggiorna prima un gruppo pilota. Includere la revisione hardware più vecchia, un dispositivo all'estremità della rete mesh e un dispositivo a batteria, se presente nel sito.
5. Aggiornare il resto in piccoli gruppi, ad esempio cinque dispositivi alla volta su un gateway, con un ritardo tra di loro. Guarda i dispositivi che non vengono aggiornati. Rapporti tardivi o mancanti da parte loro indicano che la mesh è satura, quindi riduci le dimensioni del gruppo.
6. Al termine di ogni dispositivo, leggere la versione dal dispositivo. Su Zigbee questo è l'attributo CurrentFileVersion del cluster OTA, ovvero la versione riportata tramite il cluster Basic. Quindi controlla che il dispositivo segnali nei tempi previsti e confronta le sue letture con quelle precedenti all'aggiornamento.

Quando un aggiornamento fallisce

Lo ZCL non ha alcun comando di rollback. Consente al server di offrire una versione del file inferiore a quella installata, ma il firmware del dispositivo decide se accettarla. Il metodo di recupero è lasciato al produttore (punto 11.18). Gli esempi nelle specifiche sono un bootloader che scambia la nuova immagine con quella precedente e la pressione di un pulsante all'accensione che ritorna all'immagine precedente. Se il dispositivo non ha nessuno dei due, una cattiva immagine significa una visita al sito.

Le lacune nei dati possono verificarsi sia durante il download sia al riavvio. Un registro di energia cumulativa può conservare il totale durante un'interruzione delle trasmissioni solo se la misura continua e il contatore supera l'aggiornamento senza azzeramenti o rollover non gestiti. Non recupera lo storico mancante della potenza o della temperatura istantanea. La guida ai dati obsoleti spiega come mostrare la lacuna.

Il firmware del dispositivo e il software del gateway sono separati

Il gateway è il server OTA. Conserva le immagini e risponde a ogni richiesta di blocco, quindi un aggiornamento del software del gateway che lo riavvia durante una campagna interrompe ogni trasferimento in corso. Completa o metti in pausa una campagna per dispositivo prima di aggiornare il gateway. Inizia la campagna successiva solo quando il gateway aggiornato è stabile e ogni dispositivo segnala nuovamente.

Aggiornamenti firmware con Edge

Edge sul ZGW-20 Gateway mantiene un catalogo di immagini firmware sul Gateway. Accetta tre tipi di file, fino a 5 MB ciascuno: file Zigbee OTA (.ota) per dispositivi di terze parti, immagini EBL (.ebl) per dispositivi EpiSensor e immagini binarie (.bin) per la scheda IO. Edge convalida ciascun file quando viene caricato e lo elenca con produttore, modello, versione, dimensione e validità.

Un aggiornamento può iniziare immediatamente o in un momento pianificato. Può prendere di mira un dispositivo o una selezione di dispositivi. Per una selezione, Edge invia il comando a turno a ciascun dispositivo con un ritardo fino a 60 s tra loro, quindi i trasferimenti non iniziano tutti insieme. Edge avverte che un aggiornamento può richiedere da 10 a 20 minuti per dispositivo e che il dispositivo potrebbe riavviarsi e mostra ogni aggiornamento come in esecuzione, completato o non riuscito. Edge stesso viene aggiornato tramite il suo canale Snap o l'app desktop, non da questo catalogo.