Startseite > Embedded > Sicherheit in drahtlosen Sensornetzwerken

Internet der Dinge

Sicherheit in drahtlosen Sensornetzwerken

22. Oktober 2014, 9:33 Uhr | Ralf Higgelke

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Mögliche Fehler bei der Sicherheit

Jeder kann einen Schlüssel für ein WSN erzeugen, das ist aber unpraktisch und sehr unsicher, wie weiter unten noch näher beleuchtet. Idealerweise soll ein Computer den Schlüssel erstellen. Da der Schlüssel nicht erraten werden soll, muss er zufällig sein, was einen Zufallszahlengenerator (Random Number Generator, RNG) erfordert. Im Allgemeinen sollen Computer aber vollkommen deterministisch sein, Zufall wird missbilligt. Einen Computer echt zufällig arbeiten zu lassen, ist keine leichte Aufgabe und bedingt immer ein Zusammenspiel mit einem nicht-digitalen System. Glücklicherweise sind Funkstrecken an sich nicht-digital, und es hat seit Marconi ein Jahrhundert gebraucht, um digitale Nachrichten zuverlässig zu übertragen. Ein gutes WSN-System verwendet ein HF-Teil oder eine andere Quelle thermischen Rauschens als integralen Teil seines RNG, um echte Zufallszahlen zu erzeugen.

Sogar ein zugelassener Netzwerkteilnehmer, der aber nicht korrekt eingesetzt wird, kann Steuersysteme durch nicht erwartete Eingangssignale verwirren. Zugriffskontrolllisten (Whitelists, Blacklists) bieten deshalb eine zusätzliche Sicherheitsebene, die sicherstellt, dass nicht zugelassene oder nicht korrekt eingesetzte Geräte das Netzwerk nicht unterbrechen können.

Mögliche Fehler bei der Sicherheit

Der größte Fehler in der WSN-Sicherheit ist, dass man die Größe eines Problems erst erkennt, wenn es zu spät ist. So scheint der Aufbau eines funkgesteuerten Beleuchtungssteuersystems ohne Sicherheitsfeatures kein Problem zu sein, bis beispielsweise übereifrige Studenten die Büros von Kunden für eine nette Light-Show nutzen.

Sogar Anwender, welche die Wichtigkeit von Sicherheit begrüßen, unterschätzen oft die Raffinesse sowie die entsprechenden Software- und Hardwaretools, die auf der »dunklen Seite« dieses Konflikts am Werk sind. Einige WSN-Hersteller preisen die Sicherheitsvorteile ihrer Kanalsprung-Protokolle (Channel Hopping) an, als wenn ein Angreifer nicht in der Lage wäre, einen Multikanal-Empfänger und -Sender zu kaufen. Andere denken, dass Millionen oder Milliarden Schlüssel genug seien, um Attacken abzuwehren, wenn doch selbst sogar Milliarden von Milliarden nicht genug sind. Falls die Möglichkeit einer Brute-Force-Attacke besteht, die den Schlüssel knackt, dann wird ein Schlüsselaustauschplan, der nur einen kleinen Teil der Brute-Force-Zeit ausmacht, nur den durchschnittlichen Angreifer abhalten, nicht aber den Profi.

Angenommen man hat die passende Chiffre gewählt und Nonces kommt zum Einsatz, wird man in einem einfachen System einen gemeinsamer Schlüssel für alle kryptografischen Operationen verwenden. Dieser Ansatz passt, so lange der Schlüssel geheim bleibt, was jedoch schwierig einzuhalten ist.

Ein extremes Beispiel für die Verwundbarkeit ist eine Bluetooth-gesteuerte Toiletten/Bidet-Kombination, in der ein voreingestellter Verbindungsschlüssel mit lauter Nullen verwendet wurde [3]. Das ist eigentlich ein Beispiel für keine Sicherheit als eines für schlechte Sicherheit, illustriert aber, dass die besten Protokolle nicht vor einem schlecht gewählten Schlüssel oder vor einem Zufallsschlüssel schützen, der im Internet weitgehend bekannt ist. Bluetooth bietet exzellente Sicherheitstools, wenn man sie aber nicht richtig nutzt, sind sie wertlos, sobald jemand seine produktweiten Schlüssel unklugerweise im Web offenlegt.

Jeweils einen eigenen Schlüssel verwenden

Eine Stufe höher in der Sicherheit bedeutet, für jedes gelieferte oder installierte Netzwerk einen eigenen Schlüssel zu haben oder jedes Mal, wenn das Netzwerk eingesetzt wird, einen neuen Schlüssel zu verwenden. Hat man einen guten Zufallsgenerator und die Netzwerkhardware voll unter Kontrolle, ist das ein guter Ansatz. Ist jedoch ein Netzwerkknoten unsicher, kann das gesamte Netzwerk Attacken ausgesetzt sein. Dürfen Anwender ihre eigene Software für die Netzwerkknoten schreiben, ist es ganz schwierig, einen böswilligen Anwender davon abzuhalten, den Netzwerkschlüssel herauszufinden.

Selbst wenn die Software eines Knotens in sich abgeschlossen ist, ist es sehr schwierig, Angreifer davon abzuhalten, den Code des Mikroprozessors auszulesen, wenn dieser die Hardware unter seine Gewalt gebracht hat. Die Sicherheitsliteratur ist voll von Beispielen für solche Attacken, die oft so aussehen: Man besorgt sich legal eine Version der Hardware und knackt den Code, oder findet durch Reverse-Engineering des Codes heraus, wo der Schlüssel abgelegt ist; das kann so einfach sein, indem man die Codes zweier verschiedener Netzwerke miteinander vergleicht, um zu sehen, welche Bits unterschiedlich sind. Man verwendet dann diese Information, entweder um herauszufinden, wie der Schlüssel berechnet wurde (dazu mehr weiter unten). Noch schneller geht es, wenn man den Schlüssel aus der Hardware des aktuell angegriffenen Netzwerks erfasst.

Die Sicherheitssysteme von DVDs sind solch einer Attacke zum Opfer gefallen, und zwar das originale »DVD Content Scrambling System« (CSS) und das »HD-DVD/Blu-Ray Advanced Access Content System« (AACS). Beide wurden von Hackern bloßgelegt, indem sie den Playercode untersuchten und mehrere der Processing-Schlüssel, die eigentlich schützen sollten, veröffentlichten.