FHCW ITS20 Masterarbeit Friedrich Haidn

Informationssicherheitsrisiken in der Heimautomatisierung

Am Beispiel der praktischen Implementierung von eQ-3 HomeMatic, eQ-3 HomeMatic IP und RaspberryMatic

Information security risks in home automation Using the example of the practical implementation of eQ-3 HomeMatic, eQ-3 HomeMatic

IP and RaspberryMatic

Masterarbeit

Zur Erlangung des akademischen Grades

Master of Science in Engineering

der Fachhochschule FH Campus Wien

Masterstudiengang: IT-Security

Vorgelegt von:

Friedrich Haidn

Personenkennzeichen:

1810537004

Erstbetreuer/Erstbegutachter:

Manuel Koschuch

Eingereicht am:

04.07.2020

Erklärung:

Ich erkläre, dass die vorliegende Masterarbeit von mir selbst verfasst wurde und ich keine

anderen als die angeführten Behelfe verwendet bzw. mich auch sonst keiner unerlaubter

Hilfe bedient habe.

Ich versichere, dass ich diese Masterarbeit bisher weder im In- noch im Ausland (einer

Beurteilerin/einem Beurteiler zur Begutachtung) in irgendeiner Form als Prüfungsarbeit

vorgelegt habe.

Weiters versichere ich, dass die von mir eingereichten Exemplare (ausgedruckt und

elektronisch) identisch sind.

Datum: ................................ Unterschrift: ..............................................................

iii

Kurzfassung

Diese Arbeit beschäftigt sich mit Risiken aus dem Themengebiet der

Informationssicherheit, die sich aus dem Einsatz von Heimautomatisierungslösungen

ergeben. Zur Beantwortung der Forschungsfragen werden drei Lösungen der

Heimautomatisierung, zwei davon für den weiteren Realbetrieb, aufgebaut und analysiert.

Die Systeme werden nach definierten Anforderungen auf zwei reale Standorte zugewiesen

und die Komponenten implementiert. Die Arbeit beschäftigt sich sowohl mit der

technischen Sicherheit als auch mit der Komplexität der Lösungen. Die Analyse des

Funkprotokolls bringt einen tiefen Einblick in den proprietären Funkstandard des

Herstellers. Das Ergebnis der Sicherheitsanalysen zeigt nicht nur Schwachstellen in der

technischen Implementierung durch die Hersteller auf, sondern identifiziert

Informationssicherheitsrisiken, die nicht nur technisch bedingt sind. Ein abschließender

Vergleich der drei Lösungen gibt u.a. ein klares Bild, wie die einzelnen Lösungen

sicherheitstechnisch einzuordnen und für welche Zielgruppen sie geeignet sind. Die

Darstellung der identifizierten Informationssicherheitsrisiken in Zusammenhang mit

Mitigationsmaßnahmen schaffen die Basis für einen qualifizierten Umgang mit den

identifizierten Risiken und veranschaulichen die Wichtigkeit eines

Sicherheitsbewusstseins über Technologien, die im privaten Umfeld zum Einsatz kommen.

iv

Abstract

This thesis deals with risks in the area of information security that result from the use of

home automation solutions. To answer the research questions, three home automation

solutions, two of which are used for further real operation, are being set up and analysed.

The systems are assigned to two real locations according to defined requirements and the

components are implemented. The work deals with the technical security as well as with

the complexity of the solutions. The analysis of the radio protocol provides a deep insight

into the proprietary radio standard of the manufacturer. The result of the security analysis

not only shows weaknesses in the technical implementation by the manufacturer, but also

identifies information security risks that are not just technical. A final comparison of the

three solutions gives among others a clear picture of how to classify the individual solutions

in terms of security and for which target groups they are suitable. The presentation of the

identified information security risks in conjunction with mitigation measures create the basis

for a qualified handling of the identified risks and illustrate the importance of security

awareness about technologies that are used in the private environment.

v

Abkürzungsverzeichnis

Abb. Abbildung

AES Advanced Encryption Standard

AG Aktiengesellschaft

API Application Programming Interface

ARM Advanced RISC Machines

ASLR Address Space Layout Randomization

ASVS Application Security Verification Standard

Az. Aktenzeichen

BACnet Building Automation and Control Networks

BidCoS Bidirectional Communication Standard

Bit Binary digit

BSI Bundesamt für Sicherheit in der Informationstechnik

Bsp.: Beispiel

CBC Cipher Block Chaining

CCM Cipher block chaining

CCU Central-Control-Unit

CERT Computer Emergency Response Team

CI/CD Continuous Integration/Continuous Delivery

CO2 Kohlenstoffdioxid

COBIT Control Objectives for Information and Related Technology

CRC Cyclic Redundancy Check

CUL CC1101 USB Lite

CVE Common Vulnerabilities and Exposures

CVSS Common Vulnerability Scoring System

dBm Dezibel Milliwatt

DHCP Dynamic Host Configuration Protocol

DIE Integrated Development Environment

DIN Deutsche Industrie-Norm

ECB Electronic Code Book

ECDHE Elliptic Curve Diffie-Hellman Ephemeral

EG Europäische Gemeinschaft

EN Europäische Norm

EU Europäische Union

FTEG Funkanlagen und Telekommunikationsendeinrichtungen

GCM Galois/Counter Mode

vi

GLT Gebäudeleittechnik

GPL General Public License

GPRS General Packet Radio Service

GSM Global System for Mobile communication

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

IPsec Internet Protocol Security

ISF Information Security Forum

ISM Industrial, Scientific and Medical Band

ISO International Organization for Standardization

IT Informationstechnik

ITIL Information Technology Infrastructure Library

JDK Java Development Kit

KNX Konnex-Bus

LAN Local Area Network

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

LON Local Operating Network

MAC Message Authentication Code

MD5 Message-Digest Algorithm 5

MHz Megahertz

microSD micro Secure Digital Memory Card

Ms Millisekunde

MSR Mess-, Steuerungs- und Regelungstechnik

mW Milliwatt

NAT Network Address Translation

NIST National Institute of Standards and Technology

Nonce Number used once

Nr. Nummer

OS Operating System

ÖVSV Österreichischer Versuchssenderverband

OWASP Open Source Foundation for Application Security

PC Personal Computer

vii

PCI DSS Payment Card Industry Data Security Standard

PoC Proof of Concept

REST Representational State Transfer

RF Radiofrequenz

RFID Radio Frequency Identification

RPC Remote Procedure Call

RSA Rivest-Shamir-Adleman

RSSI Received Signal Strength Indication

SDL Security Development Lifecycle

SDLC Software Development Life Cycle

SHA Secure Hash Algorithm

SIEM Security Information and Event Management

SPI Serial Peripheral Interface

SQL Structured Query Language

SRD Short Range Device

SSH Secure Shell

SSL Secure Socket Layer

TCP Transmission Control Protocol

TLS Transport Layer Security

u.a. unter anderem

UrhG Urheberrechtsgesetz

URI Uniform Resource Identifier

USB Universal Serial Bus

UTM Unified Threat Management

vgl. vergleiche

VLAN Virtual Local Area Network

VM Virtual Machine

VPN Virtual Private Network

WLAN Wireless Local Area Network

WLAN Wireless Local Area Network

XML Lightweight Directory Access Protocol

XOR eXclusive OR

XSS Cross-site scripting

XXE XML External Entity

z.B. zum Beispiel

ZAP Zed Attack Proxy

viii

Schlüsselbegriffe

AES-CCM

Bedrohungsanalyse

BidCoS

Gebäudeautomation

Heimautomatisierung

HomeMatic

Informationssicherheitsrisiken

OWASP

Raspberry Pi

RaspberryMatic

Schwachstellen

Sicherheitsanalyse

Smart Home

ix

Inhaltsverzeichnis

1. EINFÜHRUNG ........................................................................................... 1

1.1. Motivation und Aufgabenstellung ................................................... 2

1.2. Forschungsfragen ............................................................................ 4

1.3. State of the Art & Related Work ...................................................... 5

1.4. Struktur der Arbeit ............................................................................ 5

2. GRUNDLAGEN .......................................................................................... 6

2.1. Heimautomatisierung/Smart Home ................................................. 6

2.1.1. Ebene der konventionelle Elektroinstallation .............................................. 7

2.1.2. Feldebene.................................................................................................. 7

2.1.3. Automationsebene ..................................................................................... 8

2.1.4. Leitebene/Managementebene ................................................................... 8

2.1.5. Anwendungsgebiete .................................................................................. 9

2.1.6. Einteilung der Systeme ............................................................................ 11

2.1.7. Interoperabilität und Objektabhängigkeit .................................................. 13

2.1.8. Heimautomationssysteme und das Internet der Dinge (IoT) .................... 14

2.2. Informationssicherheit und -risiken ............................................. 15

2.2.1. Begriffe .................................................................................................... 15

2.2.2. Informationssicherheit im privaten Bereich............................................... 18

2.3. Sicherheitsanalysen ....................................................................... 19

2.3.1. Lebenszyklus von Anwendungen und sicherere Softwareentwicklung ..... 19

2.3.2. Nutzen ..................................................................................................... 21

2.3.3. Penetrationstest und abschließende Security Reviews ............................ 22

2.3.4. Rechtliche Aspekte .................................................................................. 23

2.4. Kryptographie in der Funkübertragung ....................................... 27

2.4.1. Advanced Encryption Standard (AES) ..................................................... 27

2.4.2. Betriebsarten ........................................................................................... 28

2.4.3. Authentifizierung ...................................................................................... 30

3. SICHERHEITSANALYSE DER LÖSUNGEN .................................................. 32

3.1. Auswahl der Methodik und Werkzeuge ........................................ 32

3.1.1. Methodik .................................................................................................. 32

3.1.2. Werkzeuge .............................................................................................. 36

3.2. HomeMatic ....................................................................................... 41

3.2.1. Anforderungen und Lösungszuordnung ................................................... 41

3.2.2. Garantien des Herstellers ........................................................................ 43

x

3.2.3. Implementierung und Funktion................................................................. 44

3.2.4. Sicherheitsanalyse ................................................................................... 49

3.2.5. Kurzzusammenfassung der Ergebnisse ................................................... 58

3.3. RaspberryMatic ............................................................................... 58






3.4. HomeMatic IP .................................................................................. 66






3.5. Kommunikationsstandard ............................................................. 75

3.5.1. Quellen .................................................................................................... 75

3.5.2. Telegramme ............................................................................................ 76

3.5.3. Ungesicherte Verbindung ........................................................................ 77

3.5.4. Gesicherte Verbindung ............................................................................ 80

3.5.5. Laufzeitunterschiede ................................................................................ 84

3.5.6. Geräte anlernen und Schlüsseländerung ................................................. 85

3.5.7. Statistik und Privatsphäre ........................................................................ 86

3.6. Vergleich der Systeme ................................................................... 89

4. INFORMATIONSSICHERHEITSRISIKEN ....................................................... 91

4.1. Bedrohungsanalyse ....................................................................... 91

4.2. Risiken ............................................................................................. 93

4.3. Möglichkeiten zur Risikomitigation .............................................. 97

5. CONCLUSIO ......................................................................................... 101

5.1. Zusammenfassung ....................................................................... 101

5.2. Beantwortung der Forschungsfragen ........................................ 101

5.3. Future Work ................................................................................... 103

LITERATURVERZEICHNIS ............................................................................. 104

ABBILDUNGSVERZEICHNIS .......................................................................... 112

TABELLENVERZEICHNIS .............................................................................. 114

xi

ANHANG A – QUELLCODE BIDCOS-SNIFFER ............................................... 115

ANHANG B – HOMEMATIC CCU3 PRÜFUNG MIT SSH-AUDIT ......................... 119

ANHANG C – HOMEMATIC NESSUS SCAN-ERGEBNIS ................................... 122

ANHANG D – PROOF OF CONCEPT CVE-2019-9727 .................................... 124

ANHANG E – RASPERRYMATIC NESSUS SCAN-ERGEBNIS ........................... 125

ANHANG F – HOMEMATIC IP MOBILE APP - MOBSF ANALYSE ..................... 126

ANHANG G – BIDCOS TELEGRAMM AUTHENTIFIZIERUNG ............................. 127

1

1. Einführung

Der Grundstein für die private Digitalisierung wurde bereits am Anfang der 1970er Jahre

gelegt. Intel präsentierte einen Chip, auf dem eine Reihe von Transistoren auf kleinstem

Raum untergebracht waren (vgl. [MÄB12]). Diese Chips mit zunächst einfachen

Schaltaufgaben wurden weiterentwickelt und komplexer, allerdings auch kleiner, günstig in

Massen zu produzieren und damit dem privaten Markt zugänglich. Mitte der 1970er Jahre

begann mit dem legendären „Altair 8800“ (vgl. [MÄB12]) die Ära der Heimcomputer.

Parallel dazu wurden die Chips zu Mikrorechnern weiterentwickelt und Peripherie-

Bausteine erweitert. Das Ein-Chip-System, System-on-a-chip (SoC) – der Mikrokontroller

– war geboren (vgl. [MEB14]). Mikrocontroller sind in der heutigen Steuer- und

Regelungstechnik nicht mehr wegzudenken. Die Möglichkeit, Einplatinencomputer und

Mikrocontroller in immer größeren Stückzahlen und auch günstiger zu produzieren, hat in

fast jedem Haushalt zum Einzug der Computertechnologie geführt. Das seit Anfang der

1990er-Jahre der Öffentlichkeit zugängliche World Wide Web, das Internet, vernetzte nun

auch global die Haushalte und eine weite Kommerzialisierung war und ist damit begleitet

(vgl. [MÄB12]).

Technologie soll den Menschen unterstützen und mehr Komfort bringen. Damit liegt nahe,

dass man sich im Eigenheim ebenfalls mit den „kleinen Helfern“ umgibt, die einem

automatisierbare Arbeit abnehmen und die Bequemlichkeit steigern sollen. Diese

Absatzmöglichkeit im Bereich der Consumer*innen/Verbraucher*innen haben einige

Technologie-Unternehmen erkannt und eine Vielzahl von Produkten für die

Hausautomation (Smart Home) auf den Markt gebracht. Die Kommunikationsfähigkeit der

„kleinen Helfer“ mit dem Internet hat Ende der 1990er-Jahre zur Formulierung des Begriffs

„Internet der Dinge“/„Internet of Things“ (IoT) geführt. In diesem Zusammenhang wird auch

von einer weiteren industriellen Revolution gesprochen. Bei der Heimautomatisierung für

die breite Masse geht es darum, Überwachungs- und Steueraufgaben an die intelligenten

Geräte zu übertragen, die einem das Leben erleichtern sollen. Zentral gesteuerte Sensoren

und Aktoren sollen dabei z.B. Rollläden bei Bedarf automatisch schließen, Licht bei

Dunkelheit einschalten, Heizelemente nach Bedarf steuern und bei einer Rauch- oder

Einbruchserkennung alarmieren. Idealerweise lässt sich solch ein System von der Ferne

mit einem Smartphone oder Tablet bedienen. Stehen für die Hersteller Absatzzahlen im

Vordergrund, so erhoffen sich die Verbraucher*innen einen erhöhten Komfort, mehr

Sicherheit und durchaus auch Einsparungen beim Energieverbrauch. Sicherheitsrelevante

Themen, die sich durch die Beschaffenheit und den Betrieb der Systeme selbst ergeben,

scheinen ob der Sicherheitswarnungen in der Fachpresse nicht im Primärfokus der

Hersteller zu liegen. So berichtet z.B. Heise über tausende angreifbare Smart Home-

Geräte (vgl. [HEI19]) und über eine Warnung des deutschen CERT-Bund über tausende

HomeMatic-Systeme, die aus dem Internet erreichbar sind (vgl. [HEI819]).

Gemäß der Einschätzung eines führenden Anbieters (Statista) für Markt- und

Konsumentendaten steigt der Absatz von Smart Home-Lösungen auch in Österreich stetig

an. Im Jahr 2020 sollen 0,7 Millionen Haushalte mit einer Smart Home-Lösung

2

ausgestattet sein, im Jahr 2023 sieht Statista bereits eine Durchdringung von 1,1 Millionen

Haushalten, wobei der durchschnittliche Umsatz pro Haushalt im Jahr 2020 bei EURO

477,10 und im Jahr 2023 bei EURO 441,38 liegen soll (vgl. [STAA20]).

Die gegenständliche Arbeit befasst sich mit den Informationssicherheitsrisiken im

Zusammenhang mit dem Einsatz von Smart Home-Systemen anhand konkreter und

praktischer Implementierungen. Die Risiken sollen durch Sicherheitsanalysen aufgezeigt

und Beispiele zur Mitigation der Risiken gegeben werden. Eine grundlegende

Auseinandersetzung mit dem Rechtsrahmen um Sicherheitsanalysen ist ebenfalls

Bestandteil der Arbeit.

1.1. Motivation und Aufgabenstellung

Wie bereits in der Einleitung erwähnt erfreuen sich Smart Home-Lösungen zunehmender

Beliebtheit. Im Bereich der Heimautomatisierung steht sich am Europäischen Markt eine

Vielzahl von Anbieter*innen gegenüber (vgl. [SH2M16]). Das deutsche Unternehmen eQ-

3 AG [eQ3C1] wurde von dem renommierten Marktforscher Berg Insight zum fünften Mal

in Folge zum Marktführer in Europa erklärt [eQ320]. Im Jahr 2013 zeigten zwei

Sicherheitsforscher (Sathya Laufer und Christian Mallas) auf dem Chaos Communication

Congress des Chaos Computer Clubs in Hamburg, wie sie die Sicherheitsmechanismen

der HomeMatic-Lösung umgehen und sogar ein elektrisches Türschloss kontrollieren

konnten (vgl. [SaMa13]). Daher liegt nahe, die Lösung des Marktführers genauer zu

analysieren und ggf. Schwachstellen im Sinne der Informationssicherheit zu identifizieren.

Nicht zuletzt liegen die Erkenntnisse dieser Arbeit im persönlichen Interesse des Autors,

da zwei der drei Implementierungen der Smart Home-Lösungen für den Realgebrauch des

Autors an seinen beiden Wohnsitzen dienen sollen.

Zum besseren Verständnis der Aufgabenstellungen, werden die drei gegenständlichen

HomeMatic-Lösungen kurz vorgestellt.

eQ-3 AG HomeMatic

Sämtliche eingesetzte Komponenten (Sensoren, Aktoren und das zentrale

Steuersystem) befinden sich lokal am Einsatzort. Die Kommunikation zwischen

den Komponenten ist funkbasiert. Für die Interaktion zwischen dem*der

Benutzer*in und dem zentralen Steuersystem steht ein webbasiertes

Benutzer*inneninterface zur Verfügung.

3

eQ-3 AG HomeMatic IP

Sämtliche Sensoren und Aktoren befinden sich lokal am Einsatzort. Das

zentrale Steuersystem wird durch einen Cloud-Dienst bereitgestellt und durch

ein lokal vorhandenes Gateway zur Funkkommunikation mit den lokalen

Komponenten unterstützt. Die Interaktion zwischen dem*der Benutzer*in und

dem Cloud-basierten Steuersystem erfolgt über eine Applikation, die für Apple

iOS-basierte Geräte und für Android-basierte Geräte genutzt zur Verfügung

steht.

RaspberryMatic

Ähnlich der HomeMatic-Lösung befinden sich sämtliche eingesetzte

Komponenten (Sensoren, Aktoren und das zentrale Steuersystem) lokal am

Einsatzort. Die Kommunikation zwischen den Komponenten ist funkbasiert. Die

Interaktion zwischen dem*der Benutzer*in und dem zentralen Steuersystem

erfolgt über ein webbasiertes Benutzer*inneninterface. Das zentrale

Steuersystem basiert jedoch lediglich auf dem Software Development Kit der

eQ-3 AG und wird von einer Community bereitgestellt. Die Sensoren und

Aktoren sind Produkte der eQ-3 AG.

Zunächst müssen für die beiden Wohnobjekte funktionelle Anforderungen erstellt werden,

auf Basis derer die Zentrale und die einzelnen Sensor- und Aktor-Komponenten

ausgewählt werden. Da nur zwei Standorte für einen Komplettausbau zur Verfügung

stehen, muss die dritte Implementierung auf einen exemplarischen Versuchsaufbau

reduziert werden. Für die Betrachtung der Informationssicherheitsrisiken muss eine

Referenz ausgewählt, beschrieben und mit der Anwendung im privaten Bereich in

Zusammenhang gebracht werden. Für die technischen Analysen muss so weit als möglich

ein tiefes Verständnis über den Aufbau und die Funktionsweise der Lösungen erarbeitet

werden. Eine Beschreibung der einzelnen Lösungen im Detail sowie die dazugehörigen

Grundlagen sind obligatorisch – sofern im Kontext der Informationssicherheit relevant. Alle

drei Lösungen verwenden das proprietäre und nicht offengelegte Funkprotokoll BidCoS

(Bidirectional Communication Standard) der eQ-3 AG zur Kommunikation zwischen der

zentralen Steuereinheit und den Sensoren und Aktoren bzw. zwischen den Sensoren und

Aktoren untereinander auf den Frequenzen 868 MHz und 869 MHz. Für die Analyse des

Funkprotokolls müssen allgemein zugängliche Informationen gesammelt und mit eigener

Beobachtung kombiniert werden. Dazu muss eine entsprechende Hard- und Software

ausgewählt werden, um die Funkübertragungen beobachten und in weiterer Folge selbst

analysieren zu können. Ggf. können Angriffsversuche durch eigens versendete

Nachrichten unternommen werden. Zur Prüfung der technischen Sicherheit müssen

standardisierte Kriterien ermittelt werden, wonach eine Sicherheitsanalyse durchgeführt

werden kann. Für die technischen Prüfungen müssen geeignete Tools identifiziert, kurz

vorgestellt und für die Analyse eingesetzt werden. Um bei der technischen Analyse keine

Risiken einer Rechtsverletzung einzugehen, muss der rechtliche Rahmen, in dem

technische Sicherheitsanalyse an erworbenen Produkten durchgeführt werden können,

4

dargestellt werden. Die gewonnenen Erkenntnisse schaffen die Basis für die Beantwortung

der Forschungsfragen, für die Überlegung risikominimierender Maßnahmen als auch für

Überlegungen weiterführender Arbeiten.

Eine Betrachtung anderer Anbieter*innen als der genannten – außer ggf. deren

Namensnennung – ist nicht Teil der Arbeit, ebenso nicht praktische Side-Channel-Angriffe.

Die Hardware und Firmware der Sensoren und Aktoren wird nicht näher analysiert, als

dazu öffentlich zugängliche Informationen bereitstehen. Ein Penetrationstest gegen den in

der Cloud befindlichen Teil der Systeme wird nicht zuletzt wegen rechtlichen

Abhängigkeiten ausgeschlossen. Komponenten oder Systeme der genannten Hersteller,

die nur von konzessionierten Fachkräften implementiert werden dürfen (z.B.

Steuerkomponenten in Elektroverteilerschränken), sind nicht Teil der Betrachtung der

Arbeit. Erweiterungsmöglichkeiten der genannten Systeme im Bereich der Integration mit

anderen Herstellern werden ggf. nur bis zu deren Schnittstellen – sofern in den Kontext

passend – exemplarisch behandelt. Von der praktischen Einbindung von

Türschlossantrieben wird aus Kosten- und Sicherheitsgründen Abstand genommen.

1.2. Forschungsfragen

Durch die Betrachtung der einzelnen Lösungen im Detail – anhand praktischer

Implementierungen im Kontext der auf den privaten Bereich umgelegten

Informationssicherheitsziele – werden die folgenden Forschungsfragen beantwortet:

• Welche Informationssicherheitsrisiken ergeben sich durch den Einsatz der

Lösungen?

• Welche Sicherheitsgarantien bestehen seitens der Hersteller und was enthalten

diese?

• Warum warnen die Hersteller davor, ihre lokal implementierten Steuerzentralen

über den eigenen Router über Portweiterleitung im Internet zur Verfügung zu

stellen?

• Wie sieht eine konkrete Implementierung der einzelnen drei Lösungen aus und

welche Kosten sind dafür vorzusehen?

• Wie kann ein Betrieb der einzelnen Lösungen abgesichert und die Risiken auf ein

akzeptables Maß reduziert werden?

• Wie sicher sind die einzelnen Lösungen im Vergleich?

5

1.3. State of the Art & Related Work

Für die Heimautomatisierung existiert kein einheitlicher Stand der Technik, der die

einzelnen technischen Disziplinen nicht zuletzt im Sinne der IT- bzw. Informationssicherheit

beschreiben könnte. Die eingesetzten Technologien reichen von Eigenentwicklungen der

Hersteller bis zur Kombination mit bewährten Technologien unter teilweiser Einbeziehung

von Standards. Die Arbeit von Bastian van Venrooy [BVSH16] aus dem Jahr 2016 setzt

sich bereits mit der Sicherheit der Heimautomatisierung sowie u. a. mit der Sicherheit des

HomeMatic Funkstandards auseinander und beschreibt u.a. dabei einige etablierte

Technologien. Die gegenständliche Masterarbeit soll sich daher nicht nur auf Teilbereiche

von z.B. Analysen des Funkprotokolls (vgl. [MGDH15], [HPOSA]) beschränken, sondern

eine exemplarische Gesamtsicht auf die Informationssicherheit und den damit

verbundenen Risiken geben, die durch den Einsatz von Heimautomatisierungssystem

entstehen können.

1.4. Struktur der Arbeit

Diese Arbeit ist wie folgt strukturiert:

Kapitel 1 führt an das Thema heran, stellt die Forschungsfragen und gibt eine kurze

Übersicht über verwandte Arbeiten. Im Kapitel 2 werden die Grundlagen zur

Heimautomatisierung, Informationssicherheitsrisiken und Sicherheitsanalysen ausgeführt.

Zusätzlich wird ein Überblick über kryptografische Verfahren gegeben, das zu einem

besseren Verständnis der in Kapitel 3 durchgeführten Analyse der Funkübertragung führen

soll. Das Kapitel 3 beschreibt die entwickelte Methodik für die Sicherheitsanalysen als auch

die zur Anwendung kommenden Werkzeuge. Ebenso setzt sich das Kapitel 3 mit den

einzelnen der drei ausgewählten Lösungen auseinander und schließt mit einem Vergleich

ab. Das Kapitel 4 führt über Bedrohungsanalysen zu Informationssicherheitsrisiken und

deren Möglichkeiten zur Mitigation über. Das Kapitel 5 zieht ein Resümee über die

Erkenntnisse aus der Arbeit, beantwortet die Forschungsfragen und gibt einen Ausblick auf

weiterführende Arbeiten.

6

2. Grundlagen

Im folgenden Abschnitt werden die Grundlagen der Gebäude-/Heimautomatisierung, der

Informationssicherheit respektive die -risiken und die Sicherheitsanalyse in Verbindung mit

rechtlichen Aspekten beschrieben.

2.1. Heimautomatisierung/Smart Home

In den 1960er Jahren wurden die Begriffe Mess-, Steuer- und Regelungstechnik (MSR-

Technik) und in Folge der Begriff Gebäudeleittechnik (GLT) geprägt. Messen, Steuern und

Regeln bilden die Grundbausteine der Gebäudeautomation. Die Heimautomatisierung

stellt einen Teilbereich der Gebäudeautomatisierung dar und bezieht sich auf

Wohngebäude (auch Gebäudeteile wie Wohnung, Zimmer). Die Begriffe

Heimautomatisierung und Smart Home werden mittlerweile als Synonyme für ein

intelligentes System verwendet (vgl. [GiW18, Kap. 1.3]).

Der Begriff Smart Home:

„Smart Home dient als Oberbegriff für technische Verfahren und Systeme in Wohnräumen

und -häusern, in deren Mittelpunkt eine Erhöhung von Wohn- und Lebensqualität,

Sicherheit und effizienter Energienutzung auf Basis vernetzter und fernsteuerbarer Geräte

und Installationen sowie automatisierbarer Abläufe steht“ [GiW18, Kap. 1.3]

Abgeleitet von der Gebäudeautomatisierung ist auch die Heimautomatisierung in drei

Ebenen aufgebaut. Die Ebenen im Gesamten bilden ein Netzwerk (Feldnetzwerk,

Automationsnetzwerk, Management-/Leitnetzwerk), das die Kommunikation zwischen den

Komponenten sicherstellt. Mit steigernden funktionalen Anforderungen erhöhen sich

allerdings auch die Anforderungen an diese Netzwerke der Heimautomatisierung. Es

kommt zur Mischung verschiedener Heimautomatisierungssystem und damit zu weiteren

Schnittstellen zwischen den einzelnen Ebenen (vgl. [GiW18, Kap. 2.1]).

Abb. 1: Ebenen der Gebäude-/Hausautomatisierung (vgl. [GiW18, Kap. 2.1])

7

Abbildung 1 zeigt die drei Ebenen der Gebäude-/Hausautomatisierung, die Leit- oder

Managementebene, die Automationsebene und die Feldebene sowie die konventionelle

Ebene der Elektroinstallation, die als Basis der drei Ebenen gilt. Die in der Grafik als orange

gekennzeichneten Verbindungen zwischen den Ebenen stellen die Schnittstellen dar (vgl.

[GiW18, Kap. 2.1]).

2.1.1. Ebene der konventionelle Elektroinstallation

Diese Ebene wird durch die Haus-/Wohnungszuleitung, den Verteiler- /Zählerschrank und

die einzelnen Stromkreise, die Verteilung auf Räume und Verbraucher, im Objekt gebildet.

Die Wichtigkeit dieser Ebene wird eindeutig, wenn man die Anforderungen einer Gebäude-

/Hausautomatisierung an diese Ebene durch bestehende Installation kaum erfüllen kann.

Eine Anpassung bestehender Verkabelungen ist meist mit hohem Aufwand verbunden,

sofern nicht nur die Leistungskapazität nachgebessert werden muss. (vgl. [GiW18, Kap.

2.1.1]). Selbst bei mehreren verfügbaren Stromkreisen pro Raum wäre aus dem

Verteilerschrank grundsätzlich nur ein Einfaches Ein- und Ausschalten möglich. Bei der

Möglichkeit einer Neuplanung haben sich Bussysteme durchgesetzt, die getrennt von der

Energieversorgung Informationen über separate Leitungen übertragen. Diese Bussysteme

sind in den drei Hauptebenen der Gebäude-/Hausautomatisierung Leitebene,

Automationsebene und Feldebene vertreten (vgl. [GiW18, Kap. 2.1.1]). Auf Grund der

hohen Aufwände für eine Nachrüstung eines Bussystem in bestehenden Gebäuden, hat

sich als Ersatz oder Ergänzung die Funkkommunikation etabliert.

2.1.2. Feldebene

In der Feldebene sind die Sensoren und Aktoren angesiedelt. Das sogenannte

Feldbussystem stellt die Kommunikation zwischen den Komponenten sicher. Sensoren

erfassen Daten aus der Umgebung, wie z.B. Temperatur, Lichtintensität oder den

Öffnungs- bzw. Schließzustand von Fenstern oder Türen. Diese Messdaten oder Zustände

werden über den Feldbus versendet. Diese Signale bzw. Nachrichten werden in den

Hauptebenen je nach Systemdesign und Programmierung interpretiert und verarbeitet. Die

aus der Verarbeitung resultierenden Befehle werden wiederum über den Feldbus an die

Aktoren gesendet, die für die Ausführung der Anweisungen verantwortlich sind. Es ist

allerdings auch möglich, dass Aktoren in der Feldebene direkt die Nachrichten von

Sensoren empfangen und verarbeiten können und ohne weitere höhere Ebenen

eigenständige Schaltfunktionen auch nach einer eigenen Verarbeitungslogik ausführen

können. Als Beispiele für diese eigenständige Sensor/Aktor Steuerung können die

Temperatur- und Lüftungssteuerung, die Verschattungssteuerung, die Steuerung der

Beleuchtung und die Bewässerungssteuerung genannt werden (vgl. [GiW18, Kap. 2.1.2]).

8

2.1.3. Automationsebene

Die Automationsebene sorgt für die logische Steuerung und Regelung. Es kommen unter

anderem Verknüpfungsbausteine Logikmodule und Controller zum Einsatz. Die

Kommunikation erfolgt ebenfalls über das Bussystem. Die Automationsebene übernimmt

u.a. die Zeitsteuerung, die Anwesenheitserkennung und die Steuerung von Zuständen.

Sensordaten über Temperatur, Luftfeuchtigkeit und Helligkeit werden verarbeitet und ggf.

sogar mit Wetterdaten kombiniert sowie Steuerbefehlt aus abgeleitet und versendet. Die

Heizungsregelung und das Energiemanagement sind ebenfalls Teilaufgaben dieser

Ebene. Grundsätzlich erfolgt ein Abgleich es vorher eingestellten Soll-Wertes mit einem

von Sensoren angelieferten Ist-Wert. Wird eine Abweichung zwischen den beiden Werten

festgestellt, wir ein entsprechender Befehlt an Aktoren übermittelt, bis der Ist-Wert im

