Software-Technologien und -Prozesse: IT-Sicherheit und Mobile Systeme. Tagungsband/Proceedings zur 4. Konferenz STeP 2014 Hochschule Furtwangen 9783110358650, 9783110355277

Citation preview

Jens-Matthias Bohli, Friedbert Kaspar und Dirk Westhoff (Hrsg.) Software-Technologien und -Prozesse

Software-Technologien und -Prozesse

IT-Sicherheit & Privatheit in Zeiten von Big Data Tagungsband/Proceedings zur 4. Konferenz STeP 2014 Hochschule Furtwangen, 20. Mai 2014 Herausgegeben von Jens-Matthias Bohli, Friedbert Kaspar und Dirk Westhoff

Herausgeber Dr. Jens-Matthias Bohli NEC Laboratories Europe Kurfürsten-Anlage 36 69115 Heidelberg [email protected] Prof. Dr. Friedbert Kaspar Hochschule Furtwangen Department of Computer Science Robert-Gerwig-Platz 1 78120 Furtwangen Germany [email protected] Prof. Dr. habil. Dirk Westhoff Hochschule Furtwangen Dept. of Computer Science Robert-Gerwig-Platz 1, 78120 Furtwangen [email protected]

ISBN 978-3-11-035527-7 e-ISBN 978-3-11-035865-0 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar Library of Congress Cataloging-in-Publication Data A CIP catalog record for this book has been applied for at the Library of Congress. © 2014 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 143, 81671 München, Deutschland www.degruyter.com Ein Unternehmen von De Gruyter Lektorat: Dr. Gerhard Pappert Druck und Bindung: CPI buch bücher.de GmbH, Birkach Gedruckt in Deutschland Dieses Papier ist alterungsbeständig nach DIN/ISO 9706.

Inhaltsverzeichnis Inhaltsverzeichnis.......................................................................................... v Organisation................................................................................................. vii Sponsoren..................................................................................................... ix Vorwort......................................................................................................... xi

Teil I: Eingeladene Vorträge Datenschutz: Ein Auslaufmodell? Günter Müller................................................................................................. 3 Vertrauen und Privatheit: Ein überwindbarer Gegensatz? Amardeo Sarma.............................................................................................. 5

Teil II: Industriepräsentationen Virtualisierung im Cloud-Zeitalter Spielt der Hypervisor noch eine Rolle? Holger Gantikow............................................................................................ 9 Cyber Phsysical Systems: Agile, adaptive und autonome Produktion - Steilvorlage für Software-Agenten Christian Dannegger..................................................................................... 21

vi

Inhaltsverzeichnis

Teil III: Young Researchers Deterministische Manipulation von Quick-Response-Codes Georg Usmanov, Alexander Kaiser, Holger Kölle........................................ 33 Penetrationtesting mit Windows Credential Editor Benjamin Nopper.......................................................................................... 49 An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures Dirk Hölscher............................................................................................... 59 JADE-OSGi im Bereich des Ambient Assisted Living Stefan Eggert, Artur Fertich......................................................................... 71 Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security Stefan Eggert, Artur Fertich......................................................................... 87

Teil IV: Technisches Programm Introduction to MAR Principle: A Log-based Approach towards Enhanced Security in Cloud Sai Manoj Marepalli, Razia Sultana, Andreas Christ................................ 101 Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living Carina Fredrich, Hendrik Kuijs, Christoph Reich..................................... 115 Security and Privacy Challenges in On-The-Fly Computing Ronald Petrlic, Alexander Jungmann, Marie Christin Platenius, Wilhelm Schäfer, Christoph Sorge.............................................................. 131 A comparison of isolated code execution approaches for mobile devices Denis Jurkovic, Friedbert Kaspar.............................................................. 143 Autorenverzeichnis..................................................................................... 155

Organisation

Veranstalter Fakultät Informatik, Hochschule Furtwangen Tagungsleitung Jens-Matthias Bohli, NEC Europe Ltd. Heidelberg Friedbert Kaspar, Hochschule Furtwangen Dirk Westhoff, Hochschule Furtwangen Organisationskoordination Fabian Berner, Hochschule Furtwangen Johann Betz, Hochschule Furtwangen Gerd Bitzer, Hochschule Furtwnagen Programmkomitee Ulrich Flegel (Hochschule Stuttgart) Willi Geiselmann (KIT) Tobias Glemser (secuvera GmbH) Nils Gruschka (FH Kiel) Alban Hessler (XING AG) Meiko Jensen (ULD) Jörg Keller (FernUniversität Hagen) Walter Kriha (Hochschule der Medien, Stuttgart) Peter Langendörfer (IHP) Hendrik Peters (Cloud4You) Thomas Schmidt (HAW Hamburg) Anthony Sulistio (HLRS) Christoph Sorge (Universität Paderborn) Osman Ugus (AuthentiDate International AG) Erik Zenner (Hochschule Offenburg)

Sponsoren Wir danken der unseren Sponsoren und der Hochschule Furtwangen für die freundliche Unterstützung.

Platin Sponsoren

Gold Sponsoren

Silber Sponsoren

x

Allgemeine Unterstützung:

Sponsoren

Vorwort STeP ist eine Konferenzreihe der Hochschule Furtwangen, die schwerpunktmäßig aktuelle Themen aus dem Bereich der Software-Technologien und Prozesse aufgreift. Sie soll als Plattform dienen für den Austausch der angewandten Wissenschaft mit der Wirtschaft, insbesondere Unternehmen aus der Region. Ein weiteres wichtiges Anliegen ist uns die Förderung des wissenschaftlichen Nachwuchses. Informations- und Kommunikationssicherheit ist ein fundamentaler Aspekt der Informatik, mit ständig steigender Bedeutung für den IT-Betrieb, für die Anwendungsentwicklung und in der Forschung. Der Bedarf der regionalen Wirtschaft, Erkenntnisse aus dem Bereich der angewandten Wissenschaft nutzbar zu machen zur Verbesserung der Sicherheitseigenschaften von Produkten und Verfahren, hat enorm zugenommen. Ebenso kann festgestellt werden, dass die Motivation des wissenschaftlichen Nachwuchses sich mit Sicherheitsthemen zu befassen sehr hoch ist. Als Schwerpunktthema der vierten Konferenz wurde deshalb „IT-Sicherheit & Privatheit in Zeiten von Big Data“ gewählt. Dieser Tagungsband veröffentlicht die wissenschaftlichen Facharbeiten, die auf der 4. Konferenz für Software-Technologien und -Prozesse (STeP‘14) vorgestellt wurden. Die akzeptierten Konferenzbeiträge gliedern sich neben den eingeladenen Vorträgen gemäß dem Anspruch der Konferenz in drei Bereiche: Industriepräsentationen, Beiträge junger Forscher sowie das technische Programm. Wir freuen uns, dass wir aus allen Kategorien qualitativ hochwertige Beiträge erhalten haben, so dass die STeP‘14, wie ihre Vorgänger, wieder ein sehr attraktives Programm bieten kann. Das Programmkomitee hatte 15 Mitglieder. Es wurden 17 Manuskripte eingereicht. Jeder Beitrag wurde von 3 Gutachtern begutachtet. Das Programm- komitee wählte schließlich 11 Facharbeiten zur Präsentation auf der Konferenz aus. Wir danken allen Autoren für die eingereichten Beiträge und den Gutachtern für ihre ausführlichen, konstruktiven und hilfreichen Kommentare zu den eingereichten Manuskripten. Das Konferenz-Programm umfasste ebenfalls zwei eingeladene Vorträge. In dem Vortrag‚ „Datenschutz: Ein Auslaufmodell?“ diskutiert Prof. Dr. Dr. h.c. Günter Müller von der Albert-Ludwig Universität Freiburg ein wenig provokant die Rolle des Datenschutzes in Zeiten von Big Data. In einem weiteren eingeladenen Vortrag welcher die Unternehmenssicht reflektiert, erörtert Amardeo Sarma von den NEC Laboratories Europe in Heidelberg das Thema: „Vertrauen und Privatheit: Ein überwindbarer Gegensatz?“. Die Kurzfassungen der einge-ladenen Vorträge befinden sich ebenfalls im

xii

Vorwort

Tagungsband der STeP‘14. Vielen Dank den eingeladenen Sprechern für die Annahme der Einladung. Die STeP‘14 fand am 20. Mai 2014 an der Hochschule Furtwangen statt, veranstaltet von der Fakultät Informatik der Hochschule Furtwangen. Die Konferenz wurde finanziell unterstützt von Endress und Hauser (Platin), M&M, ERNW (Gold), Cirosec, Intercard sowie Science + Computing (Silber). Als weitere Unterstützer der STeP’14 sind zu nennen das BMBF im Wissenschaftsjahr 2014 durch die Initiative „Die digitale Gesellschaft“, sowie die Forschungsprojekte SMARTIE, UNIKOPS und ProSeCCo. Wir freuen uns besonders, dass wir durch die Sponsoren in der Lage sind, die Teilnahme von Nachwuchsforschern an der Konferenz finanziell zu unterstützen und durch die Initiative „Die digitale Gesellschaft“, die besten Arbeiten der jungen Forscher auszuzeichnen. An der Organisation der Konferenz und an der Entstehung dieses Tagungsbandes waren viele Personen beteiligt. Wir sind unseren Kollegen aus der Fakultät Informatik, allen voran Fabian Berner, Johann Betz und Gerd Bitzer, dem Rektor der Hochschule Furtwangen, Herrn Prof. Dr. Schofer, und allen Helfern der Hochschule zu besonderem Dank verpflichtet. Ferner gebührt unser Dank dem Programmkomitee für die Begutachtung der Beiträge und seinen Einsatz, den engen Terminplan einzuhalten. Dem Oldenbourg Verlag danken wir für die gute Zusammenarbeit bei der Veröffentlichung des Tagungsbands.

Furtwangen, Mai 2014 Jens-Matthias Bohli, Friedbert Kaspar, Dirk Westhoff

Teil I: Eingeladene Vorträge

Datenschutz: Ein Auslaufmodell? Prof. Dr. Dr. h.c. Günter Müller Institut für Informatik und Gesellschaft Albert-Ludwigs-Universität Freiburg Die härteste Währung des «Cyberspace» sind die genutzte Aufmerksamkeit und die dabei abfallenden Daten. Das Geheimnis des Erfolges von u.a. Google und Facebook liegt in ihren unverzichtbaren Diensten, die das Sammeln von persönlichen Daten als Sekundärgeschäft erscheinen lässt. Wer geht noch in die Bibliothek, wer hat keine virtuellen Freunde und wer hält seinen Bekanntenkreis ohne Internet am Leben? Man denke nur daran, wie heute Musik vertrieben oder politische Meinungsbildung organisiert wird. Immer ist es die Kunst, Aufmerksamkeit zu erzeugen und zu wissen, mit wem man es zu tun hat. Ein riesiger Einbruch ist die omnipotente Position der NSA bzw. andere Geheimdienste. Es ist nun so, dass trotzdem gilt, wer viel Aufmerksamkeit durch nachgefragte Dienste gibt, dem wird gern auch Privates gegeben. War diese Transparenz und Offenheit z.B. für die Benennung der Menschenrechte im Iran oder in China begrüssenswert, hat man für eine Auskunft bei Google noch manches in Kauf genommen, so hat das systematische Ausspionieren nun den Unmut erhöht. Google-Glas ist noch nicht auf dem Markt, obwohl verfügbar, der Verkauf von Whats-App an Facebook hat die ökonomische Dimension verdeutlicht. Ein wenig Heuchelei ist allerdings auch dabei. Fast 100% der Kritiker haben ihr privates E-MailKonto bei einem Anbieter, der dann völlig legal Zugang zu den Inhalten haben kann. Der Wettlauf zwischen technischem Fortschritt und Datenschutz scheint aber trotz mancher solcher temporären Hindernisse entschieden. Im Vergleich zum objektiven Nutzen der Technik wirken die kleinen Grüppchen der Datenschützer wie anachronistische Idealisten, die vergeblich vor scheinbaren und immer neu erfundenen Gespenstern warnen. Im Einklang mit der Zeit dagegen sind diejenigen, die die Abschaffung des Datenschutzes als unzeitgemäss und fortschrittsfeindlich fordern. Wirtschaftlich gesehen entsteht dadurch ein Marktungleichgewicht, das es einer Seite ermöglicht, die andere Seite zu manipulieren. Das gegenwärtige Prinzip der Datenschutzgesetzgebung geht davon aus, dass nicht gegebene Daten auch nicht miss-braucht werden können. Dies ist seit Big Data ein Irrglaube, da Daten auch ohne Wissen auf Vorrat erhoben werden und jederzeit ausgewertet werden können. Bei einem wirksamen Datenschutz muss man das „Datensammeln“ verteuern. Dies ist eine Frage des Eigentums an Daten. Man stelle sich vor, Google und andere müssten jedes Mal den Dateneigentümer fragen, ehe sie dessen Daten verwenden. Gleichheit wäre hergestellt. Technisch möglich wäre es.

4

Müller

Kurzbiographie: Prof. Dr. Dr. h.c. Günter Müller Beruflicher Werdegang: 1976 Promotion in Duisburg zum Thema Semantik in Datenbankmodellen im Anschluss PostDoc bei IBM Almaden Research/USA, 1978 bei IBM Deutschland, verantwortlich für Daten- und Methodenbanken, später für Rechnernetze. 1987 IBM Direktor für Forschungsaktivitäten in Europa 1990 Berufung an die Albert-Ludwig Universität Freiburg zum Aufbau des Instituts für Informatik und Gesellschaft. 1999 Ernannte ihn die TU Darmstadt zum Inhaber der für ein Jahr vergebenen Alcatel Stiftungsprofessur. 2010 Erhielt er die Ehrenmedaille der WU Wien, sowie das Ehrenkreuz für Wissenschaft und Kunst, des österreichischen Bundespräsidenten. 2011 Erhielt er die Freundschaftsmedaille der Universität Zagreb und die Ehrenpromotion der TU Darmstadt.

Tätigkeitsschwerpunkt: 1976 Mitarbeit an SQL und dem 1. Relationalen Datenbanksystem R. 1985 Etablierung des europäischen Zentrums für Netzwerkforschung in Heidelberg (IBM-ENC). 1995 Mitbegründer der Fakultät für „Angewandte Wissenschaften“ der Albert-Ludwig Universität Freiburg. Er hat in Freiburg durch die Definition der mehrseitigen Sicherheit und Beiträge zum Signaturgesetz und zur europäischen E-Commerce-Inititative die Herangehensweise an die ITSicherheit verändert und die Abhängigkeit der Sicherheitsmechanismen von der Technikentwicklung erkannt. Die Verbindung von Sicherheit, Rechnernetzen und E-Commerce definiert den Spannungsbogen der Forschungen am IIG. Für seine Vorschläge für das P5-Protokoll bei X.400 (elektronische Post) wurde er von der ITU und der CCITT 1983 ausgezeichnet. Das Science and Technology Forum des Forschungsministeriums in Japan ernannte ihn für zwei Jahre zu ihrem Mitglied, wie er auch Mitglied der Enquetekommission Multimedia des Landtages Baden-Württemberg und von 1996 bis 1998 in den Beirat der Enquetekommission des Bundestages berufen wurde. Seit 1999 ist er Sprecher des Schwerpunktprogrammes der DFG “Sicherheit in der Informations- und Kommunikationstechnik”.

Vertrauen und Privatheit: Ein überwindbarer Gegensatz? Amardeo Sarma NEC Laboratories Europe Vertrauen beruht auf Offenheit und Information, meist das Gegenteil von Privatheit und Datenschutz. Der Kunde will wissen, ob der Anbieter verlässlich ist und er seine Dienste entsprechend den Erwartungen liefert. Transparenz ist zentral. Genauso muss ein Anbieter wissen, ob der Kunde verlässlich ist und zahlen kann. Eine ähnliche Offenheit braucht man auch für persönliche Beziehungen, wo Vertrauen auf Information, nicht auf Privatheit aufbaut. Dies gilt zumindest für bestimmte Informationen ohne die wir nur ein „blindes“ Vertrauen hätten. Privatheit und Datenschutz können aber auch Bedingungen für Vertrauen sind: 1. Offenheit ohne Zustimmung bezüglich ausgetauschter Daten gegenüber Dritten wird als Vertrauensbruch gesehen. Daten sollten auch nicht anders als erwartet zum Vorteil einer Seite verwendet werden: Wenn eine Geschäftsidee von dem anderen zu Geld gemacht wird wird das als Vertrauensbruch gesehen. Die geschäftliche Verwendung von persönlichen Daten wird noch als in Ordnung empfunden. Ob das so bleiben wird, ist aber offen. 2. Für Firmen spielt der Schutz der Daten bei Cloud-Diensten eine zentrale Rolle. Hier fehlt oft das notwendige Vertrauen, was auch ein Grund dafür ist, warum große Firmen trotz der erheblichen Kostenvorteile von einer Cloud-Nutzung Abstand nehmen. Gleichzeitig erkennen manche – so auch die Europäische Kommission – dass ein härterer Datenschutz bei europäischen Cloud-Diensten ein Wettbewerbsvorteil sein kann. Der Vortrag geht darauf ein, wie wir Vertrauen und Privatheit aufeinander abstimmen können und warum das alles auch eine Frage des wirtschaftlichen Erfolges sein kann. Optionen für die Zukunft werden skizziert.

6

Sarma

Kurzbiographie: Amardeo Sarma Amardeo Sarma received his Bachelor of Technology degree from the Indian Institute of Technology, Delhi, in 1977 and his Diplom-Ingenieur Degree from the Technical University of Darmstadt in 1980, both in Electrical Engineering. At NEC Laboratories Europe in Heidelberg, Germany, he is General Manager of the Software and Services Research Division, where his current responsibility includes the areas of Cloud Computing, M2M Services and the Internet of Things, Security and Trust, as well Smart Energy and Smart Transport. He previously worked for Deutsche Telekom and Eurescom. Amardeo was a Study Group Chairman at the ITU-T from 1996 – 2008, and is currently Chairman of the Board of Directors of the Trust in Digital Life Consortium (TDL). He is also ACM Member and IEEE Senior Member, and a member of the German Societies Gesellschaft für Informatik (GI) and Verband der Elektrotechnik Elektronik Informationstechnik (VDE). Besides his publications in journals and for conferences in the areas of networking, signalling, software engineering and identity management, Amardeo is co-author of two books and co-editor of several other books in the software engineering area. He has also authored two book chapters, one on self-organisation and one on identity management. In his spare time, Amardeo is active in voluntary organisations that promote the public understanding of science and critical thinking.

Teil II: Industriepräsentationen

Virtualisierung im Cloud-Zeitalter Spielt der Hypervisor noch eine Rolle? Dipl. Inform. (FH) Holger Gantikow science + computing ag Hagellocher Weg 73 72070 Tübingen [email protected] [email protected]

Abstract: Die Virtualisierungslösungen, die sich für Server-virtualisierung mit Linux eignen, werden sich im Funktionsumfang immer ähnlicher. Dies wird durch unterstützende Werkzeuge wie die libvirt weiter angetrieben. Wer mehr als einfach nur administrieren möchte, kann auf vielfältige Cloud-ManagementUmgebungen zurückgreifen, die praktisch jeden Virtualisierer unterstützen. Dies erweckt den Eindruck, dass die Wahl des Hypervisors bestenfalls zweitrangig ist. Eine Untersuchung auf Basis eines realen Szenarios aus dem IT-Alltag soll dieser Fragestellung nachgehen.

1

Virtualisierung im Cloud-Zeitalter

"Drum prüfe, wer sich bindet" wird nicht nur Heiratswilligen geraten, sondern darf auch für virtualisierungsfreudige Admins gelten. Beim Studium des Funktionsumfangs der mit Linux nutzbaren Virtualisierer kann schnell die Frage aufkommen, welche Lösung am besten zum geplanten Szenario passt. Von den unterstützten Funktionen immer weiter zusammengerückt, durch Hilfsmittel wie die libvirt [1] vereinheitlicht, buhlt eine große Anzahl von Virtualisierungslösungen um die Gunst der Admins, um in Cloud-Installationen oder einfach "klassisch" eingesetzt zu werden. Ob es sich lohnen kann selbst bei einer einfachen Problemstellung nicht einfach blind auf die erstbeste Lösung zu setzen, soll die folgende Untersuchung zeigen, die Xen, Kernel-based Virtual Machine (KVM), Oracles Virtualbox und VMwares ESXi als Virtualisierungsbasis für eine Build-Farm, wie sie unter anderem für das immer wichtiger werdende Continuous Integration genutzt werden kann, miteinander vergleicht.

10

Gantikow

1.1 Überblick über die x86 Virtualisierung Der Einsatz von Virtualisierungstechnologie hat sich beständig gewandelt. Von einer früher ausschließlich im Mainframe-Umfeld zu findenden Technologie, hat sie sich ab Ende der 90er Jahre des zwanzigsten Jahrhunderts auf dem x86-Massenmarkt zu einer Basistechnologie gewandelt, der auch weite Teile des Cloud-Computing Trends zu verdanken sind. Auch wenn es anfangs so aussah, als ob eine Virtualisierung auf Intel basierten Systemen technisch nicht möglich wäre, haben sich inzwischen eine Vielzahl von Lösungen etabliert, die sich für den Einsatz auf dem Desktop oder wie hier im Fokus stehend im Rechenzentrumsbetrieb eignen. Den Anfang machte hier VMware, die auch heute noch eine Marktführerrolle inne haben. Einige Jahre später folgte die OpenSource-Alternative Xen [2], die lange Zeit ein Synonym für Virtualisierung mit Linux darstellte und als Besonderheit eine Unterstützung für Paravirtualisierung mitbringt. Dabei ist dem Gast-System bewusst, dass es virtualisiert wird, was häufig eine besonders hohe Geschwindigkeit verspricht. Da sich die Integration in den Linux Kernel problematisch gestaltete, folgte KVM [3], die sich rasch steigender Beliebtheit erfreute und inzwischen von mehr Distributionen unterstützt wird als Xen. Auch jenseits der primär im Rechenzentrum eingesetzten Lösungen gibt es unter Linux eine Reihe von Virtualisierern die den Betrieb von mehreren GastSystemen in Form von virtuellen Maschinen (VMs) auf einem Host-System möglich machen. VMware bietet hier eine Reihe von kommerziellen Produkten an, alternativ steht mit VirtualBox eine freie Desktoplösung zur Verfügung.

1.2 Gestiegene Gemeinsamkeiten Die meisten dieser unterschiedlichen Lösungen bieten inzwischen Funktionen, wie man sie im Rechenzentrum benötigt. Live Migration [4], eine Funktion, die es ermöglicht, laufende virtuelle Maschinen praktisch unterbrechungsfrei von einem Host-System auf ein anderes umzuziehen, bietet inzwischen sogar die eigentlich auf dem Desktop angesiedelte VirtualBox. Auch Anforderungen wie die Nutzung mehrerer Prozessoren, inklusive entsprechender Virtualisierungsflags, einer großen Menge Arbeitsspeicher und eine breite Auswahl an 32- und 64-bit Gastsystemen erfüllen heutzutage alle Virtualisierer, häufig auch das Durchreichen von PCI-Geräten wie Grafikkarten. Selbst wer mit der ARM-Architektur virtualisieren möchte, steht vor der Qual der Wahl, so existiert für Xen bereits eine als produktiv einsetzbar bezeichneter Portierung, ein Ziel das KVM auch bald erreicht haben möchte.

Virtualisierung im Cloud-Zeitalter - Spielt der Hypervisor noch eine Rolle?

11

Neben der Vereinheitlichung des Funktionsumfangs der Virtualisierer kommt hinzu, dass die libvirt nahezu alle Hypervisor unterstützt [5]. Sie dient dazu die unterschiedlichen Interfaces der einzelnen Lösungen zu abstrahieren und den Benutzern einheitliche Werkzeuge, beispielsweise in Form der virsh (Abbildung 1) oder des grafischen virt-managers, zur Verfügung zu stellen ganz gleich womit sie im Hintergrund virtualisieren. Dies machen sich auch die vielen Cloudmanagementwerkzeuge wie OpenNebula [6] oder OpenStack zu nutze, die praktisch jeden Virtualisierer für Linux oder auch den in reinen Linux-Umgebungen weniger verbreiteten Hyper-V von Microsoft unterstützen können.

Abbildung 1: Die auf der libvirt aufbauende Kommandozeilenwerkzeug virsh unterstützt eine breite Hypvervisorauswahl.

1.3 Wahlfreiheit So stellt sich dem Systemverwalter bei all diesen Gemeinsamkeiten zu Recht die Frage welchen Hypervisor er einsetzen soll. Dass er diese Entscheidung nicht leichtfertig treffen sollte, zeigt sich bei der Evaluierung des Hypervisors für eine virtualisierte Buildplattform. Es soll eine virtualisierte Plattform für regelmäßig wiederkehrende, umfangreiche Compilejobs geschaffen werden, wie sie auch bei Nightly Builds im Zuge von Continous Integration immer häufiger genutzt werden. Die Anforderungen an eine solche Umgebung gestalten sich übersichtlich und decken nur ein Teilmenge der Funktionen eines modernen Hypervisors ab. Zu den benötigen Merkmalen zählt eine Unterstützung mehrerer 32- und

12

Gantikow

64-Bit Linux-Distributionen unterschiedlicher Versionen, Administrierbarkeit mittels Kommandozeile und grafischem Frontend. Funktionen wie das Durchreichen von PCI-Geräten werden hingegen nicht benötigt. Für Wartungsarbeiten sollte man die Unterstützung von Live Migration voraussetzen. Die Anforderungen an die virtuellen Build-Maschinen zeichnen sich durch moderate Ressourcenanforderungen, was RAM, CPU und IODurchsatz anbelangt, aus und entsprechen dem, was häufig auch für andere Infrastrukturdienste genutzt wird.

2

Testumgebung

Als Testumgebung dienten mehrere einheitlich ausgestattete Systeme, auf denen die unterschiedlichen Hypervisor-basierten Ansätze miteinander verglichen werden konnten.

2.1 Hardware Die Hardwarebasis bildeten drei identisch ausgestattete Dell Optiplex 745 Systeme, jeweils mit einem zweikernigen Intel Core 2 Duo 6300 mit 1.86 GHz und 4 GB RAM, sowie einer lokalen SATA-Festplatten und einer Gigabyte-Netzwerkkarte. Auch wenn es inzwischen modernere und leistungsfähiger Hardware gibt, so sind die Systeme, durch die vergleichsweise überschaubaren Ressourcenanforderungen eines Compilejobs und bereits verfügbarer Virtualisierungsunterstützung auf Prozessorebene, für das Szenario ausreichend. Den virtuellen Maschinen wurden folgende virtuelle Ressourcen zugewiesen: ein 64-Bit Prozessorkern, 2 GB Arbeitsspeicher und 8 GB Speicherplatz in Form eines virtuellen Plattenabbildes. Dies mag auf den ersten Blick recht bescheiden wirken, bewegt sich aber in der Größenordnung dessen, was oft für Infrastrukturdienste verwendet wird und ist auch für diesen Dienst realistisch dimensioniert.

2.2 Software Da es sich bei den Virtualisierungskomponenten neben den hardwareseitigen Virtualisierungsflags im Prozessor um reine Softwarekomponenten handelt, wurde besonders viel Augenmerk auf deren Auswahl gerichtet. So sind neben der Hypervisorkomponente das eingesetzte Betriebssystem und auch die dort eingesetzten Pakete und Konfigurationen relevant.

Virtualisierung im Cloud-Zeitalter - Spielt der Hypervisor noch eine Rolle?

13

2.2.1 Hypervisor Der Hypervisor stellt das Herzstück der Virtualisierung dar. Die Wahl fiel auf die etablierten Lösungen KVM, VMware ESXi und Xen. Als funktionsreicher Exot wurde VirtualBox mit ins Testfeld übernommen. Der Desktopvirtualisierer erfüllt auf dem Papier alle gestellten Anforderungen und soll zeigen, ob er sich auch im Serverraum eignet. Bedingt durch das generell linuxlastige Umfeld wurde auf eine Betrachtung des Hyper-V von Microsoft verzichtet. 2.2.2 Betriebssysteme Die Auswahl der in den Gastsystemen, und sofern nicht VMwares ESXi als Hypervisor eingesetzt wurde, auch in den Hostsystemen laufenden Linuxdistributionen, wurde zweigeteilt. So wurde einerseits CentOS, der freie Klon des im häufig im Unternehmenseinsatz zu findenden Red Hat Enterprise Linux (RHEL), das sich durch eine als eher konservativ zu bezeichnende Paketauswahl und langen Supportzyklen auszeichnet, als auch das mit neueren Versionsständen ausgelieferte OpenSUSE berücksichtigt. Für beide Distributionen sprechen eine Vielzahl von Punkten, im Unternehmenseinsatz setzt man allerdings durch entsprechende Supportverträge eher auf eine Enterprise Distribution wie RHEL, das hier durch den Klon CentOS vertreten ist. Die genauen Versionsstände der eingesetzten Komponenten sind in der Tabelle 1 dokumentiert. 64 Bit Betriebssystem + Software

OpenSUSE (12.3)

CentOS (6.4)

Linux-Kernel

3.7.10-1.1-desktop

2.6.32-358.6.1.el6.x86_64 3.9.2-1.el6xen.x86_64

KVM

1.3.0-3.3.2

1.0.3

XEN

4.2.1_12-1.8.1

4.2.2

VirtualBox

4.2.6-3.1.8

4.2.12_84980_el6

GCC

4.7-7.1.1

4.4.7

VMware ESXi

5.1.u1

5.1.u1

Tabelle 1: Versionsstände der eingesetzten Softwarekomponenten

14

Gantikow

Außer in Kombination mit dem ESXi Hypervisor vom VMware war das virtualisierte Gastsystem identisch mit dem Hostsystem. Dies reduziert die Anzahl der Testfälle und entspricht auch dem IT-Alltag. Wer auf seinen Servern eine bestimmte Distribution einsetzt, wird aus Gründen der Homogenität für virtuelle Maschinen in der Regel nicht eine zweite Distribution einsetzen. 2.2.3 Paketauswahl Um den Ressourcenbedarf der virtuellen Maschinen gering zu halten und da die Leistung der einzelnen Hypervisor im Vordergrund stand, wurden die Systeme so minimal wie möglich installiert. Dies heißt, dass jeweils die kleinste mögliche Basisinstallation durchgeführt wurde. Auf grafische Oberflächen oder zusätzliche Netzwerkdienste wurde bewusst verzichtet. Die für die Buildumgebung notwendigen Pakete und eventuelle Abhängigkeiten wurden im Anschluss an die Installation mit den Distributionswerkzeugen "yum" (CentOS) und "zypper" (OpenSUSE) nachinstalliert. Es wurde absichtlich auf eventuell mögliche Optimierung der durch die Distributoren gewählten Voreinstellungen verzichtet, um ein Ergebnis zu erhalten, das dem entspricht, was man ohne entsprechendes Expertenwissen erhält. Dies bedingt, dass die entsprechenden Pakete soweit möglich aus dem Lieferumfang der Distributionen installiert wurden. Bei OpenSUSE war dies ohne Schwierigkeiten möglich. So finden sich in den Repositories Pakete für Xen, KVM und VirtualBox. Bei CentOS war dieser Weg nicht möglich, da Red Hat seit Version 6 von Enterprise Linux kein Xen mehr unterstützt und auch ohne VirtualBox ausgeliefert wird. Die Xen-Installation wurde mit Paketen des "Xen made easy!"-Projekts von Steven Haigh [7] realisiert. VirtualBox wurde mit Paketen der Herstellers Oracle installiert.

2.3 Testfall aus dem IT-Alltag Da das zu realisierende Szenario eine virtualisierte Buildfarm darstellt, ist es naheliegend als Testfall einen typischen Compilevorgang mit mehreren Minuten Laufzeit einzusetzen. Die Wahl fiel auf das Samba-Paket, mit dem mehrfach hintereinander, durch ein kleines Bash-Skript (Quellcode 1) automatisiert, die bei einem Compilelauf notwendigen Schritte entpacken des komprimierten Quellcodes, sowie der configure und make-Lauf durchgeführt wurden. Hierbei wurden jeweils die einzelnen Zeiten gemessen und im Nachgang ausgewertet.

Virtualisierung im Cloud-Zeitalter - Spielt der Hypervisor noch eine Rolle?

15

Dieser Vorgang wurde mit beiden Distributionen sowohl direkt auf der Hardware, als auch in allen Hypervisorkombinationen durchgeführt. Zur Minimierung der Seiteneffekte war jeweils nur eine virtuelle Maschine aktiv und Ausreißer, wie sie durch einen automatisch startenden Cronjob auftreten können, konnten durch Deaktivierung von nicht benötigten Diensten ausgeschlossen werden. Nach jedem getesteten Hypervisor wurden sowohl die Hostsysteme, als auch die Gastsysteme komplett neu installiert. #!/bin/bash for run in 1 2 3 4 5 do echo run $run (time bash -c 'tar xf samba-3.6.15.tar.gz ;\ cd samba-3.6.15/source3; time ./configure; \ time make' ) >& logfile-$OS-$VIRTTYPE-$CPU-$run rm -rf samba-3.6.15 done Quellcode 1: Abbildung des Compilejobs mit einem Bash-Skript

Hierbei sei noch auf einen wichtigen Umstand hingewiesen: bei den Tests auf realer Hardware standen dem Compilevorgang im Gegensatz zur virtuellen Umgebung grundsätzlich beide Prozessorkerne und die volle Menge Arbeitsspeicher zur Verfügung. Dies mag auf den ersten Blick nicht nach einem fairen Vergleich aussehen, relativiert sich aber, wenn man sich die Eigenheiten des Testfalls vor Augen führt. Der durchgeführte Compilerlauf läuft nicht parallelisiert ab und nutzt somit effektiv nur einen Prozessor. Dies auch nur selten mit mehr als 50% CPU-Last. Auch bei den Arbeitsspeicheranforderungen zeigt sich der Bedarf mit weniger als 200MB recht moderat. Da der Fokus der Untersuchung auf dem Vergleich der Hypervisor untereinander und nicht zur Leistung direkt auf der Hardware liegt, ist der Aspekt, dass auf der blanke Hardware grundsätzlich mehr Ressourcen als virtualisiert zur Verfügung stehen, vernachlässigbar. Bei einem Test der höhere Ressourcen-Anforderungen stellt, können die Ergebnisse natürlich abweichen.

3

Ergebnisse

Die durch das Skript mitprotokollierten Werte wurden auf Ausreißer untersucht und bedingt durch homogene Zwischenzeiten der einzelnen Schritte auf die Gesamtlaufzeit des Compilevorgangs reduziert. Im weiteren Verlauf werden die einzelnen Laufzeiten relativ zur Laufzeit direkt auf der Hardware diskutiert. Die absoluten Werte sind in Tabelle 2 dokumentiert und die relativen Werte im Diagramm 1 aufbereitet.

16

Gantikow

3.1 Ohne Virtualisierung Gleich zu Beginn der Ergebnisauswertung fiel auf, dass bereits bei den Messungen direkt auf der identischen Hardware, ein deutlicher Unterschied in den Laufzeiten des Compilevorgangs, abhängig davon ob das Kompilat unter CentOS oder OpenSUSE erstellt wurde, existierte. So waren die Binärdateien unter CentOS immer wesentlich schneller erstellt. Die Ursache ist hierbei in den unterschiedlichen "gcc" Versionen zu sehen und zeigt, dass oft kleine Details große Auswirkungen haben können. Betriebssystem

OpenSUSE 12.3

CentOS 6.4

Mittel

%

Mittel

%

ohne Virtualisierung

07:24

100

06:09

100

Xen Paravirtualisierung

08:33

87

07:54

78

VMware ESXi

10:06

73

08:28

73

KVM

11:31

64

09:40

64

Xen Vollvirtualisierung

12:02

61

10:31

59

Oracle VM VirtualBox

25:31

29

18:39

33

+ Virtualisierung

Tabelle 2: Messergebnisse - Gesamtlaufzeiten und prozentuale Leistungsfähigkeit in Bezug auf die Laufzeit ohne Virtualisierung

