Sicherheit und Datenschutz

Teil 6, Artikelserie “Smart Home”

Thomas Eichstädt-Engelen, Kai Kreuzer

Schon vor mehr als einem Jahr fragte sogar die Bild-Zeitung “Wie sicher ist das smarte Eigenheim”? Gestellt wurde diese Frage im Kontext der Übernahme von Nest - dem amerikanischen Hersteller smarter Raumthermostate - durch Google. Gemeint war hier allerdings weniger die Sicherheit im Sinne des Zugriffsschutzes, sondern vielmehr die der Privatssphäre. Seitdem hat sich die Situation eher verschlimmert denn verbessert. Der vorliegende Artikel erklärt warum und zeigt Lösungsmöglichkeiten auf.

Viele von uns haben sicher noch den Roman “Blackout - Morgen ist es zu spät” im Gedächtnis. Marc Elsberg beschreibt darin ein Szenario, in dem es Hackern mit Hilfe manipulierter Smart-Meter gelingt, das weltweite Stromnetz kollabieren zu lassen.

Auch wenn der Rollout der Smart-Meter hierzulande inzwischen stellenweise schon begonnen hat, ist die Vernetzung im Energiebereich noch nicht so weit fortgeschritten, um dieses Szenario Wirklichkeit werden zu lassen. Dennoch legt man das Buch eher mit Unbehagen zur Seite und fragt sich, inwieweit die bereits heute im Heimnetz befindlichen Geräte Potential für einen solchen Angriff bieten. Der Blick schweift dabei über den WLAN-Radiowecker, die IP-Kamera, den Raumsensor, den Smart-TV hin zur vernetzten Heizung und dem (Elektro-)auto mit online Zugriff. Von all diesen Geräten erwarten wir als Kunden inzwischen beinahe automatisch, dass wir mit der passenden App Zugriff auf das System bekommen, egal ob wir uns im Heimnetz oder unterwegs befinden. Um den weltweiten Zugriff auf die heimischen, vernetzten Gerätschaften zu ermöglichen, findet man daher häufig folgendes Architekturschema vor:

Das vernetzte Gerät wird mit dem heimischen Netzwerk verbunden. Über die Internetverbindung baut das Gerät aus dem Heimnetz eine ständige Verbindung zu einem proprietären Clouddienst des Herstellers auf. Der ständige Zugang ermöglicht dem Gerät, gesammelte Daten zum Hersteller zu übermitteln und andererseits Schaltbefehle entgegen zu nehmen. Die (in der Regel) kostenlose Smartphone App baut seinerseits eine Verbindung zum Clouddienst auf und erreicht auf diesem Wege auch die im Heimnetz befindlichen Geräte. Ganz nebenbei können dem Datenstrom des Geräts auch noch dynamische Aktivitätsdaten des Benutzers hinzugefügt werden.

Abb.1: typisches Architekturschema im “Internet of Things”
Abb.1: typisches Architekturschema im “Internet of Things”

