Aggiornamento firmware OTA sicuro via Bluetooth Low Energy
La manutenzione di un dispositivo embedded non termina quando il prodotto viene installato presso il cliente. Nel corso della sua vita operativa può essere necessario correggere anomalie, distribuire aggiornamenti di sicurezza, modificare la logica applicativa o introdurre nuove funzioni.
In molti sistemi industriali e IoT, tuttavia, il dispositivo non dispone di una connessione Internet permanente. Può essere installato all'interno di una macchina, alimentato a batteria, integrato in un impianto isolato o raggiungibile esclusivamente durante un intervento tecnico.
SLX Field Device Manager è un progetto sviluppato da Silicon Logix per gestire l'identificazione, la diagnostica e l'aggiornamento firmware OTA tramite Bluetooth Low Energy. Il sistema è stato realizzato su Nordic nRF5340-DK utilizzando Zephyr, nRF Connect SDK, MCUboot e MCUmgr SMP.
L'obiettivo non è trasferire semplicemente un file al dispositivo. Il target deve verificare l'autenticità dell'immagine, controllare che l'aggiornamento sia autorizzato, impedire regressioni non consentite e mantenere una possibilità di recupero quando la nuova applicazione non raggiunge uno stato operativo valido.
Aggiornamento locale per dispositivi industriali non collegati a Internet
Bluetooth Low Energy consente a un tecnico di collegarsi localmente al dispositivo tramite computer, tablet o smartphone compatibile, senza richiedere una connessione Internet diretta del prodotto.
Il browser può recuperare il pacchetto autorizzato e mostrare lo stato del dispositivo, mentre il trasferimento del firmware avviene direttamente sul collegamento BLE locale. Il target mantiene il controllo sull'accettazione dell'aggiornamento e non dipende esclusivamente dalla correttezza dell'interfaccia web.
Questo modello può essere utilizzato per la manutenzione di:
- sensori e attuatori industriali;
- strumenti di misura portatili;
- dispositivi Bluetooth Low Energy alimentati a batteria;
- controller installati all'interno di macchine;
- prodotti IoT privi di connettività IP;
- prototipi e pre-serie utilizzati durante prove sul campo;
- apparati aggiornabili esclusivamente da personale autorizzato.
La connessione BLE diventa così un canale locale di assistenza, utile non soltanto per il trasferimento del firmware, ma anche per identificare il dispositivo, leggere la diagnostica e verificare l'esito dell'intervento.
Nordic nRF5340-DK: la piattaforma hardware utilizzata per lo sviluppo
Il progetto è stato sviluppato e verificato sulla Nordic nRF5340-DK, development kit ufficiale basato sul System-on-Chip nRF5340.
La scheda mette a disposizione il SoC dual-core, il debugger e programmatore integrato, pulsanti e LED programmabili, connettori per periferiche esterne e punti utili alla misura dei consumi. Queste caratteristiche permettono di osservare il comportamento del firmware durante le fasi di boot, aggiornamento, reset, conferma e rollback.
Nel progetto la DK non viene utilizzata come semplice supporto per un esempio software. Sulla scheda sono stati integrati:
- MCUboot e gestione degli slot firmware;
- applicazione Zephyr;
- controller Bluetooth Low Energy sul Network Core;
- trasporto OTA tramite MCUmgr SMP;
- servizio GATT di diagnostica;
- service mode temporizzato;
- health check e conferma dell'immagine;
- policy Silicon Logix applicate sul target;
- gestione del lease e dello stato persistente.
Pulsanti e reset della scheda consentono inoltre di simulare azioni fisiche di manutenzione, come l'attivazione della finestra OTA o il mancato completamento della conferma del firmware.
La nRF5340-DK è una piattaforma di sviluppo e valutazione. In una fase successiva, l'architettura può essere trasferita su una scheda elettronica personalizzata, progettata in funzione di dimensioni, alimentazione, antenna, periferiche e requisiti ambientali del prodotto finale.
Architettura dual-core: applicazione e connettività separate
Il Nordic nRF5340 integra due processori Arm Cortex-M33 programmabili. Questa architettura permette di separare la logica applicativa dalle funzioni wireless.
L'Application Core esegue l'applicazione principale, la diagnostica, le policy OTA, lo stato persistente e i controlli che stabiliscono se una nuova immagine possa essere ricevuta, avviata e confermata.
Il Network Core gestisce invece il controller Bluetooth Low Energy utilizzato per la comunicazione con il browser e per il trasporto dei dati.
MCUboot opera all'inizio della catena di avvio e gestisce la selezione delle immagini firmware. L'applicazione Zephyr aggiunge i controlli applicativi e il layer di gestione Silicon Logix.
L'architettura consente quindi di distinguere chiaramente:
- connettività radio;
- trasporto dei dati;
- gestione degli slot firmware;
- verifica crittografica;
- logica applicativa;
- policy di autorizzazione;
- stato operativo del dispositivo.
Diagnostica Bluetooth LE e identificazione del dispositivo
Il collegamento Bluetooth non viene utilizzato soltanto per inviare il firmware. Attraverso un servizio GATT dedicato, il dispositivo espone informazioni utili per comprendere il proprio stato prima e dopo l'aggiornamento.
La dashboard può leggere dati come:
- firmware installato;
- tempo di attività;
- stato del service mode;
- risultato del health check;
- stato di conferma dell'immagine;
- identità del dispositivo;
- policy OTA attiva;
- stato del lease;
- informazioni di claim e attestation.
Questi dati permettono di distinguere un semplice trasferimento concluso da un aggiornamento effettivamente avviato, verificato e confermato.
In una soluzione personalizzata, lo stesso servizio può essere esteso con diagnostica specifica del prodotto: stato dei sensori, errori applicativi, configurazione, contatori di manutenzione, periferiche disponibili o risultato degli autotest.
Flusso OTA tramite Web Bluetooth, MCUmgr SMP e MCUboot
L'aggiornamento viene avviato attraverso una dashboard browser-first. Dopo l'autorizzazione dell'utente, il browser stabilisce una connessione locale con il dispositivo tramite Web Bluetooth.
MCUmgr SMP gestisce il trasferimento progressivo dell'immagine. Il nuovo firmware viene scritto in uno slot separato da quello contenente l'applicazione già confermata, evitando di sovrascrivere immediatamente il software funzionante.
Il processo distingue diverse fasi:
- identificazione e lettura dello stato del dispositivo;
- verifica delle condizioni previste dalla policy OTA;
- trasferimento dell'immagine tramite Bluetooth LE;
- scrittura nello slot secondario;
- predisposizione dell'immagine per l'avvio di prova;
- reset del dispositivo;
- verifica dell'immagine da parte di MCUboot;
- avvio del nuovo firmware;
- health check applicativo;
- conferma oppure rollback.
Il completamento del trasferimento non viene quindi considerato automaticamente equivalente a un aggiornamento riuscito. Il risultato viene confermato soltanto dopo il riavvio e la verifica dello stato applicativo.
Firma del firmware, anti-downgrade, health check e rollback
Verifica dell'autenticità prima dell'avvio
Le immagini firmware sono firmate digitalmente con ECDSA P-256. MCUboot utilizza la chiave pubblica presente sul dispositivo per verificare l'immagine prima dell'avvio.
Se il firmware viene modificato oppure firmato con una chiave differente, non deve essere considerato valido per l'esecuzione. Questo controllo rimane attivo sul target anche se il client utilizzato per il trasferimento viene sostituito o modificato.
Le chiavi incluse nel progetto sono esclusivamente chiavi dimostrative. Non devono essere utilizzate in produzione. Un prodotto industriale richiede conservazione protetta delle chiavi private e un processo di firma separato dal repository sorgente.
Controllo anti-downgrade
Un'immagine precedente può essere autentica ma non più autorizzata. Potrebbe reintrodurre vulnerabilità, errori già corretti o formati di dati non compatibili con lo stato corrente del dispositivo.
Il progetto integra quindi una policy anti-downgrade basata sulla progressione delle release e sui controlli supportati dalla catena di aggiornamento.
Health check e conferma dell'immagine
La firma dimostra l'origine e l'integrità del pacchetto, ma non garantisce che l'applicazione funzioni correttamente dopo l'avvio.
La nuova immagine viene quindi avviata inizialmente in modalità di prova. Il firmware esegue un health check e conferma l'aggiornamento soltanto dopo avere raggiunto lo stato applicativo previsto.
Rollback alla versione precedente
Se il firmware non completa la conferma, MCUboot può ripristinare al riavvio l'immagine precedentemente confermata. Il dispositivo mantiene quindi una versione di recupero senza dipendere da un intervento immediato sul codice già caricato.
Service mode temporizzato e policy applicate direttamente sul target
Mantenere il servizio OTA sempre disponibile può aumentare inutilmente la superficie esposta del dispositivo. SLX Field Device Manager utilizza quindi un service mode temporizzato.
La finestra di aggiornamento viene aperta durante l'intervento tecnico e si chiude automaticamente dopo il periodo previsto. Durante il normale funzionamento, il servizio di aggiornamento può quindi rimanere limitato.
Il layer Silicon Logix aggiunge inoltre un gate direttamente sul firmware. Prima di accettare i dati, il dispositivo può verificare:
- identità del target;
- validità del lease;
- durata e scadenza dell'autorizzazione;
- identificativo della chiave;
- firma del lease;
- modalità operativa;
- policy associata all'aggiornamento.
Quando le condizioni previste non sono soddisfatte, il firmware può rifiutare il trasferimento. La decisione finale non viene quindi affidata soltanto all'interfaccia web.
Dashboard web per connessione locale, diagnostica e gestione delle release
SLX Field Device Manager comprende una dashboard web già sviluppata per collegarsi ai dispositivi tramite Web Bluetooth e coordinare l'aggiornamento.
L'interfaccia comprende:
- elenco dei dispositivi;
- scheda dedicata per il singolo target;
- connessione BLE locale;
- lettura dello stato GATT;
- catalogo delle release;
- selezione del pacchetto firmware;
- trasferimento OTA via MCUmgr;
- controllo dell'avanzamento;
- gestione dei rollout;
- audit trail;
- funzioni collegate al lease.
L'approccio browser-first riduce la necessità di distribuire una specifica applicazione desktop per ogni intervento locale.
La dashboard è stata sviluppata per l’ambiente dimostrativo e utilizzata per verificare connessione BLE, diagnostica e flusso OTA su hardware reale.
Apri il tool: SLX Field Device Manager, dashboard OTA via Bluetooth LE.
Come utilizzare la demo OTA su Nordic nRF5340-DK
Per eseguire la dimostrazione è necessaria una nRF5340-DK già predisposta con firmware base, MCUboot e firmware del Network Core.
Il solo pacchetto OTA scaricabile non è sufficiente per inizializzare una scheda completamente vergine. La DK deve essere già programmata oppure preparata tramite un installer factory separato.
Hardware e software necessari
- Nordic nRF5340-DK già predisposta per la demo;
- Bluetooth attivo sul computer;
- Google Chrome o Microsoft Edge con supporto Web Bluetooth;
- tool Silicon Logix aperto tramite HTTPS;
- cavo USB per alimentazione e collegamento della scheda.
Non è richiesto un pairing BLE preventivo. L'autorizzazione alla connessione viene richiesta direttamente dal browser.
1. Attivare il service mode
- Tenere premuto Button 2 sulla nRF5340-DK.
- Premere e rilasciare RESET.
- Continuare a tenere Button 2 per circa due secondi.
- Rilasciare Button 2.
La finestra OTA rimane disponibile per circa cinque minuti. Se scade prima dell'avvio dell'aggiornamento, la procedura deve essere ripetuta.
2. Collegare la scheda
Dal tool Silicon Logix selezionare Collega device e scegliere SLX-OTA-5340 nella finestra Bluetooth mostrata dal browser.
Prima di iniziare l'aggiornamento, la dashboard deve mostrare:
- firmware base installato;
- immagine confermata;
- health check valido;
- service mode attivo;
- servizio SMP disponibile.
3. Selezionare l'aggiornamento
È possibile preparare direttamente l'ultima release disponibile oppure scegliere uno specifico pacchetto dal catalogo.
Per osservare l'intera progressione della demo, gli aggiornamenti possono essere eseguiti nella sequenza:
1.0.11 → 1.0.12 → 1.0.13 → 1.0.14
4. Avviare il trasferimento
Per il test viene utilizzata la modalità Test + reset, mantenendo attivo il controllo anti-downgrade quando supportato.
La dashboard gestisce il trasferimento dell'immagine, la validazione dello slot, la predisposizione del boot, il reset e la verifica della nuova release.
5. Attendere il riavvio e la conferma
Durante la verifica il dispositivo può disconnettersi e riconnettersi più volte. Questo comportamento è previsto.
Durante questa fase non bisogna:
- premere RESET;
- chiudere la pagina;
- scollegare o spegnere la scheda.
La conferma automatica avviene dopo il completamento del health check, circa quindici secondi dopo il boot.
6. Verificare il risultato
L'aggiornamento è concluso correttamente quando il tool mostra:
- versione richiesta installata;
- immagine confermata;
- health check valido;
- messaggio di aggiornamento completato.
Se il servizio SMP non è più disponibile, la finestra OTA potrebbe essere scaduta. È sufficiente riattivare il service mode tramite Button 2 e RESET.
Test automatici e aggiornamenti verificati su hardware reale
Il progetto è stato sottoposto a controlli automatici sulla componente web e server e a prove fisiche sulla Nordic nRF5340-DK.
I test automatici hanno verificato, tra gli altri aspetti:
- modalità pubblica anonima e read-only;
- protezione dei pacchetti e degli artifact riservati;
- limitazione del catalogo ai firmware dimostrativi;
- rifiuto di path traversal e nomi non autorizzati;
- rate limiting sul login;
- rifiuto di payload malformati;
- verifica dei lease firmati;
- rifiuto di lease errati, scaduti o manomessi;
- presenza del gate OTA nel firmware.
Su una nRF5340-DK reale sono stati completati con successo:
- aggiornamento dalla release base alla release successiva;
- progressione attraverso tutti i pacchetti OTA predisposti;
- upload tramite Web Bluetooth e MCUmgr;
- reset gestito tramite MCUboot;
- riconnessione automatica dopo il riavvio;
- health check e conferma automatica dell'immagine.
Sono state inoltre verificate la lettura dello stato GATT, l'accettazione di un lease valido e il rifiuto di lease associati a un dispositivo errato, scaduti o con firma manomessa.
La suite automatica rappresenta una verifica interna del progetto e non sostituisce un penetration test indipendente.
Dalla scheda di sviluppo a un dispositivo embedded personalizzato
La nRF5340-DK permette di validare su hardware reale l'intera catena: bootloader, applicazione, controller radio, trasferimento BLE, diagnostica, health check, conferma e rollback.
Il passaggio successivo consiste nel trasferire l'architettura su una scheda progettata per il prodotto finale. In questa fase devono essere definiti:
- dimensionamento della memoria;
- partizionamento degli slot OTA;
- alimentazione e consumi;
- antenna e prestazioni RF;
- periferiche applicative;
- accesso fisico alla modalità di servizio;
- protezione delle interfacce di debug;
- gestione delle chiavi di produzione;
- provisioning e identificazione dei dispositivi;
- pipeline di firma e distribuzione delle release;
- requisiti ambientali e meccanici.
La development kit consente quindi di verificare il comportamento software e le procedure operative prima di investire nella progettazione e nella produzione dell'hardware personalizzato.
Riferimenti tecnici: Nordic nRF5340-DK, Zephyr, MCUmgr e MCUboot
Il progetto utilizza componenti e tecnologie documentate dai rispettivi produttori e progetti open source.
- Nordic Semiconductor – nRF5340-DK : caratteristiche e risorse della scheda di sviluppo.
- Nordic Semiconductor – nRF5340 Product Specification : architettura e caratteristiche del System-on-Chip.
- Zephyr Project – Nordic nRF5340-DK : supporto di Application Core e Network Core.
- Zephyr Project – Simple Management Protocol : protocollo utilizzato da MCUmgr per il device management.
- MCUboot – Design documentation : gestione delle immagini, boot di prova, conferma e rollback.
Nordic Semiconductor e nRF5340 sono marchi dei rispettivi titolari. SLX Field Device Manager è un progetto indipendente sviluppato da Silicon Logix e non implica sponsorizzazione, partnership o approvazione da parte di Nordic Semiconductor.
Quando sviluppare un sistema OTA personalizzato
Una soluzione OTA personalizzata è utile quando il dispositivo deve essere mantenuto per diversi anni, viene installato presso il cliente o non può essere collegato permanentemente a Internet.
Silicon Logix può supportare la progettazione di:
- firmware embedded aggiornabile;
- integrazione di MCUboot e MCUmgr;
- aggiornamento tramite Bluetooth Low Energy;
- secure boot e firma delle immagini;
- anti-downgrade e strategie di recovery;
- diagnostica GATT;
- service mode e autorizzazione target-side;
- dashboard di gestione dei dispositivi;
- pipeline di firma e distribuzione delle release;
- porting dalla development kit a hardware custom.
L'architettura deve essere adattata al prodotto, al ciclo di vita previsto, alle periferiche utilizzate e ai requisiti di sicurezza del settore.
Devi aggiornare e gestire dispositivi embedded installati sul campo?
Possiamo partire dall'analisi del firmware e dell'hardware esistenti per definire bootloader, partizionamento, firma delle immagini, trasporto OTA, diagnostica, policy e procedure di recovery.
Contatta Silicon Logix per una valutazione tecnica del progetto.
Le chiavi utilizzate nella dimostrazione sono esclusivamente di test e non devono essere riutilizzate in produzione. Un rilascio industriale richiede chiavi dedicate, gestione sicura e una pipeline di firma separata.
