Sicherheit in der Fertigung: Schließen der Backdoors in IoT-Produkten

| Autor / Redakteur: Josh Norem * / Michael Eckstein

Sensibles Umfeld: Nicht zuletzt in der Fertigung dürfen IoT-Geräte nicht zum Einfallstor für Hacker werden.
Sensibles Umfeld: Nicht zuletzt in der Fertigung dürfen IoT-Geräte nicht zum Einfallstor für Hacker werden. (Bild: Clipdealer)

Ein System ist nur so sicher wie seine schwächste Komponente. Das gilt auch für IoT-Applikationen. Daher kommt der Fertigung von IoT-Geräten eine besondere Bedeutung zu.

Es wird viel über die Sicherheit von Hard- und Software wie ICs, Module und Wireless-Protokolle berichtet. Doch die Absicherung des Produktionsprozesses für Geräte bleibt oft außen vor. Dabei könnten Hacker zum Beispiel über den Angriff auf einen Vertragsfertiger (CM, Contract Manufacturer) Sicherheitsmechanismen wie Smart Locks aushebeln. Ein grundlegendes Problem in der Fertigung ist, dass es mit aktuellen Embedded-Prozessoren sehr schwierig ist, die Integrität eines Firmware-Images sicherzustellen. Ist die Firmware in reinem Text programmiert, lässt sie sich auf dem Testsystem leicht modifizieren. Bei verschlüsselter Firmware könnte ein Hacker alternativ den Bootloader attackieren. Mit hoher Wahrscheinlichkeit gibt es eine Ebene, die Klartext enthält und sich als Angriffsziel eignet (Abbildung 1).

Jeder vertrauliche Boot-Ladevorgang, der bei einem nicht vertrauenswürdigen CM stattfindet, folgt letztlich dem gleichen Muster. Zuerst wird das Gerät gesperrt. Dann führt es unter Verwendung eines privaten Schlüssels einen Schlüsselaustausch mit einem vertrauenswürdigen Server durch, auf den der Fertiger keinen Zugriff hat. Sobald der Schlüsselaustausch erfolgt ist, können Informationen vertraulich zwischen Server und Gerät ausgetauscht werden. Vertraulichkeit erfordert jedoch Integrität. Wenn Angreifer die Firmware des Geräts ändern können, um einen bekannten privaten Schlüssel zu erzeugen, dann können sie auch das an das Gerät gesendete Image entschlüsseln.

Backdoors für Diagnose von Problemen

Hinzu kommt: Um Probleme im Feld oder bei der Rückgabe von Produkten diagnostizieren zu können, müssen sich sowohl der IC-Hersteller als auch der Systementwickler Zugang zu gesperrten Geräten verschaffen. Die gebräuchlichste Lösung ist es, mithilfe eines Backdoor-Zugangs „entsperren + löschen“ zu erlauben. Dadurch werden beim Entsperren eines Geräts alle Flash-Dateien gelöscht. Für Debug-Zwecke sind diese Informationen dann verloren. Außerdem öffnet diese Vorgehensweise auch eine Sicherheitslücke für Angriffe, die sich auf das Löschen und Umprogrammieren des Geräts mit geändertem Code konzentrieren. Andere Ansätze bieten eine unbeschränkte Backdoor, die sich ohne Löschen öffnet, oder eine permanente Sperre, die das Gerät schützt, aber die Fehlersuche unmöglich macht.

Die einfachste Lösung zum Absichern eines Fertigungsprozesses ist das Implementieren eines Sampling-Authentifizierungsprogramms in einem anderen Werk. Dieses zeigt mögliche Manipulationsversuche beim CM an. Um eine solche Prüfung zu umgehen, muss der Angreifer entweder zusätzlich zum CM den Engineering-Standort kompromittieren oder wissen, welche Geräte zur Überprüfung geschickt werden und sie vom Angriff ausschließen. Um den Code bei einem Engineering-Standort zu authentifizieren, muss man ihn auslesen.

Hash mit zufällig erzeugtem Startwert berechnen

Typischerweise werden MCUs jedoch nach der Produktion gesperrt. Eine Prüfmethode sollte davon ausgehen, dass jeder Gerätecode kompromittiert sein könnte. Sie könnte dazu ein Prüfsumme oder einen Hash-Code des Images berechnen und über eine Standardschnittstelle (UART, I2C) auslesen. Doch ist diese Option auf Code angewiesen, der beim Generieren kompromittiert werden kann. Wenn Angreifer ein Image ersetzt haben, können sie auch die Hashing-Funktion ersetzen. Ideal für das Authentifizieren des korrekten Images ist es, wenn eine Verifizierungsfunktion einen Hash des Images auf Basis eines vom Testsystem zufällig erzeugten und übergebenen Startwerts (Seed) erzeugen kann. Da der Hash-Wert vom Startwert abhängt, kann ein Angreifer ihn nur berechnen, wenn er Zugriff auf das gesamte Originalbild hat.

