Print

Eine Zertifizierung der Geräte verhindert einen Man-in-the-Middle-Angriff. (Bild: Green Hills Software)

| von Gregory Rudy

Eckdaten

Eine Sicherheitsarchitektur muss nicht nur das Target, sondern alle Endpunkte und Benutzer innerhalb des Gesamtsystems enthalten. Bevor man Befehlen und Geräten trauen kann, müssen alle entfernten Endprodukte authentifiziert werden. Gregory Rudy von Green Hills beschreibt in seinem Artikel wie sich ein optimales Verschlüsselungssystem erreichen lässt.

In der Zeit vor Mobiltelefonen und Textnachrichten, wiesen Eltern ihre Kinder darauf hin: „Wenn irgendetwas passiert und wir dich nicht abholen können, steige nur in ein Auto von Familienangehörigen oder Nachbarn ein, die unser Geheimwort kennen.“ Aus Sicht eines Sicherheitsfachmanns scheint dies heute sehr unvorsichtig zu sein, aber es funktionierte. Im Nachhinein war diese grundlegende Form der Authentifizierung nur aufgrund der Umgebung, in der sie verwendet wurde, erfolgreich. Geheimworte wurden zu Hause ausgetauscht, ohne dass eine andere Person zuhörte. Und Vertrauenspersonen wurden visuell erkannt.

Die heutige Umgebung vernetzter IoT-Einrichtungen beziehungsweise -Produkte ist ganz anders, aber viele Entwickler verwenden immer noch die gleiche geheime Authentifizierung – wenn überhaupt. Bei der Entwicklung für Datensicherheit (Security) muss die Betriebsumgebung den erforderlichen Grad an Robustheit bestimmen. Eine Sicherheitsarchitektur muss nicht nur das Target, sondern alle Endpunkte und Benutzer innerhalb des Gesamtsystems enthalten. Es gibt zwar Seriennummern, MAC-Adressen, weiße und schwarze Listen – diese Designs sind aber nicht 100-prozentig sicher. Die meisten Embedded-Hacks werden durch Überwachung des Netzwerkverkehrs mittels Reverse-Engineer-Befehlen durchgeführt. Anschließend wird die gleiche oder geänderte Version von einer anderen Stelle wiedergegeben. Infusionspumpen, Fahrzeuge, Zahlungsterminals, funkgesteuerte Thermostate und Sicherheitssysteme werden dann durch Spoofing-Angriffe beeinträchtigt.

In der IoT-Welt ist jeder ein Fremder, bis etwas anders bewiesen ist. Auch private Netzwerke unterliegen Datenverletzungen und sind genauso anfällig wie das Internet. Wenn kein Netzwerk sicher ist, müssen alle entfernten Endpunkte authentifiziert werden, bevor man Befehlen und Daten trauen kann. Beim Übergang vom Menschen auf den Rechner entspricht das Geheimwort dem (Code-) Schlüssel. Designs mit geheimen Schlüsseln machen in kleineren Umgebungen Sinn. Da aber die Anzahl der Geräte wächst, steigt auch die Komplexität und die Kosten nehmen zu, um diese Schlüssel zu schützen. Ist ein geheimer Schlüssel aufgrund einer Kompromittierung eines einzelnen Geräts exponiert, dann ist jedes andere System in der Umgebung anfällig und kann nicht von einem vertrauenswürdigen System unterschieden werden.

Optimales Verschlüsselungssystem