Toleranzbereich des Soll-Werts ist. Durch zyklische Kontrolle des Ist-Werts gegen den

Soll-Wert und Steuern von Aktoren kann der gewünschte Soll-Wert erreicht werden. Auf

der Automationsebene können auch Selbstlernfunktionen realisiert werden, die zum

Beispiel bei der Heizungssteuerung lernen, bei welcher Ventileinstellung über welche Zeit

die gewünschte Temperatur am besten erreicht werden kann und auf Basis dieser erlernten

Zusammenhänge kann eine optimierte Steuerung erzielt werden (vgl. [GiW18, Kap. 2.1.3]).

2.1.4. Leitebene/Managementebene

Die Leit- oder Managementebene an der Spitze der Automations-Pyramide ist für die

Bedienbarkeit, die Visualisierung und Meldung von Störungen zuständig. Dabei können die

Visualisierungs- bzw. Bedienelemente von unterschiedlicher Art und Ausprägung sowie

stationär oder mobil sein. Die Realisierung reicht dabei u.a. von einer klassischen (Funk)-

Fernbedienung über fest installierte Touchscreens, klassische Personal Computer,

Laptops bis hin zu Smartphones und Tablets. Die ortsunabhängige Kommunikation mit der

Managementebene, damit die ortsunabhängige Visualisierung und Möglichkeit der

Steuerung, kann über Webapplikationen oder spezielle Apps realisiert werden. Die

Nutzung des Internets als Kommunikationsträger zwischen Anwender*innen und der

Managementebene hat die Möglichkeit des Zugriffs praktisch aus der ganzen Welt möglich

gemacht. Die Anforderung des Zugriffs auf die Managementebene ist nicht nur eine der

betrieblichen Gebäudeautomatisierung, sondern auch eine der Heimautomatisierung, des

Smarthome. So ist es möglich, dass auch das Eigenheim beobachtet werden kann, es

kann die gewünschte Temperierung eingestellt werden oder Geräte bedient werden.

Störungen von Systemkomponenten oder Komponenten, die angesteuert werden, wie z.B.

die Heizung oder die Beleuchtung, können durch die Zustandsüberwachung in der

Managementebene erkannt und darüber informiert werden. Dazu zählt auch die

Alarmierung über einen erkannten widerrechtlichen Zutritt, dem Einbruch. Dabei kann die

Meldung der Störung textuell, graphisch und auch akustisch auf dem Visualisierungs- bzw.

Bedienelement erfolgen (vgl. [GiW18, Kap. 2.1.4]).

9

2.1.5. Anwendungsgebiete

Die einzelnen Mess- und Steuerungsaufgaben lassen sich in Anwendungsfelder

zusammenfassen. Diese werden im Folgenden aufgezählt und kurz erläutert (vgl. [GiW18,

Kap. 2.2]).

Assistenzfunktionen für hilfsbedürftige Menschen (AAL)

Dieses Gebiet stellt eine Hilfestellung für ältere, kranke oder für Menschen mit sonstigen

Beeinträchtigungen zur Verfügung. Es können Geräte (z.B. Herd oder Backofen)

abgeschaltet werden, da auf das Ausschalten vergessen werden könnte. Für andere

Anwendungsgebiete können Sprachsteuerungsfunktionen zur Verfügung gestellt und

Zustandsänderungen auch über Sprache gemeldet werden. Spezielle Sensorik (u.a. durch

Bilderkennung gestützt) und Analysemethoden können das Bewegungsverhalten von

Personen analysieren und etwa einen Sturz oder die komplette Abwesenheit von

Bewegungen oder Vitalfunktionen einer anwesenden Person erkennen und automatisch

eine Rettungskette aktivieren.

Beleuchtung

In diesem Gebiet werden Funktionen zur Lichtmessung und Beleuchtungssteuerung

angeboten. Leuchtmittel können zeitgesteuert oder in Abhängigkeit der äußeren

Lichtverhältnisse geschalten oder gedimmt werden. Die Steuerung kann mit einer

Bewegungserkennung kombiniert werden, dass z.B. bei Dunkelheit automatisch die

Beleuchtung in einem bestimmten Abschnitt für eine gewisse Dauer eingeschaltet wird.

Erweitertes Energiemanagement und Smart Metering

Dieses Gebiet erweitert das Energiemanagement der anderen Anwendungsgebiete um

das automatisierte Messen und Melden des Energieverbrauch z.B. in den Bereichen

Strom, Wasser, Gas oder Öl. Die Visualisierung des Energieverbrauchs kann den*die

Nutzer*in dazu motivieren, den Verbrauch der einzelnen Energieressourcen zu reduzieren

und damit auch neben ökologischen Gesichtspunkten eine Kostenersparnis zu erzielen.

Smart Metering im sogenannten Smart Grid lassen den Energieversorger bessere

Möglichkeiten der ökologischen und ökonomischen Steuerung des Versorgungsnetzes

durch bessere Bedarfsvorhersage und eine Entlastung des Stromnetzes selbst. Auf der

Seite der Verbraucher*innen können in diesem Funktionsgebiet sogar Berechnungen

angestellt werden, wann ein veraltetes Gerät durch ein energieeffizienteres ausgetauscht

werden sollte.

Klimatisierung

Die Funktionen im Anwendungsgebiet der Klimasteuerung stellen u.a. das Wohlbehagen

der Bewohner*innen sicher. Gewünschte Soll-Temperaturen können für jeden Raum zu

jeder Zeit nach Wunsch erreicht werden. Bei Abwesenheit kann auf eine

10

Mindesttemperatur abgesenkt werden – z.B. während der Arbeit oder im Urlaub. Die

Systeme gleichen Soll- und Ist-Wert gegeneinander ab und reagieren im programmierten

Regelbereich. So kann entsprechend auch z.B. auf Basis von Luftfeuchtigkeitswerten die

Heizung oder eine vorhandene Lüftung angesteuert werden, um z.B. einer

Schimmelbildung entgegenzuwirken. Ebenso ist eine Alarmierung bei der Überschreitung

eines CO2-Grenzwertes realisierbar.

Multimedia und Unterhaltung

Neben der Steigerung des Nutzungskomforts kann die Gebäudeautomation auch

Multimedial- und Unterhaltungsfunktionen einbinden. In diesem Anwendungsgebiet

können Audio-, Video- und Bilddaten im Gebäudeautomationssystem integriert werden.

Der Konsum erfolgt dann etwa über Computer, Displays, Lautsprecher und mobile

Endgeräte wie Smartphone und Tablet. Die Ansteuerung einzelner Media-Endgeräte wie

Audiosysteme, Fernsehgerät oder Beamer wird über Schnittstellen, wie z.B. das Wireless

Lan (WLAN) durchgeführt.

Sicherheitsfunktionen

Dieses Anwendungsgebiet stellt verschiedene Sicherheitsfunktionen zur Verfügung, die

den Eintritt von Schäden oder deren Auswirkungen reduzieren sollen. Dazu gehört z.B. die

Einbruchserkennung, die Branderkennung und die Prävention von Wasserschäden sowie

eine damit verbundene Reaktion wie beispielsweise eine akustische und visuelle

Alarmierung vor Ort und ortsunabhängig an den*die Besitzer*in. Eine automatische

Verschattung und Anwesenheitssimulation bei Abwesenheit soll präventiv das

Einbruchsrisiko reduzieren. Diese Sicherheitsfunktionen in der Gebäudeautomation

ergänzen bautechnische Schutzmaßnahmen wie z.B. einbruchshemmende Fenster und

Türen. Eine Videoüberwachung der privaten Eingangsbereiche kann ebenfalls dazu

zählen. Es werden in diesem Gebiet auch elektronisch gestützte Zutrittsmittel, wie z.B.

RFID-Systeme (Radio-Frequency Identification), elektrische Schließzylinder und digitale

Schlüssel-Codes eingebunden. Ebenfalls fällt z.B. die Erkennung von Zutrittsberechtigten

zur Öffnung der Eingangstüren und Deaktivierung des Alarmsystems auf Basis von

biometrischen Merkmalen (Fingerabdruck) in dieses Anwendungsgebiet. Nicht allein durch

das Anwendungsgebiet der Sicherheitsfunktionen kommt der Datensicherheit des

Gebäudeautomationssystems ein hoher Stellenwert zu.

Stromkreissteuerung und Einbindung von Geräten

In dieses Anwendungsgebiet fällt die Schaltung einzelner Stromkreise, aber auch das

Schalten von Steckdosen, Verbraucher, die direkt an einen Stromkreis angeschlossen sind

oder von anderen eingebunden Geräten. Die Abschaltung von einzelnen Stromkreisen im

Verteilerschrank wird eher für Großverbraucher, wie z.B. Herd oder Backofen als Schutz

beim Verlassen des Gebäudes zum Einsatz kommen oder zur Reduktion von

elektromagnetischen Feldern (Elektrosmog). Einzelne Lichtquellen, wie z.B. Stehlampen

lassen sich über eingebundene Steckdosen ansteuern. Über verbundene Lichtschalter

11

können Beleuchtungsbereiche, wie z.B. in Vorzimmern oder Eingangsbereichen

umgebungslichtabhängig und durch Bewegungserkennung geschalten und ggf. gedimmt

werden. Auch die zeitliche oder umgebungsbedingte Beleuchtungssteuerung ist diesem

Gebiet zuzurechnen. Ein Beispiel wäre die Weihnachtsbeleuchtung, die in Abhängigkeit

von z.B. Zeit, Dämmerung oder Sonnenaufgang gesteuert werden soll.

Verschattung

Dieses Gebiet deckt die Funktionen der automatischen Steuerung der Verschattung z.B.

unter Einbindung von Jalousien, Rollläden oder Sonnenmarkisen ab. Ziel ist die effiziente

Nutzung des Tageslichts bei optimaler Steuerung des Kunstlichts und die Schonung von

Ressourcen aus dem Anwendungsgebiet der Klimatisierung. Die Verschattung schützt vor

unerwünschter Wärmeeintragung insbesondere bei hohen Glasanteilen in der Fassade,

trägt aber auch durch gezielte Wärmeeintragung über die Fenster an kühleren Tagen bei.

In die Daten zur Steuerungsgrundlage werden neben Zeit ebenso Sonnenstand und Wetter

(Außentemperatur, Windgeschwindigkeit, Niederschlag) einbezogen. Nicht zuletzt stellt

dieser Bereich einen erhöhten Komfort durch z.B. das automatische Öffnen aller Rollläden

am Morgen und das automatische Schließen am Abend dar. Z.B. kann gleichfalls das

automatische Schließen der Verschattungs-Komponenten bei Abwesenheit auch den

Anwendungsbereich der Sicherheitsfunktionen durch erhöhte Einbruchshemmung

unterstützen. Im Gegenzug kann durch das automatische Öffnen der Verschattung ebenso

bei Abwesenheit eine Anwesenheit simuliert werden.

2.1.6. Einteilung der Systeme

Für die Übertragung der komplexen Informationen benötigt die auf ein logisches

Bussystem basierende Gebäudeautomation eine adäquate technische Implementierung.

Am Markt existieren zahlreichende Systeme, die sich allerdings in ihrer Implementierung

stark unterscheiden. Manche Systeme setzen auf anerkannte Standards, einige auf

proprietäre Implementierungen. Eine grundsätzliche Einteilung kann hinsichtlich

Übertragungsmedien und Struktur getroffen werden. Im Folgenden sollen zunächst die

Unterschiede der Übertragungsmedien und weiters die strukturellen Unterschiede kurz

dargelegt werden (vgl. [GiW18, Kap. 2.3]).

Übertragungsmedien

Bei den Übertragungsmedien lassen sich grundsätzlich zwei Hauptgruppen identifizieren:

die drahtgebunden und die funkbasierenden Systeme. Bei den drahtgebundenen

Systemen kann eine weitere Differenzierung auf Basis der Art der verwendeten Leitung

vorgenommen werden. Einerseits können Daten über vorhandene Elektroinstallationen

(Powerline) übertragen werden, andererseits kann ein zusätzliches Leitungssystem unter

Verwendung von zwei verdrillten Adern (Twisted Pair) zum Einsatz kommen. Ein auf

separaten Leitungen basierendes System ist KNX (Konnex-Bus), welches u.a. auch die

europäische Norm DIN EN 50090 erfüllt und damit die Interoperabilität mit KNX-

12

kompatiblen Geräten unterschiedlicher Hersteller erlaubt. Als Vertreter der Powerline-

Technik kann digitalSTROM genannt werden, welches sich durch kleine intelligente

Bauteile in die Stromkreise integrieren lässt. Die flexibelste Variante ist die der

Funkkommunikation. Es wird zwischen unidirektionaler und bidirektional Kommunikation

unterschieden. Bei der unidirektionalen Kommunikation wird auf eine empfangene

Nachricht keine Rückmeldung gesendet, bei der bidirektionalen Kommunikation werden

Nachrichten in beiden Richtungen ausgetauscht. Dabei werden die Signale über das ISM-

Band (Industrial, Scientific and Medical Band) auf den Frequenzen 433 MHz und 868 MHz

übertragen. ISM-Frequenzen sind frei von Gebühren und die Verwendung muss nicht

angemeldet werden. Allerdings handelt es sich hier um untergeordnete Dienste, die durch

andere Dienste gestört werden können. Das ISM-Band 433 MHz wird z.B. auch vom

Amateurfunk (vgl. [ÖVSV, S. 4]) verwendet. Generell sind bei der Verwendung der beiden

ISM-Bänder Vorschriften in Bezug u.a. auf Sendeleistung und auf der Frequenz 868 MHz

sogar in Bezug auf die relative Frequenzbelegungsdauer für diese sogenannten Short

Range Devices (SRD) einzuhalten (vgl. [BNA14]).

Frequenz-

bereich in

MHz

Frequenzbereich in

MHz Maximale

äquivalente

Strahlungsleistung

Zusätzliche

Parameter/Frequenzzugangs-

und Störungsminderungs-

techniken

Sonstige

Nutzungs-

beschränkung

en

433,050

bis

434,790

10 mW keine keine

868,0

bis

868,6

25 mW

Es sind Frequenzzugangs- und

Störungsminderungstechniken

einzusetzen, deren Leistung

mindestens den Techniken

entspricht, die in den gemäß

Richtlinie 1999/5/EG bzw. des

FTEG verabschiedeten

harmonisierten Normen

vorgesehen sind. Alternativ kann

ein maximaler Arbeitszyklus von

1 % verwendet werden.

Keine

analogen

Video-

anwendungen

Tab. 1: Frequenznutzungsparameter [BNA14]

Aus Tabelle 1 geht hervor, dass im Frequenzbereich 433 MHz keine Limitierung der

Belegungsdauer besteht, allerdings ist die maximale Strahlungs-/Sendeleistung auf 10 mW

beschränkt. Im Bereich 868 MHz darf mit maximal 25 mW gesendet werden, die maximale

Frequenzbelegungsdauer (Arbeitszyklus, Duty Cycle) darf in einer Stunde nur maximal ein

Prozent und somit 36 Sekunden innerhalb einer Stunde betragen (vgl. [ETSI18, S. 22]).

Nicht zuletzt aus der Störanfälligkeit von Funksystemen ergibt sich der Schluss, dass bei

einer entsprechend sicheren Leitungsführung ein autonomes kabelbasierendes

13

Bussystem als Kommunikationsträger gravierende Vorteile auf jeden Fall aus der Sicht der

Verlässlichkeit mit sich bringt.

Als Beispiel für ein innovatives funkbasiertes Gebäudeautomationssystem kann EnOcean

genannt werden. Das System baut auf batterielose Sensoren auf, welche die Energie für

die Übertragung aus der Umwelt (z.B. Schalterbewegung, Licht, Temperaturdifferenzen)

beziehen, auch Energy Harvesting genannt. Dabei wird die kinetische Energie z.B. bei

einer Schalterbetätigung oder die Drehbewegung beim Öffnen eines Fensters genutzt.

Andere Arten der Energiegewinnung der EnOcean-Technologie sind z.B. die Nutzung der

Thermoelektrizität oder die Verwendung von Solarmodulen (vgl. [GiW18, Kap. 2.3.1.3]).

Struktur

Im Bereich des strukturellen Aufbaus bzw. der Installation können

Gebäudeautomationssysteme unterschieden werden. Die Unterscheidung der Systeme

wird in zentrale, dezentrale und halbzentrale Systeme vorgenommen. Es sind allerdings

auch Mischformen möglich (vgl. [GiW18, Kap. 2.3.2]).

Bei der zentralen Struktur werden die Sensoren und Aktoren nur durch eine Zentrale zu

einer sinnvollen und intelligenten Einheit zusammengeführt. Eine direkte Kommunikation

zwischen Sensoren und Aktoren finden nicht statt. Sensoren und Aktoren sind Standard-

Komponenten ohne eigene Intelligenz. Die zentrale Steuereinheit verarbeitet die

angelieferten Daten und steuert die Aktoren entsprechend der zentralen Programmlogik.

Ein Ausfall der zentralen Steuereinheit bringt allerdings den vollständigen Systemausfall

mit sich. Bei der dezentralen Struktur kommunizieren Sensoren und Aktoren

untereinander, die Notwendigkeit einer zentralen Steuereinheit entfällt. Durch die

vermehrte Zahl an intelligenten Komponenten ist eine dezentrale Struktur mit höheren

Kosten verbunden. Bei dieser Variante handelt es sich um eine intelligente Vernetzung,

von einem umfassenden System der Gebäudeautomation kann nicht gesprochen werden.

Die dezentrale Struktur fällt damit bei Störungen einzelnen Komponenten nur teilweise aus.

Die Nutzung der Vorteile der zentralen und dezentralen Struktur wird über eine halbzentrale

Struktur realisiert. Rein über die Zentrale arbeitende Komponenten werden mit intelligenten

Komponenten kombiniert, die ohne die zentrale Steuereinheit Systemteile funktionsfähig

halten können. Auch ist die Nutzung mehrerer zentraler Einheiten denkbar. Die Systemteile

können auf Gebäudeteile oder Funktionsaufgaben (z.B. Lichtsteuerung oder

Sicherheitsfunktionen) aufgeteilt werden, das Risiko eines Totalausfall wird dabei

herabgesetzt (vgl. [GiW18, Kap. 2.3.2]).

2.1.7. Interoperabilität und Objektabhängigkeit

Standardisierte Systeme, wie z.B. KNX, LON und BACnet bieten die Möglichkeit, dass

Systeme unterschiedlicher Hersteller miteinander über Schnittstellen zusammenarbeiten

können. Bei einer großen Anzahl der Hersteller ist diese Voraussetzung allerdings nicht

gegeben. Bei der Auswahl des Herstellers von Gebäude- und Heimautomationssystemen

14

sollte daher die Notwendigkeit der Anbindungsmöglichkeit an Systeme anderer Hersteller

mitberücksichtigt werden (vgl. [GiW18, Kap. 2.3.3]).

Bei der Auswahl von Heimautomationssystemen ist eine starke Abhängigkeit zum

Wohnobjekt gegeben. Bei einem privaten Neubau eines Hauses oder der Kernsanierung

einer Wohnung kann z.B. die Leerverrohrung für ein kabelbasiertes Bussystem

kostengünstig miteingeplant werden. Auch kann die Planung der Stromkreise und des

Verteilerschranks auf die Heimautomation ausgelegt werden.

Bei Mietobjekten oder Bestandsobjekten wird daher eher auf ein funkbasiertes System

gesetzt werden (vgl. [GiW18, Kap. 2.3.4]).

2.1.8. Heimautomationssysteme und das Internet der Dinge (IoT)

Wird die Kontrolle eines Gebäude- und Heimautomationssystems über das Internet zur

Verfügung gestellt, liegt ein Vergleich zwischen Gebäude- und Heimautomationssystemen

und zunächst der Architektur von IoT-Systemen nahe. Das ist insbesondere der Fall, wenn

die Leit- bzw. Managementebene des Heimautomationssystems als Cloud-Dienst realisiert

ist.

Abb. 2: Architektur „Internet der Dinge“ nach [KeSa18, S. 6]

Gemäß Abbildung 2 befinden sich im IoT-Things Layer die Sensoren und Aktoren, damit

kann der Things Layer mit der Feldebene der Gebäudeautomation verglichen werden. Die

Schnittstellen, in der Abbildung 2 blau hinterlegt, stellen die Verbindungsschichten ähnlich

15

der Schnittstellen der Gebäudeautomation dar. Sowohl die Automationsebene als auch die

Leit- bzw. Managementebene der Gebäudeautomation kann sowohl im IoT-Cloud Layer

als auch im IoT-Edge Layer abgebildet oder sogar verteilt sein. Eine Zuordnung der

einzelnen drei in dieser Arbeit behandelten Heimautomatisierungslösungen generell zu IoT

erfolgt im Rahmen der Sicherheitsanalyse.

2.2. Informationssicherheit und -risiken

Im folgenden Abschnitt soll eine Grundlage für das Verständnis über Informationssicherheit

und -risiken geschaffen werden. Zusätzlich soll die Anwendbarkeit der Grundsätze der

Informationssicherheit und die damit verbundenen Risiken auf den privaten Bereich

dargestellt werden, um in weiterer Folge die Informationssicherheitsrisiken in der

Heimautomatisierung evaluieren, bewerten und ggf. verringern zu können.

2.2.1. Begriffe

Informationssicherheit

Die Informationssicherheit beschäftigt sich mit dem Schutz von Informationen jeglicher Art

und Herkunft. Dabei ist es nicht relevant, ob Informationen auf Papier vorhanden, in IT-

Systemen gespeichert oder in den Köpfen von Personen präsent sind. Die klassischen

Schutzziele der Informationssicherheit sind Vertraulichkeit, Integrität und Verfügbarkeit

(vgl. [BSI200-1, S. 8]).

Unter den Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit ist im Einzelnen

Folgendes zu verstehen (vgl. [ÖISHB19, S. 38]):

• Vertraulichkeit (Confidentiality)

o Schutz vor unberechtigter Offenlegung oder Kenntnisnahme durch

Personen oder Prozesse

• Integrität (Integrity)

o Schutz vor unberechtigter oder zufälliger Veränderung durch Personen oder

Prozesse

• Verfügbarkeit (Availability)

o Sicherstellen, dass Informationen berechtigten Personen oder Prozessen

zur Verfügung stehen, wenn diese sie benötigen

16

Weitere Ziele der Informationssicherheit aus dem Subbereich Kryptographie sind (vgl.

[ÖISHB19, S. 251-252]):

• Herkunftsnachweis (Nachrichtenauthentisierung, Authenticity)

o Ein*e Empfänger*in einer Nachricht soll prüfen können, dass eine

bestimmte Nachricht von einem/einer bestimmten Absender*in stammt und

nicht verändert wurde.

• Nichtabstreitbarkeit (Verbindlichkeit, non repudiation)

o Ein*e Absender*in soll die Urheberschaft einer Nachricht abstreiten können

und mit einer anderen Identität ist der Nachweis möglich.

IT-Sicherheit

Im Grunde ist die IT-Sicherheit ein Teilbereich der Informationssicherheit, diese beschäftigt

sich rein mit der Sicherheit von in IT-Systemen gespeicherten Informationen. In der

Literatur wird allerdings auch der Begriff IT-Sicherheit als Synonym für

Informationssicherheit verwendet. Der umfassendere Begriff der Informationssicherheit

wird als mehr zeitgemäß bezeichnet (vgl. [BSI200-1, S. 8]).

Cyber-Sicherheit

Der Begriff der Cyber-Sicherheit weitet das Betrachtungsfeld der IT-Sicherheit über die

Grenzen von Unternehmen aus. Es wird die IT-Sicherheit in einem bestimmten

geographischen Raum, z.B. Österreich, betrachtet. Dabei werden sämtliche mit dem

Internet verbundenen und vergleichbaren Netze der Informationstechnik inklusive

Kommunikation, Anwendungen, Prozesse und verarbeitete Informationen betrachtet (vgl.

[BSI200-1, S. 8]).

Informationssicherheitsmanagementsysteme

Informationssicherheitsmanagementsysteme fassen die Aufgaben der

Informationssicherheit in geplante, kontrollierte und sich verbessernde Prozesse mit klaren

Zielsetzungen, Verantwortlichkeiten und Ressourcen. Die Informationssicherheit soll durch

eine Kombination von technischen und organisatorischen Maßnahmen sichergestellt

werden. Das Management der Informationssicherheit kann systematisch durch die

Anwendung von Normen und Standards betrieben werden. Beispiele für derartige

Managementsysteme und Standards sind (vgl. [BSI200-1, S. 8-14]).

• Die ISO/IEC 2700x-Familie

o Der wichtigste Standard der ISO/IEC 2700x-Familie ist die ISO/IEC 27001

durch die Normierung eines Informationssicherheitsmanagementsysteme

nach dem sich Unternehmen zertifizieren lassen können.

• Der IT-Grundschutz des deutschen Bundesamts für Sicherheit in der

Informationstechnik (BSI)

• Control Objectives for Information and Related Technology (COBIT)

17

• Information Technology Infrastructure Library (ITIL)

• Payment Card Industry Data Security Standard (PCI DSS)

• US-amerikanisches National Institute of Standards and Technology (NIST) mit

speziellen Publikationen für diverse Sicherheitsbereiche

• ISF – Standard of Good Practice (ISF)

Das österreichische Informationssicherheitshandbuch referenziert häufig auf Normen der

ISO/IEC 2700x-Familie und listet die Kernthemen des Managements der

Informationssicherheit neben u.a. dem kontinuierlichen Verbesserungsprozess (KVP) wie

folgt auf [ÖISHB19, S. 39-40]:

• Festlegung der Sicherheitsziele und -strategien der Organisation

• Ermittlung und Bewertung der Informationssicherheitsrisiken (Information Security

Risk Assessment)

• Festlegung geeigneter Sicherheitsmaßnahmen

• Überwachung der Implementierung und des laufenden Betriebes der ausgewählten

Maßnahmen

• Förderung des Sicherheitsbewusstseins innerhalb der Organisation sowie

• Entdeckung von und Reaktion auf sicherheitsrelevante Ereignisse (Information

Security Incident Handling)

Informationssicherheitsziele müssen allerdings ebenso den gesetzlichen Rahmen und

damit auch den Datenschutz, branchenbezogene Regulatorik sowie z.B. Regelungen in

Verträgen berücksichtigen [ÖISHB19, S. 122].

Informationssicherheitsrisiken

Informationssicherheitsrisiken sind Bedrohungen gegen die Schutzziele Vertraulichkeit,

Verfügbarkeit und Integrität der Informationssicherheit. Die Bedrohungen oder

Gefährdungen können dabei unterschiedlichster Art und Herkunft sein. Bei der Bewertung

von Informationssicherheitsrisiken ist die mögliche Schadenshöhe verbunden mit der

Eintrittswahrscheinlichkeit für die Behandlung ausschlaggebend.

Informationssicherheitsrisiken können durch eine Risikoanalyse identifiziert werden (vgl.

[ÖISHB19, Kap.4]).

U.a. müssen zuerst die bedrohten Werte (Assets) identifiziert werden, deren Wert, welchen

Bedrohungen sie ausgesetzt sind, welche Schwachstellen sie aufweisen, welche

Sicherheitsmaßnahmen bereits getroffen wurden und welches Restrisiko damit verbunden

ist. Erst danach kann auf Basis der ermittelten Ergebnisse eine systematische

Risikobehandlung erfolgen (vgl. [ÖISHB19, S. 95-96]). Für die Identifikation der bedrohten

Werte ist interessant, dass nach dem ISO/IEC 27002 Standard, der

Umsetzungsempfehlungen für die einzelnen Kontrollbereiche der Informationssicherheit

zur Risikoreduktion gibt, alle materiellen und immateriellen Werte einer Organisation

inkludiert. Daraus ist zu schließen, dass bei der Werte-Identifikation alles, was für eine

Organisation einen Wert darstellt, einzubeziehen ist (vgl. [ÖISHB19, S. 200]).

18

Als Werte kann man nach der genannten Definition z.B. Gebäude, das Knowhow der

Mitarbeiter, Prozesse, Liquidität, Reputation, IT-Komponenten, aber auch Verträge sehen.

Mögliche Bedrohungen können z.B. Feuer, Naturkatastrophen, Einbruchsdiebstahl oder

Vandalismus, ein Hackerangriff, ein Personalausfall, u.a. auch der Verlust der Reputation

oder Liquidität sein. Für eine qualifizierte Bewertung kann durch z.B. ein dreistufiges Modell

eine Klassifizierung der Werte in gering, mittel und hoch durchgeführt werden. Durch das

Einbeziehen der Eintrittswahrscheinlichkeit unter Berücksichtigung von

Gegenmaßnahmen kann die Risikobewertung getätigt werden. Für die

Eintrittswahrscheinlichkeit kann wiederum zur Quantifizierung eine Klassifizierung in z.B.

häufig, selten und sehr selten vorgenommen werden (vgl. [ÖISHB19, S. 99-103]).

Exemplarisch kann dafür das Risiko für eine Organisation anhand des Beispiels am selbst

implementierten und betriebenen Web-Online-Shop skizziert werden. Der Web-Shop ist für

die Organisation von hoher Wichtigkeit für den Fortbestand, die Eintrittswahrscheinlichkeit

eines Hackerangriffs ist bei Nichtberücksichtigung von Sicherheitsmaßnahmen als häufig

anzusehen. Das resultierende Informationssicherheitsrisiko ist damit ebenfalls hoch. Es

können u.a. Kundendaten gestohlen werden, das System kann durch einen Hackerangriff

lahmgelegt werden und es könnten Daten unberechtigt verändert werden. Alle drei

klassischen Schutzziele Vertraulichkeit, Verfügbarkeit und Integrität sind in einem hohen

Maß bedroht.

2.2.2. Informationssicherheit im privaten Bereich

Im Folgenden soll ein Bezug der Informationssicherheit aus dem Bereich der

Organisationen zum privaten Beriech hergestellt werden. Managementsysteme der

Informationssicherheit und die dazugehörigen Normen und Standards wurden für

Organisationen geschaffen, die systematisch Informationssicherheitsmanagement

betreiben können. Nicht zuletzt stellen der hohe Ressourcenaufwand und die Komplexität

eines standardisierten Informationssicherheitsmanagementsystems eine scheinbar

unüberwindliche Hürde für die Anwendung im privaten Bereich dar.

Im privaten Bereich existieren allerdings ähnliche Werte für Einzelpersonen oder kleinen

Gesellschaftsformen wie Partnerschaften und Familien. Das sind z.B. persönliche

Beziehungen, eine Wohnung, ein Haus, ein Fahrzeug, die körperliche und seelische

Unversehrtheit, das Recht auf Privatsphäre sowie die Selbstbestimmung über

Informationen über einen selbst (Datenschutz) und nicht zuletzt das eigene Vermögen, die

eigene Liquidität. Auch lassen sich Überschneidungen bei den Bedrohungen identifizieren,

so sind die Gefahren durch Brand, Naturkatastrophen, Einbruchsdiebstahl, Vandalismus

oder einen Hackerangriff ebenfalls gegeben, wenn auch die Auswirkungen eine andere

Bedeutung haben können. Der private Einsatz von IT-Komponenten bringt ebenfalls

ähnliche Gefahren mit, so ist die Verbreitung von Schadsoftware auf privaten IT-

Komponenten oder die Gefahr durch das Ausspähen von Zugangsdaten z.B. durch

Phishing immer wieder in den Medien präsent. Das BSI nennt z.B. in einer Information für

19

Bürger u.a. fehlende Verschlüsselung, die Verbreitung von Schadprogrammen, die

Fälschung von Benutzer*innenkonten oder die Komplexität der Programme als größte

Sicherheitsrisiken für Bürger [BSIDGS].

Im privaten Bereich ist es üblich, manche Risiken, die offensichtlich unausweichlich sind,

zu verlagern. Das trifft z.B. auf eine Haushalts-, Unfall- oder Ablebenversicherung zu, damit

sollen die Auswirkungen, die z.B. durch Feuer, Wasser, Diebstahl oder temporärer oder

dauernder Verletzungen oder sogar durch das Ableben entstehen können, vermindert

werden. Der Abschluss einer Haftpflichtversicherung für die behördliche Zulassung eines

Kraftfahrzeugs ist sogar in den meisten Fällen gesetzlich vorgeschrieben. Wenn auch kein

systematischer Ansatz in Bezug auf die Informationssicherheit und der damit verbundene

Umgang mit Risiken im privaten Bereich vorausgesetzt werden kann, können manche

Prinzipien der Informationssicherheit auf das private Umfeld umgelegt werden. Damit ist

es möglich, die Ergebnisse einer Sicherheitsanalyse von IT-Systemen, gegenständlich

Heimautomationssysteme, auch mit privaten Informationssicherheitsrisiken zu

kombinieren. Nach der Sicherheitsanalyse der konkreten Heimautomationssysteme,

lassen sich daher ebenfalls die Informationssicherheitsrisiken, die durch den Einsatz der

drei konkreten Heimautomationssysteme entstehen können, identifizieren und

beschreiben.

