Portare la libreria di aggiornamento AWS IoT over-the-air (OTA)

Con gli aggiornamenti over-the-air FreerTOS (OTA), puoi fare quanto segue:

• Distribuire le nuove immagini del firmware a un solo dispositivo, un gruppo di dispositivi oppure all'intero parco istanze.

• Implementa il firmware sui dispositivi man mano che vengono aggiunti ai gruppi, ripristinati o riforniti.

• Verifica l'autenticità e l'integrità del nuovo firmware dopo averlo distribuito sui dispositivi.

• Monitorare l'avanzamento di una distribuzione.

• Eseguire il debug di una distribuzione non riuscita.

• Firma digitale del firmware utilizzando Code Signing for. AWS IoT

Per ulteriori informazioni, consulta FreerTOS Over-the-Air Updates nella FreeRTOSUser Guide insieme alla documentazione di O Update.AWS IoT ver-the-air

Puoi utilizzare la libreria di aggiornamento OTA per integrare la funzionalità OTA nelle tue applicazioni FreerTOS. Per ulteriori informazioni, consulta FreeRTOS OTA update Library nella FreerTOS User Guide.

I dispositivi FreerTOS devono applicare la verifica della firma crittografica del codice sulle immagini del firmware OTA che ricevono. Consigliamo i seguenti algoritmi:

• Elliptic-Curve Digital Signature Algorithm (ECDSA)

• NIST P256 curve

• SHA-256 hash

Prerequisiti

• Configurazione dello spazio di lavoro e del progetto per il portingCompleta le istruzioni in.

• Creare una porta di interfaccia di trasporto di rete.

  Per informazioni, consulta Portare l'interfaccia di trasporto di rete.

• Integra la libreria CoreMQTT. Vedi la libreria CoreMQTT nella Guida per l'utente di FreerTOS.

• Crea un bootloader in grado di supportare gli aggiornamenti OTA.

Porting della piattaforma

È necessario fornire un'implementazione dell'OTA portable abstraction layer (PAL) per trasferire la libreria OTA su un nuovo dispositivo. Le API PAL sono definite nel file ota_platform_interface.h per il quale devono essere forniti dettagli specifici di implementazione.

Nome funzione	Descrizione
otaPal_Abort	Interrompe un aggiornamento OTA.
otaPal_CreateFileForRx	Crea un file per archiviare i blocchi di dati ricevuti.
otaPal_CloseFile	Chiude il file specificato. Ciò potrebbe autenticare il file se si utilizza uno storage che implementa la protezione crittografica.
otaPal_WriteBlock	Scrive un blocco di dati sul file specificato in una data posizione di offset. In caso di successo, la funzione restituisce il numero di byte scritti. In caso contrario, la funzione restituisce un codice di errore negativo. La dimensione del blocco sarà sempre pari a due e verrà allineata. Per ulteriori informazioni, vedere Configurazione della libreria OTA.
otaPal_ActivateNewImage	Attiva o avvia la nuova immagine firmware. Per alcune porte, se il dispositivo viene ripristinato programmaticamente in modo sincrono, questa funzione non verrà ripristinata.
otaPal_SetPlatformImageState	Esegue ciò che è richiesto dalla piattaforma per accettare o rifiutare l'immagine firmware (o pacchetto) OTA più recente. Per implementare questa funzione, consultate la documentazione relativa ai dettagli e all'architettura della scheda (piattaforma).
otaPal_GetPlatformImageState	Ottiene lo stato dell'immagine dell'aggiornamento OTA.

Implementa le funzioni in questa tabella se il dispositivo integra il supporto per le stesse.

Nome funzione	Descrizione
otaPal_CheckFileSignature	Verifica la firma del file specificato.
otaPal_ReadAndAssumeCertificate	Legge il certificato firmatario specificato dal file system e lo restituisce al chiamante.
otaPal_ResetDevice	Reimposta il dispositivo.

Nota

Assicurati di disporre di un bootloader che supporta aggiornamenti OTA. Per istruzioni sulla creazione del bootloader AWS IoT del dispositivo, consulta. Bootloader dispositivo IoT

Test E2E e PAL

Esegui i test OTA PAL ed E2E.

Test E2E

Il test OTA end to end (E2E) viene utilizzato per verificare la funzionalità OTA di un dispositivo e simulare scenari realistici. Questo test includerà la gestione degli errori.