Benutzernamen und Passwörter helfen, einzigartige geheime Schlüssel dynamisch zu generieren, die bei Bedarf eingegeben werden und nicht im nichtflüchtigen Speicher gespeichert werden müssen. Dadurch sinkt das Kompromittierungsrisiko. Dies funktioniert zwar in einigen Umgebungen, aber viele Produkte verfügen nicht über das Nutzerkonzept und müssen sofort sicher arbeiten, sobald sie eingeschaltet werden. Diese Umgebungen erfordern für die Authentifizierung und Verschlüsselung gemeinsame geheime Schlüssel zwischen beiden Endpunkten. Aber wie kommen die Schlüssel ins System? In militärischen Umgebungen werden spezielle Handheld-Computer (Key Fill Devices) verwendet, um geheime Schlüssel physisch zu laden. Systeme werden mit einem „Fill Port“ entwickelt, um Schlüssel zu akzeptieren, damit sie nie exponiert sind. Key Fill Devices und Key-Management-Systeme schützen Schlüssel während der Verteilung, bis sie sicher innerhalb der Sicherheitsgrenze eines Geräts gespeichert sind. Entwickler müssen jedoch durch die System-Sicherheitsarchitektur regeln, wie die Schlüssel während der Fertigung geladen und während des gesamten Lebenszyklus geschützt werden. Die Anzahl der Endpunkte, die geschützten Speichergrößen, Leistungsfähigkeit, Langlebigkeit der Algorithmen und die Fertigungskette sind alles entscheidende Faktoren bei der Entwicklung des optimalen Verschlüsselungssystems. Hier steht Hilfe zur Verfügung.

Best-Practice-Sicherheit

Public-Key-Verschlüsselung vereinfacht die Komplexität gemeinsamer Schlüssel, indem jeder Endpunkt mit einem einzigen eindeutigen asymmetrischen Schlüsselpaar für die Verschlüsselung und Authentifizierung ausgestattet wird. Best-Practice-Sicherheit verwendet niemals den gleichen Schlüssel für beide. Ist ein Endpunkt kompromittiert und ein privater Schlüssel exponiert, ist die Schwachstelle nur auf dieses System beschränkt. Durch Sperrlisten (Revocation Lists) kann das kompromittierte System sicher aus der Umgebung entfernt werden, sodass es nicht irrtümlich von anderen als sicher angesehen wird. Die asymmetrische Verschlüsselung ermöglicht es zwei Endpunkten, Public Keys offen auszutauschen, um sicher zu kommunizieren, ohne den Schlüssel des anderen vorab platzieren zu müssen. Damit verbessert sich die Skalierbarkeit auf eine große Anzahl von Geräten, wobei alle Geräte sich vorher nicht kennen müssen.

Asymmetrische Verschlüsselung

Bild 2: Die Einbettung von Zertifikaten in ein Embedded-Design ermöglicht die Trennung und Interoperabilität vom Wettbewerber. Green Hills Software

Die Einbettung von Zertifikaten in ein Embedded-Design ermöglicht die Trennung und Interoperabilität vom Wettbewerber. Green Hills Software

Durch asymmetrische Verschlüsselung können die Endpunkte sicher kommunizieren, ohne die Schlüssel vorher verteilen zu müssen. Wie aber weiß ein Gerät, ob es sicher mit dem richtigen Endpunkt kommuniziert? Zertifikate werden verwendet, um Man-in-the-Middle-Angriffe während des Austauschs von Public Keys zu verhindern und die Identität eines entfernten Endpunkts zu bestätigen. Grundsätzlich besteht ein Zertifikat aus Metadaten einschließlich Name, Seriennummer, Ablaufdaten und weitere, das über eine digitale Signatur von einer Zertifizierungseinrichtung (CA = Certificate Authority) an den Public Key gebunden ist. Die Verantwortung der CA besteht darin, die Identität eines Endpunktes durch Erstellen eines digital signierten Zertifikats zu belegen. Der Austausch von Zertifikaten, anstatt lediglich von Public Keys, ermöglicht jedem Endpunkt, jeden anderen Endpunkt zu authentifizieren und das entsprechende Vertrauensniveau bereitzustellen. Bei der gegenseitigen Authentifizierung werden die Geräte niemals versuchen, eingehende Befehle zu verarbeiten, es sei denn, sie kommen von einer gültigen Quelle. IoT-Dienste von Unternehmen sind ebenfalls geschützt, weil auch sie nur auf berechtigte Geräte reagieren.

