Standards, um die Sicherheit von Geräten auf dem neuesten Stand zu halten

Da IoT-Geräte normalerweise mit geringen Gewinnspannen und geringen Leistungsspezifikationen gebaut werden, ist die Funktionalität normalerweise auf das beschränkt, was benötigt wird. Bei einem Gerät, dessen Lebensdauer voraussichtlich mehrere Jahre beträgt, gibt es jedoch Sicherheitslücken und Probleme, die behoben werden müssen (siehe das Mirai-Botnetz als Beispiel).

Wie kann ich als IoT-Hersteller das Patchen oder Aktualisieren von Verschlüsselungsalgorithmen oder Sicherheitsprotokollen aus der Ferne aktivieren oder einfach sicherstellen, dass das Gerät sicher ist? Welche Standards sollte ich befolgen?

Wie ermöglichen IoT-Hersteller das Patchen oder Aktualisieren von Verschlüsselungsalgorithmen oder Sicherheitsprotokollen aus der Ferne oder einfach, um sicherzustellen, dass das Gerät sicher ist?

Eine große Anzahl von IoT-Herstellern hat eine einfache Lösung dafür: "Mach dir keine Sorgen" . Dies sind in der Regel dieselben Entwickler, die ihren Geräten Standardkennwörter (oder sogar unveränderliche Kennwörter) hinzufügen, was in erster Linie zu Mirai führte.

Wie in Rorys Antwort erwähnt , sind die Bereitstellung der Mechanismen und der tatsächlichen Entwicklungszeit für das Entwerfen und Bereitstellen der Fixes mit erheblichen Kosten verbunden. Ich bin der festen Überzeugung, dass es ohne regulatorischen Druck (oder die Nachfrage der Verbraucher, was anscheinend nicht der Fall ist) für einen Hersteller keinen Anreiz gibt, die Preise seines Produkts für zusätzliche Sicherheit zu erhöhen. Australien scheint diesen Schritt zu unternehmen, indem es ein obligatorisches Sicherheitsbewertungssystem für alle IoT-Geräte in Betracht zieht.

Ich denke, dass für die meisten Hersteller die beste Idee ist, jemanden zum Umgang mit Sicherheit zu bewegen. So wie die meisten Web - Entwickler etabliert Frameworks wie Django und Ruby on Rails zu vermeiden , machen die gleichen Fehler immer und immer wieder , sollten IoT Entwickler das gleiche tun. Abhängig von der Komplexität Ihres Geräts gibt es verschiedene Optionen:

• High-End-Geräte können Betriebssysteme wie Ubuntu IoT oder Windows 10 IoT Core verwenden, bei denen Sicherheitsupdates vom Betriebssystementwickler durchgeführt und automatisch übertragen werden. Vieles davon ist nicht IoT-spezifisch, aber es ist jedem IoT-Gerät weitaus vorzuziehen, ein benutzerdefiniertes internes Betriebssystem zu verwenden, das wahrscheinlich keine Wartung erhält.

• Low-End-Geräte wie ESP8266-Module sind möglicherweise eingeschränkter, da sie nicht in der Lage sind, so komplexe Betriebssysteme auszuführen, und in der Regel Code ausführen, der speziell für dieses Gerät entwickelt wurde. Es gibt immer noch Optionen wie Mongoose OS, die drahtlose Firmware-Updates anbieten

IoT-Hersteller sollten generell vorhandene Lösungen nutzen, sofern verfügbar. Webentwickler erstellen normalerweise nicht für jede neue Website ein Webframework neu. Warum sollte das IoT also wesentlich anders sein? Rorys Antwort bietet eine hervorragende Liste von Funktionen, die von einem guten Betriebssystem für das IoT implementiert werden sollten , und die Verwendung eines "IoT-Betriebssystems" kann nicht alle Ihre Probleme beheben. Wie in diesem Windows IoT-Handbuch erläutert, müssen Schritte unternommen werden, um sicherzustellen, dass die Hardware und Firmware sowie das Betriebssystem selbst gesichert sind. Die Ideen in Rorys Antwort sind in dieser Hinsicht ziemlich umfassend.

Hier sind einige Beispiele aus den Betriebssystemen, die ich vorgeschlagen habe, welche Systeme sie zum Aktualisieren der Sicherheit verwenden:

• Windows IoT:

  • Automatische Funktions- und Sicherheitsupdates bei Verbindung mit dem Internet
  • Mit Azure IoT Suite verfügt jedes Gerät über ein X.509-Zertifikat zur Authentifizierung beim Hub. Dies stellt auch sicher, dass andere nicht betroffen sind, wenn ein Gerät kompromittiert wird