Prerequisiti

Per eseguire il porting di questo test, è necessario quanto segue:

• Un progetto con una libreria AWS OTA integrata. Per ulteriori informazioni, consulta la OTA Library Porting Guide.

• Esporta l'applicazione demo utilizzando la libreria OTA con cui interagire AWS IoT Core per eseguire gli aggiornamenti OTA. Per informazioni, consulta Portare l'applicazione demo OTA.

• Configura lo strumento IDT. Ciò esegue l'applicazione host OTA E2E per creare, eseguire il flashing e monitorare il dispositivo con diverse configurazioni e convalida l'integrazione della libreria OTA.

Portare l'applicazione demo OTA

Il test OTA E2E deve avere un'applicazione demo OTA per convalidare l'integrazione della libreria OTA. L'applicazione demo deve avere la capacità di eseguire aggiornamenti del firmware OTA. Puoi trovare l'applicazione demo FreerTOS OTA nel repository FreerTOS. GitHub Ti consigliamo di utilizzare l'applicazione demo come riferimento e di modificarla in base alle tue specifiche.

Fasi di portabilità

1. Inizializzare l'agente OTA.

2. Implementa la funzione di callback dell'applicazione OTA.

3. Crea l'attività di elaborazione degli eventi dell'agente OTA.

4. Avvia l'agente OTA.

5. Monitora le statistiche dell'agente OTA.

6. Chiudi l'agente OTA.

Visita FreerTOS OTA over MQTT - Punto di accesso della demo per istruzioni dettagliate.

Configurazione

Le seguenti configurazioni sono necessarie per interagire con: AWS IoT Core

• AWS IoT Core credenziali del client

  • Configura DemoConfigRoot_CA_PEM con gli endpoint Amazon Trust Services. Ota_Over_Mqtt_Demo/demo_config.h Per AWS maggiori dettagli, consulta l'autenticazione del server.

  • Configura DemoConfigClient_Certificate_PEM e DemoConfigClient_Private_Key_PEM con le credenziali del tuo cliente. Ota_Over_Mqtt_Demo/demo_config.h AWS IoT Consulta AWS i dettagli sull'autenticazione del client per informazioni sui certificati client e sulle chiavi private.

• Versione dell'applicazione

• Protocollo di controllo OTA

• Protocollo dati OTA

• Credenziali di firma del codice

• Altre configurazioni della libreria OTA

Puoi trovare le informazioni precedenti nelle demo_config.h e ota_config.h nelle applicazioni demo FreerTOS OTA. Visita FreerTOS OTA over MQTT - Configurazione del dispositivo per ulteriori informazioni.

Verifica degli edifici

Esegui l'applicazione demo per eseguire il job OTA. Una volta completato con successo, puoi continuare a eseguire i test OTA E2E.

La demo OTA di FreerTOS fornisce informazioni dettagliate sulla configurazione di un client OTA e AWS IoT Core di un lavoro OTA sul simulatore di Windows FreerTOS. AWS OTA supporta i protocolli MQTT e HTTP. Fate riferimento ai seguenti esempi per maggiori dettagli:

• Demo OTA su MQTT su Windows Simulator

• Demo OTA su HTTP su Windows Simulator

Esecuzione di test con lo strumento IDT

Per eseguire i test OTA E2E, è necessario utilizzare AWS IoT Device Tester (IDT) per automatizzare l'esecuzione. Vedi AWS IoT Device Tester FreerTOS nella FreerTOS User Guide per maggiori dettagli.

Casi di test E2E

