Die Verschlüsselung von IoT-Systemen ist sehr schwach

Am 17.08.2021, von Lucien Constantin IDG NS (Adaption von Jean Eliane), Security, Songtext 1966

Es ist nicht die Schuld der IoT-Anbieter, aber das Fehlen eines sicheren kryptografischen Subsystems des Pseudozufallszahlengenerators macht IoT-Geräte anfällig.

Die Vertraulichkeits- und Integritätsgarantien moderner Kommunikationsprotokolle beruhen auf Algorithmen, die geheime Codes generieren, die Angreifer nicht erraten können. Diese Algorithmen werden für Authentifizierung, Verschlüsselung, Zugriffskontrolle und viele andere Aspekte moderner Sicherheit verwendet. Sie alle benötigen kryptographisch sichere Zufallszahlen, also eine Zahlen- oder Symbolfolge, die so gewählt ist, dass sie einen Angreifer unberechenbar macht. Alle kryptografischen Algorithmen, die eine Art sichere Generierung von Schlüsseln oder Token beinhalten, müssen mit Zufallszahlen gesät werden. Der Prozess, durch den diese Zahlen ausgewählt werden, bekannt als Zufallszahlengeneratoren (RNG), ist die Grundlage vieler Sicherheitssysteme und -funktionen. Während moderne Betriebssysteme und Computer seit langem über sichere RNGs verfügen, haben IoT-Geräte, insbesondere Geräte mit begrenzten Ressourcen, die nicht über viele Schnittstellen verfügen, auf denen einfachere Betriebssysteme ausgeführt werden, lange Zeit Schwierigkeiten, Quellen mit hoher Zufälligkeit, auch bekannt als Entropie, zu finden.

In den letzten Jahren haben Anbieter von System-on-a-Chip (SoC) versucht, dieses Problem zu lösen, indem sie ihre Produkte mit peripheren Controllern integriert haben, die darauf ausgelegt sind, Zufallszahlen zu erzeugen, die das Betriebssystem sicher verwenden kann. Ein Forscherteam der Sicherheitsfirma Bishop Fox, das untersuchte, wie Entwickler des Internets der Dinge Hardware-Zufallszahlengeneratoren verwenden, fand jedoch erhebliche Implementierungsprobleme, die die Sicherheit ihrer Systeme gefährden. Sie präsentierten kürzlich ihre Ergebnisse auf der DEF CON-Sicherheitskonferenz, die vom 11. bis 14. August in Las Vegas stattfand. Die Forscher kamen zu dem Schluss, dass die Verwendung des Geräts entscheidend ist und der aktuelle technische Stand des Internets der Dinge nicht als unzureichend bezeichnet werden kann.

RNG-Hardware- oder Software-RNG

Software-Zufallszahlengeneratoren werden auch als Pseudozufallszahlengeneratoren oder Pseudozufallszahlengeneratoren (PRNGs) bezeichnet, da sie deterministische Softwarealgorithmen verwenden und mit Zufallswerten gesät werden müssen, normalerweise aus einem Entropiepool, der Zufallswerte aus verschiedenen Quellen kombiniert: Netzwerkinformationen , Luftschnittstellen, unterschiedliche Zeitwerte usw. aber das ist noch nicht alles. Im Allgemeinen werden generische PRNGs für unsichere Zwecke verwendet, und kryptografisch sichere PRNGs oder kryptografisch Pseudozufallszahlengeneratoren (CSPRNGs) sollen Sicherheitsgarantien gegen Angriffe bieten, die versuchen, den Seed zu erraten oder seinen Ausgang innerhalb einer angemessenen und berechneten Zeit zu antizipieren. CSPRNGs verwenden Chiffren und Hash-Funktionen, um Ergebnisse zu erzeugen, die dann für kritische Operationen wie die Schlüsselgenerierung verwendet werden. Sie führen auch Tests durch, um bekannte Angriffe zu verhindern. Alle diese Prozesse verbrauchen Rechenressourcen und Arbeitsspeicher, die auf IoT-Geräten sehr begrenzte Ressourcen sind, weshalb SoC-Anbieter Hardware-RNG-Funktionen hinzugefügt haben. Hardware-Zufallszahlengeneratoren werden auch als True RNG (TRNG) bezeichnet, da sie wie bei Softwarealgorithmen auf unvorhersehbare Weise Zufallszahlen aus physikalischen Prozessen generieren. Die Ergebnisse von TRNGs sollen sicher für die direkte Verwendung sein, aber wie Forscher von Bishop Fox herausgefunden haben, können die Schnittstellen zu diesen Systemen entmutigend sein und Fehler können schwerwiegende Folgen für die beteiligten Sicherheitssysteme haben.

Keine Fehlerprüfung Hardware RNG

