Il firmware via etere (FOTA) è un nome generico per l'esecuzione remota degli aggiornamenti SW.
Supponiamo di avere un microcontroller con memoria RW e un caricatore di avvio.
Qual è il modo giusto per eseguire gli aggiornamenti SW in modo sicuro (tramite Bluetooth o anche mezzo di comunicazione non protetto)?
È necessario disporre di spazio sufficiente per mantenere la vecchia versione durante l'installazione della nuova versione e il passaggio all'avvio dalla nuova versione dopo il completamento dell'installazione deve essere un'operazione atomica, in modo che il sistema non possa essere lasciato non avviabile da un interruzione di corrente a metà del processo.
TL; DR:
Sul tuo sistema di distribuzione:
Sul dispositivo:
In primo luogo, generi una coppia di chiavi sul tuo sistema di generazione. Avrai una chiave pubblica e una privata. Inserisci la chiave pubblica sul firmware originale dei dispositivi spediti. Questa è la versione iniziale. Conserva la chiave privata sullo storage sicuro, idealmente all'interno di un computer disconnesso (senza accesso alla rete).
Quando si rilascia un aggiornamento, è necessario utilizzare la chiave privata creata in precedenza per firmare il pacchetto di aggiornamento. È possibile aggiungere il pacchetto a un file zip, insieme a un file di testo contenente la firma generata in precedenza. Invia il file al microcontrollore.
Dopo aver ricevuto il file zip, il microcontrollore decomprimerà sia la firma che l'aggiornamento, eseguirà un controllo della firma e confronterà la firma risultante con la firma nel file zip. Se sono uguali, l'integrità del pacchetto è garantita e sa che tu (e non qualcun altro) hai creato il pacchetto.
Se non si dispone di memoria sufficiente per decomprimere e controllare, è necessario creare un formato di file speciale contenente sia la firma che l'aggiornamento. È persino possibile implementare SHA256HMAC su un microcontrollore.
Come ha detto Mike Scott, dopo aver inviato l'aggiornamento, deve avere qualche processo in atto per sostituire atomicamente il firmware corrente con quello nuovo. Ho visto un sistema che crea due partizioni sullo storage e ne usa uno per il firmware corrente e un altro per gli aggiornamenti. Dopo l'applicazione e il controllo dell'aggiornamento, sul bootloader viene impostato un flag per indicare quale partizione caricare. Ed è possibile modificare il bootloader per indicare quale partizione verrà caricata durante l'avvio.
Vorrei insistere su un fattore secondario di qualche tipo. Tale autenticazione è ereditata dalla spinta di un filo nell'unità per lampeggiare manualmente, ma manca su OTA. Si desidera assicurarsi che il dispositivo debba essere aggiornato prima di consentirne l'aggiornamento. Pochi schemi completamente digitali si sono dimostrati già robusti, quindi io (paranoico) mi piace ripiegare sulla sicurezza fisica.
Ecco alcuni semplici fattori di autenticazione che possono funzionare:
Un segreto condiviso presentato al momento dell'aggiornamento, utilizzato per autenticare il proprietario del dispositivo. è possibile stampare un codice nella parte inferiore del dispositivo, ad esempio, purché non sia disponibile in remoto in modalità digitale. Puoi usare una sorta di cosa salata-hashy per verificarlo senza rivelare.
Un pulsante o uno switch fisico per accedere alla "modalità di aggiornamento". Ciò consente solo una modifica del firmware dopo l'attuazione, impedendo agli autori di attacchi da remoto di applicare nuove immagini. Questa è probabilmente l'opzione più sicura, ma richiede hardware, anche se economico,
Un cambio logico di qualche tipo. Ad esempio, una regola secondo cui gli utenti possono aggiornare il firmware entro 90 secondi dall'accensione. if(sys_millis()>90000)return go_to_hell(); Questo significa che devi spegnere e accendere il dispositivo per sbloccarlo, qualcosa che può essere difficile / impossibile per un attaccante remoto. O forse devi collegare e scollegare qualcosa connesso al dispositivo 3 volte di seguito per sbloccarlo. In molti casi tali fattori possono essere implementati esclusivamente in software su un design esistente.
tutti questi metodi di autenticazione serviranno a prevenire gli aggiornamenti non autorizzati. Per quanto riguarda la sicurezza del codice attuale o delle chiavi di crittografia, è più una questione di stackoverflow. Non è necessario per crittografare (o persino firmare) il firmware se si pubblicano gli hash per consentire all'utente di auto-validarsi e autorizzare l'utente (e solo l'utente) ad aggiornare autonomamente il codice.
Si noti che è ancora possibile inviare gli aggiornamenti completi OTA, ma averli internamente bufferizzare la nuova immagine e attendere l'autenticazione dell'utente prima di lampeggiare; magari usando un led lampeggiante o solo e-mail per informare gli utenti che gli aggiornamenti sono pronti.
Leggi altre domande sui tag encryption digital-signature public-key-infrastructure embedded-system software-engineering