3.2 Betriebssystemabhängigkeit Dies bedingt, dass sich nur die Messergebnisse bei identischem Betriebssystem und wechselnder Hypervisorschicht miteinander vergleichen lassen. Ein Vergleich der Laufzeiten der unterschiedlichen Betriebssysteme bei identischer Virtualisierung verbietet sich hingegen, da diese, wie bereits diskutiert, schon ohne Einsatz von Virtualisierung abweichen. Prozentual zur Compilezeit ohne Virtualisierung in Bezug gesetzt zeigt sich, dass die individuellen Virtualisierungsschichten, unabhängig vom darauf virtualisierten Betriebssystem, weitestgehend homogene Leistungen liefern, was Diagramm 2 deutlich zeigt. So ist der "Virtualisierungsoverhead" mal mit einem CentOS-Gast, mal mit einem OpenSUSE Gast geringer. Der deutlichste Unterschied ergibt sich im Xen-Szenario, bei dem mit dem freien RHEL Klon CentOS ein wesentlich höheren Verlust auftritt, obwohl bei beiden Distributionen eine relativ ähnliche Xen-Version eingesetzt wird. Der Teufel steckt auch hier wieder im Ver-

Virtualisierung im Cloud-Zeitalter - Spielt der Hypervisor noch eine Rolle?

17

sionsdetail. So wird in der CentOS-VM eine deutlich neuere Version des Linux-Kernels als bei OpenSUSE eingesetzt. Dies legt nahe, dass die Wahl des Betriebssystems vernachlässigbar ist und von den sonstigen Umgebungsanforderungen abhängig gemacht werden sollte. Gerade, wenn eventuell entsprechende distributionsabhängige Managementwerkzeuge einsetzt werden, ist ein Distributionswechsel oft mit einem signifikanten Aufwand verbunden.

Diagramm 1: Prozentuale Leistungsfähigkeit - die Leistung der Virtualisierer ist weitestgehend vom Betriebssystem unabhängig

3.3 Xen: Para- oder vollvirtualisiert Die Entscheidung, ob man Xen para- oder vollvirtualisiert betreiben sollte, ist schnell getroffen. Wenn die Möglichkeit zur Paravirtualisierung gegeben ist, sollte man sie nutzen, da sie mit einem deutlichen Leistungszuwachs gegenüber der Vollvirtualisierung einhergeht. Xen liefert in diesem Modus schnellere Ergebnisse als alle andren Virtualisierer. Ein vollvirtualisiertes Setup ist mit beiden Distributionen ähnlich langsam und sollte nur genutzt werden, wenn Gäste eingesetzt werden, die sich nicht paravirtualisieren lassen. So ist Xen im paravirtualisierten Modus sowohl KVM als auch ESXi unterlegen.

3.4 KVM oder Xen vollvirtualisiert Ein Vergleich von KVM mit einem vollvirtualisierten Xen erscheint am fairsten, auch wenn die Kernel-based Virtual Machine inzwischen eine Reihe von paravirtualisierten Treibern einsetzt.

18

Gantikow

Wer in diesem Szenario vor der Wahl zwischen KVM und Xen steht, sollte sich für KVM entschieden, auch wenn der Vorsprung eher gering ist. Wer para- und vollvirtualisierte Gäste einsetzen muss, kann zur Reduktion des Aufwandes durch eine zweite eigenständige Lösung für beide Szenarien auf Xen setzen. Der Vorsprung für KVM ist eventuell entsprechenden paravirtualisierten IO-Treibern geschuldet, auch wenn die IO-Last im untersuchten Fall eher gering ist. In einem kommerziellen Linux Umfeld bietet der Einsatz von KVM den großen Vorteil, dass beispielsweise Red Hat für KVM vollen Support gewährt. Bei einem selbstgebauten Einsatz von Xen ist dies nicht vorgesehen, da beginnend mit RHEL6 die Unterstützung für Xen entfernt wurde.

3.5 Kommerziell oder frei VMwares ESXi als Platzhirsch schafft auch in diesem Testaufbau nach wie vor eine gute Leistung. So muss er sich zwar einem paravirtualisierten Xen geschlagen geben, liefert aber deutlich bessere Ergebnisse als das restliche Testfeld. Dabei darf allerdings nicht außer Augen gelassen werden, dass es sich hierbei um ein kostenpflichtiges Produkt handelt, das je nach benötigtem Funktionsumfang teuer zu lizenzieren ist, speziell wenn man ein zentrales Management für mehrere Hosts benötigt. Inzwischen hat VMware die funktionale Limitierung auf 32GB pro Hostsystem in der freien Version entfernt. Die Stärken von ESXi liegen aber weiterhin in der weiten Verbreitung, auch jenseits der Linuxwelt.

3.6 Desktopvirtualisierung im Serverraum Von der Überlegung VirtualBox im Rechenzentrum einzusetzen sollte man recht schnell Abstand nehmen, zu deutlich ist der Abstand zur Konkurrenz. Selbst wenn VirtualBox auf dem Datenblatt mit der Unterstützung von Live Migration und der Möglichkeit zur Administration per Kommandozeile eine gute Figur macht: die Leistung spricht deutlich gegen die Desktoplösung. Im Vergleich zu Xen mit Paravirtualisierung dauert die Erstellung der Samba-Binaries gut drei mal so lange. In seinem klassischen Metier auf dem Desktop gelten andere Anforderungen, sodass VirtualBox trotz allem seine Daseinsberechtigung hat.

4

Zusammenfassung

Auch in Zeiten von flexiblen Cloud-Management-Lösungen, die praktisch jeden Hypervisor unterstützen, zeigt sich, dass dessen Wahl alles andere als irrelevant ist.

Virtualisierung im Cloud-Zeitalter - Spielt der Hypervisor noch eine Rolle?

19

Der schon mehrfach totgesagte Hypervisor Xen hat nach wie vor seine Daseinsberechtigung, wenn es um optimale Leistung geht und wird weiterhin aktiv weiter entwickelt und bildet die Basis für kommerzielle Produkte [8]. Die Kernel-based Virtual Machine hat in vielen Punkten zu den älteren Mitbewerbern aufgeschlossen und erfreut sich durch ihre langjährige Integration in den Kernel stetig zunehmender Beliebtheit. Wer bereits VMware Lösungen im Einsatz hat, kann diese bedenkenlos nutzen, nur von einem Einsatz einer Desktoplösung im Rechenzentrum sollte man Abstand nehmen. Der untersuchte Testfall betrachtet zwar nur einen kleinen Teil der möglichen Einsatzzwecke eines modernen Hypervisors und bei einem anderen Szenario mit höherer IO-Last, einer stärkeren Auslastung der Hostsysteme oder anderer Hardware sind durchaus andere Ergebnisse denkbar. Er zeigt aber, dass es mit einem flüchtigen Blick auf die Datenblätter nicht getan ist. Wer Wert auf optimale Ausnutzung seiner zur Verfügung stehenden Ressourcen legt, muss den umzusetzenden Testfall mit allen möglichen Optionen evaluieren, speziell wenn er eine größere Installation plant.

Literatur [1]

M. Bolte, M. Sievers, G. Birkenheuer, O. Niehorster, A. Brinkmann: Non-intrusive virtualization management using libvirt. In Design, Automation & Test in Europe Conference & Exhibition (DATE) 2010, S. 574-579

[2]

P.Barham,B. Dragovic, K.Fraser, S.Hand, T.Harris,A.Ho, R.Neugebauer, I. Pratt, A. Warfield: Xen and the art of virtualization. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), Bolton Landing, NY, USA, 2003, S. 164–177

[3]

A. Kivity, Y. Kamay, D. Laor, U. Lublin, A. Liguori: kvm: the linux virtual machine monitor. In Ottawa Linux Symposium Juli 2007, S. 225–230

[4]

C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Pratt, A. Warfield: Live migration of virtual machines. In Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2 (NSDI'05), Vol. 2. USENIX Association, Berkeley, CA, USA, S. 273-286

[5]

M. Loschwitz: Xen und KVM, die beiden wichtigsten Hypervisoren unter Linux - Unter einem Dach. In Linux-Magazin 10/13, S. 40-42

[6]

H. Gantikow, C. Raible: OpenNebula 3 - Sternenwolke. In Linux Magazin, 10/11, S. 8084

[7]

S. Haigh: Xen made easy! - Xen Installation Guide. URL: http://xen.crc.id.au/ support/guides/install/ [Zugriff am 18.02.2014]

[8]

H. Gantikow: Citrix Xenserver 6.2 wird Open Source - Endlich frei! In Linux- Magazin 10/13, S. 76-80

Cyber Physical Systems: Agile, adaptive und autonome Produktion – Steilvorlage für SoftwareAgenten Christian Dannegger M &M Software GmbH Consulting Industriestraße 5 78112 St. Georgen [email protected]

Abstract: Cyber Physical Systems(CPS), ein u.a. durch die Bundesinitiative Industrie 4.0 geprägter Begriff, steht für die immer engere Verknüpfung von virtueller und physischer Welt. Dies bezieht sich hauptsächlich auf Produktionsabläufe, die verteilt ablaufen, dabei autonom agieren und sich an eine permanent veränderte Umgebung adaptiv anpassen müssen. Taucht man etwas ein in die Eigenschaften von CPS so erkennt man schnell, dass es sich fast um dieselben Eigenschaften handelt, die vor 20 Jahren bereits im Zusammenhang von Software-Agenten diskutiert wurden. Deshalb möchte ich in diesem Vortrag etwas motivieren, auf die bestehenden Forschungsergeb-nisse aus diesem Bereich und deren Anwendungsfälle im Echtbetrieb zurückzublicken und diese an den Anforderungen der CPS zu spiegeln. Über Begriffe und Projekteum CPS und Industrie 4.0findet man schnell den Weg zum Thema der Softwareagenten. Ein kurzer Blick darauf und mögliche Lösungsarten führt dann schließlich zu Gedanken über das grundsätzliche Vorgehen und zu einem Konkreten Vorschlag, welche Eigenschaften ein Agentensystem für die Automatisierung aufweisen sollte. Eine kritische Be-trachtung von Vorteilen und Nutzen schließt den Vortrag ab.

1 Projekte Im Umfeld von CPS gibt es natürlich unzählige Projekte, die man kaum mehr erfassen kann – und schon gar nicht in einem so kurzen Vortrag erwähnen. Deshalb hier nur ein kurzer Eindruck über ein paar Aussagen, auf die man beim Querlesen trifft:



wachsen reale und virtuelle Welt immer weiter zu einem Internet der Dinge zusammen ... eingebettete Systeme in viele Alltagsgegenstände ... Verbindung von realer -physischer -und virtueller (Cyber-) Welt

22

Dannegger

... Cyber Physical Systems, CPS -verknüpfen Alltagsgegenstände mit intelligenten Steuerungsprozessen. ... Die Vernetzung von CPS per Internet … wird "Internet der Dinge und Dienste" genannt. ... verbesserte Feinsteuerung, Optimierung und völlig neue Produktionsmethoden ... Entwicklung intelligenterer Monitoring- und autonomer Entscheidungsprozesse Der Umfang der Projekte ist wirklich beeindruckend und macht die große Herausforderung klar. Die Vernetzung der Welt ist nicht mehr weg zu denken, die Globalisierung ebenso wenig und mit der Technik fortschreitenden Möglichkeiten auch die draus folgende Informationsflut. Wenn jeder Gegenstand im Internet der Dinge permanent Daten über sich und seine Umwelt aufnimmt, sind die daraus entstehenden Informationen eine große Chance, aber eben nur eine Chance – die man auch nutzen muss.

2 Begriffe Die Begriffe, die im Umfeld von CPS fallen, sind vielfältig. Dennoch er-kennt man eine Tendenz zu: Flexibel, Wandelbar, Adaptiv ebenso wie: Smart, Intelligent, und Autonom und Interaktion. Und natürlich alles was hinter dem Internet der Dinge steckt: Die Verbindung von realer mit virtuel-ler Welt, Repräsentanten von realen Dingen in der Software-Welt und deren SelbstOrganisation.

Cyber Physical Systems: Agile, adaptive und autonome Produktion

23

Abbildung 1: Begriffe im Umfeld von Cyber Physical Systems

3 Alles schon einmal da gewesen? Irgendwie kommen mir alle Begriffe und Themen sehr bekannt vor. Wohl deshalb, weil ich mich seit über 15 Jahren mit Softwareagenten beschäftige. In den Beschreibungen zum Internet der Dinge und Cyber Physical Systems liest man u.a. davon: 

Wie verteilt und intelligent optimiert werden kann.



Wie sich Produkte ihren Hersteller suchen.



Wie sich Produkte ihren Transport selbst organisieren könn(t)en.



Über Semantik und Ontologien.

 Über dezentrale Konzepte. 

Über Parallelität und Echtzeit.

Aber man erfährt wenig über die konkrete Umsetzung der genannten Punkte. Oft liest man über „Intelligente Stellvertreter“. Dies wiederum sind (Software-) Agenten. Agent (im Englischen) bedeutet so viel wie: Beauftragte(r), Bevollmächtigte(r), Handelnde(r), Vermittler(in), Vertreter(in), Broker(in). Die Softwareagenten-Technologie wird seit über 20 Jahren erforscht. Wieso also nicht die erfolgreichen Ergebnisse und Erfahrung dieser Forschung direkt nutzen?

24

Dannegger

4 Förder/-projekte um Softwareagenten Schon lange wird die Forschung um Softwareagenten gefördert. Hier möchte ich nur ein paar wesentliche Beispiele anführen. Die Idee des RoboCup ist inzwischen schon über 20 Jahre alt und wird weltweit zwischen den Forschern in vielen Ligen ausgetragen. Diese gibt es von der rein virtuellen Simulation League über verschiedene Robotergrößen bis hin zur humanoniden Liga mit zweibeinigen Robotern. Alle Eigenschaften sind gefordert: Echtzeit, autonom, strategisch, adaptiv, usw. In der DARPA Grand Challenge ging es um ähnlich autonome Herausforderungen und funktionierenden Sensoren und Aktuatoren im rauen Umfeld. Die Fahrzeuge mussten ohne externes Leitsystem eine Strecke durch die Wüste zurücklegen. An der Universität Bremen wurde im Rahmen des SFB 637 „Selbststeuernde Logistik“ in zahlreichen Bereichen der Transportlogistik, Intralogistik und Produktion erforscht. Und seit einigen Jahren kümmert sich der VDI/VDE-GMA Fachausschuss 5.15: Agentensysteme um die Standardisierung der Begriffe, Methoden und Technologien im Umfeld der Automatisierungstechnik.

5 Einsatzgebiete Softwareagenten wurden und werden bereits in zahlreichen Gebieten eingesetzt. Hier einige Beispiele aus der praktischen Anwendung. Filmproduktion in Hollywood: Die große Schlachten bekannter Blockbuster (z.B. Herr der Ringe) wurden über Softwareagenten inszeniert. Die Firma MASSIVE hat sich darauf spezialisiert. Realistische Darstellungen erfordern individuelles Verhalten der Akteure. Mehrere 100 Verhaltensmuster in der Software sorgte aber auch für überraschende Auswüchse: Manche Kämpfer rannten davon. Jeder Nutzer von eBay wendet automatisch einen Bietagenten an, der – autonom – das Gebot erhöht, solange das Maximalgebot noch nicht erreicht ist. In der Transportlogistik werden Trucks optimiert – in der Luftfahrt als Airtaxi die Piloten und Flugzeuge. Intelligente Ampelsteuerungen könnten für signifikante Reduktion des CO2-Ausstosses sorgen, wie eine Simulation beliebiger Kreuzungen gezeigt hat.

Cyber Physical Systems: Agile, adaptive und autonome Produktion

25

Allen Optimierungsaufgaben gemeinsam ist die Dynamische Ressourcenallokation in Echtzeit.

6 Softwareagenten Oft wird von Agenten-Technologie gesprochen, aber eigentlich handelt es sich um Paradigma, eine Vorgehensweise, eine Software-Design-Methode, die unabhängig von Technologie eingesetzt werden kann – wenn man will. Schaut man (mal wieder) zurück, so erkennt man, dass die Paradigmen immer der Technologie (konkret: Programmiersprachen) voraus waren. Gute Entwickler haben bereits in Assembler wiederverwendbaren Code eingesetzt, also Funktionen genutzt. In Pascal, C, etc. konnte man auch schon objektorientiert entwickeln, ohne dass dies explizit unterstützt wurde. Nun, in der objektorientierten Welt angekommen, kann man ebenso rollen- und zielorientiert arbeiten, ohne dass man ein spezielles Programmiersystem bräuchte. Es ist also wie mit dem Designprinzip „Form follows function“, nur dass es hier heisst: Technology follows paradigm: Das Konzept ist entscheidend, nicht die Programmiersprache.

7 Begeisterung Agenten-Paradigma heißt: abschauen in der Natur bzw. im „normalen“ Leben. So wie sich Tiere aber auch Menschen organisieren, könnten auch Software-Systeme arbeiten: Beim Ameisenalgorithmus werden Pheromone eingesetzt. Bienen oder Herdentiere besitzen eine gewisse Schwarmintelligenz. Winzige verteilte Sensoren erfassen als Smart Dust Säurewerte auf einem Acker. Aber auch Firmen bzw. Organisation arbeiten natürlicherweise bereits agentenorientiert: über Stellen-/Rollenbeschreibungen mit dezentraler Zielvorgabe. Agentenorientiert bedeutet: Verteilung, Delegation, Alternativen, Zielorientierung und … Vereinfachung, Vereinfachung, Vereinfachung, … RoboCup: Warum Fußball so viel komplizierter ist als Schach. Fußball birgt wesentlich mehr Eigenschaften der realen Welt als Schach. Die Umgebung ist dynamisch, die Änderungen vollziehen sich in Echtzeit, die Informationen über die Umwelt sind nie vollständig, die Steuerung ist verteilt, Wahrnehmung und Aktionen sind unscharf bzw. ungenau und es gibt unendlich viele Positionen–im Schach nur 64.

26

Dannegger

Die Spieler der Simulation League wurden gefüttert mit einer Zielhierarchie und arbeiten auf mehrere konfliktäre Ziele hin. Entscheidungen fallen 10mal pro Sekunde. Dabei gibt es auch noch eine Zielgewichtung, die situationsabhängig veränderlich ist. Man denke an die Wichtigkeit ein Tor zu schießen, wenn der Ball einen Meter vor dem eigenen liegt. Mit der richtigen Technologie passt die gesamte Verhaltensstrategie der Mannschaft mit vier Spielertypen auf jeweils 1,5 DIN A4 Seiten.

8 Lösungsarten Eine typische agentenbasierte Lösung kann man auf (mindestens) drei verschiedene Arten in Betrieb nehmen. Die Art hängt nur von der Anbindung der Außenweltüber Sensorik und Aktorik ab. 1.

Füttert man ein Agentensystem mit künstlich erzeugen oder aufgezeichneten Daten und zeigt man das Ergebnis nur am Bildschirm an, so hat man ein reines Simulationssystem.

2.

Kommen die Sensordaten aus der realen Welt und lässt das System daraus Schlüsse ziehen und Vorschläge errechnen (erarbeiten), so spricht man von einem Decision Support System. Es ist entscheidungsunterstützend, indem es die reale Welt analysiert, aber die möglichen Aktionen nicht ausführt, sondern nur vorschlägt.

3.

Sind Sensoren und Aktuatoren mit der „Außenwelt“ verbunden, so haben wir ein Control System mit geschlossenem Regelkreis.

9 Und nun? Entlang der Automatisierungspyramide gibt es für Agenten-Lösungen mehrere denkbare Ebenen. Auf Unternehmensebene (ERP/PPS) sind sie generell einsetzbar, aber diese Ebene liegt außerhalb typischer Automatisierungssysteme und soll hier nicht betrachtet werden. Auf Betriebsleitebene (MES) und Prozessleitebene (SCADA) können Agenten ihre Vorteile am besten ausspielen. Materialfluss und Produktionsoptimierung mit naher Anbindung an die Sensorik und Aktoriker möglichen adaptive und skalierbare Control Systems. Direkt auf der Steuerungsebene in einer SPS machen Softwareagenten auf den ersten Blick nicht so viel Sinn. Aber es wäre doch schön, wenn mit einer Steuerung auch gleich deren Logik mit geliefert und verbaut würde – Plug & Play eben. Es hängt ganz von der zugedachten Aufgabe eines Agenten ab, auf welcher Ebene er am besten Läuft.

Cyber Physical Systems: Agile, adaptive und autonome Produktion

27

Kleine lokale Aufgaben, wie z.B. fehlertolerante Messwertbehandlung können auch gleich „vor Ort“ erledigt werden. Ideal wäre eine Agentenplattform, die eine Entwicklung erlaubt, die unabhängig von der Laufzeit-Ebene ist –eine Entwicklungsumgebung für alle Ebenen von MES bis SPS.

10 Agenten-Plattform Für den sinnvollen Einsatz des Agenten-Paradigmas im Rahmen von Cyber Physical Systems sollte eine Agenten-Plattform mindestens folgende Funktionen bzw. Eigenschaften bieten: 

Agenten in einer (vereinfachten) Hochsprache entwickeln.



Generierung von IEC 61131-Code aus der Hochsprache.



Vollständig transparente Kommunikation zwischen allen Agenten auf allen Ebenen.



Entscheidung der Laufzeitebene eines Agenten zur Deploymentzeit oder sogar erst zur Laufzeit.



Einfachste Grundbausteine – sorgt für eine kurze Doku.



Umfassendes Beispiel – ist besser als seitenlange Handbücher.



Abkopplung von Echtzeitaufgaben –da dies in einer dynamischen und verteilten Umgebung schwer umsetzbar ist.



Zunächst Fokus auf Lösungen „aus einer Hand“, da die semantische Abstimmung der Kommunikation einfacher ist.

11 Vorteile Vorteile einer Lösung auf Basis des Agentenparadigmas sind: 

Natürlich paralleles Denken / Inhärente Parallelität, führt zu einer einfacheren Systemarchitektur.



Flexibler: in der Zusammenstellung von Komponenten.



Adaptiv: passt sich veränderter Konfiguration und Umgebung an.



Wartbarer: durch die strenge Modularisierung in parallel laufen-de Einheiten, sind die Teile des Systems einfacher und damit besser zu warten.

28

Dannegger



Simulation: ist meist inbegriffen.



Zielorientiert: Auch mit widersprüchlichen Zielen strebt ein Agentensystem immer in Richtung Optimum.



Dynamische Optimierung: Alternativen werden optimal ausgenutzt.

Neben den in Industrie-Projekten erfahrenen Vorteilen gelten aber auch die weiterhin bekannten Herausforderungen: 

Beweisbarkeit.



Wiederholbarkeit / Determinismus.



Echtzeitfähigkeit.

12 Optimum und Komplexität Ein wichtiges Ziel der meisten Anstrengungen und auch von Cyber Physical Systems ist der möglichst optimale Umgang mit Ressourcen und die Optimierung allgemein. Wenn man sich mit Optimierung in komplexen, hoch dynamischen Umgebungen beschäftigt, sollte man sich hierüber Gedanken machen: 

Kein System kann bei der üblichen Größe der echten Probleme und der Vielfalt der Möglichkeiten das 100-prozentige Optimum errechnen.



Ein Agentensystem strebt diesem aber laufend entgegen – ähnlich einem Navi, das geduldig immer wieder einen neuen Weg (eine neue optimale Lösung) sucht, wenn man sich verfahren hat.



Lieber fortlaufend – also sofort – verbessern, als nach tagelanger Rechnerei das echte Optimum kennen.



In einer Sekunde hat sich theoretische Optimum sowieso wieder geändert.

13 Nutzen Eine agentenbasierte Vorgehensweise zeigt viele Vorteile über alle Phasen des Software LifeCycle:

Cyber Physical Systems: Agile, adaptive und autonome Produktion

29

13.1 Entwicklung 

Strenge Modularisierung hält Lösung einfach.



Durch Rollenmodellierung nahe an der realen Welt.



Simulations-System lässt sich einfach ableiten.

13.2 Einsatz 

Dynamische Optimierung eines Ressourcenproblems.



Erweiterbarkeit zur Laufzeit.



Verteilte Lösung nutzt alle (Rechen-)ressourcen.



Zielorientierung nutzt neue Alternativen ohne Code-Änderung.

13.3 Wartung und Änderung  

Einfachere und damit kostengünstigere Anpassung durch strikte Modularisierung. Anpassung einfacher, da Lösung nahe am Geschäftsmodell (1:1Mapping von Realwelt zu Software-Repräsentant = Internet der Dinge).

14 Zusammenfassung Viele Anforderungen, die aus der Zielsetzung für Cyber Physical Systems hervorgehen, lassen sich mit dem Ansatz von Software-Agenten lösen oder zumindest besser behandeln als mit herkömmlichen Architektur-Ansätzen. Viele Aspekte und Forschungsergebnisse lassen sich wiederverwenden. Eine Untersuchung dieser Annahme ist auf jeden Fall lohnenswert.

Teil III: Young Researchers

Deterministische Manipulation von QuickResponse-Codes Georg Usmanov, Alexander Kaiser, Holger Kölle Fakultät Informatik Hochschule Furtwangen University Furtwangen, Deutschland {georg.usmanov, a.kaiser, holger.koelle}@hs-furtwangen.de

Abstract: Diese Arbeit befasst sich mit den Möglichkeiten der Manipulation von QR-Codes. Nach einer detaillierten Betrachtung des Aufbaus eines QRCodes werden anhand der gewonnenen Erkenntnisse eigene Ideen vorgestellt, die eine Manipulation ermöglichen oder vereinfachen können. Im nächsten Schritt wird eine günstige Angriffsmöglichkeit theoretisch abgehandelt. Außerdem wird eine der vorgestellten Möglichkeiten der gezielten Veränderung von QR-Codes anhand eines Beispiels durchgeführt und die dabei gewonnenen Erkenntnisse zusammengefasst.

1

Einleitung

Die japanische Firma Denso Wave stellte im Jahr 1994 den sogenannten QRCode (Quick-Response-Code) vor. Dieser Code besteht aus einer begrenzten Menge von strukturiert angeordneten binären Feldelementen. Durch die darin verbaute Redundanz ist es möglich, gespeicherte Daten selbst dann wiederherstellen zu können, wenn ein Teil der enthaltenen Informationen zerstört wurde. Diese Eigenschaft erlaubt die Verwendung des QR-Codes als Schnittstelle zwischen analogen Medien und digitalen Anwendungen unter dem Einsatz von Bilderkennungsmechanismen. So finden sich QR-Codes auf Wahl- und Werbeplakaten, Postern und Zeitschriften. Die zunehmende Verbreitung wirft dabei die Frage auf, wie gut diese Codes vor Manipulationen geschützt sind.

1.1 Das Angriffsszenario Bevor die Anfälligkeit des Quick-Response-Codes genauer betrachtet werden kann, muss zunächst der Begriff der Manipulation im Kontext dieser Arbeit definiert werden. Das erdachte Szenario besteht darin, dass Information eines beliebigen QR-Codes nur durch einfärben bestimmter Elemente des Codes selbst verändert werden. Dabei muss gewährleistet sein, dass der daraus entstehende neue QR-Code valide im Sinne der zugrunde liegenden Spezifikation (ISO/IEC STANDARD 18004) ist. So hat der Angreifer nur

34

Usmanov, Kaiser, Kölle

die Möglichkeit bestehende Felder von weiß auf schwarz zu verändern, um beispielsweise URLs abzuändern (siehe Abbildung 1). Welche Felder genau eingefärbt werden müssen, wird bestimmt durch die in den nächsten Kapiteln beschriebene Analyse des QR-Codes.

Abbildung 1: Angriffsszenario bei einer QR-Code-Manipulation. So könnte eine im QRCode hinterlegte URL durch Veränderungen einiger Felder manipuliert werden und beim erneuten Auslesen eine ungewollte Adresse aufrufen.

1.2 Aufbau dieser Arbeit In dem folgenden Kapitel werden Grundlagen zum Aufbau eines QR-Codes und dessen mathematischen Besonderheiten vermittelt. Die darin beschriebenen Merkmale sind relevante Auszüge aus der QR-Code-Spezifikation und dienen im darauffolgenden Kapitel als Wissensbasis für die vorgestellten theoretischen Ansätze der Manipulation von QR-Codes. Das anschließende, vorletzte Kapitel beschreibt die praktische Anwendung einer Manipulation anhand eines QR-Codes und liefert damit einen Beweis der grundsätzlichen Durchführbarkeit und zeigt damit verbundene Einschränkungen auf. Das letzte Kapitel liefert ein Résumé zu der durchgeführten Veränderung eines gegebenen QR-Codes und fasst die gewonnenen Erkenntnisse zusammen.

2

Bestandteile und Funktionsweise des QR-Codes

Jeder QR-Code ist definiert als eine zweidimensionale Matrix, dessen Elemente die Zustände Null oder Eins annehmen können (siehe Abbildung 2). Im Rahmen dieser Arbeit wird das weiße Farbfeld als null und das Feld schwarz als eins bezeichnet. Die abbildbare Informationsmenge hängt dabei von der Version, der Redundanzstufe und der verwendeten Kodierung ab. Es gibt noch eine Reihe weiterer Komponenten, die in einem QR-Code verwendet werden. Dieser Abschnitt betrachtet einige der für diese Arbeit Relevanten Bestandteile des QR-Codes, die in dem folgenden Kapitel als Basis für weitere Analysen verwendet werden. [1, S. 6ff]

Deterministische Manipulation Quick-Response-Codes

35

Abbildung 2: Feldgröße eines QR-Codes in Abhängigkeit von der verwendeten Version. Wie in dieser Abbildung zu sehen ist, sind QR-Codes in 40 verschiedenen Größen definiert und können damit unterschiedliche Mengen an Daten darstellen.

2.1 Repräsentation von Nutzdaten Der Bereich der Nutzdaten (engl.: „Encoded Data Stream“) aus Abbildung 3 beinhaltet die für den Leser des QR-Codes relevanten Informationen (z.B. URLs oder Text) in einer binären Form. Hierbei ist anzumerken, dass durch die Version und das Redundanzlevel eine bestimmte Anzahl von 8-BitBlöcken geschrieben werden muss. Sind die encodierten Nutzdaten kleiner als die vordefinierten Blöcke, werden die restlichen Bytes abwechselnd mit einer Sequenz aus und beschrieben. Dieser Bereich der aufgefüllten Daten wird auch als „Padding“ bezeichnet. Nutzdaten deren Redundanz berechnet werden soll, werden wie bereits erwähnt, in Blöcke mit jeweils acht Bit aufgeteilt. Jeder dieser Blöcke repräsentiert ein Polynom in über dem irreduziblen Polynom . Damit ist gewährleistet, dass das Ergebnis aller arithmetischen Operationen innerhalb des ebenfalls acht Bit lang ist. So entspricht beispielsweise eine geschriebene Sequenz dem dieser endlichen Menge. Damit alle Ergebnisse der Multiplikation zweier Potenzen von Primitivwurzeln im gespeichert werden können, bedarf es einer Tabelle mit Einträgen. Um die Berechnung zu vereinfachen, werden ausgehend vom α-Wert durch Linksshift und – Operationen mit dem erwähnten Primpolynom die ersten 256 Einträge berechnet. Damit lassen sich alle Multiplikationen von mit deren Summe der Exponenten kleiner als 256 ist, direkt aus der Tabelle ablesen. Größere Potenzen von werden dabei zunächst als Produkt aus den ersten 256 Einträgen dargestellt und berechnet. Die hier beschriebene Interpretation gilt ebenso für den gesamten Datenbereich. [1, S. 67, 84], [3, S. 2, 4ff, 9], [4, S. 38, 41]

36

Usmanov, Kaiser, Kölle

Abbildung 3: Darstellung des Nutzdatenbereichs. Hierbei ist zu erwähnen, dass sich der Schreibvorgang, so wie in der Abbildung angedeutet durchzieht. Wie aus der Abbildung ersichtlich ist, besteht der Nutzdatenbereich aus einer Reihe von Metainformationen, die den eigentlichen enkodierten Datenstrom definieren.

2.2 Erstellung und Korrektur des Redundanzbereichs Nachdem die Nutzdaten beschrieben wurden, wird der Redundanzbereich berechnet. Dieser Bereich ermöglicht die Lesbarkeit von Nutzdaten unter fehlerhaften Lesebedingungen. Zur Bildung der Redundanzblöcke wird ein Reed-Solomon-Code über dem ) verwendet. Dieser zyklische Blockcode zeichnet sich dadurch aus, dass blockweise auftretende Übertragungsfehler erkannt und korrigiert werden können. Für die Berechnung der Redundanz mit den Reed-Solomon-Codes, wird abhängig von der Version und der Redundanzstufe ein Generatorpolynom aus der Spezifikation ausgelesen. Jedes Generatorpolynom wird dabei über das Produkt gebildet. Ein Beispiel, welches zur Erzeugung von 10 Korrekturblöcken verwendet wird, findet sich in Abbildung 4.

Abbildung 4: Beispiel für die Berechnung eines Generatorpolynoms der Größe =10. Hier ist anzumerken, dass sich jeder -Wert im irreduziblen Polynom befindet.

Bei der Erstellung des Redundanzbereichs werden im ersten Schritt die Nutzdaten mit Byte, dessen Redundanzpolynom berechnet werden soll, mit multipliziert. Dabei ist die Anzahl der vorgesehenen Redundanz-Bytes. Im nächsten Schritt wird Byte des Datensatzes in das Redundanzpolynom eingesetzt und an der entsprechenden Stelle mit dem Datensatz über die -Operation mit dem Nutzdatenbereich verrechnet. Das Resultat wird in den entsprechend definierten Redundanzbereich geschrieben. Zur Korrektur von Bereichen, die über die Syndromberechnung als falsch eingestuft wurden, wird der Berlekamp-Massey-Algorithmus innerhalb dieser Arbeit verwendet. Mit diesem kann

Deterministische Manipulation Quick-Response-Codes

37

für eine beliebige Folge von Byte-Sequenzen das kürzeste LSFR (Linear Shift Feedback Register) gefunden werden und ermöglicht damit eine effiziente Dekodierung von Reed-Solomon-Codes. [1, S. 67ff, 74-77, 80], [2, S. 27], [3, S. 4ff, 7, 10ff, 18, 21ff], [4, S. 31, 102ff, 142ff, 235], [5, S. 76]

2.3 Rolle von Masken An dieser Stelle ist zu erwähnen, dass Masken neben der Redundanzberechnung im Verlauf dieser Arbeit eine wesentliche Rolle spielen. Sie erfüllen zwei Aufgaben. Zum einen sollen sie verhindern, dass durch das Beschreiben von Daten in die vorgeschriebenen Bereiche, Muster entstehen, die das Lesen erschweren oder gar unmöglich machen. Zum anderen soll die Verteilung zwischen schwarzen und weißen Bereichen möglichst ausgeglichen sein, sodass keine zusammenhängenden einfarbigen Bereiche entstehen. Die Masken kommen zum Einsatz, nachdem der Nutzdaten- und der Redundanzbereich vollständig in den QR-Code geschrieben wurden und werden auch nur auf diese zwei Bereiche des QR-Codes angewendet. Um zu verhindern, dass Muster entstehen, die zu Problemen beim auslesen des QR-Codes führen würden oder zu Bereichen die gänzlich schwarz oder weiß sind, werden Masken verwendet. Dabei definiert die Spezifikation acht verschiedene Masken, die vom Ersteller des QR-Codes über eine Operation über den bereits erwähnten Datenbereichen angewendet werden. Dabei wird nach den in der Spezifikation definierten Kenngrößen jede Maske durchprobiert und die günstigste gewählt. [1, S. 51-53]

3

Analyse der Angriffspunkte

In diesem Abschnitt wird der Aufbau des QR-Codes dahingehend untersucht, wie bestimmte Bereiche gezielt verändert werden können, um das Ergebnis beim Auslesen zu verfälschen.

3.1 Ausschluss von Anpassbarkeit einzelner Bereiche Wenn man sich die Bestandteile der Rahmenstruktur anschaut, wird recht schnell deutlich, dass Änderungen an diesen Bereichen nicht zielführend sind. So führen beispielsweise Veränderungen an den Maskeninformationen oder der Redundanzstufe zur automatischen Korrektur der zugrundeliegenden BCH-Codes oder zur Unlesbarkeit des QR-Codes selbst. Die Versionsinformation kann ebenfalls nicht verändert werden, weil diese nicht ohne weiteres durch schwarz färben in eine andere Version überführbar ist. Zudem ist die Größe des QR-Codes nicht änderbar und würde somit in jedem Fall zu Lesefehlern führen. Im Gegensatz zur Rahmenstruktur besteht die Möglichkeit, dass der Datenbereich angepasst werden kann. Im Folgenden