Dieses Verfahren wird von Herstellern gerne gewählt, da es nur die üblichen Voraussetzungen benötigt, die bei einem Großteil der Anwender vorgefunden werden und die Einrichtung neuer Geräte im WLAN ein bekannter Vorgang ist. Diesen “Luxus” erkaufen sich die Benutzer allerdings mit vielen technischen Nachteilen:

  1. Ein offensichtlicher Nachteil ist die Notwendigkeit einer ständig verfügbaren Internetverbindung und das nicht nur während der Einrichtung, sondern permanent während des Betriebs. Mag die Internetversorgung in Deutschland zwar generell vorhanden sein, so gibt es doch auch genug Ausnahmesituationen. In anderen Ländern sind stundenweise Ausfälle des Internetzugangs sogar eher der Normalzustand. Darüber hinaus lassen sich selbst in den heutigen Breitbandnetzen zum Teil deutliche Latenzen messen, die spätestens dann zu Tage treten, wenn ein dunkles Treppenhaus erst Sekunden später beleuchtet wird, nur weil im Wohnzimmer gerade ein HD-Video aus dem Internet gestreamt wird.
  2. Die ständige Verfügbarkeit der Clouddienste ist in diesem Szenario eine unabdingbare Voraussetzung für die Benutzbarkeit der lokalen Geräte. Wird der Dienst also gleich aus welchem Grund eingestellt, versagen auch die heimischen Geräte ihren Dienst, da sie aus der Cloud mit nötigen Daten und ihrer “Intelligenz” versorgt werden.
  3. Schon rein statistisch wächst mit der zunehmenden Zahl verwendeter Clouddienste die Wahrscheinlichkeit für Sicherheitslücken. Ebenso bieten die zum Teil sehr CPU-schwachen Endgeräte einen ernstzunehmenden Angriffsvektor, da die Größe der zu rechnenden Schlüssel direkt von der Leistungsfähigkeit der Prozessoren abhängt und daher deren Verschlüsselung leichter gehackt werden kann. Tatsächlich gab es in der Vergangenheit schon verschiedene Berichte zu Lücken in IP-Webcams, Heizungssystemen [1], Smart-Home-Gateways [2] und vernetzten Glühbirnen [3].

Für sich genommen, sind diese eher technischen Nachteile des “Internet-of-Things-Patterns” schon gravierend genug. Bedrohlich wird es allerdings, wenn man dieses Muster durch die Datenschutz Brille betrachtet. Dann nämlich stellt man fest, dass die Benutzer jegliche Hoheit über ihre Daten verlieren. Ursache dafür ist der Transport der privaten Daten über das potentiell unsichere Internet, die unterschiedlich vertrauenswürdigen Server, deren Betreiber sowie die Diensteanbieter selbst. Sie entscheiden schließlich allein über die Granularität, die Speicherdauer und die Weitergabe unserer Daten [4] und ermöglichen sich (und allen denen sie die Daten verkaufen) damit die Erstellung umfangreicher Nutzungs- und noch schlimmer Nutzerprofile.

Intranet of Things

Um den genannten Sicherheits- und Datenschutzbedenken zu begegnen, schlagen wir daher im Gegensatz dazu das “Intranet-of-Things-Pattern” vor:

  • Die Kommunikation der Geräte erfolgt im lokalen Heimnetz. Voraussetzung dafür sind Geräte mit lokaler API, die derzeit leider bei weitem nicht von allen Herstellern angeboten wird. Ursache ist das jeweilige Geschäftsmodell, welches auch die Nutzung (und zum Teil Weitergabe) der gesammelten Daten beinhaltet.
  • Die Daten der Geräte werden grundsätzlich lokal gespeichert. Der Benutzer kann explizit von diesem Grundsatz abweichen und im Einzelnen bestimmen, welche Daten wie oft wohin “exportiert” werden. So kann der Benutzer trotzdem von etwaigen BigData-Services profitieren ohne die Kontrolle über seine Daten zu verlieren.
  • Die Zugriff von unterwegs sollte über einen einzigen, gut gesicherten Kanal erfolgen.

Kern dieses Intranet-of-Things-Patterns ist ein Home-Gateway, dass alle Anfragen zentral entgegen nimmt, an die richtigen Teilnehmer verteilt, für die lokale Datenhaltung sorgt und auch die Automatisierung ermöglicht. Neben der softwaretechnischen Umwandlung der Protokolle können auch unterschiedliche physikalische Medien, wie IP, RS–485 und USB miteinander verbunden werden.

Abb.2: Das Intranet-of-Things-Pattern löst zahlreiche Sicherheits- und Datenschutzbedenken
Abb.2: Das Intranet-of-Things-Pattern löst zahlreiche Sicherheits- und Datenschutzbedenken