Zertifikate werden verwendet, um die Identität eines Endpunkts zu authentifizieren. Tauschen zwei Systeme Zertifikate aus, kann Public Keys vertraut werden, wenn beide digital von der gleichen CA signiert sind. Da beide Systeme der CA vertrauen, kann dieses Vertrauen auf das entfernte System übertragen werden – vorausgesetzt, Private Keys werden nicht kompromittiert. Metadaten innerhalb des Zertifikats können auch produktspezifische Felder wie Benutzerrollen und spezielle Befehle enthalten. Sobald die Geräte authentifiziert und als vertrauenswürdig eingestuft sind, kann die Software das Zertifikat lesen, um festzustellen, welche Aktion zu ergreifen ist oder welche Systemfunktionen zur Verfügung zu stellen sind. Dadurch können Geräte für eine begrenzte Zeit in den Debug-Modus übergehen – abhängig vom Wissensstand des Technikers.

Digitale Identitäten integrieren

Mehrere Designs zur Erzeugung und Verwaltung von Zertifikaten stehen bereit, um Entwicklern von Embedded-Systemen zu helfen, digitale Identitäten in ihre Produkte zu integrieren. Die Spezifikation IEEE 802.1ar wird zunehmend für Embedded-Systeme wie Netzwerke und industrielle Steuerungen verwendet. 802.ar adressiert die Verwaltung und Verwendung eines einzelnen iDevID- und mehrerer LDevIDs-Zertifikate. Das iDevID-Zertifikat wird auch als „Geburtsurkunde“ bezeichnet, um den Hersteller des Systems, der Leiterplatte oder des Bauteils zu identifizieren. Dies ist generell das erste Zertifikat auf dem System und wird während der Herstellung erzeugt. Je nach Umgebung variiert der Zweck von LDevIDs. So kann in einem Produkt ein LDevID-Zertifikat erstellt werden, um Kundenprofile und Daten zu schützen. Beim Übergang von einem Nutzer auf einen anderen kann das LDevID-Zertifikat erneut erzeugt werden, womit alle vorherigen Kundendaten durch Löschen des Schlüssels kryptographisch gelöscht werden.

In einem anderen Beispiel kann eine Leiterplatte an mehrere Integratoren verkauft werden, wobei jeder eine verschlüsselte Trennung vom Wettbewerber wünscht. Für jeden Integrator kann dann ein LDevID-Zertifikat generiert werden, damit diese sicher in ihren eigenen lokalen Umgebungen kommunizieren und ihre Daten ohne Kompromittierungsrisiko schützen können. Entwickler von Embedded-Public-Key-Infrastruktur (PKI) -Designs können noch einen Schritt weiter gehen. Sie verwenden die iDevID (Registrierungszertifikat), um sich für einen gehosteten CA-Dienst zu authentifizieren, um während des Betriebs für Benutzerprofile, Funktionskontrolle, digitale Rechteverwaltung und In-App-Käufe zusätzliche LDevIDs (Pseudonymzertifikat) zu generieren. Entwickler können ihre Sicherheitsinvestitionen in die PKI so durch Mehrwerteinnahmen kapitalisieren.

Bei der Einbindung von Zertifikaten in ein Embedded-Design müssen Entwickler und Hersteller folgendes berücksichtigen:

  • Programmierung des Root-CA-Zertifikats in unveränderliche Speicher – dies hält Angreifer davon ab, das Zertifikat durch etwas anderes zu ersetzen.
  • Asymmetrische Schlüsselpaargenerierung – Private Keys sollten niemals außerhalb des Gerätes exponiert sein – vorausgesetzt, eine ordnungsgemäße Zufallszahlengenerierung ist möglich.
  • Schutz des Private Key – Spoofing-Angriffe sind möglich, wenn Private Keys kompromittiert werden.
  • Senden von Zertifikatsignierungsanforderungen an das CA-System – wird ein gehostetes CA-System verwendet, sollte man sich fragen, welche Auswirkungen sich auf die Produktion aufgrund eines Netzwerkausfalls ergeben?
  • Erhalt des Zertifikats und geschützte Speicherungwie sind Zertifikate und Schlüssel innerhalb des Geräts geschützt?
  • Laden der anfänglichen Sperrlisten – bezieht sich auf den gesamten Bestandsverwaltungsprozess und das Tracking berechtigter Systeme und RMAs.

