Verwendung von E-Paper-Anzeigen, um auf tödliche Fehler und kompromittierte Sicherheit in kritischen IoT-Knoten hinzuweisen

Von Bill Giovino

Zur Verfügung gestellt von Nordamerikanische Fachredakteure von DigiKey

Internet of Things (IoT) und industrielle IoT-Knoten (IIoT) werden in immer sichereren Systemen eingesetzt, bei denen die Sicherheit des Netzwerks als Ganzes wichtiger ist als die Funktionalität der einzelnen Geräte in diesem Netzwerk. Das bedeutet, dass, wenn ein IoT-Knoten erkennt, dass er kompromittiert wurde, oder wenn ein nicht behebbarer Firmware-Fehler auftritt, die sicherste Maßnahme möglicherweise darin besteht, dass der Knoten sich so schnell wie praktisch möglich abschaltet, um den Knoten und das Netzwerk vor potenziell gefährlichen Folgen zu schützen.

Sobald der Knoten jedoch abgeschaltet wird, sind alle flüchtigen Speicherinhalte verloren. Das Speichern von Debug-Daten in nichtflüchtigen Speichern wie EEPROM oder Flash verbraucht Zeit und Strom, was das Risiko möglicher Schäden erhöht. Darüber hinaus kann das System so weit beeinträchtigt worden sein, dass das Zurücklesen der Daten beim Einschalten möglicherweise keine vertrauenswürdigen Daten liefert, wenn die Einschaltsequenz ebenfalls beeinträchtigt wurde.

In diesem Artikel wird erläutert, wie E-Paper-Displays (EPDs) einfach an einem IoT- oder IIoT-Knoten angebracht werden können, um den letzten bekannten Fehler anzuzeigen und eine visuelle Anzeige des Grundes für das Abschaltungsereignis zu erhalten, damit Techniker die entsprechenden Maßnahmen ergreifen können. Anschließend werden Beispiele von E-Paper-Displays aus Pervasive Displays und Display Visions vorgestellt und diskutiert, wie diese Displays an einen Mikrocontroller angeschlossen und so konfiguriert werden können, dass sie Diagnoseinformationen liefern, während sie wenig oder gar keinen Strom verbrauchen.

Hochsichere IoT- und IIoT-Knoten

Es liegt zunehmend in der Verantwortung der Entwickler von IoT- und IIoT-Knoten, über immer ausgefeiltere Sicherheitsmethoden zu verfügen, um den ordnungsgemäßen Betrieb des Host-Mikrocontrollers zu gewährleisten. Im Allgemeinen gibt es drei Arten von Sicherheitsbedrohungen, vor denen man sich schützen muss:

  1. Fehlfunktion der Firmware eines Mikrocontrollers
  2. Ungültige Eingabedaten von Sensoren, Tastaturen, seriellen Peripheriegeräten oder anderen externen Geräten
  3. Aktion eines böswilligen Akteurs

Eine Fehlfunktion der Mikrocontroller-Firmware kann aus einer Reihe von Gründen auftreten: Codierungsfehler in der installierten Firmware, ungültige Berechnungen, die zu einer Fehlfunktion führen, oder, in extrem seltenen Fällen, eine Hardware-Fehlfunktion des Mikrocontrollers. Gut geschriebene Firmware erkennt dies in der Regel durch Scrubbing der Eingaben in Unterroutinen und Funktionen. In extremen Fällen, in denen die Firmware gesperrt oder in eine Schleife geschaltet ist, stellt ein Watchdog-Timeout die Firmware wieder her, indem es zu einer Fehlerkontroll-Unterroutine vektorisiert oder einen Hard-Reset des Mikrocontrollers durchführt.

Bei ungültigen Eingabedaten, z.B. bei Fehlfunktion oder Manipulation eines externen Sensors, kann es zu Daten außerhalb des Messbereichs kommen, die möglicherweise im Anwendungscode nicht richtig berücksichtigt wurden. Wenn beispielsweise der Umgebungstemperatursensor in einem von Menschen bewohnten Kontrollraum eine Blasenbildung von 250°F fälschlicherweise registriert, könnte dies eine Fehlfunktion des Sensors oder eine böswillige Manipulation sein. Ein unvorsichtiger Firmware-Programmierer hat möglicherweise nicht für so hohe Temperaturen kodiert, was zu etwas so Trivialem wie einer fehlerhaften Datenprotokollierung oder etwas so Ernsthaftem wie der Ermöglichung des Zugangs eines Eindringlings zu einem sicheren Bereich oder so kritisch wie ein Fehler bei der Berechnung eines Regelalgorithmus, der zu Geräteausfall oder schweren Personenschäden führen könnte, führen könnte. Die möglichen negativen Folgen sind vielfältig.

