Sicherer Betrieb eines Smart Homes. Ein Modell

Inhalt

I Abbildungsverzeichnis

II Tabellenverzeichnis

III Listings

IV Abkürzungsverzeichnis

1 Einführung
1.1 Zielsetzung
1.2 Vorgehensweise
1.3 Aufbau der Arbeit

2 Grundlagen Smart Home Sicherheit
2.1 Begriffsdefinition
2.2 Smart Home Komponenten
2.2.1 Aufbau und Architektur eines Smart Homes
2.2.2 Anwendungsfelder
2.2.3 Verschattung
2.2.4 Klimatisierung
2.2.5 Beleuchtung
2.2.6 Stromkreissteuerung
2.2.7 Sicherheitsfunktionen
2.3 Übertragungswege
2.3.1 Drahtgebundene Übertragung
2.3.2 Funkübertragung
2.3.3 WLAN und Bluetooth
2.4 Systemstrukturen
2.4.1 Zentrale Struktur
2.4.2 Dezentrale Struktur
2.4.3 Halbzentrale Struktur
2.5 Generische Smart Home Protokolle der Anwendungsschicht
2.5.1 Constrained Application Protocol (CoAP)
2.5.2 Message Queue Telemetry Transport Protocol (MQTT)
2.5.3 HTTP
2.6 Bekannte Angriffstechniken
2.7 Sicherheitsziele
2.8 Rahmenbedingungen
2.9 Sicherheitsbewusstsein

3 Design eines sicheren Smart Homes
3.1 Gegenstand der Untersuchung
3.2 Entwicklung des Modells
3.3 Physikalischer Testaufbau des Modells
3.3.1 Die Kernkomponenten
3.3.2 Funkbus-Anbindung
3.3.3 Aktoren
3.3.4 WAN Anbindung
3.4 Benutzte Software
3.4.1 Das Betriebssystem openHabian
3.4.2 Smart Home Hub Software openHAB
3.4.3 CCU-Ersatz RaspberryMatic
3.5 Der Weg zum Modell
3.6 Prinzipien
3.6.1 Sicherheit durch Trennung von Smart Home und privaten Netzen
3.6.2 Sicherheit durch kanalisierten Zugang zum Smart Hub durch VPN
3.6.3 Sicherheit durch gesteuerte Updates
3.7 Das Modell

4 Forschungsergebnisse der Experimente
4.1 Software zur Designevaluation
4.1.1 Kali Linux
4.1.2 NMAP
4.1.3 openVAS
4.1.4 Metasploit
4.2 Vorbereitung der Schwachstellenanalysen
4.3 Schwachstellenanalyse der Wahrnehmungsschicht
4.3.1 Schwachstellenanalyse im Funkbus-System
4.4 Schwachstellenanalyse der Anwendungsschicht
4.5 Schwachstellenanalyse der Netzwerkschicht
4.5.1 Sicherheit im Patchmanagement
4.5.2 Sicherheit durch Intrusion Detection
4.6 Bedienbarkeit

5 Interpretation mit Schlussfolgerungen und Handlungsempfehlungen
5.1 Vergleich Lösungen und Anforderungen
5.1.1 Perspektive Wahrnehmungsschicht
5.1.2 Perspektive Anwendungsschicht
5.1.3 Perspektive Netzwerkschicht
5.2 Empfehlungen für ein Future Proof Smart Home
5.2.1 Allgemein
5.2.2 Genereller Aufbau eines Smart Homes
5.2.3 Netzwerk-Dienste
5.2.4 Handlungsempfehlungen Hardware
5.2.5 Handlungsempfehlungen Penetration-Test
5.2.6 Handlungsempfehlungen für Passwörter
5.2.7 Handlungsempfehlung Intrusion Detection

6 Fazit
6.1 Zusammenfassung
6.2 Kritische Reflektion
6.3 Ausblick

Literaturverzeichnis

Anhang

Kurzfassung

In dieser Arbeit soll der Frage nachgegangen werden, ob es möglich ist, ein sicheres Modell für den Betrieb eines Smart Homes zu erschaffen. Dazu werden der Stand der Technik und die dazu gehörigen möglichen Angriffspunkte auf ein Smart Home ermittelt. Basierend darauf werden die Sicherheitsanforderungen definiert. Bevor das Modell definiert wird, werden Prin- zipen definiert, die zusammen mit verschiedenen Perspektiven einer generellen Smart Home Architektur bei der Erstellung des Modells berücksichtigt werden. Diese Perspektiven werden bei der Evaluierung des Modells in Form einer Schwachstellenanalyse wieder aufgegriffen. Die anschließende Bewertung der Lösung setzt ebenfalls wieder an diesen Perspektiven an. Das erarbeite Modell wird kritisch untersucht und es folgen Handlungsempfehlungen für ein Future-Proof-Konzept.

Abstract

In this paper, we will investigate whether it is possible to create a secure model for the operation of a smart home. To this end, the state of the art and the associated possible points of attack on a smart home will be determined. Based on this, the security requirements are defined. Before the model is then defined, principles are defined that will be considered along with different perspectives of a general smart home architecture when creating the model. These perspectives are taken up again in the evaluation of the model in the form of a vulnerability analysis. The subsequent evaluation of the solution is also based on these perspectives. The model developed is critically examined and recommendations for action for a future proof concept follow.

I Abbildungsverzeichnis

Abbildung 1: Exemplarische Darstellung eines Smart Home

Abbildung 2: Smart Home Architektur Modelle

Abbildung 3: Generischer Aufbau eines Funkbussystems

Abbildung 4: Zentrales System

Abbildung 5: Dezentrales System

Abbildung 6: Exemplarische Darstellung der Anwendungsschicht

Abbildung 7: Exemplarische Darstellung der Wahrnehmungsschicht

Abbildung 8: Exemplarische Darstellung der Netzwerkschicht

Abbildung 9: Modell von Mantoro, Ayu, & Mahmod (2014)

Abbildung 10: Physikalischer Testaufbau

Abbildung 11: Raspberry Pi Modell 3b+

Abbildung 12: HomeMatic Funkmodul, Raspberry Pi mit gestecktem Funkmodul

Abbildung 13: HomeMatic und HomeMatic IP Aktoren

Abbildung 14: Allterco Robotics Ltd Steckdose Shelly Plug S

Abbildung 15: Fritzbox

Abbildung 16: OpenHAB Thing/Item Beispiel

Abbildung 17: Prinzip Trennung Smart Home Area vom privaten Netzwerk

Abbildung 18: Firewall-Konzept Trennung internes Netzwerk

Abbildung 19: Zugriffsprinzip auf den Smart Home Hub

Abbildung 20: Firewall-Konzept Zugriff auf Smart Home Hub

Abbildung 21: Reverse Proxy Integration

Abbildung 22: Beispiel einer openHAB Sitemap im Android Client

Abbildung 23: Updateprozess

Abbildung 24: Modell sicheres Smart Home

Abbildung 25: Generelles Firewall-Konzept (Eigene Darstellung)

Abbildung 26: openVAS Schwachstellenanalyse Ergebnis

Abbildung 27: Web-Zugriff auf WLAN-Steckdose

Abbildung 28: Passwortschutz der WLAN-Steckdose

Abbildung 29: RaspberryMatic-System mit HomeMatic-RF Komponenten

Abbildung 30: Einschalten der Verschlüsselung in HomeMatic Komponente

Abbildung 31: Keine Möglichkeit HomeMatic-IP unverschlüsselt zu Betreiben

Abbildung 32: Port-Scan auf das WAN-Gateway

Abbildung 33: Port-Scan auf den Smart Home Hub

Abbildung 34: openHAB Webseite nach Installation

Abbildung 35: Wörterbuchangriff Metasploit auf openHAB Server

Abbildung 36: Firewall INPUT-Chain

Abbildung 37: Portscan mit eingeschalteter Firewall auf dem Smart Home Hub

Abbildung 38: WLAN-Netzwerk-Scan

Abbildung 39: Firewall Forward-Chain

Abbildung 40: openHAB Forward-IPTABLES Switch

Abbildung 41: Offene FORWARD Firewall Chain

Abbildung 42: Fritzbox Paketmitschnitt

Abbildung 43: Wireshark Paketmitschnitt

Abbildung 44: Geographischer Nachweis in Wireshark

Abbildung 45: Snort Sceenshot IMCP Traffic

Abbildung 46: openHAB Bindings

Abbildung 47: openHAB Things INBOX

Abbildung 48: openHAB ITEM

Abbildung 49: openHAB Model-Webseite

Abbildung 50: Empfohlenes Modell

Abbildung 51: openHAB Sitemap Handy Darstellung

II Tabellenverzeichnis

Tabelle 1: Übersicht Funkstandards

Tabelle 2: Übersicht drahtlose Verbindungen

Tabelle 3: Allgemein Protokolle in der Anwendungsschicht

Tabelle 4: Übersicht Angriffe auf IoT-Geräte

Tabelle 5: Benutzte Netzwerke

Tabelle 6: Firewall Regel auf dem WAN-Gateway

Tabelle 7: Firewall Regel auf dem Smart Home Hub

Tabelle 8: Phasen des Penetrationstest und Werkzeuge

Tabelle 9: Übersicht der verwendeten IP's und Schnittstellen der Schwachstellenanalyse

Tabelle 10: Übersicht eingesetzte Komponenten

III Listings

Listing 1: Beispiel Netzwerkscan mit NMAP

Listing 2: Beispiel Portscan eines Hosts mit NMAP

Listing 3: Beispiel Analyse eines SSL-Zertifikats

Listing 4: OpenHAB Regeln FW_auf und FW_zu

Listing 5: Snort ICMP-Regel

Listing 6: Aufgezeigter ICMP Traffic

Listing 7: Beispiel Installation Access Point

Listing 8: Beispiel einer openHAB-Sitemap

Listing 9: Beispiel Erzeugung eines SSL-Zertifikats

Listing 10: Konfiguration NGINX Server mit SSL-Zertifikat

Listing 11: Snort Beispiel

Listing 12: Überprüfung SSL-Zertifikat

Listing 13: iptables mit Root-Rechten

Listing 14: openHAB Regel iptables

IV Abkürzungsverzeichnis

CCMP... CounterMode/CBC-MAC Protocol

CCU... Central-Control-Unit

CVE... Common Vulnerabilities and Exposures

DTLS Datagram Transport Layer Security

IoT Internet of Things

ISM Industrial, Scientific and Medical Band

LAN... Local Area Network

MQTT. Message Queuing Telemetry Transport

NIDS Network Intrusion Detection System

NIPS.. Network Intrusion Prevention System

RCE... Remote Code Execution

SCP. Secure Copy

SSH. Secure Socket Shell

TCP/IP.. Transmission Control Protocol/Internet Protocol

TKIP... Temporal Key Integrity Protocol

TLS Transport Layer Security

UDP.. User Datagram Protocol

VDE VDE Verband der Elektrotechnik Elektronik Informationstechnik e.V.

VPN... Virtual Private Network

VT.. Vulnerability Tests

WAF.. Web Application Firewall

WAN.. Wide Area Network

WEP.. Wired Equivalent Privacy

WLAN. Wireless Local Area Network

WPA.. Wi-Fi Protected Access

1 Einführung

Das Wort Smart Home ist in aller Munde. 2019 hatten bereits 34 % aller Haushalte in Deutschland eine intelligente Lichtschaltung (Statista, 2021). Allerdings gibt es kaum Vorschriften oder Hinweise, wie ein Smart Home sicher zu betreiben ist, was viele Menschen dazu bewegt, ihr Smart Home leichtfertig und ohne Schutz in Betrieb zu nehmen. Nach der sogenannten Störerhaftung mussten Betreiber eines WLAN-Netzwerks bis 2017 für rechtswidriges Handeln Dritter im eigenen Netzwerk haften (Verbraucherzentrale, 2021). Auch nach Änderung des Gesetzes werden bei Rechtsverletzungen immer noch zuerst die Anschlussinhaber in die Pflicht genommen. Deshalb ist es wichtig, alles zu tun, damit der Zugang zum eigenen Netzwerk nicht durch eine unzureichend geschützte Smart Home Komponente in Gefahr gerät und Dritte das eigene Netzwerk mitbenutzen. Ein Smart Home ist im Wesentlichen der Zusammenschluss von intelligenten Geräten, deshalb spricht man auch vom Internet der Dinge. Zu diesen Dingen können sämtliche Geräte des täglichen Gebrauchs gehören, wie zum Beispiel Haushaltsgeräte, Autos oder auch Smartphones (Ray & Bagwari, 2020). Es ist anzunehmen, dass im Jahr 2020 etwa 50 Millionen IoT-Geräte weltweit ihren Dienst getan haben (Andrea, Chrysostomou, & Hadjichristofi, 2015). IoT-Geräte werden über Monate und Jahre betrieben und sind oft darauf ausgelegt, wenig Energie zu verbrauchen. Daraus resultiert, dass Stan- dard-TCP/IP-Protokolle weniger ideal und suboptimal für die IoT-Charakteristika und Herausforderungen sind. Allerdings wirft dies Sicherheitsbedenken auf, da den interoperablen IoT-Protokollen und offenen IoT-Standards im Vergleich zu den TCP/IP-Stack-Protokollen die Sicherheitsgrundlage fehlt (Andrea, Chrysostomou, & Hadjichristofi, 2015). Durch die Koexistenz und Zusammenarbeit verschiedener Technologien gibt es keinen einheitlichen Standard, was zur Folge hat, dass der Anwender die Qual der Wahl hat, welches System, mit welchem Protokoll eingesetzt werden soll. Da das Internet die Grundlage eines Smart Homes bildet, übertragen sich die Gefahren aus dem Internet auf das Smart Home. Um diesen Gefahren entgegen zu wirken, soll der Frage nachgegangen werden, ob es möglich ist, ein sicheres Smart Home aufzubauen.

1.1 Zielsetzung

Das angestrebte Sicherheitsziel ist der Schutz der gesammelten Daten und der kompletten IoT- Infrastruktur. Deshalb muss das Gesamtsystem widerstandsfähig gegen datenbezogene Angriffe sein (Andrea, Chrysostomou, & Hadjichristofi, 2015). Zusätzlich müssen die privaten Daten und auch die komplette restliche Infrastruktur, die parallel zum Smart Home betrieben wird, ebenfalls geschützt werden. Das bedeutet, dass die Vertraulichkeit, Integrität und Verfügbarkeit der Daten zu jedem Zeitpunkt gewährleistet sein muss. Um dies zu erreichen, muss die Authentifizierung, die Zugriffskontrolle und der verschlüsselte Datenverkehr mit einbezogen werden. Dazu soll ein Modell

geschaffen werden, das nicht speziell auf einen Smart Home Anbieter zugeschnitten ist. Weiter soll dieses Modell auch die Freiheit besitzen, verschiedene Technologien und Protokolle gemeinschaftlich zu vereinen. Es soll die Möglichkeit geben, dass die Smart Home Komponenten von außerhalb des eigenen Netzes gesteuert werden können. Dabei soll aber keine Cloud-Lösung zum Einsatz kommen. Das Netzwerk, in denen sich die Smart Home Komponenten befinden, soll streng getrennt vom User-Netzwerk sein, um auszuschließen, dass ein kompromittiertes Smart Home Gerät eine Möglichkeit für Angreifer bietet, von da aus private Geräte zu attackieren. Alle Smart Home Komponenten sollen zentralisiert verwaltet werden.

1.2 Vorgehensweise

Um die Thematik zu erkunden und den gegenwärtigen Stand der Technik zu erfahren, erfolgt als erstes eine Analyse der Situation. Diese beinhaltet die Sichtung der relevanten Literatur.

Im Anschluss an die Literaturanalyse erfolgt das Design eines sicheren Modells als Resultat der erworbenen Kenntnisse über mögliche Angriffspunkte eines Smart Homes.

Als nächster Schritt findet eine Validierung des Modells durch eine Analyse der möglichen Schwachstellen im erzeugten Modell statt. Dieser Teil bildet die Forschung ab.

Im Anschluss an die Validierung erfolgt eine Bewertung des Modells in Bezug auf die gewonnenen Erfahrungen und Empfehlungen über ein zukünftiges Vorgehen.

Die Vorgehensweise wird durch den Aufbau der Arbeit detaillierter dargestellt.

1.3 Aufbau der Arbeit

Um sich mit der Materie vertraut zu machen werden in Kapitel zwei wichtige Begriffe, die im Zusammenhang mit einem Smart Home stehen, erklärt. Daran anschließend werden die Komponenten eines Smart Homes erläutert. Dies schließt die Architektur ebenso ein, wie die verschiedenen gebräuchlichen Anwendungsfelder und die hauptsächlich genutzten Protokolle im Smart Home Bereich. Es folgen Erläuterungen zu Systemstrukturen von Smart Home Systemen. Daran anschließend werden Angriffsmöglichkeiten, basierend auf der allgemeinen Architektur eines Smart Homes vorgestellt. Darauf aufbauend folgen die Sicherheitsziele. Das Kapitel zwei schließt dann mit den Rahmenbedingungen ab.

In Kapitel drei wird das Ziel beschrieben und das Modell definiert. Der Testaufbau und die benutzte Software für den Testaufbau werden dargestellt. Die Prinzipien, die für dieses Modell angewendet werden sollen, werden definiert und erläutert. Der Weg zum Modell wird dargestellt. Da später das

Modell evaluiert wird, wird am Anschluss an das Modell die benutzte Software zur Evaluation erläutert.

Das vierte Kapitel widmet sich den Forschungsergebnissen. Basierend auf den Schichten des Architekturmodells eines Smart Homes werden schichtbasiert die Schwachstellen untersucht. Dazu werden die Schwachstellen nach Wahrnehmungsschicht, Anwendungsschicht und Netzwerkschicht unterteilt. Explizit wird in der Wahrnehmungsschicht exemplarisch ergründet, wie Sicherheit im Funkbussystem aussehen kann. In der Netzwerkschicht wird das Patchmanagement mit untersucht. Anhand eines Intrusion Detection Beispiels wird analysiert, wie Einbrüche erkannt werden können.

Im fünften Kapitel werden die Ergebnisse zusammengetragen und ausgewertet. Als erstes erfolgt ein Vergleich der Lösungen zu den Anforderungen. Weiter wird ein Future-Proof Konzept eines Smart Homes dargestellt. Daraus ergeben sich Handlungsempfehlungen, wie ein Smart Home zukunftssicher (future-proof) aufgebaut werden sollte.

