IT-Sicherheit in der Fertigung Backdoors in der Produktion von IoT-Geräten schließen

Anbieter zum Thema

SEPPmail - Deutschland GmbH

TXOne Networks

Keeper Security EMEA Ltd.

Silicon Laboraties GmbH

Silicon Labs

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 (Siehe Abbildung 1 in der Bildergalerie).

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.

Bildergalerie

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 (Siehe Abbildung 2 in der Bildergalerie).

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.

Benutzerkennung im gesicherten Code-Bereich

Um ein Gerät für einen bestimmten Endbenutzer zu sperren, muss das Benutzerzertifikat den öffentlichen Schlüssel des Benutzers sowie eine Benutzer-ID enthalten, damit eine Änderung entweder des Schlüssels oder der ID das Zertifikat ungültig macht. Der IC-Hersteller programmiert die Benutzerkennung in den Herstellercode-Bereich, wo sie durch den öffentlichen Schlüssel des Herstellers geschützt ist. Beim Booten überprüft der Bootvorgang die Signatur des Benutzerzertifikats und vergleicht die Benutzer-ID im Zertifikat mit der im Herstellercode. Wenn jemand versucht, einen Teil des Systems zu verändern, passiert folgendes:

• Wenn die Benutzerkennung im Herstellercode geändert wird, ist die Signatur dieses Bereichs nicht mehr gültig und das Gerät bootet nicht.

• Wenn die Benutzerkennung im Benutzerzertifikat geändert wird, stimmt sie nicht mit der im Herstellerzertifikat überein, und das Gerät bootet nicht.

• Wenn entweder der öffentliche Schlüssel des Benutzers oder die Benutzerkennung im Benutzerzertifikat geändert wird, ist das Zertifikat ungültig, und das Gerät bootet nicht.

• Wenn das Benutzer-Firmware-Image geändert wird, ist die Signatur ungültig, und der Gerät bootet nicht.

Tatsächlich bootet ein solches System nur Firmware, die vom Kunden, der das Teil beim IC-Hersteller bestellt hat, ordnungsgemäß signiert wurde. Die Sicherheit basiert also auf dem privaten Schlüssel des Herstellers und dem privaten Schlüssel des Benutzers, die beide nur zum Signieren neuer Images verwendet werden. Natürlich muss auch in diesem System das Zertifikatsystem korrekt implementiert sein. Der private Schlüssel des Herstellers ist sehr wertvoll, da er für jedes Gerät gilt, das der IC-Hersteller baut. Er wird zudem häufig aufgerufen, da er ständig zum Signieren von Benutzerzertifikaten verwendet wird. Das lässt sich vermeiden, indem für jeden Chip ein anderes Public-Private-Key-Paar des Herstellers erstellt wird. Im Falle einer Kompromittierung eines Schlüssels ist dann nur ein Chip betroffen. Anstatt Benutzerzertifikate direkt mit dem privaten Schlüssel des Herstellers zu signieren, kann eine Hierarchie von Unterschlüsseln entwickelt und für diesen Vorgang verwendet werden, so dass der Unterschlüssel durch ein Herstellercode-Update rückgängig gemacht werden kann, wenn er kompromittiert wird.

Bildergalerie

Sichere Debug-Freischaltung gezielt bereitstellen

Das Bereitstellen einer sicheren Debug-Entsperrung ist recht einfach. Jeder Systementwickler generiert dazu ein Schlüsselpaar für den Debug-Zugriff und programmiert den öffentlichen Debug-Schlüssel in das Gerät. Die Integrität des Schlüssels kann auf die gleiche Weise wie die Firmware des Benutzers hergestellt werden, so dass niemand den öffentlichen Debug-Schlüssel manipulieren kann. Jedes Gerät erhält außerdem eine eindeutige ID. Um ein Gerät zu entsperren, wird seine eindeutige ID ausgelesen und mit dem privaten Debug-Schlüssel signiert. Dadurch wird ein Entsperr-Zertifikat erzeugt, das zur Authentifizierung gegen den öffentlichen Debug-Schlüssel in das Gerät eingespeist wird. Wenn es sich authentifiziert hat, wird das Gerät entsperrt. Dadurch wird sichergestellt, dass nur diejenigen, die Zugriff auf den privaten Debug-Schlüssel haben, ein Entsperrungszertifikat erzeugen können, und nur diejenigen, die ein Entsperrungszertifikat besitzen, können das Gerät entsperren (Siehe Abbildung 3 in der Bildergalerie).