Böswillige Akteure unterscheiden sich darin, dass sie möglicherweise die absichtliche Absicht haben, eine Fehlfunktion des IoT-Knotens zu verursachen. Die durch den Hacking-Versuch verursachte Fehlfunktion könnte von den Sicherheitsroutinen als Einbruch erkannt werden; sie könnte sich jedoch auch als Fehlfunktion der Firmware oder als ungültige externe Eingabedaten tarnen. Das Beispiel einer Umgebungstemperaturanzeige von 250°F könnte dadurch verursacht werden, dass ein böswilliger Akteur das Verhalten der Firmware bei einer so hohen Anzeige mit der Absicht testet, eine Einbruchsmethode zu testen; so können beispielsweise Türen automatisch entriegelt werden, wenn die Anzeige der Umgebungstemperatur von 250°F fälschlicherweise als Feuer gewertet wird.

Reagieren auf Firmware-Fehlfunktionen

Unabhängig von der Fehlerquelle muss die Mikrocontroller-Firmware für hochsichere IoT- und IIoT-Knoten fehlertolerant sein. Alle Fehler müssen kodiert und eingefangen werden. Eingaben in Unterprogramme und Funktionen müssen gesäubert und alle Sensoreingabedaten validiert werden. Watchdog-Zeitgeber müssen mit der Absicht programmiert werden, gesperrten oder in Schleifen geschalteten Code zu erkennen, der aufgrund einer bekannten Laufzeit zu lange dauert.

Wenn eine Firmware-Fehlfunktion in einem hochsicheren IoT- oder IIoT-Knoten erkannt wird, unabhängig davon, ob die Fehlfunktion versehentlich oder absichtlich erfolgt, muss die Firmware das Ereignis so schnell wie möglich abfangen. Zu den gemeinsamen Aktionen gehört der Versuch, die Fehlfunktion auszugleichen. Bei einem defekten Sensor, der sich ständig außerhalb des Messbereichs befindet, kann die Firmware einen "Hinkebein-Modus" für diesen Sensor haben, um die schlechten Daten zu kompensieren, bis er ersetzt werden kann. Eine Firmware-Routine, die falsche Ergebnisse liefert, wird möglicherweise neu initialisiert. Häufig wird ein Fehlercode über das Netzwerk gesendet, um den Netzwerk-Host über das Problem zu informieren.

In einigen hochsicheren IoT- oder IIoT-Knoten gibt es jedoch eine besondere Kategorie von Fehlfunktionen, für die es keine Kompensations- oder Gegenmaßnahmen geben kann oder sollte. Dies kann die Erkennung physischer Manipulation, interne Prüfsummenfehler, einige Fehler beim eingebauten Selbsttest (BIST) und alle Fehler umfassen, die durch kompromittierte Firmware oder ein gehacktes System verursacht werden können. In diesen Hochsicherheitssituationen kann die einzige Möglichkeit darin bestehen, den Knoten sofort und sicher abzuschalten. Der Netzwerk-Host stellt fest, dass sich der Knoten abgeschaltet hat, wenn er nicht auf Netzwerkanforderungen reagiert. Wenn sich der Knoten abgeschaltet hat, ohne einen Fehlerbericht an den Host zu senden, und wenn der Knoten die Netzwerkbefehle zum Neustart ignoriert, ist dies ein Hinweis darauf, dass ein tödlicher Fehler aufgetreten ist und dass ein Techniker entsandt werden muss, um den Knoten physisch auf die Ursache zu untersuchen.

Sobald sich der Knoten jedoch abgeschaltet hat, werden alle flüchtigen Speicher und Statusdaten sofort gelöscht. Dies macht die Diagnose der Ursache der Abschaltung sehr schwierig, wenn nicht gar unmöglich. Optional könnten vor dem Abschalten des Knotens die Diagnosedaten in einem nichtflüchtigen Speicher wie EEPROM oder Flash-Speicher gespeichert werden. Das Problem ist, dass das Schreiben in diese Art von Speicher Zeit braucht, während der der Knoten aktiv bleiben muss und möglicherweise zusätzliche Schäden verursacht.

Fatale Fehler mit E-Paper diagnostizieren