SoC-Anbieter ermöglichen Entwicklern die Interaktion mit ihrem Hardware-RNG über die HAL-API (Hardware Abstraction Layer), indem sie verschiedene Funktionen in C-Code aufrufen. Ein RNG kann sehr unterschiedlich sein. Die Namen dieser RNG-Funktionen können von Anbieter zu Anbieter variieren, aber ihr Ergebnis ist ein Zeiger auf die Zufallszahl (32-Bit-Integer) und vor allem ein Rückgabewert, der auf mögliche Fehler hinweist. Die Forscher erklärten in einem Bericht, dass die HAL-Funktion eines RNG-Geräts aus mehreren Gründen versagen kann, aber der häufigste (und ausnutzbarste) Grund ist, dass das Gerät eine geringe Entropie hat. Geräte-RNGs extrahieren Entropie aus dem Universum durch verschiedene Mittel (z. B. analoge Sensoren oder EMF-Messwerte von elektrischen und magnetischen Feldern), aber sie haben keinen unbegrenzten Vorrat davon. Sie können nur eine bestimmte Anzahl zufälliger Bits pro Sekunde erzeugen. Wenn man also versucht, die HAL RNG-Funktion aufzurufen, wenn sie keine Zufallszahlen hat, schlägt sie fehl und gibt den Fehlercode zurück. Und wenn das Gerät versucht, zu schnell zu viele Zufallszahlen zu erhalten, werden die Anrufe Fehler zurückgeben.

Dies kann häufig passieren, wenn große Schlüssel generiert werden. Wenn zum Beispiel ein privater 2048-Bit-Schlüssel generiert wird, ruft das Gerät wiederholt die RNG-HAL-Funktion in einer Schleife auf, und das Gerät kann aufgrund seiner Einschränkungen oft nicht mithalten und beginnt, Fehler zu werfen. Das Problem ist, dass Entwickler basierend auf dem Code in GitHub für die Interaktion mit SoCs und sogar dem Code für die Handhabung von RNGs in beliebten eingebetteten Betriebssystemen wie FreeRTOS nicht nach Hardware-RNG-Fehlern zu suchen scheinen. So funktioniert die Industrie des Internets der Dinge, sagten Forscher von Bishop Fox. Diese Praxis findet sich in fast allen Softwareentwicklungskits und IoT-Betriebssystemen. Dies ist ein großes Problem, denn je nach Gerät kann die Ausgabe bei einem Ausfall der HAL RNG-Funktion teilweise Entropie, 0 oder nicht initialisierter Speicher sein. Keine dieser Ausgaben gilt als sicher für die Verwendung bei der Verschlüsselung.

Im Jahr 2019 entdeckten Keyfactor-Forscher bei der Analyse von 75 Millionen digitalen Zertifikaten auf der Grundlage von RSA-Schlüsseln, dass eines von 172 Zertifikaten anfällig für Angriffe war, die es ermöglichen würden, ihre geheimen Schlüssel abzurufen. Die Schwachstelle hing mit der unsachgemäßen Generierung von Zufallszahlen zusammen, und die meisten anfälligen Zertifikate befanden sich in IoT-Geräten und eingebetteten Netzwerkgeräten wie Routern, Switches und Firewalls. Wenn die zum Generieren von öffentlichen RSA-Schlüsseln verwendeten Primzahlen nicht zufällig genug sind, ist es möglich, dass zwei unterschiedliche Schlüssel einen gemeinsamen Faktor haben. Daher wird es sehr einfach, ihre anderen Faktoren zu erholen und zu überwinden. Obwohl wir nicht mit Sicherheit sagen können, ob unsere Forschung diese Ergebnisse erklärt, sind die allgemeinen Zustände anfälliger RSA-Switches in IoT-Geräten genau das, was man erwarten würde, sagten Forscher von Bishop Fox. Ihre Schlussfolgerungen zur Verwaltung von Hardware-RNGs auf IoT-Geräten. Sie fügten hinzu, dass diese Schwäche anscheinend in großem Umfang in der Praxis und nicht nur in der Theorie ausgenutzt werden könne.

Erzwungene schlechte Hinrichtungen