Der private Debug-Schlüssel kann auf einem sicheren Server gespeichert und gut geschützt werden. Da sich die Geräte-ID nicht ändert, erfolgt das Generieren eines Zertifikats zum Entsperren nur einmal. Nur dieses Zertifikat ist berechtigt, das Gerät so lange wie nötig zu entsperren. Ein Vorteil dieser Methode ist, dass sie Zertifikate pro Gerät freischaltet. Das bedeutet, dass es möglich ist, dem Außendienstpersonal oder dem IC-Hersteller nur auf dem zu diagnostizierenden Gerät Freischaltberechtigungen zu erteilen.

Nicht benötigte Zertifikate entwerten

Ein Nachteil ist, dass jeder, der Zugriff auf das Entsperrungszertifikat hat, das Gerät entsperren kann. Um dieses Risiko zu minimieren, kann ein Zähler an das Ende der eindeutigen ID angehängt werden. Ein Zertifikat, das nicht mehr benötigt wird, lässt sich dann durch Weiterschalten des Zählers über einen Debugger-Befehl entwerten. Dadurch wird eine neue ID generiert, und das alte Zertifikat ist nicht mehr gültig. Je mehr Geräte ein privater Schlüssel zugänglich macht, desto wertvoller wird er. Daher sollten Systementwickler die Debug-Entsperrschlüssel regelmäßig ändern, um die Anzahl der betroffenen Geräte zu begrenzen, falls ein privater Entsperrschlüssel gefährdet ist.

Es kommt vor, dass beispielweise geänderte Fertigungsanforderungen Sicherheitslecks in ein Design reißen. So kann ein Systemhersteller vergessen, die Debug-Schnittstelle als Teil seines Boardtests zu deaktivieren und Geräte mit einem geöffneten Debug-Port ausliefern. Häufiger sind absichtliche Sicherheitslücken. Zum Beispiel kann ein Entwickler eine Möglichkeit vorsehen, den Debug-Zugriff nach dem Sperren wieder zu öffnen und einen geheimen Befehl oder Pin-Status einzugeben, mit dem sich ein Gerät entsperren lässt. Auf solche Möglichkeiten sollten Entwickler besser verzichten.

Gesamte Kette muss betrachtet werden

Server und Prüfprogramme sind ebenfalls Teil des Fertigungsablaufs und können anfällig für Angriffe sein. Ein sicheres System und ein sicherer Herstellungsprozess helfen nicht, wenn Dateien über einen FTP- oder E-Mail-Server an den CM übertragen werden, der seit Jahren nicht mehr gepatcht wurde. Jeder Ort, an dem Dateien gespeichert werden, sollte als Teil des Systems betrachtet und gesichert werden. So wie die Produktherstellung oft eine untergeordnete Rolle spielt, wird auch die Produktentwicklung häufig übersehen.

Die vorgestellten Maßnahmen verpuffen wirkungslos, wenn ein Angreifer unbemerkt Änderungen am Quellcode-Repositorium vornehmen kann. Manchmal geschieht dies durch eine externe Penetration (elektronisches oder physikalisches Eindringen in das Gebäude) oder durch das Kompromittieren eines Mitarbeiters. Standardpraktiken der IT-Systemsicherheit und der Codierung spielen eine große Rolle beim Verhindern dieser Art von Angriffen. Diese Praktiken umfassen das Sicherstellen, dass alle PCs automatisch gesperrt werden, wenn sie nicht in Gebrauch sind, das unumgängliche User-Login für den Zugriff auf Code-Repositorien, das Durchführen von Code-Reviews bei allen Repositorium-Commits und das Durchführen von Testregressionen bei Release-Kandidaten.

Effiziente IT-Sicherheit mit übergreifendem Ansatz

IT-Sicherheit wird in Embedded-Systemen immer wichtiger. Produkte, die früher eigenständig waren, sind heute Teil eines Netzwerks. Das steigert sowohl ihre Verwundbarkeit als auch ihren Wert. Während bislang primär die IoT-Geräte im Fokus von IT-Sicherheitsbetrachtungen standen, muss heute dem gesamten Entwicklungs- und Fertigungsprozesses mehr Aufmerksamkeit gewidmet werden. Effektive Sicherheit setzt voraus, dass alle, vom Halbleiteranbieter über Designfirmen bis hin zu OEMs, zusammenarbeiten. Die gute Nachricht ist, dass neue Hardware-Features entwickelt werden, um diese Probleme zu lösen. Systementwickler können damit bereits heute mit der Implementierung einfacher Maßnahmen beginnen, um eine sicherere Fertigungsumgebung zu schaffen.

Über den Autor: Josh Norem ist Assistant Staff Senior Systems Engineer bei Silicon Labs in Austin/Texas.

Dieser Artikel erschien zuerst auf unserem Partnerportal Elektronikpraxis.

(ID:45661498)