2.3. Sicherheitsanalysen

Dieser Unterabschnitt soll ein Grundverständnis über Sicherheitsanalysen vermitteln und

einen Überblick geben, in welchen Lebenszyklen einer Anwendung Sicherheitsanalysen

durchgeführt werden können und sollten. Weiters soll zum nächsten Kapitel übergeleitet

werden, in dem die drei gegenständlichen Lösungen einer Sicherheitsanalyse unterzogen

werden.

2.3.1. Lebenszyklus von Anwendungen und sicherere Softwareentwicklung

Die „Lebensabschnitte“ einer Anwendung lassen sich grundsätzlich in folgende Phasen

einteilen:

• Initiale Planung

o Die ersten Ideen zu einer Anwendung, einem wertschöpfenden Produkt,

sind entstanden. Es sind grundlegende funktionale Anforderungen

vorhanden.

• Design

o Funktionen und Abläufe werden entsprechend der funktionalen und nicht-

funktionalen Anforderungen definiert, Technologien im Bereich Hard- und

Software werden festgelegt.

• Implementierung

20

o Die Komponenten werden zusammengestellt, konfiguriert und die Abläufe

und Interaktionen programmiert.

• Testen

o Es werden Tests zur Prüfung der Vollständigkeit und Richtigkeit der

definierten Funktionen geprüft.

• Auslieferung & Betrieb

o Die Anwendung wird implementiert und betrieben. Es wird Support geleistet,

Updates/Upgrades und Bugfixes werden zur Verfügung gestellt.

Es wird im Zusammenhang mit den Lebenszyklen von Anwendungen auch von einem

Softwareentwicklungs-Lebenszyklus, Software Development Lifecycle (SDLC)

gesprochen. Bereits im Jahr 2002 hat Microsoft Sicherheitsanforderungen in die einzelnen

Abschnitte des Lebenszyklus von Anwendungen integriert und damit die Grundlage für

einen sicheren Softwareentwicklungs-Lebenszyklus, Secure Development Lifecycle (SDL)

geschaffen (vgl. [BSISEC, S. 15]).

In der initialen Planung wurden u.a. generelle Sicherheitsanforderungen mit

aufgenommen, funktionale Sicherheitsanforderungen, wie z.B. Benutzermanagement,

Rollen, Berechtigungen und Schnittstellen integriert. Auch nicht-funktionale

Sicherheitsanforderungen, wie z.B. eine Bedrohungsmodellierung wurden inkludiert. Im

Bereich Design wurden Prinzipien der sicheren Architektur zugrunde gelegt. In dieser

Phase sollen sowohl Rollen- und Berechtigungskonzepte mit konzipiert werden und eine

ebenso eine Überprüfung der Sicherheitsanforderungen enthalten sein. Auch in dieser

Phase sollen Abuse (Missbrauch) Cases erstellt und eine Bedrohungsmodellierung (Threat

Modeling) durchgeführt werden (vgl. [BSISEC, S. 21-27]). Für ein besseres Verständnis

über die Bedrohungsmodellierung wird eines der Modelle kurz erklärt.

Microsoft bietet zur Bedrohungsmodellierung ebenfalls ein Vorgehensmodell, das STRIDE-

Modell, an, welches einen Kernbestandteil des Microsoft Security Development Lifecycle

ist [MSTM17]. Mit der Methodik sollen z.B. Fragen beantwortet werden können, wie ein

Angreifer Authentifizierungsdaten ändern kann. Das Modell beschreibt zur Vereinfachung

der Anwendung folgende Kategorien (vgl. [MSTM17]):

• Spoofing (Verschleierung) – Unbefugter Zugriff durch Verwendung der

Anmeldeinformationen anderer Benutzer*innen z.B. Benutzername und Passwort.

• Tampering (Manipulation) – Befasst sich mit unautorisierter und vorsätzlicher

Veränderung von Daten bei der Übertragung.

• Repudiation (Nichtanerkennung) – Benutzer*innen sollen Aktionen in einem

System nicht ausführen und in Folge abstreiten können.

• Information Disclosure (Veröffentlichung von Informationen) – Befasst sich mit

Zugriffsmöglichkeiten auf nicht vorgesehene Zugriffe auf Informationen und das

Ausspähen von Informationen bei der Datenübertragung.

• Denail of Service (Verweigerung des Dienstes) – Befasst sich mit Bedrohungen der

Verfügbarkeit von Systemen, die durch Angreifer*innen nicht oder nur

beeinträchtigt ihren Dienst erfüllen können.

21

• Elevation of Privilege (Rechteerweiterungen) – Befasst sich mit nicht gewünschten

privilegierten Zugriffen, welche die gesamte Systemsicherheit aushebeln.

Dieses Vorgehensmodell zur Bedrohungsanalyse kann auch bereits in der Planungsphase

zur Anwendung kommen. In der Phase der Implementierung sind Disziplinen zur Schaffung

sicherer Schnittstellen, zum sicheren Umgang mit Sourcecode und zur Verwendung

sicherer Programmierstandards enthalten. In der Testphase werden neben funktionalen

Tests auch Security Test Cases erstellt, Security Unit Tests und Design Reviews

durchgeführt. Es kommen statische Programmcode-Scanner und z.B. Web Security

Scanner zum Einsatz, die erste Schwachstellen identifizieren können. Fuzz Testing, ob

automatisch oder teilautomatisiert eingesetzt, konfrontiert Systeme mit zufälligen und

unerwarteten Eingabewerten und zeigt Fehler in der Eingabebearbeitung bzw.

Weiterverarbeitung auf (vgl. [BSISEC, S. 32-34]). In der Testphase sind abschließend auch

Penetrationstests und abschließende Security Reviews als Voraussetzung für die Freigabe

zum Eintritt in die nächste Phase integriert. Die Sicherheitsvorkehrungen in der Phase der

Auslieferung und des Betriebs soll sicherstellen, dass Integrität, Authentizität und

Vertraulichkeit durch den Einsatz von Prüfsummen, digitalen Signaturen und

Verschlüsselungsverfahren gewahrt werden. Eine Sicherheitsdokumentation hält alle

sicherheitsrelevanten Grundeinstellungen und Verfahren der Anwendung fest, beschreibt

einen sicheren Betrieb, enthält Hinweise auf die Konsequenzen bei der Nichtbeachtung

von Empfehlungen für sicherheitskritische Funktionen und gibt wartungsrelevante

Informationen. Als Teil der Phase ist auch die Härtung der eingesetzten Plattformen

enthalten, wobei nicht benötigte Dienste und Accounts deaktiviert werden müssen und das

Prinzip der minimalen Rechte (Least Privilege) umgesetzt werden soll. In dem Bereich des

Betriebs fällt auch der geregelte Umgang mit Änderungen an der Anwendung

unterschiedlichster Ausprägung, die ebenfalls einer Begleitung durch die Sicherheit

bedürfen. Ebenso müssen Störungsmelden systematisch abgearbeitet werden, die

Schwachstellenentwicklung eingesetzter Fremdkomponenten überwacht und eine sichere

Bereitstellung im Netzwerk ggf. durch den Einsatz zusätzlicher Schutzmechanismen, wie

z.B. einer Web Application Firewall ermöglicht werden. Zusätzlich müssen auch

Sicherheitsvorkehrungen für die Wartung berücksichtigt werden, welche die

Voraussetzungen für die Durchführung von Wartungsarbeiten vor Ort oder aus der Ferne

regelt (vgl. [BSISEC, S. 36-39]).

2.3.2. Nutzen

Der Nutzen von Sicherheitsanalysen liegt darin, dass diese durch einen sicheren

Softwareentwicklungsprozess angepasst auf die einzelnen Phasen des Lebenszyklus von

Anwendungen die Gefahr der Auslieferung unsicherer Software minimiert. Ursachen für

die Entstehung und den Betrieb von unsicheren Anwendungen durch hohe Komplexität,

fehlende Sicherheitsanforderungen und Transparenz bis hin zur verminderten Testbarkeit

sollen vermieden werden (vgl. [BSISEC, S. 9-10]). Risiken sollen dabei für den Hersteller

der Anwendung und den Nutzern minimiert werden. Durch die Früherkennung von Fehlern

22

in der progressiven Entwicklung sollen auch die Kosten für die Fehlerbehebung reduziert

werden (vgl. [BSISEC, S. 14]).

2.3.3. Penetrationstest und abschließende Security Reviews

Penetrationstests stellen ein valides Mittel dar, aus der Sicht des Angreifers

Schwachstellen von Anwendungen zu finden und diese zum Eindringen ins System

auszunutzen. Mit dem Eindringen in ein System oder durch die Möglichkeit des

Ausspionierens werden die Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit)

verletzt.

Die übliche Vorgangsweise für einem Penetrationstest neben der Planung (Inhalt und nicht

Inhalt – Scope, Ressourcen und Zeit) ist grundsätzlich (vgl. [BSISEC, S. 34-35]):

• Einholen der rechtlichen Grundlage für den Angriff

o Oft werden Penetrationstests von externen Firmen mit entsprechender

Expertise durchgeführt. Die Tests können ohne vertragliche Vereinbarung

rechtswidrig sein.

• Sammeln von Informationen über die Anwendung

o Ziel ist es, den ersten Anhaltspunkt für einen Angriffspunkt zu erlangen.

• Suchen nach Diensten, welche die Anwendung anbieten

o Für den folgenden Schritt ist es Voraussetzung, dass für genauere

Erkenntnisse mit der Anwendung interagiert werden kann.

• Genaue Identifikation der Anwendung

o Durch die Interaktion mit der Anwendung sollen genaue Technologien und

Komponenten mit deren genauen Versionierungen ermittelt werden.

• Recherche nach Schwachstellen

o Für die gefundenen Technologien werden gezielt bekannte Schwachstellen

und deren Ausnutzbarkeit recherchiert.

• Ausnutzen von Schwachstellen

o Durch einen sogenannten Proof-of-Concept (PoC) wird versucht die

Schwachstelle auszunutzen und Sicherheitsmechanismen zu umgehen.

• Dokumentation der gefunden Schwachstellen

o Das Ausnutzen einer Schwachstelle wird im Detail und wiederholbar

dokumentiert.

• Beschreiben der mit den Schwachstellen verbundenen Risiken

o Es erfolgt eine Risikobeschreibung mit einer standardisierten Einstufung

nach der Kritikalität.

• Empfehlung von Maßnahmen zur Reduktion der Risiken

o Geeignete Maßnahmen zur Verbesserung der Systemsicherheit durch das

Schließen von Schwachstellen werden in die Dokumentation

aufgenommen.

23

Beispiele für genutzte Ressourcen und Standards im Zuge einer sicheren

Softwareentwicklung und damit auch eines Penetrationstests sind:

• Common Vulnerabilities and Exposures (CVE) List [MITRE]

o Eine Datenbank im Internet, die bekannte Schwachstellen

unterschiedlichster Technologie dokumentiert und zur Verfügung stellt.

• The Open Web Application Security Project (OWASP) [OWASP]

o Eine gemeinnützige Stiftung, die zur Verbesserung von Anwendungen

Vorgehensmodelle für eine sichere Entwicklung entwickelt und bereitstellt.

o Dazu gehören u.a.:

▪ OWASP Top Ten Web Application Security Risks

▪ OWASP API Security - Top 10

▪ OWASP IoT Top 10

• Common Vulnerability Scoring System (CVSS) [CVSS]

o Ein offenes Rahmenwerk, um Schwachstellen systematisch und unter

zusätzlichen Einflussfaktoren mit einer Kennzahl bewerten zu können.

• IT-Grundschutz des deutschen Bundesamts für Sicherheit in der

Informationstechnologie [BSIITG]

o Stellt umfassende Leitfäden für die Informationssicherheit bis hin zu

detaillierten Empfehlungen für technischer Sicherheitsmaßnahmen bereit.

• National Institute of Standards and Technology (NIST) [NIST]

o Stellt u.a. technische Standardisierungen und Empfehlungen im Bereich

Informationssicherheit mit technischen Leitfäden u.a. zu kryptographischen

Verfahren zur Verfügung.

2.3.4. Rechtliche Aspekte

Der folgende Unterabschnitt befasst sich mit den rechtlichen Aspekten einer

Sicherheitsanalyse von Software generell und konkret am Beispiel der drei

gegenständlichen Lösungen zur Heimautomatisierung.

Problemstellung

Urheberrecht allgemein

In Österreich ist das Urheberrecht [LEG1] im Bundesgesetz über das Urheberrecht an

Werken der Literatur und der Kunst und über verwandte Schutzrechte

(Urheberrechtsgesetz) geregelt. Das Gesetz hat die Aufgabe, das geistige Eigentum eines

Urhebers*einer Urheberin zu schützen. Das Gesetz regelt u.a., welche Werke unter den

Schutz fallen, welche Rechte dem*der Urheber*in zustehen (z.B. Verwertungsrechte,

Vervielfältigungsrecht, Verbreitungsrecht), wie lange der Schutz des Urheberrechts zeitlich

anzuwenden ist, welche Ausnahmen zu den Rechten der Urheber*innen bestehen und

welche rechtlichen Konsequenzen bei einer Rechtsverletzung angedroht sind. Das

deutsche Urheberrecht [LEG2] ist dem österreichischen sehr ähnlich und die Unterschiede

24

für die gegenständliche Betrachtung nicht relevant, daher wird nicht speziell auf die

Rechtslage in Deutschland eingegangen. Das deutsche und das österreichische

Urheberrechtsgesetz setzen Rahmenverordnungen der Europäischen Union um (vgl. §

115 UrhG [LEG1]).

Lizenzrecht allgemein

Weder in Deutschland noch in Österreich besteht ein eigenständiges Lizenzrecht in Form

eines Gesetzes. In Europa existiert auch keine Verordnung zur EU-weiten Regelung. Die

praktische Anwendung des Urheberrechts findet sich in Lizenzverträgen oder

Nutzungsbestimmungen wieder. Das Ziel ist das Schaffen einer klaren rechtlichen

Grundlage über die einem*einer Nutzer*in eingeräumten Rechte des Urhebers.

Sicherheitsüberprüfung

Zur Analyse der Sicherheit von Programmen oder Lösungen sollte grundsätzlich ein

erprobtes und standardisiertes Verfahren herangezogen werden. Bei einer Analyse kann

z.B. von Standards ausgegangen werden, die ein Software- oder Systementwickler für die

eigene Herstellung von Produkten beachten sollte. Einen solchen „Leitfaden zur

Entwicklung sicherer Webanwendungen“ (vgl. [LEG3]) hat das Deutsche Bundesamt für

die Sicherheit in der Informationstechnik (BSI) in Zusammenarbeit mit dem

Sicherheitsspezialisten SEC Consult als Leitfaden für Anbieter entwickelt und

herausgegeben (vgl. [BSISEC]). Richtet sich dieser Leitfaden an Anbieter für Unternehmen

und Behörden, lassen sich aber für private Nutzer*innen durchaus Anforderungen an die

Informations- und IT-Sicherheit von Haushaltsprodukten ableiten, die unabhängig von

Expert*innen geprüft werden sollten. Grundlegende Themen des Leitfadens sind u.a.:

Schutz von Vertraulichkeit, Integrität und Verfügbarkeit, funktionale und nicht-funktionale

Sicherheit, der OWASP Application Security Verification Standard (ASVS),

Bedrohungsmodellierung, Secure Coding Standards, Security Tests.

Die Security Tests umfassen dabei u.a. Code Reviews, statische und dynamische Code

Scanner, Web Security Scanner und Fuzz Testing sowie Penetration Tests.

Auf Basis der Ergebnisse der Sicherheitstests sollen Schwachstellen gefunden und

beseitigt werden. Die Prüfung nach den genannten Kriterien kann jedoch zumindest

teilweise im Widerspruch mit der Rechtslage stehen, daher sollte eine Prüfung der

Rechtslage vor den Prüfungshandlungen erfolgen.

Rechtliche Betrachtung

Zur Beurteilung, welche Methoden der Sicherheitsüberprüfung rechtlich auf Basis der

Lizenzbestimmungen und des Urheberrechts erlaubt sein könnten, sollen zuerst die

Lizenzbestimmungen der Lösung in Verbindung mit dem Urheberrecht betrachtet werden.

25

Lizenzvertrag eQ-3 HomeMatic

Der Endbenutzer*innen-Lizenzvertrag der zentralen Einheit CCU3 ist nicht direkt im

Internet aufrufbar. Zur Erlangung des Lizenzvertrages muss zunächst die aktuelle

Firmware heruntergeladen und entpackt werden. Der Lizenzvertrag [LEG4] enthält

folgende relevante Bestimmungen (Auszug).

„1. Lizenz: eQ-3 gewährt Ihnen eine beschränkte Lizenz, die Software ausschließlich für

eigene Zwecke und gemäß den Bedingungen dieser Vertragsbestimmungen zu nutzen.

Sie dürfen die Software nur so nutzen, kopieren, ändern, weitergeben oder verleihen,

wie in diesen Bedingungen vorgesehen ist. Dekompilierung, Reverse Engineering

oder andere Übersetzungen der Software, ausgenommen solche, die ausdrücklich

durch das Gesetz zugelassen werden und nicht vertraglich abdingbar sind, sind

unzulässig.“ [LEG4]

2. Urheberrecht: Alle Rechte, insbesondere Immaterialgüterrechte und andere

Berechtigungen in und an der Software oder Teilen davon, außer den in diesen

Bedingungen ausdrücklich genannten Rechten, verbleiben bei eQ-3 und den Lizenzgebern

von eQ-3. Sie bestätigen hiermit, dass Ihnen keine weiteren Rechte an der Software

als die in diesen Bedingungen ausdrücklich aufgeführten zustehen.“ [LEG4]

In der Vereinbarung sind noch eine Vielzahl von Open-Source Lizenzen angeführt, die zur

Herstellung der Produktfunktionalitäten eingesetzt wurden. U.a. ist das Dekompilieren und

Reverse Engineering explizit untersagt. Im Grunde darf die Software nur insoweit genutzt

werden, als der Hersteller es vorgesehen hat.

Urheberrecht Österreich

Das österreichische Urheberrechtsgesetz [LEG1] räumt nicht verzichtbare Rechte ein, die

unter eng definierten Umständen ein Dekompilieren gestatten. So ist im Rahmen der

rechtmäßigen Lizenznutzung nach § 40e UrhG [LEG1] das Vervielfältigen und

Dekompilieren zum Zwecke der Herstellung der Interoperabilität mit einem unabhängig

geschaffenen Programm im notwendigen Umfang gestattet. Damit ist eine Dekompilierung

bzw. ein Reverse Engineering zum Zwecke der Sicherheitsanalyse durch den Gesetzgeber

nicht ausdrücklich gestattet. Allerdings erlaubt der § 40d UrhG [LEG1] unter dem Titel der

freien Werknutzungen ein Beobachten und Testen. Mit dem nicht weiter definierten Begriff

„beobachten“ lässt sich das Gesetz dahingehend interpretieren, dass Beobachtungen und

Tests im Rahmen der Programmverwendung zulässig sind.

Schranken des Urheberrechts

Am 8.11.2011 entschied das Landegericht Berlin (Urteil Az.: 16 O 255/10 [LEG5]), dass

Software, die auf General-Public-License (GPL) [LEG6] basiert und maßgeblich davon

geprägt ist, nicht urheberrechtlichem Schutz unterliegen kann. Bei der Verwendung

derartig gestalteter Software sind auf Basis „Copyleft-Prinzip“ des §§ 2, 3 GPL [LEG6]

26

Dritten dieselben Rechte einzuräumen. Es wird darauf hingewiesen, dass das deutsche

Urheberrechtsgesetz gemäß § 69e [LEG2] sogar das Recht des Dekompilierens zum

Zweck der Schaffung der Interoperabilität mit einer eigens gestalteten Anwendung

einräumt (vgl. § 40e UrhG [LEG1]).

Schlussfolgerungen

Das Urheberrecht schützt die Rechte an Werken von Softwareherstellern. Im Lizenzvertrag

wird geregelt, unter welchen Auflagen die Nutzung gestattet wird. Der Gesetzgeber hat

allerdings dem*der Nutzer*in unverzichtbare Rechte eingeräumt, die der*die Urheber*in

dem*der Nutzer*in nicht durch einen Lizenzvertrag nehmen kann. Allerdings ist eine

Sicherheitsanalyse dem*der Nutzer*in nicht als Recht eingeräumt. Auch ist das

Dekompilieren des Binärcodes im exemplarischen Lizenzvertrag ausgeschlossen. Bei

einer Sicherheitsanalyse von Software ist daher auf jeden Fall ratsam, die Lizenz- bzw.

Nutzungsbestimmungen des Rechteinhabers genau zu lesen und ggf. die Einholung einer

Rechtsmeinung eines Rechtsanwalts*einer Rechtsanwältin mit Spezialisierung auf das

Urheberrecht empfehlenswert. Es besteht nicht zuletzt die Möglichkeit den Rechteinhaber,

um eine Erlaubnis für die geplanten Tätigkeiten zu fragen. Unberührt bleibt die Frage, ob

die gegenständliche Lösung durch ihre starke Verbindung mit Open-Source tatsächlich

unter den Schutz des Urheberrechts fallen. Der*Die Urheber*in kann nicht jede Art der

Nutzung ausschließen, im Anwendungsfall einer Sicherheitsanalyse kommen daher die

nachfolgenden Analyse-Ansätze als unverzichtbare Nutzer*innenrechte (freie

Werknutzungen) in Betracht. Besonderes Augenmerk liegt dabei darauf, dass der

Gesetzgeber gemäß §40d UrhG [LEG1] die Beobachtung eines Programms erlaubt, ohne

die Art der Beobachtung in irgendeiner Form zu spezifizieren. Unter anderem als

Beobachten und im Sinne einer Art Handreichung (vgl. [LEG7]) könnte somit im Sinne des

Gesetzgebers erlaubt sein:

• Analyse von im Klartext vorhandenen Skriptdateien

• Beobachtung des Programmverhaltens durch Debugging in der Ausführung (nicht

Zurückführen in den ursprünglichen Quellcode für das gesamte Programm)

• Beobachten des Prozessverhaltens, der Speichernutzung und der Erzeugung von

Artefakten (z.B. Dateien) und des Verhaltens bei Updates

• Beobachtung des Verhaltens bei der Herstellung von Verbindungen (z.B. Check

von TLS-Handshakes, Verbindungsparameter einer Secure Shell)

• Beobachten der LAN-/WLAN-basierten Datenübertragung (z.B. durch Analyse-

Proxy)

• Beobachtung des Applikationsverhaltens im Webbrowser (z.B. durch Developer-

Tools im Browser)

• Beobachten der Funkübertragung (z.B. durch Signal- und Datenanalyse)

Fraglich, wenn nicht durch den Lizenzvertrag eingeräumt, ist das Reverse-Engineering z.B.

durch das Dekompilieren außerhalb der gesetzlichen Möglichkeiten. Eine tatsächliche

Rückführung in den ursprünglichen Quellcode ist in einer hohen Qualität meist nicht

27

möglich. Der Scan mit speziellen Tools zur Sicherheitsanalyse (z.B. Port-Scanner,

Schwachstellen-Scanner) erscheint ohne Einwilligung des Rechtinhabers eher als

unproblematisch. Ebenso die Anwendung von Fuzz-Testing. In jedem Fall ist der

Urheberrechtsschutz im Bereich der Informations- respektive IT-Sicherheit problematisch,

da das Recht ohne Zustimmung des Rechteinhabers für eine vollumfängliche

Sicherheitsanalyse nicht eingeräumt wird. Als Verbraucher*in ist man damit auf die

Aussagen und Angaben der Hersteller zu Sicherheitsfragen angewiesen.

2.4. Kryptographie in der Funkübertragung

Für ein besseres Verständnis der eingesetzten kryptographischen Verfahren in der

Analyse des Funkprotokolls (siehe Kapitel 3.5) werden die angewandten Hauptverfahren

in Form eines Überblicks erläutert.

2.4.1. Advanced Encryption Standard (AES)

Der Advanced Encryption Standard ist ein standardisierter Blockchiffre (Verschlüsselung

der Daten in festgelegten Blocklängen) unter Anwendung von 128 Bit Blöcken. Das

Verfahren wird durch die Anwendung von drei wählbaren Blocklängen 128 Bit, 192 Bit, 256

Bit unterschieden und AES-128, AES-192 und AES-256 genannt (vgl. [BEIDK, S. 115]).

28

Der Ablauf der Berechnungen kann schematisch wie folgt dargestellt werden:

Abb. 3: AES schematischer Verschlüsselungsablauf (vgl. [FIAES])

Abbildung 3 zeigt den schematischen Ablauf der AES-Verschlüsselung. Je nach

Schlüssellänge ist die Rundenanzahl mit 10 (AES-128), 12 (AES-192) und 14 (AES-256)

festgelegt. Das Verfahren ist ein symmetrisches Verschlüsselungsverfahren (Ver- und

Entschlüsselung werden mit demselben Schlüssel durchgeführt). Die Entschlüsselung

erfolgt nach dem gleichen Schema, wobei gewisse Funktionen invertiert werden (vgl.

[FIAES]).

2.4.2. Betriebsarten

Wie bereits dargestellt, ist der AES je nach eingesetzter Schlüssellänge auf einen festen

Block bei der Verarbeitung limitiert. Für die Verarbeitung von Klartexten beliebiger Länge

kommen für Blockchiffres generell sogenannte Betriebsarten (Modes) zum Einsatz, die

dieses Längenproblem lösen. Exemplarisch werden zwei Betriebsarten, die auch für den

AES Anwendung finden, im Überblick dargestellt.

29

Electronic Code Book (ECB)

Abb. 4: Electronic Code Book (vgl. [FIAES])

Abbildung 4 zeigt das Prinzip des ECB. Jeder Block wird einzeln und unabhängig

verarbeitet. Die Folge davon ist, dass bei gleichen Klartexten der verschlüsselte Text der

Blöcke ebenfalls gleich ist, kein Block hängt von einem anderen ab (vgl. [DKRYP, S. 59]).

Cipher Block Chaining (CBC)

Abb. 5: Cipher Block Chaining (vgl. [FIAES])

Abbildung 5 stellt den Ablauf im CBC dar. Da bis auf den ersten Block sind alle Blöcke vom

vorherigen Block abhängen, ist ein Initialisierungsvektor 𝐼𝑉 für den ersten Block

erforderlich. Vor jeder Verschlüsselung wird ein Block mit dem Ergebnis Exklusiv-Oder

verknüpft, der erste Block mit dem Initialisierungsvektor. Die Klartexte sind dabei 𝑚𝑖, die

verschlüsselten 𝑐𝑖. Texte Die Entschlüsselung erfolgt sinngemäß in umgekehrter

Reihenfolge mit dem entsprechenden Blockchiffre (vgl. [DKRYP, S. 61]).

Allgemein wird bei der Verschlüsselung wie folgt berechnet (vgl. [DKRYP, S. 61]):

Initialisierung

𝑐0 = 𝐼𝑉 . (2.4.2.1)

30

i-Schritte

𝑐𝑖 = 𝐸𝑘(𝑚𝑖 ⨁ 𝑐𝑖) . (2.4.2.2)

Für Klartexte, die in der Länge nicht ein Vielfaches der Blocklänge des eingesetzten

Blockchiffres aufweisen, ist ein Auffüllen (Padding) des letzten Blocks des Klartextes

erforderlich. Für das Padding existieren unterschiedliche Standards (vgl. [BSITLS, S. 25]).

Auf das Padding wird im Weiteren nicht eingegangen.

2.4.3. Authentifizierung

Eine besondere Erweiterung in den Betriebsarten ergibt sich durch die Kombination von

Verschlüsselung und Authentifizierung in einem Verfahren. Diese Kombination wird auch

„Authenticated Encryption“ genannt. Eine Nachricht soll dabei zur sicheren Übermittlung

verschlüsselt werden und der Empfänger soll prüfen können, ob die Nachricht am

Übertragungsweg verändert wurde. Ein derartiger Überprüfungscode wird vom Empfänger

mittels eines kryptografischen Verfahrens erzeugt und der Nachricht beigefügt. Der

sogenannte „Message Authentication Code“ (MAC) kann vom Empfänger verifiziert

werden, eine Veränderung der Nachricht erkannt und die Herkunft der Nachricht

festgestellt werden. Der Herkunftsbezug ergibt sich dadurch, dass Sender und Empfänger

einen geheimen gemeinsamen Schlüssel kennen (vgl. [DKRYP, S. 101]).

Eines dieser Verfahren ist „Cipher Block Chaining – Message Authentication Code“ (CCM),

in Verbindung mit AES der AES-CCM.

Abb. 6: Funktionsschema AES-CCM (vgl. [RFC3610])

Abbildung 6 zeigt das Funktionsprinzip des AES-CCM. Sender und Empfänger legen zuvor

den Blockchiffre (hier AES) kombiniert mit der Schlüssellänge, den gemeinsamen

Schlüssel und die Länge des MACs fest. Weder der Sender darf eine andere Länge des

MACs verwenden, noch darf der Empfänger eine andere als die definierte Länge des MACs

31

annehmen. Zusätzlich können noch weitere Authentifizierungsdaten enthalten sein (vgl.

[RFC3610]).

Der Sender wendet den AES-CCM mit dem Schlüssel und einer zufällig gewählten

Bytefolge, die nicht wiederholt verwendet werden darf, (Nonce) ggf. mit zusätzlichen

Authentifizierungsdaten an. Als Ergebnis erhält der Sender den verschlüsselten Klartext

und den MAC. Der Empfänger entschlüsselt die Nachricht mit dem AES-CCM ebenfalls

unter Anwendung des AES-CCM mit dem Schlüssel und der Nonce. Der Empfänger erhält

den Klartext der Nachricht und den berechneten MAC1, den er mit dem MAC der Nachricht

vergleichen kann, um festzustellen, ob die Nachricht nach der Erzeugung verändert

wurde(vgl. [RFC3610]).

32

3. Sicherheitsanalyse der Lösungen

Dieser Abschnitt beschreibt zunächst die Auswahl der Analysemethode, die Definition der

für die Analyse geeigneten Werkzeuge und befasst sich mit der Analyse der einzelnen

Lösung. Die Analyse soll ein grundsätzliches Verständnis über den Aufbau und die

Funktionsweise der einzelnen Lösungen geben, gegebenenfalls Schwachstellen

identifizieren und schließt mit einem Vergleich der Lösungen ab.

3.1. Auswahl der Methodik und Werkzeuge

Für die Durchführung der Sicherheitsanalysen ist ein Vorgehensmodell erforderlich, dass

auf der einen Seite geeignet ist, konzeptionelle Schwachstellen zu identifizieren als auch

Schwachstellen in der Implementierung und beim Betrieb aufzuzeigen. Nach dem

Festlegen der Methodik werden geeignete Werkzeuge definiert, mit denen die Analysen

durchgeführt werden können.

3.1.1. Methodik

Die in dieser Arbeit generell gewählte Methodik orientiert sich grundsätzlich am Vorgehen,

wie sie auch bei der Durchführung von Penetrationstests (siehe auch Kapitel 2.3.3)

angewandt wird. Zusätzlich muss die Methodik darauf Rücksicht nehmen, dass bei der

Cloud-basierten Lösung, HomeMatic IP, weit geringere Informationen über die zentralen

Komponenten zur Verfügung stehen und eine technische Analyse insbesondere des

Cloud-APIs nicht möglich ist. Darüber hinaus muss das Risiko von Urheber- oder

Lizenzrechtsverletzungen soweit durch die Wahl der Analysemittel und die Nutzung derer

weitgehend ausgeschlossen werden. Nicht zuletzt ist der finanzielle Aufwand für die

Anschaffung der Werkzeuge zu berücksichtigen.

Die Methodik wurde daher vom Autor dieser Arbeit wie folgt festgelegt:

Bereich Ziele Dokumentation in der Arbeit

1 Vorbereitung

Anforderungsdefinition für die beiden

Wohnobjekte in Bezug auf die

Funktionen, Zuordnung der einzelnen

Lösungen auf die Standorte, Definition

der Konfiguration für die verbleibende

dritte Lösung, Beschaffung, Erhebung

der Garantien der Hersteller

• Anforderungen

• Lösungszuordnung

• Komponentenauswahl und

Anschaffungspreise

• Kurzbeschreibung der Garantien

durch die Hersteller

2 Implementierung • Kurzbeschreibung der

Verortung, Installation und das

33

Bereich Ziele Dokumentation in der Arbeit

Installation der Zentralen

Komponenten und Ausbringen der

weiteren Komponenten

generelle Anlernen von

Komponenten

3 Erlangen von Erkenntnissen über

die grundlegende Funktionsweise der

Lösungen und deren verbundenen

Kommunikation

• Darstellung der grundlegenden

Funktionsweise und

Beschreibung von wichtigen

Abhängigkeiten sowie

Grundlagen zur Kommunikation

4 Manuelle Sicherheitsanalyse durch

Prüfung der sicherheitsrelevanten

Grundkonfigurationen und

Konfigurationsmöglichkeiten sowie