• Ubuntu Core :

  • Unbeaufsichtigte automatische Updates für die Sicherheit
  • "Transaktions-Over-the-Air-Updates - mit vollständigen Rollback-Funktionen"

Moran hat diesen IETF-Entwurf mit dem Titel A Firmware Update Architecture für Internet of Things-Geräte am 30. Oktober 2017 veröffentlicht.

Eine wichtige Zusammenfassung, die am Bleeping-Computer beschrieben wird, ist

• Der Update-Mechanismus muss auch dann funktionieren, wenn die Firmware-Binärdatei über Bluetooth, WiFi, UART, USB oder andere Medien bereitgestellt wird.
• Der Aktualisierungsmechanismus muss in einer Broadcast-Zustellungsart funktionieren, damit Aktualisierungen mehrere Benutzer gleichzeitig erreichen können.
• End-to-End-Sicherheit (Kryptografie mit öffentlichem Schlüssel) muss verwendet werden, um Firmware-Images zu überprüfen und zu validieren.
• Rollback-Angriffe müssen verhindert werden.
• Alle Informationen, die ein Gerät benötigt, um eine Entscheidung über die Installation eines Updates zu treffen, müssen in den verfügbaren RAM eines eingeschränkten IoT-Geräts passen. Dies verhindert eine Erschöpfung des Flash-Schreibens.
• Ein Stromausfall zu irgendeinem Zeitpunkt während des Aktualisierungsvorgangs darf keinen Ausfall des Geräts verursachen.
• Der Firmware-Aktualisierungsmechanismus darf keine Änderungen an vorhandenen Firmware-Dateiformaten erfordern.
• Der neue Firmware-Aktualisierungsmechanismus muss mit einem kleinen Bootloader betrieben werden können, der für die meisten IoT-Geräte spezifisch ist.
• Der Aktualisierungsmechanismus muss mehrere Berechtigungen berücksichtigen. Beispielsweise muss ein Firmware-Update für Geräte mit kritischer Infrastruktur sowohl vom Firmware-Autor als auch vom Eigentümer / Betreiber des Geräts signiert werden.
• Die neue IoT-Firmware-Update-Architektur muss Manifestdateien unterstützen.

Dies ist ein Entwurf, da dies ein neuer Bereich ist. Ich gehe davon aus, dass dies mehr von der Regulierung als von der Verbrauchernachfrage abhängt, da sich die Verbraucher wirklich nicht um Updates oder Sicherheit kümmern, es sei denn, sie wirken sich direkt auf sie aus. Verbesserungen in diesem Bereich wirken sich auf die Gerätekosten aus.

Wenn die Firmware Ihres Geräts weniger komplex sein kann als der für ein sicheres Remote-Update erforderliche Bootloader, implementieren Sie kein Remote-Update .

Ich weiß, dass der Konsens darin besteht, einen gesicherten und robusten Bootloader mit starker öffentlicher Kryptoauthentifizierung, sicheren Rollover-Mechanismen und möglicherweise einem grundlegenden Netzwerkstapel zu haben und dann ein RTOS mit einem vollständigen IP + TLS-Netzwerkstapel hinzuzufügen und dann hinzuzufügen Darüber hinaus Ihre Bewerbung. Dies ist purer Wahnsinn für ein kostengünstiges Gerät mit geringem Stromverbrauch. IMHO führt dies zu Produkten, die jede Woche oder so aktualisiert werden und die Benutzer eher stören, da Aktualisierungen manchmal im falschen Moment beginnen, fehlschlagen oder etwas kaputt machen. Updates verbrauchen auch viel Strom, sodass Benutzer häufiger aufladen müssen. Und die Sicherheit ist noch lange nicht garantiert, da die Angriffsfläche groß ist.

Ihr Gerät führt grundlegende Erfassungen / Betätigungen durch, möglicherweise lokale Auslösungen / Anzeigen, aber nicht viel? Überspringe das alles.

Schreiben Sie Bare-Metal-Code, verwenden Sie einen sehr einfachen Stapel, prüfen Sie ihn gründlich und führen Sie nach Möglichkeit eine formale Überprüfung durch. Und dann können Sie relativ sicher sein, dass Ihr Gerät in den nächsten zehn Jahren keine Sicherheitsprobleme mehr hat.

Wenn Sie nur einen Hammer haben, sieht alles aus wie ein Nagel. Und deshalb versuchen die meisten Codierer, Code zu schreiben, um ihren ungesicherten vorhandenen Code zu sichern. Weniger Code zu schreiben ist nicht immer selbstverständlich.