38

Usmanov, Kaiser, Kölle

sind einige Vorschläge zur potentiellen Manipulation beschrieben.

3.2 Nutzdatenänderung mit Redundanzkorrektur Die erste Möglichkeit besteht darin, den Datenbereich zu verändern und daraufhin das Redundanzpolynom neu zu berechnen. Diese Methode hat zwei Einschränkungen. Zum Einen muss eine beliebige Änderung über schwarzfärben dieses Bereichs bewerkstelligt werden und zum Anderen das bestehende Redundanzpolynom durch einfärben abbildbar sein. Hierbei können einige Blöcke sowohl Nutzdatenbereich, als auch im Redundanzpolynom falsch sein. Deshalb geht es in diesem, als auch in den Folgeansätzen immer um einen Abstandsvergleich zwischen dem Originalpolynom und der gebildeten Variante. Dies ist in Abbildung 5 dargestellt. Die Grafik beschreibt zwei korrekte Codewörter , und ihren Korrekturraum. Alle fehlerbehafteten Wörter werden, sofern diese unter einer bestimmten fehlerhaften Blockanzahl sind, automatisch zu korrekten Codewörtern korrigiert. Bei der Redundanzkorrektur werden daher Kandidaten gesucht, in ein Codewort überführt werden bei denen ein fehlerhaftes Codewort kann. Dabei soll der Unterschied zwischen und möglichst gering sein. Die Anzahl der Blöcke die inkorrekt sein dürfen, hängt von der Version und dem Redundanzlevel ab. Da über die verwendeten Reed-Solomon-Codes Fehlerkorrekturen automatisch stattfinden, dürfen bei gerader Blockanzahl Blöcke falsch sein, ohne dass dabei die Wiederherstellung der Originaldaten gefährdet wird. [3, S. 2]

Abbildung 5: Korrekturraum zweier Codewörter und . Hier ist zu sehen, dass eine Manipulation dann erfolgreich ist, wenn ein fehlerbehaftetes Codewort über eine Modifikation in ein Codewort übertragen wird, sodass dieses in das Codewort zurückkorrigiert werden kann.

Deterministische Manipulation Quick-Response-Codes

39

3.3 Datenänderung durch Rückwärtskorrektur Eine weitere Möglichkeit besteht darin, dass zunächst aus dem ausgehenden Redundanzpolynom Kandidaten gebildet werden, die durch schwarzfärben möglich sind. Danach werden die Kandidaten nacheinander auf ihre Tauglichkeit überprüft. Dies geschieht durch Anwendung von Korrekturmechanismen des Reed-Solomon-Codes. Im nächsten Schritt werden diese automatisch korrigierten Datenbereiche analysiert, um bestimmte geeignete Kandidaten zu finden. Als geeignet gelten Kandidaten, wenn der korrigierte Nutzdatenteil einer Manipulation im definierten Sinne entspricht. Bei dieser Manipulationsart kann es vorkommen, dass der Paddingbereich verändert wird. Dieser wird durch die definierte Längenangabe nicht interpretiert und spielt für die QR-Code-Erkennung technisch gesehen keine Rolle, verletzt jedoch die Spezifikation.

3.4 Paddinganpassung zur Datenänderung Neben den bereits beschriebenen Möglichkeiten können Änderungen auch an der Längenangabe für den Nutzdatenbereich gemacht werden. So kann durch die Änderung an den Bits für die Länge, ein Teil des Paddings als Nutzdatenbereich interpretiert werden. Wie in Abbildung 6 dargestellt, werden zunächst die Längenangaben geändert. Im nächsten Schritt wird die Datenänderung auf dem neuen Nutzdatenteil durchgeführt. Anschließend wird das zugehörige Polynom berechnet und mit dem Ursprungspolynom des Originaldatensatzes verglichen. Die Möglichkeit den Datenbereich durch eine Variation in der Größe verändern zu können, ermöglicht eine größere Menge an Kandidaten, die die Wahrscheinlichkeit einer erfolgreichen Manipulation erhöhen. Allerdings muss erwähnt werden, dass der Paddingbereich, wie in den Grundlagen beschrieben, aus zwei sich abwechselnden Bitsequenzen besteht und jede Änderung eine Abweichung von der Spezifikation darstellt. Jedoch werden die Paddingsequenzen in einigen gängigen Implementierungen beim Lesen des QR-Codes nicht berücksichtigt.

40

Usmanov, Kaiser, Kölle

Abbildung 6: Hier ist zu sehen, wie durch die Anpassung des Paddingbereiches weitere Nutzdatenblöcke gewonnen werden können um Manipulationskandidaten zu finden.

3.5 Datenänderung durch Kollisionen Ein weiterer Ansatz besteht darin, Kollisionen im Redundanzpolynom zu finden. Wie bereits erwähnt, wird der Nutzdatenbereich mit Encoding und Längenangabe über das Reed-Solomon-Verfahren in einem endlichen Redundanzblockbereich abgebildet. Hat der Datenbereich mehr Blöcke als der Redundanzbereich, kommt es durch die Abbildung in eine kleinere Menge zwangsläufig zu Kollisionen. In Folge dessen ist es theoretisch möglich, dass zwei komplett unterschiedliche Nutzdaten auf dasselbe Redundanzpolynom abgebildet werden können. In der Praxis würde dies zu mit testbaren Kombinationen führen, unter der Berücksichtigung, dass statistisch gesehen nur die Hälfte aller Feldelemente weiß sind.

3.6 Einordnung der Angriffsmöglichkeiten Betrachtet man die beschriebenen Angriffsmöglichkeiten, dann lässt sich feststellen, dass der Ergebnisraum sich aus allen Variationen des Redundanz- und Nutzdatenbereichs zusammensetzt. In Abbildung 7 ist zu sehen, dass sowohl der Ansatz der Datenänderung über Polynomkorrektur als auch die Datenkorrektur durch Redundanzänderung zwei große Ergebnisräume darstellen. Die Größe dieser Räume wird bestimmt durch die Maximalanzahl der Kombinationsmöglichkeiten beim Einfärben der weißen Bereiche. Dabei ist die Abweichung von der statistischen Gleichverteilung auswirken kann. eine Größe, die sich positiv auf den Ergebnisraum

Deterministische Manipulation Quick-Response-Codes

41

Die Paddinganpassung ist in diesem Bild nicht explizit erwähnt, bildet jedoch eine kleinere Untermenge von . Die Datenänderung über Kollisionen ist einer sehr kleinen Untermenge von zuzuordnen. Möchte man nun gezielt nach Ergebnissen suchen, wird aufgrund der statistischen Gegebenheiten immer im Mengenraum gesucht. Die Methoden aus Abschnitt 4.3 und 4.4 können dabei zusammen verwendet werden, um Ergebnismengen aus und zu bilden, welche die Einschränkungen der Syntax von URLs erfüllen. Die Restmenge aus bildet sich aus einer Verteilung von fehlerhaften Blöcken auf den Nutzdaten und - den Redundanzbereich.

Abbildung 7: Übersicht über die vorgestellten Manipulationsmöglichkeiten mit deren Mengen an möglichen Kandidaten.

4

Durchführung der Manipulation

Aus den vorgestellten Möglichkeiten zur Veränderung des Datensatzes wurde die Methode der Datenänderung mit Redundanzkorrektur gewählt. Der Grund dafür ist einerseits die Gewährleistung der spezifikationsgetreuen Änderung und andererseits der verhältnismäßig überschaubare Aufwand bei der Durchführung. Dieser Abschnitt zeigt die Umsetzung des konzeptionellen Vorgehens, sowie gewonnene Ergebnisse.

4.1 Abstand zweier Datenpolynome Bevor das durchgeführte Verfahren zur Kandidatenerstellung erklärt wird, muss zunächst der zugrundeliegende Algorithmus zur Abstandsberechnung zweier Polynomen erklärt werden. Dieser Abstandsvergleich ist der wichtigste Bestandteil des „proof of concept“. Da der Hamming-Abstand hier nicht als Abstandsmaß verwendet werden kann, wird eine eigene Abstandsdefinition eingeführt. Die Begründung dafür ist die Tatsache, dass in dem

42

Usmanov, Kaiser, Kölle

Angriffsszenario der Abstand zu einem Polynom auch dann als Null gilt, wenn Polynom A in Polynom B durch das Einfärben von Bereichen überführt werden kann. Außerdem wird der Abstand selbst über Blöcke und nicht über die einzelnen Datenbits definiert. Der Grund hierfür ist die blockweise Korrektur des Reed-Solomon-Codes. Wie erwähnt darf eine Anzahl an Polynomteilen, welche aus 8-Bit-Blöcken bestehen, falsch sein. So ist die hier beschriebene Distanz exakt die der falschen -Blöcke in dem verwendeten Polynom. Der Algorithmus zur Berechnung der erwähnten Distanz ist in Abbildung 8 veranschaulicht. Wie zu erkennen ist, wird über jeden -Wert beider Polynome iteriert. Wenn es möglich ist einen -Wert in das Gegenstück des anderen Polynoms an derselben Stelle durch Schwarzfärben darzustellen, so verringert sich die Distanz jeweils um eins. Kann ein Polynom durch schwarzfärben ohne Fehler in das zweite Polynom überführt werden, dann ist der Abstand null.

Abbildung 8: Abstandsberechnung zum Vergleich zweier Polynome. Diese Funktionalität ist notwendig, um bei der Kandidatenbildung Varianten zu bilden, die miteinander verglichen werden können.

4.2 Der Ausgangs-QR-Code Für den „proof of concept“ wird ein QR-Code der Version 1 mit der Redundanzstufe „Medium“ und dem Encoding-Format „numeric“ verwendet. Um mögliche Fehlerquellen durch nicht spezifikationsgetreue QR-Code-Generatoren ausschließen zu können, wird der QR-Code aus der Spezifikation ISO/IEC STANDARD 18004 genutzt. Ziel ist es zu zeigen, dass es generell möglich ist QR-Code-Lesegeräte dazu zu bringen, einen manipulierten QRCode im definierten Sinne lesen zu können. Dieses Prinzip lässt sich bei gleicher Vorgehensweise auch auf andere Dateninhalte anwenden.

Deterministische Manipulation Quick-Response-Codes

43

4.3 Vorgehensweise bei der Manipulation Das implementierte Programm zur Generierung von Varianten, die durch das Färben des originalen QR-Codes möglich sind, führt eine Reihe von Schritten durch. Diese werden in den folgenden Abschnitten beschrieben. 4.3.1 Extrahieren von Information Im ersten Schritt wird der QR-Code hinsichtlich der Rahmenstruktur untersucht. Dabei werden Informationen wie Maske, Kodierungslevel und Version extrahiert. Damit lässt sich die passende Struktur des Datenobjekts anlegen und das korrekte Redundanzpolynom für die spätere Generierung neuer Redundanzbereiche verwenden. Außerdem lassen sich die Masken für die entsprechende Größe vorgenerieren. Neben den Rahmendaten wird der Nutzdatensatz separat extrahiert um Variantenfragmente zu bilden. Fragmente sind alle möglichen Kombinationen, die durch einfärben von weißen in schwarze Bereiche möglich sind. Der Zusammenhang zwischen den extrahierten Daten und den generierten Fragmenten findet sich in Abbildung 9.

Abbildung 9: Jedes Byte des Nutzdatenbereiches (ausgenommen Encoding und Länge) wird extrahiert. Für jedes dieser extrahierten Bytes, die einem -Wert des Nutzdatenpolynoms entsprechen, werden Varianten gebildet und für die spätere Kombination in eine Fragmentliste eingetragen.

4.3.2 Erstellung von Kandidaten In diesem Schritt werden komplett neue Nutzdatenbereiche generiert. Dies geschieht durch den Zusammenbau von -Werten aus der Fragmentliste zu einem neuen Polynom (siehe Abbildung 10). Dabei muss beachtet werden, dass Encoding, Längenbereich und Padding unverändert bleiben, da sonst

44

Usmanov, Kaiser, Kölle

der Datenbereich von Lesegeräten nicht interpretierbar wäre.

Abbildung 10: Zusammenbau eines neuen Nutzdatenpolynoms über Kombination der Fragmentlisten.

4.3.3 Fertigstellung des Datenbereichs Nachdem das neue Nutzdatenpolynom erzeugt wurde, muss der Redundanzbereich neu berechnet werden. Das geschieht durch die Verwendung des Reed-Solomon-Codes. Aus dem ausgelesenen QR-Code sind Parameter bekannt, die die Blocklänge für das Redundanzpolynom festlegen. Diese Länge wird auch verwendet um den neuen Nutzdatenbereich zu bilden und den Redundanzbereich neu zu berechnen. Nach der Neuberechnung wird die in dem Original-QR-Code definierte Maske auf den neu erstellten Redundanzbereich gelegt. 4.3.4 Prüfung der Kandidaten In diesem Schritt wird das maskierte Originalredundanzpolynom mit dem erstellten verglichen. Dies geschieht über den in Abbildung 8 beschriebenen Algorithmus zum Abstandsvergleich zweier Polynome. Der Sinn dieses Vergleichs liegt darin, dass bestimmt werden kann, wie viele Blöcke des Redundanzpolynoms in der jeweiligen getesteten Variante durch die einzige gültige Operation nicht korrekt dargestellt werden können. Dabei gilt auch hier die Gesetzmäßigkeit dass Blöcke falsch sein dürfen. In dem Blöhier erwähnten Beispiel besteht der QR-Code aus insgesamt cken. Durch die Redundanzstufe Medium ist definiert, dass davon den Nutzdatenbereich bilden. Daraus folgt, dass die Varianten gültig, deren Redundanzpolynome maximal 5 fehlerhafte Blöcke aufweisen. Bei maximal 5 fehlerhaften Blöcken können hier über die Syndromberechnung alle Blöcke korrigiert werden. Da die Nutzdaten der Varianten aus der beschriebenen Fragmentliste kommen und die Liste selbst nur valide Fragmente beinhaltet, ist per Definition kein fehlerhafter Block vorzufinden. Deshalb wird der

Deterministische Manipulation Quick-Response-Codes

45

Vergleich nur über das Redundanzpolynom durchgeführt. Der Auszug in Abbildung 11 zeigt eine gefundene, valide Variante, deren Polynomteile als Byte-Blöcke in Dezimalform ausgedrückt werden. [FOUND] Nr. 1215166 with distance: 4, coloring effort: 19, polynomial list (dec): [113, 166, 53, 236, 108, 174,106, 9, 141, 53, 126, 88, 244, 112, 106, 0, 115, 253, 195, 184, 201, 229, 82 ] Abbildung 11: Gefundene, gültige Variante mit 4 falschen Blöcken. Jede ausgegebene Zahl aus der Liste mit 23 Elementen repräsentiert einen -Block des Nutzdatenbereichs und des Redundanzpolynoms. Die ersten 3 Byte beinhalten Version und Längenangabe und wurden somit auch nicht bei der Kandidatenbildung und der Ausgabe berücksichtigt.

4.3.5 Auswahl der günstigen Varianten Da nun die Liste aus validen Varianten durch den Zusammenbau von Fragmenten und der Neuberechnung des Redundanzpolynoms mit anschließender Distanzberechnung gegeben ist, werden diejenigen ausgewählt, die am wenigsten Veränderungen im Original-QR-Code benötigen. Damit wird das Risiko minimiert, dass zu große Schwarzbereiche oder ungünstige Muster bei der Manipulation entstehen. Nachdem diese Variantenliste gefiltert wurde, wird eine Art Maske generiert. Sie zeigt Stellen, an denen die Veränderungen eingezeichnet werden können. Abbildung 12 zeigt ein fertig manipuliertes Beispiel, dass über den beschriebenen Algorithmus berechnet wurde.

Abbildung 12: Notwendige zu färbende Bereiche für eine Manipulation. Hier werden 19 Felder gefärbt, die sich aus den Ergebnissen der Zusammensetzung der Fragmentlisten ergeben haben.

4.3.6 Relevante Manipulationsvarianten Abschließend werden nun aus der Liste der günstigen Varianten, diejenigen herausgefiltert, deren Nutzdaten ein bestimmtes, für eine gezielte Manipulation relevantes Muster erfüllen. So wäre ein solches Muster aus der in der Aufgabenstellung definierten Manipulation eine URL, die sich vom Original unterscheidet. Allerdings konnte bei den durchgeführten Versuchen mit der Implementierung kein solches Ergebnis gefunden werden. Theoretisch kann

46

Usmanov, Kaiser, Kölle

es Fälle geben, bei denen aus der Liste der günstigen Varianten einige hervorgehen, die eine URL-Manipulation im definierten Sinne möglich machen. Durch die Einschränkungen, die ein QR-Code durch seine Struktur bietet, ist dies nur schwer möglich, da sich mit jeder Einschränkung die Menge an Kandidaten erheblich reduziert. Zwar konnten bei der Durchführung einige Varianten gefunden werden, die durch Veränderung des Nutzdatenbereichs und der Anpassung des Redundanzpolynoms valide in sich korrigierbare Varianten bilden. Diese bilden jedoch keine URL ab und verletzen einige Randbedingungen der Spezifikation.

5

Resultate dieser Arbeit

Bei der Implementierung des beschriebenen Algorithmus wurde zunächst eine automatische Code-Korrektur erstellt. Damit konnten die generierten Ergebnisse theoretisch überprüft werden. So wurde die hier gezeigte Manipulation nach der Überlagerung mit dem originalen QR-Code automatisch korrigiert, um das Ergebnis vor der praktischen Anwendung zu verifizieren. Davon ausgehend wurde das Differenzmuster in den originalen QR-Code eingezeichnet. Im Anschluss wurde der veränderte QR-Code mit einigen gängigen Lesegeräten ausgelesen. In Tabelle 1 sind die Ergebnisse aufgelistet. Wie ihr entnommen werden kann, wird der veränderte QR-Code von einigen Lesegeräten erkannt und mit einem Ergebnis ausgelesen. Damit ist bereits zu sehen, dass die Manipulation generell möglich ist. Eine Vermutung, weshalb der QR-Code in vielen Lesegeräten nicht interpretiert werden konnte, liegt möglicherweise in der Art und Weise der Überprüfung. So kann beispielsweise im Nachhinein berechnet werden, ob die verwendete Maske tatsächlich die optimale für das darunterliegende Polynom darstellt. Weil durch die Manipulation zwangsläufig die statistische Gleichverteilung beeinflusst wird, liegt die Vermutung nahe, dass QR-Codes, deren Masken nicht mehr das Optimum darstellen, als ungültig interpretiert werden. Des Weiteren kann überprüft werden, ob die veränderten Elemente des Nutzdatenbereichs dem definierten Encoding entsprechen und im Fehlerfall komplett die Dekodierung verweigert wird.

Deterministische Manipulation Quick-Response-Codes

Reader QRDroid NeoReader AT&T Code Scanner MobileTag SCAN Barcode Scanner

47

Result Kein Ergebnis, QR-Code wurde nicht gelesen. Dieses Ergebnis konnte mit mehreren ergebenen Varianten verifiziert werden. QR-Code wird erkannt. Hier konnte ein verändertes Ergebnis ausgehend von dem veränderten QR-Code aus der Spezifikation ausgelesen werden. Applikation stürzt ab. Beim Auslesen des manipulierten QR-Codes wurde festgestellt, dass die Applikation ihren Dienst verweigerte. QR-Code wird erkannt. Auch mit diesem QR-CodeLesegerät konnte dasselbe veränderte Ergebnis festgestellt werden, wie in dem NeoReader gefunden wurde. Applikation stürzt ab. Auch diese Applikation stellte Ihren Dienst ein, sobald ein manipulierter QR-Code gescannt wurde. Kein Ergebnis. Hier wurde nach mehrmaligen Versuchen kein Ergebnis gefunden.

Tabelle 1: Resultate nach Scanvorgängen mit einem getesteten manipulierten QR-Code. Hier ist zu sehen, dass es überraschende Ergebnisse beim Einlesen der QR-Codes gegeben hat.

5.1 Schlusswort Die definierte Aufgabe der spezifikationsgetreuen Manipulation eines QRCodes wurde im Verlauf der Arbeit erklärt und sowohl theoretisch, als auch praktisch durchgeführt. Damit konnte gezeigt werden, dass Veränderungen durch Anpassungsschritte von grundsätzlich möglich sind und auch in den Anwendungsszenarien für QR-Codes berücksichtigt werden sollten. Allerdings hat der hier beschriebene Lösungsansatz einige Nachteile. So können zwar damit alle Lösungen bestimmt werden, die durch Veränderung des Nutzdatenbereichs möglich sind. Es werden jedoch nicht alle Manipulationsmöglichkeiten ausgeschöpft. Die beschriebene Manipulation kann über eine Rückwärtskorrektur zu weiteren Ergebnissen führen. Ein weiterer Nachteil ist die relativ große Menge an Varianten, die berechnet werden müssen. Diese Menge an möglichen Kombinationen minimiert sich mit sinkendem Nutzdatenbereich und dem damit verbundenen vergrößerten PaddingBereich. Damit ist klar, dass eine hohe Parallelisierung stattfinden muss, wenn alle Varianten über diese Manipulationsmethode berechnet werden sollen.

48

Usmanov, Kaiser, Kölle

5.2 Verwandte Arbeiten Das innerhalb den letzten Kapiteln beschriebene Themengebiet wurde bisher in kaum einer Publikation inhaltlich behandelt. Eine Arbeit, die sich wenn auch nur oberflächlich mit diesem hier vorgestellten Themengebiet der grundsätzlichen Frage nach Sicherheit innerhalb von QR-Codes beschäftigt, ist das Paper „QR Code Security“ von Peter Kieseberg, Manuel Leithner, Martin Mulazzani, Lindsay Munroe, Sebastian Schrittwieser, Mayank Sinha und Edgar Weippl. In diesem werden Ansätze behandelt, mit denen nicht nur der QR-Code selbst als Angriffsvektor dient, sondern auch die Software, die das Einlesen des Codes durchführt. [6]

Literatur [1]

INTERNATIONAL STANDARD ISO/IEC 18004, First edition 2000-06-15 - Information technology - Automatic identification and data capture techniques - Bar code symbology - QR Code

[2]

Kompendium der Vorlesung - Elektronische Version - Codierung, O. Neiße, Sommersemester 2013, Stand: 15. Mai 2013

[3]

R&D White Paper WHP 031 July 2002, Reed-Solomon error correction C.K.P. Clarke, Research & Development BRITISH BROADCASTING CORPORATION

[4]

Grundkurs Codierung - Verschlüsselung, Kompression, Fehlerbeseitigung 3. Auflage 2006, W. Dankmeier

[5]

The Berlekamp-Massey Algorithm revisited, N. B. Atti, G. M. Diaz–Toca, H. Lombardi, 9 March 2006

[6]

QR Code Security, P. Kieseberg, M. Leithner, M. Mulazzani, L. Munroe, S. Schrittwieser, M. Sinha und E. Weippl, http://www.sba-research.org/wpcontent/uploads/publications /QR_Code_Security.pdf

Penetrationtesting mit Windows Credential Editor Benjamin Nopper Fakultät Informatik Hochschule Furtwangen University Robert-Gerwig-Platz 1 78120 Furtwangen im Schwarzwald [email protected]

Abstract: Unter Verwendung des Windows Credential Editor ist es möglich, NT/LM Hashes einzelner Benutzerkonten sowie die verwendeten TGTs eines Benutzers auszulesen und zu verwenden. Aufgabe war es die einzelnen Angriffe zu untersuchen und deren Funktionsweise zu verstehen. Dabei sollten diese Angriffe auch getestet werden, um deren Funktion an Beispielen darstellen zu können und den Umfang der Möglichkeiten des Windows Credential Editors zu erschließen. Ein Augenmerk sollte darauf gelegt werden unter welchen Umständen die gewünschten Informationen aus dem Memory eines Computers ausgelesen werden können und unter welchen Umständen dies gegebenenfalls nicht möglich ist. Auch der Ablauf des Anmeldeverfahrens unter Windows sollte betrachtet werden, um dessen Risiken darzustellen.

1

Einleitung

Die Sicherheit in Windows Netzwerken, in denen die Authentifizierung mittels NTLM und Kerberos durchgeführt wird, ist stark gefährdet. Da die Sicherheit von Netzwerken und den darin enthaltenen Geräten eine äußerst wichtige Komponente ist, sollte stehts darauf geachtet werden, dass diese auch gewährleistet ist. Dies ist auch der Grund, warum Penetration Tests immer mehr an Bedeutung gewinnen, da mit diesen die Schwachstellen eines Netzwerkes aufgedeckt werden können. Mit den Ergebnissen der durchgeführten Test kann somit die Sicherheit in Netzwerken erhöht werden. In den meisten Netzwerken, die auf Windows basieren, stellt entweder NTLM oder Kerberos das verwendete Authentifizierungsverfahren dar. Beide Authentifizierungsverfahren haben neben ihren Vorteilen aber auch erhebliche Schwachstellen, die zum Verlust der Kontrolle über das Netzwerk führen können. Da zum Thema Pass-the-Hash und Pass-the-Ticket bisweilen noch kaum zusammenhängende Literatur vorhanden ist, in der die möglichen Angriffe dargestellt sind und somit auch Informationen über dieses Thema auf den unterschiedlichsten Wegen zusammengeführt werden musste, besteht in wei-

50

Nopper

ten Teilen noch eine gewisse Unwissenheit über die Existenz und die Auswirkungen dieser Attacken.

2

NTLM/Kerberos

2.1 NTLM Unter dem Begriff NT LAN Manager (im weiteren Verlauf NTLM genannt) versteht man ein Authentifizierungsverfahren, das Microsoft zum Anmelden an lokalen Clients oder in einem Netzwerk zur Verfügung stellt. Hierbei ist zu beachten, dass es sich bei NTLM nicht um ein einzelnes Protokoll handelt, sondern NTLM eine komplette Protokoll-Familie darstellt. [7] Um sich in einem Windows Netzwerk anmelden zu können, das auf der NTLM Authentifizierung basiert, müssen für das Anmelden mit einem bestehenden Benutzerkonto mehrere Schritte durchlaufen werden, um eine erfolgreiche Anwendung zu gewährleisten. So wird für das Anmelden im Netzwerk ein „Benutzername“ und ein „Passwort“ benötigt. Dieses Passwort wird nun von Windows in einen „LMHash“ und einen „NTHash“ umgewandelt, um die Übermittlung des Passworts vermeintlich sicher zu gestalten.

2.2 Kerberos Mit dem Begriff „Kerberos“ wird ein weiteres Authentifizierungsverfahren unter Windows beschrieben. Die offizielle Bezeichnung dieses Verfahren ist „Kerberos Network Authentication Service“ und wird im „RFC4120“ beschrieben.[8] Entwickelt wurde Kerberos vom MIT und verwendet dabei zur Verschlüsselung der Daten das ASN.1 Verfahren.[9] [10] Kerberos ist ein Ticket basiertes Authentifizierungsverfahren, bei dem in mehreren Schritten eine Verbindung eines Clients mit dem Server oder einem gewünschten Dienst aufgebaut wird. Für die Erläuterung des Ablaufes einer kerberosbasierten Authentifizierung sind noch einige Begriffe zu klären: „Key Distribution Center (KDC)“: Fasst den „Authentication Service“ und den „Ticket Granting Service“ zusammen und ist damit für die „Ticket Granting Tickets (TGT)“ und „Service Tickets“ verantwortlich.[11] „Authentication Service“: Der „Authentication Service“ stellt die Authentifizierung sicher und verteilt die „TGT“, um eine erfolgreiche Authentifizierung sicherzustellen.[11]

Penetrationtesting mit Windows Credential Editor

51

„Ticket Granting Service“: Der „Ticket Granting Service“ stellt die „Service Tickets“ zur Verfügung, die für den Zugriff auf Dienste benötigt werden.[11] „TGT“: Zeigt eine erfolgreiche Authentifizierung an. Ein „TGT“ ist mehrere Stunden gültig.[11] „Service Ticket“": Ermöglicht den Zugriff auf Dienste. Ein „Service Ticket“ ist mehrere Stunden gültig und muss nicht für jeden Dienst einzeln angefordert werden.[11]

3

Windows Credential Editor

Mit Hilfe des Windows Credential Editor - entwickelt von der Firma Amplia Security - lassen sich NTLM-Hashes und Kerberos Tickets aus dem Memory einiger Windows basierter Betriebssysteme auslesen. Client Betriebssysteme

Server Betriebssysteme

Windows XP

Windows Server 2003

Windows Vista

Windows Server 2003 R2

Windows 7

Windows Server 2008

Windows 8

Windows Server 2008 R2

Tabelle 1: Unterstützte Betriebssysteme des Windows Credential Editors

Mit Hilfe der erhaltenen Daten können nun Angriffe wie Pass-the-Hash und Pass-the-Ticket durchgeführt werden. Des Weiteren ist die Möglichkeit gegeben, die erhaltenen NTLM-Hashes mit Hilfe von WCE direkt zum Klartextpasswort umzuwandeln. Mit Hilfe der erhaltenen Hashes oder Tickets kann jedes Element des Netzwerks, dessen Loginverfahren mit Hilfe von NTLM Hashes oder Tickets abläuft, übernommen werden. [4]

4

Pass-the-Hash

4.1 Pass-the-Hash Allgemein Für den Pass-the-Hash Angriff sind erster Linie die LSASS.exe und die von ihr verwendete MSV1_0.dll interessant. Mit Hilfe der MSV1_0.dll werden die übergebenen Benutzername, NTHash und LMHash, in der SAM-Datenbank oder dem Memory überprüft. So ge-

52

Nopper

währleistet die MSV1_0.dll die Authentifizierung eines Benutzers, das Erstellen einer Sitzung und fügt die Benutzerdaten zur Sitzung hinzu. Zur Durchführung eines Pass-the-Hash Angriffes muss also, mit Hilfe von Code Injection, die MSV1_0.dll so manipuliert werden, damit nicht die eigentlichen Benutzerdaten übergeben werden, sondern die Benutzerdaten des gewünschten Benutzerkontos. [5] Hierbei rücken vor allem die im struct LSA_DISPATCH_TABLE aufgerufenen Funktionen  "PLSA_ADD_CREDENTIAL." [2]  "PLSA_GET_CREDENTIALS" [2]  "PLSA_DELETE_CREDENTIAL" [2] in den Vordergrund, die durch eigene Funktionen ersetzt werden müssen: 

"MSV1_0.DLL!NlpAddPrimaryCredential(PLUID pluid, BYTE* ptrto Creds, DWORD dwCredsSize);" [2]



"MSV1_0.DLL!NlpDeletePrimaryCredential(PLUIDpluid);" [2]



"MSV1_0.DLL!NlpGetPrimaryCredential(PLUID ptrtoCreds, DWORD whatever);" [2]

pluid,

DWORD*

"ptrtoCreds: typedef struct{ UNICODE_STR ustr_domain; UNICODE_STR ustr_username; BYTE NThash[16]; BYTE LMhash[16]; BYTE Udomain[MAX_DOMAIN_LEN]; BYTE Uuser[MAX_USERNAME_LEN]; } CREDSBLOCK;" [2] Diese Code Injection muss bei der Verwendung von WCE nicht selbst ausgeführt werden, da diese von WCE eigenständig durchgeführt wird. Dies macht das Verwenden von WCE um einiges einfacher und beschleunigt den Vorgang des Pass-the-Hash Angriffs deutlich.

Penetrationtesting mit Windows Credential Editor

53

4.2 Wann und wie lang sind die Hashes im Memory gespeichert Die Dauer, in der die NTLM Hashes im Memory gespeichert sind, hängt ganz davon ab, wie diese dort hinterlassen wurden. Im Verlauf meiner Abschlussarbeit wurden die Hashes auf unterschiedliche Art im Memory hinterlegt und getestet, wie lange sich diese dort befinden. Getestet wurden folgende Situationen:  Mehrere Benutzer gleichzeitig angemeldet.  Run as.  Remote Desktop. Es gibt durchaus noch weitere Situationen, in denen die Hashes im Memory hinterlegt werden, diese wurden jedoch nicht einzeln getestet. Mehrere Benutzer sind am Gerät angemeldet: Hierbei bleiben die entsprechenden Hashes der unterschiedlichen Benutzer so lange im Memory hinterlegt, bis sich alle entsprechenden Benutzer abgemeldet haben oder der Computer heruntergefahren wird. Durch das Abmelden, wird nur der Hash des entsprechenden Nutzers aus dem Memory gelöscht. Run as: Sollte man für ein bestimmtes Programm oder einen Dienst auf dem Gerät keine Rechte besitzen, so ist es möglich, dieses Programm mit den Benutzerdaten eines berechtigten Users zu starten. Auch hierbei werden die Benutzerdaten im Memory gespeichert und verbleiben dort, bis der Computer neu gestartet wird. Remote Desktop: bei Remote Desktop gibt es mehrere Szenarien in denen der Hash auch nach der beendeten Sitzung im Memory gespeichert bleibt. Jedoch ist dies nicht immer der Fall: Fall 1: . Dies stellt nur ein Abbrechen der Schließen von „RDP“ mit dem Verbindung dar und nicht wirklich eine Ausloggen. Hierbei werden die Benutzerdaten im Memory hinterlassen. Fall 2: Trennen der Verbindung: Auch das Verwenden der Funktion „Trennen“ von RDP stellt nur ein Unterbrechen der Verbindung dar und kein richtiges Ausloggen. So können auch bei dieser Funktion im Nachhinein noch Hashes aus dem Memory ausgelesen werden.

54

Nopper

Fall 3: Abmelden: Nur durch das Verwenden der Funktion „Abmelden“ wird die Sitzung so beendet, dass sich keinerlei Daten der Sitzung mehr im Memory befinden. [3]

4.3 Ergebnisse In den nachfolgenden Tabellen sehen Sie einige der Möglichkeiten die durch den Pass-the-Hash Angriff gegeben sind. Aktionen

Möglich Server 2003/

möglich Server 2008 R2/

Windows XP

Windows 7

Benutzer anlegen

Ja

Nur CMD

Rechte ändern

Nein

Ja

Computer anlegen

Ja

Ja

Computer Eingenschaften ändern

Ja

Ja

Operationseinheiten ändern

Ja

Ja

Dienste manipulieren

Ja

Ja

Tabelle 2: Auswirkungen auf Domain Controller

Aktion

Fileserver sitzt in gleicher Domäne

Filserver sitzt in übergeordneter Domäne

Dokumente betrachten

Ja

Ja

Dokumente ändern

Ja

Ja

Dokumente löschen

Ja

Ja

Dokumente verschieben

Ja

Ja

Ordner erstellen

Ja

Ja

Ordner löschen

Ja

Ja

Ordner umbenennen

Ja

Ja

Ordner verschieben

Ja

Ja

Tabelle 3: Auswirkungen auf Fileserver

Penetrationtesting mit Windows Credential Editor

55

Aktionen

Microsoft Exchange Server 2007 SP3, Outlook 2003

E-Mails lesen

Ja

E-Mails schreiben

Ja

E-Mails löschen

Ja

Kalender bearbeiten

Ja

(erstellen, löschen, bearbeiten) Tabelle 4: Auswirkungen auf Exchange Server

5

Pass-the-Ticket

Durch eine Funktion im Windows Credential Editor ist es möglich, aus einer Windows Maschine das Ticket Granting Ticket eines Benutzers auszulesen und dieses in eine andere Windows Maschine einzulesen. Durch diese Funktion wird die Sicherheit in einem Kerberos basierten Netzwerk ausgehebelt, da die Authentifizierung bereits vor dem Erhalt eines TGTs stattfindet. Da die Verschlüsselung eines Kerberos Tickets auf dem KRBTGT Hash basiert und dieser de facto dem NTHash eines Benutzers entspricht, ist es auch möglich, das Ticket zu entschlüsseln und die darin enthaltenen Informationen zu verwenden. Von Duckwall und Campell wurde auf der Black Hat Konferenz im Jahr 2012 ein theoretisches Szenario präsentiert, wie mit Hilfe vom Windows Credential Editor das Kerberos Authentifizierungsverfahren umgangen werden kann: "Schritt 1: Request eines TGT beim KDC 1. TGT mit Hilfe des KRBTGT Hash entschlüsseln: 1.1 Username und Domäne 1.2 Clientname 1.3 Gültigkeitszeitraum des Tickets 1.4 session key 1.5 PAC" [1] 2. "session key (entschlüsselt mit dem NT Hash des Benutzers)" [1] "Mit diesen Informationen kann nun ein neues TGT ohne das KDC generiert werden." [1]