das sicherheitsrelevante Verhalten,

Erkundung der Applikations- und

Systemsicherheit durch Prüfung

angelehnt an einen Leitfaden,

Erlangen eins Verständnisses über

die Komplexität der einzelnen

Lösungen

• Exemplarische Beschreibung

der sicherheitsrelevanten

Grundeinstellungen und

weiteren

Konfigurationsmöglichkeiten

• Exemplarische Beschreibung

der Erkenntnisse aus der

Prüfung der Applikations- und

Systemsicherheit

• Dokumentieren von

einsatzspezifischen

Konfigurationen

5 Werkzeuggestützte Analysen

Anwendung von technischen

Sicherheitsanalysewerkzeugen, ggf.

Ergänzung durch alternative

Sicherheitsanalysen

• Exemplarische Darstellung der

Anwendung der Werkzeuge,

Dokumentation der Ergebnisse

• Dokumentation alternativer

Sicherheitsanalyseergebnisse

6 Recherche bekannter

Schwachstellen

• Exemplarische Dokumentation

der gefunden und bekannten

Schwachstellen

7 Analyse des Funkverkehrs auf

Datenebene durch Beobachtung und

Recherche

• Dokumentation des

Protokollaufbaus und der

grundlegenden

Kommunikationsweise

8 Kurzzusammenfassung der

Einzelergebnisse als Grundlage für

den Vergleich

• Dokumentation der

grundlegenden Vor- und

Nachteile der einzelnen Lösung

9 Vergleich • Vergleich der Lösungen in

Bezug auf Funktionsumfang,

Komplexität und Sicherheit

Tab. 2: Vorgehensmodell für die Sicherheitsanalysen (vgl. [BSISEC, S. 23]).

34

In der Tabelle 2 werden die Module der Vorgehensweise dargestellt (vgl. [BSISEC],

[KLWPT]). Nicht alle Module sind in der zeitlichen Komponente voneinander abhängig und

können parallel betrieben werden. Das gilt insbesondere für die Analyse der

Funkkommunikation ab Grundkonfiguration der einzelnen Lösungen. Obligatorisch werden

für die Erkenntniserlangung ebenfalls die Herstellerdokumentationen sowie Internet-

Recherchen genutzt.

Sowohl die HomeMatic als auch die RaspberryMatic präsentieren sich dem*der

Anwender*in als Webapplikation, daher wird als generelle Referenz für die

Sicherheitsbeurteilung und Analyse OWASP Top 10 Web Application Security Risks

[OWAT10] ausgewählt.

OWASP Top 10 Web Application Security Risks

OWASP hat durch eine langjährige Kooperation mit Sicherheitsexpert*innen

unterschiedlichster Branchen und Länder eine Liste der zehn größten Sicherheitsrisiken

von Webapplikationen zusammengestellt. Diese größten zehn Risiken in Bezug auf

Webapplikationen sind nach OWASP [OWAT10G] :

Risikobereich Beschreibung

A1:2017-Injection Injection-Schwachstellen, wie beispielsweise SQL-, OS- oder

LDAP-Injection, treten auf, wenn nicht vertrauenswürdige Daten

von einem Interpreter als Teil eines Kommandos oder einer Abfrage

verarbeitet werden. Ein Angreifer kann Eingabedaten dann so

manipulieren, dass er nicht vorgesehene Kommandos ausführen

oder unautorisiert auf Daten zugreifen kann.

A2:2017-Fehler in

der

Authentifizierung

Anwendungsfunktionen, die im Zusammenhang mit

Authentifizierung und Session-Management stehen, werden häufig

fehlerhaft implementiert. Dies erlaubt es Angreifern, Passwörter

oder Session-Token zu kompromittieren oder die entsprechenden

Schwachstellen so auszunutzen, dass sie die Identität anderer

Benutzer vorübergehend oder dauerhaft annehmen können.

A3:2017-Verlust der

Vertraulichkeit

sensibler Daten

Viele Anwendungen schützen sensible Daten, wie

personenbezogene Informationen und Finanz- oder

Gesundheitsdaten, nicht ausreichend. Angreifer können diese

Daten auslesen oder modifizieren und mit ihnen weitere Straftaten

begehen (Kreditkartenbetrug, Identitätsdiebstahl etc.). Vertrauliche

Daten können kompromittiert werden, wenn sie nicht durch

Maßnahmen, wie Verschlüsselung gespeicherter Daten und

verschlüsselte Datenübertragung, zusätzlich geschützt werden.

Besondere Vorsicht ist beim Datenaustausch mit Browsern

angeraten.

35


A4:2017-XML

External Entities

(XXE)

Viele veraltete oder schlecht konfigurierte XML-Prozessoren

berücksichtigen Referenzen auf externe Entitäten innerhalb von

XML-Dokumenten. Dadurch können solche externen Entitäten dazu

eingesetzt werden, um mittels URI Datei-Handlern interne Dateien

oder File-Shares offen-zulegen oder interne Port-Scans, Remote-

Code-Executions oder Denial-of-Service Angriffe auszuführen.

A5:2017-Fehler in

der Zugriffskontrolle

Häufig werden die Zugriffsrechte für authentifizierte Nutzer nicht

korrekt um-bzw. durchgesetzt. Angreifer können entsprechende

Schwachstellen ausnutzen, um auf Funktionen oder Daten

zuzugreifen, für die sie keine Zugriffsberechtigung haben. Dies

kann Zugriffe auf Accounts anderer Nutzer sowie auf vertrauliche

Daten oder aber die Manipulation von Nutzerdaten, Zugriffsrechten

etc. zur Folge haben.

A6:2017-

Sicherheitsrelevante

Fehlkonfiguration

Fehlkonfigurationen von Sicherheitseinstellungen sind das am

häufigsten auftretenden Problem. Ursachen sind unsichere

Standardkonfigurationen, unvollständige oder ad-hoc

durchgeführte Konfigurationen, ungeschützte Cloud-Speicher,

fehlkonfigurierte HTTP-Header und Fehleraus-gaben, die

vertraulichen Daten enthalten. Betriebssysteme, Frameworks,

Bibliotheken und Anwendungen müssen sicher konfiguriert werden

und zeitnah Patches und Updates erhalten.

A7:2017-Cross-Site

Scripting (XSS)

XSS tritt auf, wenn Anwendungen nicht vertrauenswürdige Daten

entgegennehmen und ohne Validierung oder Umkodierung an

einen Webbrowser senden. XSS tritt auch auf, wenn eine

Anwendung HTML-oder JavaScript-Code auf Basis von

Nutzereingaben erzeugt. XSS erlaubt es einem Angreifer,

Scriptcode im Browser eines Opfers auszuführen und so

Benutzersitzungen zu übernehmen, Seiteninhalte verändert

anzuzeigen oder den Benutzer auf bösartige Seiten umzuleiten.

A8:2017-Unsichere

Deserialisierung

Unsichere, weil unzureichend geprüfte Deserialisierungen

können zu Remote-Code-Execution-Schwachstellen führen.

Aber auch wenn das nicht der Fall ist, können

Deserialisierungsfehler Angriffsmuster wie Replay-Angriffe,

Injections und Erschleichung erweiterter Zugriffsrechte

ermöglichen.

A9:2017-Nutzung

von Komponenten

mit bekannten

Schwachstellen

Komponenten wie Bibliotheken, Frameworks etc. werden mit den

Berechtigungen der zugehörigen Anwendung ausgeführt. Wird eine

verwundbare Komponente ausgenutzt, kann ein solcher Angriff von

Datenverlusten bis hin zu einer Übernahme des Systems führen.

Applikationen und APIs, die Komponenten mit bekannten

Schwachstellen einsetzen, können Schutzmaßnahmen unterlaufen

und so Angriffe mit schwerwiegenden Auswirkungen verursachen.

36


A10:2017-

Unzureichendes

Logging &

Monitoring

Unzureichendes Logging und Monitoring führt zusammen mit

fehlender oder uneffektiver Reaktion auf Vorfälle zu andauernden

oder wiederholten Angriffen. Auch können Angreifer dadurch in

Netzwerken weiter vordringen und Daten entwenden, verändern

oder zerstören. Viele Studien zeigen, dass die Zeit bis zur

Aufdeckung eines Angriffs bei ca. 200 Tagen liegt sowie typischer-

weise durch Dritte entdeckt wird und nicht durch interne

Überwachungs- und Kontrollmaßnahmen.

Tab. 3: Die 10 kritischsten Sicherheitsrisiken für Webanwendungen [OWAT10G]

Die in der Tabelle 3 gelisteten Aspekte der OWASP Foundation werden bei den

Sicherheitsanalysen in der Form angewendet, als das sie auf der einen Seite einen

Leitfaden für die Überprüfung darstellen und auf der anderen Seite gefundene

Schwachstellen den einzelnen Aspekten zugeordnet werden können. Die Tabelle wurde

im deutschen Originalwortlaut übernommen, damit durch mögliche Interpretationen des

Autors dieser Arbeit nicht der ursprüngliche Sinn der Aussagen verändert wird. Im Zuge

der Dokumentation werden im Kontext stehende Begriffe u.a. aus den OWASP Top 10

nach Relevanz weiterführend erklärt.

3.1.2. Werkzeuge

Für den Aufbau, den Betrieb der Lösungen und die Sicherheitsanalysen ist eine gewisse

Infrastruktur verbunden mit Analysewerkzeugen notwendig. Im Folgenden werden die

vorhandene Infrastruktur sowie die ausgewählten Analysewerkzeuge kurz beschrieben.

Ebenso wird kurz dargelegt, wie die Auswahl Werkzeuge erfolgte.

Vorhandene Infrastruktur

Abb. 7: Vorhandene Infrastruktur für die Sicherheitsanalyse

Abbildung 7 zeigt den schematischen Netzwerk-Aufbau auf den beiden Standorten und für

die Analyse relevante Systeme. Zur Vereinfachung der Darstellung wurden die Netzwerk-

Switches nicht abgebildet. Als Basis-Infrastruktur steht sowohl am Standort des

37

Wohnhauses als auch am Standort der Wohnung für die Implementierung und die

Sicherheitsanalysen u.a. eine Ethernet-basierte Netzwerkinfrastruktur zur Verfügung. Die

bestehenden Firewalls sind Unified Threat Management (UTM) Firewalls. UTM Firewalls

stellen u.a. Stateful-Packet-Inspection, Network Address Translation (NAT), Virtual Local

Area Network (VLAN), Web-Proxy, Site2Site-VPN (Virtual Private Network), Remote