Eine zunehmende Anzahl von Entwicklern schafft ihre eigenen PKIs und erzeugt Zertifikate direkt an der Fertigungslinie, wo Private Keys innerhalb jedes Geräts verbleiben können und die Produktion von Internet-Ausfällen nicht beeinflusst wird. Das Device-Lifecycle-Management (DLM-) -System von Integrity Security Services schützt die CA-Schlüssel eines Unternehmens vor IT-Netzwerken, die Datenverletzungen an entfernten und Drittanbieter-Produktionsstandorten unterliegen könnten, um eine hochverfügbare Zertifikatserzeugung sicherzustellen. DLM unterstützt Entwickler, die Zertifikate entsprechend ihrer Entwicklungs- und Versorgungskette integrieren wollen, ohne dafür ihre eigene PKI aufbauen und unterstützen zu müssen.

Keine philosophische Frage

Bild 3: Bevor ein Embedded-System sich selbst vertrauen kann, um entfernte Endpunkte zu authentifizieren, muss es überprüfen, dass die Software nicht verändert wurde. Green Hills Software

Bevor ein Embedded-System sich selbst vertrauen kann, um entfernte Endpunkte zu authentifizieren, muss es überprüfen, dass die Software nicht verändert wurde. Green Hills Software

Die wichtigste Überlegung in Sachen Authentifizierung ist, wie können wir anderen vertrauen, wenn wir uns selbst nicht vertrauen können? Leider ist das keine philosophische Frage. Wenn Systemsoftware kompromittiert wird, dann ist die Vertrauenskette von Anfang an unterbrochen, und nichts kann mehr garantiert werden. Gehackte Software kann die Verifizierung überspringen, jedes Zertifikat akzeptieren und den Nachrichteninhalt verändern. Schlüssel können kompromittiert werden, wenn sie nicht richtig geschützt sind und dazu verwendet werden, andere Geräte anzugreifen, indem sie Befehle und Daten manipulieren. Hintertüren können sich öffnen, um Daten zu sammeln und zu senden, sodass jedes Sicherheitsdesign und Authentifizierungsschema sinnlos wäre.

Bevor ein Embedded-System sich selbst vertrauen kann, um entfernte Endpunkte zu authentifizieren, muss es überprüfen, dass die Software nicht verändert wurde. Dies erfolgt durch sicheres Booten (Secure Boot), bei dem die Systemsoftware vor der Ausführung verifiziert wird. Bei jedem Einschalten überprüft der sichere Boot-Vorgang die Echtheit jeder Software-Ebene, bevor sie ausgeführt wird. Damit ist sichergestellt, dass die Software nicht korrumpiert ist und aus einer gültigen Quelle stammt. Eine Komponente wird nicht ausgeführt, sofern sie nicht als vertrauenswürdig eingestuft wird.

Hashes und Checksummen überprüfen nur die Integrität der Software – nicht deren Authentizität. Solange ein Angreifer den Hash zusammen mit dem Code modifiziert, kann schädliche Software weiter unentdeckt ausgeführt werden. Authentifizierung ergibt sich durch digitale Signierung des Hash mit einem asymmetrischen Schlüssel. Die Sicherheitsinfrastruktur eines Unternehmens schützt den Private Key und unterzeichnet die Freigabesoftware digital. Der entsprechende Public Key wird während der Fertigung in das Gerät programmiert und bei der Verifizierung verwendet. Ändert ein Angreifer nun sowohl den Code als auch den Hash, kann die digitale Signatur immer noch nicht aktualisiert werden, ohne dass der entsprechende Private Key die digitale Signatur wiederherstellt. Integrity Security Services arbeitet mit Unternehmen in allen Bereichen zusammen, um sichere Boot-Lösungen einschließlich Digital-Signing-Infrastrukturen bereitzustellen – mit einem Schutz, der keinerlei Exposition von Private Keys garantiert und einer Integration in die täglichen Software-Build-Prozesse.

Gregory Rudy

Green Hills Software

(ah)

Kostenlose Registrierung

*) Pflichtfeld

Sie sind bereits registriert?