56

Nopper

"Schritt2: Generieren des Service Tickets für den gewünschten Server 1. Sektion des Benutzers 1.1 session key zwischen User und dem gewünschten Server 1.1 generiertes TGT 2. Sektion des gewünschten Servers 2.2 session key zwischen User und dem gewünschten Server 2.2 Username und Domäne 2.2 Timestamp 2.2 User PAC mit dem Schlüssel für den Domain Controller, PAC mit dem Schlüssel zum gewünschten Server." [1] "Schritt 3: Request des Service Tickets für den gewünschten Server." [1] Dies ist allerdings ein theoretischer Aufbau dieses Angriffs, der nach Aussage von Duckwall und Campell noch nicht implementiert und getestet wurde. [1] Auf Nachfrage bei Hernan Ochoa, dem Entwickler des Windows Credential Editor ist wohl auch die direkte Verwendung des ergatterten TGTs möglich und eine Entschlüsselung somit hinfällig.

5.1 Tests Pass-the-Ticket Mit Hilfe von WCE lassen sich Kerberos Tickets aus Windows Maschinen auslesen. Allerdings fiel auf, dass es sich bei den ausgelesenen Tickets in der Testumgebung immer nur um das TGT des lokalen Benutzers handelte. Dies änderte sich auch nicht, wenn mehrere Benutzer gleichzeitig angemeldet waren. Auch wenn mit Hilfe von Remote Desktop eine Verbindung erstellt wurde konnte nur das TGT des lokalen Benutzers ausgelesen werden. Nachdem die Tickets ausgelesen wurden sollte es, möglich sein, diese in eine andere Windows Maschine einzubinden. Diese andere Maschine muss sich dazu im selben IP-Adressbereich wie der Domain Controller befinden, es wird aber mit dem lokalen Benutzerkonto gearbeitet. Dies war allerdings nicht möglich. Da allerdings die Hashes zur Verschlüsselung der TGTs der anderen Benutzer mit ausgelesen werden, ist es nun wieder möglich, den Pass-the-Hash Angriff mit diesen Informationen zu starten. So ist es also auch durch das auslesen der Kerberos Tickets möglich, den Pass-the-Hash Angriff durchzuführen

Penetrationtesting mit Windows Credential Editor

57

6 Gegenmaßnahmen Effektive Gegenmaßnahmen sowohl zu Pass-the-Hash als auch zu Pass-the-Ticket existieren nicht. Es gibt die Möglichkeit die Auswirkungen solcher Attacken zu minimieren. Diese sind allerdings teilweise sehr schwer im alltäglichen Gebrauch umzusetzen, da sie den Verwaltungsaufwand eines Netzwerkes deutlich erhöhen und somit keinen wirklichen wirtschaftlichen Nutzen haben. Hierzu wurde von Microsoft ein Guide zur Verfügung gestellt, in dem einzelne Möglichkeiten aufgezeigt werden. [6] Einzig die Auswirkungen auf die Dateien, die auf einem Fileserver gespeichert sind, können effektiv gemindert werden, indem man sensible Informationen mit Hilfe eines gesonderten Kryptographie Tools gesondert verschlüsselt.

7

Zusammenfassung

Das Zusammenspiel der Authentifizierungsverfahren NTLM und Kerberos mit dem Windows Single Sign-On bietet neben den Vorteilen für den Benutzer auch erhebliche Schwachstellen, die mit Hilfe des Pass-the-Hash und Pass-the-Ticket Angriffs ausgenutzt werden können. Es lassen sich mit einfachen Mitteln wichtige Elemente des Netzwerkes unter Kontrolle bringen, deren Funktionalität an erster Stelle stehen sollten. Gegenmaßnahmen, mit denen solche Angriffe verhindert werden können, gibt es praktisch nicht, die einzige Möglichkeit, die einem Administrator gegeben werden, bestehen hauptsächlich darin, die Auswirkungen so gering wie möglich zu halten und die Durchführung eines Angriffes etwas zu erschweren. Hier besteht dringender Handlungsbedarf von Seiten Microsofts und den Entwicklern der einzelnen Authentifizierungsverfahren.

58

Nopper

Literatur [1] C. Duckwall: Still passing the Hash. S.7-S.9 URL:http://media.blackhat.com/bh-us12/Briefings/Duckwall/BH_US_12_Duckwall_Campbell_Still_Passing_WP.pdf [2]

Ochoa: WCE INternals. URL:http://www.ampliasecurity.com/research/WCE_Internals_RootedCon2011ampliase curity.pdf

[3]

Ochoa: Post-Exploitation with WCE URL: http://www.ampliasecurity.com/research/wce12_uba_ampliasecurity_eng.pdf

[4]

AmpliaSecurity: WCE FAQ URL: http://www.ampliasecurity.com/research/wcefaq.html#supportedoses

[5]

Microsoft: Authentication Packages URL:http://msdn.microsoft.com/enus/library/windows/desktop/aa374733%28v=vs.85%29.aspx

[6]

Microsoft: Defending against Pass-the-Hash attacks URL:http://msdn.microsoft.com/enus/library/windows/desktop/aa374733%28v=vs.85%29.aspx

[7]

Microsoft: NTLM Introduction URL: http://msdn.microsoft.com/en-us/library/cc236622.aspx

[8]

Microsoft: MS-KILE Introduction URL: http://msdn.microsoft.com/en-us/library/cc233856.aspx

[9]

MIT: Kerberos: The Network Authentication Protocol URL: http://web.mit.edu/~kerberos/

[10] C. Neuman ; T. Yu ; S. Hartman ; K. Raeburn: RFC4120 URL: http://www.ietf.org/rfc/rfc4120.txt [11] M. Kuppinger: Die Funktionsweise von Kerberos. In: tecchannel (2007) URL: http://www.tecchannel.de/server/windows/461645/ die_funktionsweise_von_kerberos

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures Dirk Hölscher Fakultät Informatik Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen [email protected] Abstract: Durch die sich ständig verändernde Struktur eines Netzes im Cloud Computing wird das manuelle Monitoring erschwert. In diesem Paper wird eine Architektur vorgestellt, die autonom das Monitoring in Cloud Infrastrukturen unter Einsatz eines IDS übernehmen kann. Die Schichten und Komponenten der Architektur werden in diesem Paper beschrieben. Die Architektur ermöglicht es, die Eigendynamik der Cloud zu kontrollieren und dadurch gezieltes Monitoring zu ermöglichen. Dies wird realisiert unter dem Einsatz von Agenten, die die Generierung und Konfiguration eines IDS und dessen dazugehörigen Agenten übernehmen, sowie die autonome Auslieferung an dessen Zielort. Der Benutzer hat nur Kontakt mit dem IDS bei der Erstellung einer Virtuellen Maschine durch Festlegen der Policy und Zeitintervallen und bei der Meldung eines IDS ausgelöst durch verdächtige Aktivitäten. Um die Möglichkeiten der Architektur aufzuzeigen, wird ein exemplarischer Use- Case vorgestellt.

1 Einführung Die Überwachung von stetig wachsenden Netzwerken erfordert viel Ressourcen und Zeit. Durch die von Cloud Computing eingeführte Dynamik in Rechnernetzen wird die Überwachung zusätzlich noch erschwert. Für eine zuverlässige Überwachung großer Infrastrukturen benötigt es viel geschultes Personal. Da moderne IT-Systeme zu jeder Zeit einer viel Zahl von Gefahren ausgesetzt sind, die von automatisierten Attacken über gezielte Attacken auf das System [2] variieren können, ist ein erster Schritt zu Gegenmaßnahmen Ergreifung der Einsatz eines Intrusion Detection Systems (IDS) [3]. Aufgrund der von der NIST [1] beschriebenen Service und Deployment Models wird der Einsatz eines IDS erschwert, da 1) neue Virtuelle Maschinen in nicht vorhersehbaren Abständen hinzukommen und 2) Virtuelle Maschinen ohne Ankündigung jederzeit wieder entfernt werden können. Zusätzlich dazu, müssen die Folgenden durch NIST [1] beschriebenen Modelle ebenso beachtet werden.

60

Hölscher

1.1 Infrastructure as a Service (IaaS) Dem Nutzer werden unterschiedliche Ressourcen (z.B. CPU, Speicher) zur Verfügung gestellt, auf denen er nach Belieben Software und Applikationen installieren kann. Die Wahl des oder der Betriebssysteme steht dabei dem Benutzer offen und er besitzt die volle Kontrolle über die Systeme und Ressourcen, bis zur Cloud Infrastruktur, auf die er keinerlei Einflussnahme mehr hat. Zusätzlich zu IaaS gibt es noch zwei weitere Service Models. Platform as a Service (PaaS) räumt dem Nutzer, die Möglichkeit ein, erstellte oder erworbene Applikationen in der Cloud zu deployen. Während Software as a Service (SaaS) Software in der Cloud zur Verfügung stellt, die der Benutzer nutzen kann, ohne großen administrativen Aufwand zu haben. Das Service Modell hat großen Einfluss darauf, welche kontextbezogenen Daten dem IDS hinzugefügt werden. So ist es z.B. notwendig, dem IDS bei Nutzung von IaaS mehr kontextbezogene Daten zur Verfügung zu stellen, da die Unterschiede zu PaaS vermeintlich größer sein werden. Die Position an dem ein IDS sitzt wird maßgeblich durch das gewählte Deployment Modell [1] beeinflusst.

1.2 Public Cloud Die zur Verfügung gestellte Cloud Infrastruktur wird der Öffentlichkeit zur freien Nutzung zur Verfügung gestellt. Bei einer Public Cloud die auf Multitenancy ausgelegt ist, sollte die Position des IDS auch dem entsprechend gewählt werden, denn ein Angriff auf eine dem Nutzer unbekannte Virtuelle Maschine, muss keinerlei Auswirkungen auf die von ihm genutzte Maschine haben.

1.3 Private Cloud Die Cloud Infrastruktur steht einer Organisation bestehend aus mehreren Teilnehmern exklusiv zur Verfügung. Das Cloud Management wird dabei von einer teilnehmenden Organisation oder einem dritten vertraglichen Partner übernommen. Zusätzlich dazu ist es möglich die beiden oder andere Modelle zu einem Modell zusammenzufassen. Bei einer Hybrid Cloud werden mindestens zwei Deployment Modelle in einer Infrastruktur zusammengefasst. Die einzelnen Modelle bleiben dabei unabhängige Einheiten. Bei einer Hybrid Cloud die sich aus Public und Private Cloud zusammensetzt, ist die IDS Position wie oben genannt entweder die für die Private oder die für Public Cloud.

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures

61

1.4 Intrusion Detection System(IDS) Ziel des IDS ist es, dem Administrator, bzw. dem Nutzer einer Virtuellen Maschine über mögliche Angriffe zu informieren. Ein IDS kann zur Erkennung von Bedrohungen verschiedene verfahren verwenden, die in [4] durch das NIST definiert wurden. Signature-Based Detection Die Signatur ist ein auftretendes Muster, das einer bekannten Bedrohung zugewiesen werden kann. Diese Muster werden in einer Muster Datenbank gespeichert und mit auftretenden Mustern verglichen. Das Arbeiten mit Signaturen ist dabei, die einfachste Methode um Bedrohungen zu erkennen. Da nur bekannte Muster erkannt werden können, kann ein IDS mit Mustererkennung keine neu auftauchenden Bedrohungen erkennen, da die Muster zum Abgleichen fehlen. Anomaly-Based Detection Die Anomalien Erkennung beschreibt den Prozess, bei dem Definition miteinander verglichen werden, die als normaler Vorgang im System definiert wurden und auftretenden Events um Abweichungen der Norm zu finden. Normales Verhalten wird durch Profile repräsentiert, diese werden durch das Überwachen der Aktivitäten erstellt (z.B. Bandbreitenauslastung durch Surfen im Web während der Arbeitszeit). Die im IDS verwendeten Kontextinformationen beinhalten unter anderem Informationen über das Betriebssystem (welches Betriebssystem, Version), die sich auf dem System befindliche Software ihrer Version sowie ihr aktuelles Patchlevel. Software-defined-networks wären eine weitere Möglichkeit, Kontextdaten zu bekommen, darauf wird in diesem Paper aber nicht genauer drauf eingegangen. Um den Konfigurationsaufwand zu senken und den Benutzer dennoch die Möglichkeit bieten zu können individuell angepasste IDS zu nutzen, muss der Prozess automatisiert werden. Der Benutzer/ die Benutzergruppe Virtueller Maschinen muss nur zu Anfang (z.B. Erstellung einer Virtuellen Maschine) die benötigten Daten zu Verfügung stellen (siehe Kapitel III.). Die Verarbeitung und Bereitstellung soll das System ohne zusätzliche menschliche Einwirkung erledigen können. Erst bei der Auswertung eines Alarms des IDS muss erst wieder ein Mensch tätig werden, sofern das System keine Self- healing Eigenschaften besitzt. Im Kontext des Papers bezieht sich Selfhealing auf die Eigenschaft des Systems Meldungen des IDS selbstständig zu prüfen und nach abgeschlossener Analyse die Richtigen Maßnahmen zu treffen, um das System ohne menschliche Interaktion vor der auftretenden Gefahr zu schützen. Das Paper unterteilt sich nachfolgend in 5 Kapitel. Kapitel II. Gibt einen Überblick über Related Work. Kapitel III. stellt einen Use Case vor, in dem die Architektur eingesetzt werden kann. Kapitel IV. stellt den Architekturent-

62

Hölscher

wurf und die darin enthaltenen Komponenten vor. Kapitel V. beinhaltet einen Ausblick sowie das Fazit. Unter Kapitel VI. finden sich Acknowledgments.

2 Related Work In dieser Sektion wird auf Verwandte Arbeiten eingegangen. Das Kapitel ist in 3 Abschnitte aufgeteilt, die jeweils ein Thema behandelt. In [5] stellen die Autoren, einen hierarchisch autonom arbeitenden IDS für die Cloud vor. Dabei überwacht und analysiert das gebaute Framework ständig die eintreffenden Systemevents. Mithilfe der Analyse können Sicherheits- und Risikoparameter der einzelnen Events berechnet werden. Unter dem Einsatz eines autonomen Controllers zu dem, die Sicherheitsparameter übergeben werden, wird eine angemessene Reaktion gesucht, die die Cloud gegen gefundene Angriffe schützt. Des Weiteren soll die ausgelöste Reaktion korrumpierte Daten oder betroffene Services wiederherstellen. Neben der Möglichkeit automatisch Angriffe zu erkennen, bietet das vorgestellte Framework HA-CIDS andere autonome Fähigkeiten wie z.B. self-resilience und Fehlertoleranz. Um die Möglichkeiten des Frameworks zu testen wurde für die Evaluation ein Testbed erstellt um die Performance und Genauigkeit zu testen. In [6] wird auf die Übertragung eines IDS in die Cloud eingegangen und die damit verbunden Herausforderungen. Zum einen stellt sich die Problematik, dass der Nutzer selbst verantwortlich für den IDS ist und nicht der Administrator der Cloud Infrastruktur. Zum anderen müssen Erweiterbarkeit, effizientes Management und die Kompatibilität von IDS auf Virtuelle basierenden Kontext geprüft werden. Außerdem wird darauf hingewiesen, dass Service Provider eine Plattform benötigen, auf der Sie ihren Kunden das Konfigurieren eines IDS ermöglichen. In der Arbeit wird zusätzlich auf die Bedingungen eingegangen, die ein IDS aufbringen muss damit er in der Cloud funktioniert wie z.B. die unter I. Beschriebenen Deployment Models oder Cloud spezifische Sicherheitsaspekte. In [2] wird gezeigt, wie mit Hilfe von angemessenen kontextbezogener Daten, Benachrichtigungen eines Netzwerk basierten IDS, die als false positive eingestuft werden zu reduzieren. Dazu wurde eine konzeptuelle Architektur mitsamt Prototyp basierend auf Snort entwickelt. Ein Teil der Architektur, ist dabei zuständig für das Sammeln der Events die von Snort gefunden wurden. Ein weiterer Teil ermöglicht den Abgleich mit einer Vulnerability Datenbank. Der dritte Teil ist für das sammeln von Daten (Kontext) verantwortlich. Für große Infrastrukturen wird zur Kontext Beschaffung auf eine Configuration Management Database (CMDB) zurückgegriffen, in der alle Host bezogenen Daten liegen, die der IDS zum Differenzieren benötigt.

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures

63

3 Use Case Im folgenden Kapitel wird ein identifizierter Use Case beschrieben. Der Use Case ist in zwei Szenarien unterteilt. In Szenario A) wird ein Szenario gezeigt wie es z.B. in einer Private Cloud vorkommen kann, während Szenario B) ein mögliches Szenario einer Public Cloud zeigt.

3.1 Szenario 1 Der IDS sitzt dabei direkt am Node zum privaten Netzwerk der Cloud. In Abbildung 1 wird der Aufbau des Szenarios gezeigt. Der eingezeichnete Weg der Policies dient der Verdeutlichung, denn wie in Kapitel drei bereits erwähnt befinden sich die Policies zu diesem Zeitpunkt des Fortschritts bereits im IDS. Zusätzlich holt sich der Agent, der dafür verantwortlich ist, dass der IDS seinen Zielort erreicht (Execution Agent) die nötigen Kontext Informationen aller Virtueller Maschinen, die sich am Node befinden. In diesem Use Case werden vier Virtuelle Maschinen gezeigt die Kontextbezogene Daten liefern. Wichtig in diesem Fall sind Betriebssystem spezifische Kontextdaten. Die angenommen Daten werden in den IDS eingepflegt, damit dieser zwischen den im Einsatz befindlichen Virtuellen Maschinen differenzieren kann. Die Wolke steht symbolisch für das World Wide Web aus denen die Angreifer ihre Angriffe starten. Sobald die Daten eingepflegt wurden, startet der IDS damit, den Netzwerkverkehr zu analysieren, entweder durch die bereits vorgestellte Mustererkennung/Anomalienerkennung oder durch eine Kombination von beiden Vorgehensweisen.

Abbildung 1: Use Case Private Cloud Szenario

Durch den hinzugefügten Kontext wird erreicht, dass false positve Meldungen gemindert werden. Mit Bezug auf den hier gezeigten Use Case bedeutet das, sobald ein gezielter auf eine Windows spezifische Schwachstelle stattfindet, erkennt der IDS dies und meldet einen Alarm. Da die Linux Maschinen genauso wie die angegriffene Windows Maschine zum selben Netz ge-

64

Hölscher

hören, würde der IDS auch für die Linux Maschinen einen versuchten Angriff melden, obwohl die Ausnutzung der Schwachstelle unter Linux nicht existiert. Da der IDS aber über den nötigen Kontext verfügt, um differenzieren zu können, bringt er keine false postive alerts für Linux Maschinen.

3.2 Szenario 2 In diesem Szenario wie in Abbildung 2 gezeigt wird, sitzt der IDS nicht auf dem Node sondern ist jeder einzelnen Virtuellen Maschine vorgelagert. Dies entspricht einer Vorgehensweise wie sie beispielsweise in IaaS Public Cloud Infrastrukturen eingesetzt werden könnte. Diese vorgehen hat sowohl Vorteile als auch Nachteile. Ein Einsatz in dieser Form macht nur Sinn, wenn die Benutzer der Virtuellen Maschine selbst die alerts bekommen und nicht der Administrator der Infrastruktur.

Abbildung 2: Use Case Public Cloud Szenario

Der Vorteil besteht darin, dass voneinander unabhängige Kunden nicht durch false positive alerts beunruhigt werden, da nicht ihr System, sondern ein anderes angegriffen wird. Ein großes Problem liegt beim produzierten Overhead. Durch den Einsatz eines IDS pro Virtueller Maschine wird der Overhead gerade in großen Infrastrukturen riesig. Deshalb sollte genau geprüft werden wie sich der Overhead im jeweiligen System entwickelt und verhält. Möglich wäre eine Einführung einer Mindestanzahl an Virtuellen Maschinen bevor ein IDS eingesetzt werden darf. Das Prinzip wäre ähnlich dem Load Balancing von Amazon, wobei in diesem Fall, Nutzer ihre Virtuellen Maschinen hinter einem IDS zusammenfassen und sich dennoch weiterhin in einer Public Cloud befinden.

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures

65

4 Autonome Archtiektur für IDS / IPS Im nachfolgenden Kapitel wird die entwickelte Architektur zu sehen in Abbildung 3 vorgestellt. Dabei handelt es sich um eine 4-Schichten-Architektur. Die einzelnen Schichten samt ihrer Komponenten werden Einzelt beschrieben. Das Einfließen der Kontextdaten für den IDS erfolgt dabei, wie unter [2] beschrieben.

4.1 Configuration Layer Das Configuration Layer nimmt die Registrierungen der einzelnen Virtuellen Maschinen oder einer Gruppe entgegen. Die dabei übermittelten Werte werden geprüft und dann in der jeweiligen Datenbank gespeichert. Das Configuration Layer beherbergt, dass Registration Portal. Registration Portal: Alle Virtuelle Maschinen alleine oder im Verbund melden sich, nachdem sie erstellt wurden automatisch am Registrierungs Portal an. Die dabei mitgebrachten Daten werden in Policy, IDS/IPS, Time Intervals und VM-Register unterteilt. Sollten Änderungen an den Virtuellen Maschinen auftreten, sorgt der Conf Agent dafür, dass diese dem System mitgeteilt werden. Sobald eine Virtuelle Maschine gelöscht wird, teilt sie dies dem Registration Portal mit, damit die nötigen Schritte eingeleitet werden können, um die Einträge der jeweiligen Virtuellen Maschine aus dem System zu entfernen. Dieser Schritt soll die Übersicht bewahren und Fehler im System vermeiden. VM-Register: Im VM-Register befinden sich die Daten über die jeweilige Virtuelle Maschine. Diese Daten beinhalten zum einen die IP-Adresse der Maschine ihren Namen und gegebenenfalls die Zugehörigkeit zu einem Verbund aus Virtuellen Maschinen. Time Intervals: Da die Abrechnung im Cloud Bereich oftmals nur die effektive Nutzung eines Services berechnet (z.B. Abrechnung nach Nutzung in Stunden) wird ein Zeitintervall übertragen indem spezifiziert wurde, wie lange der IDS Agent das System überwachen soll. Für durchgehende Überwachung wird ein Wert von 0 übermittelt. IDS/IPS: Wenn gewollt ist es möglich mehr als einen IDS anzubieten. Diesen kann der Benutzer selbstständig wählen. Damit das System später weiß, welchen IDS es konfigurieren muss, überträgt die Virtuelle Maschinen die Wahl des IDS zum System. Policies: Gerade im Unternehmensbereich unterscheiden sich die Regelwerke der einzelnen Firmen stark. Um einen Dienst für ein Unternehmen dennoch interessant zu machen, ist es wichtig, dass diese ihre Policies anwenden

66

Hölscher

können. Da die Policies mit in den IDS fließen müssen diese ebenfalls Übertragen werden. Für unerfahrene Benutzer die den Dienst dennoch in Anspruch nehmen wollen gibt es zuvor definierte Policies die diese Auswählen können. Conf Agent: Die Aufgabe des Agenten ist es, Änderungen an den Virtuellen Maschinen anzufragen. Da sich Policies eher selten ändern kann der Agent z.B einmal im Monat anfragen, ob sich Änderungen ergeben haben. Grundsätzlich ist die Zeitspanne in dem der Agent zum Einsatz kommt abhängig von der jeweiligen Infrastruktur. Außerdem sammelt der Agent Kontextinformationen der einzelnen Virtuellen Maschinen (z.B. Betriebssystem, Softwareversionen, etc.). Die gesammelten Kontexte werden dann in die CMDB geschrieben. Alle Daten, die der Agent sammelt oder über das Registration Portal bekommt, werden von ihm in die Datenbank geschrieben.

4.2 Information Layer Im Information Layer befinden sich alle gesammelten Informationen des Systems. Alle Daten die Virtuelle Maschinen bei ihrer Registrierung übergeben werden in den jeweils dafür vorgesehenen Datenbanken gespeichert. Für alle Anfragen nach Daten, die sich in dieser Schicht befinden wird, der Search Agent aufgerufen.

Abbildung 3: Autonome IDS Architektur

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures

67

Knowledge Base (KB): In der KB befinden sich zusätzliche Muster, mit denen ein IDS erweitert werden kann. Da unbekannte Muster nicht erkannt werden, können neue Muster die sich nicht im IDS befinden, mithilfe der KB hinzugefügt werden. Zusätzlich ist KB wichtig für spätere Erweiterungen und Änderungen an der Architektur, wie sie in Kapitel V. Ausblick beschrieben werden. Policy DB: In dieser Datenbank werden alle bereits vordefinierten Policies sowie alle Policies gespeichert, die von Benutzern kommen. Zugriff auf die Datenbank erfolgt, durch den Search Agent der während des Konfigurationsprozesses für den IDS aufgerufen wird. VM-Register DB: In dieser Datenbank werden die Information der Virtuellen Maschinen gespeichert. Darin steht z. B., welchen Namen die Maschine besitzt, welche IP-Adresse, die Zugehörigkeit zu einem Netzverbund und die Policy. Diese Daten werden zum Versenden des IDS benötigt. IDS/IDP DB: In dieser Datenbank befinden sich die Speicherorte der nicht konfigurierten IDS sowie derer die bereits für einen Nutzer konfiguriert wurden. Dies soll die Einsatz Zeit verbessern, da nicht jedes Mal ein neuer IDS konfiguriert werden muss. CMDB: In dieser Datenbank werden alle benötigten Kontextinformationen der einzelnen Virtuellen Maschinen gespeichert. Der Generator besorgt sich diese Daten bei der IDS Generierung um diesen mit Kontext anreichern zu können. Search Agent: Der Search Agent wird aufgerufen um die benötigten Daten, in den Datenbanken zu suchen. Die Anfrage erfolgt vom Generator. Der Search Agent stellt die Verbindung zwischen den einzelnen Datenbanken her, um die jeweils richtigen Daten für die Benutzer zu finden. Die gefunden Daten werden dem Generator übergeben.

4.3 Agent Layer Diese Schicht kümmert sich um die Informationsbesorgung aus den Datenbanken und Konfiguriert den IDS nach Vorgaben der Policy. Außerdem ist die Schicht zuständig für das packen und das Versenden des IDS als Agent. Generator: Der Generator ist für die IDS Konfiguration und Agenten Generierung verantwortlich. Beides wird in unterschritten der Komponente übernommen. Den fertigen Agenten übergibt der Generator dann an den Execution Agent . IDS/IDP Configurator: Im IDS Configurator wird der vom Benutzer gewählte IDS konfiguriert. Dabei wird auf die Policy Datenbank zugegriffen. Dort wird in Verbindung mit der VM-Register DB die zugehörige Policy

68

Hölscher

gesucht. Aus der Knowledge Base können zusätzliche Muster abgerufen werden, die mit in die Konfiguration fließen. Sobald der IDS durch konfiguriert wurde, wird er wie auch die nicht konfigurierten IDS gespeichert und es wird ein Eintrag in der IDS/IPS Datenbank hinzugefügt. Dies soll gewährleisten, dass der IDS schnell wieder gefunden werden kann sollten sich Änderungen an den Policies ergeben oder dieser wieder zu einer Virtuellen Maschine geschickt werden soll. Ebenso fällt dadurch ständige neu konfiguration eines bereits benutzen IDS weg Agent Generator: Der Agent Generator, nimmt den Konfigurierten bzw. einen bereits vor konfigurierten IDS aus der Datenbank entgegen und legt ein Gerüst um den IDS. Mithilfe der VM-Register Datenbank kann der Zielort der Agenten bestimmt werden. Das Agentengerüst, dass um den IDS gelegt wird kann immer gleich sein, da es grundsätzlich immer die gleiche Aufgabe hat. Sobald der Agent erstellt wurde, übergibt der Generator den Agenten an den Execution Agent. Execution Agent: Dieser Agent ist für die Auslieferungen des IDS Agenten zuständig er bekommt die den Agenten vom Generator zugewiesen. Der Generator teilt ihm zusätzlich den Zielort mit. Sind alle Daten komplett, liefert der Execution Agent das Paket aus.

4.4 Processing Layer Diese Schicht nimmt die Alerts der IDS entgegen. Entweder gehen alle alerts zu dieser Schicht und werden dann weitergeleitet oder die Schicht ist unterstützend zur Statistik Erstellung. Notification Agent: Dieser Agent dient dazu die vom IDS produzierten Alerts an die jeweilige richtige Stelle auszuliefern. Je nach gewünschter Prozedur besteht die Möglichkeit, dass der Agent einen Alert entgegennimmt, und dann eine entsprechende Notifaction sendet. Zum anderen können Alerts normal vom IDS gesendet werden. Die Alerts werden dann zusätzlich an den Agenten gesendet. Summarizer: Der Summarizer erstellt Statistiken zu den gemeldet Alerts des IDS. Dies soll zur Erfassung dienen, wie oft angegriffen wird oder gefährliche Muster erkannt werden. Dadurch soll die Entdeckung von weiterhin aufkommenden false postives erleichtert werden. Notifier: Der Notifier nimmt die Meldungen entgegen und bereitet diese auf. Dadurch soll das Ergebnis klarer werden, was den Alert ausgelöst hat.

An Architectural Approach For Autonomous Agents To Monitor Huge Infrastructures

69

5 Ausblick/Fazit In diesem Paper wurde ein Ansatz einer autonomen Architektur vorgestellt, die die Möglichkeit bietet in großen und sich stetig verändernden Umgebungen unter Einsatz eines IDS zu Monitoren. Dabei wurde ein möglichst autonomer Ansatz gewählt, um gewährleisten zu können, dass neu erstellte Virtuelle Maschinen sofort überwacht werden können. Mit der Hinzunahme kontextbezogener Daten aus den Virtuellen Maschinen kann wie unter [2] beschrieben erreicht werden, dass false positive und false negative Meldungen minimiert werden. Des Weiteren kann erreicht werden, dass nicht relevante Meldungen nicht gesendet werden, z. B. falls Windows spezifische Sicherheitslücken angegriffen werden, die unter Linux nicht zutreffend sind, unter normalen Bedingungen dennoch Meldungen auslösen würden. Die enthaltenen Komponenten der Architektur wurden ihrer Aufgabe entsprechend beschrieben. Der Einsatz der Architektur wurde anhand eines UseCase beschrieben, um die Einsatzmöglichkeiten der Architektur zu verdeutlichen. Die bekannten Schwächen des in Szenario B vorgestellten UseCase wurden aufgezeigt. Im vorderen Teil des Papers wurden relevante Grundlagen vorgestellt und Definitionen sofern erforderlich eingeführt. In nachfolgenden Arbeiten soll die Architektur verfeinert werden. Die bestehende Autonomie soll weiter ausgebaut werden um Self-healing und Autonomes reagieren zu ermöglichen. Dazu wird es zum einem notwendig sein, die Knowledge Base zu erweitern bzw. zu verändern. Das System benötigt zu allen bekannten Mustern oder auftretenden Anomalien Gegenmaßnahmen, sofern diese bekannt sind. Für unbekannte Ereignisse muss die Architektur lernfähig gemacht werden um neue Muster und die damit verbundenen Gegenmaßnahmen eigenständig lernen zu können Eine weitere Ausbaustufe wäre Accounting und Billing. So könnten Kunden aus Unternehmen zusätzliche Features geboten werden z. B. kostenpflichtige IDS oder mehr Konfigurationsmöglichkeiten. Das im Cloud Computing weitverbreitete Pay-per-Use könnte auf den IDS übertragen werden. Um aussagekräftige Resultate zur Performance und der Ergebnisse zu erhalten, muss das hier vorgestellte theoretische Konzept der Architektur praktisch umgesetzt und evaluiert werden.

70

Hölscher

6 Acknowledgments Diese Arbeit wurde durch Prof. Dr. Christoph Reich, M.Sc. Thomas Rübsamen der Hochschule Furtwangen, sowie dem Cloud Accountability Project (A4Cloud) geleitet von den HP Labs ermöglicht. Die in dieser Arbeit getroffenen Aussagen unterliegen vollkommen der Verantwortung des Autors.

Literatur [1]

P. Mell, T. Grance, “The NIST Definition of Cloud http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

Computing”,

[2]

L. Pimenidis, B. Westermann, V. Wetzelaer, “A Context Aware Network-IDS”

[3]

J.P. Anderson, Computer Security Threat Monitoring and Surveillance. Technical report, Fort Washington, Pennsylvania, USA, April 1980.

[4]

K. Scarfone, P. Mell, “ Guide to Intrusion Detection and Prevention Systems (IDPS)”, http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf

[5]

H. Kholidy, A. Erradi, S. Abdelwahed, F. Bairadi, , “HA-CIDS A Hierarchical and Autonomous IDS for Cloud Systems”

[6]

S. Roschke, F. Cheng, C. Meinel, “Intrusion Detection in the Cloud”, 8th Int. Conference on Dependable, Autonomic and Secure Computing (DASC-09) Chengdu, China, Dec. 12-14, 2009

JADE-OSGi im Bereich des Ambient Assisted Living Stefan Eggert, Artur Fertich Fakultät Informatik Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen [email protected], [email protected] Abstract: Systeme im Bereich des Ambient Assisted Living werden oft mit den Technologien OSGi oder JADE umgesetzt. In dieser Arbeit wird die Kombination der beiden Technologien für intelligente Assistenzsysteme untersucht. Durch die Verwendung der Kombination können intelligente Assistenzsysteme mit Dynamik, Modularität und Flexibilität ausgestattet werden. Hierfür wurden zwei unterschiedliche Kombinationsansätze der beiden Technologien für einen ausgewählten Anwendungsfall im Ambient Assisted Living gegenübergestellt und ausgewertet. Zusätzlich wurde der ausgewählte Ansatz anhand des Anwendungsfalls prototypisch umgesetzt.

1 Motivation Die Unterstützung des Alltags durch technische Systeme wird in Zukunft eine immer größere Bedeutung gewinnen, insbesondere für ältere und hilfsbedürftige Menschen. Aufgrund des soziodemografischen Wandels wird der Anteil der älteren Menschen und Einzelhaushalten ansteigen und daraus resultierend die Anzahl von Pflegebedürftigen zunehmen. Der daraus induzierten Nachfrage an Pflegeaufwand kann mit Hilfe von IT-basierten Systemen entgegengewirkt werden. Insbesondere durch die Integration von intelligenten Assistenzsystemen im Bereich des Ambient Assisted Living (AAL) soll die Selbstständigkeit von älteren und hilfsbedürftigen Menschen im eigenen Haushalt gefördert bzw. unterstützt werden. AAL umfasst dabei Konzepte, Produkte und Dienstleistungen, welche ein altersgerechtes selbstbestimmtes Leben für hilfsbedürftige Menschen unterstützen. AAL-Systeme werden heutzutage für unterschiedliche Anwendungsbereiche, wie z. B. in der Gebäudeautomatisierung oder in der Vernetzung von eingebetteten Systemen in einem Middlewaresystem, verwendet. [1] Insbesondere das Informationsportal AAL-Kompetenz, für die Entwicklung von intelligenten Assistenzsystemen, stellt unterschiedliche AAL-Referenzprojekte vor, welche größtenteils basie-

72

Eggert, Fertich

rend auf dem OSGi Framework für modulare dynamische Softwaresysteme umgesetzt sind sowie zum Teil auch als agentenbasierte Systeme entwickelt werden. [2] Um AAL-Systeme als modulare intelligente Assistenzsysteme mit einer dynamischen Integration umzusetzen, soll die Kombination der beiden Technologien JADE und OSGi untersucht werden. Durch die Umsetzung eines speziellen AAL Use Cases wird diese Kombination untersucht und ausgewertet. Die beiden Technologien JADE und OSGi wurden aufgrund ihrer Kompatibilität zueinander und ihrer Plattformunabhängigkeit für die Kombination ausgewählt. Hierbei sollen im besten Fall die Vorteile der einen Technologie die Nachteile der anderen Technologie aufheben.

2 Grundlagen In diesem Kapitel werden zunächst die Grundlagen vermittelt, die für das Verständnis dieser Arbeit relevant sind. Zuerst werden Multiagenten Systeme und das ausgewählte Framework JADE für agentenbasierte Anwendungen erläutert. Zum Schluss wird das dynamische Modulsystem OSGi vorgestellt.