Access VPN (für die Einwahl von Benutzer*innen, Network Intrusion Detection/Prevention

zur Verfügung. Die beiden Standorte verfügen jeweils über eine Breitband-

Internetanbindung und sind über einen IPsec-Tunnel (Erweiterung des IP-Protokolls um

Verschlüsselungs- und Authentifizierungsmechanismen) verbunden. Über den IPsec-

Tunnel können in Abhängigkeit der Firewall-Regeln die an das Local Area Network (LAN)

oder die via Wireless Local Area Network (WLAN) auch zwischen den Standorten

kommunizieren. Der Hyper-V Server stellt die Möglichkeit zur Virtualisierung von

Betriebssystemen zur Verfügung. Sämtliche Kernkomponenten der Netzwerkinfrastruktur

(u.a. Internetprovider-Modem, UTM Firewall, WLAN-Access Points) sind durch eine

unterbrechungsfreie Stromversorgung mit Überspannungsschutz abgesichert.

CUL-Stick

Eine Internet-Recherche hat im Zusammenhang mit der Ansteuerung von Smart Home

Komponenten und der Aufzeichnung von Funkdaten u.a. HomeMatic ergeben, dass eine

Open Source Software „culfw“ in Verbindung mit einer kostengünstigen Hardware, einem

kleinen Microcontroller-Board, häufig nicht nur für die Steuerung, sondern auch für die

Analyse der Funkdaten von Smart Home Systemen eingesetzt wird. Für die

wissenschaftliche Arbeit „Sicherheit in der Heimautomatisierung“ wurde von Bastian van

Venrooy (vgl. [BVSH16]) ebenfalls diese Technologie zur Analyse des HomeMatic

Funkstandards eingesetzt.

Der sogenannte CUL-Stick besteht u.a. aus einem Funk-Sende/Empfangs-Chip C1101 von

Texas Instruments und einem Microcontroller-Board mit USB(Universal Serial Bus)-

Anschluss, dass z.B. einen ATMega32U4 Microprozessor enthält (vgl. [CULFW], [BUSW],

[ATM32]). Die Abkürzung „CUL-Stick“ kommt durch den Namen des Funk-Chips CC1101,

dem USB-Anschluss des Microcontroller-Board und durch das Aussehen (leicht eng. light,

einem USB-Stick ähnelnd) zustande und steht für „CC1101-USB-Lite-Stick“ (vgl.

[CULFW]).

Abb. 8: CC1101-USB-Lite 868MHz (CUL) von Busware

38

Abbildung 8 zeigt den CUL-Stick von Busware in der Variante 868 MHz und einer 5cm

Antenne und kostet knapp unter 70 Euro (vgl. [BUSW]).

Um auf beiden Standorten gleichzeitig Beobachtungen der HomeMatic Funkübertragung

durchführen und auch während der Berichtungen Befehle über den CUL-Stick senden zu

können, wurden weitere CUL-Sticks in einer günstigen Selbstbauvariante vom Autor dieser

Arbeit gefertigt.

Abb. 9: Nano-CUL-Stick CC1101-USB-Lite 868MHz (Eigenbau)

Der CUL-Stick im Eigenbau (siehe Abbildung 9) besteht aus einem 868 MHz CC1101-

Funkmodul inkl. Spiralantenne [AMAC11], einer Wendelantenne, einem ATmega328P

basierendem Nano-Microprozessor-Board, Nano-Board, [AMACNA] mit USB-Anschluss

und -Kabel und Verbindungsdrähten [AMACKA] zwischen dem Nano-Board und dem

CC1101-Funkmodul (Nano-CUL-Stick). Der Preis für einen Nano-CUL-Stick liegt unter 16

Euro. Die notwendige Lötausrüstung war bereits vorhanden.

Die Kommunikation zwischen dem CC1101-Funkmodul und dem Nano-Board erfolgt über

das Serial Peripheral Interface (SPI), einer synchronen seriellen Schnittstelle (vgl.

[ARDSPI]).

Abb. 10: Nano-CUL-Stick Verdrahtungsplan

39

Abbildung 10 zeigt die acht Verbindungen, die zwischen dem Nano-Board und dem

CC1101-Funkmodul hergestellt werden müssen. Zusätzlich muss die Antenne an den dem

SPI-Interface gegenüberliegenden mittleren Pin der Platine des CC1101-Funkmoduls

angelötet werden. Der Schaltplan wurde mit dem Tool „Fritzing“ [FRIPRO] erstellt und folgt

der Anleitung von Michael Heck (vgl. [EBCUL]). Die Installation der Firmware auf beiden

Varianten, CUL-Stick und Nano-CUL-Stick kann in wenigen Schritten auf den

Betriebssystemen Linux, Apple OSX oder Windows durchgeführt werden (vgl. [CULFW]).

Die CUL-Firmware unterstützt das ASKSIN-Protokoll (BidCoS) und gibt bei der seriellen

Kommunikation ein „A“ vor den eigentlichen Daten mit aus (Bsp.:

A0BA6A6405B2F2FB2318C047A). Grundsätzlich sind die Daten nicht verschlüsselt, die

einfache XOR-Codierung wird von der CUL-Firmware wieder entfernt, sodass direkt mit

den Ausgaben vom CUL-Stick bzw. Nano-CUL-Stick gearbeitet werden kann.

Splunk

Splunk ist eine Plattform, die zu Zwecken des zentralen Logging, Monitoring und Reporting

in Organisationen eingesetzt wird. Aus unterschiedlichen Datenquellen können u.a. Log-

/Eventinformationen von Systemen angenommen oder abgeholt werden. Splunk bietet

umfangreiche Visualisierungs- und Reporting-Möglichkeiten und wird ebenfalls im Bereich

des Security Information Event Managements (SIEM) eingesetzt (vgl. [SPLUNK]). Da

sowohl die HomeMatic CCU3 als auch die RaspberryMatic CCU Loginformation über

Syslog (ein Protokoll zur Übertragung von Loginformationen über das Netzwerk)

versenden kann, soll eine Möglichkeit geschaffen werden auf einfache Weise diese Logs

zentral zu sammeln und bei der Sicherheitsanalyse bequem darauf zugreifen zu können.

Weiters sollen die über die (Nano-)CUL-Sticks empfangenen Daten über einen längeren

Zeitraum gesammelt und einer statistischen Analyse zugeführt werden können. Splunk

bietet eine kostenlose Version an, die zwar im Funktionsumfang eingeschränkt ist und alle

notwendigen Funktionen für die spätere Auswertung der gesammelten Daten mitbringt.

Splunk ist dem Autor der Arbeit bereits aus seinen frühen beruflichen Tätigkeiten und der

Verwendung in seiner Bachelor-Arbeit bekannt. Die Bereitstellung erfolgt als virtuelle

Maschine auf dem Hyper-V Server unter Ubuntu 18.04.

Kali Linux

Kali Linux ist eine auf Debian-Linux basierende Linux-Distribution, die eine Vielzahl von

Werkzeugen für Sicherheitsüberprüfungen und digitale Forensik enthält (vgl. [KALIL]). Zu

den auf der Distribution enthaltenen Werkzeugen zählt u.a. der OWASP Zed Attack Proxy

(ZAP) welcher zur Prüfung der OWASP Top Ten Schwachstellen entwickelt wurde. Die

Kali Linux-Distribution zählt zu den Top Distributionen für Sicherheitsanalysten (vgl.

[INFSEI]). Die Bereitstellung erfolgt als virtuelle Maschine auf dem Hyper-V Server.

40

Tenable Nessus Essentials

Nessus Essentials ist ein Schwachstellenscanner, der über das Netzwerk die

verschiedensten Schwachstellen von Betriebssystem und Applikationen automatisiert

identifizieren kann (vgl. [TENESS]). Die Essentials-Version von Tenable Nessus verfügt

über einen eingeschränkten Funktionsumfang, ist kostenlos und stellt für die

Sicherheitsanalyse ausreichende Funktionen zur Verfügung. Tenable Nessus Essentials

ist dem Autor dieser Arbeit u.a. durch das Masterstudium, welches mit der

gegenständlichen Arbeit abgeschlossen werden soll, bekannt. Tenable ist laut Forrester

der Marktführer im Bereich „Vulnerability Risk Management“ (vgl. [FORVRM]).

Mobile-Security-Framework (MobSF)

Das Mobile Security Framework ist ein Framework zum automatisierten Test von u.a.

Android und Apple iOS Applikationen. Es dient zur Sicherheitsbewertung von mobilen

Applikationen, kann auf das Vorhandensein von Malware prüfen. Die statische

Analysefunktionalität kann durch eine Ergänzung mit einer Plattform Virtualisierung um

eine dynamische Analyse ergänzt werden. Durch das integrierte REST-API

(Representational State Transfer – Application Programming Interface) kann das Mobile

Security Framework in die Kette des Continuous Integration/Continuous Delivery (CI/CD)

zur Unterstützung eines sicheren Softwareentwicklungszyklus integriert werden (vgl.

[MOBSF]). Mit diesem Werkzeug hat der Autor dieser Arbeit bereits im gegenständlichen

Studium Erfahrungen gesammelt.

JetBrains PyCharm

JetBrains PyCharm ist eine integrierte Entwicklungsumgebung (Integrated Development

Environment – IDE) für die Programmiersprachen „Python“. Der Autor dieser Arbeit hat

PyCharm u.a. bereits im gegenständlichen Masterstudium eingesetzt und PyCharm soll

bei der Entwicklung von eigenen Werkzeugen im Zusammenhang mit der

Sicherheitsanalyse verwendet werden. PyCharm ist ein professionelles

Entwicklungswerkzeug, die Community Version ist kostenfrei (vgl. [JBPYC]).

BidCoS-Sniffer

Für das Kennenlernen und die Analyse des HomeMatic Funkstandards BidCoS wurde vom

Autor dieser Arbeit ein kurzes Python-Programm „sniffer.py“ mit PyCharm entwickelt. Das

Programm steuert über eine USB-Schnittstelle den CUL-Stick bzw. den NANO-CUL-Stick

an und verfügt über folgende Funktionen:

• Datum-/Zeitstempel

• Anzeige der angeschlossenen seriellen Geräte

• Darstellen der Daten aus den Telegrammen

• Aufteilen der Telegrammdaten zur besseren Lesbarkeit

• Zuordnung von Komponentennamen zu den Adressen im Funkprotokoll

41

• Filterfunktion, um nur bestimmte Kommunikationspartner*innen zu beobachten

• Aufbereiten und Übertragen der erfassten Daten an das Splunk-System unter der

Verwendung von Syslog

Fernbedienung --> HomeMatic CCU3

A0BA6A6405B2F2FB2318C047A

Time L C FG TP SENDER RECVR DATA

27-06-2020 23:36:04.728553 0B A6 A6 40 5B2F2F B2318C 047A

Abb. 11: Exemplarische Ausgabe des BidCos-Sniffers

Abbildung 11 zeigt exemplarisch die Bildschirmausgabe des BidCoS-Sniffers mit

kombinierten Gerätenamen, Rohdaten, Zeitstempel und logisch aufgeteilten Daten. Der

Quellcode befindet sich im Anhang A. Bei aktivierter Syslog-Übertragung werden die

empfangenen Daten an das Splunk-System übertragen und haben im Splunk-System

folgendes Aussehen.

Abb. 12: Beispiel-Datensatz des im Splunk-System gespeicherten Telegramms

Abbildung 12 zeigt die im Splunk-System gespeicherten Daten zu dem oben dargestellten

und vom BidCoS-Sniffer erfassten und für die Verarbeitung im Splunk-System

aufbereiteten Daten. Durch die Auftrennung der Felder „Datenfeld=Wert“ kann das Splunk-

System die Werte automatisch ohne weitere Anpassungen extrahieren und die Datenfeld-

Namen können auch in den Suchabfragen verwendet werden.

3.2. HomeMatic

Das folgende Kapitel beschreibt von den Anforderungen über die Implementierung bis zur

Sicherheitsanalyse die Auseinandersetzung mit der HomeMatic Lösung der eQ3-AG.

3.2.1. Anforderungen und Lösungszuordnung

Funktionale und nichtfunktionale Anforderungen

Da durch die Anforderungen an die beiden Standorte Wohnhaus und Stadtwohnung die

Entscheidung auf die RaspberryMatic für das Wohnhaus und die HomeMatic IP gefallen

42

war, wurden für den exemplarischen Aufbau der dritten Lösung HomeMatic folgende

Anforderungen definiert:

Die Implementierung soll exemplarisch, jedoch für die technische Analyse repräsentativ

sein. Das System soll als Einbruchserkennungs- und Lichtschalt-System eingesetzt

werden können. Für die Bedienung soll grundsätzlich ein Web-Interface zur Verfügung

stehen, welches mit einem Standard-Browser aus dem LAN- bzw. WLAN verwendet

werden kann. Eine an einer herkömmlichen Stromsteckdose angeschlossene Lichtquelle

soll über die Lösung geschalten werden können. Die Einbruchserkennungsfunktion soll

zwei Stufen, einen Vollschutz (Bewohner*innen abwesend) und einen Hüllschutz

(Bewohner*innen Anwesend) zur Verfügung stellen. Über eine zweite Möglichkeit der

Steuerung soll es möglich sein, die Einbruchserkennungsfunktion zu kontrollieren und die

Lichtquelle ein- und auszuschalten. Die in Folge der Anforderungen gewählten

Komponenten müssen für den Fall, dass die HomeMatic Lösung nicht dauerhaft an einem

der beiden Standorte eingesetzt wird, auf eine oder Komponentenweise sinnvoll auf die

anderen Standorte verteilt und in das jeweilige System integrierbar sein. Eine Außensirene

soll in Bedachtnahme auf die Tests mit Alarmauslösungen nicht in Betracht gezogen

werden. Sofern Bausätze der Komponenten zu einem reduzierten Preis verfügbar und

lieferbar sind, können auch Bausätze bei der Beschaffung berücksichtigt werden. Ein

Verlegen zusätzlicher Datenleitungen zur Kommunikation zwischen den Komponenten

(Bussystem) wird ausgeschlossen.

Komponentenauswahl

Es werden nur Komponenten mit funkbasierter Kommunikation eingeplant. Im Sinne der

Anforderungen wurden eine HomeMatic CCU3, zwei Tür-/Fensterkontakte, eine

Schaltsteckdose, eine Funkfernbedienung und eine Innensirene ausgewählt. Bei der

Auflösung des exemplarischen Systems können die Komponenten auf die beiden anderen

Standorte aufgeteilt und integriert werden. Die komplette Zentrale CCU3 kann als

Hardware-Komponente für die RaspberryMatic eingesetzt werden.

Komponentenaufstellung

Anzahl Bezeichnung Gesamtpreis

in Euro

1 HomeMatic Smart Home Zentrale CCU3 inklusive AIO

CREATOR NEO Lizenz (CCU-Plugin)

149,95

1 HomeMatic Funk-Schaltaktor 1fach mit Leistungsmessung,

Zwischenstecker HM-ES-PMSw1-Pl

49,95

1 HomeMatic IP Alarmsirene HmIP-ASIR-2 49,95

2 ELV HomeMatic IP Komplettbausatz Fenster- und

Türkontakt HMIP-SWDO, für Smart Home/Hausautomation

39,90

43


in Euro

1 HomeMatic Funk-Handsender, 4 Tasten, zum Schalten der

Alarmanlagenfunktion HM-RC-Sec4-3

29,95

Summe 319,70

Tab. 4: Komponentenliste HomeMatic

Die in der Tabelle 4 erfassten Komponenten wurden vom Autor dieser Arbeit beim

Elektronik-Onlinehändler ELV [ELVSH], einem Schwesterunternehmen der eQ-3 AG,

beschafft. Die Preise verstehen sich als Endverbraucher*innenpreise inkl. der

Mehrwertsteuer, exklusive Versandkosten.

3.2.2. Garantien des Herstellers

Die Lizenzinformation der HomeMatic CCU3 befasst sich im Grunde nur mit einem

Haftungsausschluss für die in der Lösung enthaltene freie Software und es werden keine

Garantien eingeräumt, die über eine gesetzliche Haftung hinausgehen.

„Diese Software enthält freie Software Dritter, die unter verschiedenen Lizenzbedingungen

weitergegeben wird. Eine Auflistung der freien Software, die in dieser Software zum Einsatz

kommt, sowie die Lizenzbedingungen unter denen diese weitergegeben wird, finden Sie

anbei. Die Veröffentlichung der freien Software erfolgt, „wie es ist“, OHNE IRGENDEINE

GARANTIE. Unsere gesetzliche Haftung bleibt hiervon unberührt. Sofern die jeweiligen

Lizenzbedingungen es erfordern, stellen wir Ihnen eine vollständige maschinenlesbare

Kopie des Quelltextes der freien Software zur Verfügung. Kontaktieren Sie uns hierfür bitte

unter [email protected].“ [LEG4]

Für sämtliche Funkkomponenten, damit auch für die Zentrale HomeMatic CCU3 liegen

Konformitätserklärungen vor, die für derartige technische Anlagen innerhalb der

Europäischen Union vorgeschrieben sind (vgl. [KECCU3]). In einer Antwort auf eine Frage

im FAQ-Bereich der eQ-3 AG schreibt die eQ-3 AG, dass der Default-

Systemsicherheitsschlüssel ausreichend sei (vgl. [eQ3AES]). Diese Aussage steht im

Widerspruch zu der Information von Micheal Gernoth, der auf die Veröffentlichung des

HomeMatic Default-AES-Schlüssels hinweist (vgl. [MGDH15]). Im Jahr 2017 wurde die

HomeMatic IP Lösung von AV-Test als sicheres Smart Home-System ausgezeichnet. Für

den Funkstandard lässt sich diese Auszeichnung auch auf die HomeMatic Lösung

übertragen (vgl. [eQ3AT1]). Ähnlich lautend ist das AV-Test Prüfurteil „Sicher“ für die

HomeMatic IP Lösung. Der auch in der HomeMatic Lösung verwendete Funkstandard wird

wieder erwähnt (vgl. [eQ3AT2]). Im Handbuch zur Weboberfläche der HomeMatic CCU3

stellt die eQ-3 AG fest, dass beide Funkprotokolle (HomeMatic und HomeMatic IP)

verschlüsselt sind und die höchsten Standards im Zusammenhang mit Datenschutz und

Sicherheit erfüllen (vgl. [eQ3AT2]). Für die HomeMatic CCU3 Zentrale selbst konnte in der

44

Recherche kein repräsentatives Testat gefunden werden. Die eQ-3 AG bietet einen

Support für ihre Software- und Hardware-Komponenten an, der teilweise von Fachpartner

ausgeführt wird.

3.2.3. Implementierung und Funktion

Im Folgenden sollen kurz die Schritte zur Einrichtung der HomeMatic Lösung in erster Linie

aus der Sicht der Benutzer*innen dargestellt und die grundsätzliche Funktion erklärt

werden.

Die HomeMatic CCU3 wird als Fertiggerät geliefert und muss für die ersten Schritte nur an

das LAN und den Strom angeschlossen werden. Nach dem Starten bezieht das Gerät

automatisch eine IP-Adresse vom lokalen DHCP-Server und ist über einen Webbrowser

im Netzwerk erreichbar. Die ersten Konfigurationsschritte bestehen aus dem Festlegen des

Kennworts für den*die Administrator*in, danach folgend kann man sich entscheiden, ob die

Sicherheitskonfiguration über einen*eine Assistent*in oder Benutzerdefiniert erfolgen soll

(vgl. [eQ3D02, S. 12]). Sind diese Schritte abgeschlossen, kann mit dem Anlernen der

Geräte begonnen werden.

Abb. 13: HomeMatic Webinterface - Leerkonfiguration

Abbildung 13 zeigt das Webinterface der HomeMatic CCU3 Version 3.51.6 nach der

Erstkonfiguration. In den nächsten Schritten werden die Geräte (Sensoren/Aktoren)

angelernt.

45

Abb. 14: HomeMatic Webinterface – Geräte anlernen

Abbildung 14 zeigt den Dialog zum Geräteanlernen. Geräte können grundsätzlich

automatisch direkt angelernt werden, oder es kann die Seriennummer des Geräts

eingegeben werden. Nach einem erfolgreichen Anlernvorgang erscheint das Gerät im

sogenannten Posteingang zur weiteren Bearbeitung (vgl. [eQ3D02, S. 55-60]).

Abb. 15: HomeMatic Webinterface – Geräteliste

Abbildung 15 zeigt die Geräteliste mit den angelernten Geräten. Eine Zuordnung der

Geräte zu Räumen bzw. Gewerken wurde ebenfalls durchgeführt. Die Geräte

kommunizieren bereits mit der HomeMatic CCU3 und senden je nach Komponente in

kurzen bzw. längeren Zeitintervallen ihren Status an die Zentrale. Virtuelle

Fernbedienungen können als Schaltflächen im Webinterface zur Bedienung genutzt

werden. Eine Funktion im Sinne der Anforderungen hat das System allerdings noch nicht.

46

Über Systemvariablen und Programme können die gewünschten Funktionen umgesetzt

werden.

Abb. 16: HomeMatic Webinterface – Systemvariablen

Abbildung 16 zeigt die Liste der Systemvariablen. Alarmzustand und Schutzzustand

wurden hinzugefügt und die Protokollierung aktiviert. Damit wird jede Zustandsänderung

im Systemprotokoll festgehalten. Um den Schutzzustand wechseln zu können, muss eine

Programmlogik hinterlegt werden.

Abb. 17: HomeMatic Webinterface – Programme für Schutzzustände

Abbildung 17 zeigt die drei Programme für das Wechseln der Schutzzustände. In jedem

der Programme ist die Logik hinterlegt, damit über das Webinterface und die

Schlüsselbundfernbedienung die Schutzzustände gewechselt werden können.

47

Abb. 18: HomeMatic Webinterface – Programmlogik „Vollschutz aktivieren“

Abbildung 18 zeigt die Programmlogik. Wird die entsprechende Taste im Webinterface

oder auf der Fernbedienung kurz oder lang gedrückt, wechselt der Schutzzustand

entsprechend der zugeordneten Tasten. Für die Visualisierung des Resultats der

bisherigen Konfigurationen muss noch ein „Favorit“ angelegt werden, welcher die virtuellen

Tasten und die relevanten Systemvariablen enthält.

Abb. 19: HomeMatic Webinterface – Favorit Alarmanlage

48

Abbildung 19 zeigt das Webinterface mit dem Favoriten, welcher die Systemvariablen und

die die virtuellen Tasten enthält. Für das Auslösen eines Alarms sorgen weitere

Programme, die ebenfalls angelegt werden müssen.

Abb. 20: HomeMatic Webinterface – Programm Alarm “Vollschutz“

Abbildung 20 zeigt die Programmlogik für die Alarmauslösung. Das System reagiert im Fall

des Vollschutzes auf die Öffnungssignale beider Fester-/Türkontakte und löst für 180

Sekunden einen optischen und akustischen Alarm aus. Das Alarmsystem ist damit

betriebsbereit. Für das Schalten der Lichtquelle muss eine ähnliche Logik hinterlegt

werden. Mit dieser Programmierung ist die Funktionalität nur dann gegeben, wenn die

Zentrale in Betrieb ist. Alternativ kann eine Direktverknüpfung zwischen Geräten angelegt

werden, um z.B. die Alarmfunktion auch bei Ausfall der Zentrale sicherzustellen. Eine wenn

auch eingeschränktere Stufenlogik für die Schutzzustände stellte im Falle der

Direktverknüpfung die Alarmsirene selbst bereit. Die Zentrale wird in diesem Fall der

befehlsempfangenen Komponente informiert. Zusätzlich zur dargestellten Möglichkeit,

Abläufe zu steuern, bietet die HomeMatic CCU3 noch die Einbindung eigener Programme

in Form von Scripts (vgl. [eQ3D02, S. 102]).

Die HomeMatic CCU3 stellt eine integrierte Update-Möglichkeit für Zentrale selbst und alle

angelernten Komponenten zur Verfügung.

49

Abb. 21: HomeMatic Geräteliste mit Firmware-Übersicht

Abbildung 21 zeigt die angelernten Geräte mit den Firmware-Versionen. Neue Versionen

können aus dem Internet heruntergeladen und über die Zentrale verteilt werden.

3.2.4. Sicherheitsanalyse

Manuelle Analyse

Die HomeMatic CCU3 besteht aus einem Raspberry Pi 3 Model B, einem Funkmodul, einer

microSD-Karte, einem Gehäuse und Steckernetzteil. Zwei der vier beim Raspberry Pi 3

vorhandenen USB-Anschlüsse sind vom Gehäuse abgedeckt und nicht verwendbar. Das

Handbuch zum Webinterface der HomeMatic CCU3 umfasst knapp 360 Seiten (vgl.

[eQ3D02]).

Abb. 22: HomeMatic CCU3 in geöffnetem Zustand

50

Abbildung 22 zeigt die geöffnete HomeMatic CCU3. Das Funkmodul stellt physisch die

Stromversorgung durch einen eigenen Rundstecker zur Verfügung. Die Verwendung eines

für einen Raspberry Pi 3 handelsüblichen Netzteils ist nicht möglich.

Das Webinterface kennt drei Gruppen von Benutzern*innen mit unterschiedlichen

Berechtigungsstufen (vgl. [eQ3D02, S. 16]). Es wird keine Passwortkomplexität

erzwungen, Benutzer*innen können ohne Passwort angelegt werden, eine Änderung des

Passworts ist für den*die angemeldete*n Benutzer*in ohne Eingabe des alten Kennworts

möglich. Passwörter werden einstellig akzeptiert und es besteht die Möglichkeit, die

Namen der angelegten Benutzer*innen vor dem Login anzuzeigen, ein*e Benutzer*in kann

für eine automatische Anmeldung eingestellt werden. Bei mehreren Fehleingaben des

Passworts erfolgt keine Sperren eines Benutzers*einer Benutzerin.

Für das XML-RPC- und das Script-API muss die Authentifizierung manuell aktiviert

werden.

Abb. 23: HomeMatic CCU3 – Konfiguration der Firewall

Abbildung 23 zeigt die Grundeinstellung der Firewall. Auf die einzelnen Dienste können

Einschränkungen für den Zugriff auf Basis Port und IP-Range gemacht werden. Beim

Mediola-Service handelt es sich um die mitgelieferte Schnittstelle für eine externe

Anbindung, diese ist nicht Teil der Betrachtung. Die Einstellungen können frei gewählt

werden. Es steht ein Sicherheitsassistent zur Verfügung und es können Einstellungen in

den Stufen „Maximal gesichert“, „Restriktiv“, „Relaxed“ und „Benutzerdefiniert“ getroffen

werden (vgl. [eQ3D02, S. 166]). Eine sichere Default-Konfiguration ist damit nicht

erzwungen. An den Firewall-Einstellungen lässt sich bereits ein Schichtenaufbau des

Systems erkennen. Die HomeMatic CCU3 zeigt folgenden Systemaufbau:

51

Abb. 24: HomeMatic CCU3 – Systemaufbau

Abbildung 24 zeigt den Systemaufbau der HomeMatic CCU3. Der Bereich „Wired“ ist für

die Steuerung des kabelgebundenen Bussystems, das als Alternative oder Ergänzung zur

Verfügung steht. Dieser Bereich ist nicht Teil der gegenständlichen Betrachtung. Das

Webinterface kommuniziert mit der Logikschicht, in die Programmabläufe gesteuert

werden. Die Logikschicht kommuniziert mit CCU-internen Teilen des Betriebssystems und

mit dem Funkdienst. Über das Webinterface kann ein direkter Zugriff auf die Logikschicht

und auf die angelernten Geräte erfolgen. Ein direkter Zugriff auf die APIs ist ebenfalls

möglich, sofern nicht die Ports gesperrt sind.

Im Webinterface kann der sogenannte „Systemsicherheitsschlüssel“ selbst gewählt

werden (vgl. [eQ3D02, S. 354]). Das im Webinterface als Systemsicherheitsschlüssel

eingegebene Geheimnis wird als MD5-Hash (Message-Digest Algorithm 5) im Dateisystem

abgelegt („/etc/config/keys“) und als Schlüssel für die Kryptographie in der

Funkverbindung genutzt. Der Default-Schlüssel ist bereits bekanntgeworden (vgl.

[MGDH15]). Eine zwingende Eingabe des Systemsicherheitsschlüssels ist nicht

vorgesehen. Das System verfügt über eine manuelle Backup- und Restore-Funktion, bei

einem selbst definierten Systemsicherheitsschlüssel dieser bei der Wiederherstellung des

Backups manuell eingegeben werden muss. Eine Einstellung für ein Session-Timeout ist

vorhanden, der Default-Wert soll 300 Sekunden betragen. Während der Wochen der

Analyse der HomeMatic CCU3 ist allerdings aufgefallen, dass die Sessions nicht in einem

Timeout fallen. Darüber hinaus ist die Session-ID Teil des URL-Pfades. Die aktiven

Sessions werden unter „/var/SESSIONS.dat“ abgelegt.

Ein Zugriff über Secure-Shell (SSH) kann aktiviert werden, die Anmeldung via SSH ist nur

als „root“ möglich. Auch die SSH-Session ist keinem Timeout unterzogen. Die Prüfung des

SSH-Dienstes mit „ssh-audit“ zeigt mehrere Schwächen auf. Die Ausgabe von „ssh-audit“

kann im Anhang B nachgelesen werden.

52

Abb. 25: HomeMatic CCU3 – Prozesse

Abbildung 25 zeigt die Ausgabe des Linux-Befehls „top“. Bis auf den Nachrichtenbusdienst

(dbus) sind alle Prozesse unter dem root-Account gestartet und haben damit die höchsten

Systemrechte. Über die Funktion „Test script“ kann ein*e Benutzer*in, der*die nicht der

Admin-Gruppe angehört und nicht Gast ist, auf dem Betriebssystem Befehle mit root-

Rechten ausführen.

Abb. 26: HomeMatic CCU3 – Webinterface “Test script”

Abbildung 26 zeigt den Zugriff als Nicht-Admin über eine Funktion des Webinterfaces mit

eskalierten Privilegien. Als Betriebssystem wird „Buildroot“ eingesetzt, welches ein Open

Source Linux Distribution für Embedded Systems ist (vgl. [BROOT]). Das Betriebssystem

und einige wichtige Systemkomponenten weisen folgende Versionen auf:

53

Software Version

Betriebssystem „Buildroot“ 2018.08.2-g4dce0d6-dirty

Webserver „lighttpd“ 1.4.5 (ssl)

Java openjdk version "1.8.0_202"

OpenJDK Runtime Environment (Zulu8.36.0.152-

CA-linux_aarch32hf) (build 1.8.0_202-b152)

OpenJDK Client VM (Zulu8.36.0.152-CA-

linux_aarch32hf) (build 25.202-b152, mixed mode,

Evaluation)

Secure Shell Dienst „sshd“ OpenSSH_7.8p1, OpenSSL 1.0.2p 14 Aug 2018

Tab. 5: HomeMatic CCU3 Software-Versionen

Tabelle 5 zeigt die Versionen des Betriebssystems sowie exemplarisch die Versionen von

drei Diensten, die über das Netzwerk erreicht werden können. Die

Applikationskonfigurationen der HomeMatic CCU3 liegen in einer XML-Datei

(/etc/config/homematic.regadom) in der auch die Anmeldeinformationen der

Benutzer*innen gespeichert sind. Als Passwort-Repräsentant dient SHA-512.

Die HomeMatic CCU3 kann automatisch zeitsynchronisiert werden. Über das Webinterface

wird ein Systemprotokoll zur Verfügung gestellt.

Abb. 27: HomeMatic CCU3 – Systemprotokoll

Abbildung 27 zeigt einen Ausschnitt des Systemprotokolls. Ereignisse können dabei

bestimmten Geräten zugeordnet werden, eine Zuordnung zu Benutzer*innen ist nicht

möglich. Dadurch, dass sich die Session-ID im URL-Pfad befindet, werden die Session-

IDs auch im Log des Webservers (/var/log/lighttpd-access.log) aufgezeichnet.

Es konnten keine Logdateien identifiziert werden, die einen erfolgreichen oder erfolglosen

Anmeldeversuch eines Benutzers*einer Benutzerin enthalten. Aktionen im Webinterface

können keinem*keiner Benutzer*in zugeordnet werden.

Grundsätzlich kann die HomeMatic CCU3 mit kleinen Funktionseinschränkungen ohne

Internet-Freischaltung betrieben werden. Das Zurverfügungstellen des Webinterfaces der

HomeMatic CCU3 aus dem Internet durch eine reine Portweiterleitung (Port-Forwarding)

ist vom Hersteller explizit nicht empfohlen.

54

Abb. 28: HomeMatic CCU3 – Update Bestätigungsdialog

Abbildung 28 zeigt den Bestätigungsdialog, in dem die eQ-3 AG explizit davor warnt, Port-

Forwarding nicht zu benutzen und stuft diese Technology sogar als „Sicherheitslücke“ ein.

Eine Abfrage bei einer Suchmaschine für Internet-Systeme und -Dienste hat mehr als 700

im Internet erreichbare HomeMatic-Systeme ergeben (vgl. [SHODAN]).

kali@kali:~$ nmap --script ssl-enum-ciphers -p 443 hm-ccu3

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-30 20:38 CEST

Nmap scan report for hm-ccu3 (10.23.100.11)

Host is up (0.025s latency).

PORT STATE SERVICE

443/tcp open https

| ssl-enum-ciphers:

| TLSv1.2:

| ciphers:

| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A

| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A

| compressors:

| NULL

| cipher preference: server

| warnings:

| Weak certificate signature: SHA1

|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.68 seconds

Abb. 29: HomeMatic CCU3 – Webinterface nmap-Scan Transport Layer Security (TLS)

55

Abbildung 29 zeigt die Ausgabe des Scanners nmap in Bezug auf die Konfiguration der

Transport Layer Security (TLS) des Webservers, welches das Webinterface der

HomeMatic CCU3 zur Verfügung stellt. Gemäß den Empfehlungen des BSI (vgl. [BSITLS,

S. 8]) weichen die vorgefundenen Einstellungen nur im letzten Cipher von der Auflistung

ab, da das SHA-1 Verfahren eingesetzt wird und ebenso für die Signatur des

Serverzertifikats. In diesem Fall handelt es sich um ein selbst signiertes Zertifikat der

HomeMatic CCU3. Daher wird auf Zertifikatswarnungen u.a. in Bezug auf „nicht

vertrauenswürdiges Zertifikat“ nicht eingegangen.

Die gegenständlichen Geräte (Sirene, Fernbedienung, Tür-/Fensterkontakte,

Schaltsteckdose) sind einfach in Betrieb zu nehmen. Sicherheits-Komponenten, wie z.B.

die Tür-/Fensterkontakte und die Sirene verfügen über Sabotagekontakte.

Sabotagemeldungen werden ebenfalls an die Zentral übertragen. Die beiden Bausätze der

Tür-/Fensterkontakte sind mit einer einfachen Elektronik-Lötausrüstung ohne Probleme

zusammenzubauen. Jedem Bausatz liegt eine ausführliche Bauanleitung bei, die auch den

Schaltplan des Geräts enthält (vgl. [HWSDO]). Nicht alle Bauanleitungen sind in digitaler

Form verfügbar. Generell sind die HomeMatic Sensoren und Aktoren mit u.a.

Microkontrollern und Funkmodulen ausgestattet. Die Analyse der Firmware der Sensoren

und Aktoren ist nicht Bestandteil dieser Arbeit.

Automatisierte Analyse

Ein automatisierter Scan mit dem auf Kali Linux enthaltenen OWASP ZAP Scanner ergab

eine mittlere (orange) und eine als gering (gelb) eingestufte Schwachstelle.

56

Abb. 30: HomeMatic CCU3 – ZAP Standard-Scan

Abbildung 30 zeigt das Scanergebnis des OWASP ZAP Scanners. Links unten in der

Abbildung sind unter Alerts die Schwachstellen aufgelistet. Die Session-ID in der URL

wurde bereits bei der manuellen Analyse festgestellt. Problematisch ist dabei, dass die

Session-ID von einem*einer Angreifer*in ausgespäht werden kann und in der Browser-

Historie sowie in Logdateien gespeichert werden kann. Die Fehler in Bezug auf Cache-

Anweisungen im Header erlaubt Browsern und Proxys, Inhalte zu speichern, die bei

richtiger Verwendung der Pragma-Parameter derartig gekennzeichnete Inhalte nicht

speichern würden. Die informellen Alerts (blau) werden aufgrund des geringen

Risikowertes nicht berücksichtigt.

Ein automatisierter Scan mit Nessus ergab zusätzlich zu den bereits gewonnenen

Erkenntnissen noch eine mittelschwere Schwachstelle „Web Server Generic XSS“

gefunden. Diese Schwachstelle kann von einem*einer Angreifer*in dazu ausgenutzt

werden, dass im Browser ein schädlicher Code ausgeführt wird, der z.B. von einer anderen

Website über einen Link oder aus der Applikation selbst geladen wird (vgl. [HAWAS]). Die

Zusammenfassung des Nessus-Scans ist im Anhang C ersichtlich.

Recherche bekannter Schwachstellen

Eine einfache Internet-Recherche bei CVE [MITRE] ergab eine längere Liste an bekannten

Schwachstellen.

57

Abb. 31: HomeMatic CCU3 – Bekannte Schwachstellen

Abbildung 31 zeigt die gekürzte Schwachstellenliste zur HomeMatic. Die meisten dieser

Schwachstellen wurden allerdings bereits von der eQ3-AG geschlossen. U.a. konnte CVE-

2019-9727 nicht mehr positiv verifiziert werden, da die ausschlaggebende Methode

entfernt wurde (siehe auch Anhang D). Weitere Schwachstellen konnten auch zu dem

implementierten Webserver „lighthttpd“ bei CVE [LHTTP] gefunden werden.

Sonstige Wahrnehmungen

Die hohe Komplexität des Systems hat sich bereits bei der beschriebenen Implementierung

im Zusammenhang mit der Hinterlegung der Programmlogik gezeigt. Dazu kommt, dass

z.B. die Alarmsirene bei der Ansteuerung dann nicht funktioniert, wenn die Parameter in

der falschen Reihenfolge abgebildet werden. Nicht zuletzt verfügen viele der Komponenten

über eine granulare Parametrisierbarkeit, die sich bei den Geräten hinter der

Parameterliste verbirgt. Einige der Parameter lassen es zu, das Funkverhalten zu

beeinflussen, mit einem Parameter kann die geräteseitige „Reset“-Funktion deaktiviert

werden (vgl. [eQ3D02, S. 190]). Ein z.B. aus der Zentrale gelöschtes Gerät müsste dann

manuell vom Support zurückgesetzt werden. Eine Möglichkeit, eine*n

abwendende*n*abwesende* Benutzer*in über eine Alarmauslösung proaktiv zu

informieren, besteht nicht. Über die beschriebenen Schwachstellen hinaus konnten keine

Fehlfunktionen über einen längeren Zeitraum der Analyse festgestellt werden.

58

3.2.5. Kurzzusammenfassung der Ergebnisse

Die HomeMatic CCU3 bietet für den*die versierte*n Anwender*in umfangreiche

Funktionen, die in der Fülle der Möglichkeiten im Zuge dieser Arbeit nicht umfassend

beschrieben werden können. Die grundsätzliche Einrichtung ist bis auf das Erstellen der

Programmlogik nicht kompliziert. Die gefundenen Schwachstellen im Design und der

implementierten Technologie führen zum Verständnis, über die Warnung des Herstellers

das Webinterface der CCU3 nicht über Port-Forwarding im Internet zur Verfügung zu

stellen. Die beschriebenen Schwachstellen identifizieren nach den OWASP Top 10 für

Webapplikationen die folgenden Risikokategorien: A2:2017, A3:2017, A5:2017, A7:2017,

A9:2017, A10:2017.

Durch das eher Internet-unabhängige Design der betrachteten HomeMatic-Lösung ist das

System nach Meinung des Autors nicht dem Internet der Dinge zuzuordnen.

3.3. RaspberryMatic


Sicherheitsanalyse die Auseinandersetzung mit der RaspberryMatic Lösung als Zentrale

und Sensor-/Aktor-Komponenten der eQ3-AG.



Für das Wohnhaus soll ein Einbruchserkennungssystem und ein Feuer-/

Raucherkennungssystem realisiert werden. Für die Bedienung soll grundsätzlich ein Web-

Interface zur Verfügung stehen, welches mit einem Standard-Browser aus dem LAN- bzw.

WLAN verwendet werden kann. Die Einbruchserkennungsfunktion soll zwei Stufen, einen

Vollschutz (Bewohner*innen abwesend) und einen Hüllschutz (Bewohner*innen

anwesend), zur Verfügung stellen. Das System soll für eine spätere Anbindung an andere

im Wohnhaus vorhandene Technologien geeignete Schnittstellen aufweisen. Das System

soll auf zumindest einer alternativen Hardwareplattform neben dem Raspberry Pi betrieben

werden können. Eine Außensirene soll in Bedachtnahme auf die Tests mit

Alarmauslösungen nicht in Betracht gezogen werden. Sofern Bausätze der Komponenten

zu einem reduzierten Preis verfügbar und lieferbar sind, können auch Bausätze bei der

Beschaffung berücksichtigt werden. Vorhandene und nutzbare Komponenten sollen soweit

wie möglich Verwendung finden. Ein Verlegen zusätzlicher Datenleitungen zur

Kommunikation zwischen den Komponenten (Bussystem) wird ausgeschlossen. Ein

Vollbetrieb nach der Implementierung ist durch das noch Vorhandensein des Altsystems

nicht zwingend erforderlich.

59

Komponentenauswahl

Auf Basis der Anforderungen erfolgt die Zuordnung der auf der RaspberryMatic basierten

Zentrale zum Wohnhaus. Es werden nur Komponenten mit funkbasierter Kommunikation

eingeplant. Der vorhandene Raspberry Pi sowie das HomeMatic Funkmodul werden zum

Einsatz gebracht. Vier Rauchmelder werden für das Schlafzimmer, die Wohnküche, den

Heizraum und die Garage vorgesehen. Vier Bewegungsmelder sind für Abdeckung der

kritischen Innenbereiche vorgesehen. Für die Absicherung der Eingangstür, des

Garagentors, der Brandabschnittstür (Zugang von der Garage zum Wohnbereich) sowie

der Balkontüre sind Tür-/Fensterkontakte eingeplant. Es kommt eine Innensirene zum

Einsatz.



in Euro

1 Raspberry Pi 3 Modell B, 1 GB; 16 GB SD-Karte;

Kühlkörper; Netzteil (bereits vorhanden)

49,40

1 ELV HomeMatic Komplettbausatz Funkmodul für

Raspberry Pi HM-MOD-RPI-PCB (bereits vorhanden)

19,95

1 HomeMatic Funk-Rauchmelder HM-Sec-SD-2 mit 10

Jahres-Batterie, 3er-Set

139,95

1 HomeMatic Funk-Rauchmelder HM-Sec-SD-2 mit 10

Jahres-Batterie

49,95

4 ELV HomeMatic IP ARR-Bausatz Bewegungsmelder mit

Dämmerungssensor innen HmIP-SMI, für Smart Home

199,80

4 ELV HomeMatic Komplettbausatz Funk-Tür-

/Fensterkontakt, optisch HM-Sec-Sco

79,80

1 ELV HomeMatic Komplettbausatz Innensirene als Mini-

Alarmanlage HM-Sec-Sir-WM

39,95

Summe 578,80

Tab. 6: Komponentenliste RaspberryMatic

Die in der obenstehenden Tabelle 6 erfassten Komponenten wurden vom Autor dieser

Arbeit ebenfalls bei ELV [ELVSH] beschafft. Die Preise verstehen sich als

Endverbraucher*innenpreise inkl. der Mehrwertsteuer, exklusive Versandkosten.

60


RaspberryMatic ist eine Open Source Lösung als Ersatz für die HomeMatic CCU3 Zentrale,

die der Community unter dem Ausschluss jeglicher Garantien zur Verfügung gestellt wird.

Manche Konformitätserklärungen können bei der Verwendung nur in der RaspberryMatic

vorhandenen Funktionen (z.B. das Aktivieren von Bluetooth oder WLAN) ungültig werden

(vgl. [RMAGI, S. 3]). Der Support erfolgt über das Community-Forum und es können auch

Schwachstellen und sonstige Fehlfunktionen gemeldet werden (vgl. [RMAVU]). Der

Funkstandard und die sonstigen anbindbaren Komponenten sind analog zur HomeMatic.


Im Folgenden sollen kurz die Schritte zur Einrichtung der RaspberryMatic-Lösung in erster

Linie aus der Sicht der Benutzer*innen dargestellt und die grundsätzliche Funktion erklärt

werden.

Die RaspberryMatic basiert auf dem HomeMatic-Open-Central-Control-Unit-SDK (HM-

OCCU-SDK) [HMSDK] der eQ-3 AG (vgl. [RMAGI], [RMATI]). Damit bauen die HomeMatic

und die RaspberryMatic auf grundsätzlich der gleichen Codebasis auf. Alle Funktionen und

das Webinterface haben daher nahezu das idente Aussehen und idente Funktionen. Es

existiert kein eigenes Handbuch für die RaspberryMatic. Einige wesentliche Unterschiede

der RaspberryMatic gegenüber der HomeMatic CCU3 sind (vgl. [RMAGI]):

• Plattformunterstützung

o RaspberryPi4 Model B

o ELV-Charly, RaspberryPi3 Model B+, RaspberryPi3 Model B, RaspberryPi3

Model A+, RaspberryPi2 Model B, RaspberryPi Compute Module 3,

RaspberryPi Compute Module 3 lite

o RaspberryPi Zero W, RaspberryPi Zero, RaspberryPi Compute Module 1,

RaspberryPi1 (A+/B+)

o Tinker Board S, Tinker Board

o Intel NUC

o Open Virtual Appliance (OVA) – (ESXi, VirtualBox, Proxmox, Synology,

QNAP, QEmu, HyperV)

• Betriebssystem und Versionen

o Aktuelle Buildroot Version

o Aktuelle Software-Komponenten

• Funktionen

o Datenübernahme aus der HomeMatic CCU3 vollautomatisch möglich

o Erweiterte Anzeigen im Webinterface (z.B. RSSI [Received Signal Strength

Indication]-Werte der Geräte, Batteriespannung)

o Automatisches Backup auf ein Netzwerklaufwerk oder einen USB-Stick

o Betrieb als reines LAN-Funk-Gateway möglich (z.B. in Verbindung mit den

virtualisierten Implementierungen)

61

o Servicemeldungen können pro Geräte deaktiviert werden (z.B. für die

Schaltsteckdose der Weihnachtsbeleuchtung, die sonst nicht am Stromnetz

angeschlossen wird und Nichterreichbarkeits-Meldungen in der Zentrale

auslösen).

o Verbesserter Skript-Editor

o Überwachungsfunktionen u.a. für die Auslastung des DutyCycles

• Frequenz der Updates

o Es werden monatliche Updates zugesagt

Da sich die Grundfunktionen der HomeMatic CCU3 und der RaspberryMatic im

Wesentlichen nicht unterscheiden, wird im Folgenden nur auf die relevanten Unterschiede

eingegangen.

Als Hardware kommt ein bestehendes Raspberry Pi 3 Model B mit dem Funkmodul HM-

MOD-RPI-PCB zum Einsatz.

Abb. 32: Raspberry Pi 3 Model B mit Funkmodul

Abbildung 32 zeigt den Raspberry Pi mit aufgesetztem Funkmodul, Kühlkörpern und

microSD-Karte. Nach dem Download der Software kann z.B. mit dem Programm

balenaEtcher [BETCH] das RaspberryMatic-Image (Version 3.51.6.20200621) auf die SD-

Karte geschrieben werden. Danach erfolgen der Anschluss an das Netzwerk und der

Stromanschluss analog zur HomeMatic.

Sämtliche weiteren Schritte, auch das Anlernen der Geräte, sind ident mit der HomeMatic

CCU3.

62

Abb. 33: RaspberryMatic - Geräteliste

Abbildung 33 zeigt die Liste der an die RaspberryMatic angelernten Geräte. Die

Anzeigenerweiterung um die Batteriespannung und die RSSI-Werte ist deutlich erkennbar.

Die kleinen grün hinterlegten Pfeile zeigen den Trend der Wertentwicklung an. Das

Hinterlegen der Programmlogik folgt den gleichen Rahmenbedingungen.

63

Abb. 34: RaspberryMatic Webinterface - Programmlogik Programm Alarm “Vollschutz“

Abbildung 34 zeigt die Programmlogik für die Alarmauslösung und enthält aufgrund der

Realimplementierung mehrere Geräte als Auslösungsquellen.


Im Rahmen der Sicherheitsanalyse werden ebenfalls nur Abweichungen zur HomeMatic

CCU3 beschrieben.

Manuelle Analyse

Die Zusammenstellung der Hardware wurde bereits dargestellt. Im Unterschied zur

HomeMatic CCU3 hat die Gruppe „Benutzer“ in der RaspberryMatic keine Berechtigung

für den Zugriff auf die Programmeinstellungen. Daher ist es nicht möglich, sich über die

Script-Funktion höhere Rechte zu verschaffen.

Im Vergleich zur HomeMatic CCU3 zeigt die RaspberryMatic deutlich neuere Versionen.

64

Software Version

Betriebssystem „Buildroot“ 2020.05-02432-g34bd6d5a

Webserver „lighttpd“ 1.4.5 (ssl)

Java openjdk version "1.8.0_252"

OpenJDK Runtime Environment (Zulu 8.46.0.225-

CA-linux_aarch32hf) (build 1.8.0_252-b225)

OpenJDK Client VM (Zulu 8.46.0.225-CA-

linux_aarch32hf) (build 25.252-b225, mixed mode,

Evaluation)

Secure Shell Dienst „sshd“ OpenSSH_8.2p1, OpenSSL 1.1.1g 21 Apr 2020

Tab. 7: RaspberryMatic Software-Versionen

Die Tabelle 7 zeigt ein aktuelles Betriebssystem und auch aktuellere Versionen für Java

und den Secure Shell Dienst.

kali@kali:~$ nmap --script ssl-enum-ciphers -p 443 rmatic

Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-01 20:57 CEST

Nmap scan report for rmatic (10.23.202.101)

Host is up (0.030s latency).

PORT STATE SERVICE

443/tcp open https

| ssl-enum-ciphers:

| TLSv1.2:

| ciphers:

| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A

| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A

| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A

| compressors:

| NULL

| cipher preference: server

|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.75 seconds

Abb. 35: RaspberryMatic – Webinterface nmap-Scan Transport Layer Security (TLS)

65

Abbildung 35 zeigt die Ausgabe des Scanners nmap in Bezug auf die Konfiguration der

Transport Layer Security (TLS) des Webservers. Die Verwendung von SHA-1 für die

Signatur des Serverzertifikats zeigt die RaspberryMatic nicht. Die Prüfung mit „ssh-audit“

ergab keine wesentlichen Unterschiede.

Bezüglich der Sensoren und Aktoren besteht kein Unterschied, da alle vom Hersteller eQ-

3 AG geliefert werden.


Der automatisierte Scan mit OWASP ZAP ergab ein unterschiedliches Ergebnis.

Abb. 36: RaspberryMatic – ZAP Standard-Scan

Abbildung 36 zeigt links unten in den Alerts folgende Schwachstellen:

• „Session ID in URL Rewrite (orange)“

o Ident mit HomeMatic CCU3

• „Absense of Anti-CSRF Tokens“

o Ein*e Angreifer*in kann im Namen des angemeldeten Benutzers*der

angemeldeten Benutzerin Aktionen durchführen (vgl. [HAWAS]).

• „Application Error Disclosure“

o Es werden Applikationsfehler ausgegeben, die einem*einer Angreifer*in

zusätzliche Informationen über das System liefern (vgl. [HAWAS]).

66

• „Incomplete or No Cache-control and Pragma http Header Set (20)“

o Ident mit HomeMatic CCU3

• „Private IP Disclosure“

o Der Nutzen ist für eine*n Angreifer*in ident mit dem „Application Error

Disclosure“.

Der Scan mit Nessus ergab ebenfalls zusätzlich die Schwachstelle „Web Server Generic

XSS“. Die Zusammenfassung des Nessus-Scans ist im Anhang E ersichtlich.


In einer Recherche zu bekannten Schwachstellen konnten keine Spezifischen für die

RaspberryMatic identifiziert werden.


Im Sinne der nach den definierten Anforderungen erfolgten Konfiguration stellt sich die

RaspberryMatic ähnlich komplex wie die HomeMatic CCU3 dar. In anderen

Anwendungsgebieten können, die in der RaspberryMatic zusätzlich verfügbaren

Funktionen eine noch höhere Komplexität ergeben. Es fehlt ebenfalls eine Möglichkeit,

eine*n abwendende*n*abwesende*n Benutzer*in über eine Alarmauslösung proaktiv zu

informieren. Fehlfunktionen wurden ebenfalls nicht beobachtet.


Die Ergebnisse sind nahezu vollständig ident mit HomeMatic CCU3.

Die RaspberryMatic bedient sich einer neuern Betriebssystemversion und manche

Systemkomponenten sind aktueller.

3.4. HomeMatic IP


Sicherheitsanalyse die Auseinandersetzung mit der Cloud-basierten HomeMatic IP Lösung

der eQ3-AG.



Für die Stadtwohnung soll ein Einbruchserkennungssystem und ein Feuer-/

Raucherkennungssystem realisiert werden. Zusätzlich sollen die drei in Verwendung

befindlichen Heizungsradiatoren angesteuert werden können. Eine an einer

67

herkömmlichen Stromsteckdose angeschlossene Lichtquelle soll über die Lösung

geschalten werden können. In der Wohnküche sollen die Temperatur und Luftfeuchtigkeit

gemessen werden können. Für die Bedienung soll grundsätzlich eine einfach zu

bedienende mobile App für Android und Apple iOS zur Verfügung stehen, welche die

Bedienung des Systems ortsungebunden über das Internet erlaubt. Im Falle der

Nichtverfügbarkeit des Internets am Standort soll eine zweite unabhängige Möglichkeit

bestehen, das Einbruchserkennungssystem ein- und auszuschalten. Eine Außensirene soll

aufgrund des Mangels einer geeigneten Montageposition nicht in Betracht gezogen

werden. Sofern Bausätze der Komponenten zu einem reduzierten Preis verfügbar und

lieferbar sind, können auch Bausätze bei der Beschaffung berücksichtigt werden. Ein

Verlegen zusätzlicher Datenleitungen zur Kommunikation zwischen den Komponenten

(Bussystem) wird ausgeschlossen. Das implementierte System soll trotz der Analysen im

Zuge dieser Arbeit nach der Implementierung sofort den Vollbetrieb aufnehmen.

Komponentenauswahl

Es werden nur Komponenten mit funkbasierter Kommunikation eingeplant. Für die lokale

Funkkommunikation dient der HomeMatic IP Access Point. Für das Schlafzimmer und die

Wohnküche wird je einen Rauchmelder vorgesehen. Alle drei benutzen

Heizungsradiatoren erhalten statt des manuellen Ventils ein intelligentes Funkventil. Ein

Temperatur- bzw. Luftfeuchtigkeitssensor ist für die Wohnküche eingeplant. Drei

Bewegungsmelder werden die kritischen Innenbereiche abdecken. Für eine Leuchtquelle

wird eine Schaltsteckdose vorgesehen. Eine Innenraumsirene wird die optische und

akustische Signalisierung übernehmen. Zwei Schlüsselbundfernbedienungen sorgen für

die Möglichkeit der Bedienung im Falle eines Internetausfalls, da in diesem Fall der Access

Point ohne den Cloud-Dienst keine lokalen Funktionen ausführen kann.



in Euro

1 HomeMatic IP Access Point - Smart Home Gateway mit

kostenloser App

43,24

1 HomeMatic IP Smart Home Schaltsteckdose HMIP-PS 37,34

2 HomeMatic IP Schlüsselbundfernbedienung HMIP-KRCA 72,64

2 HomeMatic IP Smart Home Rauchwarnmelder HMÍP-

SWSD

114,94

3 HomeMatic IP Smart Home Heizkörperthermostat –

Standard HMIP-ETRV-2

134,31

3 HomeMatic IP Smart Home Bewegungsmelder mit

Dämmerungssensor HM-IPSMI

132,27

68


in Euro

1 HomeMatic IP Temperatur- und Luftfeuchtigkeitssensor –

innen HMIP-STH

27,48

1 Homematic IP Smart Home Alarmsirene HmIP-ASIR,

akustische und optische Signalisierung

45,38

Summe 607,60

Tab. 8: Komponentenliste HomeMatic IP

Die in der obenstehenden Tabelle 8 erfassten Komponenten wurden vom Autor dieser

Arbeit beim Online-Händler Amazon [AMAZ] beschafft. Die Preise verstehen sich als

Endverbraucher*innenpreise inkl. der Mehrwertsteuer, exklusive Versandkosten.


AV-Test hat für die cloudbasierte HomeMatic IP Lösung das Testurteil „sicher“

ausgesprochen. Es wird die Sicherheit des gesamten Systems bestätigt und bietet durch

die Art der Registrierung am Cloud-Dienst (keine personenbezogenen Daten müssen

eingegeben werden) auch den besten Schutz der Privatsphäre. Die Lösung wird sogar als

vorbildlich bezeichnet (vgl. [eQ3AT2]). In den Nutzungsbestimmungen zur Lösung wird der

Cloud-Dienst als kostenlos bereitgestellter Dienst dargestellt, der keine Garantien für die

Verfügbarkeit verbrieft. Es wird von einer angestrebten durchschnittlichen Verfügbarkeit

von 99,5 % (ca. 44 Stunden Nichtverfügbarkeit pro Jahr) im Jahr gesprochen (vgl.

[eQ3IPN]). Der Support wird analog zur HomeMatic angeboten.


Im Folgenden sollen kurz die Schritte zur Einrichtung der HomeMatic IP Lösung in erster

Linie aus der Sicht der Benutzer*innen dargestellt und die grundsätzliche Funktion erklärt

werden.

Die HomeMatic IP Lösung ist eine cloudbasierte Variante der eQ-3 AG Lösungen für die

Heimautomatisierung. Anstelle einer vollständig eigenständigen Zentrale wird als lokale

und zentrale Funkkomponente ein sogenannter „Access Point“ installiert. Die Bedienung

erfolgt über eine mobile Applikation, in Folge als App bezeichnet. Ein Webinterface existiert

nicht.

69

Abb. 37: HomeMatic IP – Access Point (Vorder- und Unterseite)

Abbildung 37 zeigt den geschlossenen HomeMatic IP Access Point von der Vorder- und

der Rückseite. Aus Sicherheitsgründen wurden die zur Registrierung des Access Points in

der Cloud relevanten Informationen (QR-Code, Gerätenummer SGTIN, Key und Passwort)

vom Autor in der Abbildung unkenntlich gemacht.

Das Fertiggerät wird mit dem LAN verbunden und über den Netzadapter an das Stromnetz

angeschlossen. Nach dem Starten bezieht das Gerät automatisch eine IP-Adresse vom

lokalen DHCP-Server. Zur Einrichtung und Bedienung des Systems ist der Download einer

App entweder auf einem Apple iOS Gerät oder auf einem Android Gerät erforderlich (vgl.

[eQ3D01, S. 27]). Die App führt durch den Registrierungsprozess. Durch die englische

Spracheinstellung des Android Smartphones des Autors dieser Arbeit sind alle

Screenshots der App in Englisch gehalten.

Abb. 38: HomeMatic IP – App Einrichtung Access Point 1-3

70

Abbildung 38 zeigt die ersten drei Einrichtungsschritte, um den Access Point mit der Cloud

zu verbinden. Es kann der QR-Code direkt in der App gescannt werden oder die

Gerätenummer wird manuell eingegeben.

Abb. 39: HomeMatic IP – App Einrichtung Access Point 2-6

Abbildung 39 zeigt die letzten drei Schritte der Einrichtung des Access Points und

schließlich der App. Hat sich der Access Point erfolgreich verbunden, muss noch zum

Schutz der Konfiguration ein PIN eingegeben werden. Das Anlernen der Geräte erfolgt in

einer einfachen Weise ebenfalls durch den Scan des QR-Codes auf dem Gerät oder durch

die Eingabe der letzten vier Stellen der Gerätenummer [eQ3D01, S. 35]).