EPDs verbrauchen sehr wenig Strom und können zur Speicherung und Anzeige von Fehler- und Diagnoseinformationen kurz vor dem Ausschalten des Knotens verwendet werden. Sobald der Knoten abgeschaltet ist, kann die EPD ihr Anzeigebild tage- oder wochenlang ohne Stromzufuhr aufrechterhalten. Die Informationen auf dem Display geben den Technikern einen visuellen Hinweis auf den Grund für die Abschaltung, so dass sie entscheiden können, ob es sicher ist, den IoT-Knoten einzuschalten, oder ob er für eine detaillierte Analyse vom Netz genommen werden sollte.

Ein Beispiel für ein EPD, das zur Anzeige diagnostischer Informationen geeignet ist, ist das EPD-Modul Pervasive Displays' E2271CS091 EPD-Modul. Er kann an jeden kompatiblen Mikrocontroller mit einer seriellen SPI-Schnittstelle angeschlossen werden und verfügt über ein kontrastreiches 2,71-Zoll-Display (Abbildung 1).

Bild von Pervasive Displays E2271CS091 EPD-Modul<Abbildung 1: Das EPD-Modul E2271CS091 verfügt über ein kontrastreiches 2,71-Zoll-Display mit einer Auflösung von 264 x 176 Pixeln. Er hat einen weiten Betrachtungswinkel und Schnittstellen zu jedem kompatiblen Mikrocontroller mit einer SPI-Schnittstelle. (Image source: Pervasive Displays)

Das EPD-Modul E2271CS091 verwendet ein Aktivmatrix-Dünnfilmtransistor-Display (TFT) mit einer nativen Auflösung von 264 x 176 Pixeln bei 117 Punkten pro Zoll (dpi). Dadurch kann die Anzeige viele Informationen enthalten, die den Techniker bei der Diagnose unterstützen. Der entspiegelte Bildschirm hat einen weiten Betrachtungswinkel von nahezu 180˚, so dass die Anzeige auch an ungewöhnlichen Montageorten gut zu erkennen ist. Der EPD benötigt eine 3,0-Volt-Stromversorgung.

Der Host-Mikrocontroller sendet Daten über eine SPI-Schnittstelle am 24-poligen Flachbandverbinder der Anzeige an den EPD. Die SPI-Datenkommunikation ist nur ein Weg, vom Host-Mikrocontroller zum EPD. Die einzige Kommunikation zurück vom EPD zum Host-Mikrocontroller ist ein "device busy"-Pin am Flachbandverbinder, was die Schnittstelle stark vereinfacht und das Vertrauen in die angezeigten Diagnosedaten erhöht.

Wenn ein Fehler oder ein Hackversuch festgestellt wird und der Fehler so schwerwiegend ist, dass ein Herunterfahren des Knotens erforderlich ist, muss der Fehler zunächst durch Firmware, Watchdog oder eine andere Methode abgefangen werden. Die Kontrolle muss dann an die Fehlerprotokollierungsroutine übergeben werden, die Daten an die EPD sendet. Diese Fehlerprotokollierungsroutine sollte die Aufgabe höchster Priorität sein, um eine Unterbrechung oder Verfälschung von Daten zu verhindern. Für maximale Zuverlässigkeit wird empfohlen, dass die Fehlerprotokollierungsroutine vollständig in sich geschlossen ist und keine Aufrufe externer Unterprogramme oder Funktionen enthält. Idealerweise sollte die Fehlerprotokollierungsroutine in permanent schreibgeschütztem Flash vorliegen, um die Integrität des Codes auch nach Firmware-Updates zu gewährleisten.

Bevor das EPD mit den Fehlerdaten aktualisiert wird, sollte der Host-Mikrocontroller zunächst einen Soft-Reset-Befehl über die SPI-Schnittstelle an das EPD senden, um die Anzeige zu löschen. Es sendet dann die Schwarz-Weiß-Anzeigeinformationen in einer Reihe von Bytefolgen, wobei jedes Bit in einem Byte ein Pixel auf der EPD darstellt. Sobald die Sequenz abgeschlossen ist, kann die Fehlerprotokollierungsroutine den Mikrocontroller abschalten. Verschiedene Hersteller von Mikrocontrollern haben unterschiedliche Möglichkeiten der Abschaltung, da dies architektur- und herstellerabhängig ist. In einigen Situationen und aus Sicherheitsgründen kann der Hersteller eine nicht dokumentierte Möglichkeit haben, den Mikrocontroller abzuschalten, die nur auf Anfrage erhältlich ist. Optional kann eine externe Schaltung verwendet werden, um die Stromversorgung des Mikrocontrollers zu unterbrechen; dies erhöht jedoch die Komplexität des Systems, was die Zuverlässigkeit verringert. Daher wird die Firmware-Abschaltsteuerung des Mikrocontrollers bevorzugt.