Caso di test	Descrizione
OTAE2EGreaterVersion	Happy path test per aggiornamenti OTA regolari. Crea un aggiornamento con una versione più recente, che il dispositivo aggiorna correttamente.
OTAE2EBackToBackDownloads	Questo test crea 3 aggiornamenti OTA consecutivi. È previsto l'aggiornamento del dispositivo per 3 volte consecutive.
OTAE2ERollbackIfUnableToConnectAfterUpdate	Questo test verifica che il dispositivo ripristini il firmware precedente se non riesce a connettersi alla rete con il nuovo firmware.
OTAE2ESameVersion	Questo test conferma che il dispositivo rifiuta il firmware in ingresso se la versione rimane invariata.
OTAE2EUnsignedImage	Questo test verifica che il dispositivo rifiuti un aggiornamento se l'immagine non è firmata.
OTAE2EUntrustedCertificate	Questo test verifica che il dispositivo rifiuti un aggiornamento se il firmware è firmato con un certificato non attendibile.
OTAE2EPreviousVersion	Questo test verifica che il dispositivo rifiuti una versione di aggiornamento precedente.
OTAE2EIncorrectSigningAlgorithm	Dispositivi diversi supportano algoritmi di firma e hashing diversi. Questo test verifica che il dispositivo non superi l'aggiornamento OTA se è stato creato con un algoritmo non supportato.
OTAE2EDisconnectResume	Questo è l'happy path test per la funzione di sospensione e ripresa. Questo test crea un aggiornamento OTA e avvia l'aggiornamento. Quindi si connette AWS IoT Core con lo stesso ID client (nome dell'oggetto) e le stesse credenziali. AWS IoT Core quindi disconnette il dispositivo. Si prevede che il dispositivo rilevi che è disconnesso e AWS IoT Core, dopo un certo periodo di tempo, passi automaticamente allo stato sospeso e provi a riconnettersi e riprendere il AWS IoT Core download.
OTAE2EDisconnectCancelUpdate	Questo test verifica se il dispositivo è in grado di ripristinarsi da solo se il processo OTA viene annullato mentre è in uno stato sospeso. Fa la stessa cosa del OTAE2EDisconnectResume test, tranne per il fatto che dopo la connessione a AWS IoT Core, che disconnette il dispositivo, annulla l'aggiornamento OTA. Viene creato un nuovo aggiornamento. Il dispositivo dovrebbe riconnettersi a AWS IoT Core, interrompere l'aggiornamento corrente, tornare allo stato di attesa e accettare e completare l'aggiornamento successivo.
OTAE2EPresignedUrlExpired	Quando viene creato un aggiornamento OTA, puoi configurare la durata dell'URL prefirmato S3. Questo test verifica che il dispositivo sia in grado di eseguire un'OTA, anche se non riesce a completare il download alla scadenza dell'URL. Il dispositivo dovrebbe richiedere un nuovo documento di lavoro, che contiene un nuovo URL per riprendere il download.
OTAE2E2UpdatesCancel1st	Questo test crea due aggiornamenti OTA di seguito. Quando il dispositivo segnala che sta scaricando il primo aggiornamento, il test force annulla il primo aggiornamento. Il dispositivo dovrebbe interrompere l'aggiornamento corrente, ritirare il secondo aggiornamento e completarlo.
OTAE2ECancelThenUpdate	Questo test crea due aggiornamenti OTA di seguito. Quando il dispositivo segnala che sta scaricando il primo aggiornamento, il test force annulla il primo aggiornamento. Il dispositivo dovrebbe interrompere l'aggiornamento corrente e ritirare il secondo aggiornamento, quindi completarlo.
OTAE2EImageCrashed	Questo test verifica che il dispositivo sia in grado di rifiutare un aggiornamento quando l'immagine si blocca.

Test PAL

Prerequisiti

Per eseguire il porting dei test dell'interfaccia di trasporto di rete, è necessario quanto segue:

• Un progetto in grado di creare FreerTOS con una porta del kernel FreerTOS valida.

• Un'implementazione funzionante di OTA PAL.

Portabilità

• Aggiungi FreeRTOS-Libraries-Integration-Tests come sottomodulo nel tuo progetto. La posizione del sottomodulo nel progetto deve essere dove può essere costruito.

• Copia config_template/test_execution_config_template.h e config_template/test_param_config_template.h in una posizione nel percorso di compilazione e rinominali in and. test_execution_config.h test_param_config.h

• Includi i file pertinenti nel sistema di compilazione. Se si utilizzaCMake, qualification_test.cmake e src/ota_pal_tests.cmake può essere utilizzato per includere i file pertinenti.

• Configura il test implementando le seguenti funzioni:

  • SetupOtaPalTestParam(): definito insrc/ota/ota_pal_test.h. L'implementazione deve avere lo stesso nome e la stessa firma definiti inota_pal_test.h. Attualmente non è necessario configurare questa funzione.

• Implementa UNITY_OUTPUT_CHAR in modo che i log di output dei test non si interlacciano con i log del dispositivo.

• RunQualificationTest()Chiama dall'applicazione. L'hardware del dispositivo deve essere inizializzato correttamente e la rete deve essere connessa prima della chiamata.

Test in corso

Questa sezione descrive i test locali dei test di qualificazione OTA PAL.

Abilita il test

Apri test_execution_config.h e definisci OTA_PAL_TEST_ENABLED su 1.

Intest_param_config.h, aggiorna le seguenti opzioni:

• OTA_PAL_TEST_CERT_TYPE: seleziona il tipo di certificato utilizzato.

• OTA_PAL_CERTIFICATE_FILE: percorso del certificato del dispositivo, se applicabile.

• OTA_PAL_FIRMWARE_FILE: nome del file del firmware, se applicabile.

• OTA_PAL_USE_FILE_SYSTEM: impostato su 1 se OTA PAL utilizza l'astrazione del file system.

Crea e esegui il flashing dell'applicazione utilizzando una catena di strumenti a tua scelta. Quando RunQualificationTest() viene chiamato, verranno eseguiti i test OTA PAL. I risultati del test vengono inviati alla porta seriale.

Integrazione delle attività OTA

• Aggiungi l'agente OTA alla tua demo MQTT attuale.

• Esegui i test OTA End to End (E2E) con. AWS IoT Questo verifica se l'integrazione funziona come previsto.

Nota

Per qualificare ufficialmente un dispositivo per FreerTOS, è necessario convalidare il codice sorgente portato del dispositivo rispetto ai gruppi di test OTA PAL e OTA E2E con. AWS IoT Device Tester Segui le istruzioni in Using AWS IoT Device Tester for FreerTOS nella FreeRTOS User Guide per configurare la convalida delle porte. AWS IoT Device Tester Per testare la porta di una libreria specifica, è necessario abilitare il gruppo di test corretto nel file nella device.json cartella. AWS IoT Device Tester configs

Bootloader dispositivo IoT

È necessario fornire la propria applicazione di bootloader sicura. Assicurati che la progettazione e l'implementazione forniscano un'adeguata mitigazione delle minacce alla sicurezza. Di seguito è riportata la modellazione delle minacce come riferimento.

Modellazione delle minacce per il bootloader dei dispositivi IoT

Contesto

Come definizione operativa, i AWS IoT dispositivi integrati a cui fa riferimento questo modello di minaccia sono prodotti basati su microcontrollori che interagiscono con i servizi cloud. Possono essere distribuiti in ambienti consumer, commerciali o industriali. I dispositivi IoT possono raccogliere dati su un utente, un paziente, una macchina o un ambiente e controllare qualsiasi cosa, dalle lampadine alle serrature alle officine.

La modellazione delle minacce è un approccio alla sicurezza dal punto di vista di un ipotetico avversario. Considerando gli obiettivi e i metodi dell'avversario, viene creato un elenco di minacce. Le minacce sono attacchi contro una risorsa o un asset eseguiti da un avversario. L'elenco è classificato in ordine di priorità e viene utilizzato per identificare e creare soluzioni di mitigazione. Quando si sceglie una soluzione di mitigazione, i costi di implementazione e manutenzione devono essere bilanciati con il reale valore di sicurezza che offre. Esistono diverse metodologie dei modelli di minacce. Ciascuno è in grado di supportare lo sviluppo di un AWS IoT prodotto sicuro e di successo.

FreerTOS offre aggiornamenti software OTA over-the-air () ai dispositivi. AWS IoT La struttura di aggiornamento combina servizi cloud con librerie software su dispositivo e un bootloader fornito da partner. Questo modello di minacce si concentra in modo specifico sulle minacce contro il bootloader.

Casi d'uso del bootloader

• Aggiungere una firma digitale e crittografare il firmware prima della distribuzione.

• Distribuire le nuove immagini del firmware a un solo dispositivo, un gruppo di dispositivi oppure all'intero parco istanze.

• Verificare l'autenticità e l'integrità del nuovo firmware dopo che è stato distribuito ai dispositivi.

• I dispositivi eseguono solo software non modificato da un'origine attendibile.

• I dispositivi sono resilienti ai software difettosi ricevuti tramite OTA.

Diagramma del flusso di dati

Minacce

Alcuni attacchi utilizzano diversi modelli di mitigazione; ad esempio, una rete man-in-the-middle destinata a fornire un'immagine firmware dannosa viene mitigata verificando l'attendibilità sia del certificato offerto dal server TLS che del certificato code-firmatario della nuova immagine firmware. Per massimizzare la sicurezza del bootloader, tutte le soluzioni di mitigazione diverse dal bootloader sono considerate inaffidabili. Il bootloader deve disporre di soluzioni di mitigazione intrinseche per ogni attacco. Le soluzioni di mitigazione a più livelli sono note come. defense-in-depth

Minacce:

• Un utente malintenzionato dirotta la connessione del dispositivo al server per distribuire un'immagine firmware dannosa.

  Esempio di mitigazione

  • All'avvio, il bootloader verifica la firma crittografica dell'immagine utilizzando un certificato noto. Se la verifica ha esito negativo, il bootloader esegue il rollback all'immagine precedente.

• Un utente malintenzionato sfrutta un overflow del buffer per introdurre comportamenti dannosi all'immagine del firmware esistente archiviata in flash.

  Esempi di mitigazione

  • All'avvio, il bootloader verifica, come descritto in precedenza. Quando la verifica ha esito negativo e non è disponibile alcuna immagine precedente, il bootloader si arresta.

  • All'avvio, il bootloader verifica, come descritto in precedenza. Quando la verifica fallisce e non è disponibile alcuna immagine precedente, il bootloader entra in una modalità solo OTA a prova di errore.

• Un utente malintenzionato avvia il dispositivo su un'immagine archiviata in precedenza, che può essere sfruttata.

  Esempi di mitigazione

  • I settori Flash che memorizzano l'ultima immagine vengono cancellati dopo l'installazione e il test di una nuova immagine.

  • Un fusibile viene incendiato a ogni aggiornamento riuscito e ogni immagine si rifiuta di eseguire a meno che il numero corretto di fusibili non sia stato incendiato.

• Un aggiornamento OTA fornisce un'immagine difettosa o dannosa che copia il dispositivo.

  Esempio di mitigazione

  • Il bootloader avvia un timer watchdog hardware che attiva il rollback all'immagine precedente.

• Un utente malintenzionato esegue le patch al bootloader per ignorare la verifica dell'immagine in modo che il dispositivo accetti immagini non firmate.

  Esempi di mitigazione

  • Il bootloader è in ROM (memoria di sola lettura) e non può essere modificato.

  • Il bootloader è in OTP (one-time-programmable memoria) e non può essere modificato.

  • Il bootloader si trova nella zona sicura di ARM TrustZone e non può essere modificato.

• Un utente malintenzionato sostituisce il certificato di verifica in modo che il dispositivo accetti immagini dannose.

  Esempi di mitigazione

  • Il certificato è in un co-processore crittografico e non può essere modificato.

  • Il certificato è in ROM (o OTP o zona sicura) e non può essere modificato.

Ulteriore modellazione delle minacce

Questo modello di minaccia considera solo il bootloader. Un'ulteriore modellazione delle minacce potrebbe migliorare la sicurezza generale. Un metodo consigliato è elencare gli obiettivi dell'avversario, gli asset a cui si rivolgono tali obiettivi e i punti di ingresso degli asset. È possibile creare un elenco di minacce prendendo in considerazione gli attacchi ai punti di ingresso per ottenere il controllo degli asset. Di seguito sono elencati alcuni esempi di obiettivi, asset e punti di ingresso per un dispositivo IoT. Questi elenchi non sono esaustivi e hanno lo scopo di stimolare ulteriormente la riflessione.

Obiettivi dell'avversario

• Estendi il denaro

• reputazioni in rovina

• Falsify data (Falsificazione dati)

• Deviazione delle risorse

• Spionare in remoto un target

• Accesso fisico a un sito

• Soddisfazione

• Instill terror

Asset chiave

• Chiavi private

• Certificato client

• Certificati root CA

• Credenziali e token di sicurezza

• Informazioni personali identificabili del cliente

• Implementazioni di segreti commerciali

• Dati del sensore

• Data store di analisi nel cloud

• Infrastruttura cloud

Punti di accesso

• Risposta DHCP

• Risposta DNS

• MQTT su TLS

• Risposta HTTPS

• Immagine software OTA

• Altro, come stabilito dall'applicazione, ad esempio, USB

• Accesso fisico al bus

• IC debloccato