Abb. 40: HomeMatic IP – App Einrichtung Anlernen von Geräten 1-4

71

Abbildung 40 zeigt den Anlernvorgang eines Bewegungsmelders. Der Bewegungsmelder,

der gleichzeitig ein Helligkeitssensor ist, wird in dieser Anwendung der Sicherheit (Security)

zugeordnet. Die einzelnen angelernten Geräte können in Räume zusammengefasst

werden.

Abb. 41: HomeMatic IP – App Funktionalitätsbeispiele

Abbildung 41 zeigt links eine Raumübersicht mit der Schaltfunktion für die Schaltsteckdose

(Lampe), die eingestellte Zieltemperatur für den Raum und die Messdaten von dem Luft-

und Feuchtigkeitsmesser. In dieser Ansicht können über die Symbole z.B. die Alarmanlage

bedient oder ein Heizungsprofil ausgewählt werden. Die zweite Abbildung von links zeigt

die Konfigurationsmenüs, über die z.B. die Geräteliste abgerufen werden kann. Die zweite

Abbildung von rechts zeigt die Geräteliste mit den im Raum „Main“ angelernten Geräten.

Die Abbildung rechts zeigt die Anzeige für einen ausgelösten Alarm, zusätzlich warnt die

App akustisch. Eine Programmierung für die Alarmfunktionen ist nicht erforderlich. Ist eine

Sicherheitskomponente zur Einbruchserkennung und eine Sirene angelernt, kann die

Alarmanlage bereits eingeschalten und verwendet werden. Lediglich für ein zweistufiges

Einbruchserkennungssystem mit Voll- und Hüllschutz müssen Geräte dem Hüllschutz

zugeordnet werden. Die angelernten Schlüsselfunkfernbedienungen verfügen bereits über

entsprechende Symbole auf den vier Tasten, damit kann das Einbruchserkennungssystem

in den Zustand „Vollschutz“, „Hüllschutz“ oder „unscharf“ geschalten werden. Die vierte

Taste trägt ein Lampensymbol. Die Taste kann über eine Automationszuordnung zum Ein-

und Ausschalten des Lichts verbunden oder über eine Gruppe (analog Direktverbindung

bei den anderen Lösungen) mit der Schaltsteckdose zusammengefasst werden. Eine

Updatefunktionalität besteht für die einzelnen Komponenten als auch für die App.

72


Die Sicherheitsanalyse der HomeMatic IP stellt sich durch den Cloud-Charakter erschwert

dar. Es liegen kaum Informationen über das System vor und die Cloud-Komponente sowie

der Access Point können nicht analysiert werden.

Manuelle Analyse

Abb. 42: HomeMatic IP – Access Point geöffnet

Abbildung 42 zeigt den geöffneten Access Point. Es handelt sich um eine proprietäre

Hardware. Lediglich am großen Chip oben in der Mitte kann das Wort „ARM“ identifiziert

werden. Ein namp-Scan gegen die vom DHCP-Server an den Access Point zugeteilte IP-

Adresse blieb bis auf die Ping-Antwort ergebnislos, es konnten keine weiteren erreichbaren

Dienste festgestellt werden.

Direkt auf der Firewall wurden beim ersten Starten des Access Point die Pakete mit

„tcpdump“ für eine Kommunikationsanalyse aufgezeichnet.

Abb. 43: HomeMatic IP – Wireshark HTTP-Analyse

73

Abbildung 43 zeigt die zunächst auf http-basierte Kommunikation des Access Points mit

einem Lookup-Server. Dieser stellt die Information zur Verfügung, mit welchem Cloud-

Server sich der Access Point verbinden soll (vgl. [AVIOTB]).

Ein weiterer Blick auf die Kommunikation offenbart eine ungewöhnliche Kommunikation,

die weder auf Standard-Port noch auf HTTP über TLS basiert (HTTPS).

Abb. 44: HomeMatic IP – Wireshark Kommunikation Access Point

Abbildung 44 zeigt einen Screenshot (Wireshark) von einigen auf der Firewall

aufgezeichneten Netzwerkpaketen des Access Points. Der Access Point kommuniziert auf

den TCP-Ports 43439 und 9292 mit der HomeMatic-Cloud. Die App kommuniziert auf den

TCP-Ports 6969, 8888 und 48335 mit der Cloud (vgl. [eQ3CO]).


Die HomeMatic IP App für die Plattform Android ergab mit dem MobSF folgende

Ergebnisse:

• „Found elf built without Position Independent Executable (PIE) flag“

o Die Applikation läuft damit ohne Address Space Layout Randomization

(ASLR) auf dem Android-Gerät ab. Angreifer*innen werden damit

vereinfacht Sicherheitslücken auszunutzen, da die App vorhersagbare

Speicherbereiche nutzt. (vgl. [AVIOTB]).

• Zugriffsrechte

o Die Applikation weist in der Analyse für die Funktion nicht notwendige

Zugriffsberechtigungen am Android-Gerät auf.

74

Abb. 45: HomeMatic IP App – MobSF ASLR-Schwachstelle

Abbildung 45 zeigt die von MobSF gefundene Schwachstelle mit Einstufung und

Beschreibung. Ein Vergleich mit dem Blog von AV-Test (vgl. [AVIOTB]) lässt den Schluss

zu, dass der AV-Test ebenfalls MobSF zur Analyse eingesetzt hat.

Die wichtigsten Ergebnisse aus dem Report sind im Anhang F abgebildet.

Zur Analyse konnte die Apple iOS Version der HomeMatic IP App nicht beschafft werden.


Außer den von AV-Test dargestellten Schwachstellen konnten keine weiteren recherchiert

werden (vgl. [AVIOTB]).


Die HomeMatic IP war im Sinne der Anforderungen einfach und rasch zu implementieren.

Das System zeichnet sich durch wenig Komplexität aus. Durch die Cloud-Architektur kann

man auf das System praktisch von überall zugreifen. Die angelernten Geräte verbinden

sich automatisch mit einer gesicherten Verbindung. Diese Einstellung kann nicht geändert

werden und ist auch nicht transparent, eben kann die geräteseitige „Reset“-Funktion nicht

deaktiviert werden. Durch die integrierte Alarmierungsfunktion in der App kann

grundsätzlich auf Erweiterungen in diesem Zusammenhang verzichtet werden. Bei Tests

ist aufgefallen, dass bei getrennter Internet-Verbindung ein Alarm ausgelöst und über die

Schlüsselanhängerfernbedienungen deaktiviert werden kann, eine neuerliche Aktivierung

ist ohne Internetverbindung des Access Points nicht möglich. Bei getrennter Internet-

Verbindung des Access Points kann das System wie angenommen nicht über die App

bedient werden. Die App zeigt die Nichterreichbarkeit des Access Points an. Es steht ein

Alarmprotokoll in der App zur Verfügung, welches auch das Aktivieren und Deaktivieren

des Alarmsystems enthält. Das Protokoll identifiziert auch den Gerätenamen, auf dem die

App bedient wurde. Es können mehrere mobile Endgeräte zur Verwendung der App

autorisiert werden. Beim Autorisierungsprozess wird grundsätzlich wie bei der ersten

Registrierung der App vorgegangen, zusätzlich muss zum Abschluss der ursprünglich

definierte PIN eingegeben und die Gerätetaste kurz gedrückt werden. Zwischen den

einzelnen registrierten Apps existiert keine Berechtigungsunterscheidung. Mit der App

lassen sich auch mehrere Installationen verwalten. Das System hat Limitierungen u.a. in

Bezug auf die Anzahl (max. 80) der angelernten Geräte (vgl. [eQ3D01, S. 205]). Ein

Wechsel des Sicherheitsschlüssels für die Funkübertragung ist bei dieser Lösung nicht

möglich. Ob jede HomeMatic IP Access Point mit den individuellen Daten auf der Rückseite

des Geräts einen individuellen Sicherheitsschlüssel bildet, oder ob dieser in der Cloud

75

erzeugt wird, konnte nicht eruiert werden. Die App verfügt über keine Sperrfunktion und

kann bei nicht gesperrtem mobilem Endgerät bedient werden. Es konnten keine

Fehlfunktionen beobachtet werden.


Die HomeMatic IP Lösung bietet umfangreiche Funktionen, versteckt dabei die Komplexität

vor den*der Anwender*in. Der Aufbau und die Bedienung sind einfach. Durch die

Menüführungen in der App – beispielsweise beim Einrichten des Access Points oder beim

Anlernen der Geräte – ist es grundsätzlich nicht notwendig, das etwa 213 Seiten

umfassende Handbuch zu konsolidieren (vgl. [eQ3D01]). Die Schwachstellen

konzentrieren sich nahezu vollständig auf die mobilen Apps. Nach Meinung des Autors

kann die HomeMatic IP Lösung auf Basis des Cloud-Designs und der Erreichbarkeit dem

Internet der Dinge zugeordnet werden.

3.5. Kommunikationsstandard

Die Kommunikation aller drei gegenständlichen Lösungen zwischen den Komponenten

erfolgt über den von eQ-3 AG entwickelten Kommunikationsstandard „BidCoS“

(Bidirectional Communication Standard). Dieser Kommunikationsstandard wird sowohl für

die Funkübertragung als auch für die Übertragung am kabelgebunden Bussystem

„HomeMatic Wired“ eingesetzt. Da in der gegenständlichen Arbeit HomeMatic Wired nicht

Teil der Betrachtung ist, wird nur auf den in der Funkübertragung eingesetzten Standard

eingegangen, der von der eQ-3 AG „BidCoS RF“, in Folge BidCoS genannt, bezeichnet

wird. Dieser Funkstandard ist proprietär und wurde bislang vom Hersteller nicht

offengelegt. BidCoS soll sich besonders dadurch auszeichnen, dass die Kommunikation

zwischen den kommunizierenden Komponenten in beide Richtungen erfolgt und

kryptographisch durch den Advanced Encryption Standard (AES) abgesichert sein soll. Der

kryptografische Standard AES soll dabei zur Authentifizierung dienen. Dabei wird vom

Hersteller die Verwendung des AES-128 (128-Bit) in Kombination mit „Cipher block

chaining – message authentication code“ (CCM) angegeben. Der Funkstandard BidCoS

wird über die Frequenzen 868,3 MHz bzw. 869,525 MHz übertragen und soll eine

Übertragungsreichweite im Freien von 150 bis 400 Meter erreichen (vgl. [eQ3D01]).

3.5.1. Quellen

Aus Ermangelung einer offiziellen Dokumentation wurden daher die folgenden

Erkenntnisse über den Aufbau und die Funktion von BidCoS aus mehreren Quellen

bezogen und um die eigenen Wahrnehmungen ergänzt. Die Darstellung erfolgt auf Basis

der Funkdaten, eine Signal-Analyse ist nicht im Scope der Arbeit.

76

Autor Titel, Format Quelle

Sathya Laufer,

Christian Malla

Attacking HomeMatic, Vortrag [SaMa13]

Frank Graß Staffelung Sendeverhalten, Vortrag [HMUT18]

Michael

Gernoth

Dissecting HomeMatic AES, Blog [MGDH15]

Henryk Plötz On the Security of AES in HomeMatic,

Blog

[HPOSA]

Bastian van

Venrooy

Sicherheit in der Heimautomatisierung,

wissenschaftliche Arbeit

[BVSH16]

Tab. 9: Informationsquellen zu BidCoS

Aus den in der Tabelle 9 aufgelisteten Quellen wurden Informationen über BidCoS

gesammelt, die Informationen nach Referenz und Plausibilität miteinander verglichen und

so weit möglich durch eigene empirisch Erprobungen nachvollzogen und ergänzt. Bei der

Beschreibung von BidCoS in dieser Arbeit handelt es sich um die Darstellung der

grundlegenden Art und Funktion, ein Anspruch zur Vollständigkeit besteht nicht.

Unabhängig der beiden Produktlinien HomeMatic IP und HomeMatic (auch von der eQ-3

AG als HomeMatic Classic bezeichnet) unterscheidet BidCoS die Kommunikation

zwischen HomeMatic IP zu HomeMatic IP und HomeMatic Classic zu HomeMatic Classic.

Anders als die Zentralen HomeMatic CCU3 und RaspberryMatic CCU können die Produkte

der Produktline HomeMatic IP nicht mit denen der HomeMatic Classic direkt

kommunizieren.

3.5.2. Telegramme

Die in BidCoS übertragenen Nachrichten, von der eQ-3 AG als „Telegramme“ bezeichnet,

zeigen folgenden Grundaufbau.

Abb. 46: BidCoS grundlegender Telegrammaufbau

Die in Abbildung 46 dargestellten Abschnitte haben folgende Bedeutung:

Burst: Wird genutzt, um unterschiedliche batteriebetriebene Empfänger in ihren

empfangsbereiten Zeitfenstern zu erreichen.

77

Preamble: Dient den Empfängern zu Erkennung, dass es sich um ein Signal einer

kompatiblen Komponente (HomeMatic Classic oder HomeMatic IP) handelt.

Syncword: Dient den Empfängern dazu den Zeitraster für das nächste zu erwartendem

Signal zu synchronisieren.

Logischer Datenteil: Enthält die für die Mess- und Steuertätigkeiten relevanten

Informationen.

CRC: Der Cyclic Redundancy Check, die zyklische Redundanzprüfung, dient zur Prüfung

ob die Daten einen Übertragungsfehler aufweisen.

Die im Weiteren dargestellten Telegramme wurden von den Komponenten unter

Verwendung des Default-AES-Schlüssels erzeugt.

3.5.3. Ungesicherte Verbindung

Da der für die Analysen verwendete CUL-Stick im Grunde nur den logischen Datenteil

ausgibt, kann eine genaue Beschreibung nur für diesen Teil eines Telegramms erfolgen.

Der logische Datenteil weist folgenden Aufbau auf (einfacher Schaltbefehl einer

Schlüsselanhängerfernbedienung ohne gesicherte Verbindung):

Abb. 47: BidCoS Beispiel Telegramm ohne gesicherter Verbindung – generisch

Abbildung 47 zeigt den grundlegenden Aufbau eines BidCoS Telegramms. Die einzelnen

Telegrammteile haben folgende Bedeutung:

Length (Länge): Telegrammlänge, ein Byte; Diese Byte wird bei der Längenberechnung

nicht berücksichtigt.

Counter (Zähler): Telegrammzähler, ein Byte; Dieser Zähler wird je Telegramm um eins

erhöht.

Flag (Kennzeichen): Ein Byte; Bit 0 – WakeUp, Bit 1 – WakeMeUp, Bit 2 – Broadcast, Bit

3 – reserviert, Bit 4 – Burst, Bit 5 – Acknowledge Request (für bidirektionale Befehle), Bit 6

– Repeated, Bit 7 – Repeat Enabled

78

Diese Flags werden dazu verwendet, um z.B. das Telegramm zu kennzeichnen, dass es

von einem Repeater weitergeleitet werden darf und für den Empfänger, dass das

Telegramm über einen Repeater empfangen wurde. Als Repeater können

Schaltsteckdosen eingesetzt werden, die permanent mit Strom versorgt sind. Ebenso

werden Broadcasts, Aufweck-Signale und Antwort-Anforderungen mit den entsprechenden

Flag-Bits versehen.

Type (Typ): Ein Byte; Dieses Byte bezeichnet die Art des Events. Im konkreten Beispiel

wurde eine Taste an einer Funkfernbedienung gedrückt. Als Referenz können die XML-

Dateien der einzelnen Komponenten in der HomeMatic CCU3 sowohl als auch in der

RaspberryMatic CCU herangezogen werden (Tag: frames; Bsp.:

/firmware/rftypes/rf_rc-4-2.xml). Die Event-Typen können neben dem

genannten Beispiel u.a. auch Bewegungserkennungen, Helligkeitsänderungen oder

Statusdatenübertragungen für den Datenteil ankündigen.

Sender: Drei Bytes; BidCoS-Adresse der sendenden Komponente. Im Falle der

HomeMatic CCU3 und der RaspberryMatic CCU hat jede Zentrale je eine Adresse für die

Kommunikation zu HomeMatic IP-Komponenten und eine für die Kommunikation zu

HomeMatic Classic-Komponenten. Die Seriennummern, ausgenommen der zentralen

Einheiten, werden während dem Anlernverfahren erzeugt. Die mathematische Berechnung

für die Basis der Erzeugung der BidCoS konnte nicht in Erfahrung gebracht werden.

Receiver (Empfänger): Drei Bytes. BidCoS-Adresse des Empfängers. Die Empfänger-

Adresse kann auch 0x000000 für einen Broadcast (HomeMatic) oder Multicast

(HomeMatic IP) oder leer sein. Es konnten auch Werte wie 0xE00002, 0xF00001,

0xF00004 und 0xF00005 beobachtet werden. Bei diesen Adressen könnte es sich

unbestätigter Weise auf Basis der Senden-Komponenten um Broadcast-Adressen für

Gruppen handeln (z.B. Rauchmelder-Gruppe, Temperatursteuerungs-Gruppe, Alarm-

Gruppe).

Data (Daten): Unterschiedliche Byte-Längen möglich. Nutzdaten. Die Nutzdaten wie

Schaltbefehle, Messdaten oder Statusmeldungen sind unverschlüsselt und können

mitgelesen und interpretiert werden. Bei einer ungesicherten Kommunikation kann durch

das Weiterzählen des Counters z.B. ein beliebiger Schaltbefehl von einem nicht in das

System eingebundenen Sender abgesetzt werden. Dieser wird dann vom Empfänger

ausgeführt, als käme das Telegramm vom eingebundenen System. Der Empfänger hat

keine Möglichkeit, zwischen solchen Telegrammen zu unterscheiden.

Ein einfacher Schaltbefehl, wie im vorherigen Beispiel „EIN“ dargestellt, involviert je eine

Nachricht zwischen Sender und Empfänger. Bei einer Direktverknüpfung zwischen den

Komponenten (z.B. Funkfernbedienung und Schaltsteckdose) erfolgt eine zusätzliche

Nachricht der Schaltsteckdose an die Zentrale als Information über den Schaltvorgang.

79

Abb. 48: BidCoS Beispiel Telegramme mit gesicherter Verbindung

Abbildung 48 zeigt alle vier beim Schaltvorgang involvierten Telegramme. Durch die in der

Zentrale konfigurierte Direktverbindung wird von der Fernbedienung der Schaltbefehl an

die Schaltsteckdose gesendet, die den Befehl ausführt und die Ausführung an den Sender

bestätigt. Da die Schaltsteckdose an die Zentrale angelernt ist, erfolgt die

Zustandsänderung durch die Schaltsteckdose an die Zentrale, die den Empfang des

Telegramms über die Zustandsänderung der Schaltsteckdose bestätigt.

Die Beobachtung von drei Einschaltbefehlen hintereinander lässt einen zusätzlichen

Counter in den Nutzdaten erkennen. Beim folgenden Beispiel werden nur die reinen

Befehl-Telegramme der Funkfernbedienung an die Schaltsteckdose betrachtet. Die jedem

Einschaltbefehl gefolgten Ausschaltbefehle sowie die Antworten und die Kommunikation

zur Zentrale wurden für einen besseren Überblick entfernt.

80

Abb. 49: BidCoS Beispiel Telegramme mit ungesicherter Verbindung - Befehlscounter

Aus Abbildung 49 ist ersichtlich, dass nicht nur der Telegramm-Counter (0x80, 0x82,

0x84) hochgezählt wird, sondern auch in den Nutzdaten das Byte 11 (0x57, 0x58, 0x59).

Byte 10 (0x02) ist hier der Schaltbefehlt „EIN“ der Taste 1 an der Fernbedienung. Der erste

Counter dient zu Erkennung, ob ein Telegramm bereits empfangen wurde, der Counter in

den Nutzdaten soll das wiederholte Ausführen von bereits abgearbeiteten Befehlen

verhindern. Durch das Senden der Zeichenfolge As0B86A4405B2F2F68B32B0260 an

den CUL-Stick konnte diese Theorie bestätigt werden. Die vor das Telegramm gesetzten

Buchstaben As teilen dem CUL-Stick mit, dass die Daten im BidCoS-Format gesendet

werden sollen (vgl. [CULFW]).

3.5.4. Gesicherte Verbindung

Bei der gesicherten Verbindung zwischen den Komponenten (auch der Zentrale) werden

vier Telegramme je Kommunikationspaar übertragen. Die folgende Abbildung zeigt einen

Schaltbefehl einer Fernbedienung an die Zentrale, um einen Systemzustand in der

Zentrale zu verändern (Bsp.: Einbruchserkennung von „unscharf“ auf „Hüllschutz“

schalten).

81

Abb. 50: BidCoS Beispiel Telegramm gesicherte Verbidnung, Challenge-Resonse

Die in Abbildung 50 dargestellten einzelnen Telegramme in einer abgesicherten

Verbindung haben folgende Funktion:

Schaltbefehl: Ähnlich dem ersten Beispiel für ein Schalttelegramm wird der Befehl mit

unverschlüsselten Daten an den Empfänger übertragen.

Challenge: Der Empfänger sendet darauf eine zufällig generierte Zahl als Challenge an

den ursprünglichen Sender zurück und erwartet die Lösung der Aufgabe.

Response: Der ursprüngliche Sender verarbeitet die Challenge unter Zuhilfenahme des

AES-CCM und sendet die verschlüsselte Payload, den Response, an den ursprünglichen

Empfänger zurück.

Bestätigung: Wiederum unter Anwendung des AES-CCM prüft der Empfänger, ob der

Sender die Aufgabe richtig gelöst hat. Ist dies der Fall, wird dem Sender eine Bestätigung

für den ausgeführten Befehl übermittelt, der einen Authentisierungscode enthält, damit der

ursprüngliche Sender die Authentizität der Bestätigung ebenfalls prüfen kann.

82

Kryptografie

Die kryptografischen Berechnungen konnten wie folgt nachvollzogen werden. Zur

besseren Vergleichbarkeit wurden die Telegramme aus der Quelle [MGDH15]

übernommen.

Abb. 51: BidCoS Telegramm zur Nachberechnung (vgl. [MGDH15])

Abbildung 51 zeigt die vier Telegramme, anhand derer die Berechnung exemplarisch

nachvollzogen werden kann.

Werte aus der Abbildung:

P Parameter (5 Bytes), Schaltbefehl, Klartext

C Challenge (6 Bytes), zufällig vom Prüfer erzeugt

PL AES-Payload (16 Bytes), verschlüsselt

MT Die ersten 11 Bytes des ersten Telegramms (a-frame)

AP Ack-Params (5 Bytes), Schaltantwort, Klartext

AD Auth-Data (4 Bytes) AES-CCM Authentifizierungsdaten

Der Schlüssel 𝐾 ist der Default-Key (16 Bytes) (vgl. [MGDH15])

Zuerst wird ein temporärer Schlüssel 𝐾′ erzeugt. Der Schlüssel 𝐾 wird mit der Challenge

𝐶, die auf 16 Byte-Länge mit Nullbytes aufgefüllt (Padding) wird, Exklusiv-Oder verknüpft.

𝐾′ = 𝐾 ⨁ (𝐶 ∥ 𝑃𝑎𝑑["0", 16]) . (3.5.4.1)

83

Mit dem Schlüssel 𝐾′ wird die AES-Payload 𝑃𝐿 zu 𝑃𝐿′ mit AES-128 entschlüsselt.

𝑃𝐿′ = 𝐷𝐾′(𝑃𝐿) . (3.5.4.2)

Das Zwischenergebnis 𝑒 wird durch eine weitere Exklusiv-Oder-Operation von den

Parametern 𝑃 gepaddet auf 16 Bytes und 𝑃𝐿′ erzeugt.

𝑒 = (𝑃 ∥ 𝑃𝑎𝑑["0", 16]) ⨁ 𝑃𝐿′ . (3.5.4.3)

Die Authentifizierungsdaten AD sind die ersten vier Bytes von 𝑒 .

𝑃𝐿′′ = 𝐷𝐾′(𝑒) . (3.5.4.4)

Eine weitere Entschlüsselung von 𝑒 mit dem Schlüssel 𝐾′ liefert 𝑃𝐿′′, wobei die ersten fünf

Byte von 𝑃𝐿′′ eine Art Zufallszahl oder Zeitstempel T des Initiators ist. Bis zu diesem Schritt

war T nur dem Initiator bekannt.

Das dargestellte Verfahren kann durch den vom Initiator ursprünglich errechneten

Response 𝑃𝐿 auf die Challenge 𝐶 validiert werden. Zum Einsatz kommt der AES-128 im

CBC-Mode.

Der Initialisierungsvektor 𝑐0 wird aus 16 Nullbytes gebildet.

𝑐0 = 𝐼𝑉 . (3.5.4.5)

Der erste Verschlüsselungsblock wird mit der Nachricht 𝑚1 verknüpft durch eine Exklusiv-

Oder-Operation mit 𝑐0 durchgeführt. 𝑚1 setzt sich aus den ersten 16 Bytes von T

konkateniert mit MT und P und gepaddet auf 32 Bytes zusammen.

𝑐1 = 𝐸𝐾′(𝑚1 ⨁ 𝑐0) . (3.5.4.6)

Der zweite Verschlüsselungsblock wird mit der Nachricht 𝑚2 verknüpft durch eine

Exklusiv-Oder-Operation mit 𝑐0 durchgeführt. 𝑚2 setzt sich aus den letzten 16 Bytes von

T konkateniert mit MT und P und gepaddet auf 32 Bytes zusammen. Das Ergebnis 𝑐2 ist

die Payload PL.

𝑐2 = 𝐸𝐾′(𝑚2 ⨁ 𝑐1) . (3.5.4.7)

Die ersten vier Bytes von 𝑐1 bilden wiederum die Authentifizierungsdaten AD.

Eine programmatische Umsetzung zu dem dargestellten Verfahren in Python kann im

Anhang G nachgelesen werden. Der Default-Schlüssel (vgl. [MGDH15]) wurde vom Autor

bewusst aus dem Python-Programm entfernt, da er den Schlüssel nicht mit dieser Arbeit

veröffentlichen möchte.

84

Ein*e Angreifer*in kann somit nach Synchronisierung auf die Counter im vorangegangen

Telegramm trotz gesicherter Verbindung valide Steuerbefehlt senden, sofern im System

der Default-Schlüssel nicht geändert wurde.

3.5.5. Laufzeitunterschiede

Die folgende Abbildung soll im Vergleich zwischen ungesichertem und gesichertem

Verfahren den deutlichen Zeitunterschied für die Abarbeitung des Schaltbefehls aufzeigen.

Abb. 52: BidCoS Zeitdiagramm – gesicherte und ungesicherte Verbindung im Vergleich

Aus der Abbildung 52 ist aufgrund der doppelten Anzahl an Telegrammen und dem

Senderaster (hier 125 ms) gut zu erkennen, dass sich bei der gesicherten Verbindung eine

deutliche Verlängerung der Zeit zwischen dem Tastendruck und dem erfolgten

Schaltvorgang ergibt. Ohne der gesicherten Verbindung ist der Schaltvorgang nach 30 ms

erfolgt, bei gesicherter Verbindung erst nach 250 ms, einem Achtfachen der Zeit im

Vergleich zur ungesicherten Verbindung.

Sende- und Empfangsstrategien dienen dazu, Komponenten mit Batterieversorgung und

unterschiedlichen Leistungsbelastungen (z.B. Heizungsventil, elektrischer

85

Türschlossantrieb) durch ein besonderes Energiemanagement aus dem Bereich der

Funkkommunikation bestmöglich in Bezug auf den Batterieverbrauch zu entlasten.

Während z.B. eine Schaltsteckdose immer auf Empfang ist, sind besonders Rauchmelder

mit einer maximalen Batterielebensdauer von zehn Jahren nur zu bestimmten Zeiten

empfangsbereit. Die eQ-3 AG unterscheidet bei den Burst-Signalen zwischen „Single

Burst“ und „Triple Burst“. Die Burst-Signale werden je nach Empfängertyp jeweils kurz vor

dem „Aufwachen“ des Empfängers in seinem langen „Schlafzyklus“ – Tripple-Burst und

seinem kurzen Schlafzyklus „Single-Burst“ am Anfang eines Telegramms gesendet. Damit