Nachteil einer Architektur mit zentraler Smarthome “Intelligenz” ist, dass im Fehlerfall gleich alle Funktionen ausfallen würden (Single Point of Failure). Begegnen kann man diesem Problem entweder mit dem Aufbau redundanter Systeme, oder - was zu bevorzugen wäre - mit unterschiedlichen autarken Subsystemen, die über das Gateway integriert und damit dessen Funktionen orchestriert werden. So wird sichergestellt, dass auch im Fehlerfall die Heizung funktioniert und die Lichter geschaltet werden. Lediglich einige Komfortfunktionen wie das Abschalten der Heizung bei geöffnetem Fenster oder das Einschalten der Klimaanlage unter bestimmten Bedingungen wäre nicht vorhanden.

Prinzipbedingte Schwächen

Die unterschiedlichen Smart-Home-Systeme bieten prinzipbedingt unterschiedliche Sicherheitsfeatures as. Es gibt kabelgebundene und kabellose Systeme, wobei bei den kabelgebundenen zwischen denen mit eigener Steuerleitung und solchen die über das Stromnetz kommunizieren (Powerline) unterschieden wird.

Eines der bekanntesten kabelgebundenen Systeme dürfte das KNX-System sein, das auf dem inzwischen weltweit standardisierten KNX-Protokoll beruht [5]. KNX besitzt auf Protokollebene allerdings keinerlei Sicherungsmechanismen und verlässt sich bei der Absicherung des Systems darauf, den physikalischen Zugang zum Buskabel zu verhindern. Das dies alleine nicht ausreichend ist, haben Experten erst kürzlich wieder gezeigt [6]. Sie haben sich Zugang zu einem KNX-basierten Bewegungsmelder im Außenbereich eines Gebäudes verschafft, mit Hilfe freier Software und einem Raspberry Pi das unverschlüsselte, serielle Protokoll mitgelesen und so gezielt Manipulationen vorgenommen. Um diesem Problem zu begegnen, sollte daher der Gebäudebus mindestens mit Hilfe von Filtern, sogenannten Linienkopplern, so segmentiert werden, dass nicht direkt der ganze Bus mitgelesen werden kann. Weitere Maßnahmen zur Erhöhung der Sicherheit, hat die KNX Association zwischenzeitlich in ihrer “KNX Security Checklist” veröffentlicht [7].

Ähnlich sieht es auch bei den Powerline-Systemen, wie z.B. digtialSTROM, aus, deren Komponenten das normale Stromkabel zur Kommunikation benutzen. Zwar wird im Gegensatz zu Netzwerk-Adaptern [8] mit Hilfe von Netzfiltern verhindert, das aufmodulierte Schaltbefehle das heimische Netz verlassen, die Kommunikation selbst erfolgt jedoch unverschlüsselt. Daher wird auch hier empfohlen, den physikalischen Zugang zum Steuernetz zu verhindern und keine digitalSTROM-Schaltkreise in öffentlichen Bereichen zu installieren [9].

Auch wenn die kabelgebundenen Systeme selten weder Authentifizierung noch Verschlüsselung im Sicherheits-Portfolio haben, können sie immer noch mit dem Argument des erforderlichen physikalischen Zugriffs punkten und so die Problematik auf eine andere Ebene verlagern. Bei den kabellosen Protokollen hingegen sieht das etwas anders aus, da sich Funkwellen nicht in der Wohnung oder dem Gebäude einsperren lassen.

Diese Tatsache macht sich das so genannte Wardriving [10] zu nutze, wo Angreifer, bestückt mit einem Notebook, ein wenig freier Software und einem entsprechend empfindlichen Empfänger, gezielt durch die Straßen fahren und nach Zielen suchen. In erster Linie sind das offene WLANs, es können aber ebenso gut kabellose Smarthome-Systeme aufgespürt werden [11].