Die Forscher sind sich einig, dass man IoT-Softwareentwicklern nicht vorschnell die Schuld für eine schlechte Implementierung geben sollte, da ein angemessener Umgang mit diesen Fehlern andere Nachteile hat, die den Betrieb eines IoT-Geräts beeinträchtigen können. Wenn der Netzwerk-Stack dabei ist, einen Verschlüsselungsschlüssel zu generieren, um Verbindungen zu sichern, gibt es eigentlich nur zwei Möglichkeiten, Fehler zu behandeln: entweder aufgeben, den gesamten Prozess stoppen oder die HAL-Funktion auf unbestimmte Zeit wiederholen, bis der Anruf beendet ist , blockiert alle anderen Prozesse und verwendet 100 % der CPU in diesem Prozess. Keine dieser beiden Lösungen ist akzeptabel. Deshalb ignorieren Entwickler den Fehlerstatus. Die Alternativen sind überhaupt nicht zufriedenstellend und werden durch das Ökosystem um RNG-Geräte nicht unterstützt. Darüber hinaus gibt es nicht wenige Geräte, die mit einer angemessenen Dokumentation geliefert werden, die erklärt, wie der Zufallszahlengenerator funktionieren soll und wie Fehler behandelt oder vermieden werden können, und sie haben wenig Informationen über die erwartete Betriebsgeschwindigkeit, sichere Betriebstemperaturbereiche oder statistische Beweise dafür Zufällig. Selbst bei vorhandener Dokumentation sind die Erklärungen nicht immer so einfach und klar.

RNG-Zuverlässigkeit der Hardware allein unzureichend

Die Forscher von Bishop Fox fanden mehrere andere Probleme bei dem Versuch, sich ausschließlich auf Hardware-RNG als Quelle der Entropie im IoT zu verlassen. In Ermangelung eines echten CSPRNG verwenden beispielsweise viele SDK- und IoT-Betriebssysteme, die Hardware-RNGs unterstützen, diese, um unsichere PRNGs wie zLybrand (), und seine Ausgabe wird für Sicherheitszwecke verwendet, wenn dies nicht der Fall ist. wie PRNGsLybrand ()Äußerst unsicher, weil die Zahlen, die sie produzieren, Informationen über den internen Zustand des RNG enthüllen, sagten die Forscher. Es ist ideal in nicht sicherheitsrelevanten Kontexten, da es schnell und einfach zu implementieren ist. Und sie fügten hinzu, dass die Verwendung zum Generieren von Verschlüsselungsschlüsseln die Sicherheit des Geräts erheblich untergräbt, da alle Zahlen vorhersehbar sind.

Beim Testen des Mikrocontrollers LPC54628 bemerkten die Forscher, dass die von den RNG-Geräten erzeugten Zufallszahlen von schlechter Qualität waren, und vermuteten, dass etwas mit ihrem Code nicht stimmte. Wenn sie tiefer in die Dokumentation des Herstellers eintauchen, finden sie eine Empfehlung gegen die 32-Bit-Zahlenfolge, die RNG produziert, um größere Zahlen zu bilden. Um beispielsweise eine 128-Bit-Zufallszahl zu erhalten, müssen Entwickler nicht vier aufeinanderfolgende 32-Bit-Ausgänge von einem RNG binden, sagt der Hersteller. Stattdessen sollten sie eine 32-Bit-Zahl verwenden, die nächste 32 ablehnen, dann die nächste verwenden, eine weitere 32 ablehnen und so weiter. Dieses API-Verhalten ist so seltsam und kontraintuitiv, dass es fast garantiert zu schwachen Anwendungen führt. Selbst wenn die Entwickler den richtigen Code finden, um 32 Ziffern abzulehnen, können sie den Forschern zufolge entfernen, weil sie ihn für unnötig halten.

Darüber hinaus scheiterten einige der von den Forschern getesteten Hardware-RNG-Implementierungen an statistischen Analysetests oder zeigten klare Muster in der relativen Verteilung der von ihnen erzeugten Bytes. Selbst wenn Entwickler also alle Fehler, API-Macken und schlechte Dokumentation umgehen können, sollten sie sich nicht nur auf die Ausgabe von Hardware-RNGs verlassen. Die Lösung besteht darin, sichere PRNGs zu haben, die verschlüsselt und für IoT geeignet sind, wobei die Ausgabe der Hardware-RNGs nur eine Quelle für den Entropiepool ist. Alle wichtigen Betriebssysteme wie Linux, Windows, macOS, Android, iOS und BSD verfügen über fehlerresistente CSPRNG-Subsysteme, die Anwendungsentwickler problemlos verwenden können, ohne direkt mit Hardware und Software zu interagieren.Machen Sie sich Sorgen, dass ihr Code falsch ist oder Zufallszahlen nicht sicher. Im aktuellen Fall, so die Forscher, liege die Hauptschwachstelle nicht im SDK eines einzelnen Geräts oder der Implementierung eines bestimmten SoC. Das Internet der Dinge benötigt ein CSPRNG-Subsystem. Dieses Problem kann nicht gelöst werden, indem einfach die Dokumentation geändert und die Benutzer beschuldigt werden. Der geeignetste Ort, um ein solches CSPRNG-Subsystem unterzubringen, ist eines der immer beliebter werdenden IoT-Betriebssysteme. Die Forscher rieten, wenn Sie ein neues Gerät von Grund auf neu entwerfen, empfehlen wir, CSPRNG in das Betriebssystem zu implementieren.

Leave a Comment