kann der Empfänger energieschonend erkennen, dass ein Signal folgt, dass er zu

verarbeiten hat. Telegramme werden bei HomeMatic Classic nur auf 868,3 MHz gesendet

und empfangen. Das HomeMatic IP System verwendet zusätzlich noch 869,525 MHz, um

die Sendezeit durch den Duty-Cycle (maximale Sendezeit 36 Sekunden in einer Stunde)

reglementierten Frequenzbereich von 868 MHz zu entasten. Außerdem werden Firmware-

Updates bei HomeMatic IP ebenfalls unter Nutzung der Frequenz 869,525 MHz

übertragen, um die gesamte Zeit für die Zustellung des Updates zu verkürzen, die bei der

Nutzung von 868,3 MHz als Übertragungsfrequenz bis zu mehreren Tagen dauern kann.

3.5.6. Geräte anlernen und Schlüsseländerung

Die Telegramme beim Anlernen von Geräten unterscheiden sich grundsätzlich nicht von

anderen Telegrammen der Kommunikation zwischen den Komponenten. Beobachtet

werden konnte nur, dass beim Anlernen eine Vielzahl an Telegrammen ausgetauscht wird.

Dies kann mit der Übertragung der Gerätekonfigurationen in Zusammenhang stehen.

Bei der Änderung des Sicherheitsschlüssels auf der HomeMatic CCU3 oder

RaspberryMatic Zentrale sendet die Zentrale ein Telegramm aus. In diesem beobachteten

Beispiel hat die Schlüsselanhängerfernbedienung mit mehreren Telegrammen auf die

Nachricht geantwortet, ohne dass die Zentrale weitere Telegramme an das Gerät

verschickt hat.

HomeMatic CCU3 --> Fernbedienung

A192EA004B2318C5B2F2FEA8E82C363E991058DC6288B8E9FF583

Time L C FG TP SENDER RECVR DATA

03-07-

2020 22:42:01.324570 19 2E A0 04 B2318C 5B2F2F EA8E82C363E99105

8DC6288B8E9FF583

Abb. 53: BidCoS Telegramm – Änderung des Sicherheitsschlüssels

Obwohl der ursprüngliche Sicherheitsschlüssel sowie der neu erzeugte

Sicherheitsschlüssel bekannt sind, konnte durch mehrere Versuche der Entschlüsselung

nicht auf den neuen Schlüssel im Telegramm (siehe Abbildung 53) geschlossen werden.

86

3.5.7. Statistik und Privatsphäre

Aus der reinen statistischen Auswertung der in Splunk gesammelten Telegramme lassen

sich ebenfalls Erkenntnisse ableiten.

Abb. 54: Splunk – Telegramm-Summenstatistik über mehrere Tage pro Tag

Abbildung 54 zeigt, dass bei der HomeMatic IP im dargestellten Zeitraum bis zu knapp

3500 Telegramme am Tag versendet werden. Eine Auswertung über die gesamte

Erfassungsdauer über die maximale Telegrammlänge hat für die BidCoS Classic

Funkprotokoll 19 Byte und für das BidCoS IP Funkprotokoll 27 Byte ergeben. Eine

nachweisliche Erklärung konnte dafür nicht beigebracht werden.

87

Da Parameterwerte im Klartext übertragen werden, konnten u.a. die Spannungsmesswerte

der Schaltsteckdose direkt aus den Statusmeldungs-Telegrammen errechnet werden.

Abb. 55: Splunk – Telegramme mit Spannungswert

Abbildung 55 zeigt den Spannungsverlauf in Volt über eine gewisse Zeitdauer. Der

Spannungswert wurde direkt aus den Telegrammdaten errechnet (siehe Splunk

Suchkommando ganz oben links in der Abbildung 55).

Eine Beobachtung des Verhaltens der Bewohner*innen ist ebenfalls über eine statistische

Auswertung möglich.

88

Abb. 56: Splunk – Telegramm-Statistik pro HomeMatic IP Komponente

Abbildung 56 zeigt die Anzahl der Telegramme über mehrere Stunden pro HomeMatic IP

Komponente. Da bei dieser Lösung Bewegungsmelder im Einsatz sind, könnte auf

Anwesenheit- bzw. Abwesenheit der Bewohner*innen geschlossen werden. Ist die

Darstellung auf die Bewegungsmelder reduziert, ergibt sich ein klareres Bild.

Abb. 57: Splunk – Telegramm-Statistik HomeMatic IP nur Bewegungsmelder

Abbildung 57 zeigt die Anzahl der Telegramme von nur HomeMatic IP Bewegungsmeldern

im Verlauf von wenigen Stunden. Ganz oben in der Abbildung sind die dem Autor

bekannten An- und Abwesenheiten sowie die Schlafzeit bekannt. Da sich in dieser

89

Implementierung ein Bewegungsmelder im Schlafzimmer befindet, registriert dieser auch

die Bewegungen im Schlaf von Bewohner*innen.

3.6. Vergleich der Systeme

Der folgende Vergleich soll die drei gegenständlichen Lösungen der Heimautomatisierung

auf Basis der gewonnenen Erkenntnisse in Form von Beurteilungskategorien

gegenüberstellen.

Kriterium/System HomeMatic RaspberryMatic HomeMatic

IP

Komplexität hoch hoch gering

Funktionsumfang hoch hoch ausreichend

Verlässlichkeit des Systems hoch hoch hoch

Parametrierbarkeit auf

Expert*innen-Niveau ja ja nein

Möglichkeit der erweiterten

Programmierung ja ja nein

Integriertes Rollen- und

Berechtigungskonzept ja ja nein

Möglichkeit der Einschätzung der

Sicherheit durch eine*n versierte*n

Anwender*in

ja ja teilweise

Vertrauenswürdige

Sicherheitsüberprüfung Dritter liegt

vor

nein nein ja

Cloud-Abhängigkeit nein nein ja

Einfache und sichere Bereitstellung

im Internet bzw. Bedienbarkeit aus

dem Internet gegeben

nein nein ja

Anforderungen an die technischen

Kenntnisse des Anwenders*der

Anwenderin

hoch hoch gering

Funkstandard BidCoS Classic

und IP

BidCoS Classic

und IP BidCoS IP

Funkkommunikation abgesichert ja ja Ja

90

Kriterium/System HomeMatic RaspberryMatic HomeMatic

IP

Durchschnittliche Kosten pro

Komponente mit anteiligen Kosten

für die zentrale Steuerung in Euro

53,28 44,52 43,40

Tab. 10: Vergleich der drei Lösungen

Tabelle 10 zeigt die Einschätzung des Autors für die vom Autor definierten

Bewertungskategorien. Die Tabelle kann eine Lösungsfindung dahingehend erleichtern,

dass auf Basis der eigenen Voraussetzungen und Ansprüche an die Lösung die Auswahl

gestützt auf konkrete Eigenschaften der einzelnen Lösungen getroffen werden kann. Der

Kostenvergleich ist für den experimentellen Aufbau der HomeMatic mit wenigen

Komponenten nicht repräsentativ. Bei den realen Implementierungen der RaspberryMatic

und HomeMatic IP mit einer größeren Anzahl und vergleichbaren Komponenten

(insbesondere Rauch- und Bewegungsmelder) ist nur ein geringer Preisunterschied im

Durchschnitt erkennbar.

91

4. Informationssicherheitsrisiken

Im folgenden Abschnitt sollen über eine Bedrohungsanalyse in Verbindung mit einer

Risikoeinschätzung mögliche Informationssicherheitsrisiken in der Heimautomatisierung

identifizieren. Zusätzlich soll aufgezeigt werden, mit welchen Maßnahmen mögliche

Risiken mitigiert werden können.

4.1. Bedrohungsanalyse

Zunächst sollen exemplarisch mögliche Bedrohungen anhand des STRIDE-Modells

evaluiert werden (vgl. [MSTM17]). Die Auflistung hat keinen Anspruch auf Vollständigkeit.

Lösung Annahme Bedrohungsbereich und

-beschreibung

HomeMatic/RaspberryMatic Das Webinterface

ist über Port-

Forwarding im

Internet

bereitgestellt, die

automatische

Anmeldefunktion

ist für eine*n

privilegierte*n

Benutzer*in aktiv

Spoofing: Das System

kann aus dem Internet

uneingeschränkt bedient

werden.

Tampering: Unautorisierte

Veränderungen können

durchgeführt werden.

Repudiation: Andere

Systeme im Internet

werden vom

übernommenen System

angegriffen.

Information Disclosure:

Daten von anderen im

Netzwerk befindlichen

Systemen werden

gestohlen.

Denial of Service: Das

System wird auf den

Auslieferungszustand

zurückgesetzt oder der

Zugriff für Berechtigte

gesperrt.

Elevation of Privilege: Ein

Vollzugriff auf andere

Systeme im Netzwerk wird

erreicht.

92


-beschreibung

HomeMatic/RaspberryMatic Das Webinterface

ist über Port-

Forwarding im

Internet

bereitgestellt, die

automatische

Anmeldefunktion

ist nicht aktiv.

Spoofing: Ein Vollzugriff

kann erreicht werden.




Repudiation: Andere

Systeme im Internet

werden vom

übernommenen System

angegriffen.


Daten von anderen im

Netzwerk befindlichen

Systemen werden

gestohlen.

Denial of Service: Das

System wird auf den

Auslieferungszustand

zurückgesetzt oder der

Zugriff für Berechtigte

gesperrt.

HomeMatic/RaspberryMatic/HomeMatic

IP

Keine Spoofing: Es werden

unautorisierte Aktionen

durch Senden von

Funktelegrammen

ausgelöst.

Tampering: Das

Alarmsystem wird

deaktiviert.


Verhaltensweisen der

Bewohner*innen können

ausspioniert werden.

Denail of Service: Die

ordnungsgemäße

Funkverbindung des

Systems wird vollständig

gestört.

HomeMatic IP Das mobile

Endgerät mit der

App ist nicht




93


-beschreibung

gesperrt und

unbeaufsichtigt.

Denial of Service:

Berechtigte

Benutzer*innen können

aus dem System

ausgesperrt werden.

HomeMatic IP keine Denial of Service: Der

Cloud-Dienst wird

angegriffen und

lahmgelegt bzw. die Daten

im Cloud-Dienst werden

zerstört.

Tab. 11: Bedrohungsanalyse nach dem STRIDE-Modell

Tabelle 11 setzt sich mit möglichen Bedrohungen in Verbindung mit Annahmen

auseinander und beschreibt exemplarisch einige Kategorien nach dem STRIDE-Modell.

4.2. Risiken

In der folgenden Risikoanalyse sollen die Bedrohungen um Nichtvorsatztaten ergänzt und

in Kombination mit der Eintrittswahrscheinlichkeit und Schadenseinschätzung zu einer

Analyse der Risiken aus im Beriech Informationssicherheit übergeführt werden.

Dazu wird zunächst eine generische Risikomatrix erstellt, die eine systematische

Zuordnung zu einem Risikowert auf der Grundlage von Eintrittswahrscheinlichkeit und

Schadensausmaß erlaubt (vgl. [ÖISHB19, S. 99, 102]).

Eintrittswahrscheinlichkeit/Schadenshöhe gering mittel hoch

hoch mittel hoch hoch

mittel gering mittel hoch

gering gering gering mittel

Tab. 12: Risikomatrix

Tabelle 12 zeigt die Zuordnung zur Risikostufe (Risk-Level) kombiniert aus

Eintrittswahrscheinlichkeit und Schadenshöhe. Im Weiteren sollen die einzelnen

Bedrohungen unter Berücksichtigung bestehender Sicherheitsmaßnahmen in Bezug auf

Eintrittswahrscheinlichkeit und Schadenshöhe eingeschätzt und einer Risikostufe

zugeführt werden. Als Schäden kommen materielle und immaterielle Schäden in Betracht

94

(vgl. [ÖISHB19, S. 105]). Bei der Betrachtung werden die nicht-cloudbasierten Lösungen

zusammengefasst, die Analyse erfolgt exemplarisch.

Die durch Risiken bedrohten Werte bedeuten im Schadenfall nicht immer nur einen

materiellen (Geld-) Wertverlust. Es können auch immaterielle Schäden entstehen, die zum

Beispiel bei Verlust von nicht wiederbeschaffbaren Werten (z.B. digitale Erinnerungsfotos)

miteinhergehen. Auch Reputationsschäden sind im privaten Bereich denkbar, wenn

sensible Daten gestohlen und veröffentlich werden (vgl. [ÖISHB19, S. 97-100]).

95

HomeMatic und RaspberryMatic

Bedrohung existierende Mitigationsmaßnahmen Eintrittswahr-

scheinlichkeit Schadenshöhe Risikostufe

Logische Zerstörung des zentralen Systems

durch unberechtigten Zugriff aus dem Internet

oder über die lokale Infrastruktur

keine

hoch mittel hoch

Datendiebstahl und Missbrauch durch

unberechtigten Zugriff aus dem Internet über

die Zentrale auf andere lokale Systeme

keine

hoch hoch hoch

Zerstörung von Daten durch unberechtigten

Zugriff aus dem Internet über die Zentrale auf

andere lokale Systeme

keine

hoch mittel hoch

Störung des Funkverkehrs bei einem

Einbruchsversuch

keine mittel mittel mittel

Ausspähen des Bewohner*innen-Verhaltens

durch den Funkverkehr des Systems

keine gering gering gering

Versagen der Alarmierungsfunktion durch

fehlerhafte Konfiguration


Tab. 13: Risikobewertung – HomeMatic und RaspberryMatic

Tabelle 13 zeigt das potenzielle Risiko (Risikostufe) durch die Bedrohungen ohne Mitigationsmaßnahmen.

96

HomeMatic IP



Der Cloud-Dienst steht nicht zur Verfügung keine gering gering gering

Der*Die Benutzer*in wird aus dem System

durch missbräuchliche Verwendung der App

ausgesperrt

keine

gering gering gering

Das Internet steht nicht zur Verfügung, das

System kann nicht mehr ortsunabhängig

bedient werden

keine



Einbruchsversuch


Ausspähen des Bewohner*innen-Verhaltens

durch den Funkverkehr des Systems

keine gering gering gering



keine gering mittel gering

Tab. 14: Risikobewertung – HomeMatic IP

Tabelle 14 zeigt das potenzielle Risiko (Risikostufe) durch die Bedrohungen ohne Mitigationsmaßnahmen.

Im Folgenden sollen Maßnahmen zur Minderung der Risiken diskutiert werden. Generell kann Risiken u.a. durch Vermeidung, Minderung und

Umwälzen (z.B. Versicherung) begegnet werden.

97

4.3. Möglichkeiten zur Risikomitigation

Beim Einsatz von Heimautomationssystemen sind die damit verbundenen Risiken, wie

bereits dargestellt, von der Auswahl und Implementierung des Systems abhängig. In erster

Linie sollte eine einigermaßen sichere Infrastruktur für die IT-Komponenten des Heim-

Netzwerks als Voraussetzung für die Implementierung eines Heimautomationssystems

geschaffen werden. Eine grundlegend abgesicherte IT-Infrastruktur sollte daher folgende

exemplarische Ausprägungen aufweisen (vgl. [SIHNW]):

• Basis

o Sämtliche Komponenten stammen aus vertrauenswürdigen Quellen.

o Betriebssysteme und Programme sind auf einem aktuellen Stand.

o Schutzsoftware wird, sofern auf den Systemen verfügbar, eingesetzt und ist

ebenfalls aktuell.

o Firewall-Funktionen stellen sicher, dass nur der notwendige Internet-Zugriff

stattfinden kann.

o Das WLAN ist sicher konfiguriert (Einstellungen und entsprechende

Schlüssellänge für die Authentifizierung).

o Gästen wird kein Zugriff auf die Infrastruktur mit deren Geräte gestattet.

o Pro System wird ein individuelles Passwort verwendet.

o Konfigurationsoberflächen für z.B. die Firewall oder den WLAN-Router sind

durch individuelle Kennwörter geschützt (Änderung des Default-

Kennworts).

• Erweitert

o Das Netzwerk ist in Zonen segmentiert. Die einzelnen Zonen enthalten

Systeme gruppiert nach Schutzbedarf und der Verkehr auch zwischen den

Zonen ist auf das Notwendige eingeschränkt.

o Die Firmware von Netzwerk-Komponenten, wie z.B. Switches wird auf

einem aktuellen Stand gehalten.

o Für Gäste besteht ein eigenes WLAN mit ausschließlichem Zugriff auf das

Internet und der Einschränkung auf Basisdienste des Internets (z.B. Web

Browsing und E-Mail).

o Der Zugriff auf das interne Netzwerk ist nur über VPN-Remote-Access

möglich.

• Optimal

o Für jede zentrale Einheit eines Heimautomationssystems besteht eine

eigene Netzwerkzone mit Kommunikationsbeschränkungen.

o WLAN-basierte Heimautomationssysteme werden mit dem LAN in einer

eigenen Zone eingeschlossen.

o Die Firewall (UTM-Firewall) bietet u.a. zusätzliche Schutzfunktionen:

▪ VPN-Zugriff auf zusätzlicher Zertifikatsbasis

▪ Country-Blocking (der VPN-Zugriff kann auch auf Länder

eingeschränkt werden)

▪ Web-Proxy (Clients haben keine direkte Verbindung zum Internet)

98

Eine neuerliche Risikobewertung mit entsprechenden Gegenmaßnahmen soll zeigen,

inwieweit sich die identifizierten Risiken minimieren lassen. Ziel ist es, die Risiken zu

adressieren, die nicht die Risikostufe „gering“ haben.

Für geplante Mitigationsmaßnahmen sollten ebenfalls eine Bedrohungsanalyse und eine

Risikobewertung durchgeführt werden, da bei der Erhöhung der Komplexität von Systemen

zusätzliche Risiken entstehen, die einer Bewertung und Behandlung zugeführt werden

müssen. Eine derartige Behandlung wird in dieser Arbeit nicht durchgeführt, da der

exemplarische Umgang mit Bedrohungen und Risikobewertungen dargestellt wurde.

99

HomeMatic und RaspberryMatic nach Mitigation



Logische Zerstörung des zentralen

Systems durch unberechtigten Zugriff aus

dem Internet

Der Zugriff ist nur über eine sichere VPN-

Verbindung möglich. Die Infrastruktur ist

basisgeschützt.

gering

(vorher: hoch) mittel

gering

(vorher: hoch)

Datendiebstahl und Missbrauch durch

unberechtigten Zugriff aus dem Internet

über die Zentrale auf andere lokale

Systeme



basisgeschützt.

gering

(vorher: hoch) hoch

mittel

(vorher: hoch)

Zerstörung von Daten durch

unberechtigten Zugriff aus dem Internet

über die Zentrale auf andere lokale

Systeme



basisgeschützt.

gering

(vorher: hoch) mittel

gering

(vorher: hoch)


Einbruchsversuch

Das System wird durch mindestens eine

kabelgebundenen Erkennungskomponente

ergänzt. Ändern des Default-Schlüssels.

gering

(vorher: mittel) mittel

gering

(vorher: mittel)

Ausspähen des Bewohner*innen-

Verhaltens durch den Funkverkehr des

Systems

keine




Die Konfiguration wird durch Szenarien

basierte Tests geprüft oder durch eine*n

Expert*in durchgeführt.

gering

(vorher: mittel) mittel gering

Tab. 15: Risikobewertung – HomeMatic und RaspberryMatic nach Mitigation

100

HomeMatic IP nach Mitigation



Der Cloud-Dienst steht nicht zur Verfügung keine gering gering gering

Der*Die Benutzer*in wird aus dem System

durch missbräuchliche Verwendung der

App ausgesperrt

keine


Das Internet steht nicht zur Verfügung, das

System kann nicht mehr ortsunabhängig

bedient werden

keine



Einbruchsversuch

Das System wird durch mindestens eine

kabelgebundene Erkennungskomponente

ergänzt.

gering

(vorher: mittel) mittel

gering

(vorher: mittel)

Ausspähen des Bewohner*innen-

Verhaltens durch den Funkverkehr des

Systems

keine




keine gering mittel gering

Tab. 16: Risikobewertung – HomeMatic IP nach Mitigation

Die Tabellen 15 und 16 zeigen, dass sich mit relativ geringem Aufwand die Informationssicherheitsrisiken bei der Heimautomatisierung in den

Fällen der drei Beispiele deutlich verringern lassen.

101

5. Conclusio

Die Conclusio dieser Arbeit fasst die wesentlichen Erkenntnisse zusammen, beantwortet

die Forschungsfragen und gibt einen Ausblick auf eine mögliche weitere Behandlung der

Thematik.

5.1. Zusammenfassung

In dieser Arbeit wurden die Grundlagen der Heimautomatisierung und der

Informationssicherheit dargestellt und es wurden essenzielle Erklärungen zu den in der

Funkübertragung angewendeten kryptografischen Verfahren gegeben. Die drei

gegenständlichen und exemplarischen Lösungen wurden vorgestellt und implementiert.

Neben der Darstellung der Funktionsweisen der einzelnen Lösungen wurden diese

einander gegenübergestellt. Die Sicherheitsanalysen haben einerseits Schwachstellen

aufgezeigt, Vor- und Nachteile, andererseits die grundsätzliche Funktionsweise des nicht

offengelegten Funkstandards BidCoS erklärt. Die Bedrohungsanalyse und die

Einschätzung der Informationssicherheitsrisiken haben die Grundlage für mögliche

Mitigationsmaßnahmen gebildet und es konnten wirksame Maßnahmen zur Reduktion der

Informationssicherheitsrisiken dargestellt werden. In Folge werden die Forschungsfragen

beantwortet.

5.2. Beantwortung der Forschungsfragen

Die zu Beginn der Arbeit gestellten Forschungsfragen werden in diesem Abschnitt

zusammenfassend mit den entsprechenden Verweisen auf die Bearbeitung in der Arbeit

beantwortet.

Frage: Welche Informationssicherheitsrisiken ergeben sich durch den Einsatz der

Lösungen?

Antwort: Es ergeben sich unterschiedliche Informationssicherheitsrisiken je nach

Auswahl, Art und Einsatz der jeweiligen Lösung. Die Risiken werden durch mehrere

Faktoren beeinflusst und können bis zu einem hohen Schadensausmaß reichen. Die

Risiken bestehen in allen drei Bereichen der Informationssicherheit – Vertraulichkeit,

Integrität und Verfügbarkeit und bedrohen die materiellen und immateriellen Werte der

Benutzer*innen. Die detaillierte Behandlung der Fragestellung ist im Kapitel 4.2

beschrieben.

Frage: Welche Sicherheitsgarantien bestehen seitens der Hersteller und was enthalten

diese?

102

Antwort: Grundsätzlich geben die Hersteller keine Sicherheitsgarantien. Lediglich im

Bereich der Cloud-basierten HomeMatic IP ist ein Sicherheitsbestreben des Herstellers

durch die durch AV-Test positiv durchgeführte Attestierung erkennbar. Je Lösung sind im

Kapitel 3 die einzelnen Garantien der Hersteller beschrieben.

Frage: Warum warnen die Hersteller davor, ihre lokal implementierten Steuerzentralen

über den eigenen Router über Portweiterleitung im Internet zur Verfügung zu stellen?

Antwort: Die Sicherheitsanalysen haben ergeben, dass sowohl die HomeMatic als auch

die RaspberryMatic massive konzeptionelle als auch technische Schwachstellen

aufweisen. Darüber hinaus weisen beide Lösungen keine sichere Default-Konfiguration auf

und die Benutzer*innen können durch eigene Konfiguration die Systemsicherheit

weiterführend reduzieren. Für eine über Portweiterleitung im Internet bereitgestellte

Zentrale beider Lösungen kann daher niemand eine Sicherheitsgarantie abgeben. Die

Sicherheitsanalysen werden im Kapitel 3 behandelt.

Frage: Wie sieht eine konkrete Implementierung der einzelnen drei Lösungen aus und

welche Kosten sind dafür vorzusehen?

Antwort: Die Lösungen kosten zwischen knapp 320 Euro für die exemplarische

Implementierung bis etwa 600 Euro für die Implementierungen in der Stadtwohnung bzw.

im Wohnhaus. Die einzelnen konkreten Implementierungen sind im Kapitel 3 beschrieben.

Frage: Wie kann ein Betrieb der einzelnen Lösungen abgesichert und die Risiken auf ein

akzeptables Maß reduziert werden?

Antwort: Durch eine sichere Bereitstellung für den Zugriff aus dem Internet können die

größten Risiken reduziert werden. Das Risiko, welches die funkbasierte Kommunikation

zwischen den Komponenten mit sich bringt, kann durch eine Kombination mit

kabelbasierter Kommunikation zu weiteren Erkennungskomponenten reduziert werden.

Die exemplarische Maßnahme zur Risikominderung und die Restrisiken sind im Kapitel 4.3

beschrieben.

Frage: Wie sicher sind die einzelnen Lösungen im Vergleich?

Antwort: Am Sichersten hat sich die Cloud-basierte HomeMatic IP herausgestellt. Die

HomeMatic und die RaspberryMatic liegen auf dem gleichen Sicherheitsniveau.

Komplexität und die Art der Implementierung der Lösungen tragen einen wesentlichen

Aspekt zur Sicherheitseinstufung der einzelnen Lösung bei. Der Vergleich der drei

Lösungen befindet sich in Kapitel 3.6.

103

5.3. Future Work

Auf Basis dieser Arbeit kann ein Anforderungs- bzw. Auswahlkatalog für

Heimautomationssysteme erstellt werden. Unter Berücksichtigung funktionaler und nicht

funktionaler Anforderungen, den Kenntnissen von lösungssuchenden Anwender*innen

und Risikoakzeptanzschwellen ist ein eventuell in einer Applikation abgebildetes

Auswahlverfahren abbildbar.

Denkbar ist, den Herstellern die Ergebnisse dieser Arbeit in einer verkürzten

Zusammenfassung zur Verfügung zu stellen. Im Falle der RaspberryMatic ist eine

Mitwirkung im Community-Projekt für den Bereich Sicherheit denkbar.

Eine weitere wissenschaftliche Arbeit kann auf Basis dieser Arbeit die Absicherung des

Funkprotokolls in Form eine Kryptoanalyse behandeln.

104

Literaturverzeichnis

[AMAC11] Amazon: Onlineshop, TECNOIOT 2pcs CC1101 868MHz. Online im

Internet:

https://www.amazon.de/gp/product/B07RH67FWV/ref=ppx_yo_dt_b_asin_i

mage_o04_s00?ie=UTF8&psc=1 (Stand 27.06.2020)

[AMACKA] Amazon: Onlineshop, AZDelivery Jumper Wire Kabel 40 STK. Online im

Internet: https://www.amazon.de/AZDelivery-Jumper-Arduino-Raspberry-

Breadboard/dp/B07KYHBVR7/ref=sr_1_9?__mk_de_DE=%C3%85M%C3

%85%C5%BD%C3%95%C3%91&dchild=1&keywords=arduino+kabel&qid

=1593277831&s=ce-de&sr=1-9 (Stand 27.06.2020)

[AMACNA] Amazon: Onlineshop, AptoFun 2pcs Nano V3.0 mit Org.ATmega328P/

FT232RL Chip Development Board mit USB Kabel. Online im Internet:

https://www.amazon.de/gp/product/B07JJN8NZ3/ref=ppx_yo_dt_b_asin_tit

le_o07_s00?ie=UTF8&psc=1 (Stand 27.06.2020)

[AMAZ] Amazone: Homepage. Online im Internet: https://www.amazon.de (Stand

28.06.2020)

[ARDSPI] Arduino: Referenz, SPI library. Online im Internet:

https://www.arduino.cc/en/Reference/SPI (Stand 27.06.2020)

[ATM32] Microship: Homepage, Produkt ATmega32U4. Online im Internet:

https://www.microchip.com/wwwproducts/en/ATmega32u4 (Stand

27.06.2020)

[AVIOTB] AV-Test: AV Internet of Things Blog, eQ-3 Homematic IP erneut als sicheres

Smart Home Produkt zertfiziert. Online im Internet: https://www.iot-

tests.org/de/2020/04/eq-3-homematic-ip-erneut-als-sicheres-smart-home-

produkt-zertfiziert (Stand 01.07.2020)

[BEIDK] Buchmann, J.: Einführung in die Kryptographie. Springer, Berlin, Heidelberg,

5. Auflage, 2010.

[BETCH] Balena: Homepage, Etcher. Online im Internet: https://www.balena.io/etcher

(Stand 01.07.2020)

[BNA14] Bundesnetzagentur: Allgemeinzuteilung von Frequenzen zur Nutzung durch

Funkanwendungen mit geringer Reichweite für nicht näher spezifizierte

Anwendungen; Non-specific Short Range Devices (SRD), 2014. Online im

Internet:

https://web.archive.org/web/20170803112453/https://www.bundesnetzage

ntur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unte

rnehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2014_69_SRD_p

df.pdf?__blob=publicationFile&v=1 (Stand 21.06.2020)

105

[BROOT] Buildroot: Homepage. Online im Internet: https://buildroot.org (Stand

29.06.2020)

[BSI200-1] Bundesamt für Sicherheit in der Informationstechnik (BSI): BSI-Standard

200-1, Managementsysteme für Informationssicherheit (ISMS),

Deutschland, 2017. Online im Internet:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Ko

mpendium/standard_200_1.pdf?__blob=publicationFile&v=8 (Stand

21.06.2020)

[BSIDGS] Bundesamt für Sicherheit in der Informationstechnik (BSI): Digitale

Gesellschaft, Sicherheitsrisiken. Online im Internet: https://www.bsi-fuer-

buerger.de/BSIFB/DE/DigitaleGesellschaft/KommunikationUeberInternet/C

hatAberSicher/Sicherheitsrisiken/sicherheitsrisiken_node.html (Stand

21.06.2020)

[BSIITG] Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz.

Online im Internet:

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/itgrundschutz_node.ht

ml (Stand 22.06.2020)

[BSISEC] Bundesamt für Sicherheit in der Informationstechnik (BSI): Leitfaden zur

Entwicklung sicherer Webanwendungen, Empfehlungen und

Anforderungen an die Auftragnehmer, Bonn, 2013. Online im Internet:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Stu

dien/Webanwendungen/Webanw_Auftragnehmer.pdf?__blob=publicationF

ile&v=2 (Stand 22.06.2020)

[BSITLS] Bundesamt für Sicherheit in der Informationstechnik (BSI): Technische

Richtlinie TR-02102-2Kryptographische Verfahren: Empfehlungen und

Schlüssellängen. SWDO. Online im Internet:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Te

chnischeRichtlinien/TR02102/BSI-TR-02102-

2.pdf?__blob=publicationFile&v=10 (Stand 29.06.2020)

[BUSW] busware: Onlineshop, CC1101-USB-Lite 868MHz (CUL). Online im Internet:

http://shop.busware.de/product_info.php/cPath/1_35/products_id/29 (Stand

27.06.2020)

[BVSH16] Bastian van Venrooy: Sicherheit in der Heimautomatisierung, Bonn, 2016.

Online im Internet: https://www.h-

brs.de/files/20171215_fbinf_mclab_2016_venrooy_ba_sicherheitsmechani

smen_mk.pdf (Stand 13.06.2020)

[CULFW] culw: Homepage der Open Source Firmware. Online im Internet:

http://culfw.de/culfw.html (Stand 27.06.2020)

106

[CVSS] First: Common Vulnerability Scoring System. Online im Internet:

https://www.first.org/cvss/v3-1 (Stand 22.06.2020)

[DKRYP] Wätjen, D.: Kryptographie. Spektrum Akademischer Verlag, Heidelberg, 2.

Auflage, 2008.

[EBCUL] Michael Heck, nanoCUL 868/433 MHz Eigenbau - Haussteuerung Teil 5.

Online im Internet: https://michael-heck.net/index.php/raspberry-pi/nanocul-

868-433-mhz-eigenbau-hausautomatisierung-teil-

5?highlight=WyJjdWwiXQ== (Stand 27.06.2020)

[ELCCU3] ELV: Datenblätter, HomeMatic CCU3. Online im

https://files2.elv.com/public/15/1519/151965/Internet/151965_data.pdf

(Stand 29.06.2020)

[ELVAGB] ELV: Allgemeine Geschäftsbedingungen. Online im Internet:

https://de.elv.com/agb (Stand 28.06.2020)

[ELVSH] ELV: Homepage, Smart Home Systeme. Online im Internet:

https://at.elv.com/technik-fuer-ihr-zuhause/smart-home-systeme (Stand

28.06.2020)

[eQ320] Pressebericht eQ-3 AG, Berg Insight kürt eQ-3 zum fünften Mal zum

Marktführer, Leer, 2020. Online im Internet: https://www.eq-

3.de/presse/detail/berg-insight-kuert-eq-3-zum-fuenften-mal-zum-

marktfuehrer.html (Stand 13.06.2020)

[eQ3AES] eQ-3 AG: FAW-Bereich, Stimmt es, dass die Verschlüsselung des

HomeMatic Systems nicht sicher ist bzw. das System gehackt wurde? Wie

