Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Portierung der AWS IoT over-the-air (OTA-) Update-Bibliothek
Mit FreeRTOS over-the-air (OTA) -Updates können Sie Folgendes tun:
-
Bereitstellen neuer Firmware-Images auf einem einzelnen Gerät, einer Gruppe von Geräten oder Ihrer gesamten Flotte
-
Stellen Sie Firmware auf Geräten bereit, wenn diese zu Gruppen hinzugefügt, zurückgesetzt oder erneut bereitgestellt werden.
-
Überprüfen Sie die Authentizität und Integrität der neuen Firmware, nachdem sie auf Geräten bereitgestellt wurde.
-
Überwachen des Fortschritts einer Bereitstellung
-
Debuggen einer fehlgeschlagenen Bereitstellung
-
Signieren Sie Firmware digital mithilfe von Code Signing für AWS IoT.
Weitere Informationen finden Sie unter Over-the-Air-Updates für FreeRTOS im FreeRTOS-Benutzerhandbuch zusammen mit der O Update-Dokumentation.AWS IoT ver-the-air
Sie können die OTA-Update-Bibliothek verwenden, um OTA-Funktionen in Ihre FreeRTOS-Anwendungen zu integrieren. Weitere Informationen finden Sie unter FreeRTOS OTA Update Library im FreeRTOS User Guide.
FreeRTOS-Geräte müssen die Überprüfung der kryptografischen Codesignatur auf den OTA-Firmware-Images, die sie erhalten, erzwingen. Wir empfehlen die folgenden Algorithmen:
-
Elliptischer Kurven-Digital-Signatur-Algorithmus (ECDSA)
-
NIST P256-Kurve
-
SHA-256-Hash
Voraussetzungen
-
Füllen Sie die Anweisungen unter aus. Richten Sie Ihren Arbeitsbereich und Ihr Projekt für die Portierung ein
-
Erstellen Sie einen Netzwerk-Transport-Schnittstellen-Port.
Weitere Informationen finden Sie unter Portierung der Netzwerktransportschnittstelle.
-
Integrieren Sie die CoreMQTT-Bibliothek. Siehe CoreMQTT-Bibliothek im FreeRTOS-Benutzerhandbuch.
-
Erstellen Sie einen Bootloader, der OTA-Updates unterstützen kann.
Plattform-Portierung
Sie müssen eine Implementierung des OTA Portable Abstraction Layer (PAL) bereitstellen, um die OTA-Bibliothek auf ein neues Gerät zu portieren. Die PAL-APIs sind in der Datei ota_platform_interface.h
Funktionsname |
Beschreibung |
|---|---|
|
Stoppt ein OTA-Update. |
|
Erstellt eine Datei zum Speichern der empfangenen Datenblöcke. |
|
Schließt die angegebene Datei. Dadurch wird die Datei möglicherweise authentifiziert, wenn Sie Speicher verwenden, der kryptografischen Schutz implementiert. |
|
Schreibt einen Datenblock in die spezifizierte Datei mit dem angegebenen Offset. Bei Erfolg gibt die Funktion die Anzahl der geschriebenen Byte zurück. Andernfalls gibt die Funktion einen negativen Fehlercode zurück. Die Blockgröße entspricht immer einer Zweierpotenz und wird ausgerichtet. Weitere Informationen finden Sie unter Konfiguration der OTA-Bibliothek |
|
Aktiviert oder startet das neue Firmware-Abbild. Bei einigen Anschlüssen kehrt diese Funktion nicht zurück, wenn das Gerät programmgesteuert synchron zurückgesetzt wird. |
|
Erfüllt die Anforderungen der Plattform, um das neueste OTA-Firmware-Image (oder -Bundle) zu akzeptieren oder abzulehnen. Informationen zur Implementierung dieser Funktion finden Sie in der Dokumentation zu Ihrem Motherboard (Plattform) und zur Architektur. |
|
Ruft den Status des OTA-Updates auf. |
Implementieren Sie die Funktionen in dieser Tabelle, wenn Ihr Gerät über eine integrierte Unterstützung verfügt.
Funktionsname |
Beschreibung |
|---|---|
|
Überprüft die Signatur der angegebenen Datei. |
|
Liest das angegebene Signaturgeberzertifikat aus dem Dateisystem und gibt es an den Aufrufer zurück. |
|
Setzt das Gerät zurück. |
Anmerkung
Stellen Sie sicher, dass Sie einen Bootloader haben, der OTA-Updates unterstützt. Anweisungen zum Erstellen Ihres AWS IoT Geräte-Bootloaders finden Sie unter. IoT-Geräte-Bootloader
E2E- und PAL-Tests
Führen Sie OTA PAL- und E2E-Tests durch.
E2E-Tests
Der OTA-End-to-End-Test (E2E) wird verwendet, um die OTA-Fähigkeit eines Geräts zu überprüfen und Szenarien aus der Realität zu simulieren. Dieser Test beinhaltet die Fehlerbehandlung.
Voraussetzungen
Um diesen Test zu portieren, benötigen Sie Folgendes:
Ein Projekt, in das AWS eine OTA-Bibliothek integriert ist. Weitere Informationen finden Sie im Portierungsleitfaden für die OTA-Bibliothek
. Portieren Sie die Demo-Anwendung mithilfe der OTA-Bibliothek, mit AWS IoT Core der Sie interagieren und die OTA-Updates durchführen möchten. Siehe Portierung der OTA-Demoanwendung.
Richten Sie das IDT-Tool ein. Dadurch wird die OTA E2E-Hostanwendung ausgeführt, um das Gerät mit unterschiedlichen Konfigurationen zu erstellen, zu flashen und zu überwachen, und die Integration der OTA-Bibliothek validiert.
Portierung der OTA-Demoanwendung
Der OTA E2E-Test muss über eine OTA-Demoanwendung verfügen, um die OTA-Bibliotheksintegration zu validieren. Die Demo-Anwendung muss in der Lage sein, OTA-Firmware-Updates durchzuführen. Sie finden die FreeRTOS OTA-Demoanwendung im GitHubFreeRTOS-Repository
Schritte zur Portierung
Initialisieren Sie den OTA-Agent.
Implementieren Sie die Callback-Funktion der OTA-Anwendung.
Erstellen Sie die Aufgabe zur Verarbeitung von Ereignissen durch den OTA-Agenten.
Starten Sie den OTA-Agenten.
Überwachen Sie die Statistiken des OTA-Agenten.
Fahren Sie den OTA-Agenten herunter.
Eine ausführliche Anleitung finden Sie unter FreeRTOS OTA over MQTT — Einstiegspunkt der Demo
Konfiguration
Für die Interaktion sind die folgenden Konfigurationen erforderlich: AWS IoT Core
AWS IoT Core Kundenanmeldedaten
Richten Sie DemoConfigRoot_CA_PEM in den Amazon Trust Services-Endpunkten ein.
Ota_Over_Mqtt_Demo/demo_config.hAWS Weitere Informationen finden Sie unter Serverauthentifizierung.Richten Sie DemoConfigClient_Certificate_PEM und DemoConfigClient_Private_Key_PEM mit Ihren Client-Anmeldeinformationen ein.
Ota_Over_Mqtt_Demo/demo_config.hAWS IoT Weitere AWS Informationen zu Client-Zertifikaten und privaten Schlüsseln finden Sie in den Details zur Client-Authentifizierung.
Anwendungsversion
OTA-Steuerprotokoll
OTA-Datenprotokoll
Anmeldeinformationen für die Codesignatur
Andere OTA-Bibliothekskonfigurationen
Sie finden die obigen Informationen in demo_config.h und ota_config.h in FreeRTOS OTA-Demoanwendungen. Weitere Informationen finden Sie unter FreeRTOS OTA über MQTT — Gerät einrichten
Verifizierung erstellen
Führen Sie die Demo-Anwendung aus, um den OTA-Job auszuführen. Wenn der Vorgang erfolgreich abgeschlossen wurde, können Sie die OTA E2E-Tests weiter ausführen.
Die FreeRTOS OTA-Demo
Tests mit dem IDT-Tool ausführen
Um die OTA E2E-Tests auszuführen, müssen Sie AWS IoT Device Tester (IDT) verwenden, um die Ausführung zu automatisieren. Weitere Informationen finden Sie unter AWS IoT Device Tester für FreeRTOS im FreeRTOS-Benutzerhandbuch.
E2E-Testfälle
Testfall |
Beschreibung |
|---|---|
|
Happy Path-Test für regelmäßige OTA-Updates. Es erstellt ein Update mit einer neueren Version, die das Gerät erfolgreich aktualisiert. |
|
Dieser Test erstellt 3 aufeinanderfolgende OTA-Updates. Es wird erwartet, dass das Gerät dreimal hintereinander aktualisiert wird. |
|
Mit diesem Test wird überprüft, ob das Gerät auf die vorherige Firmware zurückgesetzt wird, falls es mit der neuen Firmware keine Verbindung zum Netzwerk herstellen kann. |
|
Dieser Test bestätigt, dass das Gerät die eingehende Firmware ablehnt, wenn die Version gleich bleibt. |
|
Dieser Test überprüft, ob das Gerät ein Update ablehnt, wenn das Image nicht signiert ist. |
|
Dieser Test überprüft, ob das Gerät ein Update ablehnt, wenn die Firmware mit einem nicht vertrauenswürdigen Zertifikat signiert ist. |
|
Dieser Test überprüft, ob das Gerät eine ältere Update-Version ablehnt. |
|
Verschiedene Geräte unterstützen unterschiedliche Signier- und Hash-Algorithmen. Dieser Test bestätigt, dass das Gerät das OTA-Update nicht bestanden hat, wenn es mit einem nicht unterstützten Algorithmus erstellt wurde. |
|
Dies ist der Happy-Path-Test für die Suspend- und Resume-Funktion. Dieser Test erstellt ein OTA-Update und startet das Update. Anschließend wird AWS IoT Core mit derselben Client-ID (Dingname) und denselben Anmeldeinformationen eine Verbindung hergestellt. AWS IoT Core trennt dann die Verbindung zum Gerät. Es wird erwartet, dass das Gerät erkennt, dass die Verbindung unterbrochen wurde AWS IoT Core, und sich nach einer gewissen Zeit in einen angehaltenen Zustand versetzt und versucht, erneut eine Verbindung herzustellen AWS IoT Core und den Download fortzusetzen. |
|
Bei diesem Test wird geprüft, ob das Gerät sich selbst wiederherstellen kann, wenn der OTA-Job abgebrochen wird, während er sich im angehaltenen Zustand befindet. Es macht dasselbe wie der |
|
Wenn ein OTA-Update erstellt wird, können Sie die Lebensdauer der vorsignierten S3-URL konfigurieren. Mit diesem Test wird überprüft, ob das Gerät in der Lage ist, einen OTA auszuführen, auch wenn der Download nach Ablauf der URL nicht abgeschlossen werden kann. Es wird erwartet, dass das Gerät ein neues Auftragsdokument anfordert, das eine neue URL enthält, um den Download fortzusetzen. |
|
Dieser Test erstellt zwei OTA-Updates hintereinander. Wenn das Gerät meldet, dass es das erste Update herunterlädt, bricht der Test Force das erste Update ab. Es wird erwartet, dass das Gerät das aktuelle Update abbricht und das zweite Update aufnimmt und abschließt. |
|
Bei diesem Test werden zwei OTA-Updates hintereinander erstellt. Wenn das Gerät meldet, dass es das erste Update herunterlädt, bricht der Test Force das erste Update ab. Es wird erwartet, dass das Gerät das aktuelle Update abbricht und das zweite Update aufnimmt und es dann abschließt. |
|
Dieser Test überprüft, ob das Gerät ein Update ablehnen kann, wenn das Image abstürzt. |
PAL-Tests
Voraussetzungen
Um die Network Transport Interface-Tests zu portieren, benötigen Sie Folgendes:
Ein Projekt, das FreeRTOS mit einem gültigen FreeRTOS-Kernelport erstellen kann.
Eine funktionierende Implementierung von OTA PAL.
Portierung
Fügen Sie FreeRTOS-Libraries-Integration-Tests
als Submodul zu Ihrem Projekt hinzu. Der Standort des Submoduls im Projekt muss dort sein, wo es gebaut werden kann. Kopieren Sie
config_template/test_execution_config_template.hundconfig_template/test_param_config_template.han eine Stelle im Buildpfad und benennen Sie sie intest_execution_config.hundtest_param_config.hum.Fügen Sie relevante Dateien in das Build-System ein. Falls verwendet
CMake,qualification_test.cmakeundsrc/ota_pal_tests.cmakekann verwendet werden, um relevante Dateien einzubeziehen.Konfigurieren Sie den Test, indem Sie die folgenden Funktionen implementieren:
SetupOtaPalTestParam(): definiert insrc/ota/ota_pal_test.h. Die Implementierung muss denselben Namen und dieselbe Signatur haben wie in definiertota_pal_test.h. Derzeit müssen Sie diese Funktion nicht konfigurieren.
Implementieren Sie UNITY_OUTPUT_CHAR, sodass sich Testausgabeprotokolle nicht mit Geräteprotokollen überschneiden.
RunQualificationTest()Rufen Sie von der Anwendung aus an. Die Gerätehardware muss ordnungsgemäß initialisiert sein und das Netzwerk muss vor dem Anruf verbunden sein.
Testen
In diesem Abschnitt werden die lokalen Tests der OTA-PAL-Qualifikationstests beschrieben.
Aktivieren Sie den Test
Öffnen test_execution_config.h und definieren Sie OTA_PAL_TEST_ENABLED auf 1.
Aktualisieren test_param_config.h Sie unter die folgenden Optionen:
OTA_PAL_TEST_CERT_TYPE: Wählen Sie den verwendeten Zertifikatstyp aus.
OTA_PAL_CERTIFICATE_FILE: Pfad zum Gerätezertifikat, falls zutreffend.
OTA_PAL_FIRMWARE_FILE: Name der Firmware-Datei, falls zutreffend.
OTA_PAL_USE_FILE_SYSTEM: Auf 1 gesetzt, wenn das OTA-PAL die Dateisystemabstraktion verwendet.
Erstellen und flashen Sie die Anwendung mit einer Toolchain Ihrer Wahl. Wenn der aufgerufen RunQualificationTest() wird, werden die OTA-PAL-Tests ausgeführt. Die Testergebnisse werden an die serielle Schnittstelle ausgegeben.
Integration von OTA-Aufgaben
Fügen Sie Ihrer aktuellen MQTT-Demo einen OTA-Agenten hinzu.
Führen Sie OTA End-to-End-Tests (E2E) mit aus. AWS IoT Dadurch wird überprüft, ob die Integration wie erwartet funktioniert.
Anmerkung
Um ein Gerät offiziell für FreeRTOS zu qualifizieren, müssen Sie den portierten Quellcode des Geräts anhand von OTA PAL- und OTA E2E-Testgruppen mit validieren. AWS IoT Device Tester Folgen Sie den Anweisungen unter Using AWS IoT Device Tester for FreeRTOS im FreeRTOS User Guide, um die Port-Validierung einzurichten AWS IoT Device Tester . Um den Port einer bestimmten Bibliothek zu testen, muss die richtige Testgruppe in der device.json Datei im Ordner aktiviert sein. AWS IoT Device Tester configs
IoT-Geräte-Bootloader
Sie müssen Ihre eigene sichere Bootloader-Anwendung bereitstellen. Stellen Sie sicher, dass das Design und die Implementierung eine angemessene Abwehr von Sicherheitsbedrohungen bieten. Im Folgenden finden Sie die Bedrohungsmodellierung als Referenz.
Modellierung von Bedrohungen für IoT-Geräte-Bootloader
Hintergrund
Als funktionierende Definition gilt, dass es sich bei den eingebetteten AWS IoT Geräten, auf die sich dieses Bedrohungsmodell bezieht, um Produkte auf Mikrocontrollerbasis handelt, die mit Cloud-Diensten interagieren. Sie können in Verbraucher-,kommerziellen oder Industrieumgebungen eingesetzt werden. IoT-Geräte können Daten über einen Benutzer, einen Patienten, eine Maschine oder eine Umgebung erfassen und von Glühbirnen und Türschlössern bis hin zu Fabrikmaschinen alles steuern.
Die Modellierung von Bedrohungen ist ein Sicherheitsansatz aus der Sicht eines hypothetischen Gegner. Unter Berücksichtigung der Ziele und Methoden des Gegners wird eine Bedrohungsliste erstellt. Bedrohungen sind Angriffe auf eine Ressource oder eine Komponente durch einen Gegner. Die Liste wird priorisiert und zur Identifizierung und Erstellung von Lösungen zur Risikominderung verwendet. Bei der Auswahl einer Risikominderungslösung sollten die Kosten für deren Implementierung und Wartung gegen den tatsächlichen Sicherheitswert, den sie bietet, abgewogen werden. Es gibt verschiedene Methoden für Bedrohungsmodelle
FreeRTOS bietet OTA (over-the-air) -Softwareupdates für Geräte an AWS IoT . Die Update-Funktion kombiniert Cloud-Services mit Softwarebibliotheken auf dem Gerät und einem vom Partner bereitgestellten Bootloader. Dieses Bedrohungsmodell konzentriert sich speziell auf Bedrohungen für den Bootloader.
Bootloader-Anwendungsfälle
-
Digitales Signieren und Verschlüsseln der Firmware vor der Bereitstellung
-
Bereitstellen neuer Firmware-Images auf einem einzelnen Gerät, einer Gruppe von Geräten oder einer gesamten Flotte
-
Überprüfen der Authentizität und Integrität der neuen Firmware nach der Bereitstellung auf Geräten
-
Geräte führen nur unveränderte Software aus einer vertrauenswürdigen Quelle aus
-
Geräte sind widerstandsfähig gegenüber fehlerhafter Software, die sie über OTA empfangen
Datenflussdiagramm
Bedrohungen
Bei einigen Angriffen gibt es mehrere Abhilfemaßnahmen. Ein Netzwerk, das ein bösartiges Firmware-Image bereitstellen man-in-the-middle soll, wird beispielsweise dadurch entschärft, dass sowohl das vom TLS-Server angebotene Zertifikat als auch das Codesignerzertifikat des neuen Firmware-Images als vertrauenswürdig eingestuft werden. Um die Sicherheit des Bootloaders zu maximieren, werden alle Lösungen zur Abwehr von Bootloadern als unzuverlässig angesehen. Der Bootloader sollte für jeden Angriff über eigene Abwehrlösungen verfügen. Mehrschichtige Abwehrlösungen sind bekannt als. defense-in-depth
Bedrohungen:
-
Ein Angreifer manipuliert die Verbindung des Geräts mit dem Server, um ein schädliches Software-Image bereitzustellen.
Beispiel für Abwehrmaßnahmen
-
Beim Systemstart überprüft der Bootloader die kryptografische Signatur des Images anhand eines bekannten Zertifikats. Wenn die Verifizierung fehlschlägt, setzt der Bootloader zum vorherigen Image zurück.
-
-
Ein Angreifer nutzt einen Pufferüberlauf, um schädliches Verhalten im vorhandenen Firmware-Image zu erzeugen, das in Flash gespeichert ist.
Beispiele für Abwehrmaßnahmen
-
Beim Systemstart führt der Bootloader eine Überprüfung wie zuvor beschrieben aus. Wenn die Verifizierung fehlschlägt und kein vorheriges Image verfügbar ist, wird der Bootloader angehalten.
-
Beim Systemstart führt der Bootloader eine Überprüfung wie zuvor beschrieben aus. Wenn die Überprüfung fehlschlägt und kein vorheriges Image verfügbar ist, wechselt der Bootloader in den ausfallsicheren Modus „Nur OTA“.
-
-
Ein Angreifer startet das Gerät mit einem zuvor gespeicherten ausnutzbaren Image.
Beispiele für Abwehrmaßnahmen
-
Flash-Sektoren, in denen das letzte Image gespeichert ist, werden nach erfolgreicher Installation und erfolgreichen Tests eines neuen Images gelöscht.
-
Bei jedem erfolgreichen Upgrade brennt eine Sicherung durch und Images werden erst ausgeführt, wenn die richtige Anzahl an Sicherungen durchgebrannt ist.
-
-
Ein OTA-Update stellt ein fehlerhaftes oder schädliches Image bereit, das einen Brick des Geräts verursacht.
Beispiel für Abwehrmaßnahmen
-
Der Bootloader startet einen Hardware-Watchdog-Timer, der ein Rollback zum vorherigen Image auslöst.
-
-
Ein Angreifer patcht den Bootloader, um die Image-Verifizierung zu umgehen, damit das Gerät nicht signierte Images akzeptiert.
Beispiele für Abwehrmaßnahmen
-
Der Bootloader befindet sich in ROM (Festwertspeicher) und kann nicht geändert werden.
-
Der Bootloader befindet sich im OTP (one-time-programmable Speicher) und kann nicht geändert werden.
-
Der Bootloader befindet sich in der sicheren Zone von ARM und kann nicht TrustZone geändert werden.
-
-
Ein Angreifer ersetzt das Verifizierungszertifikat, damit das Gerät schädliche Images akzeptiert.
Beispiele für Abwehrmaßnahmen
-
Das Zertifikat befindet sich in einem kryptografischen Co-Prozessor und kann nicht geändert werden.
-
Das Zertifikat befindet sich in ROM (oder OTP oder einer sicheren Zone) und kann nicht geändert werden.
-
Zusätzliche Modellierung von Bedrohungen
Dieses Bedrohungsmodell betrachtet nur den Bootloader. Eine zusätzliche Modellierung von Bedrohungen könnte die allgemeine Sicherheit verbessern. Eine empfohlene Methode ist die Auflistung der Ziele des Gegners, der für diese Ziele anvisierten Komponenten und der Eintrittspunkte in diese Komponenten. Um eine Liste der Bedrohungen zu erstellen, sollten Sie mögliche Angriffe auf die Eintrittspunkte betrachten, durch die die Kontrolle der Komponenten erzielt werden soll. Im Folgenden finden Sie Beispiele für Ziele, Komponenten und Eintrittspunkte für ein IoT-Gerät. Diese Listen sind nicht vollständig und sollen zu weiteren Überlegungen anregen.
Ziele des Gegners
-
Erpressen von Geld
-
Rufschädigung
-
Fälschen von Daten
-
Umleiten von Ressourcen
-
Ausspionieren eines Ziels
-
Erlangen von physischem Zugriff auf eine Website
-
Verursachen von Schäden
-
Auslösen von Panik
Wichtige Komponenten
-
Private Schlüssel
-
Clientzertifikat
-
CA-Stammzertifikate
-
Sicherheitsanmeldeinformationen und -token
-
Personenbezogene Daten des Kunden
-
Implementierungen von Geschäftsgeheimnissen
-
Sensordaten
-
Cloud-Analyse-Datenspeicher
-
Cloud-Infrastruktur
Eintrittspunkte
-
DHCP-Antwort
-
DNS-Antwort
-
MQTT über TLS
-
HTTPS-Antwort
-
OTA-Software-Image
-
Andere, wie von der Anwendung vorgegeben, z. B. USB
-
Physischer Zugriff auf den Bus
-
Offengelegter integrierter Schaltkreis