Das sechste Kapitel beinhaltet ein Fazit. Daran angelehnt erfolgt eine kritische Bewertung des Ergebnisses. Zu guter Letzt wird ein Ausblick über weitere mögliche Forschungsarbeit gegeben.

2 Grundlagen Smart Home Sicherheit

2.1 Begriffsdefinition

Unter einem Smart Home versteht man ein vernetztes Wohnhaus, das mit Sensoren, Haushaltsgeräten und weiteren Geräten ausgestattet ist und seinen Bewohnern Dienste anbietet um Bedürfnisse zu befriedigen. Auf diese Dienste kann auch aus der Ferne zugegriffen werden (Darby, 2018).

Das Internet der Dinge (Internet of Things, IoT) bezeichnet Komponenten, die untereinander vernetzt sind und in Interaktion mit dem Menschen stehen. IoT-Geräte sind in der Wirtschaft und in der Industrie vertreten. In Kombination mit dem Begriff Smart Home werden IoT-Geräte in eine smarte häusliche Umgebung integriert. Beispiele für IoT-Geräte im Smart Home sind verschiedene WLAN- Geräte, Bewegungsmelder, Smart Metering sowie weiteren Aktoren und Sensoren. Durch eine hohe Anzahl von verschiedenen Herstellern ist eine historisch gewachsene Landschaft mit verschiedenen Protokollen entstanden. Ein Vorteil von IoT-Gräten ist der Komfortgewinn im täglichen Leben. Leider entstehen damit aber auch gravierende Nachteile, denn IoT-Geräte erfassen, verarbeiten und sammeln Daten, die sie an Dritte weitergeben können (Wendel, 2020).

Wie oben beschrieben gehören zur Kategorie der IoT-Geräte auch Sensoren. Sie erfassen Daten und liefern sie an andere Geräte, wie zum Beispiel Aktoren weiter. Die Funktionsweise eines Sensors ist im Wesentlichen die Aufnahme von physikalischen Größen und deren Umwandlung in elektrische Signale. Ein gutes Beispiel stellt ein Bewegungsmelder dar, der einen Aktor triggern kann, wenn eine Bewegung wahrgenommen wurde. In der Physik gibt es aktive und passive Sensoren. Weiter gibt es mechanische und nicht-mechanische Sensoren. Neben Rauschmeldern gibt es zum Beispiel Tür- und Fensteröffnungssensoren sowie Wasserstands-Sensoren. Auch ein Thermometer ist ein Sensor. Im Smart Home arbeiten Sensoren mit Aktoren zusammen (Baumann, 2020b).

Ein Smart Home Hub ist das Kernstück eines Smart Home System. Der Hub sendet und empfängt Befehle und leitet sie koordiniert weiter. Alle Komponenten verbinden sich zu dieser zentralen Instanz. Sie wird oft auch als Zentrale, Gateway oder Bridge bezeichnet. Lange gab es nur herstellereigene Hub‘s, gegen die sich die Aktoren und Sensoren des selben Anbieters verbinden. Mit der Vielzahl von verschiedenen Herstellern und Protokollen wurde es erforderlich, Smart Home Hubs zu benutzen, die verschiedene Hersteller Komponenten zentral verwalten können. Somit ist der Smart Home Hub eine zentrale Stelle, die verschiedene Komponenten unterschiedlicher Hersteller verwalten und steuern kann (Baumann, 2020c).

Aktoren sind generell Geräte, die das Ausführen von Aktionen als Aufgabe haben. Durch ein Signal getriggert, wird dieser Prozess angestoßen. Als Beispiel dient hier ein Rollladen-Aktor, der zum Beispiel ein Signal empfängt, wenn ein Sensor (Thermometer) erkennt, dass die Temperatur einen Schwellenwert erreicht hat und die Rollos heruntergefahren werden müssen, um einen Raum zu kühlen und die Sonneneinstrahlung zu blockieren. Aktoren werden von verschieden Herstellern mit verschiedene Protokollen angeboten. In einem Smart Home sind neben Rollladen-Aktoren zum Beispiel auch noch Heizungsthermostate zu finden, die auch in Abhängigkeit der Temperatur die Heizkörper regeln (Baumann, 2020a).

Unter einer Schwachstellenanalyse versteht man die Untersuchung von IT-Geräten auf mögliche Angriffspunkte. Im professionellen Umfeld wird in diesem Zusammenhang von Penetrationtests (Pentesting) gesprochen. Schwachstellen sollen erkannt und bewertet werden (Messner, 2011, S. 13). Messner beschreibt in seinem Buch die verschiedene Phasen Vorbereitung, Informationsbeschaffung und Informationsauswertung, Bewertung der Informationen mit Risikoanalyse, das aktive Eindringen in ein System sowie die Abschlussanalyse (2011, S. 17-19).

2.2 Smart Home Komponenten

Um in das Thema Smart Home einzusteigen wird hier der Aufbau eines Smart Home vorgestellt.

2.2.1 Aufbau und Architektur eines Smart Homes

Durch das Internet der Dinge (IoT) wird es möglich, dass sich physische Geräte mit dem Internet verbinden und dem Menschen somit innovative und intelligente Dienste anbieten. Dies können intelligente Lichtschaltungen oder auch Haushaltsgeräte sein (Ali, Dustgeer, Awais, & Shah, 2017). In Abbildung 1 ist ein exemplarisches Smart Home dargestellt. Unter anderem beinhaltet ein Smart Home intelligente Steckdosen, Lichter, Türschlösser oder Home Entertainment. In Kapitel 2.2.2 werden die Anwendungsfelder näher erläutert. In der Regel werden die verschiedenen Komponenten über ein Smart Home Hub beziehungsweise Gateway gesteuert. Über Notebooks oder Smartphones kann mit dem Hub, den Aktoren oder den Sensoren kommuniziert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Exemplarische Darstellung eines Smart Home (Quelle: Ali et. al. (2017))

Das Basis-Architekturmodell eines Smart Home beinhaltet in der Regel drei Architekturschichten. Die Wahrnehmungsschicht (perception layer), die Netzwerkschicht (network layer) und die Applikationsschicht (application layer) (Yassein et al., 2019). In jeder dieser Schichten können Sicherheitslücken entstehen. Die Wahrnehmungsschicht beinhaltet Sensoren, die Daten aufnehmen und diese dann über die Netzwerkschicht an die Anwendungsschicht weiter gibt. In der Netzwerkschicht kommen verschiedene Protokolle wie zum Beispiel Z-Wave oder Zigbee zur Anwendung. Die Anwendungsschicht bildet die Schnittstelle zum Menschen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Smart Home Architektur Modelle ( Quelle: Eigene Darstellung in Anlehnung an a) James (2020) und Yassein et. al. (2019) sowie b) Al-Fuqaha et al. (2015))

Allerdings reicht das Basismodell nach heutigen Stand nicht mehr aus, da auch Berichte und Analysen erstellt werden sollen (Al-Fuqaha et al., 2015). Dafür wurde ein fünfschichtiges Modell für eine Architektur entworfen. Die unterste Schicht beinhaltet die Aktoren und Sensoren. Diese werden weiter an die Objektabstraktionsschicht gegeben. In dieser Schicht befinden sich die Protokolle zur Übertragung der Daten an die Dienstverwaltungsschicht, die die Objekte dann heterogen abbildet. Aufgesetzt auf die Dienstverwaltungsschicht ist die Anwendungsschicht. Hier kommuniziert der Anwender mit dem System und bekommt angebotene Dienste zu Gesicht. Als allerletztes kommt die Business (Management)-Schicht. Hier werden Graphen und Analysen erstellt. Abbildung 2 stellt beide Schichtmodelle dar. Diese Arbeit setzt auf das Basismodell auf, da die sicherheitsrelevanten Schichten die Wahrnehmungsschicht, Anwendungsschicht und die Netzwerkschicht betrifft.

2.2.2 Anwendungsfelder

Um einen Überblick über die Einsatzgebiete von Smart Home Anwendungen zu gewinnen, werden hier die klassischen Anwendungsgebiete dargestellt. Wisser gibt in ihrem Buch (2018, S. 12) die folgenden Anwendungsgebiete an:

- Verschattung
- Klimatisierung
- Beleuchtung
- Stromkreissteuerung
- Sicherheitsfunktionen

Zusätzlich zu diesen klassischen Bereichen beschreibt Wisser noch erweiterte Anwendungsfelder (2018, S. 13):

- Erweitertes Energiemanagement
- Multimedia und Unterhaltung
- Assistenzfunktionen für hilfsbedürftige Menschen (AAL)

Ausgewählte Felder sollen nun weiter Erläutert werden.

2.2.3 Verschattung

Hier geht es um die Automatisierung von Rollläden oder Jalousien (Wisser, 2018, S. 16-17). Aus energietechnischen- oder Komfort-Gründen werden diese automatisiert. Zum Beispiel können bei zu viel Sonneneistrahlung die Rollläden einzeln oder kombiniert heruntergefahren werden. Bei anbrechendem Tageslicht wird die Verschattung aufgehoben um durch Tageslicht künstliche Lichtquellen ausschalten zu können. In Abhängigkeit der Uhrzeit werden Rollläden hoch oder heruntergefahren. Auch kann wetterabhängig agiert werden. Zum Schutz vor Glasschäden können die Rollläden zum Beispiel bei Hagel heruntergelassen werden.

2.2.4 Klimatisierung

Zur Klimatisierung gehört die Steuerung der Heizung und der Klimaanlage (Wisser, 2018, S. 1314). Durch diese Steuerung können die Raumtemperaturen exakt eingestellt werden. Auch sind zeitabhängige Steuerungen möglich. Auch der Komfort spielt hier eine Rolle, da sich der Betreiber der Heizungsanlage durch die Automatisierung zum Beispiel beim Öffnen eines Fensters nicht um die Abschaltung der Heizung zu kümmern hat, was ihm händische Arbeit spart. Zusätzlich lassen sich dadurch Energieeinsparungen ermöglichen.

2.2.5 Beleuchtung

Durch eine intelligente Steuerung des Lichts lassen sich trotz des Einsatzes von LED‘s weitere Einsparungen tätigen (Wisser, 2018, S. 15-16). Licht muss nicht mehr manuell geschaltet werden, sondern kann zeitabhängig oder auch in Abhängigkeit von anderen Faktoren wie insbesondere Bewegung ein- oder ausgeschaltet werden. Wie schon im Kapitel über die Verschattung beschrieben, lassen sich Aktivitäten mit der Beleuchtung kombinieren. Auch in Kombination mit einer Stromkreissteuerung lassen sich Beleuchtungen automatisieren.

2.2.6 Stromkreissteuerung

Zu dieser Kategorie gehören schaltbare Leuchtmittel oder Steckdosen. Steckdosen können als Zwischenstecker oder auch als festinstallierte Variante realisiert werden. Im Wesentlichen ist das Ziel, Geräte ohne eigene Smart Home Fähigkeiten an- oder auszuschalten. Nach Aschendorf (2014, S. 1021-1022) werden Geräte in „braune" und „weiße" Haushaltsgeräte eingeteilt. Braune Geräte sind zum Beispiel Geräte der Unterhaltungselektronik. Weiße Geräte dagegen sind Geräte, die man in der Küche oder im Hauswirtschaftsraum findet. Dazu gehören Kühlschränke oder auch Waschmaschinen. Allerdings muss man auch die Sinnhaftigkeit im Auge behalten. Das automatische Anschalten eines Herdes macht nur Sinn, wenn das restliche Umfeld auch vorbereitet ist. Weiter ist auch das unbeobachtete Kochen in Frage zu stellen.

2.2.7 Sicherheitsfunktionen

Sicherheitsfunktionen dienen in der Regel der Gebäudesicherheit (Aschendorf, 2014, S. 26-27). Im Wesentlichen geht es darum, Sensoren auszuwerten. Dazu zählen zum Beispiel der Einbruchschutz oder auch Brandmeldeanlagen. Auch die Auswertung von Webcams zählt zu den Sicherheitsfunktionen. Durch Fenster- und Türkontakte kann ermittelt werden, ob sich der Zustand der Position geändert hat. Darauf kann ein Aktor angesprochen werden, der dann eine Aktion auslöst, zum Beispiel eine Dunstabzugshaube, die nur angeschaltet werden kann, wenn ein Fenster geöffnet ist. Auch lassen sich diese Meldungen dazu nutzen, um Energie einzusparen. Ein geöffnetes Fenster kann zum Beispiel das Ventil eines Heizungskörpers steuern. Nach Aschendorf sind hier einige Beispiele für Sicherheitsfunktion gelistet (Aschendorf, 2014, S. 27):

- Brandmeldung
- Meldung von Wasserlecks und Überschwemmung
- Meldung von Überhitzungen
- Automatische Meldung der Öffnung von Fenstern

2.3 Übertragungswege

Hier werden klassische Übertragungsmedien für Smart Home Komponenten dargestellt. Leider gibt es nicht nur einen Anbieter und auch keinen von allen eingehaltenen Standard. Dies macht es erforderlich, dass für die verschiedenen Übertragungswege verschiedene Gateways benutzt werden müssen (Aschendorf, 2014, S. 71) um die verschiedenen Medien miteinander zu verbinden.

2.3.1 Drahtgebundene Übertragung

Bei drahtgebundenen Systeme kommt es auf die Art der Leitung an. Es gibt Systeme, die eine vieradrige Twisted-Pair-Verkabelung einsetzten. Hier werden allerdings nur zwei Adern der Leitung benötigt. Andere Systeme nutzen zwei Adern für die Datenübertragung und die anderen beiden Adern für die Stromversorgung. Je nach zu übertragender Frequenz werden abgeschirmte oder nicht abgeschirmte Leitungen verwendet. Weiter gibt es Systeme die als Powerline-Variante ausgelegt sind und existierende Strom-Leitungen mit nutzen können. Drahtbasierte Lösungen sollten funkbasierten Lösungen immer vorgezogen werden, da die Sicherheit der Datenübertragung nicht durch Reflexion oder Dämpfung beeinflusst wird (Aschendorf, 2014, S. 51-52).

2.3.2 Funkübertragung

Funkbussysteme dienen in erster Linie der einfachen Nachrüstung in Gebäuden. Sie werden nicht verkabelt und sie sind teilweise batteriebetrieben oder greifen auf Photovoltaikzellen oder elektrodynamische oder piezoelektrische Effekte zurück. Die Frequenzen des ISM-Bandes werden genutzt. Diese sind 433 MHz (433,05-434,79 MHz) und 868 MHz. Für das 433 MHz ISM-Band gibt es keine Begrenzung in spektraler oder zeitlicher Hinsicht, dadurch ist eine permanente Übertragung möglich. Für das 868 MHz Band gibt es Beschränkungen. Das Band ist in Bereiche unterteilt, die für bestimmte Nutzungen freigegeben sind. Eine gegenseitige Störung soll ausgeschlossen werden. Die Sendeleistung und die zeitliche Nutzung der Subbänder sind unterschiedlich. Beim Einsatz von Funkbussysteme ist auch auf die Versendung, Verfügbarkeit und Auswertung von Rückmeldungen zu achten. Wenn ein unidirektionales Funkbussystem keine Rückmeldung an den Sender sendet, so sendet dieser die Anforderung nochmal und es kommt zu einer starken Belastung des Übertragungsbandes (Aschendorf, 2014, S. 52-54). Abbildung 3 zeigt einen generischen Funkbusaufbau.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Generischer Aufbau eines Funkbussystems (Quelle: Eigene Darstellung)

Bei Betrachtung der Sicherheit der verschiedenen Protokolle, stellt sich heraus, dass trotz Verschlüsselung Sicherheitslücken entstehen können. So ist zum Beispiel beim ZigBee-Standard bekannt, dass ZigBee-Netzwerksschlüssel-Sniffing, Sabotage von ZigBee-Endgeräten und Denial-of-Service (DoS) sowie Replay-Angriffe möglich sind (Wara & Yu, 2020).

Tabelle 1 gibt einen Überblick auf verschiedene Funkbussysteme.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Übersicht Funkstandards (Quelle: Klein (2020) und Ohland (2013))

Das KNX-RF System bietet von Grund auf keine Verschlüsselung. Mit der Erweiterung KNC-Data- Security wurde eine 128-bit- AES-CCM Verschlüsselung, Authentifizierung und Integritätsprüfung eingeführt, sowie eine Sequenznummer als Zähler der Datenpakete (Marksteiner, Exposito Jimenez, Valiant, & Zeiner, 2017). Allerdings ist dieser Verschlüsselungsstandard in weniger als einem Prozent der Geräte implementiert (Grohmann, 2020). Z-Wave bietet mit einem Security-Layer Schutz vor Vertraulichkeit, Authentifizierung und Replay-Attacken, der in zwei Sicherheitsklassen eingeteilt ist. Security 0 (S0) beinhaltet eine leichte Sicherheit und Security 2 (S2) ist für stärkere Sicherheit. Die Sicherheitsklasse S0 ist für Legacy-Geräte gedacht, die keine S2 Verschlüsselung erzwingen können. Alle Klassen haben aber eine AES-128 -Verschlüsselung (Marksteiner, Exposito Jimenez, Valiant, & Zeiner, 2017). Allerdings hat die Hochschule Emden eine Sicherheitslücke in der Security Klasse S2 festgestellt (Grohmann, 2020). EnOcean bietet Authentifizierung, Integritätsprüfung, Verschlüsselung und einen Wiedergabeschutz an. Zur Verschlüsselung stehen das AES-CBC- und das variable AES (VAES) -Verfahren zur Verfügung. Von der Verwendung des AES-CBC-Verfahren wird in der Literatur abgeraten, da ein konstanter Initialisierungsvektor benutzt werden, der als unsicher gilt (Marksteiner, Exposito Jimenez, Valiant, & Zeiner, 2017). Das DECT-ULE Verfahren ist eine Erweiterung des DECT-Standards, der ebenfalls mit 128-bit AES verschlüsselt wird. DECT selbst wird nur mit 64-bit verschlüsselt (Metropolis International Group Ltd., 2015). HomeMatic IP ist ein proprietäres Protokoll, das nicht unverschlüsselt betrieben werden kann. Es ist zur derzeit in Deutschland das einzige Protokoll, das vom VDE zertifiziert wurde (Grohmann, 2020).

2.3.3 WLAN und Bluetooth

