Teil 4: Large Scale Security – Sicherheit im Regenwald

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:

1. Neighbor Discovery: Mit der Landung startet jedes Gerät einen Timer. Dieser gibt ein Initialisierungs-Zeitfenster vor, in welchem neue Geräte entdeckt werden können. Zu diesem Zweck beginnen die Geräte, HELLO-Nachrichten zu versenden. Empfängt ein anderes Gerät eine HELLO-Nachricht beantwortet es diese mit einer Bestätigung (ACK).
2. Schlüsselaustausch: Da beide Geräte den Masterschlüssel kennen, können sie sich unter dessen Benutzung gegenseitig authentifizieren. Dies geschieht mit Hilfe einer pseudozufälligen Funktion, welche die Identität des Gerätes mit dem Masterschlüssel verknüpft. Das empfangende Gerät kann den Masterschlüssel aus der enthaltenen Nachricht nicht extrahieren, die Authentizität aber unter Benutzung des Masterschlüssels verifizieren. Aus den ausgetauschten Nachrichten kann schließlich ein gemeinsamer Link-Key berechnet werden.
3. Vernichtung des Masterschlüssels: Sobald der Timer abläuft, beenden die Geräte das Senden von HELLO-Nachrichten und Bestätigungen. Letztlich wird der Masterschlüssel gelöscht.

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.

• Der Node-Key wird gewählt, wenn beispielsweise besonders sensible Daten übertragen werden sollen, welche vermittelnde Geräte nicht lesen können sollen. In diesem Fall findet eine Ende-zu-Ende Verschlüsselung zur Base-Station statt. Dieses Vorgehen ist nicht ressourcensparsam, da kein In-Network Processing stattfinden kann. Dieses Szenario ist auf Abbildung 1 oben dargestellt (Fall A).
• Link-Keys werden genutzt, wenn ein spezieller Weiterleitungspfad zum Ziel genutzt werden soll. Um die optimalen Pfade zu ermitteln, werden verschiedene Routing-Algorithmen genutzt. Wurde ein passender Pfad gefunden, kann dieser gezielt zwischen den einzelnen Teilstücken (Hops) durch die passenden paarweisen Link-Keys abgesichert werden. Dieses Vorgehen ist ressourcensparsamer, da die Daten von übertragenden Geräten analysiert und gegebenenfalls zusammengefasst werden können. Dieses Szenario ist auf Abbildung 1unten dargestellt (Fall B).

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:

• Im ersten Schritt wird netzwerkweit kommuniziert, welches Gerät durch einen Angreifer kompromittiert wurden.
• Alle Sensorknoten prüfen, ob sie Link- oder Cluster-Keys mit dem infizierten Gerät teilen und entfernen diese umgehend.
• Im Anschluss werden neue Cluster-Keys ausgetauscht, die das kompromittierte Gerät nicht mehr einschließen.
• Letztlich kann durch die Base-Station ein neuer Network-Key generiert werden. Dieser wird dann unter Benutzung der Cluster-Keys durch das gesamte Netzwerk propagiert, bis alle beteiligten Geräte Kenntnis vom neuen Schlüssel erhalten haben.