2.1 Multiagenten Systeme Multiagenten Systeme (MAS) bestehen aus mehreren Softwareagenten, die kollektiv und autonom eine Problemstellung lösen. Softwareagenten sind gleiche oder unterschiedliche Computerprogramme, welche mit einem eigenständigen Verhalten in einer definierten Umgebung versuchen, ein spezifisches Ziel zu erreichen [3]. Nach Weiß und Jakob in [3] sind Softwareagenten:  autonom: Die Aufgabenbearbeitung erfolgt ohne die Kontrolle von Dritten und wird selbstständig durchgeführt.  reaktiv: Softwareagenten reagieren auf Änderungen in ihrer Umgebung und handeln angemessen darauf.  proaktiv: Softwareagenten reagieren vorausschauend und planend, um ihre Ziele in einer Umgebung zu erreichen.  interaktiv: Um ein Problem zu lösen, sind Softwareagenten in der Lage, mit ihrer Umwelt oder mit Dritten zu interagieren.

JADE-OSGi im Bereich des Ambient Assisted Living

73

2.2 Java Agent Development Framework Die Telecom Italia vertreibt die quelloffene Middleware Java Agent Development Framework (JADE) für agentenbasierte Anwendungen, welche sich nach der Foundation for Intelligent Physical Agents (FIPA) Spezifikation richtet [4]. Die FIPA ist ein Standardisierungsgremium für heterogene und interagierende agentenbasierte Systeme. Das Standardisierungsgremium befasst sich dabei mit der abstrakten Architektur, dem Agentenmanagement, der Agentenkommunikation und dem Transport von Agentennachrichten [5]. Eine JADE-Plattform besteht aus Agentencontainern, welche auf mehrere Hosts verteilt werden können. Jeder Container auf einem Host benötigt eine Java Laufzeitumgebung, um die enthaltenen Softwareagenten auszuführen. Bei jeder Agentenplattform wird ein spezieller Container, der Main Container, benötigt. Bei diesem müssen sich alle weiteren erzeugten Containern registrieren. Beim Starten eines Main Containers werden zwei spezielle Agenten initialisiert, der AMS-Agent und der DF-Agent. [6] Das Agent Management System (AMS) kontrolliert die gesamte Agentenplattform, da sie im Grunde alle Agentenverwaltet und deren Lebenszyklus steuert. Der Directory Facilitator (DF) wird von Softwareagenten verwendet, um ihre Dienste zu registrieren oder nach verfügbaren Diensten von anderen Softwareagenten zu suchen. Jeder Softwareagent erhält durch das AMS eine AID (Agent Identifier) für die eindeutige Identifikation auf der gesamten JADE-Plattform. JADE bietet für die Kommunikation von Softwareagenten den Message Transport Service (MTS), um den Transport von FIPA-konformen Nachrichten zu unterstützen. Nachrichten für den Austausch von Agenten werden in der FIPA-konformen Agent Communication Language (ACL) verfasst. Das MTS verwaltet dabei den gesamten internen sowie externen Nachrichtenaustausch zwischen Softwareagenten einer Agentenplattform durch verschiedene Transportprotokolle, wie z. B. das proprietäre Internal Message Transport Protocol (IMTP) für den internen Austausch von ACL-Nachrichten.[6]

2.3 OSGi OSGi spezifiziert eine universelle interoperable Integrationsplattform für Anwendungen und Dienste, die als dynamisches Modulsystem auf Basis von Java entwickelt wurde. Diese Plattform besteht dabei aus dem OSGi Framework und einigen Standard Services. [7] Das OSGi Framework ist die Hauptkomponente der OSGi Plattform, die ein dynamisches Modulsystem und ein Service Management bzw. eine Service

74

Eggert, Fertich

Registry enthält. Das dynamische Modulsystem unterstützt dabei einen Container, um Bundles und Services zur Laufzeit zu installieren und auszuführen. Bundles sind aus OSGi Terminologie Java Module, welche als eine eigenständige und zusammenhängende Einheit von Klassen und Ressourcen betrachtet werden können. Benutzerdefinierte Dienste und Anwendungen können durch die Service Registry systemweit als Service registriert und dadurch von Bundles genutzt werden.[8]

3 Verwandte Arbeiten Mit der Kombination von JADE und OSGi befassen sich mehrere Arbeiten. Für die Kombination der beiden Technologien gibt es in der Literatur zwei Ansätze. Der erste Ansatz ist die Aufsetzung einer JADE Plattform in OSGi als OSGi Bundle. Beim zweiten Ansatz werden die Verhaltensmuster eines Softwareagenten innerhalb einer Agentenplattform als OSGi Bundles umgesetzt. Nachfolgend werden ausgewählte Arbeiten dieser zwei Ansätze vorgestellt.

3.1 OSGi mit JADE Integration In [9] von Carneiro et. al wird eine Architektur mit JADE und OSGi im Einsatzbereich Ambient Intelligence (AmI) vorgestellt. Bei dieser Architektur fungiert die JADE Plattform als OSGi Bundle und verwaltet weitere JADEOSGi Bundles, die als eigenständige Softwareagenten agieren. Diese Architektur stellen die Autoren anhand des Fallbeispiels VirtualECare für die Überwachung von älteren Menschen im eigenen Heim durch Sensoren vor. Dabei sind die Sensoren als OSGi Bundles implementiert und liefern Informationen für die JADE-OSGi Agenten. Ein Beispiel wäre die Regulierung der elektrischen Beleuchtung im Haus durch die Agenten Power Saving und Comfort anhand der gewonnen Informationen des Heilligkeitssensors. Zusätzlich müssen sich die beiden Agenten koordinieren, da ihre Zielsetzung mit Energie sparen und Wohnlichkeit in Konflikt stehen. Nach der Kompromissfindung der beiden Agenten erfolgt die Steuerung der elektrischen Beleuchtung anhand eines OSGi Bundles. Jaszczyk und Król präsentieren in [10] ebenfalls eine OSGi Architektur mit JADE-OSGi Bundles für ein Smart Home System. Dabei gibt es drei Arten von Geräten:  Agent-Less Devices verfügen über keine hohe Rechenleistung und können keine komplette Java Laufzeitumgebung mit laufenden Agenten be-

JADE-OSGi im Bereich des Ambient Assisted Living

75

treiben. Dennoch bieten sie einige Dienste an, auf die über FIPAkonforme ACL Nachrichten oder andere standardisierte Protokolle zugegriffen werden kann.  Agent Devices verfügen über genug Rechenleistung, um als OSGi Plattform zu fungieren und mehrere Softwareagenten als JADE-OSGi Bundles und herkömmliche OSGi Bundles zu betreiben.  Main Device ist im Grunde ein spezielles Agent Device und läuft als JADE Main Container. Die Agent Devices registrieren dabei ihre JADE Container beim Main Container des Main Device.

3.2 JADE mi OSGi Integration Die Autoren Gunasekera et. al stellen in [11] VERsatile Self-Adaptive Agents (VERSAG), eine allgemeine Architektur für leichtgewichtige flexible MAS, vor. Dieselben Autoren stellen in [12] aufbauend auf dieser Arbeit eine konkrete Implementierung mit JADE und OSGi vor. Bei VERSAG verfügen die Softwareagenten über die Fähigkeit, ihre Capabilities mit anderen Softwareagenten auszutauschen. Hierbei werden die Capabilities als austauschbare Softwareinheiten mit OSGi umgesetzt. Die Agentenplattform kann in der VERSAG Architekturtheoretisch auch eine andere Agentenplattform als JADE sein, solange diese die Mobilität und Kommunikation von Softwareagenten ermöglicht. Der Kernel kontrolliert den Agenten und gibt die Kontrolle an andere Module ab, wenn dies benötigt wird. Der Itinerary Service kann als Verwaltung der Reiseroute des mobilen Agenten angesehen werden. Hierbei erhält der Agent die nötigen Informationen über bestimmte Lokationen, in welchen er agieren soll. Im Capability Repository werden die anwendungsspezifischen Capabilities gespeichert. Der OSGi Container befindet sich dabei im Capability Execution Service, welcher verfügbare Capabilities vom Capability Repository verwendet und ausführt. Zusätzlich zu den anwendungsspezifischen Capabilities als OSGi Bundles verfügt dieser über den Adaption Service und Context Service. Der Adaption Servicebeinhaltet die Logik für die jeweilige Anpassung eines Agenten in einem spezifischen Kontext und steht in Beziehung zum Context Service, welcher die Anpassung eines Agentenbeeinflusst und ihn dadurch kontextbewusst macht.

4 Gegenüberstellung von JADE-OSGi und VERSAG Dieses Kapitel beschäftigt sich mit einer Gegenüberstellung von JADEOSGi und VERSAG. Hierbei werden die Möglichkeiten durch die Kombination von JADE und OSGi in den beiden Varianten aufgezeigt.

76

Eggert, Fertich

4.1 JADE-OSGi Die Telecom Italia bietet seit Version 3.7 von JADE ein offizielles JADEOSGi Bundle an, das mit OSGi konformen Frameworks ab Version 3.4 kompatibel ist [13]. Dementsprechend ist die Installation bzw. eine minimale Konfiguration des JADE-OSGi Bundles in einer OSGi Plattform mit wenig Aufwand verbunden. Die Idee von JADE-OSGi sieht es vor, dass sich jeder Agent in einem einzelnen Bundle befindet. Hiermit entstehen bereits Vorteile gegenüber eines normalen JADE Systemsohne OSGi. Agenten können dadurch einzeln zur Laufzeitaktualisiert werden. Das heißt, falls eine neue Version eines Agenten Bundles vorliegt, kann auf einen geeigneten Zeitpunkt gewartet werden, um diesen über die OSGi Update-Funktion zu aktualisieren. Ein passender Zeitpunkt wäre beispielsweise, wenn sich der Agent in einem nicht arbeitenden Zustand befindet. Durch den entstandenen Zugriff der Agenten auf OSGi Funktionen, können auch die OSGi Standard Services genutzt werden. Dies ermöglicht es z.B. durch den Configuration Admin Service einen Management Agenten zu realisieren, der die Bundles in der OSGi Umgebung verwalten kann. Ein anderes Beispiel wäre die Nutzung der Device Accessoder Preferences Services, um die Verwaltung von Geräten bzw. Eigenschaften von Geräten zu ermöglichen. Neben Agenten in OSGi Bundles können natürlich auch normale OSGi Bundles in der OSGi Umgebung installiert und die darüber angebotenen Services von den Agenten genutzt werden. Dadurch kann Funktionalität der Agenten, wie z. B. Datenbankzugriffe oder Web Service Aufrufe, in eigene Bundles ausgelagert werden. Dies bietet Transparenz, da der Agent nur den entsprechenden OSGi Service nutzt und der eigentliche Aufruf zur Ressource verborgen bleibt. Dementsprechend wird ebenfalls die Komplexität des Agenten verringert und die Wiederverwendung von Code geschaffen, da mehrere Agenten die Funktionalität eines Bundles nutzen können. Trotz den Vorteilen von JADE-OSGi für die Agenten, muss der Einfluss von OSGi auch auf die gesamte Architektur des Systems betrachtet werden. Durch OSGi ist die Architektur sehr flexibel. Das bedeutet, dass eine Restrukturierung, bspw. das Aufteilen eines Bundles in mehrere oder das Hinzufügen eines Bundles, vorgenommen werden kann, ohne vorhandene Bundles zu beeinflussen. Zusammenfassend kann JADE-OSGi als eine dynamische modulare Architektur bezeichnet werden, die zur Laufzeit erweiterbar und aktualisierbar ist.

JADE-OSGi im Bereich des Ambient Assisted Living

77

Durch den Einsatz von Agenten kann zusätzliche Intelligenz in das System eingebracht werden. Des Weiteren besteht durch die Nutzung der OSGi Standard Services das Potential der Selbstkonfiguration oder Selbstoptimierung durch spezielle ManagementAgenten.

4.2 VERSAG Im Gegensatz zu JADE-OSGi ist VERSAG ein allgemeiner Ansatz für jede Agentenplattform und ist nicht auf JADE beschränkt. Dennoch verwenden die gesichteten Arbeiten über VERSAG alle JADE als Agentenplattform. Der zentrale Fokus liegt hier bei den Capabilities. Dies sind OSGi Bundles mit einer bestimmten Funktionalität, die z.B. als Behaviours bei gewöhnlichen Agenten umgesetzt sind. Die VERSAG Architektur erlaubt es, dass Agenten ihre benötigten Capabilites entweder untereinander austauschen oder über Capability Repositories beziehen. Daher sind die Agenten in VERSAG adaptiv, indem sie sich je nach Kontext ihre Funktionalität aneignen. Durch den Itinerary Service werden den Agenten die zu durchlaufenden Lokationen vermittelt und entsprechende Aufgaben zugeteilt. Somit befinden sich die Agenten nicht dauerhaft an dem selben Ort, sondern sind mobil. Die Konfiguration von VERSAG ist nach [14] komplex und es müssen signifikante Änderungen an der OSGi Plattform vorgenommen werden, um diese innerhalb eines Agenten zu nutzen. Dafür muss die OSGi Plattform eventuell modifiziert werden, um sie in einem Agenten einzubetten. Es müssen beispielsweise Abhängigkeiten zu lokalen Konfigurationsdateien entfernt und die Konfigurationsparameter programmatisch übergeben werden, da ein VERSAG Agent sich nicht auf eine fixe Lokation beschränkt und ein Dateizugriff problematisch wäre. Zusammenfassend kann VERSAG als flexibles, adaptives und mobiles MAS bezeichnet werden.

4.3 Vergleich Um die Auswahl eines Ansatzes zu erleichtern, sollten zunächst die beiden Architekturen miteinander verglichen werden. Der Vergleich beider Architekturen wird dabei in Abbildung 1 sehr vereinfacht dargestellt. Der JADEOSGi Ansatz betreibt prinzipiell einen JADE-Container in einer unveränderten OSGi Plattform. Die Agenten beim JADE-OSGi Ansatz werden als spezielle Bundles umgesetzt, die sich beim JADE-Container Bundle registrie-

78

Eggert, Fertich

ren. VERSAG hingegen setzt spezielle Agenten in einer JADE-Plattform auf, die die o. g. Capabilities als OSGi Bundles in einer eigenen OSGiPlattform verwenden. Die Flexibilität der Agenten ist beim VERSAG Ansatz durch die Modularisierung und dem Austausch von Fähigkeiten als OSGI Bundles sehr enorm. Beim JADE-OSGi Ansatz agieren die Agenten sehr ähnlich wie in einer normalen JADE-Plattform, wobei diese zusätzlich ohne großen Aufwand andere normale OSGi Bundles verwenden können.

Abbildung 1: Vereinfachte Architektur von JADE-OSGi und VERSAG

4.4 Schlussfolgerung Beide Ansätze haben verschiedene Vorteile. Die Vorteile des JADE-OSGi Ansatzes beziehen sich mehr auf das Gesamtsystem, wobei sich die Eigenschaften von OSGi positiv auf die Qualitätsmerkmale der Agenten auswirken. Bei VERSAG liegt der Mehrwert durch die Nutzung von OSGi ausschließlich bei den Agenten. Ein großer Unterschied der beiden Ansätze liegt in der Zugänglichkeit der Bundles. Die Bundles bei JADE-OSGi können von jedem Agenten und jedem anderen Bundle verwendet werden. Dies ist bei VERSAG nicht der Fall. Hier haben die Agenten prinzipiell auch Zugriff auf alle Bundles, werden aber letztendlich einzeln in jeder OSGi Plattform der Agenten installiert. Falls nun mehrere Agenten auf einen gemeinsamen Zustand eines Bundles angewiesen sind, ist dies nicht ohne weiteres möglich. So müssten die Bundles bei jeder Änderung des Zustands wieder untereinander ausgetauscht

JADE-OSGi im Bereich des Ambient Assisted Living

79

werden, wobei das Erreichen eines Konsens zu jeder Zeit wahrscheinlich sehr komplex wäre. Für die im nächsten Kapitel folgende Implementierung fiel die Entscheidung auf JADE-OSGi, da einerseits durch das bereits vorhandene JADE-OSGi Bundle ein einfacherer Einstieg gegeben ist und andererseits dies als die geeignetere Variante für den Use Case erschien.

5 Prototypische Umsetzung eines AAL Use Case mit JADE-OSGi Dieses Kapitel beschäftigt sich mit der prototypischen Umsetzung eines AAL Use Case, der mit dem JADE-OSGi Ansatz realisiert wurde. Nachfolgend wird der UseCase genauer beschrieben. Danach wird auf die entstandene Architektur eingegangen und die Nutzung des JADE-OSGi Bundles erläutert.

5.1 Use Case: Mitfahrgelegenheit Dieser Use Case soll ein mögliches AAL Szenario darstellen, in dem das AAL-System eine gewünschte Mitfahrgelegenheit für den Benutzer arrangiert. Abbildung 2 stellt den Ablauf des Use Case mit allen notwendigen Akteuren und Subsystemen dar.

80

Eggert, Fertich

Abbildung 2: Use Case Mitfahrgelegenheit

Der Use Case ist ausgehend vom AAL User, der einen neuen Termin in seinen Kalender einträgt und dabei mitteilt, dass für diesen Termin eine Mitfahrgelegenheit an einen bestimmten Ort benötigt wird. Um dieses Szenario zu realisieren, wurden dafür zwei Agenten verwendet. Der Ride Agent ist für die gesamte Organisation rund um die benötigte Mitfahrgelegenheit verantwortlich. Der Reminder Agent hingegen nimmt Informationen entgegen, um den AAL User durch ein Alarmsystem auf in naher Zukunft bevorstehende Ereignisse zu erinnern. Das Zusammenspiel zwischen den Akteuren, Subsystemen und Agenten ist entsprechend Abbildung 2 wie folgt: 1. Der Ride Agent durchsucht periodisch den Kalender um Einträge zu finden, die eine Mitfahrgelegenheit benötigen. 2. Sobald ein Eintrag gefunden wurde, sucht der Ride Agent bei einem entsprechenden Service (hier ein Forum für Mitfahrgelegenheiten) nach einer passenden Mitfahrgelegenheit. 3. Die möglichen Mitfahrgelegenheiten werden vom Agenten auf Diskrepanzen zwischen der angebotenen Route der Mitfahrgelegenheit und dem eingetragenen Termin überprüft. Dazu ruft der Ride Agent Informationen zu entsprechenden Routen bei einem Route Service ab, um Ankunftszeiten zu überprüfen oder auszuwerten, ob ein möglicher Umweg noch im Rahmen der angebotenen Mitfahrgelegenheit liegt.

JADE-OSGi im Bereich des Ambient Assisted Living

81

4. Wenn Punkt 2 und Punkt 3 erfolgreich abgeschlossen sind, wird der Termin mit einer gefundenen Mitfahrgelegenheit bestätigt. Es wird ebenfalls ein weiterer Termin im Kalender angelegt, der die Ankunft bzw. die Abfahrt der Mitfahrgelegenheit am Wohnsitz des AAL User kennzeichnet. 5. Nachdem alle für den Ride Agent relevanten Punkte bezüglich der Organisation der Mitfahrgelegenheit abgeschlossen sind, informiert der Ride Agent den Reminder Agent über den Zeitpunkt der Abfahrt. 6. Durch die Informationen aus Punkt 5, die Informationen über den AAL User und anderen Kontext, kann der Reminder Agent entsprechend bestimmen, wann der AAL User auf die Abfahrt hingewiesen werden soll. Zu dem bestimmten Zeitpunkt (bspw. Fünf Minuten vor Abfahrt) wird dann das Alert System ausgelöst.

5.2 Architektur Die für das Use Case verwendete Architektur orientiert sich an den in Kapitel 3.1OSGi mit JADE Integration vorgestellten Arbeiten. Dementsprechend wird hier JADE-OSGi verwendet. Abbildung 3 zeigt hierbei einen gesamten Überblick der Architektur.

Abbildung 3: Überblick der Architektur

Jedes der Geräte ist mit einer OSGi Plattform ausgestattet. Hierfür wurde Equinox gewählt. Für Equinox haben mehrere Gründe gesprochen: 

Equinox war bereits bekannt und dementsprechend nur eine minimale Einarbeitung erforderlich.



Das JADE-OSGi Bundle wurde bereits erfolgreich mit Equinox getestet. [13]



Equinox bietet eine minimale Konfiguration ohne zusätzliche Bundles. Dadurch können Konfigurationsprobleme mit unbekannten Bundles ausgeschlossen werden.

82

Eggert, Fertich

Innerhalb der OSGi Plattform befinden sich die realisierten Bundles. Dabei muss zwischen zwei Typen von Bundles unterschieden werden: Bundles mit JADE Funktionalität und normalen Bundles. Folgend werden die Bundles mit JADE Funktionalität erläutert: 

JADE-OSGi: Das komplette JADE Framework in einem Bundle. Dieses wird von der Telecom Italia zur Verfügung gestellt [4].



Ride Agent & Reminder Agent: Der Code der Agenten in jeweils einem Bundle mit der entsprechenden Agentenlogik.

Die normalen OSGi Bundles sind folgende:  

Calendar: Bietet typische Kalender Funktionen über OSGi Services an.

 Alarm System: Bietet Aktionen des Alarm Systems als OSGi Services an.



Web Service Provider: Stellt eine Schnittstelle zwischen Bundles und externen Web Services dar. Dahinter befinden sich insgesamt zwei verschiedene Schnittstellen zur Kommunikation mit Web Services.



Axis: Bietet die Funktionalität aus der Apache Axis SOAP Engine für andere Bundles an, um SOAP Web Services zu nutzen. Axis besteht ebenfalls aus mehreren Bundles. Diese wurden von dem Spring Source Enterprise Bundle Repository1 bezogen.



JAXP: Bietet die Java API for XML Processing für andere Bundles an. JAXP besteht auch aus mehreren Bundles, die aus dem Maven Repository2 bezogen wurden.

5.3 Schichtenmodell Bei der Entwicklung der vorgestellten Architektur konnten verschiedene Schichten identifiziert werden. Abbildung 4 stellt die Schichten und Kommunikationswege dar.

1

http://ebr.springsource.com/repository/app/

2

http://mvnrepository.com/

JADE-OSGi im Bereich des Ambient Assisted Living

83

Abbildung 4: Die verschiedenen Schichten der Architektur

Demnach existieren bei Betrachtung der für den Use Case realisierten Bundles, ohne Bundles von Dritten (JAXP und Axis), drei Schichten:  Agent Layer: Hier befinden sich alle Agenten Bundles. Die Kommunikation innerhalb dieser Schicht, also zwischen Agenten, findet über ACL statt. Aufrufe zur nächsten Schicht erfolgen über OSGi Services.  Bundle Service Layer: In dieser Schicht befinden sich alle Bundles, die Services anbieten. Eine Kommunikation innerhalb dieser Schicht findet in diesem bestimmten Szenario zwar nicht statt, wäre aber möglich. Der Aufruf zur nächsten Schicht geht über die OSGi Plattform hinaus, hier beispielsweise zu externen Web Services.  External Service Layer: Hier befinden sich alle Services, die außerhalb der OSGi Plattform angeboten werden. In diesem Fall sind das zwei Web Services. Der Vorteil dieser Schichten wird deutlich, wenn z. B. die externen Web Services ausgetauscht werden. Dadurch ändert sich bei den Agenten nichts, da sie weiterhin nur als Schnittstelle die Service Provider ansprechen. Die Service Provider sind OSGi Bundles und können dementsprechend zur Laufzeit aktualisiert werden, falls eine Änderung bei den externen Services vorliegt.

84

Eggert, Fertich

5.4 Nutzung des JADE-OSGi Bundles Die Registrierung von Agenten, die sich in einem Bundle befinden, bei einem Container des JADE-OSGi Bundles ist ähnlich zu der normalen Registrierung von Agenten in JADE. Listing 1 zeigt hierfür den Code in der startMethode des Bundle Activators.

Listing 1: Registrierung eines Bundle Agenten im Container des JADE-OSGi Bundles

Über einen OSGi Service des JADE-OSGi Bundles kann auf den JadeRuntimeService zugegriffen werden. Dieser ist mit dem ContainerController in einer normalen JADE Umgebung gleichzusetzen und bietet dementsprechend die Kontrolle über die Container. In diesem Beispiel wird der Reminder Agent erstellt und im Main Container des JADE-OSGi Bundles registriert. Der Vorgang beim Ride Agent ist äquivalent. Bei der normalen Verwendung von JADE können verschiedene Parameter beim Start übergeben werden. Das JADE-OSGi Bundle wird allerdings in der OSGi Plattform gestartet. Dementsprechend müssen die Parameter an einer externen Stelle angegeben werden. Bei Equinox ist diese die config.ini, die auch für die OSGi Konfiguration verwendet wird. Listing 2 zeigt hierfür den Umgang mit den JADE Parametern. In der ersten Zeile ist noch ein OSGi spezifischer Parameter zum Start des JADE-OSGi Bundles. Die restlichen Zeilen zeigen die JADE Konfiguration.

Listing 2: Konfihuration des JADE-OSGi Bundles über die config.ini von Equinox

JADE-OSGi im Bereich des Ambient Assisted Living

85

Während der Nutzung des JADE-OSGi Bundles lief zunächst alles ohne Probleme ab. Als die Kommunikation der Agenten per ACL implementiert wurde, hat das JADE-OSGi Bundle das Fehlen eines SAX (Simple API for XML) Parsers gemeldet. Um dieses Problem zu lösen, muss ein JAXP Bundle in der OSGi Umgebung verfügbar sein. Hierfür wurde Apache Xerces als JAXP Bundle verwendet. Obwohl OSGi einen Service zum automatischen Auffinden eines JAXP kompatiblen Parsers bietet, musste zusätzlich der vollqualifizierte Klassenname für den SAX Parser in der JADE Konfiguration angegeben werden (siehe Listing 3).

Listing 3: Konfiguration des SAX Parsers

6 Fazit Durch die Kombination von JADE und OSGi entstehen neue Möglichkeiten im Bereich der Architektur und Infrastruktur von Multiagenten Systemen. In dieser Arbeit wurden zwei populäre Ansätze der Literatur vorgestellt und verglichen. Es wurde der gewonnene Mehrwert beider Ansätze aufgezeigt und mögliche Schwierigkeiten und Einschränkungen diskutiert. Des Weiteren wurde JADE-OSGi ausgewählt um einen speziellen Use Case des Ambient Assisted Living prototypisch zu realisieren. Dabei konnten die gewonnenen Vorteile, wie z. B. die Transparenz oder Wiederverwendung, schnell und einfach genutzt werden. Der gemeinsame Einsatz von JADE und OSGi verbessert den Bereich des Ambient Assisted Living aus architektonischer und funktionaler Sicht. Bisherige OSGi-basierte Systeme können durch Agenten beispielsweise mit Ambient Intelligence ausgestattet werden. Umgekehrt besteht das Verbesserungspotential bisheriger Multiagenten Systeme aus den architektonischen Qualitätsmerkmalen von OSGi. Als Ausblick könnte eine gemeinsame Verwendung von JADE-OSGi und VERSAG in einem System in Betracht gezogen werden. Dadurch könnten die Vorteile beider Ansätze kombiniert werden. JADE-OSGi würde beispielsweise die dynamische Integration durch Management Agenten von neuen Geräten abdecken und VERSAG bietet flexible und adaptive Agenten, um eine intelligente Umgebung zu schaffen.

86

Eggert, Fertich

Literatur [1]

[2]

[3] [4]

[5] [6] [7] [8] [9]

[10]

[11]

[12]

[13] [14]

P. Georgieff, “Ambient Assisted Living –Marktpotenziale IT-unterstützter Pflege für ein selbstbestimmtes Altern,” in FAZIT-Schriftenreihe Band 17. MFG Stiftung BadenWürttemberg, Zentrum für Europäische Wirtschaftsforschung GmbH (ZEW), Fraunhofer ISI, Oktober 2008 Das Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, “AAL Kompetenz. Das Informationsportal für Entwickler von intelligenten Assistenzsystemen.” [Online]. Available: http://www.aal-kompetenz.de/ G. Weiß and R. Jakob, Agentenorientierte Softwareentwicklung-Methoden und Tools. Springer Berlin Heidelberg, 2005. Telecom Italia S.p.A. (2014) JADE, Java Agent Development Framework - an Open Source platform for peer-to-peer agent based applications. [Online]. Available: http://jade.tilab.com/ IEEE Foundation for Intelligent Physical Agents. (2014) The Foundation for Intelligent Physical Agents. [Online]. Available: http://www.fipa.org/ F. L. Bellifemine, G. Caire, and D. Greenwood, Developing Multi-Agent Systems with JADE (Wiley Series in Agent Technology). John Wiley & Sons, 2007. A. de Castro Alves, OSGi in Depth. Manning Publications, Dezember 2012. G. Wütherich et al., Die OSGi Service Platform: Eine Einführung mit Eclipse Equinox. April: dpunkt, 2008. D. Carneiro et al., “Developing intelligent environments with osgi and jade,” in Artificial Intelligence in Theory and Practice III, ser. IFIP Advances in Information and Communication Technology, M. Bramer, Ed. Springer Berlin Heidelberg, 2010, vol. 331, pp. 174–183. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-15286-3 17 P. Jaszczyk and D. Król, “Updatable multi-agent osgi architecture for smart home system,” in Agent and Multi-Agent Systems: Technologies and Applications, ser. Lecture Notes in Computer Science, P. Jedrzejowicz,N. Nguyen, R. Howlet, and L. Jain, Eds. Springer Berlin Heidelberg, 2010, vol. 6071, pp. 370–379. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-13541-5 38 K. Gunasekera et al., “Versag: Context-aware adaptive mobile agents for the semantic web,” in Computer Software and Applications, 2008. COMPSAC ’08. 32nd Annual IEEE International, July 2008, pp. 521–522. K. Gunasekera et al., “Component based approach for composing adaptive mobile agents,” in Agent and Multi-Agent Systems: Technologies and Applications, ser. Lecture Notes in Computer Science, A. Håkansson, N. Nguyen, R. Hartung,R. Howlett, and L. Jain, Eds. Springer Berlin Heidelberg, 2009, vol. 5559, pp. 90–99. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-01665-3 10 E. Quarantotto and G. Caire, JADE OSGi Guide, Telecom Italia, 2010. [Online]. Available: http://jade.tilab.com/doc/tutorials/JadeOsgiGuide.pdf K. Gunasekera et al., “Building ubiquitous computing applications using the VERSAG adaptive agent framework, ”Journal of Systems and Software, vol. 86, no. 2, pp. 501–519, 2013. [Online]. Available: http://www.science-direct.com/science/article/ pii/S0164121212002695

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security Stefan Eggert, Artur Fertich Fakultät Informatik Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen [email protected], [email protected] Abstract: Es gibt eine Vielzahl von Penetration Testing Tools für Web Services, die auf Schwachstellen im Backend der Anwendung prüfen. Die Anzahl von Tools für spezifische Web Service Angriffe ist hingegen minimal. Aus diesem Grund wird in dieser Arbeit das automatisierte Penetration Testing Tool WS-Attacker für spezifische Web Service Angriffe vorgestellt und evaluiert. Die Evaluation erfolgt anhand der Erfüllung der Anforderungen und der Kriterien Bedienbarkeit, Nachhaltigkeit und Wartbarkeit, um das Zukunftspotential des Tools herauszuarbeiten

1 Einleitung Die Verwendung von Serviceorientierten Architekturen (SOA) hat in den letzten Jahren stark zugenommen. Eine wichtige Technologie für SOA sind dabei Web Services (WS), welche XML-basierte SOAP-Anfragen verwenden, um entfernte Aufrufe auszuführen. [1] Aufgrund dieses Trends sind Penetrationstests für WS unerlässlich, um die Vertraulichkeit, Integrität und Verfügbarkeit dieser zu gewährleisten. Penetrationstests sind nach [2] simulierte Attacken mit dem Ziel, Systeme auf ihre Angreifbarkeit durch mögliche reale Angriffe zu untersuchen. Bei SOAP-basierten WS existieren spezifische Angriffsmöglichkeiten, welche bekannte Schwachstellen von XML-basierten SOAP-Nachrichten ausnutzen. Ebenfalls existieren nicht-spezifische Angriffsmöglichkeiten für WS, welche Sicherheitslücken im Backend von Webanwendungen, wie z.B. SQL-Injections oder Cross Site Scripting, nutzen. Für nicht-spezifische WS Angriffe gibt es eine große Anzahl von Penetration Testing Tools mit denen solche Schwachstellen identifiziert werden können. Eine kleine Anzahl dieser Tools beschäftigt sich mit spezifischen WS-Angriffen, die manuell erfolgen, wie z. B. bei soapUI. Aus diesem Grund wurde das automatisierte Pe-

88

Eggert, Fertich

netration Testing Tool WS-Attacker für spezifische WS-Angriffe entwickelt, das in dieser Arbeit evaluiert wird. [3][4]

2 Grundlagen In diesem Kapitel werden zunächst die Grundlagen vermittelt, die für das Verständnis dieser Arbeit relevant sind. Zuerst werden die grundlegen den Informationen über WS vorgestellt. Zum Schluss wird der Sicherheitsstandard WS-Security bei WS erläutert.

2.1 Web Services Web Services sind serviceorientierte Anwendungen, welche eine Schnittstelle anbieten, damit eine Softwarekomponente als Service agieren kann. Über solche Schnittstellen wird eine Anwendung-zu-Anwendung Interaktion ermöglicht. [5] Bei WS werden hierfür vier Basistechnologien verwendet: Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) und Universal, Description, Discovery and Integration (UDDI). [5] XML ist eine Metasprache für die Darstellung von hierarchisch strukturierten Daten in textueller Form. SOAP wird für den Austausch von XML Nachrichten über Standard Transport Protokolle verwendet. Hierbei können XML-Nachrichten in einem sogenannten Envelope platziert werden, um diese als SOAP-Nachricht zu verschicken. Der Envelope bei SOAP besteht aus dem SOAP-Header, der Metainformationen für die Verwaltung oder Sicherheit enthält, und SOAP-Body, der die eigentliche Nutzlast beinhaltet. WSDL ist eine XML Sprache für einen WS, welche die Operationen und die Struktur von zugeordneten SOAP-Nachrichten definiert. Eine WSDL eines WS ist im Grunde ein Abkommen, wie andere Dienste mit dem WS interagieren können. Die UDDI ist ein standardisierter Verzeichnisdienst für WS. [6]

2.2 Web Services Security Web Services Security (WS-Security) befasst sich mit dem Sicherheitsaspekt bei WS. WS-Security spezifiziert, wie XML Signature, XML Encryption und Security Tokens in SOAP-Nachrichten dargestellt werden. XML Signature bietet bei WS-Security Methoden, um SOAP-Nachrichten komplett oder teilweise zu signieren und einen Signaturwert in den SOAP-Header zu platzieren. Ebenfalls können mit XML Encryption SOAP-Nachrichten ver- und entschlüsselt werden. Informationen für die Ver- und Entschlüsselung werden dabei in den SOAP-Header platziert. XML Signature gewährleistet die

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security

89

Integrität und Authentizität und XML Encryption die Vertraulichkeit von SOAP Nachrichten. Zusätzlich können im SOAP-Header Security Tokens mitgeschickt werden, welche für Autorisierungs- oder Authentifizierungsmechanismen verwendet werden. [5]

3 WS-Attacker WS-Attacker, das automatisierte Penetration Testing Tool für spezifische WS-Angriffe, wurde in [3] von Mainka, Somorovsky und Schwenk vorgestellt. Zuerst unterstützte das Tool die WS-Attacken SOAP Action Spoofing und WS-Addressing Spoofing. Zusätzlich wurde in dieser Arbeit der Aufbau und die Funktionsweise des Tools erklärt, das später in diesem Kapitel genauer beschrieben wird. Zum Schluss erfolgte eine Evaluation von mehreren WS-Frameworks, die einige Schwachstellen dieser Frameworks durch die umgesetzten WS-Angriffe aufzeigte. Durch spätere Arbeiten wurde das Tool noch um den WS-Angriff XML Signature Wrapping und einige WSspezifische Denial of Service Attacken erweitert.

