Volume P-195(2012) - Mathematical Journals

Transcription

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
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
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: michael.waidner@sit.tu-darmstadt.de
Prof. Suri Neeraj, Ph. D.
Technische Universität Darmstadt
Zuverlässige Eingebettete Softwaresysteme
64289 Darmstadt, Germany
Email: suri@cs.tu-darmstadt.de
Series Editorial Board
Heinrich C. Mayr, Alpen-Adria-Universität Klagenfurt, Austria
(Chairman, mayr@ifit.uni-klu.ac.at)
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 Zuverlässigkeit” SICHERHEIT der Gesellschaft für
Informatik e.V. fand 2012 in der sechsten Ausgabe in Darmstadt statt. Sie ist die regelmäßig
stattfindende Fachtagung des Fachbereichs “Sicherheit – Schutz und Zuverlässigkeit” der
Gesellschaft fü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 Brücke zwischen den Themen IT Security, Safety und Dependability zu bilden.
Der vorliegende Tagungsband umfasst alle 20 Beiträge des wissenschaftlichen Programms.
Diese Beiträge wurden aus insgesamt 51 Einreichungen durch das international besetzte 38köpfige Programmkomitee ausgewählt. Traditionsgemäß durften Beiträ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 Mü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 Püchner und Marco Ghiglieri, die sich ruhig und ausdauernd um alle Probleme der lokalen Organisation gekümmert haben, von der Planung
bis zur eigentlichen Durchführung. Unser Dank gilt auch dem Leitungsgremium des GIFachbereichs “Sicherheit - Schutz und Zuverlässigkeit”, insbesondere den Mitgliedern der
Tagungsleitung, Hannes Federrath, Felix C. Freiling und Jörg Schwenk.
März 2012
Neeraj Suri, Michael Waidner
Tagungsleitung
• Hannes Federrath (Sprecher des Fachbereichs, Universität Hamburg)
• Felix C. Freiling (Leiter der Sicherheit 2010, Friedrich-Alexander-Universität ErlangenNürnberg)
• Jörg Schwenk (stellv. Sprecher des Fachbereichs, Ruhr-Universität Bochum)
• Neeraj Suri (Co-Leiter, Technische Universität Darmstadt)
• Michael Waidner (Leiter, Technische Universität Darmstadt und Fraunhofer SIT)
Programmkomitee
• Neeraj Suri (Technische Universität Darmstadt)
• Michael Waidner (Technische Universität Darmstadt und Fraunhofer SIT)
• Michael Backes (Universität des Saarlandes)
• Bernd Becker (Universität Freiburg)
• Fevzi Belli (Universität Paderborn)
• Thomas Biege (SUSE Linux Products GmbH)
• Jens Braband (Siemens AG)
• Peter Buchholz (Technische Universität Dortmund)
• Christoph Busch (Hochschule Darmstadt)
• Christof Fetzer (Technische Universität Dresden)
• Simone Fischer-Hübner (Karlstad University, Schweden)
• Felix C. Freiling (Friedrich-Alexander-Universität Erlangen-Nürnberg)
• Sabine Glesner (Technische Universität Berlin)
• Bernhard Hämmerli (Acris GmbH)
• Marit Hansen (Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein)
• Thorsten Holz (Ruhr-Universität Bochum)
• Jörg Kaiser (Otto-von-Guericke-Universität Magdeburg)
• Günter Karjoth (IBM Research – Zurich)
• Stefan Katzenbeisser (Technische Universität Darmstadt)
• Ralf Küsters (Universität Trier)
• Helmut Kurth (atsec information security)
• Peter Ladkin (Universität Bielefeld)
• Pavel Laskov (Universität Tübingen)
• Erik Maehle (Universität Lübeck)
• Jörn Müller-Quade (Karlsruhe Institut für Technologie)
• Isabel Münch (BSI - Bundesamt für Sicherheit in der Informationstechnik)
• Roman Obermaisser (Universität Siegen)
• Günther Pernul (Universität Regensburg)
• Andreas Polze (HPI Universität Potsdam)
• Kai Rannenberg (Goethe-Universität Frankfurt am Main)
• Felix Salfner (SAP Innovation Center Potsdam)
• Jörg Schwenk (Ruhr-Universität Bochum)
• Jean-Pierre Seifert (Technische Universität Berlin)
• Claus Stark (Citigroup AG)
• Martin Steinebach (Fraunhofer SIT)
• Reinhard von Hanxleden (Christian-Albrechts-Universität zu Kiel)
• Carsten Willems (Ruhr-Universität Bochum)
• Sven Wohlgemuth (National Institute of Informatics, Japan)
Zusätzliche Gutachter
• Rafael Accorsi (Universität Freiburg)
• Gökhan Bal (Goethe-Universität Frankfurt am Main)
• Zinaida Benenson (Friedrich-Alexander-Universität Erlangen-Nürnberg)
• Sebastian Biedermann (Technische Universität Darmstadt)
• Tino Brade (Otto-von-Guericke-Universität Magdeburg)
• Christian Broser (Universität Regensburg)
• Andreas Dewald (Universität Mannheim)
• Sebastian Ertel (Technische Universität Dresden)
• Linus Feiten (Universität Freiburg)
• Daniel Fett (Universität Trier)
• Marco Ghiglieri (Technische Universität Darmstadt)
• Oliver Gmelch (Universität Regensburg)
• Tim Grebien (Christian-Albrechts-Universität zu Kiel)
• Sabri Hassan (Universität Regensburg)
• Uwe Hentschel (Universität Potsdam)
• Paula Herber (Technische Universität Berlin)
• Johannes Hoffmann (Ruhr-Universität Bochum)
• Ralf Hund (Ruhr-Universität Bochum)
• Christine Hundt (Technische Universität Berlin)
• Christian Kahl (Goethe-Universität Frankfurt am Main)
• Lukas Kalabis (Technische Universität Darmstadt)
• Matthias Kirchner (Westfälische Wilhelms-Universität Münster)
• Daniel Kraschewski (Karlsruher Institut für Technologie)
• Christoph Krüger (Christian-Albrechts-Universität zu Kiel)
• Marc Kührer (Ruhr-Universität Bochum)
• André Martin (Technische Universität Dresden)
• Christian Moch (Friedrich-Alexander-Universität Erlangen-Nürnberg)
• Michael Müter (Daimler AG)
• Michael Netter (Universität Regensburg)
• Christian Neuhaus (HPI Universität Potsdam)
• Andreas Peter (Technische Universität Darmstadt)
• Marcel Pockrandt (Technische Universität Berlin)
• Robert Reicherdt (Technische Universität Berlin)
• Andreas Reisser (Universität Regensburg)
• Konrad Rieck (Universität Göttingen)
• Ahmad Sabouri (Goethe-Universität Frankfurt am Main)
• Matthias Sauer (Universität Freiburg)
• Alexander Schacht (HPI Universität Potsdam)
• Dirk Scheuermann (Fraunhofer SIT)
• Andre Schmitt (Technische Universität Dresden)
• Christian Schneider (Christian-Albrechts-Universität zu Kiel)
• Christoph Daniel Schulze (Christian-Albrechts-Universität zu Kiel)
• Miro Spönemann (Christian-Albrechts-Universität zu Kiel)
• Christoph Steup (Otto-von-Guericke-Universität Magdeburg)
• Daniel Stöhr (Technische Unversität Berlin)
• Martin Stopczynski (Technische Universität Darmstadt)
• Dirk Tetzlaff (Technische Univeristät Berlin)
• Max Tuengerthal (Universität Trier)
• Fatbardh Veseli (Goethe-Universität Frankfurt am Main)
• Andreas Vogt (Universität Trier)
• Michael Weber (Universität Regensburg)
• Robert Wierschke (HPI Universität Potsdam)
• Ralf Wimmer (Universität Freiburg)
• Philipp Winter (Karlstad University, Sweden)
• Lars Wolos (Goethe-Universität Frankfurt am Main)
• Sebastian Zug (Otto-von-Guericke-Universität Magdeburg)
Inhaltsverzeichnis
Eingeladene Sprecher
Christian Cachin
Sicherheits-Forschung fü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 Endgerä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 Löhr
Identifikation von Videoinhalten über granulare Stromverbrauchsdaten 35
Andreas Dewald, Felix C. Freiling, Thomas Schreck,
Michael Spreitzenbarth, Johannes Stüttgen, Stefan Vö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
Christina Brzuska, Özgür Dagdelen, Marc Fischlin
TLS, PACE, and EAC: A Cryptographic View at Modern Key Exchange
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Lassaad Cheikhrouhou, Werner Stephan, Özgür Dagdelen,
Marc Fischlin, Markus Ullmann
Merging the Cryptographic Security Analysis and the Algebraic-Logic
Security Proof of PACE . . . . . . . . . . . . . . . . . . . . . . . . .
83
Detlef Hühnlein, Dirk Petrautzki, Johannes Schmölz, Tobias Wich,
Moritz Horsch, Thomas Wieland, Jan Eichholz, Alexander Wiesmaier,
Johannes Braun, Florian Feldmann, Simon Potzernheim, Jörg Schwenk,
Christian Kahlo, Andreas Kühne, 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 für Mix-Implementierungen und
ihre Umsetzung als Open-Source-Framework . . . . . . . . . . . . . 123
Markus Engelberth, Jan Göbel, Christian Schö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-Wertschö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 Krätzer,
Jana Dittmann
Designansatz und Evaluation von Kindgerechten Securitywarnungen
fü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, Félix Gómez Má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
Sicherheits-Forschung für die Cloud - Heisse Luft oder
Wolke Sieben?
Christian Cachin
IBM Research – Zurich
Säumerstrasse 4
CH-8803 Rüschlikon, Schweiz
cca@zurich.ibm.com
Abstract: Seit dem Erscheinen von Cloud-Computing sind viele neue Bedenken gegenüber Big Brother“ aufgekommen. Dennoch nutzen Privatleute und Firmen heu”
te die Cloud, weil sie so praktisch ist - und behalten dabei ein mulmiges Gefühl im
Bauch zurück. Ihre größten Bedenken betreffen die Sicherheit und Zuverlässigkeit von
Cloud-Diensten. Da aber langfristige Erfahrungen mit der Cloud bis heute fehlen, sind
beide Größen noch weitgehend Unbekannte.
Besondere Sichtbarkeit erlangen daher Forschungsresultate, die darauf abzielen,
die Benutzer und ihre Daten vor Problemen in der Cloud zu schützen. Diese Arbeiten sollen Geheimhaltung und Integrität der Daten garantieren und die Zuverlässigkeit
der bezogenen Dienste sicherstellen. Dieser Vortrag präsentiert und analysiert einige Trends aus dieser Forschung: erstens, die Verarbeitung von verschlüsselten Daten durch Homomorphic Encryption“, zweitens, die Konsistenz von verteilten Spei”
cherdiensten und, drittens, hochverfügbare Systeme, welche auch teilweise von einem
Gegner unterwandert noch weiterlaufen können (sog. Byzantine Fault-Tolerant Sys”
tems“).
IT Security - Effiziente Organisation über Governance
hinaus
Hinrich Voelcker
Deutsche Bank
Alfred-Herrhausen-Allee 16-24
D-65670 Eschborn
hinrich.voelcker@db.com
Abstract: Die Sicherheit der IT-Systeme ist nicht zuletzt durch das breite Interesse der Medien und Öffentlichkeit zu einem ausgesprochen wichtigen Thema jedes
Wirtschaftunternehmens geworden. Vertraulichkeit, Verfügbarkeit und Integrität der
Unternehmens- und Kundendaten ist überlebenswichtig - gerade in Bezug auf die
Reputation. Besonders Banken leben von der Vertrauenswürdigkeit gegenüber ihren
Kunden. Während die Regulatoren des Finanzwesens schon immer auf die Einhaltung
eines hohen Standards der IT-Sicherheit achteten, richtet sich auch deren Augenmerk
noch stärker als bisher auf die Sicherheit der IT-Systeme. Auslöser hierfür sind nicht
zuletzt die steigende Anzahl und zunehmende Professionalität von Cyberangriffen
gegen Unternehmen zu deren Abwehr die Implementierung von ”Game-ChangingTechnologies”, wie proaktive Cyber-Intelligence-Lösungen, eine immer wichtigere
Rolle spielt.
Während einzelne Lösungen zur IT-Sicherheit auch nur einzelne Probleme und
mö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 für die Durchsetzung dieses Ziels ist ein zentral aufgestellter IT Security-Bereich mit einer hohen
Visibilität und globalen Verantwortung fü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
jens.braband@siemens.com
Abstract: Yin und Yang stehen in der chinesischen Philosophie für Gegensätze, z. B.
Krä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 erlä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 erläutert.
Es wird ein Ansatz vorgestellt, der es ermöglichen soll, Safety- und Security-Eigenschaften in der Kommunikationssicherheit soweit möglich zu orthogonalisieren, um
insbesondere auch die Aspekte der Zulassung bzw. Zertifizierung soweit möglich zu
trennen. Dabei wird auch verschiedene Ansä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
volkmar.lotz@sap.com
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
xuebing.zhou@cased.de
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
Endgeräte
Zinaida Benenson
Universität Erlangen-Nürnberg
zinaida.benenson@cs.fau.de
Olaf Kroll-Peters
EnBW AG
o.kroll-peters@enbw.com
Matthias Krupp
Universität Mannheim
matthias.krupp@web.de
Abstract: Mobile Endgeräte werden immer leistungsfähiger und damit wächst für die
Nutzer auch das Gefahrenpotenzial durch typische IT-Sicherheitsbedrohungen. Obwohl die Verantwortung des Benutzers fü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 Endgeräte unternommen, indem anhand von Interviews entsprechende mentale Modelle erstellt werden. Als mentale Modelle werden Abbildungen der Realitä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 für die Bemühungen der Nutzer (oder für das Fehlen solcher Bemühungen), die
IT-Sicherheit ihrer Systeme zu gewährleisten.
1 Einleitung
Die Anzahl sowie Leistungsfähigkeit mobiler Endgeräte nimmt im Verlauf der letzten Jahre immer stärker zu und damit wä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 Abhören der Datenübermittlung und das Ausspähen
von Standortinformationen ausgesetzt. Auf der anderen Seite bestehen auch menschliche
Bedrohungen wie Verlust, Diebstahl, Fehlbedienung und Social Engineering. In beiden
Fällen nehmen Benutzer einen bedeutenden Anteil für das Umsetzen von IT-Sicherheit
mobiler Endgerä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 Endgeräte nicht ausreichend
bekannt. In dieser Arbeit unternehmen wir die ersten Schritte zur Feststellung mentaler
Modelle der IT-Sicherheit bei der Benutzung mobiler Endgeräte. Mentale Modelle charakterisieren die individuelle Repräsentation und das Verständnis von Realität, beeinflusst
durch Erfahrungen, Empfindungen und Informationen, im Bewusstsein von Menschen.
8
Im Abschnitt 2 wird zunächst ein Überblick 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 Endgeräte vorgestellt.
Anschließend werden im Abschnitt 4 die Ergebnisse der Arbeit diskutiert und schließlich
im Abschnitt 5 weiterführende Arbeiten vorgeschlagen.
2 Mentale Modelle in der IT-Sicherheit
Erste mentale Modelle für den Themenkomplex der IT-Sicherheit erstellten Camp et al.
[ALC07, Cam09]. Sie unterscheiden fünf Metaphern der IT-Sicherheit: physische Sicherheit (z.B. Schlösser), medizinische Infektionen (Viren), kriminelles Verhalten (Einbrecher), Kriegsführung und wirtschaftliches Versagen (Schwachstellen in der Software).
Implizite Beschreibungen der mentalen Modelle der IT-Sicherheit finden sich hä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 gefährlich“. Hä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 Passwörter, die ihnen besser im Gedächtnis bleiben [AS99, FH07, FCB07].
Fü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 Rückmeldung der Nutzer haben möchten, haben dazu geführt, dass die Anwender herausgefunden
haben, welchen Knopf sie drücken müssen, um ungestört ihrer Arbeit weiter nachgehen
zu kö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 Endgerä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 Endgeräte
Ein erster Überblick über den Themenkomplex Anwender und ihr mobiles Endgerät“
”
wurde durch die Erstellung einer Pilotstudie verschafft. In der Hauptuntersuchung wurden
anschließend mentale Modelle der IT-Sicherheit bei der Nutzung mobiler Endgeräte erstellt. Beide Untersuchungen wurden anhand eines Fragebogens als Leitfaden-Interviews
durchgeführt.
3.1
Pilotstudie
In der Pilotstudie wurde die Nutzung mobiler Endgeräte betrachtet. Es haben sich zwei
mentale Grundmodelle bei der Nutzung mobiler Endgeräte herauskristallisiert. Zum einen
gibt es Anwender, die ihr Endgerät nur als konventionelles Telefon-Gerät sehen. Trotz
eines deutlich größeren Funktionsumfanges, nutzen sie ihr Gerät fast ausschließlich zum
Telefonieren oder Schreiben von Kurznachrichten. Zum anderen gibt es Nutzer, die ihr
Endgerät als Smartphone sehen. Bei diesen übersteigt die tägliche Nutzung deutlich den
Rahmen konventioneller Telefon-Gerä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 Endgeräts befassen. Sie fühlen sich oft sicher bei der Nutzung ihres mobilen Endgeräts, ohne sich in den Themenkomplex einzuarbeiten oder eigene Anstrengungen
fü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 Endgeräte.
3.2.1
Hypothesen
Auf Grundlage der Untersuchungen und Ergebnisse der Pilotstudie wurden unter anderem
folgende Hypothesen aufgestellt:
• H1: Benutzer, die ihr Gerät als Smartphone sehen, haben ein größeres Sicherheitsbewusstsein als Benutzer, die ihr Gerät als Telefon sehen.
10
• H2: Benutzer, die ihr Gerät als Smartphone sehen, fühlen sich weniger sicher, als
Benutzer, die ihr Gerät als Telefon sehen.
• H3: Benutzer sehen sich selbst nicht für die Sicherheit ihrer Geräte verantwortlich.
• H4: Benutzer bringen Probleme bei der Benutzung ihres Endgeräts nicht mit ITSicherheit in Verbindung.
• H5: Um für ihre IT-Sicherheit im mobilen Umfeld zu sorgen, ist die Hauptanstrengung der Benutzer der bewusste Umgang mit dem Gerät.
Die beiden Begriffe Sicherheitsbewusstsein“ und bewusster Umgang“ werden weiter
”
”
unten erläutert. Eine ausführliche und vollständige Beschreibung der Hypothesen und der
dazugehörigen Ergebnisse findet sich in Krupp [Kru11].
3.2.2
Versuchsbeschreibung
Um die aufgestellten Hypothesen zu evaluieren, wurden persönliche Leitfragen-Interviews
mit 24 Versuchspersonen durchgeführt. Das Alter der Befragten lag zwischen 18 und 50
Jahren, die Hälfte war männlich und fünf waren beruflich im IT-Umfeld tätig.
Die Interviews orientierten sich an einem zweiteiligen Fragebogen (s. Anhang A). Die
Schwierigkeit einer aussagekräftigen Evaluation besteht darin, dass sich die Teilnehmer
dem Untersuchungsfokus und der Untersuchungssituation nicht bewusst sein dü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 Endgeräte im Fokus. Hierbei wurden die Teilnehmer unter anderem zu regelmäßig genutzten Diensten, zu Eigenschaften,
die sie mit der Nutzung mobiler Endgeräte verbinden, zu Problemen bei deren Nutzung
und Kenntnissen zum Schutz mobiler Endgeräte befragt. Weiterhin wurde gefragt zu welchem Anteil sie sich selbst und die Hersteller von Programmen oder Hardware in der
Verantwortung für die Umsetzung von IT-Sicherheit bei mobilen Endgerä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 Endgerätes ist und welche Anstrengungen sie für die Umsetzung
unternehmen. Ob sie sich bei der Nutzung ihres Endgeräts sicher fühlen und welche Daten
ihrer Meinung nach auf dem Endgerät bedroht sind. Abschließend wurde eine Frage zu
einer erweiterten Sicherheitseinstellung gestellt, um die Selbsteinschätzung der Befragten
bezüglich ihrer Kenntnisse besser einordnen zu können.
3.2.3
Evaluierung der Hypothesen
H1: Benutzer, die ihr Gerät als Smartphone sehen, haben ein größeres Sicherheitsbewusstsein als Benutzer, die ihr Gerä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 Endgerät als konventionelles Telefon und
13 als Smartphone. Sieben der 13 Befragten (54 %), die ihr mobiles Endgerät als Smartphone sehen, gaben an, dass sie über gute Kenntnisse zum Schutz mobiler Endgeräte verfügen würden (s. Abbildung 1(a)). Fünf der Smartphone-Benutzer (38 %) ordneten sich
mit Grundkenntnissen ein. Die Hälfte dieser Benutzer beantwortete die Kontrollfrage korrekt.
(a) Wie schätzen Sie ihr Wissen bezüglich des
möglichen Schutzes ihres mobilen Endgeräts ein?
(b) Wie schätzen Sie ihr Interesse
bezüglich der Sicherheit von mobilen
Endgeräten und ihrer Daten ein?
Abbildung 1: Ergebnisse zu Hypothese 1
Bei den 11 Befragten, die ihr Endgerät als Telefon sehen, gaben lediglich vier Befragte
an, dass sie mindestens gute Kenntnisse über den Schutz mobiler Endgeräte verfü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 Endgeräts haben.
Abbildung 1(b) zeigt, dass sechs der elf Befragten nur ein geringes bzw. gar kein Interesse
an der Sicherheit ihres Endgeräts haben.
Bei den Befragten, die ihr Endgerät als Smartphone sehen, ist das Interesse sichtbar stärker
ausgeprägt. Sechs Studienteilnehmer gaben ein mittleres, weitere sechs ein hohes Interesse
an.
Die Teilnehmer wurden in einer offenen Frage zu ihnen bekannten Bedrohungen im mobilen Umfeld befragt. Die Gruppierung der Antworten ergab eine Übereinstimmung zu
den sechs Gruppierungen des Malicious Mobile Threats Report 2010/2011“ von Juniper
”
[Jun11]: Abhören von Datenü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 eingeschä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 verhältnismäßig gut eingeschä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 eingeschätzten Kenntnissen
Zusammenfassend zeigen die Ergebnisse, dass Anwender, die ihr mobiles Endgerät als
Smartphone sehen, bessere Kenntnisse zum Schutz und ein größeres Interesse an der Sicherheit mobiler Endgeräte haben. Somit konnte die erste Hypothese belegt werden.
(a) Fühlen Sie sich bei der Benutzung
ihres Endgeräts sicher?
(b) Welche Daten auf ihrem Endgerät sind ihrer
Meinung nach bedroht?
Abbildung 3: Ergebnisse zu Hypothese 2
H2: Benutzer, die ihr Gerät als Smartphone sehen, fühlen sich weniger sicher, als
Benutzer, die ihr Gerät als Telefon sehen. 17 der 24 Befragten gaben an, dass sie sich
bei der Nutzung ihres mobilen Endgeräts sicher fühlen (s. Abbildung 3(a)).
Dies zeigt ein insgesamt hohes Sicherheitsgefühl der Anwender. Die Betrachtung der beiden Grundmodelle zeigt, dass sich deutlich weniger Smartphone-Anwender bei der Nutzung ihres Endgeräts sicher fühlen. Gründe für die Unsicherheit sind nach Ansicht dieser
Nutzer die Überwachung von Datenflüssen und das Aufzeichnen von Standortdaten.
Das höhere Sicherheitsempfinden der Telefonanwender führten diese darauf zurück, dass
sie mit ihrem Endgerät nicht ins Internet gehen. Als weitere Gründe gaben sie an, dass
sie nicht wichtig genug für einen Angreifer wären und dass sie keine wichtigen Daten auf
13
ihrem Endgerät hätten.
Abbildung 3(b) zeigt, dass nach Ansicht aller Befragten besonders das Adressbuch und
Telefonbuch sowie die Standortinformationen auf dem mobilen Endgerät bedroht sind.
Die Telefon-Anwender sehen durchschnittlich deutlich weniger Daten auf dem mobilen
Endgerät bedroht. Damit kann die zweite Hypothese belegt werden.
H3: Benutzer sehen sich selbst nicht für die Sicherheit ihrer Geräte verantwortlich.
Um herauszufinden bei wem die Befragten die Verantwortung für die Sicherheit mobiler
Endgerä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 Hälfte der Verantwortung auf die Programmhersteller
fä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 für die Sicherheit von mobilen Endgeräten verantwortlich sein?
Anwender, die ihr Gerät als Telefon sehen, sehen den Benutzer am wenigsten in der Verantwortung fü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 Präferenz dazu, den Programm- und Hardwareherstellern die Verantwortung für die Sicherheit ihrer Gerä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 Endgeräts nicht mit ITSicherheit in Verbindung. Im Zuge des ersten Teils der Befragung wurden die Teilnehmer gefragt, ob sie bei der Nutzung ihrer Gerä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 Endgeräts zurückführen, wie z.B. das Aufhängen bzw.
Abstürzen des Gerä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 Endgerä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 Endgerät angaben, dabei aber keine Sicherheitsprobleme erwä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 Endgeräte nicht in den mentalen Modellen der Anwender verankert haben. Das
könnte damit zusammenhängen, dass die Teilnehmer bisher sehr wenig mit solchen Problemen konfrontiert wurden.
H5: Um für ihre IT-Sicherheit im mobilen Umfeld zu sorgen, ist die Hauptanstrengung der Benutzer der bewusste Umgang mit dem Gerät. Die Interviewpartner wurden gebeten, anhand vorgegebener Sicherheitsvorkehrungen anzugeben, welche Anstrengungen sie unternehmen, um für die eigene IT-Sicherheit im mobilen Umfeld zu sorgen.
Bewusster Umgang mit dem Gerät ist die populärste Sicherheitsmaßnahme (s. Tabelle 1).
Nur 8 % der Befragten gaben an, dass sie sich nie mit dem bewussten Umgang ihres Endgeräts auseinandersetzen. Während die Mehrzahl der Smartphone-Anwender versucht immer auf einen bewussten Umgang zu achten, gaben 64 % der Telefon-Anwender an, sich
gelegentlich darum zu kümmern. Unter bewusstem Umgang verstehen die Teilnehmer,
dass sie unter anderem bei der Nutzung ihres Endgerä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 Hälfte aller Anwender, die ihr Endgerä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 regelmäßig den Passwortschutz auf ihren mobilen Endgeräten und 21 % nutzen ihn
gelegentlich. Insbesondere fallen die 62 % der Smartphone-Anwender auf, die den Passwortschutz regelmäßig einsetzen. Ähnliche Werte gelten für Updates, Virenscanner sind
weniger populär. Im PC-Umfeld dagegen gibt es regelmäßig Studien, die zeigen, dass über
75 % einen Virenscanner auf ihrem PC installiert haben [BIT10, BSI11]. Gründe für diese
Ergebnisse könnten u.a. in den Voreinstellungen der Geräte liegen, wurden in dieser Arbeit
jedoch nicht weiter untersucht.
Somit konnte die fünfte Hypothese belegt werden. 88 % der Teilnehmer gaben an wenigstens gelegentlich auf den bewussten Umgang mit dem mobilen Endgerä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 kümmere
mich
gelegentlich um
die Thematik
21%
27%
15%
21%
27%
15%
13%
18%
8%
42%
64%
23%
50%
36%
62%
Ich kü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 fü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 Fehlerzustände verursachen.
4 Mentale Modelle der Sicherheit mobiler Endgeräte
Unsere Untersuchung zeigt, dass die Benutzer der mobilen Endgeräte in zwei Kategorien
unterteilt werden können, die sich deutlich hinsichtlich ihrer Einstellung zur IT-Sicherheit
ihrer Geräte unterscheiden. Die mein Gerät ist ein Telefon“-Einstellung ist unabhängig
”
vom Funktionsumfang des Geräts und hängt mit einem niedrigeren Sicherheitsbewusstsein
und einem höheren Sicherheitsgefühl zusammen, als die mein Gerät ist ein Smartphone“”
Einstellung. Insbesondere Telefon-Benutzer“ sehen sich selbst nicht für die Sicherheit
”
ihrer Gerä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 persönlich nicht bedroht sind, da sie nicht wichtig genug sind oder keine wichtigen Daten auf ihrem Gerät
speichern. Hier sind die Parallelen zur Risikoeinschä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 Endgeräte
nicht mit IT-Sicherheit sondern ausschließlich mit der Bedienung und den Eigenheiten der
Gerä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 beschränken sich die Anstrengungen zur Zeit fast ausschließlich auf den bewussten Umgang mit dem Gerät. Die Befragten gaben unter anderem an, dass sie sichere Applikationen nutzen, auf unseriöse Dienste verzichten und nicht
ungeachtet jegliche Links anklicken würden. Zusätzlich hielten sie ihr Datenvolumen so
niedrig wie möglich und achten darauf, nicht ungeschützt über Verbindungsprotokolle wie
beispielsweise Bluetooth oder WLAN erreichbar zu sein.
Es scheint, dass viele Benutzer ein ich werde Gefahren für mein Gerät auf jeden Fall
”
erkennen können“-mentales Modell haben. Ob dieses Modell tatsä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
Endgeräten hatten oder ob sie solche Probleme noch nicht erkannt haben.
5 Fazit und Weiterführende Arbeiten
Unsere Studie zeigte erste Einblicke darin, wie die Nutzer die Sicherheit ihrer mobilen
Endgeräte wahrnehmen und wie sie ihre Geräte schützen.
Obwohl die Nutzer wissen, dass viele Daten auf ihrem mobilen Endgerät bedroht sind,
fühlen sie sich bei der Nutzung zum Großteil sicher. Unternehmen die Befragten eigene
Anstrengungen für den Schutz im mobilen Umfeld, konzentrieren sich diese häufig auf den
bewussten Umgang mit dem Gerät. Anwender mit guten Kenntnissen nehmen zusätzlich
zum Schutz technische Sicherheitsvorkehrungen, wie das Nutzen eines Passwortschutzes
oder das regelmäß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 Selbsteinschätzung der Nutzer zu ihren Sicherheitskenntnissen mit den tatsächlichen Kenntnissen korreliert.
Der bewusste Umgang mit dem mobilen Endgerät stellte sich als Hauptanstrengung der
Nutzer zur Sicherstellung von IT-Sicherheit im mobilen Umfeld dar. Die Nutzer beschrieben den bewussten Umgang häufig damit, dass sie keine unseriösen Applikationen installieren, auf ihr Surfverhalten im Internet achten und nicht ungeschü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. Darüber hinaus stellt sich
die Frage, ob die Anwender tatsächlich über ausreichend Wissen verfügen, um die Unterscheidung zwischen sicheren und unsicheren Applikationen, Links und Einstellungen des
Geräts vornehmen zu können.
Ein weiterer Punkt für zukünftige Untersuchungen ist die Frage, ob die Nutzer unterschiedliche Sichtweisen auf PCs und auf mobile Endgeräte haben. Moderne mobile Endgeräte werden immer leistungsfähiger, haben einen immer größeren Funktionsumfang und
ähneln immer mehr den PCs. Dennoch scheinen die Anwender noch wenige Parallelen
zur PC-Welt zu ziehen und schützen sich im PC-Umfeld in viel stä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 fü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 Endgeräten
Einleitung zum Fragebogen:
Ziel des Fragebogens ist es das Verhalten von Anwendern im Umgang mit mobilen Endgerä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 Endgeräten. Im zweiten Teil steht
darauf aufbauend die weitere Nutzung von mobilen Endgeräten im Fokus.
Hinweis zum Datenschutz:
Die Daten werden anonymisiert erhoben und dienen nur zu Forschungszwecken. Der Fragebogen ist so konzipiert, dass kein Rückschluss auf den Befragten möglich ist.
Falls Sie eine Frage nicht beantworten möchten oder können, lassen Sie die Antwort einfach offen.
Vielen Dank für ihre Bereitschaft den Fragebogen auszufüllen!
20
Teil A
1. Ihr Geschlecht:
❐ Weiblich
❐ Männlich
2. Ihr Alter:
❐ jü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 Endgerät (Handy oder Smartphone)?
❐ Ja
❐ Nein
5. Spielt das Betriebssystem ihres mobilen Endgeräts für Sie eine relevante Rolle?
❐ Ja
❐ Nein
6. Welche Eigenschaften (Spaß, Erreichbarkeit, Streß etc.) verbinden Sie mit der Nutzung ihres Endgeräts?
7. Besitzt ihr Endgerät die Möglichkeit eigenständig Applikationen zu installieren?
❐ Ja
❐ Nein
8. Welche Dienste nehmen Sie privat am meisten in Anspruch?
9. Welche Dienste wünschen Sie sich zusätzlich?
21
10. Besitzen Sie neben ihrem privaten mobilen Endgerät auch ein Firmengerät?
❐ Ja
❐ Nein
11. Wenn ja, wie unterscheidet sich die Benutzung?
12. Welche der folgenden Programme nutzen Sie? (Mehrfachnennungen sind möglich)
privates Endgerät:
Firmenendgerät:
❐ E-Mail
❐ E-Mail
❐ Internet
❐ Internet
❐ Geldgeschäfte über Internet,
❐ Geldgeschä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 Endgeräts?
❐ Ja
❐ Nein
14. Wenn ja, welche?
15. Wie schätzen Sie ihr Wissen bezüglich des möglichen Schutzes ihres mobilen Endgerä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 für die Sicherheit von mobilen Endgeräten verantwortlich sein? (Bitte
verteilen Sie insgesamt 100 % auf die drei angegebenen Antwortmöglichkeiten)
%
• Hersteller von Programmen
• Hersteller von Hardware
%
%
• Benutzer
18. Welche Bedrohungen, speziell bezogen auf mobile Endgeräte, kennen Sie?
23
Teil B
1. Wie schätzen Sie ihr Interesse bezüglich der Sicherheit von mobilen Endgeräten und
ihrer Daten ein?
❐ hoch
❐ mittel
❐ niedrig
❐ kein
2. Hatten Sie auf Ihrem mobilen Endgerät schon einmal Sicherheitsprobleme?
privates Endgerät:
Firmenendgerä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. Fühlen Sie sich bei der Benutzung ihres Endgeräts sicher?
❐ Ja
❐ Nein
Begründung:
6. Welche Daten auf ihrem Endgerät sind ihrer Meinung nach bedroht (Mehrfachnennungen sind möglich)?
❐ Adressbuch/Telefonbuch
❐ Nachrichteninhalte (SMS/E-Mail)
❐ sonstige gespeicherte Informationen (Notizen, etc.)
❐ Standortinformationen
❐ weitere:
24
7. Welche eigenen Anstrengungen unternehmen Sie, um für IT-Sicherheit im mobilen
Umfeld zu sorgen (Mehrfachnennungen sind möglich und erwünscht)?
Virenscanner
Passwortschutz
Updates
bewusster Umgang
Verschlüsselung
Informieren über ITSicherheitsrisiken
Ich versuche
immer auf
dem neuesten
Stand zu sein
❐
❐
❐
❐
❐
Ich kümmere
mich
gelegentlich um
die Thematik
❐
❐
❐
❐
❐
Ich kü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
jan.zibuschka@iao.fraunhofer.de
heiko.rossnagel@iao.fraunhofer.de
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, Jürjen’s UMLSec [Jü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 Gü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 Günnewig, Kai Rannenberg, Ahmad-Reza Sadeghi, and Christian Stüble. Trusted
Computing Platforms: Zur technischen und industriepolitischen Situation und Vorgehensweise. In Vertrauenswü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 Úlfar 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, Valérie Issarny, and Simon Shiu, editors, Trust Management, volume 3477,
pages 93–107. Springer Berlin Heidelberg, Berlin, Heidelberg, 2005.
[Jür02]
Jan Jürjens. UMLsec: Extending UML for Secure Systems Development. In Jean-Marc
Jézé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 fü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 über granulare
Stromverbrauchsdaten∗
Ulrich Greveler, Benjamin Justus, Dennis Löhr
Labor für IT-Sicherheit
Fachhochschule Münster
Stegerwaldstraße 39
48565 Steinfurt
{greveler|benjamin.justus|loehr}@fh-muenster.de
Abstract: Sekundenscharfe Ablese-Intervalle bei elektronischen Stromzählern stellen
einen erheblichen Eingriff in die Privatsphäre der Stromkunden dar. Das datenschutzrechtliche Gebot der Datensparsamkeit und Datenvermeidung steht einer feingranularen Messhäufigkeit und der vollständigen Speicherung der Stromverbrauchsdaten
entgegen.
Wir können experimentell nachweisen, dass neben der Erkennung von im Haushalt
befindlichen Geräten eine Erkennung des Fernsehprogramms und eine Identifikation
des abgespielten Videoinhalts mö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 Gerätes waren unverschlüsselt
und nicht signiert.
Keywords. Smart Meter, Data Privacy, Audiovisual Content, Smart Grid
1 Einführung
Bundesweit und auch im europäischen Rahmen ist die Einführung von intelligenten Strommessgeräten (Smart Metern) geplant, die vorhandene Stromzähler ersetzen sollen. Stromkunden können mithilfe dieser Geräte detaillierte Informationen über den Stromverbrauch
erhalten und sind in der Lage, Stromverbraucher zu identifizieren, Ursachen für hohen
Verbrauch zu bestimmen und damit Abhilfe zu schaffen, d. h. insbesondere Stromverbrauchskosten zu senken (Förderung des bewussten Energieverbrauchs).
Für Stromverkäufer und Netzbetreiber sind granulare Verbrauchsdaten ebenfalls von Interesse, da diese zu Planungszwecken, Ausführung von Netzoptimierungen, Vorhersage
von Lastspitzen und informierte Beratungen der Kunden herangezogen werden kö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 veröffentlicht wurden.
36
Identifikation von Videoinhalten über granulare Stromverbrauchsdaten
le Zähler, die den tatsächlichen Verbrauch und die tatsächliche Nutzungszeit feststellen
[Ren11], vor. Mittelfristig ist daher damit zu rechnen, dass sich Smart Meter gegenüber
bisherigen Stromzählern bei Neuverlegungen und dem Austausch alter Zähler durchsetzen.
Aufgrund der Aufzeichnung personenbezogener Verbrauchsdaten durch Smart Meter ergeben sich Anforderungen an Datenschutz und Datensicherheit. Abhängig von der Genauigkeit der Messung und der zeitlichen Auflösung können nach Auswertung der erhobenen
Daten Rückschlüsse auf die Verhaltensweisen der sich im Haushalt aufhaltenden Menschen gezogen werden; die Granularität heute eingesetzter Geräte sieht Messpunkte im
Abstand von einer Stunde, viertelstündlich, minütlich bis hin in den Sekundenbereich vor.
2 Verwandte Arbeiten
Wie von Molina-Markham et al. [AMSF+ 10] beschrieben wurde, können Daten, die ca.
viertelstü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. Erhöht man die Granularität in den Minuten- oder Sekundenbereich, sind auch
Aussagen möglich, ob das Frühstück warm oder kalt zubereitet wurde, wann Wä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 Geräten anhand charakteristischer Lastkurven, wodurch die
Aktivitäten der im Haushalt befindlichen Personen nachvollziehbar werden [Qui09].
Hinweise auf Datenschutzaspekte in Bezug auf die Einführung von Smart Metern sind
Teil der öffentlichen Diskussion um den Nutzen und die Risiken der Technologie. [Bö11,
AMSF+ 10, Ren11] Es wurden zudem Gegenmaßnahmen, die den Datenschutz bei der
Einführung von Smart Metern stärken sollen, vorgeschlagen: Schlüsselhinterlegung zur
anonymen Authentikation [EK10], Reduktion verrä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 unabhängig zu den von den Autoren durchgeführten Experimenten mit Stromzä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 [Bö11].
37
3 Experimentelle Ergebnisse
Die Untersuchungsergebnisse beziehen sich auf die Fragestellung: Welche Auswertungsmöglichkeiten stehen in der Praxis zur Verfügung und welche Qualität haben die von
tatsächlich im Feld befindlichen geeichten Smart Metern erhobenen Daten? Welche Rückschlüsse auf personenbezogenes Verhalten können erfolgreich gewonnen werden?
3.1
Hardware
Getesteter Smart Meter: Das Gerä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 Gerät ersetzte den bisherigen von der RWE AG verbauten Stromzä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-Lösung verwendet als Modul einen Smart Meter2 der Firma EasyMeter GmbH, Bielefeld (Elektronischer 3-Phasen 4-Leiter Zähler Q3D, Messung im zweiSekunden-Intervall) und eine selbst entwickelte Lö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
Übertragung der Verbrauchsdaten
Die Übermittlung der Daten vom Smart Meter zum Discovergy-Server erfolgt über TCP/IP.
Das Gerät wird direkt mit dem heimischen LAN/DSL-Router verbunden und erhält von
diesem über DHCP seine IP-Adresse. Entgegen den vertraglichen Angaben erfolgt die
Übertragung jedoch nicht verschlüsselt. Die Daten werden in einem textbasierten Format
übertragen, so dass sie ohne weitere Decodierung abgelesen werden können. In Abb. 1 ist
eine solche Übertragung, 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 aufgefü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 Zähl- und Messwesens sowie zur Datenaufbereitung in elektronischer Form. [...] Die Übertragung der Daten im Internet erfolgt verschlüsselt.“ Der Abruf
der Daten über die Webschnittstelle war zum Testzeitpunkt nur unverschlüsselt möglich, da TLS nicht unterstützt
wurde. Die automatisierte Übertragung vom Smart Meter zum Server erfolgte im Widerspruch zum Vertragstext
ebenfalls unverschlüsselt.
2 Übermittelte Messwerte gemäß Herstellerangaben: Zä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.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 geschwärzt) könnten Daten für beliebige andere Zähler
”
an den Server übertragen werden, was zwischenzeitlich demonstriert wurde [BCC11]. Der
Smart Meter verfügt jedoch über eine digitale Anzeige des Stromverbrauchs, so dass Daten, die am Zähler abgelesen werden, von einer Verfälschung nicht betroffen sind.
4.1
Auflösung der dem Stromkunden präsentierten Daten
Discovergy stellt einen Web-basierten Zugang zur Visualisierung der Stromverbrauchsdaten zur Verfü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 Auflösung
ihrer gespeicherten Stromverbrauchsdaten einsehen kö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 Auflösung
und korrekte Daten: Abb. 3 zeigt ein kleines Intervall in voller Auflösung, welches in
Abb. 2 (im Teilzeitraum 22.35h-22.50h) enthalten ist.
Genauigkeitsklasse: A, B gemäß EN50470-1
4.2
39
Identifikation von Geräten
Wir konnten die in der Literatur getroffenen Aussagen [Har92, AMSF+ 10, Mü10] bestätigen, dass viele Geräte über ein charakteristisches Stromprofil erkennbar sind. Insbesondere
konnten wir mithilfe der feingranularen Daten identifizieren: Kühlschrank, Wasserkocher,
Durchlauferhitzer, Glühbirne, Energiesparlampe, Kaffee-Padmaschine, Herd, Mikrowelle,
Ofen, Waschmaschine, Geschirrspüler und TV-Gerät.
5 TV/Film-Detektion
5.1
TV-Gerätetechnik
Durch Auswertung des Stromverbrauchs eines im getesteten Privathaushalt vorhandenen TV-Gerätes (Panasonic Viera LCD-TV, HD, 80cm Diag., 130W) konnte nicht nur
die bereits in der Literatur genannte Einschaltzeit [Qui09] identifiziert werden. Es war
darüber hinaus möglich, das eingeschaltete Programm bzw. den abgespielten Film zu
identifizieren, obwohl der eingesetzte Smart Meter den Strom für den gesamten VierPersonenhaushalt misst - also nicht direkt mit dem TV-Gerät verbunden wurde - und die
Daten über den Discovergy-Server abgefragt wurden, d. h. dort in dieser Auflö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 führt
Ein erster Schritt ist die Messung des Stromverbrauchs für eine Folge von Grautö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 für o. g. LCD TV) und ist abhä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ß) für obige Bildersequenz. Man kann von
Hand abzählen, dass bei ab RGB-38-38-38 der Stromverbrauch maximal ist. Diesen Wert
(minimale Helligkeit für maximalen Stromverbrauch) bezeichnen wir mit bmin .
Wir konnten anhand des Messergebnisses eine lineare Abhängigkeit annehmen und prognostizierten den Stromverbrauch fü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 für 2s (k =
1), 4s (k = 2), 6s (k = 3), etc., die wir mit dem tatsächlichen Stromverbrauch korrelieren
können, um den Inhalt zu identifizieren. Abb. 5 zeigt Ergebnisse dieser Vorgehensweise
für drei Filmausschnitte à fünf Minuten. Grü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 können, wenn die im Stromverbrauchsprofil gesuchte 5-minütige Filmsequenz einem
Einschalt- oder Ausschaltvorgang eines beliebigen Gerä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 gewählten Korridoren mit jeweils 5% Höhe liegen, gezählt. Überschreiten diese
einen Schwellenwert von 50% aller Werte, wird der Treffer eliminiert. Abb. 6 zeigt einen
typischen Anwenungsfall, der zur Elimination des Treffers fü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
comsumption
prediction
120
110
100
90
80
70
60
50
0
50
100
150
200
250
300
time (s)
130
comsumption
prediction
120
110
100
90
80
70
60
50
0
50
100
150
time (s)
200
250
300
Abbildung 5: Vorhersage und tatsä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) erfüllt, ausgegeben.
Ergebnis: Bei dieser Vorgehensweise wird fast die Hälfte der gespielten Videosequenzen
anhand des Stromverbrauchs identifiziert. Da ein Film (i.d.R. mind. 90 Minuten) über 18
oder mehr Abschnitte verfügt, ist selbst bei Störungen durch andere Verbraucher (z. B.
Einschalten eines starken rauschenden“ Gerätes3 während der Abspielzeit), eine gewisse
”
Wahrscheinlichkeit gegeben, mehrere nicht wesentlich beeinträchtigte Abschnitte zu identifizieren. Über einen Zeitraum von 24h werden jedoch (bei unserer Datenbasis von 653 Videoinhalten) auch ca. 35 falsche Identifizierungen von 5-Minuten-Abschnitten vorgenommen. Zählt man jedoch nur solche Treffer, bei denen zwei korrespondierende Abschnitte desselben Inhaltes gefunden werden (wie im Beispiel von Abb. 7), wurden sämtliche
False Positives eliminiert. Im Testhaushalt konnten Spielfilminhalte trotz gleichzeitig aktiver elektrischer Geräte in allen Fällen anhand mehrerer Abschnitte identifiziert werden4 .
Aufgezeichnete Fernsehproduktionen, die ein hohes durchgehendes Helligkeitsniveau aufweisen (bspw. Talkshows), können mit LCD-Geräten oft nicht identifiziert werden, da der
gerätespezifische Wert bmin zu niedrig ist.
3 Verbraucher, die eine konstante Last erzeugen (z. B. Lampen, Standby-Geräte, Hifi), wirken sich auf die
Korrelation nicht stö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, Fö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-Gerätemodelle
Die Experimente aus den vorangegangenen Abschnitten wurden mit dem im Testhaushalt
befindlichen LCD-TV5 durchgeführt, das über eine dynamische Hintergrundbeleuchtung
verfügt. Um abzuschätzen, inwieweit andere TV-Modelle ähnliche Rückschlüsse erlauben
bzw. datenschutzfreundliche“ Stromverbrauchsprofile generieren, haben wir die Tests mit
”
einem weiteren (nicht operativen) Smart Meter desselben Typs für weitere Geräte im Labor durchgeführt. In Tab. 1 werden Testergebnisse für unterschiedlichen Videoinhalt aufgeführt. Bei zwei der getesteten Gerä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 Stromzählern stellen einen erheblichen Eingriff in die Privatsphäre der Stromkunden dar. Das datenschutzrechtliche Gebot der Datensparsamkeit und Datenvermeidung steht einer Messhäufigkeit im Sekundenbereich und der
vollständigen Speicherung des Stromverbrauchs entgegen. Eine regelmäßige oder durch
Fernabfrage ermöglichte Übermittlung dieser Daten an Energieversorger oder Netzbetreiber sollte nicht nur einer ausdrücklichen Zustimmung aller im Haushalt lebenden Personen
unterliegen, die Betroffenen sind auch darüber aufzuklären, welche Auswertungsmö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-Gerä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 Granularität der Messdaten ergeben.
Die experimentell festgestellte Tatsache, dass die Daten beim getesteten Anbieter unverschlüsselt und nicht signiert übertragen werden, stellt einen Verstoß gegen Grundsätze von
Datenschutz und Datensicherheit dar. Diese Tatsache wiegt umso schwerer, da beim getesteten Anbieter vertraglich zugesichert wurde, dass die Übertragung verschlüsselt erfolgt6 .
Die prinzipiell vorhandene Möglichkeit, audiovisuelle Inhalte bzw. das eingestellte Fernsehprogramm zu identifizieren, führt zu einer neuen Qualität des Eingriffs in die private
Lebensgestaltung. Die in diesem Beitrag durchgeführten Tests lassen aufgrund der überschaubaren Testdatenbasis (653 Videoinhalte) zwar keine Rückschlüsse zu, inwieweit eine
forensische Auswertung der Stromverbrauchsdaten tatsächlich einen ausreichenden Beweiswert (bspw. zum Nachweis von Verstößen gegen das Urheberrecht) hätte; die Relevanz in Bezug auf die Schutzwürdigkeit der granularen Stromverbrauchsdaten ist aber
bereits dadurch gegeben, dass unter günstigen Umständen eine Identifikation mö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 Sicherheitslücke zwischenzeitlich bestätigt und Abhilfe in naher Zukunft angekü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 Stromzählern. In c’t-Magazin (Heise Verlag), 23/2011, 2011.
[Bö11]
M. Bö. Was moderne Stromzähler verraten kö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.
[Mü10]
K. Müller. Gewinnung von Verhaltensprofilen am intelligenten Stromzä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 Österreich, 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 Stüttgen , Stefan Vömel , und Carsten Willems
1
2
Friedrich-Alexander Universität Erlangen-Nürnberg
3
Ruhr-Universität Bochum
Abstract: Im Oktober 2011 erregte die Veröffentlichung von Details über die inzwischen
meist als BckR2D2 bezeichnete Schadsoftware öffentliches Aufsehen. Mitglieder des Chaos Computer Club e.V. veröffentlichten einen ersten Bericht über die Funktionsweise des
Trojaners, dem weitere Analysen folgten. In dieser Arbeit geben wir einen Überblick
über die bislang veröffentlichen Einzelberichte und über die verschiedenen Komponenten der Schadsoftware sowie deren Funktionsweise. Hierzu präsentiert diese Arbeit die
wesentlichen Ergebnisse einer ausführlichen Analyse aller Komponenten des Trojaners
und geht insbesondere auf Unterschiede zwischen den beiden bislang bekannten Varianten BckR2D2-I und II ein. Ziel dieser Arbeit ist auch die kritische Überprüfung 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 Presseerklärung sowie eines dazugehörigen
20-seitigen Berichts veröffentlicht [Cha11d, Cha11b]. In diesem werden einzelne Programmfunktionen und insbesondere der eingesetzte Verschlüsselungsmechanismus detailliert dargestellt. F-Secure, ein bekannter Hersteller von Anti-Viren-Software, berichtete wenige Tage
spä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
später verö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 Verschlü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 Wü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
Ausgangspunkt unserer Arbeit war die von uns als BckR2D2-I bezeichnete Variante der Schadsoftware. Diese wurde uns von Rechtsanwalt Patrick Schladt zur Verfü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 verö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 Zusätzlich wurde uns eine Version des Droppers [FS11, Cha11e, Wer11] von
einem Hersteller von Antiviren-Software zur Verfü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 zugehö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
Softwarebibliothek
Abbildung 1: Herkunft und Komponenten der unterschiedlichen Versionen von BckR2D2.
Ziel dieser Arbeit ist es, einen unabhängigen Überblick 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 Einschrä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 erläutert.
Im Zuge dessen werden insbesondere die in unterschiedlichen Quellen [Cha11b, Cha11e,
FS11, Wer11] veröffentlichten Aussagen über einzelne Varianten der Schadsoftware überprüft.
Aufgrund der Seitenlimitierung beschränken sich die Autoren in dieser Arbeit auf die Erläuterung der wichtigsten Ergebnisse. Weitere Details werden die Autoren in einem technischen
2 So beschreibt der CCC eine Reihe zum Zwecke des Quellenschutzes vorgenommener Änderungen, die zu
BckR2D2-I’ führten, auf seiner Webseite [Cha11a].
49
Bericht [DFS+ 11] zur Verfügung stellen.
1.1
Gliederung der Arbeit
Die restlichen Abschnitte dieser Arbeit sind wie folgt gegliedert: Abschnitt 2 gibt einen kurzen
Überblick 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 näher erläutert. Eine abschließende kurze Zusammenfassung
der Untersuchungsergebnisse ist Gegenstand von Abschnitt 5.
2
Überblick über die Komponenten von BckR2D2
Bislang sind insgesamt fünf verschiedene Komponenten unterschiedlicher Funktionalität bekannt, die der Schadsoftware zuzuordnen sind. Diese Komponenten liegen jedoch ausschließlich für die Variante BckR2D2-II vollständig vor und sind in dem bereits genannten Dropper [FS11] enthalten. Für die ältere Variante BckR2D2-I liegt lediglich der 32-bit KernelLevel-Treiber und die Softwarebibliothek vor. Ein Überblick 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 )
Remover
Kurzbeschreibung
Installationsroutine zur Einrichtung der
anderen Komponenten
Bibliothek zur Überwachung verschiedener Applikationen
Treiber zur Bereitstellung privilegierter Operationen (benötigt Administratorrechte)
Treiber zur Bereitstellung privilegierter Operationen (benötigt Administratorrechte)
Programm als bestmöglicher Ersatz für
den Kernel-Level-Treiber bei eingeschränkten Benutzerrechten
Hilfsprogramm zum Löschen beliebiger Dateien
erlä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 Funktionalitäten des Kernel-Level-Treibers soweit wie möglich ersetzt, falls bei
der Installation der Schadsoftware keine Administratorprivilegien zur Verfügung stehen. Ein
so genannter Remover dient zum Löschen von Dateien und zur Verwischung angefallener
Spuren. Tabelle 3 im Anhang enthält eine Übersicht über die Prüfsummen und die Dateigröß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 erlä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
ausführbare .exe-Datei. Dieses Installationsprogramm enthält sämtliche Komponenten der
Schadsoftware als eingebettete Ressource, die mittels einer dreistelligen Ziffernfolge im Bereich von 101 bis 118 eindeutig referenziert werden können.
Nach Aufruf der Installationsroutine versucht diese zunächst im Windows-Systemverzeichnis des Rechners eine temporäre Datei mit dem Namen ˜pgp˜.tmp anzulegen, um die
Schreibberechtigung für dieses Verzeichnis zu prüfen. Sofern diese Operation erfolgreich
durchgeführt werden konnte, wird die temporäre Datei anschließend sofort wieder gelö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 erläutert wird.
Wahrscheinlich um die Bibliothek besser vor einer Entdeckung zu schützen oder den Installationszeitpunkt zu verschleiern, werden die Erstell-, Änderungs- und Zugriffs-Zeitstempel
der Datei von der namensähnlichen Bibliothek mfc42.dll übernommen. Letztere ist legitimer Bestandteil der Microsoft Foundation Classes (MFC), einer Sammlung von Klassen fü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 kürzlich vorgenommener
Änderungen auf dem System führt also nicht zur Aufdeckung der installierten Komponente.
Jedoch existiert im NTFS-Dateisystem, welches seit Windows 2000 standardmäßig eingesetzt
wird, ein weiterer, meist als ctime bezeichneter Zeitstempel, der die letzte Änderung der zugehörigen Dateisystem-Datenstruktur angibt [Gar09]. Dieser Zeitstempel ist nicht ohne Weiteres zur Laufzeit des Systems manipulierbar. Auf Basis dieses Zeitstempels sind daher unter
Umständen dennoch Rückschlüsse auf den eigentlichen Installationszeitpunkt der Schadsoftware möglich.
In Abhä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 nächsten Schritt wird der Treiber mit Hilfe der
CreateService-Funktion als SERVICE KERNEL DRIVER (Servicetyp: 0x00000001)
mit vollen Rechten und ohne weitere Abhä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 temporären Verzeichnis gespeichert wird. Wie die Autoren in
Abschnitt 3.5 darstellen, handelt es sich dabei um ein rudimentäres Löschwerkzeug, mit dem
das ursprüngliche Installationsprogramm nach Abschluss aller Maßnahmen wieder entfernt
werden kann.
Sofern die oben aufgeführten Dateien nicht im Systemverzeichnis der Windows-Installation
erstellt werden kö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 fü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
Registrierungsschlüssel HKCU\Software\Microsoft\CurrentVersion\ Run standardmäßig bei jedem Start des Betriebssystems gestartet werden. Wie wir in Abschnitt 3.4
näher darstellen werden, sind diese Prozesse für die Überwachung einer Vielzahl von Anwendungsprogrammen verantwortlich.
3.2
Softwarebibliothek
Die Softwarebibliothek wird in mehrere laufende Prozesse injiziert. (Die hierzu genutzten
Ansätze werden in Abschnitt 4.2 näher erläutert, da sie sich in den beiden vorliegenden Varianten stark unterscheiden.) In Abhängigkeit des jeweiligen Elternprozesses, in den die Softwarebibliothek injiziert wurde, weisen die gestarteten Threads unterschiedliche Verhaltensmuster auf. So überprüft beispielsweise der in den Windows Explorer eingeschleuste Code die
Version und das Patchlevel des Betriebssystems.
Ein primäres Ziel der Softwarebibliothek ist offenbar die Überwachung der Software Skype.
Hierzu registriert sich die Bibliothek über die offizielle Schnittstelle als Skype-Erweiterung,
was dazu führt, dass sie über eingehende und abgehende Anrufe und Textnachrichten informiert wird. Über 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
mögliche Steuerbefehle erhält bzw. an den er aufgezeichnete Daten versendet.
Um einen Informationsaustausch mit anderen observierten Programmen zu ermö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\<Benutzername>\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 Bildschirmschnappschüssen von aktiven
Fenstern eines Internetbrowsers
Erstellung eines dedizierten Threads, der periodische Bildschirmschnappschü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 Bildschirmschnappschüsse anfertigt (Code ähnlich zu Kommando 0x03)
Entgegennahme mehrerer (unbekannter) Parameter über das
Netzwerk
Anfertigung von Bildschirmschnappschüssen von bestimmten Fenstern im Vordergrund, unter anderem auch Internetbrowsern (ähnlich zu Kommando 0x02)
Übertragung und Ausführung einer beliebigen Datei
Noch unbekannt
Noch unbekannt
Null-Rü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: Unterstützte Kommandos der Schadsoftwarebibliothek in den beiden Trojaner-Varianten (x =
Funktionalität vorhanden)
Der Kontrollserver kann mit Hilfe einer Reihe von Kommandobefehlen den Client zur Durchführung verschiedener Operationen anweisen. Dazu gehört insbesondere die Anfertigung von
Bildschirmschnappschüssen, aber auch die Übertragung und Ausführung beliebiger Dateien.
Eine Übersicht und Beschreibung der in den jeweiligen Versionen implementierten Befehle
ist in Tabelle 2 aufgeführt. Wie aus dieser Tabelle ersichtlich, konnten die Kommandos 0x0C,
0x10 und 0x11 bis zum gegenwärtigen Zeitpunkt noch nicht vollständig analysiert werden.
3.3
Kernel-Level-Treiber
Dieser Abschnitt basiert im wesentlichen auf der Analyse von BckR2D2-I. Die beschriebene
Funktionalität ist auch in BckR2D2-II enthalten, jedoch enthält BckR2D2-II einige weitere
Funktionen, deren Zweck zum gegenwä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 Änderungen am System vorzunehmen. Des Weiteren ist eine Keylogger-Funktionalitä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 Übersicht über das Zusammenspiel des Kernel-Level-Treibers mit
den übrigen Komponenten. Für weitere Details zum Kernel-Level-Treiber verweisen wir aus
Platzgründen auf den technischen Bericht.
3.4
Die Anwendung mit der Ressourcen-Nummer 107 dient als Ersatz für den Kernel-LevelTreiber. So kann die Software auch auf Systemen verwendet werden, bei denen es zum Infektionszeitpunkt nicht möglich ist, Administrator-Rechte zu erlangen. Die Anwendung erfüllt
zwei Aufgaben: Zum einen überprüft sie periodisch, ob die Installation beschädigt wurde.
Wird festgestellt, dass der oben genannte Run-Key aus der Systemregistrierung entfernt oder
das Image der Anwendung von der Festplatte gelö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 Löschwerkzeug, das beliebige Dateien von der Festplatte des kompromittierten Systems entfernen kann. Die zu löschende Datei wird dabei als Kommandozeilenparameter spezifiziert. Der eigentliche Löschvorgang erfolgt über den Windows-Systemaufruf
DeleteFileA(). Diese Funktion überschreibt die eigentlichen Daten nicht, sodass es prinzipiell möglich ist, die gelö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 nächsten Systemstart selbständig.
4 Vergleich von BckR2D2-I und BckR2D2-II
Im Folgenden stellen wir die beiden Varianten der Schadsoftware BckR2D2 vergleichend gegenüber und gehen auf die wesentlichen Unterschiede ein. Neben diversen Änderungen 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 für 64-bit Windows-Systeme.
4.1
Der Kernel-Level-Treiber hat in der 32-bit Version von BckR2D2-I eine Größe von 5.376 Bytes, in Version BckR2D2-II bereits eine Größe von 10.112 Bytes. Anzumerken ist, dass sich die
Funktionen des Treibers zwischen den Varianten BckR2D2-I und BckR2D2-II bezüglich der
unterstützten Routinen und der Kommandokommunikation zur Usermode-Applikation nicht
wesentlich verä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 zusä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 Funktionalität nicht. Hier wird das Injizieren der Softwarebibliothek anderweitig erreicht (siehe Abschnitt 4.2). Zusätzlich zum 32bit Treiber besitzt die Variante BckR2D2-II eine 64-bit Version des gleichen Kernel-LevelTreibers. Voraussetzung fü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 standardmäßig eingerichtetes 64-bit Windows 7-System diesem Zertifikat nicht und erforderte die manuelle Bestä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 Vorgängerversion. Obwohl eine Fälschung dieser Angaben leicht möglich ist, schä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 Veränderung eines Registrierungsschlüssels in alle startenden Prozesse injiziert wird.4 Da der Dropper für diese Version nicht vorliegt, ist dies jedoch nicht mit
absoluter Sicherheit festzustellen. Die Software selbst beinhaltet aber keine entsprechende
Funktionalität, sodass ein externer Eingriff für den Start zwingend notwendig ist. Wird die
Bibliothek in einen Prozess geladen, fü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
Registrierungsschlü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 näher genannten Kunden mit der Bezeichnung QSC-CUSTOMER-5464944-56
4637 vermietet.
Bei allen untersuchten Varianten von BckR2D2 erfolgte eine Authentifizierung der Schadsoftware gegenüber dem Kontrollserver durch Übermittlung der Zeichenkette C3PO-r2d2-POE,
welche auch namensgebend für die Schadsoftware war. Aus diesem Grund ist es möglich,
einen eigenen Kontrollserver zu prä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 verschlüsselt werden und eine Authentifizierung beider Kommunikationspartner
erforderlich ist. Zur Verschlüsselung wird das symmetrische Verfahren AES (Advanced Encryption Standard) im Electronic Codebook-Verfahren (ECB) verwendet und als kryptographischer Schlü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
gegenüber dem Client prü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 Löschung des Systemtreibers und der Schadbibliothek im Systemverzeichnis des
Benutzers sowie zur Einrichtung entsprechender Komponenten im Applikationsverzeichnis
(Kommando 0x04, siehe Tabelle 2) ist eine zusätzliche Authentifikationsprüfung vorgesehen. Durch Übertragung 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 kö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 Funktionalität der Kommandos bereitstellt, ist jedoch
weitherhin in der Bibliothek enthalten.
5 Zusammenfassung
Insgesamt konnten im Rahmen unserer Untersuchung die wesentlichen Ergebnisse der eingangs erwähnten Berichte bestätigt werden. Dies betrifft sowohl die Analyse des CCC [Cha11b]
hinsichtlich der Funktionalität und des Einsatzes von Verschlü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
Stüttgen, Stefan Vömel und Carsten Willems. Analyse und Vergleich von BckR2D2-I und II.
Bericht CS-2011-08, Friedrich-Alexander Universität Erlangen-Nü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 Übersicht über Prüfsummen und Dateigrößen
Tabelle 3 enthält eine Übersicht über die Prüfsummen und die Dateigrößen der einzelnen
analysierten Komponenten.
Bezeichnung
Dropper
Softwarebibliothek
(32-bit)
(64-bit )
User-LevelAnwendung
Remover
Version
BckR2D2-II
BckR2D2-I
BckR2D2-I’
BckR2D2-II
BckR2D2-I
BckR2D2-I’
BckR2D2-II
BckR2D2-II
MD5-Prüfsumme
cd01256f3051e6465b817fffc97767dd
Größ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 zugehörigen Prüfsummen und Dateigröß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
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
Christina Brzuska Özgür Dagdelen Marc Fischlin
Technische Universitä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, Kü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 Küsters and Tuengerthal [KT11] and one by Brzuska et al. [BFS+ 11]. Both
allow to analyze the TLS Handshake protocol3 . As the model by Kü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 Küsters 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 Kü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]
Vé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]
Özgür Dagdelen and Marc Fischlin. Security Analysis of the Extended Access Control
Protocol for Machine Readable Travel Documents. In ISC 2010, volume 6531 of
LNCS, pages 54–68. Springer, 2010.
[DF10b]
Özgür Dagdelen and Marc Fischlin. Sicherheitsanalyse des EAC-Protokolls. Technical 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]
Cé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 Jö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 Schäge, and Jö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 Kü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 Bjö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 ,
Özgür Dagdelen2 , Marc Fischlin2 , Markus Ullmann3
1
German Research Center for Artificial Intelligence (DFKI GmbH)
{lassaad,stephan}@dfki.de
2
Technische Universität Darmstadt
marc.fischlin@gmail.com oezguer.dagdelen@cased.de
3
Federal Office for Information Security (BSI)
markus.ullmann@bsi.bund.de
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 Kü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 Grégoire, Sylvain Heraud, and Santiago Zanella Bé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 Vé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 für Künstliche Intelligenz
GmbH, 2010.
[CSDF10] Lassaad Cheikhrouhou, Werner Stephan, Özgür Dagdelen, and Marc Fischlin. Meilensteinreport: Integrating the Cryptographic Security Analysis and the Algebraic-Logic
Security Proof of PACE. Technical report, Deutsches Forschungszentrum für Kü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 Kügler, Heike Neumann, Sebastian Stappert, and Vö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
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
firstname.lastname@sap.com
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 für
Mix-Implementierungen und ihre Umsetzung als
Open-Source-Framework
Karl-Peter Fuchs, Dominik Herrmann, Hannes Federrath
Universität Hamburg, Fachbereich Informatik
Vogt-Kölln-Straße 30, D-22527 Hamburg
{fuchs, herrmann, federrath}@informatik.uni-hamburg.de
Abstract: Mit dem Open-Source-Projekt gMix, einem generischen Framework für Mixe, möchten wir die zukünftige Forschung im Bereich der Datenschutzfreundlichen
Techniken fö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 Verfügung stellen.
Dies ermöglicht den Vergleich verschiedener Mix-Varianten unter einheitlichen Bedingungen und unterstützt durch leicht zugängliche und verständliche Lösungen auch
den Einsatz in der Lehre. Wir stellen eine generische Softwarearchitektur fü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̈berführen wollen.
1 Einleitung
Mixe ermöglichen die anonyme Kommunikation in Vermittlungsnetzen. Das Grundprinzip ist in Abbildung 1 am Beispiel einer sog. Mix-Kaskade dargestellt. Seit dem ursprünglichen Vorschlag von David Chaum im Jahr 1981 [Cha81] wurden zahlreiche MixKonzepte und -Strategien vorgestellt. Inzwischen wurden Mixe für verschiedene Anwendungsgebiete, z. B. E-Mail [Cha81, Cot95], elektronische Wahlen [Cha81, PIK94, SK95],
Location-Based-Services [FJP96] sowie fü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 ermöglichen, bislang lediglich die Anonymisierungssysteme Tor [DMS04], JAP (JonDonym) [BFK01] und I2P etabliert.1 Durch
ihre konstante Fortentwicklung haben diese Implementierungen eine so hohe Komplexitä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 für Mix-Implementierungen und ihre Umsetzung
Nutzer
Client
Server
Mix 1
Nutzer
Mix 2
Client
Server
Abbildung 1: Nachrichten werden vom Client schichtweise verschlüsselt. Die Mixe entschlüsseln
die Nachricht schrittweise auf dem Weg zum Empfänger. Weitere Details werden in Abschnitt 2
erläutert.
tionen eines Mixes nicht mehr leicht nachvollziehbar sind und ihre Eignung als Ausgangspunkt für die Entwicklung neuer Systeme (z. B. für andere Anwendungsfälle) beschränkt
ist. Der JAP-Client besteht beispielsweise derzeit (Dezember 2011) aus über 700 JavaKlassen.2
In der Theorie gibt es eine Vielzahl an Vorschlägen, für die keine öffentlich verfügbaren
oder gar praktisch einsetzbaren Implementierungen existieren (z. B. [PPW91, DG09,
KG10, KEB98, DS03a, Ser07, SDS02, DP04, DS03b] oder [WMS08]). Von diesen Vorschlägen bleibt nur eine verbale oder formale Beschreibung in der jeweiligen akademischen Publikation.
Diese Situation hat drei Konsequenzen: Zum einen wird es Wissenschaftlern unnötig
schwer gemacht, bereits publizierte Ergebnisse nachzuvollziehen, da die existierenden
Techniken dazu von Grund auf neu implementiert werden müssen. Zweitens ist die Hürde
zur Implementierung neuer Mix-Techniken unnötig hoch, da immer wieder von neuem
Lösungen für Standardprobleme gefunden und implementiert werden müssen. Und drittens ist es zum aktuellen Zeitpunkt relativ schwierig, die Vorschläge aus unterschiedlichen
Veröffentlichungen miteinander zu vergleichen, da diese mit unterschiedlichen Implementierungen, Laufzeitumgebungen und Experimentierumgebungen realisiert wurden.
Mit dem gMix-Projekt möchten wir dazu beitragen, diese aus unserer Sicht unerwünschten
Konsequenzen zu beheben. Wir verfolgen dabei fünf Ziele:
1. Verfü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. Unterstützung der Lehre durch leicht zugängliche und verständliche Mix-Lö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 zukünftige Mixe abgebildet werden können. Die Architektur bildet die
2 Gezählt
wurden alle Klassen, die unter http://anon.inf.tu-dresden.de/develop/doc/jap/ aufgeführt sind.
125
gemeinsamen Komponenten ab, die für die Entwicklung praktischer Mix-Implementierungen grundsätzlich erforderlich sind. Weiterhin gibt sie den Rahmen fü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 ermöglichen,
einen konkreten Mix aus den verschiedenen Implementierungen zusammenzustellen, ohne den Quelltext des Frameworks anpassen zu müssen. Wir sehen dies als Voraussetzung dafü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 können,
sowie die Abhängigkeiten bei der parallelen Entwicklung verschiedener Implementierungen durch die Open-Source-Community zu minimieren. Neben dem Framework erstellen
wir derzeit Referenzimplementierungen fü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 veröffentlicht.
Der Beitrag ist wie folgt aufgebaut: Im Abschnitt 2 stellen wir die gMix-Architektur vor.
Anschließend erläutern wir in Abschnitt 3 anhand einer konkreten Implementierung, einem synchron getakteten Kanal-Mix fü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 beschrä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 Verö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 verö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 geführt, dass diese ganz selbstverständlich heute in vielen Anwendungsfeldern eingesetzt werden.
Wegen seiner Einfachheit wird WEKA inzwischen auch an vielen Universitäten im Lehrbetrieb eingesetzt.
126
2.1
Herausforderungen
Die wesentliche Herausforderung bei der Entwicklung einer generischen Architektur für
Mix-basierte Systeme besteht darin, diese einerseits generisch genug zu spezifizieren, so
dass eine Vielzahl von Mix-Varianten unterstützt wird, sie andererseits aber auch so spezifisch wie möglich zu entwerfen. Hierzu werden die wesentlichen Aufgaben eines Mixes
sowie die für eine praktisch nutzbare Implementierung nötigen zusätzlichen und wiederverwendbaren Artefakte (z. B. Serverfunktionalitä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 verfügbare Implementierungen (Tor, JAP, Mixminion)
analysiert. Der Architekturentwurf wurde zusä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 ermöglicht die parallele bidirektionale anonyme Kommunikation (Vollduplex), für nachrichtenorientierte Anwendungen (z. B. E-Mail) sowie für Datenströme mit Echtzeitanforderungen (Möglichkeit zur Schaltung langlebiger anonymer
Kanäle, z. B. für WWW-Traffic), unabhä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
für die Kernfunktion des Mixes (Unverkettbarkeit ein- und ausgehender Nachrichten)
zustä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
Bitrepräsentation verkettet werden können. Aufgaben der Komponente sind folglich
das Ver- bzw. Entschlüsseln von Mix-Nachrichten sowie die Durchführung einer Integritätsprüfung4 und Wiederholungserkennung5 . Für den Entwurf der Komponente wurden die Verfahren nach [Cha81, PPW91, Cot95, DDM03, BFK01, Köp06] und [DMS04]
analysiert. Die aktuelle Implementierung ist in Abschnitt 3 beschrieben. Derzeit wird das
4 Können Nachrichten vom Mix unbemerkt verändert werden, kann die Anonymitä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 [Köp06] beschrieben.
127
MixTrafficPort
<<delegate>>
Mix
<<component>>
:InputOutput-‐
Handler
Mix-‐
External-‐
Informa/on-‐
Port
<<component>>
:Message-‐
Processor
<<component>>
<<delegate>>
:KeyGenerator
:OutputStrategy
<<component>>
:External-‐
Informa;onPort
<<component>>
<<component>>
:Framework
<<component>>
:UserDatabase
<<component>>
:NetworkClock
Abbildung 2: Komponentendiagramm
Umkodierungsschema nach [DG09] integriert.
Umkodierte Nachrichten werden vom MessageProcessor an die Komponente OutputStrategy weitergeleitet, die für die Umsetzung der Ausgabestrategie zuständig ist. Ihre Aufgabe ist es, durch das gezielte Verzögern und die umsortierte Ausgabe eingehender Nachrichten eine Anonymitä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. Realisierungsmöglichkeiten fü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 verzö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 Empfänger (z. B. andere Mixe oder Server) weiter. Zusätzlich stellt der
InputOutputHandler mittels einer Schnittstelle über den Kommunikationskanal empfangene Nachrichten für den MessageProcessor bereit. Die Übergabe von Nachrichten an
den InputOutputHandler erfolgt asynchron, das Beziehen von Nachrichten mittels eines
Benachrichtigungsprinzips (wait-notify). Entsprechend können InputOutputHandler, MessageProcessor und OutputStrategy, abgesehen von der Nachrichtenübergabe, unabhängig
voneinander arbeiten. Im Ergebnis kö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 ermöglicht das Speichern von Daten zu einzelnen Nutzern (z. B. verbundene Clients) des Mixes. Dies umfasst beispielsweise Daten zu geschalteten anonymen
Kanälen, wie Kanalkennzeichen [PPW91] und Sitzungsschlüssel. Im einfachsten Fall kann
die Realisierung mit einer Hashtabelle erfolgen.
Über den ExternalInformationPort können allgemeine Informationen über den Mix
veröffentlicht werden, z. B. dessen Public Key, seine unterstützten Protokolle und eine Versionsnummer. Im Falle von JAP würde diese Komponente mit dem InfoService [BFK01]
kommunizieren.
Der KeyGenerator kann zum Erstellen von kryptographischen Sitzungs- oder Langzeitschlüsseln verwendet werden. Da für einige Mix-Verfahren Zeitstempel benö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
Einschränkungen bei der Generalisierung ergeben sich hinsichtlich des Detaillierungsgrades bei der Spezifikation für bestimmte Datenstrukturen und Nachrichtenformate.
Das grundlegende Problem ist, dass sich konkrete Implementierungsmöglichkeiten im
Detail stark unterscheiden können. Dies macht eine Vereinheitlichung schwer oder gar
unmöglich. Betroffen sind das Nachrichtenformat sowie die Inhalte der UserDatabase
und des ExternalInformationPort. Ein SG-Mix [KEB98] benötigt beispielsweise exklusiv
ein in das Nachrichtenformat integriertes Zeitfenster, um den Ausgabezeitpunkt von Nachrichten einzugrenzen. Sind der Aufbau eines anonymen Kanals und die eigentliche Nachrichtenübermittlung wie in [PPW91, DMS04] oder [KG10] getrennt, müssen zusätzlich
Informationen wie Kanalkennzeichen und Sitzungsschlüssel (in der UserDatabase) gespeichert werden. Kommt ein Umkodierungsschema wie in [Cha81, DDM03] oder [DG09]
zum Einsatz, kann hingegen jeder Schlüssel sofort nach dem Umkodieren der zugehörigen
Nachricht (hybrides Kryptosystem) verworfen werden.
Eine weitere Konkretisierung der Architektur lässt sich mit dem Ziel, die Architektur so
generell wie möglich zu gestalten, nicht vereinbaren. Um dieses Problem zu lösen, verwenden wir abstrakte Datentypen, die nach dem Key-Value-Prinzip arbeiten. Konkrete Werte
und Schlüssel werden über eine Enumeration spezifiziert. Entsprechend kann für konkrete Implementierungen einer Komponente angegeben werden, welche Werte sie benötigt,
d. h. mit welchen Enumerations sie kompatibel ist. Da die Enumeration nur eine abstrakte
Beschreibung benötigter Inhalte ist, kann die konkrete Realisierung unterschiedlich erfolgen. Die Spezifizierung von Abhängigkeiten und das Auflö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
können duplexfähige anonyme Kanäle zur Übermittlung von Binärdaten geschaltet werden. Von den zu übermittelnden Daten selbst und den in diesen Zusammenhang verwendetet Protokollen wird abstrahiert, um die Implementierung möglichst generisch zu halten.
Dieser Mix besitzt einen hohen Komplexitätsgrad in allen Komponenten (Echtzeitanforderung, verschiedene Nachrichtentypen, Anonymisierung von Datenströmen statt nur Einzelnachrichten). Es gibt unseres Wissens nach noch keine entsprechende Open-SourceImplementierung.
3.1
Umsetzungsdetails
Als Programmiersprache wird wegen seiner Plattformunabhä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 Schlüssellänge) und AES (OFB-Modus,
128 bit Schlüssellänge) verschlüsselt. Es gibt drei Nachrichtentypen. Kanalaufbaunachrichten zum Schalten anonymer Kanäle (Verteilung der Sitzungsschlüssel für AES und Integritätsprüfung mit HMAC-SHA256). Rein symmetrisch verschlüsselte Kanalnachrichten zum Übermitteln von Nutzdaten und Kanalabbaunachrichten zum Auflösen anonymer
Kanäle. Zusätzlich wurde eine Wiederholungserkennung nach dem Vorbild von [Köp06]
implementiert. Zum parallelen Umkodieren kö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. Zusä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 Performanzgründen zwischen Mixen und Clients asynchrone
Ein- und Ausgabe (non-blocking I/O) ein. Zwischen zwei Mixen besteht jeweils nur eine
verschlü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 herkömmlichen Debugging-Werkzeugen nicht
vollstä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 Mö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 Schlüsselverteilung kümmern zu müssen.
Nachrichten können mit einer eindeutigen ID ausgezeichnet werden, um sie beim Debugging über Systemgrenzen hinweg zu verfolgen. So kann überprüft werden, ob die Nachrichtenü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
ermö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 unterstützt und automatisiert die Verzögerung von Nachrichten in den einzelnen MixKomponenten erfassen und visualisieren kann. Wir versprechen uns davon die Identifizierung von Flaschenhä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 für neue praktische
Mix-Systeme erheblich verkürzen. Es wäre jedoch darüber hinaus wünschenswert, über
ein umfangreiches Code-Repository mit kompatiblen Implementierungen, die einfach zu
einem konkreten Mix zusammengestellt werden können, zu verfügen. Idealerweise sollte
es unterschiedlichen Entwicklern möglich sein, unabhängig voneinander an verschiedenen
Implementierungen zu arbeiten und diese ggf. zu veröffentlichen.
Dieses Ziel soll mit Hilfe eines dedizierten Rahmenwerks erreicht werden. Das Framework trennt zwischen veränderbarem Quelltext und gleich bleibenden Strukturen. Im
Framework können folglich jeweils mehrere konkrete Implementierungen für die einzelnen Komponenten erstellt und registriert werden, so lange sie den Architekturvorgaben genügen. Die Instanziierung und Steuerung (d. h. die Sicherstellung der Einhaltung
des vorgesehenen Kontrollflusses) der gewählten Komponentenimplementierungen erfolgt
durch das Framework. Verä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 Lösungsansätzen kurz dargestellt.
131
• Es wird ein Plug-in-Mechanismus benötigt, der das Einbinden konkreter Komponentenimplementierungen durch das Framework ermöglicht.
• Es wird ein Mechanismus benötigt, mit dem Abhängigkeiten zwischen Komponenten und Nachrichtenformaten abgebildet und erkannt werden können.
• Die einfache Komposition verschiedener Implementierungsvarianten zu einem konkreten Mix soll ohne Anpassung des Quelltextes möglich sein.
• Mit Hilfe einer Versionsverwaltung für verschiedene Implementierungsvarianten
soll die Nachvollziehbarkeit von durchgeführten Evaluationen verbessert werden.
• Die Bereitstellung umfangreicher Dokumentation und Tutorials ist erforderlich, um
die Hürde zur Nutzung des Frameworks zu senken.
Der Plug-in-Mechanismus ist in Abbildung 3 dargestellt. Das Framework enthält Schnittstellendefinitionen für sämtliche (in Abschnitt 2 beschriebene) Komponenten. Zusätzlich
verfügt jede Komponente über eine sogenannte Controller-Klasse, welche die durch die
jeweilige Schnittstelle spezifizierte Funktionalität nach außen (d. h. für die anderen Komponenten) zur Verfügung stellt. Intern werden Aufrufe an eine konkrete Implementierung
(Komponentenimplementierung) weitergeleitet.
Wie aus der Architektur hervorgeht, arbeiten die einzelnen Komponenten nicht völlig autonom, sondern sie interagieren. Jede Implementierung muss daher über Referenzen auf
die anderen Komponenten verfü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 enthält. Eine
Komponente wird nach dem Laden ihrer Klasse durch den Aufruf ihres Konstruktors instanziiert (Phase 1). Sobald alle Klassen geladen und alle Referenzen gültig sind, wird der
Beginn von Phase 2 durch Aufruf einer Initialisierungsmethode bekannt gegeben. In Phase 2 werden Vorbereitungsfunktionen für die Anonymisierung durchgeführt, z. B. können
Schlü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 können, ohne den Quelltext
”
des Frameworks anpassen zu müssen. Um diese Anforderung umzusetzen, greifen wir auf
einen Klassenlader zurück, der dynamisch zur Laufzeit die konkreten Implementierungen
in die Java Virtual Machine lädt. Der Klassenlader wertet Kompatibilitätsinformationen,
die für jedes Plug-in erfasst werden, aus und verhindert dadurch, dass inkompatible Konfigurationen ausgeführt werden. Die Kompatibilitätsinformationen werden vom Autor des
Plug-ins spezifiziert und liegen in einer Property-Datei vor. Darin können auch weitere
Laufzeitparameter (z. B. die Schubgröße bei einem Batch-Mix) definiert werden.
Um die Konfiguration eines Mixes zu vereinfachen, wollen wir eine grafische Oberfläche
entwickeln, die eine interaktive Auswahl der zu integrierenden Komponenten erlaubt. Die-
132
se soll die Kompatibilitäts- und Konfigurationsparameter interpretieren, um den Nutzer
bei der Auswahl der zueinanderpassenden Implementierungen zu unterstützen. Auf der
Projektseite ist der Quelltext des ersten Prototypen des Frameworks veröffentlicht. Neben einer rudimentären Implementierung des Plug-in-Mechanismus sind bereits 14 der in
[Cha81, Cot95, KEB98, SDS02, DS03b] und [WMS08] beschriebenen Ausgabestrategien
implementiert. Implementierungen für die restlichen Komponenten sind in Arbeit.
Framework
Name der Komponente
<<interface>>
Schni)stelle der Komponente
Schni)stellendefini+onen
aller Komponenten
:Implementa-on
<<delegate>>
:Controller-‐Klasse
<<delegate>>
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 müssen, in einzelnen Komponenten gekapselt. Jede Komponente erfüllt
eine klar abgegrenzte Aufgabe und hat definierte Schnittstellen. Die Architektur reduziert
zum einen die Komplexität für Entwickler, zum anderen ist sie die Grundlage für untereinander kompatible Implementierungsvarianten. Am Beispiel des synchron getakteten
Kanalmixes wurde die grundsätzliche Anwendbarkeit beispielhaft demonstriert.
Architektur und Implementierung sind öffentlich zugänglich und erweiterbar. Weiterhin
wurde das geplante gMix-Framework, an dem wir derzeit arbeiten, vorgestellt. Es wird
eine weitgehend unabhängige Entwicklung dedizierter Mix-Plug-ins und die Evaluation unter einheitlichen Umgebungsbedingungen ermöglichen. Wir hoffen, dass durch das
gMix-Projekt nicht nur die Entwicklung Datenschutzfreundlicher Techniken vorangetrieben, sondern vor allem auch deren Überführung in die Praxis begü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 Kö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, Frédé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 für anonymisierende Mixe
und Implementierung einer konkreten Mix-Variante. Magisterarbeit, Universitä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 Bü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.
[Köp06]
Stefan Kö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 Günter Mü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 Göbel
Christian Schönbein
Felix C. Freiling∗
Friedrich-Alexander-Universität Erlangen-Nü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 Schö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 Schö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 Schö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
<N t C r e a t e F i l e C r e a t e D i s p o s i t i o n =” 0 x00000005 ” C r e a t e O p t i o n s =” 0 x00000064 ”
D e s i r e d A c c e s s =” 0 x40110080 ” E x e c u t e d =”YES” F i l e A t t r i b u t e s =” 0
x00000020 ” O b j e c t =” C: \WINDOWS\ s y s t e m 3 2 \ c s s r s s . e x e ” R e t u r n V a l u e =” 0
x00000000 ” S h a r e A c c e s s =” 0 x00000000 ” Timestamp =” 3115 ” />
<N t W r i t e F i l e E x e c u t e d =”YES” L e n g t h =” 20928 ” O b j e c t =”WINDOWS\ s y s t e m 3 2 \
c s s r s s . e x e ” R e t u r n V a l u e =” 0 x00000000 ” Timestamp =” 3116 ” />
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
<NtOpenKey D e s i r e d A c c e s s =” 0 x00000002 ” E x e c u t e d =”YES” O b j e c t =”REGISTRY\
MACHINE\SYSTEM\ C o n t r o l S e t 0 0 1 \ S e r v i c e s \ S h a r e d A c c e s s \ P a r a m e t e r s \
F i r e w a l l P o l i c y \ S t a n d a r d P r o f i l e ” R e t u r n V a l u e =” 0 x00000000 ” Timestamp
=” 3121 ” />
<N t S e t V a l u e K e y D e s i r e d A c c e s s =” 0 x00000000 ” E x e c u t e d =”YES” O b j e c t =”
REGISTRY\MACHINE\SYSTEM\ C o n t r o l S e t 0 0 1 \ S e r v i c e s \ S h a r e d A c c e s s \
P a r a m e t e r s \ F i r e w a l l P o l i c y \ S t a n d a r d P r o f i l e ” R e t u r n V a l u e =” 0 x00000000
” Timestamp =” 3121 ” ValueName=” E n a b l e F i r e w a l l ” ValueType =” 4 ” />
<NtOpenKey D e s i r e d A c c e s s =” 0 x00000002 ” E x e c u t e d =”YES” O b j e c t =”REGISTRY\
MACHINE\SYSTEM\ C o n t r o l S e t 0 0 1 \ S e r v i c e s \ S h a r e d A c c e s s \ P a r a m e t e r s \
FirewallPolicy\ StandardProfile \AuthorizedApplications\ List ”
R e t u r n V a l u e =” 0 x00000000 ” Timestamp =” 3121 ” />
<N t S e t V a l u e K e y D e s i r e d A c c e s s =” 0 x00000000 ” E x e c u t e d =”YES” O b j e c t =”
REGISTRY\MACHINE\SYSTEM\ C o n t r o l S e t 0 0 1 \ S e r v i c e s \ S h a r e d A c c e s s \
Parameters\ FirewallPolicy \ StandardProfile \ AuthorizedApplications \
L i s t ” R e t u r n V a l u e =” 0 x00000000 ” Timestamp =” 3122 ” ValueName=” b i n a r y ”
ValueType =” 1 ” />
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 Krü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 Schö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 info

Volume P-195(2012) - Mathematical Journals

Transcription

Similar documents

Trojaner, Viren, Cyber-Security und der Staatstrojaner

PyBox - A Python approach to sandboxing