Proceedings - Journals - EMIS

GI-Edition

Gesellschaft für Informatik e.V. (GI) publishes this series in order to make available to a broad public recent findings in informatics (i.e. computer science and information systems), to document conferences that are organized in cooperation with GI and to publish the annual GI Award dissertation.

The volumes are published in German or English. Information: http://www.gi.de/service/publikationen/lni/

Neeraj Suri, Michael Waidner (Hrsg.)

Sicherheit 2012 Neeraj Suri, Michael Waidner (Hrsg.): Sicherheit 2012

Broken down into • seminars • proceedings • dissertations • thematics current topics are dealt with from the vantage point of research and development, teaching and further training in theory and practice. The Editorial Committee uses an intensive review process in order to ensure high quality contributions.

Lecture Notes in Informatics

ISSN 1617-5468 ISBN 978-88579-289-5 This volume contains the contributions to the 6th Conference of the GI special interest group “Sicherheit, Schutz und Zuverlässigkeit” that took place in Darmstadt on March 7-9, 2012.The main aspects of the conference were secure software development, biometrics, e-commerce, reliability and safety, certification, fault-tolerance, formal methods, critical infrastructure protection, cryptography, network security, privacy enhancing techniques, intrusion detection and prevention, and steganography.

195

Sicherheit, Schutz und Zuverlässigkeit Beiträge der 6. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.V. (GI)

7.–9. März 2012 Darmstadt

Proceedings

Neeraj Suri, Michael Waidner (Hrsg.)

SICHERHEIT 2012 Sicherheit, Schutz und Zuverlässigkeit

Konferenzband der 6. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.V. (GI) 7.-9. März 2012 in Darmstadt

Gesellschaft für Informatik e.V. (GI)

Lecture Notes in Informatics (LNI) - Proceedings Series of the Gesellschaft für Informatik (GI) Volume P-195 ISBN 978-3-88579-289-5 ISSN 1617-5468 Volume Editors Prof. Dr. Michael Waidner Technische Universität Darmstadt Sicherheit in der Informationstechnik 64293 Darmstadt, Germany Email: [email protected] Prof. Suri Neeraj, Ph. D. Technische Universität Darmstadt Zuverlässige Eingebettete Softwaresysteme 64289 Darmstadt, Germany Email: [email protected] Series Editorial Board Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt, Austria (Chairman, [email protected]) Hinrich Bonin, Leuphana Universität Lüneburg, Germany Dieter Fellner, Technische Universität Darmstadt, Germany Ulrich Flegel, Hochschule Offenburg, Germany Ulrich Frank, Universität Duisburg-Essen, Germany Johann-Christoph Freytag, Humboldt-Universität zu Berlin, Germany Michael Goedicke, Universität Duisburg-Essen, Germany Ralf Hofestädt, Universität Bielefeld, Germany Michael Koch, Universität der Bundeswehr München, Germany Axel Lehmann, Universität der Bundeswehr München, Germany Ernst W. Mayr, Technische Universität München, Germany Thomas Roth-Berghofer, DFKI, Germany Sigrid Schubert, Universität Siegen, Germany Martin Warnke, Leuphana Universität Lüneburg, Germany Dissertations Steffen Hölldobler, Technische Universität Dresden, Germany Seminars Reinhard Wilhelm, Universität des Saarlandes, Germany Thematics Andreas Oberweis, Karlsruher Institut für Technologie (KIT), Germany  Gesellschaft für Informatik, Bonn 2012 printed by Köllen Druck+Verlag GmbH, Bonn

Vorwort Die Konferenz “Sicherheit, Schutz und Zuverlässigkeit” SICHERHEIT der Gesellschaft für Informatik e.V. fand 2012 in der sechsten Ausgabe in Darmstadt statt. Sie ist die regelmäßig stattfindende Fachtagung des Fachbereichs “Sicherheit – Schutz und Zuverlässigkeit” der Gesellschaft für Informatik e.V. Die SICHERHEIT bietet einem Publikum aus Forschung, Entwicklung und Anwendung ein Forum zur Diskussion von Herausforderungen, Trends, Techniken und neuesten wissenschaftlichen und industriellen Ergebnissen. Die Tagung deckt alle Aspekte der Sicherheit informationstechnischer Systeme ab und versucht, auch eine Brücke zwischen den Themen IT Security, Safety und Dependability zu bilden. Der vorliegende Tagungsband umfasst alle 20 Beiträge des wissenschaftlichen Programms. Diese Beiträge wurden aus insgesamt 51 Einreichungen durch das international besetzte 38köpfige Programmkomitee ausgewählt. Traditionsgemäß durften Beiträge in Deutsch und in Englisch eingereicht werden. In diesem Jahr gab es zudem vier eingeladene Sprecher. Unser Dank gilt allen, die sich mit Zeit und Mühe am Gelingen der Konferenz beteiligt haben. Allen voran zu nennen sind hier die Autorinnen und Autoren, die Mitglieder des Programmkomitees und die weiteren Gutachter, sowie die Sponsoren der Konferenz. Unser ganz besonderer Dank gilt Andrea Püchner und Marco Ghiglieri, die sich ruhig und ausdauernd um alle Probleme der lokalen Organisation gekümmert haben, von der Planung bis zur eigentlichen Durchführung. Unser Dank gilt auch dem Leitungsgremium des GIFachbereichs “Sicherheit - Schutz und Zuverlässigkeit”, insbesondere den Mitgliedern der Tagungsleitung, Hannes Federrath, Felix C. Freiling und Jörg Schwenk. März 2012

Neeraj Suri, Michael Waidner

Tagungsleitung • Hannes Federrath (Sprecher des Fachbereichs, Universität Hamburg) • Felix C. Freiling (Leiter der Sicherheit 2010, Friedrich-Alexander-Universität ErlangenNürnberg) • Jörg Schwenk (stellv. Sprecher des Fachbereichs, Ruhr-Universität Bochum) • Neeraj Suri (Co-Leiter, Technische Universität Darmstadt) • Michael Waidner (Leiter, Technische Universität Darmstadt und Fraunhofer SIT)

Programmkomitee • Neeraj Suri (Technische Universität Darmstadt) • Michael Waidner (Technische Universität Darmstadt und Fraunhofer SIT) • Michael Backes (Universität des Saarlandes) • Bernd Becker (Universität Freiburg) • Fevzi Belli (Universität Paderborn) • Thomas Biege (SUSE Linux Products GmbH) • Jens Braband (Siemens AG) • Peter Buchholz (Technische Universität Dortmund) • Christoph Busch (Hochschule Darmstadt) • Christof Fetzer (Technische Universität Dresden) • Simone Fischer-Hübner (Karlstad University, Schweden) • Felix C. Freiling (Friedrich-Alexander-Universität Erlangen-Nürnberg) • Sabine Glesner (Technische Universität Berlin) • Bernhard Hämmerli (Acris GmbH) • Marit Hansen (Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein) • Thorsten Holz (Ruhr-Universität Bochum) • Jörg Kaiser (Otto-von-Guericke-Universität Magdeburg) • Günter Karjoth (IBM Research – Zurich) • Stefan Katzenbeisser (Technische Universität Darmstadt)

• Ralf Küsters (Universität Trier) • Helmut Kurth (atsec information security) • Peter Ladkin (Universität Bielefeld) • Pavel Laskov (Universität Tübingen) • Erik Maehle (Universität Lübeck) • Jörn Müller-Quade (Karlsruhe Institut für Technologie) • Isabel Münch (BSI - Bundesamt für Sicherheit in der Informationstechnik) • Roman Obermaisser (Universität Siegen) • Günther Pernul (Universität Regensburg) • Andreas Polze (HPI Universität Potsdam) • Kai Rannenberg (Goethe-Universität Frankfurt am Main) • Felix Salfner (SAP Innovation Center Potsdam) • Jörg Schwenk (Ruhr-Universität Bochum) • Jean-Pierre Seifert (Technische Universität Berlin) • Claus Stark (Citigroup AG) • Martin Steinebach (Fraunhofer SIT) • Reinhard von Hanxleden (Christian-Albrechts-Universität zu Kiel) • Carsten Willems (Ruhr-Universität Bochum) • Sven Wohlgemuth (National Institute of Informatics, Japan)

Zusätzliche Gutachter • Rafael Accorsi (Universität Freiburg) • Gökhan Bal (Goethe-Universität Frankfurt am Main) • Zinaida Benenson (Friedrich-Alexander-Universität Erlangen-Nürnberg) • Sebastian Biedermann (Technische Universität Darmstadt) • Tino Brade (Otto-von-Guericke-Universität Magdeburg) • Christian Broser (Universität Regensburg)

• Andreas Dewald (Universität Mannheim) • Sebastian Ertel (Technische Universität Dresden) • Linus Feiten (Universität Freiburg) • Daniel Fett (Universität Trier) • Marco Ghiglieri (Technische Universität Darmstadt) • Oliver Gmelch (Universität Regensburg) • Tim Grebien (Christian-Albrechts-Universität zu Kiel) • Sabri Hassan (Universität Regensburg) • Uwe Hentschel (Universität Potsdam) • Paula Herber (Technische Universität Berlin) • Johannes Hoffmann (Ruhr-Universität Bochum) • Ralf Hund (Ruhr-Universität Bochum) • Christine Hundt (Technische Universität Berlin) • Christian Kahl (Goethe-Universität Frankfurt am Main) • Lukas Kalabis (Technische Universität Darmstadt) • Matthias Kirchner (Westfälische Wilhelms-Universität Münster) • Daniel Kraschewski (Karlsruher Institut für Technologie) • Christoph Krüger (Christian-Albrechts-Universität zu Kiel) • Marc Kührer (Ruhr-Universität Bochum) • André Martin (Technische Universität Dresden) • Christian Moch (Friedrich-Alexander-Universität Erlangen-Nürnberg) • Michael Müter (Daimler AG) • Michael Netter (Universität Regensburg) • Christian Neuhaus (HPI Universität Potsdam) • Andreas Peter (Technische Universität Darmstadt) • Marcel Pockrandt (Technische Universität Berlin) • Robert Reicherdt (Technische Universität Berlin)

• Andreas Reisser (Universität Regensburg) • Konrad Rieck (Universität Göttingen) • Ahmad Sabouri (Goethe-Universität Frankfurt am Main) • Matthias Sauer (Universität Freiburg) • Alexander Schacht (HPI Universität Potsdam) • Dirk Scheuermann (Fraunhofer SIT) • Andre Schmitt (Technische Universität Dresden) • Christian Schneider (Christian-Albrechts-Universität zu Kiel) • Christoph Daniel Schulze (Christian-Albrechts-Universität zu Kiel) • Miro Spönemann (Christian-Albrechts-Universität zu Kiel) • Christoph Steup (Otto-von-Guericke-Universität Magdeburg) • Daniel Stöhr (Technische Unversität Berlin) • Martin Stopczynski (Technische Universität Darmstadt) • Dirk Tetzlaff (Technische Univeristät Berlin) • Max Tuengerthal (Universität Trier) • Fatbardh Veseli (Goethe-Universität Frankfurt am Main) • Andreas Vogt (Universität Trier) • Michael Weber (Universität Regensburg) • Robert Wierschke (HPI Universität Potsdam) • Ralf Wimmer (Universität Freiburg) • Philipp Winter (Karlstad University, Sweden) • Lars Wolos (Goethe-Universität Frankfurt am Main) • Sebastian Zug (Otto-von-Guericke-Universität Magdeburg)

Inhaltsverzeichnis Eingeladene Sprecher Christian Cachin Sicherheits-Forschung für die Cloud - Heisse Luft oder Wolke Sieben?

1

Hinrich Voelcker IT Security – Effiziente Organisation u¨ ber Governance hinaus . . . .

2

Jens Braband Security und Safety – das Yin und Yang der Systemsicherheit? . . . . .

3

Volkmar Lotz Towards a Secure and Trusted Business Web . . . . . . . . . . . . . .

4

Xuebing Zhou A Practical View of Privacy Preserving Biometric Authentication . . .

6

Benutzbarkeit von IT-Sicherheit I Zinaida Benenson, Olaf Kroll-Peters, Matthias Krupp Mentale Modelle der IT-Sicherheit bei der Nutzung mobiler Endgeräte

7

Jan Zibuschka, Heiko Roßnagel On Some Conjectures in IT Security: The Case for Viable Security Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

IT-Forensik Ulrich Greveler, Benjamin Justus, Dennis Löhr Identifikation von Videoinhalten u¨ ber granulare Stromverbrauchsdaten 35 Andreas Dewald, Felix C. Freiling, Thomas Schreck, ¨ Michael Spreitzenbarth, Johannes Stuttgen, Stefan Vömel, Carsten Willems Analyse und Vergleich von BckR2D2-I und II . . . . . . . . . . . . . .

47

Christian Zimmermann, Michael Spreitzenbarth, Sven Schmitt, Felix C. Freiling Forensic Analysis of YAFFS2 . . . . . . . . . . . . . . . . . . . . . .

59

Kryptographie ¨ ur ¨ Dagdelen, Marc Fischlin Christina Brzuska, Ozg TLS, PACE, and EAC: A Cryptographic View at Modern Key Exchange Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

¨ ur ¨ Dagdelen, Lassaad Cheikhrouhou, Werner Stephan, Ozg Marc Fischlin, Markus Ullmann Merging the Cryptographic Security Analysis and the Algebraic-Logic Security Proof of PACE . . . . . . . . . . . . . . . . . . . . . . . . .

83

¨ Detlef Huhnlein, Dirk Petrautzki, Johannes Schmölz, Tobias Wich, Moritz Horsch, Thomas Wieland, Jan Eichholz, Alexander Wiesmaier, Johannes Braun, Florian Feldmann, Simon Potzernheim, Jörg Schwenk, ¨ Christian Kahlo, Andreas Kuhne, Heiko Veit On the design and implementation of the Open eCard App . . . . . . 95 Sicherheit im Web Sebastian Lekies, Walter Tighzert, Martin Johns Towards stateless, client-side driven Cross-Site Request Forgery protection for Web applications . . . . . . . . . . . . . . . . . . . . . 111

Karl-Peter Fuchs, Dominik Herrmann, Hannes Federrath gMix: Eine generische Architektur für Mix-Implementierungen und ihre Umsetzung als Open-Source-Framework . . . . . . . . . . . . . 123 Markus Engelberth, Jan Göbel, Christian Schönbein, Felix C. Freiling PyBox - A Python Sandbox . . . . . . . . . . . . . . . . . . . . . . . 137 Dokumenten- und Netzwerksicherheit Steffen Wendzel The Problem of Traffic Normalization Within a Covert Channel’s Network Environment Learning Phase . . . . . . . . . . . . . . . . . 149 Philipp Trinius, Felix C. Freiling Filtern von Spam-Nachrichten mit kontextfreien Grammatiken . . . . 163 Patrick Wolf, Martin Steinebach FixBit-Container: Effizienter Urheberschutz durch Wasserzeichen entlang der Medien-Wertschöpfungskette . . . . . . . . . . . . . . . . 175 Benutzbarkeit von IT-Sicherheit II Michaela Kauer, Thomas Pfeiffer, Melanie Volkamer, Heike Theuerling, Ralph Bruder It is not about the design - it is about the content! Making warnings more efficient by communicating risks appropriately . . . . . . . . . . 187 Stefan Penninger, Stefan Meier, Hannes Federrath Usability von CAPTCHA-Systemen . . . . . . . . . . . . . . . . . . . 199 Wiebke Menzel, Sven Tuchscheerer, Jana Fruth, Christian Krätzer, Jana Dittmann Designansatz und Evaluation von Kindgerechten Securitywarnungen für Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Authentisierung und Biometrie Markus Ullmann, Ralph Breithaupt, Frank Gehring On-Card“ User Authentication for Contactless Smart Cards based ” on Gesture Recognition . . . . . . . . . . . . . . . . . . . . . . . . . 223 Marcus Quintino Kuhnen, Mario Lischka, Félix Gómez Mármol Triggering IDM Authentication Methods based on Device Capabilities Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Daniel Hartung, Anika Pflug, Christoph Busch Vein Pattern Recognition Using Chain Codes Spatial Information and Skeleton Fusing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

¨ die Cloud - Heisse Luft oder Sicherheits-Forschung fur Wolke Sieben? Christian Cachin IBM Research – Zurich Säumerstrasse 4 CH-8803 Rüschlikon, Schweiz [email protected] Abstract: Seit dem Erscheinen von Cloud-Computing sind viele neue Bedenken gegenüber Big Brother“ aufgekommen. Dennoch nutzen Privatleute und Firmen heu” te die Cloud, weil sie so praktisch ist - und behalten dabei ein mulmiges Gefühl im Bauch zurück. Ihre größten Bedenken betreffen die Sicherheit und Zuverlässigkeit von Cloud-Diensten. Da aber langfristige Erfahrungen mit der Cloud bis heute fehlen, sind beide Größen noch weitgehend Unbekannte. Besondere Sichtbarkeit erlangen daher Forschungsresultate, die darauf abzielen, die Benutzer und ihre Daten vor Problemen in der Cloud zu schützen. Diese Arbeiten sollen Geheimhaltung und Integrität der Daten garantieren und die Zuverlässigkeit der bezogenen Dienste sicherstellen. Dieser Vortrag präsentiert und analysiert einige Trends aus dieser Forschung: erstens, die Verarbeitung von verschlüsselten Daten durch Homomorphic Encryption“, zweitens, die Konsistenz von verteilten Spei” cherdiensten und, drittens, hochverfügbare Systeme, welche auch teilweise von einem Gegner unterwandert noch weiterlaufen können (sog. Byzantine Fault-Tolerant Sys” tems“).

¨ IT Security - Effiziente Organisation uber Governance hinaus Hinrich Voelcker Deutsche Bank Alfred-Herrhausen-Allee 16-24 D-65670 Eschborn [email protected] Abstract: Die Sicherheit der IT-Systeme ist nicht zuletzt durch das breite Interes¨ se der Medien und Offentlichkeit zu einem ausgesprochen wichtigen Thema jedes Wirtschaftunternehmens geworden. Vertraulichkeit, Verfügbarkeit und Integrität der Unternehmens- und Kundendaten ist u¨ berlebenswichtig - gerade in Bezug auf die Reputation. Besonders Banken leben von der Vertrauenswürdigkeit gegenüber ihren Kunden. Während die Regulatoren des Finanzwesens schon immer auf die Einhaltung eines hohen Standards der IT-Sicherheit achteten, richtet sich auch deren Augenmerk noch stärker als bisher auf die Sicherheit der IT-Systeme. Auslöser hierfür sind nicht zuletzt die steigende Anzahl und zunehmende Professionalität von Cyberangriffen gegen Unternehmen zu deren Abwehr die Implementierung von ”Game-ChangingTechnologies”, wie proaktive Cyber-Intelligence-Lösungen, eine immer wichtigere Rolle spielt. Während einzelne Lösungen zur IT-Sicherheit auch nur einzelne Probleme und mögliche Schwachstellen adressieren, ist es besonders in einem Großunternehmen wichtig, ein umfassendes Gesamtkonzept zur erfolgreichen Verteidigung von Cyberangriffen zu gestalten und effizient aufzubauen. Voraussetzung für die Durchsetzung dieses Ziels ist ein zentral aufgestellter IT Security-Bereich mit einer hohen Visibilität und globalen Verantwortung für die Sicherheit der IT-Systeme. Diese Organisationsform spiegelt auch den gewachsenen Stellenwert der IT-Sicherheit in Unternehmen wieder.

Security und Safety - das Yin und Yang der Systemsicherheit? Beispiel Eisenbahnsignaltechnik Jens Braband Siemens AG Ackerstraße 22 D-38126 Braunschweig [email protected] Abstract: Yin und Yang stehen in der chinesischen Philosophie für Gegensätze, z. B. Kräfte oder Prinzipien, in ihrer wechelseitigen Bezogenheit. In diesem Beitrag wird das Bild von Yin und Yang benutzt, um die Beziehungen zwischen Safety und Security am Beispiel der Eisenbahnsignaltechnik zu erläutern. Dabei werden sowohl die normativen Grundlagen als auch typische Anwendungen diskutiert. Insbesondere die in der Eisenbahnsignaltechik verwendeten Referenzarchitekturen sowie die u¨ bliche Kategorisierung von Kommunikationssystemen wird erläutert. Es wird ein Ansatz vorgestellt, der es ermöglichen soll, Safety- und Security-Eigenschaften in der Kommunikationssicherheit soweit möglich zu orthogonalisieren, um insbesondere auch die Aspekte der Zulassung bzw. Zertifizierung soweit möglich zu trennen. Dabei wird auch verschiedene Ansätze zur Zertifizierung eingegangen und konkrete Erfahrungen mit der Erstellung eines Schutzprofils nach Common Criteria werden diskutiert.

Towards a Secure and Trusted Business Web Volkmar Lotz SAP Labs France, Security & Trust Research Practice 805, Avenue du Dr Maurice Donat 06250 Mougins, France [email protected] Abstract: We currently see a major shift in development, deployment and operation of Enterprise IT systems and business applications. Driven by cost and effectiveness considerations, and facilitated by virtual infrastructures (aka the cloud) and service orientation, application development is distributed over a variety of entities (ISPs independent service providers), applications are composed of services from different ISPs, and IT operations is run by independent data and computation centers. Using the Internet as fast and ubiquitous communication infrastructure, we see a fabric of resources, platforms, services and applications emerging forming a number of ecosystems that will drive society and business. For this set of ecosystems and facilitating technology and infrastructure, we have coined the term ”Business Web”. Since the Business Web is going to be the critical infrastructure underlying business and private life, concerns related to security and privacy will inevitably be raised. These concerns are grounded in the open and dynamic nature of the Business Web and its coverage of all aspects of business including the most sensitive areas like finance, healthcare, personal information etc. The strength of the Business Web lies in information sharing and spontaneous interaction with entities, even if they are previously unknown, and there is an inherent risk of information being abused and data owners losing control over their data in terms of usage, consistency or availability. To mitigate these risk while being able to exploit the benefits of collaboration, one needs to determine with whom the collaboration takes place, to express which mutual protection needs are to be met, and which controls can be imposed to actually enforce them. In this talk, we focus on the establishment of trust in services and the complementary support of data-centric services. In addition to traditional means based on observation, recommendation, and reputation which come to their limits upon discovery of new services, rich service descriptions including security and privacy related attributes, attested by trusted parties, provide the needed information and form a service identity where the mere name of the service would not be meaningful. At the same time, such descriptions can serve as a container for policy information expressing the service’s protection needs, its abilities to match consumers’ policies and its governance. Given that the user can express her policies in a similar, machine-processable way, we are able to match policies and decide if the service can be safely used. When considering the complexity of Business Web structures, however, we have to ensure that the above approach scales to multiple layers of dynamic collaboration. Data are travelling across domains, services and resources, while still being subject to their owners’ policies. This motivates a data-centric security concept, where policies are bound to data and travel with them - ßticky policies”. Each processor of the data, even if it cannot be predicted where they will eventually end up, has access to the policy information and can handle the data accordingly. Sticky policies allow for the

Towards a Secure and Trusted Business Web

expression of obligations (like a deletion or retention period) to be met by processing entities. While this concept is theoretically pleasing, it faces practical challenges of performance and enforcement asking for further research. We show how a solution meeting some of these challenges can be provided on top of a distributed Java platform.

5

A Practical View of Privacy Preserving Biometric Authentication Xuebing Zhou Center for Advanced Security Research Darmstadt Mornewegstraße 32 D-64293 Darmstadt [email protected] Abstract: Recently, biometric market is growing rapidly and biometric applications can be found in diverse areas such as border control, banking, ID-documents, access control, etc. However, usage of personal biometric information can harm privacy of users and raise problems of cross matching and identity theft. Privacy preserving techniques like template protection are an important supplement to biometric systems to prevent abuse of stored biometric information and to improve security of biometric authentication. This work introduces the concept of biometric privacy preserving techniques and shows how to quantify their security and privacy in practice with help of a generalized evaluation framework. The advantages as well as limitations of the existing methods are analyzed. Additionally, systematic security considerations are given and a guideline to successfully design privacy preserving techniques for biometric systems is proposed.

Mentale Modelle der IT-Sicherheit bei der Nutzung mobiler Endgeräte Zinaida Benenson Universität Erlangen-Nürnberg [email protected]

Olaf Kroll-Peters EnBW AG [email protected]

Matthias Krupp Universität Mannheim [email protected] Abstract: Mobile Endgeräte werden immer leistungsfähiger und damit wächst für die Nutzer auch das Gefahrenpotenzial durch typische IT-Sicherheitsbedrohungen. Obwohl die Verantwortung des Benutzers für die Einhaltung der IT-Sicherheit anerkannt und wissenschaftlich belegt ist, konzentriert sich die Forschung zur IT-Sicherheit im mobilen Umfeld meistens auf die technische Seite der Problematik. In dieser Arbeit wird der erste Schritt zur Untersuchung der Rolle der Benutzer in der IT-Sicherheit mobiler Endgeräte unternommen, indem anhand von Interviews entsprechende mentale Modelle erstellt werden. Als mentale Modelle werden Abbildungen der Realität im Bewusstsein des Menschen bezeichnet. Obwohl diese Abbildungen normalerweise ungenau und oft fehlerhaft sind, kann ihre Kenntnis zu Prognosen u¨ ber Handlungen von Menschen verwendet werden. Mentale Modelle der IT-Sicherheit bilden die Grundlage für die Bemühungen der Nutzer (oder für das Fehlen solcher Bemühungen), die IT-Sicherheit ihrer Systeme zu gewährleisten.

1 Einleitung Die Anzahl sowie Leistungsfähigkeit mobiler Endgeräte nimmt im Verlauf der letzten Jahre immer stärker zu und damit wächst auch die Anzahl der IT-Sicherheitsbedrohungen in diesem Bereich [Jun11, BFH+ 11]. Auf der einen Seite sind die Anwender technischen Bedrohungen wie Malware, das Abhören der Datenübermittlung und das Ausspähen von Standortinformationen ausgesetzt. Auf der anderen Seite bestehen auch menschliche Bedrohungen wie Verlust, Diebstahl, Fehlbedienung und Social Engineering. In beiden Fällen nehmen Benutzer einen bedeutenden Anteil für das Umsetzen von IT-Sicherheit mobiler Endgeräte ein. Zum Beispiel ist zum Installieren der mobilen Malware meistens nach wie vor die aktive Teilnahme der Benutzer notwendig. Bisher ist die Rolle der Benutzer in der Sicherheit mobiler Endgeräte nicht ausreichend bekannt. In dieser Arbeit unternehmen wir die ersten Schritte zur Feststellung mentaler Modelle der IT-Sicherheit bei der Benutzung mobiler Endgeräte. Mentale Modelle charakterisieren die individuelle Repräsentation und das Verständnis von Realität, beeinflusst durch Erfahrungen, Empfindungen und Informationen, im Bewusstsein von Menschen.

8

Mentale Modelle der IT-Sicherheit bei der Nutzung mobiler Endgeräte

¨ Im Abschnitt 2 wird zunächst ein Uberblick u¨ ber verwandte Arbeiten zu mentalen Modellen der IT-Sicherheit gegeben. Dann wird im Abschnitt 3 unsere Untersuchung zur Ermittlung mentaler Modelle der IT-Sicherheit bei der Benutzung mobiler Endgeräte vorgestellt. Anschließend werden im Abschnitt 4 die Ergebnisse der Arbeit diskutiert und schließlich im Abschnitt 5 weiterführende Arbeiten vorgeschlagen.

2 Mentale Modelle in der IT-Sicherheit Erste mentale Modelle für den Themenkomplex der IT-Sicherheit erstellten Camp et al. [ALC07, Cam09]. Sie unterscheiden fünf Metaphern der IT-Sicherheit: physische Sicherheit (z.B. Schlösser), medizinische Infektionen (Viren), kriminelles Verhalten (Einbrecher), Kriegsführung und wirtschaftliches Versagen (Schwachstellen in der Software). Implizite Beschreibungen der mentalen Modelle der IT-Sicherheit finden sich häufig in Publikationen zum Themenkomplex der Mensch-Computer-Interaktion. So fanden Sasse et al. [SBW01] heraus, dass die Kenntnisse der Nutzer nicht ausreichend sind, um die bestehenden Sicherheitsbedrohungen richtig einzuordnen. Norman [Nor09] beobachtet, dass die Anwender sogar die Installation essentieller Sicherheitspatches abgelehnt haben aus Angst etwas Falsches zu installieren. Ihr mentales Modell lautet: Installieren neuer ” Software ist gefährlich“. Häufig sind die Anwender aufgrund fehlender Kenntnisse nicht in der Lage zwischen sicheren und unsicheren Installationsanfragen zu unterscheiden. Inakkurate mentale Modelle schaffen oft weitere Gefahrenquellen [RHJ+ 10]. Unter anderem erstellen Anwender eigene Regeln im Umgang mit IT-Systemen, wie z.B. nur scheinbar sichere Passwörter, die ihnen besser im Gedächtnis bleiben [AS99, FH07, FCB07]. Für die Anwender ist ihr sicherheitskonformes Handeln eine Kosten-/Nutzen-Kalkulation [Her09]. Werden die Kosten als zu hoch wahrgenommen, entsteht die Vorstellung Sicherheitsmechanismen sind ein Hindernis, das es zu umgehen gilt“. Nach Ansicht von ” Lampson [Lam09] hat sich bei vielen Anwendern ein Sag OK zu jeglichen Sicherheits” fragen“-Modell entwickelt. Die zunehmende Anzahl von Checkboxen, die eine Rückmeldung der Nutzer haben möchten, haben dazu geführt, dass die Anwender herausgefunden haben, welchen Knopf sie drücken müssen, um ungestört ihrer Arbeit weiter nachgehen zu können [SEA+ 09, KFR10]. Ein weiterer Einflußfaktor auf das Bild der IT-Sicherheit vieler Anwender ist ihr soziales Umfeld. Verhalten sich Anwender sicherheitsbewusst, werden sie oft als paranoid“ oder pedan” ” tisch“ beschrieben [SBW01, WS01] oder als eine Person, die niemandem vertraut. Da die Anwender sehr viel Wert darauf legen von ihrem Umfeld akzeptiert zu werden, gehen sie sogar so weit offen zuzugeben, dass sie stolz darauf sind, Sicherheitsmechanismen nicht zu verstehen oder nicht zu befolgen [SBW01]. Die obigen Publikationen beschreiben mentale Modelle der Anwender zur IT-Sicherheit der klassischen“ Rechnersysteme. Bei der Nutzung mobiler Endgeräte fehlen jedoch bis” her mentale Modelle der IT-Sicherheit. Im folgenden Abschnitt wird unser Vorgehen zur


9

Erstellung solcher mentalen Modelle sowie die daraus resultierenden Ergebnisse vorgestellt.

3 Studien zur IT-Sicherheit bei der Nutzung mobiler Endgeräte ¨ Ein erster Uberblick u¨ ber den Themenkomplex Anwender und ihr mobiles Endgerät“ ” wurde durch die Erstellung einer Pilotstudie verschafft. In der Hauptuntersuchung wurden anschließend mentale Modelle der IT-Sicherheit bei der Nutzung mobiler Endgeräte erstellt. Beide Untersuchungen wurden anhand eines Fragebogens als Leitfaden-Interviews durchgeführt.

3.1

Pilotstudie

In der Pilotstudie wurde die Nutzung mobiler Endgeräte betrachtet. Es haben sich zwei mentale Grundmodelle bei der Nutzung mobiler Endgeräte herauskristallisiert. Zum einen gibt es Anwender, die ihr Endgerät nur als konventionelles Telefon-Gerät sehen. Trotz eines deutlich größeren Funktionsumfanges, nutzen sie ihr Gerät fast ausschließlich zum Telefonieren oder Schreiben von Kurznachrichten. Zum anderen gibt es Nutzer, die ihr Endgerät als Smartphone sehen. Bei diesen u¨ bersteigt die tägliche Nutzung deutlich den Rahmen konventioneller Telefon-Geräte: sie surfen im Internet, schreiben E-Mails oder tauschen sich u¨ ber soziale Netzwerke aus. Diese mentalen Grundmodelle ( Telefon“ vs. ” Smartphone“) wurden in der Hauptuntersuchung detaillierter betrachtet. ” Weiter konnte in der Pilotstudie festgestellt werden, dass sich Nutzer wenig mit der ITSicherheit ihres Endgeräts befassen. Sie fühlen sich oft sicher bei der Nutzung ihres mobilen Endgeräts, ohne sich in den Themenkomplex einzuarbeiten oder eigene Anstrengungen für IT-Sicherheit im mobilen Umfeld zu unternehmen.

3.2

Hauptuntersuchung

Das Ziel der Hauptuntersuchung war eine detaillierte Beschreibung der Sichtweise der Nutzer auf die IT-Sicherheit ihrer mobilen Endgeräte. 3.2.1

Hypothesen

Auf Grundlage der Untersuchungen und Ergebnisse der Pilotstudie wurden unter anderem folgende Hypothesen aufgestellt: • H1: Benutzer, die ihr Gerät als Smartphone sehen, haben ein größeres Sicherheitsbewusstsein als Benutzer, die ihr Gerät als Telefon sehen.

10


• H2: Benutzer, die ihr Gerät als Smartphone sehen, fühlen sich weniger sicher, als Benutzer, die ihr Gerät als Telefon sehen. • H3: Benutzer sehen sich selbst nicht für die Sicherheit ihrer Geräte verantwortlich. • H4: Benutzer bringen Probleme bei der Benutzung ihres Endgeräts nicht mit ITSicherheit in Verbindung. • H5: Um für ihre IT-Sicherheit im mobilen Umfeld zu sorgen, ist die Hauptanstrengung der Benutzer der bewusste Umgang mit dem Gerät. Die beiden Begriffe Sicherheitsbewusstsein“ und bewusster Umgang“ werden weiter ” ” unten erläutert. Eine ausführliche und vollständige Beschreibung der Hypothesen und der dazugehörigen Ergebnisse findet sich in Krupp [Kru11]. 3.2.2

Versuchsbeschreibung

Um die aufgestellten Hypothesen zu evaluieren, wurden persönliche Leitfragen-Interviews mit 24 Versuchspersonen durchgeführt. Das Alter der Befragten lag zwischen 18 und 50 Jahren, die Hälfte war männlich und fünf waren beruflich im IT-Umfeld tätig. Die Interviews orientierten sich an einem zweiteiligen Fragebogen (s. Anhang A). Die Schwierigkeit einer aussagekräftigen Evaluation besteht darin, dass sich die Teilnehmer dem Untersuchungsfokus und der Untersuchungssituation nicht bewusst sein dürfen, da sie sich sonst anders verhalten als bei einer Entscheidungsfindung im Alltag [RWN02]. Daher wurde bei der Erstellung der Fragen darauf geachtet, dass die Teilnehmer zumindest von Anfang an nicht wussten, dass sie in Bezug auf IT-Sicherheit untersucht wurden. Im ersten Teil der Interviews stand die Nutzung mobiler Endgeräte im Fokus. Hierbei wurden die Teilnehmer unter anderem zu regelmäßig genutzten Diensten, zu Eigenschaften, die sie mit der Nutzung mobiler Endgeräte verbinden, zu Problemen bei deren Nutzung und Kenntnissen zum Schutz mobiler Endgeräte befragt. Weiterhin wurde gefragt zu welchem Anteil sie sich selbst und die Hersteller von Programmen oder Hardware in der Verantwortung für die Umsetzung von IT-Sicherheit bei mobilen Endgeräten sehen. Der zweite Teil des Fragebogens konzentrierte sich auf die Anstrengungen der Befragten zur Sicherstellung von IT-Sicherheit. Hierbei mussten sie angeben wie groß ihr Interesse an der Sicherheit ihres Endgerätes ist und welche Anstrengungen sie für die Umsetzung unternehmen. Ob sie sich bei der Nutzung ihres Endgeräts sicher fühlen und welche Daten ihrer Meinung nach auf dem Endgerät bedroht sind. Abschließend wurde eine Frage zu einer erweiterten Sicherheitseinstellung gestellt, um die Selbsteinschätzung der Befragten bezüglich ihrer Kenntnisse besser einordnen zu können. 3.2.3

Evaluierung der Hypothesen

H1: Benutzer, die ihr Gerät als Smartphone sehen, haben ein größeres Sicherheitsbewusstsein als Benutzer, die ihr Gerät als Telefon sehen. Unter Sicherheitsbewusstsein


11

verstehen wir einen Komplex aus dem Wissen u¨ ber die IT-Sicherheit und dem Interesse an IT-Sicherheit. Insgesamt sahen elf Befragte ihr Endgerät als konventionelles Telefon und 13 als Smartphone. Sieben der 13 Befragten (54 %), die ihr mobiles Endgerät als Smartphone sehen, gaben an, dass sie u¨ ber gute Kenntnisse zum Schutz mobiler Endgeräte verfügen würden (s. Abbildung 1(a)). Fünf der Smartphone-Benutzer (38 %) ordneten sich mit Grundkenntnissen ein. Die Hälfte dieser Benutzer beantwortete die Kontrollfrage korrekt.

(a) Wie schätzen Sie ihr Wissen bezüglich des möglichen Schutzes ihres mobilen Endgeräts ein?

(b) Wie schätzen Sie ihr Interesse bezüglich der Sicherheit von mobilen Endgeräten und ihrer Daten ein?

Abbildung 1: Ergebnisse zu Hypothese 1

Bei den 11 Befragten, die ihr Endgerät als Telefon sehen, gaben lediglich vier Befragte an, dass sie mindestens gute Kenntnisse u¨ ber den Schutz mobiler Endgeräte verfügen. Nur einer dieser Anwender konnte ebenfalls die Kontrollfrage korrekt beantworten. Zu den insgesamt schlechteren Kenntnissen der Telefon-Anwender kommt hinzu, dass diese im Allgemeinen kein all zu großes Interesse an der Sicherheit ihres Endgeräts haben. Abbildung 1(b) zeigt, dass sechs der elf Befragten nur ein geringes bzw. gar kein Interesse an der Sicherheit ihres Endgeräts haben. Bei den Befragten, die ihr Endgerät als Smartphone sehen, ist das Interesse sichtbar stärker ausgeprägt. Sechs Studienteilnehmer gaben ein mittleres, weitere sechs ein hohes Interesse an. Die Teilnehmer wurden in einer offenen Frage zu ihnen bekannten Bedrohungen im mo¨ bilen Umfeld befragt. Die Gruppierung der Antworten ergab eine Ubereinstimmung zu den sechs Gruppierungen des Malicious Mobile Threats Report 2010/2011“ von Juniper ” [Jun11]: Abhören von Datenübermittlungen, Ausnutzung/Fehlverhalten, Erstellung von Bewegungsprofilen/Ortung, Direkte Angriffe, Malware sowie Verlust/Diebstahl. Korreliert man die Anzahl der genannten Bedrohungsklassen der Anwender mit deren selbst eingeschätzten Kenntnissen, zeigt sich, dass viele Anwender, die sich mit guten Kenntnissen einordneten, mehr Bedrohungen nennen konnten (s. Abbildung 2). Vergleicht man die Ergebnisse der beiden mentalen Grundmodellen, so wird deutlich, dass die Smartphone-Anwender mehr Bedrohungen als die Telefon-Anwender nennen konnten und ihre Kenntnisse verhältnismäßig gut eingeschätzt haben. Hierzu besteht jedoch weiterer Forschungsbedarf, da die Anzahl der Befragten insgesamt zu gering war.

12


Abbildung 2: Anzahl der genannten Bedrohungen in Relation zu den eingeschätzten Kenntnissen

Zusammenfassend zeigen die Ergebnisse, dass Anwender, die ihr mobiles Endgerät als Smartphone sehen, bessere Kenntnisse zum Schutz und ein größeres Interesse an der Sicherheit mobiler Endgeräte haben. Somit konnte die erste Hypothese belegt werden.

(a) Fühlen Sie sich bei der Benutzung ihres Endgeräts sicher?

(b) Welche Daten auf ihrem Endgerät sind ihrer Meinung nach bedroht?

Abbildung 3: Ergebnisse zu Hypothese 2

¨ H2: Benutzer, die ihr Gerät als Smartphone sehen, fuhlen sich weniger sicher, als Benutzer, die ihr Gerät als Telefon sehen. 17 der 24 Befragten gaben an, dass sie sich bei der Nutzung ihres mobilen Endgeräts sicher fühlen (s. Abbildung 3(a)). Dies zeigt ein insgesamt hohes Sicherheitsgefühl der Anwender. Die Betrachtung der beiden Grundmodelle zeigt, dass sich deutlich weniger Smartphone-Anwender bei der Nutzung ihres Endgeräts sicher fühlen. Gründe für die Unsicherheit sind nach Ansicht dieser ¨ Nutzer die Uberwachung von Datenflüssen und das Aufzeichnen von Standortdaten. Das höhere Sicherheitsempfinden der Telefonanwender führten diese darauf zurück, dass sie mit ihrem Endgerät nicht ins Internet gehen. Als weitere Gründe gaben sie an, dass sie nicht wichtig genug für einen Angreifer wären und dass sie keine wichtigen Daten auf


13

ihrem Endgerät hätten. Abbildung 3(b) zeigt, dass nach Ansicht aller Befragten besonders das Adressbuch und Telefonbuch sowie die Standortinformationen auf dem mobilen Endgerät bedroht sind. Die Telefon-Anwender sehen durchschnittlich deutlich weniger Daten auf dem mobilen Endgerät bedroht. Damit kann die zweite Hypothese belegt werden. ¨ die Sicherheit ihrer Geräte verantwortlich. H3: Benutzer sehen sich selbst nicht fur Um herauszufinden bei wem die Befragten die Verantwortung für die Sicherheit mobiler Endgeräte sehen, wurden sie gebeten, den Programmherstellern, Hardwareherstellern und sich selbst einen prozentualen Anteil der Verantwortung zuzuteilen. Es zeigte sich, dass nach Ansicht der Befragten fast die Hälfte der Verantwortung auf die Programmhersteller fällt (s. Abbildung 4). Die Hersteller von Hardware und den Benutzer selbst sehen die Befragten zu jeweils einem Viertel in der Verantwortung.

Abbildung 4: Wer sollte für die Sicherheit von mobilen Endgeräten verantwortlich sein?

Anwender, die ihr Gerät als Telefon sehen, sehen den Benutzer am wenigsten in der Verantwortung für die Sicherheit. Dagegen sehen die Smartphone-Nutzer die Programmhersteller und den Benutzer zum gleichen Prozentanteil verantwortlich. Anhand dieser Ergebnisse kann die dritte Hypothese belegt werden, denn die Benutzer zeigen eine deutliche Präferenz dazu, den Programm- und Hardwareherstellern die Verantwortung für die Sicherheit ihrer Geräte zu geben. Jedoch sehen insbesondere SmartphoneAnwender einen Teil der Verantwortung bei sich selbst. Inwieweit sie bereit sind, diese Verantwortung zu u¨ bernehmen, bedarf weiterer Forschung. H4: Benutzer bringen Probleme bei der Benutzung ihres Endgeräts nicht mit ITSicherheit in Verbindung. Im Zuge des ersten Teils der Befragung wurden die Teilnehmer gefragt, ob sie bei der Nutzung ihrer Geräte bisher Probleme hatten. Sieben der 24 Befragten gaben ein Problem an. Die geschilderten Probleme ließen sich alle auf die Bedienung bzw. Eigenheiten des Endgeräts zurückführen, wie z.B. das Aufhängen bzw. Abstürzen des Geräts, eine schlechte Akkulaufzeit, Probleme mit dem Betriebssystem oder ein unzureichender Funktionsumfang.

14


Als die Teilnehmer im zweiten Teil der Befragung explizit zu sicherheitskritischen Problemen bei der Nutzung mobiler Endgeräte befragt wurden, gab ein Teilnehmer an, dass er bisher ein sicherheitskritisches Problem hatte. Durch das versehentliche Klicken eines Hyperlinks beim Surfen im Internet sei er in eine Abo-Falle geraten. Bei der allgemein gehaltenen Frage zu Problemen bei der Nutzung gab er dieses Problem jedoch nicht an. Auch in der Pilotstudie wurde die Beobachtung gemacht, dass mehrere Teilnehmer zwar Probleme bei der Nutzung mit ihrem Endgerät angaben, dabei aber keine Sicherheitsprobleme erwähnten. Zwei Benutzer gaben auch dort sicherheitskritische Probleme erst dann an, als sie explizit darauf angesprochen wurden. Somit kann belegt werden, dass die sicherheitskritischne Probleme sich bei der Nutzung mobiler Endgeräte nicht in den mentalen Modellen der Anwender verankert haben. Das könnte damit zusammenhängen, dass die Teilnehmer bisher sehr wenig mit solchen Problemen konfrontiert wurden. ¨ ihre IT-Sicherheit im mobilen Umfeld zu sorgen, ist die HauptanstrenH5: Um fur gung der Benutzer der bewusste Umgang mit dem Gerät. Die Interviewpartner wurden gebeten, anhand vorgegebener Sicherheitsvorkehrungen anzugeben, welche Anstrengungen sie unternehmen, um für die eigene IT-Sicherheit im mobilen Umfeld zu sorgen. Bewusster Umgang mit dem Gerät ist die populärste Sicherheitsmaßnahme (s. Tabelle 1). Nur 8 % der Befragten gaben an, dass sie sich nie mit dem bewussten Umgang ihres Endgeräts auseinandersetzen. Während die Mehrzahl der Smartphone-Anwender versucht immer auf einen bewussten Umgang zu achten, gaben 64 % der Telefon-Anwender an, sich gelegentlich darum zu kümmern. Unter bewusstem Umgang verstehen die Teilnehmer, dass sie unter anderem bei der Nutzung ihres Endgeräts darauf achten, welche Applikationen sie installieren und nutzen und dass sie verantwortungsbewusst im Internet unterwegs sind. Des Weiteren informiert sich nur ein Viertel nicht u¨ ber IT-Sicherheitsrisiken. Hierunter ist fast die Hälfte aller Anwender, die ihr Endgerät als Telefon sehen. Die restlichen Befragten informieren sich in der Regel gelegentlich u¨ ber aktuelle Gefahren.

Technische Sicherheitsmaßnahmen werden seltener eingesetzt. 38 % aller Befragten nutzen regelmäßig den Passwortschutz auf ihren mobilen Endgeräten und 21 % nutzen ihn gelegentlich. Insbesondere fallen die 62 % der Smartphone-Anwender auf, die den Pass¨ wortschutz regelmäßig einsetzen. Ahnliche Werte gelten für Updates, Virenscanner sind weniger populär. Im PC-Umfeld dagegen gibt es regelmäßig Studien, die zeigen, dass u¨ ber 75 % einen Virenscanner auf ihrem PC installiert haben [BIT10, BSI11]. Gründe für diese Ergebnisse könnten u.a. in den Voreinstellungen der Geräte liegen, wurden in dieser Arbeit jedoch nicht weiter untersucht. Somit konnte die fünfte Hypothese belegt werden. 88 % der Teilnehmer gaben an wenigstens gelegentlich auf den bewussten Umgang mit dem mobilen Endgerät zu achten. Nach


mentales Grobmodel Passwortschutz Updates Virenscanner bewusster Umgang Informieren u¨ ber ITSicherheitsrisiken

Gesamt Telefon Smartphone Gesamt Telefon Smartphone Gesamt Telefon Smartphone Gesamt Telefon Smartphone Gesamt Telefon Smartphone

Ich versuche immer auf dem aktuellsten Stand zu sein 38% 9% 62% 42% 9% 69% 21% 9% 31% 46% 9% 77% 17% 0% 31%

Ich kümmere mich gelegentlich um die Thematik 21% 27% 15% 21% 27% 15% 13% 18% 8% 42% 64% 23% 50% 36% 62%

Ich kümmere mich gar nicht um die Thematik 25% 45% 8% 21% 45% 0% 42% 55% 31% 8% 18% 0% 25% 45% 8%

15

Weiß ich nicht 17% 18% 15% 17% 18% 15% 25% 18% 31% 4% 9% 0% 8% 18% 0%

Tabelle 1: Welche eigenen Anstrengungen unternehmen Sie um für ihre IT-Sicherheit im mobilen Umfeld zu sorgen?

Ansicht der Interviewpartner sind sie so lange sicher vor Bedrohungen, so lange sie sich vorsichtig und gewissenhaft verhalten sowie selbst keine Fehlerzustände verursachen.

4 Mentale Modelle der Sicherheit mobiler Endgeräte Unsere Untersuchung zeigt, dass die Benutzer der mobilen Endgeräte in zwei Kategorien unterteilt werden können, die sich deutlich hinsichtlich ihrer Einstellung zur IT-Sicherheit ihrer Geräte unterscheiden. Die mein Gerät ist ein Telefon“-Einstellung ist unabhängig ” vom Funktionsumfang des Geräts und hängt mit einem niedrigeren Sicherheitsbewusstsein und einem höheren Sicherheitsgefühl zusammen, als die mein Gerät ist ein Smartphone“” Einstellung. Insbesondere Telefon-Benutzer“ sehen sich selbst nicht für die Sicherheit ” ihrer Geräte verantwortlich und befassen sich insgesamt wenig mit der Thematik. Es zeigte sich, dass viele Nutzer ein solange ich nicht ins Internet gehe, bin ich sicher“” mentales Modell haben. Außerdem glauben viele Benutzer, dass sie persönlich nicht bedroht sind, da sie nicht wichtig genug sind oder keine wichtigen Daten auf ihrem Gerät speichern. Hier sind die Parallelen zur Risikoeinschätzung in der PC-Welt deutlich sichtbar [Sch08, Wes08]. Im Allgemeinen scheinen die Benutzer jedoch weniger Parallelen zwischen der PC-Welt und der mobilen Welt zu ziehen, da sie die Probleme bei der Nutzung mobiler Endgeräte nicht mit IT-Sicherheit sondern ausschließlich mit der Bedienung und den Eigenheiten der Geräte in Verbindung bringen. Außerdem werden technische Schutzmaßnahmen in der mobilen Welt deutlich weniger eingesetzt als in der PC-Welt.

16


Zum Schutz im mobilen Umfeld beschränken sich die Anstrengungen zur Zeit fast ausschließlich auf den bewussten Umgang mit dem Gerät. Die Befragten gaben unter anderem an, dass sie sichere Applikationen nutzen, auf unseriöse Dienste verzichten und nicht ungeachtet jegliche Links anklicken würden. Zusätzlich hielten sie ihr Datenvolumen so niedrig wie möglich und achten darauf, nicht ungeschützt u¨ ber Verbindungsprotokolle wie beispielsweise Bluetooth oder WLAN erreichbar zu sein. Es scheint, dass viele Benutzer ein ich werde Gefahren für mein Gerät auf jeden Fall ” erkennen können“-mentales Modell haben. Ob dieses Modell tatsächlich funktioniert, ist zweifelhaft, wenn man Parallelen zur PC-Welt zieht [DTH06, DHC06, SEA+ 09, RHJ+ 10]. Es ist auch unklar, ob die meisten Anwender noch keine Sicherheitsprobleme mit ihren Endgeräten hatten oder ob sie solche Probleme noch nicht erkannt haben.

¨ 5 Fazit und Weiterfuhrende Arbeiten Unsere Studie zeigte erste Einblicke darin, wie die Nutzer die Sicherheit ihrer mobilen Endgeräte wahrnehmen und wie sie ihre Geräte schützen. Obwohl die Nutzer wissen, dass viele Daten auf ihrem mobilen Endgerät bedroht sind, fühlen sie sich bei der Nutzung zum Großteil sicher. Unternehmen die Befragten eigene Anstrengungen für den Schutz im mobilen Umfeld, konzentrieren sich diese häufig auf den bewussten Umgang mit dem Gerät. Anwender mit guten Kenntnissen nehmen zusätzlich zum Schutz technische Sicherheitsvorkehrungen, wie das Nutzen eines Passwortschutzes oder das regelmäßige Installieren von Updates, vor. Insgesamt ergab unsere erste Untersuchung mehr Fragen als Antworten, so dass weiterer Forschungsbedarf besteht. Es ist z.B. nicht ausreichend bekannt, wie gut die Selbsteinschätzung der Nutzer zu ihren Sicherheitskenntnissen mit den tatsächlichen Kenntnissen korreliert. Der bewusste Umgang mit dem mobilen Endgerät stellte sich als Hauptanstrengung der Nutzer zur Sicherstellung von IT-Sicherheit im mobilen Umfeld dar. Die Nutzer beschrieben den bewussten Umgang häufig damit, dass sie keine unseriösen Applikationen installieren, auf ihr Surfverhalten im Internet achten und nicht ungeschützt u¨ ber Kommunikationsschnittstellen wie Bluetooth oder WLAN erreichbar sind. Hierbei ist von Interesse, ob die Anwender ein gemeinsames Bild des bewussten Umgangs haben und ob sie auch unsichere Handlungen mit dem bewussten Umgang verbinden. Darüber hinaus stellt sich die Frage, ob die Anwender tatsächlich u¨ ber ausreichend Wissen verfügen, um die Unterscheidung zwischen sicheren und unsicheren Applikationen, Links und Einstellungen des Geräts vornehmen zu können. Ein weiterer Punkt für zukünftige Untersuchungen ist die Frage, ob die Nutzer unterschiedliche Sichtweisen auf PCs und auf mobile Endgeräte haben. Moderne mobile Endgeräte werden immer leistungsfähiger, haben einen immer größeren Funktionsumfang und a¨ hneln immer mehr den PCs. Dennoch scheinen die Anwender noch wenige Parallelen zur PC-Welt zu ziehen und schützen sich im PC-Umfeld in viel stärkerem Maße, obwohl immer mehr Bedrohungen identisch sind.


17

Literatur [ALC07]

Farzaneh Asgharpour, Debin Liu und L. Jean Camp. Mental models of security risks. In Proceedings of the 11th International Conference on Financial cryptography and 1st International conference on Usable Security, FC’07/USEC’07, Seiten 367–377, Berlin, Heidelberg, 2007. Springer-Verlag.

[AS99]

Anne Adams und Martina Angela Sasse. Users are not the enemy. Commun. ACM, 42:40–46, December 1999.

[BFH+ 11] M. Becher, F.C. Freiling, J. Hoffmann, T. Holz, S. Uellenbeck und C. Wolf. Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices. In Security and Privacy (SP), 2011 IEEE Symposium on, Seiten 96–111, may 2011. [BIT10]

BITKOM. Internet-Sicherheit. Studie, Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V., Februar 2010.

[BSI11]

BSI. Mit Sicherheit. BSI Jahresbericht 2010, Bundesamt für Sicherheit in der Informationstechnik, Juli 2011.

[Cam09]

L. J. Camp. Mental models of privacy and security. Technology and Society Magazine, IEEE, 28(3):37–46, Fall 2009.

[DHC06]

Julie S. Downs, Mandy B. Holbrook und Lorrie Faith Cranor. Decision strategies and susceptibility to phishing. In Proceedings of the second symposium on Usable privacy and security, SOUPS ’06, Seiten 79–90, 2006.

[DTH06]

Rachna Dhamija, J. D. Tygar und Marti Hearst. Why phishing works. In Proceedings of the SIGCHI conference on Human Factors in computing systems, CHI ’06, Seiten 581–590, 2006.

[FCB07]

Alain Forget, Sonia Chiasson und Robert Biddle. Helping users create better passwords: is this the right approach? In Proceedings of the 3rd symposium on Usable privacy and security, SOUPS ’07, Seiten 151–152, 2007.

[FH07]

Dinei Florencio und Cormac Herley. A large-scale study of web password habits. In Proceedings of the 16th international conference on World Wide Web, WWW ’07, Seiten 657–666, 2007.

[Her09]

Cormac Herley. So long, and no thanks for the externalities: the rational rejection of security advice by users. In Proceedings of the 2009 workshop on New security paradigms workshop, NSPW ’09, Seiten 133–144, 2009.

[Jun11]

Juniper Networks. Malicious Mobile Threats Report 2010/2011: An Objective Briefing on the Current Mobile Threat Landscape Based on Juniper Networks Global Threat Center Research. Juniper Networks, Inc., 2011.

[KFR10]

R. Kainda, I. Flechais und A.W. Roscoe. Security and Usability: Analysis and Evaluation. In Availability, Reliability, and Security, 2010. ARES ’10 International Conference on, Seiten 275–282, 2010.

[Kru11]

Matthias Krupp. Die Verantwortung von Nutzern zur Umsetzung von IT-Sicherheit, Masterarbeit, 2011.

[Lam09]

Butler Lampson. Privacy and security: Usable security: how to get it. Commun. ACM, 52:25–27, November 2009.

18

[Nor09]


Donald A. Norman. THE WAY I SEE IT: When security gets in the way. interactions, 16:60–63, November 2009.

[RHJ+ 10] Fahimeh Raja, Kirstie Hawkey, Pooya Jaferian, Konstantin Beznosov und Kellogg S. Booth. It’s too complicated, so i turned it off!: expectations, perceptions, and misconceptions of personal firewalls. In Proceedings of the 3rd ACM workshop on Assurable and usable security configuration, SafeConfig ’10, Seiten 53–62, 2010. [RWN02] K. Rudolph, G. Warshawsky und L. Numkin. Security Awareness. In M.E. Kabay, Hrsg., Computer Security Handbook, Kapitel 29. John Wiley & Sons, Inc., Basel, 4. Auflage, 2002. [SBW01]

M. A. Sasse, S. Brostoff und D. Weirich. Transforming the ’Weakest Link’ – a Human/Computer Interaction Approach to Usable and Effective Security. BT Technology Journal, 19:122–131, July 2001.

[Sch08]

Bruce Schneier. The psychology of security. http://www.schneier.com/essay-155.html, Januar 2008.

[SEA+ 09] Joshua Sunshine, Serge Egelman, Hazim Almuhimedi, Neha Atri und Lorrie Faith Cranor. Crying wolf: an empirical study of SSL warning effectiveness. In Proceedings of the 18th conference on USENIX security symposium, SSYM’09, Seiten 399–416, Berkeley, CA, USA, 2009. USENIX Association. [Wes08]

Ryan West. The psychology of security. Commun. ACM, 51:34–40, April 2008.

[WS01]

Dirk Weirich und Martina Angela Sasse. Pretty good persuasion: a first step towards effective password security in the real world. In Proceedings of the 2001 workshop on New security paradigms, NSPW ’01, Seiten 137–143, 2001.


19

A Anhang

Fragebogen zur Nutzung von mobilen Endgeräten

Einleitung zum Fragebogen: Ziel des Fragebogens ist es das Verhalten von Anwendern im Umgang mit mobilen Endgeräten (Handys und Smartphones) zu untersuchen. Der Fragebogen besteht aus zwei Teilen. Der erste Teil besteht aus einigen einleitenden und grundlegenden Fragen zur Nutzung von mobilen Endgeräten. Im zweiten Teil steht darauf aufbauend die weitere Nutzung von mobilen Endgeräten im Fokus.

Hinweis zum Datenschutz: Die Daten werden anonymisiert erhoben und dienen nur zu Forschungszwecken. Der Fragebogen ist so konzipiert, dass kein Rückschluss auf den Befragten möglich ist. Falls Sie eine Frage nicht beantworten möchten oder können, lassen Sie die Antwort einfach offen.

¨ ihre Bereitschaft den Fragebogen auszufullen! ¨ Vielen Dank fur

20


Teil A 1. Ihr Geschlecht: ❐ Weiblich

❐ Männlich

2. Ihr Alter: ❐ jünger als 21 ❐ 26 - 30 ❐ 36 - 40 ❐ 46 - 50 ❐ 56 - 60

❐ 21 - 25 ❐ 31 - 35 ❐ 41 - 45 ❐ 51 - 55 ❐ 61 oder a¨ lter

3. Welchen Beruf u¨ ben Sie aus? Welche Fachrichtung?

4. Besitzen Sie privat ein mobiles Endgerät (Handy oder Smartphone)? ❐ Ja ❐ Nein 5. Spielt das Betriebssystem ihres mobilen Endgeräts für Sie eine relevante Rolle? ❐ Ja ❐ Nein 6. Welche Eigenschaften (Spaß, Erreichbarkeit, Streß etc.) verbinden Sie mit der Nutzung ihres Endgeräts?

7. Besitzt ihr Endgerät die Möglichkeit eigenständig Applikationen zu installieren? ❐ Ja ❐ Nein 8. Welche Dienste nehmen Sie privat am meisten in Anspruch?

9. Welche Dienste wünschen Sie sich zusätzlich?


21

10. Besitzen Sie neben ihrem privaten mobilen Endgerät auch ein Firmengerät? ❐ Ja ❐ Nein 11. Wenn ja, wie unterscheidet sich die Benutzung?

12. Welche der folgenden Programme nutzen Sie? (Mehrfachnennungen sind möglich) privates Endgerät: Firmenendgerät: ❐ E-Mail ❐ E-Mail ❐ Internet ❐ Internet ❐ Geldgeschäfte u¨ ber Internet, ❐ Geldgeschäfte u¨ ber Internet, z.B. Onlinebanking z.B. Onlinebanking ❐ Soziale Netzwerke ❐ Soziale Netzwerke ❐ Virenscanner ❐ Virenscanner ❐ Routenplaner ❐ Routenplaner 13. Hatten Sie bisher Probleme bei der Benutzung ihres Endgeräts? ❐ Ja ❐ Nein 14. Wenn ja, welche?

15. Wie schätzen Sie ihr Wissen bezüglich des möglichen Schutzes ihres mobilen Endgerätes ein? ❐ Sehr gute Kenntnisse ❐ Gute Kenntnisse ❐ Grundkenntnisse ❐ Keine Kenntnisse 16. Beurteilen Sie die Wichtigkeit von Benutzbarkeit im Bezug auf IT-Sicherheit auf folgender Skala: Benutzbarkeit ist wichtiger

gleich wichtig

Sicherheit ist wichtiger

22


17. Wer sollte für die Sicherheit von mobilen Endgeräten verantwortlich sein? (Bitte verteilen Sie insgesamt 100 % auf die drei angegebenen Antwortmöglichkeiten) % • Hersteller von Programmen • Hersteller von Hardware % % • Benutzer 18. Welche Bedrohungen, speziell bezogen auf mobile Endgeräte, kennen Sie?


23

Teil B 1. Wie schätzen Sie ihr Interesse bezüglich der Sicherheit von mobilen Endgeräten und ihrer Daten ein? ❐ hoch ❐ mittel ❐ niedrig ❐ kein 2. Hatten Sie auf Ihrem mobilen Endgerät schon einmal Sicherheitsprobleme? privates Endgerät: Firmenendgerät: ❐ Ja ❐ Ja ❐ Nein ❐ Nein Wenn ja, welche? Wenn ja, welche?

3. Hatten Sie schon einmal Probleme mit sensiblen Daten von sich? ❐ Ja ❐ Nein 4. Wenn ja, welche?

5. Fühlen Sie sich bei der Benutzung ihres Endgeräts sicher? ❐ Ja ❐ Nein Begründung:

6. Welche Daten auf ihrem Endgerät sind ihrer Meinung nach bedroht (Mehrfachnennungen sind möglich)? ❐ Adressbuch/Telefonbuch ❐ Nachrichteninhalte (SMS/E-Mail) ❐ sonstige gespeicherte Informationen (Notizen, etc.) ❐ Standortinformationen ❐ weitere:

24


7. Welche eigenen Anstrengungen unternehmen Sie, um für IT-Sicherheit im mobilen Umfeld zu sorgen (Mehrfachnennungen sind möglich und erwünscht)?

Virenscanner Passwortschutz Updates bewusster Umgang Verschlüsselung Informieren u¨ ber ITSicherheitsrisiken

Ich versuche immer auf dem neuesten Stand zu sein ❐ ❐ ❐ ❐ ❐

Ich kümmere mich gelegentlich um die Thematik ❐ ❐ ❐ ❐ ❐

Ich kümmere mich gar nicht um die Thematik ❐ ❐ ❐ ❐ ❐

Weiß ich nicht

❐

❐

❐

❐

8. Was verstehen Sie unter dem Begriff Remote Wipe?

❐ ❐ ❐ ❐ ❐

On Some Conjectures in IT Security: The Case for Viable Security Solutions Jan Zibuschka, Heiko Roßnagel Fraunhofer IAO Nobelstraße 12 70569 Stuttgart [email protected] [email protected] Abstract: Due to the increased utilization of computers and the Internet the importance of IT security has also increased. Naturally the field of IT security has grown significantly and has provided many valuable contributions in recent years. Most of the work is concerned with the design of systems offering strong technological security. With regard to behavioural factors, researchers build their work on assumptions about human behaviour that are prevalent in the field of IT security without considering the results and insights of related disciplines. In this contribution we challenge some of these widely held conjectures and offer alternative interpretations based on the results of neighbouring disciplines. Based on this analysis, we suggest new directions for the design of security solutions that support the inclusion of insights from reference disciplines during the design process.

1 Introduction Since the series of cyber-attacks in the first half of 2011 against leading, international corporations like Sony, Citigroup, Lockheed Martin, Google, and Apple [Pau11], it should be obvious that IT security is more important than ever before. With the increased utilization of computers and networks for mission-critical applications in recent years, their reliability and security has also become essential. As a result the field of IT security has grown significantly and has provided many valuable contributions. However, as the recent successful attacks also illustrate, not all of these advances have been utilized in practice and systems remain vulnerable to attacks that are not very sophisticated. For example, a recent study by SANS Institute lists SQL injections and unpatched known vulnerabilities as the predominant threat vectors [DDEK09]. Security technologies that could protect companies or users against these attacks do exist. The problem is that these technologies are often simply not bought, not used or not configured correctly. Therefore, several authors have argued that human factors might be the biggest threat to security in practice [Sas03, JEL03]. At the same time, researchers in the IT security field rely on assumptions about human behavior to guide both the designs of individual systems, and the direction of the discipline as a whole. Examples include conjectures about how humans form trust

26

On Some Conjectures in IT Security: The Case for Viable Security Solutions

on the internet, theories concerning market failure, and opinions about user awareness and education. However, the field of IT security lacks the tools or methods to provide anything but anecdotal evidence to support those conjectures. Neighboring disciplines, especially information systems (IS) and marketing, have amassed a significant amount of knowledge about human behavior with regard to factors such as trust, diffusion of innovative systems, and what constitutes a market failure. Those results at times contradict the conjectures applied in the security domain. However, this body of kernel theory is seldom applied by researchers when designing secure systems [SO07]. In this paper, we will challenge some of the most commonly held conjectures from IT security publications, and present alternative interpretations based on evidence from neighboring disciplines. As this evidence casts doubt on some of these conjectures, we will further argue that those misconceptions are at least partially responsible for the missing market success and utilization of security solutions. In addition, we will outline a framework for the design of secure systems that allows collecting and including relevant evidence concerning behavioral aspects during the planning and specifically feasibility analysis stages, using the information systems and marketing fields as reference disciplines. Especially IS has now collected a significant body of knowledge, especially with regard to the development of innovative yet viable systems [Nam03].

2 Common Conjectures in IT Security In this section we present three common conjectures that are prevalent in the field of IT security. We will challenge these widely held beliefs and present alternative theories that are supported by inputs from kernel theory from the proposed reference disciplines.

2.1

“More Security = More Trust”

One of the most widely held beliefs in IT security is that increasing the security of a system, and thus its trustworthiness, will eventually also lead to an increase in trust towards the system [RIS09, GRSS04, Ran00]. On first glance, this reasoning seems to be quite logical. A system that is more secure than others should be more trustworthy and therefore people should trust it more, which in turn should lead to a higher intention to use or buy the system. However, both trust and intention to use are behavioral aspects, involving human beings, and thus are subject to beliefs and behavior of those involved. Therefore, methods of behavioral science are needed in order to be able to measure whether trustworthiness of systems translates into trust of users towards the system or their intention to use it. IT security research does not possess these methods, and cannot provide strong evidence answering the question scientifically. Therefore, researchers in this field should consider the results of related disciples. Trust has been subject of various disciplines, such as sociology, psychology, and economics. As a result there a many different definitions, which often reflect the disciplinary perspectives, but today most researchers see it as a multidimensional and context-dependent construct [LPF06]. When considering the results


27

of information systems and economics, we find several research contributions that provide evidence that trust indeed positively affects intention to use or buy, especially in the ECommerce environment [Gef00]. However, when looking into the relationship between technological trustworthiness and trust, it becomes apparent that the relations are much more complicated than a direct implication. Trust is influenced by many different factors. Security technology certainly is one of those factors, but not the only one. McKnight et al conducted a large-scale meta-study on trust formation in electronic commerce, and found that the most important influences on trust in an e-commerce site are institutional trust — the trust in the operator of the site — and individuals’ general predisposition to trust [MCK02]. Furthermore, technical measures providing trust through security are dominated by user interface issues: a user may distrust even a secure system because it is very complicated to use, it appeals less to him visually, or it produces errors during usage. Those influences have an impact that is at least as strong as technical security across all user groups [LT01]. Even the color of the web site has been identified as a statistical significant influence on trust [LSR10]. These results cast a serious doubt on the assumption that improved security will automatically lead to an increase in trust. Some IT security researchers have acknowledged, that trust is a social construct that is mainly influenced by the interacting parties, and is hardly influenced by preventive technologies that the user cannot even observe [And01] and have expressed skepticism whether trust can really be managed or influenced by technical means [JKD05]. Consequently, this implies that trust and trustworthiness are separate constructs that are determined by different requirements and influences. Therefore, they should also be addressed separately during system design.

2.2

“We need to educate the users”

One possible conclusion that may be drawn from the disparity of theoretical trustworthiness and actual trust is that users need to be educated, enabling them to identify trustworthy systems. This argument is quite compelling. Once users recognize the technological superiority of the more secure product they will naturally choose the better solution. However, several problems arise with regards to this argument. Flinn and Lumsden surveyed users’ security knowledge and practices, and specifically the impact of educational measures. They find “that the benefits of modest education may not be as dramatic as we would hope” [FL05]. User education is inefficient as the problems associated with security are highly complex. But even if we assume that user education does work, research in related disciplines especially marketing suggests that educating users will not necessarily make them buy more secure products. When confronted with purchasing decisions users need to make choices regarding different product features and the price of the overall product. The security of the product is only one product feature that will be weighed against other features and the costs associated with it. Since more secure solutions often also come with higher costs (including non monetary costs such as reduced performance or high complexity) they might not offer the highest consumer surplus to prospective customers, who are generally perceived as being careless and unmotivated with regard to security [VCU08]. Even when users do exhibit a significant willingness to pay for security, much of this

28


willingness to pay vanishes if the guaranteed security level is anything less than 100% [MPLK06]. This common underestimation of risks is further reinforced by the tendency of users to assume that negative events are less likely to happen to them than to others and that positive events are more likely to happen to them than others [Wei89]. Therefore, educating users about the trustworthiness of products is not sufficient by itself. It has to be combined with raising the awareness of user about the risks of using unsecure systems. However, given the prominence of the recent security incidents it remains doubtful, that users are still unaware of these risks in general. Furthermore, raising awareness about specific risks can even undermine trust in the systems due to privacy and security salience [JAL11]: the mention of security risks may reduce users’ intention to use a service as they are made aware that breaches are possible. In addition, the users’ criticized security behavior can be seen as entirely rational [Her09]: contemporary systems are asking too much of users in terms of both cost and complexity and offer too little benefit in return.

2.3

“There is a market failure, and we need regulation”

Many information security practitioners share this assessment, and call for the government to intervene and regulate computer security [Lau96, BHRR07]. A common reasoning is that the problems of security solutions in the market indicate a market failure, caused by incomplete information — a lemon market problem [Ake70], an asymmetric information distribution that results in a vicious circle where price is the dominant factor for success, and high quality systems suffer. Of course, we cannot disprove market failure for all security systems in their specific markets in general here; this has to be discussed for each market individually. However, we can say that in some cases where regulation has been made based on observations of market failure have not gone as had been hoped; in analyses following the implementation of the regulation, economic factors such as high costs, network externalities, unfair incentive distributions and lacking applications have been identified as problems e.g. in the case of the German electronic signatures [Roß06]. Speaking of a market failure of security systems in a sense that regulation was needed might be understood as implying that the situation in the market was not Pareto optimal, meaning that the situation of the users might be improved by forcing them to use highly secure systems. Vidyaraman et al. [VCU08] proposed to persuade users to improve their security practices by designing systems in a way that would artificially make insecure practices less desirable. They warned that there would be a backlash from the users, making the approach of imposing security on the user impractical where practices cannot be enforced by an overarching organization, as users would not adopt a solution threatening disciplinary measures to enforce secure practices voluntarily. As we stated in the last section, users valuate systems based on a number of factors, including but not limited to security. If they need to be forced, this would not be an improvement in the sense of Pareto optimality. We feel, in such cases we need an alternative to calls for regulation that would persuade users to use security systems they would not employ by choice. Classical information security aims at developing systems with high complexity (which is a problem with regards to diffusion [Rog03]) and offering the highest possible level of security (which users can-


29

not observe [And01]). Under those circumstances, the explanation of market failure may apply in some cases, i.e. where a lemon market problem is the main hindrance, but all in all is not necessary to explain why security systems often have no success in the market. Our idea, as an alternative to this, is to find methods for a new design process that would take market compliance factors into account early in the system design.

3 Engineering Viable Security Systems We propose an alternative approach, a stakeholder requirements driven analysis in the very early stages of security system design. As Greenwald et al. observe [GORR04], user acceptance is underrepresented in security systems design. While we recognize that security systems should offer the highest feasible level of security, we feel this feasibility is limited by market compliance, as we need to build systems that are not only trustworthy in theory, but also trusted. It is a condition for the design of such systems that all involved stakeholders would still voluntarily use them. Where related approaches like Karyda et al.’s Viable Information Systems [KKK01] are concerned with the question how much security an information system needs to be successful, we consider the design of IT security systems, and ask how to make them more viable from a market compliance perspective. One very relevant approach is the viable security model [ZR11], which illustrates important factors influencing the impact of a given security solution on the overall security of deployed information systems [ZR11], including how market-compliant a security infrastructure needs to be to succeed on the market, and how effective it is in comparison with the currently deployed state of the art. Those two aspects mirror the earlier discussion of the trustworthiness of effective security systems, and the market compliance reached by creating trust in users. An effective security solution that is not market-compliant will not lead to an increase in security in practice, while a solution that is market-compliant but not as least as secure as what is currently deployed might even harm the overall level of security [ZR11]. The question of effectiveness is widely discussed in information security and related fields of computer science. Technical soundness is the core requirement of information security research in computer science, and the requirement that computer scientists can analyze using the methods of computer science. There have also been quite some efforts to increase the usability of security systems in recent years [JEL03]. Human-computer interaction experts have a comprehensive set of methods for designing and evaluating user interfaces [JEL03]. Factors like task-technology-fit have received less attention, but require a very specific combination of implemented system and concrete task, which makes them not directly applicable to system design. Hevner et al. [HMPR04] recently made the case for design science in information systems, where artifacts such as reference architectures or design theories are developed and then evaluated using behavioral methods, as a promising vector for research that contributes both to the scientific knowledge base (the research is rigorous) and to practice (it is also relevant). While this approach brought the information systems domain, which had been focused on behavioral studies, closer to the subjects classically addressed in computer science, we propose a paradigm shift that would bring the IT security domain closer to IS. While performing an iterative design, as described

30


by Hevner and usually applied in Software Engineering and security system development, we keep an IT security and computer science perspective, implying direct applicability to the technical design of such systems, but also regularly evaluate the market compliance of the designs based on reference disciplines such as IS or marketing that have methods for assessing market compliance. Hevner et al. [HMPR04] also make a strong argument for evidence-based evaluation. Several methods from the field of information systems can be applied to assess market compliance in the early stages of the design process. Methods such as stakeholder analysis [Pou99] and analyses based on diffusion theory [RZ12] have been applied in the IS field. They are tailored towards qualitative results, but can easily be applied by engineers as part of the design process, and are capable of digesting non-monetary impacts of e.g. privacy [Pou99]. Choice-based conjoint analysis from the marketing field [DRC95] offers quantitative results in the form of measuring stakeholders’ willingness to pay for several system configurations, but requires expertise for designing a valid survey instrument.

4 Related Work As mentioned earlier, our approach builds directly on the design science approach by Hevner et al. [HMPR04]. An argument that is very similar to ours has also been made by Fenton et al [FPG94] in the software engineering domain. There, they argue, that a lot of new technologies are developed which claim to lower development effort needed and make software more readily adaptable or maintainable, without giving a sound evaluation. Fenton et al. argue that more empirically sound evaluation is needed to address this. There have been several initiatives in information systems research focussing on the design of viable, secure information systems. Those include the Viable IS approach by Karyda et al. [KKK01], as well as the approach proposed by Siponen and Baskerville [SB02]. On the computer science side, Jürjen’s UMLSec [Jür02] has provided a similar contribution, building on UML. Recently, Heyman et al [HYS+ 11] have proposed an iterative approach similar to the one proposed by Hevner, alternating between requirements and architecture, but lacking Hevner’s focus on evaluation and contribution to theory. There are also a wider range of security requirements engineering approaches [FGH+ 09].

5 Conclusion From our point of view, security systems designs should take into account both technological trustworthiness and socio-economic trust aspects. We build on findings from reference disciplines including information systems and marketing, but derive a framework for engineering secure systems targeting specifically the IT security domain. To achieve a viable security solution, designers have to make sure that their solution provides an effective security improvement and is compliant with market demands. We listed several methods that can be applied to assess market compliance already in the early stages of the design


31

process. Even though our reference disciplines are influenced by economics, our aim is not to maximise profit. Neither do we want to attack basic research in the area of security, which is of course needed to provide the underpinnings of a more secure future IT infrastructure. Our aim is to provide engineers designing security systems with tools enabling them to increase the practical impact of their solutions by designing solutions that are not only trustworthy but also trusted, effective as well as market-compliant. We see this as important contribution, as earlier work regarding system design has focused on trustworthiness/effectiveness, which, as the viable security model illustrates, is only one aspect of a larger problem. This contribution may also be applicable to field beyond IT security, Fenton et al. [FPG94] make a similar argument for software engineering tools, but we feel it is of special interest in the case of IT security due to the difficulties of many products in the market, said to be due to human factors [Sas03], and the underrepresentation in earlier works. We do not feel this contribution, specifically regarding the details of the design process, is final yet. However, we want to once again point to Hevner et al.’s design science [HMPR04], which provides a very solid meta-framework for a scientific design process with evidence-based evaluation concerning human factors.

References [Ake70]

George A. Akerlof. The Market for ”Lemons”: Quality Uncertainty and the Market Mechanism. The Quarterly Journal of Economics, 84(3):488–500, August 1970. ArticleType: primary article / Full publication date: Aug., 1970 / Copyright 1970 The MIT Press.

[And01]

Ross Anderson. Why Information Security is Hard - An Economic Perspective. In Computer Security Applications Conference, pages 358–365, Las Vegas, 2001.

[BHRR07] P. Bramhall, M. Hansen, K. Rannenberg, and T. Roessler. User-Centric Identity Management: New Trends in Standardization and Regulation. IEEE Security & Privacy, 5(4):84–87, August 2007. [DDEK09] R. Dhamankar, M. Dausin, M. Eisenbarth, and J. King. The top cyber security risks. SANS Institute, http://www.sans.org/top-cyber-security-risks/, 2009. [DRC95]

Wayne S. Desarbo, Venkatram Ramaswamy, and Steven H. Cohen. Market segmentation with choice-based conjoint analysis. Marketing Letters, 6(2):137–147, March 1995.

[FGH+ 09] Benjamin Fabian, Seda Gürses, Maritta Heisel, Thomas Santen, and Holger Schmidt. A comparison of security requirements engineering methods. Requirements Engineering, 15:7–40, November 2009. [FL05]

S. Flinn and J. Lumsden. User perceptions of privacy and security on the web. In The Third Annual Conference on Privacy, Security and Trust (PST 2005), 2005.

[FPG94]

N. Fenton, S.L. Pfleeger, and R.L. Glass. Science and substance: a challenge to software engineers. Software, IEEE, 11(4):86–95, 1994.

[Gef00]

D. Gefen. E-commerce: the role of familiarity and trust. Omega, 28(6):725737, 2000.

32


[GORR04] Steven J. Greenwald, Kenneth G. Olthoff, Victor Raskin, and Willibald Ruch. The user non-acceptance paradigm: INFOSEC’s dirty little secret. In Proceedings of the 2004 workshop on New security paradigms, pages 35–43, Nova Scotia, Canada, 2004. ACM. [GRSS04] Dirk Günnewig, Kai Rannenberg, Ahmad-Reza Sadeghi, and Christian Stüble. Trusted Computing Platforms: Zur technischen und industriepolitischen Situation und Vorgehensweise. In Vertrauenswürdige Systemumgebungen, pages 154–162. Verlag Recht und Wirtschaft, 2004. [Her09]

Cormac Herley. So long, and no thanks for the externalities: the rational rejection of security advice by users. In Proceedings of the 2009 workshop on New security paradigms workshop, pages 133–144, Oxford, United Kingdom, 2009. ACM.

[HMPR04] A.R. Hevner, S.T. March, J. Park, and S. Ram. Design Science in Information Systems Research. MIS Quarterly, 28(1):75–105, 2004. [HYS+ 11] Thomas Heyman, Koen Yskout, Riccardo Scandariato, Holger Schmidt, and Yijun Yu. ´ The Security Twin Peaks. In Ulfar Erlingsson, Roel Wieringa, and Nicola Zannone, editors, Engineering Secure Software and Systems, volume 6542, pages 167–180. Springer Berlin Heidelberg, Berlin, Heidelberg, 2011. [JAL11]

Leslie K. John, Alessandro Acquisti, and George Loewenstein. Strangers on a Plane: Context-Dependent Willingness to Divulge Sensitive Information. Journal of Consumer Research, 37(5):858–873, February 2011.

[JEL03]

J. Johnston, J. H. P. Eloff, and L. Labuschagne. Security and human computer interfaces. Computers & Security, 22(8):675–684, December 2003.

[JKD05]

Audun Jsang, Claudia Keser, and Theo Dimitrakos. Can We Manage Trust? In Peter Herrmann, Valérie Issarny, and Simon Shiu, editors, Trust Management, volume 3477, pages 93–107. Springer Berlin Heidelberg, Berlin, Heidelberg, 2005.

[Jür02]

Jan Jürjens. UMLsec: Extending UML for Secure Systems Development. In Jean-Marc Jézéquel, Heinrich Hussmann, and Stephen Cook, editors, UML 2002 The Unified Modeling Language, volume 2460 of Lecture Notes in Computer Science, pages 1–9. Springer Berlin / Heidelberg, 2002. 10.1007/3-540-45800-X 32.

[KKK01]

Maria Karyda, Spyros Kokolakis, and Evangelos Kiountouzis. Redefining information systems security: viable information systems. Proceedings of the 16th international conference on Information security: Trusted information: the new decade challenge, page 453468, 2001. ACM ID: 510799.

[Lau96]

Kenneth C. Laudon. Markets and privacy. Communications of the ACM, 39:92–104, September 1996.

[LPF06]

H Lacohee, A Phippen, and S Furnell. Risk and restitution: Assessing how users establish online trust. Computers & Security, 25(7):486–493, October 2006.

[LSR10]

S. Lee and V. Srinivasan Rao. Color and store choice in Electronic Commerce: The explanatory role of trust. Journal of Electronic Commerce Research, 11(2):110–126, 2010.

[LT01]

M.K.O. Lee and E. Turban. A trust model for consumer internet shopping. International Journal of electronic commerce, 6(1):7591, 2001.

[MCK02]

D. Harrison McKnight, Vivek Choudhury, and Charles Kacmar. Developing and Validating Trust Measures for e-Commerce: An Integrative Typology. INFORMATION SYSTEMS RESEARCH, 13(3):334–359, September 2002.


33

[MPLK06] Milton L Mueller, Yuri Park, Jongsu Lee, and Tai-Yoo Kim. Digital identity: How users value the attributes of online identifiers. Information Economics and Policy, 18(4):405– 422, November 2006. [Nam03]

Satish Nambisan. Information Systems as a Reference Discipline for New Product Development. MIS Quarterly, 27(1):1–18, March 2003.

[Pau11]

Ian Paul. IMF Hacked; No End in Sight to Security Horror Shows, PCWorld. http://bit.ly/jTpgAp, June 2011.

[Pou99]

A. Pouloudi. Aspects of the stakeholder concept and their implications for information systems development. In System Sciences, 1999. HICSS-32. Proceedings of the 32nd Annual Hawaii International Conference on, page 7030, 1999.

[Ran00]

Kai Rannenberg. Mehrseitige Sicherheit - Schutz für Unternehmen und ihre Partner im Internet. WIRTSCHAFTSINFORMATIK, 42(6):489–498, 2000.

[RIS09]

RISEPTIS. Trust in the Information Society: A Report of the Advisory Board RISEPTIS. www.think-trust.eu/downloads/public-documents/riseptis-report/download.html, 2009.

[Roß06]

H. Roßnagel. On Diffusion and Confusion Why Electronic Signatures Have Failed. In Trust and Privacy in Digital Business, pages 71–80. Springer, 2006.

[Rog03]

Everett M. Rogers. Diffusion of Innovations, 5th Edition. Free Press, original edition, August 2003.

[RZ12]

Heiko Roßnagel and Jan Zibuschka. Assessing Market Compliance of IT Security Solutions A Structured Approach Using Diffusion of Innovations Theory. In Strategic and Practical Approaches for Information Security Governance: Technologies and Applied Solutions. IGI Global, 2012.

[Sas03]

Martina Angela Sasse. Computer security: Anatomy of a usability disaster, and a plan for recovery. In Proceedings of CHI 2003 Workshop on HCI and Security Systems, 2003.

[SB02]

Mikko Siponen and Richard Baskerville. A New Paradigm for Adding Security into is Development Methods. In Jan H. P. Eloff, Les Labuschagne, Rossouw Solms, and Gurpreet Dhillon, editors, Advances in Information Security Management & Small Systems Security, volume 72, pages 99–111. Kluwer Academic Publishers, Boston, 2002.

[SO07]

Mikko T. Siponen and Harri Oinas-Kukkonen. A review of information security issues and respective research contributions. SIGMIS Database, 38(1):6080, February 2007.

[VCU08]

S. Vidyaraman, M. Chandrasekaran, and S. Upadhyaya. Position: the user is the enemy. In Proceedings of the 2007 Workshop on New Security Paradigms, pages 75–80, New Hampshire, 2008. ACM.

[Wei89]

ND Weinstein. Optimistic biases about personal risks. Science, 246(4935):1232 –1233, December 1989.

[ZR11]

Jan Zibuschka and Heiko Roßnagel. A Structured Approach to the Design of Viable Security Solutions. In N. Pohlmann, H. Reimer, and W. Schneider, editors, Securing Electronic Business Processes, pages 246–255. Vieweg, 2011.

¨ Identifikation von Videoinhalten uber granulare ∗ Stromverbrauchsdaten Ulrich Greveler, Benjamin Justus, Dennis Löhr Labor für IT-Sicherheit Fachhochschule Münster Stegerwaldstraße 39 48565 Steinfurt {greveler|benjamin.justus|loehr}@fh-muenster.de

Abstract: Sekundenscharfe Ablese-Intervalle bei elektronischen Stromzählern stellen einen erheblichen Eingriff in die Privatsphäre der Stromkunden dar. Das datenschutzrechtliche Gebot der Datensparsamkeit und Datenvermeidung steht einer feingranularen Messhäufigkeit und der vollständigen Speicherung der Stromverbrauchsdaten entgegen. Wir können experimentell nachweisen, dass neben der Erkennung von im Haushalt befindlichen Geräten eine Erkennung des Fernsehprogramms und eine Identifikation des abgespielten Videoinhalts möglich ist. Alle Mess- und Testergebnisse wurden zwischen August und November 2011 mithilfe eines geeichten und operativen Smart Meters, der alle zwei Sekunden Messwerte aufzeichnet, gewonnen. Die u¨ bertragenen Daten dieses Gerätes waren unverschlüsselt und nicht signiert. Keywords. Smart Meter, Data Privacy, Audiovisual Content, Smart Grid

¨ 1 Einfuhrung Bundesweit und auch im europäischen Rahmen ist die Einführung von intelligenten Strommessgeräten (Smart Metern) geplant, die vorhandene Stromzähler ersetzen sollen. Stromkunden können mithilfe dieser Geräte detaillierte Informationen u¨ ber den Stromverbrauch erhalten und sind in der Lage, Stromverbraucher zu identifizieren, Ursachen für hohen Verbrauch zu bestimmen und damit Abhilfe zu schaffen, d. h. insbesondere Stromverbrauchskosten zu senken (Förderung des bewussten Energieverbrauchs). Für Stromverkäufer und Netzbetreiber sind granulare Verbrauchsdaten ebenfalls von Interesse, da diese zu Planungszwecken, Ausführung von Netzoptimierungen, Vorhersage von Lastspitzen und informierte Beratungen der Kunden herangezogen werden können. Die Energieeffizienz- und Energiedienstleistungsrichtlinie (2006/32/EG) sieht individuel∗ Dieser Beitrag stellt wesentliche Ergebnisse in aktualisierter Form dar, die in einer englischsprachigen Publikation [GJL12] der Autoren veröffentlicht wurden.

36

Identifikation von Videoinhalten u¨ ber granulare Stromverbrauchsdaten

le Zähler, die den tatsächlichen Verbrauch und die tatsächliche Nutzungszeit feststellen [Ren11], vor. Mittelfristig ist daher damit zu rechnen, dass sich Smart Meter gegenüber bisherigen Stromzählern bei Neuverlegungen und dem Austausch alter Zähler durchsetzen. Aufgrund der Aufzeichnung personenbezogener Verbrauchsdaten durch Smart Meter ergeben sich Anforderungen an Datenschutz und Datensicherheit. Abhängig von der Genauigkeit der Messung und der zeitlichen Auflösung können nach Auswertung der erhobenen Daten Rückschlüsse auf die Verhaltensweisen der sich im Haushalt aufhaltenden Menschen gezogen werden; die Granularität heute eingesetzter Geräte sieht Messpunkte im Abstand von einer Stunde, viertelstündlich, minütlich bis hin in den Sekundenbereich vor.

2 Verwandte Arbeiten Wie von Molina-Markham et al. [AMSF+ 10] beschrieben wurde, können Daten, die ca. viertelstündlich erhoben werden, in einer Weise ausgewertet werden, dass feststellbar ist, wann sich Personen zuhause aufhalten, wann sie dort schlafen und wann sie Mahlzeiten zubereiten. Erhöht man die Granularität in den Minuten- oder Sekundenbereich, sind auch Aussagen möglich, ob das Frühstück warm oder kalt zubereitet wurde, wann Wäsche gewaschen oder der Fernseher eingeschaltet wurde - oder ob die Kinder alleine zu Hause waren. Bereits vor dem Aufkommen der Smart Meter wurden Forschungsarbeiten zu non-intrusive ” load monitoring“ (NILM) bekannt. NILM-Methoden [LFL07, Pru02] erlauben die Identifikation einer Vielzahl von Geräten anhand charakteristischer Lastkurven, wodurch die Aktivitäten der im Haushalt befindlichen Personen nachvollziehbar werden [Qui09]. Hinweise auf Datenschutzaspekte in Bezug auf die Einführung von Smart Metern sind Teil der o¨ ffentlichen Diskussion um den Nutzen und die Risiken der Technologie. [Bö11, AMSF+ 10, Ren11] Es wurden zudem Gegenmaßnahmen, die den Datenschutz bei der Einführung von Smart Metern stärken sollen, vorgeschlagen: Schlüsselhinterlegung zur anonymen Authentikation [EK10], Reduktion verräterischer Lastkurven durch Einsatz von Stromspeichern [EKD+ 10, KDLC11] oder auch anonyme Rechnungsstellung unter Nutzung eines Zero-Knowledge-Protokolls [AG10]. Die Messung elektromagnetischer Inteferenz mit hoher Abtastrate zur Identifikation des Fernsehbildes wurde zeitgleich und unabhängig zu den von den Autoren durchgeführten Experimenten mit Stromzählern von Enev et al. [EGKP11] betrachtet; hierbei gelingt eine Identifikation mithilfe neuronaler Netze. Erste Ergebnisse der experimentellen Arbeiten wurden zudem u¨ ber die Presse verbeitet [Bö11].


37

3 Experimentelle Ergebnisse Die Untersuchungsergebnisse beziehen sich auf die Fragestellung: Welche Auswertungsmöglichkeiten stehen in der Praxis zur Verfügung und welche Qualität haben die von tatsächlich im Feld befindlichen geeichten Smart Metern erhobenen Daten? Welche Rückschlüsse auf personenbezogenes Verhalten können erfolgreich gewonnen werden?

3.1

Hardware

Getesteter Smart Meter: Das Gerät wurde von der Firma Discovergy GmbH (Heidelberg) nach Abschluss eines Privatkundenvertrags1 durch einen von der Firma beauftragten Elektromeister im August 2011 eingebaut. Das geeichte und verplombte Gerät ersetzte den bisherigen von der RWE AG verbauten Stromzähler eines privaten Haushaltes in NRW. Der Strombezug erfolgt vor und nach dem Einbau des Smart Meters u¨ ber den Versorgungstarif RWE Klassik Strom. Die Discovergy-Lösung verwendet als Modul einen Smart Meter2 der Firma EasyMeter GmbH, Bielefeld (Elektronischer 3-Phasen 4-Leiter Zähler Q3D, Messung im zweiSekunden-Intervall) und eine selbst entwickelte Lösung zur Datenentnahme und Weiterleitung u¨ ber das Internet an einen Server von Discovergy, der dem Stromkunden einen webbasierten Zugriff auf die erhobenen Stromverbrauchsdaten liefert. In der experimentellen Untersuchung werten wir allein die Daten aus, die an Discovergy u¨ bermittelt und gespeichert werden. Alle Mess- und Testergebnisse wurden zwischen August und November 2011 gewonnen.

4

¨ Ubertragung der Verbrauchsdaten

¨ Die Ubermittlung der Daten vom Smart Meter zum Discovergy-Server erfolgt u¨ ber TCP/IP. Das Gerät wird direkt mit dem heimischen LAN/DSL-Router verbunden und erhält von diesem u¨ ber DHCP seine IP-Adresse. Entgegen den vertraglichen Angaben erfolgt die ¨ Ubertragung jedoch nicht verschlüsselt. Die Daten werden in einem textbasierten Format u¨ bertragen, so dass sie ohne weitere Decodierung abgelesen werden können. In Abb. 1 ist ¨ eine solche Ubertragung, die acht Messwerte gemeinsam u¨ bermittelt, dargestellt. 1 Der Vertrag enthielt umfangreiche Bestimmungen zum Datenschutz: Die Discovergy GmbH speichert die ” personenbezogenen Daten ausschließlich zur Abwicklung der oben aufgeführten Zwecke und gibt diese nicht an Dritte weiter, es sei denn, dieses ist zur Abwicklung des Vertrages erforderlich. Derzeit werden Daten an Dritte weitergegeben zur Erstellung der Abrechnung, im Bereich des Zähl- und Messwesens sowie zur Daten¨ aufbereitung in elektronischer Form. [...] Die Ubertragung der Daten im Internet erfolgt verschlüsselt.“ Der Abruf der Daten u¨ ber die Webschnittstelle war zum Testzeitpunkt nur unverschlüsselt möglich, da TLS nicht unterstützt ¨ wurde. Die automatisierte Ubertragung vom Smart Meter zum Server erfolgte im Widerspruch zum Vertragstext ebenfalls unverschlüsselt. 2 Ubermittelte ¨ Messwerte gemäß Herstellerangaben: Zählwerksstand (15-stellig in kWh), drei Phasenleistungen (7,5-stellig in W), Summenleistung (7,5-stellig in W), Protokoll nach EN62056-21 und EN62056-61.

38


POST /api/w.html HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host:85.214.93.99 Content-Length:851 version=0.9&identity= &msg=228601&values=[ {"meterdata":"00000285.9823514*kWh","tickdelta":"00000285.9822239*kWh","seconds":"399511319.61"}, {"meterdata":"00000285.9824793*kWh","tickdelta":"00000285.9823514*kWh","seconds":"399511321.61"}, {"meterdata":"00000285.9826075*kWh","tickdelta":"00000285.9824793*kWh","seconds":"399511323.61"}, {"meterdata":"00000285.9827358*kWh","tickdelta":"00000285.9826075*kWh","seconds":"399511325.62"}, {"meterdata":"00000285.9828636*kWh","tickdelta":"00000285.9827358*kWh","seconds":"399511327.62"}, {"meterdata":"00000285.9829915*kWh","tickdelta":"00000285.9828636*kWh","seconds":"399511329.62"}, {"meterdata":"00000285.9831196*kWh","tickdelta":"00000285.9829915*kWh","seconds":"399511331.62"}, {"meterdata":"00000285.9832476*kWh","tickdelta":"00000285.9831196*kWh","seconds":"399511333.62"}] &now=399511335.65

Abbildung 1: Kommunikation Zwischen Smart Meter und Server

Es ist zudem unmittelbar zu erkennen, dass die Daten nicht signiert werden. Durch Kenntnis der identity“ (in der Abb. 1 geschwärzt) könnten Daten für beliebige andere Zähler ” an den Server u¨ bertragen werden, was zwischenzeitlich demonstriert wurde [BCC11]. Der Smart Meter verfügt jedoch u¨ ber eine digitale Anzeige des Stromverbrauchs, so dass Daten, die am Zähler abgelesen werden, von einer Verfälschung nicht betroffen sind.

4.1

Auflösung der dem Stromkunden präsentierten Daten

Discovergy stellt einen Web-basierten Zugang zur Visualisierung der Stromverbrauchsdaten zur Verfügung. Eine typische Darstellung eines Stromverbrauchsprofils kann Abb. 2 entnommen werden (Stand: Nov. 2011).

Abbildung 2: Verbrauchsprofil visualisiert vom Anbieter

Eine Analyse des Javascript-Sourcecodes zeigte, dass die Kunden nicht die volle Auflösung ihrer gespeicherten Stromverbrauchsdaten einsehen können (Messungen erfolgen mit Frequenz 0.5s−1 ). Die Daten werden konsolidiert, indem einzelne Messwerte ausgelassen werden. Diese Konsolidierung war zum Testzeitpunkt fehlerhaft, weswegen einzelne dargestellte Messwerte nicht mit abgerufenen Daten u¨ bereinstimmten. Durch Entwicklung eines eigenen Tools zum Abrufen und zur Darstellung erhielten wir die volle Auflösung und korrekte Daten: Abb. 3 zeigt ein kleines Intervall in voller Auflösung, welches in Abb. 2 (im Teilzeitraum 22.35h-22.50h) enthalten ist. Genauigkeitsklasse: A, B gemäß EN50470-1


4.2

39

Identifikation von Geräten

Wir konnten die in der Literatur getroffenen Aussagen [Har92, AMSF+ 10, Mü10] bestätigen, dass viele Geräte u¨ ber ein charakteristisches Stromprofil erkennbar sind. Insbesondere konnten wir mithilfe der feingranularen Daten identifizieren: Kühlschrank, Wasserkocher, Durchlauferhitzer, Glühbirne, Energiesparlampe, Kaffee-Padmaschine, Herd, Mikrowelle, Ofen, Waschmaschine, Geschirrspüler und TV-Gerät.

5 TV/Film-Detektion 5.1

TV-Gerätetechnik

Durch Auswertung des Stromverbrauchs eines im getesteten Privathaushalt vorhandenen TV-Gerätes (Panasonic Viera LCD-TV, HD, 80cm Diag., 130W) konnte nicht nur die bereits in der Literatur genannte Einschaltzeit [Qui09] identifiziert werden. Es war darüber hinaus möglich, das eingeschaltete Programm bzw. den abgespielten Film zu identifizieren, obwohl der eingesetzte Smart Meter den Strom für den gesamten VierPersonenhaushalt misst - also nicht direkt mit dem TV-Gerät verbunden wurde - und die Daten u¨ ber den Discovergy-Server abgefragt wurden, d. h. dort in dieser Auflösung zentral gespeichert vorliegen.

5.2

Vorhersage des Stromverbrauchs anhand von Filmdaten

Kernelement unseres Softwaretools zur Identifikation von Inhalten ist eine Funktion, die den zu erwartenden Stromverbrauch berechnet. Input der Funktion sind Bilddaten, Output ist der Stromverbrauch wie er vom Smart Meter gemessen wird.

Abbildung 3: Bestimmung der minimalen Bildhelligkeit, die zum maximalen Stromverbrauch führt

Ein erster Schritt ist die Messung des Stromverbrauchs für eine Folge von Grautönen als Teil der Folge schwarz-(RGB-2-2-2)-weiß-schwarz-(RGB-4-4-4)-weiß-schwarz-(RGB6-6-6). . . , die es erlaubt den minimalen Helligkeitswert zu bestimmen, der den Stromverbrauch maximiert. Dies geschieht nicht selten bereits bei recht dunklen Bildern (z. B. RGB 32-32-32 für o. g. LCD TV) und ist abhängig vom Fernseher, Zeitpunkt (der Wert ist nicht u¨ ber Stunden konstant) und den Benutzereinstellungen. Abb. 3 zeigt die anstei-

40


gende Stromkurve (zwischen schwarz und weiß) für obige Bildersequenz. Man kann von Hand abzählen, dass bei ab RGB-38-38-38 der Stromverbrauch maximal ist. Diesen Wert (minimale Helligkeit für maximalen Stromverbrauch) bezeichnen wir mit bmin . Wir konnten anhand des Messergebnisses eine lineare Abhängigkeit annehmen und prognostizierten den Stromverbrauch für ein 2-Sekunden-Intervall durch den Mittelwert aus der doppelten Anzahl Frames, die in einer Sekunde dargestellt werden (meist sind es 25 fps bei Filmproduktionen). " mi :=

1 bi

bmin

ppk :=

1 n

falls bi > bmin sonst n(k+1)−1

!

mi

i=nk pp

brightness

power prediction

b

time

time

Abbildung 4: Stromverbrauch wird anhand von gemittelten Helligkeiten prognostiziert

Wir erhalten damit eine Folge von prognostizierten normalisierten Messwerten für 2s (k = 1), 4s (k = 2), 6s (k = 3), etc., die wir mit dem tatsächlichen Stromverbrauch korrelieren können, um den Inhalt zu identifizieren. Abb. 5 zeigt Ergebnisse dieser Vorgehensweise für drei Filmausschnitte a` fünf Minuten. Grün sind vorhergesagte Messwerte, rot sind die Werte vom Smart Meter: Die Korrelationen nach Pearson betragen 0.94, 0.98 und 0.93.

5.3

Korridor-Algorithmus

Nachdem sich experimentell gezeigt hatte, dass hohe Korrelationen auch dann auftreten können, wenn die im Stromverbrauchsprofil gesuchte 5-minütige Filmsequenz einem Einschalt- oder Ausschaltvorgang eines beliebigen Gerätes a¨ hnelt (z. B. lange helle Szene folgt auf eine lange dunkle Szene: korreliert stark mit dem Einschalten eines konstanten Verbrauchers, z. B. einer Lampe), haben wir einen Korridor-Algorithmus entworfen, der diese False Positives eliminiert. Bevor eine Fundstelle identifiziert wird (ab einer Korrelation von 0.85 gehen wir von einem Treffer aus), werden die Messwerte, die in zwei ¨ optimal gewählten Korridoren mit jeweils 5% Höhe liegen, gezählt. Uberschreiten diese einen Schwellenwert von 50% aller Werte, wird der Treffer eliminiert. Abb. 6 zeigt einen typischen Anwenungsfall, der zur Elimination des Treffers führt.


130

41

comsumption prediction

120

power consumption (w)

110 100 90 80 70 60 50

0

50

100

150

200

250

300

time (s)

130


120


110 100 90 80 70 60 50

0

50

100

150

200

250

300

time (s)

130


120


110 100 90 80 70 60 50

0

50

100

150 time (s)

200

250

300

Abbildung 5: Vorhersage und tatsächlicher Verbrauch: Erste 5 Minuten von Star Trek 11 (oben); Episode 1-1, Star Trek TNG; Body of Lies (unten)

42


power prediction

pp

time

Abbildung 6: Korridor-Algorithmus eliminiert False Positives

5.4

Work-flow

Mithilfe der zuvor genannten Algorithmen konnten wir den Proof-of-Concept einer forensischen Software realisieren, der automatisch nach Videoinhalten in den Stromverbrauchsdaten sucht. Wir stellten dazu eine Filmdatenbasis zusammen, die aus den 5-MinutenAbschnitten von 653 Filmen bzw. Fernsehproduktionen besteht. Der Ablauf des Suchvorgangs ist in Abb. 7 dargestellt: Jeder zu suchende Film wird in 5-Minuten-Abschnitte unterteilt und es wird die Helligkeit und daraus der erwartete Stromverbrauch jedes Frames bestimmt. Der Abschnitt wird dann fortlaufend u¨ ber die gesamten Stromverbrauchsdaten korreliert (sliding window). Ab einem Wert von 0.85 wird der Treffer, sofern er nicht die Korridorbedingung (Ausschlusskriterium) erfüllt, ausgegeben. Ergebnis: Bei dieser Vorgehensweise wird fast die Hälfte der gespielten Videosequenzen anhand des Stromverbrauchs identifiziert. Da ein Film (i.d.R. mind. 90 Minuten) u¨ ber 18 oder mehr Abschnitte verfügt, ist selbst bei Störungen durch andere Verbraucher (z. B. Einschalten eines starken rauschenden“ Gerätes3 während der Abspielzeit), eine gewisse ” Wahrscheinlichkeit gegeben, mehrere nicht wesentlich beeinträchtigte Abschnitte zu iden¨ tifizieren. Uber einen Zeitraum von 24h werden jedoch (bei unserer Datenbasis von 653 Videoinhalten) auch ca. 35 falsche Identifizierungen von 5-Minuten-Abschnitten vorgenommen. Zählt man jedoch nur solche Treffer, bei denen zwei korrespondierende Abschnitte desselben Inhaltes gefunden werden (wie im Beispiel von Abb. 7), wurden sämtliche False Positives eliminiert. Im Testhaushalt konnten Spielfilminhalte trotz gleichzeitig aktiver elektrischer Geräte in allen Fällen anhand mehrerer Abschnitte identifiziert werden4 . Aufgezeichnete Fernsehproduktionen, die ein hohes durchgehendes Helligkeitsniveau aufweisen (bspw. Talkshows), können mit LCD-Geräten oft nicht identifiziert werden, da der gerätespezifische Wert bmin zu niedrig ist. 3 Verbraucher, die eine konstante Last erzeugen (z. B. Lampen, Standby-Ger¨ ate, Hifi), wirken sich auf die Korrelation nicht störend aus, da diese nur eine Intervallskalierung voraussetzt. 4 Hier ist aber zu bemerken, dass Filme im getesteten Haushalt abends konsumiert wurden und zur gleichen Zeit kein Herd, Fön oder baugleicher Fernseher benutzt wurde.


iso file from DVD movie

find correlation matches on power profile

split into 5-min chunks

calculate bmin and correlation for each match

calculate brightness

find best corridors and discard by threshold

< threshold

calculate generic power prediction

> threshold

43

< threshold

output matches to logfile

movie tng1 movie tng1 chunk 1 at 2103h chunk 3 at 2113h

Abbildung 7: Workflow zur Identifikation einer abgespielten DVD

5.5

Weitere TV-Gerätemodelle

Die Experimente aus den vorangegangenen Abschnitten wurden mit dem im Testhaushalt befindlichen LCD-TV5 durchgeführt, das u¨ ber eine dynamische Hintergrundbeleuchtung verfügt. Um abzuschätzen, inwieweit andere TV-Modelle a¨ hnliche Rückschlüsse erlauben bzw. datenschutzfreundliche“ Stromverbrauchsprofile generieren, haben wir die Tests mit ” einem weiteren (nicht operativen) Smart Meter desselben Typs für weitere Geräte im Labor durchgeführt. In Tab. 1 werden Testergebnisse für unterschiedlichen Videoinhalt aufgeführt. Bei zwei der getesteten Geräte (Hersteller Sony und LG) ist die Watt-Differenz zwischen einem hellen und dunklen Bild zu gering, um Film-Inhalte zu identifizieren (Korrelation < 0.85).

6 Diskussion Kurze Ablese-Intervalle bei elektronischen Stromzählern stellen einen erheblichen Eingriff in die Privatsphäre der Stromkunden dar. Das datenschutzrechtliche Gebot der Datensparsamkeit und Datenvermeidung steht einer Messhäufigkeit im Sekundenbereich und der vollständigen Speicherung des Stromverbrauchs entgegen. Eine regelmäßige oder durch ¨ Fernabfrage ermöglichte Ubermittlung dieser Daten an Energieversorger oder Netzbetreiber sollte nicht nur einer ausdrücklichen Zustimmung aller im Haushalt lebenden Personen unterliegen, die Betroffenen sind auch darüber aufzuklären, welche Auswertungsmöglich5 Panasonic

Modellnummer TX-L37S10E


44

Hersteller Panasonic LG Orion Panasonic Sony Telefunken

Modellnr. Technik TX-L37S10E LCD 47LH4000 LCD TV32FX100D LCD TX-P50S20E Plasma KDL46EX505 LCD Cinevision 32 CR tube

Tabelle 1: Getestete TV-Geräte

wattmin

wattdiff

∼ 45

∼ 70.0

∼ 65

∼ 1.5

∼ 100

∼ 3.0

Korr. Korr. Korr. TVM 1a M 2b M 3c Seried 0.9599 0.9283 0.9487 < 0.85 0.9458 < < < 0.85 0.85 0.85 0.8958 0.9402 0.9326 0.8989

∼ 45

∼ 160.0

0.8722 0.9510 0.8871 0.8933

∼ 170

−

∼ 60

∼ 50.0

< < < 0.85 0.85 0.85 0.8833 0.9454 < 0.85

< 0.85 0.9283

a Fanboys

(2008). Regie: Kyle Newman. Erschien: 6. Februar, 2009 Race (2008). Regie: Paul W.S. Anderson. Erschien: 22. November, 2008 c 2012 (2009). Regie: Roland Emmerich. Erschien: 11. November, 2009 d JAG Pilotfolge. Regie: D. P. Bellisario. Erstausstrahlung: 23. September, 1995

b Death

keiten sich bei hoher Granularität der Messdaten ergeben. Die experimentell festgestellte Tatsache, dass die Daten beim getesteten Anbieter unverschlüsselt und nicht signiert u¨ bertragen werden, stellt einen Verstoß gegen Grundsätze von Datenschutz und Datensicherheit dar. Diese Tatsache wiegt umso schwerer, da beim getes¨ teten Anbieter vertraglich zugesichert wurde, dass die Ubertragung verschlüsselt erfolgt6 . Die prinzipiell vorhandene Möglichkeit, audiovisuelle Inhalte bzw. das eingestellte Fernsehprogramm zu identifizieren, führt zu einer neuen Qualität des Eingriffs in die private Lebensgestaltung. Die in diesem Beitrag durchgeführten Tests lassen aufgrund der u¨ berschaubaren Testdatenbasis (653 Videoinhalte) zwar keine Rückschlüsse zu, inwieweit eine forensische Auswertung der Stromverbrauchsdaten tatsächlich einen ausreichenden Beweiswert (bspw. zum Nachweis von Verstößen gegen das Urheberrecht) hätte; die Relevanz in Bezug auf die Schutzwürdigkeit der granularen Stromverbrauchsdaten ist aber bereits dadurch gegeben, dass unter günstigen Umständen eine Identifikation möglich ist.

Literatur [AG10]

A.Rial und G.Danezis. Privacy-Preserving Smart Metering, Technical Report MSRTR-2010-150. Microsoft Research, 2010.

[AMSF+ 10] A.Molina-Markham, P. Shenoy, K. Fu, E. Cecchet und D. Irwin. Private Memoirs of a Smart Meter. In 2nd ACM Workshop on Embedded Sensing Systems for Energy6 Der

Anbieter hat die Sicherheitslücke zwischenzeitlich bestätigt und Abhilfe in naher Zukunft angekündigt.


45

Efficiency in Buildings (BuildSys 2010), Zurich, Switzerland, November 2010. [BCC11]

D. Bachfeld, D. Carluccio und C.Wegener. Wer hat an der Uhr gedreht? Sicherheit bei intelligenten Stromzählern. In c’t-Magazin (Heise Verlag), 23/2011, 2011.

[Bö11]

M. Bö. Was moderne Stromzähler verraten könnten (Spiegel online). http://www. spiegel.de/netzwelt/netzpolitik/0,1518,787629,00.html, September 2011.

[EGKP11]

Enev, Gupta, Kohno und Patel. Televisions, Video Privacy, and Powerline Electromagnetic Interference. In Proceedings of the 18th ACM conference on Computer and communications security (Oct. 2011). ACM, 2011.

[EK10]

C. Efthymiou und G. Kalogridis. Smart Grid Privacy via anonymization of smart metering data. In First IEEE International Conference on Smart Grid Communications, SmartGridComm10, 2010.

[EKD+ 10]

C. Efthymiou, G. Kalogridis, S.Z. Denic, T.A. Lewis und R.Cepeda. Privacy for Smart Meters, Towards Undetectable Appliance Load Signatures. In First IEEE International Conference on Smart Grid Communications, SmartGridComm10, 2010.

[GJL12]

U. Greveler, B. Justus und D. Loehr. Multimedia Content Identification Through Smart Meter Power Usage Profiles. In 5th International Conference on Computers, Privacy and Data Protection, Brussels. Springer, 2012.

[Har92]

G.W. Hart. Nonintrusive appliance load monitoring. 80(12):1870–1891, 1992.

[KDLC11]

G. Kalogridis, S. Denic, T. Lewis und R. Cepeda. Privacy protection system and metrics for hiding electrical events. IJSN, 6(1):14–27, 2011.

[LFL07]

H. Lam, G. Fung und W. Lee. A Novel Method to Construct a Taxonomy of Electrical Appliances Based on Load Signatures. In IEEE Transactions on Consumer Electronics, 2007.

[Mü10]

K. Müller. Gewinnung von Verhaltensprofilen am intelligenten Stromzähler. Datenschutz und Datensicherheit - DuD, 34:359–364, 2010. 10.1007/s11623-010-0107-2.

[Pru02]

A. Prudenzi. A Neuron Nets based procedure for identifying domestic appliances pattern-of-use from energy recording at meter panel. In IEEE Power Engineering Society Winter Meeting, 2002.

[Qui09]

E.L. Quinn. Privacy and New Energy Infrastructure. http://papers.ssrn.com/sol3/papers.cfm?abstract id=1370731, 2009.

[Ren11]

¨ S. Renner. Smart Metering und Datenschutz in Osterreich, Datenschutz und Datensicherheit - DuD 2011.

Proceedings of the IEEE,

Available:

Analyse und Vergleich von BckR2D2-I und II 1

2

2

2

Andreas Dewald , Felix C. Freiling∗ , Thomas Schreck , Michael Spreitzenbarth , 2

2

3

Johannes Stüttgen , Stefan Vömel , und Carsten Willems 1

2

Universität Mannheim Friedrich-Alexander Universität Erlangen-Nürnberg 3

Ruhr-Universität Bochum

Abstract: Im Oktober 2011 erregte die Veröffentlichung von Details u¨ ber die inzwischen meist als BckR2D2 bezeichnete Schadsoftware o¨ ffentliches Aufsehen. Mitglieder des Chaos Computer Club e.V. veröffentlichten einen ersten Bericht u¨ ber die Funktionsweise des ¨ Trojaners, dem weitere Analysen folgten. In dieser Arbeit geben wir einen Uberblick u¨ ber die bislang veröffentlichen Einzelberichte und u¨ ber die verschiedenen Komponenten der Schadsoftware sowie deren Funktionsweise. Hierzu präsentiert diese Arbeit die wesentlichen Ergebnisse einer ausführlichen Analyse aller Komponenten des Trojaners und geht insbesondere auf Unterschiede zwischen den beiden bislang bekannten Varian¨ ten BckR2D2-I und II ein. Ziel dieser Arbeit ist auch die kritische Uberpr¨ ufung der von anderen Autoren getroffenen Aussagen u¨ ber die Schadsoftware.

1 Einleitung Im Laufe des Jahres 2011 wurden verschiedene Versionen der inzwischen als BckR2D2 bezeichneten Schadsoftware bekannt. Eine erste Analyse wurde Anfang Oktober 2011 durch den Chaos Computer Club e.V. (CCC) in Form einer Presseerklärung sowie eines dazugehörigen 20-seitigen Berichts veröffentlicht [Cha11d, Cha11b]. In diesem werden einzelne Programmfunktionen und insbesondere der eingesetzte Verschlüsselungsmechanismus detailliert dargestellt. F-Secure, ein bekannter Hersteller von Anti-Viren-Software, berichtete wenige Tage später in seinem Blog u¨ ber einen so genannten Dropper [FS11], welcher den eigentlichen Trojaner installiert. Dieser wurde offenbar bereits im Dezember 2010 beim Onlinedienst VirusTotal1 hochgeladen und beinhaltet eine Installationsroutine zur Einrichtung der verschiedenen Programmkomponenten der Schadsoftware auf einem System. Knapp zwei Wochen später veröffentlichte der CCC einen Bericht u¨ ber die Unterschiede zwischen beiden Varianten [Cha11e, Cha11c]. Der Fokus dieser Analyse liegt wiederum auf der Art und Weise des Einsatzes von Verschlüsselungstechniken. Eine weitere, kurze Analyse des Droppers stammt von Tillmann Werner [Wer11]. Diese Analysen, vor allem die des CCC, erregten ein umfangreiches o¨ ffentliches Aufsehen. Eine kritische Würdigung dieser Analysen sowie eine detaillierte Aufstellung der Quellengenese existiert jedoch bisher noch nicht. ∗ Kontaktautor,

Kontaktadresse: Am Wolfsmantel 46, 91058 Erlangen, Deutschland.

1 http://www.virustotal.com/

48

Analyse und Vergleich von BckR2D2-I und II

Ausgangspunkt unserer Arbeit war die von uns als BckR2D2-I bezeichnete Variante der Schadsoftware. Diese wurde uns von Rechtsanwalt Patrick Schladt zur Verfügung gestellt und stammt von der Festplatte eines seiner Mandanten. Diese Version wurde bereits 2009 eingesetzt und stellt das bislang a¨ lteste den Autoren bekannte Exemplar der Trojaner-Familie dar. Im Oktober 2011 veröffentlichten Mitglieder des CCC ebenfalls eine Variante dieses Trojaners [Cha11d], die auf den ersten Blick nicht mit der Version BckR2D2-I u¨ bereinstimmte. Nach eingehender Analyse gelangten wir jedoch zu der Einsicht, dass es sich bis auf minimale Modifikationen um die gleiche Variante der Schadsoftware handelt. Daher bezeichnen wir diese als BckR2D2-I’.2 Zusätzlich wurde uns eine Version des Droppers [FS11, Cha11e, Wer11] von einem Hersteller von Antiviren-Software zur Verfügung gestellt. Wir bezeichnen diese Version als BckR2D2-II. Abbildung 1 veranschaulicht die Quellengenese, also die Herkunft der unterschiedlichen Versionen der Schadsoftware sowie die der jeweiligen Version zugehörigen Komponenten. Schladt

CCC Website

anonymer AV-Hersteller

R2D2-I' ~ R2D2-I

R2D2-II

Dropper

User-Level-Anwendung

Remover

64-bit Kernel-Level-Treiber Softwarebibliothek

32-bit Kernel-Level-Treiber

Softwarebibliothek

32-bit Kernel-Level-Treiber

Abbildung 1: Herkunft und Komponenten der unterschiedlichen Versionen von BckR2D2.

¨ Ziel dieser Arbeit ist es, einen unabhängigen Uberblick u¨ ber die beiden bislang bekannten, unterschiedlichen Varianten der Schadsoftware zu liefern und einen Vergleich untereinander zu ziehen. Ein besonderes Augenmerk gilt hierbei potenziellen Erweiterungen oder Einschränkungen des Funktionsumfanges sowie Verbesserungen zwischen den verschiedenen Versionen. Hierzu unterzogen wir beide Varianten der Schadsoftware einer intensiven statischen Analyse. In dieser Arbeit werden die wesentlichen Ergebnisse dieser Analyse erläutert. Im Zuge dessen werden insbesondere die in unterschiedlichen Quellen [Cha11b, Cha11e, FS11, Wer11] veröffentlichten Aussagen u¨ ber einzelne Varianten der Schadsoftware u¨ berprüft. Aufgrund der Seitenlimitierung beschränken sich die Autoren in dieser Arbeit auf die Erläuterung der wichtigsten Ergebnisse. Weitere Details werden die Autoren in einem technischen 2 So beschreibt der CCC eine Reihe zum Zwecke des Quellenschutzes vorgenommener Anderungen, ¨ die zu BckR2D2-I’ führten, auf seiner Webseite [Cha11a].


49

Bericht [DFS+ 11] zur Verfügung stellen.

1.1

Gliederung der Arbeit

Die restlichen Abschnitte dieser Arbeit sind wie folgt gegliedert: Abschnitt 2 gibt einen kurzen ¨ Uberblick u¨ ber die einzelnen Komponenten der Schadsoftware. Eine detaillierte Analyse der Komponenten folgt in Abschnitt 3. Wichtige Unterschiede zwischen den beiden Schadsoftwareversionen sind in Abschnitt 4 näher erläutert. Eine abschließende kurze Zusammenfassung der Untersuchungsergebnisse ist Gegenstand von Abschnitt 5.

2

¨ ¨ Uberblick uber die Komponenten von BckR2D2

Bislang sind insgesamt fünf verschiedene Komponenten unterschiedlicher Funktionalität bekannt, die der Schadsoftware zuzuordnen sind. Diese Komponenten liegen jedoch ausschließlich für die Variante BckR2D2-II vollständig vor und sind in dem bereits genannten Dropper [FS11] enthalten. Für die a¨ ltere Variante BckR2D2-I liegt lediglich der 32-bit Kernel¨ Level-Treiber und die Softwarebibliothek vor. Ein Uberblick u¨ ber die betreffenden Ressourcen ist mit einer kurzen Beschreibung in Tabelle 1 dargestellt. Bezeichnung Dropper Softwarebibliothek Kernel-Level-Treiber (32-bit) Kernel-Level-Treiber (64-bit ) User-Level-Anwendung Remover

Kurzbeschreibung Installationsroutine zur Einrichtung der anderen Komponenten ¨ Bibliothek zur Uberwachung verschiedener Applikationen Treiber zur Bereitstellung privilegierter Operationen (benötigt Administratorrechte) Treiber zur Bereitstellung privilegierter Operationen (benötigt Administratorrechte) Programm als bestmöglicher Ersatz für den Kernel-Level-Treiber bei eingeschränkten Benutzerrechten Hilfsprogramm zum Löschen beliebiger Dateien

erläutert in Abschnitt 3.1 Abschnitt 3.2 Abschnitt 3.3 Abschnitt 3.3 Abschnitt 3.4 Abschnitt 3.5

Tabelle 1: Komponenten der untersuchten Schadsoftware

Neben dem bereits genannten Dropper, der Softwarebibliothek und dem 32-bit Kernel-LevelTreiber existiert weiterhin ein 64-bit Kernel-Level-Treiber sowie eine User-Level-Anwendung, welche die Funktionalitäten des Kernel-Level-Treibers soweit wie möglich ersetzt, falls bei der Installation der Schadsoftware keine Administratorprivilegien zur Verfügung stehen. Ein so genannter Remover dient zum Löschen von Dateien und zur Verwischung angefallener ¨ Spuren. Tabelle 3 im Anhang enthält eine Ubersicht u¨ ber die Prüfsummen und die Dateigrößen

50


der einzelnen analysierten Komponenten.

3 Analyse der Komponenten In diesem Abschnitt werden die Ergebnisse der Analyse aller Komponenten der Schadsoftware in Bezug auf ihre Funktion und Implementierung erläutert.

3.1

Dropper

Die verschiedenen Komponenten der Schadsoftware in Variante BckR2D2-II werden mit Hilfe einer Installationsroutine auf dem Zielsystem eingebracht. Dabei handelt es sich um eine ausführbare .exe-Datei. Dieses Installationsprogramm enthält sämtliche Komponenten der Schadsoftware als eingebettete Ressource, die mittels einer dreistelligen Ziffernfolge im Bereich von 101 bis 118 eindeutig referenziert werden können. Nach Aufruf der Installationsroutine versucht diese zunächst im Windows-Systemverzeichnis des Rechners eine temporäre Datei mit dem Namen ˜pgp˜.tmp anzulegen, um die Schreibberechtigung für dieses Verzeichnis zu prüfen. Sofern diese Operation erfolgreich durchgeführt werden konnte, wird die temporäre Datei anschließend sofort wieder gelöscht und eine dynamische Bibliothek mit der internen Ressourcennummer 101 unter dem Namen mfc42ul.dll im besagten Verzeichnis abgelegt. Es handelt sich hierbei um die Softwarebibliothek der Schadsoftware, welche in Abschnitt 3.2 erläutert wird. Wahrscheinlich um die Bibliothek besser vor einer Entdeckung zu schützen oder den Instal¨ lationszeitpunkt zu verschleiern, werden die Erstell-, Anderungsund Zugriffs-Zeitstempel der Datei von der namensähnlichen Bibliothek mfc42.dll u¨ bernommen. Letztere ist legitimer Bestandteil der Microsoft Foundation Classes (MFC), einer Sammlung von Klassen für die Softwareentwicklung mit C++, die u¨ blicherweise auf Microsoft Betriebssystemen vorinstalliert ist [Mic11]. Wenn diese jedoch nicht in Version 4.2 auf dem Zielrechner vorgefunden werden kann, so erfolgt die Anpassung aller Zeitstempel der Softwarebibliothek auf das fest codierte Datum 04.08.2004, 12:00 Uhr. Die bloße Betrachtung kürzlich vorgenommener ¨ Anderungen auf dem System führt also nicht zur Aufdeckung der installierten Komponente. Jedoch existiert im NTFS-Dateisystem, welches seit Windows 2000 standardmäßig eingesetzt ¨ wird, ein weiterer, meist als ctime bezeichneter Zeitstempel, der die letzte Anderung der zugehörigen Dateisystem-Datenstruktur angibt [Gar09]. Dieser Zeitstempel ist nicht ohne Weiteres zur Laufzeit des Systems manipulierbar. Auf Basis dieses Zeitstempels sind daher unter Umständen dennoch Rückschlüsse auf den eigentlichen Installationszeitpunkt der Schadsoftware möglich. In Abhängigkeit der festgestellten Betriebssystemarchitektur wird im weiteren Verlauf der Installation ein 32- oder 64-bit Treiber aus der internen Ressourcentabelle geladen (Ressourcennummer 102 und 118) und unter dem Namen winsys32.sys im Systemverzeichnis der Windows-Installation gespeichert. Im nächsten Schritt wird der Treiber mit Hilfe der CreateService-Funktion als SERVICE KERNEL DRIVER (Servicetyp: 0x00000001) mit vollen Rechten und ohne weitere Abhängigkeiten auf dem Computer eingerichtet und


51

nachfolgend gestartet. Auch hier erfolgt eine Anpassung der Zeitstempel auf die bereits bei der Installation der Softwarebibliothek genannten Werte. Im Anschluss an diesen Vorgang initiiert das Installationsprogramm mehrere Code Injection-Operationen und schleust die Softwarebibliothek in verschiedene Prozesse ein, namentlich in den Windows-Explorer (Explorer.exe) sowie in zwei Prozesse der VoIP-Software Skype (Skype.exe, SkypePM.exe). In einem letzten Schritt extrahiert die Routine eine weitere Ressource, die intern unter der Nummer 106 abgelegt ist und auf der Festplatte des Zielsystems unter dem Dateinamen ãcrd˜tmp˜.exe in einem temporären Verzeichnis gespeichert wird. Wie die Autoren in Abschnitt 3.5 darstellen, handelt es sich dabei um ein rudimentäres Löschwerkzeug, mit dem das ursprüngliche Installationsprogramm nach Abschluss aller Maßnahmen wieder entfernt werden kann. Sofern die oben aufgeführten Dateien nicht im Systemverzeichnis der Windows-Installation erstellt werden können, beinhaltet das Installationsprogramm einen alternativen Infektionsweg: Hierbei wird die Softwarebibliothek (Ressourcennummer 101) im Applikationsverzeichnis des aktiven Benutzers abgelegt und als versteckt markiert.3 Als Ersatz für den Systemtreiber, der aufgrund der fehlenden Rechte nicht eingesetzt werden kann, erstellt die Routine zwei versteckte und sich gegenseitig u¨ berwachende Instanzen der User-Level-Anwendung unter dem Namen SkypeLauncher.exe und SkypePM Launcher.exe, die u¨ ber den Registrierungsschlüssel HKCU\Software\Microsoft\CurrentVersion\ Run standardmäßig bei jedem Start des Betriebssystems gestartet werden. Wie wir in Abschnitt 3.4 ¨ näher darstellen werden, sind diese Prozesse für die Uberwachung einer Vielzahl von Anwendungsprogrammen verantwortlich.

3.2

Softwarebibliothek

Die Softwarebibliothek wird in mehrere laufende Prozesse injiziert. (Die hierzu genutzten Ansätze werden in Abschnitt 4.2 näher erläutert, da sie sich in den beiden vorliegenden Varianten stark unterscheiden.) In Abhängigkeit des jeweiligen Elternprozesses, in den die Softwarebibliothek injiziert wurde, weisen die gestarteten Threads unterschiedliche Verhaltensmuster auf. So u¨ berprüft beispielsweise der in den Windows Explorer eingeschleuste Code die Version und das Patchlevel des Betriebssystems. ¨ Ein primäres Ziel der Softwarebibliothek ist offenbar die Uberwachung der Software Skype. Hierzu registriert sich die Bibliothek u¨ ber die offizielle Schnittstelle als Skype-Erweiterung, was dazu führt, dass sie u¨ ber eingehende und abgehende Anrufe und Textnachrichten infor¨ miert wird. Uber die Windows Multi-Media-Library (winmm.dll) wird dann im Falle eines Anrufs der Ton aufgezeichnet, mit dem freien Audiocodec libspeex komprimiert und an den Kontrollserver u¨ bertragen. Der Kontrollserver ist ein System, von welchem der Trojaner mögliche Steuerbefehle erhält bzw. an den er aufgezeichnete Daten versendet. Um einen Informationsaustausch mit anderen observierten Programmen zu ermöglichen, werden benannte Dateimappings verwendet, eine Art von gemeinsamem Speicher (Shared Memory) unter Microsoft Windows. Die Namen dieser Mappings beginnen in BckR2D2 stets mit der Zeichenfolge SYS!I[PC|CP]!, gefolgt von einer mehrstelligen Ziffernkombination, im 3 Unter Microsoft Windows XP ist das Applikationsverzeichnis eines Benutzers unter C:\Dokumente und Einstellungen\\Anwendungsdaten zu finden.

52


Fall des Microsoft Messengers zum Beispiel, 79029. Die Schadsoftware ist ebenfalls in der Lage, die gesammelten Informationen u¨ ber das Internet an einen Kontrollserver zu senden. Hierzu nimmt ein dedizierter Thread u¨ ber den Port 443 Kontakt mit dem Server auf. Kommando 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0C 0x0D 0x0E 0x10 0x11 0x12

Beschreibung Anfertigung von Bildschirmschnappschüssen von aktiven Fenstern eines Internetbrowsers Erstellung eines dedizierten Threads, der periodische Bildschirmschnappschüsse des kompletten Bildschirms anfertigt Entfernung des Kernel-Level-Treibers, Einrichtung der Schadsoftware im Applikationsverzeichnis des Benutzers Aktualisierung der Schadsoftware u¨ ber das Netzwerk Herunterfahren des Systems per ExitWindowsEx() (EWX_SHUTDOWN, EWX_FORCE) Herunterfahren per KeBugCheckEx() (erzeugt einen Blue Screen of Death) Abfrage der installierten Anwendungen und Programme Erstellung eines weiteren Threads, der periodische Bildschirmschnappschüsse anfertigt (Code a¨ hnlich zu Kommando 0x03) Entgegennahme mehrerer (unbekannter) Parameter u¨ ber das Netzwerk Anfertigung von Bildschirmschnappschüssen von bestimmten Fenstern im Vordergrund, unter anderem auch Internetbrowsern (ähnlich zu Kommando 0x02) ¨ Ubertragung und Ausführung einer beliebigen Datei Noch unbekannt Noch unbekannt Null-Rückgabe

I

II

x x x

x

x

x

x

x

x

x

x x x

x

x x x x x

x x x

Tabelle 2: Unterstützte Kommandos der Schadsoftwarebibliothek in den beiden Trojaner-Varianten (x = Funktionalität vorhanden)

Der Kontrollserver kann mit Hilfe einer Reihe von Kommandobefehlen den Client zur Durchführung verschiedener Operationen anweisen. Dazu gehört insbesondere die Anfertigung von ¨ Bildschirmschnappschüssen, aber auch die Ubertragung und Ausführung beliebiger Dateien. ¨ Eine Ubersicht und Beschreibung der in den jeweiligen Versionen implementierten Befehle ist in Tabelle 2 aufgeführt. Wie aus dieser Tabelle ersichtlich, konnten die Kommandos 0x0C, 0x10 und 0x11 bis zum gegenwärtigen Zeitpunkt noch nicht vollständig analysiert werden.

3.3

Kernel-Level-Treiber

Dieser Abschnitt basiert im wesentlichen auf der Analyse von BckR2D2-I. Die beschriebene Funktionalität ist auch in BckR2D2-II enthalten, jedoch enthält BckR2D2-II einige weitere Funktionen, deren Zweck zum gegenwärtigen Zeitpunkt unklar ist. Der Kernel-Level-Treiber bietet zahlreiche Funktionen, um unter Umgehung der im User-


53

Dropper (BckR2D2-II) installiert

installiert

Softwarebibliothek

kommunizieren injiziert (BckR2D2-II)


in diverse Prozesse injiziert Abbildung 2: Zusammenspiel der Komponenten mit dem Kernel-Level-Treiber.

¨ mode geltenden Sicherheitsmaßnahmen des Betriebssystems Anderungen am System vorzunehmen. Des Weiteren ist eine Keylogger-Funktionalität enthalten, die jedoch bereits in der Version BckR2D2-I deaktiviert ist. (Der entsprechende Code ist zwar vorhanden, wird jedoch aus dem Treiber selbst nicht angesprungen.) Außerdem beinhaltet er zwei weitere Codefragmente, die in der vorliegenden Version jedoch nicht weiter referenziert werden. Abbildung 2 ¨ zeigt eine schematische Ubersicht u¨ ber das Zusammenspiel des Kernel-Level-Treibers mit den u¨ brigen Komponenten. Für weitere Details zum Kernel-Level-Treiber verweisen wir aus Platzgründen auf den technischen Bericht.

3.4


Die Anwendung mit der Ressourcen-Nummer 107 dient als Ersatz für den Kernel-LevelTreiber. So kann die Software auch auf Systemen verwendet werden, bei denen es zum Infektionszeitpunkt nicht möglich ist, Administrator-Rechte zu erlangen. Die Anwendung erfüllt zwei Aufgaben: Zum einen u¨ berprüft sie periodisch, ob die Installation beschädigt wurde. Wird festgestellt, dass der oben genannte Run-Key aus der Systemregistrierung entfernt oder das Image der Anwendung von der Festplatte gelöscht wurde, generiert sie eine entsprechende Fehlermeldung und kommuniziert diese der Softwarebibliothek. Die zweite Aufgabe ist das Injizieren der Softwarebibliothek in folgende Prozesse: • explorer.exe • SkypePM.exe • yahoomessenger.exe

• Skype.exe • msnmsgr.exe

In Abbildung 3 ist analog zu Abbildung 2 die Einrichtung der eingesetzen Komponenten bei fehlenden Berechtigungen aufgezeigt. Dieses Szenario ist jedoch, ebenso wie der Dropper, nur aus BckR2D2-II bekannt.

54


Dropper (BckR2D2-II) installiert

Softwarebibliothek

installiert

injiziert (BckR2D2-II)

zwei Instanzen überwachen sich gegenseitig


in diverse Prozesse injiziert

Abbildung 3: Zusammenspiel der Komponenten mit der User-Level-Anwendung.

3.5

Remover

Bei dieser Komponente der Schadsoftware, dem sogenannten Remover, handelt es sich um ein einfaches Löschwerkzeug, das beliebige Dateien von der Festplatte des kompromittierten Systems entfernen kann. Die zu löschende Datei wird dabei als Kommandozeilenparameter spezifiziert. Der eigentliche Löschvorgang erfolgt u¨ ber den Windows-Systemaufruf DeleteFileA(). Diese Funktion u¨ berschreibt die eigentlichen Daten nicht, sodass es prinzipiell möglich ist, die gelöschte Datei wiederherzustellen. Nach Abschluss der Operation, die bei Nichterfolg insgesamt maximal 10 Mal wiederholt wird, vernichtet sich das Werkzeug mit Hilfe der MoveFileExA-Funktion beim nächsten Systemstart selbständig.

4 Vergleich von BckR2D2-I und BckR2D2-II Im Folgenden stellen wir die beiden Varianten der Schadsoftware BckR2D2 vergleichend ge¨ genüber und gehen auf die wesentlichen Unterschiede ein. Neben diversen Anderungen in der Softwarebibliothek wurde in der Version BckR2D2-II auch der Kernel-Level-Treiber wesentlich erweitert. In dieser Version existiert erstmals neben dem 32-bit Kernel-Level-Treiber auch eine Treiberversion für 64-bit Windows-Systeme.

4.1


Der Kernel-Level-Treiber hat in der 32-bit Version von BckR2D2-I eine Größe von 5.376 Bytes, in Version BckR2D2-II bereits eine Größe von 10.112 Bytes. Anzumerken ist, dass sich die Funktionen des Treibers zwischen den Varianten BckR2D2-I und BckR2D2-II bezüglich der unterstützten Routinen und der Kommandokommunikation zur Usermode-Applikation nicht wesentlich verändert haben. In Variante BckR2D2-II wurde der Kernel-Level-Treiber jedoch dahingehend erweitert, die Softwarebibliothek in verschiedene Prozesse zu injizieren. Hierzu startet der Treiber einen zusätzlichen Thread, um kontinuierlich die Liste aller laufenden Prozesse zu ermitteln und den Schadcode der Softwarebibliothek in die folgenden Anwendungs-


55

und Kommunikationsprogramme zu injizieren: • • • • • • •

skype.exe paltalk.exe voipbuster.exe simplite-icq-aim.exe skypepm.exe yahoomessenger.exe opera.exe

• • • • • • •

msnmsgr.exe x-lite.exe simppro.exe icqlite.exe firefox.exe explorer.exe lowratevoip.exe.

Der Kernel-Level-Treiber in BckR2D2-I besitzt diese Funktionalität nicht. Hier wird das Injizieren der Softwarebibliothek anderweitig erreicht (siehe Abschnitt 4.2). Zusätzlich zum 32bit Treiber besitzt die Variante BckR2D2-II eine 64-bit Version des gleichen Kernel-LevelTreibers. Voraussetzung für das Laden dieser Treiberversion unter 64-bit Windows-Systemen ist die Signierung des Treibers mit einem digitalen Zertifikat. Der 64-bit Kernel-Level-Treiber aus Variante BckR2D2-II wurde hierzu mit einem RSA Zertifikat des fiktiven Ausstellers Goose Cert (Fingerprint: e5 44 5e 4a 9c 7d 24 c8 43 f0 c6 69 e2 a8 d3 a1 78 cf 7f a8) signiert. In unseren Experimenten vertraute ein standardmäßig eingerichtetes 64-bit Windows 7-System diesem Zertifikat nicht und erforderte die manuelle Bestätigung der Treiberinstallation.

4.2

Softwarebibliothek

Die Softwarebibliothek aus Version BckR2D2-I wurde den Angaben im PE-Header zufolge am 07.04.2009, 14:39:10 Uhr, kompiliert. Die Version BckR2D2-II hingegen wurde am 06.12.2010 um 16:23:52 Uhr erstellt und ist damit u¨ ber 1 1/2 Jahre a¨ lter als seine Vorgängerversion. Obwohl eine Fälschung dieser Angaben leicht möglich ist, schätzen die Autoren eine gezielte Manipulation der Daten angesichts lediglich nur marginaler, von der Komponente angewandter Verschleierungsmaßnahmen als unwahrscheinlich ein. In der Version BckR2D2-I ist aufgrund der Programmarchitektur davon auszugehen, dass die Schadsoftware durch Veränderung eines Registrierungsschlüssels in alle startenden Prozesse injiziert wird.4 Da der Dropper für diese Version nicht vorliegt, ist dies jedoch nicht mit absoluter Sicherheit festzustellen. Die Software selbst beinhaltet aber keine entsprechende Funktionalität, sodass ein externer Eingriff für den Start zwingend notwendig ist. Wird die Bibliothek in einen Prozess geladen, führt sie initial immer einen Abgleich des Prozesses mit einer Whitelist durch. Nur wenn der Name der Image-Datei in der Liste vorhanden ist, wird die Bibliothek aktiv. In diesem Falle startet sie mehrere Threads, die Prozess-spezifische Aufgaben wahrnehmen. Die Prozessnamen in der Whitelist sind im einzelnen: • skype.exe • x-lite.exe • explorer.exe

• skypepm.exe • yahoomessenger.exe

• msnmsgr.exe

4 Der betreffende Registrierungsschlüessel lautet HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit DLLs und veranlasst das Betriebsystem, alle hier eingetragenen Bibliotheken in den Adressraum eines jeden gestarteten Prozesses zu laden.

56


Die Liste der u¨ berwachten Programme wurde in der Version BckR2D2-II um eine weitere Anwendung, der Video-Chat-Software Paltalk, erweitert (paltalk.exe). In Version BckR2D2-II wurde ein System mit der IP-Adresse 207.158.22.134 u¨ ber den Port 443 als Kontrollserver kontaktiert. Diese IP-Adresse ist laut der lokalen Internetregistrierungs- und Verwaltungsorganisation RIPE5 dem amerikanischen Unternehmen Web Intellects in Columbus, Ohio zugeordnet. In der Version BckR2D2-II wurde dieser Server durch einen Rechner in Deutschland ersetzt, der unter der IP-Adresse 83.236.140.90 erreichbar ist. RIPE hat als Inhaber der IP-Adresse die QSC AG registriert, welche diese wiederum an einen nicht näher genannten Kunden mit der Bezeichnung QSC-CUSTOMER-5464944-56 4637 vermietet. Bei allen untersuchten Varianten von BckR2D2 erfolgte eine Authentifizierung der Schadsoft¨ ware gegenüber dem Kontrollserver durch Ubermittlung der Zeichenkette C3PO-r2d2-POE, welche auch namensgebend für die Schadsoftware war. Aus diesem Grund ist es möglich, einen eigenen Kontrollserver zu präparieren und die Kontrolle u¨ ber durch BckR2D2 kompromittierte Systeme zu erhalten, wie der CCC bereits zeigte [Cha11b]. In Variante BckR2D2-II wurde das Kommunikationsprotokoll verbessert, indem sowohl beide Richtungen der Kommunikation verschlüsselt werden und eine Authentifizierung beider Kommunikationspartner erforderlich ist. Zur Verschlüsselung wird das symmetrische Verfahren AES (Advanced Encryption Standard) im Electronic Codebook-Verfahren (ECB) verwendet und als kryptographischer Schlüssel stets die konstante (hexadezimale) Zeichenfolge 49 03 93 08 19 94 96 94 28 93 83 04 68 28 A8 F5 0A B9 94 02 45 81 93 1F BC D7 F3 AD 93 F5 32 93 eingesetzt. Die in der Version BckR2D2-II neu implementierte Authentifikation des Servers gegenüber dem Client prüft lediglich, ob vor jedem Kommando vier sequentielle, fest codierte Werte (0x95838568, 0x0B894FAD4, 0x8202840E, 0x83B5F381) u¨ bertragen werden. Der Mechanismus kann deshalb durch einen nicht-authorisierten Angreifer leicht u¨ berwunden werden. Zur Löschung des Systemtreibers und der Schadbibliothek im Systemverzeichnis des Benutzers sowie zur Einrichtung entsprechender Komponenten im Applikationsverzeichnis (Kommando 0x04, siehe Tabelle 2) ist eine zusätzliche Authentifikationsprüfung vorgese¨ hen. Durch Ubertragung der Ziffernfolgen 0x0DEAF48F7, 0x8474BAFD, 0x0BAAD49F1 sowie 0x8472BCF2 kann diese ebenfalls erfolgreich u¨ berwunden werden. Schließlich unterscheiden sich die beiden Versionen der Softwarebibliothek hinsichtlich ihres angebotenen Funktionsumfangs: Die Anzahl der Operationen, die vom Kontrollserver auf dem kompromittierten System initiiert werden können, wurde in Variante BckR2D2-II im Vergleich zu BckR2D2-I von 14 auf 8 reduziert. Die jeweiligen Kommandos wurden jedoch lediglich dadurch deaktiviert, indem sie aus der Routine zur Befehlsverarbeitung entfernt wurden. Der entsprechende Code, welcher die Funktionalität der Kommandos bereitstellt, ist jedoch weitherhin in der Bibliothek enthalten.

5 Zusammenfassung Insgesamt konnten im Rahmen unserer Untersuchung die wesentlichen Ergebnisse der eingangs erwähnten Berichte bestätigt werden. Dies betrifft sowohl die Analyse des CCC [Cha11b] hinsichtlich der Funktionalität und des Einsatzes von Verschlüsselungsmechanismen in BckR2D2, 5 http://www.ripe.net/


57

als auch den Vergleich der beiden Versionen der Schadsoftware [Cha11e]. Auch die durch Werner beschriebene Funktionsweise des Droppers [Wer11] ist nach unseren Untersuchungen zutreffend.

Literatur [Cha11a] Chaos Computer Club. Addendum Staatstrojaner. http://www.ccc.de/de/ updates/2011/addendum-staatstrojaner, 9. Oktober 2011. [Cha11b] Chaos Computer Club. Analyse einer Regierungs-Malware. http://www.ccc.de/ system/uploads/76/original/staatstrojaner-report23.pdf, 8. Oktober 2011. [Cha11c] Chaos Computer Club. Chaos Computer Club analysiert aktuelle Version des Staatstrojaner. http://www.ccc.de/de/updates/2011/ analysiert-aktueller-staatstrojaner, 26. Oktober 2011. [Cha11d] Chaos Computer Club. Chaos Computer Club analysiert Staatstrojaner. http://www. ccc.de/de/updates/2011/staatstrojaner, 8. Oktober 2011. [Cha11e] Chaos Computer Club. ozapftis — Teil 2: Analyse einer RegierungsMalware. http://www.ccc.de/system/uploads/83/original/ staatstrojaner-report42.pdf, 26. Oktober 2011. [DFS+ 11] Andreas Dewald, Felix C. Freiling, Thomas Schreck, Michael Spreitzenbarth, Johannes Stüttgen, Stefan Vömel und Carsten Willems. Analyse und Vergleich von BckR2D2-I und II. Bericht CS-2011-08, Friedrich-Alexander Universität Erlangen-Nürnberg, Department Informatik, 2011. [FS11]

F-Secure. More Info on German State Backdoor: Case R2D2. http://www.f-secure. com/weblog/archives/00002250.html, 11. Oktober 2011.

[Gar09]

Simson L. Garfinkel. Automating Disk Forensic Processing with SleuthKit, XML and Python. In Fourth International IEEE Workshop on Systematic Approaches to Digital Forensic Engineering (SADFE), Seiten 73–84. IEEE Computer Society, 2009.

[Mic11]

Microsoft Corporation. MFC Reference. http://msdn.microsoft.com/de-de/ library/d06h2x6e.aspx, 2011.

[Wer11]

Tillmann Werner. Federal Trojan’s got a “Big Brother”. http://www.securelist. com/en/blog/208193167/Federal_Trojan_s_got_a_Big_Brother, 18. Oktober 2011.

58


¨ ¨ ¨ A Ubersicht uber Prufsummen und Dateigrößen ¨ Tabelle 3 enthält eine Ubersicht u¨ ber die Prüfsummen und die Dateigrößen der einzelnen analysierten Komponenten. Bezeichnung Dropper Softwarebibliothek Kernel-Level-Treiber (32-bit) Kernel-Level-Treiber (64-bit ) User-LevelAnwendung Remover

Version BckR2D2-II BckR2D2-I BckR2D2-I’ BckR2D2-II BckR2D2-I BckR2D2-I’ BckR2D2-II BckR2D2-II

¨ MD5-Prufsumme

cd01256f3051e6465b817fffc97767dd

Größe in Bytes 643.072 364.544 360.448 356.352 5.376 5.376 10.112 262.730

BckR2D2-II

976dd8be30df45c6fb2b4aaaa9ce9106

155.648

BckR2D2-II

96c56885d0c87b41d0a657a8789779f2

40.960

309ede406988486bf81e603c514b4b82 b5080ea3c9a25f2ebe0fb5431af80c34 930712416770a8d5e6951f3e38548691 934b696cc17a1efc102c0d5633768ca2 d6791f5aa6239d143a22b2a15f627e72 d6791f5aa6239d143a22b2a15f627e72 9a8004e2f0093e3fe542fa53bd6ad1b2

Tabelle 3: Komponenten der untersuchten Schadsoftware mit ihren zugehörigen Prüfsummen und Dateigrößen

Forensic Analysis of YAFFS2 Christian Zimmermann IIG Telematics University of Freiburg, Germany Michael Spreitzenbarth Sven Schmitt Felix C. Freiling∗ Department of Computer Science Friedrich-Alexander-University Erlangen-Nuremberg

Abstract: In contrast to traditional file systems designed for hard disks, the file systems used within smartphones and embedded devices have not been fully analyzed from a forensic perspective. Many modern smartphones make use of the NAND flash file system YAFFS2. In this paper we provide an overview of the file system YAFFS2 from the viewpoint of digital forensics. We show how garbage collection and wear leveling techniques affect recoverability of deleted and modified files.

1 Introduction The ubiquitous use of smartphones and other mobile devices in our daily life demands robust storage technologies that are both low-cost and well suited for embedded use. There are several reasons why hard disks are not at all well suited for embedded use: physical size, power consumption and fragile mechanics are just some of the reasons. That is why other technologies, namely NAND flash, became very popular and are widely used within modern embedded devices today. NAND flash chips contain no moving parts and have low power consumption while being small in size. However, NAND flash is realized as integrated circuits “on chip” and comes with some limitations regarding read/write operations that can lead to decreased performance under certain conditions. Furthermore, flash technology is subject to wear while in use which may dramatically shorten the chips’ lifetime. Thus, various specific techniques have been developed to overcome such shortcomings and to enable flash technology to withstand a substantial amount of read/write operations at constant speeds. Classically, these techniques are integrated into dedicated controllers that implement and enforce the above mentioned flash specific algorithms on the hardware level. From the perspective of digital forensics, hard drives and low-level structures of various file systems are rather well studied (see for example Carrier [Car05]). The effects of NAND technologies on the amount of recoverable data on storage devices, however, is hardly understood today. Since wear leveling techniques tend to “smear” outdated data ∗ Contact

author. Address: Am Wolfsmantel 46, 91058 Erlangen, Germany.

60

Forensic Analysis of YAFFS2

all over the device, it is often conjectured that digital investigations can profit from the widespread introduction of NAND flash, because it is harder for criminals to delete files and cover their traces. However, we are unaware of any related work that has investigated this question. Probably this is due to the difficulty of circumventing the controllers of NAND flash chips. Another option, however, to implement NAND flash specific behavior is to use specifically designed file systems. These file systems are aware of the generic flash limitations and take these into account on the software level when reading and writing data from and to the chip. Such file systems are much easier to analyze since they implement techniques like wear leveling in software. The most common example of such a file system is YAFFS2, a file system used by the popular Android platform, which is “the only file system, under any operating system, that has been designed specifically for use with NAND flash” [Man02]. YAFFS2 stands for “Yet Another Flash File System 2” and was the standard file system for the Android platform until 2010. Allthough since the beginning of 2011 with version Gingerbread (Android 2.3) the platform switched to the EXT4 file system, there are still many devices in use running a lower version than 2.3 and thus using YAFFS2. Therefore, insights into the amount and quality of evidence left on YAFFS2 devices is still of major interest. Goal of this paper. In this paper, we give insights into the file system YAFFS2 from a forensic perspective. Next to giving a high level introduction to YAFFS2, our goal is to explore the possibilities to recover modified and deleted files from YAFFS2 drives. Since there is no specific literature on this topic, we reverse engineered [ZSS11] the behavior of the file system from the source code of the YAFFS2 driver for Debian Linux running kernel version 2.6.36. Results. As a result of our analysis, we found out that the movement of data on a YAFFS2 NAND never stops and that obsolete data (that could be recovered) is eventually completely deleted. Thus, a YAFFS2 NAND stays only for a very brief span of time in a state that can be considered a best case scenario regarding recovery of obsolete data. In one of our conducted tests, the block that held a deleted file was finally erased 7 minutes and 53 seconds after the file was deleted. Larger devices have a positive effect on this time from a forensic point of view (i.e., they potentially enlarge the time span). Therefore, the chances to recover deleted data after days or weeks, as can be done on classical hard disks [Car05], are not very high in YAFFS2. Roadmap. We begin by giving a high-level introduction into the concepts and terminology of YAFFS2 in Section 2. In Section 3 we give insights into the inner workings of its algorithms. We construct and experimentally analyze best case scenarios in Section 4 and present some results regarding the recovery of files in Section 5. We conclude in Section 6.


61

2 A Brief Introduction to YAFFS2 Blocks and chunks. YAFFS2 separates storage into several areas of fixed size, called blocks. Within each block, again there exist several areas of fixed size, but smaller than the size of a block. These areas are called chunks. Following the characteristics of NAND flash, a chunk is the smallest amount of data which can be written whereas a block is the smallest amount of data which can be erased from the flash. Data can only be written to a block if the corresponding chunk was erased beforehand. A chunk that was just erased is called free. Free and obsolete chunks. Since data can only be written to free chunks, modification of data is more complicated than on classical hard drives. To modify data, the data must first be read, then be modified in memory and finally be written back to a free chunk. This method is similar to the well known Copy-on-Write method. YAFFS2 writes chunks sequentially and marks all chunks with a sequence number in the flash. That way, any chunk that was associated with the original data will be identified as obsolete although it still holds the original (now invalid) data. The existence of obsolete chunks is interesting from a forensic investigator’s point of view: Whenever one or more obsolete chunks exist within a block, the corresponding data will still be recoverable until the respective block gets garbage collected. After this block gets garbage collected, all of its obsolete chunks will be turned to free chunks. Header chunks and data chunks. YAFFS2 distinguishes between header chunks used to store an object’s name and meta data and data chunks which are used to store an object’s actual data content [Man10]. The meta data in such a header chunk describes if the corresponding object is a directory, regular data file, hard link or soft link. In Table 1 the structure of a regular file with three chunks of data and one header chunk is shown. Block 1 1 1 1

Chunk 0 1 2 3

Object ID 100 100 100 100

Chunk ID 0 1 2 3

Comment Object header chunk for this file First chunk of data Second chunk of data Third chunk of data

Table 1: Structure of a file with one header chunk and three data chunks.

If a file shrinks in size, data chunks become invalid and the corresponding header chunk receives a special shrink-header marker to indicate this. In Table 2 we show how a deleted file looks like. In this case chunk number 5 indicates that the file had been deleted and this chunk receives the shrink-header marker. As we show below, shrink-header markers are important because object headers with this marker are prevented from being deleted by garbage collection [Man10, Sect. 10].

62


Block 1 1 1 1 1 1

Chunk 0 1 2 3 4 5

Object ID 100 100 100 100 100 100

Chunk ID 0 1 2 3 0 0

Comment Object header chunk for this file First chunk of data Second chunk of data Third chunk of data New object header chunk (unlinked) New object header chunk (deleted)

Table 2: Structure of the file from Table 1 after the file had been deleted.

Object ID and Chunk ID. Each object (file, link, folder, etc.) has its own Object ID, thus it is possible to find all chunks belonging to one specific object. A Chunk ID of 0 indicates that this chunk holds an object header. A different value indicates that this is a data chunk. The value of the Chunk ID stands for the position of the chunk in the file. If you have a chunk with Chunk ID = 1 it means, that this is the first data chunk of the corresponding object. The tnode tree. YAFFS2 keeps a so-called tnode tree in RAM for every object. This tree is used to provide mapping of object positions to actual chunk positions on a NAND flash memory device. This tree’s nodes are called tnodes [Man10, Sect. 12.6.1]. Checkpoint data. Checkpoint data is written from RAM to a YAFFS2 NAND device on unmounting and contains information about all of a device’s blocks and objects (a subset of information stored in the tnode tree). It is used to speed up mounting of a YAFFS2 NAND device. The number of blocks needed to store a checkpoint consists of (1) a fixed number of bytes used for checksums and general information regarding the device and (2) a variable number of bytes depending on the number of objects stored on the device and the device’s size. The variable part of a checkpoint consists of information on blocks, objects and tnodes.

3 Garbage Collection in YAFFS2 In YAFFS2, obsolete chunks can only be turned into free chunks by the process of garbage collection. Among all of YAFFS2’s characteristics and functionalities, the garbage collection algorithm has the most significant impact on the amount of deleted or modified data that can be recovered from a NAND. In this section, we describe the different garbage collection methods (Section 3.1). An important variant of garbage collection is called block refreshing and explained in Section 3.2. Additionally, we describe the impact of shrink header markers on garbage collection (Section 3.3). For brevity, detailed references to the source code of the Linux driver can be found elsewhere [Zim11, ZSS11].


3.1

63

Garbage Collection Methods

Garbage collection is the process of erasing certain blocks in NAND flash to increase the overall amount of free blocks. Valid data that exists in blocks selected for garbage collection will first be copied to another block and thus not be erased. Garbage Collection can be triggered either from a foreground or a background thread. The trigger within a foreground thread is always a write operation to the NAND. Background garbage collection is not directly triggered by any foreground thread, but executed even when the device is idle. Background garbage collection typically takes place every two seconds. Interestingly, the behavior of garbage collection does not primarily depend on a device’s storage occupancy. Execution rather depends on the current state of blocks regarding the amount of obsolete chunks they hold. Still, every garbage collection can be performed either aggressively or passively, depending on the device’s storage occupancy. Passive background garbage collection only collects blocks with at least half of their chunks being obsolete and only checks 100 blocks at most when searching a block to garbage collect. Foreground garbage collection is executed passively if one quarter or less of all free chunks are located in free blocks and a block with seven-eighths of its chunks being obsolete can be found. If no block of the entire flash qualifies for erasure, oldest dirty garbage collection is executed. This type of garbage collection selects the oldest block that features at least one obsolete chunk. It is executed every time background or foreground garbage collection have been skipped (due to the lack of qualifying blocks) 10 or respectively 20 consecutive times. Hence, as long as every block of a device has at least half of its chunks filled with valid data, the only way a block can be garbage collected is through oldest dirty garbage collection (or its variant called block refreshing explained below). Aggressive garbage collection occurs if background or foreground garbage collection is performed and a device does not feature enough free blocks to store checkpoint data. Aggressive garbage collection potentially deletes a higher number of obsolete chunks per cycle than passive garbage collection and is triggered if a device features less than a certain threshold of free blocks, where the threshold depends on the size of the checkpoint data [ZSS11]. Summary from a forensic perspective. The scenario where a maximum of obsolete chunks can be recovered (and therefore the “best” case for a forensic analyst) requires that during the whole time of its usage a device features enough free blocks to store checkpoint data and a distribution of obsolete and valid chunks that leads to every block having just more than half of its chunks being valid. Additionally, enough free blocks must be available to ensure that more than one quarter of all free chunks is located within empty blocks. This results in a behavior in which all blocks are garbage collected as seldom as possible and still feature a high number of obsolete chunks that potentially contain evidence.

64

3.2


Block Refreshing

YAFFS2’s only explicit wear leveling technique is block refreshing. Block refreshing is performed during the first execution of garbage collection after mounting a YAFFS2 NAND flash memory device and every 500 times a block is selected for garbage collection. Basically, block refreshing is a variant of garbage collection that does not pay attention to the number of obsolete chunks within blocks. Instead, its goal is to move a block’s contents to another location on the NAND in order to distribute erase operations evenly. This technique enables the collection of blocks, even if they completely hold valid chunks. Whenever block refreshing is performed, it selects the device’s oldest block for garbage collection, regardless of the number of obsolete chunks within this block. Thus, if the oldest block does not contain any obsolete chunks, block refreshing does not lead to deletion of data, as all the oldest block’s chunks are copied to the current allocation block.

3.3

Shrink header markers

From a forensic point of view, shrink header markers can play an important role, as a block containing an object header chunk marked with a shrink header marker is disqualified for garbage collection until it becomes the device’s oldest dirty block. Its contents can remain stored on a device for a comparatively long time without being deleted by YAFFS2’s garbage collector. We practically evaluate the effects of shrink header markers on the recoverability of obsolete chunks in Section 5.1

4 Best case and worst case scenarios All data written to a YAFFS2 NAND remains stored on the device until the corresponding blocks are erased during execution of garbage collection. Therefore, recovery of modified or deleted files is always a race against YAFFS2’s garbage collector. In the following, the best case scenario described above is further analyzed for its practical relevance.

4.1

Experimental Setup

All practical evaluations of YAFFS2 discussed in the following were performed on a simulated NAND flash memory device. The simulated NAND featured 512 blocks and each block consisted of 64 pages with a size of 2048 bytes. Thus, the device had a storage capacity of 64 MiB. YAFFS2 reserves five of the device’s blocks for checkpoint data and uses a chunk size matching the device’s page size. Hence, a chunk had a size of 2048 bytes. For ev-


65

ery analysis, we created images of the simulated NAND by use of nanddump from the mtd-utils.

4.2

General Considerations

As a result of previous discussions, sooner or later all obsolete chunks present on the device are deleted and thus no previous versions of modified files or deleted files exist because of the unpreventable oldest dirty garbage collection and block refreshing techniques. Passive and oldest dirty garbage collection only collect five valid chunks per execution of passive garbage collection. Thus, not every execution of passive garbage collection necessarily leads to deletion of a block. In case a block consisting of 64 pages respectively chunks contains only one obsolete chunk, thirteen executions of passive garbage collection are necessary before the block gets erased. Once a block has been selected for garbage collection, YAFFS2 does not need to select another block to garbage collect until the current garbage collection block is completely collected. Hence, as soon as a block has been chosen for oldest dirty garbage collection, every subsequent attempt of background garbage collection leads to collection of this block. Given the cycle time of 2 seconds for background garbage collection, even in a best case scenario, a block that features only one obsolete chunk gets erased 24 seconds at most after it was selected for oldest dirty garbage collection.

4.3

Experiments

To validate our findings about the best case, we created one file of size 124 928 bytes (respectively 61 chunks) on an otherwise empty NAND. Due to writing of one obsolete file header chunk on creation of a file and writing of a directory header chunk for the root directory of the device, this lead to a completely filled block that featured exactly one obsolete chunk. As no write operations were performed after creation of the file, passive garbage collection triggered by a foreground thread was not performed. Additionally, aggressive garbage collection was ruled out due to only one block of the device being occupied. As the block only featured one obsolete chunk, regular background garbage collection was also unable to select the block for garbage collection. Thus, only after ten consecutive tries of background garbage collection, the block was selected for oldest dirty garbage collection. Subsequently, the block was garbage collected every two seconds due to background garbage collection. In our conducted test, the block containing the file is selected for garbage collection six seconds after the last chunk of the block has been written. This is because of background garbage collection attempts before creation of the file making oldest dirty garbage collection necessary.

66

4.4


Summary

Since garbage collection cannot be prevented completely, all obsolete chunks will eventually be erased. Therefore, the number of obsolete chunks that can be recovered from a YAFFS2 NAND also depends on the time span between the execution of a file deletion or modification and a forensic analysis. Due to block refreshing and oldest dirty garbage collection, chunks on a YAFFS2 NAND are in constant movement. As shown above, the speed of this movement depends to a part on the occupancy of the device’s storage capacity. However, the number and distribution of obsolete chunks on the device and the device’s size have a much greater influence on the speed of this movement. Passive garbage collection only checks 100 blocks at most when searching a block to garbage collect. Therefore, it can take longer for a specific block to be selected for garbage collection on a large NAND featuring a high number of blocks than it would on a smaller NAND.

5 Data Recovery In the following, we focus on the analysis of best case scenarios regarding recovery of deleted files. For other possible scenarios see Zimmermann [Zim11].

5.1

General Considerations

YAFFS2 uses deleted and unlinked header chunks to mark an object as deleted. Hence, an object is (at least partially) recoverable from a YAFFS2 NAND until garbage collection deletes all of the object’s chunks. Although recovery of a specific deleted file does not differ fundamentally from recovery of a specific modified file, one important difference exists. YAFFS2’s deleted header chunk is always marked with a shrink header marker. In Table 3, a selection of a block’s chunks are depicted. The chunks depicted contain data of files “fileX” and “fileY”. While “fileX” was modified by changing its last chunk’s content, “fileY” was deleted. As can be seen, modification of a file leads to writing of new chunks (chunk 4) replacing the chunks containing the now invalid data (chunk 1). However, deletion of a file leads to writing of deleted and unlinked header chunks with the deleted header chunk being marked with a shrink header marker. A best case scenario regarding recovery of a delete file is a scenario in which the deleted file is completely recoverable for the longest time possible. A block containing a chunk marked with a shrink header marker is disqualified for garbage collection until the block gets the oldest dirty block. Therefore, in the best case scenario, the file’s deleted header chunk has to be stored in the same block as all of the file’s chunks in order to protect the block (and respectively the complete file) with a shrink header marker. As a block containing a deleted header chunk can only be garbage collected if it is the device’s oldest block, it does not need to feature a minimum amount of valid chunks to be disqualified for


Block 1 1 1 1 1 1 1 1 1 1 1 1

Chunk 0 1 2 3 4 5 6 7 8 9 10 11

Object ID 257 257 257 1 257 257 258 258 258 258 258 1

Chunk ID 1 2 0 0 2 0 1 2 0 0 0 0

67

Comment fileX: first data chunk fileX: second data chunk fileX: header chunk root directory: header chunk fileX: second data chunk (new content) fileX: header chunk fileY: first data chunk fileY: second data chunk fileY: header chunk fileY: unlinked header chunk fileY: deleted header chunk root directory: header chunk

Table 3: The results of modification and deletion of a file

garbage collection.

5.2

Experimental Recovery of a Deleted File

We created ten files to fill exactly ten of the device’s blocks with valid chunks. After creation of a stable initial state by the garbage collector by deleting all obsolete chunks created during the files’ creation, we performed the following steps on the device: 1. Creation of “fileD” (77 824 bytes, respectively 38 data chunks) 2. Modification of all files on the device except for “fileD” 3. Deletion of “fileD” To modify the ten initial files we overwrote one data chunk of each file in a way that lead to one obsolete data chunk in each of the ten initially filled blocks. Hence, featuring only a very small number of obsolete chunks, these blocks complied to the criteria of an overall best case scenario. However, the block containing the chunks written due to creation of “fileD” did not comply to the criteria of a best case scenario as, after the file’s deletion, it contained a high number of obsolete chunks. By analyzing the kernel log entries written by YAFFS2, we could determine that, in our conducted test, the block that held the file was finally erased seven minutes and 53 seconds after the file was deleted (see also [Zim11]). The block was selected for garbage collection after background garbage collection was skipped ten consecutive times. However, the reason for that was not, that the block, at that time being the oldest dirty block, was disqualified for regular background garbage collection. All attempts of background garbage

68


collection were skipped because the block was not checked for necessity of garbage collection during these attempts. Thus, it was not selected for regular background garbage collection immediately after it became the only dirty block, although that would have been possible. This shows, that obsolete chunks can potentially be recovered for a longer time from a larger NAND than from a small NAND as passive garbage collection only checks a subset of all blocks when trying to select a block to garbage collect. Also, an obsolete chunk can be recovered for a longer time, if the NAND is filled to a higher degree and more blocks have to be garbage collected before the block containing the obsolete chunk in question. Recovery of chunks that are obsolete due to file modifications differs only slightly from recovery of chunks that are obsolete due to file deletions. Modification of a file does not lead to writing of shrink header markers, except the modification creates a hole bigger than four chunks within the file. Thus, obsolete chunks of a modified file are usually not protected from garbage collection by a shrink header marker. Nevertheless, in a best case scenario, these chunks are recoverable for almost as long as obsolete chunks of deleted files (see also Zimmermann [Zim11] and Zimmermann et al. [ZSS11])).

6 Conclusion Generally YAFFS2 allows for easy recovery of obsolete data. However, YAFFS2’s garbage collector ensures that, over time, all obsolete data is erased. The amount of data recoverable depends on many factors, especially the distribution of valid and obsolete chunks within a device’s blocks, the device’s size and occupancy and the amount of time that has passed between modification or deletion of a file and the device’s disconnection from its power source.

Acknowledgments This work has been supported by the Federal Ministry of Education and Research (grant 01BY1021 – MobWorm).

References [Car05] Brian Carrier. File System Forensic Analysis. Addison-Wesley, 2005. [Man02] Charles Manning. YAFFS: The NAND-specific flash file system — Introductory Article. http://www.yaffs.net/ yaffs-nand-specific-flash-file-system-introductory-article, 2002.


69

[Man10] Charles Manning. How YAFFS works. http://www.yaffs.net/sites/yaffs. net/files/HowYaffsWorks.pdf, 2010. [Zim11] Christian Zimmermann. Mobile Phone Forensics: Analysis of the Android Filesystem (YAFFS2). Master’s thesis, University of Mannheim, 2011. http://www1.informatik.uni-erlangen.de/filepool/thesis/ diplomarbeit-2011-zimmermann.pdf [ZSS11] Christian Zimmermann, Michael Spreitzenbarth, and Sven Schmitt. Reverse Engineering of the Android File System (YAFFS2). Technical Report CS-2011-06, FriedrichAlexander-University of Erlangen-Nuremberg, 2011.

TLS, PACE, and EAC: A Cryptographic View at Modern Key Exchange Protocols ¨ ur Dagdelen Marc Fischlin Christina Brzuska Ozg¨ Technische Universität Darmstadt www.cryptoplexity.de Abstract. To establish a secure channel between two parties common security solutions often use a key exchange protocol as a preliminary subroutine to generate a shared key. These solutions include the protocols for secure communication between a reader and an identity card or passport, called PACE and EAC, and the TLS protocol for secure web communication. In this work we survey the cryptographic status of these protocols and the recent developments in this area.

1 Introduction A secure channel between two parties is an important cryptographic primitive. It allows to communicate securely over a public channel by “wrapping” the communication into a cryptographically protected layer. The secure channel at foremost provides two security properties: confidentiality and authenticity. The former means that no outsider can learn the payload. In contrast, authenticity ensures integrity of the data, i.e., no adversary can inject or modify data, or even change the order of transmissions. Most secure channel protocols assume that the two parties already share a common secret. Thus, before exchanging the actual data via a secure channel, the two parties first need to establish such a shared secret. For this, they usually first run a so-called key exchange protocol (occasionally also called key agreement protocol) over the public channel to agree on a symmetric key. The security property of the key exchange protocol assures that no eavesdropper on the communication can learn the key. Subsequently, the two parties use the derived secret to implement the secure channel, usually through (symmetric) encryption for confidentiality, and message authentication for authenticity. This paradigm is widely deployed by a number of practical protocols, amongst which are the prominent TLS protocol and the PACE/EAC protocols on the new German identity card. In TLS, the key exchange is called handshake, and the channel protocol is named record layer. For the identity card, the Password-Authenticated Connection Establishment (PACE) protocol establishes a shared key between the card and the channel protocol is called secure messaging. The latter is also used as the channel protocol between the card and a terminal (e.g., a service provider), after the Extended Access Control (EAC) protocol has been executed to generate the key between these two parties.

72 TLS, PACE, and EAC: A Cryptographic View at Modern Key Exchange Protocols

In this work we survey the recent cryptographic developments for building secure channels, especially for TLS and the German identity card, where we focus on the key exchange step. To this end we first review the traditional security notions for key exchange and discuss their shortcomings compared to recent approaches. We then discuss the identity card protocols and TLS in more detail, and also give a brief overview over the state-of-the-art concerning their respective channel protocols.

2 Building Secure Channels We look at secure channel protocols that consist of the key exchange step in which the parties agree upon a shared secret key, and the channel implementation that protects the payload (as in TLS/SSL, PACE, and EAC). Instead of a monolithic cryptographic analysis, it is often convenient to use a modular approach and to investigate the security of each step individually. This, however, requires to recompose the individual protocols and security proofs to be able to argue about the security of the whole protocol. Towards such a modular analysis of composed two-stage channel protocols, there are two main approaches: gamebased security models and simulation-based security models.

2.1

Game-Based Security Models

In game-based security models one defines security of the task in question as a game played between a challenger and an adversary. The game specifies the moves the adversary is allowed (and the way the challenger answers them), i.e., it defines the attack model. Consider, for example, the well established model by Bellare and Rogaway [BR94] for authenticated key exchange protocols. There, the adversary may for instance observe several protocol executions between honest parties, may modify messages sent between the parties or inject new messages, or corrupt parties and learn their long-term secret keys. In addition, a game specifies when the adversary “wins”, i.e., when the adversary breaks security. For example, to break a secure channel, the adversary wins if it either breaks authenticity or confidentiality. For authenticity, the adversary’s goal is to modify the transmitted data between two honest parties without being detected. To break confidentiality, the adversary has to learn some non-trivial information about the transmitted data. According to such a game-based definition, a scheme is called secure, if all (efficient) adversaries have only negligible winning advantage. Game-based Security of Key Agreement. We now provide an (informal) description of the well-established and game-based Bellare-Rogaway security model [BR94] for authenticated key agreement. As mentioned above, we therefore need to define the attack model and the adversary’s winning condition. In the attack model, the adversary is mainly a very powerful Dolev-Yao adversary [DY81],

TLS, PACE, and EAC: A Cryptographic View at Modern Key Exchange Protocols 73

that is, the adversary fully controls the network and decides when and what messages are received by a running session of a user. This, in particular, enables the adversary to see the messages sent by honest parties, to modify them, change the order of delivery, and to inject new messages. Moreover, after two honest sessions agreed on a key, the adversary may “reveal” it, which models potential leakage of keys. The adversary can also corrupt users and mount insider attacks, i.e., run arbitrarily many (concurrent) sessions of the key exchange protocol with honest users. The number of all executed sessions as well as their scheduling is also chosen by the adversary. In other words, the adversary’s attack capabilities are very broad, such that any security proof against such adversaries provides strong guarantees. We now turn to the adversary’s winning condition. At some point in the game, the adversary may pick an (unrevealed) terminated session between two honest users. She then needs to prove that she knows at least one bit of information about their session key. This is modeled as an indistinguishability game: the adversary is given either the session key or a random string of the same length, and the game challenger asks the adversary to distinguish between the two cases, i.e., to correctly predict the case with probability significantly greater than the pure guessing probability 12 . Note that a random guess trivially achieves the success probability 21 ; we are thus interested in the adversary’s advantage beyond this. Game-Based Security for Secure Channels. Krawczyk [Kra01] and Bellare and Namprempre [BN00] consider different security levels of the underlying building blocks, messages authentication codes (MACs) and symmetric encryption and ask when their composition yields a secure channel. As there are various ways to compose these two building blocks, the theorems do not apply directly to specific real-world protocols such as TLS, where the channel implementation is a stateful algorithm that uses padding, sequence numbers and a range of different operator modes for the cipher; moreover, error messages are usually not covered by these models. These supposedly minor aspects, however, can impact security severely, as shown in Vaudenay [Vau02] and Paterson and Watson [PW08]. Therefore, depending on the protocol under consideration, the security models sometimes need to be tailor-made. We refer to Paterson et al. [PRS11] for a recent state-of-the-art analysis of the TLS record layer.

2.2

Simulation-Based Security Models

In contrast to game-based security models, simulation-based notions do not specify the adversary’s goal explicitly. Instead, they first define an ideal version of the primitive in question such that the ideal version reflects the desired functionality. For example, the ideal version of an authenticated channel would faithfully deliver messages, which are input from the honest sender, to the intended receiver; the adversary could see the message, but not modify it or inject new messages. Authenticity is thus guaranteed by definition. An implementation through a real protocol is then called secure if it is essentially “as good as” the ideal functionality, even in the presence of an adversary.


More formally, a protocol is secure according to such a simulation-based model if any attack against the real-world protocol can also been mounted against the ideal primitive. Consequently, as the ideal primitive trivially prevents any kind of attack, there cannot be an attack against the real-world protocol either, as it is indistinguishable from the ideal functionality. Put differently, the (only trivial) attacks on the ideal functionality give an upper bound for potential attacks on the real protocol. This is usually formalized by saying that, for any adversary A against the real protocol, there exists a so-called ideal-model adversary (aka. the simulator) S which can generate the same output as A when attacking the real protocol. Simulation-Based Models for Key Agreement. The ideal functionality for a key agreement protocol is a trusted third party that gives a random string to both honest parties. The local output of the parties only consists in this random string. If a protocol is indistinguishable from this ideal functionality, then the outputs of the protocol look like random strings. For a formal description, see Canetti and Krawczyk [CK01] or the full version of Canetti [Can01].1 Simulation-Based Models for Secure Channels. The ideal version of a secure channel protocol is a functionality (or trusted third party) to which the sender can securely pass a message, that the functionality securely delivers to the intended receiver, i.e., the adversary neither gets to see the message nor to modify it. For a detailed formulation, we refer the reader to the full version of Canetti [Can01].

2.3

Comparison

There are advantages and disadvantages to each of the two approaches. Simulation-based security usually provides stronger security guarantees than game-based security: if one can break security in the game, then one can (in many cases) also make the protocol deviate from its ideal specification. Thus, whenever there is a successful adversary in the gamebased setting, then there is a successful adversary against the simulation-based security. Taking the logical contra-position this means simulation-based security usually implies game-based security. In addition, simulation-based security turns out to be useful for secure composition. Protocols shown to be secure in Canetti’s (simulation-based) universal composition (UC) framework [Can01] compose well with other protocols in this framework. In particular, the compound execution of a UC-secure key agreement protocol with a UC-secure channel is also secure. Unfortunately, simulation-based security is sometimes not achievable by real-life protocols, or sometimes even by any protocol [CF01]. As far as secure channels and key agreement are concerned, they cannot be secure against fully adaptive corruptions in the 1 While

[CK01] give a game-based model, they prove it to be equivalent to a simulation-based one.


UC model where the adversary decides during executions if and when to corrupt parties [Nie02]2 . Moreover, security in the UC framework necessitates the use of global session identifiers, and real-life protocols such as TLS or PACE/EAC usually do not meet these syntactical stipulations. We note that a recent work by Kuesters and Tuengerthal [KT11] somewhat alleviates the latter point, but their model still does not overcome the other problems with adaptive corruptions and strong simulation requirements. In contrast, game-based security only asks for a specific security property (such as key indistinguishability) instead of general “ideal world” indistinguishability. As such, gamebased security appears to be sufficient for the task at hand and is also often easier to achieve. The downside of achievable game-based security is that games are either not known, or provably lack, composition properties. This implies that when analyzing key exchange protocols and channel protocols separately in games, then their composition is often not known to be secure. In conclusion, it is desirable to combine the advantages of both approaches: feasibility of game-based security and composability of simulation-based security. In the following section, we cover the recent progress on composability of game-based security in the area of key agreement.

2.4

Other Approaches

Simulation-based models and game-based models both consider arbitrary computationally bounded adversaries, usually modeled through Turing machines. In contrast, in the setting of symbolic methods, adversaries can derive symbolic expressions via a restricted set of so-called derivation rules. In a key exchange protocol, they can inject any message, which can be derived via these rules. A session key is called secure if the adversary is unable to derive it via the rules. As this is a weaker requirement than in the computational setting, one often enhances —if possible— a symbolic security analysis by a so-called soundness result to obtain the same security guarantees as in the computational setting. The weaker security guarantees come at the advantage of a simpler (or even automated) analysis such that, in particular, a granular analysis of protocols is feasible, as done for TLS by Fournet et al. [FKS11] and for Kerberos by Backes et al. [BCJ+ 11]. Note, however, that composition of symbolic analysis is as challenging as in the computational setting, as the derivation rules for the attack model of one protocol might affect the security of another protocol which was shown to be secure against a different set of derivation rules. For advances in this regard we refer the reader to the recent work by Cortier et al. [CW11] who prove first composition results for certain classes of derivation systems. 2 Canetti and Krawczyk [CK01] claim to achieve full security—towards this purpose, they assume that the parties securely erase their state, which makes state corruption trivial and is, essentially, equivalent to not allowing state corruption.


3 Compositional Game-Based Models The idea of looking into game-based security notions which also provide composition guarantees appears to be a promising venue to overcome the disadvantages of game-based models while keeping their benefits.

3.1

Composition of Bellare-Rogaway Protocols

For key agreement protocols, a recent result by Brzuska et al. [BFWW11] proves that BR-secure key agreement protocols are generally composable with arbitrary game-based protocols, if the key agreement protocol satisfies a notion called “session matching property”. This property says that a key exchange protocol allows a third party to always identify from the public communication which sessions of which users agreed on the same key. While BR-secure protocols were always somewhat believed to be composable, the result in [BFWW11] is the first to show this property formally and to identify a sufficient condition for this. Theorem 3.1 (from [BFWW11], informally) Let ke be a key agreement protocol and let π be an arbitrary symmetric-key protocol that is secure according to some game-based model, then the following holds: if the key agreement protocol is correct, BR-secure, and satisfies public session matching, then the composed protocol (ke, π) is secure. We note that the public session matching holds for all common protocols but one can easily devise examples for which this is not true. Moreover, Brzuska et al. [BFWW11] show that the public session matching algorithm is not merely an artefact of their theorem but instead a necessary condition for key exchange protocols to be composable. Theorem 3.2 (from [BFWW11], informally) If a key agreement protocol ke is composable with arbitrary symmetric-key protocols, then ke satisfies the public session matching requirement. One can now conclude that any BR-secure protocol, composed with a secure channel protocol, automatically provides a secure channel. This holds if each of the components has been proven secure in its respective game-based model, and if the mild assumption about public session matching holds.

3.2

Compositional Results for TLS/SSL, PACE, and EAC

To protocols such as TLS and PACE/EAC, the composition result for BR-protocols, however, does not immediately apply. The reason is that in the key exchange stage, all these protocols use a so-called key confirmation step. In this step both participants authenticate the protocol transcript already with the established session key, with the intuition that


it provides an a-posteriori authentication of the otherwise unauthenticated transmissions. But this means that within the key agreement protocol, in the final protocol messages, the session key is already used. This, however, violates the security in the BR sense as the established key cannot be considered fresh anymore (and is easily distinguishable from random). Consequently, we cannot apply the general composition result for BR-secure protocols, even though the protocols allow for public session matching. In the sequel, we present several approaches to deal with the problem. Firstly, as done in the PACE/EAC proof [BFK09, DF10a], one can add an additional key refresh step to the protocol and argue that if the protocol satisfies an additional property (namely a different message structure in the key confirmation message than in the actual payload transmission), then the original protocol is secure whenever the modified protocol is secure. This approach is valid whenever the key agreement protocol is used with secure channels, and the authenticated message in the key confirmation step is distinct from the messages sent over the secure channel. For TLS, Jager et al. [JKSS11] deal with this problem by mounting a monolithic analysis, i.e., they forgo splitting the TLS protocol into separate phases, and instead analyze the whole protocol. In another approach, Küsters and Tuengerthal [KT11] cope with the key confirmation message via considering ideal functionalities that implement several primitives simultaneously. Their model is again simulation-based and thus provides high modularity but also suffers from the aforementioned disadvantages (see Section 2.3). A recent solution, which even goes beyond the application of secure channels, is a general game-based composition framework by Brzuska et al. [BFS+ 11]. They consider composition of key agreement with arbitrary game-based protocols, without requiring the key agreement to satisfy BR-security. Instead, they use a form of key usability, a notion first considered by Datta et al. [DDMW06] and formalized in the simulation-based setting in [KT11]. The idea is roughly to invest a bit more work for analyzing the key agreement and to show that it is good for some primitives like symmetric encryption and message authentication. By this, one can automatically conclude security of the composition of the key agreement protocols with any protocol that relies on these primitives, like secure channels built out of symmetric encryption and message authentication. Using their framework, they give a modular analysis of TLS and provide foundations for such proofs in a general when not only composition with secure channels, but also with other protocols is desirable.

4 TLS: Overview over the Cryptographic Status The TLS protocol consists of a key agreement step, the handshake protocol and a secure channel, called the record layer. Both protocols have been scrutinized with different goals and varying strengths of the results. As explained in the previous section, the TLS Handshake protocol in its due form (unlike the modified versions considered by Morrissey et al. [MSW10] and by Gajek et al. [GMP+ 08]) cannot be analyzed in security models that require key indistinguishability. For TLS, only this year several solutions to this problem have been considered and, noteworthy, appeared concurrently.


For one, Jager et al. [JKSS11] presented a monolithic analysis of the TLS protocol for one choice of the TLS Handshake (among the choices negotiated by the parties during the handshake). While monolithic approaches usually suffer from a lack of modularity (entailing poor robustness of the analysis in light of future protocol modifications), their analysis, interestingly, does not. Their key ingredient towards modularity is somewhat a special case of the composition result by Brzuska et al. [BFWW11]. In particular, they show that a truncated version of the TLS Handshake protocol is BR-secure and identify a sufficient condition for the TLS Record Layer to be securely composable with the (truncated) TLS Handshake. Hence, their analysis can be composed with any formal security proof for the TLS Record Layer, provided the achieved security level matches the one considered by Jager et al. [JKSS11]. In light of [BFWW11], we can even deduce that their result composes in general. Note that this approach is TLS-specific; usually, truncated versions of protocols, now without key confirmation, become insecure. Simultaneously, two new frameworks were introduced, as explained in the previous section, one by Küsters and Tuengerthal [KT11] and one by Brzuska et al. [BFS+ 11]. Both allow to analyze the TLS Handshake protocol3 . As the model by Küsters and Tuengerthal is simulation-based, it suffers from the aforementioned restrictions on the adversary’s corruption capacities, while, noteworthy, nicely circumventing nuisances of prior simulationbased approaches. The game-based composition framework by Brzuska et al. [BFS+ 11] fully applies to TLS. They carry out a security proof that, combined with a security proof for the TLS Record Layer, yields a security analysis of (an abstracted version of) the entire TLS protocol. Theorem 4.1 (from [BFS+ 11], informally) The TLS Handshake protocol can be securely composed with a secure channel that uses (specific stateful implementations of) MACs and encryption. The TLS Record Layer is similarly issue of intense research. In [Kra01], Krawczyk analyzes two abstract versions of the TLS record layer. One of them is a general scheme called MAC-then-ENC whereas the other is more specific. While he proves that MAC-then-ENC does not always yield a secure channel, Krawczyk proves it to be a secure channel when the encryption is instantiated via a secure cipher in CBC mode. The latter result was interpreted as a security proof for the TLS Record Layer and the protocol description complied, indeed, with the accepted standard for cryptographic abstraction of protocols. However, Vaudenay [Vau02] later discovered that some of the dispatched details leave leverages for attacks. In particular, the process of message padding enables additional security breaches. In subsequent works, e.g., Paterson and Watson [PW08] as well as Maurer and Tackmann [MT10], the analysis progressively reflected the actual real-world implementation, culminating in the recent work by Paterson et al. [PRS11] who analyze the actual RFC [DA99, DA06]. On the way several attacks were discovered, and the RFC was modified to prevent those attacks. We can therefore consider the cryptographic analysis of the TLS protocol as having achieved an acceptable level of rigorousness, showing that the protocol is secure. 3 K¨ usters and Tuengerthal [KT11] actually do not carry out this analysis formally, but convincingly show its feasability in their model.


5 EAC & PACE: Overview over the Cryptographic Status The Password Authenticated Connection Establishment (PACE), and the Extended Access Control (EAC) protocol, are deployed in the current electronic ID card in Germany. They each enable the card and the (local) reader resp. the card and the (remote) terminal to share a secret session key which is used subsequently in the secure messaging protocol.

5.1

Extended Access Control (EAC)

EAC is deployed in two different variants. Here, we focus on the latest version which is implemented in the German ID card. In EAC, a chip and terminal agree upon a secret session key if both parties mutually authenticate first. This is accomplished by two sub-protocols, called Terminal Authentication (TA) and Chip Authentication (CA). First, in the TA phase, the terminal signs in a challenge-response step the card’s challenge under a certified key. Subsequently, in the CA step, the chip authenticates itself also via a challenge-response step, but using already the derived session key in a message authentication code instead of a signature, as this ensures deniability for the card. The session key itself, which is also used for this chip authentication, is derived from a DH key computed between the static (certified) key of the card and an ephemeral key of the terminal. The security analysis of EAC, as a key exchange protocol, in [DF10a] is done in the Bellare-Rogaway model, with the hindsight that the key is already used in the key exchange step for a dedicated message which does not appear in the channel protocol. The formal analysis thus assumes a key refresh step for which the composition result for BRkey exchange protocols in [BFWW11] applies, noting that one can publicly match session. Alternatively, for the version using the session key already, the result [DF10b] about compositional properties of key exchange protocols with controlled usage of the key applies. The security analysis of the channel protocol, called secure messaging, is done in [DF10b]. The secure messaging follows an encrypt-then-authenticate method with a counter value for each message, with all data like the counter value, the auxiliary information, and the message carefully aligned to block length. As such it provides a secure channel for randomly chosen keys (instead of keys generates through the key exchange protocol). The entire secure channel, consisting of the EAC key exchange composed with the secure messaging, is analyzed in [DF10b] in a monolithic way, saying that security follows from the security of the key exchange protocols and the security of the primitives: Theorem 5.1 (from [DF10b], informally) The security of the composed protocol, consisting of the EAC key exchange protocol with secure messaging, follows from the security of the EAC key exchange protocol, the security of the encryption scheme, and the unforgeability of the message authentication code.


5.2

Password-Authenticated Connection Establishment (PACE)

The PACE protocol is deployed between the chip and a reader. In contrast to EAC it does not rely on certified public keys, but is password based. That is, the chip and the reader share a low-entropy secret at the outset of the execution. In practice, the card holder types in this password at the reader, or in case of machine readable travel documents the password is built out of the data in the machine readable zone and obtained by the reader through a physical read-out (say, via swiping the passport at the reader). PACE, as a key exchange protocol, has been analyzed in a version of the BR model, suitable for the case of password-based protocols. The model is due to Bellare-PointchevalRogaway (BPR model) [BPR00] and takes into account that an adversary could potentially guess the low-entropy password in an execution with an honest party. But the model says that the adversary should not be able to do more than that. In particular, the adversary should only be able to test one password in any active execution (online testing) but must not be able to identify a password after eavesdropping a communication (offline testing). Formally, the model is as the BR model, except that we measure the adversary’s success probability against the trivial prediction strategy of guessing the right password with probability 1/N (if passwords are chosen uniformly from a set of size N , say, N = 106 for 6-digit PINs). This bound is for a single execution and grows to q/N when the adversary can probe q executions. To be precise, the adversary in q executions should then not be able to be significantly better in distinguishing the genuine key from a random string, than with probability q/N . Such a password-based protocol is considered to be optimal. While the PACE protocol as a key exchange protocol has been shown in [BFK09] to be optimal, the channel protocol following the PACE step has, to best of our knowledge, not been analyzed formally (when composed with PACE). Luckily, since the channel is also implemented by secure messaging, and by the similarity of the BPR model to the BR model, the monolithic analysis in [DF10b] for EAC and Secure Messaging immediately carries over. Only the security bound for the overall protocol now also contains the weaker bound q/N (plus a negligible term). This, of course, is inevitable for password-based protocols: Theorem 5.2 (adopted from [DF10b], informally) The security of the composed protocol, consisting of the PACE password-based key exchange protocol with secure messaging, follows from the security of the PACE key exchange protocol, the security of the encryption scheme, and the unforgeability of the message authentication code.

6 Conclusion As discussed, research on key exchange protocols is crucial for a wide range of practical protocols such as TLS, EAC, and PACE. The latter, however, are often non-trivial to analyze. Fortunately, several new approaches have been developed such that TLS, EAC, and PACE are now shown to be cryptographically sound protocols.


References [BCJ+ 11]

Michael Backes, Iliano Cervesato, Aaron D. Jaggard, Andre Scedrov, and Joe-Kai Tsay. Cryptographically sound security proofs for basic and public-key Kerberos. Int. J. Inf. Secur., 10:107–134, 2011.

[BFK09]

Jens Bender, Marc Fischlin, and Dennis Kügler. Security Analysis of the PACE KeyAgreement Protocol. In ISC 2009, volume 5735 of LNCS, pages 33–48. Springer, 2009.

[BFS+ 11]

Christina Brzuska, Marc Fischlin, Nigel P. Smart, Bogdan Warinschi, and Stephen C. Williams. Less is More: Relaxed yet Composable Security Notions for Key Exchange. In submission, 2011.

[BFWW11] Christina Brzuska, Marc Fischlin, Bogdan Warinschi, and Stephen C. Williams. Composability of bellare-rogaway key exchange protocols. In CCS 2011, pages 51–62. ACM, 2011. [BN00]

Mihir Bellare and Chanathip Namprempre. Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm. In ASIACRYPT 2000, volume 1976 of LNCS, pages 531–545. Springer, 2000.

[BPR00]

Mihir Bellare, David Pointcheval, and Phillip Rogaway. Authenticated Key Exchange Secure against Dictionary Attacks. In EUROCRYPT 2000, volume 1807 of LNCS, pages 139–155. Springer, 2000.

[BR94]

Mihir Bellare and Phillip Rogaway. Entity Authentication and Key Distribution. In CRYPTO’93, volume 773 of LNCS, pages 232–249. Springer, 1994.

[Can01]

Ran Canetti. Universally Composable Security: A New Paradigm for Cryptographic Protocols. In 42nd FOCS, pages 136–145. IEEE Computer Society, 2001.

[CF01]

Ran Canetti and Marc Fischlin. Universally Composable Commitments. CRYPTO 2001, volume 2139 of LNCS, pages 19–40. Springer, 2001.

[CK01]

Ran Canetti and Hugo Krawczyk. Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels. EUROCRYPT 2001, volume 2045 of LNCS, pages 453–474. Springer, 2001.

[CW11]

Véronique Cortier and Bogdan Warinschi. A composable computational soundness notion. In CCS 2011, pages 63–74. ACM, 2011.

[DA99]

T. Dierks and C. Allen. The TLS Protocol Version 1.0. In RFC 2246, 1999.

[DA06]

T. Dierks and C. Allen. The TLS Protocol Version 1.2. In RFC 4346, 2006.

In

[DDMW06] Anupam Datta, Ante Derek, John Mitchell, and Bogdan Warinschi. Computationally Sound Compositional Logic for Key Exchange Protocols. In CSFW 2006, pages 321– 334. IEEE Computer Society, 2006. [DF10a]

¨ ur Dagdelen and Marc Fischlin. Security Analysis of the Extended Access Control Ozg¨ Protocol for Machine Readable Travel Documents. In ISC 2010, volume 6531 of LNCS, pages 54–68. Springer, 2010.

[DF10b]

¨ ur Dagdelen and Marc Fischlin. Sicherheitsanalyse des EAC-Protokolls. TechOzg¨ nical report, Project 826, 2010. http://www.personalausweisportal. de/SharedDocs/Downloads/DE/Studie_Kryptographie_Volltext. pdf?__blob=publicationFile.


[DY81]

D. Dolev and A. C. Yao. On the security of public key protocols. In SFCS ’81, pages 350–357. IEEE Computer Society, 1981.

[FKS11]

Cédric Fournet, Markulf Kohlweiss, and Pierre-Yves Strub. Modular code-based cryptographic verification. In CCS 2011, pages 341–350. ACM, 2011.

[GMP+ 08] Sebastian Gajek, Mark Manulis, Olivier Pereira, Ahmad-Reza Sadeghi, and Jörg Schwenk. Universally Composable Security Analysis of TLS. In ProvSec 2008, volume 5324 of LNCS, pages 313–327. Springer, 2008. [JKSS11]

Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk. A Standard-Model Security Analysis of TLS-DHE. IACR Cryptology ePrint Archive, 2011:219, 2011.

[Kra01]

Hugo Krawczyk. The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?). In CRYPTO 2001, volume 2139 of LNCS, pages 310–331. Springer, 2001.

[KT11]

Ralf Küsters and Max Tuengerthal. Composition theorems without pre-established session identifiers. In CCS 2011, pages 41–50. ACM, 2011.

[MSW10]

Paul Morrissey, Nigel P. Smart, and Bogdan Warinschi. The TLS Handshake Protocol: A Modular Analysis. Journal of Cryptology, 23(2):187–223, 2010.

[MT10]

Ueli Maurer and Björn Tackmann. On the soundness of authenticate-then-encrypt: formalizing the malleability of symmetric encryption. In CCS 2010, pages 505–515. ACM, 2010.

[Nie02]

Jesper Buus Nielsen. Separating Random Oracle Proofs from Complexity Theoretic Proofs: The Non-committing Encryption Case. In CRYPTO 2002, volume 2442 of LNCS, pages 111–126. Springer, 2002.

[PRS11]

Kenneth G. Paterson, Thomas Ristenpart, and Thomas Shrimpton. Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol. In ASIACRYPT 2011, to appear.

[PW08]

Kenneth G. Paterson and Gaven J. Watson. Immunising CBC Mode Against Padding Oracle Attacks: A Formal Security Treatment. In SCN 08, volume 5229 of LNCS, pages 340–357. Springer, 2008.

[Vau02]

Serge Vaudenay. Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS ... In EUROCRYPT 2002, volume 2332 of LNCS, pages 534–546. Springer, 2002.

Merging the Cryptographic Security Analysis and the Algebraic-Logic Security Proof of PACE Lassaad Cheikhrouhou1 , Werner Stephan1 , ¨ ur Dagdelen2 , Marc Fischlin2 , Markus Ullmann3 Ozg¨ 1

German Research Center for Artificial Intelligence (DFKI GmbH) {lassaad,stephan}@dfki.de 2 Technische Universität Darmstadt marc.fi[email protected] [email protected] 3 Federal Office for Information Security (BSI) [email protected]

Abstract: In this paper we report on recent results about the merge of the cryptographic security proof for the Password Authenticated Connection Establishment (PACE), used within the German identity cards, with the algebraic-logic symbolic proof for the same protocol. Both proofs have initially been carried out individually, but have now been combined to get “the best of both worlds”: an automated, errorresistant analysis with strong cryptographic security guarantees.

1 Introduction The cryptographic protocol PACE (Password Authenticated Connection Establishment) is designed by the BSI for the establishment of authenticated radio frequency connections between contactless cards and readers [UKN+ ]. PACE is deployed in the German (electronic) identity card and should be used instead of the BAC (Basic Access Control) protocol in the inspection procedure of machine readable travel documents (ePassports) [EAC]. The protocol realizes a password-authenticated Diffie-Hellman (DH) key agreement between an RF-chip and a terminal. A successful run yields a fresh session key that is used by the reader to establish a secure connection to the RF-chip. Two Views on the Security: The security of PACE has been analyzed by following two state-of-the-art approaches. A (symbolic) algebraic-logic security proof of PACE [CS10], in the Dolev-Yao (DY) model has been carried out in the Verification Support Environment (VSE) tool, yielding a machine generated proof of all its security properties. The DY model is based on a message algebra given by cryptographic operations and equations. The operations define the syntax of protocol messages while the equations in an abstract way formalize the computations that are necessary for the honest participants to execute the protocol. A subset of these operations is available for the adversary to analyze observed messages and to synthesize new ones. This attacker model is very powerful with respect to an unrestricted access (of the adversary) to the communication lines. On the other hand,

84 Merging the Cryptographic Sec. Analysis and the Algebraic-Logic Security Proof

it limits the abilities of the adversary in attacking cryptography by assuming that exactly the algebraic (or symbolic) computations can be carried out by the adversary. Concurrently, a cryptographic security analysis of PACE [BFK09] has been carried out based on the Bellare Rogaway (BR) security model, yielding a pencil-and-paper proof of the confidentiality and authenticity of the session key. The cryptographic proof follows the common complexity-theoretic approach to show that any security breach of the key exchange protocol within the security model can be used to refute any of the underlying assumptions and primitives. Vice versa, if the underlying primitives of the protocol are secure, then the proof shows – in terms of the complexity of the algorithms and concrete probabilities – how secure the PACE protocol is. Here, the adversary can be arbitrary (Turing) machines whose abilities to communicate with the system are determined by the model. Security proofs in the BR model consider strong adversaries who control the network, i.e., eavesdrop, modify and inject messages, and may learn leaked session keys or long-term keys of users. Merging the Views: In this paper we describe an approach to merge the cryptographic security analysis in [BFK09] and the algebraic-logic security proof in [CS10], aiming at a reliability improvement in the security of PACE. Our merging approach is based on an adequate formalization of the BR model used within PACE that allows us to attribute public bit strings (values) to symbolic expressions for corresponding applications of the cryptographic functions. Sequences of alternating intruder queries and protocol oracle responses (BR traces) are attributed this way a symbolic structure that allows us to define DY computations in the BR model. The main result is the theorem that symbolic traces of DY computations in the BR model are equivalent to symbolic traces in the algebraic-logic security proof. Equivalence is defined wrt. the capabilities and the knowledge of the adversary. This means that the algebraic-logic security proof of PACE in VSE provides us with a machine generated proof for the confidentiality of the session key in the BR-model, though for Turing machines restricted to DY computations. Apart from that, our formalization of the BR model for PACE provides us with the formal means to define computational problems arbitrary adversary machines are confronted with (relative to the protocol model). The ultimate goal is an axiom-based formal proof of PACE’s security in the BR model relative to an exhaustive listing of formally defined computational problems. In the paper we describe only the formalization of PACE’s BR model (Sec. 4) and the equivalence of DY computations both in the BR and the DY model (Sec. 5). Prior to that we introduce PACE (Sec. 2) and we review its cryptographic security analysis and its algebraic-logic security proof (Sec. 3). Related Work about Proof Integrations: Abadi and Rogaway [AR02, AR07] were the first to aim at bridging the gap between the two views on cryptography, the formal or symbolic view, and the complexity-based or computational view, through linking the two worlds explicitly. Their soundness theorem for encryption schemes is accomplished by mapping symbolic expressions to (probabilistic) cryptographic ensembles. Since then further works aimed at closing the gap between the two worlds in the same spirit (e.g., [BPW03, IK03, MW04a, MW04b, CLC08]).

Merging the Cryptographic Sec. Analysis and the Algebraic-Logic Security Proof 85

A supportive approach towards linking the cryptographic and the symbolic world is given by the reactive simulatability (RSIM) framework of Pfitzmann and Waidner [PW00, PW01] and Canetti’s concurrently proposed and similar-in-spirit universal composition (UC) framework [Can01]. The idea of the frameworks is to analyze cryptographic protocols in presence of ideal functionalities, similar to idealized primitives in the DY setting. So-called composition theorems then allow to conclude security of the combined protocol when the ideal functionalities are replaced by secure sub protocols. Hence, this allows to decompose the analysis of complex, potentially multi-session protocols into analysis of more handy single-session sub protocols. A series of soundness results [BPW04, CH06, Pat05, MH07, BU08] for these frameworks shows that any symbolically secure protocol (in a symbolic version of the RSIM/UC framework) is also secure in the computational framework; often such formal analysis have also been carried out explicitly. However, in order to be secure in the RSIM/UC frameworks, protocols need to satisfy very strong security guarantees in the first place. This rules out numerous protocols, especially quite a number of practical protocols. This means that the method is not applicable to a large class of protocols, and it is, in particular, unknown whether it applies to PACE.1 While computer-aided verification of cryptographic protocols is a well-established discipline, computer-aided verification of cryptographic proofs (in the computational model) is a quite new approach to combine the benefits of automated, error-free verification and the flexibility of cryptographic proofs to consider arbitrary adversaries strategies and to reason about the security of a protocol in terms of reduction to primitives (instead of idealizing the primitives). There are several approaches to build systems along this line, among which the recently proposed framework EasyCrypt [BGHB11] stands out. Our approach follows the same idea of verifying game-based proofs for the PACE protocol with the help of automated tools. Here, we used the available cryptographic proof for PACE [BFK09] and the previous efforts for the formal analysis for PACE in VSE [CS10] to merge the cryptographic reasoning with the symbolic analysis.

2 The PACE Protocol PACE is a password-based key agreement protocol with mutual entity authentication. It takes place between the RF-chip (A) of a contactless smart card and an (inspection) terminal (B). After a successful run of PACE, an RF-chip and a terminal share a fresh session key, and the terminal can establish a secure connection to the RF-chip of the smart card using the established session key. We have to point out that a successful PACE protocol run between an RF-chip A and a terminal B is only possible if the terminal has learned the appropriate password pwd(A) of the RF-chip A at the outset, e.g., if the user typed it in at the terminal, or if it is read off the machine-readable zone in passports. This password pwd(A) is stored on the RF-chip in secure memory and the way it is utilized in PACE guarantees that the chip originates 1 Note that the cryptographic analysis of PACE has indeed been carried out in the game-based BPR security model, not in the UC framework.


from the smart card at hand.

2.1

Cryptographic Functions

PACE messages are computed out of passwords, random values (nonces), and basic generators for the underlying elliptic curve group, using the following (abstract) functions: • enc(·, ·), dec(·, ·) for (symmetric) encryption and decryption, respectively, • dh(·, ·) for the computation of Diffie-Hellman values, and • mac(·, ·), gen(·, ·) for the computation of mac values and (fresh) generators, respectively. The algebraic properties that are necessary to run the protocol are expressed by three equations: • For encryption and decryption we have dec(m0 , enc(m0 , m1 )) = m1 and enc(m0 , dec(m0 , m1 )) = m1 . The second equation guarantees the absolute indistinguishability of failed and successful decrypting attempts. This property is necessary to obtain the resistance against offline password testing (see section 3.2). • For the computation of a common DH key we have dh(dh(m0 , m1 ), m2 ) = dh(dh(m0 , m2 ), m1 ).

2.2

PACE Steps

To run the protocol with an RF-chip A, the terminal B does not only have to learn the password pwd(A). It also has to access (in a protocol pre-phase) the domain parameters that include a static generator g for DH exchange in steps 2+3. In the description of the protocol steps below we additionally make use of the metaoperator % to separate the sender’s view (the left-hand side of %) from the receiver’s view (the right-hand side of %). Unstructured messages in steps 1-5 below means that the receiver accepts any message without practically any check. Compare this with steps 6 and 7 below. Here, the respective receiver sees a message that can be compared with an expression determined from the own knowledge (the right-hand side of %). 1. A −→ B : enc(pwd (A), sA ) % z 2. B −→ A : dh(g, x1 ) % X1 3. A −→ B : dh(g, y1 ) % Y 1


4. B −→ A : dh(gen(dh(g, dec(pwd (A), z)), dh(Y 1, x1 )), x2 ) % X2 5. A −→ B : dh(gen(dh(g, sA ), dh(X1, y1 )), y2 ) % Y 2 6. B −→ A : mac(dh(Y 2, x2 ), Y 2) % mac(dh(X2, y2 ), dh(gen(dh(g, sA ), dh(X1, y1 )), y2 )) 7. A −→ B : mac(dh(X2, y2 ), X2) % mac(dh(Y 2, x2 ), dh(gen(dh(g, dec(pwd (A), z)), dh(Y 1, x1 )), x2 )) A starts the protocol by sending a nonce sA encrypted with the own password pwd(A) to B. The decryption of this message z by B with the password that B can determine while B is connected with A results in sA , provided this password equals pwd(A). The first DH exchange in steps 2+3 establishes a first DH value that is used with sA and the static generator g in the computation of a fresh generator for the subsequent DH exchange in steps 4+5. The composition of these parameters by gen guarantees that the resulting generator is cryptographically as strong as g and binds this generator with the intermediate of sA to the password pwd (A). Thus, the DH value established in steps 4+5 can be determined only by participants that know the password. Its use in steps 6+7 to compute the mac authenticates the sender for the receiver. Each mac can be created only by a communication partner who has participated in the DH exchange of steps 4+5 after using the password.

3 The Cryptographic and Symbolic Security Analyses 3.1

The Cryptographic Proof

The PACE protocol is accompanied by a cryptographic security proof [BFK09]. The cryptographic proof follows the classical paper-and-pencil approach of defining a security model, describing the adversary’s capabilities and goals, specifying a set of underlying cryptographic assumptions, and a mathematical proof that the adversary cannot succeed within the model under the assumptions. As for the model, the authors in [BFK09] used the widely-deployed BR model [BR94] for authenticated key exchange (or, to be precise, the variations of Bellare-PointchevalRogaway [BPR00] and of Abdalla et al. [AFP06] for the password-based case).The BR model defines a game between the adversary and a challenger oracle in which the powerful adversary can: (a) observe interactions between honest participants (i.e., RF-chips and terminals), (b) inject or modify transmissions in such communications, or even take over the side of one of the parties, (c) corrupt players, and (d) learn the derived DH key in executions. We note that the model considers multi-session executions, which may run concurrently. The adversary’s goal is now to distinguish derived fresh DH keys from independent random strings in so-called test sessions, the idea being that good keys must still look random to the adversary. The model now demands that the adversary cannot distinguish the two cases, defined within the usual cryptographic notion of having negligible advantage over distinguishing the two cases by pure guessing with probability 21 .


The cryptographic proof now defines a set of assumptions, such as the hardness of the so-called PACE-DH number-theoretic problem (which is related to the DH problem), the security of the underlying message authentication code, and idealizing the deployed cipher and the hash function as a random oracle. Under these assumptions, it is shown (mathematically) that the PACE protocol is secure. The caveat here is that the proof takes into account the fact that the protocol is password-based, i.e., relies on low-entropy secrets, which can, in principle, be guessed by the adversary. The security claim shows that the – trivial and inevitable – on-line guessing of passwords, where the adversary tries to predict the password and then tests its guess in an execution with an honest party, is (essentially) the best adversarial strategy. In other words, PACE achieves optimal security. The proof itself is carried out with the common technique of game hopping. That is, one starts with the actual attack and gradually eliminates success strategies of the adversary in each game hop, e.g., the ability to forge MACs. In the final game, the adversary provably cannot distinguish the DH keys from random keys anymore. One then accounts for the loss in the adversary’s success probabilities and sums up all the losses for the hops. This sum gives an upper bound on the adversary’s advantage. The next theorem states the cryptographic security of the PACE protocol (for more general cases where the first Diffie-Hellman key exchange is substituted by a canonical protocol Map2Point). It obviously relates the adversary’s characteristics like running time and success probability to the ones for the underlying primitives and assumptions. The theorem roughly shows that the best strategy for the adversary (unless it can break one of the primitives) is to guess the password (with probability 1/N among all passwords) and to mount a test run for this guess. Since there can be in total qe executions the overall success probability is roughly qe /N . Theorem 3.1 ([BFK09]) Let Map2Point be canonical and assume that the password is chosen from a dictionary of size N . In the random oracle model and the ideal cipher model we have Advake P ACE (t, Q)

≤

qe gP ACE−DH ∗ + qe · AdvMap2Point (t , N, qh ) N 2qe N 2 + 8qe2 N + qc qe orge ∗ +qe · Advfmac (t , 2qe ) + min{q, |Range(H)}

The resources of an adversary are captured by the time t∗ = t + O(Q2 ) and number of oracle queries Q = (qe , qc , qh ) where qe denotes the number of key exchanges, qc the queries to the cipher oracle and qh the queries to the random oracle. The theorem says that the advantage Advake P ACE (t, Q) of any adversary having resources (t∗, Q) breaking the security of PACE is bounded by the pure guessing strategy qe /N , the advantage of f orge ∗ forging a MAC Advmac (t , 2qe ), and the DH related hard problem gPACE-DH, denoted gP ACE−DH ∗ by AdvMap2Point (t , N, qh ) plus some negligible term. In short, an adversary is merely as successful as blind guessing whenever a secure MAC scheme is used in PACE. The security reduction of PACE does not consider explicitly the hardness of the (ideal) block cipher. Instead, the security of the underlying block cipher is implicitly captured in the hardness of gPACE-DH problem and modeled as an ideal cipher.


3.2

The Algebraic-Logic Proof

The symbolic analysis of PACE has been carried out in the VSE tool, [CS10]. The resulting algebraic-logic proof handles explicitly the standard security properties (mutual authentication and confidentiality of session keys) and the following three properties, which are typical for password protocols: • forward secrecy of session keys, i.e. that a successfully guessed password does not help to reveal the session keys that had been generated in previous runs, • resistance against offline password testing, i.e. that the obtained protocol messages by an active intruder cannot be exploited offline to determine a correct password from a given list of candidate passwords, and • forward secrecy of passwords, i.e. a stronger form of the resistance property where the intruder may use disclosed session keys in addition to protocol messages. We note that these properties are implied by the BR model. They have been verified in the VSE tool where the protocol model consists of a set TP ACE of (finite) sequences (traces) tr = be0 , . . . , en−1 of (protocol-) events. The main events are of the form says(a, b, m) where a protocol participant a sends a (symbolic) message m to some other participant b. The set TP ACE is defined inductively by using predicates (rules) R(tr, e) that describe the conditions for a given trace tr to be extended by a new event e. There is a predicate Ri for each line i of the protocol and an additional predicate Rf for the fake case. We have Rf (tr, says(spy, b, m)) for an arbitrary participant b iff the intruder (named spy) is able to derive m out of the observable messages in tr. We denote the set of (immediately) observable messages by spies(tr) and the set of derivable messages (from spies(tr)) by DY (spies(tr)). The latter is an extension of spies(tr) given by the reasoning capabilities of a DY intruder, i.e. by the application of the functions and the equations in Sec. 2.1. In this algebraic-logic model, PACE properties are formalized on arbitrary traces from TP ACE and the corresponding machine-proofs are by induction on these event traces.

4 A Symbolic Formalization of the BR-Model The global structure of the BR model, as depicted in Fig. 1, consists of two components: a PPT adversary machine and the oracle O that reacts on queries from the adversary by simulating steps of a given protocol. The most important query is of the form send(adr, m) where m is a protocol message that has to be answered by a certain participant in a certain session, both given by adr, according to the protocol rules and the execution state which is part of the overall oracle state. The response value may depend on the application of cryptographic primitives where idealized functions are realized by probabilistic choices of the oracle. The adversary uses these responses to generate subsequent queries


by possibly guessing (sub-) messages and/or performing computations that are not necessarily included in the message algebra used in the DY model (see Sec. 2.1). To break the protocol, after termination of a particular session the adversary has to distinguish the session key stored in the oracle state from a random value with a considerably high probability. The test item is presented by the oracle as a reaction to a special query. In [CSDF10] we formalize the BR model by specifying O as a state transition system and by defining computation trees Comp(O G A), see Fig. 2, generated by the joint execution of the oracle and an arbitrary but fixed adversary A.

Figure 1: The BR Model

Let SO be the set of oracle states, TA be the set of states of the adversary, QA the set of queries that can be generated by the adversary, and RO the set of possible responses of the oracle. As mentioned above queries may contain protocol messages to be processed by the oracle. Nodes of computation trees are quadruples (s, t, r, p) and (s, t, q, p), where s ∈ SO , t ∈ TA , r ∈ RO , and q ∈ QA . The probability p ∈ [0, 1] captures probabilistic choices of O and A, respectively.

!!!

!!!

!!!

!!!

!!!

!!!

!!!

Starting from the initial states s0 ∈ SO and t0 ∈ TA the computation tree grows by alternating transition steps of the adversary A (•→•) and the oracle O (•→•). Steps of the adversary depend on the current state t ∈ TA and the current response r ∈ RO . The state of the adversary which is not explicitly given can be thought of (among others) as representing past responses of the oracle. Outcomes of steps of the adversary consist of a new state t% ∈ TA and a query q ∈ QA . Since the !!! !!! adversary is given by a probabilistic machine, there is a finite set (or list) of outcomes, each equipped with a probability. Similarly, steps of the oracle depend on its current internal state s ∈ SO and the current query q ∈ QA . Outcomes of computations of the oracle consist of Figure 2: A computation tree Comp(O $ A) a new state s% ∈ SO and a response r ∈ RO . Again, idealized (cryptographic) functions modeled by random choices lead to several possible outcomes. The behavior of the combined system is given by two functions stepO : SO ×QA → (SO ×RO ×[0, 1])+ and stepA : TA ×RO → (TA ×QA ×[0, 1])∗ . We specify the function stepO for PACE by transition rules that are similar to the rules R(tr, e) in the inductive definition of the set TP ACE of (DY) traces (see Sec. 3.2). In particular, we use symbolic expressions to represent the control part of the session states as part of s ∈ SO . The symbolic expressions are interpreted by an operator . that evaluates


symbols. For instance, pwd(i) is evaluated to the password (value) π ∈ P W D of the ith participant acting in role A (i.e. A[i]) and nonce(l) to the l-th nonce (value) randomly chosen from a set RN D. Probabilistic values are generated using the oracle by certain additional state components. For example, the first PACE message is generated by a participant (A[i]) with password π = pwd(i) as follows. We consider all choices for a nonce sA = nonce(l) from the set RN D. For each sA we check whether the state component orC (s) ⊆ P W D×RN D× RN D already contains a triple (π, sA , z) in which case, we generate the response value as enc(π, sA ) = z. Otherwise, we consider all choices of z from a set of n possible values (i.e. from a subset of RN D given by orC (s)) to obtain z = enc(π, sA ) after (π, sA , z) was inserted into orC (s% ). The probability of the alternative transition steps generated this way is determined by the the cardinality |RN D| and n. Obviously, the same visible response z might lead to different successor states hidden in the oracle. In the control component of the oracle, we keep enc(pwd(i), nonce(l)) as the last successful step of this session. In this way, the control states and the responses of the oracle exhibit the same structure as traces in the symbolic (DY) model. Computation paths end by situations where A halts, given by an empty image of stepA . Without further analyzing computation paths in the tree the only knowledge about the probabilities p in the outcomes of stepA is that their sum is one.

5 Analyzing (BR) Computation Trees In this section, we describe the analysis of attacks based on computation trees. Attacks are given by paths where the final problem is solved, i.e. the adversary distinguishes a session key (by an honest participant) from a random value. Every success computation path contains a terminated session by an honest participant where the responses are computed as reaction on send queries generated by the adversary. The messages in these queries have to be accepted by the honest participant as simulated by the oracle according to the protocol rules. In general, the adversary has to solve the problem of generating a correct protocol message by using knowledge obtained from all previously observed responses. The main question is whether there can be an adversary A that is able to solve all these problems including the final problem with a considerably high probability. First we consider the adversary machines that are restricted to DY reasoning. We define this kind of machines relative to computation trees: (a) In a DY-computation tree Comp(O G A), the steps of A are deterministic, i.e. every red node may not have more than a child node. This must not be confused with the fact that there are different strategies for adversaries. (b) Each value in a query must be associated a symbolic expression O ∈ DY (O), where the list O contains the symbolic expressions associated to the corresponding directly observable (message) values. The following theorem allows us to exploit the algebraic-logic proof as a VSE proof for the security of PACE (in the BR model) against DY restricted adversary machines. Note that DY adversaries cannot be removed by complexity considerations, since DY computations


are feasible. Theorem 5.1 ([CSDF10]) Let Comp(O G A) be a (PACE) DY-computation tree. For all list O of the symbolic expressions associated to the public values on a computation path in Comp(O G A) there exists a protocol trace tr in the DY model of PACE such that ∀O : O ∈ DY (O) ⇔ O ∈ DY (spies(tr)). This theorem is proved by induction on computation paths, [Neu11]. Regarding arbitrary adversary machines, the success to break the protocol shall be traced back to a complete list of local computation problems that are induced, as explained above, by protocol rules and that fit to the (partly idealized) assumptions on the cryptographic operations. This is work in progress. Up to now, we identified systematically a list of local (sub-) problems that we formally defined owing to notions given by computation trees, [CSDF10, Neu11]. Each local problem is defined by an input-output relation which is specified by input computation paths (in Comp(O G A)) and by correct outputs defined relative to associated states s ∈ SO . Further work will be an axiomatic system that can be used to prove the completeness of the identified problem list.

6 Conclusion In spite of well-developed frameworks which guarantee soundness of algebraic-logic security proofs with respect to cryptographic security, their applicability to practical protocols is quite limited (see Sec. 1). For this reason, two independent security analysis for PACE were performed, a cryptographic security analysis and an algebraic-logic security proof, to explore PACE by applying state-of-the-art techniques. As the mathematical foundations are quite different, i.e., complexity theory versus mathematical logic, both analyses for PACE existed more or less concurrently at the outset of our merging attempt. Now, the described formalization of the BR-model provides us with a uniform formal framework for algebraic-logic and (computational-)cryptographic reasoning. This enables us to merge the cryptographic security analysis and the algebraic-logic security proof of PACE as described in this paper. We obtained a closed formal security analysis for PACE. The consequence is that the proven properties of the PACE protocol in both approaches can be linked. This enhances the reliability of the cryptographic (pencil-and-paper) proof as it can be supported by an accurate, formal algebraic-logic verification. Here, we have only described the merging of a cryptographic security analysis and the algebraic-logic security proof of the password-based security protocol PACE. However, our approach, formalizing cryptographic analysis methodologies, seems to be much more general and applicable to a broad class of security protocols. This estimation has stimulated the project ProtoTo, funded by the German Federal Ministry of Education and Research (BMBF), about merges in related cases.


References [AFP06]

Michel Abdalla, Pierre-Alain Fouque, and David Pointcheval. Password-Based Authenticated Key Exchange in the Three-Party Setting. IEE Proceedings — Information Security, 153(1):27–39, March 2006.

[AR02]

Mart´ın Abadi and Phillip Rogaway. Reconciling Two Views of Cryptography (The Computational Soundness of Formal Encryption). Journal of Cryptology, 15(2):103– 127, 2002.

[AR07]

Mart´ın Abadi and Phillip Rogaway. Reconciling Two Views of Cryptography (The Computational Soundness of Formal Encryption). Journal of Cryptology, 20(3):395, July 2007.

[BFK09]

Jens Bender, Marc Fischlin, and Dennis Kügler. Security Analysis of the PACE KeyAgreement Protocol. In Proceedings of the Information Security Conference (ISC) 2009, volume 5735 of Lecture Notes in Computer Science, pages 33–48. SpringerVerlag, 2009.

[BGHB11] Gilles Barthe, Benjamin Grégoire, Sylvain Heraud, and Santiago Zanella Béguelin. Computer-Aided Security Proofs for the Working Cryptographer. In CRYPTO, volume 6841 of Lecture Notes in Computer Science, pages 71–90. Springer, 2011. [BPR00]

Mihir Bellare, David Pointcheval, and Phillip Rogaway. Authenticated Key Exchange Secure against Dictionary Attacks. In Bart Preneel, editor, Advances in Cryptology — Eurocrypt ’00, volume 1807 of Lecture Notes in Computer Science, pages 139+, 2000.

[BPW03]

Michael Backes, Birgit Pfitzmann, and Michael Waidner. A Composable Cryptographic Library with Nested Operations. In Sushil Jajodia, Vijayalakshmi Atluri, and Trent Jaeger, editors, ACM CCS 03: 10th Conference on Computer and Communications Security, pages 220–230. ACM Press, October 2003.

[BPW04]

Michael Backes, Birgit Pfitzmann, and Michael Waidner. A General Composition Theorem for Secure Reactive Systems. In Moni Naor, editor, TCC 2004: 1st Theory of Cryptography Conference, volume 2951 of Lecture Notes in Computer Science, pages 336–354. Springer, February 2004.

[BR94]

Mihir Bellare and Phillip Rogaway. Entity Authentication and Key Distribution. In Douglas R. Stinson, editor, Advances in Cryptology – CRYPTO’93, volume 773 of Lecture Notes in Computer Science, pages 232–249. Springer, August 1994.

[BU08]

Michael Backes and Dominique Unruh. Limits of Constructive Security Proofs. In Josef Pieprzyk, editor, Advances in Cryptology – ASIACRYPT 2008, volume 5350 of Lecture Notes in Computer Science, pages 290–307. Springer, December 2008.

[Can01]

Ran Canetti. Universally Composable Security: A New Paradigm for Cryptographic Protocols. In 42nd Annual Symposium on Foundations of Computer Science, pages 136–145. IEEE Computer Society Press, October 2001.

[CH06]

Ran Canetti and Jonathan Herzog. Universally Composable Symbolic Analysis of Mutual Authentication and Key-Exchange Protocols. In Shai Halevi and Tal Rabin, editors, TCC 2006: 3rd Theory of Cryptography Conference, volume 3876 of Lecture Notes in Computer Science, pages 380–403. Springer, March 2006.

[CLC08]

Hubert Comon-Lundh and Véronique Cortier. Computational soundness of observational equivalence. In Peng Ning, Paul F. Syverson, and Somesh Jha, editors, ACM CCS 08: 15th Conference on Computer and Communications Security, pages 109–118. ACM Press, October 2008.


[CS10]

Lassaad Cheikhrouhou and Werner Stephan. Meilensteinreport: Inductive Verification of PACE. Technical report, Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, 2010.

¨ ur Dagdelen, and Marc Fischlin. Meilen[CSDF10] Lassaad Cheikhrouhou, Werner Stephan, Ozg¨ steinreport: Integrating the Cryptographic Security Analysis and the Algebraic-Logic Security Proof of PACE. Technical report, Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, 2010. [EAC]

Technical Guideline: Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI). Technical Report TR-03110, Version 2.05, Federal Office for Information Security (BSI).

[IK03]

Russell Impagliazzo and Bruce M. Kapron. Logics for Reasoning about Cryptographic Constructions. In 44th Annual Symposium on Foundations of Computer Science, pages 372–383. IEEE Computer Society Press, October 2003.

[MH07]

Hirofumi Muratani and Yoshikazu Hanatani. Computationally Sound Symbolic Criteria for UC-secure Multi-Party Mutual Authentication and Key Exchange Protocols. In IEICE Tech. Rep., volume 106 of ISEC2006-150, pages 59–64, Gunma, March 2007. Thu, Mar 15, 2007 - Fri, Mar 16 : Gunma Univ. (Kiryu Campus) (IT, ISEC, WBS).

[MW04a]

Daniele Micciancio and Bogdan Warinschi. Completeness Theorems for the AbadiRogaway Language of Encrypted Expressions. Journal of Computer Security, 12(1):99– 130, 2004.

[MW04b]

Daniele Micciancio and Bogdan Warinschi. Soundness of Formal Encryption in the Presence of Active Adversaries. In Moni Naor, editor, TCC 2004: 1st Theory of Cryptography Conference, volume 2951 of Lecture Notes in Computer Science, pages 133– 151. Springer, February 2004.

[Neu11]

Stephan Rouven Neumann. Integration der kryptographischen Sicherheitsanalyse und des algebraisch-logischen Sicherheitsbeweises von PACE. Master’s thesis, Saarland University, Germany, 2011.

[Pat05]

A.R. Patil. On symbolic analysis of cryptographic protocols. Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2005.

[PW00]

Birgit Pfitzmann and Michael Waidner. Composition and Integrity Preservation of Secure Reactive Systems. In S. Jajodia and P. Samarati, editors, ACM CCS 00: 7th Conference on Computer and Communications Security, pages 245–254. ACM Press, November 2000.

[PW01]

Birgit Pfitzmann and Michael Waidner. A Model for Asynchronous Reactive Systems and its Application to Secure Message Transmission. In IEEE Symposium on Security and Privacy, pages 184–, 2001.

[UKN+ ]

Markus Ullmann, Dennis Kügler, Heike Neumann, Sebastian Stappert, and Vögeler Matthias. Password Authenticated Key Agreement for Contactless Smart Cards. In Proceedings of the 4-th Workshop on RFID Security, Budapest 2008, pages 140–161.

On the design and implementation of the Open eCard App Detlef Hühnlein1 · Dirk Petrautzki2 · Johannes Schmölz1 · Tobias Wich1 Moritz Horsch1,3 · Thomas Wieland2 · Jan Eichholz4 · Alexander Wiesmaier5 Johannes Braun3 · Florian Feldmann6 · Simon Potzernheim2 · Jörg Schwenk6 Christian Kahlo7 · Andreas Kühne8 · Heiko Veit8 1

ecsec GmbH, Sudetenstraße 16, 96247 Michelau Hochschule Coburg, Friedrich-Streib-Straße 2, 96450 Coburg 3 Technische Universität Darmstadt, Hochschulstraße 10, 64289 Darmstadt 4 Giesecke & Devrient GmbH, Prinzregentenstraße 159, 81677 München 5 AGT Group (R&D) GmbH, Hilpertstraße 20a, 64295 Darmstadt 6 Ruhr Universität Bochum, Universitätsstraße 150, 44801 Bochum 7 AGETO Innovation GmbH, Winzerlaer Straße 2, 07745 Jena 8 Trustable Ltd., Kirchröder Str. 70e, 30625 Hannover 2

Abstract: The paper at hand discusses the design and implementation of the “Open eCard App”, which is a lightweight and open eID client, which integrates major international standards. It supports strong authentication and electronic signatures with numerous common electronic identity cards in desktop as well as mobile environments. The Open eCard App is designed to be as lightweight, usable and modular as possible to support a variety of popular platforms including Android for example. It will be distributed under a suitable open source license and hence may provide an interesting alternative to existing eID clients.

1.

Introduction

Against the background of various electronic identity (eID) card projects around the globe (e.g. in the USA [NIST-PIV], Australia [AGIMO-NSF] and Europe [CEN15480]) there have been numerous initiatives in the area of research, development and standardization of eID cards, smart card middleware components and related services. The German government, for example, has been issuing a new electronic identity card (“neuer Personalausweis”, nPA) since November 2010, which features modern cryptographic privacy enhanced protocols [BSI-TR3110] and contactless smart card technology [ISO14443]. In order to support the broad adoption of this innovative security technology the German government initiated a 30 million euro subsidy program in which security bundles (“IT-Sicherheitskits”) are provided for German citizen. These security bundles comprise a free eID client [AusweisApp] for computers and a free or discounted smart card terminal. This eID client was announced to support all major platforms, interface devices, and smart cards as specified in the “eCard-API-Framework” [BSI-TR03112], which in turn is based on major international standards such as [ISO24727], [CEN15480] and [OASIS-DSS]. Thus, there have been high expectations with respect to the real world impact of these developments.

96

On the design and implementation of the Open eCard App

However, despite the tremendous political, technical and financial efforts of the German government the practical situation with respect to the secure, easy and ubiquitous use of the different smart cards involved in the German eCard-strategy (cf. [Kowa07] and [HoSt11]) is not yet satisfying. The currently available eID client [AusweisApp], for example, only supports authentication with the German ID card on selected PC-based platforms. Important features such as the support for electronic signature techniques, other smart cards, the Mac OS platform or mobile devices are still lacking. As of today it is not clear whether1 and when those features will be supported. In order to solve this problem the authors of the paper at hand have started to design and implement a lightweight alternative, the “Open eCard App”, and will publish its source under a suitable open source license. The present contribution discusses selected aspects related to the design and development of this lightweight eID client. The remainder of the paper is structured as follows: Section 2 provides an overview of related work. Section 3 summarizes the main functional and non-functional requirements for the Open eCard App. Section 4 presents the high level design that has been developed based on the given requirements. Section 5 highlights selected aspects of the module design and related implementation issues. Section 6 closes the paper with an outlook on the next steps and future development.

2.

Related Work

In addition to the development of the eCard-API-Framework [BSI-TR03112], the respective standards (e.g. [CEN15480], [ISO24727] and [OASIS-DSS]) and the eID client [AusweisApp] supported by the German government, there have been various related developments which need to be considered here. First, there are a few alternative proprietary eID clients (cf. [Ageto-AA] and [bosAutent]), which support the German ID card, or implement a subset of the eCard-APIFramework (cf. [T7-eCard-QES]). Furthermore, there have been first academic contributions to enable the use of the German ID card on mobile and PC-based platforms. [EiHü08] discusses the use of [ISO24727] in a mobile environment. In [Hors09], [Kief10], [WHB+11] and [Hors11] an NFC-enabled Java Micro Edition (Java ME) mobile phone is used for mobile authentication with the German ID card. In the [Androsmex] project an Android based NFC-enabled smartphone is used to implement the Password Authenticated Connection Establishment (PACE) protocol (cf. [BSITR3110] and [ICAO-PACE]). In [Petr11] a mobile authentication using the German ID card is realized on an Android-based Smartphone using a separate mobile smart card reader. At the University Koblenz-Landau the rosecat project [Jahn11] aims at providing an open source eID client and the [OpenPACE] project at the Humboldt University Berlin aims at providing a cryptographic library which provides support for PACE and parts of the Extended Access Control (EAC) version 2.0 protocol [BSI-TR3110]. While both latter projects have been developed with PCs as primary target in mind, there have 1 As the size of the different versions of [AusweisApp] ranges between 56.3 MB and 97.6 MB, there are serious doubts whether this eID client may ever be available for mobile devices.


97

been related contributions, which focus on mobile eID scenarios (cf. [Beil10], [Oepe10], [MMO11] and [MOMR11]). In addition to the projects in Germany, there have been some open eID related developments in other countries, which are to be considered. The JMRTD project [JMRTD] provides an open source Java implementation of the Machine Readable Travel Documents (MRTD) standards developed by the International Civil Aviation Organization. For the Belgian eID card there is already a Java library [eidlib], a Java applet [eID-Applet] and software for the creation of XML-based signatures [eID-DSS]. [VeLa+09] discusses some security and privacy improvements for the Belgian eID technology. With [MOCCA] an open source environment for the Austrian Citizen Card is available. Recently, an open source middleware for the Portuguese Citizen Card was introduced [MEDI11]. For the generation and verification of XML Advanced Electronic Signatures (XAdES) the [OpenXAdES] project provided a C-based library and in [Gonç10] a Java-based implementation has been developed. The Sirius project [Sirius-SS] develops an open source signing server, which supports the interfaces standardized in [OASIS-DSS]. With respect to smart cards, there are already two open source projects [OpenSC] and [OpenSCDP], which aim at providing a platform-independent framework for the use of smart cards. While [OpenSC] in particular supports cards with Cryptographic Information Application data according to part 15 of [ISO7816], the [OpenSCDP] project provides scripting based support for the German ID card and the German electronic health card for example. For the Android-platform there is an open source secure element evaluation kit [SEEK4Android], which implements [OpenMobile]. There are various frameworks and components in the area of the Security Assertion Markup Language (SAML). [OpenSAML] is a platform-independent and open source representative of them. The use of eID cards in a SAML-environment has been discussed in [EHS09] and [EHMS10]. Corresponding SAML-profiles have been defined in [BSITR03130] and [STORK]. The channel binding presented in Section 3.3.10 of Part 7 of [BSI-TR03112] may be used to prevent man-in-the-middle attacks. Unfortunately, this approach is only applicable to cards which feature the Extended Access Control protocol specified in [BSI-TR3110], such as the German ID card for example. In order to provide a secure SAML-binding, which may be used with arbitrary eID cards, the alternatives discussed in [SAML-HoK], [GaLiSc08] and [KSJG10] as well as the TLS-channel binding specified in [RFC5929] may serve as starting points. For PC-based platforms a trusted computing environment may be realized utilizing a Trusted Platform Module (TPM) and a Trusted Software Stack (TSS). The [jTSS] project provides an open source TSS implementation for the Java Platform. Because the Open eCard App is required to run also on mobile platforms, particularly Android, it is necessary to consider the specific security aspects for this platform in more detail. Android specific attacks have for example been shown in [DaDm+10] and there exist several projects and publications that discuss possible ways to improve the security of Android smartphones (cf. [BDDH+11], [NKZS10], [YZJF11] and [CoNC10]). To provide a robust and trustworthy implementation of the mobile eID client it is also required to consider unconventional attack vectors such as discussed in [AGMB+10] and

98


[WaSt10]. On the other side there will be mobile device platforms, which are offering enhanced security features like the Trusted Execution Environment (TEE) specified by Global Platform [GP-TEE]. The TEE realizes a secure operating system next to the standard mobile operating system (e.g. Android, iOS, Windows Phone) and hence, can be utilized to secure the mobile eID client. It offers the possibility to install new trusted applications in the field, which are completely separated from each other and applications running outside the trusted execution environment. Trusted applications can securely store data, access secure elements, perform cryptographic operations and protocols and perform secure input and output using the display and keypad of the mobile device.

3.

Requirements for the Open eCard App

This section contains the main functional and non-functional requirements of the lightweight Open eCard App, where the key words MAY, SHOULD, SHALL and MUST are used as defined in [RFC2119]. R1. Support for all popular platforms The Open eCard App MUST be designed to support the most popular client platforms. In addition to PCs based on Windows, Linux or Mac OS this in particular includes NFCenabled mobile devices, which are for example based on [Android]. On the other side – unlike the clients considered in [EiHü08], [Hors09] and [Hors11] – we do not restrict ourselves to the limited feature set provided by the Java ME platform, but only require that it SHOULD be possible to port our client to such a platform if it turns out to be necessary. R2. Modularity, open interfaces and extensibility In order to facilitate the distributed development and portability to different platforms, the Open eCard App MUST consist of suitable modules, which are connected through open interfaces. Those modules SHOULD be designed to minimize the effort of creating a new client application for a specific purpose2. For features, which are expected to change over time, such as cryptographic and communication protocols, the Open eCard App SHALL provide suitable extension mechanisms. The basic cryptographic mechanisms SHOULD be provided in form of a standardized cryptographic module to ensure implementation independence and interoperability for cryptographic functions on each supported platform. In particular the Graphical User Interface (GUI), which is expected to be very platform specific, MUST be clearly separated from the other modules. R3. Architecture based on ISO/IEC 24727 The architecture of the Open eCard App SHALL be based on the international secure element infrastructure standard [ISO24727]. This means in particular that the Interface Device (IFD) API (cf. [ISO24727], part 4) and the Service Access Layer (SAL) API (cf. [ISO24727], part 3) MUST be supported. The IFD Layer SHALL allow to use a wide range of external card terminals, e.g. those based on the PC/SC architecture or 2 As sketched in [BHWH11] the mobile phone based eID client may serve as smart card terminal for a PCbased eID-client or as standalone system for mobile authentication scenarios.


99

[OpenMobile], and NFC-modules integrated in mobile phones and SHOULD support TPMs, if present on the platform. The SAL SHALL support arbitrary smart cards, which are described by a CardInfo file according to Section 9 of [CEN15480]3. R4. Support for electronic signatures and federated identity management The Open eCard App SHOULD be able to create advanced electronic signatures in standardized formats (cf. [ETSI-101733], [ETSI-101903] and [ETSI-102778]) using the supported eID cards and / or suitable server systems. R5. Support for federated identity management The Open eCard App SHOULD support federated identity management protocols according to internationally acknowledged standards, such as [SAML(v2.0)] for example. R6. Browser integration The Open eCard App MUST be start- and accessible from within a browser to perform an authentication at web-based services. R7. Secure components The Open eCard App MUST utilize the security features of the attached components. This includes the usage of the secure input and output facility of an attached reader as well as the usage of a possibly available secure operating system like the Trusted Execution Environment for mobile devices [GP-TEE]. R8. Security The Open eCard App MUST be designed in a security aware manner, such that a formal security evaluation, e.g. according to Common Criteria [CC(v3.1)], is possible with modest additional effort. Furthermore the Open eCard App SHALL use the security features provided by attached components. This includes the usage of the secure input and output facility of an attached reader as well as the usage of a possibly available secure operating system like the Trusted Execution Environment [GP-TEE] for mobile devices. R9. Open source capable The Open eCard App SHOULD be substantially free of external dependencies. This way it can be released as open source software under a suitable license and there is no regard to take on rights of third parties. R10. Transparency The Open eCard App SHOULD provide information to the user about all the existing connections (Internet), access to smart card and other actions. R11. Stability The released versions of the Open eCard App SHOULD always be stable, i.e. work without crashes and undesired behaviour.

3

See http://www.cardinfo.eu for more information about this topic.

100


R12. High usability and accessible GUI The design and implementation of a GUI MUST consider platform specific issues to maximize usability and the GUI SHOULD support accessibility features.

4.

High Level Design

Based on previous work (e.g. [BSI-TR03112], [Petr11] and [Hors11]) and the requirements above, the high level design depicted in Figure 1 has been developed. It envisages the implementation of the Open eCard App in the Java programming language, making use of the respective architectural concepts. Java is selected mainly because it is supported on all target platforms (R1) and allows applications that can easily be modularized and updated (R2).

Figure 1: High Level Design of the Open eCard App

The main building blocks of the Open eCard App are as follows: •

Interface Device (IFD) This component implements the IFD interface as specified in part 6 of [BSITR03112] and part 4 of [ISO24727]. It also contains the additional interfaces for password-based protocols such as PACE (cf. Section 5.1). It provides a generalized interface for communication with specific readers and smart cards, to enable the user to use arbitrary card terminals or smart cards.


101

•

Event Manager The Event Manager monitors the occurrence of events (e.g. added or removed terminals or cards) and performs the type-recognition of freshly captured cards (cf. Sections 5.3 - 5.4).

•

Service Access Layer (SAL) This module implements the Service Access Layer as specified in part 4 of [BSITR03112] and part 3 of [ISO24727]. An important aspect of this component is that it provides an extension mechanism, which enables the addition of new authentication protocols in the future without changing other parts of the implementation.

•

Crypto The crypto module unifies the access to cryptographic functions of the other modules. Through the use of the Java Cryptography Architecture (JCA) [JCA] interface and the provider architecture offered by it, it is easy to exchange the Cryptographic Service Provider (CSP) and hence use the most suitable one for each platform. As JCA provider for the presented eID client primarily [BouncyCastle]4, [FlexiProvider] and [IAIK-JCE] come in mind.

•

Graphical User Interface (GUI) The GUI is connected via an abstract interface (cf. Section 5.2) and hence is easily interchangeable. This allows providing platform-specific GUI-implementations, while leaving the other modules unchanged.

•

Security Assertion Markup Language (SAML) This component provides support for the SAML Enhanced Client and Proxy (ECP) profile [SAML-ECP], which allows receiving an AuthnRequest via the PAOSbinding [PAOS-v2.0] and starting the eID based authentication procedure with a suitable Identity Provider. Compared to the Web Browser Single Sign-On (SSO) profile used in [BSI-TR03130], the support of the ECP-profile leads to a more straightforward authentication procedure that is easier to protect.

•

Electronic Signatures (eSign) This component allows to create advanced electronic signatures according to [ETSI101733], [ETSI-101903] and [ETSI-102778] using the interface defined in part 2 of [BSI-TR03112], which is based on [OASIS-DSS].

•

Dispatcher The dispatcher provides a centralized entry point for the handling of incoming and outgoing messages. By this centralization, the dispatcher helps to reduce the amount of Java code and the complexity of the Open eCard App.

4 In order to avoid conflicts with the crippled version of Bouncy Castle integrated in Android, it may turn out to be advantageous to use [SpongeCastle] instead.

102

•


Transport The transport component encapsulates the individual transport protocols settled at various transport layers. The layered structure makes it easy to use the protocols needed for a specific use case and to add new protocols. In order to support the currently available eID servers, the protocol stack will at least allow exchanging PAOS messages, which are bound to HTTP and require TLS and TCP/IP to be transported. However the protocol stack of the eID client is designed to additionally support other bindings (e.g. SOAP [SOAP-v1.1]) and alternative protocols such as the Austrian Security Token Abstraction Layer (STAL) [MOCCA] or the eID applet protocol used in Belgium [eID-Applet].

•

Browser Integration As the Open eCard App should start automatically (without requiring further action by the user) on accessing an appropriately prepared website, there has to be a mechanism for the browser to launch the application and pass over (connection-) parameters. For this purpose, the eID activation mechanisms specified in part 7 of [BSI-TR03112] and the cryptographic interfaces supported by popular browsers (e.g. [PKCS#11]) are implemented in this module.

5.

Selected Aspects of the Module Design and Implementation

This section highlights selected aspects of the design and implementation of the Open eCard App. 5.1

PACE in IFD Layer

The standardisation of the IFD interface in part 4 of [ISO24727] took place before all details of the PACE protocol (see [BSI-TR3110] and [ICAO-PACE]) and the corresponding card terminals (see [BSI-TR03119] and [PC/SC-PACE]) were specified. Thus PACE-support is currently not yet integrated in the standardized IFD layer and existing eID clients such as [AusweisApp], [bos-Autent] and [Ageto-AA] seem to implement PACE on top of the IFD layer. As in this case the Service Access Layer needs to be aware of the detailed capabilities of the connected card terminal this is not optimal from an architectural point of view. To overcome this problem we propose an extension for the IFD API, that contains the two commands EstablishChannel and DestroyChannel, which are protocol agnostic generalizations of the EstablishPACEChannel and DestroyPACEChannel commands defined in [PC/SC-PACE] and (partly) in [BSI-TR03119].


5.2

103

GUI Interface

As the Graphical User Interface (GUI) needs to be developed in a platform specific manner, it is necessary to introduce an interface, which decouples the user interface from the rest of the eID client. As the Open eCard App shall support a wide range of smart card terminals with varying capabilities in a homogeneous manner, the GUI needs to compensate these differences and provide a card- and terminal-specific dialogue to obtain the user consent for a specific transaction. In order to support arbitrary terminals and eID cards, the GUI interface is defined in an abstract manner. A user dialogue specification consists of a sequence of steps, which in turn may contain a sequence of input and output elements. The input elements allow to mark check boxes, which may for example be used to restrict a Certificate Holder Authorization Template (cf. [BSITR3110], Annex C.1.5 and C.4), or capture a PIN. 5.3

Event Manager

Events in the IFD layer (e.g. insertion or removal of cards) can be recognized using the Wait function of the IFD interface as specified in part 6 of [BSI-TR03112] and in part 4 of [ISO24727]. This function returns the state of a monitored terminal, after an event has occurred. In order to identify a specific event, the calling component must compare the received state with the previous state of the terminal. Thus, every component that makes use of the Wait function would need to implement this kind of comparison, which is not very convenient. To centralize this functionality, we introduce an Event Manager, which monitors the occurrence of events, triggers the card recognition and distributes the received information to all components that have registered to it. A component can register for one or more specific events (e.g. insertion of cards) and will be notified if one of them occurs. Furthermore custom filters can be applied to the Event Manager, in case the predefined registration options are not sufficient. 5.4

Card Recognition

In order to support the widest possible range of eID cards, the Open eCard App supports CardInfo structures according to [BSI-TR03112] Part 4, Annex A and [CEN15480] Section 9. For the recognition of the card type it is necessary to construct a decision tree (cf. [BSI-TR03112] Part 4, Figure 5 and [Wich11] Section 5.1.2) using the set of available CardInfo files. While this construction could be performed by an eID client upon initialization, we propose to perform this construction only once and store the constructed decision tree in a suitable XML format. As there is no need for the eID client to perform the construction itself, we propose that a suitable infrastructure component, such as the CardInfo repository (cf. [BSI-TR03112] Part 5), performs the construction and distributes the compact decision tree.

104


The Card Recognition module within the Open eCard App (cf. Figure 1) works with the recognition tree and just needs access to the IFD. As soon as a new card is captured and a corresponding event is identified by the Event Manager (cf. Section 5.3), the card recognition procedure is performed by connecting the card and walking through the recognition tree until the card type is determined. In the eCard-API layering model, this request to the Card Recognition module is performed by the SAL. However, with the availability of the Event Manager, the most natural approach is to perform the recognition right after a “card inserted” event and distribute the information with a “card recognised” event afterwards. This information distribution mechanism has the advantage that not only the SAL, but also other modules which need this kind of information (e.g. the GUI), can act as an event sink, too.

6.

Summary

The paper at hand presents the design and selected implementation details of the Open eCard App. This eID client supports arbitrary smart cards, which are described by CardInfo files and is designed to support PC-based as well as mobile platforms, e.g. based on [Android]. As the Open eCard App is designed to be as lightweight and usable as possible and will be distributed under a suitable open source license, it may provide an interesting open alternative to the currently available eID clients such as the [AusweisApp].


7.

105

References

[Ageto-AA] [AGIMO-NSF]

[AGMB+10]

[Android] [Androsmex]

[AusweisApp] [BDDH+11]

[Beil10] [BHWH11]

[BouncyCastle] [bos-Autent] [BSI-TR3110]

[BSI-TR03112]

Ageto Innovation GmbH: AGETO AusweisApp, http://www.ageto.de/egovernment/ageto-ausweis-app Australian Government Information Management Office (AGIMO): National Smartcard Framework, http://www.finance.gov.au/e-government/securityand-authentication/smartcard-framework.html A. Aviv, K. Gibson, E. Mossop, M. Blaze and J. Smith: Smudge attacks on smartphone touch screens, WOOT'10 Proceedings of the 4th USENIX conference on offensive technologies, http://www.usenix.org/events/woot10/tech/full_papers/Aviv.pdf Google Inc.: Android Website, http://www.android.com/ T. Senger & al.: Androsmex Project - A mobile smart card explorer for android smartphones with NFC capabilities, http://code.google.com/p/androsmex/ BSI: Official Portal for the eID-client “AusweisApp”, http://www.ausweisapp.de S. Bugiel, L. Davi, A. Dmitrienko, S. Heuser, A. Sadeghi and B. Shastry: Practical and Lightweight Domain Isolation on Android, Proceedings of the 1st ACM CCS Workshop on Security and Privacy in Mobile Devices (SPSM), ACM Press, October 2011, http://www.informatik.tudarmstadt.de/fileadmin/user_upload/Group_TRUST/PubsPDF/spsm18bugiel.pdf K. Beilke: Mobile eCard-API, Humboldt-University, Diploma Thesis, 2010, http://sar.informatik.hu-berlin.de/research/publications/#SAR-PR-2010-12 J. Braun, M. Horsch, A. Wiesmaier and D. Hühnlein: Mobile Authentication and Signature (in German), DACH Security 2011, pp. 1-12, http://www.cdc.informatik.tudarmstadt.de/mona/pubs/201109_DACH11_Mobile_Authentisierung_und_Sig natur.pdf The Legion of the Bouncy Castle: Bouncy Castle API, http://www.bouncycastle.org/ bos GmbH & Co. KG: Governikus Autent, http://www.bosbremen.de/de/governikus_autent/1854605/ BSI: Advanced Security Mechanism for Machine Readable Travel Documents – Extended Access Control (EAC), Technical Directive of the Federal Office for Information Security Nr. 03110, BSI TR-03110, Version 2.05, https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3110/index_htm.html BSI: eCard-API-Framework, Technical Directive of the Federal Office for Information Security Nr. 03112, BSI TR-03112, Version 1.1, https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr0 3112/index_htm.html

106

[BSI-TR03119]

[BSI-TR03130]

[CC(v3.1)] [CEN15480] [CoNC10]

[DaDm+10]

[eID-Applet] [eID-DSS] [eidlib] [EHS09]

[EHMS10]

[EiHü08]

[ETSI-101733] [ETSI-101903]

[ETSI-102778] [FlexiProvider] [GaLiSc08]


BSI: Requirements for Card Terminals with support for the new German eIDcard, in German, Technical Directive of the Federal Office for Information Security Nr. 03119, BSI TR-03119, Version 1.2, 27.03.2011, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Tech nischeRichtlinien/TR03119/BSI-TR-03119_V1_pdf BSI: eID-Server, Technical Directive of the Federal Office for Information Security Nr. 03130 (in German), BSI TR-03130, Version 1.4.1, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Tech nischeRichtlinien/TR03130/TR-03130_TR-eID-Server_V1_4_pdf CCMB: Common Criteria for Information Technology Security Evaluation, Version 3.1, part 1-3, 2009, http://www.commoncriteriaportal.org/cc/ CEN: Identification card systems — European Citizen Card, CEN TS 15480 (Part 1-4) M. Conti1, V. Nguyen and B. Crispo: CRePE - Context-Related Policy Enforcement for Android, ISC'10 Proceedings of the 13th international conference on Information security, Springer, ISBN: 978-3-642-18177-1, http://www.few.vu.nl/~mconti/papers/C16.pdf L. Davi, A. Dmitrienko, A. Sadeghi and M. Winandy: Privilege Escalation Attacks on Android, ISC'10 Proceedings of the 13th international conference on Information security, Springer, ISBN: 978-3-642-18177-1, http://www.ei.rub.de/media/trust/veroeffentlichungen/2010/11/13/DDSW2010 _Privilege_Escalation_Attacks_on_Android.pdf F. Cornelis & al.: eID-Applet Project, http://code.google.com/p/eid-applet/ F. Cornelis & al.: eID Digital Signature Service Project, http://code.google.com/p/eid-dss/ K. Overdulve: eidlib Project, http://code.google.com/p/eidlib/ J. Eichholz, D. Hühnlein and J. Schwenk: SAMLizing the European Citizen Card, in A. Brömme & al. (Ed.), BIOSIG 2009: Biometrics and Electronic Signatures, GI-Edition Lecture Notes in Informatics (LNI) 155, 2009, pp. 105117, http://www.ecsec.de/pub/SAMLizing-ECC.pdf J. Eichholz, D. Hühnlein, G. Meister and J. Schmölz: New Authentication concepts for electronic Identity Tokens, in Proceedings of “ISSE 2010”, Vieweg, 2010, pp. 26-38, http://www.ecsec.de/pub/ISSE2010.pdf J. Eichholz and D. Hühnlein: Using ISO/IEC 24727 for mobile devices, in Proceedings of Sicherheit 2008, GI, LNI 128, pp. 581-587, http://www.ecsec.de/pub/2008_Sicherheit.pdf ETSI: CMS Advanced Electronic Signatures (CAdES), ETSI TS 101 733, Version 1.8.1. http://pda.etsi.org/pda/queryform.asp, December 2009 ETSI: Technical Specification XML Advanced Electronic Signatures (XAdES), ETSI TS 101 903, Version 1.4.1, http://pda.etsi.org/pda/queryform.asp, June 2009 ETSI: PDF Advanced Electronic Signature Profiles, ETSI TS 102 778, part 15, http://pda.etsi.org/pda/queryform.asp, 2009 M. Maurer & al.: Flexiprovider Project, http://www.flexiprovider.de S. Gajek, L. Liao and J. Schwenk: Stronger TLS Bindings for SAML Assertions and SAML Artifacts, Proceedings of the 2008 ACM workshop on Secure web services


[Gonç10]

[GP-TEE]

[Hors09]

[Hors11]

[HoSt11]

[IAIK-JCE] [ICAO-PACE]

[ISO7816] [ISO14443] [ISO24727] [Jahn11]

[JCA]

[JMRTD] [jTSS] [Kief10]

107

L. Gonçalves: XAdES4j— a Java Library for XadES Signature Services, Master Thesis, Instituto Superior de Engenharia de Lisboa, 2010, http://luisfsgoncalves.files.wordpress.com/2011/01/xades4j.pdf Global Platform: The Trusted Execution Environment: Delivering Enhanced Security at a Lower Cost to the Mobile Market, Whitepaper, February 2011, http://www.globalplatform.org/documents/GlobalPlatform_TEE_White_Paper _Feb2011.pdf M. Horsch: MobilePACE – Password Authenticated Connection Establishment implementation on mobile devices, Bachelor Thesis, TU Darmstadt, 2009, http://www.cdc.informatik.tudarmstadt.de/mona/pubs/200909_BA_MobilePACE.pdf M. Horsch: MONA - Mobile Authentication with the new German eID-card (in German), Master Thesis, TU Darmstadt, 2011, http://www.cdc.informatik.tudarmstadt.de/mona/pubs/201107_MA_Mobile%20Authentisierung%20mit%2 0dem%20neuen%20Personalausweis%20(MONA).pdf M. Horsch and M. Stopczynski: The German eCard-Strategy, Technical Report: TI-11/01, TU Darmstadt, http://www.cdc.informatik.tudarmstadt.de/reports/reports/the_german_ecard-strategy.pdf TU Graz: IAIK Provider for the Java™ Cryptography Extension (IAIK-JCE), http://jce.iaik.tugraz.at/ ICAO: Supplemental Access Control for Machine Readable Travel Documents, ICAO Technical Report, Version 1.01, 11.11.2010, http://www2.icao.int/en/MRTD/Downloads/Technical%20Reports/Technical %20Report.pdf ISO/IEC: Identification cards – Integrated circuit cards, ISO/IEC 7816 (part 1-15) ISO/IEC: Contactless integrated circuit cards - Proximity cards, ISO/IEC 14443 (Part 1-4) ISO/IEC: Identification cards – Integrated circuit cards programming interfaces, ISO/IEC 24727 (Part 1-5) N. Jahn: rosecat - Architecture and Implementation of an Open Source eID Client, in German, Diploma Thesis, University Koblenz-Landau, 2011, http://kola.opus.hbz-nrw.de/volltexte/2011/672/pdf/Diplomarbeit.pdf Oracle: Java ™ Cryptography Architecture (JCA) Reference Guide, http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/Cry ptoSpec.html M. Oostdijk & al.: JMRTD Project, http://jmrtd.org/ M. Pirkner, R. Toegl & al.: Trusted Computing for the Java Platform Project, http://sourceforge.net/projects/trustedjava/ F. Kiefer: Efficient Implementation of the PACE and EAC Protocol for mobile devices, in German, Bachelor Thesis, TU Darmstadt, 2010, http://www.cdc.informatik.tudarmstadt.de/mona/pubs/201007_BA_Effiziente_Implementierung_des_PACE -_und_EAC_Protokolls_fuer_mobile_Geraete.pdf

108

[Kowa07]

[KSJG10]

[MEDI11] [MMO11]

[MOCCA] [MOMR11]

[NIST-PIV] [NKZS10]

[OASIS-DSS]

[Oepe10]

[OpenPACE] [OpenMobile] [OpenSAML] [OpenSC] [OpenSCDP] [OpenXAdES]


B. Kowalski: The eCard-Strategy of the Federal Government of Germany, in German, in BIOSIG 2007: Biometrics and Electronic Signatures, Proceedings of the Special Interest Group on Biometrics and Electronic Signatures, LNI 108, pp. 87–96, 2007, http://subs.emis.de/LNI/Proceedings/Proceedings108/giproc-108-008.pdf F. Kohlar, J. Schwenk, M. Jensen and S. Gajek: Secure Bindings of SAML Assertions to TLS Sessions, Proceedings of the Fifth International Conference on Availability, Reliability and Security (ARES), 2010 L. Medinas: The development of the new Free/Opensource Portuguese Citizen Card Middleware, https://codebits.eu/intra/s/proposal/212 W. Müller, F. Morgner and D. Oepen: Mobile scenario for the new German ID card, in German, in 21st Smartcard-Workshop, 2.-3. Februar 2011, Darmstadt, pp. 179-188, 2011, http://sar.informatik.huberlin.de/research/publications/SAR-PR-2011-01/SAR-PR-2011-01.pdf MOCCA: Modular Open Citizen Card Architecture Project, http://mocca.egovlabs.gv.at/ F. Morgner, D. Oepen, W. Müller and J.-P. Redlich: Mobile Reader for the new German ID card, in German, in 12th German IT-Security Congress, SecuMedia, pp. 227-240, 2011, http://sar.informatik.huberlin.de/research/publications/SAR-PR-2011-04/SAR-PR-2011-04.pdf NIST: About Personal Identity Verification (PIV) of Federal Employees and Contractors, http://csrc.nist.gov/groups/SNS/piv/index.html M. Nauman , S. Khan , X. Zhang and J. Seifert: Beyond Kernel-level Integrity Measurement: Enabling Remote Attestation for the Android Platform, In Trust and Trustworthy Computing, Vol. 6101 (2010), http://profsandhu.com/zhang/pub/trust10-android.pdf OASIS: Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0, OASIS Standard, via http://docs.oasis-open.org/dss/v1.0/oasisdss-core-spec-v1.0-os.pdf D. Oepen: Authentication in the mobile web – on the usability of eID based authentication using an NFC based mobile device, in German, Diploma Thesis, Humboldt-University, 2010, http://sar.informatik.huberlin.de/research/publications/SAR-PR-2010-11/SAR-PR-2010-11_.pdf F. Morgner & al.: OpenPACE Project - Crypto library for the PACE protocol, http://openpace.sourceforge.net/ SIM Card Alliance: Open Mobile API specification, Version 1.2, http://tinyurl.com/ckl7sbt S. Cantor & al.: OpenSAML Project, https://wiki.shibboleth.net/confluence/display/OpenSAML/Home M. Paljak & al.: OpenSC Project - tools and libraries for smart card, http://www.opensc-project.org A. Schwier & al.: OpenSCDP Project - Open Smart Card Development Platform, http://www.openscdp.org/ T. Martens & al.: OpenXAdES Project, http://www.openxades.org/


[PAOS-v2.0]

109

Liberty Alliance Project: Liberty Reverse HTTP Binding for SOAP Specification, Version v2.0, via http://www.projectliberty.org/liberty/content/download/909/6303/file/libertypaos-v2.0.pdf [PC/SC-PACE] PC/SC Workgroup: Interoperability Specification for ICCs and Personal Computer Systems - Part 10 IFDs with Secure PIN Entry Capabilities – Amendment 1, 2011, http://www.pcscworkgroup.com/specifications/files/pcsc10_v2.02.08_AMD1. pdf [Petr11] D. Petrautzki: Security of Authentication Procedures for Mobile Devices, (in German), Master Thesis, Hochschule Coburg, 2011 [PKCS#11] RSA Laboratories: PKCS #11 Base Functionality v2.30: Cryptoki – Draft 4, 10 July 2009 [RFC2119] S. Bradner: Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, via http://www.ietf.org/rfc/rfc2119.txt [RFC5929] J. Altman, N. Williams, L. Zhu: Channel Bindings for TLS, IETF RFC 5929, via http://www.ietf.org/rfc/rfc5929.txt [SAML(v2.0)] S. Cantor, J. Kemp, R. Philpott and E. Maler: Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15.03.2005. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0os.pdf, 2005 [SAML-HoK] N. Klingenstein: SAML V2.0 Holder-of-Key Web Browser SSO Profile, OASIS Committee Draft 02, 05.07.2009. http://www.oasisopen.org/committees/download.php/33239/sstc-saml-holder-of-key-browsersso-cd-02.pdf, 2009 [SAML-ECP] S. Cantor & al.: SAML V2.0 Enhanced Client or Proxy Profile Version 2.0, Working Draft 02, 19.02.2011, http://www.oasisopen.org/committees/download.php/41209/sstc-saml-ecp-v2.0-wd02.pdf [SEEK4Android] F. Schäfer & al.: Secure Element Evaluation Kit for the Android platform Project, http://code.google.com/p/seek-for-android/ [Sirius-SS] A. Kühne, H. Veit & al.: Sirius Sign Server Project, http://sourceforge.net/projects/sirius-sign/ [SOAP-v1.1] W3C Note: Simple Object Access Protocol (SOAP) 1.1, 8 May 2000, via http://www.w3.org/TR/2000/NOTE-SOAP-20000508 [SpongeCastle] R. Tyley: Sponge Castle Project, https://github.com/rtyley/spongycastle [STORK] J. Alcalde-Moraño, J. L. Hernández-Ardieta, A. Johnston, D. Martinez, B. Zwattendorfer: STORK Deliverable D5.8.1b – Interface Specification, 08.09.2009, https://www.eidstork.eu/index.php?option=com_processes&Itemid=&act=streamDocument&d id=960 [T7-eCard-QES] T7 e.V.: Common PKI – Signature API, in German, http://www.t7ev.org/themen/anwendungsanbieter/common-pki-signaturapi.html

110

[VeLa+09]

[WaSt10]

[WHB+11]

[Wich11] [YZJF11]


P. Verhaeghe, J. Lapon, B. De Decker, V. Naessens and K. Verslype: Security and privacy improvements for the Belgian eID technology, 2009, Springer, Emerging Challenges for Security, Privacy and Trust vol:297 pages:237-247, 4th IFIP International Information Security Conference (SEC) edition:24 location:Pafos, Cyprus date:18-20 May 2009, ISBN: 978-3-642-01243-3, https://lirias.kuleuven.be/bitstream/123456789/215296/1/paper.pdf Z. Wang, A. Stavrou: Exploiting Smart-Phone USB Connectivity For Fun And Profit, ACSAC '10, Proceedings of the 26th Annual Computer Security Applications Conference, www.cs.gmu.edu/~astavrou/research/acsac10.pdf A. Wiesmaier, M. Horsch, J. Braun, F. Kiefer, D. Hühnlein, F. Strenzke and J. Buchmann: An efficient PACE Implementation for mobile Devices, ASIA CCS '11: 6th ACM Symposium on Information, Computer and Communications Security, vol. ACM Symposium on Information, Computer and Communications Security, p. 176-185, ACM, March 2011, https://www.cdc.informatik.tu-darmstadt.de/de/publikationsdetails/?no_cache=1&pub_id=TUD-CS-2011-0064 T. Wich: Tools for automated utilisation of Smart-Card Descriptions, Master Thesis, Hochschule Coburg, 2011 Y. Zhou, X. Zhang, X. Jiang and V. Freeh: Taming Information-Stealing Smartphone Applications (on Android), 4th International Conference on Trust and Trustworthy Computing, Pittsburgh, http://online.wsj.com/public/resources/documents/TISSA042511.pdf

Towards stateless, client-side driven Cross-Site Request Forgery protection for Web applications Sebastian Lekies, Walter Tighzert, and Martin Johns SAP Research fi[email protected] Abstract: Cross-site request forgery (CSRF) is one of the dominant threats in the Web application landscape. In this paper, we present a lightweight and stateless protection mechanism that can be added to an existing application without requiring changes to the application’s code. The key functionality of the approach, which is based on the double-submit technique, is purely implemented on the client-side. This way full coverage of client-side generation of HTTP requests is provided.

1 Introduction Cross-site Request Forgery (CSRF) is one of the dominant threats in the Web application landscape. It has been rated by the OWASP on place five in their widely regarded “Top Ten Most Critical Web Application Security Vulnerabilities” [Ope10a]. CSRF exists due to an unfortunate combination of poor design choices which have been made while evolving the Web application paradigm. The fundamental cause being the adding of transparent authentication tracking using HTTP cookies onto a stateless hypertext medium consisting of HTTP and HTML. For this reason, there is no “easy fix” for CSRF. Instead, the current practice is to selectively identify all potential vulnerable interfaces that a Web application exposes and protecting them manually within the application logic. In this paper, we present a lightweight and stateless protection mechanism which can be added to an application deployment without requiring any changes to the actual application code. Our approach reliably outfits all legitimate HTTP requests with evidence which allows the Web server to process these requests securely.

2 Technical background In this section, we briefly revisit the technical background of Web authentication tracking and how it can be misused by CSRF, before detailing the mechanism of the double-submit cookie protection.

112

2.1

Towards stateless, client-side driven Cross-Site Request Forgery protection

Web authentication tracking

The HTTP protocol is stateless. For this reason, the application itself has to provide measures to track sessions of users that span more than one request-response pair. The most common approach to do so relies on HTTP cookies: The first time a client connects to a server, the server generates a random, hard to guess number (the so-called session identifier) and sends it to the client. From now on, the client’s Web browser will attach this cookie value to all subsequent requests, allowing the server to keep track of the session. In case the Web application requires authentication, the user will enter his credentials (usually a combination of a username and a password). After validating the provided information, the server upgrades the user’s session context into an authenticated state. In consequence, the session identifier is utilized as the user’s authentication token: All further requests which carry the user’s session identifier will be regarded by the Web server as being authenticated.

2.2

CSRF

Cross-Site Request Forgery (CSRF) is an attack that consists in tricking the victim to send an authenticated HTTP request to a target Web server, e.g., via visiting a malicious page that creates such a request in the background. In cases that the user is currently in an authenticated state with the targeted Web site, the browser will automatically attach the session cookies to such requests, making the server believe that this request is a legitimate one and, thus, may cause state-changing actions on the server-side. Take for instance the attack illustrated in Fig. 1: First, the victim logs into his online bank account (www.bank.com) and doesn’t log out. Afterwards, he navigates to a site under the control of an attacker (www.attacker.org). Tricking the victim to visit this website can be done, for instance, by sending an email to the victim promising him nice cat pictures. Unfortunately, the website doesn’t contain only pictures. A GET cross-domain request to www.bank.com is made using an invisible image tag that carries a src-URL pointing to the bank’s server1 . As the user didn’t log out, the request is made in his authentication context as the browser attach the cookies to this request and the money transfer is started. The Same Origin Policy doesn’t prevent this request to be made, it only prevent the attacker to read the request’s response but the attacker is not interested in the response, only in the action that has been triggered on the server-side.

2.3

CSRF protection with double-submit cookies

The most common protection against CSRF is to restrict the state changing action requests to POST requests and the usage of a nonce. When a form is requested, the application 1 There are different possibilities to make such cross domain requests: an HTTP GET request can be embedded in an image tag whereas a POST request can be the result of a FORM created using JavaScript.


www.bank.com

113

www.attacker.org

GET transfer.cgi?am=10000&an=3422421

Cookie: auth_ok

Abbildung 1: CSRF attack generates a nonce and attach it to the form as a hidden field. When the user submits a form, the nonce is then sent back to the server, which then checks if this nonce is valid. One of the disadvantage of this protection is that the server has to manage all nonces, i.e., the server has to remember each nonce for each form, invalidate the expired one. This can under certain circumstances even lead to a Denial of Service attack, where an attacker successively requests forms, generating for each form a new nonce. With each new nonce the available memory of the server is reduced until nothing is left anymore to store legitimate data. Moreover, this protection can not be easily integrated in a legacy application without having to modify the application’s code. The double-submit cookie method as first described in [ZF08] offers a protection against CSRF that can be implemented without the need for server-side state. Thereby, the CSRF token is submitted twice. Once in the cookie and simultaneously within the actual request. As the cookie is protected by the Same-Origin Policy only same-domain scripts can access the cookie and thus write or receive the respective value. Hence, if an identical value is stored within the cookie and the form, the server side can be sure that the request was conducted by a same-domain resource. As a result, cross-domain resources are not able to create a valid requests and therefore CSRF attacks are rendered void. Nevertheless, this methods still requires some code modifications, as the token attachment needs to be conducted within the application’s code. In the next section we present a mechanism for legacy applications that makes use of the double-submit cookie technique, but without the need for code modifications. In order to do so, we implemented a library that conducts the token attachment completely on the client-side.

3 Protection approach This section is structured as follows: First we provide an outline of the general architecture of our approach (see Sec. 3.1). Then we explore our client-side framework in depth, covering the aspects of HTML-tag augmentation (Sec. 3.2), dealing with implicit HTTP request generation (Sec. 3.3), handling JavaScript-based HTTP request generation (Sec. 3.4) and covering server-side redirects (Sec. 3.5).

114


3.1

High-level overview

Our proposed protection mechanism, which is based on the double-submit cookie technique (see Sec. 2.3) consists of a client-side and a server-side component: On the server-side a proxy (in the following called gatekeeper) tracks any incoming request and validates whether the request carries a valid token according to the double-submit scheme. Additionally, the gatekeeper holds a whitelist of defined entry points for the Web application that a client is allowed to call without a valid token. Any request that does not carry a valid token and is targeted towards a non-whitelisted resource is automatically discarded by the gatekeeper2 . Besides that, the gatekeeper injects the client-side component in the form of a JavaScript library into any outgoing response by inserting an HTML script element directly into the beginning of the document’s head section. Therewith, the JavaScript library is executed before the HTML rendering takes place or before any other script runs. Its duty is to attach the CSRF token according to the double-submit scheme to any outgoing request targeted towards the server. Unlike other approaches, such as [JKK06], which rely on server-side rewriting of the delivered HTML, our rewriting method is implemented completely on the client-side. This way, we overcome server-side completeness problems (see Sec. 4.2 for details). Within a browser multiple different techniques can be leveraged to create state changing HTTP requests. Each of these mechanisms has to ensure that CSRF tokens are attached to valid requests. Otherwise a valid request would be discarded by the gatekeeper (as it does not carry a valid token). Hence, the client-side component needs to implement such a token attachment mechanism for any of these techniques. In general we are, thereby, able to distinguish between 4 different possibilities to create valid HTTP requests: 1. Requests that are caused by a user interacting with DOM elements (e.g. ’a’ tags or ’form’ elements) 2. Requests that are implicitly generated by HTML tags (e.g. frames, img, script, link tags) 3. Requests that are created by JavaScript’s XMLHttpRequest 4. Redirects triggered by the server

3.2

Requests caused by a user interacting with DOM elements

Traditionally, requests within a Web browser are caused by user interaction, for example, by clicking on a link or submitting a form. Incorporating tokens into such a request is straight forward. For the case of ’a’ tags our library simply rewrites the ’href’ attribute whenever such a tag is inserted into the document3 . For form tags we can app2 Note:

Pictures, JS and CSS files are whitelisted by default Tags are only rewritten if the URLs point to the webpage’s own server, so that no foreign website is accidentally able to receive the CSRF token. 3 Note:


115

ly a similar technique, but instead of rewriting the location we register an onSubmit handler that takes care of attaching the token when a form is submitted. This technique of rewriting attributes or registering handler function is executed multiple times during the runtime of a document. Once, when the page has finished loading4 and once whenever the DOM is manipulated in some way. Such a manipulation can be caused by several different JavaScript functions and DOM attributes such as document.write, document.createElement or .innerHTML. Therefore, our library wraps all those functions and attributes by utilizing the function wrapping techniques described by Magazinius et al. [MPS10] . The wrapper functions simply call our rewrite engine whenever they are invoked i.e. whenever the DOM is manipulated. In that way the rewriting functionality is applied to the plain HTML elements that were already inserted into the page.

3.3

Implicitly generated Requests caused by HTML tags

Besides requests that are generated by the user, HTML tags are also able to create new requests implicitly. For example, if a new img, iframe, link or script tag is inserted into a document the browser immediately creates a new request. As a CSRF protection only has to protect state changing actions it is not necessary to incorporate protection tokens into img, script and link tags as these tags are not supposed to be used for any state changing activity. Therefore, the gatekeeper on the server-side won’t block any requests targeted towards pictures, script- or CSS-files not carrying a protection token. Frames, however, could potentially be used to trigger actions in the name of the user, hence, CSRF tokens have to be incorporated into it somehow. But as the browser fires the corresponding requests implicitly our JavaScript library is not able to do a rewriting of the location as described in the previous section (the request is already sent out when our rewriting engine is triggered). One way of overcoming this problem would be to parse the content given to DOM manipulating functions and rewriting iframe tags before inserting them into the page. This, however, has two major drawbacks. On one hand parsing is prone to errors and implies a lot of performance overhead and on the other hand we cannot parse the content during the initial loading of the Web page as this is completely done by the browser and not by JavaScript functions. Therefore, we would not be able to incorporate CSRF tokens into iframes that are initially available within an HTML document. Hence we need to utilize a different method to overcome this problem. Figure 2 shows the general setup of our framing approach. Whenever a request towards a protected resource arrives without a valid token (1), the gatekeeper responds with a 200 HTTP status code and delivers a piece of JavaScript code back to the client (2). The code which is seen in Listing 1 exploits the properties guaranteed by the Same-Origin Policy in order to detect whether a request was valid or not. The Same-Origin Policy allows scripting access from one frame to another frame only if both frames run on the same domain. So if the framed page has access to DOM properties of its parent window it can ensure that the website in the parent window runs on the same domain. As a CSRF attack is always conducted across domain boundaries, a request that is conducted cross-domain 4 at

the onload event

116


Browser

hGp://a.net 3.) Validate Framing

1.) Ini"al Request 2.) Framing Code

IFrame

Proxy

4.) Request with Token 5.) Response

hGp://a.net

Abbildung 2: Framing Solution is very suspicious while a request from the same domain is not suspicious at all. A valid request is thus caused by a frame that is contained in a page that relies on the same domain while an illegitimate request is caused by a frame that is contained on a page running on a different domain. Therewith our Script is able to validate the legitimacy of the request by accessing the location.host DOM property of its parent window (3). If it is able to access it (and thus it is running on the same domain), it receives the CSRF token from the cookie and triggers a reload of the page, but this time with the token incorporated into the request. The gatekeeper will recognize the valid token and instead of sending out our script again it will forward the request to the protected resource (4) that answers with the desired response (5). Listing 1 Frameing code (function () { "use strict"; try { if (parent.location.host === window.location.host) { var token = getCookie("CSRFToken"); var redirectLoc = attachToken(window.location, token); window.location = redirectLoc; } } catch (err) { console.log(err); //parent.location.host was not accessible } })();

3.4

Requests created by JavaScript’s XMLHttpRequest

Besides generating requests by inserting HTML elements, JavaScript is also able to initiate HTTP requests directly by utilizing the XMLHttpRequest object. Most of the modern JavaScript-based application, such as GMail, make use of this technique in order


117

to communicate asynchronously with a server. Incorporating tokens into this techniques is very easy. Our library simply wraps the XMLHttpRequest Object and is thus able to fully control any request send via this object (See Listing 2 for a code excerpt). Whenever the wrapper is supposed to send a requests towards the protected server the token is inserted as a GET parameter for GET requests or as a POST parameter for post requests. Therewith, protecting modern AJAX applications is very easy. Listing 2 XMLHttpWrapper (Excerpt) (function () { "use strict"; var OriginalXMLHttpRequest = window.XMLHttpRequest; function XHR() { this.originalXHR = new OriginalXMLHttpRequest();

}

//define getter and setter for variables Object.defineProperty(this, "readyState", { get: function () { return this.originalXHR.readyState; }, set: function (val) { this.originalXHR.readyState = val; } }); [...]

XHR.prototype.open = function (method, url, async, user, password) { var token = getCookie("CSRFToken"); this.attachToken(method, url, token); this.originalXHR.open(method, url, async, user, password); }; [...] function NewXMLHttpRequest() { return new XHR(); } window.XMLHttpRequest = NewXMLHttpRequest; })();

3.5

Redirects triggered by the server

As the application is not aware of the CSRF protection mechanism, it is possible that the application triggers a redirect from one protected resource towards another via 3xx HTTP redirects. In some cases this will cut of the CSRF tokens as the application will not generically attach each received parameter to the new redirect location. Hence, the serverside proxy has to take over this task. Whenever a redirect takes place a server responds with a 3xx status code and the location response header that defines the location to which the client is supposed to redirect. Therefore, the gatekeeper monitors the HTTP status codes for responses to requests that carry valid tokens. If the response contains a

118


3XX status code, the gatekeeper rewrites the location header field and includes the token into it.

4 Discussion 4.1

Assessing security coverage and functional aspects

To assess the protection coverage of the approach, we have to verify if the proposed approach indeed provides the targeted security properties. For this purpose, we rely on previous work: Our protection approach enforces the model introduced by Kerschbaum in [Ker07]: Only clearly white-listed URLs are allowed to pass the gatekeeper without providing proof that the corresponding HTTP request was generated in the context of interacting with the Web application (for this proof we rely on the double-submit value, while [Ker07] utilizes the referer-header, which has been shown by [BJM09] to be insufficient). Using the model checker Alloy, [Ker07] provides a formal verification of the security properties of the general approach. In consequence, this reasoning also applies for our technique.

4.2

The advantage of client-side augmentation

As mentioned before, in our approach the altering of the site’s HTML elements is done purely on client-side within the browser. This has significant advantages over doing so on the server-side both in respect to completeness as well as to performance. To do this step on the server-side, the filter of the outgoing HTTP responses would have to completely parse the response’s HTML content to find all hyperlinks, forms, and other relevant HTML elements. Already this step is in danger of being incorrect, as the various browser engines might interpret the encountered HTML differently from the utilized server-side parsing engine. In addition, and much more serious, are the shortcomings of the server-side when it comes to JavaScript: In modern Web applications large parts of the displayed HTML UI are generated dynamically. Some Web2.0 applications do not transmit HTML at all. Such HTML elements are out of reach for server-side code and cannot be outfitted with the protection value. In contrast, on the client-side the JavaScript component already works directly on the DOM object, hence, no separate parsing step is necessary. And, as described in Section 3, our technique is capable to handle dynamic HTML generation via function wrapping.

4.3

Open issues

Direct assignment of window.location via JavaScript: Besides the techniques presented in Section 3, there is one additional way to create HTTP requests within the browser.


119

By assigning a URI to either window.location, document.location or self. location a piece of JavaScript can cause the browser to redirect to the assigned URI. To control these requests it would again be possible to wrap these three location attributes with function wrappers in order to attach the token whenever something is assigned to the .location attribute. Due to security reasons, however, some browsers do not allow the manipulation of the underlying getters and setters of window.location or document.location5 . Hence, the function wrapping technique cannot be applied to those attributes. Although, there are some ways to overcome this obstacle, we are not aware of an approach that covers the whole browser spectrum. Therefore, our library is not able to cover redirects via window.location/document.location. As a result these requests will not carry a CSRF token and thus they will be discarded by the gatekeeper. Hence, applications that are using .location for redirects are not yet supported by our library. In a later version we plan to include a work around for this problem. RIA elements: Plugin-based RIA applets such as Flash, Silverlight or Java applets are also able to create HTTP requests within the user’s browser. In order to function with our CSRF protection these applets need to attach the CSRF token to their requests. Basically, this can be achieved in two different ways. On the one hand these applets could make use of JavaScript’s XMLHttpRequest object. As this object is wrapped by our function wrapper, tokens will automatically be attached to legitimate requests. However, if an applet uses a native way to create HTTP requests, our JavaScript approach is not able to augment the request with our token. Therefore, such RIA elements have to build a custom mechanism to attach our token.

4.4

Server-side requirements and supporting legacy applications

The proposed approach has only very limited footprint on the server-side. It can be implemented via a lightweight HTTP request filtering mechanism, which is supported by all major Web technologies, such as J2EE or PHP. If no such mechanism is offerd by the utilized framework, the component can also be implemented in the form of a self-standing server-side HTTP proxy. As explained in Section 3, the component itself needs no back channel into the application logic and is completely stateless, due to choosing the double-submit cookie approach. In consequence, the proposed approach is well suited to add full CSRF protection to existing, potentially vulnerable applications retroactively. To do so, only two application specific steps have to be taken: For one, potential direct access to the JavaScript location object have to be identified and directed to the proxy object (see Sec. 4.3). Secondly, fitting configuration files have to provided, to whitelist the well-defined entry points into the application and the URL paths for the static image and JavaScript data. 5 Firefox still allows the manipulation of window.location, while other browsers do not allow it. On the other hand Safari allows the overwriting of document.location, while other browsers don’t

120


5 Related work In the past, the field of CSRF-protection has been addressed from two distinct angles: The application (i.e. the server-side) and the user (i.e., the client-side). Server-side: Server-side protection measures, such as this paper’s approach, aim to secure vulnerable applications directly. The most common defense against CSRF attacks is manual protection via using request nonces, as mentioned in Sec. 2.2. [Ope10b] provides a good overview on the general approach and implementation strategies. In [JKK06] a server-side mechanism is proposed, that automatically outfits the delivered HTML content with protection nonces via server-side filtering. Due to the purely server-side technique, the approach is unable to handle dynamically generated HTML content and direct JavaScriptbased HTTP requests. As an alternative to checking protection nonces, [BJM09] proposes the introduction of an origin-HTTP header. This header carries the domain-value of the URL of the Web side from which the request was created. Through checking the value the application can ensure, that the received request was created in a legitimate context and not through an attacker controlled Web site. Up to this date, browser support of the origin-header is incomplete, hence, rendering this mechanism unsuitable for general purpose Web sites. Client-side: In addition to the server-centric protection approach, several client-side techniques have been proposed, which provide protection to the user’s of Web applications, even in cases in which the operator of the vulnerable Web application fails to identify or correct potential CSRF vulnerabilities. RequestRodeo [JW06] achieves this protection via identifying cross-domain requests and subsequent removal of cookie values from these requests. This way, it is ensured that such request are not interpreted on the server-side in an authenticated context. CSFire [RDJP11] improves on RequestRodeo’s technique on several levels: For one the mechanism is integrated directly into the browser in form of a browser extension. Furthermore, CSFire utilizes a sophisticated heuristic to identify legitimate cross-domain requests which are allowed to carry authentication credentials. This way support for federated identity management or cross-domain payment processes is granted. Furthermore, related client-side protection mechanism were proposed by [ZF08] and [Sam11]. Finally, the ABE component of the Firefox extension NoScript [Mao06] can be configured on a per-site basis to provide RequestRodeo-like protection.

6 Conclusion In this paper we presented a light-weight transparent CSRF-protection mechanism. Our approach can be introduced without requiring any changes of the application code, as the server-side component is implemented as a reverse HTTP proxy and the client-side component consists of a single static JavaScript file, which is added to outgoing HTMLcontent by the proxy. The proposed technique provides full protection for all incoming HTTP requests and is well suited to handle sophisticated client-side functionality, such as AJAX-calls or dynamic DOM manipulation.


121

Literatur [BJM09] Adam Barth, Collin Jackson und John C. Mitchell. Robust Defenses for Cross-Site Request Forgery. In CCS’09, 2009. [JKK06] Nenad Jovanovic, Christopher Kruegel und Engin Kirda. Preventing cross site request forgery attacks. In Proceedings of the IEEE International Conference on Security and Privacy for Emerging Areas in Communication Networks (Securecomm 2006), 2006. [JW06]

Martin Johns und Justus Winter. RequestRodeo: Client Side Protection against Session Riding. In Frank Piessens, Hrsg., Proceedings of the OWASP Europe 2006 Conference, refereed papers track, Report CW448, Seiten 5 – 17. Departement Computerwetenschappen, Katholieke Universiteit Leuven, May 2006.

[Ker07]

Florian Kerschbaum. Simple Cross-Site Attack Prevention. In Proceedings of the 3rd International Conference on Security and Privacy in Communication Networks (SecureComm’07), 2007.

[Mao06] Giorgio Maone. NoScript Firefox Extension. [software], http://www.noscript. net/whats, 2006. [MPS10] Jonas Magazinius, Phu H. Phung und David Sands. Safe Wrappers and Sane Policies for Self-Protecting JavaScript. In Tuomas Aura, Hrsg., The 15th Nordic Conference in Secure IT Systems, LNCS. Springer Verlag, October 2010. (Selected papers from AppSec 2010). [Ope10a] Open Web Application Project (OWASP). OWASP Top 10 for 2010 (The Top Ten Most Critical Web Application Security Vulnerabilities). [online], http://www.owasp. org/index.php/Category:OWASP_Top_Ten_Project, 2010. [Ope10b] Open Web Application Security Project. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. [online], https://www.owasp.org/index.php/Cross-Site_ Request_Forgery_(CSRF)_Prevention_Cheat_Sheet, accessed November 2011, 2010. [RDJP11] Philippe De Ryck, Lieven Desmet, Wouter Joosen und Frank Piessens. Automatic and precise client-side protection against CSRF attacks. In European Symposium on Research in Computer Security (ESORICS 2011), Jgg. 6879 of LNCS, Seiten 100–116, September 2011. [Sam11] Justin Samuel. Requestpolicy 0.5.20. [software], http://www.requestpolicy. com, 2011. [ZF08]

William Zeller und Edward W. Felten. Cross-Site Request Forgeries: Exploitation and Prevention. Bericht, Princeton University, 2008.

¨ gMix: Eine generische Architektur fur Mix-Implementierungen und ihre Umsetzung als Open-Source-Framework Karl-Peter Fuchs, Dominik Herrmann, Hannes Federrath Universität Hamburg, Fachbereich Informatik Vogt-Kölln-Straße 30, D-22527 Hamburg {fuchs, herrmann, federrath}@informatik.uni-hamburg.de Abstract: Mit dem Open-Source-Projekt gMix, einem generischen Framework für Mixe, möchten wir die zukünftige Forschung im Bereich der Datenschutzfreundlichen Techniken fördern, indem wir die Entwicklung und Evaluation von Mix-basierten Systemen erleichtern. Das Projekt gMix wird ein umfassendes Code-Repository mit kompatiblen und leicht erweiterbaren Mix-Implementierungen zur Verfügung stellen. Dies ermöglicht den Vergleich verschiedener Mix-Varianten unter einheitlichen Bedingungen und unterstützt durch leicht zugängliche und verständliche Lösungen auch den Einsatz in der Lehre. Wir stellen eine generische Softwarearchitektur für MixImplementierungen vor, demonstrieren ihre Anwendbarkeit anhand einer konkreten Implementierung und legen dar, wie wir die Architektur in ein Software-Framework mit einem Plug-in-Mechanismus zur einfachen Komposition und parallelen Entwicklung von Implementierungen u¨ berführen wollen.

1 Einleitung Mixe ermöglichen die anonyme Kommunikation in Vermittlungsnetzen. Das Grundprinzip ist in Abbildung 1 am Beispiel einer sog. Mix-Kaskade dargestellt. Seit dem ursprünglichen Vorschlag von David Chaum im Jahr 1981 [Cha81] wurden zahlreiche MixKonzepte und -Strategien vorgestellt. Inzwischen wurden Mixe für verschiedene Anwendungsgebiete, z. B. E-Mail [Cha81, Cot95], elektronische Wahlen [Cha81, PIK94, SK95], Location-Based-Services [FJP96] sowie für die Kommunikation mit Echtzeitanforderungen (z. B. ISDN [PPW91], WWW [BFK01, DMS04], DNS [FFHP11]) vorgeschlagen. In der Praxis haben sich neben den Systemen Mixmaster [Cot95] und Mixminion [DDM03], die den anonymen E-Mail-Versand ermöglichen, bislang lediglich die Anonymisierungssysteme Tor [DMS04], JAP (JonDonym) [BFK01] und I2P etabliert.1 Durch ihre konstante Fortentwicklung haben diese Implementierungen eine so hohe Komplexität und Spezialisierung auf ihren Anwendungsfall erreicht, dass die wesentlichen Grundfunk1 Die Implementierungen dieser Systeme sind u ¨ ber die jeweiligen Webseiten unter http://sourceforge.net/ projects/mixmaster/, http://mixminion.net/, http://www.torproject.org, http://anon.inf.tu-dresden.de/ und http: //www.i2p2.de abrufbar.

124

gMix: Eine Architektur für Mix-Implementierungen und ihre Umsetzung

Nutzer

Client

Server Mix 1

Nutzer

Mix 2

Client

Server

Abbildung 1: Nachrichten werden vom Client schichtweise verschlüsselt. Die Mixe entschlüsseln die Nachricht schrittweise auf dem Weg zum Empfänger. Weitere Details werden in Abschnitt 2 erläutert.

tionen eines Mixes nicht mehr leicht nachvollziehbar sind und ihre Eignung als Ausgangspunkt für die Entwicklung neuer Systeme (z. B. für andere Anwendungsfälle) beschränkt ist. Der JAP-Client besteht beispielsweise derzeit (Dezember 2011) aus u¨ ber 700 JavaKlassen.2 In der Theorie gibt es eine Vielzahl an Vorschlägen, für die keine o¨ ffentlich verfügbaren oder gar praktisch einsetzbaren Implementierungen existieren (z. B. [PPW91, DG09, KG10, KEB98, DS03a, Ser07, SDS02, DP04, DS03b] oder [WMS08]). Von diesen Vorschlägen bleibt nur eine verbale oder formale Beschreibung in der jeweiligen akademischen Publikation. Diese Situation hat drei Konsequenzen: Zum einen wird es Wissenschaftlern unnötig schwer gemacht, bereits publizierte Ergebnisse nachzuvollziehen, da die existierenden Techniken dazu von Grund auf neu implementiert werden müssen. Zweitens ist die Hürde zur Implementierung neuer Mix-Techniken unnötig hoch, da immer wieder von neuem Lösungen für Standardprobleme gefunden und implementiert werden müssen. Und drittens ist es zum aktuellen Zeitpunkt relativ schwierig, die Vorschläge aus unterschiedlichen Veröffentlichungen miteinander zu vergleichen, da diese mit unterschiedlichen Implementierungen, Laufzeitumgebungen und Experimentierumgebungen realisiert wurden. Mit dem gMix-Projekt möchten wir dazu beitragen, diese aus unserer Sicht unerwünschten Konsequenzen zu beheben. Wir verfolgen dabei fünf Ziele: 1. Verfügbarkeit eines umfassenden Code-Repository mit kompatiblen, leicht erweiterbaren Mix-Implementierungen, 2. Vereinfachen der Entwicklung neuer, praktisch nutzbarer Mixe, 3. Evaluation existierender und neuer Mix-Techniken unter einheitlichen Bedingungen, 4. Unterstützung der Lehre durch leicht zugängliche und verständliche Mix-Lösungen sowie 5. Wissenschaftler dazu zu motivieren, ihre Implementierungen auf Basis von gMix zu entwickeln und somit an der Weiterentwicklung von gMix beizutragen. Aus diesem Grund haben wir eine offene, generische Architektur entworfen, mit der existierende und zukünftige Mixe abgebildet werden können. Die Architektur bildet die 2 Gez¨ ahlt

wurden alle Klassen, die unter http://anon.inf.tu-dresden.de/develop/doc/jap/ aufgeführt sind.


125

gemeinsamen Komponenten ab, die für die Entwicklung praktischer Mix-Implementierungen grundsätzlich erforderlich sind. Weiterhin gibt sie den Rahmen für das Verhalten und die Interaktion der Komponenten vor. Basierend auf dieser Architektur haben wir damit begonnen, ein Framework mit einem Plug-in-Mechanismus zu erstellen, das die Auswahl verschiedener Implementierungen einzelner Komponenten (z. B. verschiedene Ausgabestrategien) erlaubt.3 Das Framework soll es einem Entwickler ermöglichen, einen konkreten Mix aus den verschiedenen Implementierungen zusammenzustellen, ohne den Quelltext des Frameworks anpassen zu müssen. Wir sehen dies als Voraussetzung dafür, verschiedene Implementierungen einfach und unter einheitlichen Bedingungen (z. B. wie in [FFHP11] mit einem Netzwerkemulator oder in einem Forschungsnetzwerk wie dem PlanetLab (http://www.planet-lab.org/) in [BSMG11]) testen zu können, sowie die Abhängigkeiten bei der parallelen Entwicklung verschiedener Implementierungen durch die Open-Source-Community zu minimieren. Neben dem Framework erstellen wir derzeit Referenzimplementierungen für die bedeutendsten Mix-Techniken. Das gMix-Projekt ist im Internet unter https://svs.informatik.uni-hamburg.de/gmix/ erreichbar. Die Quellcodes sind unter der GPLv3 veröffentlicht. Der Beitrag ist wie folgt aufgebaut: Im Abschnitt 2 stellen wir die gMix-Architektur vor. Anschließend erläutern wir in Abschnitt 3 anhand einer konkreten Implementierung, einem synchron getakteten Kanal-Mix für stromorientierte Kommunikation, wie die Architektur in der Praxis umgesetzt werden kann. Ausgehend von der Architektur und der konkreten Implementierung wird in Abschnitt 4 der geplante Aufbau des gMix-Frameworks skizziert. Abschnitt 5 fasst schließlich die Ergebnisse zusammen.

2 gMix-Architektur Wir verstehen unter einer Softwarearchitektur analog zu [Bal96], eine strukturierte oder ” hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Eine detaillierte Beschreibung der verschiedenen Architekturebenen und Sichten (Kontextsicht, Struktursicht, Verhaltenssicht, Abbildungssicht) der gMix-Architektur findet sich in [Fuc09]. Im Folgenden beschränken wir uns auf eine allgemeine Beschreibung der Architekturkomponenten und deren grundlegender Interaktion. Weiterhin legen wir die zentralen Designentscheidungen dar. 3 In

einem anderen Forschungsgebiet, dem Data-Mining, hat sich die Veröffentlichung eines Frameworks als großer Erfolg herausgestellt. Das Software-Paket WEKA [HFH+ 09] (http://www.cs.waikato.ac.nz/ml/weka/ index.html), das vor fast 20 Jahren veröffentlicht wurde, bietet Zugriff auf eine Vielzahl von Algorithmen und Evaluationstechniken. Es hat die Nutzung von State-of-the-Art-Data-Mining-Techniken erheblich vereinfacht und dazu geführt, dass diese ganz selbstverständlich heute in vielen Anwendungsfeldern eingesetzt werden. Wegen seiner Einfachheit wird WEKA inzwischen auch an vielen Universitäten im Lehrbetrieb eingesetzt.

126

2.1


Herausforderungen

Die wesentliche Herausforderung bei der Entwicklung einer generischen Architektur für Mix-basierte Systeme besteht darin, diese einerseits generisch genug zu spezifizieren, so dass eine Vielzahl von Mix-Varianten unterstützt wird, sie andererseits aber auch so spezifisch wie möglich zu entwerfen. Hierzu werden die wesentlichen Aufgaben eines Mixes sowie die für eine praktisch nutzbare Implementierung nötigen zusätzlichen und wiederverwendbaren Artefakte (z. B. Serverfunktionalität oder Logging) identifiziert, voneinander abgegrenzt und in Komponenten gekapselt. Dementsprechend haben wir eine Vielzahl der bislang vorgeschlagenen Mix-Konzepte (insbesondere verschiedene Ausgabe- und Dummy-Traffic-Strategien sowie Umkodierungsschemata) und drei o¨ ffentlich verfügbare Implementierungen (Tor, JAP, Mixminion) analysiert. Der Architekturentwurf wurde zusätzlich von der prototypischen Implementierung verschiedener Mix-Komponenten, darunter auch der in Abschnitt 3 beschriebene Mix sowie der von uns in [FFHP11] vorgestellte DNS-Mix, begleitet und iterativ weiterentwickelt. Die gMix-Architektur ermöglicht die parallele bidirektionale anonyme Kommunikation (Vollduplex), für nachrichtenorientierte Anwendungen (z. B. E-Mail) sowie für Datenströme mit Echtzeitanforderungen (Möglichkeit zur Schaltung langlebiger anonymer Kanäle, z. B. für WWW-Traffic), unabhängig von der konkreten Realisierung des zugrundeliegenden Kommunikationskanals, des zur Anonymisierung verwendeten Umkodierungsschemas oder der Ausgabestrategie.

2.2

Komponenten

Die wesentlichen Softwarekomponenten sind in Abbildung 2 dargestellt und werden im Folgenden kurz skizziert. Die Komponenten MessageProcessor, OutputStrategy und InputOutputHandler sind für die Kernfunktion des Mixes (Unverkettbarkeit ein- und ausgehender Nachrichten) zuständig. Die restlichen Komponenten nehmen Hilfsaufgaben wahr. Die Komponente MessageProcessor setzt das Umkodierungsschema des Mixes um. Dieses soll sicherstellen, dass ein- und ausgehende Nachrichten nicht anhand ihrer Bitrepräsentation verkettet werden können. Aufgaben der Komponente sind folglich das Ver- bzw. Entschlüsseln von Mix-Nachrichten sowie die Durchführung einer Integritätsprüfung4 und Wiederholungserkennung5 . Für den Entwurf der Komponente wurden die Verfahren nach [Cha81, PPW91, Cot95, DDM03, BFK01, Köp06] und [DMS04] analysiert. Die aktuelle Implementierung ist in Abschnitt 3 beschrieben. Derzeit wird das 4 K¨ onnen Nachrichten vom Mix unbemerkt verändert werden, kann die Anonymität der Nutzer aufgehoben werden [Dai00]. 5 Wird ein deterministisches Umkodierungsschema eingesetzt, darf jede Nachricht vom Mix nur ein einziges Mal verarbeitet werden. In diesem Fall muss der Mix wiedereingespielte Nachrichten erkennen und verwerfen, wie beispielsweise in [Köp06] beschrieben.


127

MixTrafficPort

Mix

:InputOutput-‐ Handler Mix-‐ External-‐ Informa/on-‐ Port

:Message-‐ Processor

:KeyGenerator

:OutputStrategy

:External-‐ Informa;onPort

:Framework

:UserDatabase

:NetworkClock

Abbildung 2: Komponentendiagramm

Umkodierungsschema nach [DG09] integriert. Umkodierte Nachrichten werden vom MessageProcessor an die Komponente OutputStrategy weitergeleitet, die für die Umsetzung der Ausgabestrategie zuständig ist. Ihre Aufgabe ist es, durch das gezielte Verzögern und die umsortierte Ausgabe eingehender Nachrichten eine Anonymitätsgruppe zu bilden. Ist vorgesehen, dass unter bestimmten Bedingungen bedeutungslose Nachrichten erzeugt oder verworfen werden (Dummy-Traffic-Schema), muss dies ebenfalls in dieser Komponente erfolgen. Realisierungsmöglichkeiten für die Ausgabestrategie und das Dummy-Traffic-Schema sind u. a. in [Cha81, PPW91, Cot95, KEB98, SDS02, DS03b, DP04, Ser07, BL02, DS03a, VHT08, VT08] und [WMS08] beschrieben. Durch die Komponente OutputStrategy verzögerte Nachrichten werden an den InputOutputHandler weitergeleitet. Dieser abstrahiert von den Details des zugrundeliegenden Kommunikationskanals (z. B. einer TCP-Verbindung) und leitet die Nachrichten an die vorgesehenen Empfänger (z. B. andere Mixe oder Server) weiter. Zusätzlich stellt der InputOutputHandler mittels einer Schnittstelle u¨ ber den Kommunikationskanal empfan¨ gene Nachrichten für den MessageProcessor bereit. Die Ubergabe von Nachrichten an den InputOutputHandler erfolgt asynchron, das Beziehen von Nachrichten mittels eines Benachrichtigungsprinzips (wait-notify). Entsprechend können InputOutputHandler, MessageProcessor und OutputStrategy, abgesehen von der Nachrichtenübergabe, unabhängig voneinander arbeiten. Im Ergebnis können parallel zur Umkodierung weitere Nachrichten empfangen oder versendet werden. Das Umkodieren selbst kann ebenfalls parallelisiert werden.

128


Im Folgenden wird jeweils kurz auf die Hilfskomponenten UserDatabase, ExternalInformationPort, KeyGenerator, NetworkClock und Framework eingegangen. Die UserDatabase ermöglicht das Speichern von Daten zu einzelnen Nutzern (z. B. verbundene Clients) des Mixes. Dies umfasst beispielsweise Daten zu geschalteten anonymen Kanälen, wie Kanalkennzeichen [PPW91] und Sitzungsschlüssel. Im einfachsten Fall kann die Realisierung mit einer Hashtabelle erfolgen. ¨ Uber den ExternalInformationPort können allgemeine Informationen u¨ ber den Mix veröffentlicht werden, z. B. dessen Public Key, seine unterstützten Protokolle und eine Versionsnummer. Im Falle von JAP würde diese Komponente mit dem InfoService [BFK01] kommunizieren. Der KeyGenerator kann zum Erstellen von kryptographischen Sitzungs- oder Langzeitschlüsseln verwendet werden. Da für einige Mix-Verfahren Zeitstempel benötigt werden, kann u¨ ber die Komponente NetworkClock eine synchronisierte Uhr (z. B. u¨ ber das Network Time Protocol nach RFC 5905) realisiert werden. Neben grundlegenden Funktionen, wie dem Erstellen von Logdateien und dem Laden von Konfigurationsdateien sind in der Komponente Framework weitere Funktionen gekapselt. Eine detaillierte Betrachtung erfolgt in Abschnitt 4.

2.3

Grenzen der Generalisierung

Einschränkungen bei der Generalisierung ergeben sich hinsichtlich des Detaillierungsgrades bei der Spezifikation für bestimmte Datenstrukturen und Nachrichtenformate. Das grundlegende Problem ist, dass sich konkrete Implementierungsmöglichkeiten im Detail stark unterscheiden können. Dies macht eine Vereinheitlichung schwer oder gar unmöglich. Betroffen sind das Nachrichtenformat sowie die Inhalte der UserDatabase und des ExternalInformationPort. Ein SG-Mix [KEB98] benötigt beispielsweise exklusiv ein in das Nachrichtenformat integriertes Zeitfenster, um den Ausgabezeitpunkt von Nachrichten einzugrenzen. Sind der Aufbau eines anonymen Kanals und die eigentliche Nachrichtenübermittlung wie in [PPW91, DMS04] oder [KG10] getrennt, müssen zusätzlich Informationen wie Kanalkennzeichen und Sitzungsschlüssel (in der UserDatabase) gespeichert werden. Kommt ein Umkodierungsschema wie in [Cha81, DDM03] oder [DG09] zum Einsatz, kann hingegen jeder Schlüssel sofort nach dem Umkodieren der zugehörigen Nachricht (hybrides Kryptosystem) verworfen werden. Eine weitere Konkretisierung der Architektur lässt sich mit dem Ziel, die Architektur so generell wie möglich zu gestalten, nicht vereinbaren. Um dieses Problem zu lösen, verwenden wir abstrakte Datentypen, die nach dem Key-Value-Prinzip arbeiten. Konkrete Werte und Schlüssel werden u¨ ber eine Enumeration spezifiziert. Entsprechend kann für konkrete Implementierungen einer Komponente angegeben werden, welche Werte sie benötigt, d. h. mit welchen Enumerations sie kompatibel ist. Da die Enumeration nur eine abstrakte Beschreibung benötigter Inhalte ist, kann die konkrete Realisierung unterschiedlich erfolgen. Die Spezifizierung von Abhängigkeiten und das Auflösen von Konflikten sind eine der wesentlichen Aufgaben des Frameworks (vgl. Abschnitt 4).


129

3 Fallstudie: Implementierung eines synchron getakteten Mixes Wir stellen in diesem Abschnitt vor, wie der abstrakte Architekturentwurf in einer konkreten Implementierung, einem synchron getakteten Kanal-Mix (d. h. einen Schub-Mix mit konstantem Dummy Traffic aller Teilnehmer) umgesetzt werden kann. Mit dem Mix ¨ können duplexfähige anonyme Kanäle zur Ubermittlung von Binärdaten geschaltet werden. Von den zu u¨ bermittelnden Daten selbst und den in diesen Zusammenhang verwendetet Protokollen wird abstrahiert, um die Implementierung möglichst generisch zu halten. Dieser Mix besitzt einen hohen Komplexitätsgrad in allen Komponenten (Echtzeitanforderung, verschiedene Nachrichtentypen, Anonymisierung von Datenströmen statt nur Einzelnachrichten). Es gibt unseres Wissens nach noch keine entsprechende Open-SourceImplementierung.

3.1

Umsetzungsdetails

Als Programmiersprache wird wegen seiner Plattformunabhängigkeit und weiten Verbreitung im wissenschaftlichen Bereich und Lehrbetrieb Java eingesetzt. Auf Clientseite kann die Implementierung wie ein normaler Socket mittels InputStream und OutputStream angesprochen werden. Entsprechend ist die Tunnelung anderer Protokolle, z. B. mittels eines HTTP- oder SOCKS-Proxies, sehr einfach realisierbar. Unsere Implementierung setzt in der Komponente MessageProcessor ein zu JAP und den ISDN-Mixen [PPW91] sehr a¨ hnliches Umkodierungsschema um: Nachrichten werden hybrid mit RSA (OAEP-Modus, 2048 bit Schlüssellänge) und AES (OFB-Modus, 128 bit Schlüssellänge) verschlüsselt. Es gibt drei Nachrichtentypen. Kanalaufbaunachrichten zum Schalten anonymer Kanäle (Verteilung der Sitzungsschlüssel für AES und Integritätsprüfung mit HMAC-SHA256). Rein symmetrisch verschlüsselte Kanalnachrich¨ ten zum Ubermitteln von Nutzdaten und Kanalabbaunachrichten zum Auflösen anonymer Kanäle. Zusätzlich wurde eine Wiederholungserkennung nach dem Vorbild von [Köp06] implementiert. Zum parallelen Umkodieren können mehrere Threads gestartet werden. Die Komponente OutputStrategy wurde als synchroner Schub-Mix implementiert. Entsprechend wird von jedem Teilnehmer eine Kanalnachricht (ggf. eine Dummy-Nachricht) erwartet, bevor die Nachrichten gemeinsam und umsortiert ausgegeben werden. Zusätzlich kann eine maximale Wartezeit angegeben werden. Der InputOutputHandler setzt das in Abschnitt 2 beschriebene asynchrone Benachrichtigungsprinzip in einer Steuerungsklasse um. Die Steuerungsklasse kann mittels verschiedener ConnectionHandler an konkrete Protokolle (z. B. TCP oder UDP) und Kommunikationsbeziehungen (z. B. Client-Mix, oder Mix-Mix) angepasst werden. Die aktuelle Implementierung setzt aus Performanzgründen zwischen Mixen und Clients asynchrone Ein- und Ausgabe (non-blocking I/O) ein. Zwischen zwei Mixen besteht jeweils nur eine verschlüsselte Verbindung, durch welche die Nachrichten aller Clients getunnelt werden (multiplexing). Es kommt jeweils TCP zum Einsatz.

130

3.2


Entwicklungs- und Evaluationsumgebung

Verteilte Systeme wie Mixe sind mit herkömmlichen Debugging-Werkzeugen nicht vollständig analysierbar, da Nachrichten im Betrieb mehrere Systeme durchlaufen. Wir haben eine einfache Testumgebung entwickelt, die die Fehlersuche erheblich erleichtern kann (Paket testEnvironment). Neben der Möglichkeit, die Mixe unter realen Bedingungen, also auf mehreren Systemen verteilt, manuell zu starten, besteht auch die Option, mehrere Mixe lokal auf einem Entwicklungssystem automatisiert zu starten, ohne sich um Kommunikationseinstellungen und die Schlüsselverteilung kümmern zu müssen. Nachrichten können mit einer eindeutigen ID ausgezeichnet werden, um sie beim Debugging u¨ ber Systemgrenzen hinweg zu verfolgen. So kann u¨ berprüft werden, ob die Nachrichtenübermittlung zwischen Clients und Mixen fehlerfrei funktioniert. Weiterhin existiert ein einfacher Last-Generator, der automatisiert nach einer vorgegebenen Zufallsverteilung Mix-Clients instanziiert und deren Verhalten simuliert. Dies ermöglicht es dem Entwickler, das Verhalten der Mixe mit dynamischen Nutzerzahlen und wechselndem Verkehrsaufkommen zu analysieren. Die aktuelle Implementierung ist auf das Debugging ausgerichtet und hat die Implementierung des synchron getakteten Mixes erheblich erleichtert. Wir arbeiten an einer Erweiterung, die realistische Verkehrsmodelle unterstützt und automatisiert die Verzögerung von Nachrichten in den einzelnen MixKomponenten erfassen und visualisieren kann. Wir versprechen uns davon die Identifizierung von Flaschenhälsen und den vereinfachten empirischen Vergleich von verschiedenen Implementierungen.

4 Erweiterung zum gMix-Framework Die in Abschnitt 2 dargestellte Architektur kann durch die Spezifizierung notwendiger Komponenten, deren Verhalten und Interaktion die Entwicklungszeit für neue praktische Mix-Systeme erheblich verkürzen. Es wäre jedoch darüber hinaus wünschenswert, u¨ ber ein umfangreiches Code-Repository mit kompatiblen Implementierungen, die einfach zu einem konkreten Mix zusammengestellt werden können, zu verfügen. Idealerweise sollte es unterschiedlichen Entwicklern möglich sein, unabhängig voneinander an verschiedenen Implementierungen zu arbeiten und diese ggf. zu veröffentlichen. Dieses Ziel soll mit Hilfe eines dedizierten Rahmenwerks erreicht werden. Das Framework trennt zwischen veränderbarem Quelltext und gleich bleibenden Strukturen. Im Framework können folglich jeweils mehrere konkrete Implementierungen für die einzelnen Komponenten erstellt und registriert werden, so lange sie den Architekturvorgaben genügen. Die Instanziierung und Steuerung (d. h. die Sicherstellung der Einhaltung des vorgesehenen Kontrollflusses) der gewählten Komponentenimplementierungen erfolgt durch das Framework. Veränderungen am Quelltext des Frameworks durch die Entwickler konkreter Implementierungen sind nicht vorgesehen. Die zentralen Herausforderungen bei der Entwicklung dieses Frameworks werden im Folgenden zusammen mit unseren geplanten Lösungsansätzen kurz dargestellt.


131

• Es wird ein Plug-in-Mechanismus benötigt, der das Einbinden konkreter Komponentenimplementierungen durch das Framework ermöglicht. • Es wird ein Mechanismus benötigt, mit dem Abhängigkeiten zwischen Komponenten und Nachrichtenformaten abgebildet und erkannt werden können. • Die einfache Komposition verschiedener Implementierungsvarianten zu einem konkreten Mix soll ohne Anpassung des Quelltextes möglich sein. • Mit Hilfe einer Versionsverwaltung für verschiedene Implementierungsvarianten soll die Nachvollziehbarkeit von durchgeführten Evaluationen verbessert werden. • Die Bereitstellung umfangreicher Dokumentation und Tutorials ist erforderlich, um die Hürde zur Nutzung des Frameworks zu senken. Der Plug-in-Mechanismus ist in Abbildung 3 dargestellt. Das Framework enthält Schnittstellendefinitionen für sämtliche (in Abschnitt 2 beschriebene) Komponenten. Zusätzlich verfügt jede Komponente u¨ ber eine sogenannte Controller-Klasse, welche die durch die jeweilige Schnittstelle spezifizierte Funktionalität nach außen (d. h. für die anderen Komponenten) zur Verfügung stellt. Intern werden Aufrufe an eine konkrete Implementierung (Komponentenimplementierung) weitergeleitet. Wie aus der Architektur hervorgeht, arbeiten die einzelnen Komponenten nicht völlig autonom, sondern sie interagieren. Jede Implementierung muss daher u¨ ber Referenzen auf die anderen Komponenten verfügen. Diese Anforderung setzen wir durch einen geeigneten objektorientierten Entwurf und ein dreiphasiges Initialisierungskonzept um. Jede Komponentenimplementierung muss von einer abstrakten Implementierungsklasse (Implementation) abgeleitet werden, welche Referenzen auf alle Komponenten enthält. Eine Komponente wird nach dem Laden ihrer Klasse durch den Aufruf ihres Konstruktors instanziiert (Phase 1). Sobald alle Klassen geladen und alle Referenzen gültig sind, wird der Beginn von Phase 2 durch Aufruf einer Initialisierungsmethode bekannt gegeben. In Phase 2 werden Vorbereitungsfunktionen für die Anonymisierung durchgeführt, z. B. können Schlüssel generiert und ausgetauscht werden, Zufallszahlen erzeugt werden oder ggf. die verteilte Netzwerkuhr initialisiert werden. Wenn alle Komponenten ihre Initialisierungsmaßnahmen abgeschlossen haben beginnt Phase 3, der eigentliche Mix-Betrieb, in dem Mix-Nachrichten entgegengenommen und verarbeitet werden. Die Zusammenstellung der konkreten Komponentenimplementierungen soll nicht im Quelltext fest verdrahtet“ werden, um Plug-ins entwickeln zu können, ohne den Quelltext ” des Frameworks anpassen zu müssen. Um diese Anforderung umzusetzen, greifen wir auf einen Klassenlader zurück, der dynamisch zur Laufzeit die konkreten Implementierungen in die Java Virtual Machine lädt. Der Klassenlader wertet Kompatibilitätsinformationen, die für jedes Plug-in erfasst werden, aus und verhindert dadurch, dass inkompatible Konfigurationen ausgeführt werden. Die Kompatibilitätsinformationen werden vom Autor des Plug-ins spezifiziert und liegen in einer Property-Datei vor. Darin können auch weitere Laufzeitparameter (z. B. die Schubgröße bei einem Batch-Mix) definiert werden. Um die Konfiguration eines Mixes zu vereinfachen, wollen wir eine grafische Oberfläche entwickeln, die eine interaktive Auswahl der zu integrierenden Komponenten erlaubt. Die-

132


se soll die Kompatibilitäts- und Konfigurationsparameter interpretieren, um den Nutzer bei der Auswahl der zueinanderpassenden Implementierungen zu unterstützen. Auf der Projektseite ist der Quelltext des ersten Prototypen des Frameworks veröffentlicht. Neben einer rudimentären Implementierung des Plug-in-Mechanismus sind bereits 14 der in [Cha81, Cot95, KEB98, SDS02, DS03b] und [WMS08] beschriebenen Ausgabestrategien implementiert. Implementierungen für die restlichen Komponenten sind in Arbeit.

Framework

Name der Komponente Schni)stelle der Komponente

Schni)stellendefini+onen aller Komponenten :Implementa-on

:Controller-‐Klasse

austauschbare Implemen+erungen Parameter Konfigura+on Kompa+bilität

:Komponenten-‐ implemen+erung :Hilfsklasse

Komposi+on der Komponenten :Klassenlader Referenzen auf alle Komponenten Logging GUI

... Abbildung 3: Plug-in-Mechanismus

5 Zusammenfassung In diesem Beitrag haben wir eine generische Mix-Architektur vorgestellt. In der Architektur werden die zentralen Funktionen, die von einer praktischen Mix-Implementierung erbracht werden müssen, in einzelnen Komponenten gekapselt. Jede Komponente erfüllt eine klar abgegrenzte Aufgabe und hat definierte Schnittstellen. Die Architektur reduziert zum einen die Komplexität für Entwickler, zum anderen ist sie die Grundlage für untereinander kompatible Implementierungsvarianten. Am Beispiel des synchron getakteten Kanalmixes wurde die grundsätzliche Anwendbarkeit beispielhaft demonstriert. Architektur und Implementierung sind o¨ ffentlich zugänglich und erweiterbar. Weiterhin wurde das geplante gMix-Framework, an dem wir derzeit arbeiten, vorgestellt. Es wird eine weitgehend unabhängige Entwicklung dedizierter Mix-Plug-ins und die Evaluation unter einheitlichen Umgebungsbedingungen ermöglichen. Wir hoffen, dass durch das gMix-Projekt nicht nur die Entwicklung Datenschutzfreundlicher Techniken vorangetrie¨ ben, sondern vor allem auch deren Uberf¨ uhrung in die Praxis begünstigt wird.


133

Literatur [Bal96]

Helmut Balzert. Lehrbuch der Software-Technik.: Software-Entwicklung. Lehrbuch der Software-Technik. Spektrum, Akad. Verl., 1996.

[BFK01]

Oliver Berthold, Hannes Federrath und Stefan Köpsell. Web MIXes: a system for anonymous and unobservable Internet access. In International workshop on Designing Privacy Enhancing Technologies: Design Issues in Anonymity and Unobservability, Seiten 115–129, New York, USA, 2001. Springer-Verlag.

[BL02]

Oliver Berthold und Heinrich Langos. Dummy Traffic against Long Term Intersection Attacks. In Roger Dingledine und Paul F. Syverson, Hrsg., Privacy Enhancing Technologies, Jgg. 2482 of Lecture Notes in Computer Science, Seiten 110–128. Springer, 2002.

[BSMG11] Kevin Bauer, Micah Sherr, Damon McCoy und Dirk Grunwald. ExperimenTor: A Testbed for Safe Realistic Tor Experimentation. In Proceedings of Workshop on Cyber Security Experimentation and Test (CSET), 2011. [Cha81]

David Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM, 24(2):84–90, 1981.

[Cot95]

Lance Cottrell. Mixmaster and remailer attacks. In http:// www.obscura.com/ loki/ remailer-essay.html, 1995.

[Dai00]

Wei Dai. Two attacks against freedom. In http:// www.weidai.com/ freedom-attacks.txt, 2000.

[DCJW04] Yves Deswarte, Frédéric Cuppens, Sushil Jajodia und Lingyu Wang, Hrsg. Information Security Management, Education and Privacy, IFIP 18th World Computer Congress, TC11 19th International Information Security Workshops, 22-27 August 2004, Toulouse, France. Kluwer, 2004. [DDM03] George Danezis, Roger Dingledine und Nick Mathewson. Mixminion: Design of a Type III Anonymous Remailer Protocol. In IEEE Symposium on Security and Privacy, Seiten 2–15. IEEE Computer Society, 2003. [DG09]

George Danezis und Ian Goldberg. Sphinx: A Compact and Provably Secure Mix Format. In IEEE Symposium on Security and Privacy, Seiten 269–282. IEEE Computer Society, 2009.

[DMS04]

Roger Dingledine, Nick Mathewson und Paul Syverson. Tor: The Second-Generation Onion Router. In In Proceedings of the 13th USENIX Security Symposium, Seiten 303– 320, 2004.

[DP04]

Claudia D´ıaz und Bart Preneel. Taxonomy of Mixes and Dummy Traffic. In Deswarte et al. [DCJW04], Seiten 215–230.

[DS03a]

George Danezis und Len Sassaman. Heartbeat traffic to counter (n-1) attacks: red-greenblack mixes. In Sushil Jajodia, Pierangela Samarati und Paul F. Syverson, Hrsg., WPES, Seiten 89–93. ACM, 2003.

[DS03b]

Claudia D´ıaz und Andrei Serjantov. Generalising Mixes. In Roger Dingledine, Hrsg., Privacy Enhancing Technologies, Jgg. 2760 of Lecture Notes in Computer Science, Seiten 18–31. Springer, 2003.

134


[FFHP11] Hannes Federrath, Karl-Peter Fuchs, Dominik Herrmann und Christopher Piosecny. Privacy-Preserving DNS: Analysis of Broadcast, Range Queries and Mix-Based Protection Methods. In Vijay Atluri und Claudia D´ıaz, Hrsg., ESORICS, Jgg. 6879 of Lecture Notes in Computer Science, Seiten 665–683. Springer, 2011. [FJP96]

Hannes Federrath, Anja Jerichow und Andreas Pfitzmann. MIXes in Mobile Communication Systems: Location Management with Privacy. In Ross J. Anderson, Hrsg., Information Hiding, Jgg. 1174 of Lecture Notes in Computer Science, Seiten 121–135. Springer, 1996.

[Fuc09]

Karl-Peter Fuchs. Entwicklung einer Softwarearchitektur für anonymisierende Mixe und Implementierung einer konkreten Mix-Variante. Magisterarbeit, Universität Regensburg, 2009.

[HFH+ 09] Mark Hall, Eibe Frank, Geoffrey Holmes, Bernhard Pfahringer, Peter Reutemann und Ian H. Witten. The WEKA data mining software: an update. SIGKDD Explor. Newsl., 11:10–18, November 2009. [KEB98]

Dogan Kesdogan, Jan Egner und Roland Büschkes. Stop-and-Go-MIXes Providing Probabilistic Anonymity in an Open System. In David Aucsmith, Hrsg., Information Hiding, Jgg. 1525 of Lecture Notes in Computer Science, Seiten 83–98. Springer, 1998.

[KG10]

Aniket Kate und Ian Goldberg. Using Sphinx to Improve Onion Routing Circuit Construction. In Radu Sion, Hrsg., Financial Cryptography, Jgg. 6052 of Lecture Notes in Computer Science, Seiten 359–366. Springer, 2010.

[Köp06]

Stefan Köpsell. Vergleich der Verfahren zur Verhinderung von Replay-Angriffen der Anonymisierungsdienste AN.ON und Tor. In Jana Dittmann, Hrsg., Sicherheit, Jgg. 77 of LNI, Seiten 183–187. GI, 2006.

[PIK94]

Choonsik Park, Kazutomo Itoh und Kaoru Kurosawa. Efficient anonymous channel and all/nothing election scheme. In Workshop on the theory and application of cryptographic techniques on Advances in cryptology, EUROCRYPT ’93, Seiten 248–259, Secaucus, NJ, USA, 1994. Springer-Verlag New York, Inc.

[PPW91]

Andreas Pfitzmann, Birgit Pfitzmann und Michael Waidner. ISDN-MIXes: Untraceable Communication with Small Bandwidth Overhead. In Wolfgang Effelsberg, Hans Werner Meuer und Günter Müller, Hrsg., Kommunikation in Verteilten Systemen, Jgg. 267 of Informatik-Fachberichte, Seiten 451–463. Springer, 1991.

[SDS02]

Andrei Serjantov, Roger Dingledine und Paul F. Syverson. From a Trickle to a Flood: Active Attacks on Several Mix Types. In Fabien A. P. Petitcolas, Hrsg., Information Hiding, Jgg. 2578 of Lecture Notes in Computer Science, Seiten 36–52. Springer, 2002.

[Ser07]

Andrei Serjantov. A Fresh Look at the Generalised Mix Framework. In Nikita Borisov und Philippe Golle, Hrsg., Privacy Enhancing Technologies, Jgg. 4776 of Lecture Notes in Computer Science, Seiten 17–29. Springer, 2007.

[SK95]

Kazue Sako und Joe Kilian. Receipt-Free Mix-Type Voting Scheme - A Practical Solution to the Implementation of a Voting Booth. In EUROCRYPT, Seiten 393–403, 1995.

[VHT08]

Parvathinathan Venkitasubramaniam, Ting He und Lang Tong. Anonymous Networking Amidst Eavesdroppers. IEEE Transactions on Information Theory, 54(6):2770–2784, 2008.

[VT08]

Parvathinathan Venkitasubramaniam und Lang Tong. Anonymous Networking with Minimum Latency in Multihop Networks. In IEEE Symposium on Security and Privacy, Seiten 18–32. IEEE Computer Society, 2008.


135

[WMS08] Wei Wang, Mehul Motani und Vikram Srinivasan. Dependent link padding algorithms for low latency anonymity systems. In Peng Ning, Paul F. Syverson und Somesh Jha, Hrsg., ACM Conference on Computer and Communications Security, Seiten 323–332. ACM, 2008.

PyBox — A Python Sandbox Markus Engelberth Jan Göbel Christian Schönbein Universität Mannheim Felix C. Freiling∗ Friedrich-Alexander-Universität Erlangen-Nürnberg

Abstract: The application of dynamic malware analysis in order to automate the monitoring of malware behavior has become increasingly important. For this purpose, so-called sandboxes are used. They provide the functionality to execute malware in a secure, controlled environment and observe its activities during runtime. While a variety of sandbox software, such as the GFI Sandbox (formerly CWSandbox) or the Joe Sandbox, is available, most solutions are closed-source. We present the design, implementation and evaluation of PyBox, a flexible and open-source sandbox written in Python. The application of a Python based analysis environment offers the opportunity of performing malware analyses on various operating systems as Python is available for almost every existing platform.

1 Introduction The growing amount, variety, and complexity of malicious software (malware) poses major challenges for today’s IT security specialists. It is often necessary to analyze different types of malware in order to understand and assess the resulting threats. However, since manual reverse engineering is time consuming, dynamic malware analysis has become a standard analysis approach in practice. In a dynamic analysis, malware is executed in a controlled environment and all actions during runtime such as changes in the registry or access to the network are recorded. A log file provides the analyst with a first and often sufficient overview over the basic functionality of the malware.

1.1

Related Work

Several sandbox solutions have been developed for Windows systems in the past. CWSandbox [WHF07] is a widely used sandbox tool which is now commercially available under the name “GFI Sandbox” [Sof]. While it is possible to use the sandbox over a web interface as part of a research project [Fri], the sandbox software itself is closed source. The basic idea of CWSandbox is to “hook” specific Windows API calls, i.e., to divert ∗ Contact

author. Address: Am Wolfsmantel 46, 91058 Erlangen, Germany.

138

PyBox - A Python Sandbox

control flow into own code in user mode before executing the original API call. A tool similar to CWSandbox is Joe Sandbox [joe11]. The primary difference to CWSandbox lies in the way how malware is observed. While CWSandbox applies user-mode hooking, the behavior engine of Joe Sandbox is implemented as a Windows driver and therefore runs in kernel mode. So in addition to being able to monitor malware running in kernel mode, it is also much more difficult for malware to detect the analysis environment. Still, Joe Sandbox is also a commercial closed-source system. While not being commercial, Anubis (formerly known as TTAnalyze) [BMKK06] is a sandbox system for research. However, Anubis is not open-source and can only be accessed through a web frontend1 . Leder and Plohmann [LP10] developed a user-mode sandbox which is open-source [PL]. The idea of their system is to inject an entire Python interpreter into the process to be monitored. The monitoring functionality is then provided through external Python scripts. In contrast to CWSandbox, this provides more flexibility and a higher degree of configurability. The major drawback of this approach is the severe performance overhead that is introduced. Another open-source sandbox solution is Cuckoo [Cla10], which is developed by the Honeynet Project. Cuckoo is a complete and therefore also rather complex framework for malware analysis including control of virtual machines to execute malicious software on.

1.2

Contribution

In this paper, we describe the design and implementation of an open-source sandbox called PyBox (Python Sandbox). PyBox combines ideas from existing sandbox systems to create a unique and expandable tool for automated malware analysis: • PyBox implements user-mode API hooking to monitor the behavior of executed software, i.e., it injects a dynamic-link library (DLL) into created processes in order to intercept API calls and the according arguments. • PyBox allows execution control (resume, abort) during runtime. • PyBox itself uses a programming interface based on Python for improved flexibility. The main novelty of PyBox compared to existing sandboxes is the fact that it is open source as well as its flexibility. While comparable closed source software may work well in business environments, PyBox as an open source product targets to be used in research as a building block for new malware analysis tools in the future. This way, researchers can extend PyBox’s functionality and build customized solutions for their special analysis targets or work together to create a more powerful and portable analysis tool. The required flexibility is achieved by using Python as programming language for the analysis tool. Due to its easy to understand syntax Python is widely used and available for almost every 1 See

http://anubis.iseclab.org/.


139

platform. Therefore, the interface can be used to analyze targets on various systems by providing the respective hook libraries. Python also offers the required low-level support to interact with operating systems as well as integration with the used virtualization software. All this renders Python a perfect choice for our analysis tool. PyBox can be downloaded from the PyBox homepage [pyb]. After giving a short background on the techniques used by PyBox in Section 2, we briefly describe the design requirements of PyBox in Section 3. We give an overview of the implementation in Section 4 and present a brief functional evaluation in Section 5. Section 6 concludes the paper.

2 Background This section provides some general background on techniques used by PyBox.

2.1

Inline API Hooking

Hooking is a concept used to gain control of a program’s execution flow without changing and recompiling its source code. This is achieved by intercepting function calls and redirecting them to infiltrated customized code. PyBox implements so-called inline API hooking [HB08, Eng07] to monitor software behavior. The complete process is displayed in Figure 1. Inline hooks directly overwrite the function’s code bytes in memory. In particular, only the first few instructions are replaced with a five byte jump instruction to the actual hook function. The replaced instructions are stored in the trampoline function, which is used as a new entry point to the original API call. Within the hook function the logging of information or modification of arguments can take place before the original API function is executed.

2.2

DLL Injection

In order to make use of hooked API functions within the process space of the software that we want to analyze, we first need to inject code into the target process. The mechanism we apply for this purpose is called DLL injection. We instrument the API functions CreateRemoteThread and LoadLibrary that enable us to create a new thread in the target process and load a DLL file which in turn installs the hook functions.

140


Abbildung 1: Inline hooking [Eng07, p. 33]

3 Design of PyBox The PyBox analysis environment consists of three major parts: a virtual machine, the analysis tool PyBox.py, and the hook library pbMonitor.dll. Each is described in more detail in the following paragraphs. A schematic overview of the different parts of PyBox and their interaction is displayed in Figure 2. Virtual Machine. Using a virtual machine as a basis for malware analysis guarantees a secure and controlled environment in which the malware can be executed and the original system state can be restored afterwards. Inside the virtual machine we can observe system activity of a certain target software during runtime. Analysis Tool. The analysis tool, called PyBox.py, acts as the hook server. The hook server is responsible for setup adjustments according to the settings defined in the configuration files, target process creation, and hook library injection. During the execution of malicious software, it also receives and processes the log data from the hooked API functions and in the end generates a final behavior report. Hook Library. The hook library pbMonitor.dll implements the actual hooking and monitoring functionality. It is responsible for installing the specified hooks, monitoring the system calls, and creating log entries, which are then sent to the hook server. Therefore, the hook library and the hook server have to interact with each other very closely by means of inter-process communication (IPC). This way information exchange between the two processes is straightforward. The hook library pbMonitor.dll is the only component implemented in Visual C++.


141

Abbildung 2: Schematic overview of PyBox analysis process

In this case we have chosen C++ as programming language because Python cannot create DLL files and we have to make much use of various API functions provided by Windows. This requires the use of specific C data structures and is therefore more comfortable to program in C++.

4 Implementation Excerpts Describing the complete implementation of PyBox would be out of the scope of this paper. We therefore focus on a few details only. For more information see Schönbein [Sch11].

4.1

Callbacks and Trampolines

The callback function allows us to execute our own customized code within the address space of the target process. Hence, we implement the monitoring functionality here and send the resulting data to the PyBox analysis tool. r e t u r n t y p e c a l l i n g c o n v e n t i o n c a l l b a c k f u n c t i o n ( arg1 , . . . , argn ) { return type status ; i n f o = o b t a i n i f o r m a t i o n ( arg1 , . . . , argn ) ; i f ( p r e v e n t e x e c u t i o n == f a l s e ) { s t a t u s = t r a m p o l i n e f u n c t i o n ( arg1 , . . . , argn ) ; }

142

}


else { status = customized return value ; } create log entry ( info ) ; return s t a t u s ;

Listing 1: Callback function structure

The basic structure of such a callback function is depicted in Listing 1. The variables named prevent execution and customized return value represent settings that have been specified by the user beforehand. The value of prevent execution determines whether or not the trampoline function is called in order to execute the original API function. In case it is not called, a custom value is returned. Finally, the function create log entry notifies the analysis environment about the API function that was executed and the arguments that were used. In order to describe the usage of callback functions in more detail, we present the implementation of a sample callback function in the following. The function NtCreateFile2 is provided by the native API. It is usually called in order to create a new file or to open an existing one. The interface requires eleven arguments that all have to be passed for a function call. The most important ones are described in the following: • FileHandle is a pointer to a file handle corresponding to the created or opened file after the function has been executed. • DesiredAccess defines the requested access rights concerning the file. • ObjectAttributes is a pointer to a structure containing information about the requested file such as the file name and its path. • AllocationSize is an optional pointer to the size of the initial allocation in case a file is created or overwritten. This pointer can also be NULL implying that no allocation size is specified. • FileAttributes contains flags specifying the file’s attributes. Such attributes can for example mark a file as read-only or hidden.

The corresponding callback function is shown in Listing 2. 16 17 18 19 20 21 22 23 24 25 26

NTSTATUS NTAPI N t C r e a t e F i l e c a l l b a c k ( out PHANDLE F i l e H a n d l e , in ACCESS MASK D e s i r e d A c c e s s , in POBJECT ATTRIBUTES O b j e c t A t t r i b u t e s , out PIO STATUS BLOCK I o S t a t u s B l o c k , i n o p t PLARGE INTEGER A l l o c a t i o n S i z e , in ULONG F i l e A t t r i b u t e s , in ULONG S h a r e A c c e s s , in ULONG C r e a t e D i s p o s i t i o n , in ULONG C r e a t e O p t i o n s , i n o p t PVOID E a B u f f e r ,

2 http://msdn.microsoft.com/en-us/library/ff566424(v=vs.85).aspx


27 28 29

) {

30 31

59 60

61 62 63 64 65 66 67 68 69 70 71

73

ULONG E a L e n g t h

NTSTATUS s t a t u s ; ... i f ( h o o k s e t t i n g s [ 0 ] . p r e v e n t E x e c u t i o n == FALSE ) { / / Call trampoline function s t a t u s = N t C r e a t e F i l e t r a m p o l i n e ( FileHandle , DesiredAccess , ObjectAttributes , IoStatusBlock , AllocationSize , FileAttributes , ShareAccess , C r e a t e D i s p o s i t i o n , C r e a t e O p t i o n s , EaBuffer , EaLength ) ; executed = 1; } else { / / Get c u s t o m i z e d r e t u r n v a l u e s t a t u s = (NTSTATUS ) h o o k s e t t i n g s [ 0 ] . r e t u r n V a l u e ; }

57 58

72

in

143

}

/ / C r e a t e l o g e n t r y and r e t u r n SOCKET ADDRESS INFO s a i = {0}; c r e a t e L o g ( 0 , o b j e c t , L” ” , ” ” , e x e c u t e d , D e s i r e d A c c e s s , F i l e A t t r i b u t e s , ShareAccess , C r e a t e D i s p o s i t i o n , CreateOptions , sai , s t a t u s ) ; return s t a t u s ;

Listing 2: The NtCreateFile callback function

As soon as all required information is gathered, it is determined whether the original API is to call as well, or if a predefined value should be returned. This check is implemented in line 57. Finally, the callback function returns the value of status (line 72) to the object that has called the API function. An important piece of information that is passed to the createLog function in line 71, is the file path of the target file associated with the API call. All information concerning the target file of a NtCreateFile call can be found in the argument ObjectAttributes. This structure contains the two fields providing the information we are looking for: RootDirectory and ObjectName. In order to obtain the complete path to a target file, we simply have to combine these two parts. The resulting string is stored in the variable object and finally used to create the associated log entry.

4.2

Detection Prevention

More recent malware samples implement methods to inspect the system environment they are executed in, to detect analysis software. Since we do not want malware to behave differently than on a usual personal computer, we need to avoid easy detection of the PyBox analysis environment. Possible techniques applied by malware in order to examine the system are to list all running processes or to scan the file system. Often, certain API functions are applied in order to implement the required detection techniques. In PyBox, we consider two different methods. The first method is to use the API function CreateToolhelp32Snapshot in

144


order to create a snapshot containing a list of all running processes and to parse this list using the API functions Process32First and Process32Next. The second method considered is to use the API functions FindFirstFile and FindNextFile in order to scan the filesystem. We use the the hooking functionality to intercept these API functions and successfully hide files and processes of PyBox. If an object returned by one of the above mentioned API functions belongs to the analysis framework, the corresponding trampoline function will be called again until it returns an object which does not belong to the analysis framework or until there is no more object left in the list to be queried. In this way, PyBox is basically invisible to other processes of the analysis system, in particular to the examined target process, too.

4.3

PyBox Analysis Tool

The PyBox analysis tool is the interface between the hook library and the analyst. It enables the following tasks: configuration management, process creation, library injection, data processing, and report generation.

Abbildung 3: PyBox analysis tool layout

In order to fulfil these tasks, PyBox includes various packages, modules and configuration files, as illustrated in Figure 3. In the upper part of Figure 3, the five packages belonging to the PyBox analysis tool are depicted. The package setup is responsible for reading the provided configuration files and for extracting their information. Furthermore, it converts this information into objects that can be used by the analysis tool. The package process allows to execute process-related operations such as the creation of the target process. Additionally, it provides required process-specific information. The DLL injection method is implemented in the package injection. The final report generation operations are made available by the package report. More precisely, it offers the functionality to process the data received from the monitored process and turn them into a XML-based report. The communication and inter-


145

action with the target process is implemented in the package ipc. The lower part of Figure 3 displays the two configuration files named pybox.cfg and hooks.cfg. The file pybox.cfg defines settings that are required by the analysis framework to work. In particular it contains the path to the hook library, which is injected into the target process. In contrast, the file hooks.cfg influences the execution of the hook library inside the target process. More specifically, it defines which hooks to install and, thus, which API functions to monitor. During the start of the execution of PyBox.py, all hooks are read and mapped to an array of C data structures that are present both in the PyBox main application and the hook library. Each hook has a specific identification number by which it can be identified. Once the array is created out of the configuration file, the hook library can obtain the array and install all specified hooks. More details about logging and the generation of the the XML report can be found in Schönbein [Sch11].

5 Evaluation In order to test the functionality of PyBox, we have tested the analysis environment examining different malware samples. Due to space restrictions, in this section, we present only one example. More examples can be found in Schönbein [Sch11]. The malware sample analyzed here can be categorized as back door, trojan horse, or bot. Its common name is “Backdoor.Knocker”. Information about this threat is provided by VirusTotal [Vir], Prevx [Pre], and ThreatExpert [Thr]. ThreatExpert refers to it as Backdoor.Knocker. Its purpose is to frequently send information such as the IP address or open ports of the infected system to its home server. During the analysis run of this sample it did not come to an end. Therefore, the analysis process terminated the target process after the specified time-out interval of two minutes. 227

228

Listing 3: Extract from the file management section of the malware sample’s analysis report

The first interesting aspect of the behavior report is in line 227 of Listing 3. The file section documents that the target process has created a file in the Windows system folder and written data to it. The file has been named cssrss.exe. These entries also indicate malicious behavior as the file name is very similar to the file name csrss.exe. The latter is the executable of the Client Server Run-Time Subsystem (CSRSS), which is an important part of the Windows operating system. It seems that the analyzed object is named similar to a system process to hide its presence.

146

1211

1212

1213

1214


Listing 4: Extract from the registry section of the malware sample’s analysis report

The behavior report’s registry section also contains many entries, which have to be considered. The process queries various information about system and network services as well as about the operating system such as the system’s version. One particularly noticeable part of the registry section is depicted in Listing 4. The report reveals that the target process uses registry API functions to change the value EnableFirewall (line 1212) and furthermore to add its executable file to the list of authorized applications (line 1214). These entries are clear evidence that the application tries to disable security mechanisms and thus performs malicious behavior unwanted by the system’s user.

6 Conclusion and Future Work Given the available commercial dynamic analysis tools on the market, PyBox is the first publicly available open-source tool which written in a flexible and platform independent programming language. This allows PyBox to be easily improved in many ways. In PyBox we currently only hook native API functions to monitor the behavior of malware samples. But different Windows versions often use very different native API functions. Therefore, the hook library has to be extended in order to provide compatibility with various Windows versions. An approach for extending the functionality of PyBox is to add further hooks to the analysis framework in order to monitor more types of activity. Furthermore, the analysis tool’s report generation can be extended by mapping provided numeric values such as file creation flags to strings that describe the meaning of the activated flags in order to simplify the interpretation of the report. A third approach is to implement a hook library for other operating systems such as Android and thus provide the opportunity to analyze malware samples designed to attack mobile devices. In order to provide more flexibility and exten-


147

dibility for malware analyses we could incorporate the functionality of a C compiler. We could use a special Python script and create the hook library’s code out of existing code fragments according to the configured settings specified by the analyst. Thus, we would implement a modular solution that automatically compiles a separate, customized hook library that can be injected into the remote process to be monitored. In doing so, we would have a more flexible solution, which also considers the performance criterion.

Literatur [BMKK06] Ulrich Bayer, Andreas Moser, Christopher Krügel und Engin Kirda. Dynamic Analysis of Malicious Code. Journal in Computer Virology, 2(1):67–77, 2006. [Cla10]

Claudio Guarnieri and Dario Fernandes. Cuckoo - Automated Malware Analysis System. http://www.cuckoobox.org/, February 2010.

[Eng07]

Markus Engelberth. APIoskop: API-Hooking for Intrusion Detection. Diplomarbeit, RWTH Aachen, September 2007. http: //www1.informatik.uni-erlangen.de/filepool/thesis/ diplomarbeit-2007-engelberth.pdf.

[Fri]

Friedrich-Alexander University Erlangen-Nuremberg. Malware Analysis System. http://mwanalysis.org. Retrieved November 2011.

[HB08]

Greg Hoglund und James Butler. Rootkits : Subverting the Windows Kernel. AddisonWesley, 6. edition, 2008.

[joe11]

How does Joe Sandbox work?, 2011. http://www.joesecurity.org/ products.php?index=3, Retrieved May 2011.

[LP10]

Felix Leder und Daniel Plohmann. PyBox — A Python approach to sandboxing. In Sebastian Schmerl und Simon Hunke, Hrsg., Proceedings of the Fifth GI SIG SIDAR Graduate Workshop on Reactive Security (SPRING), Seite 4. University of Bonn, Juli 2010. https://eldorado.tu-dortmund.de/bitstream/2003/27336/ 1/BookOfAbstracts_Spring5_2010.pdf.

[PL]

Daniel Plohmann und Felix Leder. pyboxed — A user-level framework for rootkit-like monitoring of processes. http://code.google.com/p/pyboxed/. Retrieved November 2011.

[Pre]

Prevx. Cssrss.exe. http://info.prevx.com/aboutprogramtext.asp? PX5=3E583C9DC0F87CBE51EE002CBE6AE800476D2E00, Retrieved April 2011.

[pyb]

PyBox – A Python Sandbox. http://www1.informatik.uni-erlangen. de/content/pybox-python-sandbox. Retrieved November 2011.

[Sch11]

Christian Schönbein. PyBox - A Python Sandbox. Diploma Thesis, University of Mannheim, May 2011. http://www1.informatik.uni-erlangen.de/ filepool/thesis/diplomarbeit-2011-schoenbein.pdf.

[Sei09]

Justin Seitz. Gray Hat Python: Python Programming for Hackers and Reverse Engineers. No Starch Press, San Francisco, CA, USA, 2009.

148


[Sof]

GFI Software. Malware Analysis with GFI SandBox (formerly CWSandbox). http: //www.gfi.com/malware-analysis-tool. Retrieved November 2011.

[Thr]

ThreatExpert. ThreatExpert Report: Trojan.Flush.G, Hacktool.Rootkit, DownloaderBIU.sys. http://www.threatexpert.com/report.aspx?md5= 3cdb8dc27af1739121b1385f36c40ce9, Retrieved April 2011.

[Vir]

VirusTotal. http://www.virustotal.com/file-scan/report.html? id=9e9efb4321ffe9ce9483dc32c37323bada352e2dccc179fcf4ba66 dba99fdebf-1233827064, Retrieved April 2011.

[WHF07]

Carsten Willems, Thorsten Holz und Felix Freiling. Toward Automated Dynamic Malware Analysis Using CWSandbox. IEEE Security and Privacy, 5:32–39, 2007.

The Problem of Traffic Normalization Within a Covert Channel’s Network Environment Learning Phase Steffen Wendzel Faculty of Mathematics and Computer Science, University of Hagen, 58084 Hagen, Germany Abstract: Network covert channels can build cooperating environments within overlay networks. Peers in such an overlay network can initiate connections with new peers and can build up new paths within the overlay network. To communicate with new peers, it is required to determine protocols which can be used between the peers – this process is called the “Network Environment Learning Phase” (NEL Phase). We show that the NEL phase itself as well as two similar approaches are affected by traffic normalization, which leads to a two-army problem. Solutions to overcome this not completely solvable problem are presented and analyzed. A proof of concept code was implemented to verify the approach.

Keywords: network covert storage channel, traffic normalization, active warden

1 Introduction A covert channel is a communication channel that is not intended for information transfer at all [Lam73]. Using network covert channels it is possible to send information in a way prohibited by a security policy [And08, WAM09]. Network covert channels can be used by both, attackers (e.g. for hidden botnet communication [GP+ 08, LGC08]) as well as normal users (e.g. journalists, if they want to keep a low profile when transferring illicit information [ZAB07]). Network storage channels utilize storage attributes of network protocols while network timing channels modify the timing behavior of network data [ZAB07]. We focus on covert storage channels since they (in comparison to covert timing channels) provide enough space to place a covert channel-internal protocol into the hidden data. Ways to implement covert channels in TCP/IP network packets and their timings were described by different authors (e.g. [Gir87, Wol89, HS96, Row97, CBS04, Rut04, LLC06, JMS10]). However, such channels occur outside of TCP/IP networks as well, such as in smart grids [LG10], electronic identity cards [Sch10] and business processes [WAM09]. A number of means to protect systems against covert channels were also developed (e.g. [Kem83, PK91, Hu91, Fad96, FFPN03, CBS04, BGC05, KMC05]). Covert channels can contain internal communication protocols [RM08, Stø09], so called micro protocols [WK11]. These protocols are located within the hidden data, which is used for both: the micro protocols as well as payload. Micro protocols are used to extend

150

Traffic Normalization within the Network Environment Learning Phase

the capabilities of covert channels by implementing features such as reliability and runtime protocol switching. To enable two communicators to communicate using a covert channel, they need to find a common cover protocol. A cover protocol is the network protocol (the bits used within a network protocol) which is used to place hidden data into. The discovery of information about network protocols to use can either be done using a micro protocol as presented in [WK11] or by passive monitoring of traffic [YD+ 08]. A traffic normalizer is a network gateway with the capaibility to affect the forwarded traffic in a way that prevents malicious communication (e.g. malformed traffic as well as any kind of network-based attacks such as botnet traffic or exploit traffic). Traffic normalizers are also known as packet scrubbers [BP09]. Usually, a traffic normalizer is part of a firewall system [MWJH00] and can decide to drop or forward network traffic. A popular example of such a combination of a firewall with a traffic normalizer is the pf firewall of the OpenBSD operating system [Ope11]. A similar implementation for the FreeBSD kernel focuses on the implementation of transport and application layer scrubbing [MWJH00]. Additionally to a plain firewall system, a traffic normalizer is able to modify forwarded traffic [MWJH00]. Therefore, the normalizer can apply rules such as clearing bits of a network protocol’s header or setting a header flag that was not set by the packet’s sender [HPK01]. Because of a normalizer’s applied modifications, their implementation in a network can result in side-effects, e.g. blocked ICMP types result in the unavailability of the related network features of these ICMP types [SN+ 06]. Traffic normalizers are also referred to as a special type of an active warden. While passive wardens in networks monitor and report events (e.g. for intrusion detection), active wardens are capable of modifying network traffic [SN+ 06] to prevent steganographic information transfer. Active wardens with active mapping capability reduce the problem of ambiguities in network traffic (i.e. data that can be interpreted in multiple ways [LLC07]) by mapping a network and its policies [Sha02]. Afterwards, the mapped information is used by a NIDS to provide unambiguity [LLC07]. Based on the idea of active mapping and traffic normalization, Lewandowski et. al. presented another technique called network-aware active wardens [LLC07]. Network-aware active wardens have knowledge about the network topology and implement a stateful traffic inspection with a focus on covert channel elimination [LLC06, LLC07]. All these techniques have in common that they drop or modify parts of the network traffic regarding to their configuration. For our purpose, it is required to focus on this common dropping and modification feature. We decided to use only the term normalizer in the remainder because we only deal with the normalization aspect that all three mentioned techniques (normalizer, active mapper and network-aware active warden) have in common. This paper contributes to the existing knowledge by presenting and discussing the problem of traffic normalization in a covert channel’s network environment learning phase (NEL phase). Within the NEL phase, the covert channel peers try to find out which protocols they can use to communicate with each other (e.g. two journalists want to determine how they can communicate using application layer protocols). Thus, the NEL phase is significant for establishing a network covert channel. We show that traffic normalization


151

within the NEL phase results in a two-army problem. We evaluate passive monitoring not to be capable to solve this problem and present two means to overcome the two-army problem. The drawbacks of these results are discussed as well. The remainder of this paper is organized as follows. Section 2 introduces the problem of traffic normalization within the NEL phase. Section 3 discusses means to overcome this problem and their possible drawbacks while Section 4 highlights the effect of four existing normalizers on the NEL phase. Section 5 concludes.

2 Related Work and the Problem of NEL-Normalization Yarochkin et. al. presented the idea of adaptive covert channels, capable of automatically determining the network protocols which can be used between two covert channel communicators [YD+ 08]. Their approach filtered out blocked and non-routed network protocols within a two-phase communication protocol containing a “network environment learning” (NEL) phase as well as a “communication phase”. Within the network environment learning phase, the covert channel software detects the usable network protocols, while the payload transfer is taking place within the communication phase. Wendzel and Keller extended this approach by introducing goal-dependent protocol sets, i.e., usable protocols are chosen with different probabilities to optimize a covert channel for goals such as providing a high throughput or sending as few data packets as possible to transfer a given payload [WK11]. A similar approach by Li and He is based on the idea of autonomic computing [LH11]. The authors try to detect survival values for embedded steganographic content in network packets, i.e. they evaluate whether hidden data was corrupted within the transmission, or not, and therefore use checksums, transmission rates, and sequence numbers [LH11]. However, Li’s and He’s approach requires a previously established connection to evaluate the results, what is not sufficient if a normalizer is located between sender and receiver, since the two-army problem cannot be solved under such circumstances. Yarochkin et. al. are focusing on whole network protocols [YD+ 08]. They detect usable network protocols exchanged between two hosts by monitoring network data. Wendzel and Keller distinguish protocols on a finer scale, e.g. one “protocol” can be to set the “IP ID” as well as the “Don’t fragment flag” in IPv4 while another protocol could only use the “Reserved” flag of IPv4 but both “protocols” belong to the same network protocol (IPv4) [WK11]. To prevent confusion, we call the network protocol (or the bits used within a network protocol) the “cover protocol” of a covert channel. Using this term, we can refer to both approaches at the same time.

Figure 1: Communication between two hosts A and B. Neither A nor B know about the existence of a normalizer (and its configuration) between them a priori.

152


All three mentioned methods, Yarochkin et. al., Wendzel and Keller, and Li and He, aim to gain information about usable cover protocols but do not focus on the problem of traffic normalization. When a traffic normalizer is located between two covert channel systems which want to exchange information about protocols they can send and receive, a normalizer can drop or modify the exchanged information (Fig. 1). It is also possible that more than one normalizer is located on the path between A and B but this does not differ from a single normalizer in our scenario. Normalizers usually modify bits (such as they unify the TTL value in IPv4) or clear bits (such as the “Don’t fragment” flag). Implementations like norm [HPK01], the Snort Normalizer [Sno11], the netfilter extension ipt scrub [Bar08], or the OpenBSD packet filter scrubbing [Ope11]1 provide more than 80 normalization techniques for IPv4/IPv6, ICMP, TCP, UDP and the most important application layer protocols. In the given scenario, host A and host B want to exchange information about the cover protocols, i.e. network protocols and the protocol specific bits they can use to communicate with each other. For example, host A is sending a network packet (e.g. a DNS request) to host B with the reserved flag set in the IPv4 header: If the normalizer clears the reserved flag (it is zero afterwards), host B cannot determine whether host A did not set the reserved flag or whether a normalizer (B and A are possibly not aware of a normalizer) modified the bit. Alternatively, the normalizer can – like a plain firewall – drop a packet if the reserved flag is set (in that case, host B does not know about the sent packet). To exchange the information about all usable bits of all cover protocols a covert channel can support between A and B, it is required to test all bits and protocols in both directions (each received packet must be acknowledged to inform the sender about the successful sending). Since A cannot know which of his packets will reach B, A depends on the acknowledgement of B. If A can successfully send a packet to B, B cannot make sure that the response containing the protocol acknowledge information is not getting dropped by a normalizer (since B does not know which bits or protocols will reach A). Since neither A nor B can be sure whether their packets will reach the other system, they are left in an uninformed situation. Hence, the exchange of protocol information between A and B results in the two-army problem [Kle78]. The two-army problem cannot be eliminated but the uncertainty of A and B can be reduced by sending multiple (acknowledgement) messages or acknowledgement messages from each side (A acknowledges B acknowledgement, such as performed by the three-way-handshake of TCP [Pos81]). The next section discusses specific means for dealing with the two-army problem within the NEL phase.

3 Realizing the NEL Phase in Normalized Environments If the covert channel software is able to determine a set of non-normalized cover protocols, it will enable the covert channel to communication without problems. Therefore, we define a set of cover protocols P = {x1 , ..., xn } (P contains all possible bit areas which can be used within a cover protocol) where, for instance, x1 could represent “sending an IP packet 1 Regarding

to our investigation, pf supports a number of undocumented normalization features.


153

with DF flag set”. An element xi ∈ P can contain other elements of P (e.g. x1 =“set DF flag” and x2 =“set the reserved flag”, x3 = {x1 , x2 }=“set the reserved flag as well as the DF flag”). This condition is necessary, since a normalizer can include a rule to drop, modify or clear a packet (respectively bits) if a packet contains both x1 and x2 , but does not apply the same rule (or no rule) in case of x1 or x2 . Based on this initial specification, we develop two different means for applying the NEL phase in normalized environments as well as in environments where A and B cannot be sure whether a normalizer is located between them. The first solution is to use a pre-defined sequence of the elements of P . In comparison to the passive monitoring approach of Yarochkin et. al., this is an active approach. We describe a disadvantage of the passive approach in Sect. 3.1. In the first step, A sends an ordered sequence x1 , ..., xn to B. The data hidden in xi must contain information B can use to identify these as covert data (such as a “magic byte” as in ping tunnel [Stø09] or micro protocol data [WK11]). In case host B receives some of these packets, B can assume that A is currently sending the pre-defined packet sequence. Probably, host B will receive a sequence such as x3 , x9 , x10 (with bit i cleared), x11 , x17 (with bits j and k cleared), x19 , x20 , i.e. some protocols or bit-combinations were blocked (respectively modified) by a normalizer, or got lost. In this case, host B can never be completely sure that it is currently receiving the packet sequence from A but can use the information received to communicate with A in a limited way nevertheless. The complete process has to be done vice versa since normalizer rules can be direction-dependent. Afterwards, A and B will have a set of protocols they can receive from the other peer. A and B assume that the cover protocols of the packets that were received correctly can be used to send data back to the peer. After this step is completed too, the communication phase can start. Since B (respectively A) do not know whether their own packets were received by the peer if the normalizer applies direction-dependent rules, and depend on the acknowledgement information from the peer itself, they do not know which cover protocol they can use to send their acknowledgement. Therefore, this solution results in the two-army problem again if the normalizer applies direction-dependent rules and has to be considered errorprone.

Figure 2: A and B exchanging protocol information using C.

A second solution (shown in Fig. 2) we want to present is to include a third (but temporary) participant C known to A and B. We assume that A and C, as well as B and C already exchanged the information about usable protocols, i.e. they are able to exchange

154


information in a way not dropped or cleared, even if a normalizer is present between them. C is not necessarily required to be aware of a covert communication between itself and A or B, i.e. C could be a shared temporary resource such as a Flickr account [BK07]. C is a temporary solution since A, B (and probably others) can only build a complex covert overlay network if new paths besides already known paths are created. If A and B would transfer all information between them using C, no new path would be created and C would be a single point of failure if no other connection between A and B exists. Additionally, it is more secure to transfer only information about usable protocols between A and B via C than it is to transfer all hidden information itself via C. In this scenario, C can be used by A to inform B (and vice versa) about packets which A (respectively B) is about to sent. For instance: A sends C the information to tell B that A will now send an IP packet with DF bit set to B; C will forward the information to B. A will sent the described packet either after a short waiting time < t to B or after B responds its waiting state to A (via C). The first method decreases the amount of exchanged data while the latter is less error-prone. If B received the packet, B knows, that the DF flag can be used and was not cleared or dropped. In any case, B reports the reception/the miss of the announced cover protocol containing packet. The whole process works in both directions, i.e. A and B can exchange all required information about usable cover protocols. The temporary system C is not required to be a single hop within the overlay network, it can also be a chain of proxies C = P1 → ... → Pn represented as a single system in this second solution. The only difference between a single hop called C and a proxy chain called C is the internal forwarding within the system. Such forwarding for covert channel proxy chains must be bi-directional and can be achieved and optimized by known micro protocol means [WK11]. Discussion of the two presented means While the first scenario (sending a pre-defined sequence) is error-prone, the second scenario depends on a third communicator C connected to A and B. A combination of both scenarios will be a promising approach for further implementations. A drawback in the second solution exists in case C is aware of covert communication (i.e. not a passive system, such as a Flickr account), since C can manipulate the covert communication. For instance, C could drop all protocol information requests from A to B (and vice versa). If A and B are able to exchange cryptographic keys a priori, they can sign messages sent via C to prevent undetected message modifications. However, the use of signatures does not prevent C from actively dropping the messages. Therefore, it is recommended to use a passive C.

3.1

Improved Protocol Determination Strategies

If a covert channel implementation supports a large amount of cover protocols (or some areas containing many bits), the packet count required to transfer all feasible bit-combinations through the possible normalizer can become high, thus the number of required packets for the protocol determination can also be high.


155

For example, if P = {x1 , x2 , x3 } (say each xi is representing one bit of data in this case), it is possible to send each element alone, in combination with another element, or all three elements at the same time, i.e. there are seven possible combinations. To verify the possible use of these protocols using strategy #2 (as explained before), it would require 14 packets to verify all elements of P and their combinations for the cover protocols between A and B (the packets exchanged between A and C as well as between B and C are not included in this calculation). If P contains many elements, the number of required packets can result in raising a high attention due to the abnormal traffic pattern [WK11]. Therefore, it is mandatory to reduce the number of required packets. A reduction of the necessary network packets for determining the usable cover protocols between A and B can result in a loss of quality in the determined protocol information. We present two reduction strategies, where the first strategy results in a loss of quality while the second does not. These strategies are presented since each practical implementation can profit from them to keep a low profile. Reduction Strategy 1: If each protocol layer (e.g. the TCP/IP layers) can be scanned independent of the other layers, the number of possible combinations decreases. For instance, if x1 and x2 refer to bits within the IPv4 header, and x3 refers to UDP, there are only six (instead of eight) combinations left to try. This scan technique has the drawback that normalizer rules which depend on multiple layers are not taken into account. Reduction Strategy 2: If each different covering network protocol on the same network layer is scanned independent from all other network protocols on the same layer, a loss in the quality of the resulting information is not possible since different protocols usually do not depend on other protocols on the same layer.2 For instance, if P = {x1 , x2 } where x1 modifies two bits within the TCP header and x2 modifies one bit within the UDP header, there are only 6 possible bit combinations to verify. Critique on the passive approach: Another simplification is thinkable but less valuable for real implementations: Regarding to the passive monitoring approach presented by Yarochkin et. al. (as discussed in Sect. 2), A could try to use only protocols for the communication with B which it can receive on its own network interface. However, the occurrence of a network protocol on a network interface of A does not necessarily mean that a normalizer will forward such network packets to A in any case. If, on the other hand, the source address of such a network protocol’s packet does not belong to A’s subnet, it is the case that such a network protocol is forwarded to the network of A. Such a packet has probably passed a normalizer but since there can be more than one normalizer between A and B, this solution is also error-prone and cannot be recommended for implementations. Of course, one could argue that A could wait for network packets containing the source address of B’s subnet, but this is only realistic in the case of regular communication between both subnets. Additionally, filter rules can be address-based instead of interface- or subnet-based, i.e. it is possible that a normalization rule applies for some hosts in B’s (A’s) 2 This second rule is mandatory since it is not possible for network packets to contain two different network protocols of the same network layer. An exception is to use network tunneling but in network tunneling, a single network layer also does not really contain two protocols, but a layer can occur multiple times.

156


subnet but not for all hosts in the subnet. Thus, this approach is only useful for a direct communication between B and A, and due to that limitation provides no improvement in comparison to the already presented means. However, the passive approach is linked to a number of drawbacks: It requires additional waiting time and is is not successfully adaptable to most overlay network situations, since information about the underlay network are not necessarily available. Mentionable as well, is that a direct third party network data exchange between A and B, which is required for the monitoring, will usually be rare and will additionally not necessarily include all elements of P .

3.2

The Problem of Dynamic Routing Environments

Problematic as well is the possibility for traffic to take different routes on the path between A and B within the underlay network, where one packet could pass a normalizer and another packet does not (or some packets are transferred over different normalizers). Since neither A nor B are able to control the routing decisions between them and do not necessarily possess knowledge about the underlay network structure, A and B cannot overcome this situation.

3.3

Proof of Concept Implementation

A proof of concept implementation was developed to run a simulated NEL phase. A covert channel receiver program (representing B) was built to accept information from a temporary participant (representing C) as shown in strategy #2. The input from C to B was scripted by hand and the traffic from A to B was generated using the network packet generator scapy (www.secdev.org/projects/scapy/), while the covert receiver software is based on libpcap (tcpdump.org). Using scapy, we were able to simulate packet loss, perfect packet transfer and traffic modifications. If packet loss occurs, B assumes that a packet was filtered. Since uncommon packet occurrences can result in raising a high attention, we cannot recommend to sent such packets multiple times within a small time slice to deal with packet loss. Non-normalized packets obviously result in an uncorrupted NEL phase (excluding lost packets). The effect of traffic modifications turned out to produce multiple packets containing the same flag combinations on system B. For instance, if A sends an IPv4 packet containing the DF flag set as well as one packet with an unset DF flag, B will receive two packets with DF=0 if a normalizer clears the DF flag. B must ensure not to accept packets using the same bits as announced by A from other sources, thus B must apply filter rules (e.g. using libpcap filter settings to accept only packets from A). The covert channel receiver B transfers the information of an useless cover protocol back to A (using C) if such a doubled cover protocol was received. We implemented the acknowledgement transfer to A using a micro protocol as described in [WK11].


157

4 Effects of Existing Normalizers on the NEL Phase As discussed in the previous sections, traffic normalizers can drop, modify and clear cover protocols. Thus, for realizing a covert channel’s NEL phase, it is important to obtain knowledge about the usable cover protocols a priori. By analyzing four normalizers (pf scrubbing, norm, the Linux netfilter/iptables extension ipt scrub, and the Snort normalizer), we were able to carve out general rules which can be applied to the NEL phase. Different traffic normalizers contain different capabilities. For instance, Snort and norm are able to clear the IPv4 reserved flag, but pf is not. Some capabilities are configurationdependent, e.g. the handling of the “Don’t Fragment” flag in pf depends on the usage of the “no-df” rule in the configuration file. Additionally, the amount of features differs significantly: While norm supports more than 70 normalization rules, ipt scrub supports only 8 of them. Additional differences apply for the amount of supported network protocols. For the NEL phase, it is useful to define the elements of P by verifying their support within normalizers: Elements which are not supported by any or by very few normalizers are likely to reach their destination within the NEL phase, while elements which are supported by (almost) any normalizer have a higher probability to get normalized. We compared the features of the four normalizers and found out that several normalization capabilities are provided by most of the implementations: IPv4: TTL modification, removing DF flag, reserved bit and options and drop packets with IHL 53 . IPv6: modify the hop limit, modify or remove optional headers. ICMP modify/drop ICMP type 0 and 8. TCP: Clear the reserved bits, drop packets with unusual flag or flag/data combinations (e.g., SYN=1 and RST=1, SYN=1 and FIN=1, or SYN=1 with payload), drop in case of a small header length. UDP (norm)/HTTP (Snort): Only supported by one normalizer. Additionally, we want to provide a general explanation which cover protocols we can call useful in our scenario. UDP and HTTP are currently only supported by one of the normalizers, which makes them good choices for bypassing normalizers within the NEL phase. On the other hand, there are network protocols which are not in the scope of any of the normalizers, e.g. application layer streaming protocols, frames on the network access layer, or dynamic routing protocols, what makes them good choices for the NEL phase too. If such protocols are used, it is important to understand that the occurrence of rarely used network protocols can raise the attention of a covert channel [WK11] (e.g. the usage of IGRP in an OSPF network). Thus, the usefulness of rarely used protocols for the NEL phase is low. A passive monitoring can be done to determine the occurrence rates of network protocols (but as described in Sect. 3.1, passive monitoring is not recommendable to detect cover protocols). Tab. 1 shows occurrence rates of transport layer network protocols within different passive traffic recordings and demonstrates the significant differences within different Ethernet networks. These three traffic recordings where downloaded from http://www.simpleweb.org/wiki/Traces, a website providing a number of tcpdump recordings (mainly from universities). These different protocol occurrences do not only exist for network protocols but for types of cover protocols as well, as shown in Tab. 2 in case of 3 In

case of OpenBSD, this is not specified in the manual, but found in a source code analysis for this paper.

158


Source Simpleweb-Loc1 Simpleweb-Loc2 Simpleweb-Loc3

ARP 0.02% -

TCP 77.67% 92.46% 68.88%

UDP 21.94% 0.08% 3.95%

ICMP 0.25% 3.20% 27.12%

IGMP

Proceedings - Journals - EMIS

Proceedings - Journals - EMIS

Suggest Documents

MODELING RADIATED ELECTROMAGNETIC EMIS ... - (PIER) Journals

MODELING RADIATED ELECTROMAGNETIC EMIS - PIER Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

Proceedings Template - WORD - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

GI-Proceedings Cover - Journals

GI-Edition Proceedings - Journals

GI-Edition Proceedings - Journals

Proceedings of the 29 Conference of the International Group ... - EMIS

Proceedings of the 29 Conference of the International Group ... - EMIS

Proceedings of the 29 Conference of the International Group ... - EMIS

Proceedings of the 29 Conference of the International Group ... - EMIS

Proceedings of the 29 Conference of the International Group ... - EMIS

Proceedings of the 29 Conference of the International Group ... - EMIS