3.1 Aufbau und Funktionsweise WS-Attacker unterstützt einen Penetrationstester bei der Durchführung spezifischer WS-Angriffe mit Hilfe einiger Bearbeitungsschritte, die in Abbildung 1 dargestellt werden. Ebenfalls kann aus Abbildung 1 eine Übersicht der Hauptkomponenten von WS-Attacker entnommen werden. [3]

Abbildung 1: Hauptkomponenten und Bearbeitungsschritte von WS-Attacker [3]

90

Eggert, Fertich

WS-Attacker besteht dabei aus einem Framework als Hauptkomponente und der Plugin Architecture. Die Aufgabe des Frameworks ist es, die Umgebung für die Durchführung von Attacken aufzusetzen und die Bearbeitungsschritte zu verwalten. Die Plugin Architecture besteht aus einer gewissen Anzahl von Plugins, wobei jedes Plugin eine Attacke repräsentiert. [3] Die Bearbeitungsschritte beim Framework sind nach [3] wie folgt: 1. Das Framework analysiert und extrahiert alle möglichen Operationen und anschließend erfolgt die Auswahl dieser durch den Benutzer. 2. Danach wird eine gültige Anfrage für die ausgewählte Operation generiert und es werden Eingabefelder für Nachrichtenparameter bereitgestellt. 3. Der Benutzer sendet durch das Tool eine Testanfrage und erhält eine Antwort vom WS. Diese Anfrage-Antwort-Paare werden als Referenz für die Erstellung von Angriffen verwendet. 4. Plugins werden ausgewählt und konfiguriert. 5. Das Framework führt anschließend die ausgewählten Attacken aus. 6. Zum Schluss werden die vom Plugin erzeugten Ergebnisse dem Benutzer grafisch dargestellt. Zusätzlich verwendet das Framework noch einen Plugin Manager, der alle Plugins enthält und aktivieren kann. [3]

3.2 Erweiterung um XML Signature Wrapping Mainka erweitert das Tool in [1] um die spezifische WS-Attacke XML Signature Wrapping (XSW). Bei XSW wird die signierte Originalnachricht über ein Wrapper Element an eine andere Position in einer SOAP-Nachricht platziert und die ursprüngliche Stelle der signierten Nachricht mit einer neuen schadhaften Nutzlast ausgestattet [8]. Diese Attacke funktioniert, da das Modul für die Signaturprüfung anhand der Referenz nach der signierten Originalnachricht sucht und diese als valide betrachtet. Aufgrund der Trennung der Module für die Signaturprüfung und der Ausführung der Nutzlast führt das Modul für die Ausführung der Nutzlast die veränderte Nutzlast trotzdem aus. Das Modul betrachtet dabei nur die Nutzlast und wird aufgrund der gültigen Signaturprüfung ausgeführt. Zusätzlich zur Erweiterung des Tools konnte in [1] festgestellt werden, dass die WS-Frameworks Apache Axis2 und IBM DataPower X150 anfällig für XSW sind. Nur das WS-Framework XML Spoofing Resistant Electronic Signature (XSpRES), ein von dem Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickeltes Modul

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security

91

für die sichere Erstellung und Verifikation von Signaturen, konnte dieser WS-Attacke widerstehen.

3.3 Erweiterung um Denial of Service Falkenberg et. al erweiterten in [4] das Tool mit Denial of Service (DoS) Funktionalität und entwickelten zusätzlich noch mehrere spezifische WS DoS-Angriffe für WS-Attacker. WS-spezifische DoS-Angriffe zielen dabei auf die Verarbeitungseinheiten von WS ab. Zum Beispiel nutzt die implementierte SOAP Array Attack eine Schwachstelle beim WS aus, damit der XML Parser eine immense Menge von großen Arrays deklarieren muss und daraus resultierend den Speicher des Web Servers erschöpft [7]. Auf Basis der Funktionalität von WS-Attacker, WSDL Dateien zu analysieren und aus diesen SOAP-Nachrichten zu generieren, wurde in [4] ein abstraktes, wiederverwendbares DoS Plugin entwickelt. Ein DoS Plugin teilt sich dabei in zwei Komponenten auf, die MVC DoS Erweiterung und die DoS Attack Klasse. Die DoS Attack Klasse benötigt je nach Angriffsart spezifische Konfigurationsparameter, um die Nutzlast des Angriffs für das Testszenario anzupassen. Anschließend werden unveränderte sowie veränderte SOAP-Nachrichten erzeugt und mit einem Padding versehen, damit die veränderten sowie unveränderten SOAP-Nachrichten die gleiche Größe besitzen. Darauffolgend wird die konfigurierte DoS-Attacke mit der MVC DoS Erweiterung ausgeführt. Dabei werden in der ersten Phase eine benutzerdefinierte Anzahl an unveränderten Nachrichten versendet und in der zweiten Phase die gleiche Anzahl von veränderten Nachrichten. Parallel dazu werden Drittnutzeranfragen versendet, die im Grunde weitere Nutzer im System simulieren sollen. Bei allen drei Arten von Nachrichten wird die Anfragezeit gemessen und ausgewertet. Erhöhen sich bei der Messung während oder nach der Versendung der veränderten Nachrichten die Anfragezeiten immens, kann dies als erfolgreicher DoS-Angriff gewertet werden. Anschließend werden die generierten Ergebnisse aus der MVC DoS Erweiterung an die DoS Attack Klasse weitergereicht, damit diese die Ergebnisse im WSAttacker grafisch aufbereitet. [4]

4 Evaluation Die Evaluation dieser Arbeit bezieht sich dabei auf die Bedienbarkeit, Nachhaltigkeit und Wartbarkeit des Tools WS-Attacker basierend auf den Kriterien von [9], die von der ISO/IEC 9126-1 abgeleitet wurden. In dieser Arbeit wurden die spezifischen WS-Attacken explizit nicht anhand von WSFrameworks evaluiert, da dies bereits in der Literatur [1][3][4] durchgeführt

92

Eggert, Fertich

wurde. Zusätzlich zu den Kriterien aus [9] wird WS-Attacker auf die Erfüllung der Anforderungen überprüft, die in [3] gestellt wurden.

4.1 Erfüllung der Anforderungen Die Anforderungen sind in Anforderungen für Framework Benutzer und Anforderungen für Plugin Entwickler unterteilt. Nachfolgend werden die jeweiligen Anforderungen dargestellt und deren Erfüllung in WS-Attacker diskutiert. 4.1.1 Anforderungen für Framework Benutzer „The framework must be easy to use.“ [3] Diese Anforderung ist bei alleiniger Betrachtung des Frameworks grundlegend erfüllt. Die Nutzung von WS-Attacker ist sehr einfach. Allerdings baut WS-Attacker auf Plugins, um die eigentliche Attacke auszuführen. Dadurch ist die Schwierigkeit der Nutzung zu einem größeren Teil von den Plugins abhängig. Hierbei kann, je nach Attacke, ein größerer Konfigurationsaufwand notwendig sein. „Only a few clicks should be necessary to test a Web Service.“ [3] Die Erfüllung dieser Anforderung ist einfach zu überprüfen: Vom Start des Tools bis zur Ausführung einer Attacke werden mindestens sieben Klicks benötigt. Dies ist inklusive notwendiger Wechsel von Tabs, aber exklusive Klicks um Textfelder zu fokussieren. Dabei wurde nur das SOAP Action Spoofing Plugin aktiviert, welches keine Konfiguration benötigt. “The users do not need any knowledge about XML or Web Services and especially, they do not need any knowledge about XML Security.” [3] Diese Anforderung ist als kontrovers zu betrachten. Um eine einfache Attacke ohne aufwändige Konfiguration auszuführen, wird zunächst eine URL zur WSDL des zu testenden WS benötigt. Falls ein Benutzer kein Wissen über WS hat, kennt dieser wahrscheinlich nicht den Zweck der WSDL und auch nicht die URL zu dieser. Weiterführend sollte zumindest ein Basiswissen über die ausgeführten Attacken vorhanden sein, um möglicherweise komplexere Konfigurationen vorzunehmen und Auswirkungen der Attacke abschätzen zu können.

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security

93

4.1.2 Anforderungen für Plugin Entwickler „It must be easy to implement new attacks, where each attack is represented by a WS-Attacker plugin.“ [3] Die ersten Schritte bei der Entwicklung eines Plugins sind dank abstrakter Klassen und Templates einfach. Da jeglicher Quellcode offen und zugänglich ist, besteht ebenfalls die Möglichkeit der Orientierung an bestehenden Plugins. Probleme traten allerdings bei der Installation des Plugins in WSAttacker auf. Es gibt keine konkrete Anleitung, wie das fertig gebaute und in einem JAR (Java Archive) verpackte Plugin konfiguriert werden muss, um es in WS-Attacker einzubinden. Bei der Betrachtung der eigentlichen Implementierung einer Attacke ist die Komplexität ebenfalls von der Attacke selbst abhängig. Das WS-Attacker Framework unterstützt den Entwickler jedoch bei WS-spezifischen Gegebenheiten. Beispielsweise wird die Funktionalität von soapUI zur Verfügung gestellt, um SOAP-spezifische Aufgaben einfacher zu lösen. „Any attack category must be supported (spoofing attacks, Denial of Service, etc.)“ [3] Als diese Anforderung gestellt wurde, gab es nur zwei Attacken der Kategorie Spoofing. Die Kategorien wurden später um Security bzw. Signature durch XSW und um Denial of Service durch mehrere DoS-Attacken ergänzt. Diese Anforderung ist demnach erfüllt und bereits praktisch belegt. „Open for extension: there must be support even for prospective, not yet invented, attacks.“ [3] Dies wird sich erst widerlegen, wenn eine neue Attacke entwickelt wurde und WS-Attacker eine korrekte Umsetzung nicht ermöglicht. Derzeit kann aber die Aussage getroffen werden, dass Plugins in ihrem Funktionsumfang nicht eingeschränkt sind. Dies beweist die Erweiterung der DoS-Attacken in [4]. Hier wurde beispielsweise, zusätzlich zu den Attacken, ein in anderen DoS-Angriffen wiederverwendbares Tool zur Analyse und Auswertung des Netzwerkverkehrs integriert.

4.2 Bedienbarkeit Die Verständlichkeit, worum es sich bei WS-Attacker handelt, ist erkenntlich. Der Zweck des Tools ist das Penetration Testing von WS. Die angesprochene Gruppe von Nutzern ist ebenfalls deutlich: Entwickler von WS und Sicherheitsexperten. Die Funktionen sind in Grundfunktionen und erweiterte Funktionen eingeteilt. Die Grundfunktionen umfassen die Benutzung des Tools und ergeben dementsprechend die Sicherheitsanalyse von

94

Eggert, Fertich

WS. Die erweiterten Funktionen umfassen die Plugin Entwicklung, bzw. die dafür bestehende Unterstützung des Frameworks. Die Dokumentation ist negativ zu bewerten. Es existiert eine Benutzerdokumentation mit einer Schritt-für-Schritt-Anleitung der Grundfunktionen. Für einzelne Plugins bestehen ebenfalls kurze Erläuterungen über die Nutzung und Konfiguration. Eine Entwicklerdokumentation vom Aufbau des Tools ist nur grundlegend in [3] vorhanden. Dort ist ebenfalls eine kurze Anleitung zur Plugin Entwicklung geschildert. Allerdings gibt es keine Details zur Installation bzw. Konfiguration eines Plugins für WS-Attacker. Die Installierbarkeit ist dank Umsetzung in Java und Auslieferung der Distribution als JAR sehr gut. Dadurch ist kein Installationsprozess notwendig. Eine Dokumentation wird nicht direkt mitgeliefert. Für Entwickler ist der gesamte Quellcode auf SourceForge verfügbar. Es wird ebenfalls die BuildKonfiguration für Apache Maven mitgeliefert. Pakete oder Bibliotheken von Drittanbietern werden direkt mitgeliefert oder von Maven während dem Build-Prozess hinzugefügt. Die Erlernbarkeit der Grundfunktionen von WS-Attacker erfolgt schnell. Durch einen immer ähnlichen Ablauf bei der Ausführung einer Attacke ist die Einarbeitung sehr schnell. Bei den erweiterten Funktionen, also der Entwicklung von Plugins für Angriffe, ist dies nicht der Fall. Da es keine explizite API Dokumentation zur Plugin Entwicklung gibt, dauert die Einarbeitung verhältnismäßig lange. Für den produktiven Einsatz fehlt es dem Tool allerdings an Sicherungsfunktionen. Es ist zwar möglich, die Konfiguration der Plugins zu speichern, aber nicht die Voreinstellungen für den zu testenden WS. Dementsprechend muss bei jedem Start von WS-Attacker die URL zur WSDL neu eingegeben und die SOAP Konfiguration neu vorgenommen werden. Ebenfalls wäre es wünschenswert, wenn mehrere WS in einem Durchlauf getestet werden könnten.

4.3 Wartbarkeit Die Testbarkeit von WS-Attacker ist überwiegend gegeben. Für beinahe jede Funktion ist ein Unit Test vorhanden. Des Weiteren ist die Ausführung der Unit Tests notwendig für den Build-Prozess. Automatisierte Tests für die Benutzeroberfläche sind nicht enthalten. Dies ist einerseits verständlich, da GUI Tests meist sehr aufwändig sind. Andererseits wäre zumindest ein sorgfältiger manueller Test der GUI sinnvoll gewesen, da bei der Nutzung von WS-Attacker einige Fehlverhalten der Benutzeroberfläche festgestellt werden konnten. So war es beispielsweise nicht möglich, im Bereich der Ergebnisinformationen bei einem maximierten Fenster nach oben zu scrollen.

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security

95

Durch die Entwicklung in Java ist die Portabilität hervorragend. WSAttacker kann somit auf jedem Gerät mit einer Java Laufzeitumgebung benutzt werden. Die Analysierbarkeit des Quellcodes ist ebenfalls gut. Beinahe jede Methode ist mit Kommentaren zu ihrer Funktionalität, inkl. Eingabe- und Rückgabeparameter, ausgestattet. Insgesamt konnten sehr wenige Fragmente aus der Entwicklung, wie z. B. auskommentierter Code oder Todos, gefunden werden. Die Änderbarkeit innerhalb des Open Source Projekts ist noch nicht sehr ausgebaut. Für den eigenen Nutzen sind Änderungen durch die Maven Build-Scripts kein Problem. Wie Änderungen für die Allgemeinheit eingebracht werden, ist wegen fehlender Contribution Policies noch offen. Ebenfalls sind die Änderungen zwischen den Versionen nur teilweise dokumentiert und müssen zu einem großen Teil aus den Kommentaren der Commits im Repository gelesen werden. Die Interoperabilität ist ebenfalls gegeben. Prinzipiell besteht die Möglichkeit, jeden WS* Standard zu verwenden und dementsprechend dafür Angriffe zu entwickeln. Da WS-Attacker auf WS abzielt und diese bereits interoperabel standardisiert sind, besteht hier keine Eingrenzung auf bestimmte Web Server, die getestet werden können.

4.4 Nachhaltigkeit Die Grundbausteine zur Identität von WS-Attacker sind vorhanden. WSAttacker ist das erste automatisierte Penetration Testing Tool für XMLbasierte WS [3]. Ebenfalls schließt der Name des Tools sofort auf die dadurch gebotene Funktionalität. Durch die Präsenz auf SourceForge sind erste Schritte für die Öffentlichkeit des Projekts geschaffen. Copyright und Lizenz sind ebenfalls vorhanden. Jede Codedatei hat einen Copyright Header mit expliziter Angabe des Autors und Lizenzinformationen. WS-Attacker ist unter der GNU General Public Licence 2 lizenziert. Die Community von WS-Attacker befindet sich noch im Wachstum. Das Projekt wurde vom BSI gefördert. Dementsprechend ist davon auszugehen, dass eine gewisse Nachfrage nach einem solchen Tool besteht. Die Erreichbarkeit des Projekts bzw. des Quellcodes ist ebenfalls gegeben. Durch das öffentliche Repository bei SourceForge ist der Quellcode für jeden zugänglich und Entwicklungsschritte des Projekts nachvollziehbar.

96

Eggert, Fertich

5 Zusammenfassung In dieser Arbeit wurde das Penetration Testing Tool für XML-basierte Web Services WS-Attacker zunächst vorgestellt und danach auf die Erfüllung der Anforderungen, Bedienbarkeit, Wartbarkeit und Nachhaltigkeit überprüft, um das Zukunftspotential dieses Tools zu veranschaulichen. WS-Attacker bietet als erstes Penetration Testing Tool für Entwickler und Sicherheitsexperten die Möglichkeit, WS-spezifische Angriffe einfach und automatisiert durchzuführen. Durch die Plugin-basierte Erweiterbarkeit des Tools können weitere Angriffe problemlos integriert werden. Spätere Implementierungen von Attacken werden aufgrund der bereits gebotenen Grundfunktionalität erleichtert. Einzig die schwache Dokumentation hindert die Einarbeitung in die Entwicklung von Plugins und Förderung des Projekts. Zwar ist das Tool noch in einer frühen Phase der Entwicklung und daher noch relativ unbekannt, hat aber aufgrund des wenig abgedeckten Anwendungsgebiets großes Zukunftspotential.

Literatur [1] C. Mainka (22.Mai.2012): Automatic Penetration Test Tool for Detection of XML Signature Wrapping Attacks in Web Services. Master Thesis. Ruhr-Universität Bochum, Bochum. Lehrstuhl für Netz- und Datensicherheit. Online verfügbar unter http://www.nds.ruhr-uni-bochum.de/media/nds/arbeiten/2012/07/24/ws-attacker-ma.pdf. [2] K. M. Henry (2012): Penetration Testing: Protecting Networks and Systems. United Kingdom: IT Governance Publishing. [3] C. Mainka; J. Somorovsky; J. Schwenk (2012): Penetration Testing Tool for Web Services Security. In: Services (SERVICES), 2012 IEEE Eighth World Congress on, S. 163–170. [4] A. Falkenberg; C. Mainka; J. Somorovsky; J. Schwenk (2013): A New Approach towards DoS Penetration Testing on Web Services. In: Web Services (ICWS), 2013 IEEE 20th International Conference on, S. 491–498.Literatur (manuell nummeriert) [5] J. B. Rosenberg (2004): Securing Web services with WS-Security. Demystifying WSSecurity, WS-Policy, SAML, XML Signature, and XML Encryption. - Includes index. Indianapolis, IN: Sams. Online verfügbar unter http://proquest.tech.safaribooks online.de/0672326515. [6] E. Bertino; L. Martino; F. Paci; A. Squicciarini (2010): Security for Web Services and Service-Oriented Architectures: Springer Berlin Heidelberg. Online verfügbar unter 10.1007/978-3-540-87742-4. [7] mitre.org, “CAPEC-256: SOAP Array Overflow,” http://capec.mitre.org/data/definitions /256.html, 2012. [8] M. McIntosh; P. Austel (2005): XML Signature Element Wrapping Attacks and Countermeasures. In: Proceedings of the 2005 Workshop on Secure Web Services. New York, NY,

Evaluation des Penetration Testing Tool WS-Attacker für Web Services Security USA: ACM (SWS ’05), S. org/10.1145/1103022.1103026.

20–27.

Online

verfügbar

unter

97 http://doi.acm.

[9] M. Jackson; S. Crouch; R. Baxter (2011): Mike Jacks on, Steve Crouch and Rob Baxter. Software Evaluation: Criteria-based Assessment. Hg. v. The University of Edinburgh. The Software Sustainability Institute. Online verfügbar unter http://software.ac. uk/sites/default/files/SSI-SoftwareEvaluationCriteria.pdf.

Teil IV: Technisches Programm

Introduction to MAR Principle: A Log-based Approach towards Enhanced Security in Cloud Sai Manoj Marepalli

Razia Sultana

Andreas Christ

University of Applied Sciences Offenburg Badstrasse 24, 77652 Offenburg [email protected]

University of Applied Sciences Offenburg Badstrasse 24, 77652 Offenburg [email protected]

University of Applied Sciences Offenburg Badstrasse 24, 77652 Offenburg [email protected]

Abstract: Data is ever increasing in the computing world. Due to advancement of cloud technology the dynamics of volumes of data and its capacity has increased within a short period of time and will keep increasing further. Providing transparency, privacy, and security to the cloud users is becoming more and more challenging along with the volume of data and use of cloud services. We propose a new approach to address the above mentioned challenge by recording the user events in the cloud ecosystem into log files and applying MAR principle namely 1) Monitoring 2) Analyzing and 3) Reporting.

1

Introduction

Cloud computing is a next generation computing architecture of IT enterprises, due to its promise of helping enterprises and their IT departments to be more agile, efficient and cost-effective. Today, most of the small, medium and high level enterprises are adopting OPEX (Operational Expenditure) as their business model i.e. using this model cloud users can use a shared pool of cloud computing infrastructure and pay as he/she uses it, [1] according to Khajeh-Hosseini with usage of the OPEX model, an enterprise can save 37% of its cost over 5 years and also enterprise can eradicate 21% of the support calls.

102

Marepalli, Sultana, Christ

Figure 1: Different Cloud users outsourcing their data to Cloud Storage at CSP (Cloud Service Provider)

Figure 1 explains how different cloud users are, outsourcing their critical data information to the CSP cloud data storage. Cloud users can be any organization e.g. (Software, Health care, Aviation, Education, etc.), users may be connecting through desktop, or mobile users connecting through mobile devices (such as Tablet, Mobile Phone, Smart Phone, etc.) all these different users outsource their critical information in to the CSP's data storage. As cloud computing emerges it also gets a hold on myriad security and privacy challenges due to overblown by velocity (the rate of data generation and transmission), volume (the amount of data) and variety (types of structured or unstructured data) of data[2]. Computer Security Alliance (CSA) in a research report stated that everyday human beings generate 2.5 quintillion bytes of data [3], 90% of the data in the world today is created in last two years alone. Now the question is whether the data is secured or not? Is there any standard mechanism to investigate criminal activity occurred within cloud ecosystem (forensic analysis)? According to the report of Federal Bureau of Investigation (FBI) the size of the average digital forensic case is growing by 35% per year in the United States, from 2003 to 2007. [4] From the above mentioned reasons we can derive that, there should be some new mechanisms which can analyze the security and forensic issues in a better and efficient way compared to traditional mechanisms.

A Log-based Approach towards Enhanced Security in Cloud

103

In this paper we introduce a new approach which contributes to solve some of the relevant security and privacy issues in the cloud. As scope of this approach it is necessary to mention that the principle named MAR is still a theoretical proposal, implementation and test yet to be done. Since volume of data to be processed by the system is huge, it is advantageous to use Big Data Analysis technology to handle the challenge efficiently.

2

Problem Statement

Data is escalating every day, challenges involved here are 1) how to monitor the huge data, 2) monitor vulnerable cloud management interface, 3) know whether CSP follows the regulatory compliance and access control mechanism specified by the enterprise or not 4) is enterprises/users data in cloud ecosystem really safe? [5] We further understand the traditional and cloud architectures to find how problem actually started. 1. In-house(e.g. Traditional) In traditional computing architecture data/application reside within organization premise and quantity of data is always minimal, so monitoring for theft of data or un-authorized access towards the application can be indentified easily by using fewer security tools 2. Public (e.g. Cloud) In cloud architectures every single instance of cloud application is mapped to multiple tenants who access the resource parallel and persist huge amounts of data into the cloud servers located in multiple locations Identifying the theft and unauthorized access in cloud architectures are difficult for the reason of huge volumes of data, and located in different locations. Challenges can be overcome through MAR-Principle 1. Monitoring: recording all the user events through log files 2. Analyzing: analyzes log records and extracts information out of it and correlates with the rules defined by the organization 3. Reporting: if any misbehavior found/occurred informs to the user MAR principle is used in the architecture to solve above mentioned challenges in the cloud ecosystem.

104

3

Marepalli, Sultana, Christ

System Overview

MAR principle can be seamlessly integrated within the cloud ecosystem using existing technologies. The overview of the integration can be depicted as the below stated flow chart shown in Figure 2.

Figure 2: Logging system overview from the sources till the reporting

Log Sources (such as Applications, Networks, Computing Servers, Storage, etc), uses Apache Flume to record all the generated log entries and persists them in HDFS (Hadoop Distributed Filesystem). A detail explanation could be found in 3.1 Monitoring. In this project log data comes from everincreasing number of diverse information sources. For extracting information from those generated log entries, Big Data analysis is a suitable approach. One of the open source Big Data tool for processing large data sets is Hadoop [8], which is a batch data processing system that processes enormous amounts of data. Among plenty of advantages of Hadoop one should be mentioned that makes it more suitable for the project is “it processes the user-provided logic on the machine where the data lives rather than dragging the data across the network”. As soon as Hadoop finishes the process of extracting information, it passes collected information and control to Behavioral Analysis. First task performed in Behavioral Analysis is learning the user patterns from the extracted information. A detail explanation could be found in 3.2 Analyzing followed by 3.3 Reporting.

A Log-based Approach towards Enhanced Security in Cloud

3

105

Proposed Solution

In this section, architecture is proposed where MAR principle was followed Figure3.

Figure 3: Proposed cloud monitoring, analyzing, and reporting ecosystem for advance security measures

The architecture is mainly divided into three parts 1. Monitoring 2. Analyzing 3. Reporting Advantages provided by the proposed architecture can be mentioned in 5 major points 1. Resource Management: Keeps track of all available resources in the cloud space, and provides response to the users when requested (e.g. Enterprise Applications, Infrastructure, Network, etc.) 2. Log Manager: Records all the events occurred in the cloud ecosystem in a centralized storage, for monitoring thefts and forensic analysis 3. Policy Manager: Converts the regulatory compliance (such as HIPPA, FISMA, etc), and organization specific access control mechanism into a rule based structure

106

Marepalli, Sultana, Christ

4. Behavioral Analysis: Correlates between the defined organization rules and extracted meaning of the log records, through this it identifies the threat profile of the cloud ecosystem 5. Alert Notifier: Notifies status information of the cloud ecosystem to the cloud user, if system is behaving normal or abnormal

3.1 Monitoring This is the first part of the proposed architecture; the exponential growth in number of processors’ and transistor described by Moore’s law [6], similar way can also be applied to the data escalating in cloud ecosystem. Providing security to the persisted huge volumes of data with the traditional security systems is a complicated task. This paper introduces a new approach to this challenge with the log entries. Cloud ecosystem produces millions of log entries per day [7]. This creates a barrier to efficiently extract useful information, and to find if any malicious user/vulnerabilities effecting the cloud ecosystem. New Big Data technology can help in speeding up the process of extracting useful information from the generated log entries, such as Hadoop ecosystem which is a library framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models [8]. This technology can improve the process of monitoring the large sets of log data and help enterprises to build a secured monitoring system. The components of the monitoring system are 1. Log Manager 2. Policy Manager 3.1.1 Log Manager Records all the user interactions carried inside the cloud ecosystem into a log files and transports these log records into a centralized Data collector. Figure 4 an example shows how a simple web application records user events into a log file. After collecting log files a demon process can structure the log files by: 1. converting into a common format 2. discarding unwanted data inside log records 3. dividing log records according to time/date/event/... 4. transforming log records into a rule structure, and name it as Log Rules (LR)

A Log-based Approach towards Enhanced Security in Cloud

107

Figure 4: Architecture for recording Log events in a web application

Apache Flume [9] is an open source API which simplifies the process of collecting and aggregating large amounts of log data into a centralized repository as shown in Figure 5

Figure 5: Logs collected from hundreds of web servers sent to a dozen of agents that write to Hadoop Distributed File System (HDFS) cluster

As shown in Figure 5 a data center holds multiple web servers, these are the sources where log files are generated upon user requests/events to the enterprise application. All these generated logs/events are consumed by the Flume sources in a format that it is recognized by the target Flume sources. When

108

Marepalli, Sultana, Christ

Flume sources receives an event, it stores it into one or more channels as shown in Figure 5, the channel is a passive store that keeps the event until it's consumed by a Flume sink. Sink then removes the event from the channel and persist it into an external repository like Hadoop Distributed File System (HDFS) as shown in Figure 5. How long does the log file will be kept? This issue has still to be investigated in a further step in more detail to optimize the concerns related to both the IT security and private issues, otherwise long term storage of log files could be another target of potential IT security violations. 3.1.2 Policy Manager Consist Policy Engine shown in Figure 3, this component converts regulatory compliance (such as HIPPA, FISMA, etc [10]), and organization specific access control mechanism (such as Service Level Agreement (SLA) or Policies) into a rule based structures these structures are named as Policy Rules (PR). PR's are mapped to the organization specific instance by policy reflection. This can leverage organization instance to control according to their defined rules. Schematic Description of policies: Typical access control mechanism provided by the organization/enterprise policy can be,

1. Alice and Bob are login IDs of users who are allowed access to the LOGISTIC file see Figure 6 for clear understanding 2. Accountant and payment are the groups where Alice and Bob are belong to 3. r and w indicate the type of access allowed. r means the user can only read e.g. LOGISTIC file, w means user can also change it

A Log-based Approach towards Enhanced Security in Cloud

109

Figure 6: Access control mechanism specified in the organization policy for a particular file

Policy engine further has to convert this policy to rule which then maps it with the cloud instance so that the restrictions'/features specified in the policies are mapped to cloud applications. Rule can be in program/script structures, this is according to the CSP customization, a typical Java program rule structure is shown in Table 1. Public boolean verifyPermisions(String userAccessed, String groupdID){ if(userAccessed.equals("Alice") && groupID.equals("accountant")){ // grant permission to read Logistic file } else if(userAccessed.equals("Bob") && groupID.equals("payment")){ // grant permission to read and write Logistic file } else { //ignore the requests } } Table 1: Policy rule structure in a Java program

Further rule structures are classified and tagged into patterns, which are used in correlating and training of the cloud ecosystem.

110

Marepalli, Sultana, Christ

3.2 Analyzing After monitoring the next step of the architecture is to analyze, and this is the second part of our proposed architecture. Job of analyzing system is done in two different phases 1. Correlating, in this phase algorithm correlates between the defined rules (such as Policy Rules e.g. regulatory compliance) and Log Rules (LR) generated upon user request to the cloud ecosystem, and then verifies whether organization instance in the cloud ecosystem pursue the organization specific rules or not 2. Training, is a self learning algorithm trains the system with new access patterns of the user through log files, and it understands if and all any access pattern tries/attempts to exploit the vulnerability of the cloud ecosystem then it denies or reports to the cloud admin/user. We further categorized the classes of behavior of the cloud ecosystem into 1. Normal behavior class (as stable state) 2. Confidential Behavior class (special permission acquired by admin in this state) 3. Un-authorized behavior class (Anonymous person accessing the system without proper privileges is in this state) According to the class of the system and security settings it notifies the cloud user/admin Analyzing possibly will not be an easy task because, enterprises like Hewlett-Packard (HP) in a report whispered, in 2013 HP enterprise generated 1 trillion events per day, or roughly 12 million events per second [3]. So the process of Correlating and Training requires a specialized tool such as Big Data [11].

3.3 Reporting After monitoring and analyzing next step is to report the right user on right time, this is the responsibility of the third part of the architecture named Reporting. As shown in Figure 3 this step 1. provides forensic evidences in case of any theft occurred in the cloud ecosystem 2. reports timely to the cloud user/admin in case of any theft or vulnerabilities in application, inside the cloud ecosystem Reporting may not be as easy task as we expected. If data/applications at CSP's end are spreaded in different locations managing their own events,

A Log-based Approach towards Enhanced Security in Cloud

111

alerts, notifications, etc and providing instantaneous reports; without having proper infrastructure and control over the complete system it will not be possible to send useful report to the enterprises/cloud users. Further research is necessary to have better understanding of the problem so that a suitable solution can be provided.

4 Related Works (Ashish Gehani, et. al) called for a proactive collection of forensic evidence which is then examined to identify criminal activity. This approach proactively collects potential forensic evidences through quantified volume of evidences [12], which is for sure address potential threats but vulnerable applications are unpredictable, unpredictable threats are dangerous and harms the cloud ecosystem, our approach is more on finding unpredictable threats and try to avoid them. Shams Zawoad, et. al introduced Secure-Logging-as-a-Service (SecLaaS), which stores virtual machines’ logs and provides access to forensic investigators ensuring the confidentiality and integrity of the cloud users, this work focused on preserving privacy of users log and avoids tampering or manipulating the log files [13]. Ting Sang, proposed an approach which uses logbased model for building a forensic-friendly system, also for non-repudiation of behaviors on cloud [14]. Jia Li, introduced a Web log mining process to analyze the users behaviors [15]. All the aforementioned works are extracting information through log mining/modeling/analysis to perform forensic analysis of the cloud ecosystem. Our approach to the problem introduced in the problem statement is by dividing the log analysis into two phases 1) Correlating and 2) Training, the advantage of using this process is, in the first phase user behavior is verified with the organization specific policies or SLA (Service Level Agreement). In the second phase system learns the user behavior through user events, and responds to the cloud user/admin if any malicious user effecting the system.

5 Conclusions The big challenge of monitoring, analyzing and reporting of cloud ecosystem is fairly complicated task, due to its acceleration of information/data. The new Big Data analytic tools can leverage to improve the process of analyzing and reporting. But there are some open issues that need to be addressed 1) monitoring and understanding huge unstructured data, 2) processing the data and reporting right time to the right person, 3) storing and retaining

112

Marepalli, Sultana, Christ

large quantities of log data 4) preventing any kind of unauthorized access to the system etc. Unauthorized users can access the virtual machine via ssh is an example of unauthorized access, which is an important topic for the overall cloud IT security and has to be investigated additionally. Right now that does not fall under the scope of this paper. The proposed approach has taken under consideration all these above mentioned open issues. Still the architecture is under development phase so performance test is yet to be done. When critical information of users'/enterprises' is outsourced into the cloud, it is the responsibility of cloud providers (CSP) to provide transparency, privacy, and security. This approach aims for a better trust worthy relationship between CSP and cloud users/enterprises and offers a greater potential for education and national as well as international cooperation.

References [1]