Ist mit der Wardriving-Methode erstmal ein Smarthome-Netzwerk (bzw. Z-Wave) lokalisiert, kann es aufgrund vorhandener Protokollschwächen zum Ziel von Replay-Attacken werden [12]. Hierzu werden alle Pakete des Zielnetzwerks mitgeschnitten und ausspioniert, welche Aktion im jeweiligen Fall ausgeführt wurde (Licht an, Schloss auf, Heizung rauf). Weil der Angreifer die jeweilige Aktion beobachtet hat, muss er den Inhalt der Pakete gar nicht entschlüsseln können, sondern kann sie eins zu eins wiederverwenden. Sind die richtigen Pakete “im Kasten” wird die Sequenz später auf einem anderen Knoten des Netzwerks abgespielt. Dazu gibt sich der Angreiferknoten als Ursprungsknoten aus und führt den aufgezeichneten Befehl erneut aus. Handelt es sich dabei um LED-Farblampe wäre das vielleicht noch zu verkraften. Nutzt das heimische Türschlüss allerdings dieses Protokoll, bekäme ein solcher Angriff eine andere Brisanz.

Ebenso gut könnte eine Man-in-the-middle Attacke initiiert werden. Bei dieser Attacke werden bekannte Schwächen der Protokolle ausgenutzt, um dem Netzwerk einen neuen Masterknoten vorzugaukeln, über den dann fortan sämtlicher Netzwerkverkehr geroutet wird. Wenn das gelungen ist, können auch eigene Kommandos ohne den tatsächlichen Netzwerkschlüssel zu kennen eingeschleust werden (Eavesdropping). Schenkt man den Autoren glauben, konnten mit Hilfe solcher Attacken schon ZigBee [13] und Z-Wave Netzwerke kontrolliert werden, wenngleich in beiden Fälle der Aufwand für solche Angriff als hoch eingeschätzt wurde [14],[15].

All diese Angriffsszenarien sind für sich genommen schon lange bekannt und erforscht. Auch die entsprechenden Gegenmaßnahmen wie Signierung und Verschlüsselung der Nachrichteninhalte, die Verwendung von Sequenzennummern und ausreichend großer Schlüssel sind keine Neuigkeit. Was vielen Software-Ingenieure sehr wohl eher neu ist, ist der Umgang mit kleinen, zum Teil batteriebetriebenen Geräten und ihren sehr begrenzten Energie- und CPU-Ressourcen. Die CPU wird allerdings zur Berechnung großer Zahlen benötigt, die bekanntlich die Grundlage zur sicheren Signierung und Verschlüsselung sind, was wiederum die Haltbarkeit der Batterie beeinflusst. Aus diesem Grund wird allzu oft zu Gunsten kleinerer Schlüssel und eingeschränkter Sicherheitsfeatures und damit für einen vermeintlich größeren Kundennutzen entschieden [16].

Fazit

Auch wenn mit dem “Intranet of Things” im Smarthome schon viele Sicherheits- und Datenschutzbedenken adressiert werden können, ist dennoch eine gesunde Skepsis bei der Integration neuer Geräte in das heimische Netzwerk oder dem Klick des “Datenschutzerklärung akzeptieren”-Buttons geboten.

Denjenigen, die befürchten, dass “gewöhnliche” Diebesbanden in Zukunft nur noch das Smartphone statt einem Brecheisen zücken, sei gesagt, dass Kriminelle Aufwand und Nutzen sehr gut abwägen. Die Statistik zeigt, dass nur in seltenen Fällen ein Eingriff in die Haustechnik vorgenommen wird, weil der Aufwand dafür schlicht zu hoch ist. Die Kommissare des Bereichs Prävention und Opferschutz der Kreispolizeibehörde Paderborn bspw. wissen zwar um diese theoretische Gefahr, geben aber Entwarnung: „Wohnungseinbrecher kommen durch die Tür, Hauseinbrecher durch ungesicherte Fenster und Terrassentüren. Ein elektronischer Einbruch dagegen hinterlässt Spuren und dauert viel zu lange. Wer die Technik beherrscht, eine Tür per Computer zu öffnen, kann damit mehr Geld verdienen.“ [17]

Auch gegen das “Blackout”-Szenario gibt es inzwischen gesetzliche Massnahmen, die im Schutzprofil für Smart-Meter durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) zusammengefasst sind. Hierin wird beschrieben wie elektronische und vernetzte Zähler für Strom, Gas, Wärme und Wasser abgesichert werden müssen.

