FHCW ITS20 Masterarbeit Friedrich Haidn
Transcript of 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.3.1. Anforderungen und Lösungszuordnung ................................................... 58
3.3.2. Garantien des Herstellers ........................................................................ 60
3.3.3. Implementierung und Funktion................................................................. 60
3.3.4. Sicherheitsanalyse ................................................................................... 63
3.3.5. Kurzzusammenfassung der Ergebnisse ................................................... 66
3.4. HomeMatic IP .................................................................................. 66
3.4.1. Anforderungen und Lösungszuordnung ................................................... 66
3.4.2. Garantien des Herstellers ........................................................................ 68
3.4.3. Implementierung und Funktion................................................................. 68
3.4.4. Sicherheitsanalyse ................................................................................... 72
3.4.5. Kurzzusammenfassung der Ergebnisse ................................................... 75
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
Risikobereich Beschreibung
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
Risikobereich Beschreibung
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
Anzahl Bezeichnung Gesamtpreis
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
Das folgende Kapitel beschreibt von den Anforderungen über die Implementierung bis zur
Sicherheitsanalyse die Auseinandersetzung mit der RaspberryMatic Lösung als Zentrale
und Sensor-/Aktor-Komponenten der eQ3-AG.
3.3.1. Anforderungen und Lösungszuordnung
Funktionale und nichtfunktionale Anforderungen
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.
Komponentenaufstellung
Anzahl Bezeichnung Gesamtpreis
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
3.3.2. Garantien des Herstellers
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.
3.3.3. Implementierung und Funktion
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.
3.3.4. Sicherheitsanalyse
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.
Automatisierte Analyse
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.
Recherche bekannter Schwachstellen
In einer Recherche zu bekannten Schwachstellen konnten keine Spezifischen für die
RaspberryMatic identifiziert werden.
Sonstige Wahrnehmungen
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.
3.3.5. Kurzzusammenfassung der Ergebnisse
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
Das folgende Kapitel beschreibt von den Anforderungen über die Implementierung bis zur
Sicherheitsanalyse die Auseinandersetzung mit der Cloud-basierten HomeMatic IP Lösung
der eQ3-AG.
3.4.1. Anforderungen und Lösungszuordnung
Funktionale und nichtfunktionale Anforderungen
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.
Komponentenaufstellung
Anzahl Bezeichnung Gesamtpreis
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
Anzahl Bezeichnung Gesamtpreis
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.
3.4.2. Garantien des Herstellers
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.
3.4.3. Implementierung und Funktion
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
3.4.4. Sicherheitsanalyse
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]).
Automatisierte Analyse
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.
Recherche bekannter Schwachstellen
Außer den von AV-Test dargestellten Schwachstellen konnten keine weiteren recherchiert
werden (vgl. [AVIOTB]).
Sonstige Wahrnehmungen
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.
3.4.5. Kurzzusammenfassung der Ergebnisse
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
Lösung Annahme Bedrohungsbereich und
-beschreibung
HomeMatic/RaspberryMatic Das Webinterface
ist über Port-
Forwarding im
Internet
bereitgestellt, die
automatische
Anmeldefunktion
ist nicht aktiv.
Spoofing: Ein Vollzugriff
kann erreicht 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.
HomeMatic/RaspberryMatic/HomeMatic
IP
Keine Spoofing: Es werden
unautorisierte Aktionen
durch Senden von
Funktelegrammen
ausgelöst.
Tampering: Das
Alarmsystem wird
deaktiviert.
Information Disclosure:
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
Tampering: Unautorisierte
Veränderungen können
durchgeführt werden.
93
Lösung Annahme Bedrohungsbereich und
-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
keine mittel mittel mittel
Tab. 13: Risikobewertung – HomeMatic und RaspberryMatic
Tabelle 13 zeigt das potenzielle Risiko (Risikostufe) durch die Bedrohungen ohne Mitigationsmaßnahmen.
96
HomeMatic IP
Bedrohung existierende Mitigationsmaßnahmen Eintrittswahr-
scheinlichkeit Schadenshöhe Risikostufe
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
gering gering gering
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
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
Bedrohung existierende Mitigationsmaßnahmen Eintrittswahr-
scheinlichkeit Schadenshöhe Risikostufe
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
Der Zugriff ist nur über eine sichere VPN-
Verbindung möglich. Die Infrastruktur ist
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
Der Zugriff ist nur über eine sichere VPN-
Verbindung möglich. Die Infrastruktur ist
basisgeschützt.
gering
(vorher: hoch) mittel
gering
(vorher: hoch)
Störung des Funkverkehrs bei einem
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
gering gering gering
Versagen der Alarmierungsfunktion durch
fehlerhafte Konfiguration
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
Bedrohung existierende Mitigationsmaßnahmen Eintrittswahr-
scheinlichkeit Schadenshöhe Risikostufe
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
gering gering gering
Störung des Funkverkehrs bei einem
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
gering gering gering
Versagen der Alarmierungsfunktion durch
fehlerhafte Konfiguration
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
OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256 -- [fail] using weak
elliptic curves
`- [info] available since
OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using weak
elliptic curves
`- [info] available since
OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using weak
elliptic curves
`- [info] available since
OpenSSH 5.7, Dropbear SSH 2013.62
(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, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since
OpenSSH 7.3
(kex) diffie-hellman-group14-sha256 -- [info] available since
OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group14-sha1 -- [warn] using weak hashing
algorithm
`- [info] available since
OpenSSH 3.9, Dropbear SSH 0.53
# 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
`- [info] available since
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
`- [info] available since
OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since
OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) aes256-ctr -- [info] available since
OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since
OpenSSH 3.7
(enc) aes128-ctr -- [info] available since
OpenSSH 3.7, Dropbear SSH 0.52
# message authentication code algorithms
(mac) hmac-sha2-256 -- [warn] using encrypt-and-
MAC mode
`- [info] available since
OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512 -- [warn] using encrypt-and-
MAC mode
`- [info] available since
OpenSSH 5.9, Dropbear SSH 2013.56
# 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) -ecdh-sha2-nistp384 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521 -- 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] -- enc algorithm to append
(rec) [email protected] -- enc algorithm to append
(rec) [email protected] -- mac algorithm to append
121
(rec) [email protected] -- mac algorithm to append
(rec) [email protected] -- mac algorithm to append
(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>
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
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('==========================================================')