Um die Entwicklung mit der EPD zu unterstützen, bietet Pervasive Displays das B3000MS034 EPD-Erweiterungskit an (Abbildung 2). Es hat eine Erweiterungsplatine mit einem Steckverbinder für das 24-polige EPD-Display sowie Steckverbinder für andere Pervasive Display-EPDs, die 40-polige und 26-polige Steckverbinder benötigen. Die Erweiterungsplatine ist kompatibel mit Texas Instruments' LaunchPad Entwicklungs- und Evaluationskits, kann aber auch mit anderen Entwicklungs-Kits verwendet werden. An die 20-polige 90˚ Stiftleiste kann ein 20-poliges Brückenkabel angeschlossen werden, das, wenn es an die Erweiterungsplatine gelötet wird, die Überwachung der Steuersignale an das EPD während der Entwicklung ermöglicht.

Abbildung des Erweiterungskits für das Pervasive Displays E2271CS091 EPD-Modul<Abbildung 2: Das Erweiterungskit für das EPD-Modul für Pervasive Displays E2271CS091 enthält einen 24-poligen Steckverbinder auf der Erweiterungsplatine für das 24-polige Flachbandkabel des Displays. Es enthält auch ein Überbrückungskabel und einen 20-poligen 90˚ Pfostenstecker. (Image source: Pervasive Displays)

Eine weitere EPD-Option ist die Display Visions EA EPA20-A (Abbildung 3).

Bild von Display-Visionen EA EPA20-A EPD<Abbildung 3: Das Display Visions EA EPA20-A EPD ist ein 172 x 72-Display, das den Display-Status auch ohne angeschlossenen Strom aufrechterhalten kann. (Bildquelle: Display Visions)

Diese EPD hat ein 172 x 72 Graustufen-Display und verwendet außerdem eine SPI-Schnittstelle für die Kommunikation mit einem Host-Mikrocontroller. Der EPD ist extrem stromsparend, benötigt eine einzige 3,3-Volt-Versorgung und nimmt während eines Display-Wechsels nur 40 Milliwatt (mW) auf. Die Display-Visionen EA EPA20-A EPD können ihre Anzeige auch im spannungslosen Zustand beibehalten.

Fazit:

Hochsichere IoT- und IIoT-Knoten müssen sich manchmal als Reaktion auf einen fatalen Firmware-Fehler oder eine erkannte Bedrohung abschalten. Dies kann zum Verlust aller flüchtigen Daten einschließlich des internen Status des Host-Mikrocontrollers führen. Status- und Diagnosedaten können jedoch vor der Abschaltung an einen angeschlossenen EPD gesendet und für Tage oder Wochen angezeigt werden. Dadurch erhalten die Techniker die Informationen, die sie benötigen, um die Ursache der Abschaltung zu ermitteln und ggf. zukünftige Vorkehrungen zum Schutz und zur Sicherung des Knotens und des Netzwerks zu treffen.

DigiKey logo

Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der DigiKey oder offiziellen Politik der DigiKey wider.

Über den Autor

Image of Bill Giovino

Bill Giovino

Bill Giovino ist Elektronikingenieur mit einem BSEE von der Syracuse University und einer der wenigen, die erfolgreich vom Entwicklungsingenieur über den Anwendungsingenieur zum Technologiemarketing wechselten.

Seit über 25 Jahren wirbt Bill für neue Technologien vor technischem und nicht-technischem Publikum für viele Unternehmen, darunter STMicroelectronics, Intel und Maxim Integrated. Während seiner Zeit bei STMicroelectronics trug Bill dazu bei, die frühen Erfolge des Unternehmens in der Mikrocontroller-Industrie voranzutreiben. Bei Infineon inszenierte Bill die ersten Erfolge des Unternehmens im Bereich Mikrocontroller-Design in den USA. Als Marketingberater für sein Unternehmen CPU Technologies hat Bill vielen Unternehmen geholfen, unterbewertete Produkte in Erfolgsgeschichten zu verwandeln.

Bill war zudem ein früher Anwender des Internets der Dinge, einschließlich der Implementierung des ersten vollständigen TCP/IP-Stacks auf einem Mikrocontroller. Die Botschaft von „Verkauf durch Aufklärung“ und die zunehmende Bedeutung einer klaren, gut geschriebenen Kommunikation bei der Vermarktung von Produkten im Internet sind Bills Anliegen. Er ist Moderator der beliebten „Semiconductor Sales & Marketing Group“ auf LinkedIn und spricht fließend B2E.

Über den Verlag

Nordamerikanische Fachredakteure von DigiKey