A. Khajeh-Hosseini, D. Greenwood, and I. Sommerville. Cloud Migration: A Case Study of Migrating an Enterprise IT System to IaaS. In: at - 3rd International Conference on Cloud Computing (CLOUD '10). vol., no., pp.450,457, 5-10. (Conference Proceedings)

[2]

D. Laney: META Group: Application Delivery Strategies: (2001), file no: 949 URL: http://blogs.gartner.com/doug-laney/files/2012/01/ad949-3D-Data-ManagementControlling-Data-Volume-Velocity-and-Variety.pdf

[3]

Cloud Security Alliance: Big Data Analytics for Security Intelligence. (2013). (Research Article)

[4]

FBI: Regional Computer Forensics Laboratory annual Report for Fiscal year 2007. URL:http://www.rcfl.gov/downloads/documents/RCFL_Nat_Annual07.pdf [Accessed 23.12.2013]. (Internet)

[5]

M. Sai Manoj, R. Sultana, A. Christ: The challenges of collaborative learning in cloud and a three layered architecture towards the solution. In: at - The Society of Digital Information and Wireless Communications (SDIWC). (2013). (Conference Proceedings)

[6]

Wikipedia: Moore's Law URL: http://en.wikipedia.org/wiki/Moore's_law [Accessed 25.01.2014]. (Internet)

[7]

S. Thorpe, T. Grandison, A. Campbell, J. Williams, and K. Burrell I. Ray: Towards a Forensic-Based Service Oriented Architecture Framework for Auditing of Cloud Logs. In: at - Services (SERVICES). (2013) vol., no., pp.75,83

[8]

Apache Hadoop: An open-source software framework for storage and large scale processing of data-sets. URL: http://hadoop.apache.org/ [Accessed 20.01.2014]. (Internet)

[9]

Apache Flume: Collects, aggregates, and moves large amounts of log data URL: http://flume.apache.org/index.html [Accessed 20.12.2013]. (Internet)

[10] M. K. Srinivasan, K. Sarukesi, P. Rodrigues, M. Sai Manoj, and P. Revathy: State-ofthe-art cloud computing security taxonomies: a classification of security challenges in

A Log-based Approach towards Enhanced Security in Cloud

113

the present cloud computing environment. In: at - International Conference on Advances in Computing, Communications and Informatics (ICACCI '12). vol., no., pp. 470-476. (Conference Proceedings) [11] C. Li, Z. Deng: Value of Cloud Computing by the View of Information Resources. In: at - Network Computing and Information Security (NCIS). (2011) vol.1, no., pp.108,112, (Conference Proceedings) [12] A. Gehani, G.F. Ciocarlie, and N. Shankar: Accountable clouds. In: at - Technologies for Homeland Security (2013) vol., no., pp.403,407. (Conference Proceedings) [13] S. Zawoad, A. K. Dutta, and R. Hasan: SecLaaS: secure logging-as-a-service for cloud forensics. In: at - SIGSAC symposium on Information, computer and communications security (ASIA CCS '13). vol., no., pp. 219-230. (Conference Proceedings) [14] T. Sang: A Log Based Approach to Make Digital Forensics Easier on Cloud Computing. In: at - Intelligent System Design and Engineering Applications (ISDEA). (2013). vol., no., pp.91,94 (Conference Proceedings) [15] J. Li: Research of Analysis of User Behavior Based on Web Log. In: at - Computational and Information Sciences (ICCIS), (2013) vol., no., pp.601,604, 21-23 (Conference Proceedings)

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living Carina Fredrich, Hendrik Kuijs, Christoph Reich Fakultät Informatik Hochschule Furtwangen Robert-Gerwig-Platz 1 78120 Furtwangen Email {Carina.Fredrich, Hendrik.Kujis, Christoph.Reich}@hs-furtwangen.de Abstract: In diesem Paper präsentieren wir eine Plattform, die älteren Menschen Unterstützung bei der Kommunikation, Informationsbeschaffung und beim Lernen bietet. Sie ermöglicht es älteren Menschen länger in ihrer gewohnten Umgebung zu Hause bleiben zu können und fördert die soziale Integration trotz oft auftretender mangelnder Mobilität. Durch die in diesem Paper beschriebene benutzerzentrierte Ontologie ist eine optimale Personalisierbarkeit des User Interfaces und der Funktionalitäten möglich. Die Ontologie bietet dabei viele Vorteile, wie eine historische Betrachtung der Kontextinformationen, Agentenkommunikation oder Erweiterbarkeit.

1 Einführung Viele Entwicklungen im Bereich Ambient Assisted Living (AAL) lösen Problemstellungen im Bereich der Hausautomatisierung, der Barrierefreiheit oder des Erkennens von Notsituationen wie in [1], [2] und [3]. So wird es älteren Menschen ermöglicht, länger zu Hause bleiben zu können. Oft kommt jedoch noch ein anderes Problem dazu: mangelnde soziale Integration. Diese tritt häufig dann auf, wenn die Mobilität der älteren Menschen eingeschränkt ist und diese nicht mehr regelmäßig am öffentlichen Leben teilhaben können. Um diesem Problem entgegenzuwirken, reichen Lösungen in den oben genannten Bereichen nicht aus. Hierfür werden Systeme benötigt, die personalisiert die Kommunikation mit anderen Menschen fördern und dem Benutzer Informationen aus seiner sozialen Umgebung zugänglich machen. Das Forschungsprojekt PCEICL (Person Centered Environment for Information Communication and Learning) hat die Entwicklung einer altersgerechten Plattform zum Ziel, die ältere Menschen bei der Informationsbeschaffung, bei der Kommunikation und beim Lernen unterstützt, um länger zu Hause leben zu können und gleichzeitig sozial integriert zu bleiben. Aufgrund von gesundheitsbedingten Einschränkungen ist es absolut notwendig das User Interface aber auch die Funktionalitäten, die ein AAL-System bietet, auf die Bedürfnisse des Benutzers anzupassen [4]. Um diese Personali-

116

Fredrich, Kuijs, Reich

sierung zu erreichen, nutzt die PCEICL-Plattform Kontextinformationen, die durch eine Ontologie modelliert werden. Die meisten AAL-Systeme betrachten lediglich die Umgebung des Benutzers und lassen dabei den Benutzer selbst außer Acht. Die PCEICL-Plattform dagegen sieht den Benutzer und seine Bedürfnisse als zentrale Kontextinformation, betrachtet gleichzeitig aber auch seine Umgebung.

2 Verwandte Arbeiten Grundsätzlich werden Ontologien zur Kontextmodellierung vor allem im Bereich Ambient Assisted Living sehr häufig verwendet. Doch nur in wenigen dieser Arbeiten wird Kontext als der Benutzer und seine Eigenschaften verstanden. Hier liegt der Fokus oft auf der Umgebung des Benutzers. Im Rahmen des Projekt SOPRANO (Service Oriented PRogrammable smArt enviroNments for Older Europeans)[1] wurde eine offene Middleware für AAL-Lösungen entwickelt. Die SOPRANO Ambient Middleware (SAM) empfängt Benutzerbefehle oder Sensordaten, reichert diese semantisch an und ermittelt eine passende Systemantwort. Diese wird dann über die im Wohnumfeld des Benutzers installierten Aktoren ausgeführt. Die Komponenten von SAM kommunizieren auf Basis einer gemeinsamen Domänenontologie. Diese Ontologie ist „Status-zentriert“, was bedeutet, dass jedes Konzept der Ontologie (Geräte, Personen, Orte, etc.) durch seinen aktuellen Status repräsentiert wird. Die PCEICL-Plattform dahingegen ist benutzerzentriert. Sie kann daher den Benutzer und seine Eigenschaften sehr viel detaillierter beschreiben. Da die Zentralisierung des Benutzers Ziel der PCEICL-Plattform ist, ist es nicht sinnvoll die SOPRANO-Ontologie zu verwenden. Ein anderes Beispiel für die Fokussierung auf die Umgebung des Benutzers ist PersonisAD, das in [5] von M. Assad etal. vorgestellt wird. Einige Informationen über den Benutzer, wie beispielsweise seine Vorlieben, werden hier zwar auch betrachtet, sind aber nicht detailliert genug, um eine gute Personalisierung für ältere Menschen zu erreichen. Das universAAL (UNIVERsal open platform and reference Specification for Ambient Assisted Living) [6] Projekt versucht verschiedene Ansätze aus unterschiedlichen Projekten zu einer einheitlichen AAL-Lösung zusammenzuführen. Eines dieser Projekte ist SOPRANO. Das Ziel von universAAL ist es, eine offene Plattform zu schaffen, die das Entwickeln von AAL-Services rentabel machen soll. Im Rahmen des Projekts sollen Standards für den AAL-Bereich entwickelt werden, die möglicherweise für zukünftige Arbeiten des PCEICL-Projekts genutzt werden könnten.

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

117

Das Projekt MobileSage [7][8] entwickelt einen Smartphone-basierten „Help-On-Demand“-Service, durch den kontextsensitive, personalisierte und lokationsabhängige Dienste angeboten werden können. Solche Dienste können ältere Menschen bei der Navigation, beim Bedienen von Geräten wie Ticket-Automaten und Haushaltsgeräten oder bei der Bewältigung alltäglicher Aufgaben unterstützen. Die Personalisierung und Kontextsensitivität wird durch eine Ontologie realisiert, die nicht nur die Umgebung des Benutzers betrachtet. In dieser Ontologie spielender Benutzer und seine Eigenschaften eine ebenso wichtige Rolle. Der Benutzer wird durch sein Profil beschrieben, welches in Teilprofile, wie ein Interessenprofil oder ein Gesundheitsprofil, untergliedert wird. Trotz dessen liegt der Fokus bei MobileSage mehr auf dem Umgebungskontext, um dem Benutzer beispielsweise Location Based Services (LBS) anbieten zu können. Das PCEICL-Projekt legt den Fokus dagegen mehr auf mobil eingeschränkte Personen, die an ihre häusliche Umgebung gebunden sind und versucht diese bei der Kommunikation, der Informationsbeschaffung und beim Lernen zu unterstützen. Um hier eine gute Personalisierung bieten zu können, muss der Benutzer mit seinen Eigenschaften detaillierter beschrieben werden. Da aber beide Ontologien ein Benutzerprofil modellieren, gibt es viele ähnliche Konzepte. Eine weitere Ontologie, die ein Benutzerprofil im Bereich Ambient Assisted Living modelliert, ist AALUMO. Sie wird in [9] von P.A. Moreno, M.E. Hernando und E.J. Gómez beschrieben und stellt eine Erweiterung von GUMO (General User Model Ontology) [10], einer Ontologie zur allgemeinen Nutzung innerhalb vieler Anwendungsgebiete, dar. GUMO beschreibt den Benutzer sehr detailliert von seinen Herzschlägen über den emotionalen Zustand zu seinen Interessen und seinen persönlichen Informationen. AALUMO erweitert GUMO um Konzepte wie beispielsweise chronische Krankheiten, um eine bessere Adaption an die besonderen Eigenschaften älterer Menschen zu erreichen. Durch die PCEICL-Ontologie sollen dagegen nur die Informationen gespeichert werden können, die auch wirklich für eine optimale Personalisierung der Services notwendig sind. Hierbei spielen die Herzschläge oder der emotionale Zustand derzeit keine Rolle und sollen daher auch nicht erfasst oder ausgewertet werden. Die Ontologie, die von M. Sutterer et al. in [11] vorgestellt wird, modelliert ein Benutzerprofil, das allerdings nicht auf die Bedürfnisse älterer Menschen angepasst ist. Die Personalisierung der Services erfolgt situationsabhängig. Dafür muss der Benutzer zu jeder möglichen Situation die von ihm bevorzugten Einstellungen angeben, die dann übernommen werden, wenn die Situation eintrifft. Dies ist sicherlich für viele ältere Menschen schwer zu realisieren und kommt daher für die PCEICL-Plattform nicht in Frage. Zusammenfassend kann man sagen, dass die PCEICL-Ontologie auf Konzepten der MobileSage-Ontologie basiert und dass für zukünftige Entwick-

118

Fredrich, Kuijs, Reich

lungen der PCEICL-Plattform die Entwicklungen des universAAL-Projekts betrachtet werden müssen.

3

Use Case

In diesem Kapitel werden die Use Cases der PCEICL-Plattform vorgestellt. Diese dienen dazu, den Nutzen der Plattform und ihrer benutzerzentrierten Ontologie aufzuzeigen. Zunächst folgt eine kurze Beschreibung des Nutzers der PCEICL-Plattform: Herr F. ist ein 73 Jahre alter Witwer, hat zwei Kinder und lebt allein auf einem großen Bauernhof weit außerhalb. Eines seiner Kinder lebt im Ausland und das andere in einer weit entfernten Großstadt. Dadurch können sie ihren Vater nur sehr selten besuchen. Herr F. ist Mitglied im Modelleisenbahnverein einer rund 30 km entfernten Stadt. Er nimmt schon seit Jahren einmal in der Woche an den Vereinstreffen teil. Seitdem er sich ein Bein durch einen Sturz auf seinem vereisten Grundstück gebrochen hat, ist er mobil eingeschränkt und kann das Haus kaum mehr verlassen. Seine Kinder machen sich Sorgen, weil seine Freunde und Vereinskameraden wenig Zeit haben, Herrn F. zu Hause zu besuchen. Die PCEICL-Plattform unterstützt Herrn F. bei seinen täglichen Aufgaben, indem sie Assistenz bei der Kommunikation, Informationsbeschaffung und beim Lernen bietet. Dadurch erhält sie seine soziale Integration trotz der mangelnden Mobilität. Besonders seine Kinder sind nun beruhigt, da sie Herrn F. jederzeit leicht erreichen können. Im Folgenden werden die Use Cases für jeden der drei Assistenzbereiche beschrieben. Sie dienen dazu, in Kapitel 6 die Vorteile der neu entwickelten Ontologie und Plattform aufzuzeigen.

3.1 Use Case:Assistenz bei der Kommunikation Jeder Kontakt in Herr F.’s Kontaktliste hat verschiedene Kommunikationskanäle, wie Telefon, E-Mail, Video-Chat, SMS, etc., festgelegt, über die er erreichbar ist. Zusätzlich haben die Kontakte Angaben über die Erreichbarkeit über die verschiedenen Kommunikationskanäle gemacht, ausgehend von ihren täglichen Gewohnheiten und Terminen. Dabei wird vorausgesetzt, dass jeder Kontakt zu jedem Zeitpunkt in Notsituationen über mindestens einen Kanal erreicht werden kann. Angenommen Herr F. möchte mit einem seiner Kinder kommunizieren, dann muss er lediglich den Namen des Kindes aus seiner Kontaktliste auswählen. Daraufhin wählt die PCEICL-Plattform au-

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

119

tomatisch den Kommunikationskanal, der von seinem Sohn für diese Zeit angegeben wurde, also z.B. SMS, weil sein Sohn beschäftigt ist.

3.2 Use Case: Assistenz bei der Informationsbeschaffung Eine andere Applikation der Plattform hilft Herrn F. dabei, Hilfe und Unterstützung von anderen Menschen aus seiner Umgebung zu finden. Obwohl er keine aktive Landwirtschaft mehr betreibt, hat er viele Dinge wie beispielsweise das Füttern der Hasen, das Rasen Mähen, das Einkaufen, das Putzen des Hauses und verschiedene Reparaturen, die erledigt werden müssen. All diese Aufgaben sind für eine mobil eingeschränkte Person nur sehr schwer oder gar nicht zu bewältigen. Wenn Herr F. Hilfe benötigt wird er hierbei von dem Service der PCEICL-Plattform unterstützt. Dadurch dass die Plattform den Gesundheitszustand des Benutzers kennt, kann sie automatisiert einen „Suche/Biete“-Service zur Verfügung stellen. Dabei kann sowohl nach regelmäßiger Unterstützung z.B. im Haushalt als auch nach einmaliger Unterstützung gesucht werden. Wenn beispielsweise ein Vereinstreffen ansteht, an dem er gerne teilnehmen würde, kann das System automatisch aufgrund seines gebrochenen Beins nach einer Mitfahrgelegenheit suchen. Verschlechtert sich sein Gesundheitszustand, kann das System die Mitfahrgelegenheit automatisch und rechtzeitig absagen. Durch die zusätzliche Kenntnis des Systems über die Umgebung des Benutzers, also z.B. das Wetter, kann auch situationsbedingte Hilfe automatisch organisiert werden, wie z.B. Hilfe beim Schnee Räumen.

3.3 Use Case: Assistenz beim Lernen Das Fitness-Programm der PCEICL-Plattform nutzt Herr F. jeden Tag undleitet ihn bei seinen täglichen Fitness-Übungen an. Durch die Änderung seines Gesundheitszustands vermeidet das Programm automatisch Übungen, die mit seinem gebrochenen Bein nicht möglich sind und fügt andere Übungen z.B. für das Training der Arme hinzu, um möglichst das gleiche FitnessLevel zu erreichen. Mit der Zeit verheilt sein Bein und das Programm bietet ihm automatisch Übungen für sein Bein an, um seine Mobilität langsam wiederherzustellen.

4 PCEICL Plattform Die PCEICL-Plattform ist, wie in Abbildung 1 dargestellt, als „OSGi Platformas a Service“ (OSGi-PaaS) innerhalb einer Cloud-Infrastruktur realisiert. Die Vorteile dieses Ansatzes liegen in der guten Skalierbarkeit durch die PaaS-Technologie und in der einfachen Erweiterbarkeit durch den OSGi-

120

Fredrich, Kuijs, Reich

Bundle Mechanismus. Dadurch können bestehende Bundles aus dem AALBereich leicht integriert werden. Innerhalb der PCEICL-Plattform gibt es neben einfachen Bundles, spezielle Agenten-Bundles, die es ermöglichen, intelligentes Verhalten zu entwickeln. Durch diese Bundles ist es möglich eine Kommunikation über ACL (Agent Communication Language [12]) zwischen den Agenten zu realisieren. ACL legt den Einsatz von Ontologien fest, was durch die PCEICL-Ontologie realisiert wird. Für die Entwicklung der Software-Agenten wurde JADE (JavaAgent DEvelopment Framework [13]) verwendet, da es weit verbreitet ist und schon als OSGi-Bundle angeboten wird.

Abbildung 1: Die PCEICL-Plattform

Der Vertrieb, die Installation und das Deployment der PCEICL-Services werden über einen OSGi-Bundle-Store (siehe Abbildung 1) realisiert, der sich an den bekannten App-Stores für Smartphones oder Betriebssysteme orientiert. Die Services können von dem Nutzer selbst, einer Assistenzperson, einem Verwandten oder auch von dem System selbst ausgewählt werden, um automatisch Services zu aktualisieren oder auch um Services passend zu den Bedürfnissen (z.B. Interessen oder Vorlieben) des Benutzers zur Installation vorzuschlagen. Das Profil und die Umgebung des Benutzers werden durch die PCEICLOntologie modelliert. Sie beinhaltet alle Informationen über die Person und ihre relevante Umgebung, die benötigt werden, um die PCEICL-Services und Applikationen optimal an die Bedürfnisse der Person anzupassen. Das gespeicherte Profil wird durch den Context Management Agent der PCEICLPlattform (siehe Abbildung 1) verwaltet. Er entscheidet, welcher Service

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

121

welche Informationen über den Benutzer erhält. Aufgrund des Prinzips der Minimierung privater Daten, sollte nicht jeder Service alle Informationen erhalten. Beispielsweise sollte ein Kommunikationsdienst, der lediglich Audio- und Video-Anrufe anbietet, keine Informationen über den Gesundheitszustand des Benutzers, dafür aber Informationen über die Kontakte, die optimale Lautstärke oder mögliche Farben des User Interfaces bekommen. Innerhalb der PCEICL-Plattform gibt es außerdem spezielle Agenten-OSGiBundles, die für die drei Assistenzbereiche Kommunikation, Information und Lernen zuständig sind. Sie realisieren mit Hilfe der durch den Context Management Agent zur Verfügung gestellten Kontextinformationen die Unterstützung des Benutzers in den drei Bereichen.

5 PCEICL-Ontologie Für eine optimale Personalisierung des PCEICL-Systems muss der Benutzerkontext modelliert, eine semantisch gestützte Kommunikation zwischen den Agenten realisiert, die Informationen semantisch miteinander verknüpft und Regeln über die Nutzung der einzelnen Informationen aufgestellt werden. Daher wurden die Kontextinformationen und die von ACL benötigte Ontologie als PCEICL-Ontologie modelliert. Sie ermöglicht es, die Beziehungen zwischen den einzelnen Informationen zu beschreiben und neue Daten aus den gegebenen Informationen abzuleiten. Wenn das System beispielsweise über den Gesundheitszustand des Benutzers informiert ist, können ein Teil seiner Fähigkeiten und Einschränkungen daraus abgeleitet werden. Die PCEICL-Ontologie dient als Basis zur Speicherung und Interpretation von Kontextinformation und beschreibt primär den Benutzer und seine Eigenschaften aber auch seine Umgebung. In Abbildung 2 ist eine Übersicht über die Hauptkonzepte der Ontologie dargestellt. Eine detaillierte Beschreibung kann in [14] eingesehen werden.

5.1 Wichtige Konzepte der PCEICL-Ontologie Zusätzlich zu den obligatorischen Benutzerdaten wie den persönlichen Informationen (Name, Adresse, Geburtsdatum, Kontaktinformationen, etc.), beinhaltet die Ontologie auch speziellere und komplexere Konzepte wie Interessen, Vorlieben, Fähigkeiten oder auch den Gesundheitszustand. Viele der Ontologie-Klassen sind definierte Klassen, die die Properties definieren, die eine Instanz dieser Klasse haben muss. Das führt zu einer besseren Konsistenz der Daten.

122

Fredrich, Kuijs, Reich

Abbildung 2: Überblick über die Hauptkonzepte der PCEICL-Ontologie

Die zentrale Rolle des Benutzers spiegelt sich in der zentralen Klasse User wieder, da sie über Properties zu jeder anderen Hauptklasse der Ontologie in Verbindung steht (siehe Abbildung 2).Die Klasse User ist von der Klasse Person abgeleitet, dessen Instanzengenau eine ID und genau eine PersonalInformation besitzen müssen. So wird sichergestellt, dass jede Person eindeutig beschrieben wird.

Abbildung 3: Klasse Person

Für die Kommunikationsassistenz ist es notwendig eine Kontaktliste zu haben. Die Kontakte werden durch die Klasse Contact repräsentiert, die ebenfalls eine Unterklasse der Klasse Person darstellt. Zusätzlich zu einer ID, den persönlichen Informationen und Fotos besitzen Instanzen der Klasse Contact eine Kategorie. So ist es möglich die Beziehungen zwischen dem Benutzer und dem Kontakt zu beschreiben und beispielsweise zwischen Familienmitgliedern und Ärzten unterscheiden zu können. Die Klasse Education bietet lediglich die Möglichkeit Fremdsprachen, die der Benutzer spricht, und Informationen über den Lernfortschritt zu spei-

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

123

chern. Andere Informationen über die Bildung des Benutzers sind derzeit nicht relevant, können aber gegebenenfalls leicht ergänzt werden. Die Interessen werden durch die Klasse Interest repräsentiert. Um zwischen passiven Interessen wie Sport im Fernsehen anschauen und aktiven Interessen wie Sport betreiben unterscheiden zu können, wurde zusätzlich die Klasse Activitiy modelliert. In Abbildung 4 ist das Konzept der Klasse Interest dargestellt, welches identisch ist zu dem der Klasse Activity. Zusätzlich zum Namen und Typs der Interesse oder Aktivität ist es möglich, spezifischere Informationen wie Webseiten, Fotos oder Beschreibungen zu speichern (Klasse AdditionalInformation). Außerdem sollte jede Instanz der Klassen Interest und Activity eine Property hasLevel haben, die beschreibt wie sehr jemand Interesse an etwas hat.

Abbildung 4: Klasse Interest

Persönliche Vorlieben, wie die Lieblingsfarbe oder die bevorzugte Musikrichtung werden durch die Klasse PersonalPreference abgebildet. Sie ist gleich aufgebaut wie die Klasse Interest und ist wie die Klasse SystemPreference abgeleitet von der Klasse Preference. Die Klasse SystemPreference stellt dagegen die bevorzugten Systemeinstellungen dar, wie z.B. Schriftgröße, Lautstärke oder Farben. Viele der Systemeinstellungen können direkt aus anderen Informationen abgeleitet werden. So werden beispielsweise die Farben Rot und Grün bei einer Rot-Grün-Sehschwäche vermieden oder die Basislautstärke bei einer Schwerhörigkeit erhöht. Die Klasse Capability unterteilt sich in die Klassen CognitiveCapability und PhysicalCapability, die wie die Klasse Interest aufgebaut sind. Die körperlichen und geistigen Fähigkeiten und Einschränkungen, die durch die entsprechenden Klassen gespeichert werden können, können ebenfalls zum Teil von den Gesundheitsinformationen abgeleitet werden.

124

Fredrich, Kuijs, Reich

Abbildung 5: Klasse HealthCondition

Die Klasse HealthCondition (siehe Abbildung 5) beinhaltet die wohl wichtigsten Informationen über den Benutzer. Durch das Wissen über den Gesundheitszustand des Benutzers kann die PCEICL-Plattform und ihre Services optimal personalisiert werden. Jede Instanz der Klasse beschreibt eine Krankheit oder Einschränkung. Hier können Angaben zur Medikamentierung oder auch zum behandelnden Arzt gemacht werden. Jede Krankheit oder Beeinträchtigung kann über die Property hasLevel eingestuft werden. So können darüber z.B. die Dioptrien bei einer Sehschwäche oder der Fortschritt einer Krankheit gespeichert werden. Damit die Krankheiten einheitlich und medizinisch korrekt beschrieben werden, kann zu jeder Instanz der Klasse HealthCondition ein ICD-Code abgelegt werden. ICD bedeutet International Statistical Classification of Diseases and Related Health Problems Code [12] und ist eine weltweit eingesetzte und anerkannte Codierung von Diagnosen. Insgesamt wird so eine einheitliche und medizinisch korrekte Beschreibung des Gesundheitszustands des Benutzers erreicht.

Abbildung 6: Klasse History

Die PCEICL-Ontologie bietet außerdem die Möglichkeit den Kontext historisch zu betrachten. So können beispielsweise Lernfortschritte oder Veränderungen des Gesundheitszustands beobachtet werden und das Verhalten der Services kann sich entsprechend anpassen. Dafür wurde die Klasse History modelliert, die eine ungültige Instanz einer der in Abbildung 6 aufgelisteten

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

125

Klassen nimmt und diese mit dem aktuellen Zeitstempel versieht. Hat der Benutzer beispielsweise eine Erkältung, wird diese als HealthConditionInstanz angelegt. Ist die Erkältung überstanden, wird diese Instanz mit einem Zeitstempel versehen und als History-Objekt abgelegt. Abbildung 7 zeigt ein Beispiel für einen Teil eines Benutzerprofils, das mit Hilfe der Konzepte der Ontologie beschrieben wird. Das Benutzerprofil stammt von Herrn F., der in Kapitel 3 vorgestellt wurde.

Abbildung 7: Beispiel der PCEICL-Ontologie

5.2 Nutzender PCEICL-Ontologie für die Use Cases In diesem Kapitel wird aufgezeigt, wie die Services aus den Use Cases (Kapitel 3) die Konzepte der Ontologie nutzen, um sich an den Benutzer und seine Bedürfnisse anzupassen. 5.2.1 Use Case: Assistenz bei der Kommunikation Die Kommunikations-App selbst ist nur ein einfacher Client, der lediglich die Informationen erhält, die er zur Interaktion mit dem Benutzer und zur Erfüllung seiner Funktion als Kommunikationsdienst benötigt. Dazu gehören vor allem Kontextinformationen über den Kontakt, den der Benutzer gerade erreichen möchte. Die Kontakte werden als Instanzen der Klasse Contact gespeichert und geben dort ihre zeitabhängig bevorzugten Kommunikationskanäle an. Die Kommunikations-App erhält so eine Liste der priorisierten Kanäle und kann diese wenn nötig abarbeiten. Das User Interface wird, wie bei allen Diensten, entsprechend der Informationen aus der Klasse SystemPreferences angepasst. Hier können die meisten Informationen direkt aus

126

Fredrich, Kuijs, Reich

den Angaben der HealthCondition abgeleitet werden. Gibt der Benutzer beispielsweise an, dass er an einer Rot-Grün-Blindheit leidet, können diese Farben bei der Farbwahl der GUI ausgeschlossen werden. Leidet der Benutzer an einer Hörschwäche sollte die Lautstärke nicht unter einen bestimmten Pegel fallen. Andere Informationen, die von der SystemPreferences-Klasse erfasst werden, müssen manuell eingegeben werde, wie beispielsweise bestehende Accountdaten. 5.2.2 Use Case: Assistenz bei der Informationsbeschaffung Für den Dienst, der den Benutzer bei der Informationsbeschaffung unterstützt sind primär Daten über den Gesundheitszustand des Benutzers (Klasse HealthCondition)und seine Umgebung (Klasse Environment) notwendig. Der Hauptvorteil dieses Dienstes liegt darin, dass er abhängig vom aktuellen Kontext anbietet, Unterstützung oder Hilfe bei etwas zu organisieren. Dabei kann Kontext beispielsweise das Wetter, der Gesundheitszustand des Benutzers, die Zeit oder auch Daten von Sensoren im Haus sein. Aus den Kontextinformationen, die durch die Ontologie modelliert werden, kann das System die Notwendigkeit einer Hilfsanfrage ermitteln. Damit der Dienst nicht komplett autonom handelt, wird dem Benutzer lediglich empfohlen, Hilfe anzunehmen. Er kann diese jederzeit ablehnen. Beispielsweise könnte ihm die Applikation anbieten jemanden zu suchen, der für ihn den Schnee räumt, wenn es schneit und er aufgrund seines gebrochenen Beins dazu nicht in der Lage ist. Aber auch Informationen über die Interessen (Klasse Interest) oder Aktivitäten (Klasse Activity) des Benutzers können dazu genutzt werden, ihm bei der Hilfesuche zu assistieren. Dadurch dass das System über die Vereinsmitgliedschaft im Modelleisenbahnclub (Instanz der Klasse Activity) informiert ist, kann es Herrn F. während der Zeit, in der er aufgrund seines gebrochenen Beins mobil eingeschränkt ist, anbieten, eine Mitfahrgelegenheit zu den wöchentlichen Treffen des Vereins zu organisieren. 5.2.3 Use Case: Assistenz beim Lernen Lernfortschritte aller Art also auch der Fitness-Status von Herrn F. kann über die Klasse Education festgehalten werden. Erreicht Herr F. ein neues Fitness-Level, weil er alle dafür erforderlichen Übungen erfolgreich absolviert hat, kann das über die Klasse gespeichert werden. Der gesamte Verlauf des Fitness-Zustands kann mit Hilfe der Klasse History beobachtet werden. Dadurch können zum Beispiel die Übungen angepasst werden, wenn Rückschritte beim Fitness-Zustand erkannt werden. Durch die Informationen über den Gesundheitszustand (Klasse HealthCondition) des Benutzers, können

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

127

automatisch nur solche Übungen angeboten werden, die in seinem Zustand förderlich sind oder zumindest nicht schaden.

6 Zusammenfassung In diesem Paper haben wir eine Ontologie vorgestellt, die die Basis einer kontextsensitiven Plattform darstellt. Die PCEICL-Plattform ist als OSGiPaaS realisiert und bietet die Möglichkeit JADE-Agenten für die Integration von semantischer Intelligenz durch Ontologien zu nutzen. Die vorgestellte Ontologie stellt die Basis für die Kommunikation über ACL zwischen den einzelnen Agenten dar. Zukünftig wird es einen OSGi-App-Store geben über den die Bundles, egal ob einfache OSGi-Bundles oder JADE-OSGi-Bundles, vertrieben werden können. Durch den Einsatz von Cloud-Technologien ist die Plattform flexibel und skalierbar. Die Vorteile der PCEICL-Ontologie können in 5 Punkten zusammengefasst werden: 1. Der Benutzer als zentrales Konzept: Kontextsensitivität ist eine notwendige Voraussetzung für eine optimale Assistenz für ältere Menschen. Dabei ist es wichtig, nicht nur die Umgebung des Benutzers zu betrachten sondern vor allem ihn selbst und seine Bedürfnisse. Die PCEICL-Ontologie bietet diese Nutzerzentralisierung, womit es möglich ist, personalisierte Dienste anzubieten. 2. An die Bedürfnisse des Benutzers angepasste Services: Die Dienste der PCEICL-Plattform können Informationen über die Fähigkeiten, Interessen, gesundheitlichen Einschränkungen, usw. nutzen, um das User Interface aber auch ihre Funktionalität den Bedürfnissen des Benutzers anzupassen. Beispielsweise können sie die Schriftgröße, die Lautstärke oder auch die Farben an den Zustand der Augen und Ohren des Benutzers adaptieren. 3. Historische Betrachtung: Durch die historische Betrachtung, die durch die Konzepte der Ontologie ermöglicht wird, kann das System auf Änderungen im Benutzerprofil reagieren. 4. Agentenkommunikation: Die Ontologie stellt die Basis für die Kommunikation der Agenten über ACL dar. Sie dient einem einheitlichen Verständnis und der semantisch korrekten Interpretation von Benutzerprofildaten. 5. Erweiterbarkeit: Eine einfache Erweiterbarkeit der Ontologie wird durch das zentrale Konzept User sichergestellt, da es sehr einfach ist, dem Benutzer weitere Eigenschaften hinzuzufügen. Weitere Gründe sind die hierarchische Struktur und die Wiederverwendung von Konzepten von vielen Klassen. Durch die Ontologie werden aufgrund des Datenschutzes auch nur aktu-

128

Fredrich, Kuijs, Reich

ell nützliche Daten gespeichert. Konzepte, die sich im Laufe der Zeit als zusätzlich notwendig erweisen, können leicht in die Ontologie integriert werden. Zukünftig soll eine dynamische Adaption der Ontologie während der Laufzeit auf sich ändernden Kontext realisiert werden. Einige der Kontextinformationen können automatisch erfasst und analysiert werden. Das Ergebnis dieser Analyse könnte dann zu einer Änderung der Ontologie führen. Beispielsweise könnte das System das Verhalten und die Suchanfragen des Benutzers analysieren und feststellen, dass sich die Interessen des Nutzers geändert haben. Diese Änderung würde zu einer Anpassung der InteressenInstanz der Ontologie führen.

Danksagung Das Projekt ZAFH-AAL („Zentrum für Angewandte Forschung an Hochschulen für Ambient Assisted Living“) wird gefördert durch das Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg im Rahmen der Förderung von Forschungsschwerpunkten an Fachhochschulen Zukunftsoffensive IV „Innovation und Exzellenz“ (ZO IV). Das PCEICL-Projekt ist ein Teilprojekt des ZAFH-AAL.

Literatur [1]

M. Klein, A. Schmidt und R. Lauer: Ontology-Centred Design of an Ambient Middleware for Assisted Living: The Case of SOPRANO.–In: Towards Ambient Intelligence: Methods for Cooperating Ensembles in Ubiquitous Environments (AIM-CU), 30th Annual German Conference on Artificial Intelligence KI 2007 (2007)

[2]

L. Litz und M. Gross: Covering Assisted Living Key Areas based on Home Automation Sensors.–In: Networking, Sensing and Control, 2007 IEEE International Conference on (2007),S. 639-643

[3]

J. A. Botia, A. Villa und J. Palma: Ambient Assisted Living system for in-home monitoring of healthy independent elders.–In: Expert Systems with Applications (2012), Nr. 39, S. 8136 –8148

[4]

S. Lauriks, A. Reinersmann, H. Roest, F. Meiland, R. Davies, F. Moelaert, M. Mulvenna, C. Nugent und R.-M. Dröes: Review of ICT-Based Services for Identified Unmet Needs in People with Dementia. –In: Supporting People with Dementia Using Pervasive Health Technologies, Springer London (2010), S. 37-61

[5]

M. Assad, D. Carmichael, J. Kay und B. Kummerfeld: PersonisAD: Distributed, Active, Scrutable Model Framework for Context-Aware Services. – In: Pervasive Computing, Springer Berlin Heidelberg (2007) Nr. 4480, S. 55-72

[6]

R. Ram, F. Furfari, M. Girolami, G. Ibañez-Sánchez, J.-P.Lázaro-Ramos, C. Mayer, B. Prazak-Aram und T. Zentek: universAAL: Provisioning Platform for AAL Services. –

Benutzerzentrierte Ontologie im Bereich Ambient Assisted Living

129

In: Ambient Intelligence -Software and Applications, Springer International Publishing (2013) Nr. 219, S. 105-112 [7]

K.-L. Skillen, L. Chen, C. Nugent, M. Donnelly, W. Burns und I. Solheim: Ontological User Profile Modeling for Context-Aware Application Personalization. – In: Ubiquitous Computing and Ambient Intelligence, Springer Berlin Heidelberg (2012) Nr. 7656, S. 261-268

[8]

K.-L. Skillen, L. Chen, C. Nugent, M. Donnelly und I. Solheim: A user profile ontology based approach for assisting people with dementia in mobile environments. – In: Engineering in Medicine and Biology Society (EMBC), 2012 Annual International Conference of the IEEE (2012), S. 6390-6393

[9]

P. Moreno, M. Hernando und E. Gómez: AALUMO: A User Model Ontology for Ambient Assisted Living Services Supported in Next-Generation Networks. – In: XIII Mediterranean Conference on Medical and Biological Engineering and Computing 2013, Springer International Publishing (2014) Nr. 41, S. 1217-1220

[10] D. Heckmann, T. Schwartz, B. Brandherm, M. Schmitz und M. WilamowitzMoellendorff: Gumo -The General User Model Ontology. – In: User Modeling 2005, Springer Berlin Heidelberg (2005) Nr. 3538, S. 428-432 [11] M. Sutterer, O. Droegehorn undK. David: UPOS: User Profile Ontology with SituationDependent Preferences Support. –In: Advances in Computer-Human Interaction, 2008 First International Conference on (2008), S. 230-235 [12] Agent Communication Language Spezifikationen URL: http://www.fipa.org/repository/aclspecs.html [Zugriff am 18.02.2014] [13] Java Agent 18.02.2014]

DEvelopment

FrameworkURL:

http://jade.tilab.com/

[Zugriff am

[14] C. Fredrich: Kontextgetriebene „Software as a Service“ im Bereich „Ambient Assisted Living“. Masterthesis, Hochschule Furtwangen 2013, URL: http://www.wolke.hsfurtwangen.de/assets/files/Theses/2013_SS13_Carina_Fredrich_Kontextgetriebene_SaaS_im_B ereich_AAL.pdf [15] World Health Organization (WHO): International Classification of Diseases (ICD)URL: http://www.who.int/classifications/icd/en/ [Zugriff am 19.02.2014]

Security and Privacy Challenges in On-The-Fly Computing Ronald Petrlic, Christoph Sorge Institut für Informatik Universität Paderborn Warburger Strasse 100 33098 Paderborn

Alexander Jungmann C-LAB Universität Paderborn Fürstenallee 11 33102 Paderborn

Marie Christin Platenius, Wilhelm Schäfer Heinz Nixdorf Institut Universität Paderborn Fürstenallee 11 33102 Paderborn

Abstract: On-The-Fly (OTF) Computing constitutes an approach towards highly dynamic and individualized software markets. Based on service-oriented computing, OTF Computing is about realizing global markets of ser-vices that can be flexibly combined. We report on our current research activi-ties, the security and privacy implications thereof, and our approaches to tack-le the challenges. Furthermore, we discuss how the security and privacy chal-lenges are addressed in research projects similar to OTF Computing.

1 Introduction Security and privacy protection play a major role in today’s software technologies and processes. The aim of this article is to look at highly dynamic and individualized software markets that we might face in the future and to identify potential risks in terms of security and privacy. We perform this investigation for On-The-Fly (OTF) Computing, which constitutes one approach towards future software markets. We will highlight the state-of-theart of our research and present future challenges that still need to be solved. The OTF Computing initiative includes researchers from different disciplines: Software engineering, distributed systems, applied cryptography, among others. The different views and requirements in terms of security and privacy are reflected in this article. We do not only focus on technical measures to guarantee security and privacy protection but we also look at the legal ramifications, which will also be picked up in this article. of the device or more precisely the integrity of all the installed software.

This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Centre On-The-Fly Computing (SFB 901)

132

Petrlic, Jungmann, Platenius, Schäfer, Sorge

1.2 On-The-Fly Computing The On-The-Fly (OTF) Computing [1] initiative at the University of Paderborn is funded by the DFG as a Collaborative Research Centre. Its objective is to enable automated on-the-fly composition of software services provided on world-wide dynamic markets. The services are composed by intermediaries called OTF providers and deployed to what are called OTF compute centers. This also involves developing methods for quality assurance and protection of market participants, i.e., service requesters and service providers. The functional components of OTF Computing can be classified into three different layers (cf. Figure 1). Each layer has to deal with a different amount of services. The upper layer represents the global market of services. It includes algorithms for searching services in large-scale networks. The middle layer includes the actual service composition process. It retrieves service candidates from the upper layer and passes a composed service for verification and execution to the lower layer. The lower layer comprises extensive verification of composed services with respect to functional as well as nonfunctional properties and requirements. Furthermore, the lower layer provides means for executing services.

Figure 1: Classification of functional components into three different layers.

Service providers provide their (software) services to OTF providers for service composition and, eventually, to end users who execute the composed service in an OTF compute center. This approach is fundamentally different from today’s cloud computing approaches, where users typically interact with a single “cloud provider” that executes its own software within its own premises. The separation between software provision and execution implies a need for a digital rights management (DRM) solution for OTF Computing, as the provider is not in control of its software service any more. Another aspect needed to be solved is how users are able to choose one out of a multitude of OTF providers in such a highly dynamic market to do business with. The same is true for OTF providers: How to decide from which service providers offering comparable basic services for service composition. Our approach is to introduce reputation at different stages within OTF

Security and Privacy Challenges in On-The-Fly Computing

133

Computing. The multi-level need for reputation by itself is a non-trivial task that we investigate as part of our research, but security and privacy requirements furthermore complicate the issue.

2 Security and Privacy Challenges In this section, we give an overview of the security and privacy challenges that we have identified for the different tasks in OTF Computing.

2.1 Reputation Management Reputation information is needed during several phases in OTF Computing. The reputation of a party is computed as a function of a multitude of individual user ratings. From a security point of view, authorization plays a crucial role: Only users that executed a composed service shall be allowed to rate this service or its providers, etc. On the other hand, users may see privacy protection as a requirement to be even willing to provide a rating: Users might not want that anybody can link their ratings to transactions. The reasons are that users could fear bad feedback in return or even bad service in the future from those providers rated badly. Moreover, users might not want that any other users retrieving information from the reputation system are able to identify which services they used – being able to create detailed user profiles. This argument is even more important for companies: Their specialized OTF Computing services might be business secrets and their incentive to rate those services would not be given unless their “privacy” is protected.

2.2 Service Selection Selection of services in OTF Computing can be divided into two separate phases. A service matching component determines to what extent a particular service fulfills a search request. A subsequent service recommendation component identifies the best candidates out of the set of remaining services. 2.2.1 Service Matching Architecture Automated service matching is done by Service Matchers. In OTF Computing, each service provider gets a service matching algorithm when entering the market. Thereby, the bottleneck of having a few global service matchers can be avoided so that the execution time of the overall service discovery process is improved and the whole scenario even scales for dynamic markets, where the number of service providers changes all the time. However, this also entails the risk that service providers try to manipulate the matching

134

Petrlic, Jungmann, Platenius, Schäfer, Sorge

results: In order to improve their sales opportunities, service providers could pretend to provide services that fit the request better than they actually do. On the other hand, providers could try to manipulate the matching results of other providers by faking bad matching results even for services that would match well. Such attacks have to be prohibited by adequate security mechanisms. This challenge is partly addressed by the reputation system as it ensures long-term consequences for each transaction. If a provider fakes matching results, leading to a successful sale even though the sold service does not match the request, the customer has the possibility to (anonymously) provide a bad rating for the service and/or the service provider. Thereby, sooner or later, malicious service providers are marked with a bad reputation and their sales opportunities decrease. This reduces the attraction for manipulating the matcher, however, it does still not completely prohibit manipulation. 2.2.2 Security and Privacy Specification and Matching As part of a service selection process, basic services traded on the market need to be discovered. For this purpose, available service offers need to be matched to a search request. Service matching needs to take different information about a service into account: The information may be structural (e.g., operational signatures), behavioral (e.g., protocols), and non-functional properties (e.g., different kinds of quality properties). As security and privacy are important non-functional properties for most services, approaches for security and privacy matching are required. These approaches should determine how much a service offer complies with the requirements of a request. In OTF Computing, we perform the matching process automatically. However, automated matching requires precise and comprehensive service specifications that can be processed automatically. Finding an appropriate service specification language for security and privacy properties as well as finding a corresponding matching approach is a challenge; for example: a) The specification language should be expressive enough that security and privacy properties can be matched accurately while, at the same time, it cannot be too complex such that the matching is still efficient. b) The effort for service providers and requesters to describe offered and requested security properties and privacy policies should be low. c) The specification language and the matching approach have to allow and cope with uncertain, imprecise, and incomplete specifications to allow requesters and providers more flexibility.