kann ich mein HomeMatic System vor Angriffen schützen? Online im

Internet: https://www.eq-3.de/service.html (Stand 13.06.2020)

[eQ3AT1] eQ-3 AG: Presseinformation, Homematic IP von AV-Test als sicheres

Smart-Home-System ausgezeichnet. Online im Internet: https://www.eq-

3.de/presse/detail/homematic-ip-von-av-test-als-sicheres-smart-home-

system-ausgezeichnet.html (Stand 28.06.2020)

[eQ3AT2] eQ-3 AG: Presseinformation, „Vorbildlicher Schutz“: AV-TEST zeichnet

Sicherheit von Homematic IP aus. Online im Internet: https://www.eq-

3.de/presse/detail/vorbildlicher-schutz-av-test-zeichnet-sicherheit-von-

homematic-ip-aus.html (Stand 28.06.2020)

[eQ3C1] Homepage eQ-3 AG, Firmengeschichte, 2020. Online im Internet:

https://www.eq-3.de/ueber-uns.html (Stand 13.06.2020)

[eQ3CO] eQ-3 AG: FAQ-Bereich, Was muss ich bei der Einrichtung des Homematic

IP Access Points beachten? Online im Internet: https://www.eq-

3.de/service/faq/netzwerkeinstellungen.html (Stand 01.07.2020)

107

[eQ3D01] eQ-3 AG: Anwenderhandbuch, HomeMatic IP. Online im Internet:

https://www.homematic-

ip.com/downloads/download/handbuecher/Homematic_IP-

Anwenderhandbuch.pdf (Stand 13.04.2020)

[eQ3D02] eQ-3 AG: WebUI Handbuch. Online im Internet: https://www.eq-

3.de/Downloads/eq3/download%20bereich/handbuecher/WebUI_Handbuc

h_eQ-3.pdf (Stand 28.06.2020)

[eQ3IPN] eQ-3 AG: Nutzungsbedingungen für die Homematic IP App und Homematic

IP Cloud. Online im Internet: https://www.homematic-

ip.com/kontakt/datenschutz/eula.html (Stand 28.06.2020)

[eQ3SUP] eQ-3 AG: Technischer Support für Kunden, Infos und Ansprechpartner.

Online im Internet: https://www.eq-3.de/service/support.html (Stand

28.06.2020)

[ETSI18] ETSI: Final draft ETSI EN 300 220-2 V3.2.1 (2018-04) Short Range Devices

(SRD) operating in the frequency range 25 MHz to 1 000 MHz; Part 2:

Harmonised Standard for access to radio spectrum for non specific radio

equipment, 2018. Online im Internet:

https://www.etsi.org/deliver/etsi_en/300200_300299/30022002/03.02.01_3

0/en_30022002v030201v.pdf (Stand 21.06.2020)

[FIAES] National Institute of Standards and Technology: Federal Information

Processing Standards Publication 197, ADVANCED ENCRYPTION

STANDARD (AES). Online im Internet:

https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-

197.pdf (Stand 03.07.2020)

[FORVRM] Tenable: Homepage, Tenable Is a Leader in The Forrester Wave™:

Vulnerability Risk Management, Q4 2019. Online im Internet:

https://www.tenable.com/analyst-research/forrester-wave-

2019?utm_source=homepage&utm_medium=tenable-

website&utm_campaign=00018454&utm_content=forrester-wave (Stand

27.06.2020)

[FRIPRO] Fritzing: Homepage. Online im Internet: https://fritzing.org/home (Stand

27.06.2020)

[GiW18] Wisser K.: Gebäudeautomation in Wohngebäuden (Smart Home), Springer

Fachmedien, Wiesbaden, eBook, 2018

[HAWAS] Hoffman, Andrew. Web Application Security (Kindle Location 186). O'Reilly

Media. Kindle Edition.

108

[HEI19] Heise Medien GmbH Co. KG, Sicherheitslücke: Tausende Smart-Home-

Geräte angreifbar, Artikel, Heise Online 01/2019. Online im Internet:

https://www.heise.de/newsticker/meldung/No-Name-Hausautomation-

Luecke-erlaubt-leichten-Firmware-Upload-4284783.html (Stand

20.04.2020)

[HEI819] Heise Medien GmbH Co. KG, Sicherheitslücke: Tausende Smart-Home-

Geräte angreifbar, Artikel, Heise Online 01/2019. Online im Internet:

https://www.heise.de/newsticker/meldung/No-Name-Hausautomation-

Luecke-erlaubt-leichten-Firmware-Upload-4284783.html (Stand

20.04.2020)

[HINCCU] HomeMatic Inside: CUx-Daemon. https://www.homematic-

inside.de/software/cuxd Online im Internet: (Stand 29.06.2020)

[HMSDK] Github: HomeMatic-Open-Central-Control-Unit-SDK (HM-OCCU-SDK).

Online im Internet: https://github.com/eq-3/occu (Stand 01.07.2020)

[HMUT18] Graß, F: eQ-3 AG: Vortrag, Staffelung Sendeverhalten, HomeMatic User

Treffen, Kassel, 2018. Online im Internet:

https://www.youtube.com/watch?v=uAyzimU60jw (Stand 13.06.2020)

[HPOSA] Plötz, H.: On the Security of AES in HomeMatic, Blog. Online im Internet:

https://blog.ploetzli.ch/tag/homematic (Stand 13.06.2020)

[HTWDR] Hochschule für Technik und Wirtschaft Dresden: HomeMatic. Online im

Internet: https://www2.htw-dresden.de/~wiki_sn/index.php/HomeMatic

(Stand 27.06.2020)

[HWSDO] ELV: Bauanleitung, Homematic IP Optischer Tür-/Fensterkontakt HmIP-

SWDO. Online im Internet:

https://files2.elv.com/public/15/1532/153203/Internet/153203_bauanleitung

.pdf (Stand 29.06.2020)

[INFSEI] Infosec: Homepage, Top 10 Linux Distro for Ethical Hacking and Penetration

Testing. Online im Internet: https://resources.infosecinstitute.com/top-10-

linux-distro-ethical-hacking-penetration-testing/#gref (Stand 27.06.2020)

[JBPYC] Jet Brains: Homepage, PyCharm. Online im Internet:

https://www.jetbrains.com/de-de/pycharm (Stand 27.06.2020)

[KALIL] Kali Linux: Homepage. Online im Internet: https://www.kali.org (Stand

27.06.2020)

[KECCU3] eQ-3 AG: EG Konformitätserklärung. Online im Internet: https://www.eq-

3.de/downloads/download/homematic_ip/ce/HmIP-CCU3_CE_GE_eQ-

3_180220.pdf (Stand 28.06.2020)

109

[KeSa18] Kewei Sha, Wei Wei, Andrew T. Yang, Zhiwei Wang, Weisong Shi: On

security challenges and open issues in Internet of Things, 2018. Online im

Internet: http://iranarze.ir/wp-content/uploads/2018/03/E6066-IranArze.pdf

(Stand 21.06.2020)

[KLWPT] Najera-Gutierrez, Gilberto. Kali Linux Web Penetration Testing Cookbook:

Identify, exploit, and prevent web application vulnerabilities with Kali Linux

2018, 2nd Edition. Packt Publishing. Kindle Edition.

[LEG1] Österreich: Bundesgesetzblatt für den Bundesstaat Österreich,

Bundesgesetz über das Urheberrecht an Werken der Literatur und der Kunst

und über verwandte Schutzrechte (Urheberrechtsgesetz), BGBl. Nr.

111/1936 idF I 105/2018

[LEG2] Deutschland: Bundesgesetzblatt der Bundesrepublik Deutschland, Gesetz

über Urheberrecht und verwandte Schutzrechte (Urheberrechtsgesetz),

BGBl. I S. 1273) idF Bl. I S. 2014

[LEG3] BSI: Homepage bsi.bund.de, Leitfaden zur Entwicklung sicherer

Webanwendungen. Online im Internet:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Stu

dien/Webanwendungen/Webanw_Auftragnehmer.pdf?__blob=publicationF

ile&v=2 (Stand 25.04.2020)

[LEG4] eQ-3 Homepage, Downloads, CCU3 Firmware 3.49.17. Online im Internet:

https://www.eq-3.de/service/downloads.html?id=547 (Stand 28.06.2020).

[LEG5] fsfe Homepage, schriftliche Begründung des Urteils des Landgerichts Berlin.

Online im Internet: https://fsfe.org/activities/ftf/lg-urteil-20111118.pdf (Stand

25.04.2020)

[LEG6] GNU.de: GNU General Public License. Online im Internet:

https://www.gnu.de/documents/gpl-2.0.de.html (Stand 20.04.2020)

[LEG7] Reinhardt D., Langweg H., Witt B.C., Fischer M. et al. (Hrsg.): Sicherheit

2020, Lecture Notes in Informatics (LNI), Gesellschaft für Informatik,

Göttingen 2020. Online im Internet:

https://dl.gi.de/bitstream/handle/20.500.12116/31793/A3-1.pdf (Stand

21.04.2020)

[LHTTP] MITRE: Common Vulnerabilities and Exposures (CVE), lighttpd. Online im

Internet: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=lighttpd (Stand

03.07.2020)

[MÄB12] Märk, B.: Von der Rechenmaschine zum Personal Computer. Ein

technologiegeschichtlicher Abriss, Universität Innsbruck, 2012. Online im

Internet:

110

https://webapp.uibk.ac.at/ojs/index.php/historiascribere/article/viewFile/248

/128 (Stand: 20.04.2020)

[MEB14] Metz, B.: Was ist ein Mikrocontroller?, Technische Universität München,

2014. Online im Internet:

http://www.i6.in.tum.de/pub/Main/TeachingWs2014ProseminarMicrocontrol

lerEmbedded/Was_ist_ein_Microcontroller.pdf (Stand: 20.04.2020)

[MGDH15] Gernoth, M.: Dissecting HomeMatic AES, Blog, 2015. Online im Internet:

https://git.zerfleddert.de/hmcfgusb/AES (Stand 13.04.2020)

[MITRE] MITRE: Common Vulnerabilities and Exposures (CVE). Online im Internet:

https://cve.mitre.org (Stand 22.06.2020)

[MOBSF] Mobile Security Framework (MobSF): Github-Repository, README. Online

im Internet: https://github.com/MobSF/Mobile-Security-Framework-MobSF

(Stand 28.06.2020)

[MSTM17] Microsoft: Microsoft Threat Modeling Tool-Bedrohungen. Online im Internet:

https://docs.microsoft.com/de-de/azure/security/develop/threat-modeling-

tool-threats (Stand 22.06.2020)

[NIST] National Institute of Standards and Technology (NIST): Publications. Online

im Internet: https://www.nist.gov/publications (Stand 22.06.2020)

[ÖISHB19] Bundeskanzleramt Österreich: österreichisches

Informationssicherheitshandbuch, 2019. Online im Internet:

https://www.sicherheitshandbuch.gv.at/downloads/sicherheitshandbuch.pdf

(Stand 21.06.2020)

[ÖVSV] Österreichischer Versuchssenderverband: Amateurfunk Bandpläne für

Österreich von 50 MHz bis 3000 GHz, 2019. Online im Internet:

https://www.oevsv.at/export/shared/.content/.galleries/Downloads_Referat

e/UKW-Referat-Downloads/UKW-Bandplan.pdf (Stand 21.06.2020)

[OWASP] OWASP Foundation: The Open Web Application Security Project (OWASP).

Online im Internet: https://owasp.org (Stand 22.06.2020)

[OWAT10] OWASP Foundation: Top 10 Web Application Security Risks. Online im

Internet: https://owasp.org/www-project-top-ten (Stand 26.06.2020)

[OWAT10G] OWASP German Chapter: OWASP Top 10 -2017, Die 10 kritischsten

Sicherheitsrisiken für Webanwendungen, deutsche Version 1.0, 2017.

Online im Internet: https://wiki.owasp.org/images/9/90/OWASP_Top_10-

2017_de_V1.0.pdf (Stand 26.06.2020)

[OWZAP] OWASP Foundation: Homepage, OWASP ZAP. Online im Internet:

https://owasp.org/www-project-zap (Stand 27.06.2020)

111

[RFC3610] Internet Engineering Task Force: RFC 3610, Counter with CBC-MAC

(CCM). Online im Internet: https://tools.ietf.org/html/rfc3610 (Stand

03.07.2020)

[RMAGI] Jens Maus: Einführung Vergleich RM vs. CCU3 Entwicklungsstand

Roadmap. Online im Internet: https://homematic-

forum.de/forum/download/file.php?id=59500 (Stand 28.06.2020)

[RMATI] RaspberryMatic: Security Policy. Online im Internet:

https://raspberrymatic.de (Stand 01.07.2020)

[RMAVU] RaspberryMatic: Security Policy. Online im Internet: https://github.com/jens-

maus/RaspberryMatic/blob/master/SECURITY.md (Stand 28.06.2020)

[SaMa13] Laufer, S., Malla, C.: Attacking HomeMatic, 30th Chaos Communication

Congress, Computer Club, Hamburg, 2013. Online im Internet:

https://media.ccc.de/v/30C3_-_5444_-_en_-_saal_g_-_201312301600_-

_attacking_homematic_-_sathya_-_malli#download (Stand 13.06.2020)

[SH2M16] Bundesministerium für Wirtschaft und Energie:SmartHome2Market,

Marktperspektiven für die intelligente Heimvernetzung, 2016. Online im

Internet: https://www.digitale-

technologien.de/DT/Redaktion/DE/Downloads/Publikation/smarthome-

broschuere.pdf?__blob=publicationFile&v=9 (Stand 13.06.2020)

[SHODAN] Shodan: Suchabfrage „Homematic“. Online im Internet:

https://www.shodan.io/search?query=Homematic (Stand 04.07.2020)

[SIHNW] Gundall, M.: Projekt „Silver Tipps – sicher online!“, Ein sicheres

Heimnetzwerk in 5 Schritten. Online im Internet: https://www.silver-

tipps.de/ein-sicheres-heimnetzwerk (Stand 02.07.2020)

[SPLUNK] Splunk: Homepage. Online im Internet: https://www.splunk.com (Stand

27.06.2020)

[STAA20] Statista: Smarthome-Umsätze Österreich, 2020. Online im Internet:

https://de.statista.com/outlook/283/128/smart-home/oesterreich (Stand

13.06.2020)

[TENESS] Tenable: Homepage, The Nessus family. Online im Internet:

https://www.tenable.com/products/nessus (Stand 27.06.2020)

112

Abbildungsverzeichnis

Abb. 1: Ebenen der Gebäude-/Hausautomatisierung (vgl. [GiW18, Kap. 2.1]) .................. 6

Abb. 2: Architektur „Internet der Dinge“ nach [KeSa18, S. 6] .......................................... 14

Abb. 3: AES schematischer Verschlüsselungsablauf (vgl. [FIAES]) ................................ 28

Abb. 4: Electronic Code Book (vgl. [FIAES]) ................................................................... 29

Abb. 5: Cipher Block Chaining (vgl. [FIAES]) .................................................................. 29

Abb. 6: Funktionsschema AES-CCM (vgl. [RFC3610]) ................................................... 30

Abb. 7: Vorhandene Infrastruktur für die Sicherheitsanalyse ........................................... 36

Abb. 8: CC1101-USB-Lite 868MHz (CUL) von Busware ................................................. 37

Abb. 9: Nano-CUL-Stick CC1101-USB-Lite 868MHz (Eigenbau) .................................... 38

Abb. 10: Nano-CUL-Stick Verdrahtungsplan ................................................................... 38

Abb. 11: Exemplarische Ausgabe des BidCos-Sniffers ................................................... 41

Abb. 12: Beispiel-Datensatz des im Splunk-System gespeicherten Telegramms ............ 41

Abb. 13: HomeMatic Webinterface - Leerkonfiguration ................................................... 44

Abb. 14: HomeMatic Webinterface – Geräte anlernen .................................................... 45

Abb. 15: HomeMatic Webinterface – Geräteliste ............................................................. 45

Abb. 16: HomeMatic Webinterface – Systemvariablen .................................................... 46

Abb. 17: HomeMatic Webinterface – Programme für Schutzzustände ............................ 46

Abb. 18: HomeMatic Webinterface – Programmlogik „Vollschutz aktivieren“ .................. 47

Abb. 19: HomeMatic Webinterface – Favorit Alarmanlage .............................................. 47

Abb. 20: HomeMatic Webinterface – Programm Alarm “Vollschutz“ ................................ 48

Abb. 21: HomeMatic Geräteliste mit Firmware-Übersicht ................................................ 49

Abb. 22: HomeMatic CCU3 in geöffnetem Zustand ......................................................... 49

Abb. 23: HomeMatic CCU3 – Konfiguration der Firewall ................................................. 50

Abb. 24: HomeMatic CCU3 – Systemaufbau .................................................................. 51

Abb. 25: HomeMatic CCU3 – Prozesse .......................................................................... 52

Abb. 26: HomeMatic CCU3 – Webinterface “Test script” ................................................ 52

Abb. 27: HomeMatic CCU3 – Systemprotokoll ................................................................ 53

Abb. 28: HomeMatic CCU3 – Update Bestätigungsdialog ............................................... 54

Abb. 29: HomeMatic CCU3 – Webinterface nmap-Scan Transport Layer Security (TLS) 54

Abb. 30: HomeMatic CCU3 – ZAP Standard-Scan ......................................................... 56

Abb. 31: HomeMatic CCU3 – Bekannte Schwachstellen ................................................ 57

Abb. 32: Raspberry Pi 3 Model B mit Funkmodul ............................................................ 61

Abb. 33: RaspberryMatic - Geräteliste ............................................................................ 62

Abb. 34: RaspberryMatic Webinterface - Programmlogik Programm Alarm “Vollschutz“ . 63

Abb. 35: RaspberryMatic – Webinterface nmap-Scan Transport Layer Security (TLS) ... 64

Abb. 36: RaspberryMatic – ZAP Standard-Scan ............................................................. 65

113

Abb. 37: HomeMatic IP – Access Point (Vorder- und Unterseite) .................................... 69

Abb. 38: HomeMatic IP – App Einrichtung Access Point 1-3 ........................................... 69

Abb. 39: HomeMatic IP – App Einrichtung Access Point 2-6 ........................................... 70

Abb. 40: HomeMatic IP – App Einrichtung Anlernen von Geräten 1-4 ............................. 70

Abb. 41: HomeMatic IP – App Funktionalitätsbeispiele ................................................... 71

Abb. 42: HomeMatic IP – Access Point geöffnet ............................................................. 72

Abb. 43: HomeMatic IP – Wireshark HTTP-Analyse ....................................................... 72

Abb. 44: HomeMatic IP – Wireshark Kommunikation Access Point ................................. 73

Abb. 45: HomeMatic IP App – MobSF ASLR-Schwachstelle ........................................... 74

Abb. 46: BidCoS grundlegender Telegrammaufbau ........................................................ 76

Abb. 47: BidCoS Beispiel Telegramm ohne gesicherter Verbindung – generisch ............ 77

Abb. 48: BidCoS Beispiel Telegramme mit gesicherter Verbindung ................................ 79

Abb. 49: BidCoS Beispiel Telegramme mit ungesicherter Verbindung - Befehlscounter . 80

Abb. 50: BidCoS Beispiel Telegramm gesicherte Verbidnung, Challenge-Resonse ........ 81

Abb. 51: BidCoS Telegramm zur Nachberechnung (vgl. [MGDH15]) .............................. 82

Abb. 52: BidCoS Zeitdiagramm – gesicherte und ungesicherte Verbindung im Vergleich

................................................................................................................................ 84

Abb. 53: BidCoS Telegramm – Änderung des Sicherheitsschlüssels .............................. 85

Abb. 54: Splunk – Telegramm-Summenstatistik über mehrere Tage pro Tag ................. 86

Abb. 55: Splunk – Telegramme mit Spannungswert ....................................................... 87

Abb. 56: Splunk – Telegramm-Statistik pro HomeMatic IP Komponente ......................... 88

Abb. 57: Splunk – Telegramm-Statistik HomeMatic IP nur Bewegungsmelder ................ 88

114

Tabellenverzeichnis

Tab. 1: Frequenznutzungsparameter [BNA14] ................................................................ 12

Tab. 2: Vorgehensmodell für die Sicherheitsanalysen (vgl. [BSISEC, S. 23]). ................. 33

Tab. 3: Die 10 kritischsten Sicherheitsrisiken für Webanwendungen [OWAT10G] .......... 36

Tab. 4: Komponentenliste HomeMatic ............................................................................ 43

Tab. 5: HomeMatic CCU3 Software-Versionen ............................................................... 53

Tab. 6: Komponentenliste RaspberryMatic ..................................................................... 59

Tab. 7: RaspberryMatic Software-Versionen ................................................................... 64

Tab. 8: Komponentenliste HomeMatic IP ........................................................................ 68

Tab. 9: Informationsquellen zu BidCoS ........................................................................... 76

Tab. 10: Vergleich der drei Lösungen ............................................................................. 90

Tab. 11: Bedrohungsanalyse nach dem STRIDE-Modell ................................................ 93

Tab. 12: Risikomatrix ...................................................................................................... 93

Tab. 13: Risikobewertung – HomeMatic und RaspberryMatic ......................................... 95

Tab. 14: Risikobewertung – HomeMatic IP ..................................................................... 96

Tab. 15: Risikobewertung – HomeMatic und RaspberryMatic nach Mitigation ................ 99

Tab. 16: Risikobewertung – HomeMatic IP nach Mitigation........................................... 100

115

Anhang A – Quellcode BidCoS-Sniffer

####################################################################

# BidCoS-Sniffer with CUL device - FH 2020

# sniffer.py Version 2.3

# used with

# CC1101-USB-Lite 868MHz (CUL)

# http://shop.busware.de/product_info.php/cPath/1/products_id/29

# on Pi4 Raspbian GNU/Linux 10 (buster) and Python 3.7.3

# pip3 install pyserial

####################################################################

# Imports

import socket

import sys

from datetime import datetime

import serial

import serial.tools.list_ports as port_list

import time

# Variables

# Feature settings

sniffer_name = 'cul-stick'

list_serial_ports = False

show_raw_data = True

show_device_names = False

filter_devices = False

valid_devices = ['68B32B', '5B2F2F', 'B2318C']

send_to_syslog = False

# Serial port setting

serial_port = 'COM3'

serial_speed = 38400

# Syslog (UDP)

syslog_host = 'localhost'

syslog_port = 514

# BidCos ID/Device dictionary/Example

hm_dict = {

# "BidCos ID": "Device name"

"B2318C": "HomeMatic CCU3",

"B36B82": "HomeMatic CCU3 (IP)",

"5B2F2F": "Fernbedienung",

116

"502F65": "Sirene (IP)",

"6517D8": "TF-Kontakt WW (IP)",

"66306A": "TF-Kontakt WV (IP)",

"68B32B": "Schaltsteckdose",

"000000": "Broadcast",

}

# Sub

# Send to syslog sink

def syslog(message, host='localhost', port=514):

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

sock.connect((host, port))

sock.sendall(bytes(message, 'utf-8'))

sock.close()

def show_data(line, syslog_host, syslog_port, show_device_names):

# Split message

mlen = line[1:3]

mcnt = line[3:5]

flag = line[5:7]

mtyp = line[7:9]

msrc = line[9:15]

mdst = line[15:21]

data = line[21:len(line)]

# Generate timestamp

now = datetime.now()

tstamp = datetime.timestamp(now)

tstamp = now.strftime('%d-%m-%Y %H:%M:%S.%f')

# Show device names

if show_device_names:

# Deal with empty broadcasts

if mdst == "":

mdst = "empty"

# Show who is talking to whom

try:

src_device_name = hm_dict[msrc]

except KeyError:

pass

else:

try:

dst_device_name = hm_dict[mdst]

print(src_device_name + " --> " + dst_device_name)

except KeyError:

print(src_device_name + " --> " + mdst)

117

pass

finally:

pass

finally:

pass

# Show raw data

if show_raw_data:

print(line)

# Show separated data

print('Time L C FG TP SENDER RECVR DATA')

print(tstamp + ' ' + mlen + ' ' + mcnt + ' ' + flag + ' ' + mtyp + '

' + msrc + ' ' + mdst + ' ' + data + '\n')

# Syslog

if send_to_syslog:

# Construct syslog message

syslog_msg = 'sniffer=' + sniffer_name + ', stimestamp=' + tstamp

+ ', Length=' + mlen + ', Counter=' + \

mcnt + ', Flag=' + flag + ', Type=' + ', Src=' + msr

c + ', Dst=' + mdst + ', Data=' + data + \

', RAW=' + line

# Send syslog message

try:

syslog(syslog_msg, syslog_host, syslog_port)

except:

e = sys.exc_info()[0]

print('Cannot send message to ' + syslog_host + ' [' + str(e)

+ ']')

exit()

# Main

# list serial ports

if list_serial_ports:

ports = list(port_list.comports())

for p in ports:

print(p)

# Connect to serial port

try:

myPySerial = serial.Serial(serial_port, serial_speed)

except:

e = sys.exc_info()[0]

print('Failed to connect to ' + serial_port + ' [' + str(e) + ']')

exit()

118

# Initialize CUL device

time.sleep(0.5)

myPySerial.write('X00\n'.encode())

time.sleep(0.5)

myPySerial.write('Ar\n'.encode())

# Read data from serial port

while True:

# Read line

line = myPySerial.readline().decode().strip()

msrc = line[9:15]

mdst = line[15:21]

# Check if filtered

if msrc in valid_devices or mdst in valid_devices and not filter_devi

ces:

show_data(line, syslog_host, syslog_port, show_device_names)

else:

show_data(line, syslog_host, syslog_port, show_device_names)

119

Anhang B – HomeMatic CCU3 Prüfung mit ssh-audit

kali@kali:~$ ssh-audit hm-ccu3

# general

(gen) banner: SSH-2.0-OpenSSH_7.8

(gen) software: OpenSSH 7.8

(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+

(gen) compression: enabled ([email protected])

# key exchange algorithms

(kex) curve25519-sha256 -- [info] available since

OpenSSH 7.4, Dropbear SSH 2018.76

(kex) [email protected] -- [info] available since


(kex) ecdh-sha2-nistp256 -- [fail] using weak

elliptic curves

`- [info] available since



elliptic curves




elliptic curves



(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info]

available since OpenSSH 4.4

(kex) diffie-hellman-group16-sha512 -- [info] available since



OpenSSH 7.3



(kex) diffie-hellman-group14-sha1 -- [warn] using weak hashing

algorithm



# host-key algorithms

(key) rsa-sha2-512 (2048-bit) -- [info] available since

OpenSSH 7.2

(key) rsa-sha2-256 (2048-bit) -- [info] available since

OpenSSH 7.2

120

(key) ssh-rsa (2048-bit) -- [fail] using weak hashing

algorithm


OpenSSH 2.5.0, Dropbear SSH 0.28

(key) ecdsa-sha2-nistp256 -- [fail] using weak

elliptic curves

`- [warn] using weak random

number generator could reveal the key



(key) ssh-ed25519 -- [info] available since

OpenSSH 6.5

# encryption algorithms (ciphers)

(enc) aes256-ctr -- [info] available since



OpenSSH 3.7



# message authentication code algorithms

(mac) hmac-sha2-256 -- [warn] using encrypt-and-

MAC mode



(mac) hmac-sha2-512 -- [warn] using encrypt-and-

MAC mode



# fingerprints

(fin) ssh-ed25519: SHA256:O8w/lO7nOKeGOMnUv6/M3hxMYnRG+yLOvwMU1QUXmY4

(fin) ssh-rsa: SHA256:U1GSUu5eek5blJD6H2Qpz5o+LPo9v5OranFtf82pyTA

# algorithm recommendations (for OpenSSH 7.8)

(rec) -ecdh-sha2-nistp256 -- kex algorithm to remove



(rec) -ecdsa-sha2-nistp256 -- key algorithm to remove

(rec) -ssh-rsa -- key algorithm to remove

(rec) [email protected] -- enc algorithm to append



(rec) [email protected] -- mac algorithm to append

121



(rec) -diffie-hellman-group14-sha1 -- kex algorithm to remove

(rec) -hmac-sha2-256 -- mac algorithm to remove

(rec) -hmac-sha2-512 -- mac algorithm to remove

# additional info

(nfo) For hardening guides on common OSes, please see: <https://www.ssh-

audit.com/hardening_guides.html>

122

Anhang C – HomeMatic Nessus Scan-Ergebnis

Tenable Nessus Essentials 8.10.1 – Network Scan

123

Tenable Nessus Essentials 8.10.1 – Web Scan

124

Anhang D – Proof of Concept CVE-2019-9727

kali@kali:~$ curl -X POST -k -i 'https://hm-ccu3/api/homematic.cgi' --

data '{

> "version": "1.1",

> "method": "User.getUserPWD",

> "params": {

> "_session_id_": "@MagZdAHu8d@",

> "userID": "Admin"

> }

> }'

HTTP/1.1 200 OK

CONTENT-TYPE: application/json; charset=utf-8

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

X-Robots-Tag: none

X-Download-Options: noopen

X-Permitted-Cross-Domain-Policies: none

Referrer-Policy: no-referrer

Content-Length: 156

Date: Tue, 30 Jun 2020 19:43:34 GMT

{

"version": "1.1",

"result": null,

"error": {

"name": "JSONRPCError",

"code": 401,

"message": "method not found (User.getUserPWD)"

}

}

125

Anhang E – RasperryMatic Nessus Scan-Ergebnis

Tenable Nessus Essentials 8.10.1 – Network Scan

Tenable Nessus Essentials 8.10.1 – Web Scan

126

Anhang F – HomeMatic IP Mobile App - MobSF Analyse

Mobile Security Framework v3.0.4 Beta

127

Anhang G – BidCoS Telegramm Authentifizierung

####################################################################

# BidCos AES-CCM calculation - FH 2020

# bidcos_aes.py Version 1.2

# Used with pyhton 3.7

# pip3 install pycryptodome

# Thanks to https://git.zerfleddert.de/hmcfgusb/AES/

####################################################################

# Imports

from Crypto.Cipher import AES

# Variables

# HomeMatic AES-CCM Challenge-Response Telegrams

mframe= '0E03A01168EA141ED0170201C80000'

cframe= '1103A0021ED01768EA1404D962D9FB2B0300'

rframe= '1903A00368EA141ED017344305154D33A8766DBAE938311FA514'

aframe= '120380021ED01768EA140101C800168B0C277F'

# HomeMatic Key 16 bytes

key = b''

# Extract needed fields

params = mframe[22:]

challenge = cframe[22:-2]

payload = rframe[20:]

auth_data = aframe[-8:]

ack_data = aframe[20:30]

# Show extraction

print('Extracting data from telegrams (all values are hex) ...')

print('==========================================================')

print('Parameters from m-frame: ' + params)

print('Challenge from c-frame: ' + challenge)

print('Payload from r-frame: ' + payload)

print('Auth data from a-frame: ' + auth_data)

print('Ack-Data from a-frame: ' + ack_data)

print('==========================================================')

print('Recalculating values ...')

# Save the original payload for later comparisn

opl = payload

128

# Padding

pchalle = challenge.ljust(32, '0')

k_hex = hex(int(key, 16))

p_hex = hex(int(payload, 16))

# XOR key and padded challenge to generate temp key

t_key = hex(int(pchalle, 16) ^ int(k_hex, 16))

iv = params.ljust(32, '0')

b_tkey = t_key[2:].upper().encode()

# Decrypt payload with temp key

plain = AES.new(bytes.fromhex(t_key[2:]), AES.MODE_ECB)

bt2 = plain.decrypt(bytes.fromhex(payload)).hex()

# XOR iv with encrypted payload to get auth data

plo = hex(int(iv, 16) ^ int(bt2, 16))

authc = plo[2:10]

print('Calculated auth data: ' + authc.upper())

# Decrypt again

plain = AES.new(bytes.fromhex(t_key[2:]), AES.MODE_ECB)

bt = plain.decrypt(bytes.fromhex(plo[2:])).hex()

print('Encrypted payload: ' + bt.upper())

# Extract the timestamp (random value of the sender)

t = bt[:10]

print('Timestamp was: ' + t.upper())

# Recreate the payload as the sender has calculated it to respond to the

challenge

payload = t + mframe[0:22] + params[0:4]

plh = hex(int(payload, 16))

# Prepare for encryption using AES-CBC

iv = '00000000000000000000000000000000'

# Encrypt payload data

ncipher = AES.new(bytes.fromhex(t_key[2:]), AES.MODE_CBC, bytes.fromhex(

iv))

ct = ncipher.encrypt(bytes.fromhex(plh[2:].ljust(64, '0')))

cts = ct.hex()

print('First decrypted block is: ' + cts[:32].upper())

print('Decrypted auth data is: ' + cts[:8].upper())

print('Encrypted payload is: ' + cts[32:].upper())

print('==========================================================')

FHCW ITS20 Masterarbeit Friedrich Haidn

Documents

Transcript of FHCW ITS20 Masterarbeit Friedrich Haidn