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 mit Code Signing für AWS IoT. [Weitere Informationen finden Sie unter [ Over-the-AirFreeRTOS-Updates](https://docs.aws.amazon.com/freertos/latest/userguide/freertos-ota-dev.html) im *FreeRTOS-Benutzerhandbuch* zusammen mit der Update-Dokumentation.AWS IoT Over-the-air ](https://freertos.org/Documentation/api-ref/ota-for-aws-iot-embedded-sdk/docs/doxygen/output/html/index.html) 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](https://docs.aws.amazon.com/freertos/latest/userguide/ota-update-library.html) 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. [Deinen Workspace und dein Projekt für die Portierung einrichten](porting-set-up-project.md) + Erstellen Sie einen Netzwerk-Transport-Schnittstellen-Port. Weitere Informationen finden Sie unter [Portierung der Netzwerktransportschnittstelle](afr-porting-network-transport-interface.md). + Integrieren Sie die CoreMQTT-Bibliothek. Siehe [CoreMQTT-Bibliothek](https://docs.aws.amazon.com/freertos/latest/userguide/coremqtt.html) 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\$1platform\$1interface.h](https://github.com/aws/ota-for-aws-iot-embedded-sdk/blob/main/source/include/ota_platform_interface.h) definiert, für die implementierungsspezifische Details angegeben werden müssen. | Funktionsname | Description | | --- | --- | | `otaPal_Abort` | Stoppt ein OTA-Update. | | `otaPal_CreateFileForRx` | Erstellt eine Datei zum Speichern der empfangenen Datenblöcke. | | `otaPal_CloseFile` | Schließt die angegebene Datei. Dadurch wird die Datei möglicherweise authentifiziert, wenn Sie Speicher verwenden, der kryptografischen Schutz implementiert. | | `otaPal_WriteBlock` | 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](https://freertos.org/Documentation/api-ref/ota-for-aws-iot-embedded-sdk/docs/doxygen/output/html/ota_config.html). | | `otaPal_ActivateNewImage` | 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. | | `otaPal_SetPlatformImageState` | 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. | | `otaPal_GetPlatformImageState` | 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 | Description | | --- | --- | | `otaPal_CheckFileSignature` | Überprüft die Signatur der angegebenen Datei. | | `otaPal_ReadAndAssumeCertificate` | Liest das angegebene Signaturgeberzertifikat aus dem Dateisystem und gibt es an den Aufrufer zurück. | | `otaPal_ResetDevice` | 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](#afr-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](https://www.freertos.org/Documentation/api-ref/ota-for-aws-iot-embedded-sdk/docs/doxygen/output/html/ota_porting.html). + 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](#e2e-porting-demo-application). + 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](https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS-Plus/Demo/AWS/Ota_Windows_Simulator). Wir empfehlen Ihnen, die Demo-Anwendung als Referenz zu verwenden und sie gemäß Ihren Spezifikationen zu modifizieren. ##### Schritte zur Portierung 1. Initialisieren Sie den OTA-Agent. 1. Implementieren Sie die Callback-Funktion der OTA-Anwendung. 1. Erstellen Sie die Aufgabe zur Verarbeitung von Ereignissen für den OTA-Agenten. 1. Starten Sie den OTA-Agenten. 1. Überwachen Sie die Statistiken des OTA-Agenten. 1. Fahren Sie den OTA-Agenten herunter. Eine ausführliche [Anleitung finden Sie unter FreeRTOS OTA over MQTT — Einstiegspunkt der Demo](https://www.freertos.org/ota/ota-mqtt-agent-demo.html#OtaMqttAgentEntryPoint). ##### Konfiguration Für die Interaktion sind die folgenden Konfigurationen erforderlich: AWS IoT Core + AWS IoT Core Kundenanmeldedaten + Richten **Sie DemoConfigRoot\$1CA\$1PEM** in den Amazon Trust Services-Endpunkten ein. `Ota_Over_Mqtt_Demo/demo_config.h` [AWS Weitere Informationen finden Sie unter Serverauthentifizierung](https://docs.aws.amazon.com/iot/latest/developerguide/server-authentication.html). + **Richten **Sie DemoConfigClient\$1Certificate\$1PEM und DemoConfigClient\$1Private\$1Key\$1PEM** mit Ihren Client-Anmeldeinformationen ein.** `Ota_Over_Mqtt_Demo/demo_config.h` AWS IoT Weitere [AWS Informationen zu Client-Zertifikaten und privaten](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html) 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](https://www.freertos.org/ota/ota-mqtt-agent-demo.html#OTABasicDemoClient). ##### 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](https://www.freertos.org/ota/ota-mqtt-agent-demo.html) bietet detaillierte Informationen zur Einrichtung eines OTA-Clients und eines AWS IoT Core OTA-Jobs im FreeRTOS-Windows-Simulator. AWS OTA unterstützt sowohl MQTT- als auch HTTP-Protokolle. Weitere Informationen finden Sie in den folgenden Beispielen: + [OTA über MQTT-Demo auf Windows Simulator](https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS-Plus/Demo/AWS/Ota_Windows_Simulator/Ota_Over_Mqtt_Demo) + [OTA-über-HTTP-Demo auf Windows Simulator](https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS-Plus/Demo/AWS/Ota_Windows_Simulator/Ota_Over_Http_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](https://docs.aws.amazon.com/freertos/latest/userguide/device-tester-for-freertos-ug.html) im *FreeRTOS-Benutzerhandbuch*. ##### E2E-Testfälle | Testfall | Description | | --- | --- | | `OTAE2EGreaterVersion` | Happy Path-Test für regelmäßige OTA-Updates. Es erstellt ein Update mit einer neueren Version, die das Gerät erfolgreich aktualisiert. | | `OTAE2EBackToBackDownloads` | Dieser Test erstellt 3 aufeinanderfolgende OTA-Updates. Es wird erwartet, dass das Gerät dreimal hintereinander aktualisiert wird. | | `OTAE2ERollbackIfUnableToConnectAfterUpdate` | 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. | | `OTAE2ESameVersion` | Dieser Test bestätigt, dass das Gerät die eingehende Firmware ablehnt, wenn die Version gleich bleibt. | | `OTAE2EUnsignedImage` | Dieser Test überprüft, ob das Gerät ein Update ablehnt, wenn das Image nicht signiert ist. | | `OTAE2EUntrustedCertificate` | Dieser Test überprüft, ob das Gerät ein Update ablehnt, wenn die Firmware mit einem nicht vertrauenswürdigen Zertifikat signiert ist. | | `OTAE2EPreviousVersion` | Dieser Test überprüft, ob das Gerät eine ältere Update-Version ablehnt. | | `OTAE2EIncorrectSigningAlgorithm` | 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. | | `OTAE2EDisconnectResume` | 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. | | `OTAE2EDisconnectCancelUpdate` | 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 `OTAE2EDisconnectResume` Test, außer dass nach dem Herstellen einer Verbindung zum Gerät AWS IoT Core, wodurch die Verbindung zum Gerät getrennt wird, das OTA-Update abgebrochen wird. Ein neues Update wird erstellt. Es wird erwartet, dass das Gerät erneut eine Verbindung mit dem AWS IoT Core herstellt, das aktuelle Update abbricht, in den Wartestatus zurückkehrt und das nächste Update akzeptiert und abschließt. | | `OTAE2EPresignedUrlExpired` | 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. | | `OTAE2E2UpdatesCancel1st` | 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. | | `OTAE2ECancelThenUpdate` | 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. | | `OTAE2EImageCrashed` | 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](https://github.com/FreeRTOS/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.h` und `config_template/test_param_config_template.h` an eine Stelle im Buildpfad und benennen Sie sie in `test_execution_config.h` und `test_param_config.h` um. + Fügen Sie relevante Dateien in das Build-System ein. Falls verwendet`CMake`, `qualification_test.cmake` und `src/ota_pal_tests.cmake` kann verwendet werden, um relevante Dateien einzubeziehen. + Konfigurieren Sie den Test, indem Sie die folgenden Funktionen implementieren: + `SetupOtaPalTestParam()`: definiert in`src/ota/ota_pal_test.h`. Die Implementierung muss denselben Namen und dieselbe Signatur haben wie in definiert`ota_pal_test.h`. Derzeit müssen Sie diese Funktion nicht konfigurieren. + Implementieren Sie **UNITY\$1OUTPUT\$1CHAR**, 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\$1PAL\$1TEST\$1ENABLED auf 1.** Aktualisieren `test_param_config.h` Sie unter die folgenden Optionen: + **OTA\$1PAL\$1TEST\$1CERT\$1TYPE: Wählen Sie den verwendeten** Zertifikatstyp aus. + **OTA\$1PAL\$1CERTIFICATE\$1FILE: Pfad** zum Gerätezertifikat, falls zutreffend. + **OTA\$1PAL\$1FIRMWARE\$1FILE: Name der Firmware-Datei, falls** zutreffend. + **OTA\$1PAL\$1USE\$1FILE\$1SYSTEM: 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-Ende-zu-Ende-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](https://docs.aws.amazon.com/freertos/latest/userguide/device-tester-for-freertos-ug.html) 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 Abwehrlösungen 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](https://en.wikipedia.org/wiki/Threat_model). Jede dieser Lösungen ist in der Lage, die Entwicklung eines sicheren und erfolgreichen AWS IoT Produkts zu unterstützen. 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** ![\[Datenflussdiagramm für eingebettete Gerätesicherheit, das physischen Zugriff, eingebettete Geräte, Internetgrenzen und andere Komponenten enthält.\]](http://docs.aws.amazon.com/de_de/freertos/latest/portingguide/images/bootloader-dataflow-diagram.png) #### 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