Die beiden Standards WLAN und Bluetooth werden separat erwähnt, da sie nicht über den gleichen Weg wie die im vorherigen Kapitel beschriebenen Funkstandards in ein Smart Home System eingebunden werden. WLAN-Komponenten werden über einen Access Point in das Netzwerk eingebunden und nutzen somit als TCP/IP für die Verbindung zum Smart Home System. Bluetooth Geräte brauchen ebenfalls ein eigenes Gateway um in das System eingebunden zu werden (Aschendorf, 2014, S. 56-57). Tabelle 2 (Klein, 2020) stellt die Charakteristiken von WLAN und Bluetooth gegenüber. Die WLAN-Verschlüsselung hat sich über mehrere Stufen entwickelt. Die erste Stufe war der WEP Standard, der als absolut ungenügend betrachtet wird. Dieser wurde vom WPA Standard abgelöst, der allerdings abwärts kompatibel ist. WPA arbeitet mit dem Temporal Key Integrity Protocol (TKIP) für die Sicherheit, das auch als ungenügend gilt. Der heutige WPA 2 Standard unterstützt das Protokoll „CounterMode/CBC-MAC Protocol (CCMP)" für die Sicherheit, das AES für die Verschlüsselung nutzt (Adnan et al., 2015). Zur Authentifizierung wird ein Pre-Shared-Key-Verfahren genutzt. WPA 2 gilt mit einem starken Passwort als weitestgehend sicher (Schmitz, 2018). Allerdings wurde in 2017 eine Schwachstelle in WPA 2 bekannt, in der es möglich ist, dass nach der Attacke Daten unverschlüsselt übertragen werden (Westhoff, 2020, S. 66-72).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Übersicht drahtlose Verbindungen (Quelle: Klein (2020))

2.4 Systemstrukturen

Es gibt verschiedene Systemstrukturen, um Smart Home Komponenten zu verbinden. Man unterscheidet hauptsächlich zwischen einer zentralen Struktur und einer dezentralen Struktur.

2.4.1 Zentrale Struktur

Bei einer zentralen Struktur steht eine Zentrale in der Mitte zwischen alle Sensoren und Aktoren. Der Nachteil einer solchen Struktur ist die Anfälligkeit der Zentrale. Wenn sie gestört ist, kann dies den Ausfall des gesamten Systems zur Folge haben (Aschendorf, 2014, S. 42). Als Vorteil kann gewertet werden, dass nahezu jede logische Funktion durch die Zentrale ausgeführt werden kann. Abbildung 4 zeigt ein zentrales System.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Zentrales System (Quelle: Eigene Darstellung in Anlehnung an Aschendorf (2014, S. 43))

2.4.2 Dezentrale Struktur

Dezentrale Systeme kommunizieren untereinander ohne eine Zentrale. Dafür ist es erforderlich, dass jedes Gerät eine eigene Intelligenz besitzt. Dies macht die Komponenten teurer (Aschendorf, 2014, S. 44). Ein großer Nachteil eines solches System ist die verteilte Intelligenz. Es ist nicht nur ein Gerät, was die Logik beinhaltet. Als Vorteil wird hier gewertet, dass der Ausfall einzelner Komponenten nichts das gesamte System nicht zum Erliegen bringt (Aschendorf, 2014, S. 45). In Abbildung 5 ist die dezentrale Struktur zu ersehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Dezentrales System (Quelle: Eigene Darstellung in Anlehnung an Aschendorf, 2014, S. 44)

2.4.3 Halbzentrale Struktur

Halbzentrale Systeme sind Mischformen. Dabei werden zentrale Systeme mit dezentrale Systemen kombiniert (Wisser, 2018, S. 31). Dies ist ein guter Kompromiss, um die jeweiligen Nachteile der Systeme zu reduzieren.

2.5 Generische Smart Home Protokolle der Anwendungsschicht