Ähnlich wie beim Stichprobenprogramm können die Leiterplattenmontage und -programmierung an einem Standort erfolgen, der Test an einem anderen. Dieser Ansatz fängt einen Angriff sofort ab und verhindert, dass kompromittierte Einheiten ausgeliefert werden. Er hat jedoch dieselben Nachteile wie das Samplingverfahren, da eine Möglichkeit zur Authentifizierung der Firmware während der Testphase erforderlich ist. Es ist verlockend, das Gerät während der Fertigung zu programmieren und erst nach dem Test zu sperren. Ein spezieller Verifizierungscode entfällt, da der Inhalt des Gerätes einfach ausgelesen werden kann. Die meisten Embedded-Prozessoren bleiben allerdings programmierbar, wenn Debugging erlaubt ist. Angreifer könnten dies ausnutzen, indem sie den Teststandort kompromittieren und dort ihre geänderte Firmware in die produzierten Geräte programmieren. Over-the-Air-(OTA)-Updates können helfen, Geräte davor zu schützen.

Eine Komplettlösung für die Firmware-Integrität

Eine sichere Lösung basiert auf Hardware, die einen hart codierten öffentlichen Authentifizierungsschlüssel und fest codierte Befehle zu dessen Verwendung enthält – zum Beispiel in einem ROM. Obwohl dieser Speicher durch physikalische Analyse leicht auszulesen ist, lässt er sich kaum kontrolliert und zerstörungsfrei verändern. Die in das Gerät geladene Firmware muss signiert werden. Nach dem Reset beginnt die CPU mit der Ausführung des ROMs und kann mit dem ebenfalls im ROM gespeicherten öffentlichen Authentifizierungsschlüssel überprüfen, ob der Flash-Inhalt korrekt signiert ist.

Versucht ein Angreifer, eine modifizierte Version der Firmware zu laden, schlägt die Authentifizierung fehl und das Gerät bootet nicht. Um ein modifiziertes Image zu booten, muss der Angreifer eine gültige Signatur für seine modifizierte Firmware bereitstellen, die nur mit einem gut geschützten privaten Schlüssel erzeugt werden kann. Der fest codierte öffentliche Schlüssel (Manufacturer Public Key) ist für alle Geräte gleich, da er nicht veränderbar ist. Er ist ein Vertrauensanker für alle Geräte und deswegen sehr wertvoll. Den zugehörigen privaten Schlüssel (Manufacturer Private Key) muss der IC-Hersteller gut schützen. Ein Benutzer darf niemals Zugriff darauf haben, um seinen Code zu signieren. Beim Booten wird der öffentliche Schlüssel des Herstellers verwendet, um jeden vom IC-Hersteller bereitgestellten Code zu validieren (Abbildung 2).

Schlüsselpaar zum Signieren und Authentifizieren

Gerätebenutzer benötigen ihr eigenes Schlüsselpaar (User Private Key und User Public Key) zum Signieren und Authentifizieren von Firmware-Images. Um den öffentlichen Schlüssel des Benutzers in den Vertrauensanker einzubinden, muss der IC-Hersteller den öffentlichen Schlüssel des Benutzers mit dem privaten Schlüssel des Herstellers signieren und ein Benutzerzertifikat erstellen. Ein Zertifikat ist einfach ein öffentlicher Schlüssel mit einigen zugehörigen signierten Metadaten. Beim Booten authentifiziert das Gerät das Benutzerzertifikat mit dem öffentlichen Schlüssel des Herstellers. Die User-Firmware kann mit dem User Public Key im gültigen Benutzerzertifikat authentifiziert werden.

Ein weiterer Schritt ist erforderlich, um ein Gerät für einen bestimmten Benutzer zu sperren. Das zuvor beschriebene System kann nur sicherstellen, dass das Benutzerzertifikat vom IC-Hersteller signiert wurde. Während dies eine Neuprogrammierung des Geräts verhindert, könnte ein anderer legitimierter Kunde seinen Code und sein rechtmäßig signiertes Zertifikat auf das Gerät schreiben, und es würde booten. Daraus folgt: Wenn ein Angreifer den IC-Hersteller davon überzeugen kann, dass er ein legitimer Kunde ist und ein signiertes Benutzerzertifikat generieren kann, kann er das Gerät dazu bringen, seinen Code zu booten.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45586600 / Industrie 4.0)