In Teil 2 der IoT-Artikelreihe haben wir das Szenario eines Wireless Sensor Networks (WSN) im Regenwald vorgestellt, zusammen mit den verschiedensten technischen Herausforderungen, die damit einhergehen. Ungeklärt war bislang die Frage, wie sich ein solches Sensor-Netzwerk effizient und wirkungsvoll gegen Angreifer absichern lässt. Im Teil 3 haben wir einen allgemeinen Blick auf das Thema Sicherheit im IoT geworfen. Nun wollen wir der Frage nachgehen, wie man es schaffen kann, das groß angelegte, in unwegsamem Gelände verteilte Sensornetz im Regenwald ohne die Nutzung externer Infrastruktur effektiv gegen Angreifer, abzusichern. Und das erfordert einen gewissenhaft und ganzheitlich durchdachten Ansatz.
Möchte man in der Industrie ein großes IoT-Netzwerk in einem Unternehmen in Betrieb nehmen, stützt sich dieses in der Regel stark auf vorhandene Infrastruktur. Werden die Geräte drahtlos vernetzt nutzt man die vorhandene, gegebenenfalls ausgebaute und optimierte WLAN-Infrastruktur, bei einem Kabelanschluss muss lediglich das Kabel zum nächsten passenden Switch geplant werden. Gerade ein bestehendes Identity and Access Management (IAM) etwa auf Basis einer Public Key Infrastruktur (PKI) vereinfacht die Inbetriebnahme eines IoT-Netzwerkes massiv, da die Geräte einen gemeinsamen Vertrauensanker besitzen und somit eine Stelle kennen, die ihnen die sichere Kommunikation untereinander ermöglicht.
Im Regenwald-Szenario existiert diese Infrastruktur schlicht nicht. Es gibt keine vorhandenen Zugangspunkte, geschweige denn ein bestehendes IAM. Während sich die fehlende Vernetzung durch geeignete Übertragungsarten ersetzen lässt (siehe Teil 3), stellt der fehlende gemeinsame Vertrauensanker der Geräte ein ernstzunehmendes Problem dar: Ohne ihn ist zunächst keine sichere Kommunikation im Netzwerk möglich, da sich die Geräte nicht zuverlässig auf dem gewohnten Weg gegenseitig identifizieren können.
Natürlich stellt sich die Frage, warum mit den IoT-Sensorknoten nicht auch ein geeignetes Gerät für diese Aufgabe mit ausgebracht wird, dem die anderen Teilnehmer initial vertrauen. Der Grund hierfür ist, dass dieses Gerät für alle Teilnehmer jederzeit erreichbar sein müsste. Diese Eigenschaft ist im Regenwald-Szenario schlicht nicht möglich. In den vorhergehenden Teilen haben wir uns bereits damit beschäftigt, dass aus Gründen der Ressourcensparsamkeit Nachrichten gezielt aggregiert werden und primär eine Kommunikation mit direkten Nachbarn stattfindet. Müssten nun die Nachrichten zu einem zentralen Punkt weitergeleitet werden, würde das über der gesamten Kette beteiligter Geräte zu einem erhöhten Strombedarf führen. Abgesehen davon kann nicht garantiert werden, an welcher Stelle das IAM-Gerät landen würde und ob es überhaupt erreichbar und einsatzbereit wäre. Es würde ein Flaschenhals geschaffen werden, welcher der Idee vom autonomen Netzwerkbetrieb diametral entgegensteht.
Folglich müssen alternative Wege gefunden werden, Vertrauen zwischen gelandeten Geräten zu schaffen. Das Problem lässt sich zunächst darauf reduzieren, dass kryptographische Schlüssel zwischen den Geräten ausgetauscht sein müssen, um die Schutzziele Vertraulichkeit (durch Verschlüsselung) und Authentizität (durch Message Authentication Codes oder Digitale Signaturen) zu gewährleisten. Das Schutzziel der Authentizität stellt sicher, dass die Geräte sich gegenseitig korrekt identifizieren und wissen, mit wem sie kommunizieren.
Da asymmetrische kryptographische Verfahren deutlich höhere Ressourcen benötigen als symmetrische Verfahren, werden letztere für den Anwendungsfall bevorzugt. In einem naiven Ansatz könnte man nun versuchen, auf jedem Gerät schon vor der Verteilung des Sensor-Netzwerkes jeweils paarweise symmetrische Schlüssel zu allen weiteren Geräten des Netzwerkes vorzuinitialisieren. Die Zahl der Schlüsselpaare steigt jedoch so stark, dass bereits für 10.000 Geräte im Netzwerk knapp 50 Millionen paarweise Kombinationen existieren, die jeweils einen eigenen, vorinitialisierten Schlüssel benötigen würden. Diese Herausforderung ist als Schlüsseltausch-Problem bekannt und es ist unausweichlich, dass bei diesem Vorgehen der Gerätespeicher von minimalistisch ausgestatteten IoT-Geräten schnell an seine Grenzen stoßen würde.
Abhilfe kann durch die Nutzung verschiedener Schlüsseltypen geschafft werden. Diese unterscheiden sich jeweils dadurch, mit welchen weiteren Geräten sie geteilt werden, um die Anzahl der insgesamt benötigten Schlüssel zu reduzieren. Node Keys werden jeweils zwischen einem Sensorknoten und der Basisstation geteilt, an welcher die Daten schließlich verarbeitet werden sollen und welche ausreichenden Ressourcen zur Speicherung aller Schlüssel der im Netzwerk eingesetzten Geräte besitzt. Unter der Verwendung von Node Keys kann daher kein in-network processing stattfinden, da die Ende-zu-Ende verschlüsselten Daten nicht von weiterleitenden Geräten eingesehen und aggregiert werden können. Um einen effizienteren Datentransport zu gewährleisten werden daher weitere Schlüsseltypen benötigt.
Der Network Key zeichnet sich dadurch aus, dass ihn alle Geräte kennen. Er könnte beispielsweise dazu benutzt werden, netzwerkweite Broadcast-Nachrichten zu versenden die von allen Geräten empfangen werden sollen. Ein solcher gemeinsamer Schlüssel wird bereits bei der Herstellung und Initialisierung der Geräte hinterlegt. Theoretisch wäre es mit diesem Schlüssel auch möglich, Messdaten weiterzuleiten und gleichzeitig zu verarbeiten. Jedoch birgt dieses Vorgehen auch Risiken: Wird der Schlüssel in einem beliebigen Gerät von einem Angreifer ausgelesen, kann er die gesamte Kommunikation, die auf dem Network Key basiert, mitlesen. Auch das nachträgliche Austauschen oder Erneuern dieses kompromittierten Schlüssels ist nicht ohne weiteres möglich.
Aus diesem Grund werden überdies Schlüssel genutzt, die lokal begrenzt eingesetzt werden und die Übertragung zu nahegelegenen Geräten absichern können. Link Keys werden jeweils zwischen zwei benachbarten IoT-Geräten geteilt. Cluster Keys hingegen werden zwischen einem Gerät und all seinen Nachbarn geteilt, die sich in Reichweite der Funkübertragung befinden.
Diese Aufteilung verschiedener Schlüsseltypen kann dabei helfen, die Sicherheit im Betrieb des Gesamtnetzwerks zu steigern. Aber auch der initiale Schlüsselaustausch profitiert von unterschiedlichen Schlüsseltypen. Im Folgenden schauen wir uns mehrere Szenarien genauer an und analysieren, wie sich das Netzwerk vor einem Angreifer schützen oder gegen sein Einwirken verteidigen kann.
Zurück in der anfänglichen Situation wurden die Geräte gerade aus dem Flugzeug abgeworfen, und müssen nun die Herausforderung meistern, sich an unbekannten Orten mit unbekannten Nachbargeräten zu orientieren und mittels Authentifizierung und Verschlüsselung eine sichere Kommunikation einzurichten. Dazu gehen wir davon aus, dass alle gelandeten Geräte mit Node Key und Network Key ausgestattet sind. Es wäre ihnen also problemlos möglich, Ende-zu-Ende verschlüsselt mit der Basisstation zu kommunizieren, oder Broadcast-Nachrichten in das Netzwerk zu verschicken. Für die verschlüsselte Kommunikation in Clustern oder zu individuellen Nachbargeräten besteht die Schwierigkeit nun darin, Cluster Keys und Link Keys nach der Landung zu etablieren. Hierzu existieren verschiedene Vorgehensweisen, wir haben uns in diesem Fall für die Nutzung von Kurzzeit-Masterschlüsseln entschieden.
Die Idee hinter diesem Begriff ist, dass neben Node und Network Key noch ein dritter Kurzzeit-Masterschlüssel vorinitialisiert wird. Dieser Schlüssel wird ausschließlich in der ersten Phase des Netzwerk-Betriebs genutzt, in der sich die Geräte gegenseitig kennenlernen und weiteres Schlüsselmaterial austauschen. Dieser Prozess funktioniert folgendermaßen:
Sicherheitsbetrachtung: Die Sicherheit dieses Verfahrens basiert auf der Annahme, dass die gerade gelandeten Geräte sind alle in einem vertrauenswürdigen Zustand befinden und die benötigten Schlüssel in einer sicheren Umgebung vorinitialisiert wurden. Diese Annahme ist plausibel, da dem Hersteller von Geräten gewöhnlich als vertrauenswürdig angenommen wird. Außerdem wird angenommen, dass ein Angreifer, der sich potenziell in örtlicher Nähe der Geräte befindet, mindestens die Zeitspanne des initialen Timers benötigt, um ein oder mehrere Geräte zu infizieren und in den Besitz der Schlüssel zu gelangen. Wird der Timer in der Größenordnung weniger Sekunden oder Minuten gewählt, ist auch diese Annahme belastbar. Dem Angreifer bietet sich in diesem Fall keine Möglichkeit die Initialisierungsphase zu infiltrieren, da er keine Kenntnis des Kurzzeit-Masterschlüssels hat. Gelingt es ihm nach dem Ablauf des Timers Geräte zu befallen, wurde der Masterschlüssel bereits gelöscht und es können nachträglich keine Link-Keys berechnet werden. Es ist somit gelungen, einen sicheren Schlüsselaustausch mit den Nachbargeräten zu etablieren.
Sobald Link-Keys mit allen Nachbargeräten aufgesetzt wurden, lässt sich auch der Cluster-Key einrichten. Hierzu generiert das betrachtete Gerät einen neuen Schlüssel und sendet ihn, verschlüsselt mit den jeweiligen Link-Keys an all seine Nachbarn. Diese speichern den Cluster-Key für zukünftige Datenübertragungen ab.
Nach der Initialisierungsphase geht das Netzwerk in den Regelbetrieb über und es werden durch die Sensorknoten Messdaten erfasst. Diese sollen nun in regelmäßigen Zeitintervallen zur Auswertung und weiteren Verarbeitung an eine Base-Station gesendet werden. Hierbei ist es wichtig, dass die Datenübertragung über die ganze Kette vom Sensor bis zur Base-Station integritätsgesichert, authentifiziert und verschlüsselt stattfindet, damit Angreifer Sensordaten weder verändern, einschleusen oder mitlesen können. Hierzu greifen wir auf die eingerichteten Schlüsseltypen zurück. Die Auswahl des passenden Schlüssels, der genutzt werden soll, geschieht auf Basis des Anwendungsfalles.
Trotz der bisherigen Sicherheitsmaßnahmen ist es möglich, dass ein Gerät im laufenden Betrieb von Angreifern infiziert wird und hierbei Schlüssel entwendet werden. Bei Cluster-, Link- und Node-Keys hat das jedoch nur lokale Effekte, da die Übertragungen der anderen, nicht infizierten Geräte größtenteils unverändert weiter stattfinden können. Anders sieht das beim Network-Key aus, der zwischen allen Geräten geteilt wird. Hier reicht ein einziger entwendeter Schlüssel aus, um die Kommunikation auf Basis dieses Schlüssels netzwerkweit zu beeinträchtigen. Dies ist auch der Grund, warum der Network-Key sich nicht zur gezielten Absicherung von Sensordaten im Szenario 2 eignet.
Für Broadcast-Nachrichten innerhalb des WSN ist der Network-Key hingegen durchaus relevant, da so etwa Statusinformationen zum Betrieb des Netzes effizient zwischen allen Teilnehmern ausgetauscht werden können. Da dieser Schlüssel vorinitialisiert wurde, ist es äußerst komplex, im Falle des Schlüsselverlusts einen neuen Netzwerk-Key zwischen allen Geräten zu etablieren. Es muss nämlich davon ausgegangen werden, dass der Angreifer ab diesem Zeitpunkt sämtliche Datenübertragungen mitlesen kann, die durch den Network-Key verschlüsselt wurden. Somit kann dieser initiale, inzwischen ungültige Schlüssel nicht mehr für die Verteilung eines neuen Schlüssels genutzt werden.
Abhilfe können hier die zuvor etablierten Cluster-Keys schaffen:
Das Regenwald-Szenario zeigt eindrucksvoll, wie komplex die Thematik rund um den sicheren Betrieb eines Wireless Sensor Networks werden kann. Und selbst mit diesen umfassenden Überlegungen ist das Ende der Fahnenstange nicht erreicht: Es lauern noch zahlreiche weitere mögliche Angriffe, beispielsweise auf Routing-Verfahren, die darauf abzielen, dass Nachrichten nie ihr Endziel erreichen.
Um in dieser Umgebung der sich schnell fortentwickelnden Angriffe nicht den Überblick zu verlieren, befassen wir uns regelmäßig mit neusten Ansätzen kreativer Angreifer um die IoT-Anwendungsfälle unserer Kunden vollumfassend und bestmöglich abzusichern. Wir freuen uns darauf, uns auch mit Ihnen unverbindlich zu Ihrem IoT-Einsatz auszutauschen!
Im nächsten Teil der IoT-Artikelreihe bewegen wir uns vom hypothetischen Anwendungsfall des IoT-Sensornetzes im Regenwald zurück in die Realität. Denn um die Sicherheit von aktuell eingesetzten IoT-Geräten steht es schlimmer als man im ersten Moment glauben mag: Automatisierte Massenangriffe haben es geschafft, Millionen von Geräten in kürzester Zeit zu befallen. Welche ausgeklügelten Mechanismen die Angreifer hierfür einsetzen, wie sich IoT-Botnets in den vergangenen Jahren entwickelt haben und wie man diesen bedrohlichen Trend unterbrechen kann, thematisieren wir im nachfolgenden Teil 5 der Artikelreihe.
Lesen Sie den nächsten Artikel oder kehren Sie zurück zur Gesamtübersicht.
