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

| Autor / Redakteur: Josh Norem * / Michael Eckstein

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.

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 (Abbildung 3).

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.

* Josh Norem ist Assistant Staff Senior Systems Engineer bei Silicon Labs in Austin/Texa.s

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? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45586600 / Industrie 4.0)