info

rmat

ikJo

urna

l201

7/18

informatikJournal2017/18

Aktuelle Berichte aus Forschung und Lehre der Fakultät Informatik

Ausgabe 7, Dezember 2017

Fakultät InformatikHochschule FurtwangenRobert-Gerwig-Platz 1D-78120 Furtwangen

info

rmat

ikJo

urna

l201

7/18

informatikJournal2017/18

Aktuelle Berichte aus Forschung und Lehre der Fakultät Informatik

Ausgabe 7, Dezember 2017

Fakultät InformatikHochschule FurtwangenRobert-Gerwig-Platz 1D-78120 Furtwangen

informatikJournal 2017/18

Aktuelle Berichte aus Forschung und Lehre der Fakultät Informatik

Herausgeber

Fakultät Informatik Hochschule Furtwangen Robert-Gerwig-Platz 1 D-78120 Furtwangen

http://www.hs-furtwangen.de/studierende/fakultaeten/informatik.html

Redaktion

Prof. Dr. Lothar Piepmeyer

© 2017 Fakultät Informatik, Hochschule Furtwangen Alle Rechte vorbehalten

Printed in Germany

Inhaltsverzeichnis

Vorwort v

Softwaretechnik 1

Nachhaltige Verbesserung der Softwarequalität durch Überwachung der Architekturentwicklung im Entwicklungsprozess mit Structure101 Stefan Wywior und Marius Bacher

3

Technologien und Muster zur Entwicklung von Nanoservice-Architekturen Timo Bayer und Philipp Ruf

11

Transaktionen in Microservices Timo Hauser und Enrico Schro dter

25

Big Data 35

It does not always have to be Map Reduce or Spark Petra Borowski und Timo Nürnberg

37

Datenanalyse mit Apache Solr Cedric Schweizer, Peter Wursthorn

45

Die Zeitreihen-Challenge Lothar Piepmeyer

53

Apache Cassandra Jennifer Jurreit, Merlin Gernsheimer und Peter Wursthorn

55

Cloudera Impala Timo Hauser, Enrico Schro dter und Andreas Dorn

59

Timestamp based range queries with Redis Petra Borowski, Timo Nürnberg und David Rohatschek

63

Komplexe Datenanalyse mittels MongoDB Simon Hübner und Cedric Schweizer

67

Anwendungsspezifische Performancesteigerung von Abfragen in HBase Systemen durch konzeptionelle Aggregationen Philipp Ruf, Timo Bayer und Burak Karakilinc

71

iii

Software Engineering mobiler Systeme 75

Analyse von Sicherheitsanforderungen an Entertainment- und Steuerungskomponenten im Automobil Ricou Jaschke und Eduard Wolf

77

Analyse und Optimierung der Privatsphäre und des Datenschutzes bei Telematik-Systemen Marc Merzinger und Johann Ulbrich

83

Analyse aktueller Sicherheitskonzepte im Smart-Home-Bereich Katharina Mollus und Christian Häusler

93

Analyse gängiger Smart Home-Übertragungstechnologien bezüglich Datenschutz und Sicherheit Johannes Wieland und Johannes M. Hunn

101

Internet of Things 109

"Can I offer you some water?" – Developing Behaviors for the Pepper Humanoid Robot in an Ambient Assisted Living Environment1 Judith Jakob und Elmar Cochlovius

111

ScnSim - A Scenario Simulator for IoT Environments Tobias Holstein, Christoph Reich und Matthias Ulrich

117

Security 125

Analysis of security vulnerabilities in Microsoft Office 365 in regard to SAML Jennifer Jurreit, Patrik Fehrenbach und Friedbert Kaspar

127

Sandbox-Detection-Angriffe gegen den Android Emulator Hermann Weisenmu ller, Fabian Berner und Friedbert Kaspar

135

1 Dieser Beitrag wurde im Rahmen eines Peer-Review-Verfahrens begutachtet.

iv

Vorwort

Liebe Leserinnen und Leser,

herzlich willkommen zu dieser Ausgabe des informatikJournal, der Fachpublikation der Fakultät Informatik. In dieser Ausgabe haben wir wieder ausgewählte Arbeiten aus den vielfältigen Forschungsaktivitäten und Seminaren unserer Fakultät zusammengestellt.

Die Beiträge der vorliegenden Edition 2017/18 beschäftigen sich mit aktuellen Themengebieten der Informatik wie etwa mobile Systeme oder Big Data, die einen hohen Stellenwert für die Ausbildung von Informatikerinnen und Informatikern. So sind die Arbeiten aus dem erstgenannten Gebiet überwiegend Ergebnisse aus Lehrveranstaltungen unseres neuen Masterstudienganges Mobile Systeme.

Wir danken unseren Doktoranden, Masterstudenten und Absolventen für das Engagement und die zahlreichen Beiträge in dieser Ausgabe. Ferner danken wir allen beteiligten Kolleginnen und Kollegen für die freundliche Unterstützung und kompetente Betreuung der Arbeiten. Ganz besonders danken wir den Gutachtern für Ihre aktive Teilnahme am Peer-Review-Prozess. Wir wünschen Ihnen eine interessante Lektüre und freuen uns über Ihre Rückmeldung.

Furtwangen im November 2017

Prof. Dr. Mohsen Rezagholi Prof. Dr. Lothar Piepmeyer (Dekan) (Redaktion)

v

Softwaretechnik

Lothar Piepmeyer und Mohsen Rezagholi

1

Nachhaltige Verbesserung der Softwarequalitatdurch Uberwachung der Architekturentwicklung im

Entwicklungsprozess mit Structure101Stefan Wywior

Fakultat InformatikHochschule FurtwangenFurtwangen, Germany

s.wywior@hs-furtwangen.de

Marius BacherFakultat Informatik

Hochschule FurtwangenFurtwangen, Germany

marius.bacher@hs-furtwangen.de

Abstract—Die Softwarearchitekturanalyse ist ein wichtigesMittel, um die Architektur eines Systems besser verstehen zukonnen und zu untersuchen, ob die definierten Qualitatskriterienerfullt werden. In dieser Arbeit wird vor allem die werkzeug-gestutzte Analyse von Softwarearchitekturen betrachtet. Dazuwerden Grundlagen und Voraussetzungen fur die erfolgreicheDurchfuhrung definiert. Mit Hilfe des Werkzeugs Structure101wird die Architektur eines Open Source Projektes untersucht,bei dem bereits eine Architekturdokumentation vorhanden ist.Auf Grund dieser Erkenntnisse werden Verbesserungsvorschlagebetrachtet und untersucht, wie eine Degeneration der Architek-tur im Entwicklungsprozess proaktiv vermieden werden kann.Ziel ist es zu zeigen, wie die Qualitatssicherung im Bezugauf Softwarearchitekturen weitgehend vereinfacht werden kann,um die Qualitat des Endproduktes mit geringem Mehraufwandmaßgeblich zu erhohen.

Stichworter—Architekturrestrukturierung, Softwarearchi-tekturanalyse, Softwarearchitekturmetriken, Softwarequalitat,Structure101

I. EINLEITUNG

Die Große und Komplexitat eines Softwaresystems steigt imLaufe eines Projektes stetig an. Dadurch entsteht das BedurfnisZusammenhange in einem System besser nachvollziehen zukonnen. Ab einer gewissen Große konnen Entwickler das Sys-tem nicht mehr ohne weiteres auf Quelltextebene uberblicken.Die meisten Systeme konnen jedoch in Module unterteiltwerden und deren Zusammenhange konnen, ubersichtlich dar-gestellt, dem Entwickler ein gutes Gesamtbild vermitteln.

Die Unterteilung und die Darstellung der Zusammenhangeeines Systems kann von Entwicklern mit entsprechendemDomanenwissen durch Review des Quelltextes manuell durch-gefuhrt und dokumentiert werden. Bei entsprechender Großeeines Projekts ist dieser Vorgang jedoch nicht mehr sinnvollvon einem einzelnen Entwickler oder in vertretbarer Zeitzu erledigen. Aus diesem Grund mochten wir uns in dieserArbeit mit Methoden und Werkzeugen auseinandersetzen, diediesen Prozess optimieren und den Entwickler mit geeignetenVisualisierungen so unterstutzen, dass das zu entwickelndeSoftwaresystem besser verstanden werden kann.

Weiterhin lassen sich durch die statische Quelltextanalyse,die auch bei den in den folgenden Abschnitten beschriebenen

Methoden zur Softwarearchitekturanalyse zum Einsatz kommt,Softwaredefekte fruhzeitig erkennen und beheben [1]. Wirversuchen geeignete Qualitatskriterien einer Softwarearchitek-tur zu finden, die sich quantifizieren lassen. So konnen wirdurch die Quantifizierung dieser Kriterien werkzeuggestutztdie Qualitat der Architektur bewerten. Neben der Analyse ei-nes bestehenden Softwaresystems mochten wir auch Vorgangebetrachten, die das gesamte Projektteam im Entwicklungs-prozess unterstutzen. Dazu werden wir uns mit Methodenbeschaftigen, die uns helfen, die Evolution einer Architekturzu kontrollieren und die Degeneration zu vermeiden.

Da die Analyse einer Softwarearchitektur, wie bereitserlautert, sehr aufwandig sein kann, wird dieser Vorgang imProjektverlauf oftmals vernachlassigt. Ziel dieser Arbeit istes, diese zeitintensiven Vorgange zu automatisieren und dabeieine hohere Qualitat des Endproduktes sicherzustellen. ZurUnterstutzung dieses Vorhabens werden wir das WerkzeugStructure101 Studio evaluieren.

II. SOFTWAREARCHITEKTURANALYSE

Das Ziel der Architekturanalyse ist die Uberprufung derArchitektur anhand festgelegter Kriterien [2]. Der Fokus dieserArbeit soll dabei vor allem Qualitatskriterien berucksichtigen,die mit Hilfe von Werkzeugen analysiert werden konnen. Wirmochten uns dabei weniger auf Methoden konzentrieren, diedabei helfen die Architekturdefinition ansich zu uberprufen,wie zum Beispiel die Architecture tradeoff analysis me-thod (ATAM) [3] oder Software architecture analysis method(SAAM) [4]. Vielmehr gehen wir davon aus, dass die definierteSoftwarearchitektur bereits von Experten sorgfaltig evaluiertwurde. Im Folgenden mochten wir also Techniken vorstellen,mit denen die Ist-Architektur einer Software, anhand des vor-handenen Quellltextes, werkzeugunterstutzt analysiert werdenkann.

Eine Softwarearchitektur hat direkten Einfluss auf nichtfunktionale Anforderungen und die Qualitat der daraus ent-stehenden Software. Eine gute Architektur muss deshalb vonBeginn an wohldefiniert und auf die Anforderungen der jewei-ligen Domane zugeschnitten sein. Weiterhin wird eine gute

3

Softwarearchitektur maßgeblich uber die Erfullung der defi-nierten Qualitatskriterien definiert. Qualitatskritierien lassensich aus dem Quelltext einer Software aber nicht ohne weiteresableiten. Es gibt jedoch ein Kriterium, welches sich besondersgut quantifizieren lasst und automatisch aus dem Quelltexteiner Software bestimmt werden kann, die Komplexitat.

Die meisten Werkzeuge, die Ist-Architekturen analysieren,beschranken sich also auf die Analyse der Komplexitat einerArchitektur. Von der Komplexitat hangen indirekt, zumindestteilweise, alle Qualitatskriterien einer Softwarearchitektur ab.Beispielsweise verringert sich die Wartbarkeit einer Appli-kation mit steigender Komplexitat, da Fehlerbehebungen un-gewollte Seiteneffekte auslosen konnen. Ahnliche Beispielelassen sich zu Sicherheit, Laufzeit, Skalierbarkeit und weiterenAttributen finden. Umgekehrt kann jedoch nicht behauptetwerden, dass eine nicht komplexe Applikation automatischgut wartbar ist. Eine Senkung der Komplexitat hilft jedochzumindest die Wartbarkeit zu erhohen.

Auch wenn sich die Komplexitat einer Anwendung gutquantifizieren lasst, so gibt es keinen absoluten Messwertdafur. Vergleicht man die architekturale Komplexitat von zweiProjekten, kann deshalb nicht behauptet werden, dass ProjektA schlechter als Projekt B ist, nur weil die Komplexitat vonProjekt A absolut gesehen hoher ist. Neben Werkzeugen zurstatischen Quelltextanalyse gibt es auch Unterstutzung furUberprufungen die zur Laufzeit eines Programms durchgefuhrtwerden konnen. Hierbei konnen andere quantifizierbare Qua-litatskriterien wie die Laufzeit eines Programms uberpruft wer-den. Diese Werkzeuge werden im Rahmen dieser Arbeit nichtnaher betrachtet, da sie wesentlich aufwandiger zu bedienensind und keinen hohen Automatisierungsgrad bieten [5].

Die werkzeugunterstutzte Softwarearchitekturanalyse kannnur quantitative Werte messen und muss diese sinnvoll in-terpretieren, um Aussagen uber die Qualitat der Architekturtreffen zu konnen. Sie soll dabei helfen, die Ist-Architektur ba-sierend auf dem aktuellen Entwicklungsstand des Projektes zuverstehen - man spricht hier auch von einem Reflexionsmodell[6]. Dabei konnen Abweichungen von der Soll-Architekturoder eine zu hohe Komplexitat innerhalb der Pakete festgestelltwerden. Der Fokus liegt hier auf der strukturellen Komplexitateiner Architektur. Hierbei spielen nicht nur Visualisierungenwie die Design Structure Matrix (DSM) [7] zur Darstellung derKomplexitat eine Rolle, sondern auch Veranschaulichungender Kapselung, beziehungsweise der Intra-Modul Kommunika-tion im Projekt. Werkzeugspezifische Visualisierungen werdenim Abschnitt III detaillierter vorgestellt. Um Abweichungenvon der Soll-Architektur bereits bei der Entwicklung weitge-hend zu vermeiden, konnen durch Verwendung eines geeig-neten Werkzeuges gewisse Architekturregeln auch erzwungenwerden.

Durch die Analyse von Softwarearchitekturen mit Hilfe vonWerkzeugen konnen wir nicht feststellen ob die Qualitat derArchitektur ausreichend gut ist. Jedoch ist es uns moglich,Abweichungen von der Spezifikation und Schwachen in derArchitektur aufzudecken. So deuten zum Beispiel vermehrtezyklische Abhangigkeiten oder Zugriffe uber mehrere Schich-

ten hinweg auf eine schlechte Architektur hin. Wir erwarten,dass ein Werkzeug uns dabei hilft, diese Ungereimtheiten aufintuitive Art und Weise zu entdecken und in geeigneter Formdarzustellen. Die Darstellungsformen sollen dabei helfen, auchdie Architektur von großen Projekten besser zu verstehen undInformationen gezielt herauszufiltern. Ein Vergleich zwischender Soll- und Ist-Architektur einer Applikation, ermoglicht esuns Fehler bei der Entwicklung moglichst fruh zu erkennen.Weiterhin muss das Werkzeug Architekturanderungen geeignetunterstutzten, um einer Evolution im Entwicklungsprozessnicht im Wege zu stehen.

III. STRUCTURE101

Das fur die Architekturanalyse verwendete Werkzeug Struc-ture101 Studio [8] der Firma Headway Software, in der aktu-ellen Version 4.2, ist sowohl fur Windows, Linux als auch furOSX verfugbar. Dabei werden auf Java und .NET basierendeSprachen unterstutzt. Uber Drittanbieter konnen unter anderemweitere Quelltextparser fur PHP oder C++ integriert werden.Mit Hilfe verschiedener Plugins werden Integrationen in diegangisten Entwicklungsumgebungen wie Visual Studio oderEclipse angeboten. Neben dessen gibt es Anbindungen anContinuous integration (CI) Systeme sowie einen Webserver,der die Ergebnisse der Architekturanalyse zur Verfugung stellt.

Um die Komplexitat in Softwareprojekten zu messen, stelltStructure101 dem Anwender mehrere Metriken zur Verfugung.Eine davon ist die Cyclomatic Complexity (CC) [9]. Dievon Thomas J. McCabe entwickelte Metrik rechnet einenWert aus, welcher die Komplexitat eines Programmes darstellt.Dieser Wert M kann uber die Anzahl an Binarverzweigungenmit M = b + p berechnet werden, wobei b die Anzahl anBinarverzweigung wie zum Beispiel IF-Anweisungen undp die Anzahl der einzelnen Kontrollflussgraphen ist. SolltenAnweisungen mit mehr als zwei moglichen Flussen, wiezum Beispiel Switch-Case-Anweisungen verwendet wer-den, wird b durch b = z � 1 berechnet, da z die Anzahl allerZweige wiedergibt. Zum anderen kann M durch die Anzahlvon Knoten und Kanten uber M = e � n + 2p berechnetwerden. Hierbei ist e die Anzahl der Kanten, n die Anzahl anKnoten und p die Zusammenhangskomponente im Graphen.Diese Berechnung wird in Structure101 durch die Metrik ”Fat“auf Methodenebene abgebildet. In hoheren Hierarchieebenenwird Fat uber die Anzahl von Abhangigkeiten zu unter-geordneten Paketen gemessen. Daneben gibt es die Metrik

”Tangled“ die das Verhaltnis der zyklischen Abhangigkeitenzu anderen Modulen im Projekt an gibt. Dabei werden abernur Abhangigkeiten auf der Design-Ebene, wie zum Beispielzwischen Paketen, mit einbezogen. Der Tangled-Wert beziehtsich darauf, wie viele ”aufwarts“-Beziehungen es im Vergleichzu allen anderen Beziehungen gibt. Beide Metriken, Fat undTangled, werden in Structure101 in die excess (XS)-Metrik[10], [11] umgerechnet. Hierzu wird bei XS die jeweiligeGroße der Methode, Klasse, oder des Pakets berechnet, indemdie Lines of Code (LOC) mit dem Fat- beziehungsweiseTangled-Wert multipliziert werden. Der Average-XS-Wert sollals Anhaltspunkt verwendet werden, um zu bestimmen, wie

4

gut die Architektur eines Softwareprojekts ist. Dabei steht einkleinerer XS-Wert fur weniger Komplexitat im Projekt.

Um ein neues Projekt in Structure101 anzulegen, mussdas zu analysierende Programm in Form von kompiliertemBytecode vorliegen. Beim Import der Dateien konnen nochverschiedene Filter benutzt werden, wie zum Beispiel dasVerstecken von externen Abhangigkeiten, um nur die Archi-tektur der eigenen Projekte zu analysieren. Daraufhin generiertStructure101 auf Basis der oben genannten Metriken eineUbersicht uber die Abhangigkeiten der Module und derenKontrollflusse. Neben dieser Ubersicht wird als wichtigstesWerkzeug von Structure101 die Levelized Structure Map(LSM) [12] aufgebaut. Uber die LSM kann intuitiv durch dieStruktur der analysierten Applikation navigiert werden. Dabeiwerden Abhangigkeiten zwischen Paketen und Klassen sicht-bar und tragen so zum Verstandnis der Architektur bei. Nichtspezifizierte Kommunikationen zwischen einzelnen Schichtensowie zyklische Abhangigkeiten konnen so schnell identifiziertwerden und erleichtern den Vergleich zwischen Soll- und Ist-Architektur. Zusatzlich findet auch die DSM Verwendung,um einen groben Uberblick uber die Zusammenhange derModule zu verschaffen. Neben der Analyse von bestehendenApplikationen, konnen auch Regeln fur die Soll-Architekturangelegt werden. Dazu wird entweder aus der erstellten LSMein Architekturmodell abgeleitet, oder der Nutzer modelliertdie Komponenten und deren Abhangigkeiten zueinander vonHand. Im Detail wird diese Funktionalitat in Abschnitt VIbetrachtet.

Der mitgelieferte Webserver [13] kann so konfiguriert wer-den, dass immer der aktuelle Stand des Projektes reflek-tiert wird. Beliebige Projektteilnehmer konnen sich so eineUbersicht uber das Projekt verschaffen ohne komplizierte Soft-ware installieren zu mussen. Weiterhin kann der Webserver alszentrale Dokumentationsstelle fur die Architektur des Projek-tes benutzt werden. Durch die Funktion, mehrere Projektstandemiteinander vergleichen zu konnen, kann hier auch, basierendauf der XS-Metrik, auf einen Blick abgelesen werden, ob sichdie Architektur verbessert oder verschlechtert hat.

IV. EVALUIERUNG EINER ARCHITEKTUR

Die automatische Analyse von Softwarearchitekturen istnur sinnvoll, wenn aus dem Quelltext auch fur den Nutzerverstandliche Informationen erzeugt werden konnen. Wie be-reits in Abschnitt III beschrieben, stellt uns Structure101 ver-schiedene Darstellungsformen zur Verfugung, um ein Softwa-resystem auf verschiedenen Abstraktionsebenen zu betrachten.Im Folgenden mochten wir ein Softwareprojekt betrachten unddessen Architektur analysieren sowie verstehen. Im Rahmendieser Arbeit mochten wir uns im speziellen mit Structure101Studio in der .NET Ausfuhrung beschaftigen.

Um die Unterstutzung des Werkzeugs bei der Softwarear-chitekturanalyse zu untersuchen, betrachten wir das OpenSource Projekt SuperSocket [15] in der Version 1.5 und1.6. Das Projekt wurde ausgesucht, da der Quelltext in C#vorliegt und wir durch den geringen Umfang von ca. 8000LOC die Moglichkeit haben die Projektstruktur vollstandig

Abbildung 1. SuperSocket Architekturebenen [14]

zu verstehen. SuperSocket ist ein erweiterbares und leichtgewichtiges Framework fur .NET und Mono, um serverseitigeSocketverbindungen zu ermoglichen, ohne sich dabei um diesystemnahen Konzepte von Sockets kummern zu mussen [15].In Abbildung 1 wird die Architektur von SuperSocket grafischdargestellt. Generell kann hier auf oberster Ebene eine saubereTrennung zwischen der Socket- und der Applikationsschichterwartet werden. Der Endnutzer soll letztendlich nur Zugriffauf die Applikationsschicht haben.

Betrachten wir Abbildung 1 genauer, gehen wir davonaus, dass die einzelnen Schichten klar voneinander getrenntsind und entsprechend den Abgrenzungen der Schichten kei-ne Kommunikation uber mehrere dieser hinweg stattfindet.Der Autor von SuperSocket scheint sich bewusst Gedankenuber die Architektur gemacht zu haben, was nicht selbst-verstandlich fur ein Hobbyprojekt ist. Dadurch erwarten wirauch einen strukturierten Aufbau des Gesamtprojekts sowiedie Vermeidung von zyklischen Abhangigkeiten. In einemoberflachlichen Vergleich von Version 1.5 zu 1.6 sind uber1,5k LOC hinzugekommen, also ist das Projekt in einemkurzen Zeitraum um uber 15% gewachsen. Wir vermuten,dass die Architektur unter dem Zeitdruck, neue Features zuentwickeln, gelitten hat.

Eine initiale Analyse der Ist-Architektur von SuperSocketlasst auf oberster Paketebene eine klare Hierarchie der Schich-ten erkennen. Wir konnen in Abbildung 2 bereits den inAbbildung 1 beschriebenen Application Layer iden-tifizieren, als Paket Agent und SocketService. DerFacility Layer auf gleicher Ebene lasst sich ebenfalls alsklar gekapseltes Paket wiederfinden. Betrachten wir die zweiteSchicht, so konnen wir auch hier in der Architekturkom-position SocketEngine und SocketBase wiederfinden,die deutlich vom Application Layer getrennt sind. DasPaket Common wird uber fast alle Schichten hinweg benutzt

5

Abbildung 2. SuperSocket Komposition und DSM

und stellt unserer Meinung nach aber keine Verletzung derKommunikation uber mehrere Schichten hinweg dar, sonderntragt zur Wiederverwendbarkeit bei. Hier finden sich gangigeMethoden zum Beispiel zur Konvertierung von Netzwerkda-tentypen. Die abgebildete DSM lasst auch auf den erstenBlick erkennen, dass es auf dieser Ebene weder zyklischeAbhangigkeiten noch Aufwartsbewegungen zwischen den Pa-keten gibt.

In einer weiteren Betrachtung gehen wir den Hinweisenvon Structure101 nach, die innerhalb dieser Pakete Problemevermuten lassen. So werden in der Ubersicht in dem Pa-ket SocketBase zyklische Abhangigkeiten und aufgeblahtePakete angezeigt. Uber die Slice-Ansicht konnen wir direktden Problembereich isolieren. Abbildung 3 informiert unsuber eine zyklische Abhangigkeit zwischen einer Klasse undeinem Paket. Nach Analyse des Quelltextes gibt es unsererMeinung nach hier keinen nachvollziehbaren Grund fur einepaketubergreifende zyklische Abhangigkeit. Analog zu die-sem Beispiel lassen sich noch wenige andere unerwunschteAbhangigkeiten finden. Generell scheint die Struktur vonSuperSocket aber sehr durchdacht zu sein und der Tangled-Wert liegt nur bei 9%. Auch haben nur wenige Pakete, Klassenund Methoden einen hohen Fat-Wert, welcher die Schwellevon 120 uberschreitet und somit als schlecht klassifiziertwird. Der Average-XS-Wert, als Maß fur die Qualitat derArchitektur, betragt bei SuperSocket gerade mal 8%. Bei denAnfangs zur Auswahl stehenden Open Source Projekten furdie Evaluierung, konnten wir ofters Werte im Bereich vonuber 40% feststellen. Abschließend lasst sich auf Grund derpositiven Analyseergebnisse behaupten, dass SuperSocket einebeabsichtigte Architektur hat, die weitgehend durchdacht ist.Dies entspricht unseren zuvor definierten Erwartungen, die aufdem Architekturschaubild und dem strukturiertem Quelltextbasieren. In Abschnitt V werden wir Verbesserungsvorschlagebetrachten, um die Qualitat des Projektes gegebenenfalls zuerhohen.

Uber die Funktion What’s new? von Structure101 mochten

wir nun Version 1.5 und 1.6 vergleichen. In der Ubersicht falltdirekt der gestiegene Average-XS-Wert von 8% auf 11% auf.Dies bestatigt zunachst unsere Annahme, dass die Architekturunter dem Wachstum des Projekts gelitten hat. Bei einergenaueren Betrachtung fallen uns hier nur minimale neueProblembereiche auf. So hat sich vor allem der Fat-Werterhoht, indem existierende Pakete durch neue Funktionalitatenaufgeblaht wurden. Weiterhin wurden die bereits in Version1.5 vorhandenen zyklischen Abhangigkeiten nicht aufgelost.

Structure101 hat uns maßgeblich dabei geholfen, die Ar-chitektur von SuperSocket zu verstehen. Die Architekturdo-kumentation konnten wir problemlos durch die Visualisierun-gen von Structure101 ersetzen und uns somit das manuelleErstellen der Abbildung 1 sparen. Problembereiche werdenubersichtlich dargestellt und helfen uns, die Architektur einesProjektes auf den Soll-Stand zu bringen. Der Versionsvergleichist nicht nur auf Architekturebene sinnvoll, sondern unterstutztEntwickler Anderungen an einem Projekt besser nachvollzie-hen zu konnen.

Abbildung 3. SuperSocket Tangle

V. RESTRUCTURE101Restructure101 [8], zuerst als eigenstandiges Produkt ent-

wickelt, ist mittlerweile eine Komponente des Structure101

6

Studios [16], [17]. Uber eine visuelle Reprasentation der Soft-warerchitektur, basierend auf der statischen Quelltextanalyse,kann der Architekt strukturelle Anpassungen durchfuhren.Eigens dafur wurde die in bereits Abschnitt III erwahnte LSMvon Headway Software entwickelt. Die LSM soll Softwa-rearchitekten ein intuitives Werkzeug, um Architekturen zuvisualisieren und manipulieren, zur Verfugung stellen [12].Dabei werden die Komponenten einer Software in verschie-dene Ebenen eingeteilt, um deren Abhangigkeiten zueinan-der darzustellen. Die Einteilung folgt einer einfachen Regel:Elemente auf der selben Ebene haben keine Abhangigkeitenzueinander und die unterste Ebene ist nur mit Elementen ohneAbhangigkeiten befullt. Durch diese Visualisierung kann aufdie Pfeile, die normalerweise die Abhangigkeiten der Kompo-nenten in Architekturdiagrammen veranschaulichen, verzichtetwerden ohne dabei Kontextinformationen zu verlieren [18].

Um strukturelle Anpassungen an der Architektur durch-zufuhren, muss zuerst fur eine bestehende Applikation eineneue Sandbox erstellt werden. Die Sandbox stellt dem Nutzereine LSM zur Verfugung, die nun uber verschiedene Operatio-nen manipuliert werden kann. Es konnen neue Pakete, Klas-sen oder Abhangigkeiten zwischen Letzteren uber ein Kon-textmenu erstellt werden. Weiterhin lassen sich existierendePakete und Klassen verschieben oder gruppieren. Anderungenan der Architektur werden umgehend analysiert und die inAbschnitt III beschriebenen Metriken reflektieren den aktu-ellen Entwurfsstand (vgl. Abbildung 4). Neben manuellenWerkzeugen zur Restrukturierung der Architektur, gibt es auchdie Moglichkeit uber die Operation ”Auto-levelize“ samtlichezyklische Abhangigkeiten auf Paketebene aufzulosen.

Im Rahmen dieser Arbeit mochten wir an dem Pro-jekt SuperSocket Veranderungen an der Architektur vor-nehmen, um beispielhaft eine der in Abschnitt IV be-schriebenen zyklischen Abhangigkeiten zu entfernen. Diein Abbildung 3 eingezeichnete zyklische Abhangigkeitzwischen dem Paket AsyncSocket und der KlasseIAsyncSocketSessionBase im hoher gelegenen PaketSocketEngine, konnen wir in der LSM durch eine Ope-ration beheben. Dazu verschieben wir die Klasse aus demPaket AsyncSocket in das Paket SocketEngine. Ob-wohl wir damit die zyklische Abhangigkeit zwischen deneinzelnen Klassen nicht entfernt haben, konnten wir sie aufPaketebene auflosen. Structure101 passt die Metriken desProjekts nach Ausfuhrung dieser Operation in der Sandboxan und wir erhalten das Feedback, dass ein Tangle aufgelostwurde. Zyklische Abhangigkeiten zwischen Klassen werdenvon Structure101 zwar weiterhin aufgelistet, sie werden aberim Gegensatz zu Paketabhangigkeiten nicht mehr prominentals Problem identifiziert. Dieses Verhalten unterstutzt unsdabei, den Fokus auf strukturelle Probleme der Architekturzu legen und nicht die Qualitat des Quelltextes zu bewerten.Zyklische Abhangigkeiten zwischen Klassen in einem Paketmussen nicht zwingend schlecht sein [19] und stellen keineVerletzung der Architektur dar.

In einem weiteren Versuch wurde die Funktion ”Auto-levelize“ auf das SuperSocket Projekt angewendet. Durch

Abbildung 4. Verhaltnis von Fat und Tangled im Projekt SuperSocket V1.6

Ausfuhren der Funktion wurden samtliche zyklischenAbhangigkeiten zwischen Paketen aufgelost. Dazu hat Re-structure101 Klassen, die zwischen einander Abhangigkeitenhaben, in neue Pakete verschoben. Im Gegensatz zu unsererim vorherigen Absatz beschriebenen manuellen Restrukturie-rung, wurde hier das Paket AsyncSocket beibehalten unddie Klasse IAsyncSocketSessionBase in dieses Paketverschoben. Diese Maßnahme halten wir fur sinnvoll, da sodas ubergeordnete Paket SocketEngine nicht unnotig auf-geblaht wird. Die neu entstandenen Pakete werden mit ”Auto“und einer Zahl, die angibt wie viele Klassen sich in dem Paketbefinden, gekennzeichnet. Der Architekt kann nun bequem dieautomatisch erstellten Pakete entsprechend ihrer Funktionalitatumbenennen. Die meisten neuen Pakete stellen eine rationaleGruppierung einzelner Klassen dar. Restructure101 scheinthier Klassen, die miteinander kommunizieren, zusammenzu-legen. Betrachtet man das gesamte Projekt, lassen sich aberauch fragliche Anderungen an der Paketstruktur feststellen. Sowurde das Paket ”Common“, das einige Helferklassen enthalt,in viele kleine Pakete unterteilt. Diese Anderung hatten wirmanuell nicht durchgefuhrt, da das Paket nicht ubermaßigviele Klassen enthalt. Eine Aufteilung von 15 Klassen in 7Pakete wirkt unserer Meinung nach der Ubersichtlichkeit derArchitektur eher entgegen.

Gleichwohl erachten wir die Auto-levelize Funktion alssinnvolle Erganzung, da, richtig angewendet, das manuelleVerschieben von Klassen automatisiert werden kann. Beigroßeren Projekten ist es sicherlich ratsam, diese Funktio-nalitat nicht auf das gesamte Projekt anzuwenden, sondernnur auf einzelne Pakete. Anderenfalls ist es schwierig dieArchitekturanderungen, die Restructure101 durchgefuhrt hat,nachzuvollziehen. Die Rolle des Softwarearchitekten kanndadurch nicht ersetzt werden. Eine manuelle Kontrolle undein Nachbessern der automatisch erstellten Architekturstrukturmuss dennoch von Experten durchgefuhrt werden.

VI. QUALITATSSICHERUNG DER ARCHITEKTUR

In den vorherigen Abschnitten haben wir gezeigt, welcheAnforderungen an eine Softwarearchitektur werkzeuggestutztanalysiert werden und wie wir diese Ergebnisse interpretierenkonnen, um durch Umstrukturierung der Architektur messbardie Komplexitat zu verringern. Im Folgenden mochten wiruns damit auseinandersetzen, wie diese Erkenntnisse in den

7

Abbildung 5. Structure101 im Arbeitsablauf [8]

Entwicklungsprozess integriert werden konnen, um zu einernachhaltigen Verbesserung der Softwarequalitat beizutragen.Wir gehen dabei von einem neuen Softwareprojekt aus, durchleichte Modifikation der Arbeitsablaufe lassen sich diese aberauch auf bestehende Projekte ubertragen.

Um die Qualitat einer Software durch die Architekturana-lyse verbessern zu konnen, machen wir folgende Annahme:Entwickler modifizieren unbewusst oder bewusst die Architek-tur, indem Abhangigkeiten verandert werden, um eine Aufgabezu erledigen. Die Motivationen konnen hier unterschiedlicherNatur sein. Ein denkbarer Grund ware zum Beispiel dieErledigung der Aufgabe in kurzerer Zeit, durch Verwendungvon Funktionen aus einer anderen Architekturschicht, die denselben Zweck erfullen zu scheint. Diese naive Entscheidungstellt nicht nur eine Verletzung der Architektur dar, sondernkonnte auch durch Seiteneffekte gravierende Folgen fur dieQualitat der Software haben. Hierbei ist anzumerken, dass eineVeranderung der Architektur durchaus gewollt sein kann undauch notwendig ist [20]. Nur sollte diese in einem kontrol-lierten Umfeld und nicht bei der zeitkritischen Umsetzungeiner Aufgabe entstehen. Anderenfalls kann es schnell zueiner Degeneration der Architektur kommen, die sich imSoftwareentwicklungsprozess fortpflanzt.

Anhand dieses Beispiels wird deutlich, wie schwerwiegendsich scheinbar kleine Anderungen an der Software und indirektan der Architektur auf die Qualitat auswirken konnen. Wirmochten nun uberprufen, wie wir mit Werkzeugunterstutzungdie Architektur kontrollieren konnen, um solche Anderungenvon Experten prufen zu lassen. Geeignete Experten sind unver-zichtbar und helfen uns hier zu verstehen, ob es sich um eineDegeneration der Architektur handelt, oder die Architektur aufGrund der Evolution der Software angepasst werden muss.Voraussetzung fur die Integration des Werkzeugs in den Ent-wicklungsprozess ist demnach eine wohldefinierte Architekturund das Vorhandensein von Personen, die Expertenwissen uberdas Softwareprojekt und die Architektur besitzen. Weiterhin

setzen wir voraus, dass das Werkzeug jederzeit Zugriff aufden aktuellen Entwicklungsstand des Projektes uber Versions-verwaltungssysteme (VCS) hat. Abbildung 5 stellt den grobenAblauf zur Qualitatssicherung der Architektur dar.

Vor dem Start der Implementierung muss der Architekt inStructure101 ein Architekturmodell anlegen. Das Architek-turmodell reprasentiert die Architektur der zu entwickelndenSoftware auf Paketebene. Hierbei hat er die Moglichkeit, Be-ziehungen der Pakete zueinander und deren Sichtbarkeit nachaußen zu modellieren. Das Architekturmodell kann daraufhinexportiert und automatisch uber ein Netzwerklaufwerk denEntwicklern in ihrer Entwicklungsumgebung uber ein Pluginweitergegeben werden. Das Plugin veranschaulicht dem Ent-wickler das Architekturmodell direkt in der vertrauten Arbeit-sumgebung. Weiterhin wird beim Kompilieren des Quelltextesanhand des Modells uberpruft, ob die hinterlegten Architektur-regeln verletzt werden. Ist dies der Fall, wird dem Entwicklereine Fehlerliste angezeigt und die Entwicklungsumgebungverweigert das Ausfuhren des Programms. Zusatzlich lassensich die Architekturregeln in den Buildprozess eines Projektesintegrieren. Somit kann gewahrleistet werden, dass zustandigeArchitekten bei Verletzungen der Architektur automatischinformiert werden. Nach Prufung der aktuellen Architektur,kann der Architekt, wie in Abschnitt V beschrieben, zumBeispiel zyklische Abhangigkeiten auflosen oder die Architek-tur den neuen Anforderungen entsprechend anpassen. Dabeiverfolgt Structure101 die Anderungen und erstellt eine Akti-onsliste, die analog zum Architekturmodell dem Entwicklerin der Entwicklungsumgebung zur Verfugung gestellt wird.Dadurch wird dem Entwickler auf sehr verstandliche Weisedie Anderung an der Architektur kommuniziert und er kanndie Liste gegebenenfalls abarbeiten.

Durch die kontinuierliche Uberprufung unterstutzt Struc-ture101 das Projektteam dabei, die Architektur der Softwarebesser zu verstehen und dabei die Komplexitat zu verrin-gern, beziehungsweise gering zu halten. Dabei kann auchdie Qualitat der zu entwickelnden Software nachhaltig erhohtwerden. Naturlich ist der Einsatz solcher Werkzeuge keineGarantie fur eine hohe Qualitat des Endproduktes. Wir konnenaber abschließend festhalten, dass wir durch den Einsatz vonWerkzeugen zur Architekturanalyse die geplante Struktur ei-ner Software einhalten und Abweichungen kontrolliert planenkonnen.

VII. BEWERTUNG DES WERKZEUGS

Structure101 hat sich als hilfreiches Werkzeug fur denProzess der Softwarearchitekturanalyse erwiesen. Mit we-nig Aufwand konnten bestehende Projekte analysiert undnutzliches Erkenntnisse im Hinblick auf die Architektur ge-wonnen werden. Die Architektur wird durch verschiedeneDarstellungsformen wie die LSM und die DSM sehr praziseabgebildet. Architekten konnen durch die verschiedenen Filterden Umfang der zu betrachtenden Teilsysteme eingrenzen, umeine Informationsflut zu vermeiden. Problembereiche in derIst-Architektur werden zusatzlich in einer Liste ubersichtlichdargestellt und bieten direkt zu Anfang einen guten Uberblick

8

uber das Gesamtprojekt. Structure101 beschrankt sich aufwenige sinnvolle Metriken und unterstutzt den Nutzer dabeischnell, wichtige Erkenntnisse uber das Projekt zu erlangen.An einigen Stellen wird die CC-Metrik [21] fur die Berech-nung der Komplexitat auf Funktionssebene verwendet. DieMetrik gilt als umstritten, da ein Mensch die Komplexitatdes Quelltextes differenzierter betrachten kann und somit dieAussage der CC-Metrik oftmals weit entfernt von der Realitatist [22]. Diese stellt aber in Structure101 nur eine zusatzlicheInformation dar und muss fur die Evaluation der Architekturnicht zwingend betrachtet werden.

Zur Analyse der Ist-Architektur im .NET oder Java Umfeldmuss das Kompilat einer Applikation in Form von Bytecodevorliegen. Structure101 bedient sich dabei gangiger Reverse-Engineering Methoden. Dadurch ergeben sich einige Vorteileim Vergleich zur Quelltextanalyse. Bytecode stellt sicher, dassdas zu analysierende Programm ausfuhrbar und somit auchsyntaktisch korrekt ist. Weiterhin ist ein Bytecode-Parser nichtauf eine einzige Sprache beschrankt, da Sprachen wie C#, F#oder auch VB.NET in die gleiche Zwischensprache ubersetztwerden. Dies bringt aber auch die Einschrankung mit sich,dass eine Applikation von der Analyse kompiliert werdenmuss.

Obwohl der initiale Aufwand fur die Softwarearchitektur-analyse von bestehenden Applikationen gering ist, muss furdie Integration in den gesamten Entwicklungsprozess mehrZeit investiert werden. Die Abbildung von Architekturregelnund das Verhindern von Architekturverletzungen uber Pluginsin der Entwicklungsumgebung finden wir sehr gelungen. Auchist Restructure101 ein hilfreiches Werkzeug, um Anderungenan der Architektur abzubilden und diese zwischen Entwicklernund Softwarearchitekten zu kommunizieren. Die LSM, alsim Zentrum stehendes Werkzeug, bietet Architekten einenguten Uberblick uber ein Projekt und funktioniert selbst nochsinnvoll bei Projekten mit mehr als einer Millionen LOC. DieErstellung der LSM geschieht zumeist in wenigen Sekunden.Positiv ist uns auch der Support aufgefallen, der trotz kosten-loser Lizenz innerhalb eines Tages auf Anfragen antwortet.

Als negativ empfanden wir Teile der grafischen Oberflachedes Structure101 Studios. Arbeiten mit hoch aufgelosten Bild-schirmen ist auf Grund der nicht anderbaren Schriftgroßefast nicht moglich. Weiterhin traten ofters Darstellungsfehlerauf, die uns Worter oder gar Satze raten ließen. Selten kames auch zu Absturzen des Programms. Wunschenswert wareauch eine Zoom-Funktion der LSM, um die Ubersichtlichkeitbei der Analyse und der Restrukturierung der Architektur zuwahren. Durch den großen Funktionsumfang des gesamtenStudios musste unserer Meinung nach die Dokumentationstrukturierter und detaillierter sein, ansonsten geht viel Zeitdurch Erraten der Funktionalitat verloren.

VIII. AUSBLICK

Structure101 bietet bereits sehr gute Moglichkeiten die Ar-chitektur einer Software im Entwicklungsprozess anzupassenund dementsprechend fur die Entwicklungsumgebungen uber

Plugins diese Veranderungen fur Entwickler verpflichtend undverstandlich darzustellen.

Unserer Meinung nach konnte der Vorgang, die Regeln indie Tat umzusetzen, in Zukunft, zumindest teilweise, auto-matisiert fur die .NET Plattform umgesetzt werden. Durchdie .NET Compiler Plattform ”Roslyn“ [23], die von Mi-crosoft seit 2014 [24] angeboten wird, konnen QuelltextTransformationen von in C# und Visual Basic geschriebenenProgrammen mit Hilfe der Feature API [25] durchgefuhrtwerden. Abhangigkeiten von Objekten, Klassen, Methodenund Variablen werden bis zu einem sehr hohem Grad aufgelostund konnen in einem Syntax Baum dargestellt und direktmanipuliert werden [26]. Dadurch entfallt ein Großteil derArbeit zur Entwicklung von Quelltext-Parsern und erlaubt es,den Fokus auf die Ausfuhrung der von Structure101 definiertenRegeln zu legen. Transformationen konnten in einer SandboxUmgebung durchgefuhrt und die Richtigkeit direkt durch dasKompilieren des Sandbox Projektes getestet werden.

Auch wenn Roslyn die Entwicklung von automatischenQuelltexttranformationen im .NET Bereich erleichtert undweniger fehleranfallig macht, ist und bleibt die automatischeRestrukturierung des Quelltextes ein fehleranfalliger Prozess.Manche Abhangigkeiten in einem Softwaresystem konnenerst zur Laufzeit eines Programms aufgelost werden, so dassnach einer Restrukturierung des Quelltextes die Korrektheitdes Systems trotzdem noch validiert werden muss. Dennochsind wir der Ansicht, dass kleinere strukturelle Anpassungenauf Paketebene, wie in Abschnitt V beschrieben, zu einerZeitersparnis auf Entwicklerseite fuhren konnen.

IX. FAZIT

Durch die fruhzeitige Planung der Integration von Werk-zeugen zur Architekturanalyse in den Projektablauf, konnenwir die Qualitat der zu entwickelnden Software nachhaltigverbessern. Wir konnten feststellen, dass durch wenig Zeit-aufwand Architekturen in Module mit ihren Abhangigkeitenzerlegt werden konnen, um so Entwicklern jederzeit ein gutverstandliches Gesamtbild des Softwaresystems zu bieten.Durch Visualisierungen der Architektur und dem Forcierenvon Architekturregeln in der Entwicklungsumgebung, werdenEntwickler fur die Wichtigkeit der Architektur sensibilisiert.Dadurch lasst sich proaktiv die Degeneration der spezifiziertenSoftwarearchitektur vermeiden und somit ein positiver Effektfur das Gesamtprojekt erzielen.

Mit Hilfe von Werkzeugen wie Structure101 kann die Doku-mentation einer Architektur auch bei sich andernden Anforde-rungen jederzeit aktuell gehalten werden. Samtliche Projekt-teilnehmer konnen ohne hohen zeitlichen Mehraufwand vonder Integration profitieren. Die Werkzeugunterstutzung fur dieSoftwarearchitekturanalyse wurden wir als nicht nur hilfreich,sondern unverzichtbar bezeichnen, um eine hohe Qualitat derArchitektur im Entwicklungsprozess zu wahren. Auf Grunddes hohen initialen Integrationsaufwands sowie gegebenenfallsanfallenden Lizenzkosten, eignet sich das Structure101 Studiovorrangig fur mittlere bis große Projekte.

9

LITERATUR

[1] (2016, june) Static analysis ibm rational software analyzer: Gettingstarted. [Online]. Available: http://www.ibm.com/developerworks/rational/library/08/0429 gutz1/

[2] R. Kazman, L. Bass, M. Klein, T. Lattanze, and L. Northrop, “Abasis for analyzing software architecture analysis methods,” SoftwareQuality Journal, vol. 13, no. 4, pp. 329–355, 2005. [Online]. Available:http://dx.doi.org/10.1007/s11219-005-4250-1

[3] R. Kazman, M. Klein, and P. Clements, “Atam: Method for architectureevaluation,” Software Engineering Institute, Carnegie Mellon University,Pittsburgh, PA, Tech. Rep. CMU/SEI-2000-TR-004, 2000. [Online].Available: http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5177

[4] R. Kazman, L. Bass, M. Webb, and G. Abowd, “Saam: Amethod for analyzing the properties of software architectures,”in Proceedings of the 16th International Conference on SoftwareEngineering, ser. ICSE ’94. Los Alamitos, CA, USA: IEEEComputer Society Press, 1994, pp. 81–90. [Online]. Available:http://dl.acm.org/citation.cfm?id=257734.257746

[5] V. Cortellessa and L. Frittella, Formal Methods and Stochastic Modelsfor Performance Evaluation: Fourth European Performance EngineeringWorkshop, EPEW 2007, Berlin, Germany, September 27-28, 2007.Proceedings. Berlin, Heidelberg: Springer Berlin Heidelberg, 2007,ch. A Framework for Automated Generation of Architectural Feedbackfrom Software Performance Analysis, pp. 171–185. [Online]. Available:http://dx.doi.org/10.1007/978-3-540-75211-0 13

[6] G. C. Murphy, D. Notkin, and K. Sullivan, “Software reflexion models:Bridging the gap between source and high-level models,” in Proceedingsof the 3rd ACM SIGSOFT Symposium on Foundations of SoftwareEngineering, ser. SIGSOFT ’95. New York, NY, USA: ACM, 1995, pp.18–28. [Online]. Available: http://doi.acm.org/10.1145/222124.222136

[7] (2016, may) The design structure matrix (dsm). [Online]. Available:http://www.dsmweb.org/

[8] (2016, may) structure101. [Online]. Available: http://structure101.com/[9] T. J. McCabe, “A complexity measure,” IEEE Transactions on Software

Engineering, vol. SE-2, no. 4, pp. 308–320, Dec 1976.[10] Headway Software. (2006, jan) Xs – a measure of structural over-

complexity. [Online]. Available: https://structure101.com/static-content/pages/resources/documents/XS-MeasurementFramework.pdf

[11] R. S. Sangwan, P. Vercellone-Smith, and P. A. Laplante, “Structuralepochs in the complexity of software over time,” IEEE Software, vol. 25,no. 4, pp. 66–73, July 2008.

[12] C. Chedgey. (2011, march) Introducing levelized structuremaps (lsm). [Online]. Available: http://structure101.com/blog/2011/03/introducing-levelized-structure-maps-lsm/

[13] (2016, may) Webapp. [Online]. Available: http://structure101.com/legacy/webapp/

[14] (2016, june) Supersocket architecture diagrams. [Online]. Available:http://docs.supersocket.net/v1-6/en-US/Architecture-Diagrams

[15] (2016, june) Supersocket. [Online]. Available: http://supersocket.net[16] (2016, june) Restructure101 1.0 release. [Online]. Available: http:

//www.prweb.com/releases/2011/5/prweb8414342.htm[17] (2016, june) Structure101 studio release. [Online]. Available: http:

//structure101.com/blog/2013/11/upgrade-now-to-structure101-studio/[18] (2016, june) Structure101 levelized structure map (lsm). [Online].

Available: http://structure101.com/help/dotnet/studio/#restructure101/lsm.html%3FTocPath%3DModel%2520tab%7C 2

[19] (2016, june) Circular dependencies are not always evil. [Online].Available: http://beust.com/weblog2/archives/000208.html

[20] (2016, june) Architecture evolution. [Online]. Available: http://www.sei.cmu.edu/architecture/research/previousresearch/evolution.cfm

[21] M. Shepperd, “A critique of cyclomatic complexity as a software metric,”Software Engineering Journal, vol. 3, pp. 30–36, 1988.

[22] N. E. Fenton and M. Neil, “A critique of software defect predictionmodels,” IEEE Trans. Softw. Eng., vol. 25, no. 5, pp. 675–689, Sep.1999. [Online]. Available: http://dx.doi.org/10.1109/32.815326

[23] (2016, june) .net compiler platform (roslyn). [Online]. Available:https://www.dotnetfoundation.org/dotnet-compiler-platform

[24] (2016, june) .net compiler platform (roslyn) preview heading to .netand visual studio vnext. [Online]. Available: https://goo.gl/0xKh4m

[25] (2016, june) .net compiler platform (roslyn) overview apilayers. [Online]. Available: https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview#api-layers

[26] P. Samrongsap and W. Vatanawood, “A tool for detecting dependencyviolation of layered architecture in source code,” in Computer Scienceand Engineering Conference (ICSEC), 2014 International, July 2014,pp. 130–133.

10

Technologien und Muster zur Entwicklung von Nanoservice-Architekturen

Timo Bayer und Philipp RufHochschule FurtwangenFurtwangen, Germany

Email: {timo.bayer, philipp.ruf}@hs-furtwangen.de

Zusammenfassung—Die Verwendung von Microservices bie-tet ein hohes Potential bei der Erstellung flexibler, skalierbarerund dynamischer Anwendungen und erfreut sich zunehmendsteigender Beliebtheit in verschiedenen Anwendungsbereichen.Die vorliegende Arbeit untersucht das Konzept der Microser-vices und nimmt hierbei insbesondere Bezug auf die idealeGroße eines einzelnen Microservice. Die Erstellung moglichstfeingranularer Microservices, sogenannten Nanoservices, erfor-dert geeignete Technologien zur effizienten Umsetzung diesesArchitekturmusters. Ein Schwerpunkt dieser Arbeit liegt daherauf der Untersuchung und Bewertung moglicher Technologienzur effektiven Reduktion der Große eines Microservice. Hierbeiwerden die notwendigen Kompromisse und Einschrankungenbei der Erstellung feingranularer Microservices betrachtet. DieBetrachtung umfasst Technologien wie OSGi, Amazon Lambda

und Erlang. Anhand einer Beispielimplementierung werden dieEignung und Besonderheiten dieser Technologien im Kontextder Entwicklung von Nanoservices betrachtet. Das Ziel dieserArbeit ist die Bewertung des umstrittenen ArchitekturmustersNanoservices sowie die Identifikation geeigneter Technologienund notwendiger Einschrankungen dieses Architekturmusters.

Keywords-Microservices, Nanoservices, OSGi, AmazonLambda, Vert.x, Erlang

I. EINLEITUNG

Kaum ein Architekturmuster erfuhr in den letzten Jah-ren mehr Beachtung als das Konzept der Microservices.Obwohl die Aufteilung von Anwendungssystemen in un-abhangige Dienste kein neues Phanomen darstellt, sondernsich insbesondere durch Service Orientierte Architekturen(SOA) bereits stark etabliert hat, werden Microservicesoft als neues vielversprechendes Architekturkonzept ange-sehen. Dies ist vorwiegend durch deren charakteristischeEigenschaften, wie dem unabhangigen Deployment, dergegebenen Technologiefreiheit oder der Moglichkeit zurbedarfsgerechten Skalierung zu begrunden. Da diese Ei-genschaften hauptsachlich aus der reduzierten Modulgroßeresultieren, entstehen haufig Architekturen, innerhalb de-rer, unter Berucksichtigung der verwendeten Technologien,eine zu feingranulare Unterteilung der Module stattfindet.Werden Microservices zu feingranular, wirkt sich der hoheKommunikations-, Koordinations- und Infrastrukturaufwandnegativ auf das gesamten System aus, weswegen diesesSzenario haufig als Anitpattern bezeichnet wird. Die Defini-tion eines geeigneten Umfangs der Microservices ist daheressenziell fur die erfolgreiche Umsetzung dieses Architek-

turmusters. Der Umfang wird jedoch stark von den verwen-deten Technologien zur Ausfuhrung und Kommunikationder Microservices bestimmt. Gangige Rahmenwerke furdie Umsetzung herkommlicher Microservices sind SpringBoot und WSO2 MSF4J. Ist eine weitere Unterteilung derMicroservices gewunscht, mussen alternative Technologienverwendet werden, welche eine effiziente Ausfuhrung undKommunikation der Dienste ermoglichen. Die vorliegendeArbeit widmet sich der Untersuchung dieser feingranularenMicroservices und moglichen Technologien zur effizientenUmsetzung des Architekturmusters.

Neben einer einfuhrenden Betrachtung der aus demMicroservice-Architekturmuster resultierenden Vorteile undEinschrankungen werden Einflussfaktoren zur Definition ei-ner geeigneten Große der Microservices in Kapitel III dis-kutiert. Der Schwerpunkt dieser Arbeit ist die Untersuchungfeingranularer Microservices. Dies umfasst insbesondere dieBetrachtung der speziellen Eigenschaften sowie die Ab-grenzung von herkommlichen Microservices, welche KapitelIV entnommen werden konnen. Anhand der, in Kapitel Vvorgestellten, Auswahl- und Bewertungskriterien, werdenselektierte Technologien fur die Entwicklung von Nanoser-vices, in den Kapiteln VI, VII, VIII und IX untersucht. DenAbschluss bilden die Reflexion der Technologien und dieBeantwortung der Frage, in welchen Fallen eine weitereUnterteilung in Nanoservices sinnvoll ist (Kapitel X).

II. RELATED WORK

Der Entwicklung des Architekturmusters Microservicesund den daraus resultierenden Vorzugen wurden uber dieJahre zahlreiche Publikationen gewidmet. Neben den gene-rellen Veroffentlichungen uber die grundlegenden Konzepteund Besonderheiten der Microservices, wie etwa in [1],entstanden weiterfuhrende Arbeiten, welche dieses Architek-turmuster auf verschiedene Anwendungsszenarien und dieVerwendung konkreter Technologien adaptierten.

In [2] stellte Zimmermann generelle Grundsatze der Mi-croservice Architektur vor und ging hierbei ebenfalls aufdie Abgrenzung zu monolithischen Anwendungen und einerSOA ein. Die darin beschriebenen Grundsatze werden inder vorliegenden Arbeit im Rahmen der Bewertung derbetrachteten Technologien aufgegriffen. Daruber hinaus wur-den Aspekte, wie die Kommunikation und der Betrieb derMicroservices diskutiert. Diese werden bei der Entwicklung

11

von Nanoservices noch weiter verstarkt und sind daherebenfalls Teil der vorliegenden Arbeit.

Ein wesentlicher Aspekt der Einfuhrung einerMicroservice-Architektur umfasst die Steigerung derEntwicklungseffizienz und die daraus resultierendenKostensenkungen. Neben generellen Vorteilen desdiskutierten Architekturmusters widmete sich Singleton in[3] im Speziellen den okonomischen Vorteilen und zeigteden direkten Zusammenhang der reduzierten Modulgroßemit den entstehenden Entwicklungskosten auf.

Bedingt durch neue Trends der Informationstechnologie,wie etwa Big Data oder Internet of Things, gewinnt dasMicroservice-Architekturmuster weiterhin an Bedeutung. Soveranschaulichte Sill in [4] das hohe Potential im Kontextdieser und weiterfuhrenden, aktuellen Anwendungsgebieten.Bedingt durch die Integration vieler leichtgewichtiger Com-putersysteme steigt die Relevanz der Entwicklung moglichstfeingranularer Microservices und zeigt die Brisanz der Be-trachtung des umstrittenen Architekturmusters Nanoservices.

Der Begriff Nanoservice tritt in der Literatur selten aufund wurde stark von Eberhard Wolf gepragt. Dieser be-schrieb in [5], neben generellen Aspekten der Nanoser-vices, mogliche Technologien, um diese zu realisieren. DieBetrachtung umfasste mehrere Technologien, wie OSGi,JavaEE und Erlang, welche anhand mehrerer Aspekte ver-glichen wurden. Die Auswahl der nachfolgend betrachtetenTechnologien beruht unter anderem auf dieser Arbeit.

Ein genereller Trend im Kontext der Microservices ist derBetrieb innerhalb bestehender Cloud-Infrastrukturen. Dieserleichtert die Moglichkeiten zur flexiblen Skalierung undabstrahiert dabei technische Details der zugrunde liegendenInfrastruktur. So beschrieben Villamizar et. al. in [6] dieVerwendung von Amazon Lambda fur den Betrieb feingranu-larer Microservices und verglichen dies mit herkommlichenmonolithischen Anwendungen. Ein Fokus lag hierbei aufden entstehenden Kostensenkungen.

III. MICROSERVICES

Die zielfuhrende Entwicklung von Nanoservices erfor-dert zunachst ein tiefes Verstandnis der Microservice-Architektur, da eine weitere Unterteilung der Module ge-wissen Grundsatzen entsprechen sollte. Das folgende Kapitelbetrachtet daher generelle Aspekte der Microservices. Diesumfasst die Betrachtung der zugrunde liegenden Konzepte,resultierenden Vorteile sowie die Einflussfaktoren zur Defi-nition einer idealen Modulgroße.

A. Grundlegende Konzepte

Modularisierung: Microservices sind ein Modularisie-rungskonzept zur Aufteilung eines Anwendungssystems inunabhangige Module [1]. Diese Module definieren eine klareVerantwortlichkeit und stellen der Anwendung ihre Dienstemittels expliziter Schnittstellen zur Verfugung. Abseits der

definierten Schnittstellen erhalten die Module keine Informa-tionen uber die konkrete Funktionsweise der weiteren Mo-dule. Dieses Konzept ist keine Besonderheit, sondern stelltein wesentlicher Bestandteil strukturierter Softwarearchitek-turen dar. Im Vergleich zu monolithischen Anwendungen istder Umfang eines Moduls jedoch wesentlich geringer. DasAnwendungssystem entsteht durch gezielte Komposition dereinzelnen Microservices [1].

Unabhangiges Deployment: Das zentrale Ziel einerMicroservice-Architektur ist die Moglichkeit eines un-abhangigen Deployments einzelner Module, weswegen, ins-besondere bei der Fragmentierung der Module, Vorsichtgeboten ist. Monolithische Anwendungen unterziehen sichmeist einem einzigen, kompletten Deployment und mussenalle Phasen der Continous-Delivery-Pipeline, wie Deploy-ment, Test, Abnahme und Release als Ganzes durchlaufen[5]. Bedingt durch die Große, gestaltet sich dieser Prozessals wesentlich komplexer und zeitaufwendiger als bei klei-neren Systemen. Das Konzept der Microservices ermoglicht,aufgrund der Unabhangigkeit der Module, diese einzeln zudeployen und den beschriebenen Aufwand zu reduzieren.

Kommunikation: Zur Komposition der Anwendung isteine Kommunikation uber die Grenzen eines Microserviceshinaus erforderlich. Die Interaktion der Microservices unter-einander findet dabei jedoch lediglich uber die definiertenSchnittstellen statt. Im Gegensatz zu monolithischen An-wendungen, in welchen Funktionalitaten zwischen Modulenmeist mittels Funktionsaufrufen definiert werden, erfolgtein Aufruf in einer Microservice-Architektur gewohnlichuber die Netzwerkebenen mittels REST-Aufrufen. Fur denInformationsaustausch zwischen Modulen kommen standar-disierte Formate, wie XML oder JSON zum Einsatz [1].Abseits der definierten Schnittstellen durfen Microserviceskeine direkten Abhangigkeiten enthalten.

Isolation: Eine weitere Besonderheit der Microservicesist die Ausfuhrung eines jeden Dienstes innerhalb eineseigenen Prozesses. Dies ist ein wesentlicher Unterschiedgegenuber einer monolithischen Anwendung, welche meistaus einem oder wenigen Prozessen bestehen. Die Aufteilungin unabhangige Prozesse ermoglicht eine hohe Isolation derMicroservices und resultiert insbesondere in einer starkenFehlertoleranz, da das Fehlverhalten eines Moduls sich nichtauf weitere Systemkomponenten auswirkt [7].

B. Ausgewahlte Vorteile von MicroservicesVerglichen mit monolithischen Anwendungen weisen Mi-

croservices spezielle Starken auf. Nachfolgend werden, ba-sierend auf [7], die im Kontext der Betrachtung einerNanoservice-Architektur relevanten Vorteile beschrieben.

Starke Modularisierung: Die Unterteilung in feingra-nulare Module resultiert bei einer geeigneten Umsetzung ineiner starken Modularisierung mit klaren Verantwortlichkei-ten. Die Beschrankung der Kommunikation auf definierteSchnittstellen reduziert zudem, aufgrund technischer Hurden

12

der erforderlichen Netzwerkkommunikation, unerwunschteAbhangigkeiten zwischen den Modulen. Daruber hinausermoglichen die expliziten Schnittstellen einen einfachenAustausch vorhandener Module und begunstigen daher dasunabhangige Deployment der Microservices.

Hohere Robustheit und Fehlertoleranz: Eine weiterepositive Eigenschaft der Microservices ist die aus der Iso-lation resultierende Robustheit einzelner Module. Aufgrundder Aufteilung in Prozesse konnen globale Auswirkungenvon Fehlern innerhalb eines Microservice verhindert werden.Enthalt ein Microservice besonders fehleranfallige Funk-tionen, konnen diese kritischen Dienste mittels gezielterRedundanz abgesichert werden.

Unabhangige Skalierbarkeit: Eine besondere Charak-teristik der Microservices ist die Moglichkeit, einzelneKomponenten unabhangig zu skalieren. Verglichen mit mo-nolithischen Anwendungen, welche meist bei steigenderLast als Ganzes skaliert werden mussen, ermoglicht dieMicroservice-Architektur eine bedarfsgerechte Skalierungder von der erhohten Last betroffenen Modulen.

Technologiefreiheit: Eine monolithische Anwendungerfordert meist vor Projektbeginn eine strikte Festlegungder zu verwendenden Technologien. Die hierbei getrof-fenen Entscheidungen besitzen Gultigkeit fur das gesam-te Projekt und sind im Nachhinein, aufgrund des hohenRisikos von Kompatibilitatsproblemen bei der Ubernahmeneuer Technologien, nur schwer anderbar. Die Microservice-Architektur ermoglicht hingegen eine flexible und proble-madaquate Auswahl der Technologien auf Modulebene. Diesumfasst die verwendeten Programmiersprachen, Frameworksoder Bibliotheken. Dennoch sind gewisse Einschrankungensinnvoll, da die Verwendung stark heterogener Technologiendie Gesamtkomplexitat des Systems stark erhoht.

C. Einflussfaktoren fur die minimale GroßeDie Verwendung von Microservices ist neben den beste-

henden Starken jedoch ebenfalls mit Einschrankungen undKompromissen in verschiedenen Bereichen verbunden. ImKontext der Entwicklung moglichst feingranularer Micro-services sind daher die Einflussfaktoren zur Definition einerminimalen Grenze von besonderer Bedeutung.

Verteilte Kommunikation: Microservices sind verteilteSysteme, da die Kommunikation zwischen den einzelnenModulen meist uber ein Netzwerk erfolgt. Verteilte Sys-teme und die dadurch notwendige Kommunikation sindallerdings immer mit einer erhohten Komplexitat und Feh-leranfalligkeit verbunden. Netzwerkkomponenten konnenausfallen, Verbindungen unterbrechen und unvorhersehba-re Ubertragungsverzogerungen entstehen. Daher mussendiese Aspekte, bei der Entwicklung einer Microservice-Architektur, fruhzeitig beachtet werden und bei der Wahleines geeigneten Umfangs stets abgewogen werden, ob eineweitere Unterteilung den entstehenden Kommunikationsauf-wand rechtfertigt.

Infrastrukturanforderungen: Aufgrund der Vielzahleinzelner Module und der Notwendigkeit diese einzeln zubetreiben, uberwachen und deployen, stellt die Microservice-Architektur erhohte Anforderungen an die zugrunde liegen-de Infrastruktur [5]. Dies umfasst die Notwendigkeit zureffizienten Handhabung des erhohten Ressourcenverbrauchsund die Einfuhrung moglichst automatisierter Verfahren zurWartung und Uberwachung der Komponenten. Werden dieMicroservices zu feingranular, ubersteigt die Komplexitatund der Ressourcenverbrauch deren Nutzen.

Transaktionen und Konsistenz: Eine weitere Ein-schrankung betrifft die Sicherstellung konsistenter Verarbei-tungsergebnisse. Basiert die Verarbeitung eines Microserviceauf Ergebnisse einer anderen Systemkomponente, kann dies,bedingt durch die Probleme verteilter Systeme, unweigerlichzu Inkonsistenzen und falschen Ergebnissen fuhren. Einsolches Szenario erfordert die Verwendung globaler Trans-aktionen, welche eine atomare Verarbeitung sicherstellen.Da die Sicherstellung der Konsistenz in verteilten Systemennur unter Kompromissen moglich ist, muss der Umfangeines Microservice so gewahlt werden, dass dieser samtlicheFunktionalitaten zur Sicherstellung der Korrektheit des Ver-arbeitungsergebnisses selbst beinhaltet und keine globalenTransaktionen erfordert [5].

IV. NANOSERVICES

Das Konzept der Nanoservices ist nicht einheitlich de-finiert. Das folgende Kapitel beschaftigt sich daher mit derAbgrenzung zu Microservices und beschreibt die Motivationzur Entwicklung dieser. Daruber hinaus werden die notwen-digen Voraussetzungen und erforderlichen Kompromisse zureffizienten Umsetzung dieses Architekturmusters aufgezeigt.

A. Definition und AbgrenzungDer Begriff Nanoservice wird verwendet um Modulari-

sierungen hervorzuheben die dem Konzept der Microser-vices ahneln, aber einen geringeren Umfang aufweisen,spezielle Technologien verwenden und meist verschiedeneAnwendungsgebiete adressieren [5]. Die Motivation zurErstellung von Nanoservices resultiert dabei maßgeblich ausdem Wunsch, die bestehenden Vorteile der Microserviceszu verstarken. Kleine Module konnen leichter entwickeltwerden und daher zu einer Optimierung des Entwicklungs-prozess beitragen. Eine geeignete Umsetzung resultiert inkleineren Deploymenteinheiten und begunstigt die bedarfs-gerechte Skalierung sowie die Ersetzbarkeit der Module.

Umfang der Module: Obwohl gewisse Kompromissezugunsten der Modularisierung akzeptable sind, mussenbestimmte Eigenschaften, wie das unabhangige Deploymentstets beibehalten werden. Ein Nanoservice definiert daherweiterhin eine klare Verantwortlichkeit, welche ohne dieBeteiligung weiterer Dienste erfullt werden kann. Im Ge-gensatz zu Microservices ist die Verantwortlichkeit jedochfeingranularer und besteht meist nur aus wenigen Zeilen

13

Programmcode. Wahrend ein Microservice gewohnlich dieVerantwortlichkeit uber eine bestimmte Ressource definiert,umfasst die Verantwortlichkeit eines Nanoservice lediglicheine einzelne Operation, wie das Lesen eines Datensatzes[5]. Eine Schwierigkeit bei der Erstellung von Nanoser-vices ist die Identifikation geeigneter Partitionspunkte zurDefinition der Verantwortlichkeiten. Die Anforderung zurErfullung einer klaren Verantwortlichkeit wird maßgeblichdurch die Notwendigkeit atomare Funktionen zu definierenund globale Transaktionen zu vermeiden festgelegt.

Technologien: Ein wesentlicher Unterschied zwischenMicroservices und Nanoservices besteht in den verwendetenTechnologien. Wahrend der Schwerpunkt bei Microservicesauf einer moglichst hohen Isolation der Module liegt, fo-kussieren sich die Technologien der Nanoservices auf eineeffiziente Ausfuhrung um den Ressourcenverbrauch undInfrastrukturaufwand gering zu halten. Gangige Kompromis-se die hierbei eingegangen werden betreffen die Isolation,indem mehrere Nanoservices auf einer virtuellen Maschineund in einem einzelnen Prozess ausgefuhrt werden oderdie Technologiefreiheit, da Nanoservices eine gemeinsamePlattform oder Programmiersprache erzwingen [5].

Anwendungsgebiete: Eine weitere Unterscheidung derArchitekturmuster betrifft die zu adressierenden Anwen-dungsgebiete und die Verteilung der Systemkomponenten.Wahrend Microservices stets ein verteiltes System bildenund mittels Netzwerkverbindungen kommunizieren, werdenNanoservices meist zentral betrieben und durch lokale Kom-munikationsmechanismen koordiniert. Die Notwendigkeitzur Reduktion der verteilten Kommunikation resultiert daherin verschiedenen Anwendungsgebieten der Architekturmus-ter. Ein mogliches Anwendungsszenario fur Nanoservices istdie Nutzung in lokalen Bereichen, wie Desktopanwendun-gen, in denen Microservices aufgrund von Schwierigkeiteninnerhalb des Deployments kaum nutzbar sind [5].

B. Technologische AnforderungenNanoservices sind kein Widerspruch zu den beschriebenen

Einflussfaktoren fur die Große von Microservice, sondernversuchen durch Verwendung geeigneter Technologien dietechnischen Grenzen fur die minimale Große eines Mi-croservice weiter zu reduzieren [5]. Die Reduktion dertechnischen Grenzen und des notwendigen Infrastrukturauf-wands erfordert Kompromisse, welche jedoch zugunsten derModularisierung eingegangen werden.

Infrastrukturaufwand: Die feingranulare Unterteilungder Funktionalitat resultiert in einer erhohten Anzahl ei-genstandiger Module und erfordert daher eine effizien-te Ablaufumgebung, welche den anfallenden Infrastruktur-aufwand durch geeignete Mechanismen zur automatischenAusfuhrung, Uberwachung und Auslieferung der Nanoser-vices reduziert. Erfordert jeder Nanoservice einen eige-nen Application Server oder die manuelle Integration inMonitoringsysteme, rechtfertigen die Vorteile der starken

Modularisierung nicht den resultierenden Aufwand [5]. Umden Aufwand zu reduziert, sind haufig Einschrankungen derTechnologiefreiheit notwendig, in dem feste Mechanismenfur die Auslieferung oder ein einheitliches Logging fur dieUberwachung der Module vorgeschrieben werden.

Ressourcenverbrauch: Eine weitere Anforderung be-trifft die Reduktion des, auf die Vielzahl einzelner Ser-vices zuruckzufuhrenden, erhohten Ressourcenverbrauchs.Damit dieser reduziert werden kann, sind meist starkeEinschrankungen der Isolation notwendig. Ein Ansatz denbenotigten Ressourcenverbrauch zu reduzieren, stellt die Zu-sammenfassung mehrerer Services innerhalb eines einzelnenProzesses oder einer einzelnen Ausfuhrungsumgebung dar.Dies hat jedoch starke Auswirkungen auf die Robustheitder Komponenten, da sich einzelne Fehler auf samtlicheDienste innerhalb des Prozesses auswirken konnen odereinzelne Nanoservices derart massiv Ressourcen verbrau-chen, dass andere Dienste in ihrer Handlungsfahigkeit ein-geschrankt werden [5]. Die Verwendung einer gemeinsamenAusfuhrungsumgebung resultiert allerdings ebenfalls in ei-ner Einschrankung der Technologiefreiheit. Damit mehrereServices in einer Ausfuhrungsumgebung betrieben werdenkonnen, ist meist die Verwendung bestimmter Rahmenwerkeoder Programmiersprachen erforderlich.

Verteilte Kommunikation: Eine weitere technischeGrenze, die es zu reduzieren gilt, betrifft die aus der ver-teilten Kommunikation resultierenden Probleme. Steigt dieAnzahl der Module, ist unweigerlich eine erhohte Koordi-nation und Kommunikation zwischen den Modulen erfor-derlich. Neben der generellen Anforderung eine moglichsthohe Kohasion innerhalb der Nanoservices zu erreichenund Kommunikationen uber Netzwerkgrenzen zu vermeiden,muss eine geeignete Technologie effiziente und robusteKommunikationsmechanismen definieren. Ein gangiger An-satz hierfur ist die Verwendung programmiersprachenspezi-fischer Kommunikationsmechanismen und die daraus resul-tierende Festlegung einer einheitlichen Programmiersprache.Da auf die Zuverlassigkeit und Ubertragungsverzogerungvon Netzwerkverbindungen nur bedingt Einfluss genom-men werden kann, erfordert die Entwicklung von Nano-services ebenfalls eine Beschrankung der Lokalitat derAusfuhrungsumgebungen. Die aus den Netzwerkproblemenresultierenden Einschrankungen sind so weitreichend, dassEmpfehlungen zur vollstandigen Einstellung der Netzwerk-kommunikation zwischen Nanoservices vorliegen [5].

V. UNTERSUCHUNG DER TECHNOLOGIEN

Eine effiziente Umsetzung der Nanoservice-Architekturerfordert in erster Linie die Festlegung einer geeignetenTechnologie. Im weiteren Verlauf dieser Arbeit werdenausgewahlte Technologien und deren Besonderheiten vor-gestellt. Das nachstehende Kapitel beschaftigt sich mit derAuswahl dieser Technologien und das zur praktischen Un-tersuchung verwendete Anwendungsszenario.

14

A. Auswahl der TechnologienEine Problematik bei der Umsetzung von Nanoservices ist

die Identifikation geeigneter Technologien, die durch eineeffiziente Ausfuhrung den Ressourcenverbrauch reduzierenund gleichzeitig diverse Vorteile der Microservices erhal-ten [5]. Es existiert eine Vielzahl moglicher Ansatze ver-schiedener Technologiesparten, wie die Verwendung klas-sischer Komponentenmodelle und Frameworks, cloudba-sierter Losungen oder dem Einsatz funktionaler Program-miersprachen. Die vorliegende Arbeit betrachtet potenzielleMoglichkeiten und verwendet hierzu stellvertretend aus-gewahlte Vertreter der genannten Technologieklassen.

Serverlose Cloudservices: Aufgrund der Notwendig-keit zur Reduktion des Infrastrukturaufwands, konnen ser-verlose Clouservices, wie AWS Lambda ([8]) oder GoogleCloud Functions ([9]) ein vielversprechender Ansatz furdie Entwicklung von Nanoservices sein. Serverlose Cloud-services sind in der Lage, definierten Programmcode beimEintreten bestimmter Ereignisse auszufuhren und verwaltendie zugrunde liegenden Datenverarbeitungsressourcen ein-schließlich der Serverwartung, Kapazitatsbereitstellung undautomatischer Skalierung sowie Codeuberwachung dabeiautomatisch [8]. Da Google Cloud Functions zum Zeitpunktder Erstellung dieser Arbeit in einer geschlossenen Alpha-Version vorlag, wird AWS Lambda stellvertretend fur dieseTechnologiekategorie betrachtet. Dennoch scheint sich Goo-gle Cloud Function durch die leichtgewichtige, eventbasierteVerarbeitung zu einer vielversprechenden Technologie zuentwickeln [9].

Anwendungsframeworks: Bedingt durch die Popularitatdes Architekturmusters Microservices entstand eine Vielzahlvon auf die Entwicklung von Microservices optimierterFrameworks, wie Spring Boot [10]. Spring Boot bietetFunktionalitaten zur Verwaltung der Abhangigkeiten, Re-gistrierung und Discovery der Services sowie vordefinierteKonzepte zur Bereitstellung der Netzwerkkommunikation[11]. Daher gilt Spring Boot als eine geeignete Technologiezur Entwicklung herkommlicher Microservices. Aufgrunddes Fokus auf die verteilte Kommunikation und Isolationder Services, erfordert die Entwicklung von Nanoservices je-doch leichtgewichtigere Frameworks. Die vorliegende Arbeitbeleuchtet das Anwendungsframework Vert.x ([12]) als Re-prasentant dieser Technologiekategorie. Die Auswahl diesesVertreters ist insbesondere auf dessen Ereignisorientierungund performanten Ausfuhrung zuruckzufuhren.

Klassische Komponentenmodelle: Eine weitere Tech-nologieklasse umfasst die Verwendung klassischer Kompo-nentenmodelle, wie OSGi [13] oder Java EE und dessenEnterprise Beans. Ein Komponentenmodell legt einen Rah-men fur die Entwicklung und Ausfuhrung von Komponentenfest, definiert Komponsitionsmoglichkeiten und stellt eineInfrastruktur mit haufig benotigten Mechanismen, wie dieAuslieferung, Kommunikation und Versionierung der Kom-ponenten bereit [14]. Da Microservices im Grunde ebenfalls

ein Komponentenmodell darstellen, kann die Verwendungdieser Technologieklasse und deren bereitgestellte Infra-struktur zur Erstellung von Nanoservices verwendet werden.Fur die Untersuchung der Eignung dieses Ansatzes, findeteine nahere Betrachtung von OSGi statt.

Funktionale Programmiersprachen: Eine eher unkon-ventionelle aber vielversprechende Moglichkeit zur Umset-zung von Nanoservices ist die Verwendung funktionalerProgrammiersprachen wie Erlang ([15]) oder Scala ([16]).Eine Besonderheit dieser Sprachen ist die effiziente Imple-mentierung der Nebenlaufigkeit mittels Aktoren und derenLeichtgewichtigkeit. Im Gegensatz zu Ansatzen, wie derVerwendung klassischer Komponentenmodelle und derenbereitgestellten Infrastrukturen, spielt die Reduktion desRessourcenverbrauchs hierbei eine ubergeordnete Rolle. Furdie Untersuchung der Eignung zur Entwicklung von Nano-services wird Erlang betrachtet. Die Auswahl ist maßgeblichdurch die effiziente Ausfuhrung großer Mengen von Erlang-Prozessen innerhalb der Laufzeitumgebung begrundet [5].

B. AnwendungsszenarioZur Untersuchung der Eignung der betrachteten Technolo-

gien wurde jeweils ein konkretes Anwendungsszenario um-gesetzt. Das Szenario reprasentiert, wie in Abbildung 1 dar-gestellt, einen Onlineshop und umfasst den Bestellvorgang,die Verwaltung des Warenkorbs sowie eine Produktubersicht.Die Verbindung von Backend und Frontend erfolgt uberein API Gateway, welches REST-Aufrufe empfangt und dieKomposition der Nanoservices mittels technologiespezifi-scher Kommunikationsmechanismen ubernimmt.

Abbildung 1. Anwendungsszenario

Produktubersicht, Warenkorbverwaltung: Die Um-setzung dieser Funktionalitaten verfolgen ein gangigesMicroservice-Architekturmuster und dient zur Untersuchungfeingranularer Module ohne Anderungen der Architekturund Einschrankung der verteilten Kommunikation. Die Pro-duktubersicht besteht aus einem Nanoservice (Retrieve Pro-ducts), der die vorhandenen Produkte aus der Datenbank

15

liefert und dem Frontend zur Verfugung stellt. Die Wa-renkorbverwaltung umfasst die Nanoservices Add ShoppingItem und Retrieve Shopping Cart, welche das gewunschteProdukt dem Warenkorb hinzufugen bzw. dessen Inhalteaus der Datenbank liefern. Die Komposition der Servicesfindet innerhalb des API Gateways statt. Bei steigender Lastkonnen die Services in Abhangigkeit der zugrunde liegendenDatenbank beliebig verteilt und skaliert werden.

Bestellvorgang: Die Umsetzung des Bestellvorgangsverfolgt, wie in [5] empfohlen, einen Ansatz zur Reduktionder verteilten Kommunikation. Um dies zu ermoglichen,wurde eine zweite Kompositionsschicht (Order Gateway)eingefuhrt, welche die nachfolgenden Nanoservices mittelstechnologiespezifischer, lokaler Kommunikationsmechanis-men koordiniert. Die Verarbeitung einer Bestellung umfasstdie Validierung der Anfrage (Request Validator), die Per-sistierung der Bestellinformationen (Persist Order) und dieErstellung der Bestellbestatigung (Order Confirmation). Dadie Komponenten trotz ihrer feingranularen Aufteilung eineklare Verantwortlichkeit umfassen, erfordert die gewahlteModularisierung keine globalen Transaktionen. Die Verwen-dung einer zweiten Kompositionskomponente ermoglichtdaruber hinaus die Integration einer Lastverteilung undFehlererkennung. Der gewahlte Ansatz verdeutlich ebenfalls,wie einzelne Bestandteile einer bestehenden Anwendungdurch eine Nanoservice-Architektur ersetzt werden konnen.

C. BewertungskriterienDie Bewertung der Eignung der betrachteten Technologi-

en bezieht sich auf die im Folgenden genannten Kriterien.Isolation der Services: Die Isolation der Nanoser-

vices wird anhand der bereitgestellten Ablaufumgebung undAusfuhrung der Dienste beurteilt. Es wird insbesondereuntersucht, ob durch die getroffenen Maßnahmen zur Reduk-tion der technischen Grenzen, einzelne Fehler Auswirkungenauf weitere Services haben konnen.

Ressourcenverbrauch: Dieses Kriterium untersucht denGrad der Reduktion des notwendigen Ressourcenverbrauchsmittels einer effizienten Ausfuhrung der Module oder sons-tigen Maßnahmen, wie die Zusammenfassung mehrererDienste in gemeinsame Prozesse oder die Bereitstellungspezieller Ausfuhrungsumgebungen.

Technologiefreiheit: Hierbei wird untersucht, ob undwelche konkreten Einschrankungen der Technologiefreiheitzur Reduktion der technischen Grenzen erforderlich sind.

Verteilte Kommunikation: Umfasst die Betrachtung derbereitgestellten lokalen sowie verteilten Kommunikations-wege und erganzende Moglichkeiten, eine fehlertoleranteKommunikation zwischen den Diensten zu ermoglichen.

Infrastrukturaufwand: Es werden die Mechanismen zurVerwaltung der Infrastruktur sowie zur Unterstutzung desEntwicklungsprozesses, wie beispielsweise die Integrationin bestehende Monitoringsysteme und Automatisierung desDeploymentprozesses oder der Versionskontrolle betrachtet.

VI. AMAZON LAMBDA

Ein beliebter und vielversprechender Ansatz zur Ent-wicklung feingranularer Microservices ist die Verwendungserverloser Cloudfunktionen. Das folgende Kapitel beziehtsich auf Amazon Lambda und untersucht dessen Eignungund Besonderheiten bei der Entwicklung von Nanoservices.

A. Grundlegendes Konzept

Amazon Lambda ist ein serverloser Verarbeitungsdienstdes Amazon Okosystems der Programmcode beim Eintretenbestimmter Ereignisse ausfuhrt und automatisch die zu-grunde liegenden Verarbeitungsressourcen verwaltet [8]. Derausgefuhrte Programmcode wird als Lambda-Funktion be-zeichnet, die mittels JavaScript, Python oder Java Implemen-tierungen eine bestimmte Funktionalitat definiert. Aufgrundder automatischen Verwaltung der Infrastruktur definiert derEntwickler lediglich die Funktionalitat und die auslosendenEreignisse der Funktionen. Wahrend die Ereignisse ur-sprunglich auf die verschiedenen Amazon Webservices be-schrankt waren, konnen diese mittlerweile unter Nutzungdes API-Gateways durch REST-Aufrufe ausgelost werden[5]. Dies ermoglicht die Erstellung feingranularer Micro-services ohne Abhangigkeit der weiteren Amazon Dienste.Unter Nutzung dieser Technologie wird ein Microserviceals eine einzelne Lambda-Funktion reprasentiert, welcheunter Verwendung einer definierten Datenreprasentation wieJSON kommunizieren und ihre Ergebnisse den weiteren Sys-temkomponenten bereitstellen konnen. Beim Aufruf einessolchen Nanoservices wird die korrespondierende Lambda-Funktion automatisch innerhalb der Amazon Infrastrukturgestartet und ausgefuhrt. Die Komposition der Dienste fin-det dabei lediglich uber das Absenden der entsprechen-den REST-Aufrufe statt. Das Deployment der Lambda-Funktionen erfolgt abhangig von der verwendeten Program-miersprache durch ZIP- oder JAR-Dateien, die mittels derAWS Management Console oder per API Aufruf ausge-liefert werden [5]. Definiert eine Lambda-Funktion externeAbhangigkeiten, konnen die hierfur benotigten Bibliothekenebenfalls in den Deploymentpaketen enthalten sein. Eineerhebliche Effizienzsteigung des Deploymentprozesses wirdunter Verwendung erganzender Werkzeuge, wie beispiels-weise Apex ([17]) erreicht. Apex ermoglicht das Deploymentmehrerer Lambda-Funktionen mittels eines einzelnen Auf-rufs und stellt gleichzeitig Moglichkeiten zur Versionskon-trolle und Monitoring der Funktionen bereit [17].

Die Eignung zur Erstellung von Nanoservices resul-tiert insbesondere aus der Leichtgewichtigkeit der Lambda-Funktionen, der performanten Ausfuhrung in der AmazonInfrastruktur und den feingranularen Deploymenteinheiten,welche in ihrer geringsten Auspragung eine einzelne Funk-tion umfassen [5]. Ebenfalls begunstigt wird dies durch dieautomatische Verwaltung der Infrastruktur und des dadurchstark reduzierten Infrastrukturaufwand.

16

B. Besonderheiten der UmsetzungDas in Kapitel V beschriebene Anwendungsszenario

konnte unter Verwendung von Amazon Lambda mit ge-ringen Anpassungen umgesetzt werden. Die Nanoserviceswurden vollstandig als Lambda-Funktionen abgebildet undmittels des von Amazon bereitgestellten AWS API-Gatewayinnerhalb des Webinterfaces koordiniert. Aufgrund der au-tomatischen Lastverteilung, ausschließlich verteilten Kom-munikation und integrierten Fehlertoleranz, bestand keineNotwendigkeit zur Verwendung einer zweiten Kompositi-onsschicht (Order Gateway Service). Die Nanoservices desBestellvorgangs losen mittels AWS Events den nachstenVerarbeitungsschritt eigenstandig aus. Hierfur bietet eineLambda-Funktion die Moglichkeit, weitere Funktionen auf-zurufen und so eine Verarbeitungskette zu bilden. Es istjedoch zu beachten, dass die definierten Timeouts derFunktionen bei einer solchen sequenziellen Verarbeitungnicht uberschritten werden. Da die Verarbeitungsschritte zurErfullung ihrer Aufgabe keinen Zustand halten, konnen diesebeliebig skaliert und im Fehlerfall erneut aufgerufen werden.Eine besondere Starke zeigte sich bei der einfachen Integrati-on weiterer Amazon Dienste, wie DynamoDB. Dieser Dienstwurde zur Realisierung der Persistenzschicht verwendet.Abbildung 2 zeigt die angepasste Architektur.

Abbildung 2. Anwendungsszenario mit Amazon Lambda

C. Bewertung der TechnologieIsolation der Services: Die Infrastruktur stellt eine

vollstandige Isolation der Services sicher [5]. Es ist da-her ausgeschlossen, dass Fehler einer einzelnen Lambda-Funktion Auswirkungen auf andere Systemkomponenten ha-ben konnen. Daruber hinaus verfugen Lambda-Funktionen,bedingt durch die hochverfugbare Amazon Infrastruktur,uber eine integrierte Fehlertoleranz [8].

Ressourcenverbrauch: Die Nutzung der Ressourcen istaufgrund der automatisch verwalteten Infrastruktur fur denNutzer vollstandig transparent. Da das Kostenmodell keinen

Bezug auf die verwendeten Ressourcen hat, sondern aufBasis der Haufigkeit des Aufrufs einer Funktion entsteht,hat der Nutzer keinen Einfluss auf die aufgewendeten Hard-wareressourcen und kann sich stets auf eine performanteAusfuhrung seiner Dienste verlassen [6].

Technologiefreiheit: Die Verwendung von AmazonLambda schrankt die Technologiefreiheit ein, da diemoglichen Programmiersprachen zum Zeitpunkt der Verfas-sung dieser Arbeit auf Java, JavaScript und Python begrenztsind [5]. Die Verwendung verschiedener Bibliotheken isthingegen ohne Einschrankung moglich.

Verteilte Kommunikation: Bedingt durch den cloudba-sierten Ansatz ist keine lokale Kommunikation moglich.Die Verwendung dieser Technologie ist daher fur lokaleAnwendungen nicht geeignet und widerspricht der in [5]genannten Anforderung zur Vermeidung verteilter Kommu-nikation in Nanoservice-Architekturen. Damit dennoch einegewisse Lokalitat erreicht werden kann, empfiehlt es sich,Teile der Anwendung, wie in Abbildung 2 gezeigt, innerhalbder AWS-Infrastruktur zu koordinieren.

Infrastrukturaufwand: Neben der automatisch ver-walteten Infrastruktur bietet Amazon Lambda ebenfallsMoglichkeiten zur signifikanten Reduktion des aus dem Ent-wicklungsprozess resultierenden Aufwands. Da alle AmazonServices mittels einer API angesprochen werden konnen,ist es moglich, das Deployment und Monitoring in eigeneInfrastrukturen zu integrieren und dadurch zu automatisieren[5]. Daruber hinaus werden Lambda-Funktionen automa-tisch in Cloud Watch eingebunden, wobei Metriken erhoben,Benachrichtigungen ubermittelt und somit samtliche Diensteuberwacht werden konnen [5].

Sonstige Besonderheiten: Ein besonderer Vorteil die-ser Technologie resultiert aus der einfachen Integrationder Dienste des Amazon Okosystems. Dies ermoglicht dieEntwicklung kompletter Anwendung innerhalb der Ama-zon Infrastruktur. Zu beachten gilt jedoch, dass Lambda-Funktionen potenziell bei jedem Aufruf neu gestartet wer-den und daher zustandslos sind [5]. Dies ermoglicht eine,entsprechend der Haufigkeit der eingehenden Ereignisse,bedarfsgerechte und automatische Skalierung [8].

D. FazitAmazon Lambda ermoglicht die Entwicklung besonders

kleiner Nanoservices, da der Overhead fur einen einzelnenService gering ist, die Infrastruktur vollstandig abstrahiertwird und außerst feingranulare Deployment-Einheiten de-finert werden konnen [5]. Nach einer gewissen Einarbei-tungszeit, bedingt durch die Vielzahl AWS spezifischerKonfigurationen, stellt Amazon Lambda insbesondere fur dieEntwicklung webbasierter Anwendungen eine vielverspre-chende Technologie dar. Jedoch ist die Einfuhrung dieserTechnologie eine weitreichende Entscheidung, welche auf-grund der starken Abhangigkeit zu Amazon nur mit hohemAufwand ruckgangig gemacht werden kann.

17

VII. VERT.XEin weiterer gangiger Ansatz zur Entwicklung feingranu-

larer Microservices ist die Verwendung spezieller Anwen-dungsframeworks. Das folgende Kapitel beschaftigt sich mitVert.x und untersucht dessen Eignung und Besonderheitenbei der Entwicklung von Nanoservices.

A. Grundlegendes KonzeptVert.x ist ein reaktives, modulares und nachrichtenorien-

tiertes Anwendungsframework, mit dem sich besonders per-formante und leichtgewichtige Microservice-Architekturen,aber auch klassische Anwendungen umsetzen lassen [18].Das grundlegende Konzept von Vert.x besteht in der Auf-teilung der Anwendung in sogenannte Verticles. Verticlesstellen Anwendungskomponenten dar, welche in der JVMausgefuhrt und mittels Nachrichten koordiniert werden. DieKommunikation findet dabei ausschließlich asynchron an-hand von Events statt, wodurch eine vollstandig lose Kopp-lung erreicht wird [5]. Hierfur bietet Vert.x eine Event Loop,welche die Events zur Verarbeitung den entsprechendenVerticles bereitstellen. Die Event Loop besteht aus mehrerenThreads und ermoglicht so, dass Events mehrerer Verbindun-gen parallel bearbeitet werden konnen [5]. Daruber hinausist es moglich, die Event Loop uber mehrere Knoten zukoordinieren und somit die Verarbeitung uber ein Netzwerkzu verteilen. Vert.x bietet zahlreiche Funktionalitaten umeine verteilte Ausfuhrung zu erleichtern. So lassen sich mitgeringem Konfigurationsaufwand Hochverfugbarkeitsclustererstellen, welche unterbrochene Dienste automatisch an ei-nem weiteren Standort starten und beliebig skalieren [19].

In einer Nanoservice-Architektur wird ein Service alseinzelnes Verticle abgebildet. Die feingranulare Aufteilungwird dabei insbesondere aufgrund des reduzierten Res-sourcenverbrauchs ermoglicht, da die Verticles innerhalbeiner JVM ausgefuhrt werden und somit keine Prozess-wechsel erfordern. Die Laufzeitumgebung erleichtert zudemdie Umsetzung zahlreicher positiver Eigenschaften einerMicroservice-Architektur, wie die einfache Ersetzbarkeit undbedarfsgerechte Skalierung von Diensten. Dies begunstigtdie Umsetzung von Nanoservices, da die Eigenschaften mit-tels der bereitgestellten Funktionen ohne großen Aufwandfur eine Vielzahl von Deploymentpaketen erfolgen kann. Sobietet Vert.x die Moglichkeit, die Last zwischen mehrerenInstanzen eines Services automatisch zu verteilen. Hierfurmuss, wahrend des Deployments, lediglich die gewunschteAnzahl der Instanzen eines Dienstes angegeben werden.

Die Verticles konnen zur Laufzeit unabhangig ausgelie-fert und entfernt werden. Das Deployment ist dabei unterAngabe der entsprechenden Deploymentpakete uber dasKommandozeilenwerkzeug vertx oder entsprechender API-Aufrufe moglich. Ein Deploymentpaket enthalt, abhangigder verwendeten Programmiersprache, lediglich die kom-pilierten Quelldateien und falls erwunscht, die erforderli-chen Abhangigkeiten. Ein gangigerer Ansatz bei der Ent-

wicklung von Nanoservices ist jedoch die Verwaltung derAbhangigkeiten innerhalb der Ablaufumgebung [5]. Diesreduziert, auf Kosten der Technologiefreiheit, die Großeder Deploymentpakete. Eine Besonderheit ist die Erkennunggeanderter Deploymentpakete, welche automatisch neu aus-geliefert werden [19]. Das Deployment einer neuen Versionumfasst deshalb lediglich die Bereitstellung der entsprechen-den Pakete und kann vollstandig automatisiert werden.

B. Besonderheiten der UmsetzungDas in Kapitel V beschriebene Anwendungsszenario wur-

de ebenfalls unter Nutzung von Vert.x umgesetzt. Die aufge-zeigte Architektur konnte dabei vollstandig beibehalten wer-den. Die Nanoservices wurden als Verticles abgebildet undmittels des Event Bus koordiniert. Der Event Bus ermoglichtnach einer initialen Konfiguration eine vollstandige Trans-parenz zwischen lokalen und verteilen Aufrufen der EventLoops. Dies ermoglicht eine einheitliche Kommunikationzwischen lokalen und verteilten Nanoservices. Fur die Er-stellung des API Gateway wurde auf die Erweiterung Vert.x-Web ([20]) zuruckgegriffen, welche zahlreiche Funktiona-litaten fur den Umgang mit REST-Aufrufen bereitstellt. Wirdein REST-Endpunkt aufgerufen, erstellt das API Gateway einentsprechendes Event, welches von dem korrespondierendenNanoservice konsumiert wird. Eine Besonderheit ist dieEinfuhrung und Integration eines zweiten Event Bus fur denBestellvorgang. Dies ermoglicht eine vollstandige Isolationder Funktionalitat und gestattet eine ausschließlich lokaleKommunikation der in den Bestellvorgang involvierten Na-noservices. Abbildung 3 veranschaulicht die Umsetzung.

Abbildung 3. Anwendungsszenario mit Amazon Lambda

C. Bewertung der TechnologieIsolation der Services: Da die Nanoservices unter Ver-

wendung von Vert.x als Verticles abgebildet und diese inner-halb einer JVM ausgefuhrt werden, besteht keine Isolationzwischen den Diensten. Ein Absturz der JVM, Speicherlecks

18

oder das Blockieren der Event Loop beeinflussen samtlicheVerticles die innerhalb einer JVM ausgefuhrt werden [5].

Ressourcenverbrauch: Vert.x reduziert den Ressourcen-verbrauch erheblich, in dem mehrere Services innerhalb ei-ner JVM und somit innerhalb eines einzelnen Prozesses aus-gefuhrt werden. Ein einzelnes Verticle ist daher wesentlichleichtgewichtiger als ein Microservice in herkommlichenTechnologien. Weiter reduziert wird der Ressourcenver-brauch durch den reaktiven Ansatz. Ein Verticel wird ledig-lich aktiv, wenn eine entsprechende Nachricht vorliegt oderderen Callbacks aufgerufen werden [5].

Technologiefreiheit: Eine besondere Starke von Vert.xliegt in der Technologiefreiheit. Obwohl die Verticles in-nerhalb einer JVM ausgefuhrt werden, unterstutzt das Fra-mework viele verschiedene Sprachen, wie Scala, Ruby undJavascript. Um dies zu ermoglichen, bietet Vert.x eine Ab-straktionsschicht, mit der Basisfunktionalitaten so adaptiertwerden, dass diese wie eine native Bibliothek fur die jeweili-ge Programmiersprache wirken [5]. Diese Verticles konnen,bedingt durch die abstrahierten Kommunikationsmechanis-men, ohne Einschrankungen Nachrichten austauschen.

Verteilte Kommunikation: Die Kommunikation zwi-schen Verticles findet hauptsachlich mittels Events statt. DerEvent Bus abstrahiert dabei die Unterscheidung zwischenlokaler und verteilter Kommunikation. Neben dem verteiltenNachrichtenaustausch ist es deshalb moglich, Verticels derselben JVM verlasslich mittels lokaler Kommunikations-mechanismen anzusprechen. Vert.x unterstutzt auch weitereNachrichtensysteme und kann mittels HTTP und RESTkommunizieren [5]. Vert.x bietet daher eine flexible, pro-blemadaquate Festlegung der Kommunikation und eignetsich sowohl fur lokale Anwendungen, als auch fur verteilteArchitekturen.

Infrastrukturaufwand: Vert.x bietet eine Vielzahl er-leichternder Funktionalitaten zur Reduktion des Infrastruk-turaufwands. Insbesondere das Deployment der Dienstekann nach einer Integration in geeignete Deploymentsys-teme vollstandig automatisiert werden. Zur Uberwachungder Verticles stehen verschiedene Metriken bereit, welchemittels API-Aufrufen in bestehende Monitoringsysteme ein-gebunden werden konnen [19]. Vert.x erfordert jedoch einenerhohten initialen Konfigurationsaufwand fur den Betriebverteilter Architekturen.

D. FazitVert.x stellt, aufgrund des reaktiven und nachrichtenori-

entierten Ansatz, eine vielversprechende Technologie dar,welche bedingt durch die lokale Kommunikation, ebenfallszur Entwicklung klassischer Desktopanwendungen unterNutzung einer Nanoservice-Architektur verwendet werdenkann. Es gilt allerdings die fehlende Isolation zu beachten,welche zugunsten des Ressourcenverbrauchs eingegangenwurde. Ist eine hohe Isolation der Services erforderlich,mussen weitere Technologien in Betracht gezogen werden.

VIII. OSGI

Der schematische Aufbau einer Microservice-Architekturentspricht dem grundlegenden Gedanken eines Komponen-tenmodells. Das folgende Kapitel betrachtet daher stell-vertretend die OSGi-Plattform und dessen Eignung undBesonderheiten zur Entwicklung von Nanoservices.

A. Grundlegendes KonzetDie Open Services Gateway Initiative (OSGi) ist ein

Komponentenmodell und verfolgt das Prinzip der Modula-risierung von Anwendungssystemen. Hierbei wird von derVerwendung applikationsbeinhaltender Bundles, innerhalbeiner Plug-in-Infrastruktur gebrauch gemacht. Bundles sindArchive, die neben kompilierten Java Klassen auch HTMLDokumente, Icons und weitere applikationsspezifische Da-teien enthalten konnen. Die Modularisierungseigenschaftenwerden dabei mittels einer Manifest-Datei definiert. DieAusfuhrung einer OSGi-Anwendung besteht aus der Kom-position mehrerer Bundles und erfolgt in einer speziellenAusfuhrungsumgebung, welche eine Administrationsschnitt-stelle anbietet, mittels welcher die einzelnen Bundles verwal-tet werden konnen. Bei der Installation eines Bundles wirddessen Konfiguration analysiert und zur weiteren Nutzungdurch die Laufzeitumgebung bereitgestellt. Bundles sindin der Lage, implementierte Module fur andere Bundleszuganglich zu machen. Dies geschieht durch das Propagiereneines Export-Package Eintrags innerhalb ihrer Manifest-Datei. Fur die Verwendung eines registrierten Moduls, mussdieses ebenfalls durch einen Import-Package Parameter inder Konfigurationsdatei des nutzenden Bundles festgehaltenwerden. Die Nutzung eines fremden Services innerhalbeines Bundles erfolgt durch die Verwendung von Remote-Interfaces. Die Implementierung eines Interfaces kann voneinem Bundle, innerhalb des Anwendungscodes des Acti-vator, als Service definiert werden. Mittels eines Eintragsin der zentralen Service Registry einer OSGi-Plattform,wird der Service allen registrierten Bundles offeriert. Dabeibindet ein aufrufendes Bundle das Service Objekt an einexportiertes Interface, dessen Funktionsaufrufe innerhalb derService-Implementierung ausgefuhrt werden [13].

B. Verteiltes OSGiTrotz der Empfehlung zur Reduktion der verteilten Kom-

munikation in Nanoservice-Architekturen ist diese meistnicht vollstandig vermeidbar. Eine geeignete Technologiesollte daher dennoch uber die Moglichkeit zur Verteilungder Systemkomponenten verfugen. In OSGi wird dies durchdie Verwendung erganzender Implementierungen erreicht.Sobald alle verteilten OSGi-Instanzen aktiv und miteinanderverbunden sind, konnen die einzelnen Services von jedemKnoten im Netzwerk genutzt werden. Die Verteilung spieltfur den Programmierer eine untergeordnete Rolle, da jeg-liche verteilte Kommunikation transparent stattfindet undes keine programmatische Unterscheidung zwischen lokalen

19

und entfernten Services gibt. Der dabei gewahlte adaptiveAnsatz beruht auf symmetrischen Beziehungen zwischenModulen, die keinen Zwang fur Rollen wie Client oderServer vorgeben [5]. Der Hauptunterschied zur Architek-tur klassischer OSGi-Systeme ist der verteilte DiscoveryService sowie ein platforminterner Distribution Provider.Im Gegensatz zu der Service Registry ist die DiscoveryService-Komponente eine zentrale Anlaufstelle fur verteilteBundles, die zum Erfragen und Registrieren implementier-ter Bundles genutzt wird. Der Distribution Provider hatKenntnis uber die Lokalitat des Discovery Service und stellteine transparente Kompositionsschicht zwischen verteiltenServices dar. Mochte das Client Bundle einer OSGi Platformeinen entfernten Service nutzen, wird diese Anfrage anden Discovery Service gestellt. Existiert der erfragte Dienstinnerhalb der OSGi-Foderation, findet ein entfernter Funk-tionsaufruf statt, wobei eine dynamische Proxy Generierungzur Bindungszeit durch das Interface des Service geschieht.Uber diesen Client Proxy kann im Anschluss transparentauf die Implementierung zugegriffen werden. Im Fall vonnetzwerkspezifischen Fehlern behandelt das verteilte OSGidiese wie eine lokale Modulinteraktion [21], [22].

C. Besonderheiten der Umsetzung

Die Umsetzung des Anwendungsbeispiels konnte un-ter Nutzung von OSGi grundlegend wie in Abbildung 1umgesetzt werden. Prinzipiell wird jeder Nanoservice in

Abbildung 4. OSGi-Service Modell

ein Schnittstellen-Bundle und Implementierungs-Bundle se-pariert. Durch Exportieren des Interface-Bundle und demImport der Schnittstellen in die tatsachliche Implementie-rung ist fremden Bundles eine dynamische Moglichkeitdes Object-Bindings gegeben. Bei einer neuen Version desImplementierungs-Bundles eines Service, kann auf dieseWeise ein zur Laufzeit unabhangiges Deployment stattfin-den. Wird eine Schnittstelle neu definiert, hat ein nutzendesBundle ohne Neustart keine Moglichkeit ein Binding derneuen Version durchzufuhren. In der Realitat unterzieht sichmeist die gesamte OSGi-Anwendung einem Neustart [5].

D. Bewertung der Technologie

Isolation der Services: Bedingt durch die Ausfuhrungder Bundles innerhalb einer JVM ist eine Isolation derServices nicht gegeben. Terminiert ein Bundleaufruf in nicht

vorhergesehener Weise, kann es unter Umstanden zum Aus-fall der OSGi-Platform kommen. Ein solcher Fall kann durchFehlverhalten innerhalb der Bundles verursachte Speicher-lecks oder massive CPU-Belastung ausgelost werden.

Ressourcenverbrauch: Die Umsetzung von Nanoser-vices in Form von Plug-ins spricht in erster Linie furdynamische Applikationen und einen damit einhergehenden,niedrigen Ressourcenverbrauch. Da alle Services innerhalbeiner JVM angesiedelt sind, werden diese durch das Be-triebssystem als einzelner Prozess behandelt, wobei dieZuweisung von Aktivitaten durch die JVM realisiert ist.Daher ist der Ressourcenverbrauch von OSGi Applikationim Allgemeinen als gering einzustufen.

Technologiefreiheit: Die Technologiefreiheit unterliegtbei der Verwendung von OSGi starken Einschrankungen, dadie Implementierung der Bundles strikt auf die Programmier-sprache Java beschrankt ist. Aufgrund des umfangreichenAuflosungsmechanismus ist die Verwendung bundlespezifi-scher Bibliotheken jedoch uneingeschrankt moglich.

Verteilte Kommunikation: Alle bereitgestellten Servicesdes OSGi-Frameworks werden in Form einer Remote Me-thod Invocation ausgefuhrt. Diese netzwerkbasierte Heran-gehensweise widerspricht zunachst dem Prinzip der lokalenKommunikation. Solange jedoch nicht Distributed-OSGi zurUmsetzung verwendet wurde, werden die Funktionsaufrufedennoch lokal und daher robust verarbeitet. Unter Nutzungder beschriebenen Erweiterungen verfugt OSGi sowohl uberlokale als auch verteilte Kommunikationsmoglichkeiten.

Infrastrukturaufwand: OSGi bietet die Moglichkeit desDeployment einzelner Bundles zur Laufzeit. Die Entkopp-lung von Schnittstellen und deren Implementationen fuhrtdennoch zwangslaufig zu Abhangigkeiten. Die Kausalitatdes Deployments einer neuen Version der Schnittstelle kannweder fur das umsetzende Bundle abgeschwacht, noch in-nerhalb der Implementierung ausgenutzt werden. OSGi bie-tet, durch die Nutzung verschiedener Management-Bundlesund erganzender Uberwachungswerkzeuge der jeweiligenImplementierungen, umfassende Moglichkeiten den Sys-temzustand zu uberwachen. Eine Integration in bestehendeMonitoring- und Deploymentsysteme ist ebenfalls moglich.

E. FazitDie OSGi Plattform gewann in den letzten Jahren nicht

zuletzt durch verschiedene Umsetzungen im Kontext Inter-net of Things und der wachsenden Begeisterung von modula-risierten Architekturen in Verbindung mit Cloud Computing-Technologien an Bedeutung. Die Eignung dieses Frame-works fur Nanoservices muss auf Grund der einzugehendenKompromisse in Bezug auf die Isolation, Technologiefreiheitund des Infrastrukturaufwands jedoch abhangig des An-wendungsfalls abgewogen werden. Entstehen, bedingt durchdas Anwendungsszenario, keine konkreten Vorteile aus derNutzung dieser Technologe, empfiehlt sich die Verwendungder beschriebenen Alternativen.

20

IX. ERLANG

Das folgende Kapitel beschreibt die Umsetzung und tech-nologischen Besonderheiten einer Nanoservice-Architekturmittels der funktionalen Programmiersprache Erlang. Erlangist eine von Ericsson Computer Science Laboratory entwi-ckelte funktionale Programmiersprache, deren Grundgedan-ke auf Stabilitat, Ausfallsicherheit und der Gewahrleistungmassiver Parallelitat beruht. Die Verwendung angepassterLaufzeitumgebungen zur Ausfuhrung der Applikationen isteine verbreitete Herangehensweise bei der Generalisierungder Hochsprachen in unterschiedlichen Systemarchitekturen.Daher bewegen sich auch diese Anwendungen innerhalbeiner Bjorn Gustavsson/ Bogumil Hausman Erlang AbstractMachine (BEAM). Hierbei wurde auf das Konzept leichtge-wichtiger BEAM-Prozesse zuruckgegriffen, deren Lebens-zyklus und Arbeitsweise strikt voneinander isoliert sind.

A. Grundlegende StrukturGrundlegend besteht ein Erlang Projekt aus verschie-

denen Modulen, die dem Event-Loop Muster folgen undunter Verwendung des Aktorenmodells kommunizieren. Dieasynchrone Kommunikation besteht aus dem Senden vonNachrichten an die Mailbox eines Prozesses oder um esmit den Worten von [23] auszudrucken: “In a nutshell,if you were an actor in Erlang’s world, you would bea lonely person, sitting in a dark room with no window,waiting by your mailbox to get amessage.”. Unter diesenUmstanden konnen Millionen Prozesse parallel ausgefuhrtwerden und in Abhangigkeit voneinander Interagieren. Ein-zelne Zwischenprozesse einer Ereigniskette von Nachrichtenfehlertollerant zu gestalten ist nicht nur Aufgabe des An-wendungscodes einzelner Prozesse. Vielmehr stehen dieseleichtgewichtigen Prozesse unter der Aufsicht von Supervi-sor Komponenten, die bei auftretenden Problemen einzelnerBEAM Prozesse fur deren Neustart verantwortlich sind [24].Innerhalb der Erlang-Welt konnen alle der BEAM bekanntenModule durch direkte Interaktion mit der Konsole oderdurch den Anwendungscode dynamisch in den Applikations-lebenszyklus einbezogen werden. In beiden Fallen bestehtder Ruckgabewert der spawn/3 Funktion aus einem Tupel,welches die Erlang Prozess-ID des gestarteten Moduls bein-haltet. Diese Erlang PID wird des Weiteren fur die asyn-chrone Kommunikation einzelner Module verwendet. Dabeikonnen sowohl Variablen als auch statische Nachrichten inder Form von PID ! [message] versendet werden. Daruberhinaus bietet Erlang die Moglichkeit der Integration von OS-Prozessen. Hierbei werden die in beliebiger Programmier-sprache geschriebenen, und bereits durch den zugehorigenCompiler ubersetzten, Programme durch Erlang gestartetund in die Supervisor-Hierarchie eingebunden [5].

B. Generierung und Implementierung des ServicesFur die Komponente des Gateway Service wurde der

leichtgewichtige REST Server Cowboy[25] verwendet, der

auf der Open Telecom Platform (OTP) aufbaut. Ahnlichwie bei gelaufigen Buildsystemen oder dem Bereich dermodellgetriebenen Softwareentwicklung, gibt erlang.mk dieMoglichkeit, das Grundgerust einer Anwendung zu generie-ren. Das aus erlang.mk resultierende Makefile ist mit allenfur das Projekt benotigten Abhangigkeiten zu bestucken.Alle fur das Projekt angegebenen Bibliotheken werdendem Laufzeitsystem, ohne Weiteres zutun, durch einmali-ges Herunterladen der zugehorigen Module und deren furden Entwickler transparente Integration in das Projekt, zurVerfugung gestellt. Des Weiteren besteht die Moglichkeitvon Deklarationen der Quellen einzelner Abhangigkeiten,was dem Entwickler zusatzliche Freiheit bei der Verwendungprojektinterner Git Repositories und deren unterschiedlichenVersionen sowie Branches bietet. Die aus dem Makefile re-sultierende Grundstruktur der Erlang Anwendung beinhaltetvorstrukturierte app und sup Module, die im Folgendenmit anwendungsspezifischer Logik anzureichern sind. Das

app Modul bildet hierbei den Event Manager der An-wendung, in dem eingehende REST-Aufrufe auf einzelneCowboy Handler abzubilden sind. Mit erlank.mk konnenauch bereitgestellte Templates angegebener Abhangigkeitenbenutzt werden, was ebenfalls auf den cowboy http Handlerzutrifft. Diese Art von Modulen reprasentiert die Kom-positionsschicht aus Abbildung 1 und ist mit dem cow-boy http handler Verhalten betraut, dass eine Aktion aufeingehende Anfragen implementiert. Mit einer weiteren An-wendung des Makefiles wird das Projekt in ein Releasekompiliert, welches das System starten kann und ebenfallsals Grundlage des Code Replacement zur Laufzeit benutztwird. Alle modifizierten Module werden innerhalb diesesPakets separat festgehalten und im Zielsystem, nach derUberprufung auf syntaktische Richtigkeit, installiert. Zykli-sche Abhangigkeiten zu anderen Modulen erschweren dasDeployment zur Laufzeit erheblich und implizieren meistden Neustart der gesamten Anwendung [23].

C. Besonderheiten des Szenarios

Das Anwendungsszenario lasst sich direkt durch Erlangumsetzen und durch technologiespezifische Vorzuge erwei-tern. So ist, wie in Abbildung 5 dargestellt, die CowboyAPI Gateway-Komponente fur die initiale Erstellung deranderen Nanoservices verantwortlich. Dieses Modul ist furdas Entgegennehmen der REST-Aufrufe zustandig und mussdaher jederzeit verfugbar sein. Alle direkt nachfolgendenModule ubernehmen das Verhalten von Cowboy Handler-Komponenten und werden bei zutreffendem REST-Aufrufdynamisch als eigener Prozess gestartet. Bis zum Eintreffender Validierung des dynamisch gestarteten Prozesses befin-det sich der jeweilige ’Vaterprozess’ im Leerlauf.

Durch diese Vorgehensweise werden Ressourcen einerErlang-Node zusatzlich entlastet, da beispielsweise der furdie Persistierung einer Bestellung verantwortliche Prozess,bei einer durch den Request Validator erkannten Verletzung

21

Abbildung 5. Nanoservice Architektur des Anwendungszenarios in Erlang

des Jugendschutzes, nicht erstellt wird. Die Kommunika-tion der Module findet ausschließlich auf lokalem Wegeunter Verwendung des Aktorenmodells statt und entlastetzusatzlich den Ressourcenverbrauch des Gesamtsystems,was durch die asynchrone Verarbeitung und der daraus re-sultierenden nicht blockierenden Prozesse zu begrunden ist.Neben der Verwendung der Standardbibliothek von Erlangkonnte beispielsweise die Ruckgabe einer JSON-Nachrichtbequem durch einen Funktionsaufruf, von in dem Makefileangegebenen Abhangigkeiten, umgesetzt werden.

D. Bewertung der Technologie

Isolation der Services: Durch die Kombination desSupervisor Prozesses mit dem asynchronen Nachrichten-versand einzelner Prozesse an die Mailbox anderer, kannein ’let it crash’ Konzept umgesetzt werden. Grundlegendkonnen innerhalb eines Erlang-Systems mehrere MillionenProzesse existieren und bei fehlerhaftem Verhalten durcheinen Supervisor neu konfiguriert und gestartet werden.Bei sauberer Implementierung und Definition von durchSupervisor uberwachten Prozessbaumen sind Szenarien, beidenen der komplette Service beeintrachtigt wird, vermeidbar.Daher ist trotz der gemeinsamen Ausfuhrung innerhalb einesProzesses eine vollstandige Isolation gegeben [5].

Ressourcenverbrauch: Eine Besonderheit von Erlangist der stark reduzierte Ressourcenverbrauch einzelner Er-lang Prozesse welche allgemein als außerst leichtgewichtigeApplikationen betrachtetet werden. Da jeweils nur ein ein-zelner OS-Prozess fur einen Erlang Knoten verantwortlichist, wirkt sich das BEAM-interne Scheduling positiv aufdie Gesamtlaufzeit parallel arbeitender Systeme aus. Auchdie Erstellung einzelner Erlang-Prozesse On-Demand ist

betriebssystemunabhangig, bewegt sich im Mikrosekunden-bereich und fordert bei entsprechender Implementierung diedynamische Reduktion benotigter Ressourcen zur Laufzeit.

Technologiefreiheit: Durch den Zugriff auf das Be-triebssystemterminal oder einen nativen Aufruf innerhalbvon Erlang zur Ausfuhrung fremder Anwendungen, istdie Moglichkeit eines heterogenen Systems, bei dem un-terschiedliche Teile unter die Aufsicht eines Supervisorsgestellt und durch diesen verwaltet werden, gegeben. DerNachrichtenaustausch von heterogenen Applikationen ist imGegensatz zu Vert.x jedoch nur durch eigens zu definierendeKommunikationskanale, wie beispielsweise der Verwendungvon Message Queues umzusetzen [5].

Verteilte Kommunikation: Die Umsetzung der Kommu-nikation durch das Aktorenmodell kann sowohl lokal alsauch entfernt stattfinden. Das Zustellen von Nachrichtengeschieht in den meisten Fallen auf Ebene der Erlang-Prozesse, jedoch ist die Verwendung externer Anwendungenals Nachrichtenkanal nicht ausgeschlossen. Des Weiterenbietet Erlang eine native Moglichkeit zur horizontalen Ska-lierung der Anwendung. Durch die Verknupfung einzelnerErlang Nodes bzw. Beam-Instanzen wird eine transparenteKommunikation von verteilten Services bereitgestellt, wobeieinzelne Prozesse mit einem Namen versehen werden. DerNachrichtenaustausch einzelner Erlang Module uber dasNetzwerk kann durch Kombination von Node- und Prozess-name in der Form von {ProcessName, NodeName@[IP |DNS]}!Message umgesetzt werden.

Infrastrukturaufwand: Sobald ein Erlang-Release ak-tiviert wurde, konnen die Module innerhalb der laufendenBEAM-CLI unabhangig kompiliert, ausgeliefert und betrie-ben werden. Dabei konnen, ahnlich der Activator-Klassein OSGi, Funktionen definiert werden, die beim Ladendes Moduls unmittelbar auszufuhren sind. Neben dem ent-fernten Starten von Erlang-Prozessen sind unterschiedlicheMoglichkeiten der effizienten Administration auf Prozes-sebene gegeben. Dies schließt ebenfalls Moglichkeiten zurIntegration des Deployments und Uberwachung der Dienstein bestehende Systeme ein [5].

E. FazitErlang ist eine alte Programmiersprache, dessen großer

Anklang innerhalb der funktionalen Programmierwelt durchlang erprobten Einsatz, hoher Auswahl freier Bibliotheken,Stabilitat und vieler weiterer Eigenschaften zu begrundenist. Unter Verwendung des Aktorenmodells konnen Nano-services ideal auf Prozessstrukturen innerhalb von Erlangabgebildet werden. Der geringe Infrastrukturaufwand undRessourcenverbrauch tragen zur Eignung sehr kleiner undfunktionaler Services ebenso bei, wie das Nachrichtensystemund die Isolation einzelner Module untereinander. Kannein Service durch das funktionsbasierte Erlang umgesetztwerden, werden im Vergleich zu den bisher betrachtetenTechnologien nur geringe Kompromisse eingegangen.

22

X. FAZIT

Die Entwicklung außerst kleiner Microservices ohne ent-sprechende Anpassungen der verwendeten Technologien,kann aufgrund des erhohten Ressourcenverbrauchs und dernotwendigen Netzwerkkommunikation zu recht als Anti-pattern angesehen werden. Die vorliegende Arbeit zeigtemehrere Moglichkeiten, wie die technischen Grenzen derartverschoben werden konnen, dass eine weitere Reduktion derModulgroße dennoch sinnvoll sein kann. So existieren Tech-nologien, welche unter Akzeptanz gewisser Kompromisseden Ressourcenverbauch immens reduzieren konnen undzusatzlich lokale Kommunikationsmechanismen anbieten.Die Auswahl der Technologien wird maßgeblich durch daskonkrete Anwendungsszenario sowie der darin akzeptablenKompromisse vorgegeben. Liegt der Fokus beispielsweiseauf einer moglichst hohen Isolation, ist Erlang eine viel-versprechende Technologie, wogegen Amazon Lambda sichbesonders fur webbasierte Anwendungssysteme, in welcheneine verteilte Kommunikation unabdingbar ist, eignet.

Neben den technischen Grenzen wird die minimale Großeeines Microservice jedoch ebenfalls durch die Notwendig-keit zur Gewahrleistung globaler Konsistenz und die Vermei-dung von modulubergreifender Transaktionen beeinflusst.Da sich diese Grenze nur sehr bedingt beeinflussen lasst,hangt die Eignung des Architekturmusters Nanoservicesstark von dem zugrunde liegenden Anwendungsszenarioab. Ein vielversprechendes Einsatzgebiet ist die Verwen-dung innerhalb lokaler Desktopanwendung. Dies ermoglichtdie Adaption der bestehenden Vorteile der Microservice-Architektur und ermoglicht den Verzicht verteilter Kommu-nikation und die Reduktion der Notwendigkeit zur strik-ten Isolation. Daruber hinaus konnen Nanoservices ver-wendet werden, um einzelne Module einer Microservice-Architektur weiter aufzuteilen. Dabei sollte jedoch auf dietechnologiespezifischen, lokalen Kommunikationsmechanis-men zuruckgegriffen werden.

LITERATUR

[1] R. Rodger, The Tao of Microservices. ManningPublications Company, 2017. [Online]. Available:https://books.google.de/books?id=uosOkAEACAAJ

[2] O. Zimmermann, “Microservices tenets,” Computer Science -Research and Development, 2016.

[3] A. Singleton, “The economics of microservices,” IEEE CloudComputing, vol. 3, no. 5, pp. 16–20, Sept 2016.

[4] A. Sill, “The design and architecture of microservices,” IEEECloud Computing, vol. 3, no. 5, pp. 76–80, Sept 2016.

[5] E. Wolff, Microservices: Grundlagen flexibler Softwarearchi-tekturen. Dpunkt.Verlag GmbH, 2015. [Online]. Available:https://books.google.de/books?id=SrccswEACAAJ

[6] M. Villamizar, O. Garces, L. Ochoa, H. Castro, L. Salamanca,M. Verano, R. Casallas, S. Gil, C. Valencia, A. Zambrano,and M. Lang, “Infrastructure cost comparison of running webapplications in the cloud using aws lambda and monolithicand microservice architectures,” 2016 16th IEEE/ACM Inter-national Symposium on Cluster, Cloud and Grid Computing(CCGrid), vol. 00.

[7] C. Carneiro and T. Schmelmer, Microservices: The What andthe Why. Berkeley, CA: Apress, 2016, pp. 3–18.

[8] “Aws lambda,” Dezember 2016. [Online]. Available:https://aws.amazon.com/de/lambda/

[9] “Lightweight event-based microservices,” Dezember 2016.[Online]. Available: https://cloud.google.com/functions/

[10] “Spring boot,” November 2016. [Online]. Available:https://projects.spring.io/spring-boot/

[11] I. Cosmina, Spring Microservices with Spring Cloud. Ber-keley, CA: Apress, 2017, pp. 435–459.

[12] “Vert.x,” Dezember 2016. [Online]. Available: http://vertx.io/

[13] “Osgi alliance,” Dezember 2016. [Online]. Available:https://www.osgi.org/

[14] V. Gruhn and A. Thiel, Komponentenmodelle DCOM, Java-beans, Enterprise Java Beans, CORBA. Addison-Wesley,2000.

[15] “Erlang,” Dezember 2016. [Online]. Available: htt-ps://www.erlang.org/

[16] “Scala,” Dezember 2016. [Online]. Available:https://www.scala-lang.org/

[17] “Apax,” Dezember 2016. [Online]. Available: http://apex.run/

[18] J. Mader, “Vert.x fur microservices - eine reaktivelosung,” Java Magazin, 2016. [Online]. Availa-ble: https://public.centerdevice.de/879e2310-824f-4c73-98dc-7ce3fedb6218

[19] “Vert.x core manual,” Dezember 2016. [Online]. Available:http://vertx.io/docs/vertx-core/java/

[20] “Vert.x web,” Dezember 2016. [Online]. Available:http://vertx.io/docs/vertx-web/js/

[21] H. Kuijs, C. Reich, M. Knahl, and N. L. Clarke, “A scalablearchitecture for distributed osgi in the cloud,” in CLOSER2016 - Proceedings of the 6th International Conference onCloud Computing and Services Science, Volume 2, Rome,Italy, April 23-25, 2016., 2016, pp. 109–117.

[22] J. S. Rellermeyer, G. Alonso, and T. Roscoe, in Middleware,R. Cerqueira and R. H. Campbell, Eds.

[23] F. Hebert, Learn You Some Erlang for Great Good!: ABeginner’s Guide. San Francisco, CA, USA: No StarchPress, 2013.

[24] F. Cesarini and S. Thompson, ERLANG Programming, 1st ed.O’Reilly Media, Inc., 2009.

[25] “Ninenines - cowboy http server website,” November 2016.[Online]. Available: https://github.com/ninenines/cowboy/

23

Transaktionen in MicroservicesTimo Hauser, Enrico Schrödter

Informatik MasterHochschule Furtwangen University

78120 Furtwangen, Deutschland{Timo.Hauser, Enrico.Schroedter}@hs-furtwangen.de

Zusammenfassung—Microservices bieten eine Möglichkeit

große monolythische Anwendungen in einzelne kleine Kompo-

nenten zu unterteilen und die Gesamtanwendung durch Kompo-

sition der einzelnen Microservices abzubilden. Die Sicherstellung

der Atomitzität von Geschäftsprozessen innerhalb eines solchen

Systems stellt derzeit noch eine der Herrausforderungen in

einer Microservice-Architektur dar. Vor allem für Services mit

REST Schnittstellen findet sich noch kein etablierter Standard.

In dieser Arbeit werden einige Ansätze für Transaktionen an

einem einzelnen Microservice, sowie über mehrere Microservices

hinweg vorgestellt und diskutiert.

Index Terms—Microservices; Atomizität; Verteilte Transakti-

on; REST

I. EINLEITUNG

Microservices bieten eine Möglichkeit große monolythischeAnwendungen in einzelne kleine Komponenten zu unterteilenund die Gesamtanwendung durch Komposition der einzelnenMicroservices abzubilden. Hauptziel einer Microservice Ar-chitektur ist eine möglichst agile, unabhängige und flexibleEntwicklung der einzelnen Komponenten. Die Sicherstellungder Atomitzität von Geschäftsprozessen innerhalb eines sol-chen Systems stellt derzeit noch eine der Herrausforderungenin einer Microservice-Architektur dar. Vor allem für Servicesmit REST Schnittstellen findet sich noch kein etablierterStandard.

Diese Arbeit gibt zunächst in Kapitel II einen kurzenÜberblick zu Microservices. Anschließend werden in KapitelIII Motivation und Anforderungen an Transaktionen in einemMicroservice System vorgestellt. Die in den Kapiteln IV - VIIIvorgestellten Konzepte reichen dabei von Transaktionen aneinem einzelnen Microservice hin zu verteilten Transaktionenüber mehrere Microservices hinweg. Sie werden auf ihreStärken und Schwächen hin untersucht, bevor in Kapitel IXein abschließendes Resümee gezogen wird.

II. MICROSERVICES

In diesem Abschnitt wird kurz dargestellt welche MerkmaleMicroservices auszeichnen und wie sie sich auf Entwicklungund Betrieb eines Microservice Systems auswirken.

Microservices sind ein derzeit sehr beliebtes Architektur-muster in stark verteilten und skalierten Systemen. Im Ge-gensatz zur monolithischen Bereitstellung einer Anwendungwird diese in eine Vielzahl eigenständiger Services unterteilt,die zusammen eine Gesamtanwendung bilden. Die Hauptzieleeiner solchen Architektur liegen in einer deutlich gesteigerten

Abbildung 1. Monolythische Anwendungen und Microservices im Vergleich

Flexibilität und Agilität bei der Entwicklung der einzelnenKomponenten, sowie die Möglichkeit von Skalierung und Red-undanz auf Ebene einzelner Microservices. Sämtliche erreich-ten Vorteile gehen auf Kosten einer steigenden Komplexitätdes Gesamtsystems.

Abbildung 1 zeigt anschaulich wie sich ein MicroserviceSystem von einer als Monolyth deployten Applikation unter-scheidet. Bei Microservices wird jede Komponente bzw. jederService unabhängige von den anderen Services betrieben. DieKommunikation zwischen den einzelnen Services erfolgt überexplizite Schnittstellen. Dadurch lassen sich verschiedene Mi-croservices unabhängig voneinander entwickeln und betreiben.Darüber hinaus bietet eine solche Struktur die Möglichkeiteinzelne Microservices gezielt zu skalieren oder replizieren,um die Leistung beziehungsweise Fehlertoleranz des Gesamt-systems zu verbessern. Würden alle Komponenten als eineEinheit betrieben werden, könnte nur die gesamte Anwendungskaliert bzw. repliziert werden, was zu vergleichsweise hohenRessourcenbedarf führt. Auf der anderen Seite geht mit stei-gendem Grad der Vernetzung und verteilten Kommunikationauch ein Zuwachs der Gesamtkomplexität einher. In Hinsichtauf die verteilte Kommunikation der einzelnen Services un-tereinander muss deren Unzuverlässigkeit unbedingt beachtetwerden, es muss also mit Fehlern bei Übertragung der Nach-richten gerechnet werden. Ansonsten droht die Zuverlässigkeitdes Gesamtsystems zusammenzubrechen. [1]

Auf organisatorischer Seite bedeuten Microservices für einUnternehmen besondere Anforderungen an die Organisationder Entwicklung und des Betriebs solcher Systeme. Für Ent-wicklung und Betrieb eines Microservice ist stets ein einzelnesEntwicklerteam zuständig, das allerdings auch für mehrereServices verantwortlich sein kann. Die starke Autonomie derMicroservices ermöglicht eine vergleichsweise einfache Er-setzung bzw. Überarbeitung eines kompletten Service, sowieeine Unabhängigkeit von der Technologiewahl für andere

25

Microservices.�Damit� ein�Microservice�System� effizient�wei-terentwickelt�und�betrieben�werden�kann,�ist�der�Einsatz�einer�Contineous-Delivery-Pipeline�unerlässlich.� [1]

Weitere� Informationen� zu� Microservices� sind� in� [1]–[5]�enthalten.

III.� TRANSAKTION

Nachdem� im� vorhergehenden� Kapitel� Microservices� defi-niert� wurden,� wird� hier� die� Motivation� bzw.� Anforderungen�an�Transaktionen� in�einem� solchen�System�beschrieben.

Die�Koordinierung�der�Aufrufe�an�Microservices� innerhalb�eines�Geschäftsprosesses� als� eine� transaktionale�Einheit� stellt�eine� der� großen� Herrausforderungen� in� diesem� Gebiet� dar.�In�Microservice�Anwendungen� ergeben� sich� im�wesentlichen�zwei�Gründe� für� die�Notwendigkeit� von�Transaktionen.�Zum�einen�wären�hier�Transaktionen�auf�einen�einzelnen�Microser-vice�über�mehrere�Aufrufe�hinweg� zu�nennen,�beispielsweise�um� erst� eine� Bestellung� anzulegen� und� ihr� dann� nach� und�nach�die�einzelnen�Positionen�hinzuzufügen.�Zum�anderen�ver-teilte�Transaktionen�über�mehrere�Microservices�hinweg.�Ein�Beispiel� hierfür� könnte� der� Kauf� eines� Musiktitels� in� einem�Cloudservice� sein.�Hier� darf� das�Guthabenkonto� des�Kunden�nur� dann� belastet� werden,� wenn� das� Musikstück� in� seine�persönliche�Bibliothek�aufgenommen�wurde.�Auf�der�anderen�Seite� sollte� dem� Kunden� aber� kein� Musikstück� zugeordnet�werden,�wenn�die�Abbuchung�des�Guthaben�fehlschlägt.�Wenn�der� eben� beschriebene� Cloudservice� als� System� von� Micro-services� organisiert� ist,� so� sind�mit� hoher�Wahrscheinlichkeit�verschiedene�Services� für�Kundenkonto� und�Musikbibliothek�zuständig.� In�einem� solchen�Fall� ist�also�eine�verteilte�Trans-aktion� über� alle� an� diesem� Prozess� beteiligten�Microservices�notwendig.Im�Kontext� eines�Microservice�System�wird� der�Fokus� einer�Transaktion� vor� allem� auf� den�Aspekt� der�Atomizität� gelegt.�Die� Konsistenz� sowie� Dauerhaftigkeit� der� Daten� ist� Aufga-be� der� einzelnen� Microservices.� Gegenüber� herkömmlichen�ACID-Transaktionen�wird� vor� allem� die� Isolation� der� einzel-nen�Transaktionen,�zugunsten�einer�stärkeren�Parallelität,�stark�abgeschwächt,Vor�allem� für�REST-Microservices�existiert�derzeit�noch�kein�etablierter� Standard� der� für� eine� Kombination� von� Aufrufen�mehrerer�Microservices�die�Atomizität� für�den�gesamten�Pro-zess�garantiert.�Setzt�ein�System�von�Microservices�auf�SOAP�als�Schnittstelle�kann�auf�den� im�SOA-Umfeld�etablierte�WS-Transaction�Standard�zurückgegriffen�werden.�Wird�asynchron�mittels�Nachrichten�über�eine�geeignete�Middlewaretechnolo-gie� kommuniziert,� bieten� diese� Systeme�meist�Unterstützung�für�verteilte�Transaktionen.�ActiveMQ�bietet�hier�beispielswei-se�eine� Implementierung�des�XA-Protokolls�an.� [1]

IV.� OVERLOADED�POST

Das� Überladen� von� HTTP� POST� Anfragen� ist� die� in� der�Praxis�aktuell�am�weitesten�verbreitete�Variante,�um�Transak-tionsunterstützung� in� einer� REST-Schnittstelle� zu� implemen-tieren.� [6,�p.2]

1) Funktionsweise: Mit dem Überladen des POST wirddie eigentlich ausgeführte Methode nicht durch die für denAufruf verwendete HTTP-Methode vorgegeben, sondern istin irgendeiner Form Teil der Nachricht. Die Angabe derMethode kann dabei an verschiedenen Stellen vorgenommenwerden. Zum einen kann sie Teil der URL bzw. ein Parameterdarin sein, zum anderen besteht die Möglichkeit die Methodeüber einen HTTP-Header zu spezifizieren. Die dritte Variantebesteht darin die Beschreibung der auszuführenden Methodeim Body der Nachricht unterzubringen. [7, p.101] Eine genaueAussage oder Richtlinie, welcher dieser Varianten der Vorzugzu gewähren ist, lässt sich derzeit nicht ausmachen.

Schnittstellen die mit SOAP oder XML-RPC arbeiten ver-wenden ausschließlich das Überladen von POST für ihreAufrufe. [7, p.220]

2) Beispiel: Möchte man beispielsweise Geld von einemKonto auf ein anderes überweisen, bietet es sich an dieseOperation in einer Überladung des POST bereitzustellen.Konkret bedeutet das, dass an der Ressource ’account’ nebenden Methoden GET, PUT, DELETE und dem einfachen POSTnoch eine Methode ’moneyTransfer’ zur Verfügung steht. DieImplementierung von ’moneyTransfer’ kann dann mit einerherkömmlichen Datenbank-Transaktion vollständige ACID-Konformität gewährleisten.

3) Problemfälle: Geht die Antwort Nachricht nach er-folgreicher Bearbeitung auf dem Weg zum Client verloren,besteht für diesen keine Möglichkeit diese erneut Anzufordern.Letztendlich bleibt einem Client also nur das erneute Sendender Anfrage übrig. Gerade bei nicht idempotenten Operationenkann eine erneute Ausführung der Operation allerdings zuinkonsistenten Daten führen. Beispielsweise wenn die selbeRechnung oder Bestellung in einem Onlineshop mehrfachangelegt wird.

4) Bewertung: Einer der größten Nachteile dieser Vorge-hensweise ist sicherlich, dass für jede besondere Operation,die so nicht direkt Teil des REST-Interface ist, eine eigene Me-thode implementiert werden muss. Die Flexibilität der Schnitt-stelle hinsichtlich sich ändernder oder neuer Anforderungenvon Geschäftsprozessen wird damit stark eingeschränkt. Tretenim Betrieb einer Schnittstelle mit überladenem POST Fehlerauf, kann sich die Fehlersuche unter Umständen schwieriggestalten, da die tatsächlich ausgeführte Operation im Nach-hinein eventuell gar nicht nachvollzogen werden kann. Nebenden eben aufgeführten Nachteilen spricht die Einfachheit undgeringe Komplexität für den Einsatz dieses Konzepts. In Hin-sicht auf die Zustandslosigkeit des Microservice bzw. dessenSchnittstelle ergeben sich keine Änderungen.

Dieses Konzept eignet sich zwar nicht für über mehrereMicroservices verteilte Transaktionen oder eine Kombinationvon Aufrufen an einem einzelnen Microservice. Ermöglichtes aber mit vergleichsweise geringem Aufwand besondereOperationen bereitzustellen, die eine REST Schnittstelle sonormalerweise nicht bieten würde. Des weiteren wird dieKommunikation zwischen den Microservices nicht durch zu-sätzlichen Aufwand belastet, was die Performance des Sys-tems quasi unangetastet belässt. Für einfache Szenarien dürftedieses Verfahren sicherlich ausreichen, es deck allerdings beiweitem nicht alle denkbaren Fälle ab.

26

Abbildung 2. OData: Aufbau eines Batch Request

V. BATCH-OPERATION

Eine Alternative dazu, für jede benötigte besondere Ope-ration eine Überladung des POST zu implementieren, ist esmehrere Operationen an einer REST-Schnittstelle als Batchauszuführen. Der OASIS Standard OData spezifiziert unter an-derem ein Nachrichtenformat, sowie den Ablauf einer solchenBatch Anfrage.

1) Funktionsweise: Abbildung 2 zeigt schematisch wie einOData Batch aufgebaut sein kann. Schreibende Operationen,also INSERT, UPDATE und DELETE Anforderungen, werdenin sogenannten Changesets zusammengefasst, wobei in einemChangeset keine weiteren Changesets oder GET Anforderun-gen enthalten sein dürfen. In einem Batch können dann meh-rere GET Anforderungen und Changesets zusammengefasstwerden. Die Reihenfolge der Elemente in einem Batch istbindend, das heißt sie werden auf Serverseite auch in genaudieser Reihenfolge ausgeführt. [8]

Bei Bearbeitung einer Batch Nachricht in einem Micro-service kann dann eine einzelne Datenbanktransaktion desdarunterliegenden RDBMS für die Ausführung aller im Batchenthaltenen Anfragen verwendet werden. Damit lässt sichvollständige ACID-Konformität herstellen.1 POST /service/$batch HTTP/1.12 <...>3 Content-Type: multipart/mixed; boundary=batch_47114

5 --batch_47116 Content-Type: multipart/mixed; boundary=changeset_427 Content-Length: ###8

9 --changeset_4210 <...>11

12 POST /service/Orders HTTP/1.113 Host: host14 Content-Type: application/json15 Content-Length: ###16

17 <JSON representation of a new Order>18

19 --changeset_4220 <...>21

22 POST $1/Items HTTP/1.123 Host: host24 Content-Type: application/json25 Content-Length: ###26

27 <JSON representation of a new Order-Item>28

29 --changeset_4230 <...>

31

32 PUT /service/Orders(4711) HTTP/1.133 Host: host34 Content-Type: application/json35 Content-Length: ###36

37 <JSON representation of Order #4711>38

39 --changeset_42--40 --batch_4711--

Listing 1. Vereinfachter OData-Batch-Request

In Listing 1 ist ein stark vereinfachtes Beispiel einer ODataBatch Anforderung zu sehen, eine detaillierte Beschreibungdes Protokolls findet sich unter [8]. Das hier verwendete Bei-spiel besteht aus einem einzelnen Changeset in dem zuerst eineneue Bestellung aufgegeben wird, um dieser anschließend einePosition hinzuzufügen. Abschließend wird noch die Bestellungmit der Id 4711 geändert. Die eigentlichen Nutzdaten sindhier der Übersichtlichkeit halber nicht dargestellt und Stellenan denen Teile der vom Protokoll geforderten Informationenentfernt wurden sind mit ’<...>’ gekennzeichnet. Die zweiteOperation des Beispiels, in der eine neue Position zur zu-vor angelegten Bestellung angelegt wird, zeigt ein wichtigesFeature des OData-Batch, das Referenzieren vorhergehenderAnweisungen. Ohne diese Funktionalität wäre ein solchesBeispiel erst gar nicht möglich, was den Nutzen solcherBatches stark einschränken würde. [8]

Eine dem Beispiel aus Listing 1 entsprechende Antwortwird wieder in vereinfachter Form in Listing 2 dargestellt.Der Aufbau einer solchen Response-Nachricht entspricht imWesentlichen dem der Anfrage, nur das anstatt der Anfragenderen Ergebnisse an den entsprechenden Stellen enthaltensind. Interessant ist hier noch der Fakt, dass ein Batch mit’HTTP 200 Ok’ beantwortet wird selbst wenn eine der darinenthaltenen GET-Anfragen fehlgeschlagen ist. Ob ein Batcherfolgreich durchgeführt wurde richtet sich also lediglich nachden darin enthaltenen schreibenden Operationen. Grund hier-für ist, dass sämtliche lesende Anfragen durch erneutes Sendengefahrlos wiederholt werden können. [8]1 HTTP/1.1 200 Ok2 Content-Length: ####3 Content-Type: multipart/mixed; boundary=b_47114

5 --b_47116 Content-Type: multipart/mixed; boundary=cs_427

8 --cs_429 <...>

10

11 HTTP/1.1 201 Created12 Content-Type: application/json13 Location: http://host/service/Orders(9)14 Content-Length: ###15

16 <JSON representation of a new Order>17

18 --cs_4219 <...>20

21 HTTP/1.1 201 Created22 Content-Type: application/json23 Location: http://host/service/Orders(9)/Items(47)24 Content-Length: ###25

26 <JSON representation of a new Order-Item>27

28 --cs_4229 <...>30

31 HTTP/1.1 204 No Content

27

32 Host: host33

34

35 --cs_42--36 --b_4711--

Listing 2. Vereinfachte OData-Batch-Response

3) Probemfälle: Bei OData Batch Anfragen ergibt sich dieselbe Problematik wie bereits in Abschnitt IV für das Überla-den von POST beschrieben. Auch hier bietet die Schnittstelledem Client keine Möglichkeit eine Antwort erneut anzufor-dern.

4) Bewertung: Auf den ersten Blick fällt die Einfachheitdieses Protokolls auf, bei genauerer Betrachtung ergeben sichallerdings einige Probleme in Hinsicht auf eine Verwendungin Microservice Architekturen.Für verteilte Transaktionen über mehrere Services hinwegeignen sich OData Batches nicht, bieten aber eine flexibleMöglichkeit Anfragen an einen einzelnen Microservice ineiner Transaktion zusammenzufassen. Darüber hinaus kann dieGröße der Batch-Nachrichten zu einem Problem werden, wenndie Nutzdaten der einzelnen Operationen groß sind oder vieleOperationen in einem Batch enthalten sind. Aus diesem Grundschränkt Microsoft beispielsweise die Größe eines Batches inden Azure Table Services auf eine Payload von maximal 4MB und einen Umfang von höchstens 100 Operationen ein.Mehrere Changesets innerhalb einer Batch-Operation werdenebenfalls nicht unterstützt. [9] Damit die Verwendung vonOData Batches in einem Microservice System möglich ist,müssen alle beteiligten Services diesen Standard unterstützen.Da es sich hier um einen OASIS Standard handelt, dürfte esallerdings nicht mehr allzu lange dauern bis entsprechendeFrameworks für viele Programmiersprachen zur Verfügungstehen.

VI. TRANSACTION AS RESOURCE

Eine dritte Möglichkeit Transaktionen in einer REST-Schnittstelle abzubilden ist es die Transaktion selbst als Res-source zu betrachten und auch genau so zu behandeln.

1) Funktionsweise: Transaktionen werden bei diesem Ver-fahren zusätzlich zu den normalerweise bereitgestellten Res-sourcen als eigenständige Ressource definiert. Möchte ein Cli-ent eine Transaktion starten, fordert er mittels einer POST An-frage auf die Transaktionsressource eine neue Transaktion an.Als Antwort erhält er eine URL die er im Folgenden als Proxyfür alle weiteren Aufrufe verwendet. Alternativ besteht je nachImplementierung der Schnittstelle auch die Möglichkeit dieTransaktion zu der ein Aufruf zugeordnet werden soll miteinem HTTP-Header Element zuzuordnen. Sind alle Teilope-rationen einer Transaktion durchgeführt, kann der Client dieTransaktion entweder committen oder zurück rollen. Für dieImplementierung auf Seite des Microservice bieten sich zweiVarianten an. Zum einen kann die verwendete Transaktiondes darunterliegenden RDBMS bereits bei Anfordern einerneuen Transaktion geöffnet werden, sie muss dann allerdingsbis zum Ende der Transaktion im Microservice vorgehaltenwerden. Diese Vorgehensweise bedeutet Einschränkungen fürdie Zustandslosigkeit des Services, bietet im Gegenzug aber

die Möglichkeit auf Anfragen direkt mit den Ergebnissender Operationen zu antworten. Die zweite Variante bestehtdarin, die einzelnen Operationen bis zum Ende der Transaktionzwischenzuspeichern um dann bei Commit der Transaktionalle Aktionen nacheinander durchzuführen. Hier wird dieZustandslosigkeit gewahrt, insofern die vorgehaltenen Ope-rationen nicht im Hauptspeicher gehalten werden. Allerdingslassen sich voneinander abhängige Aufrufe, wie beispielsweisedas Anlegen einer Bestellung mit anschließendem Hinzufügeneinzelner Positionen, nur schwer abbilden. [7, p.231f]

A. Beispiel

Listing 3 zeigt in den Zeilen 1 bis 2 wie eine neueTransaktion angefordert werden kann. Als Antwort (Z. 4-5)enthält der Client eine URL unter der die neu begonneneTransaktion erreicht werden kann.1 POST /service/transactions/ HTTP/1.12 Host: host3

4 201 Created5 Location: /service/transactions/11a5

Listing 3. Transaktion als Ressource - Transaktion starten

Diese kann er nun für Operationen innerhalb der Transakti-on verwenden (vgl. Listing 4), die URL der Transaktion wirdhierbei einfach um den URI der entsprechenden Ressourceerweitert. Im gezeigten Beispiel wird eine neue Rechnunghinzugefügt. Darauf könnten beliebig viele weitere Aufrufefolgen, etwa um der eben angelegten Rechnung Positionenhinzuzufügen.7 POST service/transactions/11a5/orders HTTP/1.18 Host: host9 Content-Type: application/json

10 Content-Length: ###11

12 <JSON representation of a new Order>

Listing 4. Transaktion als Ressource - Aufruf

Soll die Transaktion abgeschlossen werden, kann dies wie inListing 5 dargestellt durchgeführt werden. Ein Rollback einerTransaktion erfolgt durch das Löschen der Ressource mittelsDELETE (vgl. Listing 6).14 POST /service/transactions/11a515 Host:host16

17 commited=true

Listing 5. Transaktion als Ressource - Commit

19 DELETE /service/transactions/11a520 Host:host

Listing 6. Transaktion als Ressource - Rollback

B. Problemfälle

Wird für begonnene und nicht beendete Transaktionen keinTimeout ausgelöst, besteht die Möglichkeit einer dauerhaftenBlockierung von Ressourcen. Zumindest wenn die Transaktioninnerhalb des Microservice vorgehalten wird. Bei einer Im-plementierung mit Zwischenspeichern der einzelnen Aktionenkann diese Problematik nicht auftreten, da die eigentlicheDatenbanktransaktion erst mit dem Commit geöffnet wird.Allerdings besteht hier theoretisch die Möglichkeit, dass der

28

Zeitunterschied� zwischen� der� eigentlichen�Anfrage� und� ihrer�Ausführung� auf� den�Datenbestand� zu� unerwünschten�Neben-effekten� führt.�Gerade�bei� länger�dauernden�Transaktionen� ist�es�denkbar,�dass� in�der�Zwischenzeit�eine�andere�Transaktion�Änderungen� am� Datenbestand� vorgenommen� hat.� Wird� die�Transaktion�schließlich�comitted,�werden�die�Änderungen�der�bereits� abgeschlossenen� Transaktion� einfach� überschrieben.�Die� Isolation�der�Transaktionen� ist�nicht�gegeben.

C. Bewertung

Einmal in einen Microservice implementiert lässt sich diesesVerfahren für alle angebotenen Ressourcen wiederverwenden.Die Implementierung auf Seite des Aufrufenden gestaltet sichauch nicht allzu schwierig. Unterstützung für voneinanderabhängige Anfragen lässt sich nur auf Kosten der Zustandslo-sigkeit eines Service bewerkstelligen. Sie sind allerdings einerder häufigsten Anwendungsfälle für Transaktionen an einemeinzelnen Microservice, was zu einer gewissen Notwendigkeitführt.

Generell ergeben sich mit der Abbildung von Transaktionenals Ressource einige Herausforderungen für die Skalierungeines solchen Systems. Wird ein Microservice skaliert, mussdafür Sorge getragen werden dass die Anfragen eines Clientstets durch die selbe Instanz eines Service bearbeitet werden.Alternativ besteht auch die Möglichkeit die Zustände der ein-zelnen Transaktionen über alle Instanzen hinweg zu Synchro-nisieren, beispielsweise durch den Einsatz eines geeignetenDatenbanksystems.

Verteilte Transaktionen über mehrere Microservices hinweglassen sich mit diesem Ansatz nicht realisieren.

VII. TIMESTAMP-BASED 2-PHASE COMMIT

Ein weiteres Konzept für die Ausführung von Transaktionenin REST Services ist das Timestamp-based 2-Phase Com-mit (TS2PC4RS) Protokoll. Das Ziel des TS2PC4RS ist dieGewährung der Atomizität von Transaktionen über verteilteServices, wobei lesende Anfragen, die typischerweise häufigervorkommen, vor schreibenden Anfragen priorisiert werdensollen. [10]

1) Funktionsweise: Zur atomaren Durchführung von Trans-aktionen wird das 2-Phase-Commit Protokoll verwendet. Die-ses wird ohne einer zusätzlichen Instanz zwischen Client undService verwendet.

Wie in 3 dargestellt, wird die Transaktion in zwei Phasendurchgeführt. In der ersten Phase erhalten im Beispiel diebeiden Services Anfragen vom Client. Jeder Service überprüft,ob er die Operation, die diese Anfrage darstellt, ausführenkann, ohne dass seine Daten in einem inkonsistenten Zustandüberführt werden. Können wie im Beispiel alle Operationenausgeführt werden, so erhält der Client von jedem Service eineAntwort mit dem Statuscode 200 (OK). Kann eine Operationnicht ausgeführt werden, so gibt der Service den Statuscode400 (bad request) zurück.

Nachdem der Client von jedem Service eine Antwort erhal-ten hat, beginnt die zweite Phase. Hat der Client nur Antwortenmit dem Statuscode 200 erhalten, so kann die Transaktiondurchgeführt werden. In diesem Fall sendet der Client an jeden

Abbildung 3. 2-Phase-Commit Protokoll

Service eine commit Anfrage. Damit werden die einzelnenOperationen in den Services ausgeführt. Erhält der Client eineAntwort mit dem Statuscode 400, so müssen alle Operationenzurückgesetzt werden. Dies erfolgt durch das Senden einerabort Anfrage an alle Services.

Durch das 2-PC Protokoll werden alle Operationen einerTransaktion oder gar keine Operation ausgeführt. Es wird dieAtomizität sichergestellt. Für die ordnungsgemäße Durchfüh-rung des 2PC-Protokolls trägt der Client die Verantwortung.

Durch das 2-PC kann die Atomizität sichergestellt werden.Um eine hohe Performance zu erhalten, benötigen die Servicesin der ersten Phase eine gute Strategie, um die Anfragen aus-zuwählen, welche zugelassen und welche abgelehnt werden,wobei die Konsistenz der Daten gewährt sein muss. Dafürwerden Timestamps verwendet.

Jede Transaktion erhält von seinem Client einen eindeutigenTimestamp. Dieser wird auch jeder Operation der Transaktionzugeordnet. Zusätzlich speichert jeder Service drei Werte ab.Zum einen wird der höchste Timestamp einer durchgeführtenSchreiboperation (WTM) und der höchste Timestamp einerLeseoperation (RTM) gespeichert. Außerdem werden Schreib-operationen nicht direkt durchgeführt, sondern in einem Buffer(LPW) zwischengespeichert.

Der Algorithmus unterscheidet zwischen Schreib- und Le-seoperationen. Eine Schreiboperation kann nur bearbeitet wer-den, wenn der Timestamp der Operation größer ist als WTMund RTM, d.h. seit dem Start der Transaktion wurden keineOperationen in dem Service ausgeführt, und die Daten ineinem konsistenten Zustand hinterlässt. Dann wird die Opera-tion in den LPW eingefügt und zu einem späteren Zeitpunktausgeführt.

Eine Leseoperation wird nur abgebrochen, falls ihr Time-stamp kleiner ist als WTM, d.h. seit dem Start der Transaktionwurde eine Schreiboperation auf den Daten ausgeführt. Indiesem Fall wird die Operationen nicht akzeptiert und ein 400(bad request) zurückgegeben.

Anderenfalls wird die Leseoperation durchgeführt. Zusätz-lich zu den gelesenen Daten werden auch alle Operationen ausdem LPW ausgeführt und zurückgegeben, deren Timestampkleiner ist das der Timestamp der Operation. Außerdem wirdder RTM ggf. neu gesetzt.

29

Abbildung 4. Schreiboperation wird abgelehnt

2) Beispiel: In diesem Abschnitt wird ein Teil des Beispielsaus [10] erläutert, um die Unterschiede zum 2PC-Protokolldeutlich zu machen. In diesem Beispiel gibt es zwei Services,die Tickets für ein Spiel bzw. der Zugfahrt zu diesem Spielanbieten. Zwei Client möchten gleichzeitig von beiden Ser-vices Tickets buchen. Client 2 hat in Schritt 5 und 6 die erstePhase des 2PC-Protokolls ausgeführt. Client 1 möchte dies inSchritt 7 und 8 auch ausführen. Dessen Operationen werdenjedoch nicht akzeptiert, da dies Schreiboperationen sind undder RTM der beiden Server mit 40 größer ist als der TS desClient 1 mit 32. Deshalb werden die Operationen von denServern nicht akzeptiert und die Transaktion wird mit einemneuen Timestamp wiederholt.

In Abbildung 5 wird die Fortsetzung des Beispiels darge-stellt. Client 1 führt die komplette Transaktion noch einmaldurch. Bei den lesenden Anfragen erhält Client 1 zusätzlichzum aktuellen Wert auch alle Einträge des LPW, bis zu seinemTS von 50. Damit kann dieser anhand der Business Regelnentscheiden, dass er von Server B nur noch maximal 200Tickets buchen kann, da Client 2 von den vorhandenen 500Tickets möglicherweise 300 Tickets kauft. Da Server B dieseBusiness Regeln kennt, akzeptiert dieser eine Anfrage über200 Tickets.

Die weiteren Schritt des Beispiels unterscheiden sich nichtvon der Durchführung des 2PC-Protokolls, außer dass dieschreibenden Anfragen von Client 1 auch erst im LPWzwischengespeichert und erst mit dem Commit durchgeführtwerden. Das vollständige Beispiel kann aus [10] entnommenwerden.

3) Problemfälle: Durch die Verwendung des 2-PC Proto-koll kann die Atomarität sichergestellt werden. Die Verant-wortung für die Durchführung des Protokolls trägt jedoch derClient und keine kontrollierbare Zwischeninstanz. Führt derClient das Protokoll nicht korrekt durch, so ist es möglich, dassRessourcen dauerhaft blockiert werden und damit die Services

Abbildung 5. Isolation wird aufgelöst

von keinem anderen Client verwendet werden können.Ein Beispiel ist ein Client der jeweils eine Operation auf

zwei unterschiedlichen Services ausführen möchte. Die erstePhase des 2PC-Protokolls verlief erfolgreich. In der zweitenPhase fällt ein Microservice durch Überlastung aus. Der Clientsendet an beide Microservices die Bestätigung der Transakti-on, sodass der aktive Microservice, die Operation durchführt.Die Fehlermeldung, dass ein Microservice nicht erreichbarist, ignoriert der Client jedoch, sodass er die Transaktion alsdurchgeführt ansieht.

Nachdem der Microservice neu gestartet wurde, befindetsich dieser in der ersten Phase des 2-PC Protokolls undblockiert seine Ressourcen. Da der Client das Protokoll jedochnicht vollständig ausgeführt hat, werden diese Ressourcendauerhaft blockiert.

Da der Client für die Durchführung des 2-PC Protokollszuständig ist, muss der Betreiber der Services den Clientsvollständig vertrauen, dass diese das Protokoll korrekt imple-mentiert haben.

4) Bewertung: Das Timestamp-based 2-Phase Commit Pro-tokoll ermöglicht die Ausführung von verteilten Transaktio-nen, wobei die Atomizität durch das bekannte 2PC-Protokollgewährleistet wird.

Das Protokoll kann jedoch nicht allgemein angewendetwerden, da die Business Regeln für die speziellen Servicesfür sowohl den Client als auch die Services bekannt seinmüssen. Die Ticket-Services im Beispiel müssen wissen, dassdie minimale Anzahl an Tickets null beträgt. Außerdem wirddie Isolation durch die zusätzliche Angabe des LBWs beieiner Leseanfrage stark geschwächt. Der größte Nachteil desProtokolls ist, dass Ressourcen dauerhaft blockiert werdenkönnen, wenn die Clients das 2PC-Protokoll nicht vollständigdurchführen.

Ein Protokoll, dass verteilte Transaktionen ermöglicht undRessourcen nicht dauerhaft blockiert ist das TCC. Dieses wird

30

Abbildung 6. TCC: Architektur

im folgenden Kapitel betrachtet.

VIII. TRY-CANCEL/CONFIRM

Ein weiteres Transaktionsmodell für Transaktionen in RESTServices, welches auch auf dem 2PC basiert, ist das Try-Cancel/Confirm (TCC). TCC wurde entwickelt um kurzzei-tige Transaktionen in REST Service über verteilte Server zuermöglichen. Beim TCC können nur idempotente Operationenverwendet werden. [11]

1) Funktionsweise: Die TCC Architektur besteht aus dreiSchichten. Der Client kommuniziert mit einem CompositeService. Der Composite Service ist ein zentraler Service, derdie Transaktion ausführt, welche aus mehreren Operationenauf verschiedenen TCC Ressourcen besteht. Die Architekturist in Abbildung 6 dargestellt.

Der Composite Service ist in eine Workflow Engine undeinem Transaction Coordinator eingeteilt. Die Workflow En-gine führt die erste Phase des 2PC-Protokolls aus. Er sendet anjede TCC Ressource eine TRY Nachricht und erhält eine URLvon jeder Ressource, wenn diese Operation ausgeführt werdenkann. Diese URL wird im späteren Verlauf des Protokolls ver-wendet um die Operation zu bestätigen oder abzubrechen. DieListe von URLs übergibt die Workflow Engine der TransactionCoordinator.

Der Transaction Coordinator kann die zweite Phase des2PC-Protokolls ohne das Wissen über die TCC Resourcenausführen, da die Schnittstelle über die erhaltenen URLsgegeben ist. Kann die Transaktion durchgeführt werden, sowird auf jede URL eine PUT Anfrage gesendet, die diejeweilige Operation bestätigt. Kann eine Operation und damitdie komplette Transaktion nicht durchgeführt werden, so wirdan alle URLs eine DELETE Anfrage gesendet. Damit werdenalle Operationen abgebrochen.

Um dauerhaft blockierte Ressourcen zu verhindern, werdenim TCC Protokoll Timeouts bei den Resourcen verwendet.TCC Resourcen können drei Zustände annehmen. Zu Beginnsind alle Ressourcen im initialen Zustand. Von der WorkflowEngine werden sie mit einer Try Anfrage in den reserviert Zu-stand überführt. Vom Zustand reserviert kann eine Operationbestätigt werden, sodass die Resource in den finalen Zustand

Abbildung 7. TCC: Beispiel

übergeht oder abgebrochen werden, sodass sie in den initialenZustand zurück geht. Zusätzlich gibt es die Möglichkeit,dass die Ressource über einen Timeout ihren Zustand vonreserviert zu initial ändert. Die Verwendung von Timeoutsist der zentrale Unterschied zum 2PC-Protokoll. Durch diesekann verhindert werden, dass Ressourcen dauerhaft blockiertwerden. Diesen Vorteil erkauft man sich durch das möglicheAuftreten von kritischen Fehlern, die manuell korrigiert wer-den müssen. Diese werden nach einem Beispiel im AbschnittVIII-3 erläutert.

2) Beispiel: Ein Beispiel für eine Transaktion, die mithilfedes TCC durchgeführt wird ist in 7 dargestellt. Das Zieldes Benutzers ist das Buchen einer Reise über die zweiFluggesellschaften swiss und easyjet. Von jeder Gesellschaftsoll ein Flug gebucht werden und nur wenn beide Flügeverfügbar sind, sollen diese zusammen gebucht werden.

Schritt 1 ist die Anfrage des Clients an den BookingProcess. Dieser wird in der TCC Workflow Engine abgebildet.Der Booking Process löst die beiden TRY-Anfragen R1 undR2 an die Microservices swiss und easyjet aus. Von diesenerhält dieser jeweils eine URL, die zur Buchung der Ticketsverwendet wird.

In Schritt 1.3 werden diese Links dem Transaction Coordi-nator übergeben. Dieser führt nun die Transaktion atomar aus,indem er zu den gegeben URLs jeweils eine Confirm-Anfragesendet. Damit wird die Transaktion vollständig durchgeführt.

3) Problemfälle: Durch die Kombination des 2PC-Protokolls mit Timeouts kann es zu kritischen Fehlern kom-men, die nicht automatisch korrigiert werden können, sodassdie Daten in einem inkonsistenten Zustand hinterlassen wer-den.

Kritische Fehler können immer auftreten, sobald der Tran-saction Coordinator eine Transaktion vollständig durchführenwill und dieser oder eine TCC Ressource für längere Zeit aus-fällt. Die beiden kritischen Szenarien sind in den Abbildungen8 und 9 dargestellt.

Das erste Szenario ist, dass der Transaction Coordina-tor ausfällt, nachdem er an einen Teil der Services eineConfirm Nachricht gesendet hat. Damit haben alle Services,die diese Nachricht erhalten haben, ihre Operation dauerhaftdurchgeführt. Alle anderen Operationen wurden noch nichtdurchgeführt. Kann der Transaction Coordinator schnell genuggestartet werden, so kann dieser die Confirm Nachrichten an

31

Abbildung 8. TCC: Ausfall des Transaction Coordinator

Abbildung 9. TCC: Ausfall einer Ressource

alle Services noch einmal schicken, sodass die Transaktiondurchgeführt wird. Startet der Transaction Coordinator jedochnicht schnell genug, so kann es passieren, dass eine TCCRessource duch ihren Timeout zurückgesetzt wird. In diesemFall ist es für den Transaction Coordinator nicht mehr möglichdessen Operation durchzuführen. Damit wurde ein Teil derOperationen durchgeführt und ein Teil nicht. Die Transaktionwurde nur teilweise durchgeführt und muss manuell korrigiertwerden.

Der zweite kritische Fehler kann auftreten, wenn ein Servicein der Confirm Phase zu lang ausfällt. Dadurch kommt es zumselben Fehler wie in Szenario 1. Der Timeout des Servicewird ausgelöst und die Operation kann nicht mehr ausgeführtwerden. Damit ist die Transaktion nur teilweise durchgeführtwurden.

4) Bewertung: TCC kann sowohl für Transaktionen aufeinem Microservice als auch für Transaktionen über verteilteMicroservices verwendet werden. Für Transaktionen auf einemMicroservice ist es nicht geeignet, da es bessere Alternativendafür gibt, die einfacher und weniger fehleranfällig sind.

Transaktionen über mehrere verteilte Microservices ermög-licht das TCC mithilfe des 2-PC Protokoll. Dabei können keineRessourcen dauerhaft blockiert werden, da diese nach einemTimeout nach einer gewissen Zeit wieder freigegeben werden.Außerdem ist das TCC relativ leicht zu implementieren undes basiert auf dem bekannten Konzept des 2-PC Protokolls.

Gegen das TCC spricht, dass die Timeouts das 2PC-Protokoll soweit abschwächen, dass eine Transaktion untergewissen Umständen nur teilweise durchgeführt werden kann,

sodass die Daten in einem inkonsistenten Zustand hinterlassenwerden, die nicht automatisch korrigiert werden können.

Diese Fehler können nur durch die richtig Wahl der Ti-meouts verhindert werden, diese müssen so konfiguriert wer-den, dass sie möglichst keine Ressourcen blockieren und dieWahrscheinlichkeit für Timeouts minimieren. Wird die Zeitbis zu einem Timeout zu hoch gewählt, so werden Ressourcensehr lange blockiert. Bei einer zu kurzen Zeit steigt jedoch dieWahrscheinlichkeit, dass inkonsistente Daten entstehen. DieWahl des richtigen Timeouts ist der zentrale Konfigurations-parameter bei der Verwendung des TCCs.

IX. FAZIT

Zusammenfassend lässt sich sagen, dass je nach Anwen-dungsgebiet unterschiedliche Strategien für die Ausführungvon Transaktionen sinnvoll sind. Die größten Unterschiedeliegen darin, ob die Transaktionen auf einem Microserviceoder auf vielen Microservice verteilt durchgeführt werdensollen.

Für die Durchführung von mehreren Operationen alsTransaktion auf einem Microservice scheint sich die Batch-Operation, für die es den OASIS Standard OData gibt, zukünf-tig durchzusetzen. Durch die Einfachheit und dem vorhande-nen Standard, werden sich in Zukunft Produkte um diesenStandard entwickelt, sodass dieser in den verschiedenstenProgrammiersprachen einfach verwendet werden kann. Für dieDurchführung von verteilten Transaktionen lässt sich dieserjedoch nicht verwenden, dafür sind komplexere Protokollenotwendig.

Verteilte Transaktionen werden durch das Timestamp-based2-Phase Commit und dem Try-Cancel/Confirm Protokoll er-möglicht. Beide Protokolle haben ihre Vor- und Nachteile.Während das TS2PC4RS blockierte Ressourcen zulässt, kannbeim TCC bei ungünstigen Umständen und einer schlechtenWahl des Timeouts die Atomizität nicht gewährleistet wer-den. Beide Protokolle können keine stets zu 100% korrekteFunktionsweise garantieren. Diese Problematik ist bereits vonFischer et al. in [12] vor langer Zeit diskutiert worden undaktueller den je.

Die Durchführung von verteilten Transaktionen ist miteinem nicht zu vernachlässigenden Aufwand verbunden. Seies in der Laufzeit oder auf Seite der Entwicklungskosten.Daher sollten in sich logisch geschlossene Prozesse, soferndies möglich ist, nicht in mehrere Microservices aufgespal-ten werden, sondern als eine Einheit in einem Microservicezusammengefasst werden. Dadurch kann die Notwendigkeitfür verteilte Transaktionen in vielen Fällen verhindert werden.Oftmals ist es auch ausreichend die Transaktionen auf Ebeneder Geschäftsprozesse abzubilden. Das Zurückrollen einerTransaktion wird dann mittels kompensierender Aktionen rea-lisiert.

LITERATUR

[1] E. Wolff, Microservices: Grundlagen flexibler Softwarearchitekturen,1st ed. Heidelberg: dpunkt, 2016.

[2] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi,R. Mustafin, and L. Safina, “Microservices: yesterday, today, andtomorrow.” [Online]. Available: https://arxiv.org/pdf/1606.04036v1.pdf

32

[3] S. Newman, Building microservices, first edition ed. Beijing andCambridge and Farnham and Köln and Sebastopol and Tokyo: O’Reilly,2015.

[4] R. Rodger, The Tao of Microservices. Manning Pubns Co, 2016.[5] J. Thones, “Microservices,” IEEE Software, vol. 32, no. 1, p. 116, 2015.[6] S. Kochman, P. T. Wojciechowski, and M. Kmieciak, “Batched transacti-

ons for restful web services,” in Current Trends in Web Engineering, ser.Lecture Notes in Computer Science, A. Harth and N. Koch, Eds. BerlinHeidelberg: Springer Berlin Heidelberg, 2012, vol. 7059, pp. 86–98.

[7] L. Richardson and S. Ruby, RESTful web services: Web services

for the real world, 1st ed. Sebastopol CA u.a.: O’Reilly, 2007.[Online]. Available: https://www.crummy.com/writing/RESTful-Web-Services/RESTful_Web_Services.pdf

[8] M. Pizzo, R. Handl, and M. Zurmuehl, “Odata version 4.0.part 1: Protocol plus errata 03: Oasis standard incorporatingapproved errata 03,” 2016. [Online]. Available: http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.html

[9] T. Myers and S. Arvapally, “Performing entitygroup transactions: Microsoft azure dokumentation,”07.12.2016. [Online]. Available: https://docs.microsoft.com/de-de/rest/api/storageservices/fileservices/performing-entity-group-transactions

[10] L. A. H. da Silva Maciel and C. M. Hirata, “A timestamp-based twophase commit protocol for web services using rest architectural style,”Journal of Web Engineering, vol. 9, no. 3, pp. 266–282, 2010.

[11] G. Pardon and C. Pautasso, “Towards distributed atomic transactionsover restful services,” in REST: From Research to Practice,E. Wilde and C. Pautasso, Eds. New York, NY: SpringerScience+Business Media LLC, 2011, pp. 507–524. [Online]. Available:http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf

[12] M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility ofdistributed consensus with one faulty process,” in Proceedings of the 2nd

ACM SIGACT-SIGMOD symposium on Principles of database systems,R. Fagin, Ed. New York, NY: ACM, 1983, p. 1.

33

Big Data Lothar Piepmeyer

35

It does not always have to be Map Reduce or SparkPetra Borowski, Timo Nurnberg

Faculty of Computer ScienceFurtwangen UniversityRobert-Gerwig-Platz 1Furtwangen, Germany

{petra.borowski, timo.nuernberg}@hs-furtwangen.de

Abstract—Stream and batch processing has attained a lot ofattention in information analysis domains. Fast processing andquerying of streams and large volumes of data is required to fulfillthe needs in domains like data mining, social networks, mediaanalysis and monitoring. Steadily increasing demands to processlarge volumes of data and the ability to analyze streams in real-time yielded to technologies like Apache Hadoop, Spark, Stormand programming models like Map Reduce. In this paper weintroduce and give a brief overview over the two newly emergedtechnologies Apache Flink and Apache Tez, which promise newfeatures and improvements upon older technologies.

Index Terms—Apache Flink, Apache Tez, Batch Processing,Stream Processing, Map Reduce

I. INTRODUCTION

Real-time processing of event-based streams and processinglarge amounts of data has gained a lot of attention over the lastcouple of years. As a result, frameworks that are specializedfor this daunting task of processing data in real-time and in ascalable manner, have emerged. Processing data in real-time isespecially required in environments where data is continuouslyproduced and immediately analyzed and where decisions arederived, based on the streamed data. In domains where frauddetection, intrusion detection and surveillance is of major im-portance, event-based streaming frameworks can be leveraged,to improve awareness and detection of anomalies. Throughproper utilization of streaming frameworks like Apache Storm,Apache Flink and Apache Samza these mentioned goalscan be achieved. Besides the processing of timely streameddata, the handling of petabyte scaled historical data is alsoa noteworthy topic. Relatively cheap commodity hardwarein conjunction with programming models like Map Reduce,enabled the possibility to compute large batches of data in aparallel and responsive matter. Due to the rising interest andsteadily growing ecosystem of frameworks, we introduce andanalyze two newly arrived frameworks for streaming and batchprocessing data. The paper is structured as follows: We startwith Apache Tez in chapter II and give a brief introduction.Furthermore we describe in chapter III the Apache Flinkframework. In chapter IV we compare Apache Spark againstApache Flink and describe the points, that we have consideredfor our comparison. Chapter V describes our chosen showcaseand important aspects of the Apache Flink framework, whichwere used to implement it. In chapter VI we present ourbenchmark of the implemented showcase in Apache Storm andApache Flink. Finally, we draw our conclusion in chapter VII.

II. APACHE TEZ

Apache Tez is an Apache Top-Level project since 2014.Through its graduation to a Top-Level project, it gained a lot ofattention and support to establish usage among companies likeMicrosoft, Yahoo, LinkedIn and Netflix. [1] It provides supportfor high performance batch and interactive data processingapplications and improves the general Map Reduce paradigmin terms of performance, while maintaining the ability toscale to petabytes of data. [2] Tez by itself is neither a data-flow runtime nor an engine, but can be used to leveragethe development of such a runtime or engine. By proposinga reusable, flexible and scafolding application programminginterface (API) Tez allows frameworks to model the logicaland physical semantics of their data-flow graphs. [3], [4]The data-flow is described as directed acyclic graph (DAG)to enable a finer grained description of the vertex and edgeresponsibilities and relations. In addition to the stated features,Tez provides full fledged support for Apache Hadoop and YetAnother Resource Negotiator (YARN) compatibility. [2]

A. MotivationWith the shift from the tightly coupled Map Reduce data

processing engine in Apache Hadoop 1.0, to the flexibleYARN architecture in Apache Hadoop 2, Tez took the chanceto represent an alternative to the often used data processingprogramming model Map Reduce. [3], [5] Tez tackles thesteadily rising need of shorter run- and response-time, whileperforming a batch process with petabytes of data. Tez pro-vides the following key additions: [2], [3]

• Improved Map Reduce in terms of performance andresource usage

• Compatibility to existing Map Reduce Jobs• Fit-to-purpose API for individual data access applications• YARN compatible and easy to integrate in Apache

Hadoop

B. YARN and TezAs stated in II-A, Tez can be used alongside Map Reduce

since Apache Hadoop 2. The general purpose layer YARNseparates the resource allocation and management from MapReduce, which claimed all these responsibilities in ApacheHadoop 1. [5] Therefore, allowing multiple application typesto run on top of YARN and alongside Map Reduce. Further-more the restriction to rely only on Map Reduce is resolved,

37

as the resource management is now handled by YARN. YARNcontainerizes the cluster resources and distributes them toclients, if requested. The most notable components in YARNare:

1) Resource Manager: Resource Managers (RM) exposeinterfaces towards clients, Application Masters (AM) andNode Managers (NM). [5] Clients can submit applicationsto the RM, AM’s dynamically negotiate access to resources,while Node Managers provide functionality to monitor thecluster and resource management. [5]

2) Node Manager: Node Managers are the ”worker dae-mons” in YARN. They monitor the execution, resource usage(CPU, RAM) and provide a set of services to containers. [5]After the registration at the RM a NM heartbeats its statusperiodically and receives instructions. [5]

3) Application Master: AM’s request cluster resources andexpress their demand in required containers, resources percontainer (CPU cores, RAM), locality preferences and priorityrequests within the application. [5] As seen in figure 1 Tezis above the YARN layer and beyond the data processingapplications like Apache Hive, Apache Pig and Cascading.It is fully YARN compatible in terms of requesting clusterresources, providing an AM and reusing containers. [5] As itrelies on YARN, Tez cannot be used as standalone and has tobe used in conjunction with Apache Hadoop.1

Fig. 1. Tez integration in Hadoop YARN [3]

C. DAG modeling with Tez API

Modeling a DAG with the Tez API is straightforward andeasy to establish. Every component is expressed within theTez API and can be constructed with it. The following corecomponents of the Tez API are used to express a DAG:

• DAG: Describes the Tez job with all its vertices andedges.

• Vertex: Contains the processing logic to transform data.• Edge: Describes the data-flow between vertices. Further-

more, additional parameters allow a finer grained controlto distribute the data.

1https://tez.apache.org/install.html

DAG dag = new DAG( ”DAG” )

V er t e x f i l t e r 1 = V er t e x . c r e a t e ( F i l t e r 1 . c l a s s )V e r t e x agg = V er t e x . c r e a t e ( A g g r e g a t o r . c l a s s )

Edge edge1 = Edge . c r e a t e (SCATTER GATHER,f i l t e r 1 , agg )

dag. addVer t ex ( f i l t e r 1 ). addVer t ex ( agg ). addEdge ( edge1 )

Fig. 2. Tez API example of a DAG definition

D. Tez gains over Hadoop Map Reduce

Tez expands the batch only processing of Map Reduceto batch and interactive query processing. Furthermore, thedata processing schema from map/reduce is enhanced in away that multiple reduce phases can be launched after amap phase. This improves the performance greatly since theHadoop Distributed FileSystem (HDFS) usage is kept smalland instead the data is stored in-memory if possible. [4], [6]

III. APACHE FLINK

Apache Flink is an open source distributed platform forstream and batch processing, and a top-level project of theApache Software Foundation since 2014 [7]. This platformcomes along with promising features:

1) Support for event time and out of order streams: Eventstreams rarely arrive in the chronological order in which theyare produced, especially if the streams stem from distributedsystems or devices. Usually, the application programmer hadto correct this time drift, if one would not want to acceptinaccurate results. Flink 0.10 was a pioneer for open sourceengines by supporting out of order streams and event time.

2) Expressive and easy-to-use APIs in Scala and Java: TheDataStream and DataSet APIs in Flink are available in Javaand Scala. Flink’s DataStream API has many operators whichare well known in batch processing APIs, for example map,reduce, and join. Additionally, Flink provides stream specificoperations like window, split, and connect.

3) Support for sessions and unaligned windows: Window-ing is a concept that almost all streaming systems have, such asgrouping of events based on some function of time. However,many systems like Storm hard-coded these windows, meaningthat they are connected with the internal checkpointing mech-anism of the system. In Flink windowing is decoupled fromfault tolerance, allowing richer forms of windows, for examplesessions.

4) Consistency, fault tolerance, and high availability: In thepresence of failures Flink guarantees consistent state updates,and consistent data movement between selected sources andsinks, for example consistent dataflow between Kafka andHDFS. Flink also supports master failover, eliminating anysingle point of failure.

38

5) Low latency and high throughput: Flink has beenclocked at 1.5 million events per second per core, and hashad observed latencies in the 25 millisecond range for jobsthat include network data shuffling. By using a tuning knob,the latency-throughput tradeoff can be navigated, making thesystem suitable for both high-throughput data ingestion andtransformations, as well as ultra low latency (millisecondrange) applications [8].

6) Integration: The Apache Flink project is a bundle thatcontains a Hadoop Map Reduce compatibility layer, a Stormcompatibility layer, and libraries for machine learning andgraph processing. A variety of open source systems can beintegrated with Flink for data input and output, such as HDFS,Kafka, Elasticsearch, HBase and others, and for deployment,YARN. It is also possible to use Flink as execution enginefor other frameworks, for example Cascading, Apache Beamincubating.

7) Support for batch: Batch processing is a special caseof stream processing in Flink, because finite data sources arejust streams that happen to end. Flink offers a full toolset forbatch processing with a dedicated DataSet API and librariesfor machine learning and graph processing. Additionally, Flinkcontains several batch-specific optimizations for scheduling,memory management, and query optimization, matching andeven out-performing dedicated batch processing engines inbatch use cases [9].

8) Developer productivity and operational simplicity: Flinkruns in several environments, such as local, distributed andYARN mode. Local execution within an IDE is significantlyeasy in regards to developing and debugging of Flink appli-cations. In distributed setups, Flink runs at massive scale-out.The YARN mode allows users to bring up Flink clusters ina matter of seconds. A REST interface serves as monitoringmetrics of jobs and the system as a whole. These metrics aredisplayed through a build-in web dashboard.

A. Apache Kafka Integration

Flink is a storage-agnostic stream processing framework,and is often used in conjunction with data storage or brokeringsystems. A typical architectural pattern is to use Flink inconjunction with Apache Kafka to:

1) Ingest data into other systems such as HDFS, databases,or search indices and create continuous ETL pipelines.

2) Perform analytics directly on the moving data to createalerts, dashboards, or power operational applicationsobviating the need for ingestion and ETL.

3) Perform machine learning on streams by continuouslybuilding models of the events as they arrive and usingthe model to serve online recommendations. Flink is alsoa full-fledged system for batch processing, it can be usedfor applications on top of static data. Figure 3 providesan overview of where Flink applications might fit in abroader stack.

Fig. 3. Flink with Kafka integration [8]

Flink is being used for various use cases, such as monitoringof equipment, analysis of machine-generated logs, analyticson customer activity data, online recommender systems, andgraph processing applications [10].

B. Streaming and Micro-BatchingThe technologies for distributed big data platforms have

become more refined and mature with expanding demand forscalable solutions, so too have technologies for streaming dataflow and real time applications been evolving. Apache Stormwas a pioneer in real time processing with true streaming.Apache Spark approximated real time through micro-batchingmaking it possible to provide exactly once computing alongwith the advantages of in-memory processing. Apache Flinkhas developed software that, like Storm, is a real-time streamprocessor but, like Spark, has exactly once capability. Stream-ing and Micro-Batching differ in their way to receive andprocess arriving data. In the following section we give anoverview how streaming and micro-batching are defined, andin what cases streaming has to be considered over micro-batching.

1) Streaming:• Input arrives as records in a particular sequence• Output is needed as soon as possible (but not sooner

as the sequence has first to be verified)• Output never needs to be modified once it is written

2) Micro-Batching:• Input is divided into batches, by number of records

or by time• As many input batches as are necessary (but a finite

number) are retained• A batch program is run against retained batches,

with stored state• A new state and all of the rows of output are

recorded as streaming outputIn micro-batching states must be enumerated, serialized andpreserved across batches, which is not easy to do and whichmakes it difficult to meet the soon as possible need of truestreaming [11]. Often it does not matter what approach to use.As an example, the computation of rolling monthly total saleson daily intervals. An implementation for this computes dailysums and then adds. Here, true steaming is not essential anda micro-batch based approach will suffice. There are somesituations, however, that need a true streaming process. In

39

many real world situations, the input to the program from theprocess or event of interest is a steady stream and essentiallynever stops. If we want to compute the rolling monthly time-on-site for visitors to a website we now actually need truestreaming. The number of visits might be updated in a settime frame, but the problem is that the time-on-site dependson definition of a session. Recognizing the start and stop of asession or a series of activities between periods of inactivityis not that easy, as there are no natural boundaries that can beused to define batches. Therefore, a true streaming architectureis required. Another use case that profits from streaminganalysis is anomaly detection.

IV. APACHE SPARK STREAMING VERSUS APACHE FLINK -A COMPARISON

Implementing a stream processing framework such asApache Flink or Apache Spark goes along side with analyzingtheir respective properties. In this chapter, properties likeprogramming and runtime model, state management, as wellas message delivery guarantees and fault tolerance of bothframeworks will be inspected.

A. Programming and Runtime ModelThe programming model provided by a platform determines

its expressiveness and its features, and it should be capableto handle all possible use-cases for the application. ApacheFlink uses native or true streaming. As mentioned before,all incoming events are processed on the time of theirarrival, one by one. An advantage of native streaming isthe expressiveness. It is not limited by any abstraction overits incoming data, because it takes in the stream the wayit is. The achievable latencies of these systems are betterthan those of its micro-batching companions, because ofthe immediate processing of records on arrival. Statefuloperations are much easier to implement, as to why willbe covered in state management. Usually, native streamingsystems have lower throughput, and fault tolerance is muchmore expensive as it has to consider every single record.Another challenge is load-balancing. For example, if data ispartitioned by a key and has to be processed and the processingof some key of the partition is more resource intensive forany reason, this partition quickly becomes the jobs bottleneck.

Apache Spark Streaming implements micro-batching toachieve streaming. Instead of processing each record onarrival, short batches are created from incoming records andgo through the system. These batches are created according topre-defined time constant, typically every couple of seconds.However, splitting a stream into micro-batches inevitablyreduces system expressiveness. Also, some operations,especially state management or joins and splits, are muchharder to implement as the system has to manipulate thewhole batch. Unfortunately, the batch interval connects twothings which should never be connected - an infrastructureproperty and a business logic [12]. On the contrary, faulttolerance and load balancing are much easier to implement as

in native streaming, as every batch is send to a worker node.If something goes wrong it just as to resend the batch and/oruse another worker node.

B. State Management

State management includes maintaining, accessing andupdating state informations in the system. Most of thestreaming applications have some kind of state, like statefulbolts in Storm (Version 2.0.0) or stateful operators in Flink.Where stateless operations have just an input, processingand an output, stateful operations have an input and a state,then processing and then an output with a modified state.This state has to be managed, persisted and in case of failureto be recreated. The recreation of the state needs exactlyonce guarantee, where some of the records can be replayedmultiple times. Although, it is also possible to work withlesser guarantees, such as at least once which is used inApache Storm.

Spark Streaming manages a state as just another micro-batched stream. During the processing of each micro-batchSpark takes a current state and a function representing theoperation, and the result is a processed micro-batch andan updated state. Flink provides stateful operators that canbe thought of as an embedded key/value store. The state ispartitioned and distributed strictly together with the streamsthat are read by the stateful operators. Thus, access to thekey/value state is only possible on keyed streams, after akeyBy function, and is restricted to the values associatedwith the current events key. Aligning the keys of streams andstate makes sure that all state updates are local operations,guaranteeing consistency without transaction overhead. Thisalignment also allows Flink to redistribute the state and adjustthe stream partitioning transparently.

C. Message Delivery Guarantees and Fault Tolerance

There are a couple of message delivery guarantees, likeat most once, at least once and exactly once. At mostonce delivery means that for each message handed to themechanism, that message is delivered a maximum of onetime, so there is the danger of messages being lost. If eachmessage is potentially send on multiple attempts, so that atleast one attempt is successful, the system has at least oncedelivery. Messages can be duplicated, but will never be lost.And finally, exactly once delivery is when for each messagehanded to the mechanism exactly one delivery is made to therecipient, the message can neither be lost nor duplicated.

The reasons that systems need message delivery guarantessis that failures can and will happen, especially in distributedsystems. A platform should be able to recover from failuresand resume from the last successful state without falsifyingthe results. In streaming systems fault tolerance is definitelyharder to achieve than in batch systems, because with batch

40

processing systems the failed part of the computation can berestarted without further ado. The reason why it is harder instreaming scenarios is that data are still incoming and jobscan run all day every day. We also have to consider stateconsistency, because at some point the system has to startreplaying events, and not all state operations are idempotent.

Spark Streaming has actually a simple idea. Micro batchesare processed on various worker nodes, where each micro-batch may either succeed or fail. At a failure, the microbatch can be simply recomputed, as they are persistent andimmutable, achieving exactly once delivery relatively easy.

Flink implements fault tolerance using a combination ofstream replay and checkpointing. A checkpoint is related toa specific point in each of the input streams along with thecorresponding state for each of the operators. A streamingdataflow can be resumed from a checkpoint while maintainingconsistency (exactly-once processing semantics) by restoringthe state of the operators and replaying the events fromthe point of the checkpoint. The checkpoint interval is ameans of trading off the overhead of fault tolerance duringexecution with the recovery time (the number of eventsthat need to be replayed). The checkpointing mechanismis described in Lightweight Asynchronous Snapshots forDistributed Dataflows [13], which is inspired by the standardChandy-Lamport-Algorithm [14].

V. DEBS CHALLENGE 2016 QUERY 2 IMPLEMENTATION

As showcase implementation we have chosen the Dis-tributed Event-Based System (DEBS) challenge 2016. In detailwe implemented the large communities of interested querywith the Apache Flink Streaming Engine. 2

A. Large communities of interest query

For further readings the large communities of interest queryis referenced as Query 2. Query 2 addresses the change ofinterests within large communities. Main goal of Query 2 isthe continuous processing of results, while data is read fromthree different data sources. Query 2 computes the top k ofthe largest connected community, who liked a comment. Thecomments to evaluate are defined by d, where d represents theduration of an active time window. [15]

B. Apache Flink API Overview

The implementation of Query 2 with Apache Flink is doneby separating the individual tasks that are needed to fulfillQuery 2. The following Apache Flink components are neededto model the data-flow:

• Data Source: The data source represents the start of adata-flow model. It allows the definition of which inputsshould be read and forwarded to data processor compo-nents. Apache Flink offers built-in formats to create adata set from a data source. Supported data sources from

2http://www.ics.uci.edu/ debs2016/call-grand-challenge.html

which can be read are for example text-based, collection-based, and user-defined sources.

• Data Processor: Data processors perform various trans-formations on input data. Once the input data is processedthe output is defined as new data processor stream.Multiple built-in transformations like aggregations, map,window, split, filter, reduce, join and keyBy can be usedto perform and control the data-flow.

• Data Sink: Data sinks are used to end a branch or thewhole DAG. Data sinks support the same formats likedata sources.

1) Stream and Batch Environments: Stream and batchenvironments decide if the Streaming or Batch API is usedwithin Apache Flink. Both share common operations, butdiffer greatly in the behavior of the DAG. The streamingenvironment provides continuous data streaming withDataStreams, while the batch environment provides batchprocessing with DataSets. A DataSet or DataStreamdescribes the data processor within the DAG. Due to usingtwo different kinds of APIs for streaming and batching, thesame software can not be interchanged without modification.

2) Notion of Time: As there are different notions of time,Apache Flink offers multiple concepts to handle them. De-pending on the use case, either the system time of the workingmachine or the timestamp within an event can be used, todetermine the occurrence, of said event. Based on those twodecisions, Apache Flink provides three concepts: [16], [17]

• Event Time: Event time makes use of timestamps, thatare defined inside the events. Those timestamps maybe created on a different machine and thus completelyindependent of the working machine. The downside ofevent time is, that it contains a certain level of latency, dueto having to wait for late events or out-of-order events.

• Operation Time: Operation time makes use of the sys-tem time on the working machine. In contrast to eventtime the throughput is higher, since the working machinemust not wait until a specific event arrives. The downsideof the operation time is that the in-order processing cannot be guaranteed, as latencies are not considered.

• Ingestion Time: Ingestion time describes the time whenthe event was ingested into the system. At ingestion thetimestamp is assigned to the event and all successivemachines progress onto that timestamp. Using theingestion time avoids falsely assigned timestamps andprocessing due to drifting clocks.However, Ingestiontime is not able handle any out-of-order events or latedata.

3) Data-flow Operators: Apache Flink provides a large setof data-flow operators, that can be used to control the flow ofdata within the DAG. In comparison to Apache Storm thereare operators, that are similar groupings like shuffle-, field- andall-grouping. In addition to the groupings, Apache Flink offers

41

data transformation and data-flow operators, than can be usedin combination. A combination may be used to merge twodifferent streams into a single stream under a given condition.For example the merged streams output integer numbers, thatare summed and only even numbers are processed further inthe newly merged stream.

C. Query 2 with Apache FlinkAs seen in figure 4 the implementation of Query 2

contains a DataSoure, DataProcessor and DataSinkcomponent. As runtime environment the stream environmentis set, as the DEBS Challenge requires continuous streamprocessing. The FileReaderStream in figure 4 reads datafrom the comment, like and friendship file. The data is parsedand immediately ordered within the FileReaderStreamand forwarded to the WindowScoreStream. TheDataSource is implemented with the built-in text-baseddata source. The WindowScoreStream is configured assliding window, where the parameter d (described in V) isused as window duration. The window length is estimatedwith the event timestamp, as the notion of time is set toEvent Time. Furthermore each window is processed and usedto calculate the top k results. If the top k has changed, theresults are forwarded to the ResultSink.

1) FileReaderStream: The FileReaderStream heavilyrelies on the built-in text-based data source. As ApacheFlink provides common functionality, to set and read plaintext files as data source. Before the data is emitted to theWindowScoreStream, data mappers map the plain stringsto complex objects for further processing.

2) WindowScoreStream: The WindowScoreStreamis directly fed with the FileReaderStream outputand extracts the timestamps from the given events. Thetimestamps are used to calculate the window. Inside theWindowScoreStream the result is processed with customwritten code. As for the graph processing, the Bron-KerboschAlgorithm is used, to calculate the largest connected cliqueof a given sub-graph.

3) ResultSink: The ResultSink is based on the built-infunctionality to write the output from a connected stream toa text file. Every change in the computed top k is written tothe output file.

Apache Flink offers a rich API to define and model DAG’s,that are capable to solve various tasks. Each built-in functioncan be derived and extended with custom functionality, tofulfill a given requirement.

VI. SUITABILITY COMPARISON OF APACHE FLINK ANDSTORM

Alongside the DEBS Grand Challenge implementationwith Apache Flink, parts of the source code were reusedand adopted to the Apache Storm framework. Apache Storm

was chosen as framework, as it provides native streaminglike Apache Flink. This chapter gives a brief overview of theperformance and difficulties we encountered, while using bothframeworks for the DEBS Grand Challenge 2016. Moreover,we used a feature that allowed us to run a native ApacheStorm application onto the Flink engine.

The measurements were done on dedicated hardware withthe following specifications:

• Intel I7 5820k @ 3,3GHz• 32GB RAM• 512GB SSD• Windows 10 Professional 64 bit

A. Transition from Apache Flink to StormBoth frameworks rely on a nearly identically programming

model in terms of describing, building and binding streamstogether to a larger system. The transition from one frameworkto the other was therefore relatively simple to achieve. Themost notable difficulties, with the process of transferring thetopologies, were the missing stream operators and windowing-functionality in Apache Storm. The WindowScoreStreamin Apache Flink is backed by a sliding window and processesthe events according to the window. Apache Storm offerstumbling and sliding window capabilities that are comparablewith the windows in Apache Flink. As for Apache Storm wewere not able to utilize the window implementation withoutgetting events, that are processed in a mixed order. Despitethe ordered event streams in both implementations, we hadno success to not get events, that are recognized as lateevents with Apache Storm. To address this problem, we hadto implement our own windowing function in Apache Storm.Furthermore, the high abstraction layer of Spouts and Boltsin Apache Storm led us to write a lot more boilerplate code,in order to achieve the same tasks, as in Apache Flink.

Apache Flink offers Storm compatibility and thus is able totranslate a native Storm topology with Spouts and Bolts intoa Flink topology. Storm Spouts and Bolts are embedded intoFlink DataStreams and deployed onto the Flink engine [18].For our benchmark, we compare both frameworks based onour Storm topology, running as native Storm and Flink appli-cation. This guarantees a fair basis for both frameworks, as theused source code is identical. The native Flink implementationdiffers greatly from the native Storm implementation and thusdoes not guarantee a fair basis for our benchmark.

B. Benchmark: Storm topology with the native Storm andFlink engine

The benchmark was done with the native and translatedStorm topology. The translated Storm topology was auto-matically generated by Flink. The translation was simplydone, by binding a Flink library to the Storm applicationand changing the StormTopology to a FlinkTopology. Toachieve the automatic translation, only a few lines of codehave to be changed. As metric we used the throughput per

42

Fig. 4. Query 2 StreamGraph

second accordingly to the processed messages. The describedparameters in chapter V, are set to 30 days for d and 3top-k results for k. As seen in figure 5 Flink achieves anoverall higher throughput than Storm. The higher throughputwith Flink, can be attributed to the different approach ofthe fault tolerance mechanism. We assume that the per tupleacknowledgment in Storm, is a more heavy lifting task,than the checkpoint acknowledgment mechanism in Flink.Deactivating the fault tolerance mechanism in Storm, led to anapproximately throughput increase of 15%, but the throughputof Flink could not be achieved.

0

2000

4000

6000

8000

10000

12000

14000

0 200000 400000 600000 800000 1x106

Mes

sage

s pe

r Sec

ond

Processed Messages

FlinkStorm

Fig. 5. Query 2: Storm topology running on Storm and Flink engine

C. Benchmark: Native Flink App

Besides the benchmark of the native and translated Stormtopology, we measured our native Flink implementation ofQuery 2 separately. As already mentioned we did this, as thenative implementation differs greatly in the topology and usedAPIs. The data mappers and graph processing algorithm isidentical to the one used in the Storm application. As seenin figure 6 the native implementation with Flink has a higherthroughput than our Storm and translated implementations. Atthis point, we can not exclude that the higher throughput isdue to code discrepancies between the implementations or thefact, that we used the Flink API directly.

0

5000

10000

15000

20000

25000

30000

0 200000 400000 600000 800000 1x106

Mes

sage

s pe

r Sec

ond

Processed Messages

Flink

Fig. 6. Query 2: Native Flink Application

VII. CONCLUSION

In this paper we introduced two frameworks that can beused instead of MapReduce or Spark. Then we comparedApache Flink with Apache Spark Streaming in theory, andfollowed with an implementation of the DEBS 2016 GrandChallenge Query 2 with Flink. At this point we compared ourFlink implementation with our Storm implementation. ApacheTez improves the Map Reduce paradigm and promises generalimprovements. Due to the constantly increasing demands inthe processing of historical data, the arise of new frameworksand programming models is a logical consequence ofit. Innovations in IT-infrastructures and cheaper and yetpowerful commodity hardware are an additional catalyst forthis evolution, as the frameworks and programming modelsare adapted to these.

Apache Flink resides somewhere between Apache Sparkand Storm. It combines functionalities and ideas of bothframeworks into a sole contender, giving it the advantage of ageneral purpose solution for streaming and batch tasks. Flinkappears to be faster in streaming and batch processing thanStorm or Spark, making it attractive for real time applicationand anomaly detection, as well as for system monitoring. Asof now, the biggest letdown of Flink seems to be its maturitylevel. Besides the status of a recently released framework, itmay become industrial standard like Apache Storm and Spark.

43

The implemented showcase was easier to achieve withApache Flink than with Apache Storm, because Flink offers aricher API to work directly on the data streams. The alreadybuilt-in stream operations led to a faster implementationof our showcase and in less verbose code in contrast toStorm. In Storm, we had to implement even basic dataoperations ourselves. Due to the high abstraction layer ofStorm expressed in Spouts and Bolts, the programming modelenforces a lot of boilerplate code. The Flink programmingmodel is a lot more elegant and less verbose, as everythingis achieved directly with API calls. Hence the codingstyle in Flink is more similar to Apache Spark or ApacheTrident, where everything is expressed with a clean interface.Furthermore, the possibility to translate a native Stormapplication into a Flink application is a neat feature, as itallows fast prototyping and testing. An already written Stormapplication can be executed on the Flink engine, withouttaking any risks.

Does it have to be MapReduce or Spark all the time?We do not think so. With Apache Tez and Apache Flinkwe have some widely used frameworks that can fulfill thesame functionalities as MapReduce or Spark. However, we cannot give a recommendation in what scenarios to use whichframework. Although we have noticed that at least ApacheFlink can be a contender amongst other stream processingframeworks, and outshines Apache Storm and Apache Sparkin some aspects, users could still be better of with Storm,Spark, or Samza. It clearly depends on what functionalitiesand also which level of maturity the framework should have.

REFERENCES

[1] Bikes Saha, “Apache tez graduates to top-level,” 2014. [Online].Available: http://hortonworks.com/blog/apache-tez-graduates/

[2] “Apache tez: Overview.” [Online]. Available:http://hortonworks.com/apache/tez/

[3] B. Saha, H. Shah, S. Seth, G. Vijayaraghavan, A. Murthy, and C. Curino,“Apache tez,” in the 2015 ACM SIGMOD International Conference,T. Sellis, S. B. Davidson, and Z. Ives, Eds., pp. 1357–1369.

[4] “Apache tez: Introduction,” 2016. [Online]. Available:https://tez.apache.org/

[5] V. K. Vavilapalli, S. Seth, B. Saha, C. Curino, O. O’Malley, S. Radia,B. Reed, E. Baldeschwieler, A. C. Murthy, C. Douglas, S. Agarwal,M. Konar, R. Evans, T. Graves, J. Lowe, and H. Shah, “Apache hadoopyarn,” in the 4th annual Symposium, G. Lohman, Ed., pp. 1–16.

[6] R. Singh and P. J. Kaur, “Analyzing performance of apache tez andmapreduce with hadoop multinode cluster on amazon cloud,” Journalof Big Data, vol. 3, no. 1, p. 34, 2016.

[7] heise.de, “Big data: Apache flink wird top-level-projekt.” [Online].Available: https://www.heise.de/developer/meldung/Big-Data-Apache-Flink-wird-Top-Level-Projekt-2516177.html

[8] K. Fabian Hueske, “The essential guide tostreaming-first processing with apache flink.” [Online].Available: https://www.mapr.com/blog/essential-guide-streaming-first-processing-apache-flink

[9] K.M.J. Jacobs, “Apache flink: Distributed stream dataprocessing.” [Online]. Available: https://www.data-blogger.com/wp-content/uploads/2016/08/report.pdf

[10] “Powered by apache flink.” [Online]. Available:https://flink.apache.org/poweredby.html

[11] Kostas Tzoumas, Stephan Ewen, “Real-time stream pro-cessing: The next step for apache flink.” [Online].Available: https://www.confluent.io/blog/real-time-stream-processing-the-next-step-for-apache-flink/

[12] Petr Zapletal, “Comparison of apache stream pro-cessing frameworks part 2.” [Online]. Avail-able: http://www.cakesolutions.net/teamblogs/comparison-of-apache-stream-processing-frameworks-part-2

[13] Paris Carbone, Gyula Fra, Stephan Ewen,Seif Haridi,Kostas Tzoumas,“Lightweight asynchronous snapshots for distributed dataflows.”[Online]. Available: https://arxiv.org/pdf/1506.08603v1.pdf

[14] L. K. Mani Chandy, “Distributed snapshots: Determiningglobal states of distributed systems.” [Online]. Available:http://lamport.azurewebsites.net/pubs/chandy.pdf

[15] V. Gulisano, Z. Jerzak, S. Voulgaris, and H. Ziekow, “The debs 2016grand challenge,” in the 10th ACM International Conference, A. Gal,M. Weidlich, V. Kalogeraki, and N. Venkasubramanian, Eds., pp. 289–292.

[16] Stephan Ewen, “Time and order in streams:Different notions of time.” [Online]. Available:https://cwiki.apache.org/confluence/display/FLINK/Time+and+Order+in+Streams

[17] “Event time: Event time / processing time / ingestiontime.” [Online]. Available: https://ci.apache.org/projects/flink/flink-docs-release-1.2/dev/event time.html

[18] Matthias J. Sax, “Storm compatibility in apache flink: Howto run existing storm topologies on flink.” [Online]. Available:https://flink.apache.org/news/2015/12/11/storm-compatibility.html

[19] T. Sellis, S. B. Davidson, and Z. Ives, Eds., the 2015 ACM SIGMODInternational Conference.

44

Datenanaylse mit Apache SolrCedric Schweizer, Peter Wursthorn

Fakultat InformatikHochschule Furtwangen

Furtwangen, DeutschlandE-Mail: {cedric.schweizer, peter.wursthorn}@hs-furtwangen.de

Zusammenfassung—Die Verarbeitung und Analyse von großen

Datenmengen gewinnt durch die standige Zunahme an Mas-

sendaten immer mehr an Bedeutung. Durch die Verknupfung

unterschiedlicher Datenquellen und Datensatzen wird ein Er-

kenntnisgewinn erhofft, der beispielsweise zur Beantwortung wis-

senschaftlicher Fragestellungen, zur Kriminalitatsbekampfung

oder zur Erlangung von Wettbewerbsvorteilen beitragen kann.

In der vorliegenden Arbeit wird der Fragestellung nachgegangen,

inwieweit die Datenanalyse von umfangreichen Datenmengen

durch das Suchmaschinen-Framework Apache Solr unterstutzt

wird. Dabei werden unterschiedliche Aspekte vom allgemeinen

Datenimport bis zu spezifischen Trendanalysen untersucht, eva-

luiert und mit alternativen Losungen verglichen. Zur Losung

der Problemstellung wurde ein empirisches Vorgehen verfolgt.

Ein Datenbestand, bestehend aus uber zwei Millionen Webseiten-

Abbildern, wurde uber eine eigens fur diesen Zweck entwickelte

Anwendung zur Solr-Indizierung vorverarbeitet und importiert.

Daraufhin wurde die Machbarkeit von unterschiedlichen Fra-

gestellungen aus den Bereichen der Worthaufigkeiten, Sprach-

sowie Trendanalysen praxisnah untersucht. Im Ergebnis zeigt

sich, dass serverseitig, allein durch die Solr-Plattform, die meisten

analytischen Fragestellungen nicht zufriedenstellend bearbeitet

werden konnen. Die Starken von Solr liegen in einer hochautoma-

tisierbaren Datenzufuhrung, sowie in einer umfangreichen Voll-

textsuche mit der diverse Anwendungsszenarien im Bereich von

Suchfunktionalitaten abgedeckt werden. Die Schwachen hingegen

liegen in der Verknupfung und Aggregation von Datensatzen, was

in der Datenanalyse jedoch ein zentraler Bestandteil darstellt.

Zwar gibt es einige Funktionalitaten die hierzu angewendet

werden konnen, jedoch ist dies meist eine Zweckentfremdung

des ursprunglichen Anwendungsgebiets, wodurch oft keine aus-

reichende Leistungsfahigkeit gegeben ist.

Schlusselworter—Apache Solr, Datenanalyse, Big Data,

Hadoop HDFS, Cloudera

I. EINLEITUNG

Das Solr-Framework wird hauptsachlich im Bereich vonSuchfunktionalitaten verwendet. Aufgrund des breiten Funkti-onsumfangs und des generellen Aufbaus als Dokumentenda-tenbank liegt die Anwendung im Bereich der Datenanalysenahe. In diesem Kontext untersucht die vorliegende Arbeitdie Eignung von Solr praxisnah anhand eines Datenbestandsvon uber zwei Millionen Webseiten-Abbildern, die innerhalbeines Hadoop Distributed File System (HDFS) abgelegt sind.Als Ausfuhrungsplattform kommt dabei ein Hochleistungs-rechner mit eingerichteter Cloudera-Distribution zum Einsatz.Die konkrete Problemstellung ist recht offen gestaltet, dasich das Themengebiet der Datenanalyse nicht auf wenigeAbfragen reduzieren lasst. Generell kann die praktische Arbeitin drei nacheinander folgende Schritte, dem Datenimport,

dem Durchfuhren von Analysen sowie der Bewertung derErgebnisse, unterteilt werden. Dabei teilt sich jeder Schrittin weitere Teilschritte auf, deren Erlauterung im Laufe dieserArbeit erfolgt.

Die Struktur folgt dem thematischen Verlauf derDurchfuhrung der empirischen Untersuchung. Das zweiteKapitel beschreibt die Funktionsweise und Architektur vonSolr, da spatere Kapitel auf diesen Grundlagen aufbauen.Im dritten Kapitel wird die Datenindizierung durch Solranalysiert. Dabei erfolgt die Prasentation einer eigens furdiesen Zweck entwickelten Anwendung. Im vierten Kapitelfolgt die Betrachtung durchgefuhrter Abfragen und Analysenmit jeweiligen Bewertungen zur Eignung von Solr. Dasfunfte Kapitel gibt einen Ausblick auf noch zu beantwortendeFragestellungen. Abschließend folgt im sechsten Kapitel einFazit.

II. GRUNDLAGEN SOLR

Bei Solr handelt es sich um eine in Java geschriebeneServeranwendung zur Umsetzung von Suchanfragen auf einenindizierten Datenbestand. Das quelloffene Projekt wird durchdie Apache Software Foundation verwaltet und es belegt unterden Plattformen zur Umsetzung von Suchanfragen aktuell denzweiten Rang in Sachen Verbreitung [1]. Besondere Merkmalesind die ausgepragten Moglichkeiten zur Volltextsuche, diestandardisierten Schnittstellen, die Kompatibilitat zu Hadoop-Komponenten sowie die hohe Skalier- und Verteilbarkeit.

Fur das Verstandnis der Kapitel zur Umsetzung des Daten-imports und der durchgefuhrten Analysen ist grundlegendesWissen uber die Architektur, Arbeitsweise und Funktiona-litaten von Solr notwendig. Die genannten Themengebietewerden nachfolgend auf einem Abstraktionsniveau, entspre-chend der jeweiligen Anwendbarkeit im spateren Verlauf,behandelt.

A. Ubersicht der Solr-Architektur

Bevor detailliert auf die Interaktion der einzelnen Kom-ponenten der Solr-Plattform eingegangen wird, erfolgt indiesem Unterkapitel die Einfuhrung in den grundlegendenAufbau der Architektur. Dabei orientieren sich nachfolgendeErlauterungen an der Abbildung 1.

Die Solr-Plattform baut intern auf der Apache-Lucene-Programmbibliothek auf. Diese bildet die Basis zur Umsetzungder Volltextsuche und damit den Kern von Solr. Dieser Kernwird durch Schnittstellen und Verarbeitungsroutinen erweitert.

45

Ein zentraler Bestandteil der Architektur stellt der Datenindexdar, da Anfragen auf diesem bearbeitet werden und er dadurchden Informationsgehalt des Systems abbildet.

Eine Anfrage wird von einem externen System oder von ei-nem Anwender uber einen Webbrowser gestellt. Die Request-Handler-Komponente bearbeitet diese Anfrage nun entspre-chend ihrer Parameter mithilfe der Lucene-Bibliothek unddes Datenindexes. Das Ergebnis der Anfrage wird durch ei-ne Response-Writer-Komponente aufbereitet und als Antwortubermittelt. Der Datenindex kann durch die Data-Import-Handler-Komponente automatisiert mit einer externen Da-tenquelle synchronisiert werden. Uber die Update-Handler-Komponente kann der Datenindex hingegen manuell verwaltetwerden, indem entsprechend formatierte Dokumente an dieseSchnittstelle weitergeleitet werden.

Anfrage Antwort

Solr-Plattform

Lucene-Kern

Response-WriterRequest-Handler

Data-Import-Handler

Daten-Quelle

Pull

Update-Handler

Push

Index

Abbildung 1. Abstrahierte Solr-Architektur (i.A.a. [2])

B. Anfragen in Solr

In Solr sind an der Bearbeitung einer Anfrage unter-schiedliche Komponenten und Erweiterungen beteiligt, dieim nachfolgenden naher spezifiziert werden. Dabei wird sichauf die Komponenten beschrankt, die eine Schnittstelle zumAnwender besitzen und dementsprechend fur die Nutzungvon Solr relevant sind. Die Abbildung 2 zeigt beispielhaftden Aufbau einer Anfrage, wobei sich die Nummerierung dereinzelnen Bestandteile auf die nachfolgenden Komponentenbezieht.

1) Request-Handler: Diese Komponenten fungieren alsSchnittstelle fur Suchanfragen externer Systeme und Anwen-der. Dabei gibt es viele unterschiedliche konkrete Imple-mentierungen fur unterschiedliche Anwendungsgebiete. Bei-spielsweise kann es sich um klassische Auswahlabfragen, umanalytische Abfragen oder um Abfragen, die an ein bestimmtesZielsystem angepasst sind, handeln. Die einzelnen Request-

Handler konnen uber eine jeweils individuelle URL (1) ange-sprochen werden.

2) Search-Component: Die Suchkomponenten werden in-nerhalb der Request-Handler spezifiziert und verwendet. Siestellen die eigentlichen Routinen, die auf den Datenindexeinwirken, dar. Dabei konnen sie durch den Anwender uberdie Anfrage-URL (2) als Parameter spezifiziert werden. Somitkann ein Request-Handler dynamisch fur unterschiedliche Ein-satzzwecke genutzt werden, da Funktionalitaten des Handlerspipelinebasiert hintereinandergeschaltet werden. Die Such-komponenten konfigurieren somit den individuellen Request-Handler, wobei es auch standardisierte Suchkomponenten gibt,die von allen Request-Handlern unterstutzt werden.

3) Response-Writer: Diese Komponenten transformierendie Antwort einer Anfrage entsprechend unterschiedlicherAuszeichnungssprachen. Der Anwender kann die Antwortseiner Anfrage beispielsweise im JSON-, XML- oder CSV-Format erhalten. Uber einen URL-Parameter (3) bei derSuchanfrage kann der gewunschte Response-Writer aktiviertwerden.

/select?http://localhost:8983/solr & &wt=json q=word stats=true

(Basis-URL) (1) (2) (3)

Abbildung 2. URL-Schnittstelle fur Anfragen

C. Dokumentenschema

Solr arbeitet mit einem dokumentenorientierten Schema.Jedes Dokument teilt sich in Felder und zugehorige Werteauf. Das Schema der Dokumente sollte dabei aus Performanz-und Integritatsgrunden manuell definiert werden, auch wenneine automatische Schemagenerierung wahrend der Indizie-rung moglich ist [3]. Die Spezifikation des Schemas erfolgtin einer Konfigurationsdatei. Dabei besitzt jedes Feld einenbestimmten Typ, der Eigenschaften und Merkmale des Feld-inhalts und wie dieser intern verwaltet wird spezifiziert.

D. Verwalten des Datenindexes

Damit auf einem Datenbestand Suchanfragen bearbeitetwerden konnen, muss dieser zuerst durch Solr indiziert wer-den. Innerhalb der Architektur sind dafur die Update-Handler-und Data-Import-Handler-Komponenten zustandig.

1) Update-Handler: Der Update-Handler stellt eine ab-strakte Schnittstelle dar, von der verschiedene, konkreteAuspragungen existieren. Dabei unterstutzen die konkretenUpdate-Handler unterschiedliche Dokumentenformate. Wiedie bisher erlauterten Schnittstellen wird auch der Update-Handler uber eine spezifizierte URL konfiguriert wobei die zuindizierenden Dokumente mittels HTTP ubertragen werden.

2) Data-Import-Handler: Der Data-Import-Handler kannmit unterschiedlichen Datenquellen wie Datenbanken undDateisystemen verbunden werden. Dadurch kann eine au-tomatisierte Synchronisation des Solr-Indexes erfolgen. ImGegensatz zu den bisherigen Schnittstellen holt sich Solr selbst

46

die Daten von der Datenquelle, so dass keine aktive Indexer-Anwendung notwendig ist.

Durch eine Konfigurationsdatei konnen fur die unterschied-lichen Data-Handler jeweils individuelle Verarbeitungskettendefiniert werden. Dabei ist beispielsweise eine Validierung,Transformierung oder Aggregierung der zu indizierenden Da-ten moglich. Die einzelnen Verarbeitungsprozesse werden all-gemein definiert und konnen daraufhin beliebig kombiniertwerden.

Die Abbildung 3 zeigt beispielhaft wie ein Indizierungs-vorgang uber die jeweiligen Indizierungsschnittstellen ausse-hen kann. Dabei zeigen sich gewisse Gemeinsamkeiten zurStruktur der Abfragen. In beiden Fallen existiert Schnittstellennach außen, die durch eine pipelinebasierte Konfigurationspezialisiert werden.

XML/update/xml

Binary/update/extract

JSON/update/json/docs

CSV/update/csv

Update-Handler

JdbcDataSource

ContentStreamDataSource

URLDataSource

FileDataSource

Data-Import-Handler

IndividualProcessor-Chain

Quelldaten

Push

Pull

Validate

Parse

Replace

Aggregate

Index

Abbildung 3. Visualisierung der Indizierungskomponenten

E. Verteilung von Solr

Im vorliegenden Projekt wurde Solr innerhalb der Cloudera-Distribution verwendet. Diese Distribution sorgt fur eine Kon-figuration und Einbettung von unterschiedlichen Komponen-ten und Plattformen in eine Hadoop-Umgebung, wobei derAnwendungsfokus auf einer hohen Verteil- und Skalierbarkeitliegt. Der Solr-Index wird dabei standardmaßig in einemHDFS abgelegt. Die Anwendung kann verteilt auf unterschied-lichen Knoten, Replikationen und Kollektionen erfolgen.

III. DATENIMPORT

Bevor mithilfe von Solr Daten analysiert werden konnen,muss zuerst ein entsprechender Index aufgebaut werden. Beidiesem Vorgang handelt es sich bereits um einen entscheiden-den Wegweiser der nachfolgenden Datenanalyse, da der Indexdie spateren Moglichkeiten limitiert. Entsprechend der offenenProblemstellung ist im vorliegenden Projekt ein moglichstuniversell einsetzbarer Index wunschenswert.

Konkret ist die Indizierung von 2.319.898 Dokumenten,die jeweils unbearbeitete Abbilder von Webseiten darstellen,gefordert. Diese Abbilder liegen innerhalb eines HDFS in derForm von Sequenzdateien vor, wobei die Speicherung circa55 GB in Anspruch nimmt.

Fur den Datenimport gilt es dementsprechend mehrereHurden zu uberwinden. Die Erstellung eines universell ein-setzbaren Schemas stellt sich als komplexe Herausforderungdar. Daraufhin schließt sich der Import einer umfangreichenDatenmenge von einem HDFS in einen Solr-Index an. Dabeimussen die Daten vorverarbeitet, bereinigt und aggregiertwerden, damit die nachfolgende Datenanalyse zu konsistentenErgebnissen kommt.

In diesem Kapitel erfolgt die Evaluation unterschiedlicherDokumentenschemata und Importansatze. Daraufhin wird eineeigens entwickelte Indexer-Anwendung vorgestellt und ana-lysiert. Im letzten Unterkapitel werden die Ergebnisse derIndexer-Anwendung naher betrachtet.

A. Evaluation unterschiedlicher Dokumentenschemata

Es erfolgte die Evaluation von unterschiedlichen Doku-mentenschemata, die ihre jeweiligen Vor- und Nachteile furunterschiedliche Anfragen mit sich bringen. Da kein einzelnesSchema gefunden wurde, das unterschiedlichste Anfragen zu-friedenstellend unterstutzt, wurden zwei Schemata ausgewahlt.Dementsprechend wird im spateren Verlauf der vorliegendenArbeit und des Projektes mit unterschiedlichen Schemata, dieredundante Daten beinhalten, gearbeitet.

1) Volltext-Schema: Die Struktur des sogenannten Volltext-Schemas kann der Tabelle I entnommen werden. Dabei wirdfur jedes Abbild einer Webseite ein einzelnes Dokument an-gelegt. Dieses enthalt Metainformationen und den komplettenWebseiteninhalt als Volltext. Die Vorteile dieses Schemassind, dass der Textzusammenhang erhalten bleibt und dassnur eine geringe Redundanz bezuglich der Speicherung vonMetainformationen vorliegt. Als mogliche Probleme werdendie Performanz spaterer Anfragen sowie die Machbarkeitanalytischer Anfragen in Bezug auf Worthaufigkeiten gesehen.

Tabelle IVOLLTEXT-SCHEMA

Feldtyp Feldname Beispielhafter Inhalt

string id 65ec644e-0c07-4fae-97d1...string domain reddit.comstring subdomain newsstring url http://www.reddit.com/r/news/...string file redditcommentslong time 1406787166000string type socialtext general content Last Christmas there was a...

2) Worthaufigkeiten-Schema: Die Struktur des sogenanntenWorthaufigkeiten-Schemas kann der Tabelle II entnommenwerden. In diesem Schema existieren fur jedes Abbild einerWebsite mehrere Dokumente. Anstatt den jeweiligen Volltext

47

abzulegen, enthalt jedes Dokument ein Wort aus dem entspre-chenden Abbild sowie die Haufigkeit des Wortes innerhalbdes Abbildes. Somit findet bereits bei der Indizierung eineSummierung als Aggregationsfunktion ihre Anwendung. DieVorteile dieses Schemas liegen im Bereich von Anfragen,die Worthaufigkeiten unter bestimmten Bedingungen ermitteln.Durch die Struktur des Indexes sind Anfragen uber konkreteWorter performanter erfullbar. Probleme dieses Schemas be-stehen in der hohen Anzahl an Dokumenten mit redundantenMetainformationen. Durch die dokumentenbasierte Strukturvon Solr lassen sich die Metainformationen nicht ohne wei-teres extrahieren und wahrend der Laufzeit verknupfen. DesWeiteren geht der Textzusammenhang verloren, wodurch keineAnfragen in Bezug auf die direkte Verknupfung mehrereWorter moglich sind.

Tabelle IIWORTHAUFIGKEITEN-SCHEMA

Feldtyp Feldname Beispielhafter Inhalt

string id 65ec644e-0c07-4fae-97d1...string domain reddit.comstring subdomain newsstring url http://www.reddit.com/r/news/...string file redditcommentslong time 1406787166000string type socialstring word Christmas

int count 42

B. Evaluation unterschiedlicher Importansatze

Nachfolgend erfolgt die Evaluation unterschiedlicherMoglichkeiten um den Datenimport nach Solr durchzufuhren.Dabei werden die einzelnen Moglichkeiten mit ihren jeweili-gen Vor- und Nachteilen erlautert. Alle Importarten nutzen alsBasis die Datenimport-Schnittstellen von Solr. Ein allgemeinesProblem im vorliegenden Datenimport ist, dass die Webseiten-Abbilder innerhalb eines HDFS abgelegt sind, wobei Solrzwar ein HDFS zur Speicherung des Indexes unterstutzt,hingegen aber keine Funktionalitaten zum Direktimport voneinem HDFS anbietet.

1) Data-Import-Handler: Der Data-Import-Handler stellteine direkte Schnittstelle fur den automatischen Solr-Datenimport dar. Dadurch kann Solr mit einer Datenquellewie einer Datenbank, einer Webressource oder auch mit einemDateisystem verbunden werden. Fur HDFS besteht leiderkeine Unterstutzung. Die Daten hatten im konkreten Projektzuerst verschoben werden mussen, weshalb diese Moglichkeitfruhzeitig ausgeschlossen wurde.

2) Update-Handler: Der Update-Handler stellt eine weiteredirekte Schnittstelle fur den Solr-Datenimport dar. Dokumen-te konnen der Importpipeline uber eine HTTP-Schnittstellezugefuhrt werden. Entsprechend benotigt diese Losung einesteuernde Anwendung. Die HTTP-Ubertragungen sowie dieStapelverarbeitungsfunktionalitaten mussen dabei manuell ver-

waltet werden. Aus diesen Grunden kam die Losung fur dievorliegende, umfangreiche Datenmenge nicht in Frage.

3) Flume Indexer: Dieses Software-Werkzeug ist Bestand-teil der Cloudera-Plattform. Dabei bietet es die Konfigurationeiner Datensenke. Eintreffende Dokumente werden automati-siert indiziert, wodurch der Index immer aktuell gehalten wird.Dabei ist Flume fur die Verarbeitung von strukturierten Datei-en in Standardformen optimiert. Dadurch konnen beispielswei-se Logdateien verarbeitet werden. Fur die vorliegenden, nichteinheitlich strukturierten Webseiten-Abbilder ist diese Losunghingegen schlecht geeignet.

4) Lily HBase Indexer: Auch dieses Werkzeug ist in derCloudera-Plattform enthalten. Dabei unterstutzt es den Im-port von Datensatzen, die innerhalb einer HBase-Datenbankabgelegt sind. Dafur hatten die Daten auf dem HDFS imkonkreten Fall erstmal einer HBase-Datenbank zugefuhrt wer-den mussen, weshalb auch diese Losung keine optimale Wahldarstellt.

5) Spark Indexing: Ein weiteres Werkzeug ausdem Cloudera-Universum. Mithilfe eines Spark- oderMapReduce-Clusters lasst sich ein Importvorgang von HDFS-Verzeichnissen durchfuhren. Eine Prozess-Pipeline kannuber eine Morphline-Konfiguration definiert werden. DasMorphline-Werkzeug bietet Funktionalitaten zur Extraktionund Transformation von Daten. Dementsprechend ist dieseLosung gut fur den vorliegenden Anwendungsfall geeignet.

6) Hadoop und SolrJ: Hierbei handelt es sich umzwei Java-Bibliotheken. Die Hadoop-Bibliothek bietet Un-terstutzung zur Interaktion mit HDFS-Verzeichnissen undHDFS-Dateien. Die SolrJ-Bibliothek hingegen erlaubt dieperformante und hochskalierbare Datenindizierung einer Solr-Instanz. Innerhalb einer individuellen Java-Anwendung lassensich beide Werkzeuge kombiniert einsetzen, um Daten dieauf einem HDFS gespeichert sind in Solr zu indizieren. ImVergleich zur vorherigen Losung durch MapReduce bietet eineindividuelle Implementierung eine großere Freiheit, was inAnbetracht der vielfaltigen Problemstellung als großer Vorteilangesehen wird. Nachteilig ist der hohere manuelle Aufwandum eine angemessene Performanz und Skalierbarkeit zu er-reichen sowie die dadurch einhergehende Fehleranfalligkeitund schlechte Portabilitat. Letztendlich wurde sich fur dieseLosung entschieden, da die Ausfuhrung in keinem produktivenUmfeld erfolgt und die Nachteile dadurch vernachlassigbarsind.

C. Analyse der Indexer-Anwendung

In diesem Unterkapitel erfolgt die Analyse der entwickel-ten Indexer-Anwendung. Dabei wird im Folgenden auf dieStruktur und Architektur der Anwendung eingegangen undes erfolgt eine Ubersicht uber die Leistungsfahigkeit derAnwendung.

1) Architektur und Ablauf: Die grundlegende Architekturder Anwendung ist durch die Abbildung 4 ersichtlich. DieserAbbildung konnen außerdem Abhangigkeiten zu genutztenBibliotheken, durch eine Visualisierung mittels abgeschragterRechtecke, entnommen werden. Die Laufzeitkonfiguration der

48

Anwendung kann uber 13 unterschiedliche Parameter spezifi-ziert werden. Dabei erfolgt die interne Verarbeitung paralleli-siert und modular. Jede der parallelen Ausfuhrungseinheitenladt dabei Key-Value-Paare aus den Sequenzdateien uberdie Hadoop-Bibliothek vom HDFS in den Zwischenspeicher.Von dort erfolgt die Extraktion von Inhalts- und Metadaten.Diese werden validiert und mithilfe der JSOUP-Bibliothekbereinigt. Zuletzt erfolgt der Versand der aufbereiteten Do-kumente uber eine Stapelverarbeitung der SolrJ-Bibliothekan die Solr-Instanz. Fur das Worthaufigkeiten-Schema findetzusatzliche eine Aggregation, bei der die Worthaufigkeitengezahlt werden, ihre Anwendung. Hierbei kommt die trove-Bibliothek zum Einsatz, da sie schnelle Zahlvorgange miteiner vorteilhaften Komplexitat bietet [4]. Die Parallelisierunginnerhalb der Anwendung wird automatisch gesteuert. Wenndie Solr-Instanz mit dem entgegennehmen der Dokumentenicht mehr nachkommt, wird die Ausfuhrungsgeschwindigkeitder Anwendung entsprechend heruntergeregelt. Somit ist si-chergestellt, dass der Speicherverbrauch nicht unnotig hochist und dadurch auch große Datenmengen indiziert werdenkonnen.

HDFS Solr

Solr-Indexer

1.seq

0.seq

...

Key-Value JSON

Extraktion Verarbeitung Formatierung

hadoop solrj

jsoup jcommander

tinylog

json progressbar

trove4j

Index

Abbildung 4. Architektur des Solr-Indexers

D. Ergebnisse der Indexer-Anwendung

Die nachfolgende Tabelle III zeigt Messergebnisse derjeweiligen Importvorgange. Dabei ist zu beachten, dasseinige Metriken aufgrund der unterschiedlichen Datenba-sis nicht direkt vergleichbar sind. Wie sich zeigt, ska-liert die Indexer-Anwendung auf einer einzelnen Maschi-ne sehr gut mit zusatzlichen Recheneinheiten, was auf diegeringen Abhangigkeiten der einzelnen Verarbeitungsschrittezuruckzufuhren ist. Lediglich das lesen aus dem HDFS sowiedas indizieren durch eine Solr-Instanz stellen potentielle Fla-schenhalse dar, die im vorliegenden Projekt jedoch nur beimWorthaufigkeiten-Schema zu einem Problem wurden. Dort wardie Anzahl an zu indizierenden Dokumenten so hoch, dass dieSolr-Instanz große Mengen an Zwischenspeicher benotigte und

mit der Indizierung der Dokumente nicht mehr nachkam. Ausdiesem Grund wurde fur das Worthaufigkeiten-Schema eineviel kleinere Datenbasis genutzt, was bereits zu einem fruhenZeitpunkt einen großen Nachteil dieses Ansatzes aufzeigt. Furdas indizieren von nur 126.322 Webseiten-Abbildern wurdenuber 34 Millionen Dokumente durch Solr indiziert. Offensicht-lich ist Solr nicht fur eine so große Anzahl von Dokumentenmit einem jeweils relativ kleinen Inhalt ausgelegt. Die Indizie-rung des Volltext-Schemas verlief hingegen zufriedenstellend.Ein relativ kleiner Anteil an Dokumenten konnte nicht indiziertwerden, da die zugrundeliegenden HTML-Dokumente nichtvalidiert werden konnten. Bei diesen Dokumenten kann es sichbeispielsweise um Binardateien handeln.

Tabelle IIIERGEBNISSE DER INDEXER-ANWENDUNG

Volltext-Schema Worthaufigkeiten-

Schema

Anzahl indizierterSequenzdateien 21 1

Anzahl anWebseiten-Abbildern 2.319.898 126.322

Erfolgs-wahrscheinlichkeit 99,8 % 99,8 %

Anzahl indizierterDokumente 2.315.621 34.198.010

Speicherverbrauchdes Indexes 39 GB 10 GB

Gesamtdauerder Indizierung 49 min 40 min

Indizierungsdauer jeWebseitenabbild ca. 1 ms ca. 19 ms

Speicherverbrauch jeWebseitenabbild ca. 17 kB ca. 80 kB

Dokumentenzahl jeWebseitenabbild 1 ca. 270

IV. ANALYSEN

Um die Anwendbarkeit von Solr auf die Analyse der in IIIvorgestellten Dokumente zu uberprufen, wurden diverse An-fragen entwickelt, die folgend beschrieben werden. Anschlie-ßend werden die Ergebnisse der Anfragen, falls vorhanden,dargelegt.

A. Worthaufigkeiten

Die Anfragen zu Worthaufigkeiten beschaftigen sichgrundsatzlich mit der Frage, welches Wort wie oft in Da-tensatzen zu finden ist. Dies kann uber das Hinzufugenweiterer Kriterien konkretisiert werden. Weiterhin wird dieUmsetzbarkeit mit den verschiedenen Index-Schemata ausTabellen I und II differenziert betrachtet. Fur die Untersuchungvon Solr wurden nachfolgende Anfragen definiert.

1) Wie oft kam Wort w im Zeitraum x vor?: Diese Anfragewar mit dem Volltextschema nicht vollstandig losbar, es wirdzwar eine Ergebniszahl von Solr zuruckgegeben, dabei handeltes sich jedoch um die Anzahl an gefundenen Dokumenten,die nur mit der Wortanzahl ubereinstimmt, wenn w in jedemgefundenen Dokument nicht mehr als einmal vorkommt. DieBildung der Summe aus den Haufigkeiten von w in den

49

verschiedenen Dokumenten wird von Solr in der verwendetenVersion 4.10.3 noch nicht unterstutzt.

Mit Hilfe des Worthaufigkeitsschemas konnte diese An-frage komplett umgesetzt werden. Dies wird uber die Stats-Komponente von Solr erreicht. Diese kann Statistiken fureine Suchanfrage berechnen, wodurch eine Summenfunktionabgebildet werden kann. Die Stats-Komponente kann jedochnur auf das gesamte Suchergebnis und nur auf geeigneteFelder, wie das frequency-Feld, angewendet werden.

2) Was sind die n haufigsten Worter im Zeitraum x?:

Diese Anfrage war ebenfalls nicht mit dem Volltextschemalosbar. Es gibt zwar Solr-Komponenten, die Aussagen uber dievorhanden Worter in einem Volltextfeld treffen konnen, dieseAussagen sind allerdings nicht durch die Suchkomponentenbeeinflussbar, womit die Beschrankung auf den Zeitraum xnicht moglich ist.

Diese Anfrage war nicht vollstandig mit demWorthaufigkeitsschema losbar. Es konnten zwar uber dieAnwendung der Facet-Komponente auf das word-Feld dieeinzelnen Haufigkeiten nach dem enthaltenen Wort gruppiertwerden, das in IV-A1 beschriebene Problem, dass nurDokumente, nicht Haufigkeiten zuruckgegeben werden, tritthier, fur die Ergebnisse der Facet-Komponente, jedoch auchauf.

3) Welche Domain enthalt das Wort w im Zeitraum x am

haufigsten?: Diese Anfrage ist nicht mit dem Volltextschemalosbar, die Differenzierung nach Domains ist zwar moglich,das Problem aus IV-A1 tritt hier allerdings auch auf.

Das Worthaufigkeitsschema kann diese Anfrage problemloserfullen. Es muss lediglich nach x und w gesucht und anschlie-ßend nach frequency absteigend sortiert werden.

Es zeigt sich, dass die von Solr bearbeitbaren An-fragen durch das Zusammenspiel der verschiedenen Solr-Komponenten beschrankt sind. Um fur eine konkrete Anfrageauszusagen, ob Solr das richtige Werkzeug zur Beantwortungist, sind tiefgehende Kenntnis der einsetzbaren Komponenten,ihrer Interaktion und dem eingesetzten Schema vonnoten.

B. Domain-Namen-Analyse

Nachdem sich die direkte Untersuchung vonWorthaufigkeiten mit Solr als schwierig herausstellte,wurden weitere Anwendungsgebiete gesucht. Hierbei botsich an, Analyseanfragen nicht mehr auf Werte innerhalbder Dokumente, wie zum Beispiel die Summer mehrererfrequency-Felder oder die Worter innerhalb eines analysiertenTextfeldes, sondern auf die Gruppierung und Analyse derDokumente selbst und auf die ihrer Metadaten anzuwenden.Fur diese Analyse ist das Volltextschema notwendig, da nurhier ein Dokument fur eine Website steht, sonst gibt es furjede Website so viele Dokumente, wie sie einzigartige Worterbeinhaltet. Dies wurde Seiten mit viel Text bevorzugen.

Diese Analyse wurde zunachst am Beispiel des Domain-Namens, der im domain-Feld hinterlegt ist, durchgefuhrt. Eswurden zwei Anfragen definiert, auf die im Folgenden kurzeingegangen werden soll.

1) Wie oft kommen Dokumente in den Top n Domain-Namen

vor?: Hier ist zunachst eine Ubersicht uber die n Domain-Namen, welche die meisten Dokumente beinhalten, gefragt.Dies kann durch die Facet-Komponente von Solr berechnetwerden. Sie gibt dabei nicht nur an, welche Domain-Namendie meisten Dokumente beinhaltet, sie gibt zusatzlich zumDomain-Namen auch an, wie viele Dokumente sich in deneinzelnen Gruppen befinden [5, S. 259ff].

Die Ergebnisse einer solchen Abfrage sind beispielhaftfur n=6 in Abbildung 5 dargestellt. Es ist erkennbar, dassdie meisten Dokumente von reddit.com-Domains stammen,gefolgt von huffingtonpost.com und focus.de.

Abbildung 5. Haufigkeitsverteilung pro Domain-Name

2) Welche x Dokumenttypen sind in den Top n Domain-

Namen am verbreitetsten?: Diese Anfrage ist eine Erweite-rung der vorherigen Anfrage um eine Stufe, da zusatzlich zuder Gruppierung der Dokumente in Domaingruppen weiterunterschieden werden muss, welchem Typ sie angehoren. Umdiese mehrstufigen Anfragen zu bearbeiten bietet Solr in derFacet-Komponente eine weitere Funktionalitat an, um inner-halb eines Facets erneut Facets zu berechnen. Diese Funktio-nalitat ist allgemein als Pivot-Facets [5, S.267ff] bekannt. Umdiese Anfrage umzusetzen wurde lediglich ein Pivot-Facet aufdie Felder domain und type gesetzt, was alle benotigten Datenliefert. Ein Ergebnis fur n,x=2 kann Abbildung 6 entnommenwerden.

Abbildung 6. Haufigkeitsverteilung pro Domain-Endung und Typ

50

C. Sprachanalyse

Solr bietet eine Funktionalitat um beim Indizierungsvorgangdie Sprache, in der ein Feld eines Dokuments verfasst ist,zu erkennen. Die erkannte Sprache wird anschließend in eineigenes Feld, in diesem Fall language detected, eingefugt.Weiterhin kann ein sogenannter fallback-Wert angegeben wer-den, der eingefugt wird, sollte die Spracherkennung zu keinemeindeutigen Ergebnis kommen [5, S. 200ff ].

Mit Hilfe der Facet-Komponente konnen nun Dokumenteanhand des Werts in language detected gruppiert werden.Somit konnen Zusammenhange zwischen Metadaten der Do-kumente, wie Domain oder Dokumenttyp, und der Sprachehergestellt werden. Konkret wurden hier zwei Anfragen er-stellt, deren Ergebnisse in Abbildungen 7 und 8 zu sehen sind.Hierbei ist zu beachten, dass Solr selbst keine Funktionalitatbietet, Grafiken aus den Suchergebnissen zu generieren. DieAbbildungen wurden aus den Rohdaten von Solr mithilfe einerdritten Anwendung erstellt.

Abbildung 7 zeigt die Sprachverteilung im gesamten Da-tenbestand. Die Daten wurden durch den Einsatz der Facet-Komponente zur Sammlung gleichsprachiger Dokumente er-hoben. Es zeigt sich, dass die meisten Dokumente in Englischverfasst wurden gefolgt von Deutsch. Die nachstgroßere Grup-pe konnte nicht eindeutig erkannt werden.

Abbildung 7. Haufigste Sprachen im Datenbestand

Abblidung 8 zeigt die Sprachverteilung der zwei haufigstenSprachen, Deutsch und Englisch, in den drei haufigsten Do-mainendungen, .de, .com und .co.uk.

Abbildung 8. Erkannte Sprachen fur Domain-Endungen

D. Trend-Analyse

Abschließend wurde eine Trend-Analyse verschiedenerWorter durchgefuhrt. Die Basis der Trendanalyse bietet wiederdas Volltextschema. Dabei kann die Trend-Analyse immer nurauf einzelne Worter angewendet werden, da ein Facet auf soeine große Menge von unterschiedlichen Werten in Form vonanalysierten Textfeldern Laufzeitprobleme verursachen wurde.Zur Umsetzung wurde die Range-Facet-Funktionalitat vonSolr verwendet [5, S. 264ff]. Diese erlaubt die Gruppierungund Summierung der Worthaufigkeiten in frei definierbarenZeitabstanden. Das zu analysierende Wort wird uber die An-frage eingeschrankt.

Der zu untersuchende Zeitraum lasst sich beliebig wahlen,wobei die Intervalldauer von Tagen bis Jahren konfigurierbarist. Somit lasst sich nachvollziehen, in welchem Zeitintervallein bestimmtes Wort besonders haufig vorkam. Allerdingszeigt sich hierbei das Problem, dass die Worthaufigkeit alleinnicht ausreicht um einen Trend zu erkennen. Dies liegt daran,dass die Gesamtanzahl an Dokumenten, die in diesem Intervallindiziert wurden, keine Berucksichtigung findet. Somit steigtder Trend automatisch mit der Anzahl an indizierten Doku-menten.

Um diesem Problem entgegenzuwirken werden die Trend-analysen von einem entwickelten Werkzeug durchgefuhrt, dasdie Anzahl der Dokumente, die das gesuchte Wort enthalten,gegen die Anzahl an indizierten Dokumenten im selben Zei-tintervall, relativiert. Dadurch ist erkennbar, wann ein Wortbesonders haufig verwendet wurde und damit im Trend lag.

Das Ergebnis einer solchen Anfrage wird in Abbildung 9dargestellt. Wie zu erwarten ist Christmas ein beliebtes Wortin der Weihnachtszeit, was sich jeweils mindestens mit einerVerdoppelung des ublichen Verwendungsanteils darstellt.

Abbildung 9. Relative Vorkommen von Christmas

V. AUSBLICK

Zukunftige Forschung sollte sich zunachst mit der Untersu-chung neuerer Versionen von Solr beschaftigen, da es hierdiverse Verbesserungsmaßnahmen in der Abfragelogik unddem Zusammenspiel der verschiedenen Suchkomponenten gab[6]. Diese neuen Funktionalitaten ermoglichen erweiterte Ana-lysemoglichkeiten, wie die Anwendung der Stats-Komponenteauf die Ergebnismenge eines Facets oder das Einschranken der

51

Datenmenge, auf die ein Facet angewendet wird. Dies sollteeinigen der in IV-A erlauterten Probleme entgegenwirken.Somit konnte Solr weitaus attraktiver zur Analyse beliebigerDaten werden, als in dieser Arbeit festgestellt werden konnte.Weiterhin wurde die Volltextsuchkapazitat von Solr in dieserArbeit nur am Rande untersucht, da sich hier auf einzelneWorter spezialisiert wurde. Im Rahmen zusatzlicher Forschungkonnte die Analyse von n-Grammen ihre Anwendung finden.

Ein weiteres Themengebiet konnte der Performanzvergleichvon Solr mit anderen gangigen Datenbanksystemen, bei derBearbeitung beliebiger Analyseanfragen, darstellen. Dabei istdie Fragestellung, inwieweit Solr innerhalb von einer Kette un-terschiedlicher Datenbanksysteme sinnvoll eingesetzt werdenkann, von besonderem Interesse. Mogliche Vergleichskandida-ten sind unter anderem Elasticsearch, Impala, IBM Informixund MongoDB.

Zusatzlich kann die Solr-Importanwendung weiterentwi-ckelt werden, um auch Solr-Cluster zu unterstutzen. Im Zen-trum einer solchen Entwicklung sollte stehen, dass die Im-portanwendung zu einem verteilten System erweitert wird, dasauch großere Datenmengen schnell und zuverlassig verarbeitenkann.

VI. FAZIT

Wie sich zeigte erweitert die Solr-Plattform die Lucene-Programmbibliothek und bietet dabei zusatzliche Schnittstel-len, Funktionalitaten und datenstromorientierte Verarbeitungs-prozesse. Uber unterschiedliche Komponenten ist eine kom-fortable und automatisierbare Verwaltung des Datenindexesmoglich. Dabei bestehen Kompatibilitaten zu unterschiedli-chen externen Systemen und Technologien. Uber umfang-reich definierbare Verarbeitungsroutinen konnen homogeneRohdaten direkt beim Import, innerhalb der Solr-Plattform,vorverarbeitet und aufbereitet werden. Ein ahnlicher Prozesswird auch bei Abfragen genutzt, wobei die Antwort durchindividuell konfigurierbare Komponenten transformiert wird.

Fur die vorliegende Problemstellung konnte kein einheit-liches Dokumentenschema, mit dem unterschiedlichste Ana-lysen moglich sind, gefunden werden. Uber das Dokumen-tenschema und die entsprechende Aufbereitung der Import-daten, werden die Moglichkeiten der spateren Datenanalysebereits zu einem fruhen Zeitpunkt stark eingeschrankt. ZurUmsetzung unterschiedlicher Analysen wurden die Dokumen-tenschemata Volltext und Worthaufigkeit gewahlt, da sie sichgegenseitig erganzen. Die entwickelte Java-Anwendung zurIndizierung von Rohdaten unterstutzt dabei eine hohe Dy-namik und bietet viel Spielraum, um unterschiedliche Do-kumentenschemata und Vorverarbeitungen umzusetzen. DiePerformanz der parallelisierten und modular aufgebauten An-wendung war dabei durchweg ausreichend fur die vorliegendeAufgabenstellung. Jedoch zeigte sich, dass die Indizierungs-leistungsfahigkeit von Solr mit der Anzahl an zu indizieren-den Dokumenten korreliert, weshalb das Worthaufigkeiten-Schema, aufgrund der hohen Anzahl an Dokumenten, bereitsbeim Importvorgang große Schwachen zeigte.

Die Ergebnisse der allgemeinen und universellen Datenana-lysen durch Solr waren Großteils ernuchternd. Trotz der ange-passten Dokumentenschemata und einer entsprechenden Vor-verarbeitung und Voraggregation waren die meisten Analysen,die die Verknupfung von unterschiedlichen Feldern beinhalten,nicht befriedigend serverseitig losbar. Generell mangelte esin dieser Hinsicht an Funktionalitaten zur Aggregation undVerknupfung von Daten. Die eigentliche Volltextsuche warauch bei großen Datenmengen hochperformant, nur konntendie Informationen daraufhin serverseitig nicht optimal wei-terverarbeitet werden. Somit konnte die Nutzung von Solran einer fruhen Position, innerhalb einer Kette von mehrerenVerarbeitungssystemen, auch im Bereich der Datenanalyse,von großem Wert sein.

In Solr integrierte Funktionalitaten, wie die Sprachenerken-nung, ermoglichten interessante Analysen von recht speziellenTeilbereichen. Auch die Untersuchung von historischen Trendskonnte durch eine bereichsbasierte Facettierung umgesetztwerden. Nach einer Normalisierung und Visualisierung liefertediese Untersuchung erstaunlich prazise korrelierte Ergebnisse.

In Bezug auf die reinen Analysefahigkeiten zeigte sich, dassdas primare Anwendungsgebiet von Solr im Bereich von Such-funktionalitaten und nicht in der allgemeinen Datenanalyseliegt. Viele Funktionalitaten aus dem Bereich der Suche konn-ten nicht sinnvoll eingesetzt werden, wohingegen benotigteAggregationsfunktionalitaten fehlten. Hier hatte MongoDB alsalternative, dokumentenbasierte Datenbank, in Anbetracht derumfangreichen Aggregationspipeline, sowie der MapReduce-Funktionalitaten, sicherlich bessere Analysefahigkeiten beses-sen.

Abschließend muss hervorgehoben werden, dass Solrstandig weiterentwickelt und um neue Funktionalitaten erganztwird. Die vorliegende Arbeit nutzte, bedingt durch dieCloudera-Distribution, nicht die aktuellste Solr-Version. Nachaktueller Planung scheint Solr in der zukunftigen Entwick-lung viele Funktionalitaten zur Datenanalyse zu integrieren,wodurch die Ergebnisse der vorliegenden Arbeit in Zukunftkritisch auf ihre weitere Gultigkeit zu prufen sind.

LITERATUR

[1] “Db-engines ranking - popularity ranking of search engines,” 2017.[Online]. Available: https://db-engines.com/en/ranking/search%20engine

[2] S. S. Mangar, 4th Bangalore Apache Solr/Lucene Meetup Group, April2014.

[3] S. Rowe, “Schemaless solr: Part 1,” 2013. [Online]. Available:https://lucidworks.com/2013/05/21/schemaless-solr-part-1/

[4] R. Leventov, “Fastest word count in java,” May 2016. [Online].Available: https://github.com/leventov/java-word-count

[5] “Apache solr reference guide.” [Online]. Availa-ble: https://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-4.10.pdf

[6] Hoss, “Hey, you got your facets in my stats! you gotyour stats in my facets!!” January 2016. [Online]. Available:https://lucidworks.com/2015/01/29/you-got-stats-in-my-facets/

52

Die Zeitreihen-Challenge

Lothar Piepmeyer Fakultät Informatik

Hochschule Furtwangen D-78120 Furtwangen

lothar.piepmeyer@hs-furtwangen.de

Abstract—In einer Folge von Beiträgen wird aufgezeigt, wie mit einem Zeitstempel versehene Textdaten effizient verwaltet und analysiert werden können.

Keywords—big data; data analysis; time series; database management systems

I. EINLEITUNG Mit Lioncub wurde an der Hochschule Furtwangen eine

Plattform zur Evaluierung von Big-Data-Technologien entwickelt [1]. Softwareagenten durchsuchen bekannte Nachrichtenportale wie spiegel.de oder cnn.com und soziale Netzwerke wie Reddit nach neuen Beiträgen. Jeder neue Artikel wird heruntergeladen und mit Metadaten im JSON-Format angereichert:

{"time":"14133887000","domain":"www.abc.de","type":"news","url":"http://www.abc.de/bic.htm"}

<!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <title> …

Nach und nach entstand so ein Textkorpus mit mehreren Millionen Artikeln, der ein interessanter Anwendungsfall für Big-Data Werkzeuge ist.

II. DER ANWENDUNGSFALL Zählt man für jedes Wort pro Dokument die Häufigkeit im

Dokument, so ergeben sich Daten, die dem folgenden Schema genügen:

url timestamp word frequency

http://www.abc.de/bic.htm 14133887000 wendepunkt 7

Die Worte werden

• normalisiert, indem etwa alle Umlaute durch Kombinationen wie ae oder ss ersetzt werden.

• gegen eine Blacklist geprüft, um sogenannte Stoppworte wie 'der', 'und' oder 'dass' zu vermeiden.

Aus dieser Vorgehensweise ergeben sich zwei Probleme:

• die so entstandenen Milliarden von Datensätzen müssen mit vertretbaren Aufwand in ein Datenbanksystem (DBMS) importiert werden

• es müssen ein Datenbanksystem und geeignetes Datenmodell gefunden werden, um Abfragen mit einer Latenz im von wenigen Sekunden zu bearbeiten.

In [1] wurde dies bereits für die Datenbanksysteme HBase und Druid diskutiert. In den Beiträgen zur Zeitreihen-Challenge werden Lösungen mit anderen DBMS entwickelt. Insbesondere wird aufgezeigt, wie die folgenden beiden Abfragen umgesetzt werden können:

Query 1: Map<Date,Integer> query(String word, String from, String to)

Query 2: List<String,Integer> query(String word, String from, String to, int top)

Beide Abfragen suchen nach dem Wort, dass Ihnen als erster Parameter übergeben wurde. Es werden alle Dokumente mit Zeitstempeln zwischen from und to durchsucht. Query 1 liefert eine Map, die die summierten Worthäufigkeiten aus all diesen Dokumenten enthält.

Das Ergebnis von Query 2 ist eine Map, die in absteigender Reihenfolge die Häufigkeiten von word in den top URLs enthält. Im Fall von top=10 erhält man also die 10 Dokumente, in denen das Wort am häufigsten aufgetreten ist.

53

III. LÖSUNGEN Die Zeitreihen-Challenge wurde im Rahmen des Moduls

‚Informationssysteme’ von Studierenden des Master-Studiengangs Informatik der Hochschule Furtwangen bearbeitet. Verschiedene Teams haben dabei jeweils die Möglichkeiten und Grenzen der folgenden DBMS diskutiert:

• Redis • Cassandra • MongoDB • HBase

• Impala

Diese DBMS werden den NoSQL-Systemen zugeordnet. Es ist interessant zu sehen, wie die gestellten Herausforderungen mit den jeweiligen Paradigmen auf zum Teil vollkommen verschiedene Weise gelöst werden können.

LITERATUR

[1] L. Piepmeyer, M. Bölling, „Datenstrom im Blick - Big und Fast Data mit Druid“, iX 10/2016, pp 112-116.

54

Apache Cassandra

Jennifer Jurreit, B.Sc.Hochschule Furtwangen University

Furtwangen, Deutschland

Email: jurreitj@hs-furtwangen.de

Merlin Gernsheimer, B.Sc.Hochschule Furtwangen University

Furtwangen, Deutschland

Email: gernshei@hs-hs-furtwangen.de

Peter Wursthorn, B.Sc.Hochschule Furtwangen University

Furtwangen, Deutschland

Email: wursthop@hs-furtwangen.de

Zusammenfassung—In diesem Paper wird die Umsetzung derQueries 1 und 2 unter Verwendung des DatenbanksystemsApache Cassandra geschildert. Es stellte sich heraus, dassCassandra nur bedingt dafur geeignet ist.

1. Cassandra

Apache Cassandra ist eine spaltenorientierte Open Sour-ce NoSQL Datenbank (vgl. [1]). In diesem Kapitel sollendie Besonderheiten und das Datenbankmodell von ApacheCassandra beschrieben werden.

1.1. Datenbankmodell

Cassandra speichert Daten in sogenannten Keyspaces,welche mindestens eine oder mehrere Column Familiesenthalten (vgl. [1]). Verglichen mit dem relationalen Modell,entsprechen Keyspaces der Datenbank und Column Familiesder Tabellen innerhalb der Datenbank.

1.2. Besonderheiten des Primarschlussels

Ahnlich wie in relationalen Datenbanken, gibt es inCassandra einen Primarschlussel. Anders als bei relationalenSystemen, wird dieser in Cassandra aus zwei unterschied-lichen Schlussel-Arten zusammengesetzt, dem PartitioningKey und dem Clustering Key. Der Partitioning Key zeigtauf die Partition, auf der die Daten liegen. Er dient demAuffinden der entsprechenden Partition, auf der sich diegesuchten Daten befinden.Der Clustering Key zeigt auf das entsprechende Cluster undgibt die Sortierung der Daten innerhalb der entsprechendenPartition an.Bei einem einfachen Primarschlussel gibt der enthalteneWert den Partitioning Key an. Bei einem zusammengesetz-ten Primarschlussel dient der erste Teil des Schlussels alsPartitioning Key und der zweite Teil als Clustering Key.

1.3. Cassandra Query Language

Die Cassandra Query Language (CQL) ist eine SQL-ahnliche, deklarative Abfragesprache des Datenbankmana-gementsystems (DBMS) (vgl. [2]). Als Datenbankabfrage-sprache unterstutzt CQL sowohl Data Definition Language

(DDL), als auch Data Manipulation Language (DML). Mitcreate konnen Column Families erstellt, mit drop geloscht,und mit alter geandert werden. Mit insert konnen Daten indie Datenbank eingefugt, mit update angepasst, mit delete

geloscht, und mit select selektiert werden.

2. Query 1 - Aggregatsfunktionen

Query 1 beschreibt eine typische Aggregatsfunktion. Eswird nach der summierten Worthaufigkeit aus allen gegebe-nen Dokumenten fur einen bestimmten Zeitraum gesucht.

2.1. Datenmodell

Cassandra ist abfragespezifisch, das heißt die Datenmussen so vorliegen, wie sie laut Fragestellung gefordertwerden.Daher wurden in dem erstellten Keyspace Informationssy-

steme zwei Column Families, wordinfo (siehe Tab. 2 ) undaggregation (siehe Tab. 1 ), erstellt:

Tabelle 1. AUSSCHNITT AUS DER TABELLE AGGREGATION

word frequencySum timestampGerman 50 1403992800000Germany 40 1403992800000

Zur Aggregierung von Daten wird hier ein Counterverwendet. Counter sind von Cassandra vorgegebene Daten-strukturen, die das Zahlen von Eintragen vereinfachen (vgl.Abschnitt 2.2).

Tabelle 2. AUSSCHNITT AUS DER TABELLE WORDINFO

word frequency timestamp urlGerman 3 1403992800000 http://www.google.de/...German 4 1403992800000 http://www.twitter.com/...

2.2. Einfugen der Daten

Zum Einfugen der Daten, wird die Java API Astyanax

von Netflix verwendet. Ahnlich wie JDBC erlaubt die-se die Verwendung der Abfragesprache (CQL) im Java-Anwendungscode (vgl. [3]).

55

Die Daten werden so uber einen Generator bezogenund asynchron mithilfe von Prepared Statements in dieentsprechenden Tabellen bzw. Column Families eingefugt.

Wenn das Wort noch nicht in der aggregation Tabellevorhanden ist, wird es dort automatisch mit der Frequency-Sum 1 angelegt (upsert).

2.3. Datenbankabfrage

Zur Abfrage der Worthaufigkeiten innerhalb aller Doku-mente fur einen bestimmten Zeitraum wird die aggregation

Tabelle, d.h. die voraggregierten Daten, verwendet:

s e l e c t ⇤ from a g g r e g a t i o nwhere word = ? and t imes t amp <= ? andt imes t amp >= ?o r d e r by t imes t amp a s c ;

3. Query 2 - Top-k Liste

3.1. Zielsetzung

Query 2 stellt ein sogenanntes top-k Query dar. Dabeiwird ein Suchwort zusammen mit einem Zeitrahmen, be-stehend aus Start und Enddatum, angegeben. Gesucht sindnun diejenigen k Dokumente, die die großte Haufigkeit desSuchwortes aufweisen, absteigend sortiert nach der Haufig-keit.

3.2. Ansatz

Die Umsetzung dieses Query mit Cassandra gestaltetsich schwierig. Cassandra ist ein Datenbanksystem, dassfur schnelles Schreiben optimiert wird. Im Gegenzug sindLeseoperationen weniger performant und auch durch dieCassandra Query Language deutlich eingeschrankt.

Fur Query 2 wurde das Datenmodell zur wordinfo

Tabelle, wie es in Abschnitt 2.1 beschrieben wird, genutzt.

3.3. Probleme

s e l e c t f r e q u e n c y , u r l from w o r d i n f owhere word = ? and t imes t amp <= ?and t imes t amp >= ? ;

Das Problem in der obigen Abfrage, ist derenUnvollstandigkeit in Bezug auf die Aufgabe. So fehltsowohl die absteigende Sortierung nach der Haufigkeitdes Suchwortes, wie auch die Limitierung auf diehochsten k Ergebnisse. An dieser Stelle zeigt sich, dassCassandra fur diese Art von Query die falsche Wahldes Datenbanksystems ist. Top-k Queries beinhalten eineDynamik, die nicht mit dem statischen Abfragemodellvon Cassandra vereinbar ist. Zwar bietet die CassandraQuery Language ein order-by-Statement, das von derSyntax aufgebaut ist wie in der Structured Query Language

(SQL), die in RDBMS verwendet wird. Die Funktiondieses Statements ist allerdings wesentlich eingeschrankterals in SQL. So kann in CQL in einer Query nur geandertwerden, ob die Sortierung der Daten aufsteigend oderabsteigend erfolgt. Die Spalte, nach der sortiert wird,muss bereits beim Erstellen der Tabelle festgelegt werden.Um eine Spalte als Ordnungskriterium festzulegen, mussdiese im Primarschlussel enthalten sein. Im vorliegendenFall musste also die Spalte frequency zum Clustering-Keyhinzugefugt werden, um aber nach ihr sortieren zu konnenmuss sie außerdem im Clustering-Key vor dem timestampstehen. Wenn die Frequency allerdings vor dem timestampim Clustering-Key steht, konnen keine Range-Queriesmehr auf den Timestamp angewendet werden, ohnedie Frequency auf einen bestimmten Wert festzulegen.Die Frequency kann aber nach Aufgabenstellung nichteingeschrankt werden. Range-Queries auf Frequency undtimestamp sind von CQL verboten. Dies fuhrt zu zweiOptionen: Entweder mussen Sortierung und Limitierungapplikationsseitig vorgenommen werden, oder Cassandramuss mit einer anderen Technologie erweitert werden,die es erlaubt, dynamische Abfragen durchzufuhren. Imfolgenden Abschnitt wird zu diesem Zweck Cassandrazusammen mit Lucene verwendet.

3.4. Apache Lucene

Apache Lucene ist eine Bibliothek, die zur Erstellungvon Volltextsuchindexen konzipiert wurde, mittlerweile aberauch andere fortgeschrittene Abfragemethoden zulasst (vgl.[4]). Fur Cassandra existiert ein Plugin, mit dem sekundareIndexe fur ganze Records mithilfe von Lucene erstellt wer-den konnen. Diese Sekundarindexe sind weitaus machtigerals die in Cassandra mitgelieferten Sekundarindexe underlauben, Query 2 auch datenbankseitig zu losen. Um dieIndizierung des gesamten Records zu ermoglichen musstein der verwendeten Cassandra-Version ein workaround an-gewandt werden: Der Index wird fur den Zugriff auf einleeres Dummy-Feld ’Lucene’ angelegt, auf welches dannLucene-Queries angewandt werden konnen.

Hierzu wird ein Cassandra-Record folgendermaßen inLucene indexiert: Das Wort wird als ’string’ indiziert ohneTextanalyse, die Anzahl als ’integer’ und der Timestamp alsDatum.

s e l e c t u r l , f r e q u e n c y from w o r d i n f owhere l u c e n e = ? l i m i t ?

Die Abfrage von Query 2 mithilfe von Lucene istim obigen Code zu sehen. Der erste Parameter ist dabeidie Lucene-Query und der zweite, wie viele Ergebnissezuruckgegeben werden. Die verwendete Lucene-API wirdmithilfe von JSON-Dokumenten angesprochen, in welchendie Query dargestellt wird, ein solches Dokument ist imFolgenden zu sehen:

56

1 {"search":{2 "filter":{3 "bool":{4 "must":[{5 "match":{6 "word": "reddit"7 }8 },{9 "range":{

10 "timestamp":{11 "lower": "01.01.2014",12 "upper": "31.12.2014"13 }}}]}},14 "sort":{15 "field": "frequency",16 "reverse": true17 }18 }}

Die soeben dargestellte Query filtert nach dem Wort “reddit”und im Zeitraum vom 01.01.2014 bis zum 31.12.2014. DieErgebnisse werden aufsteigend nach der Frequenz sortiertund an Cassandra zuruckgegeben, dieses ubernimmt dieLimitierung auf die angegebene Ergebniszahl.

4. Performance

Die folgenden Laufzeiten wurden auf dem kleinen Da-tensatz auf einem lokalen Rechner ausgefuhrt.Fur Query 1 konnte eine Laufzeit von 7 - 15ms festgestelltwerden. Die zwei Losungen, applikationsseitige Sortierungund Lucene Suche, von Query 2 unterscheiden sich aufdiesem Datensatz in ihrer Laufzeit nur unwesentlich. Beidehaben eine durchschnittliche Laufzeit von 12ms.

5. Fazit

Fur die vorliegende Aufgabe erweist sich Cassandra mitBlick auf Query 2 als grundlegend falsche Wahl des Da-tenbanksystems. Die fehlende Unterstutzung dynamischerAbfragen muss entweder applikationsseitig oder durch Zu-schalten einer weiteren Technologie ausgeglichen werden.In jedem Fall bedeutet dies einen unnotig hohen Aufwand.Dennoch erwies sich die Aufgabe als lehrreich, da anhandeines praktischen Beispiels deutlich wurde, wie wichtig diesorgfaltige Auswahl des richtigen Datenbanksystems fur denErfolg einer Applikation ist.

Literatur

[1] “Apache cassandraTM 3.0,” 06.02.2017. [Online]. Available:http://docs.datastax.com/en/cassandra/3.0/index.html

[2] “Introduction to cassandra query language,” 29.12.2016. [Online].Available: https://docs.datastax.com/en/cql/3.1/cql/cql intro c.html

[3] “Netflix/astyanax.” [Online]. Available: htt-ps://github.com/Netflix/astyanax/wiki

[4] “Apache lucene 6.4.1 documentation,” 06.02.2017. [Online]. Available:http://lucene.apache.org/core/6 4 1/index.html

57

Cloudera ImpalaTimo Hauser, Enrico Schrödter, Andreas Dorn

Informatik MasterHochschule Furtwangen University

78120 Furtwangen, Deutschland{Timo.Hauser, Enrico.Schroedter, Andreas.Dorn}@hs-furtwangen.de

Zusammenfassung—Im Rahmen der Vorlesung Informations-

systeme ist den Studierenden die Aufgabe gestellt worden vorge-

gebene Abfragen auf Word-Count-Daten in einem ihnen zugewie-

senen Datenbanksystem möglichst effizient zu implementieren.

Diese Arbeit beschäftigt sich mit Cloudera Impala und der dafür

entwickelten Lösung der gestellten Aufgabe.

Index Terms—Informationssysteme; Cloudera; Impla; Hadoop

I. EINLEITUNG

Grundlage der Aufgabe waren Datensätze verschiedenerArtikel und Websites, die nach Häufigkeit einzelner Worteuntersucht werden sollen. Die ermittelten Werte sind mit URL,Zeitstempel und dem zugehörigen Wort zur Verfügung gestelltworden.

Die Erste der beiden geforderten Abfragen soll die aufsum-mierte Häufigkeit aller Vorkommen eines Worts innerhalb ei-nes bestimmten Zeitraums aufgeschlüsselt nach Tagen liefern.Für die Zweite Abfrage sind die Top X größten Häufigkeiteneines Worts in einem bestimmten Zeitintervall aufgeschlüsseltnach URL zurückzugeben.

Bevor auf die eigentliche Arbeit eingegangen wird soll andieser Stelle Impala kurz vorgestellt werden. Impala ist eineQuery-Engine für Daten, welche in Apache HBase oder demApache Hadoop Distributed File System (HDFS) abgelegtsind [1]. Hauptmerkmal ist die, für typische Datawarehousing-Szenerios, kurze Laufzeit der Abfragen. Diese hohe Geschwin-digkeit wird sowohl durch die Verwendung eines spaltenori-entierten Dateiformats, dem Parquet-Format, als auch durchdie automatische Aufteilung einer Abfrage in viele paralleleTeilabfragen erreicht.

Im Parquet-Format werden die Daten spaltenorientiert abge-speichert. Dadurch kann für eine Selektion einer Spalte den ge-samten Datenbestand hinweg ein sequentieller Lesezugriff aufdie Festplatte erreicht werden. Besonders für Aggregatsfunk-tionen wie sum() oder avg() erweist sich eine solche Strukturals nützlich. Durch die Verwendung von Kompressionsverfah-ren kann die zu Lesende Datenmenge weiter reduziert werden[2].

Um die Zeit für Festplattenzugriffe weiter zu reduzierenkann das Auslesen von nicht benötigten Datensätzen durchdie Partitionierung der Tabelle nach einem oder mehrerenSpaltenwerten verwendet werden [2]. Hierbei wird die Tabellein mehrere Dateien aufgeteilt, beispielsweise nach dem Datum.Bei einer Query auf eine solche partitionierte Tabelle werden

nur diejenigen Dateien gelesen, die von den Einschränkungender Where-Klausel einer Abfrage betroffen sind.

Die automatische Aufteilung und parallele Verarbeitung vonQueries ist Google Dremel nachempfunden [3]. Auf jedemNode arbeitet ein Deamon-Prozess, der als Query-Planer, -Koordinator und -Ausführungsengine fungiert. Die erstelltenTeilabfragen werden entsprechend den lokal vorhandenen Da-tensätzen verteilt. Dabei werden die Zwischenergebnisse sofortan die nachfolgende Aggregationsstufe weitergeleitet, um einemöglichst schnelle Bearbeitung der Query zu gewährleisten.

Vergleicht man Impala mit anderen ’SQL on Hadoop’ Lö-sungen, wie z.B. Hive, besticht Impala vor allem durch seinedeutlich schnelleren Antwortzeiten. Diese ist vor allem auf dieUnterschiede zurückzuführen, wie die jeweiligen Frameworkseine Query verarbeiten. Bei Hive muss eine Query zunächst ineinen MapReduce-Job oder einen Tez-Job übersetzts werden.Im Gegensatz dazu unterstützt Impala nativ die direkte Ab-frage von Tabellen in HDFS. Des Weiteren wird von Impala,soweit möglich, Pipelining verwendet um Zwischenergebnisseunverzüglich weiterzuverarbeiten. Dabei wird jedoch auf einePersistierung von Zwischenergebnissen verzichtet.

Im Folgenden soll zunächst das für die Umsetzung derbeiden gestellten Queries entwickelte Datenmodell vorgestelltwerden. Damit anschließend der Import der bereitgestelltenDaten in Impala erläutert werden kann. Anschließend werdendie Umsetzungen der beiden Queries, sowie deren Ausfüh-rungszeiten dargestellt. Abschließend wird noch ein Fazit be-züglich gewonnener Erfahrungen und Erkenntnisse gezogen.

II. DATENMODELL

A. Query 1

Für die erste Abfrage ist eine Tabelle mit den drei Spaltenymd, word, und frequency implementiert worden. Wobei dieSpalte ymd das Datum der Rohdaten als ganze Zahl nach demSchema ’yyyyMMdd’ repräsentiert.

Da Abfragen nur auf Tagesbasis erfolgen sollen, lohnt essich bereits beim Import der Daten von Millisekunden aufTage zu aggregieren. Des weiteren werden für Query 1 proTag und Wort sämtliche Vorkommen über alle URL hinwegaufsummiert. Damit verringert sich die später für Abfragen zuverarbeitende Anzahl an Tupeln deutlich, wie der Vergleich inTabelle I zeigt.

Um später schnelle Antwortzeiten zu gewährleisten, wirddie Tabelle nach der Spalte ymd partitioniert und als Parquet

59

Tabelle ITABELLENGRÖSSEN

Tabelle Anz. Zeilen Größe Speicherformat

Rohdaten 595.941.527 20,55 GB TSVQuery 1 54.060.076 591,76 MB ParquetQuery 2 422.109.215 3,18 GB Parquet

Datei gespeichert. So können je nach Einschränkung des abge-fragten Zeitraums, Teile der Partitionen respektive Dateien vonder Auswertung ausgeschlossen werden, was zu einer Reduk-tion der von den Festplatten zu lesenden und verarbeitendenDaten bedeutet. Impala bietet zwar einen eigenen Datentypfür Zeitstempel an, unterstützt allerdings keine Partitionierungauf Feldern dieses Typs [4]. Daher die Wahl des speziellenFormats für die Spalte ymd, um die Partitionierung nachDatum zu ermöglichen.

Die Wahl des Speicherformats der Tabelle stellt einenweiteren wichtigen Faktor für die vom Dateisystem zu lesendeDatenmenge dar. Tabelle I zeigt dies sehr deutlich. So wird fürdie Tabelle von Query 1 bei einer Reduktion der Zeilenanzahlum lediglich 41%, ein um den Faktor sieben geringerer Spei-cherplatzbedarf im Vergleich zu den Rohdaten erreicht.

B. Query 2Für die zweite Abfrage ist eine ähnliche Tabelle entwickelt

worden. Zusätzlich zu den für Query 1 beschriebenen Spaltenenthält diese noch eine Spalte url für die URL der Rohdaten.Wie für Query 1 wird auch hier nach ymd partitioniert undParquet als Dateiformat verwendet. Bei genauer Betrachtungvon Tabelle I zeigt sich welche Auswirkung dieses zusätzlicheFeld auf die Anzahl zu speichernder Zeilen hat. Da nunnicht mehr über alle URLs hinweg für ein Wort pro Tagaggregiert werden kann, steigt die Anzahl der Zeilen um fastdas achtfache.

III. IMPORT

Der Import von Daten in Impala gestaltet sich recht einfach.Für jede Tabelle die angelegt werden soll, ist im HDFS einVerzeichnis anzulegen. In dieses können anschließend beliebigviele Dateien gelegt werden, die später alle als Teil der Tabellebetrachtet werden. So ist es beispielsweise auch möglich ein-fach neue Daten zu einer bestehenden Tabelle hinzuzufügen.Die Dateien können dabei einfache CSV oder TSV Dateiensein, oder aber auch andere unterstützte Dateiformate wieParquet Files.

Um Impala die neue Tabelle bekannt zu machen kanneine externe Tabelle mit Verweis auf das zuvor angelegteVerzeichnis erstellt werden. Hierbei werden auch die Spaltenund das Dateiformat definiert. Listing 1 zeigt die zugehörigeSQL Anweisung.1 CREATE EXTERNAL TABLE pr_words_samples2 ( ymd INT,3 uri STRING,4 word STRING,5 frequency INT )6 ROW FORMAT DELIMITED FIELDS TERMINATED BY ’\t’7 LOCATION ’/user/impala/praktikum/samples’;

Listing 1. Externe Tabelle in Impala anlegen

Die erstellte Tabelle kann bereits für Abfragen verwendetwerden. Allerdings kann sie, wie bereits zuvor in AbschnittII erläutert, noch weiter optimiert werden. Aus diesem Grundwird mit der in Listing 2 abgebildeten Anweisung eine weitereTabelle angelegt. Hierbei werden die in das HDFS hochge-ladenen Rohdaten soweit möglich voraggregiert um späterschnellere Antwortzeiten bieten zu können und Speicherplatzzu sparen. Die neu erstellte Tabelle wird darüber hinausnoch nach dem Tag (ymd) partitioniert und als Parquet Filegespeichert.1 CREATE TABLE pr_words2 PARTITIONED BY (ymd)3 STORED AS PARQUET4 AS SELECT uri, word, SUM(frequency) AS frequency, ymd FROM

pr_words_samples5 GROUP BY uri, word, ymd

Listing 2. Voraggregierte Tabelle für Query1 erstellen

Wie eben für Query1 beschrieben wird eine weitere Tabellefür Query2 angelegt. Das Vorgehen ist hier grundsätzlich dasselbe. Zusätzlich wird die Spalte uri benötigt. Auch dieseTabelle wird nach ymd partitioniert und Parquet als Spei-cherformat verwendet. Listing 3 zeigt die hierzu notwendigeAnweisung.1 CREATE TABLE pr_words_url2 PARTITIONED BY (ymd)3 STORED AS PARQUET4 AS SELECT word, SUM(frequency) AS frequency, ymd FROM

pr_words_samples5 GROUP BY word, ymd;

Listing 3. Voraggregierte Tabelle für Query2 erstellen

In diesem Abschnitt wurde beschrieben, wie Tabellen fürImpala erzeugt werden können. Diese werden im folgendenKapitel verwendet um die beiden Queries zu implementieren.

IV. QUERY-IMPLEMENTIERUNGEN

Die Implementierung der beiden gestellten Queries gestaltetsich für Impala einfach, da sie sich auf Standard SQL abbildenlassen. Im nachfolgenden wird für jede Query das entspre-chende Statement kurz vorgestellt und erläutert. Anschließendwird noch auf die Laufzeiten der einzelnen Queries und dieAuswirkungen verschiedener Aspekte der Tabellengestaltungund Impala Infrastruktur auf die Ausführungszeiten disku-tiert. Die Abbildung der dargestellten Abfragen auf eine JavaSchnittstelle kann wie für die allermeisten DBMS mit einerJDBC Schnittstelle realisiert werden, und soll im Folgendendaher auch nicht genauer erläutert werden.

A. Query1

Listing 4 zeigt das für Query1 verwendete SQL Statement.Variable Parameter diese Query sind das Wort, sowie Start-und Endzeitpunkt. Als Ergebnis wird eine Auflistung dersummierten Häufigkeit eines Worts für jeden im betrachtetenZeitraum enthaltenen Tag zurückgegeben. Mit den verwende-ten Daten ließen sich auf dem HPC-Cluster der HochschuleAntwortzeiten von etwa 0,93 Sekunden erreichen. Wie späterin Abschnitt IV-C erläutert, kann diese Zeit je nach gewähltemZeitraum variieren.

60

1� SELECT� ymd,� SUM(frequency)� AS� freq� FROM� pr_words�2� WHERE� word=’merkel’3� AND� ymd� BETWEEN� 20140115� AND� 201512014� GROUP� BY� ymd

Listing�4.� Abfrage� für�Query1

B. Query2Die für Query2 verwendete Abfrage wird in Listing 5

dargestellt. Zusätzlich zu Wort, Start- und Endzeitpunkt wirdhier noch die maximale Anzahl zurückzugebender Datensätzeangegeben. Ergebnis dieser Query ist eine nach URL grup-pierte Liste der summierten Häufigkeit eines Worts über denbetrachteten Zeitraum. Die für diese Abfrage erreichten Ant-wortzeiten belaufen sich für ein Limit von zehn Datensätzenauf etwa 2,19 Sekunden. Auch hier spielt die Einschränkungdes betrachteten Zeitraums wieder eine maßgebliche Rolle,mehr dazu in Abschnitt IV-C.1 SELECT url, SUM(frequency) AS freq FROM pr_words_url2 WHERE word=’merkel’3 AND ymd BETWEEN 20150115 AND 201512014 GROUP BY url5 ORDER BY freq DESC6 LIMIT 10;

Listing 5. Abfrage für Query2

C. AusführungszeitenTabelle II zeigt die Ausführungszeit der Query 2, wobei der

betrachtete Zeitraum variiert wird. Die Daten zeigen deutlich,dass die benötigte Zeit für die Auswertung einer Query sinkt,umso weniger Partitionen für diese Query benötigt werden.Gerade für Anfragen mit deutlichen Einschränkungen des be-trachteten Zeitraums im Vergleich zur gesamten vorhandenenDatenmenge ergibt sich somit ein deutlicher Zugewinn anPerformance. Bei einer äquivalenten Auswertung für Query1 lässt sich das selbe Verhalten beobachten.

Tabelle IIAUSFÜHRUNGSZEIT QUERY 2 (WORT=MERKEL)

Startdatum Enddatum Ausführungszeit (s) Beteiligte Partitionen

- - 2.55 116501.01.2015 31.12.2015 1.17 35401.01.2015 31.01.2015 0.65 3101.01.2015 01.01.2015 0.54 1

V. FAZIT

Wie in den vorhergehenden Abschnitten deutlich gewordenist, bietet sich Impala bestens für Abfragen auf großen Daten-mengen, die in tabellenartiger Form vorliegen an. Der Importexterner Daten ist mit einem überschaubarem Aufwand ver-bunden und lässt sich auch einfach automatisieren. Anschlie-ßend kann eine geeignete Tabelle in Impala angelegt werden,die dann für verschiedenste Abfragen verwendet werden kann.Das Hinzufügen weiterer Daten zu einer Tabelle kann ohnegrößere Schwierigkeiten direkt im HDFS erfolgen, ohne dabeibesondere Rücksicht auf die Tabellen in Impala nehmen zumüssen.

Mit der Partitionierung von Tabellen bietet Impala darüberhinaus noch die Möglichkeit die verwalteten Datenmengen

sinnvoll in kleinere Abschnitte zu unterteilen. Wird diese Un-terteilung für die gestellten Anfragen geschickt gewählt, lassensich auch für große Datenmengen Antwortzeiten erreichen dieeine direkte Benutzerinteraktion ermöglichen.

Um eine optimale Performance zu erhalten sollte eine Dateiim Parquet-Format stets etwa die Größe eines Blocks im HDFSbesitzen, welche üblicherweise 256 MB beträgt. Dies gilt auchfür die partitionierten Teile eine Tabelle. Der von uns genutzteDatensatz lieferte bei der Partitionierung nach Tagen allerdingsnur Dateigrößen von wenigen MB und konnte damit nicht dasganze Potential von Impala aufzeigen.

Vor allem Bereiche, die eine schnelle und flexible Ana-lyse größerer Datenmengen erfordern, dürften zukünftig vonImpala profitieren. Anwender können hier zum einen mitgewohnten Werkzeugen wie SQL arbeiten, haben auf deranderen Seite aber auch die Möglichkeit Datenmengen zuanalysieren, die in einem herkömmlichen RDBMS so ohneweiteres nicht effizient verarbeitet werden könnten.

LITERATUR

[1] Cloudera Inc., “Using the parquet file for-mat with impala tables.” [Online]. Available:http://www.cloudera.com/documentation/enterprise/latest/topics/impala_parquet.html

[2] ——, “Apache impala (incubating) - interactive sql.” [Online]. Available:http://www.cloudera.com/documentation/enterprise/latest/topics/impala.html

[3] Haifeng Li, “Why is impala faster than hive?” [Online].Available: https://www.linkedin.com/pulse/20140910142911-22744472-why-is-impala-faster-than-hive

[4] Cloudera Inc., “Partitioning for impala tables.” [Onli-ne]. Available: https://www.cloudera.com/documentation/enterprise/5-5-x/topics/impala_partitioning.html

61

Timestamp based range queries with RedisPetra Borowski, Timo Nurnberg, David Rohatschek

Faculty of Computer ScienceFurtwangen UniversityRobert-Gerwig-Platz 1Furtwangen, Germany

{petra.borowski, timo.nuernberg, david.rohatschek}@hs-furtwangen.de

Abstract—In this short paper we give a brief overview of oursolution to the given exercise of determining word frequencies indocuments between a specified time span. We were assigned touse Redis as a database management system.We start with a short introduction to Redis, which is followedby our data models. After an analysis of the runtime behaviorof our solution, we describe why key/value stores should not beused to query in big data environments.

Index Terms—Redis, dense numbering, key/value store, bigdata

I. REDIS

Redis is an in-memory data structure store which can beused as database, cache and message broker. Strings, hashes,lists, sets, and sorted sets with range queries are amongst themany data structures Redis supports Atomic operations can berun on these types, for example, computing set intersection,union, and difference, or evaluating the member with thehighest ranking in a sorted set. Although Redis is workingwith an in-memory dataset, there are also ways to persist dataeither through dumping it on disk or appending each commandto a log.In our implementation we choose to use sorted sets as datastructures for queries 1 and 2. This choice was based uponone of the use cases for sorted sets, top-k determination. 1

Score Payload20140101 1;120150101 3;220150101 2;620150102 5;3

TABLE IEXAMPLE DATA SET

II. QUERY 1The data structure of query 1 is based entirely on sorted

sets. As mentioned before, sorted sets are ideally suited fortop-k and range tasks, as they provide built-in functionsto retrieve score based results. Each distinct word in theLCD data set is represented as a sorted set. Any occurringword is assigned to the sorted set with the following key”/words/*placeholder*”, the placeholder is substituted with theoccurring word. Inside the sorted set the summarized word

1https://redis.io/topics/data-types-intro#sorted-sets

occurrence, further referenced as frequency, and its URI arestored as payload. The URI is the link to the correspondingdocument in which the word appeared. The aggregated timestamp (yyyyMMdd) is then used as score for the new entryinside the sorted set. As seen in figure 1 the word ”Wetter”with the time stamp 20150101, and the frequency 3 in URI2 is stored in the sorted set ”/words/Wetter”. A new sortedset is created by default if the ZADD operation is called forthe first time. If the sorted set already exists ZADD inserts thenew entry within time complexity of O(log(N)), where N isthe number of elements in the sorted set.

Fig. 1. data model of query 1

A. Querying the ResultThe built-in operation ZRANGEBYSCORES is utilized to

construct query 1. To retrieve the accumulated word fre-quency of a word within a time span on each distinctday in the time span, the start and end point must bepassed to ZRANGEBYSCORE with the optional parameterWITHSCORES. Without the optional parameter the resultscannot be assigned to the event day, since the score is notretrieved by default. The ZRANGEBYSCORE operation withoutlimit is executed within the time complexity of O(log(N) + M),where N is the number of elements in the sorted set and Mthe number of elements being returned.

B. Processing the ResultThe data stored inside Redis is handled as string. There-

fore, the returned result of ZRANGEBYSCORE needs furtherrefinement to fulfil query 1. As seen in table I, our payloadis constructed with the information (word frequency:uri). Thepayload must be split on the character ’:’. The splitting of data

63

can be achieved through various approaches. For example, wecould separate the data on the client side, or Redis could doit by means of using a Lua script.However, we could not determine the run time or resultsize in query 1. This could lead to a Lua timeout in Redis.Therefore, we had to choose to split the data on the clientside. String separation and summarization of the result is quitea costly operation and not suited to be used inside a Luascript. Typically, Lua scripts are reserved for short and atomicoperations.

III. QUERY 2In query 2, we want to determine the top-k of URIs

for certain words in a certain time frame. The result ofquery 1, distinct timestamps of the sorted set /words/Wetterwithin its time frame, are needed in order to form the keyfor new sorted sets. The keys of our new sorted sets are/words/*keyword*/*timestamp*. Within these sorted sets wehave frequency of the word as score, and uri-hash as value.In Figure 2, we have two sorted sets, as we only havetwo timestamps, in which the first set has two entries, andthe second has only one. Sorted sets are capable of unions.

Fig. 2. data model of query 2

ZUNIONSTORE computes the union of numkeys sorted setsand stores the result in a new destination. The resulting scoreof elements is the sum of all its scores in every sorted set itexists in. ZUNIONSTORE operates with a time complexity ofO(N)+O(M log(M)) with N being the sum of the sizes of theinput sorted sets, and M being the number of elements in theresulting sorted set. As seen in Figure 2, every frequency anduri-hash in the given time frame are written into one sortedset /word/Wetter/*timeframe*. Our resulting sorted set nowcontains three entries of different word frequencies belongingto a different uri-hash. The default order of sorted sets isascending, but for query 2 we need the top-k, and thissimply means the reversed order of the current sorted set. Toachieve this we use ZREVRANGEBYSCORE. This commandreturns all elements in the sorted set with a score betweenmax and min value. The elements are then ordered fromhigh to low scores. If elements have the same score, theywill be returned in reverse lexicographical order. Apart fromthis reversed ordering ZREVRANGEBYSCORE is similar toZRANGEBYSCORE, and yields the same time complexity ofO(log(N)+M).

Fig. 3. data model of query 2

IV. EVALUATION

The measurement was done on a virtual machine with thefollowing specifications:

• Intel Core i5-3320M CPU @ 2.60GHz• 512MB RAM• Debian 8.7 on kernel 3.16.0-4-amd64• Redis 2.8.17

For query 1 we measured a runtime of 3 milliseconds withthe search term ”Trump” between the timespan 01.01.2014-20.11.2016. Query 2 took, with identical arguments, 4 mil-liseconds longer. The longer runtime of query 2 opposed toquery 1 was to be expected, as there are more function callsinvolved.

V. DENSE NUMBERING

Redis stores data in the main memory of the machine.Hence, it is important to reduce the footprint of the storeddata. We use dense numbering to map the URI onto an integer.Each new URI is assigned to an identifier. We use two sets tostore the URI and identifier as key and value. The identifieris generated through a counter which is incremented for eachnew URI written to Redis. Each time an URI is read, we queryRedis to check if the URI already has a dense id reference.If not, we add the URI to the set and increment the densecounter. Figure 4 shows the memory footprint along the stagesof compression. As you can see, dense numbering reduces thememory footprint by approximately 90%.

0

100

200

300

400

500

600

700

800

rawdata aggregated aggregated+dense

Mem

ory

in m

b

Fig. 4. Memory Footprint reduction through aggregation and dense number-ing.

64

VI. WHY KEY/VALUE STORES ARE NOT THE RIGHTCHOICE

This assignment seems to be a typical big data task. Bothqueries might require to process the whole data batch as worstcase. Furthermore, in the real world the processed data wouldbe growing, as new data for each day would be appendedto the data set. Marz et. al. describe in their book Big Data[1] an effective architecture to process large amounts of data,and give some reasons why key-value stores are the wrongchoice for storing big data. First of all, our data consists ofURLs, timestamps, words and their frequencies. This dataonly contains values without an index or key. In big data,data is consumed in large bulks and does usually not requirekeys to access single values. Hence, we were forced to createa surrogate key in order to work with Redis.

Secondly, key-value stores need access to each and everykey. We cannot compress multiple key-value pairs. In casethat we would have to operate with far more data than wealready had, Redis would quickly reach the end of its limit,resulting in almost no option of tuning the trade-off betweenstorage and processing costs [1].

Thirdly, the given data model consists of immutable data.New values of further days will only be appended to theexisting data. So there is no need to change data, that is alreadywritten to Redis, because a key/value store is optimized formutable data to efficiently change values given for a key. Thisdoes not directly influence our solution to this assignment, butnevertheless adds to the complexity of the tool, while we stillwant to maintain minimal complexity.

VII. CONCLUSION

We used Redis in order to determine timestamps and top-kof URIs for certain words in a set time frame. Redis was ableto process our queries in a reasonable amount of time, althoughwe were only able to use the small data set, because wewere limited by our hardware and available ram. Nevertheless,implementing our solution was relatively easy. On the plusside, we were able to keep the traffic between server and clientto a minimum.

However, we do not recommend to use Redis in the contextof big data as it is not optimized to be used in such anenvironment.

REFERENCES

[1] N. Marz and J. Warren, Big Data. Manning Publications Co., 2015.

65

1

Komplexe Datenanalyse mittels MongoDBSimon Hubner⇤, Cedric Schweizer†

Fakultat Informatik, Hochschule FurtwangenRobert-Gerwig-Platz 1

78120 FurtwangenEmail: ⇤simon.huebner@hs-furtwangen.de, †cedric.schweizer@hs-furtwangen.de

Zusammenfassung—Die vorliegende Arbeit prasentiert das

Ergebnis einer Untersuchung des Datenbanksystems MongoDB

im Bereich der Datenanalyse. Die Aufgabe war zum einen, ein

geeignetes Datenmodell fur die zur Verfugung gestellten Daten zu

entwickeln. Zum anderen mussten anhand dieses Datenmodells

zwei Abfragen realisiert werden, deren Ergebnisse nach einer

moglichst kurzen Zeitspanne verfugbar sein mussen. Neben der

Entwicklung des Modells und der Abfragen, geht diese Arbeit

auf die Optimierung der gefundenen Losung ein. Abschließend

folgt eine Analyse und Bewertung der erreichten Performanz.

Dabei zeigt sich, dass MongoDB viel Potenzial im Bereich der

Datenanalyse bietet und eine effiziente und einfach zu implemen-

tierende Problemlosung der Aufgabenstellung moglich macht.

Index Terms—MongoDB, Datenanalyse, Schlusselwortsuche,

Indexoptimierung

I. EINLEITUNG

Unsere Aufgabe war es, die Datenverwaltungund die eingangs erwahnten Abfragen mit demdokumentenorientierten Datenbanksystem MongoDBzu realisieren. Unser Beispieldatensatz umfasste 1.450Datensatze, aus denen 387.609 Datenbankdokumente erzeugtwurden. Ziel der Arbeit war es, eine geeignet Datenstruktur zufinden und die durch MongoDB bereitgestellten Funktionenwie Indizierung und Aggregation sinnvoll zu nutzen. Vorgabewar, dass die zu entwickelnden Abfragen innerhalb von einerSekunde bearbeitet sind.

Im konkreten handelt es sich bei den zur Verfugunggestellten Daten um statistische Worthaufigkeiten bestimmterInternetseiten die zu definierten Zeitpunkten ermittelt wurden.Gefordert ist die Umsetzung zweier Abfragen aus demOLAP-Umfeld1. In der ersten Abfrage wird ein Zeitraum undWort spezifiziert. Die Antwort der Abfrage soll eine Liste mitden aufaddierten Worthaufigkeiten auf Tagesbasis enthalten.Die zweite Abfrage spezifiziert dieselben Eingangsparameterund zusatzliche eine Maximalanzahl an Ergebnissen. DieAntwort darauf enthalt die Internetadressen mit den meistenWortvorkommen in absteigender Reihenfolge.

In Abschnitt II wird das zum Einsatz kommende Datenbank-system vorgestellt. Außerdem wird die gewahlte Datenstrukturerlautert und die zur Losung der Aufgabe entwickelten Ab-fragen werden aufgezeigt. Im Anschluss daran werden in Ab-schnitt III die Moglichkeiten zur Indizierung und Optimierung

1System, das auf komplexe Datenanalysen ausgelegt ist.

fur MongoDB vorgestellt. Des Weiteren wird in Abschnitt IVder Aufbau und das Ergebnis unserer Performance-Messungprasentiert. Abschnitt V nimmt ein abschließendes Fazit vor.

II. VORGEHEN ZUR LOSUNG DER AUFGABE MITMONGODB

Mongo steht fur humongous was gigantisch oder riesigbedeutet. MongoDB wurde mit dem Ziel entwickelt, eineschemalose und dokumentenorientierte Datenbank fur riesigeDatenmengen bereitzustellen. Bei dem Datenbanksystem han-delt es sich um eine Open-Source-Software, die derzeit durchdie Firma MongoDB, Inc. verwaltet wird. Begonnen wurdemit der Entwicklung im Jahre 2007. Mittlerweile umfasstdas Datenbanksystem eine Vielzahl an Eigenschaften, wieeine eigene Abfragesprache, sekundare Indizes, Replikation,Sharding und ein machtiges Aggregations-Framework [1].

A. Entwicklung eines DokumentenmodellsIn diesem Kapitel geht es um die Entwicklung eines

Datenmodells zur Problemlosung der beiden Abfragetypen.Da es sich bei MongoDB um eine dokumentenorientierteDatenbank handelt, ist die zugrundeliegende Strukturder Datensatze dokumentenbasiert. Dabei ist dieDokumentenstruktur von essentieller Bedeutung, da sichan ihr die spateren Abfrage- und Optimierungsmoglichkeitenorientieren. Grundvoraussetzung war eine einheitlicheStruktur fur alle Dokumente, sodass beide Abfragetypendurch dieselben Datensatze bearbeitet werden konnen. Dasprimare Ziel beim Design der Dokumentenstruktur war, dassbereits vor der Laufzeit moglichst viele Daten aggregiertwerden konnen. Bei einer Aggregation werden entsprechendeDaten zusammengefasst, in der Form wie sie durch dieGeschaftslogik benotigt werden. Durch die Aggregation vorder Laufzeit kann die spatere Performanz der Abfragen starkerhoht werden. In diesem Kontext war ein weiteres Ziel,dass die Daten bereits logisch gruppiert abgelegt werden,sodass die Dokumentensuche beschleunigt und die Anzahlan Dokumentenzugriffe minimiert wird. Der Speicherbedarfder Dokumentenstruktur sollte moglichst gering sein, wasdurch die Minimierung von Redundanzen erreicht wird.Teilweise konkurriert diese Forderung aber mit einem hochperformanten Datenzugriff. Im Zweifel und im Kontext einesOLAP-Systems besitzt der performantere Zugriff in dervorliegenden Problemlosung die hohere Prioritat.

67

2

Bei der nachfolgenden Listing 1 handelt es sich um einBeispieldokument im JSON-Format. Der Abbildung kann dieentwickelte und implementierte Dokumentenstruktur entnom-men werden. In dieser existiert fur jede Wort-Tag-Kombinationein eigenes Dokument. Dabei ist die Gesamtanzahl derWorthaufigkeit, fur die entsprechende Wort-Tag-Kombinationbereits voraggregiert. Die einzelnen Datenquellen, mit ihrerjeweiligen Worthaufigkeit, werden dynamisch innerhalb einesFeldes hinterlegt. Dies ist jedoch nur fur den zweiten Abfrage-typ relevant. Bedingt durch die Dokumentenstruktur sind dieDaten bereits nach einzelnen Tagen gruppiert, wodurch dieZeitstempel an Genauigkeit verlieren. Fur die Abfragetypenist dies jedoch nicht von Nachteil und in der vorliegendenAufgabestellung, aufgrund einer erhohten Performanz, sogarvorteilhaft. Da keine dynamischen Elementnamen verwendetwerden, gibt es in Sachen MongoDB-Optimierungen keineBeschrankungen.

Listing 1DOKUMENTENMODELL

{

"Wort": "stop",

"Tag: 1439157600000,

"Gesamthaufigkeit": 3,

"Wortvorkommen": [

{

"URI": "http://www.aol.com/...",

"Haufigkeit": 1

},

{

"URI": "http://www.google.com/...",

"Haufigkeit": 2

}

]

}

Durch die entwickelte Dokumentenstruktur kann dererste Abfragetyp ohne Laufzeitaggregation gelost werden.Dafur mussen nur alle Dokumente mit dem gesuchtenWort, innerhalb des gesuchten zeitlichen Bereichs, gefundenund die relevanten Daten ausgegeben werden. Fur denzweiten Abfragetyp ist zusatzlich eine Aggregation nach denWortvorkommen mit anschließender Sortierung notwendig.

Da jedes Dokument nur die Information uber ein einzel-nes Wort an einem einzelnen Tag besitzt, mussen keine furdie spezifische Abfrage unnotigen Daten, geladen werden.Gleichzeitig werden alle entsprechenden Vorkommnisse ineinem einzelnen Dokument gehalten und aggregiert. Dadurchergibt sich fur die Abfragetypen eine passende Balance ausDokumentengroße und Dokumentenanzahl. Fur jede Abfragemussen maximal n Dokumente geladen werden, wobei n derAnzahl an Tagen im gesuchten Zeitraum entspricht.

B. Abfragen zur Losung der AufgabeIn diesem Kapitel liegt der Fokus auf den MongoDB-

Abfragen zur Losung der beiden Problemstellungen. Diezur Verfugung gestellten Daten wurden voraggregiert

und in das zuvor erlauterte Datenmodell transformiert.Daraufhin folgte der Import in eine MongoDB-Datenbank.Die Transformierung und der Importvorgang wurdenuber eine Java-Clientanwendung realisiert, die fur dieGesamtbearbeitung aller 387.609 Datensatze rund 98Sekunden benotigte. Auch die Abfragen wurden durch dieseAnwendung umgesetzt. Die konkreten Implementierungenwurden mithilfe der Builderklasse [2] der MongDB-Java-Bibliothek durchgefuhrt. Durch diese Abstrahierung konnteeine geringere Fehleranfalligkeit und eine hohere Robustheit,vor allem in Bezug auf Versionsanderungen, erreicht werden.

a) Abfrage 1: Fur die erste Abfrage wird die Suchfunk-tion von MongoDB genutzt. Dabei werden alle Dokumentemit dem spezifizierten Wort, innerhalb des definierten Zeitrau-mes, gesucht. Daraufhin folgt eine Projektion, damit nur diebenotigten Attribute Tag und Worthaufigkeit zuruckgegebenwerden. Die folgende Abbildung 2 zeigt eine beispielhafteAbfrage in der MongoDB-Abfragesprache.

Listing 2ABFRAGE 1

db.WordInfoCollection.find({

$and: [{

Wort: "stop"

}, {

Tag: {

$gte: 1388530800000,

$lte: 1420066800000,

}

}]

}, {

Tag: 1,

Gesamthaufigkeit: 1

})

b) Abfrage 2: Bei der zweiten Abfrage findet dieMongoDB-Aggregation-Pipeline2 ihre Anwendung. Diesewird benotigt, um die einzelnen Wortvorkommen, inner-halb des definierten Zeitraums, zu aggregieren. Diese Ag-gregation ist notwendig, da fur dieselbe Datenquelle, meh-rere Datensatze fur jeweils unterschiedliche Tage existierenkonnen. Anstatt der Aggregation-Pipeline konnte dafur auchdie MapReduce-Funktionalitat3 von MongoDB eingesetzt wer-den. Diese benotigt fur die vorliegenden Datenmengen jedocheine langere Rechenzeit und bietet dabei eine geringere Flexi-bilitat. Da auf den Elementen des Feldes fur die Worthaufigkeitnicht direkt gearbeitet werden kann, muss dieses zuvor ubereine Pipeline per Unwind-Funktionalitat entpackt werden. DiePipeline fuhrt nacheinander die Suche, Gruppierung, Sor-tierung und Limitierung des Ergebnisses aus. Das folgendeListing 3 zeigt eine beispielhafte Abfrage in der MongoDB-Abfragesprache, wobei die einzelnen Aggregationsstufen grunmarkiert sind.

2Funktionalitat um mehrere Verarbeitungs- und Aggregationsstufen anein-andergereiht auszufuhren.

3Programmiermodell fur die parallele Aggregation von großen Datenmen-gen

68

3

Listing 3ABFRAGE 2

db.WordInfoCollection.aggregate([{

$match: {

$and: [{

Wort: "stop"

}, {

Tag: {

$gte: 1388530800000,

$lte: 1420066800000,

}

}]

}, {

$unwind: "$Wortvorkommen"

}, {

$group: {

_id: "$Wortvorkommen.URI",

sumHaufigkeiten: {

$sum: "$Wortvorkommen.Ha

ufigkeiten"

}

}

}, {

$sort: {

sumHaufigkeiten: -1

}

}, {

$limit: 5

}

}])

III. OPTIMIERUNG DER LOSUNG

MongoDB bietet eine große Anzahl an Optimie-rungsmoglichkeiten. Im Nachfolgenden wird auf einigedieser Optimierungen naher eingegangen.

A. IndexDurch MongoDB werden unterschiedliche Arten

der Indizierung unterstutzt. Dazu gehoren klassischeIndizes auf einzelne Felder, fur die Textsuche optimierteIndizes, hashbasierte Indizes fur eine besonders effizienteVerteilung, sowie Indizes fur Geodaten. Fur die vorliegendeProblemstellung sind außerdem der zusammengesetzte undfeldbasierte Index relevant.

Ein Index wird bei MongoDB immer im Zwischenspeichergehalten, weswegen seine Große kritisch analysiert werdenmuss. Sofern eine Abfrage komplett durch einen Indexgelost werden kann, entfallt das Laden der Dokumentevom persistenten Speicher und die Abfrage wird direktaus dem Zwischenspeicher heraus bearbeitet. Sofern fureine Abfrage kein passender Index vorhanden ist, bestehtdie Moglichkeit einen vorhanden Index, der einen Teil derrelevanten Informationen enthalt, zur Losung der Abfrageheranzuziehen. Fur die Bearbeitung der Abfrage kann auch

die Schnittmenge mehrerer, voneinander unabhangiger Indizesverwendet werden. Diese Funktionalitat ist standardmaßigaktiv und wird automatisch im Hintergrund ausgefuhrt. DiePerformanz der Abfrage mithilfe eines passenden Index istjedoch immer hoher.

Fur die vorliegende Problemstellung wurde einzusammengesetzter Index verwendet. Dabei ist dieReihenfolge der einzelnen Elemente von großer Bedeutung.Die Reihenfolge spezifiziert automatisch die Struktur desinternen Indexbaums, wodurch der Index mehr oder wenigereffizient zu den Abfragen passt. Fur die beiden Abfragenwurde ein zusammengesetzter Index auf die Elemente Wort-Tag, in jeweils absteigender Reihenfolge, gewahlt. Dadurch isteine, auf die beiden Abfragen bezogene, fragmentierungsfreieIndexabfrage moglich. In diesem Kontext bedeutet dies,dass keine nicht relevanten Indexblatter durchlaufen werdenmussen und die Elemente innerhalb des relevanten Bereichesdirekt ausgewahlt werden konnen. Ware die ReihenfolgeTag-Wort mussten auch Indexblatter mit nicht gesuchtenWortern durchlaufen werden.

Die nachfolgende Tabelle I zeigt dabei beispielhaft, wiedie Unterschiede der Index- und Dokumentenzugriffe je nachIndextyp ausfallen. Die Analysewerte stammen dabei vonden sehr detaillierten MongoDB-Entwicklungsausgaben, de-nen fast jeder interne Bearbeitungsschritt entnommen werdenkann. Es wurde eine Abfrage des ersten Abfragetyps gestellt,wobei die Antwort 47 Dokumente lieferte. Wie zu erkennenist, werden bei einem optimal gewahltem Index nur die wirk-lich notigsten Indexblatter durchlaufen und dementsprechendauch nur auf die notigsten Dokumente zugriffen. Ohne Indexwerden hingegen alle 387.609 Dokumente durchsucht.

Tabelle IVERGLEICH DER VERSCHIEDENEN INDIZIERUNGEN

Indextyp Durchlaufene Indexblatter DokumentenzugriffeKein Index 0 387.609Index [Tag, Wort] 441 47Index [Wort, Tag] 47 47

B. Partitionierungen

MongoDB unterstutzt Partitionierungen, wobei die Doku-mente auf unterschiedliche Knoten aufgeteilt werden. Mitder vorliegenden Datenstruktur ließe sich eine hashbasiertePartitionierung nach dem Wort-Element einfach und effizientumsetzen. Trotz der Hashfunktion wurden gleiche Worter aufgleichen Knoten abgelegt, aber die Verteilung der Worterauf die Knoten ware etwas gleichmaßiger und nicht mehrvollstandig von der statistischen Worthaufigkeit abhangig.

C. Caching

In unterschiedlichen Bereichen von MongoDB wirdCaching eingesetzt. Wenn eine Abfrage keine genaueSpezifikation bezuglich des zu nutzenden Index enthalt, fuhrtMongoDB eine entsprechende Untersuchung durch. Das

69

4

Ergebnis dieser Untersuchung wird zwischengespeichert undbei ahnlichen Abfragen erneut verwendet.

In neueren MongoDB-Versionen werden standardmaßig allegespeicherten Dokumente zusatzlich im Zwischenspeicher ge-halten, sofern diese eine bestimmte Große nicht uberschreitenund indiziert sind. Falls diese Große nicht ausreichend ist,werden nur haufig angeforderte Dokumente bereitgestellt. Diesfuhrt zu einer starken Erhohung des Durchsatzes zu Lastendes Speicherverbrauchs. Fur die nachfolgenden Kapitel wirddiese Funktionalitat explizit nicht genutzt, damit vergleichbareErgebnisse mit messbaren Ausfuhrungszeiten erreicht werden.Die Ergebnisse von Abfragen werden in MongoDB nie zwi-schengespeichert, sodass auch mehrere identische Abfragenimmer neu bearbeitet werden.

IV. MESSUNGEN ZUR PERFORMANCE DER LOSUNG

In diesem Abschnitt wird der Aufbau der durchgefuhrtenPerformance-Tests beschrieben und die Testergebnisse werdenaufgezeigt. Die Tests wurden auf einer virtuellen Maschine(VM) mit zwei Intel Core i5 Prozessoren mit 2.30 GHz und4 GB Arbeitsspeicher durchgefuhrt. Bei dem eingesetztenMongoDB-Datenbanksystem handelt es sich um die Version2.4.10 aus den Paket-Quellen der Debian 8 Distribution.Es wurden keine Anderungen an der Paketkonfigurationvorgenommen.

Gemessen wurde die Ausfuhrzeit der Abfragen inMongoDB. Dadurch werden mogliche Verzogerungen durchden Client und andere Randeffekte eliminiert. Zur Messungder Ausfuhrzeit kommt das MongoDB eigene Profilingzum Einsatz. Dies kann innerhalb der Mongo-Shell mitfolgendem Aufruf aktiviert werden: db.setProfilingLevel(2).Wenn das Profiling aktiviert wurde, speichert MongoDB einProfil von jeder Anfrage in der Kollektion mit den Namendb.system.profile ab. Das Profil beinhaltet unter anderemdie Millisekunden, welche fur die Ausfuhrung benotigtwurden, die Anzahl an gelesenen Dokumenten, die Abfrageselbst und einen Zeitstempel. Um das Cache-Verhalten desBetriebssystems so weit wie moglich zu eliminieren, wurdevor jeder Anfrage der Linux Kernel angewiesen, seinen Cachezu bereinigen. Dazu wurde die MongoDB-Instanz gestopptund die Zahl 3 in die Datei /proc/sys/vm/drop caches desvirtuellen Kernel Dateisystems geschrieben [3].

Anschließend wurden 500 Abfragen, jeweils mit undohne Index ausgefuhrt. Im Anschluss wurden die Profildatenausgelesen und ausgewertet. Dabei hat sich gezeigt, dass dieAbfrage 1 mit Index etwa 23 Mal schneller ist, als ohneIndex. Bei Abfrage 2 beschleunigt ein Index die Ausfuhrungder Anfrage um etwa das 21-Fache. Anhand der Datenergeben sich die in Tabelle II aufgefuhrten Perzentilen fur dieAntwortzeiten.

Weitere Versuche zeigen, dass die Antwortzeiten durchden Einsatz von MongoDB in der Version 3.4 und durchModifikationen an der Konfiguration deutlich gesteigert

werden konnen. Das liegt vor allem an dem verbessertenCachingverhalten, welches in Abschnitt III unter Punkt C.Caching beschrieben wird.

Tabelle IIANTWORTZEITEN DER ANFRAGEN 1 UND 2, MIT UND OHNE INDEX

Abfrage 1 Abfrage 2mit Index ohne Index mit Index ohne Index

50. Perzentile 54 ms 1324 ms 45 ms 1373 ms99. Perzentile 63 ms 1493 ms 58 ms 1628 ms

V. FAZIT

Die vorliegende Arbeit zeigt, dass MongoDB der gestelltenAufgabe mehr als gewachsen ist. Es wurde zwar nur miteiner vergleichsweise kleinen Menge an Daten gearbeitet,diese konnten jedoch ohne nennenswerte Verzogerung durcheine leistungsschwache VM verarbeitet werden. Bei großerenDatenmengen konnten die Daten, zum Beispiel anhand desWortes, per Sharding uber mehrere MongoDB-Instanzenverteilt werden. Die entwickelte Dokumentenstrukturbeinhaltet alle, fur die Abfragetypen relevanten Daten.Dadurch minimieren sich aufwandige Aggregationen zurLaufzeit und kostenintensive Datenzusammenfuhrungenentfallen.

Ein Negativpunkt der Losung ist das redundante Vorhaltender URLs. Dies fuhrt zu einem erhohten Verbrauch vonArbeitsspeicher. Die Auslagerung der URLs in eine separateKollektion ist aufgrund der nur rudimentaren Unterstutzungvon Referenzen in MongoDB momentan keine Option. DieBewertung der Skalierbarkeit der Losung fallt gemischtaus. Fur die Abfrage 1 steigt die Effizienz, je mehr Datenhinzukommen. Die Komplexitat der Abfrage und dieAntwortzeiten sind nur im geringen Maße abhangig vonder Anzahl an Dokumenten. Anders stellt sich das fur dieAbfrage 2 dar. Das Entpacken der eingebetteten URLsund das Sortieren der Ergebnisliste wird mit zunehmenderDatenmenge aufwandiger. Ab welcher Datenmenge tatsachlichmit großeren Einbußen bei den Antwortzeiten zu rechnen ist,lasst sich nur schwer vorhersagen.

Abschließend kann gesagt werden, dass MongoDB allenotigen Eigenschaften mitbringt, die zur Erfullung der Auf-gabe notig sind. Die Problemlosung ist hoch performant undbesitzt dabei eine geringe Komplexitat. Auch auf großereDatenmengen kann durch weitere Optimierung und Shardingentsprechend reagiert werden.

LITERATUR

[1] M. Inc, “MongoDB and MySQL Compared,” zuletzt besucht: 12.01.2017.[Online]. Available: https://www.mongodb.com/compare/mongodb-mysql

[2] ——, “MongoDB Java Driver Reference - Builders,” zuletzt besucht:31.01.2017. [Online]. Available: http://mongodb.github.io/mongo-java-driver/3.4/builders/

[3] R. van Riel and P. W. Morreale, “Documentation for /proc/sys/vm/*,”zuletzt besucht: 03.12.2016. [Online]. Available: https://www.kernel.org/doc/Documentation/sysctl/vm.txt

70

Anwendungsspezifische Performancesteigerung von Abfragen in HBase Systemen

durch konzeptionelle Aggregationen

Philipp RufHochschule FurtwangenFurtwangen, Germany

Email: philipp.ruf@hs-furtwangen.de

Timo BayerHochschule FurtwangenFurtwangen, Germany

Email: timo.bayer@hs-furtwangen.de

Burak KarakilincHochschule FurtwangenFurtwangen, Germany

Email: burak.karakilinc@hs-furtwangen.de

Zusammenfassung—Das Datenbanksystem Apache HBase

erfreut sich zunehmend großer Beliebtheit und stellt insbe-

sondere bei der Verwaltung großer nicht-relationaler Daten-

mengen eine vielversprechende Technologie dar. Aufgrund der

Besonderheiten dieses Systems und dem im Vergleich mit

herkommlichen Datenbanksystemen beschrankten Funktions-

umfang erfordert die Verwendung von HBase ein besonderes

Maß an Aufmerksamkeit bei der Wahl eines geeigneten Daten-

modells. Zur Verdeutlichung des Potenzials dieser Technologie

beschreibt die vorliegende Arbeit eine Moglichkeit, die vor-

gestellte Aufgabenstellung unter Nutzung von HBase effizient

zu losen. Hierbei werden insbesondere das gewahlte Datenmo-

dell sowie problembezogene Datenaggregierungen diskutiert.

Zur Verifikation der Adaquanz des gewahlten Datenmodells

werden Laufzeitmessungen verschiedener Datensatze sowie

ausgewahlte Skalierungsaspekte vorgestellt.

Keywords-Apache HBase, NoSQL, Spaltenorientierung, fle-

xibles Datenschema, Effizienzsteigerung durch Aggregierung

I. APACHE HBASE

Apache HBase ist ein verteiltes, hoch skalierbares OpenSource NoSQL Datenbanksystem, welches auf Grundlagevon Google BigTable erstellt wurde [1]. Der Fokus vonHBase liegt auf einer effizienten Verwaltung sehr großerTabellen mit flexiblem Datenschema [2]. Apache HBaseist ein Teil des Hadoop Okosystems und basiert auf demHadoop Distributed File System (HDFS) [3].

Apache HBase unterscheidet sich von herkommlichenrelationalen Datenbanksystemen in einigen Aspekten funda-mental. Eine wesentliche Charakteristik ist das flexible undzur Laufzeit anpassbare Datenschema von HBase. Hierbeiwird das Hinzufugen einzelner Spalten innerhalb einer ein-zelnen Zeile ohne weitere Auswirkungen auf die gesamteTabelle ermoglicht. Um dennoch eine gewisse Strukturie-rung der Daten zu erhalten und die Definition von spezifi-schen Eigenschaften zu ermoglichen, gruppiert HBase ein-zelne Spalten zu sogenannten Spaltenfamilien. Grundlegendwerden Daten auf mehrdimensionale Tabellen abgebildet,wobei konkrete Datenobjekte durch deren Zeilenschlusselund Objekteigenschaften unter Verwendung der zugehorigenSpaltenbezeichnung angesprochen werden [4].

Spaltenfamilien mussen bei der Tabellendefinition ange-geben werden und konnen individuell mit speziellen Eigen-

schaften, wie beispielsweise dem zu verwendenden Kom-pressionsverfahren versehen werden [3]. Ein weiterer Aspektdes spaltenorientierten Datenbanksystems ist die Ablage derInhalte einer Spaltenfamilie innerhalb einer Datei. Sofernlediglich eine einzelne Spaltenfamilie angefragt wird, kannder tatsachliche Lesevorgang sequenziell uber mehrere Zei-len stattfinden. Innerhalb der Dateien werden einzelne Zei-len sowie Spalten automatisch anhand der lexikografischenOrdnung ihrer Schlussel sortiert. Bei Verwendung eines ge-schickten, auf die individuelle Aufgabenstellung angepasstenDatenmodells, konnen effiziente Lesevorgange ermoglichtund teurer Random Access vermieden werden. Eine wei-tere Besonderheit ist die Verwaltung mehrerer Versionenpro Spaltenwert, wobei die Anzahl der zu speicherndenVersionen pro Datenobjekt bereits bei der Definition derzugehorigen Spaltenfamilie deklariert werden muss. Dievon HBase bereitgestellten Abfragemoglichkeiten sind imdirekten Vergleich mit dem Funktionsumfang traditionel-ler Datenbanksysteme eher schwach ausgepragt. Beispiels-weise sind Abfragen uber mehrere Tabellen oder seman-tische Einschrankungen mittels einer where-Klausel nichtdurch HBase definierbar. Des Weiteren existiert keine na-tive Moglichkeit, Fremdschlusselbeziehungen zwischen Da-tensatzen auszudrucken. Diese Einschrankungen erforderneine besonders sorgfaltige Datenmodellierung, welche dievorhandenen Starken des Datenbanksystems ausnutzt unddie bestehenden Einschrankungen umgeht.

II. DATENMODELL

Das folgende Kapitel behandelt den grundlegenden Ge-danken des im Rahmen der Aufgabe erarbeiteten Daten-modells. Anschließend werden die Umsetzung der Queriessowie verschiedene Performanceaspekte und Eigenschaftender Datenstruktur im Zusammenhang mit HBase erlautert.

A. Grundlegendes DatenmodellDie Herausforderung bei der Erstellung eines geeigneten

Datenmodells bestand darin, bestehende Limitierungen desDatenbanksystems HBase durch eine moglichst effizienteStruktur der Daten sowie der effektiven Verwendung spe-zifischer Funktionalitaten zu umgehen.

71

Abbildung 1. Grundlegendes Datenmodell

Das in Abbildung 1 aufgezeigte Datenmodell stellt dieGrundlage der in Kapitel III spezifizierten Losung dar undbesteht aus der Tabelle Words, welche wiederum die Spal-tenfamilie WordInfos beinhaltet. Das jeweilige Wort wirdhierbei als Schlussel verwendet, da ein bestimmtes Wort stetsder zentrale Bestandteil der Abfragen darstellt und HBasein der Lage ist, effizient auf diese zugreifen zu konnen.Fur jedes Dokument, welches ein bestimmtes Wort bein-haltet, wird die Spaltenfamilie WordInfos der betroffenenZeile um eine zusatzliche Spalte erweitert. Der resultierendeSpaltenname setzt sich aus dem Datum des Ursprungsdoku-ments (YYYYMMDD) sowie dessen URI zusammen. DieseVorgehensweise ermoglicht neben einer eindeutigen Na-mensgebung der Spalten, auch die automatische Sortierungder Spalten anhand des Datums und bietet daruber hinauseine zusatzliche Dimension, deren Vorteile in Abschnitt IIIdiskutiert werden. Da diverse Grundgedanken des HBase-Systems der klassischen Aufteilung von Datensatzen un-ter Verwendung eines relationalen Ansatzes widersprechen,werden die auf das jeweilige Wort bezogenen Informationen(Timestamp, Frequency, URI) als Versionen innerhalb derzugehorigen Spalte abgelegt. Die Versionen eines Daten-satzes werden durch das Datenbanksystem automatisch mitZeitstempeln versehen und anhand dieser in absteigenderReihenfolge sortiert. Um dennoch eine feste und determi-nistische Reihenfolge der Versionen zu ermoglichen, bedarfes einer manuellen Vergabe der Zeitstempel. Die Notwendig-keit zur manuellen Vergabe wird durch das programmatischeEinfugen zusatzlich verstarkt, da ansonsten die Moglichkeitbesteht, dass Versionen bedingt durch identische Zeitstempeluberschrieben werden und somit Inkonsistenzen entstehen.

III. AGGREGIERUNG DER DOKUMENTE

Aufgrund der im Vorfeld gegebenen Abfragen konntenzusatzliche Moglichkeiten zur gezielten Aggregierung derDatenmenge betrachtet werden. Diese verfolgten das Ziel,die Effizienz weiter zu steigern und somit schnellere Abfra-

gezeiten zu ermoglichen. Der folgende Abschnitt beschreibtdie gewahlten Datenaggregierungen, deren konkrete Umset-zungen sowie die daraus resultierenden Vorteile.

A. Aggregierung fur Query 1Um eine Effizienzsteigerung der Query zu ermoglichen,

wird die tagliche Summierung der auftretendenWorthaufigkeiten durchgefuhrt und in die Tabelle eingefugt.Zur Ablage der aggregierten Haufigkeiten wurde dasbestehende Datenmodell, wie in Abbildung 2 dargestellt,um die Spaltenfamilie DailyAggregation erweitert. Hierbeiwird eine Spalte, welche uber das jeweilige Datumidentifiziert wird, fur jedes Wort in WordInfo erstellt. Diegewahlte Struktur der Spaltenfamilie ermoglicht die gezielteAbfrage einer gewunschten Zeitspanne, da bedingt durchdie automatische Sortierung der Spalten die Ergebnismengederart eingeschrankt werden kann, dass lediglich dieabgefragten Tage gelesen werden mussen.

Abbildung 2. Aggregierung fur Query 1

Damit die zusatzliche Spaltenfamilie mit Informationengefullt werden kann, wird zunachst die Spaltenfamilie Word-Infos angefragt und innerhalb einer Schleife uber deren Zei-len und Spalten iteriert. Da nur Dokumente des jeweiligenTages fur die tagliche Aggregierung von Interesse sind,konnen die betroffenen Spalten, bedingt durch die gewahlteSpaltenbezeichnung und der daraus resultierenden Sortie-rung, sequenziell betrachtet werden, wobei die Schleife beierstmaligem Uberschreiten der zeitlichen Bedingung unter-brochen werden kann. Nach jeder Iteration uber eine Zeileder Tabelle wird die summierte Haufigkeit innerhalb derSpaltenfamilie DailyAggregation abgelegt. Der beschriebeneAblauf ist nachstehend abgebildet.g e t a l l rowkeys wi th CF Wordinfosf o r ( rows i n words ){

sum = 0f o r ( column i n CF Wordinfos ){

i f ( q u a l i f i e r i n TIMERANGE( day ) ){sum = sum + f r e q u e n c y

} e l s e { b r e a k }}i n s e r t sum i n t o CF Da i lyAggrega t ion

}

Aufgrund des gewahlten Datenschemas kann die Query,wie nachfolgend exemplarisch aufgezeigt, mittels einer ein-zelnen Abfrage effizient beantwortet werden.g e t ’ Words ’ , ’ merkel ’ , {COLUMN => [ ’ dag :20161101 ’

, . . . , ’ dag :20161110 ’ ]}

72

B. Aggregierung fur Query 2

Damit eine Effizienzsteigerung fur Query 2 ermoglichtwerden konnte, wurde ebenfalls eine tagliche Aggregierungder relevanten Daten durchgefuhrt. Die Aggregierung um-fasst in diesem Fall die Top-N Dokumente des betrachtetenTages. Wie in Abbildung 3 aufgezeigt, werden fur alleTop-N Dokumente eines Tages, Versionen innerhalb derSpaltenfamilie DailyTopDocuments angelegt. Damit auchin diesem Fall eine gezielte Abfrage der relevanten Tageermoglicht werden konnte, wurden die Spalten erneut an-hand des Datums identifiziert.

Abbildung 3. Aggregierung fur Query 2

Aquivalent zu der vorherigen Aggregierung findet unterNutzung der automatischen Sortierung, eine Iteration uberdie relevanten Spalten der Spaltenfamilie WordInfo statt. Furjede Spalte, die der zeitlichen Bedingung genugt, werdendie relevanten Informationen (URI, Frequency) zunachsteiner Liste innerhalb des Anwendungscodes hinzugefugt.Anschließend werden die Eintrage in der dadurch entstan-denen Liste anhand der Haufigkeit sortiert und auf die Top-N Elemente beschrankt. Damit die Reihenfolge der Listewahrend des Einfugens in die Tabelle sichergestellt werdenkann, wurde der invertierte Index der Liste als Zeitstem-pel fur die Versionen verwendet. Diese Desingentscheidungermoglicht eine gezielte Einschrankung der, einer Abfra-ge entsprechenden, Ergebnismenge. Als Wert einer jedenVersion wurde die konkatenierte Haufigkeit und URI desjeweiligen Dokumentes verwendet. Nachstehend wird derbeschriebene Ablauf aufgezeigt.

g e t a l l rowkeys wi th CF Wordinfosf o r ( rows i n words ){

f o r ( column i n CF Wordinfos ){i f ( q u a l i f i e r i n TIMERANGE( day ) ){

add w o r d i n f o t o L i s t<WordInfo>} e l s e { b r e a k }

}s o r t A n d S p l i t L i s t ( )i n s e r t topN i n t o CF DailyTopDocuments

}

Wird die Abfrage angestoßen, werden die relevantenSpalten gezielt identifiziert und entsprechend der Query, NVersionen des jeweiligen Datensatzes abgefragt. Das nach-stehende Beispiel zeigt die zugehorige Datenbankabfrage.g e t ’ Words ’ , ’ merkel ’ , {COLUMN => [ ’ d t d :20161101 ’

, . . . , ’ d t d : 2 0 1 6 1 1 1 0 ’ ] , VERSIONS => N}

Da hierbei nicht die Top-N Dokumente des gesamten Zeit-raums, sondern fur jeden Tag innerhalb des Zeitraums NDokumente abgefragt werden, muss die Ergebnismenge er-neut sortiert und auf N Elemente beschrankt werden. ImVergleich zu einer aufwendigen Iteration uber samtlicheSpalten von WordInfo konnen dennoch signifikante Perfor-mancesteigerungen erzielt werden.

Diese Vorgehensweise erfordert jedoch, dass die maxima-le Auspragung von N vor Beginn der Aggregierung bekanntist. Wird dieser Wert uberschritten, muss eine aufwendigeIdentifikation der Ergebnismenge unter Nutzung der Spal-tenfamilie WordInfo durchgefuhrt und die Aggregierung beiwiederholtem Auftreten angepasst werden.

IV. QUERY-LAUFZEITEN

Damit die Adaquanz des Datenmodells und die aus dendurchgefuhrten Aggregierungen resultierende Effizienzstei-gerung untersucht werden konnten, wurden Laufzeitmessun-gen der verschiedenen Queries durchgefuhrt. Die Messungenwurden unter Verwendung steigender Datenmengen durch-gefuhrt und umfassten die Abfrage des Wortes Merkel imZeitraum 2016. Die verwendete Hardware verfugte uber 4CPU-Kerne, 32GB RAM und einer HDD-Festplatte.

Abbildung 4. Laufzeiten beider Queries

Abbildung 4 zeigt die Ergebnisse der durchgefuhrtenLaufzeitmessungen. Deutlich wird hierbei insbesondere dieAbhangigkeit der durch die Aggregierung erreichten Effizi-enzsteigerung mit der vorhandenen Datenmenge. Wahrenddie Aggregierungen bei kleinen Datenmengen einen un-wesentlichen Performancegewinn bieten, steigt dieser beiErhohung der Datenmenge deutlich an. Dies ist dadurchzu begrunden, dass bei einem steigenden Datenvolumen dieDifferenz der angefragten Spalten zwischen Aggregierungund Rohdaten erheblich ansteigt.

73

V. ERGANZENDE OPTIMIERUNGEN

Neben den konzeptionellen Verfeinerungen desDatenmodells wurden weitere Optimierungsaspekte,wie Moglichkeiten zur gezielten Effizienzsteigerung desEinfugens der Daten, Partitionierung von Datensatzen sowiedie Skalierung auf mehrere Server betrachtet.

A. Einfugen der DatenDas initiale Einfugen der Daten kann abhangig von der

zugrunde liegenden Hardware und der einzufugenden Da-tenmenge eine erhebliche Zeit in Anspruch nehmen. Einebereits etablierte Moglichkeit, sehr große Datenmengen indas Datenbanksystem HBase einzufugen, ist die Verwen-dung geeigneter MapReduce Jobs. Diese umfassen im We-sentlichen die Transformation der einzufugenden Daten indas HFile-Format sowie das Laden der HFile in die Tabellen[5]. Im Folgenden werden jedoch die von HBase nativbereitgestellten Funktionalitaten der put-Methode behandelt.

Abbildung 5. Laufzeiten fur put list bei Einfugen der Daten

Bei erstmaligem Auftreten eines bestimmten Wortes wirdeine neue Zeile innerhalb der Tabelle Words erstellt und eineentsprechende Spalte fur das betrachtete Dokument ange-legt. Tritt ein bereits vorhandenes Wort in einem weiterenDokument auf, wird lediglich eine neue Spalte innerhalbder betroffenen Zeile erstellt. Da jede Spalte drei Werteenthalt, umfasst dies zunachst den dreimaligen Aufruf derput-Methode und dadurch implizit den Aufruf dreier Re-mote Procedure Calls an das Datenbanksystem. Damit derdaraus resultierende Overhead reduziert werden kann, emp-fiehlt sich das kombinierte Einfugen mehrerer Datensatze.Hierfur kann der Methode put eine Liste mit put-Elementenubergeben werden, welche innerhalb eines einzelnen Aufrufsubertragen werden. Unter Nutzung dieser Vorgehensweisekonnte die Gesamtlaufzeit des Einfugens, wie in Abbildung5 dargestellt, erheblich reduziert werden. Die ideale Anzahlder simultan einzufugenden Datensatze hangt dabei von derkonfigurierten Große des write-buffer ab. Die abgebildetenMessungen beziehen sich auf die Standardkonfiguration.

B. Skalierung und PartitionierungNeben den in Abschnitt I aufgefuhrten Eigenschaften bie-

tet HBase weitere Moglichkeiten der feingranularen Einstel-lung unterschiedlicher Aspekte, wie der Partitionierung vonDatensatzen und deren Verteilung uber mehrere Maschinen.Hierbei konnen einzelne Zeilen einer Tabelle anhand ihresSchlussels auf sogenannte Region Server aufgeteilt werden.Die Umsetzung erfolgt in erster Linie durch die lexiko-grafische Partitionierung der Zeilenschlussel. Die exklusiveZustandigkeit eines Region Server fur einen bestimmtenSchlusselraum birgt in diesem Anwendungsfall allerdingsdie Gefahr der lexikografischen Ungleichverteilung. Damitdennoch eine Performanzsteigerung erreicht werden kann,besteht die Moglichkeit, einen Hashwert des Wortes zubilden und als Schlussel der verteilten Words Tabelle zuverwenden. Dies stellt sicher, dass die Schlussel gleichmaßigauf die einzelnen Region Server aufgeteilt werden undermoglicht dennoch die gezielte Abfrage ohne samtlicheRegion Server anfragen zu mussen.

VI. FAZIT

In dieser Arbeit stand die Wahl eines geeigneten Da-tenmodells sowie die Aggregierung von Datensatzen furvorab bekannte Abfragen an das Datenbanksystem im Vor-dergrund. Die Definition des in Abschnitt II diskutierten Da-tenmodells musste daher unter Verwendung moglichst vieler,von HBase nativ unterstutzten Mechanismen umgesetzt wer-den. Durch eine geeignete Wahl des Datenmodells stellendie auf den ersten Blick spartanischen Funktionalitaten desDatenbanksystems HBase keine Einschrankungen dar. Vielmehr ermoglichten die vorhandenen Mechanismen eine per-formante Losung der beschriebenen Aufgabenstellung undbewiesen die Geeignetheit des Datenbanksystems fur dievorliegenden Daten.

LITERATUR

[1] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A.Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber,“Bigtable: A distributed storage system for structured data,”in Proceedings of the 7th USENIX Symposium on OperatingSystems Design and Implementation - Volume 7, ser. OSDI ’06.Berkeley, CA, USA: USENIX Association, 2006. [Online].Available: http://dl.acm.org/citation.cfm?id=1267308.1267323

[2] A. S. Foundation, “Apache hbase,” November 2016. [Online].Available: https://hbase.apache.org/

[3] D. Vohra, Apache HBase and HDFS. Berkeley,CA: Apress, 2016, pp. 9–43. [Online]. Available:http://dx.doi.org/10.1007/978-1-4842-2424-32

[4] A. Meier and M. Kaufmann, NoSQL-Datenbanken. Berlin,Heidelberg: Springer Berlin Heidelberg, 2016. [Online].Available: http://dx.doi.org/10.1007/978-3-662-47664-2 7

[5] J. Yang and X. Feng, Loading Data into HBase. Cham:Springer International Publishing, 2014. [Online]. Available:http://dx.doi.org/10.1007/978-3-319-01766-231

74

Software Engineering mobiler Systeme Mohsen Rezagholi

75

Analyse von Sicherheitsanforderungen anEntertainment- und Steuerungskomponenten im

Automobil

Ricou Jaschke B.Sc.Hochschule Furtwangen

Fakultat InformatikStudiengang: Mobile Systeme M.Sc.

E-Mail: ricou.jaschke@hs-furtwangen.de

Eduard Wolf B.Sc.Hochschule Furtwangen

Fakultat InformatikStudiengang: Mobile Systeme M.Sc.

E-Mail: eduard.wolf@hs-furtwangen.de

Abstract—Diese Ausarbeitung beschaftigt sich mit dem Thema

der Analyse von Sicherheitsanforderungen an Komponenten im

Automobil. Hierzu werden aktuell verbaute Komponenten sowie

aufkommende Trends in der Automobilindustrie analysiert. Dabei

werden die Risiken des Einsatzes von schnelllebigen Komponen-

ten, wie beispielsweise Wireless Local Area Network (WLAN),

beleuchtet. Diese Ausarbeitung soll Aufschluss darauf geben, ob

die Sicherheitsanforderungen im Automobilbereich, in Hinsicht

auf die neu verwendeten Technologien angepasst werden mussen

und wie eine solche Anpassung aussehen kann.

I. EINLEITUNG

Fur den Endverbraucher ist die Komplexitat eines heuti-gen Automobils nicht direkt ersichtlich. Dabei kommen ver-schiedene Bausteine zum Einsatz die in Verbindung zueinan-der stehen. So haben Sicherheitssysteme beispielsweise dieMoglichkeit auf Anzeigeelementen Warnungen darzustellen.Diese Vernetzung der Bauteile ermoglicht, neue Funktionenzu realisieren. Sie erhoht aber auch die Komplexitat unddamit das Risiko weiterer Fehler. Des Weiteren bedeutenSchnittstellen ein gewisses Angriffspotenzial. Beispielsweisesind Drittausruster daran interessiert, ihre Produkte moglichstkomfortabel an die bestehenden Bauteile im Automobil anzu-binden. Dabei machen sie sich die bestehenden Schnittstellenund Netzwerke zu Nutze [1].

Das Ziel dieser Arbeit ist eine Analyse der Sicherheitsan-forderungen an Automobile. Dabei soll im Mittelpunkt stehen,ob die bisherigen Sicherheitsanforderungen ausreichend furdie neu eingesetzten Komponenten sind oder gegebenenfallsangepasst werden mussen, um die Sicherheit fur die Passagieredes Automobils auch in Zukunft zu gewahrleisten.

In den folgenden Abschnitten wird genauer auf dieseProblematik eingegangen. Im Abschnitt II, State of the Artwerden aktuelle Technologien angesprochen die zur Zeit inAutomobilen zum Einsatz kommen. Dieser Abschnitt soll dasGrundverstandnis fur die aufkommenden Probleme vermittelnund auf den folgenden Abschnitt Sicherheitsrisiken vorbere-iten.

Abschnitt III setzt sich mit den Sicherheitsrisiken au-seinander. Diese werden kategorisiert. Dabei wird beleuchtet,wie mogliche Sicherheitsrisiken aussehen und welche Folgendiese fur den Endverbraucher haben konnen. Der Abschnitt

IV ist den Sicherheitsanforderungen gewidmet. Sicherheit-sanforderungen werden definiert und Automobilkomponentenanhand der Sicherheitsanforderungen erlautert. Im nachstenAbschnitt Future Work, wird beschrieben, wie zukunftig mitkurzlebigen EDV-Komponenten verfahren werden kann, umdiese im Automobil einsetzen zu konnen. Dabei wird insbeson-dere auf mogliche Anpassungen der Sicherheitsanforderungen,im Hinblick auf die Erkenntnisse der Analyse, eingegangen.Zum Abschluss folgt eine Zusammenfassung der Erkenntnisse.

II. STATE OF THE ART

Dieser Abschnitt gibt einen Uberblick uber die Technolo-gien die heutzutage in Automobilen zum Einsatz kommen.Dabei werden speziell neue Technologien und aufkommendeTrends beleuchtet. Es wird explizit auf die Technologien vonBMW und Opel (General Motors) eingegangen. Die Losungvon BMW wird betrachtet, da sie Vorreiter auf dem Gebietdes Infotainments waren und zu dem hochklassigen Segmentgehoren. Opel (GM) stellt die niedrigpreisige Alternative dar.Des Weiteren werden Faktoren wie Standardisierung vonSchnittstellen und Ubertragungsprotokolle, sowie die Ferti-gung durch Automobilzulieferer angesprochen.Im Allgemeinen sind alle Automobilhersteller an der Gunstdes Kunden interessiert, dies ist besonders gut mit neuenTechnologien, die sie von anderen Herstellern abheben, zurealisieren. Dieser Wettstreit hat mit den Smartphones einneues Level erreicht. Bereits seit Ende der 90er Jahre ist esmoglich ein Mobiltelefon mittels eines Funknetzes mit demInfotainmentsystem eines Fahrzeuges zu koppeln [10]. Dieswird durch Funktechnologien wie Bluetooth ermoglicht. Inden letzten Jahren wurden diese Technologien immer aus-gereifter. Komponenten im Fahrzeug tauschen Informationenaus, Fahrzeuge konnen untereinander kommunizieren oderKontakt zum Hersteller aufnehmen [2]. Um diese Kommu-nikation moglich zu machen sind Schnittstellen am Automobilnotig.So bieten verschiedene Hersteller die Moglichkeit eines erweit-erten Verkehrswarnsystemes an. Dabei werden Informationenvon anderen Fahrzeugen zeitnah erfasst und gegebenenfallsan Nutzer, die sich in der Nahe oder auf dem Weg zudieser Position befinden, weitergegeben. Fahrzeuge weisendie Nutzer auf eine mogliche Verzogerung hin und berech-nen eine alternative Route. Dieser Ansatz wird Car-to-Car

77

Kommunikation genannt [3] [4]. Ein anderer Ansatz ist dieKommunikation des Fahrzeuges mit seiner Umgebung. Sokonnen beispielsweise Schilder ihre jeweilige Bestimmung anein Fahrzeug ubermitteln. Diese Informationen konnen demFahrer durch das Fahrzeug aufbereitet dargestellt werden [4].Das Automobil kann gegebenenfalls Maßnahmen einleiten umeinen Verstoß der Verkehrsordnung zu verhindern. Durch dieLKW-Maut wird in Deutschland bereits eine Form der Car2XKommunikation eingesetzt [4].

BMW und Opel zeigen mit ihren Systemen, welcheFunktionen heutzutage moglich sind. Dem Nutzer wird esermoglicht, die ihm von seinem Smartphone bekannten An-wendungen im Automobil zu nutzen. Durch Integration vonSchnittstellen der Smartphone-Anwendungen in die Infotain-mentsysteme der Automobile, soll dem Nutzer ein vertrautesGefuhl vermittelt werden. Das Fahrzeug integriert sich indas Leben des Nutzers [10]. BMW wie auch Opel bietenihren Kunden die Moglichkeit, uber eine eigene SmartphoneAnwendung weitere Funktionen zu nutzen. Dabei stehen Infor-mationen fur den Nutzer im Vordergrund. Der Nutzer kann seinFahrzeug wiederfinden (Kartenansicht, Akustische Signale,Visuelle Signale), Ent- und Verriegeln, Statusinformationenwie notwendige Wartungsarbeiten abrufen und gegebenenfallsdas Fahrzeug fahruntuchtig machen (Diese Option bietet Opelin ausgewahlten Landern an) [9]. Automobile konnen imNotfall eigenstandig den Notruf alarmieren und somit zurSicherheit beitragen [10]. Des Weiteren wird den Insassen dieMoglichkeit gegeben die Internetverbindung des Fahrzeugeszu nutzen. Opel hat hierfur einen WLAN-Zugangspunkt imAutomobil verbaut. Bei BMW konnen Nutzer das Internet nuruber die im Fahrzeug vorhandenen Systeme verwenden.

III. SICHERHEITSRISIKEN

In diesem Abschnitt werden aktuelle Sicherheitsrisikenin Bezug auf das Automobil dargestellt und eine moglicheRisikoklassifizierung wird erlautert. Außerdem werdenAngriffe aufgezeigt und die Sicherheitsrisiken werdenabschließend gruppiert und zudem bewertet.

A. Klassifizierung von Sicherheitsrisiken

Im Hinblick auf Sicherheitsrisiken konnen die imAutomobil verwendeten Komponenten in drei Gruppeneingeteilt werden: Interne Komponenten, externeKomponenten und Kommunikationsprotokolle. Zur erstenGruppe zahlen die ECU (Electronic Control Unit), dasNetzwerk im Fahrzeug, welche aus Bussystemen aufgebautsind, und mogliche Verbindungsgateways [6]. Diese Gatewaysdienen zum einen zur Verknupfung von internen Netzwerkenund zum anderen dient ein Gateway als Schnittstellenach Außen, dem Internet. Das zweite Sicherheitsrisikosind Mobile Devices, welche mit den Komponenten imAutomobil verbunden werden. Dies kann zum Beispielein Smartphone sein, welches sich uber Bluetooth mit derEntertainmentkomponente verbindet, um Musik abspielenzu lassen [6]. Als drittes Sicherheitsrisiko werden dieKommunikationsprotokolle klassifiziert. Dazu zahlen zumBeispiel WiFi oder Bluetooth [6]. Die Klassifizierungder Sicherheitsrisiken wird durch Punkte wie Protokolle,Authentifizierung, Autorisierung, Verschlusselung und

Datenschutz erganzt. Diese Punkte spielen bei alleneine entscheidende Rolle. Die einzelnen Klassen derSicherheitsrisiken werden im Folgenden nun genauerdargestellt und bewertet.Die Steuergerate (Electronic Control Unit) im Automobilbesitzen alle einen Diagnosezugang (On-Board-Diagnose).Der physische Zugang stellt ein Risiko dar. Angreifer konnendurch diesen Zugang und mit manipulierten Daten in dieSysteme eindringen und Schadcode ausfuhren [6]. In neuerenAutomodellen kann die Firmware von Steuergeraten sogaruber das Internet aktualisiert werden. Ein Angreifer konnte dieVerbindung kapern und eigenen Code aufspielen. Er ware inder Lage das Auto komplett zu steuern. In diesem Fall spieltdie Datenintegritat eine große Rolle. Die Steuergerate mussenprufen, ob die Daten geandert wurden [6]. Ein weiterer Punktist die Kommunikation zwischen Microcontrollern. Wenndiese unverschlusselt ablauft, konnen Daten im Klartextmitgelesen werden. Dazu muss der Angreifer allerdingsphysischen Zugang zu einem Steuergerat haben [6].Ein weiteres Risiko stellen die Netzwerke im Automobildar. Hierzu zahlen LIN, CAN, FlexRay und MOST. Beider Entwicklung dieser Netzwerkprotokolle waren die Zielezum einen die Zuverlassigkeit und zum anderen sollten siekostengunstig sein [6]. Sie sind ein in sich geschlossenesNetzwerk mit einer festen Topologie. Durch die Anbindung derAutomobile an das Internet wird dieses in sich geschlosseneNetzwerk aufgelost. Ein Angreifer konnte zum Beispiel miteinem Denial-of-Service-Angriff das Automobilnetzwerklahm legen und dadurch eventuell das komplette Automobilunkontrollierbar machen [6].Die Sicherheitsrisiken der Komponenten im Automobillassen sich durch die Gateways abschließen. Diese bildendie Schnittstelle zwischen den internen Automobilnetzwerkenund der Außenwelt (WiFi, GSM, Bluetooth) [6]. DasGateway muss die ankommenden Daten in eine Formverarbeiten, damit die internen Automobilnetzwerke dieseDaten interpretieren konnen [6]. Durch diese Ubersetzungs-und Interpretationsfunktionen muss das Gateway Kenntnisuber die Verschlusselung der Daten und der Datensemantikbesitzen [6]. Diese Tatsache macht das Gateway fur Angreiferzum perfekten Ziel. Beispielsweise konnte ein Angreiferuber die Entertainmentkomponente auf andere Steuergeratezugreifen. Dazu verbindet sich der Angreifer per Bluetoothmit dem Radio und fuhrt Schadcode ein [6].

Der zweiten Gruppe risikokritischer Komponenten gehorendie Mobile Devices an [6]. Unter Mobile Devices sind hierSmartphones oder Tablets zu verstehen, welche sich mitden Komponenten im Automobil verbinden. Der bekanntesteAnwendungsfall ist das Abspielen von Musik uber Bluetooth.Normalerweise werden Automobile als geschlossenes Systembetrachtet. Ahnlich wie bei dem Zugang zum Internet,wird dieses geschlossene System durch die Integration vonexternen Geraten aufgelost. Dadurch entstehen neue Risikenund Angriffsflachen uber diese externen Mobile Devices[6]. Durch veraltete Betriebssystemsoftware in den MobileDevices und nicht geschlossenen Sicherheitslucken entstehteine neue Angriffsflache mit Hilfe der Mobile Devices [6].Bedrohungen konnen beispielsweise uber Apps erfolgen,welche sich mit den Komponenten verbinden [6]. DasProblem bei den Mobile Devices ist, dass diese nicht fureine maximale Sicherheit, wie es im Automobil notwendig

78

ist, entwickelt wurden. Daher sind die Mobile Devices deranfalligste Punkt im kompletten Kommunikationsfluss [6].

Zur dritten Gruppe der Sicherheitsrisiken zahlen dieeingesetzen Kommunikationsprotokolle [6]. Durch denEinzug von WiFi, Bluetooth und GSM ins Automobil mussendiese Protokolle bei der Sicherheitsbetrachtung mit einfließen.Bei WiFi sollte WPA2 als Verschlusselung eingesetztwerden [6]. Bei Bluetooth konnen durch unverschlusseltesPairing Angriffsflachen entstehen, daher sollte das Pairingverschlusselt werden [6]. Das Handynetz GSM gilt heutebereits als knackbar, allerdings mit hohem Aufwand.Dennoch ist es moglich einen Man-in-the-middle-Angriffauf die GSM-Verbindung zu starten und Daten mitzulesenoder sogar zu verandern. Somit kann Schadcode aufden Steuergeraten platziert und das Automobil damitubernommen werden [6]. Letztendlich kann die Sicherheit derKommunikationsprotokolle allerdings nicht die letzte Liniedes Schutzes sein, da die Automobilhersteller und -zuliefererauf die Protokollsicherheit keinen Einfluss haben [6].Abbildung 1 verdeutlicht die vorgestellte Risikoklassifizierung.Die Pfeile sollen den Kommunikationsfluss darstellen. DasGateway stellt die zentrale Schnittstelle dar, die uberKommunikationsprotokolle mit der Außenwelt kommuniziert.

Fig. 1. Klassifizierung sicherheitsrelevanter Komponenten im Automobil

B. Angriffe

Im Folgenden werden allgemeine Angriffe auf dasAutomobil aufgezeigt und abschließend noch Angriffe,welche sich speziell auf Opel OnStar und BMW ConnectedDrive beziehen, dargestellt.TMC (Traffic Message Channel) ist ein spezieller Radiokanalzur Verbreitung von Verkehrsmeldungen. Bei einer TMC-Injection simuliert der Angreifer einen Radiosender. Dereigene Radiosender des Angreifers versendet manipulierteNachrichten. Somit kann der Angreifer, einem Fahrer odersogar einer Gruppe von Fahrern falsche Verkehrsmeldungenzukommen lassen und dadurch die Fahrer auf eine gewisseArt navigieren [1].Einen so genannten Single-Point-of-Failure, besitzt daskey-less-entry-System. Als Single-Point-of-Failure wird eineSchwachstelle oder ein Ausfall einer Systemkomponente,die zu einer Kompromittierung des Gesamtsystems fuhrt,bezeichnet. Grundsatzlich gilt das System als sicher, beijedem Offnen und Schließen der Turen wird ein neuesSchlusselpaar ausgehandelt [1]. Das Problem besteht darin,dass die Hersteller einen Art Generalschlussel besitzen, mitdem die Hersteller jedes Auto offnen konnen. Bekommt einAngreifer diesen Generalschlussel, hat er Zugriff auf alleModelle des Herstellers, die dieses key-less-entry-Systembesitzen [1].Car2Car bzw. Car2X bieten Angreifern eine Plattform zurAusbreitung von Schadcode. Die Automobile kommunizierenmiteinander und stufen die Verbindung dazwischen alsvertrauenswurdig ein [1]. Diese Tatsache konnte sich einAngreifer zu Nutze machen und mithilfe der Car2Car- bzw.Car2X-Infrastruktur Schadcode verbreiten und somit eineMasse an moglichen Zielen angreifen. Ein Angreifer konntemit einem Man-in-the-middle-Angriff die Verbindung abhorenund gefalschte Pakete einschleusen [1].Im Folgenden werden nun ein Angriff auf eineMultimediakomponente und vier Angriffe aufSteuerungskomponenten aufgezeigt. Der Angriff auf dieMultimediakomponente ist recht trivial und durchbrichtim Grunde genommen auch keine Sicherheitsmechanismen[1]. Bei diesem Angriff werden manipulierte ID3-Tags, dienormalerweise zur Anzeige des Liedtitels und des Kunstlerseines Songs belegt sind, manipuliert. Ein Angreifer falschtdiese ID3-Tags dahingehend, dass er den Fahrer direkt mitpotentiellen Warnmeldungen des Motors anspricht. Es wirdeinfach eine gefalschte MP3-Datei auf einer CD mitgefuhrt[1]. Abbildung 2 verdeutlicht diesen Angriff. Der Fahrerkonnte durch diese ID3-Tags verwirrt werden und seinAuto sofort abstellen. Das Fahrzeug hat allerdings keinerleiSchaden genommen bzw. wurde keinerlei Schadcode in einSteuergerat oder eine Komponente geschleust [1].Die folgenden Angriffe beziehen sich auf den CAN-Bus unddie angeschlossenen Steuergerate. Es wird vorausgesetzt, dassder Angreifer bereits Zugang zu den Steuergeraten hat. Essind folgende Szenarien moglich: Das erste Szenario beziehtsich auf die Fenstersteuerung. Durch das Einschleusen einesSchadcodes auf das Fenstersteuergerat kann das Fensterunkontrolliert hoch- und runterfahren [1]. Beispielsweise kannein Angreifer einen Schadcode einschleusen, der das Fensterbei 200km/h offnet und es sich anschließend nicht mehrschließen lasst. Der Fahrer ware dadurch extrem abgelenktund wurde moglicherweise ein Unfall bauen [1].

79

Fig. 2. Angriff ID3-Tag [1]

Ein anderes Szenario ware, dass ein Angreifer die Alarmanlagemithilfe des Fenersteuerungs-Steuergerat lahm legen konnte[1]. Die Alarmanlage wird dadurch manipuliert, dass dasFenstersteuergerat auf dem CAN-Bus lauscht und wennein Paket mit der Meldung ”Alarm an” ankommt, sendetdas Fenstersteuergerat sofort ein gefalschtes Paket mit derMeldung ”Alarm aus” [1]. Ein weiteres Szenario ist dieManipulation des Airbag-Steuergerates. Da die Airbag-Komponente sehr teuer und eines der meist gestohlenenKomponenten im Automobil ist, konnen Angreifer bzw. Diebeden Diebstahl verschleiern, in dem sie die Funktionalitatdes Airbag-Steuergerates auf einem anderen Steuergeratsimulieren [1]. Dadurch bemerkt das Fahrzeug und der Fahrernicht, dass die Airbag-Komponente fehlt [1].

Im Juli 2015 hat Samy Kamkar einen Angriff demonstriert,der das Opel OnStar System komprommitiert. Um den Angriffzu verstehen, muss die Architektur und Funktionsweise kurzdargestellt werden. Das Opel OnStar System besitzt eineMobile App, die es ermoglicht, das Auto fernzusteuern. Dazuzahlen, das Offnen der Turen, das Betatigen der Hupe, dasAktivieren des Lichts, die Ortung des Fahrzeugs und dieAnzeige von Reifenluftdruck und Olrestlebensdauer [8]. DieApp auf einem Mobile Device kommuniziert uber einen Servermit der App [7]. Durch einen Man-in-the-middle-Angriffkann nun die Verbindung zwischen dem Mobile Device unddem Server komprommitiert werden [7]. Samy Kamkar hatdafur eigenes ein Gerat namens ”OwnStar” entwickelt [7].Mit diesem Gerat lasst sich die Verbindung in der Nahe einesOpel mit OnStar-System kapern und die oben genanntenFunktionen ausfuhren [7]. Dazu muss sich der Besitzer einesOpel OnStar System uber die App Zugang zu den Funktionenverschaffen. Das ”OwnStar”-Gerat fangt die Verbindung derApp ab und manipuliert die Datenpakete dahingehend, dassder Server die gefalschten Pakete fur korrekt halt [7]. DerAngreifer hat nun vollen Zugriff uber das Fahrzeug. LautSamy Kamkar liegt das Problem in der App auf dem MobileDevice und im Fahrzeug selbst. Durch diese Tatsache lasstsich diese Sicherheitslucke durch ein Update schließen [7].

Der Angriff auf das BMW Connected Drive System wurdeim Februar 2015 veroffentlicht. Das dazugehorige Steuergeratnamens Combox, welches zustandig fur Multimediafunktionenoder die Bluetooth-Koppelung von Mobile Devices mit demFahrzeug ist, wird seit 2010 verbaut [11]. Dieter Spaar hatdie Combox mithilfe von Reverse Engineering analysiertund einige Design-Fehler, die zu Sicherheitslucken fuhren,gefunden. Dieter Spaar listet sechs kritische Sicherheitsluckenauf [11]. In allen Comboxen wird derselbe symmetrische

Schlussel zur Datenverschlusselung genutzt. Außerdem ist derTransport der Daten, von der Combox zu den BMW BackendServern unverschlusselt. Die XML-Struktur lasst sich einfachmitlesen. Des Weiteren wurde die Integritat der Connected-Drive-Konfiguration nicht geschutzt. Antwortet die Comboxmit einer Fehlermeldung, wird die korrekte Fahrgestellnummermit dieser Fehlermeldung mitgeliefert, welche Ruckschlussefur weitere Angriffe bietet. Die versendeten SMS werden mitdem unsicheren DES-Verfahren verschlusselt und sind somitknackbar. Abschließend bietet die Combox keinen Schutzvor Replay-Angriffen [11]. Die genannten Sicherheitsmangelbieten einem Angreifer nun die Moglichkeit, das Fahrzeuguber die ”My BMW Remote”-App fernzusteuern [11].

Sicherheitsrisiken konnen nach ihrer raumlichen Anordnungklassifiziert werden. Die drei Klassifizierungen sind die Cloud,WiFi und Bluetooth, sowie OBD (On-Board-Diagnose) undUSB. Hat ein Angreifer Zugang zur Cloud, kann er sehr vielSchaden anrichten und viele Automobile fernsteuern. Diesenkann von einem entfernten Punkt aus geschehen. Dabei mussder Angreifer keinen physischen Zugriff auf das Automobilhaben. Bei der zweiten Klasse der raumlichen Anordnungmuss der Angreifer in Sichtweite zum Automobil stehen, umeinen Angriff durchfuhren zu konnen. Dies kann er durchFunktechnologien wie WiFi und Bluetooth ausuben. Bei derletzten Klasse muss ein Angreifer physischen Zugang zumSystem haben, um einen Angriff auf das Automobil ausfuhrenzu konnen. Beispiele hierfur sind die OBD-Schnittstelle,welche zur Diagnosezwecken genutzt wird, und ein moglicherUSB-Anschluss, der fur das Abspielen von Multimediadateiengenutzt werden konnte.

IV. SICHERHEITSANFORDERUNGEN

Der folgende Abschnitt soll einen Uberblick uberSicherheitsanforderungen im Automobil geben: WelcheAnforderungen mussen erfullt werden, damit aus denSicherheitsrisiken, die bereits in Kapitel III aufgezeigtwurden, keine Sicherheitslucken werden. Außerdem sollenspezielle Anforderungen an den CAN-Bus aufgezeigt werden.Abschließend wird kurz auf den ASIL (Automotive SafetyIntegrity Level) eingegangen. ASIL ist fest in ISO 26262verankert und bietet eine Moglichkeit, Komponenten nachmoglichen Risiken einzuordnen [15].

Die dargestellten Sicherheitsrisiken und Angriffe habenaufgezeigt, welche verschiedenen Moglichkeiten es gibt, umSchaden im Automobil anzurichten. Um potentielle Angriffezu vermeiden, muss bereits wahrend des System-Designsauf Sicherheitsanforderungen geachtet werden [6]. DieseSicherheitsanforderungen sind im Grunde genommen identischmit den Schutzzielen, die man von der IT-Sicherheit kennt.Die funf zentralen Sicherheitsaspekte sind Vertraulichkeit,Integritat, Verfugbarkeit, Authentizitat und Verbindlichkeit[1]. Diese funf Schutzziele sollen im Folgenden, in Bezugzum CAN-Bus des Automobil, erlautert werden und einemogliche Losung dargestellt werden.

Vertraulichkeit. Unter der Vertraulichkeit von Informationenwird verstanden, dass Drittpersonen keine unautorisiertenInformationen aus einem IT-System bekommen konnen[16]. Um diese Vertraulichkeit gegenuber Informationen

80

sicherzustellen, konnen beispielsweise einzelne Subjekte, diemit dem System auf irgendeine Art und Weise kommunizieren,durch Berechtigungen als vertraulich eingestuft werden. InBezug zum CAN-Bus muss sichergestellt werden, dass dieCAN-Pakete vertraulich sind. Die CAN-Pakete werden vonden Steuergeraten auf den CAN-Bus gesendet. Prinzipiellkann nun jedes Steuergerat, welches an diesen CAN-Bus angeschlossen ist, dieses Paket mitlesen [1]. Umsicherzustellen, dass diese CAN-Pakete vertraulich behandeltwerden, also nicht von anderen Steuergeraten gelesen werdenkonnen, konnen diese CAN-Pakete verschlusselt ubertragenwerden [1]. Das Steuergerat, welches den korrekten Schlussel,zum Entschlusseln beinhaltet, kann die Pakete entschlusseln.Somit kann sichergestellt werden, dass Steuergerate, die nichtals vertraulich eingestuft sind, diese CAN-Pakete mitlesenkonnen [1].

Integritat. Die Integritat von Informationen wird so definiert,dass Subjekte diese Informationen nicht im Geheimenmanipulieren und verandern konnen [16]. Um nun auf dasoben genannte Beispiel fur die CAN-Pakete einzugehenund deren Integritat sicherzustellen, konnen kryptografischeHash-Funktionen, Message Authentication Codes oder digitaleSignaturen eingesetzt werden [1].

Verfugbarkeit. Ein System gilt als verfugbar, wenn esin einem bestimmten Zeitrahmen Funktionen und Dienste zurVerfugung stellt [16]. Die Verfugbarkeit von IT-Systemenkann zum Beispiel durch DOS-Attacken vermindert werden[1]. Steuergerate im CAN-Bus konnen diesen durch dasstandige Senden von CAN-Paketen uberlasten und somit dieVerfugbarkeit beeintrachtigen [1]. Um dies zu verhindern,konnen kompromittierte Steuergerate vom CAN-Bus getrenntwerden [1].

Authentizitat. Die Authentizitat von Informationen oderSubjekten wird als die Echtheit oder Glaubwurdigkeitdieser Informationen oder Subjekte beschrieben [16]. DieseGlaubwurdigkeit muss durch eine eindeutige Eigenschaftnachweisbar sein [16]. Um die Authentizitat im CAN-Bussicherzustellen gibt es keine Maßnahmen [1]. CAN-Paketeenthalten keine Sender- oder Empfangeradresse, lediglich eineID um den Typ der Nachricht zu bestimmen [1]. Eine konkreteLosung fur dieses Problem kann im Grunde genommen nurdurch eine Weiterentwicklungen des CAN-Buses erfolgen [1].

Verbindlichkeit. Verbindlichkeit bedeutet, dass ein Subjektaus einer Menge von Aktionen, im Nachhinein eine Aktionausfuhren konnte und dies nicht abstreiten kann [16]. ImCAN-Bus ist die Verbindlichkeit, dass ein Steuergerattatsachlich eine gefalschte Nachricht versendet hat, nichtsicherzustellen [1].

Damit die vorgestellten Schutzziele eingehalten werdenkonnen, mussen die vorgestellten Losungsansatze eingehaltenwerden. Somit kann sichergestellt werden, dass moglicheSicherheitsrisiken nicht zu Sicherheitslucken werden.

Abschließend wird ASIL kurz vorgestellt, welcher imISO Standard 26262 enthalten ist. ASIL ist eine ISO Normzur funktionalen Sicherheit von Automobilen [12]. DieASIL-Norm beinhaltet unter anderem Verifikations- und

Validationsmechanismen und die klare Zuweisung vonVerantwortungen, wenn es um die Sicherheit bei verteiltenEntwicklerteams handelt [12]. ASIL gilt allerdings nur furPersonenkraftwagen bis maximal 3500 kg Gesamtgewicht.[12] Im Prinzip werden die Entwicklungsphasen in dreiUnterphasen aufgeteilt [13]. Diese Unterphasen sind diePlanung der Aktivitaten, die Durchfuhrung der geplantenAktivitaten und die Verifikation und Validitation derAktivitaten [13]. In einer Gefahrdungs- und Risikoanalysewerden so Sicherheitsziele definiert und eben durch dieAutomotive Safety Integrity Level kategorisiert [13]. DieLevel werden durch drei Parameter bestimmt und dadurchentsteht dann die Sicherheitseinstufung, wobei hier A dieniedrigste und D die hochste Stufe bezeichnet [14].

V. FUTURE WORK

Die vorherigen Abschnitte haben gezeigt, dass vieleGefahren den Menschen und die Technik bedrohen. Die An-greifer finden immer neue Wege die Sicherheitsmechanis-men der Hersteller zu umgehen. Dabei ist das Erweitern derSchnittstellen durch neue Technologien aus Sicht der Herstellerkontraproduktiv [1].Diese Risiken stehen fur den Endverbraucher nicht im Fokus.Die Vielfalt der Funktionen, die die moderne Technik liefert,ist verlockend. Volvo arbeitet daran, Automobile mittels derApple Watch zu entriegeln [5]. Ein Schlussel wird nicht mehrbenotigt, es reicht lediglich ein mit dem Fahrzeug assoziiertesGerat aus. Somit erreicht die Keyless Go-Funktionalitat eineneue Stufe. [5]Ein weiterer Schritt in Richtung Zukunft im Automobil hatGoogle Anfang 2014 bekannt gegeben. Die Mitglieder derOpen Automotive Alliance (OAA), bestehend aus Audi, GM,Google, Honda, Hyundai, Nvidia, sowie 40 weiteren Un-ternehmen, haben sich zum Ziel gesetzt, die Android-Plattformin die Automobil Welt zu bringen [5]. Diese Entwicklungkann zu einer hoheren Kompatibilitat mit mobilen Geraten unddem Automobil fuhren. Nutzer werden nicht mehr wissen aufwelchem Gerat sie momentan arbeiten.Fur mehr Sicherheit mussen die bekannten Sicherheitsan-forderungen angepasst und konsequent eingehalten werden.So durfen nicht nur die Schnittstellen nach außen abgesichertwerden, sondern die gesamte Kommunikation auch innerhalbdes Automobil muss mittels Verschlusselung und Prufungder Datenpakete auf Herkunft und Ziel sowie Manipulation,abgesichert werden. Dies ist vor allem fur die Manipulationinterner Baugruppen von hochster Relevanz. Fehler, die in derIT bereits seit Jahren bekannt sind, durfen im Automobil nichtneu aufleben [1]. Ein Beispiel hierfur ist der aufkommendeTrend, Informationen uber den Zustand des Fahrzeuges an dasInternet zu senden [5]. Bereits seit einiger Zeit ist bekannt, dassDatentrager nicht ohne weiteres an Computer angeschlossenwerden sollen, da diese oftmals den Computer schadigenkonnen. Der OBD-Stecker Vinli fuhrt das Prinzip des USBSticks in das Automobil [5]. Zukunftig konnen alle Automo-bile, die mit diesem Stick nachgerustet werden, miteinanderkommunizieren und dem Nutzer Informationen mittels Mobil-funknetz mitteilen [5]. Ein Nebeneffekt der Generierung vonInformationen ist der Nutzen fur Unternehmen. Beispielsweisekonnen Informationen zum Nutzungsverhalten des Fahrers beider Platzierung von Werbung helfen [5]. Anhand der GPS-Position und der Dauer des Aufenthaltes konnen Schlussfol-

81

gerungen auf viele Bereiche des Lebens getroffen werden.Solche Informationen in Zusammenspiel mit Informationenuber das Fahrzeug (Pedalstellung, Lenkeinschlag), konnenin Zukunft von Versicherungen herangezogen werden, umim Schadensfall eine fahrlassige Handlung festzustellen oderbereits vor einem Schaden die Betragssumme der Risikobere-itschaft des Fahrers anpassen [5].Vorhersagen zeigen, dass im Jahr 2020 bereits 250 Millionenvernetzte Fahrzeuge auf den Straßen sein konnen [5]. Zudiesem Zeitpunkt werden viele Unternehmen Einfluss aufdie Kommunikation der Fahrzeuge haben. Dies kann uns inZukunft in gewisse Schwierigkeiten bringen. Ein moglichesSzenario ist ein Botnetz aus Fahrzeugen [5]. Auswirkungeneines solchen Netzes sind unvorstellbar.Automobilhersteller, wie beispielsweise Tesla, beginnen bereitsmit IT-Sicherheitsunternehmen zusammen zu arbeiten, um dieSicherheit ihrer Systeme zu gewahrleisten. Viele Unternehmenwerden ohne konsequente Richtlinien durch regulierende In-stanzen wie Gesetzgeber keine Sicherheitsfunktionen imple-mentieren, da dieser Schritt mit Kosten verbunden ist [5].

VI. ERGEBNIS / SCHLUSSFOLGERUNG

Zusammenfassend lasst sich sagen, dass die Sicherheit imAutomobil eine immer großer werdende Rolle spielen wird.Durch den Einzug des Internets und die damit verbundeneAuflosung des ”geschlossenen Systems” Automobil mussenganz neue Sicherheitsbetrachtungen durchgefuhrt werden. Dieursprunglichen BUS-Systeme hatten zum Ziel, kostengunstigund zuverlassig zu sein. Heute hingegen sind diese Ziele ver-altet; es muss sich uber die Sicherheitsaspekte mehr Gedankengemacht werden. Deshalb ist es wichtig, Sicherheitsrisikenzu kennen um daraus Sicherheitsanforderungen erstellen zukonnen. Wichtig ist außerdem, dass man bereits wahrend desSystem-Design auf die Sicherheit achtet. Die ISO Norm 26262und die darin verankerten ASIL bieten eine gute Moglichkeit,um funktionale Sicherheit im Automobil umzusetzen.

REFERENCES

[1] Tobias Hoppe, Stefan Kiltz, and Jana Dittmann (2008): Security Threatsto Automotive CAN Networks – Practical Examples and Selected Short-Term Countermeasures

[2] H. E. Moßmer, M. Schedlbauer, W. A. Gunthner (2007): Neue Wege inder Automobillogistik. Springer Berlin Heidelberg

[3] Rohling, H. (2012): Car-to-car communications. in Signals, Systems, andElectronics (ISSSE), 2012 International Symposium on , vol., no., pp.1-5,3-5 Oct. 2012

[4] Werner Zimmermann, Ralf Schmidgall (2014): Bussysteme in derFahrzeugtechnik. Kommunikation zwischen Fahrzeugen. SpringerFachmedien Wiesbaden

[5] Richard Kirk, AlienVault (2015): Cars of the future: The Internet ofThings in the automotive industry.

[6] Becsi, T. and Aradi, S. and Gaspar, P. (2015): Security issues and vulnera-bilities in connected car systems. Models and Technologies for IntelligentTransportation Systems (MT-ITS), 2015 International Conference on.

[7] Samy Kamkar (2015): OwnStar - hacking cars with OnStar to locate,unlock and remote start vehicles, http://youtu.be/3olXUbS-prU

[8] Opel Group (2015): myOpel, https://play.google.com/store/apps/details?id=com.gme.opel.owner.android

[9] Opel Group (2015): http://www.opel.de/onstar/onstar.html[10] BMW (2015): http://www.bmw.de/de/topics/faszination-bmw/con-

necteddrive/ubersicht.html

[11] Dieter Spaar (2015): Auto, offne dich! - Sicherheitslucken bei BMWsConnectedDrive, c’t magazin, http://www.heise.de/ct/ausgabe/2015-5-Sicherheitsluecken-bei-BMWs-ConnectedDrive-2536384.html

[12] Jurgen Sauler und Stefan Kriso / Martina Hafner (2011):ISO 26262 - Die zukunftige Norm zur funktionalenSicherheit von Straßenfahrzeugen, Elektronik Praxis,http://www.elektronikpraxis.vogel.de/dossiers/iso26262/articles/242243/

[13] Jurgen Sauler und Stefan Kriso / Martina Hafner (2011):ISO 26262 - Die zukunftige Norm zur funktionalenSicherheit von Straßenfahrzeugen, Elektronik Praxis,http://www.elektronikpraxis.vogel.de/dossiers/iso26262/articles/242243/index2.html

[14] Jurgen Sauler und Stefan Kriso / Martina Hafner (2011): ISO26262 - Die zukunftige Norm zur funktionalen Sicherheit vonStraßenfahrzeugen - Methodik der ASIL-Einstufung, Elektronik Praxis,http://www.elektronikpraxis.vogel.de/dossiers/iso26262/articles/242243/index3.html

[15] Martin Hillenbrand (2012): Funktionale Sicherheit nach ISO 26262 inder Konzeptphase der Entwicklung von Elektrik/Elektronik Architekturenvon Fahrzeugen, Karlsruher Institut fur Technologie (KIT), KIT ScientificPublishing 2012

[16] Claudia Eckert (2012): IT-Sicherheit: Konzepte - Verfahren - Protokolle,7. uberarbeitete und erweiterte Auflage, Oldenbourg Verlag Munchen

82

Analyse und Optimierung der Privatsphare und desDatenschutzes bei Telematik-Systemen

Marc MerzingerHochschule FurtwangenMobile Systeme (MOS)

E-Mail: marc.merzinger@hs-furtwangen.de

Johann UlbrichHochschule FurtwangenMobile Systeme (MOS)

E-Mail: joahnn.ulbrich@hs-furtwangen.de

Zusammenfassung—In dieser Arbeit werdendie Telematik-Tarife von sieben verschiedenenVersicherungsanbietern analysiert und verglichen.Dabei liegt der Fokus auf der technischen Art derDatenerfassung, dem Datenschutz und dem Schutz derPrivatsphare der Versicherten. Die Tarife wurden anhandsechs Kriterien untersucht und gegenubergestellt. Anhandder Kriterien wurden die Tarife in privatsphare-freundlichbzw. -unfreundlich unterteilt. Zudem ist beschrieben,welche Ansatze hinter den Telematik-Tarifen stehen undwelcher Entwicklungstrend von Telematik-Tarifen und-Systemen zu erkennen ist. Auf Basis der Rechercheund der Analyse der Telematik-Tarife wurde eineinheitliches System fur ein Telematik-Modul entworfenund dessen Vor- und Nachteile beschrieben. Das Systemist auf die maximale Privatsphare des Versichertenund dessen Selbstbestimmung seiner Daten ausgelegt.Da Autohersteller in Deutschland ab 31. Marz 2018eCall-Systeme serienmaßig einbauen mussen, wurde furdieses System ein standardisiertes Telematik-Modul alsTeil des eCall-Systems angenommen.

I. EINLEITUNG

Durch die zunehmende Verbreitung von Kfz-Versicherungen in Deutschland, welche aufTelematik-Tarife setzen, und die steigende Anzahlverschiedener Losungen zur Erfassung desFahrverhaltens lassen eine Analyse der Systemehinsichtlich der Sicherung der Privatsphare desVersicherten sinnvoll und notig erscheinen. Viele derVersicherungsgesellschaften werben mit der Einhaltungdeutscher Datenschutzbestimmungen, jedoch ziehtdas Verwenden eines solchen Telematik-Tarifs und -Systems oft auch einen Verlust der Privatsphare mit sich.

Ziel dieser Arbeit ist es, dem Leser eine Ubersichtuber verschiedene Telematik-Tarife und -Systeme zugeben und diese anhand ihrer Vertraglichkeit mit derPrivatsphare zu untersuchen. Außerdem soll erarbeitet

werden, wie in zukunftigen Systemen die Privatsphareder Versicherten besser geschutzt werden kann. DieErgebnisse dieser Arbeit sind fur alle Personeninteressant, die sich mit Telematik-Systemen und derenBezug zur Sicherung der Privatsphare der Benutzerbeschaftigen.

Fur eine allgemeine Ubersicht werden verschiedeneTelematik-Tarife und -Systeme von großen undbekannten deutschen Versicherern herangezogenund analysiert. Fur die Analyse wurden Kriterienwie ”Umfang der erfassten Daten“, ”automatischeDatenweitergabe“ und ”Einbeziehung von Dienstleisternfur Datenauswertung“ berucksichtigt. Die benotigteHardware oder Software spielt eine untergeordneteRolle. Die Auswertung gibt Informationen daruber, wound weshalb die Privatsphare der Versicherten/Benutzereingeschrankt wird.

Diese Arbeit legt zudem den Fokus auf eine thematischeBeschreibung eines privatsphare-freundlichen Telematik-Systems. Auf Basis der Analyseergebnisse wird einSystem beschrieben, welches die privatsphare-kritischenElemente aus den zuvor analysierten Systemen nichtenthalt oder andere Losungsansatze zur Verbesserung derPrivatsphare bietet. Auf die technische Umsetzung einessolchen Systems wird hierbei nicht naher eingegangen.

II. VERWANDTE ARBEITEN

In dem Paper ”PriPAYD“ [1] beschreiben die Autorenein Telematik-System, das die Privatsphare durch lokaleDatenaggregation verbessert. Die Autoren diskutierenuber Punkte wie Kosten und die Sicherheit ihresentwickelten Systems. Das System besitzt Ahnlichkeitenmit dem in dieser Arbeit beschriebenen, jedoch benotigtes mehr Mitarbeit vom Versicherten.In einem anderen Paper ”Identifikation neuer Ansatze zur

83

individuellen Kfz-Tarifierung“ [2] werden Moglichkeitenzur Tarifdifferenzierung bei Kfz-Versicherungen durchdie Eigenschaften von Telematik-Systemen unterBerucksichtigung der Umsetzbarkeit, dem Nutzen unddem Datenschutz beschrieben.

III. EINFUHRUNG IN TELEMATIK-TARIFE

Unter Telematik-Tarifen versteht man Kfz-Versicherungstarife, bei welchen sich die Hohedes Versicherungsbeitrags nach dem Fahrstil desAutofahrers richtet. So soll langfristig die Fahrweise derKunden verbessert werden, da jeder Versicherte eineBewertung seines eigenen Fahrstils einsehen kann. Wervorausschauend und defensiv fahrt, soll Geld sparenkonnen. Die Bewertung des Fahrstils erfolgt dabei durchTelematik-Systeme im Auto. Diese erfassen mittelsSensoren die Fahrweise des Versicherten, auf dessenBasis ein Punkte-Wert (Score) ermittelt wird, welcherdas Fahrverhalten des Nutzers widerspiegelt.

Telematik-Tarife sind noch relativ neu in Deutschland.Als erster Versicherer erprobte die SparkassenDirektVersicherung 2014 die Anwendung vonTelematik-Diensten in Deutschland [3]. In einemTestlauf konnten Teilnehmer eine Telematik-Boxin ihrem Auto installieren und per Smartphoneihr Fahrverhalten uberwachen. Aufgezeichnet undzur Bewertung verwendet wurden dabei Daten wiedie aktuelle Position, Uhrzeit, Geschwindigkeit,Geschwindigkeitsubertretungen, Brems- undBeschleunigungsverhalten, zuruckgelegte Kilometerund auch die Fahrtrichtung. Die aufgezeichneten Datenwurden von der eingebauten Telematik-Box im 20-Sekundentakt an einen Dienstleister zur Auswertungubermittelt, um einen Score-Wert der Fahrweise zuermitteln [4]. Der Tarif wurde allerdings zum Jahresende2015 aus Kostengrunden nicht mehr angeboten.

Aktuell existieren viele verschiedene Systeme derunterschiedlichen Versicherer am Markt. So gibtes Telematik-Apps fur das eigene Smartphone undTelematik-Boxen mit eingebauten Sensoren, mit oderohne Zugriff auf den Board-Computer des Fahrzeugs.Des Weiteren gibt es auch Systeme, die fest imAuto verbaut werden, um das Fahrverhalten zuuberwachen und Telematik-Tarife nutzen zu konnen.Die große Anzahl unterschiedlicher Systeme machteinen Vergleich schwierig. So sind besonders detaillierteInformationen uber die aufgezeichneten Daten oftschwer zu finden. Auch Informationen daruber,

welche Daten an die Versicherungen bzw. beauftragteDienstleister, zur Auswertung weitergeleitet werden,und ob die Ubertragung auf sicherem Wege stattfindet,wird oft nicht genauer beschrieben. So konnen Kundenaktuell nur auf den Schutz der Daten durch dieVersicherungsunternehmen hoffen. Wer anschließendZugriff auf welche Daten bekommt und was außer derErmittlung des Versicherungsbeitrags, mit den Datengeschieht, erfahrt der Kunde meist nicht.

IV. ANALYSE AKTUELLER SYSTEME

Im Folgenden findet eine Analyse von Telematik-Tarifen folgender Anbieter statt: Allianz [5], HUK-COBURG [6], AXA [7], VHV Versicherungen [8],Sparkassen DirektVersicherung [9], Signal Iduna [10]und Generali [11]. Das Telematik-System von Generalikommt zusatzlich bei den Anbietern AachenMunchenerund CosmosDirekt zum Einsatz, weswegen es in derAuswertung nur einmal auftaucht.Die Analyse dieser Systeme basiert auf sechsKriterien: Technik zur Datenerfassung, ubermittelteDaten, erhaltene Daten (Versicherer), erhaltene Daten(Versicherter), automatisches Senden der Daten undob externe Datenverarbeitungdienstleister einbezogenwerden.Durch Recherche der Tarife hat sich herausgestellt,dass die am meisten verwendeten Techniken zurDatenerfassung eine Box im Auto oder eine App sind.Selten hingegen ist eine Kombination einer App undeines zusatzlichen Gerats im Auto, wie es die Allianzanbietet. Das zusatzliche Gerat dient zur Sicherstellung,dass der Versicherte in seinem Auto sitzt und nichtfalschlicherweise eine Fahrt als Beifahrer in einemanderen Auto aufgezeichnet wird. Andere Versichererverwenden andere Mechanismen, um dieses Problem zubeheben. Durch eine fest im Auto installierte Box wirddieses Problem zum Beispiel umgangen, da diese nichtwie ein Smartphone an der Person getragen wird.Bei installierten Boxen hat sich herausgestellt, dassdiese nicht nur Strom, sondern auch Fahrzeugdatenuber den OBD-2-Stecker beziehen konnen. Hier kannals Beispiel Signal Iduna genannt werden. Was jedochpositiv hervorzuheben ist, Signal Iduna zeichnet keinenStandort auf. Es werden nur Fahrzeugdaten und andereMesswerte zur Berechnung verwendet.Die aufgezeichneten Rohdaten ahneln sich bei fastallen Versicherungen. Zu den wichtigsten gehoren: Ort,Zeit, Geschwindigkeit, Beschleunigungsverhalten,Bremsverhalten, zuruckgelegte Kilometer,Kurvengeschwindigkeit und die Art der gefahrenen

84

Straße (bspw. Uberland). Bei vielen Tarifen hatsich herausgestellt, dass Scores unabhangig vonder verwendeten Aufzeichnungstechnik uberwiegendvon externen Dienstleistern der Versicherung berechnetwerden. Dafur werden alle Rohdaten an den Dienstleisterubermittelt. Dieser kann die Daten lediglich einerTelematik-ID zuordnen. Nur die Versicherung kennt dieZuordnung zwischen Versicherten und der Telematik-ID.Dieser Ansatz ist in Deutschland datenschutzkonform,da die Rohdaten keiner Person zugeordnet werdenkonnen. Jedoch konnte der Dienstleister schnell denWohnort oder den Arbeitsplatz und so eventuell auchden Namen des Versicherten herausfinden, da dieRohdaten komplette Bewegungsprofile enthalten. MitSicht auf die untersuchten Telematik-Tarife nutzenalle bis auf AXA einen externen Dienstleister zurAuswertung der Daten.Der Versicherer erhalt von seinem Dienstleister, oderwie bei AXA aus der Smartphone-App, die berechnetenScores. Diese drucken beispielsweise aus wie stark undwie oft Geschwindigkeitsuberschreitungen aufgetretensind oder wie intensiv der Benutzer beschleunigt odergebremst hat. Oft erhalten die Versicherungen aucheine Angabe uber die zuruckgelegten Kilometer. DerBenutzer hingegen erhalt bei den meisten Tarifen einekomplette Einsicht uber die gefahrene Strecke und eineUbersicht, wie gut oder schlecht er gefahren ist.Das letzte Kriterium ist, ob die aufgezeichneten Datenautomatisch gesendet werden. Bei einem Großteil derVersicherungen (Allianz, HUK-COBURG, SparkassenDirektVersicherung, Signal Iduna) ubermittelt dieBox/App die Daten automatisch. Dieses Vorgehen lasstdem Benutzer keine Moglichkeit, uber seine Datenselbst zu bestimmen. Andere Systeme wie sie z. B.von AXA oder Generali angeboten werden, senden dieDaten nicht automatisch, sondern uberlassen dies demBenutzer. Diese Moglichkeit ist besonders privatsphare-freundlich fur den Nutzer, allerdings sinkt damit auchdie Integritat der ubermittelten Daten, da die meistenNutzer wohl nur ihre besten Fahrergebnisse sendenwerden. Im Pressebereich von AXA findet man dazufolgende Aussage: ”Wir haben uns bewusst gegendie permanente Aufzeichnung von Daten entschieden.Die Erhebung der Daten uber das Smartphone raumtVersicherten die Moglichkeit ein, frei zu entscheiden,ob und wann sie Fahrdaten teilen“. Und ”Wir sinduberzeugt, dass junge Autofahrer ihren Fahrstil imLaufe einiger Wochen recht eindeutig zeigen“ [7].

Tabelle I zeigt eine Ubersicht der analysierten Tarife.

Tabelle IVERGLEICH DER PRIVATSPHAREFREUNDLICHKEIT

VERSCHIEDENER VERSICHERUNGSTARIFE

Versicherer/Tarif Bewertung Begrundung

Allianz

”BonusDrive“ - Daten werden automatisch anDienstleister ubertragen

HUK-Coburg

”Smart Driver“ - Daten werden automatisch anDienstleister ubertragen

AXA

”DriveCheck“ +Daten mussen vom Benutzergesendet werden, keinDienstleister

VHV

”TELEMATIK-GARANT“

-Verwendet einen Dienstleister,keine Angabe uber erhalteneDaten

Generali

”Mobility“ oDaten werden an Dienstleisterubertragen, jedoch nichtautomatisiert

Sparkassen Di-rektVersicherung

”S-Drive“- Daten werden automatisch an

Dienstleister ubertragen

Signal Iduna

”AppDrive R�“ oDaten werden automatisch anDienstleister ubertragen, jedochohne Standort

Der Schutz der Privatsphare wurde dabei wie folgtbewertet: + (positiv/freundlich), o (mittelmaßig),- (negativ/unfreundlich). Im Anhang dieser Arbeitbefindet sich Tabelle II, welche alle analysierten Tarifeinklusive deren genauen Eigenschaften enthalt.

Die Analyse der Tarife offenbart, dass zur Berechnungeines Scores viele Daten uber den Benutzer erfasst undauch versendet werden. Der Versicherte hat insgesamtsehr wenig Moglichkeiten uber seine Daten zu bestim-men, nachdem er eine solche Versicherung abgeschlos-sen und der Datenerfassung und Ubermittlung zuge-stimmt hat. Vereinzelt gehen Versicherungen wie z. B.AXA auf diese Probleme ein und kommen dem Benutzerdabei entgegen. Dies kann jedoch auch Nachteile haben,wie beispielsweise einen geringeren Preisnachlass.

V. DATENINTEGRITAT

Die verschiedenen Systeme lassen sich nicht nur aufBasis des Schutzes der Privatsphare des Versicherten,sondern auch auf die Aussagekraft der erfassten Datenmiteinander vergleichen. So liefern die eingesetzten Sys-teme auch Daten mit unterschiedlicher Qualitat an denVersicherer, wie folgender Abschnitt zeigt.

85

A. App-basierte SystemeBei Systemen, die ausschließlich das Smartphone zur

Erfassung der Daten nutzen, ist die Qualitat der Da-ten stark von den Sensoren im Smartphone abhangig.Aktuelle Gerate bieten zwar meist viele verschiedeneSensoren, jedoch verbauen die Hersteller Sensoren vonunterschiedlicher Qualitat.Auch lassen sich die Sensorwerte leicht verfalschen oderfehlinterpretieren. Zum Beispiel kann der Versichertedirekten Einfluss auf die Daten nehmen, indem er seinSmartphone vor rasanten Fahrten einfach ausschaltet, umnur die ausgeglichenen Fahrten in seinen Score einfließenzu lassen. Andersherum kann die App nicht selbststandigfeststellen, ob der Versicherte aktuell selbst fahrt oderzum Beispiel nur ein Beifahrer in einem Auto ist.Um zumindest das Beifahrerproblem in fremden Autoszu verhindern, bietet die Allianz-Versicherung zusatzlichzur Smartphone-App einen 12 V-Stecker mit Bluetooth-Verbindung an, mit welchem sich das Smartphone ver-binden muss, um die Fahrt aufzuzeichnen.Ein weiteres Beispiel betrifft die Sensoren selbst: StarkesAbbremsen, Beschleunigen oder auch Unfalle konnenzwar uber die Bewegungssensoren im Smartphone er-mittelt werden, fallt das Smartphone wahrend der Fahrtaber herunter, kann dies leicht als Unfall fehlinterpretiertwerden. Dies wurde den Score des Nutzers negativbeeinflussen, ohne dass gezwungenermaßen ein Fehlver-halten vorlag.Mit Smartphone-Apps lassen sich zwar kostengunstigDaten erzeugen, deren Aussagekraft sollte aber mit Vor-sicht betrachtet werden.

B. Telematik-Box mit eigenen SensorenAufgrund der schlechten Aussagekraft und einfachen

Manipulierbarkeit App-basierter Systeme setzen vieleVersicherungsunternehmen auch auf eigene Telematik-Boxen mit integrierten Sensoren. Diese liefern uberalle Kunden hinweg identisch-aussagekraftige Daten,wodurch sich diese besser in Relation zueinanderauswerten lassen.Die Aussagekraft dieser Daten ist aber auch stark vonden Algorithmen zur Auswertung abhangig. So kannein Telematik-System, welches nur Zugriff auf eigeneSensoren hat, nur schwer feststellen, wann ein Autoins Rutschen oder Schleudern gerat. Auch kann einsolches System schwer zwischen schlechtem Bremsenund sehr guter Reaktion zur Vermeidung eines Unfallsunterscheiden. Dies kann sich negativ auf den Score desKunden auswirken, auch wenn dieser durch seine guteFahrweise und Reaktion einen Unfall durch eine starke

Bremsung vermieden hat.

C. (Fest verbautes) System mit Zugriff auf Board-Computer

Die besten und aussagekraftigsten Daten konnen voneinem System mit Zugriff auf den Board-Computerdes Fahrzeugs erfasst werden. Denn im Vergleich zuexternen Sensoren kann ein System, welches Zugriffauf alle Sensorwerte des Autos hat, viel genauere Datenliefern. So kann mittels ABS- und ESP-Sensoren einRutschen oder Schleudern genau registriert werden.Auch Unfalle konnen besser durch Abstands- undAirbag-Sensoren registriert werden.

Die Wahl eines geeigneten Systems muss auf Seitedes Versicherers getroffen werden, wenn dieserKalkulationen auf Basis der erfassten Daten vornehmenmochte. Weitere Faktoren fur die Wahl eines geeignetenSystems sind aber auch die anfallenden Kosten und derAufwand zur Installation.

VI. PRIVATSPHARE UND DATENSCHUTZ

Je mehr Daten unterschiedlicher Sensoren denTelematik-Systemen zur Verfugung stehen, destobesser konnen diese zur aussagekraftigen Auswertungverwendet werden. Jedoch steigt mit der Menge dererfassten Daten und deren Informationsgehalt auch dieNotwendigkeit zum Schutz der Privatsphare.

Auch wenn die meisten Versicherungen die Verarbeitungder Daten auf zwei voneinander getrennte Datenkreiseaufteilen (Datenverarbeitungsunternehmen arbeitet mitpseudonymisierte Rohdaten, Versicherer arbeitet mit mitnutzerbasierten, aggregierten Daten), ergeben sich vieleDatenschutzbedenken.So kommunizieren die Versicherungsunternehmenzwar, dass die erfassten Daten pseudonymisiert (durchTelematik-ID) an ein Datenverarbeitungsunternehmenubertragen wird, welches keinen Zugriff auf Versi-cherungsdaten erhalt. Das Versicherungsunternehmenselbst erhalt laut Informationen nur aggregierteScore-Werte und kann diese mittels Telematik-ID einem Kundenkonto zuordnen. Zu Bedenkengibt es, dass eine Personenzuordnung fur dasDatenverarbeitungsunternehmen durch die Mengeder erfassten Daten wie GPS-Koordinaten oft moglichware. So ubermitteln viele Systeme GPS-Daten,aus welchen sich genaue Bewegungsprofile erstellenlassen. Aber auch ohne GPS-Daten kann bei langeren

86

Fahrten mittels Koppelortung festgestellt werden,wo sich der Fahrer befunden hat. Daruber konntenumfangreiche Bewegungsprofile mit Informationen uberWohnort, Arbeitsplatz, besuchte Personen, personlicheGewohnheiten etc. erstellt werden.

Ebenso muss festgestellt werden konnen, auf welcheSensoren ein Telematik-System Zugriff hat. Soware denkbar, dass ein Mudigkeitssensor oder dieSprachsteuerung des Entertainment-Systems zurUberwachung des Nutzers verwendet wird.

Auch das Recht auf informationelle Selbstbestimmunglasst sich nur schwer mit Telematik-Tarifen verbinden.Durch automatisches Senden der Daten kann derNutzer nicht sicherstellen, dass keine fur ihn sensiblenDaten ubertragen werden. Wurde man dem Nutzerallerdings das Recht einraumen selbst zu entscheiden,welche Daten er weitergeben mochte, ware damitdie Datenintegritat gefahrdet. Auch das Recht aufinformationelle Selbstbestimmung eines dritten Fahrersist gefahrdet, wenn ein Telematik-System im Autoinstalliert, die Datenerhebung aber nicht offensichtlichist.

Weiterhin ist auch die Speicherung der Daten ineiner Telematik-Box bedenklich. So muss in jedem Fallsichergestellt werden, dass die Daten nicht von Dritten,wie Kfz-Werkstatten ohne die Einwilligung des Nutzersausgelesen werden konnen. Das Gleiche gilt auch furdie Daten, welche in einer Smartphone-App gespeichertwerden.

Auch die weitere Verwendung der Daten kann nichtimmer unterbunden werden, wurden die Daten einmalerhoben, kann dies leicht die Begehrlichkeiten andererwecken. So konnte zum Beispiel die Polizei ein großesInteresse an diesen Daten haben, um im Fall einesUnfalls alle Anwesenden zu ermitteln.Aber auch Richter konnten die Herausgabe der Daten imFalle eines Unfalls einfordern. So konnte das bisherigeRecht zu schweigen, um sich nicht selbst zu belasten,in einigen Fallen durch Telematik-Daten seine Wirkungverlieren.Durch diese Entwicklungen kamen Telematik-Tarifeschnell einer ”freiwilligen Vorratsdatenspeicherung“gleich.

Sobald personliche Daten uber den Benutzer erfasstwerden oder sich Bewegungsprofile erstellen lassen, ist

es unverzichtbar, den Schutz der Daten sehr ernst zunehmen. So lassen sich die Daten leicht missbrauchen,um den Versicherten zu uberwachen. Schnell lassensich Wohnort, Arbeitsstelle, Einkaufsmarkte undGewohnheiten bestimmen und so auch gegen denNutzer verwenden. In jedem Fall sollte der Nutzereindeutig nachvollziehen konnen, welche Informationenuber ihn erfasst, gespeichert und ubertragen wurden.

Um den Datenschutz bei Telematik-Tarifen sicher-zustellen, hat der Landesbeauftragte fur Datenschutzund Informationsfreiheit Nordrhein-Westfalen alserste deutsche Datenschutzaufsichtsbehorde einenPay-As-You-Drive-Tarif bewertet und Anforderungenan Datenschutz und Datensicherheit formuliert (22.Tatigkeitsbericht (2015) fur 2013/14, Ziff. 5.1) [12].Aber auch diese raumen nicht alle Bedenken aus, daaktuelle Tarife diese berucksichtigen und einhalten,viele der oben genannten Punkte aber nicht gelostwerden.

VII. ENTWICKLUNGSTREND

Es ist davon auszugehen, dass die Entwicklungaufgrund mehrerer genannter Faktoren in RichtungTelematik-Systeme mit Zugriff auf den Board-Computergeht.Zum einen sind solche Telematik-Boxen in Landernwie den USA, Großbritannien und Italien schon langerverbreitet, zum anderen setzen mittlerweile auch einigedeutsche Versicherungsunternehmen auf diese Systeme.Ein prominentes Beispiel ist das Opel OnStar-System.Zusammen mit der Allianz-Versicherung bietet Opel einTelematik-System an, welches durch die Buchung einesTelematik-Tarifs bei der Allianz genutzt werden kann.Die Versicherung kann ohne aufwendiges Nachrustenvon allen Opel-Fahrern, deren Fahrzeug mit demTelematik-Dienst ”Opel OnStar“ ausgestattet ist, inAnspruch genommen werden. Aber auch Systemeanderer Hersteller, wie zum Beispiel Signal Iduna,fordern bereits Zugriff auf den Board-Computer uberden OBD-2-Port des Fahrzeugs, um Daten zu erfassen.

Auch wird die Einfuhrung des gesetzlich verpflichtendeneCall-Systems fur Neuwagen ab 31. Marz 2018 dieSituation grundlegend andern. Mit dem Einbau derhierfur erforderlichen Technik ist kunftig jedes Autotelematikfahig. So drangen viele Versicherungen aufeine Offnung des Systems fur ihre Tarife. Durch dieVerwendung des eCall-Systems fur Telematik-Tarifewurde auch die Hurde des Einbaus eines zusatzlichen

87

Telematik-Systems wegfallen. Fur den Versichererwurde dies eine große Kostenersparnis bedeuten undeventuell auch fur den Kunden die Hemmschwelle furdie Nutzung senken.

Auch ist abzusehen, dass nach einer entsprechendenVerbreitung von Telematik-Tarifen in DeutschlandVersicherte ohne Telematik-Tarife mehr fur ihreVersicherung zahlen mussen. Auch wenn aktuell Kundenhauptsachlich durch Einsparungen und Vergutungenzu Telematik-Tarifen gelockt werden, gibt es bereitsVersicherungen, bei denen schlechte Fahrer bestraftwerden, indem sie mehr zahlen mussen [13].

Ein großer Nachteil dieser Entwicklung ist derDatenschutz. Um sicherzustellen, dass diesereingehalten wird, wird im folgenden Kapitel einmogliches, privatsphare-freundliches Telematik-Systembeschrieben.

VIII. VERBESSERUNG DER PRIVATSPHARE BEI FESTVERBAUTEN TELEMATIK-SYSTEMEN

Fur das in diesem Kapitel beschriebene Telematik-System wird davon ausgegangen, dass es einstandardisiertes Modul in einem eCall-Systemgibt, das explizit fur die Telematik-Funktionalitatzustandig ist. Das Modul sollte fest im Auto verbautund gegen Eingriffe von außen geschutzt sein, umManipulationen oder das Abgreifen der Daten zuverhindern. Um moglichst prazise Berechnungen derScores zu gewahrleisten, darf das Modul wahrend derFahrt alle relevanten Rohdaten aufzeichnen (Ort, Zeit,Geschwindigkeit etc.). Sobald das Auto abgestellt ist,startet das Modul die Berechnung der Scores. Ist dieBerechnung abgeschlossen, verwirft das Modul alleaufgezeichneten Rohdaten und speichert lediglich dieberechneten Scores.Des weiteren bietet das Modul eine Schnittstelle zurKommunikation mit dem Benutzer oder mit demAutoradio. Uber diese Schnittstelle lasst sich das Modulkonfigurieren. Jegliche Kommunikation mit dem oderausgehend vom Modul muss gesichert sein.

Fur Fahrer, die selbst ihre Fahrweise kontrollierenwollen, bietet das Modul eine zusatzliche und optionaleFunktion. Diese erlaubt es, dass die Rohdaten nichtsofort, sondern erst nach Abruf der Daten vom Nutzergeloscht werden. Damit diese Daten nur fur denrichtigen Benutzer zuganglich sind, konnen diese nur

uber die Eingabe eines Passworts vom Modul abgerufenwerden. Das Hinterlegen des Passworts wird im Laufedieses Kapitels beschrieben. Zum Schutz des Benutzerssollte diese Funktion per Standard deaktiviert sein. Sowird verhindert, dass ohne Wissen des Benutzers Datengesammelt werden.

Abbildung 1 zeigt das gesamte System mit allenTeilnehmern. Es funktioniert nach folgendem Ablauf:Der Benutzer schließt einen Telematik-Tarif ab underhalt von der Versicherung eine Konfiguration fur seinAuto. Diese Konfiguration kann der Benutzer entwederuber sein Smartphone oder uber das Autoradio an dasTelematik-Modul ubergeben.Die Konfiguration, die der Benutzer von derVersicherung erhalt, besitzt im initialen Zustandlediglich Informationen uber die Schnittstellen derVersicherung, an welche das System die Daten schickensoll, und einen Token, welches den Versichertenidentifiziert. Damit der Benutzer die optionale Funktionzur Einsicht der eigenen Daten aktivieren kann, mussdieser in der Konfiguration zusatzlich ein Passworthinterlegen. Hier kann er zusatzlich konfigurieren, wielange das Modul die Rohdaten speichert, bis diese auchohne Abruf vom Benutzer geloscht werden. Eine solcheZeitschranke verhindert große Datenmengen und eineRuckverfolgung der Standorte des Benutzers vor dieserZeitschranke.

Sobald die Konfiguration im Modul hinterlegtwurde, werden die Aufzeichnung der Fahrten unddie Berechnung der Scores moglich. Damit das Systemmaximal privatsphare-schonend ausgelegt ist, wird demBenutzer das Ubermitteln der Scores selbst uberlassen.Der Benutzer hat die volle Kontrolle daruber, wann undwelche Scores gesendet werden sollen.

Die Auslegung des Systems auf maximalen Schutzder Privatsphare bringt einige Vor- und Nachteile mitsich. Der Versicherte hat die volle Kontrolle uber seineDaten. Durch die Berechnung der Scores, welche schonlokal im Modul stattfindet, muss der Benutzer sich keineSorgen mehr daruber machen, dass weitere personlicheDaten an externe Dienstleister weitergegeben werden.Außerdem kann er, um seinen Fahrstil zu verbessern,die aufgezeichneten Daten mittels Passwort abrufen undeinsehen. Um zu verhindern, dass die Daten des Modulsbeispielsweise an ein Gericht herausgegeben werdenmussen, werden Rohdaten, wenn uberhaupt, nur eineselbst festgelegte Zeitdauer gespeichert. Ein Nachteil

88

Abbildung 1. Gesamtubersicht des Systems

ergibt sich jedoch fur den Benutzer, dieser muss stetsselbst daran denken, die Scores an den Versichererzu senden. Im Falle einer Nicht-Ubertragung konnteder Versicherte auf einen regularen Versicherungstarifzuruckfallen.

Auch fur den Versicherer ergeben sich Vorteile durchein einheitliches System. Durch dieses System mussendie Versicherer keine Dienstleister mehr einbeziehen,da alle Scores lokal im Fahrzeug berechnet werden. Furdie Versicherer entstehen aber auch Nachteile durch eineinheitliches System. Alle Versicherungsunternehmenmussen sich auf einen standardisierten Algorithmuseinigen, welcher fest im Modul hinterlegt ist. Außerdemwerden weitere tarifunabhangige Big-Data-Analysenerschwert, da nur noch Scores ubermittelt werden.

IX. FAZIT UND AUSBLICK

Wie sich gezeigt hat, gibt es aktuell eine Vielzahlunterschiedlicher Systeme zur Analyse des Fahrverhal-tens. Der langfristige Trend geht zu fest verbauten Sys-temen mit Zugriff auf den Board-Computer des Fahr-zeugs. Spatestens die Offnung des verpflichtenden eCall-Systems fur Telematik-Tarife wird diesen Tarifen inDeutschland zum Durchbruch verhelfen.Aufgrund dieser Entwicklungen ist eine ausfuhrlicheAuseinandersetzung mit dem Thema Privatsphare undDatenschutz wichtig, damit auch in Zukunft jeder Nutzerdie Moglichkeit auf die Selbstbestimmung seiner Datenhat und behalt.Das von uns entworfene System bietet starke Vorteilefur den Benutzer, jedoch auch einige Nachteile furVersicherungen. Fur einen breiten Einsatz dieses Systemsmussen auf Seiten der Versicherer einige Kompromissezum Schutz der Privatsphare des Nutzers eingegangenwerden. Hierzu bietet das System mehrere Punkte, andenen es Anpassungsmoglichkeiten fur Versicherungen

bietet. Beispielsweise kann das Senden der Scores an dieVersicherung automatisch einmal im Monat passieren.Das ergibt kleine Einschnitte fur den Benutzer, da diesernicht mehr selbst entscheiden kann, wann Daten gesendetwerden, dafur erhalt der Versicherer monatlich aktuelleDaten.Insgesamt bietet das System eine hohe Sicherheit undgleiche Bedingungen fur alle Benutzer und Versicherun-gen. Es stellt sicher, dass die Privatsphare bestmoglichbei der Verwendung eines Telematik-Tarifs geschutzt ist.

89

X. ANHANG

Tabelle IIVERGLEICH DER PRIVATSPHAREFREUNDLICHKEIT VERSCHIEDENER VERSICHERUNGSTARIFE

Versicherer/Tarif System Ubermittelte DatenErhalteneDaten(Versicherer)

AutomatischeUbertragung

der Daten

Einbezugeines

externenDienstleisters

Allianz ”BonusDrive“App +Bluetooth-Device

Bremsverhalten, Beschleunigung,Kurvengeschwindigkeit,Geschwindigkeit, Zeit, Straßentyp, Ort

AggregierteDaten Ja Ja

HUK-Coburg ”SmartDriver“ Box

Bremsverhalten, Beschleunigung,Geschwindigkeit, Zeit, Ort,Lenkverhalten

AggregierteDaten Ja Ja

AXA ”DriveCheck“ AppBremsverhalten, Beschleunigung,Kurvengeschwindigkeit,Geschwindigkeit, Ort

Score Nein Nein

VHV

”TELEMATIK-GARANT“ BoxBremsverhalten, Beschleunigung,Geschwindigkeit, Zeit, Straßentyp,Ort, zuruckgelegte Strecke

k. A. k. A. Ja

Generali ”Mobility“ App

Bremsverhalten, Beschleunigung,Kurvengeschwindigkeit,Geschwindigkeit, Zeit, Ort,zuruckgelegte Strecke

Score, Anzahlder Fahrten,zuruckgelegteStrecke

Nein Ja

SparkassenDirektVersicherung

”S-Drive“Box

Bremsverhalten, Beschleunigung,Geschwindigkeit, Zeit, Ort,zuruckgelegte Strecke

Score,zuruckgelegteStrecke

Ja Ja

Signal Iduna ”AppDrive R�“ Box Kein Ort, ansonsten unbekannt k. A. Ja Ja

90

LITERATUR

[1] C. Troncoso, G. Danezis, E. Kosta, J. Balasch, and B. Preneel,“Pripayd: Privacy-friendly pay-as-you-drive insurance,” IEEETransactions on Dependable and Secure Computing, vol. 8,no. 5, pp. 742–755, 2011.

[2] W. Weidner and R. Weidner, “Identifikation neuer ansatze zurindividuellen kfz-tarifierung,” Zeitschrift fur die gesamteVersicherungswissenschaft, vol. 103, no. 2, pp. 167–193. [Online]. Available: http://link.springer.com/content/pdf/10.1007%2Fs12297-014-0268-4.pdf

[3] Sparkassen DirektVersicherung, “Sparkassen direktversiche-rung startet mit telematik-sicherheits-service,” 11.11.2013.[Online]. Available: https://www.sparkassen-direkt.de/presse/telematik-sicherheits-service-startet/

[4] Sparkassen DirektVersicherung, “Vereinbarung zum telematik-sicherheits-service (s-drive-service).” [Online]. Availa-ble: https://www.sparkassen-direkt.de/fileadmin/pdf/telematik/Endkundenvertrag.A2.2.pdf

[5] Allianz, “Telematik-versicherung: Besonders junge fahrerprofitieren: Ausgezeichnet: Allianz bonusdrive.” [Onli-ne]. Available: https://www.allianz.de/auto/kfz-versicherung/telematik-versicherung/

[6] Coburg, “Telematik: Mit dem ”Smart Driver Programm“belohnt die huk-coburg sicheres autofahren.” [Onli-ne]. Available: https://www.huk.de/presse/pressemitteilungen/presseinfos-2016/smart driver.jsp

[7] AXA, “Axa mit telematik-app: Sicherer fahren, wenigerzahlen.” [Online]. Available: https://www.axa.de/presse/axa-mit-telematik-app

[8] VHV Versicherungen, “Telematik.” [Online]. Available: https://www.vhv.de/kundenservice/rund-ums-fahrzeug/pkw-telematik

[9] Sparkassen DirektVersicherung, “S-drive - der erste telematik-sicherheits-service in deutschland.” [Online]. Available: https://www.sparkassen-direkt.de/telematik/s-drive/

[10] Signal Iduna, “App drive.” [Online]. Available: https://www.app-drive.de/

[11] Generali, “Telematik.” [Online]. Available: https://www.generali.de/mobility

[12] Ulrich Lepper, “Datenschutz und informationsfreiheit,” 2015.[Online]. Available: https://www.ldi.nrw.de/mainmenu Service/submenu Berichte/Inhalt/22 DIB/DIB 22.pdf

[13] Eric Brandmayer, “Guter fahrstil soll geld sparen,” 2016.[Online]. Available: http://www.finanztip.de/kfz-versicherung/telematik-tarif/

91

Analyse aktueller Sicherheitskonzepte imSmart-Home-Bereich

Katharina Mollus, Christian HauslerHochschule FurtwangenFurtwangen, Germany

{katharina.mollus, christian.haeusler}@hs-furtwangen.de

Zusammenfassung—Das immer mehr an Bedeutung gewin-nende Konzept Smart-Home begunstigt es, dass vernetzte Sen-soren und Aktoren zur intelligenten Haussteuerung vermehrtEinzug in private Haushalte nehmen. Begunstigt wird diesnoch weiter durch die Verfugbarkeit erschwinglicher modularerSysteme mit vielfaltigen Einzelkomponenten wie beispielsweisevernetzte Thermostate, Steckdosen und Brandmelder, welchedurch Laien einfacher installiert und eingerichtet werden konnen.Die Omniprasenz dieser Gerate, welche nicht nur Daten auf-zeichnen, sondern auch ihre Umwelt beeinflussen konnen, fuhrtdabei jedoch auch zu neuen Sicherheitsproblemen sowohl imBereich des Datenschutzes als auch der Betriebssicherheit. Indieser Arbeit mochten wir aktuelle Sicherheitskonzepte anhandzwei reprasentativer Fallbeispiele analysieren und gegebenenfallsvorhandene Sicherheitsprobleme aufzeigen.

I. EINLEITUNG

Intelligente und teilautomatisierte Haussteuerung durch so-genannte Smart-Home-Systeme gewinnt immer an Bedeutung.Smart-Home beschreibt die Vernetzung vielfaltiger Sensorenund Aktoren, um diese dann zentral uberwachen und fernsteu-ern zu konnen. Ein Beispiel fur ein solches System ist in Ab-bildung 1 dargestellt. Es zeigt die vielfaltigen Moglichkeiten,die sich einem Nutzer bieten. Komponenten wie beispiels-weise Thermostate, Steckdosen, Brandmelder, Alarmanlagenoder Lichtschalter kommunizieren im Allgemeinen uber Funk-protokolle mit einer zentralen Basisstation, auch Gatewaygenannt. Diese ist dabei meist uber das Internet mit einemPortal des Anbieters verbunden. Die Komponenten konnendann uber das entsprechende Webportal oder beispielsweiseeine Smartphone-Anwendung konfiguriert und gesteuert wer-den. Die Installation des Systems kann je nach Modul invielen Fallen auch von Laien durchgefuhrt werden. Soge-nannte Starter-Kits, welche zumeist eine Basisstation sowiebeispielsweise ein Heizkorperthermostat und einen Zwischen-stecker zur Steckdosensteuerung enthalten, sind oft gunstigerhaltlich. Damit die Erweiterung der heimischen Vernetzungnicht zum Einfallstor fur Angreifer wird, mussen Anbieterein durchdachtes Sicherheitskonzept fur Daten- und Betriebs-sicherheit aufstellen. So mussen sowohl die Verbindungender einzelnen Module zur Basisstation, die Verbindung derBasisstation zum Anbieter als auch die Zugriffe beispiels-weise uber Smartphone-Apps ausreichend abgesichert werden.Angriffsszenarien fur ungenugend gesicherte Haussteuerungensind vielfaltig vorhanden. So konnte ein Angreifer durch dieBeobachtung der Abschaltzeitpunkte von Licht und Strom undHeizung feststellen, wann sich niemand mehr im Haus aufhalt.Sollte die Alarmanlage ebenso in das Smart-Home-Systemintegriert sein, kann diese dann einfach abgeschaltet wer-

IEEE Communications Magazine • June 2010 93

The main characteristics and requirementsfor WHANs are as follows:• The node density is potentially high, and

the number of nodes may be on the orderof hundreds.

• The home is typically a multipath environ-ment due to the presence of reflective sur-faces (e.g., walls, floors, and tables).

• Residential scenarios are subject to interfer-ence. Industrial, scientific, and medical(ISM) bands are particularly crowded withthe presence of WiFi, Bluetooth, cordlessphones, and even microwave ovens.

• To facilitate end-to-end connectivity, multi-hop communications are required, so thatintermediate nodes can retransmit data fornodes that are not within the sender’s trans-mission range.

• Although most devices are static, the mobil-ity of some of them and the dynamics ofRF signal propagation require the networkto be self-healing. The duration of connec-tivity gaps due to network topology changesshould be low.

• The applications require WHANs to sup-port various traffic patterns, such as point-

Figure 1. An example of a WHAN-enabled home.

Undergroundhumiditysensor

Legend

Light switchLight

Other devices

Porch

Remotecontrol Occupancy

sensor

Dining room

Smokedetector

Garden

Kitchen

Undergroundhumiditysensor

Irrigationcontroller

HVACcontroller

Presencesensor

Presencesensor

UtilitymetersAlarm

Garage dooropener

Garage dooropener

Garage doorremote control

Temperaturesensor

CO2 detector

CO2 detector

Luminancesensor

Living room

Hall

Windowshade

Gateway

Light sensor

Bedroom 1

Bathroom

Bedroom 2

Garage

On-body medicalsensor

Glass breaksensor

TV, HiFi, DVD

Office PCWindow shades,HVAC, central

heating, etc. may becontrolled dependingon the informationcollected by several

types of sensors thatmonitor parameterssuch as temperature,

humidity, light, and presence.

Unnecessary wasteof energy can thus

be avoided.

GOMEZ MONTENEGRO LAYOUT 5/18/10 11:46 AM Page 93

Abbildung 1. Beispielszenario fur ein Smart-Home-System nach [1].

den. Vielfaltige auf dem Markt erhaltliche Komplettsystemeermoglichen fur Laien zwar eine Umwandlung einer Wohnungoder eines Hauses in ein smartes Zuhause, befahigen diesejedoch nicht, diese Systeme auch entsprechend gegen Miss-brauch und Angriffe zu schutzen. Endanwender mussen daherdem meist intransparenten Sicherheitskonzept der Herstellervertrauen. Kurzlich durchgefuhrte Untersuchungen bezuglichder Sicherheitsmaßnahmen ([2],[3],[4]) zeigten gerade auch inSystemen namhafter Hersteller zum Teil gravierende Mangelauf. Ziel dieser Arbeit ist daher zunachst eine Festlegungund Abgrenzung verschiedener Ebenen in einem Smart-Home-System, fur die Sicherheitsmaßnahmen notig sind. Anschlie-ßend werden anhand dieser Ebenen und Komponenten zweiBeispielsysteme auf ihr Sicherheitskonzept hin untersucht.

93

An dieser Stelle werden die eingesetzten Verfahren, sofernmoglich, mit den Empfehlungen beziehungsweise der State-of-the-Art fur Sicherheitslosungen in den entsprechenden Be-reichen verglichen. Im Allgemeinen kann man zwischen zweigrundlegenden Kommunikationsarten von Sensoren und Ak-toren mit den jeweiligen Basisstationen, auch Gateway oderControl Host genannt, unterscheiden [5]. Zum einen werdensogenannte Powerline Communication (PLC) Losungen, wiebeispielsweise Homeplug oder X10, bei denen die Ubertragungvon Daten uber das Stromnetz erfolgt und Funksysteme wieKNX, HomeMatic, ZigBee oder Z-Wave zur Ansteuerung derKomponenten verwendet. Eine Sonderstellung nimmt hier derKNX-Standard ein, da dieser als erster weltoffener Standardfur Haus- und Gebaudeautomation als EN50090 beziehungs-weise ISO/IEC 14543-3 offiziell standardisiert wurde [6]. Ab-bildung 1 zeigt ein Beispiel fur den Umfang und die Komple-xitat eines Smart-Home-Szenarios. Grundsatzlich konnen dieeinzelnen Komponenten in die Kategorien Sensoren, Aktoren,Basis, Backend und Frontend eingeteilt werden. Teilweise sindjedoch auch Kombinationen wie beispielsweise von Sensorenund Aktoren moglich.

• Sensor: Erfassung von Daten

• Aktor: Ausfuhren einer Aktion (z.B. Start/Stopp Mo-tor)

• Basis: zentrale Kontrollstelle im Haushalt

• Backend: zentrale Kontrollstelle beim Anbieter

• Frontend: Endgerat fur den Zugriff auf Basis oderBackend

Erganzend sei zu sagen, dass nicht jeder Hersteller auchein Backend anbietet beziehungsweise sind diese auch zumTeil in die Basis integriert. Diese einzelnen Komponentensind insbesondere bezuglich ihrer Betriebssicherheit einzelnzu betrachten, was jedoch den Rahmen dieser Arbeit sprengenwurde. Im Folgenden gehen wir daher grundsatzlich von einersicheren Konstruktion der Komponenten aus, betrachten jedochallgemein ihre Manipulationsanfalligkeit. Hierzu zahlt auch derZugriffsschutz in Form von Authentifizierungsverfahren (Log-In). Die physische Manipulation einzelner Komponenten istdabei schwierig zu verhindern, darf jedoch gleichzeitig nichteine Korrumpierung des Gesamtsystems zur Folge haben. InBezug auf Manipulation sind auch sichere Aktualisierungs-verfahren der eingesetzten Firmware wichtig. Auf Grundlageder Einteilung in die einzelnen Kategorien, ergeben sich diefolgenden zu sichernden Ubertragungswege:

• Sensor ! Aktor: SA

• Sensor ! Basis: SB

• Aktor ! Basis: AB

• Basis ! Backend: BB

• Frontend ! Basis: FBas

• Frontend ! Backend: FBack

Die Verbindung FBack sowie BB erfolgt im Allgemeinenuber das Internet (Heimanschluss bzw. mobiles Internet). Wenndie Basis eine direkte Verbindung des Frontends zulasst,

wird hierfur meist das Heimnetz (kabelgebunden oder draht-los) verwendet. Die Sicherheit des WLAN-Zugangspunktesist besonders wichtig. Sollte also uber dieses auch aufdie Basis zugegriffen werden, mussen hierfur die empfoh-lenen Sicherheitsmaßnahmen[7] wie WPA2 Verschlusselung,Anderung der Default SSID und Abschalten von WPS umge-setzt werden. Da dies jedoch nicht vom Hersteller der Hausau-tomatisierungslosung beeinflusst werden kann, mussen dessenSicherheitskonzepte auch den Fall eines Angreifers innerhalbdes Heimnetzwerks abdecken. SA, SB und AB Schnittstellensind je nach Hersteller die schon zuvor genannten PLC- oderFunkverbindungen. Im Folgenden werden wir die Sicherheits-konzepte der Systeme RWE SmartHome (RWE) und Quivicon(Telekom) beispielhaft anhand der genannten Komponentenund Ubertragungsschnittstellen analysieren.

A. Sicherheitskonzept

Ein Sicherheitskonzept beschreibt die getroffenen oderzu treffenden Maßnahmen eines Systems und damit auchdessen Sicherheitsniveau. Im Allgemeinen wird das Sicher-heitskonzept bei der Planung eines Systems nach erfolgterRisikobewertung erstellt1. Jedoch konnen auch, wie in dieserArbeit beschrieben, bei einer externen Analyse die gleichenVerfahren eingesetzt werden. So sind zunachst die Schutzzieleund Gefahren fur diese zu nennen und anschließend diegetroffenen Maßnahmen fur alle Teilkomponenten (u.a. auchdie Verbindung zwischen Komponenten) zu untersuchen.

B. Schutzziele

Die Schutzziele im Smart-Home-Bereich entsprechen dender Informationssicherheit: Vertraulichkeit (Confidentiality),Integritat (Integrity), Verfugbarkeit (Availability), Authentizitat(Authenticity). Ebenso spielt auch hier der Datenschutz einewichtige Rolle, man konnte diesen jedoch zum Schutzziel derVertraulichkeit hinzurechnen. Datenschutz bezieht sich explizitauf personenbezogene Daten wohingegen die Vertraulichkeitsich auf Daten im Allgemeinen bezieht. Im folgenden werdendie einzelnen Schutzziele erklart und Beispiele fur einenAngriff gegeben (vgl. [4]).Vertraulichkeit bedeutet dabei, dass ein Angreifer nicht unbe-fugt an Informationen gelangt. Ein Angriff auf die Vertraulich-keit konnte beispielsweise das Ausspahen eines kryptografi-schen Schlussels sein, wodurch zum Einen der Datenaustauschzwischen einzelnen Komponenten abgehort und zum Anderensogar eigene gefalschte Befehle injiziert werden konnten. An-dere Angriffe wie die Musteranalyse von Datenstromen oderauch ein Umgehen von Authentifizierungsmaßnahmen konnendie Vertraulichkeit gefahrden und zum Bekanntwerden vonsensitiven Daten fuhren.Integritat beschreibt den Schutz von ubertragenen und gespei-cherten Daten vor illegitimer (unerkennbarer) Veranderung. Sokonnte ein Angreifer Befehle zwischen Basis und Aktorenabfangen und erneut absenden oder gar eigene Pakete erstellen,wenn der Integritatsschutz nicht ausreichend implementiert ist.Verfugbarkeit nimmt eine wichtige Rolle im Smart-Home-Umfeld ein. Das Schutzziel beschreibt dabei die Erreichbar-keit aller Komponenten des Systems was beispielsweise die

1https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzSchulung/WebkursITGrundschutz/Sicherheitsmanagement/Sicherheitskonzept/sicherheitskonzept node.html

94

Ausfuhrung von Befehlen verzogern oder ganz verhindernkonnte. Sicherheitsmaßnahmen, die Ausfallsicherheit garan-tieren, mussen besonders bei Sicherheitskomponenten wieBrandmeldern oder Alarmanlagen zuverlassig funktionieren.Angriffe auf die Verfugbarkeit konnen insbesondere bei einerFunkverbindung von Aktoren/Sensoren einfach durchgefuhrtwerden und mussen, sollten diese nicht verhindert werdenkonnen, zumindest erkannt und dem Nutzer sofort angezeigtwerden. Ein Angriff auf die Verfugbarkeit der Basisstation undder Verbindung zum Endgerat des Nutzers muss insbesonderein einem solchen Fall verhindert werden.Authentizitat bezieht sich darauf, dass die Echtheit jederKomponente des Systems uberpruft und durch geeignete Maß-nahmen sichergestellt werden muss. Sind die hierfur vorge-sehenen Sicherheitsmaßnahmen nicht ausreichend, konnte einAngreifer eine Komponente des Systems vortauschen und soTeile des Systems oder sogar das gesamte System kompromit-tieren. Wie auch bei der Vertraulichkeit kann so beispielsweiseein gefalschter Befehl, der beispielsweise eine Alarmanlageabschaltet, an einen Aktor gesendet werden.

II. ANGRIFFE

Angriffe auf die zuvor genannten Schutzziele konnen durcheinen internen, einen externen oder einen Angreifer mit phy-sischem Zugriff durchgefuhrt werden.Physischer Zugriff kann dabei auch durch den Vertrieb vonmanipulierten Gebrauchtgeraten erfolgen, bei dem Gebraucht-gerate explizit so verandert werden, dass sie eine Hintertur(Backdoor) beispielsweise in Form einer gefalschten Firmwareenthalten. Ein Angreifer konnte auch eigene SSL-Zertifikateinstallieren und dann die Kommunikation auf seine eigenenServer umleiten, um den Nutzer auszuspionieren. Exponier-te Komponenten im Außenbereich (z.B. Außenbeleuchtung)konnen auch als Einfallstor dienen, durch welches das ge-samte System kompromittiert werden kann. Auch die direkteManipulation von Sensoren oder Aktoren kann bei einemEinbruch ausgenutzt werden. So wurde beim Fenster- undTuroffnungssensor von RWE, welcher einen Magnet als Ge-genpol verwendet, festgestellt, dass ein einfacher Magnet vordem Sensor ausreicht, damit dieser eine Offnung nicht mehrerkennt.Interne Angreifer nutzen eine Sicherheitslucke oder beispiels-weise ein ungenugend gesichertes WLAN, um sich Zugangzum Heimnetz zu verschaffen. Zwar kann dies durch denHersteller des Smart-Home-Systems nicht verhindert werden,jedoch muss dieser alle Verbindungen zwischen den Kom-ponenten vor einem internen Angreifer beispielsweise durcheine geeignete Verschlusselung geschutzt werden. Ansonstenkonnte dieser durch ARP Poisoning die Kommunikation vonder Basis zum Backend oder von der Basis zu einem Aktor (BBoder AB) auf sein eigenes Gerat umleiten und dann Befehlesenden und z.B. eine Alarmanlage abschalten.Externe Angreifer sind nicht daran gebunden in geografischerNahe zum Zielsystem sein zu mussen. Sie konnen uber dasInternet Backend, Basis oder die Verbindung zwischen bei-den (BB bzw. FBas/FBack) angreifen und sich so Zugangzum System verschaffen. Hierzu kann dieser beispielsweiseSicherheitslucken in Webapplikationen und deren Authentifi-zierungsmechanismen benutzen, um dort Abschaltzeitpunkteeines Sicherheitssystems zu andern oder Uberwachungsdatenauszulesen. Auch im Allgemeinen als unkritisch geltende

Daten wie die Schaltzeitpunkte von Heizungsthermostatenkonnten einem Einbrecher dazu verhelfen, ein Profil der Haus-bewohner anzufertigen, um einen Zeitpunkt zu ermitteln, andem niemand zu Hause ist.

III. FALLSTUDIEN

A. RWE

RWE wurde 1898 als Rheinisch-Westfalischen Elektri-zitatswerks Aktiengesellschaft (RWE AG) gegrundet und wirdseit 1990 durch die Ausweitung der Unternehmensbereichezusatzlich zur Kernkompetenz ”Energie“ nur noch ”RWEAG“ genannt. Das 2009 gestartete Tochterunternehmen ”RWEEffizienz GmbH“ als Dienstleister fur die Energieeffizienz-Infrastruktur bietet mit Marktstart 2010 ein eigenes Smart-Home-System an[8]. Die fur Energiekunden der RWE kos-tenlosen Starter-Kits bestehen aus einer Basis beziehungs-weise Zentrale, einem Steckdosenschalter, zwei Wandschal-tern und einem Heizkorperthermostat. Verschiedene weitereKomponenten sind im RWE eigenen Webshop erhaltlich undkonnen das System beispielsweise um Sicherheitsfunktionen(Brandmelder, Einbruchsschutz) erweitern. RWE setzt auf einexternes Backend (Unternehmensserver), in dem Konfigurati-onsdaten gespeichert werden, und ein mobiles Online Portal,uber welches diese Konfigurationen angepasst werden konnen.Ein lokales auf der Basis verfugbares Portal lasst lediglich dieAktivierung und Deaktivierung von voreingestellten Regeln zu.Der Zugriff auf das lokale und mobile Portal kann von einemPC mit einem Browser oder uber die von RWE vertriebeneSmartphone-APP erfolgen. Dabei ist die App jedoch nur be-grenzt kostenlos nutzbar und muss dann uber ein Abonnementverlangert werden. Schon bei der ersten Installation des Starter-Kits hat RWE einige Sicherheitsmaßnahmen vorgesehen. Sokann eine online Registrierung nur nach dem Anschluss derBasis an das Internet und mittels auf der Basis angezeigtemEinmalpasswort durchgefuhrt werden. Zur Sicherung der Ver-bindungen FBack und FBas setzt RWE auf Microsofts .NETbasierende Browsererweiterung Silverlight, welche zusatzlichzu Transportverschlusselungen sogenannte Policies unterstutzt.Uber diese kann RWE den Verbindungsaufbau feingranularerSteuern und verschiedene Regeln aufstellen [9]. Sollte dieBasis zum Beispiel durch einen Angriff auf die Verfugbarkeitkeine Verbindung zum Internet herstellen konnen, ist es demNutzer lediglich moglich, die zu einem fruheren Zeitpunkterstellten Regeln zu aktivieren oder deaktivieren. Somit ist esan dieser Stelle nicht moglich, beliebige Befehle in das Systemeinzuschleusen. RWE setzt bei den Verbindungen zwischenallen Teilkomponenten auf eine vom Hersteller angepasste Ver-sion des HomeMatic-Funkprotokolls, welches auch in vielenanderen Smart-Home-Losungen verwendet wird (vgl. III-B).Bei der Anpassung des Protokolls legte RWE besonderen Wertauf Datensicherheit und Hackerschutz[10].

Verschlusselte Kommunikation: RWE setzte zunachst beiallen Verbindungen auf TLS 1.0 mit der Moglichkeit, diefolgenden Verschlusselungsalgorithmen zu verwenden: 3DES,AES 128 CBC, RC4. Hierbei sind 3DES und AES 128 CBCals sicher anzusehen. RC4 gilt als unsicher, und es wirdangenommen, dass es von mindestens einem Geheimdienstgebrochen werden kann. Der zum Brechen der Verschlusselungnotige Aufwand ist unbekannt, dennoch sollte der Einsatzvon RC4 vermieden werden. Ein aktueller, im Februar 2015

95

veroffentlichter, Request for Comments (RFC 7465) siehtsogar ein Verbot von RC4 vor[11]. RWE sollte an dieser StelleRC4 nicht mehr als mogliche Verschlusselung akzeptierenund hat aktuell auch teilweise die eingesetzten Algorithmengewechselt. So wird fur die Einrichtung des Benutzerkontosaktuell TLS1.1 mit ECDHE RSA, AES 256 CBC und SHA256eingesetzt. Da das Funkprotokoll von eQ-3 entwickelt wurdeund auf HomeMatic basiert, kann davon ausgegangen werden,das hier weiterhin auf AES128 gesetzt wird.

Aktive Authentifizierung: Zur Registrierung der Basisund Ersteinrichtung des Nutzers werden sowohl ein auf derBasis angezeigtes Einmalpasswort (PIN) verwendet als auchdie Seriennummer des Gerates und entspricht somit einerZwei-Faktor Authentifizierung. So wird verhindert, dass einAngreifer ohne physischen Zugriff die Basis mit einem eige-nen Konto registriert. Zur Einrichtung weiterer Komponentenmussen auch deren Seriennummern im Backend hinterlegtwerden. Ein Angreifer der sich als Smart-Home-Komponenteausgibt musste daher zusatzlich zu Zertifikaten und der Ver-schlusselung auch die Seriennummer der zu falschenden Kom-ponente vortauschen.

Manipulation durch Externe Um einer Manipulationvorzubeugen, wird ein Verschlusselungsverfahren fur nahe-zu alle Verbindungen im System eingesetzt. Lediglich dieBB-Verbindung enthalt eine unverschlusselte Keep-Alive-Kommunikation, in der keinerlei sensitive Daten enthaltensind. Als Sicherheitsmaßnahmen gegen das Einspielen ei-nes manipulierten Firmware-Images ist aufgrund der Intrans-parenz des Sicherheitskonzepts lediglich die verschlusselteUbertragung von automatischen Updates bekannt. Es ist jedochdavon auszugehen, dass auch die Integritat des Updates vor derInstallation und die Authentizitat der Quelle durch geeigneteMaßnahmen gesichert werden (z.B. Prufsummen und sicherenSignaturverfahren). Eine Manipulation durch physischen Zu-griff auf einzelne Komponenten ist auch bei RWE moglich.So kann der Tur- oder Fensteroffnungssensor, wie schon inAbschnitt II beschrieben, manipuliert und umgangen werden.Auch der Vertrieb von manipulierten Gebrauchtgeraten kannnicht ausgeschlossen werden.

B. QIVICON

QIVICON ist eine, im Jahr 2013, von der Telekom in-itiierte Allianz verschiedener Hersteller von Hausautomati-sierungskomponenten. Dabei ist einer der Grundungs- undPlattformpartner eQ-3, deren HomeMatic-Funkprotokoll festerBestandteil von QIVICON ist [12]. Da QIVICON viele ver-schiedene Komponenten diverser Hersteller (z.B. RheinEnergieoder Vattenfall) unterstutzt, soll im folgenden Abschnitt nur aufdas QIVICON Starter-Kit, welches von der Telekom vertriebenwird, eingegangen werden. Dies hat keine Auswirkung aufdie Analyse da sich die Starter-Kits nur in ihrem Liefer-umfang bezuglich zusatzlicher Komponenten unterscheiden.Alle Starter-Kits verwenden die selbe Basisstation (QIVICONHome Base). Neben dieser beinhaltet das Starter-Kit der Te-lekom noch vier weitere HomeMatic-Produkte: einen Rauch-melder, einen Steckdosenschalter und zwei Thermostate. ZurVerwendung des QIVICON Smart-Home-Starter-Kits, musszunachst ein Benutzerkonto mit der Anschrift des Benutzerssowie einer E-Mail-Adresse und einem gewahlten Passwortangelegt werden. Die Basis muss dann mit dem Internet

verbunden und im Backend registriert werden. Hierzu wirddie auf der Basis aufgedruckte Seriennummer und Passwortverwendet. Eine Anderung des Passwortes ist im Anschlussan die Registrierung jedoch auch moglich. Als Frontend kannder Nutzer entweder jedes Internetfahige Gerat mit einemBrowser oder eine der herstellerabhangigen Smartphone-Appsverwenden, welches dann auf das Webportal des Backendsoder innerhalb des Heimnetzes auf das Webportal der Basiszugreift. Uber dieses Portal und den dort verfugbaren Ver-bindungsassistenten konnen einzelne Komponenten mit derBasis Verbunden werden. Dazu ist es notwendig, die Basis perKnopfdruck in Empfangsbereitschaft zu versetzen. Außerdemmuss auf der Komponente, die registriert werden soll, ebensoder entsprechende Knopf gedruckt werden. Das Sicherheits-konzept von QIVICON besteht, wie auch bei RWE aus derKombination von Verschlusselung und Authentifizierung.

Verschlusselte Kommunikation: QIVICON setztezunachst bei der Verschlusselung TLS 1.0 mit den AlgorithmenRSA, RC4 128 und SHA ein. Hierbei ist anzumerken, daswie schon im Abschnitt III-A beschrieben RC4 nicht mehrverwendet werden sollte und es von der Internet EngineeringTask Force (IETF) sogar verboten werden soll [11]. Auchwenn aktuell RC4 noch nicht ohne großeren Aufwandgebrochen werden kann, konnte dies auch zukunftig einegroßere Sicherheitslucke darstellen. Aktuell hat QIVICONzumindest teilweise die Verschlusselungsalgorithmen geandert.Fur die Registrierung wird aktuell beispielsweise TLS1.2mit ECDHE RSA, AES 128 GCM und SHA256 eingesetzt.Nach Herstellerangaben wird im HomeMatic-FunkprotokollAES128 eingesetzt.

Aktive Authentifizierung: Beim Zugriff uber das lokaleNetzwerk auf die Basisstation, ebenso wie beim Zugriff aufdas Webportal des Backends wird die E-Mail-Adresse unddas vergebene Passwort verlangt. Zunachst war die einzigeVoraussetzung fur jenes Passwort die Lange von 8 Zeichen, eswar vollig irrelevant, ob Buchstaben, Zahlen, Sonderzeichenoder Groß/Kleinschreibung verwendet werden. Es entsprachsomit auch nicht den BSI-Empfehlungen fur eine sicherenAuthentikationsmechanismus bzw. ein sicheres Passwort [13],[14]. Hier hat QIVICON nachgebessert, im Webportal mussnun ein “sicheres“ Passwort gewahlt werden (was grafischals “Passwortstarke“ angezeigt wird). Dieses muss dabei ausmindestens einer Kombination von Zahlen, Sonderzeichenoder Groß/Kleinschreibung bestehen und wie zuvor eine Min-destlange von 8 Zeichen haben. Fur das Geratepasswort undfur das Passwort der Konfigurationssicherungsdateien gilt, esmuss mindestens 6 Stellen (maximal 32) und jeweils eineZahl, einen Buchstaben und ein Sonderzeichen enthalten. ZurErsteinrichtung des Systems bzw. der Basis wird zusatzlichzum aufgedruckten Passwort die Seriennummer des Geratsbenotigt. Das Verfahren entspricht damit einer Zwei-FaktorAuthentifizierung.

Manipulation durch Externe: Auch QIVICON setzt zumSchutz vor Manipulation auf Verschlusselung aller Verbindun-gen. Auch Firmware-Aktualisierungen werden uber eine solcheVerbindung ubertragen. Als Sicherheitsmaßnahme gegen dieManipulation der Basisstation mit Hilfe von gefalschten Siche-rungsdateien werden diese auch nur mit einem, pro Sicherungselbst vergebenen Passwort, verschlusselt. Zur Uberprufungder Authentizitat verfugt die Basis sowie das Backend uber

96

eigene, von der Telekom eigenen Zertifizierungsstelle ausge-stellte Zertifikate.

IV. ANALYSE

Damit die vorgestellten Systeme exemplarisch auf ihr Si-cherheitskonzept hin analysiert werden konnen, mussen dieeinzelnen in Abschnitt I genannten Teilkomponenten undVerbindungen auf Sicherheitsmaßnahmen bezuglich der inAbschnitt II genannten Angriffe auf die Schutzziele untersuchtwerden. Da die formale Analyse der Gesamtsysteme denRahmen dieser Arbeit deutlich sprengen wurde, wird dieserSchritt, auch bedingt durch die Intransparenz der Hersteller,auf die bekannten Sicherheitsmaßnahmen (z.B. verwandte Ar-beiten, Herstellerinformationen, etc.) eingeschrankt. Der Ver-gleich beider Systeme und die abschließende Einschatzungbezuglich des erreichten Sicherheitsniveaus sind dennochmoglich und sinnvoll. Zur Bewertung der hier aufgezeigtenMaßnahmen und Konzepte konnen verschiedene Sicherheits-standards und Empfehlungen, wie beispielsweise durch dasBundesamt fur Sicherheit in der Informationstechnik (BSI) im“IT-Grundschutzkatalog“ [15] oder durch die Bundesnetzagen-tur in der “Ubersicht uber geeignete Algorithmen“ (fur elektro-nische Signaturen nach dem Signaturgesetz) [16] herangezogenwerden. Generell gilt, dass erprobte und als sicher eingestufteAlgorithmen und Techniken fur die folgenden allgemeinenMaßnahmen auszuwahlen sind:

Verschlusselung aller Verbindungen und (personlicher)Daten

• Kommunikation: TLS mit sicherem Ver-schlusselungsalgorithmus (z.B.: 3DES, AES)

• Daten: (clientseitige) Verschlusselung mit sicheren Al-gorithmen (z.B.: 3DES, AES)

Sichere Signaturverfahren (Integritat und Authentizitatvon Nachrichten)

• Kombination von Asymmetrischem Ver-schlusselungsalgorithmus (z.B. RSA) und einerHashfunktion (z.B. SHA)

Prufsummen (Integritatsprufung, vgl. [17])

• Cyclic redundancy checks (CRC)

Sichere Authentifizierung (vgl. [13])

• Zwei-Faktor-Authentifizierung

• Nur Passworter mit hoher Passwortgute erlauben

• Anderung von Default Passwortern erzwingen

• Passworter und Schlussel generieren, anstatt statischhinterlegt (Hard-Coded)

Zusatzlich sollten die eingesetzten Maßnahmen regelmaßigdurch geeignete Auditierungs- und Penetrationstests auf ihreWirksamkeit uberpruft werden. Tabelle I zeigt im Vergleich,welche Sicherheitsmaßnahmen die Hersteller RWE und QI-VICON fur die untersuchten Komponenten und Verbindungenin Bezug auf verschiedene Angriffsmoglichkeiten einsetzen.Leider sind nicht alle Sicherheitsmaßnahmen offentlich be-kannt und auch nur zum Teil durch Tests offengelegt. Daher

Objekt Angriff / Ereignis Schutzziel Maßnahme RWE

Maßnahme QIVICON

Backend [Int., Ext.] Umgehender Authentifizierung C,I,Au Sichere Authentisierungs-

merkmale [TUV]

Zwei-Faktor-Authentifizierung

Limitierung vonZugriffsversuchen(Verzogerung),Regeln zur PasswortguteZwei-Faktor Authentifizie-rung, [AV-Test]

Backend [Int., Ext.] XSSInjection, SQLInjection

C,I,Au Eingabevalidierung und Aus-gabekodierung [TUV]

Eingabevalidierung und Aus-gabekodierungHttpOnly Attribut im Cookie

Backend [Int., Ext.]VerwendungabgelaufenerZertifikate

C,I,Au Eigene ZertifikatstelleSichere Implementierung vonabgelaufenen Zertifikaten

Eigene ZertifikatstelleBasis: selbst signiertes Zertifi-kat

Backend [phys. Zugr.] Brand,Stromausfall I,Av Brandmeldeanlagen,

LoschanlageDirekte Feuerwehrschaltung,Zertifizierung [TUV]

—-

Backend [phys. Zugr.]Einbruch inDatenzentrum,Diebstahl von Daten,Festplatten etc.

C,I,Av Zugangskontrolle, Mehrstufi-ger EinbruchsschutzEinbruchmeldeanlage, Zertifi-zierung [TUV]

—-Backend,Basis

[Int., Ext.]Sicherheitslucken imWebportal

C,I,Au,Av Penetrationstests,Zertifizierung [TUV]

—- [AV-Test]

Frontend Sicherheitslucken inder Smartphone-App C,I

—-

Frontend CRSF Angriff imBrowser C,I Zugriff auf das Portal (Ba-

ckend/Frontend) nur uber Sil-verlight

Same Origin Policy, HttpOnlyund Secure Attribute im Coo-kie

Sensor,Aktor,Basis

ManipulierteFirmware C,I,Av Verschlusselte Ubertragung,

gepruftes Update-Konzept[TUV]Integritatsprufung derinstallierten Firmware u.neuer Updates

Verschlusselte UbertragungSensor,Aktor,Basis

Vortauschen(Spoofing) einerKomponente

Au Registrierung derSeriennummern im Backend,eigene ZertifikateVerschlusselte Ubertragungder Seriennummer

Registrierung derSeriennummern im Backend,eigene ZertifikateVerschlusselte Ubertragungder Seriennummer

FBas,FBack

[Int., Ext.] Abhorender Verbindung C,I TLS 1.1 (ECDHE RSA, AES

256 CBC und SHA256)

TLS 1.2 (ECDHE RSA, AES128 GCM, SHA 256),HttpOnly und Secure Attribu-te im Cookie

FBas,FBack

Ubernahme derSitzung (z.B. ReplayAngriff)

C,I Sicheres Sitzungsmanagement[TUV]

—-, [AV-Test]

BB Ubernahme derSitzung (z.B. ReplayAngriff)

C,I Sicheres Sitzungsmanagement[TUV]

—-, [AV-Test]SA, SB,AB

[Int.] Abhoren derVerbindung C,I TLS1.0 (AES 128)

TLS1.0 (AES 128)Tabelle I. ANALYSE VERSCHIEDENER KOMPONENTEN DER

BEISPIELSYSTEME

97

bedeuten Eintrage in der Tabelle die ein TUV-Siegel [TUV]enthalten, dass die an dieser Stelle eingesetzten Verfahrenzwar nicht genau bekannt sind, im Rahmen einer Akkredi-tierung vom TUV-IT jedoch uberpruft und als “sicher“ ein-gestuft wurden. Eine Zertifizierung besteht jedoch nur furRWE. QIVICON verweist bezuglich einer Attestierung ihrerSicherheit auf Studien wie AV-Test ([2]). [AV-Test] markiertdaher in der Tabelle entsprechende Eintrage, bei denen dieSicherheitsmaßnahmen nicht genau bekannt sind, jedoch vonAV-Test nicht als unsicher eingestuft wurden. Im Vergleichzeigt RWE mehr Transparenz oder demonstriert zumindestdie Effektivitat von unveroffentlichten Maßnahmen durch eineoffizielle Zertifizierung. QIVICON wurde zwar als Hersteller-allianz einen hoheren Aufwand fur eine entsprechende Zerti-fizierung benotigen, sollte an dieser Stelle jedoch Transparenzfordern oder geeignete Sicherheitsuberprufungen (Audit, Pene-trationstests) mit entsprechender, fur Endkunden ersichtlicherAttestierung einfuhren.

V. BEWERTUNG

Die Smart-Home-Starter-Kits von RWE und QIVICONgelten aktuell, wie in verschiedenen Analysen gezeigt, noch alssicher. So wurde die Funkverbindung von RWE beispielsweisebereits 2013 intensiv von Thomas Reuter[4] untersucht, eineallgemeine Studie uber die Sicherheit der Systeme von RWEund QIVICON wurde durch AV-Test erstellt [2]. Beide Ana-lysen attestieren grundsatzlich eine sichere Implementierung,zeigen jedoch noch einige kleinere Sicherheitslucken. DieAnalyse erfolgte zunachst durch automatisierte Test wie bei-spielsweise mittels Nmap und Metasploit, zeigten jedoch keineoffensichtlichen Schwachstellen. Eine manuelle Untersuchungzeigte jedoch auch Schwachstellen in den Sicherheitskonzep-ten. So waren auch zunachst weniger sichere Verfahren wieRC4 im Einsatz. Hier haben jedoch beide Hersteller nach-gebessert und setzen aktuell die von der Bundesnetzagenturempfohlenen Algorithmen und vom Bundesamt fur Sicherheitin der Informationstechnik empfohlene Verfahren ein. Dasgenerelle Sicherheitskonzept beider Systeme ahnelt sich daherauch in den wesentlichen Punkten. Als Funkprotokoll wirdin beiden Fallen eine Variante von HomeMatic mit AES128Verschlusselung eingesetzt. Die Einrichtung beziehungsweiseSicherheit des vom Endnutzer eingerichteten Heimnetzes spielteine wichtige Rolle fur die Gesamtsicherheit des Smart-Home-Systems, kann aber nur bedingt durch herstellerseitige Maß-nahmen verbessert werden. Sowohl QIVICON als auch RWEsetzen daher auf eine Verlagerung von Daten und Programm-logik vom Heimnetz in das Unternehmensnetzwerk (Backend,Datenzentren). Hierdurch konnen bessere Mechanismen wieetwa Redundanz von Datenzentren, Zutritt- und Zugriffskon-trollen, starke Serverseitige Sicherheit sowie Wartung undAuditierung eingesetzt werden, jedoch erhoht sich auch furden Nutzer die Gefahr fur eine Verletzung des Datenschutzes.Die Verarbeitung der im Smart-Home-System gesammeltenpersonlichen beziehungsweise personenbezogenen Daten imBackend kann nicht nachvollzogen werden, auch wenn derBetreiber die bestimmungsgemaße Verarbeitung nach §9BDSGgarantiert. Auch die Registrierung und Einrichtung der Syste-me von RWE und QIVICON ahneln sich und setzen meh-rere Faktoren (Internetverbindung der Basis, Geratekennwort,Seriennummer) voraus. Eine entsprechende Passwortgute furdas Benutzerkonto wird bei beiden vorausgesetzt. Fur das

Geratekennwort konnte man die Losung von RWE, ein ge-neriertes Passwort auf dem Display der Basis anzuzeigen, alssicherer ansehen, jedoch muss dieses durch einen als sichergeltenden Generator erstellt werden. QIVICON erlaubt imGegenzug die Anderung des Geratekennworts, was auch vomBSI empfohlen wird (vgl. [14]). Die Sicherung von Funk- undNetzwerkverbindungen entspricht den allgemeinen Standards,wobei hier auch die Bereitschaft zur Verbesserung deutlichwird. So wurde im April 2014 beim Einsatz von TLS1.0 nochdas unsichere RC4 angeboten (vgl. [2]), konnte bei einer ak-tuellen Uberprufung ein Wechsel zu TLS1.1 beziehungsweiseTLS1.2 ohne Unterstutzung von RC4 festgestellt werden. Umdie Authentizitat von Komponenten zu garantieren, wird derenSeriennummer herangezogen und bei der Einrichtung in derBasis hinterlegt. Außerdem werden (selbst signierte) Zertifi-kate eingesetzt. Sollte die Uberprufung von Seriennummernbeziehungsweise der Zertifikate die einzigen Sicherheitsmaß-nahmen2 fur die Uberprufung der Authentizitat sein, konntedies, insbesondere bei einem Angreifer mit physischen Zu-griff (z.B. “Duplizierung“ von Gebrauchtgeraten) ein Problemdarstellen. Im Gegensatz dazu zeigten die Maßnahmen furdie Sicherstellung von korrekter unmanipulierten Firmwareund Firmware-Aktualisierungen keine Sicherheitslucken. Ak-tualisierungen werden grundsatzlich verschlusselt ubertragen,weitere Integritatsprufungen sind jedoch nicht bekannt, mankann aber von einer Umsetzung mit Hilfe von Prufsummenoder ahnlichem ausgehen. Hinweise hierzu finden sich bei-spielsweise in der Dokumentation der Basis des RWE Systems,in welcher Fehlermeldungen wie “Ungultige Firmware aufder Smart-Home-Zentrale“ oder “Ungultige Firmwareaktuali-sierungsdatei“ aufgefuhrt sind (vgl. [18]). Bezuglich der Aus-fallsicherheit beziehungsweise den Maßnahmen beim Nichter-reichen von Aktoren und Sensoren sowie der Manipulierungsolcher Komponenten bei physischem Zugriff, ist eine Analyseder Sicherheitsmaßnahmen schwierig. Diese hangt stark vomEinzelfall ab und beispielsweise QIVICON unterstutzt uber200 verschiedene Teilkomponenten verschiedenster Hersteller.Dieser Aspekt sollte jedoch nicht unterschatzt werden, da furRWE hier beispielsweise bereits gezeigt wurde, dass Fens-ter und Turoffnungssensoren umgangen werden konnen. BeiQIVICON fuhrte am 29.09.2015 ein Ausfall des Backendszu einem Funktionsausfall der angeschlossenen Smart-Home-Systeme, Komponenten wie Thermostate arbeiteten darauf-hin nicht mehr korrekt (z.B. keine Abschaltung)3. In dieserBeziehung mussen beide Hersteller ihr Sicherheitskonzeptuberprufen, insbesondere muss darauf geachtet werden, dassder Nutzer sofort uber Ausfalle informiert wird und der Ausfalleinzelner Komponenten nicht die Funktion des Gesamtsystemsbeeintrachtigt.

VI. FAZIT

Trotz der Intransparenz der Hersteller konnten die in derAnalyse betrachteten Sicherheitsmaßnahmen als angemessenbeurteilt werden. Es ist jedoch zu erwarten, dass Sicherheits-maßnahmen auch kunftig nicht offengelegt werden, daher soll-te im Interesse der Endkunden die Uberprufung und Zertifizie-

2Weitere Sicherheitsmechanismen zur Sicherstellung der Authentizitat sindnicht bekannt bzw. offengelegt.

3Deutsche Telekom: Ausfall des QIVICON-Servers legt Smarthomeslahm - http://www.heise.de/newsticker/meldung/Deutsche-Telekom-Ausfall-des-Qivicon-Servers-legt-Smart-Homes-lahm-2832456.html

98

rung fur Smart-Home-Losungen durchgefuhrt werden. AnsatzeSicherheitslucken, die durch Studien wie AV-Test bekanntwurden, zu beheben, sind sowohl bei RWE als auch QIVI-CON erkennbar. Das Sicherheitsniveau fur die Systeme istgut, jedoch muss bei einem Einsatz von sicherheitskritischenKomponenten wie Alarmanlagen, Brandmelder etc. abgewagtwerden, ob die Einbindung in ein Smart-Home-System ihreSicherheit und die korrekte Funktion nicht gefahrdet. SolcheKomponenten sollten im Grundsatz immer auch autonomarbeiten. Im Beispiel der Alarmanlage konnte diese in das Sys-tem eingebunden werden, jedoch nur die Uberwachung mittelsBasis und nicht die Abschaltung erlauben. Generell ist trotz derSicherheitskonzepte ein erfolgreicher Angriff durchaus denk-bar, insbesondere wenn man bedenkt, dass die durchgefuhrtenTests und Analysen ([2],[4]) nicht tiefergehend und allumfas-send waren. Auch die Anzahl der Smart-Home-Gerate wird inZukunft weiter steigen. Zurzeit scheint die Gefahrdungslagenoch nicht kritisch, jedoch werden Smart-Home-Komponentenimmer popularer und vielfaltiger, hierdurch konnen sich neueAngriffe und kriminelle Geschaftsmodelle entwickeln. Schonjetzt sind lohnenswerte Angriffsszenarien denkbar: Smart-Home-Systeme, die mit Kameras, Tur- und Fenstersensorenarbeiten, stellen fur Einbrecher ein nutzliches Angriffsziel dar.Denn Angreifer konnten durch Auslesen der Konfiguration vonGeraten oder den historischen Daten folgern, wann die Besitzeranwesend sind (z.B. Einschalten der Alarmanlage bei Verlas-sen des Hauses). Einbrecher konnten daraufhin die Alarm-anlage deaktivieren, und hatten so ein leichtes Spiel. SelbstSysteme, die lediglich unkritisch erscheinende Komponentenwie Steckdosen, Schalter und Heizungsthermostate steuern,und aus Sicht des Endnutzers einen großen Komfortgewinnbieten, konnten lohnenswerte Ziele darstellen. Gelingt es bei-spielsweise einem Angreifer, die Kontrolle uber ein solchesSystem zu erlangen, konnte dieser Schadsoftware einspielen,um die Anlage unbrauchbar zu machen oder Konfigurationendes Nutzers zu verandern. Beispielsweise konnten Thermostateherunter geregelt werden, so dass die Wohnung auskuhlt oderim schlimmsten Fall sogar Frostschaden an Wasserrohrenentstehen konnten. Ein vom Angreifer kontrolliertes Systemkonnte auch fur Betrugs- und Erpressungsversuche genutztwerden. Ahnlich des sogenannten BKA-Trojaners, welcherPCs sperrt und erst nach Bezahlung eines bestimmten Betrageswieder freigibt, ware hier eine virtuelle Geiselnahme einesganzen Hauses denkbar. Auch ein realistischeres Szenario waredenkbar, hierfur musste sich ein Betruger lediglich kurz nach“Sperrung“ des Systems dem Nutzer als Techniker vorstellenund konnte dann einen Betrag als Lohn zur “Reparatur“der Gerate verlangen. Trotz dieser erschreckenden Szenari-en muss ein Angreifer zunachst die Sicherheitsmaßnahmender Hersteller uberwinden. Und obwohl die bisher genanntenSchwachstellen in Smart-Home-Systemen oft noch theoreti-scher Natur sind, zeigen sie dennoch die Gefahrenpotenzialeauf, mit welchen sich die Hersteller konfrontiert sehen mussen.Die von den in dieser Arbeit untersuchten Sicherheitskonzeptekonnten daher eine Grundlage fur die Erarbeitung allgemeinerVorgaben oder sogar gesetzlicher Regelungen fur die Sicher-heitsmaßnahmen im Smart-Home-Bereich darstellen. Denntrotz des positiven Analyseergebnisses, zeigen Studien wie AV-Test, dass manche Hersteller sogar grundlegende Regelungeneiner sicheren Implementierung und offizielle Empfehlungenmissachten. So gibt es Systeme, die keinerlei Verschlusselungvon Netzwerkverbindungen einsetzen und sogar ein komplettes

Fehlen von Authentifizierungsmechanismen (z.B. Passwort)beim Zugriff auf die Basis wurde in den Studien von AV-Testund Symantec festgestellt. Ein weiteres Problem mit fehlendenSicherheitskonzepten ist, dass die nachtragliche Implementie-rung von Sicherheitsmechanismen und die Schließung vonSicherheitslucken in eingebetteten Systemen teilweise nichtohne weiteres moglich sind. So ist beispielsweise die Rechen-geschwindigkeit in einem solchen System zu gering, als das al-le aktuell als sicher eingestuften Verschlusselungsalgorithmenverwendet werden konnten. Auch ist fraglich, ob die automa-tische Versorgung mit Updates fur Gerate wie Kuhlschranke,Telefone, Fernseher oder ahnliches einfach moglich ist. Dasmanuelle Einspielen von solchen Aktualisierungen ist, auchin Anbetracht der Anzahl von zukunftig vernetzten Geratenkaum vorstellbar. Ein im Vorfeld aufgestelltes, zukunftssiche-res Sicherheitskonzept, welches zudem ein automatisiertes undsicheres Aktualisierungsverfahren enthalt, ist daher auch wei-terhin unumganglich. Standardisierungen und Normen warendiesbezuglich gerade fur kleinere Hersteller von Vorteil.

LITERATUR

[1] C. Gomez and J. Paradells, “Wireless home automation networks: Asurvey of architectures and technologies,” Communications Magazine,

IEEE, vol. 48, no. 6, pp. 92–101, June 2010.[2] M. Schiefer, U. Losche, and M. Selinger. (2014, April) Av-test-studie 7

smart-home-starter-kits im sicherheits-test. Abgerufen am 30.11.2015.[Online]. Available: https://www.av-test.org/fileadmin/pdf/avtest 2014-04 smart home deutsch.pdf

[3] M. B. Barcena and C. Wueest. (2015, Marz) Insecurity in theinternet of things. Abgerufen am 04.12.2015. [Online]. Availa-ble: http://www.symantec.com/content/en/us/enterprise/media/securityresponse/whitepapers/insecurity-in-the-internet-of-things.pdf

[4] T. Reuter, “Security analysis of wireless communication standards forhome automation,” Master’s thesis, Technische Universitat Munchen,Nov. 2013.

[5] Mastery IT. (2015, Januar) Smart home egypt – smart hometechnology. Abgerufen am 10.12.2015. [Online]. Available: http://masteryit.com/blog/smart-home/tag/smart-home/

[6] KNX Association cvba. Knx ist jetzt der internationale standardiso/iec 14543-3. Abgerufen am 04.12.2015. [Online]. Available: http://www.knx.org/fileadmin/news/120524713218185PR20061201-DE.pdf

[7] M. Semmler. (2013, Juli) Wireless-lans richtig absichern!Antago GmbH/BMWV. Abgerufen am 10.12.2015. [Online].Available: http://www.bvmw.de/fileadmin/NewsLetter/mit-sicherheit/201303/Semmler paper wireless-lan.pdf

[8] P. Hoscheidt. (2010, Juli) Die rwe effizienz gmbh: Dienstleisterfur energieeffizienz. Abgerufen am 14.01.2016. [Online]. Available:https://www.heuer-dialog.de/aktuell/02.07.2010

[9] Push Technology Limited. (2015) Silverlight securitymodel. Abgerufen am 15.01.2016. [Online]. Available: http://docs.pushtechnology.com/docs/5.6.1/manual/html/administratorguide/webserver/crossdomain/silverlight crossdomain.html

[10] G. Ohland. (2013, August) Funkprotokolle: Z-wave, homematic undrwe im vergleich. PC-Magazin. Abgerufen am 16.12.2015. [On-line]. Available: http://www.pc-magazin.de/ratgeber/funkprotokolle-ueberblick-rwe-zwave-homematic-1530051.html

[11] A. Popov. (2015, Februar) Prohibiting rc4 cipher suites. InternetEngineering Task Force. [Online]. Available: https://tools.ietf.org/html/rfc7465

[12] ELV Elektronik AG. (2013, August) eq-3 ist grundungspartner inder qivicon-herstellerallianz der deutschen telekom. Abgerufen am10.01.2016. [Online]. Available: http://www.elv.de/controller.aspx?cid=242&detail=1&detail2=230

[13] Bundesamt fur Sicherheit in der Informationstechnik (BSI). (2013) M 4.133 geeignete auswahl von authentikations-mechanismen. Stand 2013, Abgerufen am 06.01.2016. [Onli-

99

ne]. Available: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/ content/m/m04/m04133.html

[14] Bundesamt fur Sicherheit in der Informationstechnik (BSI). (2013)M 2.11 regelung des passwortgebrauchs. Stand 2013, Abgerufenam 07.01.2016. [Online]. Available: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/ content/m/m02/m02011.html?nn=6610622

[15] ——. It-grundschutz kataloge. [Online]. Availa-ble: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge node.html

[16] Bundesnetzagentur. (2015, 11) Bekanntmachung zur elek-tronischen signatur nach dem signaturgesetz und dersignaturverordnung. Abgerufen am 04.01.2016. [Online].Available: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekSignatur/Algorithmenkatalog Entwurf.pdf

[17] Bundesamt fur Sicherheit in der Informationstech-nik (BSI). (2013) M 4.93 regelmaßige inte-gritatsprufung. Stand 2013, Abgerufen am 20.12.2015. [Onli-ne]. Available: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/ content/m/m04/m04093.html

[18] RWE AG. (2011, Oktober) Rwe smarthome anleitungfur problembehebungen, meldungen, hinweise undfehlercodes. Abgerufen am 11.01.2016. [Online]. Available:https://www.rwe-smarthome.de/web/cms/mediablob/de/1390108/data/496046/1/smarthome/informieren/hilfe/RWE-SmartHome-Troubleshootingguide.pdf

100

Analyse gangiger Smart Home-Ubertragungstechnologien bezuglich

Datenschutz und Sicherheit

Johannes WielandHochschule Furtwangen

Studiengang: Mobile Systeme MasterEmail: johannes.wieland@hs-furtwangen.de

Johannes M. HunnHochschule Furtwangen

Studiengang: Mobile Systeme MasterEmail: johannes.markus.hunn@hs-furtwangen.de

Zusammenfassung—Diese Ausarbeitung beschaftigt sich mitder Betrachtung von Sicherheitskonzepten ausgewahlter SmartHome-Ubertragungstechnologien und soll einen Uberblick uberZigBee, Z-Wave und EnOcean geben. Fortfuhrend werden diesedrei Technologien analysiert, auf Schwachstellen und auf feh-lerhafte Implementierungen uberpruft und anhand von bereitsveroffentlichten Angriffen dargestellt. Dabei wird auf diverseAngriffsvektoren und Sicherheitsmechanismen eingegangen. An-schließend werden die drei Technologien mit einander bezuglichderen Sicherheit verglichen. Abschließend wird ein Ausblick indie Zukunft der Smart Home-Ubertragungstechnologien gewagt.

I. EINLEITUNG

Smart Home ist momentan ein gangiges Thema in dendeutschen wie auch den internationalen Medien, gerade auch inVerbindung mit dem Schutz personlicher Daten und der Sicher-heit des deutschen Eigenheims. Besonders im Bezug auf diegesetzliche Datenvorratsspeicherung und der umgangssprach-lichen Datensammelwut der deutschen Behorden macht eineBetrachtung der Sicherheits- und Datenschutzaspekte Sinn. ImVergleich zu Burgern anderer Nationen sind die deutschenBurger momentan noch bedeutend konservativer gegenuberdiesen neuen ”smarten“ Technologien eingestellt (vgl. [1]).

Die Experten des Instituts fur Innovation und Technik (IIT)in Berlin, Hartmut Strese, Uwe Seidel, Thorsten Knape undAlfons Botthof definieren den Begriff ”Smart Home“ in ihremFachartikel ”Smart Home in Deutschland“[2] wie folgt:

”Das Smart Home ist ein privat genutztes Heim (z.B.Eigenheim, Mietwohnung), in dem die zahlreichenGerate der Hausautomation (wie Heizung, Beleuch-tung, Beluftung), Haushaltstechnik (wie z.B. Kuhl-schrank, Waschmaschine), Konsumelektronik undKommunikationseinrichtungen zu intelligenten Ge-genstanden werden, die sich an den Bedurfnissen derBewohner orientieren.“

Im weiteren Verlauf dieser Arbeit wird der Begriff ”SmartHome“ in Anlehnung an die Definition des IIT genutzt. AufGrund der eher konservativen Einstellung der Deutschen ge-genuber diesen smarten Technologien wird der Begriff hier inabgeschwachter Form genutzt. So genugt es, wenn ein paarwenige dieser Systeme miteinander verknupft werden. Einevollstandige Verknupfung aller Haushaltsgerate ist somit nichterforderlich.

Zu den Komponenten eines Smart Homes zahlen nicht nurFernseher, Radios sowie Wasch- und Kuchengerate, sondernauch Komponenten einer Hausautomatisierung mit diversenSensoren und Aktoren, mit denen ein intelligentes Haus auchvon unterwegs gesteuert werden kann. Sicherheitskomponen-ten wie beispielsweise Alarmanlagen, automatische Turoffneroder Zutrittskontrollsysteme fallen ebenfalls darunter. Schonanhand dieses Spektrums an Anwendungsgebieten lasst sicherahnen, wie vielseitig und unubersichtlich ein Smart Homesein kann.

Fur die Kommunikation unter all diesen Komponentenwurden diverse kabellosen sowie kabelgebundenen Uberta-gungstechnologien entwickelt. Untereinander kompatibel sinddiese allerdings nur in seltenen Fallen. So fragmentiert sich derMarkt der Smart Home-Produkte zunehmend immer weiter,abhangig von den Ubertagungstechnologien, den Einsatzgebie-ten sowie den Produktherstellern.

Diese Arbeit konzentriert sich auf die wichtigsten undaktuellsten Technologien, welche im Praxiseinsatz betrachtetwerden. Zu diesen Technologien gehoren unter anderem eQ3,KNX, Bluetooth, WLAN, EnOcean, Z-Wave und ZigBee. Zurweiteren Eingrenzung werden auf Grund der hohen Praxisrele-vanz und Aktualitat nur letztere drei drahtlosen Technologiengenauer betrachtet.

Diese ausgewahlten Ubertragungstechnologien werden imweiteren Rahmen dieser Arbeit anhand oft eingesetzter An-griffsvektoren fur Funkubertragungen auf deren Sicherheituberpruft. Diese Angriffsvektoren stellen ebenfalls nur eineUntermenge aller moglichen Angriffsarten dar. Abgrenzenlasst sich die Sicherheitsbetrachtung dadurch, dass nur dieSeite der zuvor ausgewahlten drahtlosen Ubertragungstechno-logien betrachtet wird. So werden beispielsweise eine Sicher-heitsbetrachtung des LAN Interface und des Web Interfacesdes Gateways ausgeschlossen.

II. GRUNDLAGEN

Das folgende Kapitel beschaftigt sich mit grundlegendenBegriffen, Technologien und Konzepten wie Frequenzbandern,Duty Cycle, Mesh-Netzwerken und Rolling-Codes.

A. Frequenzbander

Fur die drahtlose Kommunikationsubertragung wird imBereich Smart Home auf die sog. ISM-Frquenzbander gesetzt.

101

”Der Begriff ”ISM“ steht fur ”Industrial Scienti-fic and Medical“ (Hochfrequenzanwendungen in In-dustrie, Wissenschaft und Medizin). Die zugehori-gen ISM-Frequenzen sind international zur Nutzungdurch Hochfrequenzgerate zugewiesen. [3][S. 1]“

Diese Frequenzbander sind offentlich und ohne weite-re Lizenzkosten fur jedermann nutzbar. Viele Smart Home-Komponenten senden in Europa deshalb auf diesen Fre-quenzbandern. Populare Vertreter sind die Bander um868MHz und 2, 4GHz. Bekannte Vertreter des 868MHz-Bandes sind beispielsweise Funkrauchmelder oder Gar-agenturoffner. Auf dem 2, 4GHz-Band senden hingegen Ama-teurfunkgerate und Mikrowellenherde. EnOcean und Z-Wavesenden auf dem Frequenzband von 868MHz, Bluetooth- undWLAN-Gerate hingegen senden auf dem Frequenzband von2, 4GHz. ZigBee ist eine Ausnahme und kann nach demStandard, auf dem es basiert auf beiden Frequenzbandernsenden. Abbildung 1 stellt dies ubersichtlich dar. Auf demFrequenzband mit 868MHz kann mit max. 10mW ERP(Equivalent isotropic radiated power) mit einem Duty Cycle< 1% gesendet werden. Im 2, 4GHz-Band kann mit einerSendeleistung von max. 100mW ERP gesendet werden. Dadiese Frequenzbander offentlich nutzbar sind, senden vieleGerate mit unterschiedlichen Anwendungsbezugen auf diesenBandern. Dadurch entstehen physikalische Interferenzen undprotokollbasierte Kollisionen von Datenpaketen, wodurch dieUbertragungen gestort werden.

B. Duty Cyle

Viele der Komponenten eines Wireless Sensor Net-works (WSN) sind batteriebetrieben, was der flexiblen Ein-satzmoglichkeiten sowie einer schnellen, userfreundlichen In-stallation geschuldet ist. So ist eine der wesentlichen Anfor-derungen einer WSN-Komponente das Sparen von Energie,damit diese moglichst lange ohne das Wechseln von Batte-rien oder Akkus betrieben werden kann. Dazu werden dieSensorkomponenten in einen Energiesparmodus versetzt, aus

Abbildung 1. Vergleich: Ubertagungstechnologien[4][S. 4]

dem sie in zyklischen Zeitabstanden aufgeweckt werden. Indiesem Zeitraum lauschen sie im Netzwerk, ob Informationenan die gesendet werden, und senden u.U. selbst eigene Datenin das Netzwerk. Die Zeitspanne, in der eine Komponenteaktiv ist, sie somit Daten senden und empfangen darf, wirdDuty Cycle genannt. Dieser Duty Cycle wird zum einenvon Regierungsbehorden wie der Bundesnetzagentur fur diejeweiligen Frequenzbander und zum anderen von Standards furdie einzelnen Protokolle definiert. Diese Duty Cycle liegen inWSNs meist in Bereichen um < 0, 1% und < 1% (vgl. [5][S.55], [3]).

C. Mesh-Netzwerk

Ein Mesh-Netzwerk (vermaschtes Netzwerk) ist eine Netz-werktopologie, in der ein Netzwerkknoten mit einem odermehreren anderen Knoten verknupft ist (siehe Abbildung 2).Sobald alle Knoten des Netzwerks untereinander verknupftsind, wird von einer vollstandigen Vermaschung gesprochen.Diese Netzwerktopologie kommt sehr oft in Sensornetzwerkenauf Grund der Flexibilitat, Robustheit und deren Ausfallsicher-heit zum Einsatz.

In einem solchen Mesh-Netzwerk werden die zu sendendenDaten von einem Knoten immer an den nachst besten Nach-barknoten weitergeleitet. Dieser sendet das Datenpaket ebenso an seinen Nachbarknoten weiter, bis das Datenpaket seinZiel erreicht hat. Am Besten heißt in diesem Fall, dass dieVerbindung die schnellste, die ausfallsicherste oder der phy-sikalisch naheliegendste Knoten ist. Sobald einer der Knotenuber diesen Ubertragungsweg ausfallt, werden die Daten anden nachst besseren Knoten gesendet.

So bietet diese Topologie eine hohe Robustheit gegenuberAusfallen von einzelnen Komponenten (vgl. [6][S. 178-179],[5][S. 36]).

102

Abbildung 2. Beispiel Mesh-Netz Topologie [5][S. 36]

D. Grundlegende Sicherheitsanforderungen in Datennetzwer-ken

Eine Informationsubertragung in einem Datennetzwerkmuss, unabhangig der verwendeten Ubertragungstechnologienoder der verwendeten Ubertragungsprotokolle, grundlegendeSicherheitsanforderungen erfullen. Dazu zahlen unter anderemdas Einhalten der folgenden Schutzziele:

1) Vertraulichkeit: Sobald bei einer Informationsuber-tragung die unautorisierte Informationsgewinnung verhindertwird, ist das Schutzziel der Vertraulichkeit (englisch: confi-dentiality) gewahrleistet. Das Erreichen des Zieles der Vertrau-lichkeit kann durch eine verschlusselte Ubertragung unterstutztwerden (vgl. [8][S. 9-10]).

2) Integritat: Die Integritat (englisch: integrity) einerNachricht ist dann gewahrleistet, wenn eine unautorisierte Ma-nipulation der ubertragenen Nachricht vom Empfanger erkanntwerden kann. Durch Hilfe von Prufsummen sowie kryptogra-fischen Hash-Funktionen konnen Manipulationen von Datenerkannt und somit der Verletzungen der Datenintegritat entge-gen gewirkt werden (vgl. [8][S. 9]).

3) Verfugbarkeit: Ein System an sich und die von ihmbereitgestellten Dienste gelten als verfugbar (englisch: availa-bility), wenn die geforderte Leistung ohne Einschrankungdurch unautorisierte Storungen erbracht werden (vgl. [9][S. 11-12]).

4) Authentizitat: Um dieses Schutzziel einzuhalten mussenbei der Datenubertagung die zu ubertragenen Daten auf ih-re Echtheit und Glaubwurdigkeit uberprufbar sein. Die Au-thentizitat (englisch: authenticity) von Objekten kann durchkryptografische Verfahren erreicht werden. Dadurch wird dieeindeutige Identitat und somit Echtheit bestimmt (vgl. [8][S.8]).

5) Verbindlichkeit/Nichtabstreitbarkeit: Sollte ein Nutzereine Handlung, welche er durchgefuhrt hat, nicht abstreitenkonnen, ist die Verbindlichkeit (englisch: non repudiation) alsSchutzziel erreicht. Dies kann mittels digitaler Signaturen oderdurch sichere Aufbewahrung von Log-Dateien erreicht werden(vgl. [8][S. 12-13]).

III. ANGRIFFSVEKTOREN

Da im Rahmen dieser Arbeit ausschließlich funkbasierteUbertagungstechnologien betrachtet werden, muss die fol-gende Auswahl der Angriffsvektoren diesen Technologiengenugen. So wurden zum einen Angriffe ausgewahlt, diespeziell auf eine Funkubertagung abzielen, zum anderen wer-den Angriffe betrachtet, die auf Protokoll- und Logikebene

abzielen. Angriffe auf die Funkubertragung sind ein Manin the Middle-Angriff, ein Denial of Service-Angriff, einJamming-Angriff sowie ein Capture and Replay-Angriff. Dabeistellen die ausgewahlten Angriffstechniken bei weitem nichtalle moglichen Angriffstechniken dar. Viel mehr reprasentierendiese die auf Funktechnologie am haufigsten angewendetenAngriffsvektoren. So werden beispielsweise Angriffsmethodenauf die LAN-Anbindung sowie auf Web Interfaces nicht naherbetrachtet. Im Folgenden wird auf die Angriffsvektoren nahereingegangen. Darunter fallen Angriffe wie ein Man in theMiddle-Angriff, ein Denial of Service-Angriff, ein Jamming-Angriff, ein Capture und Replay-Angriff, Seitenkanalangrif-fe, der Einsatz von Verschlusselung sowie der ungesicherteSchlusselaustausch.

A. Man in the Middle-Angriff

Ein Man in the Middle-Angriff (MitM) bezeichnet einenAngriff, bei dem der Kommunikationsweg zwischen zweiKommunikationspartnern uber einen dritten Partner umgeleitetwird. Dabei kann die Kommunikation abgehort und der Inhaltder Nachrichten verandert werden (vgl. [9][S. 574]).

B. Denial of Service-Angriff

Im Gegensatz zu einem Man in the Middle-Angriff werdenbei einem Denial of Service-Angriff (DoS) der Kommuni-kationsweg weder abgehort noch Nachrichten verandert. Eshandelt sich dabei um eine protokollseitige Storung einesDienstes bzw. eines Systems. Dadurch wird ein Dienst durchdas Fluten von legitimen Anfragen derart belastet, dass dasSystem mit der Beantwortung der Anfragen nicht nachkommenkann. Weiter nachkommende Nachrichten werden komplettverworfen oder erst extrem spat beantwortet. So ist mit demSystem bzw. dem Dienst keine weitere Kommunikation mehrmoglich (vgl. [9][S. 556]).

C. Signal Jamming-Angriff

Ahnlich wie bei einem Denial of Service-Angriff wirddurch das sogenannte Signal Jamming (kurz Jamming) dieKommunikation eines Netzwerkteilnehmers unterbunden. Diesgeschieht jedoch nicht auf Protokollebene, sondern auf derEbene der physikalischen Ubertragung. So wird der ange-griffene Teilnehmer mit Storsignalen auf seiner Sende- oderEmpfangsfrequenz blockiert. Dabei uberlagern sich die beidenSignale auf dem Ubertragungsmedium und fuhren zu Interfe-renzen (vgl. [10][S. 185-186],[11][S. 409]).

Tritt dieses Phanomen in der Praxis auf, muss es sich dabeijedoch nicht zwingend um einen Angriff handeln, sondernkann durch andere gewohnliche Gerate mittels Funktechno-logie in der Nahe temporar ausgelost werden.

D. Capture und Replay

Bei einem Capture und Replay-Angriff wird eine Ubertra-gung zwischen einem Sender und einem Empfanger in einem(meist) drahtlosen Netzwerk abgehort und aufgezeichnet. Die-se aufgezeichnete Nachricht wird anschließend vom Angreifernoch einmal an den Empfanger gesendet (vgl. [12][S. 108]).

103

E. Seitenkanalangriffe

Wie der Begriff Seitenkanalangriff bereits aussagt, handeltes sich dabei nicht um einen Angriff auf die eigentlicheAnwendung, sondern es wird vielmehr versucht durch Nut-zung anderer Wege einer Ubertagung an die Daten einesSystems zu kommen. Durch solch einen Angriff wird versuchtein bestimmtes Verhalten der Anwendung bzw. des Systemsherbeizufuhren (vgl. [13][S. 52-53], [14][S. 97-98]). DieseAngriffstechnik wird oft fur Angriffe auf Algorithmen undkryptografische Verfahren angewendet (vgl. [14][S. 97-98]).

F. Einsatz von Verschlusselung

Ein Angriff auf die Verschlusselung selbst kann in unter-schiedlichsten Formen erfolgen. Dabei werden die Angriffedurch die zur Verfugung stehenden Informationen der Ver-schlusselung klassifiziert. Bei einem Brute Force-Angriff wirdder gesamte mogliche Schlusselraum, d.h. alle moglichenSchlussel automatisiert durchgetestet, in der Hoffnung, dasseiner der genutzten Schlussel zum Erfolg fuhrt (vgl. [8][S.363-364]).

Bei einem Klartext-Angriff (englisch: ciphertext-only) ste-hen dem Angreifer mehrere verschlusselte Nachrichten zurVerfugung. Dabei wird versucht, beispielsweise durch eineHaufigkeitsanalyse der Buchstaben, den Klartext oder den ge-nutzten Schlussel der Verschlusselung zu bestimmen. Fur einenAngriff mit bekanntem Klartext (englisch: known-plaintext-attack) stehen Paare von Klartext und verschlusseltem Textzur Verfugung. Der Versuch zur Bestimmung des verwendetenSchlussels liegt in der Entwicklung eines Algorithmus, welcheralle verschlusselten Texte in den richtigen Klartext umwandelt(vgl. [8][S. 364]).

Ist der Zugang zu einem asymetrischen Verschlusselungs-verfahren vorhanden, kann durch einen sogenannten chosen-ciphertext-Angriff versucht werden, den Schlussel zu ermitteln.Dabei ist eine ausgewahlte verschlusselte Nachricht vorhanden.Werden nun Texte mit dem selben Verfahren verschlusselt undmit dem ausgewahltem verschlusselten Text verglichen, kannder ursprungliche Schlussel ermittelt werden (vgl. [8][S. 364-365]).

G. ungesicherter Schlusselaustausch

Ein sicherer Schlusselaustausch ist Grundvoraussetzungfur eine sicherer Kommunikation zwischen Sender undEmpfanger. Sollte bei einem unsicheren Schlusselaustauschder Schlussel von einem dritten mit gelesen werden, sindalle nachfolgend ubertragenen Nachrichten gefahrdet. Diesekonnen dadurch mitgeschnitten, entschlusselt und manipuliertwerden (vgl. [8][S. 429]).

H. Einsatz von Rolling-Codes

Durch den Einsatz von Rolling Codes werden Replay-Angriffe verhindert. Dazu besitzt der Sender sowie derEmpfanger jeweils einen vorab gespeicherten geheimenSchlussel. Dieser wird zur Verschlusselung des Rolling Codesund der zu ubertragenen Nachricht verwendet. Bei erfolgrei-cher Ubertragung zahlt der Sender einen Counter-Wert nachoben, um einen neuen Rolling Code zu erzeugen. Dies ge-schieht mittels dem KeeLoq Algorithmus. Der neu erzeug-te Rolling Code wird beim nachsten senden genutzt. Der

Empfanger validiert den empfangenen des Rolling Code, solltedieser nicht ubereinstimmen wird die Nachricht verworfen(vgl.[7][S. 65-69]).

IV. BETRACHTUNG DER UBERTRAGUNGSPROTOKOLLE

Im folgendem Kapitel werden die drei zuvor ausgewahltenUbertragungstechnologien ZigBee, Z-Wave und EnOcean furdie Smart Home-Vernetzung naher betrachtet. Es wird auf dieHerkunft der Technologien, den Aufbau des Protokoll-Stackssowie auf die Standards, auf denen diese basieren eingegangen.

A. ZigBee

ZigBee ist eine Funktechnologie, die im Bereich Smart Ho-me eingesetzt wird um ein WSN (Mesh-Netzwerk) aufzubau-en und somit diverse, meist batteriebetriebene Smart Home-Komponenten wie Sensoren, Aktoren und Gateways, untereinander zu verbinden. Abbildung 1 zeigt einen Uberblickuber die Technologie und den Vergleich mit anderen ahnlichenTechnologien.

Die ZigBee-Technologie wurde von der ZigBee-Allianzentwickelt und erweitert den Standard IEEE 802.15.4 [15] dervon dem US Institute of Electrical and Electronics Engineers(IEEE), der im Jahre 2003 ratifiziert wurde. Die OSI-Layer 1und 2 werden vom IEEE-Standard definiert, die Layer 3 und4 werden vom ZigBee-Standard definiert. Die hoheren Layerkonnen sowohl vom ZigBee-Standard als auch von einemEntwickler umgesetzt werden (siehe Abbildung 3).

Die Allianz wurde im Jahre 2002 von den namenhaftenElektrogerateherstellern Phillips, Motorola, Honeywell, Inven-sys and Mitsubishi gegrundet (vgl. [16][S. 6]). Inzwischenbesitzt diese Allianz ca. 450 Partner1.

ZigBee ist eine Technologie, die im Vergleich zu vielenanderen Wireless-Ubertragungstechnologien auf mehreren, un-terschiedlichen ISM-Frequenzbandern operieren kann. Dazuzahlen die Frequenzbander um 433MHz und 868MHz inEuropa, 915MHz in den USA und 2, 4GHz weltweit. Gerate,die auf diesen Frequenzbandern senden, werden allgemeinauch als Short Range Devices (SRD) bezeichnet.

Diese Frequenzbander sind jedoch nicht alleine fur dieZigBee-Technologie reserviert. Auf den Frequenzbandern um433MHz, 868MHz und 915MHz arbeiten fur gewohnlichGerate zur Kurzstreckenkommunikation, wie Funk-Kopfhorer,Funk-Thermometer und Funk-Steckdosen, aber auch Funk-Alarmanalgen und Funk-Wetterstationen. Im Frequenzband um2, 4GHz sind Microwellenherde, WLAN- und Bluetoothgeratezu finden.

Im weiteren Verlauf der Arbeit wird jedoch ausschließlichdas europaische Frequenzband um 868MHz betrachtet, umden Umfang der Arbeit einen Rahmen zu setzten.

B. Z-Wave

Die Funktechnologie Z-Wave findet hauptsachlich in derGebaudeautomation seine Verwendung. Ebenfalls wie ZigBeebilden die Z-Wave Komponeten ein WSN. Z-Wave basiert

1http://www.zigbee.org/2http://m.eet.com/media/1055711/chipcon-fig1.jpg

104

Abbildung 3. ZigBee-Protokollstack2

auf dem 2012 veroffentlichten Standard G.9959 [17] der in-ternationalen Telekommunikationsunion (ITU-T). Dieser Stan-dard legt den sogenannten Physical-Layer (PHY-Layer) sowieden Medium-access-Layer (MAC-Layer) fest. Die hoherenProtokoll-Layer werden vom Z-Wave-Standard definiert, wel-cher proprietar ist.

Die Funktechnologie selbst operiert in Europa mit ei-ner Frequenz von 868, 40MHz und 868, 42MHz. In denUSA nutzt Z-Wave die Frequenz von 908, 40MHz und908, 42MHz. Dabei darf ein SRD in Europa, welches Z-Waveals Funkprotokoll verwendet, maximal 25mW an Sendeleis-tung verwenden. Dadurch werden im Freifeld eine Reichweitebis zu 200Meter erreicht. In Gebauden kann typischerweiseeine Distanz von 30Metern uberwunden werden. Die Da-tenrate, die von Z-Wave-Komponenten erreicht werden kann,liegt bei 9600Bit/s, 40kBit/s oder bei 100kBit/s. Dieunterschiedlichen Datenraten kommen durch die unterschied-lich verwendeten Kodierungen zustande. [18][S. 149-150] Diephysikalische Schicht beschreibt genau solch eine Nutzungder Frequenz und wie die Bits in Sendeimpulse, fur dieUbertragung, kodiert werden mussen.

Wie ein Datenpaket des Z-Wave Protokolls aufgebautist, wird mittels des MAC-Layers festgelegt. Ein Datenpaketenthalt neben weiteren Datenfeldern eine Home-ID, welche dasNetzwerk identifiziert, eine Gerate-ID des Senders und einedes Empfangers (vgl. [19]).

Das Ubertragungsprotokoll verwendet fur die Vertraulich-keit der Nachrichten den AES-OFB-Modus (Output FeedbackMode). Die Datenintegritat wird durch das AES-CBC-MAC-Verfahren geschutzt. Zum Schutz vor einem MitM-Angriffist ein CLASS SECURITY Befehl implementiert. Dieser Be-fehl tauscht Sicherheitsinformationen zwischen den Geratenaus und kann den MAC (Message Authentication Code) derverschlusselten Nachrichten validieren. Da keine Vertraulich-keitsprufung des temporaren Schlussels implementiert ist, kannein Angreifer wahrend des Anlern-Prozesses von Geraten,den Netzwerkschlussel herausfinden, da dabei der Schlusseluber das Netzwerk ubertragen wird. Um einem Replay-AngriffStand zu halten, nutzt ein Secure-Device sowie der Controllersogenannte Nounces. Dieser wird vom Controller auf Kor-rektheit uberpruft. Ist dieser Korrekt wird die Ubertragung

fortgesetzt. Sollte eine Nachricht wiederholt, zu einem spaterenZeitpunkt, abgesetzt werden, ist der Nounce nicht mehr gultigund das Paket wird verworfen (vgl. [20]).

Abbildung 4. Z-Wave-Layers - Quelle: [15]

C. EnOcean

Das proprietare Funkverfahren der deutschen Firma EnO-cean produziert Sendemodule, welche autark bezuglich ihrerbenotigten Energie arbeiten. Dabei nutzt EnOcean das ISM-Band auf 868, 3MHz bei einer maximalen Sendeleistung von10mW (vgl. [18][S. 244]). Die Technologie basiert auf demISO/IEC 14543-3-10:2012 [21].

Die Energie erhalt ein solches Sendemodul, durch einensogenannten Energy Harvester welcher eine Energie, durcheinen im Umfeld durchlaufener Prozess, in elektrische Energieumwandelt. Ein solcher Prozess kann bspw. elektromagneti-sche Strahlung, Temperaturunterschiede oder mechanische Be-wegung sein. Ein Beispiel fur eine solche Energieumwandlungbzw. -nutzung ist das Drucken eines Lichtschalters. Dabeiwandelt der Engery Harvester die Energie, die beim betatigendes Schalters erzeugt wird in elektrische Energie um. Durchdie so erzeugte Energie kann das Smart-Device anschließendbetrieben und eine Nachricht abgesetzt werden (vgl. [22]).

Da durch das Energy-Harvesting nur eine begrenzte Mengean Energie gewonnen werden kann, ist eine deutlich geringerDatenrate, im Vergleich zu ZigBee und Z-Wave moglich (sieheAbbildung 1). Diese betragt maximal 125KBit/s, wobeijede versendete Nachricht maximal 14Byte groß ist. Da keinKollisionsschutz und Synchronisationsschutz implementiert ist,wird jede Nachricht dreimal gesendet. Die Wartezeit zwischenden Nachrichten wird dabei zufallig generiert. EnOcean bietetauch Transreciever an welche eine bidirektionale Kommuni-kation ermoglichen, jedoch nur in Verbindung eines hoherenEnergiebedarfs. Dieser Energiebedarf kann nur durch einezusatzliche Stromquelle gedeckt werden (vgl. [18][S. 245]).EnOcean baut auf dem ISO/IEC-Standard 14543-3-10 auf.Dieser Standard stellt die unteren drei Layer des ISO/OSI-Modells bereit, wohingegen EnOCean die hoher liegendenLayer Definiert (vgl. Abbildung 5).

V. VEROFFENTLICHTE ANGRIFFE UNDSCHWACHSTELLEN

Im folgenden werden bereits bekannte und veroffentlichteAngriffe auf Z-Wave, ZigBee und Enocean erlautert. Dies soll

3http://www.epdtonthenet.net/global/showimage/Article/49305/

105

Abbildung 5. EnOcean-Layers3

zeigen, welche Gefahren durch falsche oder unaufmerksameImplementierung sowie logische Fehler in Designentscheidun-gen bestehen. Bei der Hardwarebetrachtung wurde schnellersichtlich, dass trotz Einsatz von Krypto-Algorithmen oftmalsveraltete und als unsicher geltende Protokolle zum Einsatzkommen.

A. EnOcean

Da EnOcean ein proprietares Verfahren ist, gibt es keineoffentlichen Spezifikationen, welche die Codierung und Deco-dierung oder die Verschlusselungsverfahren offen legen.

Ein moglicher Angriff besteht darin, das EnOcean-DevKit4,welches offiziell zum Verkauf angeboten wird, zu nutzen. Die-ses kann Nachrichten codieren und decodieren und somit fureinen Angriff missbraucht werden. Da seit 2012 Sicherheits-maßnahmen implementiert wurden, kann ein Angriff mittelsdem EnOcean-DevKit nur bei alteren EnOcean-Modulen oderbei nicht verschlusseltem Datenverkehr eingesetzt werden (vgl.[23]).

B. ZigBee

Der Standard IEEE 802.15.4, welchen ZigBee nutzt, enthalteinige Schwachstellen. Diese konnen dem zufolge in ZigBeeNetzwerken ausgenutzt werden. Kann ein Angreifer beispiels-weise zwei Chiphretexte mitschneiden die mit dem selben Wertund dem selben Schlussel verschlusselt wurden, ist es fur ihnmoglich, diese mittels der XOR-Funktion wiederherzustellen(vgl. [24][S. 2]).

Des weiteren kann eine einfache DoS-Attacke erreichtwerden, indem eine Nachricht mit einem falschen Schlusselverschlusselt wird und dabei der Frame-Counter und Key-Counter auf das Maximum gesetzt werden. Der MAC-Layersetzt dabei die Counter selbst auf das Maximum und allefolgende Pakete werden verworfen, da es fur den zu Empfan-genden Knoten wie eine Replay Attacke aussieht. Diese Paketehaben keine Integritatsmechanismen und sind somit leicht zufalschen. (vgl. [24][S. 3]).

Auf Grund der Kenntnis des Netzwerkschlussel konnenweitere Schlussel, beispielsweise der Link-Key, aus demNetzwerk abgeleitet werden. Die Sicherheit des Link-Key-Austauschs hangt von der vorhergehenden Integritat des Netz-werkschlussels ab welcher in Klartext ubertragen wurde. Auchwenn dies eine Bedrohung darstellt, nutzen viele ZigBeeNetzwerke diesen Mechanismus des Schlusselaustauschs, da

4https://www.enocean.com/de/enocean module/edk-350/

er der einzige vernunftige verfugbare Mechanismus fur einedynamische oder rotierende Schlusselverteilung ist.

C. Z-Wave

Fouladi und Ghanoun analysierten die Sicherheit des Z-Wave Protokolls. Dabei entdeckten Sie eine Schwachstellein der Implementierung der Firmeware, von Turschlossern.Aufgrund ihrer Entdeckung entwickelten Sie ein Exchange-Modul fur das Penetration-Testing-Tool Z-Force. Diesesermoglicht mit einem eigens gewahlten Netzwerkschlussel undder Ausnutzung der Schwachstelle, den Netzwerkschlusseldes Turschlosses zuruckzusetzen. Nutzt ein Angreifer dieseSchwachstelle aus, kann dieser unautorisierte Befehle somitauch das offnen der Ture, an das Turschloss absetzten.

Die Schwachstelle ist eine nicht korrekte Implementationeiner Uberprufung des Status des aktuellen Shared Key. DerAblauf des Angriffs startet mit dem anstoßen eines Schlusse-laustausch, dabei wird ein bestimmtes Paket an das Turschlossgesendet. Dieses Paket enthalt den Payload der Key-Exchange-Start-Nachricht und der Gerate-ID des Home-Controllers. Nunsollte das Turschloss den aktuellen Network-Key uberprufen,statt dessen wird der vor implementierte Schlussel (16 Byte anNullen) geladen. Ein Angreifer kann so einen eigenen Netz-werkschlussel in diesem Gerat setzten und somit unautorisierteBefehle absenden (vgl. [25]).

Die Z-Wave Allianz hat einen Modus implementiert wel-cher das Anlernen von Geraten nur bei einer geringen Leistungerlaubt. Dies soll die Chance verringern, dass ein AngreiferErfolg beim Mitschneiden eines Schlusselaustauschs hat. Diesist allerdings nicht sehr Praktikabel, da ein Anlernen derGerate im Abstand zwischen Controller und anzulernendemGerat maximal einen Meter betragen darf. Somit ist dieskeine wirkliche Sicherheitslosung. Nutzer von Z-Wave Geratenwerden diesen Modus durch eine solche Einschrankung nichtnutzen (vgl. [20]).

VI. VERGLEICH DER DREI TECHNOLOGIEN

EnOcean unterstutzt standardmaßig keine verschlusselteUbertragung. Nur wenige (meist netzgebundene) Sensorenund Aktoren unterstutzen uberhaupt eine Verschlusselung. DerEinsatz einer Verschlusselung benotigt viel Rechenleistungund lasst sich daher nicht mit dem Grundkonzept des EnergyHarvestings vereinbaren. Jedoch konnte sich dies nach Moore’sLaw [27] in naher Zukunft andern.

Auf das proprietare Protokoll von Z-Wave ist zur Zeitkein Angriff bekannt und gilt momentan als sicher. VonHaus aus wird ein zeitgemaßer Verschlusselungsalgorithmus(AES 128 Bit im OFB-Modus) zur sicheren Datenubertragungsowie Prufsummen (AES 128 Bit im CBC-MAC-Modus) zurSicherstellung der Datenintegritat genutzt. Jedoch existieren zuProduktumsetzungen einzelner Hersteller Angriffe bspw. aufdie Verwaltung der Kryptoschlussel, wie Fouladi und Ghanounin ihrer Veroffentlichung [25] gezeigt haben.

Das ZigBee-Protokoll verwendet, wie auch Z-Wave, einenzeitgemaßen Verschlusselungsalgorithmus (AES 128 Bit imOFB-Modus) zur sicheren Datenubertragung sowie Prufinfor-mationen (AES im CBC-MAC-Modus) zur Sicherstellung derDatenintegritat.

106

Durch die Analyse und Gegenuberstellung zeigt sich,dass fur die Kommunikation der Gerate von Smart Home-Netzwerken, das Z-Wave Protokoll hinsichtlich seiner Sicher-heitsaspekte am ehesten in Frage kommt. Trotzdessen ist zubeachten, dass bisher im Vergleich zu ZigBee nur eine geringeAuswahl an Smart Devices auf dem Markt existiert. So kannes sein, dass fur bestimmte Anwendungsgebiete noch keineZ-Wave-Komponenten zur Verfugung stehen.

VII. FAZIT

In dieser Arbeit wurden die drei gangigsten WPAN- bzw.WSN-Protokolle am deutschen Markt bezuglich ihrer Sicher-heit betrachtet. Im Smart Home-Bereich existieren jedochuber die protokollseitigen Angriffsvektoren hinaus noch einigeweitere Angriffsvektoren, die keinesfalls außer Acht gelassenwerden sollten. Dazu zahlen zum einen die Hardware inklusiveFirmware, das Gateway, das die Schnittstelle an das LANbzw. WAN bereitstellt, sowie der Schlusselaustausch zwischenWSN-Knoten und dem Gateway sowie dem Gateway undKomponenten im LAN/WAN.

Die Ubertragung von Sensor- und Steuerdaten uber einWSN, sollte wie bereits in der LAN-Vernetzung eine um-fassende Transportverschlusselung der zu ubertragenden Da-ten eingefuhrt werden. Da hierzu Protokolle wie das ausLAN- und WAN-Netzen bekannte Secure Sockets Layer (SSL)bzw. Transport Layer Security (TLS) fur viele Embedded-Prozessoren zu schwergewichtig sind und die eingesetztenProzessoren dies oft nicht unterstutzen, kann hierzu bspw.auf leichtgewichtigere Opensource-Alternativen wie MbedTLSoder TinyTLS zuruckgegriffen werden. Generell sollte nachaktuellem Stand der Technik nur noch auf TLS Version 1.2gesetzt werden. Fruhere Versionen von TLS sowie SSL geltenals gebrochen und sollten moglichst nicht mehr eingesetztwerden. Auch der Verschlusselungsalgorithmen Rivest Cipher4 (RC4 oder auch ARC4), welcher sich in der praktischenBetrachtung der Z-Wave-Komponenten fand, gilt offiziell alsgebrochen. Der Einsatz dieses Algorithmus wurde durch dasRFC 7465 [26] im Jahre 2014 bereits verboten.

Daruber hinaus spielt nicht nur das eingesetzte Verfahreneine große Rolle, sondern auch die Tatsache, dass diesesuber langere Zeit hinweg auch durch Updates auf dem SmartDevice austauschbar bleiben muss, um eine lange Nutzungszeitzu gewahrleisten. vor dem Einsatz von Technologien undderen Umsetzungen in Produkten immer gepruft werden, aufwelche Art und Weise die Kryptoschlussel im WSN ausge-tauscht werden. Ein sicherer Schlusselaustausch sollte hierbspw. durch den Diffie–Hellman Key Exchange-Algorithmusgewahrleistet werden. Wobei dieser nutzlos wird, sobald einSchlusselaustausch vom Angreifer getriggert und mitgelesenwerden kann.

Bei der sicherheitstechnischen Beachtung von Protokollenund Technologien hat sich in der Vergangenheit gezeigt, dasseine Veroffentlichung der Technologie, das Auffinden undBeheben von Fehlern und Schwachstellen unterstutzt. Durchdiesen Vorgang kann jedermann Einsicht auf die Technolo-gie nehmen und diese selbst auf Fehler und Schwachstellenuberprufen. Bei einer Entwicklung proprietarer Technologienfehlt diese Komponente des offentlichen Reviews, so konnenSicherheitsschwachstellen die in Produkten enthalten sind, aber

ubersehen wurden, zu schweren Sicherheitslucken der Tech-nologie bzw. eines Produktes fuhren. Deshalb sollten auch dieProtokolle fur WSN veroffentlicht und offentlich gereviewedwerden. Bei ZigBee ist dies heute schon der Fall, wodurchsichergestellt wird, dass Fehler und Schwachstellen gefundenund zuverlassig behoben werden.

Das keine weiteren Angriffe und Schwachstellen zu denProtokollen ZigBee und Z-Wave bekannt sind bedeutet kei-nesfalls, dass diese Produkte als sicher gelten. Schwachstellenkonnten von Angreifern absichtlich verheimlicht werden undziehen es daher vor diese nicht zu veroffentlichen, da in Folgeeiner Veroffentlichung fur den Angreifer ein Schließung derSchwachstelle droht.

VIII. AUSBLICK

Nach einer Studie von Cisco Systems Inc. werden heute injeder Sekunde 127 neue Dinge mit dem Internet verbunden. ImJahre 2020 werden es insgesamt mehr als 50 Milliarden Dingesein (vgl. [28]). Viele von diesen durften in nachster ZukunftKomponenten eine Smart Homes, eines Smart Buildings oderKomponenten aus dem Bereich der Industrie 4.0 sein, da derMarkt in diesen Bereichen boomt und auch in Zukunft nochweiter wachst (vgl. [29]).

Aufgrund von ”Moores Law“ (nach Dr. Gordon EarleMoore) [27] kann davon ausgegangen werden, dass die Anzahlder Gerate die in Zukunft mit dem Internet verbunden bzw.miteinander vernetzt werden immens ansteigen wird. Mooreschreibt in seiner Veroffentlichung, dass die Integration derComputer Chips zunimmt und deren Leistung bezogen aufdie Flache uberproportional ansteigt (vgl. [27]). Im Bezug aufSmart Home-Konzepte bedeutet dies, dass deren Hardwaredementsprechend ebenfalls immer leistungsfahiger wird, zu-gleich aber weniger weniger Raum und somit auch Energiebenotigt. Dadurch lasst sich der Ausblick wagen, dass inZukunft immer mehr Gerate miteinander vernetzt werden, dieunter sich uber gesicherte Verbindungen kommunizieren.

Nicht nur die Anbindung all dieser Komponenten stellt furUnternehmen und unsere Gesellschaft eine Herausforderungdar, sondern besonders dessen sichere Vernetzung. So musssichergestellt werden, dass die einzelnen Komponenten IhreDaten nicht unverschlusselt uber ein (unsicheres) Netzwerkubertragen werden.

Daher ist es fur die WSN-Knoten in Zukunft wichtig,dass wie bereits gewohnliche LAN-Komponenten heutzutage,als sichere Hardware verfugbar sind und dies zum Stan-dard fur WSN-Komponenten wird. Dazu zahlt zum einendie Einfuhrung eines Trusted Platform Module (TPM) sowiedarauf aufbauend einem Secure Boot, damit sichergestelltwerden kann, dass die Systemsoftware auf den Geraten selbstnicht kompromittiert wurde. Denn dies bildet die Grundlagefur eine sichere Netzinfrastruktur.

107

LITERATUR

[1] Linux Magazin, “Deutsche furchten sich vor iot,” Linux Magazin, no.10/2015, p. 13, 2015. [Online]. Available: http://www.linux-magazin.de/NEWS/Deutsche-fuerchten-sich-vor-IoT

[2] Hartmut Strese, Uwe Seidel, Thorsten Knape, Alfons Botthof,“Smart home in deutschland: Untersuchung im rahmen derwissenschaftlichen begleitung zum programm next generationmedia (ngm) des bundesministeriums fur wirtschaft undtechnologie,” http://www.iit-berlin.de/, 2010. [Online]. Available:http://www.iit-berlin.de/de/publikationen/smart-home-in-deutschland

[3] “Funkanwendungen auf den ism-bandern,” Ph.D. dissertation,30.04.2015. [Online]. Available: http://emf3.bundesnetzagentur.de/pdf/ISM-BNetzA.pdf

[4] F. S. Armin Anders, “Entscheidungshilfe funkstandards:Welches funksystem wann einsetzen?” 2007. [Online].Available: https://www.enocean.com/fileadmin/redaktion/pdf/articles/perpetuum funkstandards de.pdf

[5] S.-H. Yang, Wireless Sensor Networks: Principles, Design andApplications, ser. Signals and Communication Technology. London:Springer London, 2014. [Online]. Available: http://dx.doi.org/10.1007/978-1-4471-5505-8

[6] C. Meinel and H. Sack, Eds., Internetworking: Technische Grundlagenund Anwendungen, ser. X.media.press. Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg, 2012.

[7] L. Breveglieri, Ed., 2009 Workshop on Fault Diagnosis and Tolerancein Cryptography: (FDTC 2009) ; Lusanne, Switzerland, 6 September2009. Piscataway, NJ: IEEE, 2009.

[8] C. Eckert, IT-Sicherheit: Konzepte - Verfahren - Protokolle, 7th ed.,ser. Informatik 10-2012. Munchen: Oldenbourg, 2012. [Online].Available: http://www.oldenbourg-link.com/isbn/9783486706871

[9] J. F. Kurose and K. W. Ross, Computernetzwerke: Der Top-Down-Ansatz, 5th ed., ser. Informatik - Pearson Studium. Munchen: PearsonStudium, 2012.

[10] S. C. Satapathy, B. N. Biswal, S. K. Udgata, and J. K. Mandal,Eds., Proceedings of the 3rd International Conference on Frontiers ofIntelligent Computing: Theory and Applications (FICTA) 2014: Volume1, ser. Advances in Intelligent Systems and Computing. Cham, s.l.:Springer International Publishing, 2015, vol. 327. [Online]. Available:http://dx.doi.org/10.1007/978-3-319-11933-5

[11] A. Herrero, B. Baruque, F. Klett, A. Abraham, V. Snasel, A. C.Carvalho, P. G. Bringas, I. Zelinka, H. Quintian, and E. Corchado,Eds., International Joint Conference SOCO’13-CISIS’13-ICEUTE’13:Salamanca, Spain, September 11th-13th, 2013 Proceedings, ser.Advances in Intelligent Systems and Computing. Cham, s.l.:Springer International Publishing, 2014, vol. 239. [Online]. Available:http://dx.doi.org/10.1007/978-3-319-01854-6

[12] L. Dong and K. Chen, Cryptographic Protocol: SecurityAnalysis Based on Trusted Freshness. Berlin, Heidelberg:Springer Berlin Heidelberg, 2012. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-24073-7

[13] M. Rohr, Ed., Sicherheit von Webanwendungen in der Praxis: Wie sichUnternehmen schutzen konnen - Hintergrunde, Maßnahmen, Prufver-fahren und Prozesse, ser. Edition <kes>. Wiesbaden: Springer Vieweg,2015.

[14] S. Wendzel, Ed., Tunnel und verdeckte Kanale im Netz: Grundlagen.s.l.: Springer Fachmedien Wiesbaden, 2012.

[15] J. A. Gutierrez, E. H. Callaway, and R. L. Barrett, Low-rate wireless per-sonal area networks ... enabling wireless sensors with IEEE 802.15.4,ser. IEEE standards wireless networks series. New York, NY: Instituteof Electrical and Electronics Engineers, 2004.

[16] Florian Eichelberger, “Using software defined ra-dio to attack ”smarthome” systems,” 2015. [Onli-ne]. Available: https://www.sans.org/reading-room/whitepapers/threats/software-defined-radio-attack-smart-home-systems-35922

[17] ITU-T, “Short range narrow-band digital radiocommunicationtransceivers – phy, mac, sar and llc layer specifications,” 2015-01-13. [Online]. Available: http://handle.itu.int/11.1002/1000/12399

[18] R. Gessler and T. Krause, Wireless-Netzwerke fur den Nahbereich:Eingebettete Funksysteme: Vergleich von standardisierten und

proprietaren Verfahren, 2nd ed. Wiesbaden: Springer Vieweg, 2015.[Online]. Available: http://dx.doi.org/10.1007/978-3-8348-2075-4

[19] C. Patz, Z-Wave: Die Funktechnologie fur das Smart Home. Norders-tedt: BoD - Books on Demand, 2014.

[20] J. Wright and J. Cache, Hacking exposed wireless: Wireless securitysecrets & solutions, 3rd ed. New York, NY: McGraw-Hill, 2015.

[21] International Organization for Standardization, “Information technology– home electronic systems (hes) – part 3-10: Wireless short-packet(wsp) protocol optimized for energy harvesting – architecture and lowerlayer protocols,” Geneva, Switzerland, 2012-03-01. [Online]. Available:http://www.iso.org/iso/catalogue detail.htm?csnumber=59865

[22] B. S., R. J., M. A., N. N. F., and L. K.-D., “Energy harvesting fordistributed microsystems – the link between environmental performanceand availability of power supply,” in Design for Innovative Value To-wards a Sustainable Society, ser. SpringerLink Bucher, M. Matsumoto,Y. Umeda, K. Masui, and S. Fukushige, Eds. Dordrecht: SpringerNetherlands, 2012, pp. 183–190.

[23] Ina Trautmann, “Opus greennet: Planungsinforma-tionen,” http://www.opus-schalter.de/service/fuer-den-fachmann/fuer-planer-architekten. [Online]. Available: http://www.opus-schalter.de/sites/default/files/download/2012 04 03 v1 0 planermappe.pdf

[24] Lindsey N. Whitehurst, Todd R. Andel, and J. Todd McDonald,“Exploring security in zigbee networks: 2014 9th cyber and informationsecurity research conference,” Paper zur Cyber and Information SecurityResearch Conference, University of South Alabama, 2014. [Online].Available: https://dl.acm.org/citation.cfm?id=2602087.2602090

[25] Behrang Fouladi and Sahand Ghanoun, “Security evalua-tion of the z-wave wireless protocol,” Veroffentlichung,SensePost UK Ltd., London, UK. [Online]. Availa-ble: https://www.sensepost.com/cms/resources/conferences/2013/bhzwave/Security%20Evaluation%20of%20Z-Wave WP.pdf

[26] A. Popov, Prohibiting RC4 Cipher Suites. RFC Editor, 2015.[27] Dr. Gordon E. Moore, “Cramming more components onto integrated

circuits: With unit cost falling as the number of components per circuitrises, by 1975 economics may dictate squeezing as many as 65,000components on a single silicon chip,” Electronics, no. Volume 38, Nr.8, 1965. [Online]. Available: http://www.monolithic3d.com/uploads/6/0/5/5/6055488/gordon moore 1965 article.pdf

[28] Michael Kranawetter, “Internet of things (iot): Die dinge sindda - und die sicherheit?” <kes>, vol. 2015, no. 5, pp. 54–60,2015. [Online]. Available: https://www.kes.info/nc/archiv/heft-archiv/jahrgang-2015/ausgabe-20155/

[29] Statista, “Prognose zum weltweiten umsatz mit vernetzten geraten biszum jahr 2020 (in milliarden us-dollar),” Statista, 2016. [Online].Available: http://de.statista.com/statistik/daten/studie/295168/umfrage/umsatzprognose-auf-dem-weltmarkt-fuer-vernetzte-geraete/

108

Internet of Things Elmar Cochlovius und Christoph Reich

109

“Can I offer you some water?” – Developing Behaviors for the Pepper Humanoid Robot in an

Ambient Assisted Living Environment Judith Jakob*,**, Elmar Cochlovius*

*Faculty of Computer Science, Hochschule Furtwangen University, Furtwangen, Germany **Doctoral School of Applied Informatics and Applied Mathematics, Óbuda University, Budapest, Hungary

{Judith.Jakob, Elmar.Cochlovius}@hs-furtwangen.de

Abstract—An ageing population causes various social and health care related problems, one being the risk of dehydration for the elderly living alone. The field of Ambient Assisted Living addresses those problems and offers assistive technologies based on a digital environment. We explore the capabilities of the Pepper humanoid robot and the feasibility to improve living conditions of elderly persons in the context of an Ambient Assistant Living setup. Specifically we have developed the “Water Buddy” behavioral software controlling the Pepper humanoid robot to actively approach clients and offer drinking water in order to proactively reduce the risk of dehydration. In this paper, we present our approach, analyze the programming paradigms applied for implementing this robot behavior, and assess current problems and potentials of the Pepper humanoid robot system to improve the “Water Buddy” and to be used in future use cases of Ambient Assisted Living.

Keywords—Ambient Assisted Living, Humanoid Robots, Dehydration, Integrated Development Environment

I. INTRODUCTION According to a United Nations study, by 2050 more than

20 % of the world population will be 60 years and older [1]. As pointed out in [2], ageing not only leads to many challenges for the elderly, such as age related diseases and limitations in agility and sensory perception, but also for society in general, which e. g. is confronted with increasing health care budgets, shortage of nursing staff and dependency of the elderly.

In order to support elderly clients and other people with special needs, researchers are exploring different assistive technology devices based on a digital environment. Those technologies are summarized in the term “Ambient Assisted Living (AAL)”, whose goal is to support and assist people with special needs in order to ensure their independency as long as possible [2].

In recent years, humanoid robots became increasingly sophisticated and at the same time more affordable. This encourages scientists and research groups to work on a variety of robotic subjects specifically related to AAL.

One problem, which elderly people living alone often face, is the risk of dehydration. Our “Water Buddy” project addresses this problem with the help of the humanoid robot Pepper who regularly approaches the user, motivates her to drink and actively brings a regular water bottle to the client.

Additionally, the “Water Buddy” offers assistance to call for help if required.

In the following, we first discuss fundamentals concerning AAL, especially robotic-based applications in the context of AAL, and then give an overview of the humanoid robot Pepper and its Integrated Development Environment (IDE). Chapter III focuses on the design and implementation of the “Water Buddy” behavior for Pepper. Before chapter V concludes the paper, we give an outline of our future work.

II. FUNDAMENTALS In this chapter, we first define the term Ambient Assisted

Living, before looking into the different AAL fields that are of interest for the scope of our research: robotics in AAL and prevention of dehydration. Afterwards, we describe the Pepper humanoid robot and its programming model.

A. Ambient Assisted Living (AAL) AAL focuses on technical systems which assist and support

people with special needs, e. g. elderly people, in their daily life in order to ensure and maintain their autonomy as well as increase the safety in their home environment [3].

According to [2], which describes the state of the art of AAL tools for the elderly, assistive robots are divided into three categories depending on the degree of assistance: Robots assisting with Activities of Daily Living (ADL), robots assisting with Instrumental Activities of Daily Living (IADL), and robots assisting with Enhanced Activities of Daily Living (EADL).

In the category of ADL, which our work is part of, the main objective is to reduce the client’s need to move by fetching various objects or by assisting daily routines such as feeding or clothing. Examples are Dusty robot, who helps retrieving objects dropped on the floor [4], Fraunhofer IPA’s Care-O-bot, who can move safely among humans and detect and grasp household objects as well as exchange them with the user [5], and RIBA robot, who can transfer patients, e. g. from the bed to the wheelchair [6].

In a representative study, the fluid intakes of 1372 independently living people in Germany aged 65 and above without any serious health problems were examined [7]. Although the participants on average achieved the required

111

minimum amounts of fluid intake, it was shown that the risk of dehydration increases with age.

In [8], Zimmermann et al. introduce the smart cup holder TrinkTracker, which can measure the amount of a consumed liquid with an accuracy of 2 ml and send the data to a monitoring software. The system can be used by individuals at home, but also in nursing homes. In a user-oriented study carried out in an inpatient nursing care facility, Zimmermann et al. show that the use of TrinkTracker can verifiably result in temporarily increased hydration. Other systems addressing the problem of dehydration of the elderly are for example Obli1 and several wearables such as Aquaband2.

These systems clearly are beneficial in context of AAL scenarios. However, they are also limited since they cannot actively present the fluid in front of the client, thus requiring the client to move and fetch the fluid by herself. This often may exceed the capabilities of the client. Our project explores possibilities of a robot to resolve these limitations.

B. Pepper Technical Overview Fig. 1 pictures the humanoid robot Pepper produced by the

Japanese company SoftBank Robotics and that we use in the “Water Buddy” project. The specifications presented here can be found in the documentation3.

Pepper has a size of 1.2 m and weighs about 28 kg. Its 20 motors, located at head, shoulders, elbows, wrists, fingers, hip, knee and wheels, ensure Pepper’s mobility. Using its hands, it can carry objects up to a weight of 500 g.

Pepper’s head contains two loudspeakers located in the ears, four directional microphones, a 3D sensor behind the eyes, two HD cameras on forehead and mouth, and a three-part tactile sensor. Further tactile sensors are located on the

1 http://www.obli.info/

2 http://aquaband.de/ 3 http://doc.aldebaran.com/2-4/family/pepper_technical/index_pep.html

backsides of the hands and on the foot base (three bumpers). In addition, the foot base consists of two sonar sensors, two infra-red sensors, six laser scanners, and three omniwheels that allow Pepper to move freely on flat ground at 3 km/h by 360 degrees. For orientation and stabilization purposes, Pepper has a 3-axis accelerometer and a 3-axis gyrometer.

The motherboard, located inside the head, consists of a quad core Atom E3845 processor with 1.91 GHz, 4 GB RAM and 8 GB flash memory. The flash memory is not available for users, but used for the NAOqi OS, the robot’s operating system. Pepper provides Ethernet and Wifi for connectivity. The capacitive touch screen is a 10.1 inch LG CNS tablet.

C. Pepper IDE The Pepper humanoid robot is controlled by a set of

interconnected software modules called behaviors. An Integrated Development Environment (IDE) is used to implement behaviors based on a graphical modelling language4. Behavioral primitives are represented by boxes with input and output pads. Several primitives can be interconnected with each other by means of flow lines. The intuitive nature of this graphical IDE is one of the intriguing aspects of the Pepper software environment, and it provides a smooth learning curve, in particular in an academic setting.

The graphical modelling language is based on an extended flow chart metaphor. Flow charts are commonly used to describe and specify algorithms or workflows. In its most basic variant they are composed of two kinds of boxes, rectangles and diamonds, connected by arrows.

Rounded boxes, called terminals, indicate starting and end points of the algorithm. Boxes have one or more incoming arrows. Rectangles have one outgoing arrow. Diamonds provide two outgoing arrows.

As indicated in Fig. 2, the algorithm starts at T1, then executes a procedure P1 (“action”). The next step is a decision (C?), the result depending on a condition variable C. In case the condition holds true, procedure P2 is executed, otherwise procedure P3. Both paths lead to terminal T2, thus finishing the algorithm.

Using the graphical modelling language, extended flow charts are used to express behavioral aspects of the Pepper control software. Unlike in flow charts, these diagrams are read from left to right, see Fig. 3. When the start terminal gets triggered, the flow line will start the “Move-To” behavior box by means of one of its input pads. This box implements a parameterized movement of the Pepper robot. When Pepper finally has reached its destination, the “Move-To” behavior stops and sends a trigger to the end terminal, thus terminating this behavior model.

Boxes are used to define behavior primitives. Due to the potentially complex outcome of a behavior, boxes may have several output pads indicating different postconditions.

4 The software environment provided by SoftBank Robotics to program

Pepper is called “Choregraphe“. The figures in chapter II contain screenshots taken from this IDE.

Figure 1. Pepper Humanoid Robot – © Philippe Dureuil/TOMA

112

Likewise, boxes can have several input pads, each used to capture a different precondition.

However, as outlined in chapter III, the implementation of non-trivial AAL scenarios usually requires concurrent threads, which may execute independently from each other and potentially communicate with each other. Given the example above, it is not robust or safe for Pepper, to keep on moving until it has reached its destination. During the complete course of the movement, the robot also needs to watch out for obstacles in its way. In case it approaches or bumps into an obstacle, the robot has to stop immediately by interrupting the movement. This type of parallelism cannot be expressed by regular flow charts. To resolve this limitation, the graphical modelling language extends traditional flow charts by introducing parallel flow lines as shown in Fig. 4.

The start terminal in this behavior is connected to input pads of two separate blocks by parallel flow lines. When this behavior starts executing, both blocks, the “Move-To” and the “Bumpers” block, will be triggered in parallel hence forming concurrently running threads. Whenever Pepper bumps into an obstacle triggering one of its bumper sensors, the “Bumpers” block stops and triggers its output pads which in turn will trigger the “Stop” input pad of the “Move-To” behavior. This causes it to stop and thus terminate the complete model.

Introducing parallel flow lines substantially extends the expressive power of the graphical modelling language. However, for real-life examples this is not sufficient. Due to the graphical nature of the modelling language, even seemingly trivial behaviors tend to result in cluttered diagrams which are difficult to understand and impossible to maintain. To address this limitation, the graphical modelling language uses hierarchy to structure complex behaviors into separate layers of increasing abstraction.

As illustrated in Fig. 5, boxes do not have to be primitive, i.e. atomic, but may include a set of lower-level boxes hence specifying a more complex behavior. Now, a single box “Careful Move-To” contains the implementation of a Move-To behavior, which is aware of obstacles and can react accordingly. By means of hierarchically structured boxes, complexity is efficiently controlled. This abstraction mechanism combined with parallel flow lines has proven to be essential, when specifying non-trivial behaviors required when implementing use cases for AAL environments.

In the following sections some of the more challenging aspects of modeling the “Water Buddy” behavior are highlighted in the context of these fundamental concepts: the orientation of the Pepper humanoid robot in space using special landmark icons, the synchronization of parallel threads required to manage coordinated and controlled activities and finally, the complexity of meaningful interaction between the client and the robot.

III. THE “WATER BUDDY” BEHAVIOR The first section of this chapter provides an overview of the

design and workflow of the “Water Buddy”. Before we discuss in the last section several detailed aspects of the implementation, namely orientation based on landmarks, synchronization of parallel processes and human robot interaction, we briefly describe the implementation based on Pepper’s IDE.

A. Design The flow chart in Fig. 6 defines the high-level workflow of

the “Water Buddy” behavior. First, the robot approaches the client and assesses the situation by interviewing the client using its tablet.

Figure 3. Graphical Modelling Language

Figure 2. Flow chart

Figure 4. Parallel Flow Lines triggering Concurrent Threads

Figure 5. Hierarchical Behaviors to manage complexity

113

Depending on whether the user requests water or help, Pepper offers support by either fetching and bringing water or calling help. Once this is completed or in case the user does not need anything, Pepper moves back to its home position.

B. Implementation While Fig. 6 indicates an overview of the workflow, Fig. 7

contains details of the implementation using the IDE as described in chapter II. Here, only the top-level of the hierarchy is illustrated. The behavior consists of seven main steps. In addition to these steps, the safety box “Stop Behavior” is running in parallel in order to be able to stop the behavior at any time if necessary by activating one of the foot bumpers or the tactile sensors on the head.

These are the main steps comprising the top-level behavior:

x Initialize: Pepper wakes up from its default rest mode, checks its surroundings, moves to a safe position in the room and makes sure, some free space is around it.

x Move to user + interview: Pepper searches for the client by using special landmarks, moves towards her and conducts an interview with the help of its tablet. Depending on the outcome of the interview, the robot moves directly back to its home position, calls help, or fetches and brings the water bottle.

x Call help: In the current implementation state, Pepper displays predefined phone numbers of relevant people such as relatives, doctors and a help line. In future versions of the behavior, we intend to directly start a call from Pepper’s tablet.

x Fetch water bottle: Pepper looks for the table where the water bottle is placed, moves there and grabs the bottle. In order to be able to grab the bottle, Pepper needs to raise its hands before approaching the table, because its physiology would not allow it to do so once it is too close to the table.

x Bring water bottle: Pepper looks for the client, again moves towards her and offers the water bottle. The user has to grab the bottle and at the same time has to touch the tactile sensor on one of Pepper’s hands. This will cause Pepper to release the bottle.

x Move to initial position: Pepper looks for its home position and moves there.

x Rest: Pepper switches into rest mode in order to save energy.

During the complete behavior, Pepper continuously utters explanatory speech outputs. This is essential to ensure the client has a clear understanding of what Pepper is doing at any time and also to give instructions to the client.

Figure 6. Overview of the "Water Buddy" behavior

Figure 7. Implementation of the "Water Buddy" behavior

114

C. Details While the previous section describes the top-level

abstraction of the implementation, this section highlights some of the implementation details.

In order to find client, water bottle and its home position, Pepper needs a way of orienting itself inside the room. We use so called Naomarks (see Fig. 8), which are special landmarks provided by SoftBank Robotics and named after their first robot called Nao, to label those three positions. The Naomarks can be detected by means of the built-in cameras using predefined behaviors inside the IDE. Provided the marks are printed large enough (in our case, a diameter of 20 cm was required to allow for distances of up to 3 m) and the illumination of the room is suitable, the detection process is quite robust.

Throughout the “Water Buddy” behavior, there are several parallel threads. For example, when Pepper conducts the tablet interview with the client, there is a longer speech output at the beginning to instruct the client regarding the interview. It is recommended to start the speech output at the same time as the tablet-based interview with the client, because the latter needs some time to load. For synchronization purposes, we need to wait for both boxes to terminate, before we can continue (see Fig. 9). This template is often applied in the context of parallel threads to ensure a robust behavior.

For human robot interaction, we use different technologies. Pepper communicates using both speech output and its tablet. Client input is provided by means of the tablet’s touch display. During initial tests, the clients reported the tablet did not always react immediately which lead to confusion. However, we decided not to use speech input at this stage of the project, because the built-in speech recognition library proved to be not stable enough and requires the client to use exactly the phrases expected. Another important aspect reported is the language used by Pepper. The robot’s voice was described as “pleasant”, but as it is sometimes challenging to understand Pepper, it is important to use the client’s native language. 5

IV. FUTURE WORK In future steps, we intend to realize several ideas to further

improve the “Water Buddy” behavior: A daily routine triggers the AAL behavior as described, however not only once but rather several times a day.

5 http://doc.aldebaran.com/2-1/_downloads/NAOmark.pdf

In addition, integration into the network infrastructure of the Smart Home may improve communication between the robot and the client. Finally, replacing the landmarks, currently used for orientation of the robot in space, means less intrusion into the private environment of the client and extended Usability Testing will help to further improve the “Water Buddy”.

A. Daily routine When initiated, the “Water Buddy” behavior executes the

routine described above exactly once. We envision increased benefit to reduce dehydration if the behavior is extended in a way that the routine is executed several times spread throughout the day. The frequency and exact schedule can be adjusted by the user, nursing staff or relatives.

In addition, this procedure enables Pepper to keep track of the amount of fluid intake and hence it can be more persistent during times when the client does not drink enough by herself.

B. Connecting to the Smart Home At Hochschule Furtwangen University, Pepper is part of the

Smart Home Lab. For now, the “Water Buddy” application runs on the robot, but it is not yet connected to the Smart Home communication infrastructure.

Connectivity, however, will allow for several improvements of the behavior. In addition to the daily routine explained above, the client will be able to actively “call” Pepper at any time in order to get some water. Once connected to the Smart Home, this calling function can be implemented using several devices such as smartphone, tablet, smart table or a traditional button. The benefit of using fixed devices, e. g. a smart table or a button installed in the wall, is that Pepper instantly knows the user’s position without searching.

One way to connect the Pepper robot to the Smart Home infrastructure is by integrating the Message Queue Telemetry Protocol (MQTT) [9]. Based on an Observer pattern, this low-overhead protocol is used to connect various devices across different vendors by means of MQTT bindings. A specific binding and a MQTT broker have been developed already for Nao and can be extended to be used by Pepper.

C. Replacing landmarks As outlined above, we use landmarks to support Pepper’s

orientation. Although their usage contributes to a quite stable behavior, it is desirable to find other ways of orientation. The reason is that they can be perceived as an intrusion to the design of the (smart) home thus e. g. violating the intimate environment of an elderly client.

Figure 8. Examples of Naomarks5

Figure 9. Synchronization of Parallel Processes

115

We use two different classes of landmarks: One labels Pepper’s home position and the water bottle. These positions are fixed whereas the mark labeling the position of the client can be moved. The fixed ones may be replaced by a map-based navigation algorithm that can be easily created for a given floorplan. Technically, this can be realized with directed and weighted graphs, similar to the ones used in navigational systems. The moving landmark indicating the user can be replaced by face recognition and by additionally combining the map with a priori knowledge of the Smart Home, e. g. the position from which Pepper was called or from which the last Smart Home action was performed.

D. Usability Testing For further evaluation and improvement of the “Water

Buddy”, we plan for more Usability Testing. Currently, only a single elderly person with full capabilities has been exposed to this Pepper behavior, already contributing valuable feedback as indicated above. We expect additional insights when performing user tests with a wider range of clients including seniors with impaired capabilities.

V. CONCLUSION As one of the many challenges an ageing society has to

face, we address the problem of possible dehydration of elderly people living alone in the context of AAL. In the “Water Buddy” behavior implemented for the Pepper humanoid robot, Pepper actively approaches the client, brings drinking water if requested and offers assistance to call help if needed.

For the implementation, we use Pepper’s IDE which is based on a graphical modelling language. Its hierarchical structure enables us to efficiently define the relevant procedures of the “Water Buddy” behavior by presenting the top-level abstraction. The complete behavior is composed of only seven main behavior boxes: After initialization, Pepper moves towards the user and conducts an interview. Depending on the outcome of the interview, it either fetches and brings water or offers assistance to call for help. Afterwards, or if no water or help is required, it moves back to its home position and switches to rest mode. An additional safety box enables the client to stop the behavior at any time if necessary.

Parallel processes are one of the challenges in the design and implementation of AAL robot behaviors. In order to create robust behaviors, it is inevitable to keep their structure clear,

i.e. using hierarchy, and to use pre-defined boxes to control parallelism, e. g. “wait for signals”.

Furthermore, issues related to the orientation of the robot and to human robot interaction are addressed and solved by using landmarks, speech output as well as input and output by means of Pepper’s touch display.

In the future, we intend to improve the “Water Buddy” by implementing a user-defined and flexible daily routine, connecting Pepper to the Smart Home infrastructure, replacing the landmarks with map-based navigation in combination with face detection, and by conducting more thorough Usability Testing with a diverse group of possible clients.

ACKNOWLEDGMENT The presented “Water Buddy” behavior of Pepper is based

on a term project in the study course “Mobile Systems” at Hochschule Furtwangen University. We thank the students Markus Burger, Patrik Fehrenbach and Anastasia Lebedeva for their commitment and contribution to the project.

REFERENCES [1] UN, “World population ageing 2013,” 2013. [2] P. Rashidi and A. Mihailidis, “A survey on ambient-assisted living tools

for older adults,” in IEEE journal of biomedical and health informatics, vol. 17(3), pp. 579–590. 2013.

[3] A. Dohr, R. Modre-Opsrian, M. Drobics, D. Hayn, and G. Schreier, “The internet of things for ambient assisted living,” 7th IEEE International Conference on Information Technology: New Generations (ITNG), pp. 804–809, 2010.

[4] Z. Xu, T. Deyle, and C.C. Kemp, “1000 Trials: An empirically validated end effector that robustly grasps objects from the floor,” IEEE International Conference on Robotics and Automation (ICRA), pp. 2160–2167, 2009.

[5] B. Graf, U. Reiser, M. Hägele, K. Mauz, and P. Klein, “Robotic home assistant Care-O-bot® 3-product vision and innovation platform,” IEEE Workshop on Advanced Robotics and its Social Impacts (ARSO), pp. 139–144, 2009.

[6] T. Mukai, S. Hirano, H. Nakashima, Y. Kato, Y. Sakaida, S. Guo, and S. Hosoe, “Development of a nursing-care assistant robot riba that can lift a human in its arms,” IEEE International Conference on Intelligent Robots and Systems, pp. 5996–6001, 2010.

[7] D. Volkert, K. Kreuel, P. and Stehle, “Fluid intake of community-living, independent elderly in Germany – a nationwide, representative study,” in The journal of nutrition, health & aging, vol. 9(5), pp.305–309, 2004.

[8] C. Zimmermann, J. Zeilfelder, T. Bloecher, M. Diehl, S. Essig, and W. Stork, “Evaluation of a smart drink monitoring device,” IEEE Sensors Applications Symposium (SAS), pp. 1–5, 2017.

[9] The MQTT protocol, http://www.mqtt.org, cited June 2017.

116

ScnSim - A Scenario Simulator for IoTEnvironments

Tobias HolsteinHochschule Furtwangen University

Robert-Gerwigplatz 178120 Furtwangen

tobias.holstein@hs-furtwangen.de

Christoph ReichHochschule Furtwangen University

Robert-Gerwigplatz 178120 Furtwangen

christoph.reich@hs-furtwangen.de

Matthias Ulrichlogicline GmbHPlaniestraße 10

71063 Sindelfingenmatthias.ulrich@logicline.de

Abstract—Testing applications for SmartHome environments is

quite complicated, since a real environment is not accessible or

the conditions are not controllable during development time. The

need to set up the whole hardware environment, increase the

complexity of these systems enormously. Therefore, it is helpful to

simulate the SmartHome hardware components and environment

conditions (e.g. rain, heat, etc.).

This paper contains an approach to improve the test and demon-

stration process of Internet of Things scenarios. A prototype

(ScnSim: Scenario Simulator) was developed to set up scenarios.

The user of the ScnSim can create her/his own scenario using

items (sensors/actuators) and rules, which control the sensors and

actors building the IoT environment. This simulator is supposed

to support the user testing IoT applications or configurations of

SmartHome platforms like openHAB. In addition, the ScnSim is

supposed to help demonstrating showcases, for example, often

demonstrated on a trade fair or as a proof of concept for a

customer.

Keywords-Internet of Things, IoT, Simulation, Proof of Concept,

Scenario, Testing, Demonstration, Showcase, MQTT, ScnSim,

Scenario Simulator

I. INTRODUCTION

Millard et.al [1] are describing the Internet of Things asa system, that is rapidly gaining popularity. The influence onother sectors like the semiconductor sector is growing, as well.This raises the following questions: How to test applicationsfor IoT systems? Is it necessary to set up the whole hard- andsoftware environment or is there another way?

In general an IoT system consists of multiple sensor andactor components in a SmartHome environment. The compo-nents need to have a logical connection to each other. Forexample, a connection between the temperature sensor in theroom where the sensor is placed and the windows of the room.So, it will be possible to close the windows, if the temperaturein the room gets too low. If the set up for such a use case wasmade: How is it possible to test the system, without waitinguntil the temperature in the room gets as cold as needed, toclose the windows automatically? For demonstrations, it isquite complex to set up all hardware components. Waitinguntil the needed scenario occurs, is quite time-consuming aswell.

A possible solution for these scenarios is to simulate thesensors and actors. With the use of a simulator, a companycould easily show the features of the SmartHome application.

To demonstrate a customer the functionality of her/his futureSmartHome system will be simplified. Further, as describedbefore, tests will be simplified. To summerize, ScnSim, canbe used for:

• simulating the SmartHome environment to develop andconfigure a SmartHome platform such as openHAB

• demonstrating SmartHome use cases and therefore ableto do automatic system tests

• generating SmartHome scenarios, which can be used fortrade fairs or customer requirement engineering

This paper is structured as follows: After the related work hasbeen shown the topic Internet of Things will be introduced.Chapter “Simulation” introduces the basic of computer simula-tion. The chapter “Prototype” V describe the prototype ScnSimand its components. In chapter VI a typical SmartHomescenario will be described followed by the evaluation. Thelast Chapter gives a conclusion of this paper.

II. RELATED WORK

In the papers [2], [3, p. 77 - 88] and [4] the simulationof IoT nodes is described. They use platforms for the nodesimulation. In contrast to this paper, they simulate devices andoccasionally network connectivity is simulated. This makessense for testing the firmware, which runs on an embeddeddevice. Their approaches is the virtualization of IoT nodes.Therefore, an installation of the device firmware to a cloudplatform is described by the authors. The technologies men-tioned in [2], [3, p. 77 - 88] and [4], are specialized firmwaretesting with the following testing questions:

• Runs firmware stable?• Works the connectivity of the device to the network, well?• Are the node requirements met?

The firmware usually gets the sensor values from the labenvironment. For enabling the publication of values, it wouldbe necessary to simulate the values. It does not make senseto simulate a network, at least for the research described inthis paper. Generally, simulations described in these papers areuseful to test a single device in a network with others, but theyare not quite useful to test a configuration for example made inopenHAB. Further it is complicated to demonstrate a showcase.Because the firmware of the devices is not public accessible.

117

Usually the firmware belongs to a device and the developersof such a device usually do not publish the firmware of thesedevices. Such a firmware is not including a simulation of thesensor values. This raises three problems:

1) A dependency is created on a special hardware and thismight be exactly what the company wants to demon-strate.

2) If the firmware is published, updating this firmware willbe hard but would be necessary to simulate the sensorvalues.

3) The physical network is not used.These problems shows the requirements of the ScnSim proto-type described in this paper.

Kim et.al [5] is describing an emulator for IoT devices.They show the possibility of reducing the costs and time forapplication development processes. This is possible because ofreducing the devices needed for the application. These reduceddevices will be replaced by the emulation of them. This featureenables a less time consuming development of a large scaleIoT system.

The paper [4] describes a complex set up of IoT systems.Therefore, it is relevant to test not just the devices. Theapplications and IoT platform configurations are complicatedto test, as well.

The authors of the articles [6] and [7] prove that it isnecessary to get new methods for testing IoT systems. Themost discussed solutions are based on traditional methods. Themain point of these articles is the split of the system in multipleparts. So, it should be split in the network, the devices andthe back end. These parts should be tested separately.

There are different articles about improvements on thetesting of IoT systems. But there is no paper, that describes asimulation as it will be done in this paper, yet.

III. INTERNET OF THINGS

The Internet of Things (IoT) consists of multiple dailylife things connected to the Internet. The connection to theInternet enables them to communicate to the outside. Becauseof that they can communicate with other things, like the useror services [8]. The main architecture of an IoT system, isshown in Figure 1. At the bottom of the figure there isshown the Thing layer showing multiple things, generalizedas sensors and actors of a SmartHome environment. The graybox represents a gateway, that is used for communicatingwith the outside world and is also the protection bastionfor the SmartHome. This gateway transfers the protocols ofthe Wireless Sensor Network to the protocols of the WANor the Mobile Networks (e.g. 3G). The cloud at the top ofthe figure contains, for example, the Device Management, theEvent Management and other components of an IoT platform.The idea of IoT is to connect things to the Internet. Thesethings can be daily life things like mirrors, washing machinesor light bulbs. These connections enable the state tracking ormanipulation [9].

In the following sections the main IoT terms are defined.

Fig. 1. Example of an IoT

A. ThingsThe things are physical objects. Usually the user of the IoT

system is interested in controlling, track them or communicatewith them. Things can be usual household devices like fridgesor anything else. Things are not needed to be in a household.Machines in the industry or health care things, like smartwatches or fitness tracking systems are such things, too. Itis possible that things are parcels shipped all over the world.In conclusion things can be all natural things or objects theuser wants to communicate with [9].

B. SensorsSensors detect physical information from the environment

and translate them into an analog electrical signal. This leadsto a knowledge about the device environment. Therefore, adevice can react on the environmental conditions. A fewexamples of sensors are a temperature sensor, a rain sensoror a sensor, that detects the air pressure of the environment[9].

C. ActuatorsActuators are the opposite of the sensors. They transform an

electrical signal into a mechanical movement or other physicalsizes. Probably the most well-known actuator is the electricalmotor. It transforms the electrical signal into a mechanicalmovement [9].

D. IoT PlatformsIoT platforms enable the logical connection of things. One

example for a platform is openHAB. Some IoT platformsprovide the option to deploy IoT applications, like the AmazonWeb Services (AWS) IoT platform. These platforms are used toset up automations [10]. An example would be to set up therule, that the window is opening, if the temperature is above22°C. These platforms are displayed as a cloud by figure 1.This is because they are usually located in clouds.

118

IV. SIMULATION

[11] gives the definition of simulation according to DIN3633. Simulation is described as a process of rebuilding a realor virtual system. This means that the process is modeled,to enable the derivation of knowledge. It should be possibleto transfer this knowledge to the real world. In the followingsections the different kinds of simulation will be defined [12].

A. Dynamic SimulationThe dynamic simulation models are based on time. That

means the time influences all the components states. Thiskind of simulation is usually used for modeling, processesand sequences.

a) Continuous Simulation: This Simulation uses differ-ential equations to model physical or biological principles.These principles need to be the base of the simulated process[13].

b) Discrete Simulation: This kind of simulation is basedon time. It gives events in static or dynamic time intervals.These events lead to a new state of the system. The main use ofthis simulation is for processes in logistics and production. Thevalue changes are saltus, because of the predefined, discretetime slots. The state changes are based on events. In this case,an event is the time slot, that makes the system changing thestate [11] [13].

c) Hybrid Simulation: Hybrid Simulation describes amodel with the properties of the continuous and the discretesimulation. This kind of simulation is often used for medicalsimulations, especially if the biology is not well known enoughto reach a proper continuous simulation [11] [13].

B. Sequential SimulationThe sequential or static simulation models do not have state

changes. This kind of simulation just represents one moment.If this kind of simulation is based on random numbers orstochastic it is called Monte-Carlo-Simulation. This namebelongs to the gambling at Monte Carlo [11] [13] [12].

V. PROTOTYPE

The prototype of the ScnSim is supposed to help the user,configuring the scene simulator (ScnSim) for IoT systems. Theuser can configure his own scenario. The simulation, whichwas created, can be used to test or demonstrate applicationsfor IoT systems.

The simulation of this prototype is based on a discretesimulation. All the Items receive their event of the systemtime. The Simulated Time receives the events of the systemtime, as well. These events lead to a change of the state. Inthe following sections the definitions of keywords used for theScnSim will be described, as well as the architecture used.

A. Things According to the PrototypeEach Thing needs to have at least one Item (see section

V-B). But it can have as many Items as needed. The ScnSimoffers the opportunity to start up multiple things. All the thingsstarted up in the same simulation use the same Simulated Time.

There is the option to set the type of the Thing to four differentvalues:

1) Custom: this selection leads to a setup, starting fromscratch.

2) Room: this selection will give a possible configuration,for a room.

3) Weather: this selection will give a possible configuration,for a weather station.

4) Machine: this will give a possible configuration, for amachine temperature.

It is still possible to edit all the configurations, created withthe use of these types, afterwards.

B. Items According to the PrototypeThroughout this paper, the term Item refers to sensors and

actuators. Each Item has a value. The Item publishes this value,by MQTT. The user has the chance to set up the Broker andthe Topic for each Item. A basic setup will be made on creationof the Item. Each Item belongs exactly to one Thing. To enablethe configuration of the ScnSim, it provides different kindof Items. These Items are simulated mostly realistic. So, forexample the “Temperature Sensor” is defined by two function:

1) representing the average temperature in Germany2) representing the daily progression of the temperature

Therefore, the highest temperature is reached at noon and thelowest temperature is reached at midnight. This behavior isrelevant for showcases. It is possible to interact with the Scn-Sim, for example with a Subscription Item. The SubscriptionItem listens to the given Topic on the given broker. With theuse of the Rules there is the opportunity to set up the reactionof an Item.

C. Rules According to the PrototypeTo get a proper simulation of a scenario it is possible to add

Rules. The Rules can read the data published by an Item andcompare it to a value. If the result of the comparison is true,the “Do part” will be executed. This leads to the possibility ofstate changes, in dependency on an event. The Rules are notlinked to a Thing. With the help of the Rules it is possible tosetup a connection between two or more things.

D. Simulated TimeBecause most of the Items are time dependent, it is impor-

tant to set up the Simulated Time. For example, the temperaturesensor depends on the time and the season of the SimulatedTime. Especially for showcases it is an important feature torun the simulated time faster. Therefore, it is possible, to setup the duration of one day between 1 and 60 minutes. TheSimulated Time gets the start value from the current systemtime. On execution of the simulation the Simulated Time runsone day, in the duration that was specified before.

E. Architecture of the PrototypeIn general, one Thing can have multiple sensors and actua-

tor. A Thing consists of at least one sensor or actuator. Thisleads to the main architecture of the ScnSim. Figure 2 shows

119

Fig. 2. Architecture of the ScnSim

the architecture of the ScnSim.The ScnSim (represented by the box at the bottom) can containmultiple Things. All of them have at least one Item. Thesimulation of these Items will be started by their Thing. Whilethe simulation runs, these Items publish their values.The Rules are connected to the Items, because the Rule willexecute a function on them. Therefore, the topic of the Items,which are selected in any “If part” of the Rule configuration,will be subscribed. The line between the Item and the MQTT-Broker shows the possibility of publishing the values. Theline between the Rule and the MQTT-Broker represents thesubscription of topics. If a subscribed message arrives, theRules check the “If part”. If the result is true, the “Do part”(for more details see section V-C) will be executed.Because of the Items depend on the Simulated Time, the Itemsneeds to know the state of the Simulated Time (line betweenItem and Simulated Time).The Items depend to the System Time. This is, because theSystem Time gives the event for the value update. This happensevery 600 milliseconds. The Simulated time knows the SystemTime, as well. The Simulated Time updates the state, everymillisecond according to the System Time.The line between the Data Display and the MQTT-Brokershows, that the application can publish values, as well. Thesevalues can be subscribed by the ScnSim, using the Subscrip-

tion Item1. This leads to a possible interaction of a real systemand the ScnSim.In the mid part of the figure the MQTT-Broker is located.The MQTT-Broker is the link between the ScnSim and theapplication. For the development Mosquitto and the publicMQTT-Broker provided by HIVEMQ were used. But it ispossible to use other MQTT-Brokers because the broker canbe set up for each single Item.The application, which should be tested or demonstrated is thebox in the top area of the figure.

VI. SCENARIO

In this chapter, it is illustrated how to set up the configura-tion of the ScnSim for the following Scenario.

In this simple scenario: Room Temperature Control withWindows one Thing exists. This Thing has two Items. TheseItems are:

• Temperature Indoor• Window

The Scenario represents a room with a temperature and awindow. The window should open and close automaticallyaccording to the temperature. Therefore, the following automa-tions should be simulated:

• If the temperature in the room gets below 21°C thewindow should close.

1a special Item type, allows the subscription of a topic not used forpublishing by an Item of the ScnSim

120

• If the temperature gets above 22°C the window shouldopen

If the Window is open, usually the temperature in the room isnot rising. Therefore, it should cool down.

Because of the Scenario is used to demonstrate a showcase,the duration of one simulated day should be set to one minute.

A. Mocking the Scenario with the ScnSim

Fig. 3. Thing Configuration

The first step is to set up the Thing. An example for thisset up is shown in figure 3. The name of the Thing is set to“Room”. This name is used to identify the correct Thing in thelist, located on the left-hand side of the figure. The selectedtype of the Thing should be “Custom”. To identify the Thingmore clearly the location is set to “Living Room”.

The next step is to add the Temperature Indoor Item.Therefore, the selection of the tab “Items” is needed. When thebutton “Add Item” was clicked, the Item configuration framewill be shown (see figure 4). The name for the Item is usedto identify the item in the list shown in figure 5. It is used forthe default topic, as well. In this case, the type needed to beselected is “Temperature Indoor”. The fields, starting from thelabel “Topic” to the last one, are needed for the configurationof the MQTT-Broker. In this case, the default values fit. If theydo not fit, it is possible to change them to the needed values.Now it is necessary to repeat this for the Window Item.Therefore, the type to select is “Window”.

If that was done, the next step is to set up the Rules.Therefore, the tab “Rules” must to be selected. If the button“Add Rule” was clicked, the frame shown in figure 6 willbecome visible. The name is just be used for the identificationin the list shown in figure 7.The top box, shows the “If-Items”. If all of them return true, allthe functions in the bottom box (“Do-Items”) will be executed.The “If-Items” has to be configured as follows:

Fig. 4. Item Configuration

Fig. 5. List of Items

1) Selection of the Item: The topic of this Item will besubscribed.

2) Selection of the operator: necessary for comparison.3) Enter the value to compare with the value published by

the item.The configuration of the “Do-Items” has to be done as follows:

1) Selection of the Item, the function should be executedon.

2) Selection of the function, should be executed.3) If necessary, enter the parameter of the function (mostly

the new value).Figure 6 shows the configuration of the Window opening.If this configuration is done, there are three more actionsrequired.

121

Fig. 6. Rule Configuration

Fig. 7. List of Rules

• closing the window• setCoolDown• stopCoolDown

If these configurations have been done, the final step begins.Therefore, the “Simulated Time” needs to be configured. Thisconfiguration is shown in figure 8. The tab “Simulated Time”needs to be selected. The Slider at the top needs to be usedto set up the duration, of one simulated day. In this case,the simulated day should take one minute. The fields can beused to set up the MQTT-Broker, the simulated time will bepublished to. This configuration works the same way as forthe items.If all the configurations are finished, a click on the button“Run Simulation” starts up the simulation of the scenario. A

Fig. 8. Simulated Time Configuration

Fig. 9. List of Rules

Log frame (shown in figure 9) appears.

VII. EVALUATION

The prototype is written in Java to enable the executionon every platform. Because of that it would be possible torun it on a cloud server. This makes it possible to test theapplication according to how it works while a lot of messagesare transmitted, from all over the world.To proof that the described scenario is being simulated cor-rectly, the published massages were subscribed by anothertool. This tool was logging the received messages according tothe system time. This result was used to create two diagrams(shown in figure 10).

122

Fig. 10. Diagrams Showing the Results of the Scenario

The upper diagram shows the state of the window. It displays“1”, if the window is open and “0”, if it is closed. The diagramat the bottom part of the figure gives a representation about thetemperature in the room. These diagrams lead to the followingpoints:

• Every time the window is open, the temperature goesdown.

• Every time the window is closed, the temperature heatsup.

• Every time the temperature is above 22°C, the windowbecomes open.

• Every time the temperature is below 21°C, the windowbecomes closed.

• The period, where the window is closed for a longer time,was the simulated night. The temperature in the room wasthat low, that the window was not opening any more.

These points proof, that the simulation of this scenario workswell. The window opens and closes depending on the tem-perature. If the window would be controlled by openHAB,the temperature sensor of the ScnSim could be used to testthis configuration. Because it is possible to retrieve data,the temperature sensor simulated by the ScnSim, could reactaccording the real window. An example is shown in figure 11.The ScnSim simulates the temperature sensor (bottom right).This temperature sensor cools down, if the real window willbe opened. openHAB controls the real window according thesimulated temperature. So, the window will be opened, if thesimulated temperature is above 22°C. This advantage leads tothe possibility to test SmartHome configurations.As conclusion, the ScnSim can still be extended. This proto-type proofs the concept that a simulation of IoT systems canimprove testing or demonstrating applications. Often there isno hardware available when the project starts. For sure it is stillnecessary to execute a system test after the development of anapplication was done. But to test the application in advanceit is a great feature. Developing a hardware independentapplication becomes easier because of the opportunity to

Fig. 11. Example Testing SmartHome Configuration

simulate a lot of different sensors. In a future version, itcould be possible that the payload can be changed in differentformats like Jason or others. The implementation of differentprotocols like COAP or others would be possible, as well.These are facts, showing that the use of the ScnSim is usefulfor testing. The use of the ScnSim for demonstrations at atrade fair is clearly easier, too.Even if it is necessary to add different features, the ScnSimcan be useful. The implemented features work well, especiallythe demonstration of a SmartHome is advanced.

VIII. CONCLUSION AND FUTURE WORK

The ScnSim tool developed is useful for simulating aSmartHome environment consisting of sensor, actors andrules simulating scenarios. The messaging backbone of theprototype is MQTT messages in JSON format. Sensor/actorvalues get publish to topics associated to applications. Theconfiguration of an environment sensors or actors have tobe configured multiple times, which is time consuming. It isplaned to implement the import and export of configurations.This could lead to speed up the configuration.

The demonstration of a showcase will become easier withthe help of ScnSim. If a company wants to show a proofof concept to a potential customer, it is possible to use theScnSim, because the company might not know much about thehardware. They are still able to present and test the application.On trade fairs the companies can demonstrate the showcasewith the ScnSim.

In conclusion, it is possible to say that the ScnSim is apowerful assist for testing and demonstrating applications forIoT systems.

REFERENCES

[1] C. Millard, W. K. Hon, and J. Singh. Internet of things ecosystems:Unpacking legal relationships and liabilities. In 2017 IEEE InternationalConference on Cloud Engineering (IC2E), pages 286–291, April 2017.

[2] Nadir Javed. Iot node emulation and management testbed. Master’sthesis, Tampere University of Technology, 12 2014.

[3] Georgios Keramidas, Nikolaos Voros, and Michael Hubner. Componentsand Services for IoT Platforms. Number 978-3-319-42302-9 in ISBN:.SpringerLink, 2017.

123

[4] G. D’Angelo, S. Ferretti, and V. Ghini. Simulation of the internetof things. In 2016 International Conference on High PerformanceComputing Simulation (HPCS), pages 1–8, July 2016.

[5] B. Kim, H. Kim, and S. T. Kim. Design of large scale network simulatorusing device emulator for internet of things. In 2017 19th InternationalConference on Advanced Communication Technology (ICACT), pages855–857, Feb 2017.

[6] CHRIS RILEY. Functional testing for iot. Technical report, devops.com,2015.

[7] VASSILI VAN DER MERSCH. Automated testing for the internet ofthings. Technical report, nordicapis.com, 05 2016.

[8] Subhas Chandra Mukhopadhyay, editor. Internet of Things - Challengesand Oppertunitys, volume 9 of Smart Sensors, Measurement and Instru-mentation. SpringerLink, 2014.

[9] Patrick Hanselmann. Internet of things – concepts, applications andprocesses. Master’s thesis, Universitat Ulm, 2015.

[10] Santosh Singh. Top 10 iot platforms. Technical report, inter-netofthingswiki.com, 03 2016.

[11] ITWissen. Simulation, 1 2010.[12] Hans Benker. Mathematik-Problemlosungen mit MATHCAD und MATH-

CAD PRIME, pages 251–256. Springer Berlin Heidelberg, Berlin,Heidelberg, 2013.

[13] Alexander K. Hartmann. A Practical Guide To Computer Simulation.Wolrd Scientific, 2009.

124

IT-Sicherheit Friedbert Kaspar

125

Analysis of security vulnerabilities in MicrosoftOffice 365 in regard to SAML

Jennifer Jurreit, Patrik Fehrenbach, Prof. Dr. Friedbert KasparFakultat Informatik

Hochschule Furtwangen University{jennifer.jurreit, patrik.fehrenbach, f.kaspar}@hs-furtwangen.de

Abstract—Microsoft Office 365 is a commonly used office appli-

cation, distributed by Microsoft. Several well-known companies

and education institutes, such as schools and colleges, registered

their office subscriptions as federated. As it was demonstrated

in April 2016, a security vulnerability in Microsoft’s Office 365

Single Sign On (SSO) implementation exposed these accounts to

an external threat.

The implementation in question was an implementation of the

Security Assertion Markup Language (SAML) 2.0 Web Browser

SSO Profile, customized by Microsoft’s developer team.

By analyzing known security vulnerabilities of SAML implemen-

tations and security risks in web-based SSO implementations, the

probability of a general vulnerability in SAML has been assessed.

Furthermore, the cause of the vulnerability in Microsoft’s Office

365 SSO, as demonstrated by Kakavas and Bratec, has been

examined.

Regarding the aforementioned analyses, it could be demonstrated

that the security vulnerability in Microsoft’s Office 365 SAML

2.0 Web Browser SSO Profile implementation did not emerge

from a general security flaw in SAML, but from disregarding

established security standards.

I. INTRODUCTION

The Security Assertion Markup Language, in short SAML, isa widely-used authentication mechanism used by numerouscompanies and products around the world. Since it got firstintroduced in November 2002, it evolved across severalversions to what it is right now. Over the last approximatelytwenty years, hundreds of functions have been implementedin SAML. Integrations of SAML are available in almostevery programming language. As SAML and its integrationsevolved, researches, focusing on its frameworks’ security,commenced. An interesting example is ”On Breaking SAML:Be Whoever You Want to be”, which attempts to identify flawsin SAML implementations of commonly used frameworks[15]. One of the discussed topics in the paper is the commonlymisinterpreted usage of cross domain authentication. Theflaws associated with this mechanism were also discoveredby Klemen Bratec and Ioannis Kakavas in December 2015.They discovered a vulnerability in Microsoft Office 365,which allowed the bypassing of cross domain authentication.This vulnerability was caused by the implementation of theSAML Service Provider, and affected all federated domains.In this paper, the cause of the vulnerability will be assessed,answering the questions whether there is a security issue inSAML or whether Microsoft violated fundamental securitymechanisms, causing a major security vulnerability.

Section II of this paper discusses related work of the topic,starting with the first published research regarding SAMLsecurity.Section III and IV provide fundamental knowledge ofWS-Trust and SAML.In Section V known security issues of web-based Single SignOn are discussed to assess the overall security of SAML insection VI.The Microsoft Office 365 Single Sign On implementation isdescribed and the exploit discussed in section VII.Section VIII concludes the paper.

II. RELATED WORK

One of the earliest researches regarding SAML and securitywas published in October 2003 by Thomas Groß of IBMZurich with the title ”Security Analysis of the SAML SingleSign-on Browser/Artifact Profile” [13]. It provides a commonattack-by-attack list, as well as countermeasures and securityrestrictions.SAML and SOAP implementations were a common causefor devastating security issues over the last years. Onefamous example of a wrongly implemented SAML is theSSO (Single Sign On) plugin for the content managementsystem and blogging platform WordPress. Due to a mistakein the implemented check of the <ds:Signature> tag, itwas possible to bypass the authentication by stripping theSignature tag from the message. This example shows theimportance of auditing the actual implementations of SAMLendpoints. This was also demonstrated by an attack on theSOAP implementation of the e-Commerce platform Magento[20]. A privileged attacker could insert PHP classes throughthe autoloader function of PHP. This was possible due to thefact, that a SOAP message was used to insert products. Thisallowed the researcher to add a xsi:type=”xsd:base64Binary”element into the body, which included a base64 encodedstring. This string contained an ftp:// wrapper to maliciouslyinclude external PHP classes.Lastly, the blog entry ”The road to hell is paved with SAMLAssertions” by Ioannis Kakavas [4] discusses the securityvulnerability in Microsoft Office 365 SAML Service Providerregarding its cause and impact on Microsoft Office 365.

127

III. WS-TRUST

WS-Trust was designed to enable applications to build andexchange trusted SOAP messages [9]. The trust system worksby exchanging and brokering security tokens in a protocolagnostic way.The WS-Trust specification provides a flexible set ofprocedures to support various security protocols, but does notdirectly describe any protocols [9].The provided procedures include processes to request andobtain security tokens, and to establish, manage and assesstrust relationships [9].The core of each process is the Security Token Service (STS),which is a web service that declares security tokens [9]. Toestablish trust, a web service expects that incoming messagesprove a series of claims, e.g. name, key, permissions. In casethe expectation is not met, the web service rejects or ignoresthe message [9].One way to present those claims is to associate securitytokens with the messages. If the requestor does not havea security token to prove the required claims, it canrequest a token from the STS. This approach is calledbrokered authentication. Trust relationships are establishedbetween the client (also referred to as requestor) and the STS,and between the STS and the requested service (see Figure 1).

Figure 1. Brokered Authentication in WS-Trust

IV. SECURITY ASSERTION MARKUP LANGUAGE

The Security Assertion Markup Language (SAML), definedby the OASIS Security Technical Committee (SSTC), is anXML-based, commonly used framework for authenticationand authorization across platforms. It is used for sendingand receiving attributes and user privileges, e.g. credentials

and roles, between different platforms, without the necessityof sending critical data. Its well-known Web Browser SSOProfile was used in Microsoft Office 365 SSO implementation.In this section, the fundamentals of SAML will be explainedto assess its overall security.

A. Fundamentals

SAML is composed of three parties, the User Agent (user),the Identity Provider (IdP), and the Service Provider (SP).The Service Provider corresponds to the application the userrequests to use, while the Identity Provider saves all relevantuser information, e.g. credentials and roles. Therefore, theIdP is also called the SAML Asserting Party [3].To secure Single Sign On, SAML consists of four concepts,Assertions, Protocols, Bindings, and Profiles [7].Assertions are XML structures that contain information aboutthe user, requesting access. They are created by the IdP andconsumed by the SP. To establish trust, the Assertions containa Token the IdP created. To verify its validity, it also containsa digital signature.There are three types of Assertions, the AuthenticationStatements, the Attribute Statements, and the AuthorizationStatements [3].Authentication Statements inform the SP, that the user isauthenticated by the IdP. They communicate when and howthis authentication occurred.The Attribute Statements are used by the SP to sendinformation about user identifying attributes to the IdP.Using the information received by both parties, theAuthorization Statements serve to assess which resources theuser is allowed to use.Sending and receiving of Assertions between the IdP and SPtypically follows a request/response pattern. This pattern iscalled a Protocol [7].In SAML there are six different Protocols predefined [3].The goal of the Authentication Request Protocol is to establisha security context between the IdP and the SP, that is neededto secure the SSO process. It is used to receive Assertionsabout the user from the IdP.The Single Logout Protocol terminates all sessions of a user.It can be triggered by the user, the IdP, or the SP.The Assertion Query and Request Protocol defines messagetypes and rules for handling messages to request alreadyknown Assertions via reference, or to use defined searchparameters to find a specific Assertion.The Artifact Resolution Protocol is used to send referencesto SAML messages, and to use SAML artifacts via SAMLbinding. These are used to minimize the message’s networkload. The protocol can also be used to solve references.To change the value of an identifier that is linked to the user,the Name Identifier Management Protocol is used.The Name Identifier Mapping Protocol, on the other hand,enables the SP to request an identifier for the requesting userfrom the IdP to access another SP.To determine how SAML messages are transported between

128

the IdP and SP within a protocol, Bindings are used [7].Typical bindings are SOAP and HTTP.Profiles combine Assertions, Protocols, and Bindings forspecific use cases. The most common profile is the WebBrowser SSO Profile, that is widely used for Web SSO [3].

B. SAML 2.0 Web Browser SSO

The Web Browser SSO Profile is a well-known SAML Profilefor web-based Single Sign On. It combines the AuthenticationRequest Protocol, as defined in [16], an authentication Asser-tion, and Bindings. As defined by [6], the following steps areimplemented by the Profile (see Figure 2).

Figure 2. Web Browser SSO

First the principal makes an HTTP request to a protectedresource at the SP without a security context, using an HTTPUser Agent.Then the SP determines which IdP to use for this request,based on the supported bindings.In the third step the SP issues an <AuthnRequest> message tothe IdP, which is delivered by the User Agent. For this, eitheran HTTP Redirect, HTTP POST or HTTP Artifact Bindingis used to convey the message from the SP, through the UserAgent, to the IdP.Listing 1 shows a typical <AuthnRequest> message [10].

Listing 1. AuthnRequest message<samlp : AuthnReques txmlns : samlp=” urn : o a s i s : names : t c :SAML: 2 . 0 : p r o t o c o l ”xmlns : saml=” urn : o a s i s : names : t c :SAML: 2 . 0 : a s s e r t i o n ”ID=” i d e n t i f i e r 1 ” V e r s i o n =” 2 . 0 ”I s s u e I n s t a n t =”2004�12�05T09 : 2 1 : 5 9 Z”A s s e r t i o n C o n s u m e r S e r v i c e I n d e x =” 0 ”>

<saml : I s s u e r>h t t p s : / / sp . example . com /SAML2

</ saml : I s s u e r><samlp : NameIDPolicyAl lowCrea t e =” t r u e ”Format=” urn : o a s i s : names : t c :SAML: 2 . 0 : nameid�f o r m a t : t r a n s i e n t ” />

</ samlp : AuthnReques t>

To define the SP issuing the request, an URI like string,uniquely identifying the SP, is included in the Issuer tagof the message. In addition to this, the IssueInstant valueindicates when the request was issued. The given ID is aninternal identifier to link the <Response> message to therequest.Examining the <AuthnRequest>, the IdP assesses whether ittrusts the SP or not, identifies the principal by prompting the

user for authentication (step four), and issues a <Response>message to the SP (step five). The <Response> message isissued by the IdP, but sent via the User Agent. In this case,the HTTP POST or HTTP Artifact Bindings can be used.The HTTP Redirect Binding cannot be used in this context,because the response will most likely exceed the maximumURL length.When the authentication was successful, the <Response>message looks like the example shown below (see Listing 2)[10].

Listing 2. Response message<samlp : Response xmlns : samlp=” urn : o a s i s : names : t c :SAML: 2 . 0 : p r o t o c o l ”ID=” s 2 c d c 7 4 f 3 7 f 9 2 3 e 2 6 f e 1 a e e c 4 2 b 7 0 a 9 3 d 2 4 2 3 0 3 3 4 f ”InResponseTo =” 90AA6073F01567BFB0DF194F596314E2 ”V e r s i o n =” 2 . 0 ”I s s u e I n s t a n t =”2010�04�29T23 : 2 1 : 5 1 Z”D e s t i n a t i o n =” h t t p s : / / dloomac . s e r v i c e�now . com / navpage . do ”><saml : I s s u e r xmlns : saml=” urn : o a s i s : names : t c :SAML: 2 . 0 : a s s e r t i o n ”>

h t t p : / / i d p . s s o c i r c l e . com</ saml : I s s u e r><samlp : S t a t u s xmlns : samlp=” urn : o a s i s : names : t c :SAML: 2 . 0 : p r o t o c o l ”>

<samlp : S t a t u s C o d e xmlns : samlp=” urn : o a s i s : names : t c :SAML: 2 . 0 : p r o t o c o l ”Value=” urn : o a s i s : names : t c :SAML: 2 . 0 : s t a t u s : S u c c e s s ”></ samlp : S t a t u s C o d e>

</ samlp : S t a t u s><saml : A s s e r t i o n xmlns : saml=” urn : o a s i s : names : t c :SAML: 2 . 0 : a s s e r t i o n ”ID=” s23e536bfc51b8487d4d3299dec162d9c2e338823b ”I s s u e I n s t a n t =”2010�04�29T23 : 2 1 : 5 1 Z”V e r s i o n =” 2 . 0 ”>

<saml : I s s u e r>h t t p : / / i d p . s s o c i r c l e . com

</ saml : I s s u e r><S i g n a t u r e xmlns=” h t t p : / / www. w3 . org / 2 0 0 0 / 0 9 / xmlds ig # ”>

. . .</ S i g n a t u r e><saml : S u b j e c t>

<saml : NameID Format=” urn : o a s i s : names : t c :SAML: 1 . 1 : nameid�f o r m a t :e m a i l A d d r e s s ”

N a m e Q u a l i f i e r =” h t t p : / / i d p . s s o c i r c l e . com”SPNameQua l i f i e r =” h t t p s : / / dloomac . s e r v i c e�now . com / navpage . do ”>

d a v i d . loo@serv ice�now . com</ saml : NameID><saml : S u b j e c t C o n f i r m a t i o n Method=” urn : o a s i s : names : t c :SAML: 2 . 0 : cm : b e a r e r ”>

<saml : S u b j e c t C o n f i r m a t i o n D a t aInResponseTo =” i d e n t i f i e r 1 ”NotOnOrAfter=”2010�04�29T23 : 3 1 : 5 1 Z”R e c i p i e n t =” h t t p s : / / dloomac . s e r v i c e�now . com / navpage . do ”/>

</ saml : S u b j e c t C o n f i r m a t i o n></ saml : S u b j e c t><saml : C o n d i t i o n s NotBefore =”2010�04�29T23 : 1 1 : 5 1 Z”NotOnOrAfter=”2010�04�29T23 : 3 1 : 5 1 Z”>

<saml : A u d i e n c e R e s t r i c t i o n><saml : Audience>

h t t p s : / / dloomac . s e r v i c e�now . com</ saml : Audience>

</ saml : A u d i e n c e R e s t r i c t i o n></ saml : C o n d i t i o n s><saml : A u t h n S t a t e m e n t A u t h n I n s t a n t =”2010�04�29T23 : 2 1 : 5 1 Z”S e s s i o n I n d e x =” s2dbf89ab99001e0e8cdaed67266d9d4b21b968a04 ”><saml : AuthnContex t>

<saml : A u t h n C o n t e x t C l a s s R e f>urn : o a s i s : names : t c :SAML: 2 . 0 : ac : c l a s s e s : P a s s w o r d P r o t e c t e d T r a n s p o r t

</ saml : A u t h n C o n t e x t C l a s s R e f></ saml : AuthnContex t>

</ saml : A u t h n S t a t e m e n t></ saml : A s s e r t i o n>

</ samlp : Response>

To link the <Response> message to the issued request theInResponseTo value refers to the ID value shown above (seeListing 1).IssueInstant, NotOnOrAfter and NotBefore define when themessage is valid to protect against replay attacks.To verify that the message is sent from the right IdP, theIssuer field is provided in the <Response> message.To prevent the message to be used by a foreign SP, theAudienceRestriction element is provided.The Subject element identifies the authtenticated principal,and the AttributeStatement contains user specific attributes

129

and their values.Lastly, the SP either grants access to the principal or deniesit, depending on the received response from the IdP.In case the first request of the User Agent is not sent to theSP, but directly to the IdP, the process starts at the fifth stepand ignores all prior steps.

V. SECURITY RISKS OF WEB-BASED SINGLE SIGN ON VIASAML

The SAML web-based SSO procedure, as described inSection IV, has been used for approximately twenty years.During this time, two essential security vulnerabilities havebeen discovered in many SAML implementations. Thesevulnerabilities are explained in this section.

A. XML Signature Wrapping

SAML and any other authentication based mechanisms, suchas SOAP, are highly flexible, when it comes to deployingintegrity features [17]. To establish a trust model betweenmessage deliveries, the integrity must be validated. For thatreason, several parts of SOAP and SAML messages use cryp-tographic signatures. In most cases, these signatures include aX509 Certificate with Block Encryption Algorithms of AES(Advanced Encryption Standard)-128, AES-256 or Triple DES(Data Encryption Standard), represented by ASN.1 (AbstractSyntax Notation One).In a hypothetical scenario, a web service receives a signedmessage by a client, validates the signature and processes thedata. A malformed request should not be accepted by the webservice in any case. However, the XML Signature Wrappingattack, also known as the XML Rewriting attack, allows anattacker to change the content of the signature part withoutinvalidating the signature [17].

Simple Context. One instantiation of the XML Signaturewrapping is the simple context attack methodology. In asignature process the data is embedded within the documentbody and is referenced via an ID attribute. The data iscomprised in a so called Simple Ancestry Context. During thevalidation, the XML parser references the element and verifiesthe signature. As a result, it returns a Boolean value. In caseof a true statement the service processes the SOAP request,and in case of a false return value it rejects the message.If the validation logic works correctly, no manipulation ispossible. However, it is possible to bypass the logic bychanging the signed data without invalidating the signature.This is possible due to the fact, that the verification algorithmstarts by looking for the Body element, which is stated inthe <Reference> element. The referenced element may findthe <soap:header> element within the <wrapper> element.The real <soap:Body> outside of the <soap:Header> getsignored, since it has the wrong ID element [17]. Althoughthe context of the message is malformed, the signature

verification will still process the <soap:header> within the<wrapper> element, since the signature still contains theoriginal SOAP Body, that was signed by the sender of themessage. The SOAP message is then parsed to the applicationlogic, that processes the SOAP body and ignores all otherSOAP elements.

B. XXE Attacks

One major aspect of SAML-based authentication is the us-age of XML (Extensible Markup Language) for request andresponse messages. XML is one of the oldest formats usedin the world wide web. It was first introduced, almost twentyyears ago, by the W3C Consortium. Back then, XML wasseen as a simple text-based format for representing structuredinformation. As the usage of XML and overlaying file formatsincreased, the W3C introduced a new functionality, calledexternal entities. In theory, entities are used to assign names toreusable chunks of text, which can be declared by entities inXML data. One powerful aspect of the described entities is theability to include foreign sources into XML. This functionalityallows developers to outsource XML information, and, ifneeded, include them without having to store them on the samedevice. This functionality, although helpful in some cases,leads to the possibility of an attack, which is called XXE(External Entity Attack). In this kind of attack, an attacker cre-ates a specially crafted XML document, containing a referenceto an external entity, which is processed by an ill-configuredXML parser. The fundamental problem with parsers is, thatexternal entity processing is enabled by default. So, whetherit is used or not, the parser processes the entities. The securityrisk, however, is limited to requests, where attackers are ableto interact with any kind of XML requests.A typical attack scenario is demonstrated subsequently:

Listing 3. XXE Example<?xml v e r s i o n =”1.0” e n c o d i n g=”ISO�8859�1”?><!DOCTYPE t e s t i n g x x e [<! ENTITY name System ” c :\ boo t . i n i ”>]><Prod>

<Prod><Type>Hochschu le Fur twangen</ t y p e><name>XXE T e s t</ name><i d>&name</ i d>

</ Prod></ Prod>

As seen in the listing above, an additional doctype and entityelement has been set to the original request. This requestwill be processed, if external entities are not disabled. Theparser requests the external entity and processes the SYSTEM

namespace, which requests the file c :boot.ini. Once the fileis requested, it is referenced with the name attribute at theresponse context.Figure 3 shows the attack flow of the XXE scenario. Usingthis method an attacker is capable to exfiltrate sensitivefiles from the server by abusing external entities. Thisattack, however, only works, if the XML output is reflectedsomewhere in the page content. If there is no direct reflectionof XML, a verbose error message discloses the attack.

130

Figure 3. XXE Attack Example [14]

C. XXE OOB

A new technique, called XXE OOB (External Entity AttackOut of Bounds), allows an attacker to exploit certain scenarioswherein there is no direct reflection of the XML output. Thisworks by defining an external entity on a remote destination.

Listing 4. XXE OOB Example<?xml v e r s i o n =”1.0” e n c o d i n g=”ISO�8859�1”?><!DOCTYPE xxeoob [<!ENTITY % d t d SYSTEM ” h t t p : / / 1 4 1 . 2 8 . 6 8 . 2 4 3 : 8 0 8 0 / p a y l o a d . d t d ” >

%d t d ;]><Prod>

<Prod><Type>T e s t</ t y p e><name>Hochschu le Fur twangen</ name><i d>21</ i d>

</ Prod></ Prod>

This attack works by defining a new document type anddeclaring an additional dtd (Document Type Definition) fileon a remote server. A dtd document represents a structureof legal elements and attributes of XML documents [19].By adding the external entity on a remote server, the XMLparser follows the link and processes the document type. Inthis attack scenario, the document type contains the followinginstructions:

<!ENTITY % d a t a SYSTEM ” f i l e : / / / e t c / passwd ”><! ENTITY % param1 ”<!ENTITY e x f i l SYSTEM ’ h t t p : / / 1 4 1 . 2 8 . 6 8 . 2 4 3 : / ? % d a t a ;’>”>

The instructions execute exfil in the SYSTEM namespace toget the content of the well-known Unix file etc/passwd. In asecond step, the content of the file is appended as an URI tothe server the attacker controls. The web server is receivingthe content of the file. By using this technique an attacker iscapable to exfiltrate files from the server.

VI. SECURITY ASSESSMENT OF SAMLThe SAML 2.0 Web Browser SSO Profile is widely usedin Single Sign On applications across the web. It has beenimplemented in various tools and open source libraries, suchas OpenSAML [12].Over the years, a few security vulnerabilities have been foundin a series of SAML implementations (cf. Section V).

Whereas XXE is not directly affecting SAML, but XML, itdoes demonstrate the risks that must be considered in SAMLimplementations. XSW, on the other hand, is directly affectingSAML and has been found in many SAML tools and libraries.OpenSAML, for example, has been vulnerable to both attacks,XXE and XSW, in the past [11], [13].The fact that some vulnerabilities have been found in exam-ple code, provided by OpenSAML, shows how difficult theimplementation of SAML 2.0 Web Browser SSO can be [11].However, while vulnerabilities have been detected in the past,solutions have also been presented [2], [8], [5].Various considerations, concerning SAML security, can befound online, for example in [2] and [8].While assessing an implementation of SAML several ques-tions should be asked to ensure a correctly working SAMLmechanism. These should include [18]:

• If an SAML message is signed, what happens if thecontent is changed?

• If it is accepted, what happens if the signature is re-moved?

• Does it accept re-signing with a different certificate?

Following the instructions in [2] and [8], and consideringthe aforementioned questions, leads to an overall secureimplementation of SAML.Therefore, SAML can be considered secure. To avoidvulnerabilities in implementations developers mustmeticulously follow the described good practice.

VII. SINGLE SIGN ON IN MICROSOFT OFFICE 365In Microsoft Office 365 Microsoft used a combination ofWS-Trust and SAML 2.0 Web Browser SSO to implementSingle Sign On on the Office platform.As discussed in [4], this implementation allowed malicioususers to exploit the cross-domain authentication (cf. Section I).This section discusses the implementation of WS-Trust andSAML as used for the platform’s Single Sign On.

A. SAML Implementation

To use Single Sign On, the user must be registered inAzure AD for the specific tenant. The authentication processstarts with a request to the SP by accessing the Office365 portal and sending an authentication request to theportal. The SP then checks, whether the domain, providedby the user, is known and registered as federated in AzureAD, and sends an <AuthnRequest> to the IdP (see Listing 5).

Listing 5. AuthnRequest message from Microsoft Office 365 [4]<samlp : AuthnReques t xmlns : samlp=” urn : o a s i s : names : t c :SAML: 2 . 0 : p r o t o c o l ”xmlns : saml=” urn : o a s i s : names : t c :SAML: 2 . 0 : a s s e r t i o n ”ID=” f6dae f39�fb54�407e�abb4�c75d261b75ae ”I s s u e I n s t a n t =”2016�04�11T21 : 1 3 : 4 4 Z”V e r s i o n =” 2 . 0 ”A s s e r t i o n C o n s u m e r S e r v i c e I n d e x =” 0 ”>

<saml : I s s u e r>urn : f e d e r a t i o n : M i c r o s o f t O n l i n e</ saml : I s s u e r><samlp : NameIDPolicy Format=” urn : o a s i s : names : t c :SAML: 2 . 0 : nameid�f o r m a t : p e r s i s t e n t

” /></ samlp : AuthnReques t>

131

When the user has sent an authentication request to the IdP,the IdP identifies the user and sends a <Response> messageback to the SP. To identify the user, the following attributes arereleased to the SP by the IdP within the <Response> message(see Listing 6):

• The IDPEmail, containing the domain of the user’s IdP• An ImmutableId to uniquely identify the user

Listing 6. Response message from Microsoft Office 365 [4]<saml2p : Response D e s t i n a t i o n =” h t t p s : / / l o g i n . m i c r o s o f t o n l i n e . com / l o g i n . s r f ”ID=” c e f c 5 f 9 9 2 f 2 e 4 5 5 d 7 b 3 e 5 2 5 2 2 f c 4 7 9 d b ” InResponseTo =” f6dae f39�fb54�407e�abb4�

c75d261b75ae ”I s s u e I n s t a n t =”2016�04�11T21 : 1 4 : 3 5 . 3 6 5 Z” V e r s i o n =” 2 . 0 ” xmlns : saml2p=” urn : o a s i s :

names : t c :SAML: 2 . 0 : p r o t o c o l ”xmlns : xsd=” h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema”>

<saml2 : I s s u e r xmlns : saml2=” urn : o a s i s : names : t c :SAML: 2 . 0 : a s s e r t i o n ”>h t t p s : / / i d p . admin . g r n e t . g r / i d p / s h i b b o l e t h

</ saml2 : I s s u e r><ds : S i g n a t u r e xmlns : ds=” h t t p : / / www. w3 . org / 2 0 0 0 / 0 9 / xmlds ig # ”>

[ . . . ]<saml2 : S u b j e c t>

<saml2 : NameID Format=” urn : o a s i s : names : t c :SAML: 2 . 0 : nameid�f o r m a t :p e r s i s t e n t ”>

Thi s i s where my Immutab le Id i s</ saml2 : NameID><saml2 : S u b j e c t C o n f i r m a t i o n Method=” urn : o a s i s : names : t c :SAML: 2 . 0 : cm : b e a r e r

”><saml2 : S u b j e c t C o n f i r m a t i o n D a t a Address =” 2 a02 :214 d :811 b : 7 2 0 0 : dc15 :

b7bc : a304 :3738 ” InResponseTo =” f6dae f39�fb54�407e�abb4�c75d261b75ae ”

NotOnOrAfter=”2016�04�11T21 : 1 9 : 3 5 . 3 8 4 Z” R e c i p i e n t =” h t t p s : / / l o g i n .m i c r o s o f t o n l i n e . com / l o g i n . s r f ”

/></ saml2 : S u b j e c t C o n f i r m a t i o n>

</ saml2 : S u b j e c t><saml2 : C o n d i t i o n s NotBefore =”2016�04�11T21 : 1 4 : 3 5 . 3 6 5 Z” NotOnOrAfter=”

2016�04�11T21 : 1 9 : 3 5 . 3 6 5 Z”><saml2 : A u d i e n c e R e s t r i c t i o n>

<saml2 : Audience>urn : f e d e r a t i o n : M i c r o s o f t O n l i n e

</ saml2 : Audience></ saml2 : A u d i e n c e R e s t r i c t i o n>

</ saml2 : C o n d i t i o n s><saml2 : A u t h n S t a t e m e n tA u t h n I n s t a n t =”2016�04�11T21 : 1 4 : 3 5 . 0 2 7 Z”S e s s i o n I n d e x =” 91380d0480ac9a f6bcb19f3b26f0ea81 ”>

<saml2 : S u b j e c t L o c a l i t y Address =” 2 a02 :214 d :811 b : 7 2 0 0 : dc15 : b7bc : a304 :3738 ”/>

<saml2 : AuthnContex t><saml2 : A u t h n C o n t e x t C l a s s R e f>

urn : o a s i s : names : t c :SAML: 2 . 0 : ac : c l a s s e s : P a s s w o r d P r o t e c t e d T r a n s p o r t</ saml2 : A u t h n C o n t e x t C l a s s R e f>

</ saml2 : AuthnContex t></ saml2 : A u t h n S t a t e m e n t><saml2 : A t t r i b u t e S t a t e m e n t>

<saml2 : A t t r i b u t e Fr iendlyName =” IDPEmail ”Name=” IDPEmail ”NameFormat=” urn : o a s i s : names : t c :SAML: 2 . 0 : a t t r n a m e�f o r m a t : u r i ”>

<saml2 : A t t r i b u t e V a l u e xmlns : x s i =” h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema�i n s t a n c e ”

x s i : t y p e =” xsd : s t r i n g ”>

ikakavas@mymail . example . com</ saml2 : A t t r i b u t e V a l u e>

</ saml2 : A t t r i b u t e></ saml2 : A t t r i b u t e S t a t e m e n t>

</ saml2 : A s s e r t i o n></ saml2p : Response>

B. WS-Trust Implementation

The implementation of WS-Trust is not isolated from theWeb Browser SSO implementation. The IdP, as implementedfor the Web Browser SSO, simultaneous works as a SecurityToken Service by internally converting SAML messages toWS-Trust messages [4]. Therefore, the WS-Trust token is notgenerated explicitly. Instead, the SAML message is merelytranslated into a WS-Trust token, which leads to a crucialflaw in this implementation (cf. Section VII-C).

C. Flaws in Microsoft Office 365 Implementation

The implementation, as it is described above, shows severaldeficits from a security perspective.

Even though the ImmutableId within the Subject element ofthe <Response> message uniquely identifies the user issuingthe authentication request, the Service Provider disregards theSubject of the Assertion upon arrival.Therefore, the user can only be identified via the IDPEmail,provided within the AttributeStatement element. Whereas theSP uses the Issuer element to verify the SAML Response byretrieving the corresponding certificate, it does not check thevalue of the IDPEmail attribute against the IdP, that issuedthe original request. Thus, neither the token content nor theIDPEmail is checked against the IdP, enabling the exploitationof the cross-domain authentication [4].Additionally, the obtained security token is forwarded toWS-Trust, in case the user chooses a different SSO methodthan SAML SSO. Therefore, the vulnerability’s scope exceedsusers federating their domains via SAML, including usersfederating their domains via Active Directory FederationsServices (ADFS) [4].

D. Exploitation

The above-mentioned flaws lead to a serious vulnerabilitythat can be exploited by copying the victim’s email to anotherOffice 365 subscription [4] and changing the provided usercredentials at the second login form.The victim’s email address must be known to the maliciousIdentity Provider to successfully log in to the account, whenprompted with a login form. Thus, in a first step, the emailmust be copied to the directory of the attacker’s Office 365subscription. Figure 4 shows the process of the attack afterthe prerequisites are met.First, the attacker requests access to the Office 365 portalthrough a web browser. Using the attacker’s domain,something@attacker.com, to log in, he is redirected to theattacker’s Identity Provider and prompted with another loginrequest.At this point, the attacker can use any user credentials thatare known to the IdP to log in. Therefore, the attacker canchange the previously set email (something@attacker.com) tosomething@victim.com and log in successfully.Having logged in successfully, the attacker is redirected tothe victim’s Office 365 portal, where he has access to thevictim’s files, account information, and Office applications.This attack is successful, because the provided email addressesused for the first and second login are not evaluated againsteach other (cf. Section VII-C).

E. Assessment of the vulnerability

Having analyzed the flaws in Microsoft’s Office 365 SAMLimplementation and discussed an exploit, resulting from these,this section focuses on the assessment of the aforementionedvulnerabilities.Although a few security vulnerabilities in SAML have beendiscovered in the past (cf. Section V), the vulnerabilities inMicrosoft’s Office 365 implementation did not originate from

132

Figure 4. Flowchart of the attack (The attacker’s actions are marked blue,and the application’s processes are marked yellow)

any general SAML vulnerabilities.Furthermore, the flaws in the implementation described above(cf. Section VII-C) could have been avoided by followingwell-known security standards, that are described in [8].First Mile Considerations [2] were disregarded, because theIdP was not validated.Furthermore, Last Mile Considerations [2] were disregarded,because the user identity obtained from the SAML ticketassertions was not verified by the Service Provider.

VIII. CONCLUSION

SAML is used in various companies and products as a SingleSign On solution. When security vulnerabilities were foundin the Microsoft Office 365 SAML implementation, it raisedthe question whether this vulnerability was caused by SAMLor Microsoft’s implementation.Taking a closer look at SAML implementations and itshistory of known security vulnerabilities, it could be assessedthat SAML can be considered secure, if established securitystandards are met.In addition to this, it could be shown, that Microsoft’simplementation of a custom SAML 2.0 Web Browser SSOhas been disregarding some of these security standards,such as validation of the security token against the IdentityProvider. Furthermore, the combination of SAML with WS-Trust caused an even more serious vulnerability by extendingthe scope of the attack. Because WS-Trust tokens weresimply translated from SAML messages, the vulnerability inthe SAML implementation did affect all federated accountsof Microsoft Office 365.In conclusion, it could be assessed, that the cause of thesecurity vulnerability in Microsoft Office 365 lay exclusivelyin a flawed implementation of SAML 2.0 Web BrowserSSO, and was not related to any general flaws in the SAMLspecification.

REFERENCES

[1] Benjamin Sanno https://www.nds.rub.de/media/ei/arbeiten/2014/12/04/

SAMLAttacker.pdf, Ruhr Universitat Bochum. Ruhr Unvierstitat Bochum6, 2013.

[2] B. Broulik, P. Krawczyk, G. Peterson, and J. McGovern, “Samlsecurity cheat sheet - owasp,” 31.01.2017. [Online]. Available:https://www.owasp.org/index.php/SAML Security Cheat Sheet

[3] D. Krafzig and M. Yunus, “Anwendungssicherheit saml– eine einfuhrung - jaxenter,” 2015. [Online]. Available:https://jaxenter.de/anwendungssicherheit-saml-eine-einfuehrung-18066

[4] I. Kakavas, “The road to hell is paved with saml assertions,” 06.06.2016.[Online]. Available: http://www.economyofmechanism.com/office365-

authbypass.html

[5] MCINTOSH, M., AND AUSTEL, P. XML Signature Element Wrapping

Attacks and Countermeasures. In SWS ’05: Proceedings of the 2005workshop on Secure web services (New York, NY, USA, 2005) ACMPress, pp. 20–27

[6] OASIS, “Profiles for the oasis security profiles for the oasis securityassertion markup language (saml) v2.0,” 15.03.2005. [Online]. Available:https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

[7] OASIS, “Security Assertion Markup Language (SAML) V2.0 Tech-nical Overview,” 09.10.2006. [Online]. Available: http://www.oasis-

open.org/committees/documents.php?wg abbrev=security

[8] OASIS, “Security and Privacy Considerations for the OASIS SecurityAssertion Markup Language (SAML) V2.0,” 15.03.2005. [Online]. Avail-able: http://docs.oasis-open.org/security/saml/v2.0/

[9] OASIS, “Ws-trust 1.4,” 25.04.2012. [Online]. Available: http://docs.oasis-

open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-

complete.html# Toc325658922

[10] ServiceNow, “Servicenow wiki:saml 2.0 webbrowser sso profile,” 23.01.2017. [Online]. Available:http://wiki.servicenow.com/index.php?title=SAML 2.0 Web Browser SSO

Profile#4. Validate SAMLResponse&gsc.tab=0

[11] SendSafely, “Web-based single sign-on and the dangers of samlxml parsing.” [Online]. Available: https://blog.sendsafely.com/web-based-

single-sign-on-and-the-dangers-of-saml-xml-parsing

[12] Shibboleth Consortium, “Opensaml-java,” 06.01.2017. [Online]. Avail-able: https://shibboleth.net/products/opensaml-java.html

[13] Somorovsky,Mayer; Kampmann,Jensen, On Breaking SAML: Be Who-

ever You Want to Be, IBM Zurich Research Laboratory. Usenix SecuritySymposium 12, 2003.

[14] Somorovsky, Juraj, “Webservices und Single Sign-On: XML-basierte Angriffe im Uberblick” 29.06 2015 [Online]. Availabe:https://www.informatik-aktuell.de/betrieb/sicherheit/webservices-und-

single-sign-on-xml-basierte-angriffe-im-ueberblick.html

[15] Thomas Groß, Security Analysis of the SAML Single Sign-on

Browser/Artifact Profile, IBM Zurich Research Laboratory. UsenixSecurity Symposium 12, 2012.

[16] T. Hardjono, H. Lockhart, and S. Cantor, “Oasis security ser-vices (saml) tc — oasis.” [Online]. Available: https://www.oasis-

open.org/committees/tc home.php?wg abbrev=security

[17] “XML Signature Wrapping ” 23.12.2015 [Online]. Available:http://www.ws-attacks.org/XML Signature Wrapping

[18] “Bypassing SAML 2.0 SSO with XML Signature Attacks”30.11.2016[Online]. Available: http://research.aurainfosec.io/bypassing-saml20-

SSO/

[19] “DTD Tutorial” [Online]. Available:https://www.w3schools.com/xml/xml dtd intro.asp

[20] “Autoloaded File Inclusion in Magento SOAP API” [Online]. Available:http://blog.mindedsecurity.com/2015/09/autoloaded-file-inclusion-in-

magento.html

133

1

Sandbox-Detection-Angriffe gegen den AndroidEmulator

Hermann Weisenmüller, HFUFabian Berner, HFU

Friedbert Kaspar, HFU

Zusammenfassung—Schadsoftware zählt seit vielen Jahren zuden wichtigsten Sicherheitsrisiken der IT im geschäftlichen undprivaten Bereich. Malware-Scanner prüfen deshalb Android-Apps in Bezug auf bösartiges Verhalten. Eine gängige Methodeist die automatisierte, dynamische Analyse in einer Sandbox. Umnicht erkannt zu werden, versucht ein hochentwickelter Schad-code die Sandbox-Umgebung zu erkennen und verschleiert oderdeaktiviert seine Schadfunktion in diesem Fall. Dadurch könnenTestsysteme die Schadsoftware oft nicht erkennen. Dieses Arbeitgibt einen Überblick über die gängigen Methoden zur Sandbox-Detection. Methoden zur Erkennung des Android Emulatorswerden vorgestellt und bezüglich ihrer Zuverlässigkeit bewertet.

I. EINLEITUNG

In den letzten Jahren hat die Smartphone-Benutzung stetigzugenommen. Das Smartphone hat den PC als wichtigstesAngriffsziel abgelöst. Waren es 2010 noch 300 Millionenverkaufte Smartphones, stieg die Anzahl im Jahr 2015 auf 1,4Milliarden abgesetzte Geräte (vgl. [Sta]). Android hat dabeieinen Marktanteil von ca. 80-90% und ist somit das am meis-ten verbreitete Betriebssystem für Smartphones und Tablets(vgl. [IDC]). Jedoch ist Android durch seine Popularität undVerbreitung auch zum Ziel von Angreifern geworden.

Eine gängige Angriffsvariante ist die Installation einer Soft-ware als Trojanisches Pferd (vgl. [AT], S.10). Ein TrojanischesPferd bietet eine scheinbar nützliche Funktionalität und ver-steckt dabei seine Schadfunktion vor dem Benutzer des Mo-bilgerätes. Kostenpflichtige Apps aus dem Google Play Storewerden durch einen Angreifer mit Schadfunktionen versehenund als scheinbar kostenlose Kopie über einen ungesichertenDrittanbieter App-Store angeboten.

Smartphones sind interessante Angriffsziele für Cyber-Kriminelle, da sich auf ihnen oft sensible Daten des Usersbefinden. So können Angreifer durch den Zugriff auf einSmartphone Schäden anrichten, die bei PCs bisher nicht odernur schwerer möglich waren.

Beispiele für Schadfunktionen sind:• Gebühren verursachen durch SMS an kostenpflichtige

Premiumanbieter• Sammeln von Kontakt- und Ortsinformationen• Diebstahl von Audio- und KameradatenEin wichtiger Faktor der die Abwehr von Schadsoftware auf

mobilen Geräten erschwert, sind die begrenzten Ressourcen,wodurch nur selten zusätzliche Sicherheitssoftware verwendetwird.

A. MotivationAngreifer nutzen Androids offene Plattform, um Schadsoft-

ware über offizielle und inoffizielle Wege an eine möglichstgroße Nutzergruppe zu verteilen. Oft reicht dabei jedochdie Installation von Malware-Scannern nicht aus, da diesehauptsächlich bereits bekannte Schadprogramme erkennen.Unbekannte Apps zur Laufzeit durch eine Verhaltensanalysezu erkennen, ist deutlich aufwendiger und benötigt mehrSystemressourcen wie Speicher, Prozessorzeit und dadurchauch mehr Energie aus dem Akku des mobilen Geräts.

Einige dynamische Sicherheitssysteme basieren aufSandbox-Umgebungen wie dem Android Emulator, mit demes möglich ist, Apps ohne physisches Gerät auszuführen undzu testen. Für potenzielle Schadsoftware ist es wichtig, dieAusführung in einer Sandbox zu erkennen, um so der Analysezu entgehen. Dazu prüfen Angreifer typische Eigenschafteneines Gerätes und entscheiden auf dieser Basis, ob die Appin einer Sandbox ausgeführt wird oder nicht. Erkennt dieMalware, dass sie sich auf einem Opfersystem befindet, wirder Schadcode ausgeführt.Eine bekannte Android-Malware, die die Aufmerksamkeitvieler Forscher erregte, war OBAD. OBAD hat eine breitePalette an Schadfunktionen implementiert und wurde zu jenerZeit nach der Enttarnung durch den SicherheitsdienstleisterKaspersky Lab im Jahr 2013 als bis dahin komplexestesSchadprogramm für Android eingestuft[Kas]. Die App hat 24Berechtigungen (App Permissions) erfordert. Sie konnte ohneKenntnis des Benutzers beispielsweise den Netzwerkstatusändern, SMS lesen und senden oder sogar Telefonanrufetätigen. Der Entwickler dieses Schadprogrammes hatmehrere Techniken implementiert, um im Analyseprozessnicht entlarvt zu werden. Die Malware hat dazu versuchteine Sandbox-Umgebung zu erkennen, indem der Wertandroid.os.build.MODEL mit dem Wert verglichenwurde, der üblicherweise vom Android Emulator verwendetwird. Zusätzlich wurden Verschleierungsmethoden (engl.obfuscation techniques) eingesetzt, um die statische Analysezu erschweren (vgl. [Sol]).

B. Zielsetzung und Abgrenzung der ArbeitIn diesem Paper sollen Methoden gesammelt und bewertet

werden, die zur Erkennung von Sandbox-Umgebungeneingesetzt werden können. Wir werden zeigen, dass derAndroid Emulator durch einfachste heuristische Methodenerkannt werden kann. Auch wenn der Fokus in dieser Arbeit

135

2

auf dem Android Emulator liegt, können die vorgestelltenTechniken auch auf andere Sandbox-Umgebungen übertragenwerden. Als proof of concept wurde eine Android-Appimplementiert werden, die einige der vorgestellten Methodenzur Sandbox-Erkennung implementiert.

In diesem Paper werden die folgenden Fragen beantwortet:• Wie kann der Android Emulator mittels heuristischer

Methoden durch Angreifer identifiziert werden?• Welche Merkmale (fingerprints) hinterlassen virtuelle

Umgebungen im Android-System?• Welche Möglichkeiten gibt es, die Erkennung einer

Sandbox-Umgebung zu erschweren?

II. GRUNDLAGEN

A. Sandboxing als Anti-Malware-Werkzeug

Malware-Scanner verwenden verschiedene Methoden, umbekannte und unbekannte Malware zu erkennen. Grundsätzlichkann zwischen der signaturbasierten und verhaltensbasier-ten Analyse unterschieden werden. Bei der signaturbasiertenAnalyse wird das Schadprogramm nach bekannten Musterndurchsucht, die in einer Signatur definiert sind. Der Vorteildieser Analyseform ist – je nach Güte der Signaturen – diehohe Zuverlässigkeit der Analyseergebnisse. Die Schwäche istallerdings, dass nur bekannte Schadsoftware erkannt werdenkann, für die eine Signatur entwickelt wurde.

Die verhaltensbasierte Analyse von Schadprogrammen be-obachtet das Verhalten des Programmes während der Laufzeit.Der Vorteil daran ist, dass auch unbekannte Malware erkanntwerden kann. Malware-Scanner setzt dabei unter anderemheuristische Erkennungsmethoden ein. Das Programm wirdzur Überwachung oftmals in einer Sandbox ausgeführt. Nebenden Malware-Scannern werden Sandbox-Umgebungen auchfür weitere Sicherheitssysteme verwendet. Beispielsweise dieAndroid Application Sandbox zur Trennung der laufendenApplikationen auf einem Android System.

Ein wichtiges Ziel von Sandbox-Umgebungen die auf Si-cherheitssystemen basieren ist, nicht von einer möglichen Mal-ware erkannt zu werden. Hersteller von Sicherheitssoftwarereagieren mit immer neuen Abwehrmethoden auf die Sandbox-Erkennungsversuche von Malware-Entwicklern. Es wird ver-sucht die typischen Charakteristika eines echten Endgerätesmit einem Benutzer bspw. durch simulierte Interaktion mitdem Programm vorzutäuschen. Da die Emulation einer Aus-führungsumgebung jedoch allgemein ein komplexes Problemdarstellt, findet intelligente Malware immer wieder neue Wege,eine Sandbox zu erkennen (vgl. [DNS]) und zu umgehen.Die Sandbox-Detection ist kein neues Thema. Sie wird vonAngreifern seit Jahren angewandt. Die Erfüllung der Anforde-rung, die Sandbox-Umgebung zu verschleiern, ist bei Androidbesonders komplex, da Android durch seinen sensorbasiertenund ereignisgesteuerten Aufbau hier eine besondere Heraus-forderung darstellt. Intelligente Malware kann auf eingehendeAnrufe, Standortänderungen etc. reagieren. Diese Aspekteerfordern komplexere Werkzeuge, um Schadprogramme mitintegrierter Sandbox-Detection zu erkennen.

B. Android EmulatorDer Emulator basiert auf dem Open-Source-Projekt Quick

Emulator (QEMU). QEMU bildet die komplette Hardwareeines Computers oder – im Falle des Android Emulators –ein Smartphone nach. Da in mobilen Geräten wie Smart-phones und Tablets hauptsächlich ARM-Prozessoren verbautwerden, muss QEMU die ARM-Prozessorarchitektur emulie-ren. Aus Performance-Gründen werden aber auch x86-basierteAndroid-Images bereitgestellt die durch die wegfallende Emu-lation deutlich schneller ausgeführt werden können.

III. SANDBOX-DETECTION-METHODEN

Intelligente Schadprogramme versuchen der Analyse zuentgehen, indem sie prüfen, ob sie in einer kontrolliertenUmgebung (Sandbox) ausgeführt werden. Die in der Literaturdiskutierten Ansätze basieren auf den folgenden Methoden[GST+15], [JZAH14], [Blu], [VC14]:

a) Die Sandbox abwarten (Sleep)b) Die Sandbox-Umgebung (VM) erkennenc) Die Präsenz eines realen Users prüfen

a) Die Sandbox abwarten: Malware-Scanner müssengroße Datenmengen analysieren und sollten dabei möglichstwenig Systemressourcen verbrauchen. Wie Oberheide (vgl.[Obe]) in seinen Untersuchungen nachweist, werden bspw.Apps, die in den Google Play Store hochgeladen werdennur in den ersten fünf Minuten durch den Google Bounceranalysiert. Angreifer nutzen dies aus, indem die Ausführungdes Schadcodes für eine bestimmte Zeit verzögert wird. Daeinige Sandbox-Systeme während der statischen Analyse denCode auf lange Sleep-Calls prüfen, kombinieren die Entwick-ler lange mit kurzen, sich wiederholenden Sleep-Calls (vgl.[Blu]). Da einzelne lange Sleeps (bspw. 1 * 600 Sekunden = 10Minuten) auffällig sind und unter Umständen erkannt werdenkönnen, setzen Angreifer eher auf wiederholende kurze Sleeps(z.B. 600.000 * 1 Millisekunde = 10 Minuten). Bei dieserMethode handelt es sich nicht zwangsläufig um eine Sandbox-Erkennung, jedoch wird sie von Angreifern oft genutzt undkann auch mit Sandbox-Detection-Methoden kombiniert wer-den.Als Gegenmaßnahme verändern manche Anti-Malware-Systeme die Systemzeit, sodass die verzögerte Schadfunktionausgelöst wird.

b) Die Sandbox-Umgebung erkennen: Die Methoden zurSandbox-Detection können in drei Kategorien eingeordnetwerden (vgl. bspw. [PVA+14]). Bei den ersten zwei Kate-gorien handelt es sich um Methoden, die Sandbox durchstatische und dynamische Heuristiken zu erkennen. StatischeHeuristiken basieren auf Informationen im System, die sichnach der Initialisierung nicht mehr ändern. Dazu gehört z.B.die IMEI des Gerätes. Dynamische Informationen, wie dasVerhalten der Sensoren oder die Performance, werden derzweiten Kategorie, den dynamischen Heuristiken, zugeordnet.Die dritte Kategorie beinhaltet Methoden, die als Context-Awareness bezeichnet werden.

Alle drei Methoden versuchen Unterschiede zwischen dervirtuellen Umgebung und einem realen Opfergerät zu finden.Das Emulieren von Smartphones stellt allgemein eine große

136

3

Herausforderung dar: Moderne mobil Geräte bieten eine stetigsteigende Anzahl an Hard- und Softwarefeatures. Mit dieserschnellen Entwicklung der Geräte können Emulatoren nichtmithalten und bieten deshalb zum jetzigen Stand nicht alleMöglichkeiten eines echten Gerätes. Dadurch hinterlassenEmulatoren typische Fingerprints im emulierten System (vgl.[Pal09]). Die Echtheit der simulierten Hardwarekomponentenim Emulator kann in den meisten Fällen geprüft werden,indem über die System-API die dynamische Werte abgefragtund auf geprüft werden.

c) Die Präsenz eines realen Users testen: Smartphonesbieten dem User viele Möglichkeiten der Interaktion mit derApp. Da eine Malware-Analyse in einer Sandbox im Nor-malfall voll automatisiert abläuft, muss der App ein Benutzervorgetäuscht werden. Hierfür kann bspw. das Tool Monkey1

eingesetzt werden. Aber es sind nicht nur Eingaben auf demTouchscreen, die einen realen User ausmachen. Auch andereEvents, die typisch für den täglichen Gebrauch des Smartpho-nes sind, können die Schadfunktion auslösen. Beispielsweiseein Systemneustart oder das Anschließen von Kopfhörern andas Smartphone. Malware, die nur durch Eintreten bestimmterEreignisse ihre Schadfunktion entfaltet, wird in der Forschungoft als Context-Aware Malware bezeichnet.

IV. STATISCHE HEURISTIKEN

Nach einer Untersuchung (vgl. [HX]) hatten im Jahr 2013nahezu 50% der Apps im Google Play Store ein Anti-Emulator-Verhalten. Dieses Verhalten wird zum größten Teilin Apps und Bibliotheken wie Facebook, Twitter, PayPal etc.beobachtet. Hierbei handelt es sich nicht zwangsweise umMalware, sondern um normale Apps. Bei der untersuchtenMalware wurde bei 19% der Samples ein Anti-EmulatorVerhalten festgestellt. Die Auswertung der Ergebnisse von[HX] belegt, dass die statischen Werte der Build-Klasse amhäufigsten für die Sandbox-Detection missbraucht werden.Methoden, die System-Properties nutzen, sind weniger zufinden, jedoch steigt ihre Anzahl stetig.

A. Geräte ID und TelefonieDas android.telephony-Paket bietet Funktionen zum

monitoring telefoniebezogener Informationen, dem Versandvon SMS-Nachrichten und der Verarbeitung von Telefon-nummern (vgl. [Tel]). Mithilfe des TelephonyManagerskönnen Informationen wie z.B. Cell Location, IMEI (auchGeräte ID) und Network Provider abgerufen werden. Dader Zugriff auf diese Daten durch den Benutzer bestätigtwerden muss, muss die Permission READ_PHONE_STATEim Android Manifest eingetragen sein. Tabelle I zeigt eineÜbersicht aus der TelephonyManager-API.Die IMEI eines Mobiltelefons dient als einzigartige Se-riennummer für das Gerät und kann mit der FunktionTelephonyManager.getDeviceId() abgefragt wer-den. Besteht der Rückgabewert aus fünfzehn Nullen, ist dieaktuelle Instanz mit Sicherheit eine Sandbox. Die Methode inZeile 2 gibt die Telefonnummer des Gerätes zurück. Im Falle

1https://developer.android.com/studio/test/monkey.html

Tabelle IAUSGABEWERTE DER TELEPHONYMANAGER-METHODEN IM EMULATOR

1 getDeviceId() 0000000000000002 getLine1Number() 155552155xx3 getNetworkOperator() 3102604 getNetworkOperatorName() Android5 getNetworkCountryIso() us6 getNetworkType() 137 getPhoneType() 18 getSimSerialNumber() 890141032111185107209 getSubscriberId() 310260000000000

10 getVoiceMailNumber() 15552175049

eines Emulators beginnt sie immer mit 1555521 und endetmit 55xx, wobei sich die letzten vier Ziffern aus dem Portergeben, den der Emulator von der Android Debug Bridge(ADB) zugewiesen bekommt (vgl. [VC14]). Android ist keinNetzbetreiber, deswegen ist der Wert in Zeile 4 ebenfalls einIndiz für den Emulator.

Bewertung: Sicherheitssysteme versuchen, die verwen-dete Sandbox wie ein reales Gerät aussehen zu lassen. Des-wegen sollten realistische Werte, wie auf Opfersystemen zu-rückgegeben werden. Da Smartphones in den meisten Fällenauch mit einer SIM-Karte betrieben werden, sollte auch dieTelefonnummer, der Netzbetreiber und die damit verbundeneSIM-Serialnummer realistische Werte zurückgeben.

Ein Test in [Wei17] von fünf verschiedenen Sandbox-Umgebungen ergab, dass die IMEI bei allen Sandboxenaußer DroidBox abgeändert wurde. Die typische Emulator-Telefonnummer findet sich nur noch bei APKScan und Dro-idBox. Ebenso wurde festgestellt, dass die SIM-Serialnummernur durch zwei Anbieter verändert wurde. Das ist bei Droid-Analyst und einer unbekannten Sandbox, bei der es sich wahr-scheinlich um ein russisches Sicherheitsunternehmen handelt,der Fall.

Nicht alle Werte in Tabelle I sprechen sofort für einenEmulator. Dies belegen auch weitere Untersuchungen vonVidas et al. zu telefoniebezogenen Daten. Durch die Me-thode TelephonyManager.getNetworkOperator()lässt sich schlussfolgern, dass der Emulator immer Werteausgibt, die den realen Werten von T-Mobile USA entspre-chen. Deswegen können Prüfungen nur dieser Werte falscheErgebnisse liefern (vgl. [VC14]).

B. System-PropertiesÄhnlich der Windows-Registry bietet Android mit

den System-Properties eine zentrale Möglichkeit,Systemkonfigurationen und -status zu speichern.Die System-Properties unterscheiden sich von Gerät zuGerät, beschreiben jedoch immer grundsätzlich gleicheInformationen. Die Werte des jeweiligen Systems können mitdem Befehl adb shell getprop, aber auch über die APIausgelesen werden. Sie bestehen aus einer Liste von Key-Value-Paaren, die wesentliche Informationen über das Gerätenthalten. Die Dateien haben den Zweck, dass Apps Spezifikades Gerätes auslesen können, um Benutzeroberfläche undEinstellungen anzupassen zu können oder um zu prüfen, obdas Gerät den Systemanforderungen der App entspricht.

137

4

Auch zur Erkennung des Android Emulators (bzw. QEMU)können Properties ausgewertet werden. Beispielsweise enthältder Eintrag ro.kernel.qemu a) QEMU im Namen b)den Wert 1 als Value, also TRUE und c) findet sich diesesKey-Value-Paar nicht auf echten Geräten. Ebenso sind dieStrings Android, ranchu, goldfish oder emulatormehrfach zu finden. Weitere Untersuchungen in AbschnittIV-C zeigen, warum es sich bei diesen Werten um Fingerprintsdes Emulators handelt.

Bewertung: Die App Morpheus von Jing et al. [JZAH14]beispielsweise sucht nicht nur nach Werten, die einem Emu-lator zuzuordnen sind, sondern auch Werte, die nur auf echtenGeräten zu finden sind. So konnte er ca. 10.000 Heuristikenfinden, anhand derer Emulatoren oder echte Geräte erkanntwerden können.

C. BuildDie Klasse Build aus dem android.os-Paket extrahiert

einige Werte aus den System-Properties. Sie wird durch dieJava-API von Android bereitgestellt und stellt einige Mem-bervariablen zur Verfügung. Emulatoren haben Build-Wertebasierend auf dem Software Development Kit (SDK), welchezum Erstellen der Emulator-Instanz bzw. des Android VirtualDevice (AVD) verwendet wurde. Smartphones hingegen habenWerte, die auf dem Production Build basieren. Vidas et al.haben gezeigt, dass das Prüfen auf das Vorhandensein vonWerten wie generic, sdk, test-keys etc. bereits genügend präziseErgebnisse liefert, um eine Sandbox zu erkennen. Jedochhaben Experimente mit realen Geräten gezeigt, dass einigeWerte nicht sofort auf einen Emulator schließen lassen. Soist der CPU_ABI-Wert auf Emulatoren armeabi, was einplausibler Wert für alle Geräte mit ARM Prozessor ist (vgl.[VC14]).

Die Variable HARDWARE liefert den Namen des Kernels.Der Android Emulator läuft mit einer virtuellen CPU mit demCodenamen Goldfish. Um ARM64-Emulation zu unterstützen,wurde eine neue Emulator Code-Base mit dem Namen ranchuveröffentlicht, die auf QEMU2 basiert (vgl. [Goo]). Wird beimErstellen der Emulator-Instanz ein x86-System-Image gewählt,gibt das HARDWARE-Feld ranchu aus. Detection-Heuristikenfinden sich auch im Feld MANUFACTURER, das beim AndroidEmulator unknown enthält.

Ebenfalls in der Build-API enthalten ist das FeldBuild.FINGERPRINT, welches einige Klassenvariablen zueinem String zusammenfügt. Der Rückgabewert setzt sich wiefolgt zusammen:BRAND/PRODUCT/DEVICE/BOARD:VERSION.RELEASE/ID/VERSION.INCREMENTAL:TYPE/TAGS

In Tests konnte das Feld in verschiedenen Sandbox-Umgebungen ausgelesen und zur Sandbox-Erkennung einge-setzt werden. Tabelle II zeigt2, dass reale Werte für einigeFelder der Build-API gesetzt wurden. Das System Trend Microverwendet Werte die ein Samsung-Gerät imitieren.Eine weitere Möglichkeit zur Sandbox-Erkennung stellt derSignierungsschlüssel des Android-Betriebssystems dar. Emu-latoren nutzen test-keys, während reale Geräte release-keys

2Die angegeben Fingerprints wurden gekürzt. Vollständig in [Wei17].

Tabelle IIBUILD.FINGERPRINT VERSCHIEDENER SANDBOX-UMGEBUNGEN

Sandbox Fingerprint

Emulator Android/sdk_google_phone_x86/generic_x86:7.0/.../dev-keysEmulator generic/sdk_phone_armv7/generic:5.0.2/.../3079185:eng/test-keysTrend Micro Samsung/full/generic:4.1.1/.../.../test-keysTrend Micro Samsung/unia_x86/vmi:5.1/.../.../test-keysDroidAnalyst generic/Batwing/generic:4.3/.../2.6.38+EXALT:eng/rtlAPKScan Android/full/generic:4.1.1/.../.../test-keysDroidBox generic/sdk_phone_armv7/generic:5.0.2/.../3079185:eng/test-keysGenyMotion generic/vbox86p/vbox86p:5.0/.../genymotion.../test-keysUnbekannt Android-x86/android_x86/x86:5.1.1/.../.../test-keysLG Nexus 4 google/occam/mako:5.1.1/.../.../release-keysGalaxy S5 samsung/.../zeroflte:6.0.1/.../G920FXXS4DPJ5:user/release-keys

Tabelle IIIGOOGLE BOUNCER 2012 VS. 2016

Google Bouncer 2012

BRAND Tmobile SERIAL unknownCPUABI armeabi Phone Number 15555215504CPUABI2 unknown Phone Device 112358132134559HOST android-test- Phone Serial 890141032111185

2.mtv.corp.google.com 10720MANUFACTURER HTC SIM Name T-MobileMODEL T-Mobile myTouch 3G Network Name T-MobilePRODUCT opal

Google Bouncer 2016

BRAND google HARDWARE shamuHOST wped2.hot. BOOTLOADER moto-apq8084-

corp.google.com 71.15MANUFACTURER motorola DEVICE shamuMODEL Nexus 6 FINGERPRINT google/shamu/PRODUCT shamu shamu:6.0.1/MMB29K/

2419427:user/release-keys

Quelle: [Obe], [DLLZ16]

nutzen (vgl. [key]). Eine Suche nach test-keys, genericund Android kann damit bereits die meisten Sandbox-Umgebungen enttarnen.

Bewertung: Die Build-API wird gerne von Angreifern fürDetection-Heuristiken verwendet, wofür auch keine speziellenBerechtigungen nötig sind. Der Zweck der Klasse ist, dasssich Apps besser an das Gerät anpassen können. Dement-sprechend wird die Build-API ebenfalls in vielen Apps ohneSchadfunktion genutzt. Die Verwendung dieser Klasse ist nichtauffällig, allerdings kann eine Malware, die ausschließlichstatische Werte prüft, schnell auffliegen, da sich die Werte mitUpdates des Emulators oder der Android SDK ändern können.

Oberheide [Obe] und Diao et al. [DLLZ16] haben durchTests verschiedene Daten des Google Bouncers herausfin-den können. In Tabelle III werden die Eigenschaften desBouncers im Jahr 2012 und 2016 gegenüber gestellt. Wiedie Ergebnisse zeigen, simulierte der Google Bouncer beimRelease im Jahr 2012 ein HTC Smartphone. Google hatdurch realitätsnahe Werte Detection-Heuristiken verhindert,die versuchen, mithilfe der Build-API und Telefoniewerteneine Sandbox zu erkennen. Die Bouncer Version von 2012hat jedoch Schwachstellen, wie die SimSerialNummer"89014103211118510720"die typisch für Emulatoren ist. Ak-tuell simuliert der Google Bouncer ein Smartphone des Mo-dells Nexus 6. Mit den in diesem Abschnitt gezeigten Heuris-

138

5

tiken könnte die aktuelle Version des Bouncers nicht erkanntwerden.

D. Dateipfade und Pipes

Der Linux Kernel als Basis von Android ist für Speicher-und Prozessverwaltung zuständig und stellt die Schnittstellezur Hardware bereit. Auch das von Android verwendeteDateisystem basiert auf der hierarchischen Baumstrukturvon Linux inklusive der Pseudo-Dateisysteme. Jing et al.hat in [JZAH14] gezeigt, dass auch Informationen aus denbeiden Pseudo-Dateisystemen /proc und /sys verwendetwerden können, um den Android Emulator zu erkennen.Die Sandbox oder das Gerät kann dabei alleine durch dieExistenz der Datei identifiziert werden. Bei der Entwicklungvon QEMU, auf dem der Android Emulator basiert, wurdekeine Möglichkeit geschaffen, die Emulation vor dememulierten Betriebssystem zu verstecken. Durch die Abfrageverschiedener System-Properties oder der Nutzung vonQEMU Pipes (Kommunikationskanal zwischen Host- undGast-System) kann die Emulationsumgebung erkannt werden.

Bewertung: Jing et al. hat sich bei seinen Untersuchun-gen mit der Genauigkeit der gefundenen Heuristiken befasst.Sie wurden dabei in die Kategorien Datei-, API- und Property-Heuristiken eingeteilt. Die besten Ergebnisse haben die da-teibasierten Heuristiken erzielt. Das Gerät oder die Sandboxwurde mit einer Genauigkeit von 97,8% erkannt.

E. Network

Der Android Emulator simuliert ein komplettes Android-Gerät inklusive der Netzwerkkomponenten. Das Emulator-Netzwerk unterscheidet sich jedoch vom Netzwerk auf rea-len Geräten und ist via Software vom Netzwerk des Host-Computers getrennt. Dafür besitzt der Emulator einen vir-tuellen Router mit der IP-Adresse 10.0.2.1, d.h. es laufenzwei Netzwerke auf dem Host-PC. So würde der Localhost,also 127.0.0.1, im Emulator und Host-PC jeweils sich selbstadressieren. Möchte der Emulator eine Verbindung ins Internetherstellen, muss er sich über die IP-Adresse 10.0.2.2 mit demHost-PC verbinden (vgl. [BP15]). Die Netzwerkdaten könnenwährend der Laufzeit mithilfe des NetworkInterfaceund WifiManager im Programmcode gelesen werden. Die-se Methode würde jedoch die Berechtigungen INTERNET,ACCESS_NETWORK_STATE und ACCESS_WIFI_STATEdes Users benötigen. Mithilfe der System-Properties (s. Ab-schnitt IV-B) können Netzwerkinformationen aber auch oh-ne die drei Berechtigungen angefragt werden. Bspw. könn-ten die folgenden Keys ausgewertet werden: [net.dns1],[net.eth0.gw] und [net.gprs.local-ip].Oberheide und Miller konnten zeigen, dass der Google Boun-cer ebenfalls anhand seiner IP-Adresse erkannt werden kann.Da Google den Zugriff auf das Internet während der Analyseerlaubt, konnten die Forscher an netzwerkbezogene Daten ge-langen. Die zurückgelieferten IP-Adressen konnten per WhoIs-Abfrage Google Inc. zugeordnet werden (vgl. [Obe]).

Bewertung: Sandbox-Umgebungen können sich gegenErkennung durch die API schützen. Gajrani et al. [GST+15]hat in seiner Arbeit die Erkennung des Emulator-Netzwerkesmithilfe von Android Run Time Hooking verhindert3. DieMethode kann ebenfalls bei Datei-Heuristiken eingesetzt wer-den, um beim Nutzen der exists()-Methode die Boolean-Rückgabewerte zu ändern, wodurch dann das Schadverhaltender App ausgelöst wird.Es ist fraglich, ob die von Oberheide 2012 beschriebenenMethoden den Google Bouncer heute noch erkennen können.

V. DYNAMISCHE HEURISTIKEN

Moderne Smartphones werden immer performanter undkommen mit einer Vielzahl von Sensoren, die Informationenüber die Geräteumgebung liefern. Der Android Emulator hältmit dieser raschen Entwicklung nicht mit. Angreifer könnendiese Schwäche ausnutzen, um sensor- oder performance-basierte Detection-Heuristiken zu implementieren.

A. SensorenAndroid-Sensoren sind virtuelle Sensoren, die Daten aus

einer Reihe physischer Sensoren bereitstellen. Die physischenSensoren liefern Rohdaten, die vom Prozessor des Smartpho-nes verarbeitet werden. Kombiniert bilden die Sensoren einMikrosystem, das auf die gegenwärtige Situation und die Be-dürfnisse des Nutzers eingeht. Die Android-API unterteilt dieSensoren in drei Kategorien. Motion Sensors (Accelerometer,Gravity Sensor etc.), Position Sensors (Orientation Sensor,Magnetometer etc.) und Environmental Sensors (Barometer,Thermometer etc.). Obwohl es sich bei GPS, Fingerprint-Sensoren und einigen weiteren physischen Komponenten umSensoren handelt, kommunizieren sie über andere Schnitt-stellen mit dem System. Die Sensordaten werden den Ent-wicklern durch das Android-Sensor-Framework bereitgestellt.Beispielsweise können verfügbare Sensoren, Attribute (Ener-gieverbrauch, Auflösung etc.) und generierte Daten ausgelesenwerden (vgl. [Sen]). Laut der Daten von OpenSignal4 sindheute ca. zwei Mrd. Smartphones in Gebrauch, die jeweils15 bis 20 Sensoren besitzen. Pro Smartphone-Generationkommen laut OpenSignal etwa zwei bis drei Sensoren dazu.

1) Anzahl der Sensoren: Android gibt in seinem API Guideeinen Überblick über alle verfügbaren Sensoren. Im Folgen-den wird zum Vergleich zwischen einer AVD (virtualisiertesHardwareprofil im Android Emulator) und einem echten Gerät,ein vordefiniertes Hardwareprofil eines Nexus 4 mit API22 erstellt. Die Sensoren im Emulator wurden mit einemrealen Nexus 4 verglichen, das ebenfalls mit der API 22läuft. Ein Vergleich auf Basis der Android-API FunktionengetMaximumRange(), getPower(), getVersion(),getResolution() und getVendor() zeigt, dass dasechte Gerät auf eine Gesamtanzahl von 14 Sensoren kommt,

3Beim Android Run Time Hooking wird das Verhalten der API dynamischmodifiziert. Rückgabewerte können verändert werden und eine Sandbox-Detection durch die API erschwert.

4OpenSignal is the leading source of insight into the coverage and perfor-mance of Mobile Operators worldwide. Our data is crowdsourced by usersof the OpenSignal app, downloaded over 15 million times, which constantlymonitors the coverage and performance of their mobile connection. [Opea]

139

6

während der Emulator über lediglich 9 Sensoren verfügt.Beim Auslesen der Sensoren finden sich darin bereits einigeDetection-Heuristiken. Bspw. hinterlässt der Emulator Fin-gerprints in Sensornamen wie im Namen des Lichtsensors(Goldfish Light Sensor). Auch ist wieder ist der interne Nameder virtuellen CPU (Goldfish) zu finden, während auf echtenGeräten immer die Marke des Smartphones oder eine Modell-nummer im Namen steht. Vidas et al. [VC14] hat in seinenUntersuchungen bereits die Anzahl der Sensoren in Gerätenund Emulatoren miteinander verglichen. Es wurde festgestellt,dass eine Sandbox bereits an der Anzahl der verfügbarenSensoren erkannt werden kann. Obwohl beispielsweise dasveraltete Motorola Droid nur mit sechs Sensoren ausgestattetist, war es trotzdem möglich, eine Sandbox an der Anzahlihrer Sensoren zu erkennen. Grund dafür ist, dass der AndroidEmulator zu diesem Zeitpunkt nur fünf Sensoren emulierthatte. Durch das Update auf QEMU2 wurde der Emulatorum einige Sensoren erweitert und unterstützt zum jetzigenZeitpunkt neun Sensoren. Um die Forschungsergebnisse vonVidas et al. mit aktuellen Geräten und Emulatoren zu bestäti-gen, wurde die Sensorenliste einiger Geräte ausgelesen und mitdem Emulator verglichen. Als Geräte dienten dazu das Nexus4, ein Galaxy S5 und ein Galaxy S6 Edge. Verglichen wurdees mit dem Emulator mit API 24 und GenyMotion, welcheranders als der Android Emulator auf VirtualBox basiert. Dasälteste Gerät, das Nexus 4, hat mit 14 Sensoren die geringsteAnzahl. Die Geräte der Galaxy-Reihe mit bis zu 17 Sensorenbildeten dagegen das obere Ende.

Auch wurde von uns untersucht, ob intelligentere Analyse-systeme diesen Wert manipulieren, um wie ein Gerät auszu-sehen. Die Ergebnisse in Tabelle IV zeigten, dass keines dergetesteten Analysesysteme diesen Wert manipuliert [Wei17].

Tabelle IVANZAHL DER SENSOREN

Sandbox SDK Version Anzahl Sensoren

BlueStacks 19 7APKScan 16 5Trend Micro 1 22 1Trend Micro 2 16 5DroidBox 21 8DroidAnalyst 18 5Andy 17 8

2) Attribute: Die Analyse der Sensoreigenschaften ergabdie in Tabelle V angegebenen Ergebnisse. Dabei haben wiruns auf den Accelerometer-Sensor bezogen, da er in 99,81%aller verfügbaren Android Geräte vorhanden ist. TypischeSensoreigenschaften des Accelerometers sind:

• MaximumRange (m/s2): Die maximale Reichweite derAchsen

• Power (mA): Der Energieverbrauch durch den Sensor• Resolution (m/s2): Definiert den kleinsten Änderungs-

wert, der durch den Sensor erfasst werden kann• Vendor: SensorherstellerDie Werte des Android Emulators in Tabelle V sind be-

sonders auffällig. Der emulierte Sensor hat mit 2.8 nur einen

Tabelle VACCELEROMETER-EIGENSCHAFTEN

Attribut Emulator Nexus 4 Galaxy S5

MaximumRange 2.8 39.226593 19.6133Power (mA) 3.0 0.5 0.25Resolution 0.0002480159 0.0011901855 0.0005985504

Vendor The Android OpenSource Project InvenSense Invensense

Bruchteil der Reichweite auf normalen Geräten. Ebenfallsauffällig ist der Wert des Energieverbrauchs: Mit 3,0 mAhat der Emulator einen vielfach höheren Wert als die ver-glichen echten Geräte. Noch deutlicher wird das Ergebnis,wenn der durchschnittliche Energieverbrauch lt. OpenSignalbetrachtet wird. Dieser beträgt beim Accelerometer lediglich0,13 mA (vgl. [Opeb]). Der Hersteller des Accelerometersist im Emulator als The Android Open Source Project ange-geben, was kein realistischer Wert für ein Smartphone ist. LautOpenSignal sind die am meisten verbreiteten SensorherstellerBosch, STMicro, InvenSense, Kionix und MTK. Die Ergeb-nisse der Untersuchung zeigen, dass Detection-Heuristiken inden Attributen des Sensors existieren. Die Durchschnittswertekönnen dabei unterstützen, starke Differenzen zwischen Gerätund Emulator festzustellen.Eine interessante Frage bezüglich der Sensoreigenschaften ist,ob die moderne Anti-Sandbox-Detection in Sicherheitssyste-men diesen Aspekt abdeckt. Boomgaarden et al. [BCW+15]hat dazu Accelerometer-Sensoren in Anti-Malware-Systemengetestet. Die Forschungsergebnisse bestätigen die Ergebnisseaus Tabelle V und zeigen sogar weitere Heuristiken auf. Eswurde festgestellt, dass jede Sandbox, die einen Accelerometerbereitstellt, exakt selben Werte liefert. Besonders auffälligwaren dabei die Werte entlang der x-,y- und z-Achse, diedurchgehend 0.0 m/s2, 9.77622 m/s2, 0.813417 m/s2 waren(vgl. [BCW+15]). Der Accelerometer-Sensor eines echtenGeräts, liefert ständig – zumindest leicht veränderte – Achsen-Werte. Bei allen von Boomgaarden et al. untersuchten Um-gebungen ist ebenfalls, wie auch im Android Emulator, dergenerische Wert (G) The Android Open Source Project alsSensorhersteller (Vendor) eingetragen.

3) Sensor Updates: Komplexere dynamische Heuristikenkönnen mit einzelnen Sensoren kommunizieren und sie aufrealistisches Verhalten prüfen. So müsste der GPS-Sensorregelmäßig Standortänderungen feststellen, wenn das Smart-phone in gewöhnlichem Gebrauch ist. Ein weiteres Heuristik-Beispiel kann durch Prüfen des realistischen Verhaltens desBatterie-Sensors stattfinden. Ist der Status der Batterie aufladend, so müsste sich der Batteriestand in regelmäßigenAbständen ändern. Werden Szenarien wie diese nicht durchdas Anti-Sandbox-Detection abgedeckt, kann die Sandboxleicht durch Angreifer erkannt werden. In diesem Abschnittwerden einige Methoden aufgezeigt, die Updates des Sensorsnutzen, um eine Sandbox zu erkennen.Android-Sensoren melden dem System über ein SensorE-vent Änderungen in den Sensordaten. Bei einigen Sensoren

140

7

entsprechen die Daten im Event den Achsen in einem 3D-Koordinatensystem. Bei den meisten Sensoren ist das Koordi-natensystem dabei relativ zum Bildschirm des Smartphones.Das Koordinatensystem basiert immer auf der natürlichenPosition des Gerätes (vgl. [Sen]).

Der Android Emulator gibt Entwicklern die Möglichkeit,einige Sensoren zu testen. So kann ein Entwickler bspw.Rotationen am virtuellen Gerät über das Emulatormenü aus-führen. Beim Accelerometer können die Bewegungen Yaw-Pitch-Roll (deutsch: Rollen-Nicken-Gieren) getestet werden.Mit diesen Bewegungen werden die Werte auf allen drei Ach-sen verändert. Das ermöglicht zwar ein realistisches Testen desSensors, jedoch laufen Analysen in der Sandbox automatisiertab, d.h. die Bewegungen am Gerät müssen immer wiederausgeführt werden, um eine realistische Sensoränderung zuemulieren. Angreifer können allerdings mit dem timestamp-Attribut prüfen, ob die Differenz zwischen eingehenden Eventskonstant ist. Auch folgen programmierte Bewegungen oftmalsbestimmten Mustern, die ebenfalls erkannt werden können.Die Untersuchungen durch Boomgaarden et al. [BCW+15]haben bereits gezeigt, dass es keine Änderung an den Achsenwährend der Analyse in verschiedenen Systemen gab. Beiden festgestellten Werten handelt es sich um die Initialwer-te des Sensors. Da es sehr unwahrscheinlich ist, dass derAccelerometer-Sensor eines realen Geräts beim Starten derApp exakt diese Werte besitzt, kann eine Sandbox daran mithoher Zuverlässigkeit erkannt werden.Eine weitere Möglichkeit, mithilfe von Sensoren eine Sandboxzu erkennen, ist eine Aktion auszuführen, die wiederum durchSensoren messbar ist. Beispielsweise besitzt jedes Smartphoneein Mikrofon, einen Accelerometer-Sensor und die Fähigkeitzu vibrieren. Um die Auswirkung einer Vibration auf Acce-lerometer und Mikrofon besser zeigen zu können, werden zuUntersuchungszwecken Apps5 eingesetzt, die für Messungendieser Sensoren entwickelt wurden. Für unseren Test wurdedas Smartphone auf einen Tisch gelegt und versucht alle Ein-flüsse, die das Ergebnis verfälschen könnten, zu vermeiden. ImAusgabelog der Messung schwankt der x-Wert der Achse ohneVibration zwischen ca. �0, 005 und 0,008 m/s2. Während derVibration schwankt er zwischen ca. �0, 680 und 0,465 m/s2.Da ein reales Opfergerät während der Nutzung in der Handgehalten wird, ist der Ausschlag der Achsenwerte sogar nochhöher.In einem zweiten Test wurde mit dem Mikrofon in einemruhigen Raum 20 bis 30 dB gemessen. Durch die Vibrationstieg der Wert auf fast 70 dB an.Diese Ergebnisse zeigen, dass eine Sandbox mit einer ausge-lösten Vibration erkannt werden kann. Die Malware muss al-lerdings die Permission android.permission.VIBRATEhaben, um die Funktion des Smartphones nutzen zu können.Da es sich bei einer Vibration um kein auffälliges Verhaltenhandelt, wird die Berechtigung im Normalfall wahrscheinlichdurch den Benutzer gewährt.Android stellt Entwicklern verschiedene Möglichkeiten zur

5Accelerometer: https://play.google.com/store/apps/details?id=com.lul.accelerometerMikrofon: https://play.google.com/store/apps/details?id=com.gamebasic.decibel

Verfügung, um an Standortdaten des Gerätes zu gelangen.Standortänderungen können über GPS oder über den Wifi-Standort bezogen werden. Boomgaarden et al. [BCW+16]hat Untersuchungen zu Standortänderungen in Anti-Malware-Systemen durchgeführt. Mithilfe der android.location-API wurde eine App entwickelt, die den LocationManagernutzt um Informationen zum aktuellen Standort zu sammeln.Die erste dynamische Heuristik, die Boomgaarden et al. fest-gestellt hatte, war, dass keines der getesteten Analysesystememehr als eine Standortänderung durchgeführt hat. Auf realenGeräten hingegen wird der Standort innerhalb kurzer Zeitmehrmals aktualisiert. Die GPSSatellite-API liefert Datenzum Satellit, wenn eine Standortänderung registriert wurde.Ebenfalls wurde festgestellt, dass keines der Systeme sinnvolleDaten zu den Satelliten zurückgegeben hat. Zum Beispielwurde die Anzahl der Satelliten bei einer Standortänderungmit 0 angegeben (vgl. [BCW+16]).

Bewertung: Mit der Anzahl der Sensoren in Smartphonessteigt auch die Anzahl der dynamischen Heuristiken. Dievorgestellten Methoden sind nur ein Teil der Möglichkeiten,die Cyberkriminelle nutzen können, um eine Sandbox durchdynamische Heuristiken zu erkennen. So könnte der Angreiferbspw. aufwendige Prozesse starten, die die Wärme im Geräterhöhen. Die Sensoren der Kategorie Environmental Sensorserlauben es, die Wärmeentwicklung im Gerät genauestens zumessen. Eine Sandbox müsste sehr viele Werte manipulieren,um dynamische Heuristiken zu verhindern. Anders als dieHeuristiken in Abschnitt IV, zeigen Untersuchungen, dass diedynamischen Werte größtenteils nicht von der Sandbox modi-fiziert werden. Aus diesem Grund kann der Emulator mittelsdynamischer Detection-Heuristiken leicht erkannt werden.

B. Performance

Wird der Emulator ohne Hardware-Beschleunigung ausge-führt, ist er einem Smartphone in Sachen Rechenleistung deut-lich unterlegen. Jeder CPU-Befehl des Gast-Systems durch denEmulator in CPU-Befehle des Host-Systems zu übersetzen ver-ringert die Ausführungsgeschwindigkeit der App enorm. Eben-falls können dem Gast-System ohne Hardware-Beschleunigerkeine Ressourcen dynamisch zugeteilt werden (vgl. [qem]).Ein Beispiel: Um Pixel auf den Bildschirm darzustellen, wer-den hauptsächlich vier Hardwarekomponenten benötigt. DieCPU berechnet die Daten, die GPU rendert die Grafiken, derSpeicher sichert die Daten und die Batterie stellt die Energiebereit. Da der reibungslose Ablauf einer App von diesen Kom-ponenten abhängig ist, lässt sich daran ihre Leistungsfähigkeitmessen (vgl. [Andb]). Intel stellt mit Hardware AcceleratedExecution Manager (HAXM) einen Beschleuniger für x86-basierte Emulatoren bereit und ermöglicht es dem Emulator,direkt die CPU des Host-Systems zu nutzen. Da Emulatoreni.d.R. auf Computern mit leistungsstarker Hardware ausgeführtwerden, nähert sich die Performance des Emulators so andiejenige eines echten Gerätes an.Vidas et al. hat in seinen Untersuchungen (vgl. [VC14]) diePerformance der CPU und GPU im Emulator mit echten Gerä-ten verglichen. Für die CPU wurde ein Programm geschrieben,das die ersten 220 Stellen von Pi berechnet. Die Ergebnisse

141

8

Tabelle VIPI-KALKULATION

Gerät / Emulator Durchschn. Rundendauer (Sec) Abweichung

PC 0,153 0,012Galaxy Nexus 16,798 0,419Samsung Charge 22,647 0,398Motorola Droid 24,420 0,413Emulator (2.2) 62,184 7,549Emulator (4.2.2) 68,872 0,804

Quelle: [VC14]

Tabelle VIIPI-KALKULATION MIT HAXM

Gerät / Emulator Durchschn. Rundendauer (Sec)

Emulator (ARM) 24,55Emulator (x86) 0,33Nexus 4 2,16S. Galaxy S4 1,36

in Tabelle VI zeigen, dass der Emulator mit Android 4.2.2durchschnittlich 68,8 Sekunden pro Runde für die Kalku-lation benötigt. Im Gegensatz dazu brauchte das Gerät mitder schwächsten CPU, das Motorola Droid, durchschnittlichnur 24,4 Sekunden pro Runde. Mit diesem Ergebnis konnteVidas et al. zeigen, dass Detection-Heuristiken in aufwendigenBerechnungen existieren.

Die Untersuchungsergebnisse aus VI lassen darauf schließen,dass der Hardware-Beschleuniger HAXM bei den Untersu-chungen nicht zum Einsatz kam, da HAXM – ebenfalls wie derArtikel von Vidas et al. – erstmals im Jahr 2014 veröffentlichtwurde. Dies belegen auch weitere Untersuchungen im Rahmendieser Arbeit. In vergleichbaren Tests (220 Stellen von Pi mitgleicher Berechnungsmethode wie in [VC14] dokumentiert)zeigte sich eine deutliche Verbesserung der Performance durchden Einsatz von HAXM. Das Ergebnis des Tests in TabelleVII zeigt, dass sich die CPU-Performance im Emulator beiBerechnungen der Performance eines realen Geräts nicht nurannähert, sondern sie teilweise sogar übersteigt. Dieses Resul-tat widerlegt die Ergebnisse von Vidas et al. und zeigt, dasssich eine Sandbox alleine durch die CPU-Performance nichterkennen lässt.

Rechenintensive Aufgaben wie oben beschrieben führenaber zu anderen Heuristiken. Arbeitet die CPU aufHochleistung, steigt die CPU-Temperatur schnell an,was wiederum durch Sensoren im Gerät gemessen werdenkann. Ein einfacher Test mithilfe einer Stress-Test-App6

verdeutlicht das. Die CPU wird dabei auf 100% Leistunggebracht und die Temperaturentwicklung wird durch dieApp ausgegeben. Die Messung hat ergeben, dass sich dieCPU-Temperatur im Nexus 4 bei normaler Belastung (ca.40% Auslastung) im Bereich von 26 bis 32°C bewegt.Die Temperatur verdoppelt sich auf 63 bis 65°C bei 100%CPU-Auslastung. Ebenso steigt die Batterie-Temperatur um

6Bspw. Stress CPU. Online unter: https://play.google.com/store/apps/details?id=xyz.bluephoenix.stresscpu

ca. 10°C. Im Gegensatz dazu zeigt der Emulator für CPU undBatterie immer 0°C an. Angreifer können also eine Sandboxerkennen, indem sie entweder die Temperaturen zu einembestimmten Zeitpunkt prüfen oder die Temperaturänderungwährend rechenintensiver Prozesse überwachen.

Eine weitere Heuristik bietet die Messung der GPU-Performance, die üblicherweise in Frames Per Second (FPS)gemessen wird. Vidas et al. beschreibt in [VC14] eineUntersuchung mit einer App, die 5000 FPS-Werte sammelt.Die Untersuchung zeigte, dass sich bei einem Galaxy Nexusmit Android 4.2.2 der Großteil der gemessenen Werte imBereich 58-60 FPS befinden. Diese Werte stehen in einemstarken Kontrast zu den FPS-Werten im Emulator der aufverschiedenen Betriebssystemen ausgeführt wurde. DerEmulator erreichte durchschnittlich zwischen 9 bis 14 FPS.Auch hier zeigt sich, dass der Emulator durch seine FPS-Rateerkannt werden kann.

Ab der SDK-Version 17 kann der Emulator ebenfalls dieGPU durch Host-Hardware beschleunigen. Der Emulator er-zeugt durch die Hardwarebeschleunigung ähnliche Werte, dieauch auf echten Geräten vorkommen. Allerdings schwanktdie FPS-Rate auf echten Geräten in deutlich kleineren Be-reichen als bei der hardwarebeschleunigten Emulation (vgl.[VC14]). Zusammenfassend kann festgestellt werden, dasseine Detection-Heuristik, die prüft, ob die FPS-Rate unter 30liegt oder weniger als 80% der FPS innerhalb eines Bereichesliegen, eine Sandbox erkennen kann.

Bewertung: Die gezeigten Methoden können zurSandbox-Detection eingesetzt werden. Jedoch haben die Un-terschiede zu den Untersuchungen von Vidas et al. gezeigt,dass es in Zukunft schwieriger wird eine Sandbox nur anhandder Performance zu erkennen. Neue Technologien wie Intel’sHAXM ermöglichen es, dass Emulatoren sich mit der Per-formance von physischen Geräten messen können. Da nichtjedes Anti-Malware-System auf QEMU basiert, kann es inder Performance Unterschiede zum hier untersuchten AndroidEmulator geben.

VI. CONTEXT AWARENESS

In diesem Abschnitt werden Methoden behandelt, die dasGerät auf normale Nutzung durch einen User prüfen. Beispielefür Nutzungsmerkmale sind: menschliche Interaktion mit demGerät, keine leeren Kontakt- und SMS-Listen und Dateien imDownload-Ordner.

A. Programmierte InteraktionUm in der dynamischen Analyse das Verhalten einer App

beobachten zu können, ist im Normalfall eine Interaktionzwischen dem Benutzer und der App nötig. Andersausgedrückt: Weil Android event-driven ist und viele wichtigeEvents durch UI-Interaktion ausgelöst werden, sind für eineautomatisierte Erkundung Werkzeuge nötig (vgl. [CML+16]).Das Ziel dieser Werkzeuge ist es möglichst viele Pfade derUI in kürzester Zeit zu erkunden. Eines dieser Werkzeugeist das Fuzzing-Programm Android Monkey, das einenPseudozufallsstrom von User-Events generiert. Darüber

142

9

Abbildung 1. Wischen: User vs. MonkeyRunner

Quelle: [DLLZ16]

hinaus bietet Android den UI Automator der automatisch dieLayout-Hierarchie einer App inspiziert. Er ermöglicht, alleUI-Komponenten samt ihrer Eigenschaften zu analysieren,die gerade auf dem Bildschirm angezeigt werden. Anhanddieser Informationen entscheidet das Framework, welcheUI-Aktionen durchgeführt wird (vgl. [Andc]).Beide Werkzeuge versuchen alle potenziellen Pfade aufmöglichst effiziente Weise zu durchlaufen. Die generiertenEvents decken die gefundenen Pfade in einem kurzenZeitintervall und in regulären Abständen ab. Dieses Verhaltenunterscheidet sich aber stark von menschlicher Interaktion. ImFolgenden werden die Forschungsergebnisse von Diao et al.(vgl. [DLLZ16]) referiert, der Heuristiken in programmiertenInteraktionen untersucht hat.

Eine sehr einfache Methode, um den Monkey zu er-kennen, liefert die Android-API selbst. Die MethodeisUserAMonkey() gibt den Boolean-Wert true zurück,wenn das User-Interface gerade durch einen Monkey genutztwird (vgl. [Anda]). Eine Sandbox wie Andrubis, die den Mon-key als UI-Erkundungswerkzeug einsetzt, kann bereits daranerkannt werden, wenn der Wert nicht durch API Hookingmodifiziert wird.

1) Auffällige Parameterwerte in Interaktions-Events: Beisimulierten Event-Injections durch die Frameworks könnenAnomalien bei MotionEvent (Tippen auf Touchscreen) undKeyEvent (Tastendruck) gefunden werden. Wenn ein Smart-phone durch einen Benutzer bedient wird, werden die Eventsvon der Hardware im Gerät ausgelöst. Den Events werden In-formationen von der Hardware mitgegeben. Zum Beispiel dieKoordinaten der Eingabe auf dem Bildschirm. Im Gegensatzdazu sind die Events, die von den Frameworks erzeugt werden,mit Dummydaten gefüllt.

Untersuchungen zeigen die Unterschiede zwischen realenEingaben und durch den Monkey generierte Eingaben. DieErgebnisse eines Experiments aus [DLLZ16] sind in derAbbildung 1 dargestellt und zeigen den Unterschied zwischeneinem menschlichen Benutzer und programmierter Interaktionmithilfe des MonkeyRunners. In beiden Versuchen wurde diegleiche, mehrmals wiederholte Wischgeste ausgeführt.

2) UI-Fallen: Um mit so vielen UI-Elementen wie mög-lich zu interagieren, kann das Analysesystem die App nachBedienelementen durchsuchen, um diese zu betätigen. Die-

ses Verhalten kann durch UI-Fallen erkannt werden, die fürBenutzer nicht sichtbar sind. Das Analysewerkzeug scanntalle Bedienelemente und erkennt keinen Unterschied zwi-schen normalen UI-Elementen und UI-Fallen. Eine mögli-che Form einer UI-Falle ist eine isolierte Activity, die überdas UI nicht erreichbar und in der XML-Beschreibung mitandroid:exported="true" versehen ist. Jede Activitywird im Android Manifest eingetragen und definiert das UI-Interface des aktuellen Bildschirmes. Eine App besteht norma-lerweise aus einer Haupt-Activity und weiteren Activities zudenen navigiert werden kann. Während ein User nur durch dieerreichbaren Activites navigiert, scannt das Analysesystem dieManifest-Datei nach eingetragenen Activities und durchläuftihre UI-Elemente. Die Betätigung eines UI-Elements in derisolierten Activity führt dann zu einer Sandbox-Detection.Eine weitere Möglichkeit, eine UI-Falle zu integrieren, ist dieEinbettung von unsichtbaren UI-Elementen. Das kann bspw.ein Button sein, der so klein erstellt wurde, dass er für dasmenschliche Auge nicht sichtbar ist. Auch kann der Buttonmit der gleichen Farbe gefüllt sein wie anliegende Elemente,um unsichtbar zu werden. Werkzeuge wie der UI Automatorscannen die Layout-Hierarchie und betätigen diesen Button,weil er für das Programm wie ein valides UI-Element wirkt.

Bewertung: Die vorgestellten Werkzeuge werden Ent-wicklern für Testzwecke bereitgestellt und sind deswegen nichtdarauf ausgelegt, UI-Fallen zu erkennen. Dennoch wird derMonkey etc. in Analysesystemen für die Erkundung genutzt.Diao et al. hat die gezeigten Methoden in einer App imple-mentiert und in verschiedenen Analysesystemen getestet (vgl.[DLLZ16]). In jedem untersuchten System hat mindestens eineder Methoden zu einer Sandbox-Erkennung geführt.

B. Weitere NutzungsmerkmaleSmartphones, die täglich in Gebrauch sind, weisen be-

stimmte Nutzungsmerkmale auf: bspw. Kontakte im Telefon-buch oder versendete und empfangene SMS-Nachrichten. DieErgebnisse unseres Tests zeigen, dass die Sandbox in denmeisten Fällen keine Kontakte gespeichert hat (vgl. [Wei17]).DroidAnalyst zum Beispiel hat lediglich drei Kontakte in derKontaktliste. Für die Anzahl der SMS wurde z.B. bei APKScander Wert null zurückgegeben.

Ein weiteres Merkmal ist der Inhalt bestimmter Ablageord-ner. Standardmäßig werden unter Android heruntergeladeneDateien im Download-Ordner (sdcard/download) gespei-chert. Oberheide hat bei seinen Untersuchungen in [Obe]festgestellt, dass der Google Bouncer verschiedene Dateienin typischen Ablageordnern enthält.

Bewertung: Eine Sandbox kann zwar durch fehlendeNutzungsmerkmale durch Angreifer identifiziert werden, je-doch zeigen die Ergebnisse der Untersuchungen, dass dieseDetection-Heuristiken nicht immer erfolgreich sind. Zwar sindkeine Kontakte eine auffällige Eigenschaft an einem Smart-phone, jedoch könnte es zu diesem Ergebnis kommen, weilder User der App keine Berechtigungen erteilt hat.

VII. AUSBLICK UND FAZIT

Einige der diskutierten Methoden wurden in einer Proof ofConcept-App implementiert. Dazu sollten auf dem Bildschirm

143

10

Abbildung 2. Unmask App

allgemeine Informationen zum aktuellen System aufgelistetwerden. Für jede Sandbox-Detection-Methode, wird in derGUI ein X-Zeichen angezeigt, ob anhand dieser Methodeder Emulator erkannt werden konnte. Mit den abgehaktenMethoden in Abbildung 2 konnte in diesem Beispiel dieemulierte Ausführungsumgebung erkannt werden. Listing 1zeigt eine einfache Methode zur Analyse der Build-API wiein IV-C beschrieben.

Listing 1. Build-Werte prüfenboolean checkBuild() {return Build.BOARD.startsWith("unknown")|| Build.FINGERPRINT.contains("generic")|| Build.FINGERPRINT.contains("test-keys")|| Build.MODEL.contains("emulator")|| Build.MODEL.contains("android sdk")|| Build.MANUFACTURER.contains("unknown")|| Build.DEVICE.startsWith("generic")|| Build.HARDWARE.contains("goldfish")|| Build.HARDWARE.contains("ranchu")|| "google_sdk".equals(Build.PRODUCT)}

Es wurde gezeigt, wie einfach es sein kann, eine Sandbox-Umgebung zu erkennen. Es ist davon auszugehen, dasszukünftige Sandboxen mit ausgefeilteren Anti-Sandbox-Detection-Techniken versuchen werden, die Sandbox-Detection weiter zu erschweren. Dabei können intelligenteMethoden eingesetzt werden, um Abfragen der Appabzufangen und so zu verändern, dass die Sandbox unentdecktbleibt bis das Schadverhalten hervorgerufen wurde. Auchmuss bei der Simulation von Sensoren nachgebessert werden.So sollten bspw. regelmäßig GPS-Änderungen vorgenommenwerden.

Um sämtlichen Überprüfungen durch Malware standzuhalten,

müsste ein Emulator den entsprechenden Systemzustandsimulieren, was aber ein zu aufwändiger Prozess wäre. Auchwenn die Analyse-Umgebung die Detection-Methoden durchintelligente Konfiguration umgehen kann, steht sie immernoch vor der Herausforderung das schädliche Verhalten derApp zu erkennen. Rasthofer et al. [RAMB16] setzt sich mitdiesem Problem in der Malware-Analyse auseinander und hatdas Werkzeug Harvester entwickelt. Mit Harvester könnenSicherheitsexperten und Entwickler automatisch Laufzeitwerteaus Android-Applikationen extrahieren. Diese Laufzeitwertesollen darüber informieren, mit welchen Internetdienstendie App kommuniziert, um Datendiebstahl frühzeitig zuerkennen. Alle Ausführungsvarianten abzudecken, damit alleLaufzeitwerte extrahieren werden können, ist aber ein sehrkomplexer Prozess. Das Pfadabdeckungs-Problem wurde inAbschnitt VI-A am Beispiel des Android Monkey aufgezeigt.Der Harvester versucht dieses Problem zu lösen, indemer nur genau den Programmcode ausschneidet, der überLaufzeitwege entscheidet. So kann das Werkzeug effizientLaufzeitwerte extrahieren, die Aufschluss darüber geben, mitwelchen Servern die App kommuniziert und bietet Hinweisedarauf, ob die App Schadcode enthält (vgl. [RAMB16]).

Eine andere Methode, Einfluss auf den Systemzustandund die Android Bibliotheken zu nehmen, ist das AndroidRun Time Hooking. Eines der bekanntesten Frameworks, diedafür eingesetzt werden ist Xposed (vgl. [GST+15]). DasFramework erlaubt es, API-Verhalten während der Laufzeit zumodifizieren, um somit beispielsweise die Sandbox-Detectionzu erschweren.

Emulatoren werden in der dynamischen Analyse eingesetzt,weil sie skalierbar sind und die virtuelle Umgebung inSekunden zurückgesetzt werden kann, um mit der nächstenAnalyse zu beginnen. Cyberkriminellen ist das natürlichbewusst, deswegen werden Sandbox-Detection-Technikeneingesetzt. Das Modifizieren simpler Systemwerte schütztnicht vor intelligenten Heuristiken, die nach Unterschiedenzwischen Emulatoren und Geräten suchen. Eine möglicheLösung dafür stellt Mutti et al. [MFB+15] mit BareDroidvor. BareDroid ermöglicht die Malwareanalyse auf echtenGeräten, die über eine Cloud-Schnittstelle bereitgestelltwerden.Die Firma VMRay geht davon aus, dass die Sandbox-Detection bei Malware für Windows-Systeme an Bedeutungverlieren wird, da mittlerweile viele Produktionsumgebungen(Workstations und Server) virtualisiert betrieben werden. Jenach Absicht des Angreifers kann aber auch eine solcheProduktionsumgebung Ziel des Angriffes sein. Zusätzlichsind die virtuellen Umgebungen so fortgeschritten, dass esnicht mehr viele Anomalien gibt, an denen die Sandboxerkannt werden kann (vgl. [VMR]). Android ist mittlerweilenicht mehr nur auf Smartphones zu finden, sondern auchin Fernsehern, Uhren, Autos oder Zugangskontrollsystemen.Möglicherweise entwickelt sich Android ebenfalls in dieRichtung wie Windows und wird in näherer Zukunft fürbestimmte Zwecke nur virtuell in einer Sandbox genutzt.Dann könnte die Sandbox-Detection auch für Android an

144

11

Bedeutung verlieren.Das würde für Apps von Cyberkriminellen heißen, dasssie auf anderem Wege herausfinden müssen, ob sie geradeanalysiert werden. Eine der größten Herausforderungen derMalware-Analyse wäre dann die Simulation eines realenUsers. Angreifer können durch Prüfen auf einen realenUser leicht erkennen, ob sie gerade analysiert werden. Auchder Ansatz wie bei BareDroid ist in diesem Fall keineLösung, denn auch bei der Analyse auf echten Geräten istdie Interaktion programmiert. Das Thema bleibt also einhochinteressantes Gebiet für weitere Forschung.

LITERATUR

[Anda] ANDROID: ActivityManager API. https://developer.android.com/reference/android/app/ActivityManager.html#isUserAMonkey(),Abruf: 22. Februar 2017

[Andb] ANDROID: Profile Your App. https://developer.android.com/studio/profile/index.html, Abruf: 14. Februar 2017

[Andc] ANDROID: UI Automator. https://developer.android.com/topic/libraries/testing-support-library/index.html#uia-viewer, Abruf:22. Februar 2017

[AT] AV-TEST: Security Report 2015/16. https://www.av-test.org/fileadmin/pdf/security_report/AV-TEST_Sicherheitsreport_2015-2016.pdf, Abruf: 23. Dezember 2016

[BCW+15] BOOMGAARDEN, Jacob ; CORNEY, Joshua ; WHITTAKER, Hol-ly ; DINOLT, George ; MCEACHEN, John: Challenges in emu-lating sensor and resource-based state changes for Android mal-ware detection. (2015), Dec, S. 1–10. http://dx.doi.org/10.1109/ICSPCS.2015.7391733. – DOI 10.1109/ICSPCS.2015.7391733

[BCW+16] BOOMGAARDEN, Jacob ; CORNEY, Joshua ; WHITTAKER,Holly ; DINOLT, George ; MCEACHEN, John: Mobile KonamiCodes: Analysis of Android Malware Services Utilizing Sensorand Resource-Based State Changes. (2016), S. 5578–5587

[Blu] BLUE COAT SECURITY: Malware Sandbox Evasion Tacticsand Countermeasures. https://www.bluecoat.com/company-blog/2016-05-03/malware-sandbox-evasion-tactics-part-1, Abruf: 1.Februar 2017

[BP15] BECKER, Arno ; PANT, Marcus: Android 5: Programmieren fürSmartphones und Tablets. dpunkt.verlag GmbH, 2015. – ISBN978–3864902604

[CML+16] CARTER, Patrick ; MULLINER, Collin ; LINDORFER, Martina ;ROBERTSON, William ; KIRDA, Engin: CuriousDroid: Automa-ted User Interface Interaction for Android Application AnalysisSandboxes. (2016)

[DLLZ16] DIAO, Wenrui ; LIU, Xiangyu ; LI, Zhou ; ZHANG, Kehuan: Eva-ding Android Runtime Analysis Through Detecting ProgrammedInteractions. (2016), S. 159–164

[DNS] DEEG, Matthias ; NERZ, Sebastian ; SAUDER, Daniel: Ausge-trickst - Warum Schadprogramme trotz aktueller Antivirensoftwa-re zum Zuge kommen. https://www.syss.de/fileadmin/dokumente/Publikationen/2014/Anit_Virus_Evasion_dt.pdf, Abruf: 10. Janu-ar 2017

[Goo] GOOGLE: Emulator Code-Base - ranchu. https://groups.google.com/forum/#!topic/android-emulator-dev/dltBnUW_HzU,Abruf: 11. Februar 2017

[GST+15] GAJRANI, Jyoti ; SARSWAT, Jitendra ; TRIPATHI, Meenakshi; LAXMI, Vijay ; GAUR, M. S. ; CONTI, Mauro: A RobustDynamic Analysis System Preventing SandBox Detection byAndroid Malware. (2015), 290–295. http://dx.doi.org/10.1145/2799979.2800004. – DOI 10.1145/2799979.2800004. ISBN978–1–4503–3453–2

[HX] HU, Wenjun ; XIAO, Zihang: Guess Where I Am: Detection andPrevention of Emulator Evading on Android. https://github.com/MindMac/HideAndroidEmulator/blob/master/XCON/Guess%20Where%20I%20Am-Detection%20and%20Prevention%20of%20Emulator%20Evading%20on%20Android.pdf, Abruf:17. Februar 2017

[IDC] IDC: Smartphone OS Market Share. http://www.idc.com/promo/smartphone-market-share/, Abruf: 14. Dezember 2016

[JZAH14] JING, Yiming ; ZHAO, Ziming ; AHN, Gail-Joon ; HU, Hongxin:Morpheus: automatically generating heuristics to detect Androidemulators. (2014), S. 216–225

[Kas] KASPERSKY: Kaspersky Lab analysiert denaktuell komplexesten mobilen Schädling der Welt.http://newsroom.kaspersky.eu/de/texte/detail/article/kaspersky-lab-analysiert-den-aktuell-komplexesten\-mobilen-schaedling-der-welt, Abruf: 15. Juni 2017

[key] Signing Build for Release. https://source.android.com/devices/tech/ota/sign_builds.html, Abruf: 11. Februar 2017

[MFB+15] MUTTI, Simone ; FRATANTONIO, Yanick ; BIANCHI, Antonio; INVERNIZZI, Luca ; CORBETTA, Jacopo ; KIRAT, Dhilung ;KRUEGEL, Christopher ; VIGNA, Giovanni: BareDroid: Large-Scale Analysis of Android Apps on Real Devices. In: Pro-ceedings of the 31st Annual Computer Security ApplicationsConference. New York, NY, USA : ACM, 2015 (ACSAC 2015).– ISBN 978–1–4503–3682–6, 71–80

[Obe] OBERHEIDE, Jon: Dissecting the Android Bouncer. https://jon.oberheide.org/blog/2012/06/21/dissecting-the-android-bouncer/,Abruf: 1. Februar 2017

[Opea] OPENSIGNAL: About OpenSignal. https://opensignal.com/about/, Abruf: 18. Febraur 2017

[Opeb] OPENSIGNAL: The sensor revolution is accelerating. https://opensignal.com/sensors/, Abruf: 18. Febraur 2017

[Pal09] PALEARI, Roberto: A fistful of red-pills: How to automaticallygenerate procedures to detect CPU emulators. (2009)

[PVA+14] PETSAS, Thanasis ; VOYATZIS, Giannis ; ATHANASOPOULOS,Elias ; POLYCHRONAKIS, Michalis ; IOANNIDIS, Sotiris: RageAgainst the Virtual Machine: Hindering Dynamic Analysis ofAndroid Malware. (2014), 5:1–5:6. http://dx.doi.org/10.1145/2592791.2592796. – DOI 10.1145/2592791.2592796. ISBN978–1–4503–2715–2

[qem] QEMU. http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Grundlagen, Abruf: 1. Februar 2017

[RAMB16] RASTHOFER, Siegfried ; ARZT, Steven ; MILTENBERGER, Marc; BODDEN, Eric: Harvesting runtime values in android applica-tions that feature anti-analysis techniques. (2016)

[Sen] Sensors Overview. https://developer.android.com/guide/topics/sensors/sensors_overview.html, Abruf: 14. Dezember 2016

[Sol] SOLUTIONS, Comodo S.: Android OBAD Technical Analysis Pa-per. https://www.comodo.com/resources/Android_OBAD_Tech_Reportv3.pdf, Abruf: 4. Februar 2017

[Sta] STATISTA: Smartphone-Absatz weltweit 2015. https://de.statista.com/themen/581/smartphones/, Abruf: 14. Dezember 2016

[Tel] TelephonyManager API. https://developer.android.com/reference/android/telephony/package-summary.html, Abruf:14. Dezember 2016

[VC14] VIDAS, Timothy ; CHRISTIN, Nicolas: Evading Andro-id Runtime Analysis via Sandbox Detection. (2014), 447–458. http://dx.doi.org/10.1145/2590296.2590325. – DOI10.1145/2590296.2590325. ISBN 978–1–4503–2800–5

[VMR] VMRAY: Sandbox Evasion Techniques. https://www.vmray.com/blog/sandbox-evasion-techniques-part-2/, Abruf: 22. Januar2017

[Wei17] WEISENMÜLLER, Hermann: Sandbox Detection Angriffe gegenden Sandbox Detection Angriffe gegen den Android Emulator.Furtwangen, Hochschule Furtwangen, Bachelor Thesis, 2017

145