OTA Update (Over-the-Air)
Un aggiornamento OTA (Over-the-Air) è il processo di distribuzione wireless di nuovo firmware, software o dati di configurazione a un dispositivo embedded dispiegato sul campo. Nel contesto del Cyber Resilience Act dell’UE, la capacità di aggiornamento OTA non è più facoltativa: è un requisito normativo per qualsiasi prodotto connesso che debba ricevere patch di sicurezza durante l’intero ciclo di vita.
Fatti chiave
| Dettaglio | Informazione |
|---|---|
| Termine completo | Over-the-Air Update |
| Scopo | Distribuzione remota di firmware/software senza accesso fisico al dispositivo |
| Requisito CRA | Meccanismo di aggiornamento sicuro obbligatorio per tutti i prodotti con elementi digitali |
| Standard di sicurezza | IETF SUIT (Software Updates for IoT) — formato manifest RFC 9019 |
| Protocolli tipici | HTTPS, CoAP, MQTT, LwM2M, basati su TLS personalizzati |
| Intervallo di banda | da 1 KB (patch delta) a oltre 100 MB (immagini firmware complete) |
Perché l’OTA è un requisito del CRA
Il Cyber Resilience Act impone ai fabbricanti di fornire aggiornamenti di sicurezza per la durata di vita prevista del prodotto (minimo 5 anni). Per i dispositivi dispiegati sul campo — sensori industriali, automazione degli edifici, contatori intelligenti, ECU automobilistiche — l’accesso fisico per gli aggiornamenti è impraticabile o impossibile. L’OTA è l’unico meccanismo di distribuzione attuabile.
L’articolo 13 del CRA richiede in particolare:
- Patch di sicurezza tempestive — Le vulnerabilità devono essere corrette senza indebito ritardo.
- Aggiornamenti automatici o facilmente applicabili — Gli utenti non dovrebbero necessitare di competenze tecniche per applicare le correzioni di sicurezza.
- Notifica degli aggiornamenti — Gli utenti devono essere informati quando sono disponibili aggiornamenti di sicurezza.
Architettura OTA sicura
Un sistema di aggiornamento OTA conforme al CRA richiede molteplici livelli di sicurezza:
┌──────────────────────────────────────────────────────────────────────┐
│ SERVER DI BUILD (infrastruttura del fabbricante) │
│ Compila il firmware │
│ Firma con la chiave privata conservata in un HSM │
│ Genera il manifest SUIT con i metadati │
│ Calcola la patch differenziale (facoltativo) │
│ Carica i file sulla CDN o sul server di distribuzione │
│ Trasmette l’immagine firmware firmata e il manifest SUIT │
└──────────────────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────────────────┐
│ DISPOSITIVO (sul campo) │
│ 1. Scarica manifest e immagine tramite TLS 1.3 │
│ 2. Verifica la firma del manifest con la chiave pubblica dell’HRoT │
│ 3. Controlla la versione (contatore anti-rollback) │
│ 4. Scrive nella partizione inattiva (schema A/B) │
│ 5. Verifica l’integrità (hash SHA-256) │
│ 6. Cambia in modo atomico la partizione di avvio │
│ 7. Avvia il nuovo firmware tramite la catena di Secure Boot │
│ 8. Avvio non riuscito → ritorno automatico alla partizione A │
└──────────────────────────────────────────────────────────────────────┘Proprietà di sicurezza critiche
| Proprietà | Scopo | Rilevanza per il CRA |
|---|---|---|
| Firma del codice | Garantisce che il firmware provenga dal fabbricante legittimo | Obbligatoria — previene l’iniezione di firmware malevolo |
| Anti-rollback | Previene il downgrade a firmware obsoleto e vulnerabile | Obbligatoria — contatore di versione monotòno in fusibili OTP |
| Partizionamento A/B | Aggiornamenti atomici con fallback a un’immagine nota e funzionante | Buona pratica — previene il blocco dei dispositivi (bricking) |
| Hardware Root of Trust | Verifica della chiave di firma ancorata a hardware resistente alla manomissione | Obbligatoria — la sola memorizzazione software della chiave è insufficiente |
| Trasporto cifrato | TLS 1.3 per il canale di download | Obbligatorio — previene gli attacchi man-in-the-middle |
| Payload cifrato | Immagine firmware cifrata (facoltativo) | Raccomandato — protegge la PI, previene il reverse engineering |
| Aggiornamenti delta | Vengono trasmessi solo i byte modificati | Ottimizzazione — riduce la banda per i dispositivi con risorse limitate |
OTA senza hardware sicuro: il rischio
Molti dispositivi IoT esistenti implementano gli aggiornamenti OTA con sicurezza basata solo sul software:
| Aspetto | OTA solo software | OTA protetto dall’hardware |
|---|---|---|
| Memorizzazione della chiave di firma | Memoria flash o file system | Secure Element / HSM / fusibili OTP |
| Rischio di estrazione della chiave | Elevato — dump JTAG/SWD, analisi del firmware | Fisicamente non estraibile |
| Protezione dal rollback | Flag software (modificabile) | Contatore hardware monotòno (irreversibile) |
| Verifica al boot | Facoltativa, aggirabile | Secure Boot da HRoT |
| Conforme al CRA | ? No | ? Sì |
La trappola del firmware: un dispositivo con OTA solo software può ricevere aggiornamenti, ma un aggressore che estragga la chiave di firma può distribuire firmware malevolo a ogni dispositivo dispiegato. L’OTA protetto dall’hardware rende ciò fisicamente impossibile.
Termini correlati
- Secure Boot — Il processo di verifica al boot che garantisce l’esecuzione solo di firmware firmato e distribuito via OTA.
- Hardware Root of Trust — L’hardware resistente alla manomissione che memorizza il materiale di verifica della chiave di firma OTA.
- CRA — Il regolamento UE che impone la capacità di OTA sicuro per i prodotti connessi.
- SBOM — I metadati dell’aggiornamento OTA dovrebbero includere i diff della SBOM per tracciare le modifiche dei componenti.