Zur Zeit gibt es im Bereich Smart Home kein Standard-Protokoll (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Allgemein Protokolle in der Anwendungsschicht (Quelle: Andrea, Chrysostomou, & Hadjichristofi, 2015)

Es gibt aber einige Protokolle, die häufig Anwendung und einen de-facto Standard bilden. Sie werden in diesem Kapitel vorgestellt. Tabelle 3 gibt einen ersten Überblick.

2.5.1 Constrained Application Protocol (CoAP)

Das CoAP Protokoll wurde für ressourceneingeschränkte Geräte entworfen. Es ermöglicht das automatsche Interagieren zwischen IoT-Geräten. CoAP-Clients können selbstständig Dienste und Ressourcen in ein IoT-Netzwerk finden. Dies ist bedeutsam in der machine-to-machine Kommunikation. Eine kryptographische Absicherung für CoAP ist das Datagram Transport Layer Security (DTLS) Verfahren. Hier können Daten verschlüsselt übertragen werden (Wendzel, 2018, S. 320324).

2.5.2 Message Queue Telemetry Transport Protocol (MQTT)

Das Protokoll Message Queuing Telemetry Transport (MQTT) wird ebenfalls zur machine-to-ma- chine Kommunikation eingesetzt. Es unterscheidet sich zum CoAP-Protokoll darin, dass es keine 1:1 Beziehung, sondern eine 1:n Beziehung zu den Komponenten gibt. Das MQTT-Protokoll setzt auf TCP auf und ist ein sogenanntes Publish-Subscribe-Verfahren. Publisher senden Daten, genauer gesagt Themen, an Geräte. Ein Broker empfängt die Daten und stellt diese Daten anderen Geräten zur Verfügung, die diese Themen abonniert haben. Die Abonnenten sind die Subscriber. Ein Publisher und ein Subscriber müssen sich nicht untereinander kennen. Zur Absicherung des Dienstes wird TLS vorgeschlagen (Wendzel, 2018, S. 324-325).

2.5.3 HTTP

Das HTTP-Protokoll ist eines der am weitesten verbreiteten Protokolle im Internet und steht deshalb oft im Fokus von Angriffen. Es wird hauptsächlich zur Übertragung von Webseiten benutzt (Wendzel, 2018, S. 54-55). Auch im IoT-Bereich findet das Protokoll Anwendung um Geräte zu steuern. Um das Protokoll abzusichern kann im ersten Schritt eine Verschlüsselung des Protokolls (HTTPS,SSL) unternommen werden. Um das HTTP-Protokoll weiter abzusichern, können die Methoden PUT, TRACE, CONNECT und DELETE abgeschaltet werden (Wendzel, 2018, S. 264). Aktuell ist das HTTP-Protokoll in der Version 2 verfügbar (Wendzel, 2018, S. 58). Allerdings muss man davon ausgehen, dass IoT-Geräte nicht immer die aktuellste Version implementiert haben und Fehler in der Implementierung des Protokolls bei IoT-Geräten nur selten durch Updates behoben werden.

2.6 Bekannte Angriffstechniken

Wie bereits erläutert besteht ein Smart Home aus mehreren Schichten. Jede dieser Schichten bietet verschiede Angriffspunkte für Hacker. Wichtig ist zu erkennen, wo diese Schwachstellen liegen (James, 2019). In der Wahrnehmungsschicht sind Sicherheitsprobleme dadurch gekennzeichnet, dass sich die Topologie ändern kann und man darauf reagieren muss. Es kann zu „Code-Injection" Angriffe kommen (Yassein et al., 2019). Smart Home Systeme bieten große Angriffsflächen. Gerade veraltete Anwendungen haben Schachstellen durch nicht aktualisierte Software. Angriffe können aus dem internen oder dem externen Netzwerk stammen. Deshalb ist es wichtig, dass ein Smart Home von intern und extern geschützt wird (James, 2019). Die meisten IoT Smart Home Geräte sind im lokalen Netzwerk und in der Wahrnehmungsschicht Cyberangriffen ausgesetzt (James, 2019). Zwischen dem Smart Home Gateway und dem öffentlichem Netzwerk in der Netzwerkschicht sind Sicherheitsrisiken meist authentifizierungsbasiert (James, 2019). Weitere Sicherheitsprobleme der Netzwerkschicht sind zum Beispiel das Handhaben von großen Datenmengen, die dann zu einer Überlast des Netzwerks führen (Yassein et al., 2019). Es können auch Vertraulichkeitsprobleme zwischen IoT Geräten und der Anwendungsschicht (James, 2019) auftreten, wenn Kriminelle IoT Geräte abhören. Hier kann es vorkommen, dass ein Gerät durch einen Hacker kompromittiert ist. Dies gilt es zu erkennen, da von diesem Gerät andere Geräte in Mitleidenschaft gezogen werden können (Yassein et al., 2019).

Generell können Angriffe auf IoT-Geräte in vier verschiedene Klassen unterteilt werden: Physische, Netzwerk-, Software- und Verschlüsselungsangriffe. Eine Auswahl der Angriffe wird nachfolgend dem Architekturmodell zu geordnet. Dazu werden zuerst Angriffe in der Wahrnehmungsschicht betrachtet. Sie konzentrieren sich auf Hardwaregeräte. Der Angreifer muss dazu vor Ort sein (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Hijacking:Hier geht es darum, dass ein Knoten feindlich übernommen wird. Der Angreifer bekommt die Kontrolle über den Knoten und kann schadhaften Code ausführen. Es ist auch möglich, von diesem Knoten aus weitere Knoten zu übernehmen. Schwerwiegend wird es, wenn die Übernahme des Master- oder Basisknoten kompromittiert sind (Mantoro, Ayu, & Mahmod, 2014).

Node Tampering: Hier handelt sich darum, den Knoten zu manipulieren. Das kann durch teilweisen oder vollen Austausch der Hardware geschehen. Ein Angreifer könnte sich dadurch Zugang zu gemeinsam genutzten Schlüsseln verschaffen (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Malicious Node Injection: Ein Angreifer schleust einen neuen bösartigen Knoten zwischen zwei oder mehr Knoten in das bestehende IoT-System ein, um damit den ganzen Datenfluss zu kontrollieren. Dies entspricht einem Man-in-the-Middle Angriff (Andrea, Chrysostomou, & Hadjichristofi, 2015) auf physischer Ebene.

Malicious Code Injection: Der Angreifer implementiert bösartigen Code in einen Knoten, der ihm dann Zugriff auf das IoT-System verschafft. Eine Möglichkeit könnte durch das Einführen eines USB- Stick mit schädlicher Software passieren. Dadurch würde der Angreifer die volle Kontrolle über den Knoten erlangen oder darüber möglicherweise sogar über das volle System (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Node Jamming in Wireless Sensor Networks (WSNs): Dieser Angriff stört den Funkverkehr durch Störsignale. Dadurch könnte der ganze Dienst blockiert und außer Funktion gesetzt werden (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Sleep Deprivation Attack: Viele Knoten werden mit Batterien betrieben und gehen in einen Schlafmodus. Der Angreifer verhindert, dass Geräte in diesen Modus gehen können. Somit wird mehr Energie verbraucht und die Geräte werden mit der Zeit ausfallen (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Im Weiteren werden mögliche Angriffe auf die Netzwerkschicht dargestellt, die einen Zugang zum Netzwerk erfordern, der aber nicht zwingend vor Ort erfolgt.

Abhören: Passiver oder aktiver Angriff von außen auf die Sensornetzwerkkommunikation durch einen Angreifer mit dem Ziel, Daten zu stehlen. Ein passiver Angriff ist dabei das unbemerkte Eindringen in das Sensornetzwerk, bei dem Daten gesammelt werden. Ein aktiver Angriff ist dabei eine Manipulation durch Unterbrechen, Stören oder Modifizieren von Netzwerkpaketen. Auch das Einführen falscher Pakete ist möglich (Mantoro, Ayu, & Mahmod, 2014).

Denial of Service (DoS): Hier geht es darum, die Verfügbarkeit des Smart Home Hubs zu stören. Dies geschieht durch einen Überfluss an Daten, der kontinuierlich auf das Ziel gerichtet wird. Der Angriff kann von außen auf das zentrale Gateway gerichtet sein oder intern zwischen den Sensoren oder Aktoren stattfinden. Bei so einem Angriff spricht man von Datenverfügbarkeitsverletzungen (Mantoro, Ayu, & Mahmod, 2014).

Man-in-the-Middle Attack: Der Angreifer schaltet sich über das Netzwerk zwischen zwei Sensorknoten und greift den Datenverkehr ab. Dadurch kann eventuell auch die Kontrolle über den Daten verkehr zustande kommen. Der Unterschied zur Malicious Node Injection besteht darin, dass der Angreifer nicht physisch vor Ort sein muss (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Sinkhole- und Wormhole-Angriffe:

Bei dieser Art von Angriffen wird das Routing verändert. Ein böswilliger Knoten zieht Netzwerkpakete dadurch an, dass er falsche oder qualitativ hochwertigere Routinginformation an seine Nachbarn verbreitet. Bei einer Wurmloch-Attacke geht es darum, Verwirrung im Netzwerk zu schaffen. Datenpakete werden an einem Punk im Netzwerk empfangen und dann an einen anderen Punkt im Netzwerk unbemerkt weitergeleitet. Von da aus werden die Daten dann wieder in das Netzwerk eingespielt (Mantoro, Ayu, & Mahmod, 2014).

Sybil Attack: Ein bösartiger Knoten gibt die Identität eines oder mehrerer Knoten vor. Dadurch werden Informationen an den falschen Knoten gesendet (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Traffic Analysis Attacks: Hier werden vertrauliche Informationen oder andere Daten in einem drahtlosen Netzwerk ausgespäht. Meist versucht ein Angreifer, Information über das Netzwerk zu erhalten, bevor er seinen Angriff durchführt. Dies geschieht oft mit Hilfe von Sniffing-Anwendungen wie Port-Scannern oder Packet-Sniffern (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Als drittes sollen mögliche Angriffe auf die Applikationsschicht beschrieben werden.

Malicious Code Attack: Das IoT-Netzwerk ist in der Regel mit dem Internet verbunden. Der Benutzer der auf dem Smart Home Hub zugreift kann verleitet werden bösartigen Code auszuführen. Dadurch könnte das ganze System ausfallen (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Phishing Attack: Durch Fälschung von Authentifizierungsdaten eine Benutzers erhält der Angreifer Zugang zum System (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Distributed Denial of Service (DDoS):

Hier geht es wie schon weiter oben für DoS-Angriffe beschrieben darum, dass sehr viele Zugriffe gleichzeitig auf ein Gerät einprasseln. Bei DDoS-Angriffe geschieht dies von einer Menge aus verschieden Geräten (Andrea, Chrysostomou, & Hadjichristofi, 2015).

Eine Zusammenfassung der Angriffstechniken ist in Tabelle 4 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Übersicht Angriffe auf IoT-Geräte (Quelle: Andrea, Chrysostomou, & Hadjichristofi, 2015)

2.7 Sicherheitsziele

Zu den fünf wichtigsten Sicherheitszielen (Ali, Dustgeer, Awais, & Shah, 2017) im Smart Home zählen die ...

Authentifizierung: Überprüfung der Identität der kommunizierenden Parteien oder Benutzer. Es wird sichergestellt, wer der Benutzer ist.

Autorisierung: Überprüfung der Zugriffsrechte eines authentifizierten Benutzers zur Nutzung einer Systemressourcen oder Systemfunktion.

Vertraulichkeit: Hier wird sichergestellt, dass nur der authentifizierte Benutzer selbst oder ein von ihm autorisierter Benutzer auf seine privaten Daten zugreifen kann.

Integrität: Überprüfung und Sicherung, dass die Daten konsistent und korrekt sind. Modifikation und Verlust von Daten sollen bemerkt werden.

Verfügbarkeit: Sicherstellung, dass jeder autorisierte Benutzer Dienste und Ressourcen immer zur Verfügung hat und diese gegen Bedrohung geschützt sind.

Die Sicherheitsziele Verfügbarkeit, Integrität und Vertraulichkeit werden in das Modell übernommen.

2.8 Rahmenbedingungen

Zu den Rahmenbedingungen für das nachfolgende Design eines sicheren Smart Home Netzwerks gehören die folgenden Punkte:

- Der Smart Home Hub soll von außen und aus dem privaten Netzwerk erreichbar sein.
- Die Kommunikation mit dem Smart Home Hub darf nur per HTTPS- oder SSH-Protokoll erfolgen.
- Datenfluss aus Richtung des Smart Home Hubs in Richtung des privaten Netzwerkes ist nicht erlaubt.
- Smart Home Komponenten können Funkbus-, LAN- oder WLAN-Komponenten sein.
- Funkbus-Komponenten müssen die Möglichkeit haben eine verschlüsselte Kommunikation aufzubauen.
- Die Kommunikation zwischen WLAN-Komponenten und Smart Home Hub muss verschlüsselte sein.
- Der Smart Home Hub soll die Möglichkeit bieten Systeme verschiedener Anbieter einbinden zu können.

2.9 Sicherheitsbewusstsein

Einer Studie von Trend Micro zur Folge (Böttcher, 2018), sind 86 % der Teilnehmer der Meinung, dass das Sicherheitsbewusstsein für IoT-Geräte gesteigert werden muss. So sind viele Angriffe auf IoT-Geräte nur erfolgreich, weil ein mangelndes Bewusstsein für Sicherheit vorherrscht. Dies hat zur Folge, dass Sicherheitsbedürfnisse nicht vollständig definiert werden. Insbesondere im IoT-Bereich ist dies zu beobachten.

3 Design eines sicheren Smart Homes

3.1 Gegenstand der Untersuchung

In dieser Arbeit geht es darum zu erarbeiten, ob es ein generisches Modell gibt, dass für den Aufbau eines sicheren Smart Homes genutzt werden kann. Da es sehr viele Smart Home Komponenten gibt, wird diese Arbeit auf grundlegende Komponenten reduziert. Wie in Kapitel 2.2.1 erwähnt, ist ein Smart Home in drei Schichten einzuteilen. Es soll untersucht werden, ob es auf jeder dieser Schichten die Möglichkeit zu einer sicheren Lösung gibt. Deshalb werden die folgenden Perspektiven betrachtet:

- Perspektive der Wahrnehmungsschicht
- Perspektive der Netzwerkschicht
- Perspektive der Anwendungsschicht

Die Perspektive der Anwendungsschicht stellt den Zugriff auf das Smart Home Gateway dar. Der Anwender kann entweder über eine Anwendung außerhalb des internen Netzwerks auf die Zentrale zugreifen oder sich innerhalb des internen Netzwerkes befinden. Abbildung 6 stellt dies dar.

Aus Perspektive der Wahrnehmungsschicht geht es darum, die gewonnenen Informationen an die Zentrale zu senden oder Aktoren zu steuern. Die Sensoren und Aktoren werden über eine Schnittstelle (Middleware oder Bridge) an den Smart Home Hub angebunden, wenn es sich um Komponenten handelt, die zum Beispiel über ein Funkbussystem kommunizieren. Weiter gibt es IoT-Geräte, die über WLAN angebunden werden. Meist kommunizieren diese Geräte dann über das HTTP-Protokoll mit dem Smart Home Hub. Eine exemplarische Darstellung wird in Abbildung 7 gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Exemplarische Darstellung der Anwendungsschicht (Quelle: Eigene Darstellung)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Exemplarische Darstellung der Wahrnehmungsschicht (Quelle: Eigene Darstellung)

Die Perspektive der Netzwerkschicht betrachtet die ankommenden und abgehenden TCP/IP Verbindungen des Smart Home Hubs. Der Smart Home Hub wird in der Regel hinter einer Firewall betrieben. Somit ist die Aufgabe der Netzwerkschicht die eingehenden Verbindungen aus der Cloud weiter an den Smart Home Hub zu leiten. Zusätzlich gehen vom Smart Home Hub auch Verbindungen ab, die Geräte per LAN/WLAN an den Hub anbinden. Dies ist in Abbildung 8 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Exemplarische Darstellung der Netzwerkschicht (Quelle: Eigene Darstellung)

Es soll ein Modell aufgebaut werden, das für die drei Perspektiven Lösungen bietet. Dabei liegt der Fokus auf der Wahrung der Vertraulichkeit, der Verfügbarkeit und der Integrität. Die Autorisierung und Authentifizierung gehen in den drei vorher genannten Zielen mit auf. Als Basis dient das Model von Mantoro, Ayu, & Mahmod (2014), das darauf abzielt, mit einem Smartphone ein Smart Home zusteuern. Dieses Modell wird aufgegriffen und entsprechend abgewandelt. Es wird in Abbildung 9 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Modell von Mantoro, Ayu, & Mahmod (2014) (Quelle: Eigene Darstellung in Anlehnung an Mantoro, Ayu, & Mahmod, 2014)

Da im Rahmen der vorliegenden Arbeit nicht alle Komponenten eines Smart Home untersucht werden können, werden drei Szenarien herausgestellt:

Szenario 1: Zugriff auf die Zentrale von außen. Hier soll ein Modell erzeugt werden, was den Zugriff auf die Zentrale so beschränkt, dass nur ein autorisierter Benutzer Zugriff auf die Zentrale hat. Die Daten dürfen auf dem Weg zur Zentrale nicht kompromittiert werden, dass bedeutet, dass hier die Vertraulichkeit gewahrt werden muss.

Szenario 2: Gesicherter Zugriff auf Smart Home Komponenten, die über WLAN an die Zentrale angeschlossen sind. Die Daten dürfen nicht abgehört werden. Die Komponenten im WLAN dürfen nicht kompromittiert werden.

Szenario 3: Updates der Komponenten sollen reibungslos funktionieren. Dafür muss die Kommunikation von innen nach außen offen sein. Umgekehrt darf dadurch kein Sicherheitsproblem entstehen.

Das BSI (Bundesamt für Sicherheit in der Informationstechnik, o.J.) hat acht Richtlinien für den Betrieb eines Smart Home herausgegeben, die ebenfalls angewendet werden sollen:

- Aktuelle Software und Sicherheitsupdates
- Zentrale Firewall und Routersicherheit
- Keine Standardpasswörter verwenden
- Verschlüsselte Kommunikation und lokale Nutzung
- VPN einrichten
- Separates Heimnetz
- Physikalische Sicherheit
- Bewusster Einsatz von IoT-Geräten

Aus den angesprochenen Perspektiven, den Szenarien und den vom BSI angegebenen Richtlinien soll ein Modell entwickelt werden. Dazu wird ein Testaufbau benötig, der in den folgenden Kapiteln detailliert beschrieben wird.

3.2 Entwicklung des Modells

Um die Lösung zu erarbeiten, wird ein Testszenario aufbaut. Dieses Szenario wird hier beschrieben.

3.3 Physikalischer Testaufbau des Modells

Um die theoretische Untersuchung dieser Arbeit in der Praxis nachvollziehen und überprüfen zu können, wird ein Testszenario aufgebaut. Das Design des Aufbaus wird in Abbildung 10 dargestellt. Im Wesentlichen setzt sich der Testaufbau aus verschiedenen Aktoren, einem Sensor, einer Funkbus-Bridge, einem WAN-Gateway und der Kernkomponente, dem Smart Home Hub, zusammen. Die einzelnen Komponenten werden nach der Abbildung detaillierter erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Physikalischer Testaufbau (Quelle: Eigene Darstellung)

3.3.1 Die Kernkomponenten

Der wesentliche Kern des Aufbaus ist ein Raspberry Pi Modell 3B+ (Raspiberry, o.J.). Ein Gerät dieser Art eignet sich sehr gut, um Testszenarien darzustellen. Das Gerät hat genug Leistung, um ein Smart Home aufzubauen. In diesem Szenario werden zwei Raspberry Pi’s benutzt, einer als Smart Home Hub und einer als Ersatz einer HomeMatic Central-Control-Unit (CCU) zur Anbindung von Funkbus-Komponenten des Unternehmens eQ-3 an den Smart Home Hub. Dies wird später erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Raspberry Pi Modell 3b+ (Quelle: Raspberry.org)

3.3.2 Funkbus-Anbindung

Um Komponenten per Funkbus anzusteuern, muss es ein Gateway geben. Hierzu wird ein zweiter Raspberry Pi eingesetzt der zusammen mit dem Funkmodul (RPI-RF-MOD) und der Software Rasp- berryMatic ein Gateway für die Funkbus-Anbindung sorgt. Das Funkmodul wird auf die GPIO Steckleise des Raspberry Pi montiert.

3.3.3 Aktoren

Um Smart Home Komponenten zu steuern, werden drei Aktoren des Herstellers eQ-3 verwendet. HomeMatic und HomeMatic IP sind die hier verwendeten Marken der eQ-3 AG. Die in dieser Arbeit benutzten HomeMatic-Komponenten sind zwei Rollladen-Aktoren, ein Außenthermostat und ein Funkdimmer. Als HomeMatic IP-Komponente dient eine Steckdose.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: HomeMatic und HomeMatic IP Aktoren (Quelle: ELV Webseite, de.elv.com)

Des Weiteren wird eine schaltbare WLAN-Steckdose der Firma Allterco Robotics Ltd., Modell Shelly Plug S, eingesetzt.

3.3.4 WAN Anbindung

Um den Testaufbau mit dem Internet zu verbinden wird als Router eine Fritzbox 7490 benutzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Fntzbox 7490 (Quelle: AVM Deutschland, 2021)

Um den als Smart Home Hub agierenden Raspberry Pi mit dem Internet zu vernetzen, wird dessen Ethernet Port an einen Ethernet-Port des WAN-Routers (Fritzbox) angeschlossen.

3.4 Benutzte Software

3.4.1 Das Betriebssystem openHabian

Um den ersten Raspberry Pi zum Smart Home Hub zu machen, wird das openHabian Betriebssystem genutzt. Es handelt sich dabei um ein frei verfügbares Debian-Derivat, das auf einer SD-Karte installiert wird (openHAB, o.J.). Das Betriebssystem unterstützt die 64-Bit-Version des Raspberry Pi. Zusammen mit dem Betriebssystem wird die openHAB-Software vorinstalliert ausgeliefert, die die Software-Basis für die in dieser Arbeit beschriebene Lösung bildet.

3.4.2 Smart Home Hub Software openHAB

Das Kernstück des Smart Home Hubs ist die Software openHAB. Sie läuft als zentrale Komponente im Smart Home. Eine große Stärke von openHAB ist die Herstellerunabhängigkeit. Eine Vielzahl von verschiedenen Komponenten unterschiedlicher Hersteller lassen sich über ein dreischichtiges open- HAB-Modell (Bindings,Things,Items) zu einem Gesamtsystem zusammenfassen. Dadurch ist es möglich, Hausautomatisierungssysteme und Smart Home Komponenten sowie andere Geräte gemeinschaftlich zu steuern. Über eine einheitliche Benutzeroberfläche werden Komponenten eingebunden und gesteuert. Durch Automatisierungsregeln lassen sich Sensoren abfragen und Aktoren schalten. openHAB kann leicht über die Weboberfläche konfiguriert werden, man kann aber für komplexere Einsatzszenarien auch auf Commandline-Ebene arbeiten und eigene Skripte zur Steuerung einsetzen. openhab ist in der Sprache Java geschrieben worden. Erweiterungen werden als Addons eingebunden, die die Kompatibilität zu verschiedenen Smart Home Komponenten herstellen.

openHAB bietet eine physische und eine funktionale Ansicht. Über „Bindings" wird die Kompatibilität zu einer Hardware hergestellt. Dadurch ist es möglich Hardwarekomponenten eines Herstellers in das System einzubinden. Diese Komponenten werden als „Things" in openHAB integriert, die sich noch in einer Abhängigkeit zu einem Hersteller befinden. Dies ist die physische Ansicht. Als nächster Schritt wird die Erzeugung eines „Items" durchgeführt. Ab hier ist eine Komponente als funktionales Gerät sichtbar und hat keine Abhängigkeit mehr zum Hersteller. Abbildung 16 stellt dies dar (openHAB, o.J.).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: OpenHAB Thing/Item Beispiel (Quelle: openHAB.org)

Der Aktor wird als „Thing" in openHAB integriert. Durch zwei Kanäle im Aktor lassen sich zwei Leuchten steuern, die als „Item" in openHAB abgebildet werden.

3.4.3 CCU-Ersatz RaspberryMatic

Um die im Hardware-Kapitel beschriebenen Komponenten des Herstellers eQ-3 für openHAB sichtbar zu machen, wird ein eQ-3 Funkmodul mit einem zweiten Raspberry Pi betrieben. Dazu wird die Software RaspberryMatic genutzt (Raspberrymatic, o.J.). Durch diese Software werden die Home- Matic Komponenten mit den proprietären HomeMatic- und HomeMatic IP- Protokollen in das System integriert. Der Hersteller eQ-3 bietet normalerweise eine proprietäre Steuereinheit mit dem Namen Central-Control-Unit (CCU) an, diese wird in dieser Arbeit durch die RaspberryMatic Lösung ersetzt. RaspberryMatic bietet zwar selbst schon eine vollwertige Steuerung für HomeMatic-Komponenten und könnte somit als Standalone-Lösung eingesetzt werden. Da das Ziel dieser Arbeit aber eine Lösung ist, die verschiedene Hersteller integrieren soll, wird RaspberryMatic hier nur als Bridge eingesetzt, um die eQ-3-Komponenten in das System zu integrieren. Die wesentlichen genutzten Funktionen der Software sind das Pairing und das Patchen der Komponenten mit neuer Firmware, sowie die Umsetzung der Steuerbefehle in die Funk-Technik. Die Sensoren und Aktoren, die über Rasp- berryMatic an den Smart Home Hub angeschlossen, sind kommunizieren über den Funkbus mit der 868 MHz Technik. Dabei agiert RaspberryMatic als Bridge und stellt einen TCP/IP basierten Server zur Verfügung. openHab integriert diese Bridge über das HomeMatic Binding. Daten, die von den Sensoren und Aktoren kommen werden somit in für openHAB lesbare Informationen gewandelt.

3.5 Der Weg zum Modell

Um das Modell zu entwickeln werden die bekannten Angriffsmethoden aus Kapitel 2.6 und die Sicherheitsziele aus Kapitel 2.7 in Betracht gezogen. Wie bereits beschrieben, liegt der Fokus dieses Modells auf der Vertraulichkeit, der Verfügbarkeit und der Integrität. Im Bereich der Verfügbarkeit soll ein Schutz vor DoS- beziehungsweise DDoS-Angriffen entstehen. Dazu soll das Modell eine Möglichkeit schaffen, diese zu limitieren und sogar ganz abzufangen. Um die Vertraulichkeit zu integrieren, soll das Abhören eines Netzwerkes unterbunden werden. Um einem Angreifer keine Möglichkeit zu geben, das private Netzwerk abzuhören, wenn ein Angreifer in das Smart Home Netzwerk eingedrungen ist, ist die Abtrennung des privaten Netzwerkes mit dem Smart Home Netzwerk erforderlich. Dazu wird eine Netzwerkstruktur aufgebaut, die es ermöglicht, diese Trennung zu implementieren. Um die Vertraulichkeit zu gewährleiten, darf zudem der Datenverkehr nicht lesbar sein. Dies beginnt bei den Requests des Smart Home Web-Frontends an und endet beim openHAB-Ap- plikationsserver. Eine Verschlüsselung der entsprechenden Kommunikation ist deshalb erforderlich. Um auf den Smart Home Hub zuzugreifen sollen nur die Protokolle HTTPS und SSH erlaubt sein. Dazu und auch um das Smart Home Netzwerk abzutrennen, ist eine lokale Firewall erforderlich. Somit werden Zugriffe aus dem privaten Netzwerk blockiert. Zugriffe aus dem Internet (WAN) sollen über einen dedizierten Client oder Webbrowser erfolgen, der durch ein virtuelles privates Netzwerk (VPN) gesichert ist, um einen kanalisierten Weg zu definieren. Um diese Anforderungen tiefer zu gestalten, werden im nächsten Kapitel drei Prinzipien definiert.

3.6 Prinzipien

3.6.1 Sicherheit durch Trennung von Smart Home und privaten Netzen

Um Sicherheit in die angestrebte Lösung zu bringen, soll der Datenverkehr bezüglich der Smart Home Komponenten von den privaten Daten streng getrennt werden. Aus Sicht des Smart Home Hubs gibt es nur einen Zugang in Richtung WAN, der durch eine lokale Firewall eingehend und ausgehend geschützt wird. Hinter dieser Firewall wird ein eigenes Netzwerk erzeugt, in dem sich die Smart Home Komponenten und dem Smart Home Hub befinden. Smart Home Komponenten können über drei Wege an den Smart Home Hub angeschlossen werden. Als erster steht ein WLAN Access Point mit eigenem Netzwerk zur Verfügung, weiter können Komponenten über eine LAN- Schnittstelle angeschlossen werden. Funkbus-Komponenten werden über eine Bridge (Gateway) an den Smart Home Hub angeschlossen. Durch dieses Konzept durchläuft jeder Datentransfer den Smart Home Hub. Alle Aktionen können nur durch diesen Hub gestartet werden. Dadurch wird der Datenverkehr kanalisiert und kann somit überwacht werden. Abbildung 17 zeigt das Prinzip.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Prinzip Trennung Smart Home Area vom privaten Netzwerk (Quelle: Eigene Darstellung)

Durch die Firewall im Smart Home Hub wird nur der Datenverkehr zum WAN-Gateway zugelassen. Daten in Richtung des privaten Netzwerks werden geblockt. Das folgende Schaubild stellt den Mechanismus vor.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Firewall-Konzept Trennung internes Netzwerk (Quelle: Eigene Darstellung)

Abbildung 18 stellt die Trennung dar. Die Wahrung der privaten Daten wird durch die 2. Firewall realisiert. Jeglicher Datenverkehr in das interne Netzwerk wird gesperrt.

Die für die Erarbeitung benutzten Netzwerke sind in Tabelle 5 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Benutzte Netzwerke (Quelle: Eigene Darstellung)

3.6.2 Sicherheit durch kanalisierten Zugang zum Smart Hub durch VPN

Um auf den beschriebenen Smart Home Hub von außen zuzugreifen, wird eine Applikation auf einem Smartphone oder ein Web-Frontend im Browser genutzt. Zuerst muss eine VPN-Verbindung bis zum Router aufgebaut werden. Durch diese VPN-Verbindung wird dann der Datentransfer vom Handy oder dem Webbrowser bis zum Router geleitet, der dann die verschlüsselte Verbindung bis zum Webserver auf dem Smart Home Hub weiterleitet. Hier wird die Verbindung entschlüsselt und der Webserver gibt die Daten weiter an die openHAB Software. Es werden keine anderen Wege möglich sein, den Smart Home Hub zu erreichen. Abbildung 19 zeigt den vollständigen Ablauf.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Zugriffsprinzip auf den Smart Home Hub (Quelle: Eigene Darstellung)

Der oben angesprochen Webserver ist als Reverse Proxy vor den eigentlichen Applikation-Server geschaltet. Der Request kommt aus dem WAN über einen VPN-Tunnel bis zum WAN-Gateway. Hier wird der VPN-Tunnel aufgebrochen. Das WAN-Gateway reicht den Request weiter an den Smart Home Hub, der nach Außen nur auf dem verschlüsselten Netzwerk-Port 443 (SSL) horcht. Der Request wird auf dem Hub von einem Reverse Proxy angenommen und von diesem unverschlüsselt an den Applikation-Server (openHAB) weitergeleitet und dort verarbeitet. Abbildung 21 stellt den Ablauf dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: Firewall-Konzept Zugriff auf Smart Home Hub (Quelle: Eigene Darstellung)

Firewall 1: Gateway, eingehende Verbindungen mit VPN-Tunnel

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Firewall Regel auf dem WAN-Gateway

Firewall 2: Firewall auf dem Smart Home Hub

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Firewall Regel auf dem Smart Home Hub

Der in dieser Arbeit als Reverse Proxy verwendete Webserver ist NGINX. Die Konfiguration und die Erzeugung des SSL-Zertifikates des Proxies ist in Anhang 3 ersichtlich. Der Reverse-Proxy ist dem Applikationsserver vorgeschaltet. Durch den Reverse-Proxy ergibt sich unter anderem die Möglichkeit, DoS-Attacken abzufangen (nginx, 2015). Der NGINX Webserver bietet weiter die Möglichkeit über ein Modul (ModSecurity) eine Web Application Firewall (WAF) einzubinden. Damit lassen sich Regeln definieren um bestimmte Inhalte zu filtern um somit die hinter dem Reverse Proxy laufende Applikation zu schützen. Zum Beispiel können Remote Code Execution (RCE) abgefangen werden (NGINX Documentation, 2021). Dadurch kann verhindert werden, dass Angreifer aus der Ferne Änderungen ausführen können. Das Zusammenspiel zwischen Reverse Proxy und Applikationsserver ist in Abbildung 21 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Reverse Proxy Integration (Quelle: Eigne Darstellung)

Die Kanalisierung kommt dadurch zustande, dass Smart Home Komponenten nur durch den Smart Home Hub angesprochen werden können. Das Konzept beruht darauf, dass Komponenten nicht direkt angesprochen werden. In dieser Arbeit wird eine Software (openHAB) als zentrale Instanz eingesetzt, die verschiedene Web Frontends bereitstellt. Außerdem wird auch ein nativer Client als Handy-App bereitgestellt, der eine vom Smart Home Hub bereitgestellte Sitemap auf dem Handy visuell darstellt. Diese Sitemap ist genau auf die zu steuernden Komponenten abgestimmt und diese lassen sich somit schalten oder auslesen. Abbildung 22 zeigt ein Bespiel einer Sitemap. In Anhang 2 ist ein Listing einer Sitemap abgebildet. Im Webbrowser wird die Sitemap als sogenannte Basic- UI dargestellt und kann wie auf dem Handy bedient werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22: Beispiel einer openHAB Sitemap im Android Client (Quelle: Eigene Darstellung) Die Ansicht auf einem mobilen Gerät wird in Anhang 8 gezeigt.

3.6.3 Sicherheit durch gesteuerte Updates

Ein weiteres Prinzip ist die Steuerung für Updates, um diesen Vorgang gezielt beobachten und manuell steuern zu können. Es wird ein Mechanismus deklariert, in dem Updates möglichst nur von Hand angestoßen werden können. Selbstständig durchgeführte Updaten von Smart Home Komponenten sollten möglichst unterdrückt werden. Abbildung 23 stellt dies dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Updateprozess (Quelle: Eigene Darstellung)

Die Aktoren und Sensoren, die über Funk (RF, radio frequency) kommunizieren, sind über eine Bridge an den Smart Home Hub angebunden. Über das Benutzer-Interface der Bridge kann der Update-Prozess gestartet werden. Die Bridge leitet die Daten dann weiter durch den Smart Home Hub, der über die angeschlossene LAN-Schnittstelle Updates aus dem Internet erfragt und gegebenenfalls per Download bezieht. Aktoren und Sensoren, die per LAN oder WLAN an den Smart Home Hub angeschlossen sind, durchlaufen ebenfalls den Smart Home Hub und beziehen ihre Updates in gleicher Art aus dem Internet. Der Smart Home Hub kommuniziert für eigene Updates auch über diesen Weg.

3.7 Das Modell

Nachdem die Vorarbeiten gemacht, die Perspektiven und die Prinzipien definiert, sind, wird jetzt das Modell vorgestellt und beschrieben. Der User greift über eine dedizierte App von seinem Handy oder über einen Webbrowser verschlüsselt und durch einen VPN-Tunnel auf den Smart Home Hub zu. Zuerst passiert der Request das WAN (Internet, Cloud) und erreicht den lokalen Router des Eigentümers, der das Smart Home betreibt. Der VPN-Tunnel wird hier aufgebrochen und der Request wird an den Smart Home Hub per SSL-Verschlüsselung weitergleitet. Auf dem Smart Home Hub ist ein Webserver installiert, der nur auf verschlüsselte Verbindungen horcht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Modell sicheres Smart Home (Quelle: Eigene Darstellung)

Die Verschlüsselung wird hier beendet und der Request wird von dem Webserver über die loopbackAdresse (127.0.0.1) an den Applikations-Server weitergeleitet, der den Request annimmt. Die Applikation ist per User/Passwort geschützt und der User muss sich authentifizieren.

Um die Vertraulichkeit der Daten des Smart Home Betreibers zu schützen werden die Komponenten des Smart Home in einem eigenen Netzwerkaufgebaut. Das Internet-Gateway wird mit einem Router und einer Firewall betrieben. Es muss mindestens ein Patchport am Internet-Router vorhanden sein, um ein Kabel anzuschließen, dass eine Ethernet-Verbindung zum Smart Home Hub bereitstellt. Der Hub stellt per WLAN und LAN getrennte Netzwerke bereit, in dem sich Smart Home Komponenten befinden, die über eine IP-Verbindung kommunizieren. Weiter werden Komponenten per Funk (radio frequency) über eine Bridge angeschlossen. Das komplette Modell ist in Abbildung 24 zu sehen. Das Sicherheitskonzept fußt auf einem kaskadierten Firewall-Modell. Die erste Firewall befindet sich auf dem Internet-Gateway und lässt nur eine verschlüsselte Verbindung auf dem Smart Home Hub zu. Auf dem Smart Home Hub läuft ebenfalls eine Firewall, die nur Verbindungen zulässt, die unbedingt für den Betrieb das Smart Homes erforderlich sind, insbesondere eingehende Requests eigener Web-/App-Frontends und ausgehende Requests für Updates. Abbildung 25 stellt das Firewall-Konzept dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: Generelles Firewall-Konzept (Eigene Darstellung)

4 Forschungsergebnisse der Experimente

4.1 Software zur Designevaluation

Kriminelle nutzen Schwachstellen von Geräten um sich Zugang zu Netzwerken zu verschaffen, und dann Datendiebstähle oder Sabotage zu betreiben. Oftmals ist dies leicht zu realisieren, da Geräte nicht ausreichend geschützt sind. Alte Geräte werden seit Jahren betrieben. Mit der Vernetzung entsteht jetzt eine Gefahr, die es früher nicht gegeben hat. Sicherheitslücken und Betriebssystemschwachstellen entstehen durch nicht ausreichend mit Updates versorgte Geräte. Eine einzelne Schwachstelle kann die Integrität des gesamten Netzwerks in Frage stellen. Ein SchwachstellenManagement wird erforderlich. Schlechte Passwörter oder unsichere Protokolle bieten dabei eine Angriffsfläche für Hacker. Oft werden Ziele in Betracht gezogen, die leicht zu erobern sind. Deshalb sollte bei der Schwachstellenanalyse die Widerstandsfähigkeit der Systeme in Betracht gezogen werden (openvas, 2020). Das erzeugte Modell soll genau diese Schwachstellen abfangen. Um das Modell auf diese Schwachstellen hin zu untersuchen, werden im folgenden Software-Tools beschrieben, die an dieser Stelle hilfreich sind.

4.1.1 Kali Linux

Kali Linux (kali, o.J.) ist eine Linux-Distribution aus dem Haus Offensive Security, die auf Debian Linux aufsetzt. Sie ist auf fortgeschrittene Penetrationstests und Sicherheitsaudits ausgerichtet. Sie enthält mehrere hundert Tools, die für Aufgaben zur Prüfung und Herstellung der Informationssicherheit geeignet sind. Diese sind Penetrationstests, Sicherheitsforschung, Computerforensik und auch Reverse Engineering. Kali -Linux bietet mehr als 600 freie Penetrationstests. Um das Modell zu evaluieren werden verschiedene Tools dieser Suite genutzt.

4.1.2 NMAP

NMAP ist ein Port-Scanner, der offene und geschlossene Netzwerk-Ports erkennt. Damit kann identifiziert werden, ob ein Dienst erreichbar ist oder nicht (Rahalkar, 2019, S. 4-44). Weiter kann ermittelt werden, welche Version einer Software installiert ist. Eine Unterscheidung in TCP und UDP Ports kann getroffen werden. NMAP ist ebenfalls in der Lage durch zusätzliche Software eine Schwachstellenanalyse durchzuführen.

4.1.3 openVAS

Um ein System aktuell zu halten, schlägt das BSI (BSI, 2021) den Open Vulnerability Assessment Scanner (openVAS) vor. Dieser sehr umfangreiche Scanner, ermöglicht authentifiziertes und nicht- authentifiziertes Testen. openVAS ist Teil der Kali Linux Distribution und bietet auch eine Integration verschiedener low- und high-level Internet- und Industrieprotokolle. Außerdem gibt es eine interne Programmiersprache mit der eigene Schwachstellen-Prüfungen entwickelt werden können (BSI, 2021). Auf täglicher Basis werden aktualisierte „Feeds" eingespielt, die die Sicherheitsprüfung aktuell halten. OpenVAS beinhaltet über 50000 Schwachstellentest und Compliance Prüfungen. Er wird unter der GNU General Public License (GNU GPL) frei angeboten. Es ist möglich, dass man im Netzwerk verschiedene Prüftiefen einstellt. Zusätzliche kann weitere Sicherheitssoftware eingebunden werden und es können Prüfberichte und Alarme erstellt werden.

OpenVAS wurde 2008 von der Firma Greenbone Networks GmbH übernommen und weiter entwickelt. Bis heute wird OpenVAS von diesem Unternehmen vorangetrieben (openvas, 2020). Das BSI hat bei einzelnen Funktionen mitgeholfen, diesen Scanner weiterzuentwickeln. Nachfolgend sind ausgewählte Eigenschaften von OpenVAS dargestellt (BSI, 2021):

- Einbindung verschiedener Sicherheitswerkzeuge über entsprechende Schnittstellen und Steuerprotokolle
- Zeitgesteuerte Prüfungen
- Management von Scan-Aufgaben
- Manuelle oder automatische Aktualisierung der Schwachstellen-Prüfroutinen (VTs) über das Internet
- Weit über 50.000 Schwachstellen-Prüfroutinen (VTs) im Community Feed verfügbar
- Security-Scanning von kompletten Netzwerken
- Durchführung authentifizierter Sicherheitsprüfungen
- Ergebnisübersicht mit Filterung und Priorisierung
- Alarmierung bei Richtlinien-Verstoß oder erkannten Schwachstellen
- Delta-Vergleich von Prüfberichten
- Umfangreiche Suchfunktion in Prüfberichten
- Hilfestellungen zu den gefundenen Schwachstellen in den Prüfberichten und über das Internet
- Integration aktueller CVE (Common Vulnerabilities and Exposures) Informationen

4.1.4 Metasploit

Das Framework Metasploit beinhaltet sehr viele Tools die für einen Penetrationstest gebraucht werden. Dieses Framework besteht aus vielen Teilbereichen, Teilprojekten und Modulen. Es wird nicht nur bei Penetrationstests eingesetzt, sondern auch für Sicherheitsforschungen genutzt (Messner, 2011, S. 9).

4.1.5 Snort

Snort wird als freies Network Intrusion Detection System (NIDS) und Network Intrusion Prevention System (NIPS) eingesetzt, das heißt um bekannte Schwachstellen zu erkennen und Laufzeit Protokollanalysen durchzuführen. Im Wesentlichen hat Snort drei Haupteinsatzgebiete. Als Paket-Sniffer, als Paketlogger und eben als vollwertiges Intrusion Detection System (Snort, o.J.).

4.2 Vorbereitung der Schwachstellenanalysen

Das vorgeschlagene Modell soll aus Sicht der drei verschiedenen Perspektiven Anwendungsschicht, Wahrnehmungsschicht und Netzwerkschicht validiert werden. Dies erfolgt in zwei Schritten. Zuerst werden exemplarische Schwachstellen der drei Schichten dargestellt, indem keine Firewall auf dem Smart Home Hub eingesetzt wird. Im zweiten Schritt wird die beschriebene Firewall eingeschaltet und das Modell wird auf Schwachstellen validiert.

Als generelles Vorgehen einer Schwachstellenanalyse werden folgende Phasen durchlaufen (Rahalkar, 2019, S. 2-3):

- Sammeln von Informationen: Ein bedeutsamer Punkt ist die Beschaffung von Information über das zu untersuchende Objekt.
- Herausfinden der Schwachstellen: Nachdem Informationen über das zu untersuchen Objekt bereit stehen, werden die Schwachstellen ermittelt, die für den Penetrationstest gebraucht werden.
- Schwachstellenanalyse: In dieser Phase werden die in der vorherigen Phase ermittelten möglichen Schwachstellen durch Tools validiert.
- Zugang verschaffen: Wenn die Schwachstellen identifiziert sind, kann versucht werden, sich Zugang durch einer dieser Schwachstellen zu verschaffen.
- Eskalierende Privilegien: Zu diesem Zeitpunkt des Penetrationstest kann durch bekannte Sicherheitslücken tiefer in das System eingedrungen werden.
- Aufrechterhaltung des Zugriffs: Nachdem in ein System eingedrungen worden ist, soll die Zugriffsmöglichkeit dauerhaft aufrecht erhalten bleiben.
- Erzeugte Daten aufräumen: Am Ende des Penetrationstest werden angelegte Dateien oder ähnliche Änderungen rückgängig gemacht um das Ursprungssystem wieder herzustellen.

In der folgenden Tabelle sind die Phasen des Penetrationstest und zugehörige Tools dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Phasen des Penetrationstest und Werkzeuge (Quelle: Rahalkar (2019))

Bevor eine Schwachstellenanalyse der einzelnen Schichten stattfinden kann, müssen zuerst Informationen über das Ziel der zu untersuchenden Komponenten gesammelt werden (Rahalkar, 2019, S. 2). Über das definierte Modell ist folgendes bekannt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 9: Übersicht der verwendeten IP's und Schnittstellen der Schwachstellenanalyse (Quelle: Eigene Herstellung)

Auf diese Informationen werden in den Schwachstellenanalyse zurückgegriffen. Für die Untersuchung der Smart Home Komponenten (Wahrnehmungsschicht) ist das Netzwerk an der Schnittstelle wlan0 interessant.

4.3 Schwachstellenanalyse der Wahrnehmungsschicht

Wie aus Tabelle 9 ersichtlich ist, werden Smart Home Komponenten in das Netzwerk 192.168.1.0/24 integriert. Hier müssen jetzt die einzelnen Geräte identifiziert werden. Dazu wird im Betriebssystem des Raspberry PI Smart Home Hubs mit dem NMAP-Kommando das zu untersuchende Netzwerk gescannt. Die Sicherheit in der Netzwerkschicht ist zu diesem Zeitpunkt noch nicht aktiviert, da diese das Ergebnis deutlich beeinflusst.

Abbildung in dieser Leseprobe nicht enthalten

Listing 1: Beispiel Netzwerkscan mit NMAP (Quelle: Eigene Darstellung)

Um jetzt herauszufinden ob ein Gerät anfällig für Attacken sein kann, müssen mehrere Tests durchgeführt werden. Ein Test ist dabei zu schauen, welche Dienste und damit verbunden welche Netzwerk-Ports auf dem Gerät geöffnet sind. Dazu kann wieder das Tool NMAP benutzt werden. Eins der oben beim Netzwerk-Scan identifizierten Geräte soll hier in Listing 2 weiter untersucht werden.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2: Beispiel Portscan eines Hosts mit NMAP (Quelle: Eigene Darstellung)

Wie man deutlich sieht, ist der TCP Port 80 auf dem Gerät geöffnet. Dieser wird in diesem Beispiel zur Steuerung genutzt. Sollten noch weitere Ports erkannt werden, so könnten die Dienste dahinter abgeschaltet werden, wenn sie keinen Mehrwert für das Smart Home System darstellen würden. Dazu muss auf dem jeweiligen Gerät individuell geschaut werden, wie dies zu machen ist. Je nach Betriebssystem oder Firmware ist dies unterschiedlich zu handhaben. Im oberen Beispiel ist, wie schon erkannt, nur der HTTP-Port geöffnet. Dieser wird für die Funktion des Gerätes gebraucht und bietet daher keine Möglichkeit zur Abschaltung.

Nach dem nicht genutzte Dienste abgeschaltet wurden, muss geschaut werden, ob die noch zur Verfügung stehenden Dienste Schwachstellen haben. Dazu dient das openVAS-Framework. Es kann ein Gerät oder auch mehrere Geräte gleichzeitig ausgewählt werden. Hier wird wieder am Beispiel der schaltbaren WLAN-Steckdose geschaut, wo sich Schwachstellen befinden. Die Abbildung 26 zeigt das Ergebnis der Schwachstellenanalyse. Das Tool openVAS stellt die Schwachstellen dar und gibt Hinweise darauf, wie die Schwachstelle geschlossen werden kann. Bei einer schaltbaren Steckdose kann dies in der Regel nur durch ein Firnware-Update geschehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: openVAS Schwachstellenanalyse Ergebnis (Quelle: openVAS results)

In diesem Beispiel ist ersichtlich, dass es Schwachstellen gibt. In Kombination mit dem NetzwerkScan sieht man, dass der HTTP-Dienst ohne Schutz betrieben wird. Dazu wird ein Test im Browser gemacht, ob man die Webseite der WLAN-Steckdose erreichen kann. Dies ist ein Punkt, an dem ein Angreifer sich Zugriff zur Komponente verschaffen kann. Abbildung 27 zeigt die Webseite der WLAN-Steckdose, die ohne weiteres aufgerufen werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 27: Web-Zugriff auf WLAN-Steckdose (Quelle: Eigener Webbrowser)

Anhand von wenigen Schritte kann man sehen, dass hier eine ungeschützte WLAN-Steckdose betrieben wird und es - Zugang zum Smart Home Netzwerk vorausgesetzt - einfach ist, auf die WebOberfläche zu gelangen um die Funktionen der Steckdose zu manipulieren. Um hier eine Attacke zu erschweren bietet die WLAN Steckdose von Allterco Robotics Ltd. die Möglichkeit, einen User mit starkem Passwort zu vergeben. Dies sollte auf jeden Fall gemacht werden. In Kombination mit der WPA2-Verschlüsselung ist dann ein ausreichender Schutz vorhanden. Dies zeigt Abbildung 28.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 28: Passwortschutz der WLAN-Steckdose (Quelle: Eigener Webbrowser)

Um Passwörter sicher zu erzeugen sollten bestimmte Kriterien eingehalten. Auf der DatenschutzWebseite (datenschutz.org, 2018) werden Hilfen dazu bereitgestellt.

4.3.1 Schwachstellenanalyse im Funkbus-System

In dieser Arbeit werden Aktoren und Sensoren über einen Funkbus angesteuert, der sich in der Wahrnehmungsschicht befinden. Um zu untersuchen, wie sich die genutzten Komponenten im Auslieferungszustand verhalten, werden exemplarisch Komponenten der Marken HomeMatic und HomeMatic IP der Firma eQ-3 AG untersucht. Zuerst wird der HomeMatic Standard, der auch als HomeMatic-RF bezeichnet wird und das BidCos-Protokoll nutzt, betrachtet. Dieser Standard kann mit oder ohne Verschlüsselung betrieben werden. Neben diesem Standard bietet die Firma eQ-3 einen weiteren proprietären Standard an, der ein Protokoll beinhaltet, das als IP over BidCos bezeichnet wird. Komponenten mit diesem Standard lassen es nicht zu, unverschlüsselt in Betrieb genommen zu werden. Um zu demonstrieren, dass dies auch wirklich so ist, stellen die folgenden Abbildungen 29 und 30 die Integration von Verschlüsselung in HomeMatic-Komponenten dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 29: RaspberryMatic-System mit HomeMatic-RF Komponenten (Quelle: Eigene Darstellung im Webbrowser)

In diesem Beispiel ist zu erkennen, dass es möglich ist, Komponenten ohne Verschlüsselung zu betreiben. In der Spalte „Übertragungsmodus“ steht der Wert auf „Standard", was gleichbedeutet mit „unverschlüsselt“ ist. Für HomeMatic-Komponenten kann der Übertragungsmodus nachträglich auf „Gesichert“ umgeschaltet werden, was gleichbedeutend mit „verschlüsselt“ ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 30: Einschalten der Verschlüsselung in HomeMatic Komponente (Quelle: Eigene Darstellung im Webbrowser)

Erst nach der Umstellung erfolgt eine gesicherte Übertragung zwischen Aktoren, Sensoren und der Zentrale. Dies zeigt, dass HomeMatic-RF-Komponenten im Auslieferungszustand keinen Verschlüsselungsschutz bieten. Nachfolgend wird eine HomeMatic IP-Komponenten dargestellt. Die Situation von HomeMatik-IP-Komponenten ist von Anfang an anders. Hier gibt es nicht die Möglichkeit eines Betriebes ohne Verschlüsselung. Dies ist in Abbildung 31 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 31: Keine Möglichkeit HomeMatic-IP unverschlüsselt zu Betreiben (Quelle: Eigene Darstellung im Webbrowser)

Hier steht der Wert beim Übertragungsmodus dauerhaft auf „Gesichert. Es besteht keine Möglichkeit diesen Wert umzustellen. Die Kommunikation wird somit immer verschlüsselt übertragen.

4.4 Schwachstellenanalyse der Anwendungsschicht

Die Anwendungsschicht beginnt am Endgerät, dass auf den Smart Home Hub zugreift. Deshalb muss überprüft werden, ob der Zugriff auf das WAN Gateway ausreichend geschützt ist. Zuerst werden offene Ports mit dem Tool NMAP ermittelt. Dazu muss der Scan aus dem Internet heraus gemacht. Abbildung 32 zeigt das Ergebnis.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 32: Port-Scan auf das WAN-Gateway (Quelle: Eigene Darstellung)

Wie man erkennen kann, sind von außen nur zwei Ports geöffnet, die für den Betrieb des Telefonnetzes gebraucht werden. Das HTTP oder HTTPS Protokoll sind nicht freigegeben, was zur Sicherheit beiträgt. Dadurch, dass ein VPN-Tunnel genutzt wird, ist dies nicht erforderlich. Allerdings wird bereits schon beim Client ein verschlüsselter Zugriff auf den Smart Home Hub initiiert. Deshalb wird als nächstes überprüft, ob der Datenverkehr ausreichend verschlüsselt ist. Dazu wird aus der KaliLinux-Suite das Tool SSLYSE benutzt. Hiermit wird überprüft, ob eine SSL-Verbindung ausreichend geschützt ist. Mit dem Kommando sslyze -regular 192.168.2.1 wird der Webserver überprüft.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3: Beispiel Analyse eines SSL-Zertifikats (Quelle: Eigene Darstellung)

Zu erkennen ist, dass der Webserver des Smart Home Hubs mit einem SSL-Zertifikat geschützt ist. Ein voller Auszug des Tests befindet sich in Anhang 5. Nachdem ein Portscan von außen gezeigt hat, dass keine HTTP oder HTTPS Ports auf dem WAN-Gateway offen sind, müssen die NetzwerkPorts auf dem Smart Home Hub selbst überprüft werden. Um dies zu realisieren, erfolgt ein Portscan aus einem der Smart Home Netzwerke in Richtung Smart Home Hub. Abbildung 33 zeigt das Ergebnis. Hier erfolgt die Untersuchung noch ohne Einbeziehung der Sicherheit (Firewall) in der Netzwerkschicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 33: Port-Scan auf den Smart Home Hub (Quelle:Eigene Darstellung)

Man erkennt sehr viele Dienste, die auf dem Smart Home Hub erreichbar sind. Dieser Überblick gibt einem Angreifer die Möglichkeit zu testen, ob das System erreichbar ist und er Zugang dazu erlangen kann. Anhand eines webbasierten Zugriffs auf den hinter Port 8080 laufenden Dienst aus dem privaten Netz heraus wird der Versuch dargestellt, weitere Information zu bekommen. In Abbildung 34 ist ersichtlich, dass man die Webseite erreichen kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 34: openHAB Webseite nach Installation (Quelle: Eigener Webbrowser)

Als Ergebnis des Tests ist ersichtlich, dass das benutzte System auf dem Smart Home Hub openHAB ist. Auf der Webseite des Open Source Projekts kann das Standard Passwort nebst Standard Login nachgelesen werden (openHAB, o.J.). Unter der Annahme, dass Standard-Benutzer und deren Passwörter nach der Installation immer noch verfügbar sind, kann eine Wörterbuch-Attacke ausgeführt werden, die auch noch weitere Benutzer/Passwort-Kombinationen abdeckt. Mit META- SPLOIT kann dann eine komplette Wörterbuch-Attacke durchgeführt werden. Natürlich ist auch ein direkter Zugriff mit dem SSH-Protokoll auf den Smart Home Hub möglich. Abbildung 35 zeigt die Wörterbuch-Attacke auf den Smart Home Hub aus dem privaten Netzwerk heraus.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 35: Wörterbuchangriff Metasploit auf openHAB Server (Quellen Eigene Darstellung)

Als Ergebnis ist zu erkennen, dass es einen erfolgreichen Zugriff (Success) für den User „openhab" mit dem Passwort „openhab" gab. Dieses Beispiel stellt dar, wie man logisch vorgeht, um Gefahren zu untersuchen. Weiter zeigt es auch, wie gefährlich es ist, nicht geänderte Passwörter zu benutzen und wie wichtig ein Schutz in der Netzwerkschicht ist, der im nächsten Kapitel erläutert wird.

4.5 Schwachstellenanalyse der Netzwerkschicht

In den beiden vorhergehenden Kapiteln sind die Sicherheitsmöglichkeiten im Netzwerk noch nicht mit einbezogen worden, da man mit bereits geschlossenen Netzwerk-Ports keine Schwachstellen in den anderen Schichten aufzeigen kann. Dies wird hier jetzt nachgeholt. Wie im Modell beschreiben besitzt der Smart Home Hub eine eigene Firewall die jetzt eingeschaltet wird. Dieser Firewall kommt eine besondere Bedeutung zu. Generell besteht die Netzwerkschicht aus dem WAN-Gateway mit eingebauter Firewall, der Firewall auf dem Smart Home Hub, dem WLAN-Netzwerk für Smart Home Komponenten, einem LAN-Netzwerk für Smart Home Komponenten und allen Verkabelungen, die dafür nötig sind. Um die Netzwerk-Sicherheit zu erhöhen, wird jetzt die Firewall auf dem Smart Home Hub aktiviert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 36: Firewall INPUT-Chain (Quelle: Eigene Darstellung)

Nach dem die Firewall eingeschaltet wird, ist ersichtlich, dass am Ende der Firewall Input-Kette alle Datenpakete einen „Drop“ erhalten, die nicht vorher durchgelassen worden sind. Das bedeutet, sollte keine Regel vorher greifen, so wird der Zugriff gesperrt. Zu den freigeschalteten Firewall-Ports gehören die SSL-Verbindung und für die Administration gebrauchte SSH-Zugriffe. Dies ist Abbildung 36 zu entnehmen. Jetzt kann ein neuer Port-Scan durchgeführt werden, der dann mit den vorhergehenden Ergebnissen des Port-Scans auf den Smart Home Hub verglichen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 37: Portscan mit eingeschalteter Firewall auf dem Smart Home Hub (Quelle: Eigene Darstellung)

Der Unterschied zum Port-Scan der Schwachstellenanalyse der Anwendungsschicht ist deutlich. Es gibt nur noch einen Weg auf das Web Frontend des Smart Home Hubs (IP-Adresse 192.168.178.70) zuzugreifen. Dies ist die verschlüsselte Verbindung über den Netzwerk-Port 443. Der Port 22 dient dem Zugriff der Administration. Daraus ist ersichtlich, dass die Firewall auf dem Smart Home Hub den Zugriff deutlich einschränkt. Zu sehen ist dies in Abbildung 37.

Ein weiterer Aspekt der Netzwerkschicht ist das eigens für die Einbindung der WLAN-Komponenten geschaffene WLAN-Netzwerk. Dieses Netzwerk ist nicht aus Richtung des WAN-Gateways erreichbar, da wie weiter oben zu sehen, die Firewall auf dem Smart Home Hub das Netzwerk abschirmt. Somit kann es nur kompromittiert werden, wenn Angriffe auf dieses WLAN im eigenem Haus stattfinden. Um dies zu vermeiden, wird eine WPA2 Verschlüsselung gewählt.

Mit dem Tool AIRODUMP-NG der Kali Linux Distribution kann überprüft werden, welche WLAN- Netzwerke sich in der Nähe befinden und welche Verschlüsselung diese bieten. Um die Schwachstellen im WLAN-Netzwerk gering zu halten, wird in dem erarbeiteten Modell WPA 2 mit dem CCMP- Protokoll genutzt. Dies impliziert die AES-Verschlüsselung. Die Darstellung in Abbildung 38 macht dies deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 38: WLAN-Netzwerk-Scan (Quelle:Eigene Darstellung)

Das genutzte Wireless LAN, ist das WLAN-Netzwerk SMART_HOME. Deutlich ist zu erkennen, dass es mit WP2 und CCMP-Protokoll betrieben wird.

Außer dem WLAN-Netzwerk gibt es noch ein an die zweite Ethernet Schnittstelle des Smart Home Hubs angeschlossenes LAN-Netzwerk. Dieses Netzwerk kann, wie das WLAN-Netzwerk, nicht direkt erreicht werden, da es sich hinter der internen Firewall befindet.

4.5.1 Sicherheit im Patchmanagement

Wie bereits weiter oben bei den Prinzipien angesprochen, soll verhindert werden, dass Smart Home Komponenten eigenständig Updates installieren. Um dies zu verhindern, wird die lokal installierte Firewall soll konfiguriert, dass jeglicher, ausgehenden Datenverkehr geblockt wird. Dies verhindert auch, dass Komponenten ungewollt Daten an Dritte weiterleiten. Abbildung 39 zeigt die konfigurierte Firewall (iptables).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 39: Firewall Forward-Chain (Quelle: Eigene Darstellung)

Da der gesamte Datenfluss durch den Smart Home Hub läuft und dieser dann in Richtung des WANGateways weitergeleitet wird, ist es die Forward-Chain, die hier geblockt werden muss. Um jetzt Updates zu erlauben muss die Regel

DROP all -- anywhere anywhere (siehe Abbildung 39) gelöscht werden. Dadurch wird wieder erlaubt, dass alle Komponenten uneingeschränkten Datenverkehr von innen nach außen haben. Um dies komfortabel zu lösen, bietet openHAB eine Möglichkeit, einen virtuellen Schalter zu definieren, der die Firewall-Konfiguration umschaltet. Dieser Schalter ist bei geblocktem Datentransfer aus. Abbildung 40 zeigt den Schalter bei ausgeschaltetem Zustand.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 40: openHAB Forward-IPTABLES Switch (Quelle: Eigene Darstellung)

Wenn der Schalter angeschaltet wird, wird die Firewall-Regel gelöscht. Anhang 7 beschreibt die notwendigen Schritte, die erforderlich sind, damit im Hintergrund Firewall-Regeln verändert werden können. In Abbildung 41 sieht man die geöffnete Firewall.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 41: Offene FORWARD Firewall Chain (Quelle: Eigene Darstellung)

Jetzt können Updates der Komponenten durchgeführt werden. Nachdem die Updates eingespielt worden sind, wird der Schalter wieder ausgeschaltet und die Firewall-Regeln werden wieder zurückgesetzt. OpenHAB bietet auch die Möglichkeit, zeitgesteuerte Aktionen auszuführen. Dazu können in openHAB Regel (rules) definiert werden, die zum Beispiel den oben definierten Schalter genau zu einer bestimmten Uhrzeit an einem bestimmten Tag auf „an" zuschalten. Dadurch kann zum Beispiel immer am letzten Tag der Woche für eine Stunde die Firewall geöffnet werden, um Updates einzuspielen. Listing 4 zeigt eine beispielhafte Zeitschaltung in openHAB, in der die geöffnet und nach einer Stunde wieder geschlossen wird. Diese Möglichkeit beinhaltet die Gefahr, dass man dieses Zeitfenster aus den Augen verliert, wenn man längere Zeit keine Updates durchgeführt hat. Dadurch wird der Datenfluss dann nicht beobachtet und es können Angriffe durchgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Listing 4: OpenHAB Regeln FW_auf und FW_zu (Quelle: Eigene Darstellung)

Um den Datenfluss zu überwachen, kann an einer zentralen Stelle mitgeschnitten werden, wo die Daten hinfließen. Dazu bietet sich das WAN-Gateway an, da hier alle Daten zentral durchlaufen werden. In dieser Arbeit wird die Fritzbox 7490 genutzt. Diese bietet die Möglichkeit, Daten mitzuschneiden. Abbildung 42 stellt dies dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 42: Fritzbox Paketmitschnitt (Quelle: Eigener Webbrowser)

Die aufgezeichneten Daten können dann zum Beispiel mit dem Tool Wireshark (Wireshark, 2021) sichtbar gemacht werden. Abbildung 43 zeigt einen Wireshark Paketmitschnitt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 43: Wireshark Paketmitschnitt (Quelle: Eigener Mitschnitt)

Mit einer MaxMind (Maxmind, o.J.) Erweiterung in Wireshark lässt sich geographisch nachvollziehen, wo die Daten aus dem eigenen Haus hingegangen sind. Dies ist Abbildung 44 zu entnehmen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 44: Geographischer Nachweis in Wireshark (Quelle: Eigener PC)

4.5.2 Sicherheit durch Intrusion Detection

Um die Integrität zu gewährleiten wird in der Fachliteratur der Einsatz eines „Intrusion Detection Systems" vorgeschlagen (Lee, Kim, & Shon, 2016). Auch dieser Angriff findet in der Netzwerkschicht statt. Ein Beispiel mit ausgeschalteter Firewall soll zeigen, wie durch Snort erkannt werden kann, dass ein Rechner durch einen Netzwerk-Ping (ICMP-Request) aufgespürt werden soll. Die Snort Regel ist in Listing 5 abgebildet:

Abbildung in dieser Leseprobe nicht enthalten

Listing 5: Snort ICMP-Regel (Quelle: Eigene Darstellung)

Die dazugehörigen Meldungen auf Kommandozeilen-Ebene stellt Abbildung 45 dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 45: Snort Sceenshot IMCP Traffic (Quelle: Eigene Darstellung)

Die Regel veranlasst Snort, alle Datenpakete eines ICMP-Protokolls mit zu loggen und dies auf der Kommandozeile als Alarm darzustellen. Listing 6 zeigt gezielt einen Eintrag aus der oberen Abbildung, wie der Smart Home Hub einen Ping-Request beantwortet:

Abbildung in dieser Leseprobe nicht enthalten

Listing 6: Aufgezeigter ICMP Traffic (Quelle: Eigene Darstellung)

Anhang 4 zeigt wie Snort gestartet wird und wie weitere Regel aussehen können. Snort ist ein mächtiges Werkzeug um Netzwerkverkehr zu scannen und unbefugten Zugriff zu erkennen.

4.6 Bedienbarkeit

Nachdem die Installationen abgeschlossen sind, wird das gesamte System über den Smart Home Hub verwaltet. Dies soll hier auf Bedienbarkeit untersucht werden. Die verwendete Software open- HAB bietet sehr viele Möglichkeiten, Komponenten zu verwalten und direkt oder in Abhängigkeit von Regeln zu steuern. Anhand einer schaltbaren HomeMatic IP-Steckdose wird dies von der Integration ins System bis zum schaltbaren Ergebnis dargestellt. openHAB braucht zuerst die entspreche Softwareschnittstelle, um HomeMatic-Komponenten über das HomeMatic-Gateway einbinden zu können. Dazu wird ein Addon, ein sogenanntes „Binding" für HomeMatic in das System installiert. Abbildung 46 zeigt dies.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 46: openHAB Bindings (Quelle: Eigene openHAB Installation)

Im nächsten Schritt wird ein „Thing" in openHAB generiert, das das physische Gerät wiederspiegelt. Dazu wird ein Scan durchgeführt, der alle Bindings durchschaut, ob diese mit Geräten verbunden sind. Die folgende Abbildung 47 stellt die Inbox der gefunden Komponenten dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 47: openHAB Things INBOX (Quelle: Eigener openHAB Server)

Hier sind vier weitere Komponenten in der „INBOX". Im dritten Schritt wird jetzt aus der physischen Ebene eine logische Ebene geschaffen und aus dem Thing wird ein Item erzeugt, das dann geschaltet werden kann. Im folgenden Beispiel wird ein Item mit der Bezeichnung „HomeMatic IP-Steck- dose" erzeugt. Dieses Item gehört zur Kategorie Switch (Schalter). Damit kann dann die Steckdose logisch geschaltet werden (Abbildung 48). Über die Verbindung zu einem Thing, das die physische Verbindung zur realen Steckdose durch das HomeMatic-Binding bildet, wird der Schaltimpuls weiter an die HomeMatic-Bridge geleitet, die dann den Impuls per Funk weiter an die Steckdose sendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 48: openHAB ITEM (Quelle: Eigener openHAB-Server)

Die Steckdose steht jetzt dem Gesamtsystem zur Verfügung. Somit sind jetzt auch regelabhängige Aktionen oder Interaktionen mit anderen Geräten möglich. Die Abbildung 49 stellt mehrere angelegte Items (openHAB Ansicht: Model) im System dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 49: openHAB Model-Webseite (Quelle:Eigener openHAB Server)

5 Interpretation mit Schlussfolgerungen und Handlungsempfehlungen

5.1 Vergleich Lösungen und Anforderungen

Der Kernpunkt dieser Arbeit ist die Untersuchung der Vertraulichkeit, Integrität und Verfügbar in den drei Schichten eines Smart Home Systems. Nachfolgend wird das erarbeitete Ergebnis bezogen auf die drei Perspektiven Wahrnehmungsschicht, Anwendungsschicht und Netzwerkschicht erläutert. Das Modell von Mantoro, Ayu, & Mahmod (2014) ist als Basisarchitektur (siehe Kapitel 3.1) aufgegriffen und dahingehend erweitert worden, dass es möglich ist, verschiedene Hersteller einzubinden. Leider bietet das Model von Mantoro, Ayu, & Mahmod keine Trennung zwischen einem privaten Netzwerk und dem Smart Home Netzwerk. Dies ist hier mit einer zusätzlichen Firewall realisiert worden.

5.1.1 Perspektive Wahrnehmungsschicht

Die Wahrnehmungsschicht ist in der Arbeit durch Komponenten des Unternehmens eQ-3 AG und Allterco Robotics Ltd. realisiert worden. Die eingesetzte WLAN-Steckdose der Firma Allterco Robotics Ltd. zeigte Schwächen bei der Vertraulichkeit und der Integrität. Durch einen Netzwerkport-Scan, der innerhalb des Smart Home Netzwerks ausgeführt wurde, wurde ersichtlich, dass die Datenübertragung ohne Verschlüsslung stattfindet. Zusätzlich war es nicht zwingend erforderlich einen User mit Passwort einzurichten. Ein Test, auf die Weboberfläche der WLAN-Steckdose zu zugreifen, war ohne Probleme möglich, wenn man sich bereits im WLAN-Netzwerk befand. Dadurch hätte durch ein Ausschalten der Steckdose die Verfügbarkeit kompromittiert werden können. Allerdings bot die Steckdose einen leichten Schutz für die Vertraulichkeit, in dem ein User mit Passwort nachträglich angelegt wurde. Eine Verschlüsselung der Datenkommunikation (HTTPS) war aber weiterhin nicht gegeben. Da die Steckdose aber über WPA 2 an den Smart Home Hub angebunden war, erfolgte die Kommunikation generell verschlüsselt.

Die eingesetzten Komponenten des Unternehmens eQ-3 AG waren in zwei verschiedenen Marken unterteilt. HomeMatic und HomeMatic IP. Erstere hat gezeigt, dass es möglich war, dass die Komponenten eine unverschlüsselte Kommunikation zum proprietären Gateway aufbauen. Zwar ist eine Verschlüsselung mit AES-Verschlüsselung möglich, diese ist aber nicht automatisch aktiv geschaltet oder zwingend vorgeschrieben. Anders die Marke HomeMatic IP. Hier war es nicht möglich, eine Komponente unverschlüsselt in Betrieb zu nehmen, was auch zuvor bereits in der Literatur beschrieben worden war (Grohmann, 2020).

Da die Tests innerhalb des Smart Home Netzwerks ausgeführt worden sind, war die Netzwerksicherheit hier noch nicht berücksichtigt worden. Dies erfolgte später bei der Betrachtung der Netzwerkschicht selbst.

5.1.2 Perspektive Anwendungsschicht

Die Anwendungsschicht wurde durch die Weboberfläche der openHAB-Applikation repräsentiert. Alle Smart Home Komponenten können nur zentral über den Smart Home Hub gesteuert werden. Weitere Möglichkeiten werden durch die Firewall gesperrt. Weiter verhindert die Firewall auf dem Smart Home Hub die Kommunikation in Richtung des privaten Netzes. Aus dem privaten Netz heraus wird der Zugriff nur auf die Weboberfläche über das HTTPS-Protokoll, sowie über das SSH- Protokoll erlaubt. Die Integrität der Daten wird generell durch die verschlüsselte Kommunikation auf den Smart Home Hub gewährleistet. Durch eine native Applikation auf einem mobilen Gerät oder einen Webbrowser auf einem Endgerät kann über einen VPN-Tunnel, der am WAN-Gateway endet, auf die Weboberfläche des Smart Home Hubs zugegriffen werden, um Komponenten zu steuern. Dieser kanalisierte Zugang ist eins der Prinzipien und durch den beschriebenen Weg erreicht worden. DoS-Angriffe von außen werden durch die Firewall im WAN-Gateway abgefangen und dringen nicht bis zum Smart Home Hub durch.

5.1.3 Perspektive Netzwerkschicht

Die Netzwerkschicht ist das Bindeglied der Wahrnehmungsschicht und der Anwendungsschicht, weiter beinhaltet sie die Verbindung in das Internet und in weitere interne Netzwerke. Sie stellt eine wesentliche Bedeutung in dieser Arbeit dar, da sie unerlaubte Zugriffe verhindert. Durch das zweistufige Firewall-Konzept werden direkte Zugriffe aus dem Internet auf den Smart Home Hub unterdrückt. Der einzigen Weg, von außen auf diesen zuzugreifen, ist eine VPN geschützte Verbindung. Die Vertraulichkeit der privaten Daten ist durch die Abtrennung des internen Netzwerks mit dem Smart Home Netzwerk geschaffen worden. Auch der Datenfluss der angeschlossen HomeMatic- Bridge (Gateway) durchläuft bei Updates die interne Firewall auf dem Smart Home Hub. Dadurch ist eine Kontrolle der Daten durch ein Intrusion-Detection-System möglich. Die Verbindung nach außen kann nach Wusch geöffnet oder geschlossen werden.

Der Aufbau eines Smart Home Netzwerks kann über die LAN-Schnittstelle des Smart Home Hubs oder über das eigens dafür eingerichtete WLAN-Netzwerk bereitgestellt. Der genutzte WPA 2-Standard mit dem CCMP-Protokoll und AES-Verschlüsselung entspricht den heutigen gängigen Methoden, ist aber theoretisch angreifbar, wie in Kapitel 2.3.3 erläutert.

Eines der Prinzipien dieser Arbeit ist die Vertraulichkeit der privaten Daten zu gewährleisten. Dies wurde durch die Trennung der verschiedenen Netzwerke erreicht.

5.2 Empfehlungen für ein Future Proof Smart Home

5.2.1 Allgemein

Hier sollen allgemeingültige Empfehlungen für den generellen Aufbau eines Smart Homes aufgezeigt werden, um das Sicherheitsbewusstsein der Anwender zu steigern.

5.2.2 Genereller Aufbau eines Smart Homes

Das Smart Home System sollte nicht im eigenen internen Netzwerk aufgebaut werden, wie nach dem Modell von Mantoro, Ayu, & Mahmod (2014). Wenn ein Gerät kompromittiert ist, besteht die Gefahr, dass von da aus, das ganze interne Netzwerk erreichbar ist. Um dies zu vermeiden, sollten eigene Netzwerke für Smart Home Komponenten aufgebaut werden, die durch eine Firewall vom internen Netzwerk getrennt werden. Abbildung 50 zeigt das final empfohlene Modell.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 50: Empfohlenes Modell (Quelle: Eigene Darstellung)

Der generelle Ablauf startet beim User, der über einen dedizierten mobilen Client oder einen Browser auf den Smart Home Hub über eine getunnelte Verbindung zugreift. Der Tunnel wird am WAN-Gateway aufgebrochen und der Request wird weiter verschlüsselt an den vor die Applikation geschalteten Reverse Proxy weitergeleitet. Hier wird die Verschlüsselung aufgebrochen. Der Request wird innerhalb des Smart Home Hubs an den Applikations-Server weitergeleitet. Jetzt können die Smart Home Komponenten über den Applikations-Server bedient werden. Wie oben schon beschrieben, sind die Smart Home Komponenten über eigene Netzwerke erreichbar. Alle genutzten Netzwerke für Smart Home Komponenten bekommen eigene Netzwerk-Segmente und -Adressbereiche. Diese sind zum Beispiel 192.168.1.0/24 für das WLAN-Netzwerk und 192.168.2.0/24 für das LAN-Netz- werk. Es wird empfohlen, dass zwischen dem WAN-Netzwerk und den internen Netzwerken eine Firewall eingerichtet wird, damit keine internen Netzwerk-Dienste von außen erreichbar sind. Diese sind dem WAN-Gateway nicht bekannt. Der Smart Home Hub wird per Ethernet (eth0) an das WANGateway (lan 1) angebunden. Auf dem Smart Home Hub sollte dann selbst eine Firewall installiert werden, die die eingehenden und ausgehenden Verbindungen überwacht. In Verbindung mit der Firewall auf dem Smart Home Hub, werden die Smart Home Netzwerke streng vom privaten Netzwerk, was mit dem WAN-Router über die Ethernet-Schnittstelle (eth0) verbunden ist, getrennt. Funkbus Komponenten werden über eine Bridge an den Smart Home Hub angebunden und haben keine direkte Verbindung zum Internet. Die Firewall auf dem Smart Home Hub ist für ausgehende Verbindungen in Richtung Internet und in das private Netzwerk gesperrt. Somit können die Komponenten nicht mit dem Internet oder mit Geräten im privaten Benutzer Netzwerk kommunizieren. Nur für Updates der Komponenten wird die Firewall unter Kontrolle des Anwenders geöffnet. Nach erfolgtem Update wird die Firewall wieder geschlossen. Benutzte WLAN-Netzwerke sollten immer den höchstmöglichen Verschlüsselungsstandard verwenden.

5.2.3 Netzwerk-Dienste

Generell sollten nur Dienste eingesetzt werden, die eine verschlüsselte Kommunikation zwischen den Smart Home Komponenten gewährleisten. Um auf dem Smart Home Hub zuzugreifen und Daten auszutauschen, sollten Protokolle wie Telnet oder FTP gänzlich ausgeschlossen werden. Statt- dessen sollte zur Kommunikation mit dem Smart Home Hub das SSH-Protokoll genutzt werden. Daten sollten - wenn nötig - per SCP kopiert werden.

Um die Kommunikation über das Web Frontend sicher zu gewährleisten sollte der Zugriff weitestgehend verschlüsselt ablaufen. Dazu sollte die Entschlüsselung erst direkt auf dem Smart Home Hub stattfinden. Hierzu bietet sich die Einbindung eines Reverse-Proxies an, der auch für weitere Sicherheitsmaßnahmen wie zum Beispiel die Reduzierung der maximalen Zugriffe auf ein System nutzbar ist (nginx, 2015).

Die eingesetzte Hardware für Smart Home Komponenten sollte generell aus vertrauenswürdiger Quelle stammen. Eventuell gebraucht gekaufte Hardware könnte sicherheitstechnisch bedenkliche Software enthalten, die eventuell vorher mit Absicht manipuliert wurden.

Komponenten von vielen verschiedenen Herstellern müssen für jeden Hersteller auf Sicherheit untersucht werden. Dazu empfiehlt es sich, lieber Komponenten von wenigen verschiedenen Herstellern einzusetzen, die aus vertrauter Quelle stammen. Damit kann sich auch die Anzahl der eingesetzten Protokolle reduzieren, was ein weiterer Punkt zu einem sicheren Smart Home ist, denn jedes nicht genutzte kann von Hackern auch nicht kompromittiert werden.

Hardware, die keine Möglichkeit für eine verschlüsselte Kommunikation bietet, sollte nicht eingesetzt werden. Hardware, die über Funkprotokolle eingesetzt wird, sollte über eine verschlüsselte FunkKommunikation verfügen.

5.2.5 Handlungsempfehlungen Penetration-Test

Es empfiehlt sich, regelmäßig Penetrationstests durchzuführen, um die eingesetzten Komponenten auf Sicherheitslücken hin zu untersuchen. Dazu sollte ein Schwachstellen-Scanner eingesetzt werden. Wie beschrieben empfiehlt das BSI (BSI, 2016) Penetrationstest und hat dazu einen Leitfaden herausgegeben.

5.2.6 Handlungsempfehlungen für Passwörter

Komponenten oder Software wird meist mit einem Standard-Benutzer und -Passwort ausgeliefert. Dies hat die Untersuchung der WLAN-Steckdose bestätigt. Standard Benutzer/Passwort-Kombina- tionen sind in der Regel im Internet recherchierbar. Hacker kennen diese Passwörter in der Regel. Daher wird empfohlen, als allererstes bei der Inbetriebnahme von Komponenten die Standard-Benutzer und -Passwörter zu ändern beziehungsweise, eigene Benutzerkonten einzurichten. Der Datenschutz gibt eine Empfehlung, wie Passwörter sicher zu erzeugen sind und stellt eine Webseite bereit, um ein sicheres Passwort zu generieren (datenschutz.org, 2018).

Wie in Kapitel 4.5.2 beschrieben und wie auch von (Lee, Kim, & Shon, 2016) vorgeschlagen sollte eine Software genutzt werden, um das Netzwerk zu überwachen und um Unregelmäßigkeiten im Netzwerkverkehr aufzuspüren.

6 Fazit

6.1 Zusammenfassung

In dieser Arbeit war das Ziel zu überprüfen, ob es möglich ist ein Smart Home sicher zu betreiben. Dazu wurde ermittelt, welche technischen Möglichkeiten es gibt, ein Smart Home aufzubauen. Im Wesentlichen konnte ermittelt werden, dass zwischen drahtgebundenen System und nicht drahtgebundenen Systemen unterschieden wird. Die nicht drahtgebundenen Systeme werden weiterunterteilt in Funk-, WLAN- oder Bluetooth-Systeme. Basierend auf den physikalischen Unterschieden wurden die dazugehörigen Protokolle und die möglichen Sicherheitslücken ermittelt. WLAN zum Beispiel hat eine längere historische Entwicklung hinter sich, die darauf beruht, dass immer wieder Sicherheitslücken im WLAN-Standard gefunden wurden. Somit wurden die Verschlüsselung über WEB, WPA und WPA2 eingeführt und verstärkt. WPA3 steht bereit, ist aber noch wenig verbreitet und wurde daher hier nicht berücksichtigt. Bei der Untersuchung der WLAN Standards wurde ermittelt, dass WPA2 zwar als sicher gilt, es sind aber theoretische Angriffsmöglichkeiten bekannt.

Weiter wurden die Systemstrukturen von Smart Homes erarbeitet. Diese haben eine zentrale Struktur, eine dezentrale Struktur oder auch eine Kombination aus beiden. Die Architektur eines Smart Home ist in der Regel aus drei Schichten aufgebaut, der Wahrnehmungsschicht, der Anwendungsschicht und der Netzwerkschicht. Es wurden die gebräuchlichsten Protokolle der Anwendungsschicht dargestellt, diese sind HTTP, MQTT oder auch CoAP. Daran anschließend wurden die möglichen Angriffstechniken basierend auf die dreischichtige Architektur ermittelt. Eine typische Angriffsmethode auf Smart Homes sind DoS-Attacken. Aus dieser Erkenntnis heraus sind die Sicherheitszeile für eine Smart Home erarbeitet worden. Weiter sind ebenfalls noch die für diese Arbeit erforderlichen Rahmenbedingungen dargelegt worden. Ein wichtiger Punkt in diesem Zusammenhang war die Möglichkeit, ein Modell zu schaffen, dass Sicherheit unabhängig von unterschiedlichen Anbietern von Smart Home Komponenten bietet. Um das Modell zu entwickeln wurde eine Testumgebung aufgebaut, die iterativ das Modell Stück für Stück vorangetrieben hat. Die Komponenten für das Modell wurden definiert und vorgestellt. Hierzu gehörten sowohl physische Komponenten, als auch Software Komponenten. Es wurden drei Prinzipien definiert, die im Modell verankert werden

sollten. Dazu zählten die Trennung der unterschiedlichen Netzwerke. Ein weiteres Prinzip war, dass das Modell eine Kanalisierung des Zugangs auf den Smart Home Hub bietet sollte. Das dritte Prinzip war die Möglichkeit, ein gesteuertes Update-Fenster zu ermöglichen. Auf diesen Grundlagen wurde das Modell entwickelt. Um das Modell zu evaluieren wurden Tools aus der Kali Linux Distribution genutzt. Im Wesentlichen waren dies NMAP, openVAS, Metasploit und Snort. Um die SSL-Verbin- dung zum Smart Home Hub zu überprüfen, wurde das Tool SSLYSE genutzt. Pro Architekturschicht wurde eine Schwachstellenanalyse mit den erwähnten Tools durchgeführt. In der Wahrnehmungsschicht wurde eine WLAN-Steckdose untersucht. Hier kam heraus, dass dieses Produkt nur über HTTP, nicht aber HTTPS ansprechbar war. Zusätzlich war kein Benutzer mit Passwort aktiviert. Die Anwendungsschicht wurde mit SSL abgesichert und könnte auch nur über dieses Protokoll erreichet werden. Somit konnte hier die geforderte Sicherheit nachgewiesen werden. Die Netzwerkschicht ist das Bindeglied der Anwendungs- und Wahrnehmungsschicht und hat somit eine tragende Rolle für die Sicherheit des Gesamtmodells. Weiter wurde in dieser Schicht die Trennung des Smart Home Netzwerks vom privaten Netzwerk durch eine zusätzlich Firewall realisiert und durch Tests nachgewiesen. Weiter wurde ein Konzept dargestellt, wie man mit openHAB die Firewall zu Patch-Zwecken öffnen und wieder schließen kann. Nach der Analyse der Schwachstellen wurden diese aus Sicht der Perspektiven Wahrnehmungsschicht, Anwendungsschicht und Netzwerkschicht diskutiert. Als Resultat der Diskussion wurden Handlungsempfehlungen ermittelt, die auch dargelegt worden sind und für ein Future Proof Smart Home genutzt werden können. Diese sind im Wesentlichen der Aufbau für ein sicheres Smart Home, Empfehlungen für die zu benutzende Hardware, die Empfehlung Penetrationstests durchzuführen, eine Empfehlung sichere Passwörter zu nutzen und ein Intrusion Detection System einzuführen.

Abschließen kann gesagt werden, dass es möglich ist, ein Smart Home sicher aufzubauen. Allerdings ist dies eventuell mit höheren Zeit- und Kostenaufwendungen zu realisieren. Zertifizierte Smart Home Komponenten gibt es aktuell nur aus dem Hause eQ-3. Dies ist das HomeMatic-IP System. Bei diesem System ist auch garantiert, das immer eine Verschlüsslung zwischen dem Gateway und den Aktoren/Sensoren stattfindet. Aus den eigenen Erfahrungen heraus braucht es Zeit, sich in den Aufbau einer Firewall gestützten Lösung einzuarbeiten, deshalb ist hier, wie oben schon angesprochen, mit einer Einarbeitungszeit zurechnen.

6.2 Kritische Reflektion

In dieser Arbeit lag die Konzentration hauptsächlich auf der Sicherheit, die in der Netzwerkschicht integriert werden kann. Ein Hauptgrund dafür ist, dass man hier durch Konzentration des gesamten Netzwerkverkehrs einen möglichst großen Erfolg bei der Sicherheit erzielen kann. Die Betrachtung der Sicherheit im WLAN-Netzwerk ist nur dadurch bestätigt worden, dass sichergestellt wurde, dass das genutzte WLAN Netzwerk den WPA2 Standard mit CCMP-Protokoll und AES Verschlüsselung nutzt, nicht aber durch einen gezielten Angriff. Dies ist dahingehend kritisch zu beurteilen, da hier der Aussage vertraut wurde, dass der WPA2 Standard ein Netzwerk genügend schützt. Ein ähnliches Vorgehen gab es bei der Untersuchung der Sensoren, Aktoren und dem dazugehörigen Gateway des Funkbus-Systems. Die Untersuchung fand bis auf eine Sichtung in der Weboberfläche der RaspberryMatic-Zentrale (Bridge) literaturbasiert statt. Die Sichtung ergab, dass HomeMatic IP- Komponenten immer verschlüsselt mit der Zentrale kommunizieren, was laut Sichtung mit Home- Matic-Komponenten nicht standardmäßig der Fall ist. Kritisch zu beurteilen ist hier das Verlassen auf das Gesehene und die unterlassene netzwerktechnische Überprüfung.

6.3 Ausblick

Das Thema Smart Home ist sehr umfangreich. Es gibt sehr viele Konfigurationen eines vernetzten Hauses. Nur eine davon konnte in dieser Arbeit abgebildet werden. Um zu der erarbeiteten Lösung zu gelangen, wurde ein eigenes Smart Home Netzwerk aufgebaut. Es wäre hilfreich für die Zukunft, wenn Hersteller von Routern für den Hausgebrauch eine Schnittstelle für ein Smart Home Netzwerk implementieren würden. Diese Schnittstelle könnte ein eigenes Netzwerk beinhalten, das durch die eingebaute Firewall, wie in dem hier erarbeiteten Modell, einen eigenen Bereich für Smart Home Komponenten schafft. Dadurch wäre, genauso wie hier im Modell, eine Trennung zwischen UserNetzwerk und Smart Home Netzwerk gewährleistet. Die Ergebnisse zur Schwachstellenuntersuchung von Smart Home Komponenten geben Anlass, darüber nachzudenken, weitere Komponenten zu untersuchen und zu erarbeiten, welcher Hersteller die beste Verschlüsselung bietet. Dies wurde in dieser Arbeit nur rudimentär untersucht. In dieser Arbeit wurde openHAB als zentrale Software Lösung eingesetzt, um die verschiedenen Komponenten zu steuern. Da es viele weitere Open Source Lösungen als Smart Home Zentrale gibt, wäre auch eine Untersuchung auf Sicherheitsfunktionen und Bedienbarkeit der einzelnen Lösungen denkbar. Dazu würde zum Beispiel die Einbindung der Hardware-Komponenten in das System zählen. Aber auch die Performance und Stabilität könnten in diesem Zusammenhang untersucht werden. Eine andere Untersuchung könnte die Ermittlung der erzielbaren Energieersparnisse verschiedener Smart Home Komponenten sein. Hier wäre es interessant zu prüfen, in welchem Bereich des Hauses mit welcher Technik, in Bezug zu den Anschaffungskosten, ein effektives Ersparnis erzielt werden kann.

Literaturverzeichnis

Adnan, A. H. et al. (2015). A comparative study of WLAN security protocols: WPA, WPA2. In 2015 International Conference on Advances in Electrical Engineering (ICAEE) (S.165-169). doi: 10.1109/ICAEE.2015.7506822

Al-Fuqaha, A. et al. (2015). Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications. IEEE Communications Surveys & Tutorials, 17 (4), S.2347-2376. doi: 10.1109/COMST.2015.2444095

Ali, W., Dustgeer, G., Awais, M., & Shah, M. A. (2017). IoT based smart home: Security challenges, security requirements and solutions. In 2017 23rd International Conference on Automation and Computing (ICAC) (S.1-6). doi: 10.23919/IConAC.2017.8082057

Andrea, I., Chrysostomou, C., & Hadjichristofi, G. (2015). Internet of Things: Security vulnerabilities and challenges. In 20th IEEE Symposium on Computers and Communication (ISCC). 20th IEEE Symposium on Computers and Communication (ISCC) took place 6-9 July 2015 in Lanarca, Cyprus (S.180-187). Piscataway, NJ: IEEE. doi: 10.1109/ISCC.2015.7405513

Aschendorf, B. (2014). Energiemanagement durch Gebäudeautomation: Grundlagen - Technologien - Anwendungen. Berlin: Springer Vieweg. doi: 10.1007/978-3-8348-2032-7

AVM Deutschland. (2021). Deutschland. Abgerufen am 20.03.2021 von https://avm.de/

Baumann, M. (2020a). Smart Home Aktor - So funktioniert das Antriebselement. homeandsmart.de. Abgerufen am 08.03.2021 von https://www.homeandsmart.de/aktor-aktoren- und-aktuatoren-erklaert

Baumann, M. (2020b). Smart Home Sensor - So funktioniert der Detektor. homeandsmart.de. Abgerufen am 08.03.2021 von https://www.homeandsmart.de/sensor-induktiver-und-kapazitiver

Baumann, M. (2020c). Was ist ein Smart Home Hub? Aufgabe, Funktion und Einsatzgebiete. homeandsmart.de. Abgerufen am 15.02.2021 von https://www.homeandsmart.de/hub-smart- home-aufgabe-funktion-einsatzgebiete

Böttcher, S. (2018). Das Bewusstsein für IoT-Sicherheit fehlt. IT-BUSINESS. Abgerufen am 27.03.2021 von https://www.it-business.de/das-bewusstsein-fuer-iot-sicherheit-fehlt-a-778019/

BSI. (2016). Pen Tests und IS Webcheck - Praxis-Leitfaden: IT-Sicherheits-Penetrationstest. Abgerufen am 14.03.2021 von https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Sicherheitsberatung/Pentest_Webcheck/Leitfaden_Penetrationstest.html

BSI. (2021). BSI - Open Vulnerability Assessment System - Open Vulnerability Assessment System (OpenVAS). Abgerufen am 29.01.2021 von https://www.bsi.bund.de/DE/Themen/Cyber- Sicherheit/Tools/OpenVAS/OpenVAS.html

Bundesamt für Sicherheit in der Informationstechnik. (o.J.). Smarthome sicher einrichten. Abgerufen am 13.02.2021 von https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und- Verbraucher/Informationen-und-Empfehlungen/Internet-der-Dinge-Smart-leben/Smart-Home/ smart-home_node.html

Darby, S. J. (2018). Smart technology in the home: time for more clarity. Building Research & Information, 46 (1), S.140-147. doi: 10.1080/09613218.2017.1301707

Datenschutz.org (2018). Sicheres Passwort erstellen: Was ist hier wichtig? Datenschutz. Abgerufen am 02.03.2021 von https://www.datenschutz.org/passwort-erstellen/ Elektronik-Kompendium. (o.J.). Raspberry Pi als WLAN-Router einrichten (WLAN-Access-Point). Abgerufen am 11.03.2021 von https://www.elektronik-kompendium.de/sites/raspberry-pi/ 2002171.htm

Grohmann, B. (2020). Smart-Home-Security - Widerspruch in sich? Abgerufen am 06.02.2021 von https://www-wiso-net-de.pxz.iubh.de/document/DEH105e94617a18f8d1231ea33b2b8be66d41620214 James, F. (2019). IoT Cybersecurity based Smart Home Intrusion Prevention System. In 2019 3rd Cyber Security in Networking Conference (CSNet) (S. 107-113). doi: 10.1109/CSNet47905.2019.9108938

Kali. (o.J.). What is Kali Linux? | Kali Linux Documentation. Abgerufen am 22.02.2021 von https:// www.kali.org/docs/introduction/what-is-kali-linux Klein, U. (2020). Smart Home Funkstandards im Überblick und Vergleich. homeandsmart.de. Abgerufen am 06.02.2021 von https://www.homeandsmart.de/smart-home-funk-standards- uebersicht-hausautomation Lee, S., Kim, J., & Shon, T. (2016). User privacy-enhanced security architecture for home area network of Smartgrid. Multimedia Tools and Applications, 75 (20), S.12749-12764. doi: 10.1007/s11042-016-3252-2

Mantoro, T., Ayu, M. A., & Mahmod, S. M. b. (2014). Securing the authentication and message integrity for Smart Home using smart phone. In 2014 International Conference on Multimedia Computing and Systems (ICMCS) (S.985-989). doi: 10.1109/ICMCS.2014.6911150 Marksteiner, S., Exposito Jimenez, V. J., Valiant, H., & Zeiner, H. (2017). An overview of wireless IoT protocol security in the smart home domain. In 2017 Internet of Things Business Models, Users, and Networks (S.1-8). doi: 10.1109/CTTE.2017.8260940 Maxmind. (o.J.). GeoLite2 Free Geolocation Data « MaxMind Developer Site. Abgerufen am 26.03.2021 von https://dev.maxmind.com/geoip/geoip2/geolite2/

Messner, M. (2011). Metasploit: Das Handbuch zum Penetration-Testing-Framework (1. Aufl.). s.l.: dpunkt.verlag. Abgerufen von http://search.ebscohost.com/login.aspx?direct=true&scope=site& db=nlebk&AN=908182

Metropolis International Group Ltd. (2015). Homes connect for IoT with DECT ULE. Abgerufen am 09.03.2021 von http://eds.a.ebscohost.com.pxz.iubh.de/eds/detail/detail?vid=6&sid=449b613a- 4e15-4776-a556-e6108b9d6d51%40sessionmgr4006&bdata=JnNpdGU9ZWRzLWxpdmUmc2NvcGU9c2l0ZQ%3d%3d#AN=edsgcl.430210939&db=edsggo Nginx (2015).

Mitigating DDoS Attacks with NGINX and NGINX Plus. NGINX, Inc. Abgerufen am 07.03.2021 von https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/ NGINX Documentation. (2021). NGINX Docs | NGINX ModSecurity WAF. Abgerufen am 27.03.2021 von https://docs.nginx.com/nginx-waf/

Ohland, G. (2013). Funkprotokolle: Z-Wave, HomeMatic und RWE im Vergleich - PC Magazin, pc- magazin. Abgerufen am 14.03.2021 von https://www.pc-magazin.de/ratgeber/funkprotokolle- ueberblick-rwe-zwave-homematic-1530051.html OpenHAB. (o.J.). Introduction. Abgerufen am 10.02.2021 von https://www.openhab.org/docs/ Openvas. (2020). OpenVAS - OpenVAS - Open Vulnerability Assessment Scanner. Abgerufen am 29.01.2021 von https://www.openvas.org/index-de.html

Rahalkar, S. (2019). Quick Start Guide to Penetration Testing: With NMAP, OpenVAS and Metasploit. Berkeley, CA: Apress. doi: 10.1007/978-1-4842-4270-4 Raspberrymatic. (o.J.). Home - RaspberryMatic. Abgerufen am 04.03.2021 von https:// raspberrymatic.de/de/home/

Raspiberry. (o.J.). Buy a Raspberry Pi 3 Model B - Raspberry Pi. Abgerufen am 01.02.2021 von https://www.raspberrypi.org/products/raspberry-pi-3-model-b/

Ray, A. K. & Bagwari, A. (2020). IoT based Smart home: Security Aspects and security architecture. In 2020 IEEE 9th International Conference on Communication Systems and Network Technologies (CSNT) (S.218-222). doi: 10.1109/CSNT48778.2020.9115737 Schmitz, P. (2018). Was ist CCMP? Security-Insider. Abgerufen am 04.03.2021 von https:// www.security-insider.de/was-ist-ccmp-a-742246/

Snort. (o.J.). Snort - Network Intrusion Detection & Prevention System. Abgerufen am 22.02.2021 von https://www.snort.org/

Statista. (2021). Verteilung der Smart Home-Geräte in Deutschland 2019 | Statista. Abgerufen am 15.03.2021 von https://de.statista.com/statistik/daten/studie/1067828/umfrage/verteilung-der- smart-home-geraete-in-deutschland/

Verbraucherzentrale. (2021). Störerhaftung: besserer Schutz für WLAN-Betreiber | Verbraucherzentrale.de. Abgerufen am 15.03.2021 von https://www.verbraucherzentrale.de/wissen/digitale-welt/mobilfunk-und-festnetz/stoererhaftung-besserer-schutz-fuer-wlanbetreiber-

Wara, M. S. & Yu, Q. (2020). New Replay Attacks on ZigBee Devices for Internet-of-Things (IoT) Applications. In 2020 IEEE International Conference on Embedded Software and Systems (ICESS) (S.1-6). doi: 10.1109/ICESS49830.2020.9301593 Wendel, M. (2020). Internet der Dinge: Daten, Geräte, Anwendungsbereiche. homeandsmart.de. Abgerufen am 08.03.2021 von https://www.homeandsmart.de/internet-der-dinge-smart-home- internet-of-things

Wendzel, S. (2018). IT-Sicherheit für TCP/IP- und IoT-Netzwerke: Grundlagen, Konzepte, Protokolle, Härtung. Wiesbaden: Springer Fachmedien Wiesbaden GmbH. Abgerufen von http:// www.springer.com/

Westhoff, D. (2020). Mobile Security: Schwachstellen verstehen und Angriffsszenarien nachvollziehen. Berlin: Springer Vieweg. doi: 10.1007/978-3-662-60855-5 Wireshark. (2021). Wireshark • Go Deep. Abgerufen am 26.03.2021 von https://www.wireshark.org/

Wisser, K. (2018). Gebäudeautomation in Wohngebäuden (Smart Home): Eine Analyse der Akzeptanz. Wiesbaden: Springer Fachmedien Wiesbaden. doi: 10.1007/978-3-658-23226-9 Yassein, M. B. et al. (2019). Smart Home Is Not Smart Enough to Protect You - Protocols, Challenges and Open Issues. Procedia Computer Science, 160, S.134-141. doi: 10.1016/j.procs.2019.09.453

Anhang 1: Einrichtung eines Access Points auf dem Raspberry Pi Um einen Access Point aufzubauen, ist zum einen die Access Point Software erforderlich. Zum anderen braucht man einen DHCP-Server, der die dynamisch IP-Adressen für die Clients verteilt. Hier die exemplarische Einrichtung des Access-Points (Elektronik-Kompendium, o.J.):

Abbildung in dieser Leseprobe nicht enthalten

Häufig gestellte Fragen zu diesem Sprachentwurf

Was ist das Ziel dieser Arbeit zum Thema Smart Home Sicherheit?

Das Ziel ist es, ein sicheres Modell für den Betrieb eines Smart Homes zu entwickeln. Dies beinhaltet die Ermittlung des Stands der Technik, möglicher Angriffspunkte und die Definition von Sicherheitsanforderungen.

Welche Kernkomponenten werden in diesem Modell für ein sicheres Smart Home verwendet?

Zu den Kernkomponenten gehören ein Raspberry Pi (als Smart Home Hub und CCU-Ersatz), HomeMatic/HomeMatic IP Aktoren, eine schaltbare WLAN-Steckdose und eine Fritzbox als WAN-Anbindung.

Welche Software wird für den Testaufbau des Smart Homes verwendet?

Es werden openHabian als Betriebssystem, openHAB als Smart Home Hub Software und RaspberryMatic als CCU-Ersatz verwendet.

Welche Prinzipien liegen dem Design eines sicheren Smart Homes zugrunde?

Die Prinzipien sind: Sicherheit durch Trennung von Smart Home und privaten Netzen, Sicherheit durch kanalisierten Zugang zum Smart Hub durch VPN und Sicherheit durch gesteuerte Updates.

Welche Perspektiven werden bei der Untersuchung der Smart Home Sicherheit berücksichtigt?

Es werden die Perspektiven der Wahrnehmungsschicht, der Netzwerkschicht und der Anwendungsschicht betrachtet.

Welche Sicherheitsziele werden in dem Modell verfolgt?

Die wesentlichen Sicherheitsziele sind Vertraulichkeit, Integrität und Verfügbarkeit.

Welche Tools werden für die Designevaluation und Schwachstellenanalyse eingesetzt?

Es werden Kali Linux, NMAP, openVAS, Metasploit und Snort verwendet.

Wie wird die Trennung von Smart Home und privaten Netzen im Modell realisiert?

Die Trennung erfolgt durch den Einsatz einer Firewall auf dem Smart Home Hub, die den Datenverkehr zum privaten Netzwerk sperrt.

Wie wird der Zugriff auf den Smart Home Hub von außerhalb gesichert?

Der Zugriff erfolgt über eine VPN-Verbindung zum Router, wodurch ein kanalisierter und verschlüsselter Zugang gewährleistet wird.

Wie werden Updates der Smart Home Komponenten gesteuert?

Updates werden manuell initiiert und gesteuert, um unkontrollierte Aktualisierungen zu vermeiden. Eine lokale Firewall blockiert standardmäßig jeglichen ausgehenden Datenverkehr, der nur für Updates freigegeben wird.

Welche Handlungsempfehlungen werden für ein "Future Proof" Smart Home gegeben?

Empfehlungen sind: Aufbau eines sicheren Smart Home Netzwerks, Verwendung vertrauenswürdiger Hardware, Verschlüsselung der Kommunikation, regelmäßige Penetrationstests, sichere Passwörter und der Einsatz eines Intrusion Detection Systems.

Welche Funkstandards werden im Smart Home verwendet, und welche Sicherheitsaspekte sind dabei zu beachten?

Es werden verschiedene Funkstandards wie Z-Wave, ZigBee, DECT-ULE und HomeMatic IP genutzt. Wichtig ist, auf die Verschlüsselung der Datenübertragung zu achten und unsichere Protokolle zu vermeiden.

Wie wird die Integrität und Vertraulichkeit der Daten im Smart Home gewährleistet?

Die Integrität und Vertraulichkeit werden durch verschlüsselte Kommunikationswege, die Trennung von Netzwerken und den kanalisierten Zugang zum Smart Home Hub sichergestellt.

Was ist ein Smart Home Hub und welche Rolle spielt er in diesem Modell?

Der Smart Home Hub ist das Kernstück des Smart Homes. Er ist die zentrale Komponente, die alle Informationen sendet, empfängt und verarbeitet.