HP Fortify stellte überdies in einer Studie zum Thema Sicherheit im IoT fest, dass etwa 70% der IoT-Geräte mehr oder weniger verwundbar sind. Derzeit scheine das Internet of Things die Schwachstellen aller bekannten Bereichen, wie Netzwerk-, Applikations- und Mobilsicherheit sowie den Internet-konnektierten Geräten zu vereinen und sie in eine neue, noch unsicherere Dimension zu überführen [18]. Hoffen wir, dass die Hersteller bald reagieren, damit mangelnde Sicherheit und unzureichender Datenschutz nicht den aufkommenden Erfolg der Internet-of-Things- und Smarthome-Branche hemmen.

Referenzen

  1. http://www.heise.de/security/meldung/Vaillant-Heizungen-mit-Sicherheits-Leck-1840919.html  ↩

  2. http://www.heise.de/security/meldung/Licht-an-Whirlpool-aus-Smart-Home-Hacking-1927124.html  ↩

  3. http://fusion.net/story/55026/this-guys-light-bulb-ddosed-his-entire-smart-house/  ↩

  4. http://upon2020.com/blog/2015/01/nest-responds-to-my-privacy-questions/  ↩

  5. http://en.wikipedia.org/wiki/KNX_(standard)  ↩

  6. http://www.golem.de/news/knx-schwachstellen-spielen-mit-den-lichtern-der-anderen-1503-113085.html  ↩

  7. http://www.knx.org/media/docs/Flyers/KNX-Security-Checklist/KNX-Security-Checklist_de.pdf  ↩

  8. http://www.pcwelt.de/tipps/Powerline-Netzwerke_vor_Nachbarn_schuetzen-Heimnetz-8291047.html  ↩

  9. http://www.digitalstrom.com/documents/A0818D044V005_FAQ.pdf  ↩

  10. http://de.wikipedia.org/wiki/Wardriving  ↩

  11. http://travisgoodspeed.blogspot.co.uk/2012/02/wardriving-for-zigbee.html  ↩

  12. http://www.mirlabs.net/his14/proceedings/html/paper77.xml  ↩

  13. http://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1044&context=isw  ↩

  14. http://www.insinuator.net/2015/01/riding-the-z-wave-part-1/  ↩

  15. https://www.youtube.com/watch?v=gn-amPvXn6M  ↩

  16. https://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisa-thematic-landscapes/threat-landscape-for-smart-home-and-media-convergence/  ↩

  17. http://www.connected-home.de/ratgeber/sicherheit-vernetztes-heim-smart-home-sicher-1934188.html  ↩

  18. http://h30499.www3.hp.com/t5/Fortify-Application-Security/HP-Study-Reveals-70-Percent-of-Internet-of-Things-Devices/ba-p/6556284#.VU9tkM65N6l  ↩

Thumb dsc02125 2

Thomas Eichstädt-Engelen is a Smart Living enthusiast, and contributor to the Eclipse SmartHome project, as well as project lead for openHAB. Until March 2016, he worked as Principal Consultant at innoQ. He has a strong focus on developing individual custom software with Eclipse technologies (Java, RCP, OSGi) primarily in the Smart Home sector.

More content

Thumb kaik

Kai Kreuzer is a Java and OSGi expert, a Home Automation enthusiast, founder of openHAB.org and the project lead of the Eclipse SmartHome project. He works as a Developer Evangelist in the Connected Home department of Deutsche Telekom AG, which develops an OSGi-based platform for smart homes called QIVICON.

More content

Entwickler magazin
Dieser Artikel ist ursprünglich in der Ausgabe 04/2015 der Zeitschrift Entwickler Magazin erschienen. Die Veröffentlichung auf innoq.com erfolgt mit freundlicher Genehmigung des S&S Media-Verlags.

Comments

Please accept our cookie agreement to see full comments functionality. Read more