Hallo liebe Internet der Dinge Liebhaber. Fortsetzung Hinweise IoT-Anbieter.
Der erste Teil > || >
Zweiter Teil > || >
Dritter Teil > || >
Der vierte TeilHeute ist es Zeit, bei LoRaWAN über Sicherheit zu sprechen. Es gibt viele Gerüchte und Legenden. Wir werden versuchen herauszufinden, wie es funktioniert und welche Risiken bestehen.
Um zum Thema Sicherheit überzugehen, müssen Sie eine kleine Einführung machen und über die anfängliche Initialisierung des Funkmoduls im Netzwerk sprechen. Dieser Vorgang in LoRaWAN wird als Aktivierung bezeichnet.
Der Kürze halber werde ich nachfolgend die Begriffe auflisten, die wir benötigen. Wenn Sie etwas verwirrt sind, können Sie hierher zurückkehren und nachsehen. Sie müssen wahrscheinlich zurückkommen, weil Abkürzungen vieler Begriffe sind sehr ähnlich. Außerdem werde ich in dieser Beschreibung Analogien geben, damit Sie ungefähr verstehen, womit dieser oder jener Begriff verglichen werden kann. Es ist nicht immer möglich, genaue Analogien auszuwählen. Bitte beurteilen Sie diese Spalte nicht zu streng.
Die Aktivierung in LoRaWAN kann also über Luft (OTAA) oder über eine Voreinstellung (ABP) erfolgen.
OTAA (Over-the-Air-Aktivierung)
Bei Aktivierung durch Luft müssen drei Parameter an unserem Funkmodul eingestellt werden. Seine eindeutige Kennung (DevEUI), Serverkennung (AppEUI) und Serverschlüssel (AppKey).
Auf der Serverseite müssen auch die Funkmodul-ID, die Server-ID und der Schlüssel registriert werden. Das heißt, Der Server sollte zunächst das Gerät kennen, das versucht, sich ihm anzuschließen. Wenn wir die Kennungen und Serverschlüssel kennen, unser DevEUI jedoch nicht in seiner Datenbank registriert ist, schlägt die Verbindung fehl.
Beim ersten Einschalten sendet das Funkgerät das Paket join_request in der Luft mit einer der drei vordefinierten Verbindungsfrequenzen. Mit diesem Paket fragt er, ob es in der Nähe ein Netzwerk gibt, das ihn „erkennt“. Das Folgende ist die Zusammensetzung des join_request-Pakets. Wie Sie sehen können, enthält es genau DevEUI und AppEUI sowie DevNonce.
DevNonce ist eine Zufallsvariable. Der Server speichert es für einige Zeit im Speicher. Wenn join_request mit derselben DevNonce wie eine der vorherigen eingeht, ignoriert der Server diese Anforderung. Dies dient zum Schutz vor einem wiederholten Angriff, wenn ein Angreifer eine Aktivierungsanforderung aufschreiben und dann von seinem Gerät aus wiederholen kann. Übrigens können nicht alle IoT-Standards Schutz vor diesem Angriff bieten.
AppKey wird in dieser Nachricht nicht direkt verwendet, aber dadurch wird die MIC-Prüfsumme am Ende des Frames berücksichtigt.
Wir werden diesen Schlüssel in der Antwortnachricht vom join_accept-Server etwas weiter benötigen.
Join_request wird unverschlüsselt übertragen.
Join_accept wird empfangen, wenn der Server AppEUI und DevEUI kennt, keine Übereinstimmung im Feld DevNonce vorliegt und keine Probleme mit dem MIC vorliegen. Andernfalls erfolgt keine Antwort. Wenn alle Prüfungen bestanden wurden, generiert der Server eine join_accept-Antwortnachricht. Die Zusammensetzung ist im Bild unten dargestellt.
Tatsächlich werden zwei Sitzungsschlüssel generiert - der Netzwerkserver (NwkSKey) und der Anwendungsserver (AppSKey). Diese Schlüssel werden zusammen mit anderen Informationen von AppKey verschlüsselt und an das Funkmodul gesendet. Darüber hinaus erfolgt das gesamte Messaging mit doppelter Verschlüsselung mit Sitzungsschlüsseln (mit Ausnahme von Paketen mit MAC-Befehlen werden diese nicht mit dem Anwendungsserverschlüssel verschlüsselt). NwkSKey nimmt nicht nur mit Daten (ohne Befehle) an der Paketverschlüsselung teil, sondern es wird eine Prüfsumme berücksichtigt.
NwkSkey und AppSKey sind für jedes einzelne Funkmodul einzigartig.
Für zusätzlichen Informationsschutz werden zwei Schlüssel verwendet. Jedes Mal, wenn ein Paket vom Funkmodul in unserem System ankommt, wird es teilweise für den Netzwerkserver und teilweise für den Anwendungsserver verschlüsselt. Das heißt, Der Netzwerkserver kann nur die an ihn adressierten Nachrichten entschlüsseln (verschiedene Dienstnachrichten). Der Anwendungsserver sieht nur die nützliche Komponente der Pakete (tatsächlich die weitergeleiteten Daten). Dies ist notwendig, da der Netzwerkserver mit einer Wahrscheinlichkeit von 99 Prozent beim Anbieter ist. Der Anwendungsserver kann jedoch durchaus vom Client gehostet werden. Die doppelte Verschlüsselung erschwert es dem Anbieter, den Inhalt des Pakets herauszufinden.
Zusätzlich zu den beiden Schlüsseln gibt es noch eine weitere wichtige Funktion von join_accept in OTAA - die erweiterte Frequenzliste (CFList). Ich möchte Sie daran erinnern, dass ein Funkmodul zunächst nur drei Frequenzen kennt, bei denen es arbeiten kann. Nach der Aktivierung werden zusätzliche Frequenzen für die Kommunikation registriert.
Dies ist sehr praktisch, wenn nicht genau bekannt ist, in welchem Netzwerk das Gerät funktioniert. Wir können uns darauf einigen, dass in allen Netzen immer 3 Frequenzen (+ RX2) zusammenfallen und die restlichen fünf im Ermessen des Anbieters liegen.
Für die Zukunft kann CFList auch für das Clustering verwendet werden, um mit einer großen Anzahl von Geräten zu arbeiten
Dies ist der Fall, wenn Sie das Netzwerk in Cluster aufteilen und innerhalb der Cluster eine Frequenzplanung durchgeführt wird. Angenommen, unser Funkmodul kennt die drei Frequenzen F1, F2 und F3. Es wird bei einer der Frequenzen aktiviert und wenn es sich in Cluster1 befindet, erhält es eine zusätzliche Frequenztabelle in Form von F4-1, F5-1 und F6-1. Für Cluster 2 erhält er völlig andere F4-2, F5-2, F6-2. Gleichzeitig können wir alle Funkmodule auf die gleiche Weise konfigurieren und denken nicht wirklich, welches in welchen Cluster fallen wird. In benachbarten Clustern nimmt die Wahrscheinlichkeit von Kollisionen stark ab.
ABP (Aktivierung durch Personalisierung)
Ein vereinfachtes Verfahren, bei dem Sitzungsschlüssel sofort mit dem Funkmodul verbunden und zunächst auf der Serverseite registriert werden. Das Funkmodul ist praktisch einsatzbereit und sofort einsatzbereit. Nichts bequemeres, weil Sicherheit ist in diesem Fall so lala. Außerdem können Sie keine Frequenzen vom Server abrufen. Ich habe noch nie Fälle von wirklichem Gebrauch gesehen. Wir werden es nicht berücksichtigen, und in allen folgenden Abschnitten geht es um OTAA.
Und was ist mit Sicherheit?
Im Wesentlichen haben wir also die Hauptverschlüsselungslast für die Sitzungsschlüssel des Netzwerkservers und des Anwendungsservers.
Betrachten Sie sie etwas genauer.
Die Hauptbeschwerde von Kritikern des LoRaWAN-Standards ist, dass wir bei Aktivierung des Geräts im Netzwerk zwei Schlüssel haben, die dann monatelang unverändert bleiben können. Genauer gesagt können sie sich jahrelang nicht ändern, bis das Gerät wieder aktiviert wird. Unter normalen Bedingungen haben wir das Funkmodul aktiviert und vergessen, daher ist eine Schlüssellebensdauer von drei bis vier Jahren eine sehr realistische Perspektive. Eigentlich von der Installation bis zum Nulllassen der Batterie.
Wie zuverlässig sind unsere Schlüssel?
Die Spezifikation besagt, dass sie dem mysteriösen RFC4493 entsprechen.
Was ist das? Dies ist ein Verschlüsselungsalgorithmus, besser bekannt als AES-CMAC.
Lassen Sie uns nicht in die Wildnis der Kryptographie kriechen und uns auf ein gemeinsames Verständnis des Bildes beschränken. Es ist in der folgenden Abbildung dargestellt.
Das Prinzip von AES-CMAC ist ungefähr das folgende: Die verschlüsselte Nachricht ist in 128-Bit-Blöcke unterteilt. Jeder Block wird separat mit einem AES-Schlüssel verschlüsselt. Darüber hinaus wird beim Verschlüsseln des zweiten Blocks zusätzlich zum Schlüssel das Verschlüsselungsergebnis des ersten verwendet. Und beim Verschlüsseln des dritten - das Ergebnis des zweiten und (indirekt) des ersten. Eine solche Kette von Komplikationen.
Wie zuverlässig ist dieses Prinzip?
Sehr zuverlässig. Der Algorithmus kam vor mehr als zehn Jahren heraus. Seitdem wurde er von vielen verschiedenen Angriffen angegriffen, und schließlich haben sie theoretisch bewiesen, dass er gehackt werden kann. Das Problem ist, dass eine große Stichprobe von Paketen, mehrere Tausend, benötigt wird, um ihn zu zerbrechen. Dann besteht die Möglichkeit zu verstehen, was sich in den verschlüsselten Blöcken befindet.
Kann ein Angreifer mit den erforderlichen Kenntnissen dieses Beispiel erhalten, wenn es um das Abfangen von LoRaWAN-Paketen geht? Lassen Sie uns schätzen. Lassen Sie die Pakete einmal pro Stunde gehen. In einem Monat werden 720 Pakete vom Funkmodul gesendet. Nicht genug.
Für eine echte Bedrohung brauchen wir einen sehr geduldigen Patienten, der monatelang Pakete schreibt. Und es ist keine Tatsache, dass er den Algorithmus immer noch knacken und die wertvollen Schlüssel erhalten kann. Vergessen Sie nicht, dass diese Geduld in Bezug auf jedes Funkmodul separat gezeigt werden muss. Und denken Sie daran, dass das Versenden von Paketen einmal pro Stunde SEHR häufig ist. In der Praxis sind die Intervalle viel länger - sechs Stunden oder sogar ein Tag.
Aber auch diese gespenstische Gelegenheit ist jetzt nach der Veröffentlichung von Spezifikation 1.1 geschlossen, in der die Befehle zur erneuten Aktivierung und zum Beitritt zum Server implementiert sind. Lassen Sie uns irgendwie über diese Spezifikation sprechen. Im Moment erinnere ich mich an meinen Gedanken aus dem vorherigen Artikel: Wenn der Standard offen ist und eine Community hat, sind alle seine Löcher sichtbar. Während des Upgrades wissen die Entwickler genau, worauf sie zuerst achten müssen.
Infolgedessen stellen wir fest, dass die Sicherheitsbedrohung eher illusorisch ist. Irgendwo in der tiefen Theorie kann gehackt werden, aber in der Praxis ist es praktisch nicht realistisch. Multiplizieren Sie nun mit dem Wert der empfangenen Informationen. Wird unser Angreifer monatelang Pakete schreiben, um den Zähler herauszufinden? Unwahrscheinlich.
LoRaWAN erfüllt dieses angemessene Preis-Leistungsverhältnis. Wir verstehen, dass der Schutz verbessert werden kann. Dies ist jedoch die Rechenleistung des Endes. Dies ist eine zusätzliche Belastung der Batterie. Es ist möglich, die Größe der Pakete zu erhöhen oder die Nutzlast zu verringern.
Für mich ist es mehr als eine Telemetrieaufgabe.
In den Kommentaren werde ich mich freuen, sowohl meine Gegner als auch meine Unterstützer zu hören. Denken Sie daran, dass das Thema Sicherheit immer eine Diskussion erfordert und sich niemals auf die Meinung einer Person stützen sollte.