Security and Privacy Challenges in On-The-Fly Computing

135

2.2.3 Adaptive Recommendation System Each OTF provider runs its own recommendation system: Recommendation knowledge based on user feedback is accumulated over time in order to improve subsequent selection processes. This knowledge can be considered as a business secret that shall not be globally accessible, especially not by other competing OTF providers, i.e., security is a major requirement. In order to facilitate a user-friendly OTF Computing process, we want to minimize efforts for users that provide feedback. Hence, for avoiding redundant user rating processes, we intend to combine the OTF providers’ local recommendation systems and the global reputation system. However, this incorporation entails a major challenge as the reputation system is to be built in a privacy-preserving way: Deterioration for the recommendation system. The entire recommendation process is interpreted as a sequential decisionmaking problem, modeled as Markov Decision Process and solved by Reinforcement Learning (RL) techniques that try to maximize reward by identifying optimal actions. In OTF Computing, reward depends on user ratings that reflect users’ satisfaction with respect to the execution result of a composed service. It is a basic concept of RL to directly integrate new feedback into the overall process in order to improve the decision-making for subsequent processes. [2] However, the privacy-preserving reputation system solution, which will be discussed in Section 3.1, does not provide immediate feedback but only in accumulated form. As a consequence, we have to identify a well-balanced trade-off between privacy protection and learning speed of our adaptive recommendation system.

2.3 Service Composition VÖLKER [3] notes that security properties are not composable and, thus, it is hard to conclude from security properties of individual services to security properties of a composed service. Völker did his investigation for communication protocols – however, we face the same challenges in our context. It needs to be investigated how security and privacy guarantees of composed services can be based on the guarantees of the basic services.

2.4 Digital Rights Management The challenges imposed by a DRM solution for OTF Computing are manifold. Service providers require a secure solution that does not allow unauthorized executions of their services, whereas users require that a DRM solution must not invade their privacy, i.e. allows for a creation of usage profiles.

136

Petrlic, Jungmann, Platenius, Schäfer, Sorge

The challenge in designing a DRM solution is to find a way to support differentiated rights models without allowing any party to build user profiles. The goal in designing a DRM solution for OTF Computing is even to prevent profile building under a pseudonym. A solution needs to be found that provides a fully anonymous access rights control.

2.5 Legal Issues The composition of services immediately raises a number of questions: Which of the involved parties can be held responsible, and how should contracts between those parties be designed? If the contractual framework becomes too complex, end-users may be discouraged from using the system. A similar issue arises from the perspective of data protection legislation: If personal data are processed, the “processor” – the entity responsible for data processing and for adherence to data protection regulations – must be determined. In case a provider outsources processing of personal data to a third party, it must still be in control, and adhere to the rules set forth by data protection legislation, as defined – in Germany – in Section 11 of the Federal Data Protection Act. The goal of this legislation is to guarantee the individuals’ right to informational self-determination, which requires transparency concerning the flow of personal data about oneself. Besides data protection legislation, the individual services provided in OTF Computing relate to a number of other fields of law. For example, digital rights management is closely linked to copyright law. The legal challenges of the OTF Computing scenario are further complicated in an international context, where the applicability of national legislation has to be determined before even considering the original legal issue.

3 Research Activities In this section, we cover a few of the research activities towards security and privacy protection in OTF Computing that we have been working on.

3.1 Reputation Management We are still researching how to implement a reputation system for OTF Computing that complies with our contradicting requirements in terms of security and privacy. An approach where the reputation system collects a number k of individual ratings and outputs reputation values, which are aggregations of bulks of k ratings, seems to be promising from a privacy point of view. [4] However, as discussed above, the OTF providers also use repu-

Security and Privacy Challenges in On-The-Fly Computing

137

tation information for their internal learning algorithms to get to know which service compositions best fit together. Thus, such a privacy-preserving reputation system approach introduces a non-negligible deterioration. We are investigating which value k is still passable for a learning algorithm to be efficient enough and the level of anonymity provided to be still high enough. We do have first technical results already [5]: The reputation system, requir-ing only a single reputation provider – in contrast to related work where sev-eral independent providers are assumed – is based on the Paillier cryptosys-tem to homomorphically compute the aggregation of individual user ratings.

3.2 Security and Privacy Specification and Matching We started to create a specification language for privacy properties by taking recent approaches from literature [6, 7] and “merging” them into one, more powerful language using language integration techniques. The next steps are to evaluate this language and to implement a matching algorithm. For this algorithm, we apply fuzzy matching techniques in order to be able to match incomplete specifications. [8, 9] This is important, as we know from the P3P problems [10] that we cannot assume that providers as well as users are able and disposed to create large, formal, and complete specifications of privacy policies, respectively preferences. The same steps also have to be done for security specifications. For this, we already began to integrate the specification languages WS-Security [11] and UMLSec [12].

3.3 Digital Rights Management We have come up with several approaches towards a secure and privacypreserving DRM solution for OTF Computing. We present a solution which is based on re-encryption of the composed service for each single execution in order to achieve execution unlinkability towards the OTF compute centers. Moreover, the incorporation of a suitable anonymous payment scheme for the integration of a DRM system into OTF Computing is investigated in detail. [13] The idea of re-encryption is transferred to the “symmetric world” – for reasons of better efficiency [14]: Users perform the re-encryption of the service decryption key, which is then forwarded to the compute center to decrypt the service without allowing it to draw conclusions about previous executions (i.e., to achieve execution unlinkability). The re-encryption key generation, however, can only be done by a secure hardware device (e.g., a TPM or a smartcard) after verification of the proper access rights so that the user cannot arbitrarily perform re-encryptions without the right to do so.

138

Petrlic, Jungmann, Platenius, Schäfer, Sorge

3.4 Legal Ramifications From the perspective of cryptography, identity-based cryptographic schemes are a major contribution to OTF Computing. In comparison to previous public-key schemes, they enable a simplification of infrastructures: Identities – represented by arbitrary data – can be used as public keys, so retrieving certificates is no longer necessary to encrypt data. The use of identity-based cryptography also has legal implications. Within the project, we have investigated whether identity-based signatures can be used as advanced or qualified electronic signatures, as defined in the European Signature Directive and its national transposition in Germany. In comparison to identity-based encryption, the advantage of identity-based signatures over existing schemes is more limited: The common practice of sending along a certificate with a signed message can, in fact, be considered as a special case of identity-based signatures. However, the general concept of identity-based cryptography is to have private keys generated by a trusted entity, the Private Key Generator (PKG). The research question is if this concept fits into the legal framework for electronic signatures, and if not, where the delineation between the above-mentioned construction of identity-based signatures (which, as generally accepted, is suitable for advanced and qualified electronic signatures) and other identity-based schemes can be drawn. In particular, it is a requirement for advanced and qualified electronic signatures that the private key is under the signatory’s “sole control”. We have shown that identity-based signature schemes can fulfill this requirement. However, this only holds if cheating by the PKG can be uncovered. This is possible if that entity does not have, and cannot reconstruct, the particular private key used by any particular signatory. At first glance, this may seem contradictory; however, if private keys are generated in an interactive protocol with the signatory, such a signature scheme is considered possible. [15]

4 Related Work The ANIKETOS project [16], funded by the European Union as part of the seventh framework programme, has comparable goals as OTF Computing. The project focuses on trustworthiness and secure service composition: The goal is to allow users a means to rely on the security guarantees of the service composition – which they perform themselves in opposition to an automatic approach done in OTF Computing – based on the claimed security guarantees of the basic services. To rate service compositions, metrics of the compositions are determined (e.g., reputation values, costs, security properties, etc.). For each metric, a value is determined that is used by genetic algorithms to find the best service composition. As part of ANIKETOS’ promises

Security and Privacy Challenges in On-The-Fly Computing

139

to come up with a platform that allows for the creation and maintenance of security and trust of composed services, research has been done in the context of service composition: ZHOU ET AL. [17] state that a checking of metrics of a service composition done only once does not suffice. A periodic checking of the basic services is needed so that a secure execution is guaranteed when individual services change. MELAND ET AL. [18] note that service contracts are needed that define which security properties a service (or a ser-vice composition) provides and which security properties are required by the services. Based on the ideas of periodic checking and service contracts, COSTA ET AL. [19] introduced the SxCxT (Security-by-Contract-withTrust) concept, which allows for the replacement of modified basic services. More-over, the trust relationship between users and service providers is automati-cally adapted, e.g. when a service provider violates its service contract, it automatically “looses” trust by others (its reputation deteriorates). The AVANTSSAR project [20] pursues a similar approach. The service composition and the rating are done by different parties, the “orchestrator” and the “validator”, respectively. The orchestrator is created by the user by defining the required security properties. The orchestrator chooses basic services that comply with the security properties, composes them and provides the composed service to the validator. The validator validates the composition against security violations and provides feedback to the orchestrator. This process is repeated until a proper composition is found.

5 Conclusion and Outlook We have shown – for the example of OTF Computing – that any “big” software project involves a multitude of different security and privacy challenges. Coping with those challenges requires potential attack vectors to be taken care of from the beginning. We have covered some of the security and privacy challenges that we face as part of our research: We think that the software community can benefit from knowing those challenges. Even though OTF Computing is highly dynamic, with OTF providers and service providers joining and leaving the market, we need to investigate the trust relationships between the parties in more detail in the future. We have come up with cryptographic approaches to guarantee security and privacy, and we have dealt with the legal issues; however, trust will also play a central role in OTF Computing. Taking reputation – as a means towards trust – into account can only be a first step in that direction.

140

Petrlic, Jungmann, Platenius, Schäfer, Sorge

Literature [1]

University of Paderborn: SFB 901 On-The-Fly Computing. URL: http://sfb901.upb.de

[2]

A. Jungmann, B. Kleinjohann und L. Kleinjohann: Learning Service Recommendations –In: Int. J. of Business Process Integration and Management 6 (2014), Nr. 4, S. 284-297

[3]

L. Völker: Automatisierte Wahl von Kommunikationsprotokollen für das heutige und zukünftige Internet. Dissertation, Karlsruher Institut für Technologie 2012

[4]

S. Brangewitz, A. Jungmann, M. C. Platenius, R. Petrlic: Towards a Flexible and Privacy-Preserving Reputation System for Markets of Composed Services – In: Proc. of the 6th Int. Conf. on Advanced Service Computing, 2014

[5]

R. Petrlic, S. Lutters und C. Sorge: Privacy-Preserving Reputation Management – In: Proc. of the 29th ACM Symposium On Applied Computing, 2014

[6]

E. Costante, F. Paci und N. Zannone: Privacy-Aware Web Service Composition and Ranking – In: Proc. of the 20th IEEE Int. Conf. on Web Services, 2013, S. 131–138

[7]

G. M. Kapitsaki: Reflecting user privacy preferences in context-aware Web Services – In: Proc. of the 20th IEEE Int. Conf. on Web Services, 2013, S. 123-130

[8]

M. C. Platenius, M. von Detten, S. Becker, W. Schäfer und G. Engels: A survey of fuzzy service matching approaches in the context of on-the-fly computing – In: Proc. of the 16th Int. ACM Symp. on Component-Based Software Engineering (2013), S. 143-152

[9]

M. C. Platenius: Fuzzy Service Matching in On-The-Fly Computing – In: Proc. of the Doctoral Symp. of the 9th joint meeting of the European Software Engineering Conf. and the ACM SIGSOFT Symp. on the Foundations of Software Engineering, 2013

[10] P. Beatty, I. Reay, S. Dick und J. Miller: P3P Adoption on E-Commerce Web sites: A survey and Analysis – In: IEEE Internet Computing 11 (2007), Nr. 2, S. 65-71 [11] A. Nadalin, C. Kaler, R. Monzillo und P. Hallam-Baker: Web services security: SOAP message security 1.0 – In: Oasis Standard (2004), vol. 200401 [12] J. Jürjens: UMLsec: Extending UML for secure systems development – In: > 2002—The Unified Modeling Language (2002), S. 412-425 [13] R. Petrlic, S. Sekula und C. Sorge: A privacy-friendly Architecture for future Cloud Computing – In: Int. J. of Grid and Utility Computing 4 (2013), Nr. 4, S. 265-277 [14] R. Petrlic und S. Sekula: Unlinkable content playbacks in a multiparty DRM system – In: Proc. of the Data and Applications Security and Privacy XXVII LNCS (2013), vol. 7964, S. 289-296 [15] C. Sorge: The Legal Classification of Identity-Based Signatures – In: Computer Law and Security Review (2014), vol. 30, to appear [16] ANIKETOS: Ensuring Trustworthiness and Security in Service Composition. URL: http://www.aniketos.eu/ [17] B. Zhou, D. Llewellyn-Jones, D. Lamb, M. Asim und Q. Shi, M. Merabti: A heuristic approach for secure service composition adaptation – In: Proc. of the 1st Int. Workshop on Cyberpatterns (2012), S. 39-42 [18] P. Meland, J. Guerenabarrena und D. Llewellyn-Jones: The challenges of secure and trustworthy service composition in the future internet – In: Proc. of the 6th Int. Conf. on System of Systems Engineering (2011), S. 329-334

Security and Privacy Challenges in On-The-Fly Computing

141

[19] G. Costa, A. Lazouski, F. Martinelli, I. Matteucci, V. Issarny, R. Saadi, N. Dragoni und F. Massaci: Security-by-contract-with-trust for mobile devices – In: J. of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications (2010) Nr. 4, S. 75-91 [20] AVANTSSAR: Automated Validation of Trust and Security of Service-oriented Architectures. URL: http://www.avantssar.eu

A comparison of isolated code execution approaches for mobile devices Friedbert Kaspar Denis Jurkovic Hochschule Furtwangen Hochschule Furtwangen Robert-Gerwig-Strasse 1 Robert-Gerwig-Strasse 1 78120 Furtwangen 78120 Furtwangen [email protected] [email protected]

Abstract: The increasing capabilities of mobile devices which more and more make use of sensitive data and functionalities render security for mobile devices as chief concern. In this work we consider isolated code execution approaches like Flicker and TrustZone for their viability to secure critical data and functionality. We compare Flicker to the specification of Trusted Execution Environments and show how the functionalities and components match and what benefits a cross-over approach would salvage.

1 Introduction Recently the interest in making mobile devices more secure has been increased significantly, due to the uprising number of use cases in which sensitive user data is involved. One of the most serious problems is the fact, that these devices are physically accessible by the user respectively a potential attacker. Smartphones, tablets and laptops have improved in performance, resources and capabilities. It has become a realistic threat, that software installed on such a device is used for malicious activities. Hereby the user does not have to be aware of accidentally supporting an attack himself, for software which was originally secure can be altered to be used for sinister intentions without notice. Considering that it is the nature of mobile devices to roam between several different networks, for which security measures may vary from very strict security standards to e.g. home-made networks with only marginal security measures. Mobile devices pose an incalculable risk to sensitive network infrastructures and therefore to all other network participants. Therefore mobile devices cannot be trusted, unless certain measures are taken to assure the trustworthiness of the device or, more precisely, the integrity of all the installed software.

144

Jurkovic, Kaspar

Trusted Computing concepts for mobile devices may help to solve the problem. The idea of adding an additional “secure execution environment” to the common execution environment was introduced in 2002 when ARM presented his implementation of TrustZone [3] which has been further developed and refined and is widely distributed in ARM based platforms until today. The GlobalPlatform association has taken up the idea of securing critical or sensitive functionality from the insecure execution environment, by separately keeping up an additional Trusted Execution Environment (TEE). Their major goal was to define a more general standard for Trusted Execution Environments, by providing a detailed architecture specification with detailed requirements of what is needed to establish a proper Trusted Execution Environment [7,8]. The former mentioned TrustZone fulfills these specifications and counts as an example for the implementation of the GlobalPlatform standard. The Trusted Computing Group [4] specified a hardware solution for mobile trusted computing, based on its successful and broadly distributed Trusted Platform Module (TPM) [10]. This adapted Mobile Trusted Platform Module (MTM) [2] fits to common mobile architectures. It provides all TPM functionalities on a similar hardware chip base and introduces additional features like secure boot [2, 11]. Based on the TCG specifications, propositions like Flicker [1] represent approaches to demonstrate the high performance capabilities of TPM/MTM based functionalities. Furthermore the possibility to execute small code pieces in complete isolation of all applications and the running operating system is proven. Sadly the MTM hardware is only scarcely distributed among the common mobile platforms today.

1.1 Organisation of this work In this work we give a short introduction in Flicker and TrustZone. It is shown that the Flicker approach satisfies all the requirements of a Trusted Execution Environment defined by the GlobalPlatform specification. The benefits and drawbacks of the two technologies are compared to one another and the benefits of a combination of both technologies are discussed. The architectural ideas of Flicker are transferred to the more commonly distributed Trusted Execution Environment implementation TrustZone.

A comparison of isolated code execution approaches for mobile devices

145

This work shows what benefits the use of Trusted Execution Environments yield, while reducing the Trusted Code Base (TCB) size to a minimum.

2. Background This section gives a short background information summary on Trusted Execution Environment definitions and describes two approaches to implement trust capabilities in a device.

2.1 Trusted Execution Environments (TEE) Trusted Execution Environments are employed as an additional secure processing environment for sensitive or critical functionalities. These environments handle storage and memory as well as the protection of the integrity of the processing, by providing isolated execution while running alongside to the common, unprotected execution environment (Rich Execution Environment, REE) [7]. The GlobalPlatform Device Technology association has published specifications concerning the requirements to constitute a TEE with the purpose to establish a common standard.

2.2 Requirements for the constitution of a TEE As shown in [5,7,8] a TEE has to deal with three essential fields to satisfy the definition of the GlobalPlatform standard: Platform integrity, isolation of Storage and execution, as well as to provide a reliable device identity.

Figure 1: Constitution of a Trusted Execution Environment [5]

146

Jurkovic, Kaspar

To establish trust, the mobile device needs to rely on a Trusted Computing Base (TCB) as a trust anchor consisting of software and hardware components which need to be trusted a priori [5] as depicted in figure 1. To implement the needed functionality all three fields make use of cryptographic algorithms and mechanisms like encryption, digital signing, hashing, etc. As a Hardware requirement a root of trust for verification is needed that contains certificates for boot code, trusted applications (TA) and prove of identity. 2.2.1 Platform integrity The central point of all running software considering mobile devices is the operating system. To ensure trustworthiness it is essential to verifiably ensure a completely unaltered boot process. Otherwise the correctness of any further action cannot be trusted. The most common approach to establish secure boot is the usage of code signing combined with an immutable boot process. By storing a verifiable signature for every step in the boot process inside e.g. the ROM of the processor [5] during the manufacturing process a controllable system boot is enabled. Each step of the sequence must be successively signed and stored with respect to the certificates and mechanisms the TCB provides for later use. For achieving a secure boot, each step has to be validated at launch time to assure it fits to the according signed value stored in the TCB. 2.2.2 Secure storage and isolated execution Secure storage is an isolated part of memory which is protected from being read or altered from outside a certain environment. It can be used to store information that needs to be protected from manipulation. This requires a hardware trust root like the device key which has to be inserted into the TCB by the manufacturer. In addition to these requirements some cryptographic functionalities demand a persistent storage to keep its state beyond a device boot. While capable of cryptographic protection and mechanisms it is possible to provide certain functions to the REE with the guarantee that no cryptographic secret is leaving the TCB. In addition, code isolation is one of the most important requirements for a trusted infrastructure. Due to the common central processing architecture of modern devices, processors have to support mechanisms to enable separation. To provide the isolated execution of arbitrary code pieces the device hardware must provide a TEE API by which the additional TEE code can be loaded. Therefore the added TEE code must be hashed

A comparison of isolated code execution approaches for mobile devices

147

and signed by the verification root to constitute a trusted application certificate. This can later be used to authorize the application’s execution inside the TEE. 2.1.4 Device identification Remote attestation is the capability of a system to inform others about its current system state respectively to attributes that indicate the system’s integrity. Hereby no evaluation is done by the system itself. It displays its current state to enable third parties to determine, if this state satisfies their security demands. The TCB must have an immutable base identity, integrated by the manufacturer, for example in the fashion of a serial number, to make secure authentication possible. By using a manufacturer signed certificate, bound to the device key, it is even possible to sign statements, respectively measurement values, from the volatile storage to enable secure remote attestation.

2.3 ARM TrustZone The TrustZone implementation realizes an additional isolated environment by a System on a Chip (SoC) architecture, where resources like data and critical code segments are securely processed [3,7,8]. The separation is achieved by the CPU hardware architecture, where a certain CPU switch determines which CPU mode is executed. There are two modes: normal mode Rich Execution Environment (REE) and the secure mode, Trusted Execution Environment (TEE). The SoC internal bus carries a status flag while additional hardware components are enforcing access control to memory and off-chip peripherals. Figure 2 shows the general hardware architecture of the TrustZone implementation. REE applications in this architecture are able to shift their sensitive functionality into a secure environment, accessing this functionality at need by calling the TEE API via Secure Monitor Call (SMC) [3]. Therefore two requirements must be fulfilled: First the hardware architecture has to be TrustZone enabled, which is given on most of the ARM processor architectures and second the software must implement the TEE API to load the executable TEE code.

148

Jurkovic, Kaspar

Figure 2: Hardware architecture of TrustZone [5]

2.4 Flicker Flicker is a TPM based trust infrastructure for isolated code execution with the aim of a minimized trusted code base [1]. Additionally Flicker provides provable protection via meaningful attestation of the system state, the correct code execution and the attestation of input and output data. The Flicker isolation process is shown in figure 3. By employing the late launch capabilities of today’s processor architectures, which originally allow host operating systems to launch a Virtual Machine Monitor at any time, to shortly halt the running operating system, to execute a short piece of application logic (PAL) by using the SKINIT instruction and resume the execution of the OS at the same point where it was stopped. The SKINIT command accepts a secure loader block (SLB) as an argument. An SLB contains the code (PAL) which the programmer wants to execute in isolation and is created by linking the according code to the Flicker module called SLB core. After the execution of the PAL, all remaining data in the memory is removed to assure no sensitive information is leaked to the outside environment. After the memory clean-up has ended, the operating system environment is resumed and the output of the isolated execution sequence is returned.

A comparison of isolated code execution approaches for mobile devices

149

Figure 3: Flicker process [1]

The underlying TPM provides all the capabilities like encryption mechanisms, hashing algorithms, sealed storage functionalities, mechanisms for remote attestation and digital signing as well as the storage root key which is integrated inside the chip during its manufacturing [1]. Since version 1.2 TPM provides volatile or dynamic storage registers (PCR1723) which are used by Flicker to store the measurements of the PAL executions. By initiating the SKINIT command or by rebooting the device the values stored inside these dynamic registers are reset and can now be used for other purposes e.g. the next Flicker session. Through these capabilities a provable, secure and isolated code execution is enabled.

4. Flicker and TrustZone face to face 4.1 Functionality coverage Figure 4 shows the functionality coverage of the GlobalPlatform TEE standard by Flicker. In combination of Flicker and the usage of the dynamic root of trust for measurement, all the capabilities needed to build a trusted execution environment can be addressed.

Figure 4: Component coverage by Flicker

150

Jurkovic, Kaspar

In detail, the verification root maps to the dynamic root of trust for measurement. The TPM chip provides all the necessary cryptographic mechanisms as well as cryptographic keys, volatile and non-volatile storages which are provided through the dynamic and static PCRs and are used for the sealed storage mechanism. Considering this mapping of functionality and capabilities, we conclude that Flicker provides a true Trusted Execution Environment. The main difference between Flicker and TrustZone is the distribution and size of their TCB. Flicker relies strongly on a TPM hardware addition which provides most of the critical functionalities in a hardware separated environment. In contrast TrustZone uses a system on a chip approach were all functionalities as well as all processes are maintained on one single CPU chip. As shown in figure 5 concerning the Trusted Code Base (gray colored elements), both approaches include the hardware of the devices as well as all the trusted applications. In case of Flicker the TPM chip provides most of the needed functionalities and is therefore added to the TCB. TrustZone in return has these functionalities (as shown in figure 1) provided by its native hardware, but is designed to uphold an additional instance of the operating system in a trust validated state at all time. Flicker, in contrast, works completely independent from any operating system. Isolated Flicker sessions are added to the TCB only when isolated code execution is needed. Despite the differences in their code bases and hardware requirements, both approaches satisfy the needs of Trusted Execution Environments. This means that each of the two approaches is capable to be exchanged with one another.

Figure 5: Comparison of the TCB between Flicker and TrustZone [1,5]

A comparison of isolated code execution approaches for mobile devices

151

4.2 Benefits and drawbacks As shown in section 4.1 Flicker maintains a very low sized TCB compared to Trustzone by dissociating itself from any operating system. A low TCB is beneficial for security because any additional code increases the risk of additional vulnerabilities and therefore provides a broader surface for attacks. While Flicker only maintains an isolated environment during the execution of the short code segments, the overhead for security measures is very low compared to the always alongside running TEE of TrustZone. By avoiding the overhead of an underlying operating system Flicker gains advantage in performance measures. A drawback of Flicker is its dependence to TPM/MTM hardware which has a lower distribution among mobile platforms compared to ARM TrustZone. Common mobile devices are not designed for modification of hardware elements, except for additional SD-memory so the approach is restricted to platforms with the necessary hardware already implemented. This limits the applicability on today’s mobile devices markets. The ARM processors have a big market share for mobile devices. They come with integrated TrustZone capability. It is therefore possible to use TrustZone on the majority of mobile devices without additional hardware. As mentioned before, Flicker requires the addition of a module to the Kernel. That means the operating system has to be altered. The task to manipulate a mobile device successfully is very unlikely carried out by common users. Additionally it is not possible to alter the kernel of closed source operating systems with a justifiable amount of effort. This adds up to a lower appliance rate of this approach. While TrustZone merely requires the implementation of the TEE API on top of the operating system, no changes have to be applied to the device or the operating system itself.

5. Conclusion This work shows the necessary capabilities and required components for the constitution of a Trusted Execution Environment. By looking at the specifications of the TrustZone and GlobalPlatform TEE’s it is shown how the Flicker approach is satisfying all the common requirements of a TEE by using TPM and late launch. From the similar concerns of secure boot, isolation of storage and execution, we derive the idea to transfer

152

Jurkovic, Kaspar

the flicker capabilities to the TrustZone not by re-implementing TPM/MTM inside TrustZone but by mapping the mechanisms to its Trusted Code Base. Considering drawbacks and benefits of Flicker and TrustZone it would be beneficial to define and implement a best-breed approach between the two technologies. The resulting approach promises the benefits of Flicker, i.e. a small and high performance TCB on a platform, which is far more widely spread in the field of mobile computing than TPM and is more flexible considering the integration into mobile operating systems. First work has already been done by Winter, who shows an approach of merging TPM concepts with TrustZone to define an open Linux-based embedded trusted computing platform [6]. The Trusted Computing Group has published a roadmap within a white paper, where the implementation of TPM/MTM as a Trusted Application inside the GlobalPlatform TEE is suggested by the name of TMP mobile [9].

References [1]

[2] [3]

[4] [5]

[6]

[7] [8]

J. M. McCune, B. Parno, A. Perrig, M. K. Reiter, H. Isozaki: Flicker: An Execution Infrastructure for TCB Minimization, Carnegie Mellon University, EuroSys’08 Glasgow Scotland ACM 2008 Trusted Computing Group: TCG Mobile Trusted Module Specification Specification Version 1.0 Revision 7.02 29 April 2010 ARM Security Technology – Building a Secure System using TrustZone Technology. ARM Technical White Paper, 2009. http://infocenter.arm.com/help/top-ic/com.arm.doc.prd29-genc009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf Trusted Computing Group: http://www.trustedcomputinggroup.org (access: 16.02.14) J.Ekberg, K. Kostiainen, N. Asokan: “The Untapped Potential of Trusted Execution Environments on Mobile Devices”; Proceedings of the Financial Cryptography and Data Security 17th International Conference 2013, Okinawa, Japan, April 2013, pp 293-294 S. Xu; C. Nita-Rotaru; J.-P. Seifert; J. Winter:” Trusted computing building blocks for embedded linux-based ARM trustzone platforms”; ACM STC’08, October 2008, Fairfax Virginia, USA GlobalPlatform Device Technology: “TEE System Architecture”, Version 1.0 Public Release Dec. 2011. Doc. Ref.: GPD_SPE009 GlobalPlatform Device Technology:”The Trust Execution Environment: Delivering Enhanced Security at Lower Cost to the Mobile Market”, White Paper Feb.2011

A comparison of isolated code execution approaches for mobile devices [9] [10] [11]

153

Trusted Computing Group: “Mobile Trusted Module 2.0 Use Cases”; Version 1.0, Revision 1, March 2011 Trusted Computing Group: TCG Specification Architecture Overview v1.2, page 11-12. Technical report, Trusted Computing Group, April 2004 Trusted Computing Group: TPM MOBILE with Trusted Execution Environment for Comprehensive Mobile Device Security, White Paper June 2012 https://www.trustedcomputinggroup.org/files/static_page_files/5999C3C11A4B-B294-D0BC20183757815E/TPM%20MOBILE%20with%20 Trusted%20Execution%20Environment%20for%20Comprehensive%20Mobile%20 Device%20Security.pdf (accessed:16.02.2014)

Autorenverzeichnis

C

Kölle, H. 33 Kuijs, H. 115

Christ, A. 101

M

D

Marepall, S. M. 101 Müller, G. 3

Dannegger, C. 21

N E

Nopper, B. 49

Eggert, S. 71, 87

P F Fertich, A. 71, 87 Fredrich, C. 115

Petrlic, R. 131 Platenius, M.C. 131

R G

Reich, C. 115

Gantikow, H. 9 Grunow, F. 21

S

Hölscher, D. 59

Sarma, A 5 Schäfer, W. 131 Sorge, C. 131 Sultana, R. 101

J

U

Jungmann, A. 131 Jurkovic, D. 143

Usmanov, G. 33

H

K Kaiser, A. 33 Kaspar, F. 143