GI-Edition Proceedings - Journals

GI-Edition

Gesellschaft für Informatik (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.

Lecture Notes in Informatics

Broken down into the fields of • Seminars • Proceedings • Dissertations • Thematics current topics are dealt with from the fields of research and development, teaching and further training in theory and practice. The Editorial Committee uses an intensive review process in order to ensure the high level of the contributions.

Felix C. Freiling (Hrsg.)

Sicherheit 2010

Information: http://www.gi-ev.de/service/publikationen/lni/

Felix C. Freiling (Hrsg.): Sicherheit 2010

The volumes are published in German or English.

Sicherheit, Schutz und Zuverlässigkeit Beiträge der 5. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.V. (GI) 5.–7. Oktober 2010 Berlin

ISSN 1617-5468 ISBN 978-3-88579-264-2 This volume contains the contributions to the 5th Conference of the GI special interest group “Sicherheit, Schutz und Zuverlässigkeit” that took place in Berlin on October 5-7, 2010.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.

170

Proceedings

Felix C. Freiling (Hrsg.)

SICHERHEIT 20 10 Sicherheit, Schutz und Zuverlässigkeit Konferenzband der 5. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft für Informatik e.V. (GI) 5.-7. Oktober 2010 in Berlin

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

Lecture Notes in Informatics (LNI) - Proceedings Series of the Gesellschaft für Informatik (GI) Volume P-170 ISBN 978-3-88579-264-2 ISSN 1617-5468 Volume Editor Prof. Dr. Ing. Felix C. Freiling Lehrstuhl Praktische Informatik I Universität Mannheim A5, 6 68159 Mannheim, Germany Email: [email protected] Series Editorial Board Heinrich C. Mayr, Universität Klagenfurt, Austria (Chairman, [email protected]) Hinrich Bonin, Leuphana-Universität Lüneburg, Germany Dieter Fellner, Technische Universität Darmstadt, Germany Ulrich Flegel, SAP Research, Germany Ulrich Frank, Universität Duisburg-Essen, Germany Johann-Christoph Freytag, Humboldt-Universität Berlin, Germany Thomas Roth-Berghofer, DFKI, Germany Michael Goedicke, Universität Duisburg-Essen, Germany Ralf Hofestädt, Universität Bielefeld 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 Sigrid Schubert, Universität Siegen, Germany Martin Warnke, Leuphana-Universität Lüneburg, Germany Dissertations Dorothea Wagner, Universität Karlsruhe, Germany Seminars Reinhard Wilhelm, Universität des Saarlandes, Germany Thematics Andreas Oberweis, Universität Karlsruhe (TH)  Gesellschaft für Informatik, Bonn 2010 printed by Köllen Druck+Verlag GmbH, Bonn

Preface “Sicherheit, Schutz und Zuverlässigkeit” (SICHERHEIT) is the main conference on safety and security of Gesellschaft für Informatik e.V. (GI), the German non-profit organization of computing professionals with around 25.000 members. Having been held before in Frankfurt (2003), Regensburg (2005), Magdeburg (2006) and Saarbrücken (2008), SICHERHEIT 2010 was co-located with the conference Information Security Solutions Europe (ISSE) in Berlin and jointly organized by Gesellschaft für Informatik e.V, eema, TeleTrusT and ENISA. By teaming up with ISSE in this one-time endeavour, the official conference language of SICHERHEIT 2010 was English. The academic program of SICHERHEIT featured 30 papers that were selected in a rigorous peer-review process from 57 submissions by a program committee consisting of 98 experts from the areas of safety and security. All accepted papers are collected within the present volume. Following the tradition, papers could be written in either German or English. Several special interest groups within GI organized Special Sessions that brought additional focus to the program I would like to express my gratitude to all people who helped to make the event possible. This includes the steering committee and organizational staff of ISSE who mastered the burden of all financial and local arrangments of the joint conference. I am indebted to all reviewers of SICHERHEIT, in particular the members of the program committee and the chairs and co-chairs of the five special sessions. Finally, I would like to thank the organizing committee of SICHERHEIT — Ammar Alkassar, Ulrich Flegel, and Michael Waidner — for sharing their experience in organizing the conference. Last but not least, thanks to Stefan Vömel for his careful help in preparing the proceedings.

Vorwort Die fünfte Ausgabe der Konferenz “Sicherheit, Schutz und Zuverlässigkeit” (SICHERHEIT) der Gesellschaft für Informatik e.V. fand 2010 in Berlin statt. SICHERHEIT führt als das deutsche Diskussionsforum Experten aus Wissenschaft und Wirtschaft für beide Aspekte von Sicherheit zusammen: Safety als Schutz vor katastrophalem Fehlverhalten technischer Systeme und Security als Schutz informationstechnischer Systeme vor Datenspionage und Datenkorruption. Nach Frankfurt (2003), Regensburg (2005), Magdeburg (2006) und Saarbrücken (2008) wurde SICHERHEIT in 2010 als einmaliges Experiment gemeinsam mit der Konferenz “Information Security Solutions Europe” (ISSE) veranstaltet und von der Gesellschaft für Informatik e.V., eema, TeleTrusT und ENISA gemeinschaftlich organisiert. Der vorliegende Tagungsband umfasst alle 30 Beiträge des wissenschaftlichen Programms. Diese Beiträge wurden aus insgesamt 57 Einreichungen durch das international besetzte 98köpfige Programmkomitee ausgewählt. Obwohl die Tagungssprache aufgrund der Kooperation mit ISSE Englisch war, durften traditionsgemäß Beiträge auch auf Deutsch eingereicht werden. Zudem bereicherten mehrere Fachgruppen innerhalb der GI das Programm durch “Special Sessions” zu spezifischen Fragestellungen.

Mein Dank gilt all denen, die sich mit Zeit und Mühe bei der Vorbereitung der Konferenz engagiert haben. Zu ihnen zählen die Mitglieder der ISSE-Leitungsgruppe sowie alle, die vor und hinter den Kulissen für die reibungslose organisatorische und finanzielle Abwicklung der gemeinsamen Tagung sorgten. Außerdem danke ich sämtlichen Mitgliedern des Programmkomitees und allen weiteren Gutachtern. Nicht zuletzt gilt mein herzlicher Dank der Tagungsleitung — Ammar Alkassar, Ulrich Flegel und Michael Waidner — für ihre Unterstützung dieses Projekts sowie Stefan Vömel für seine umsichtige Hilfe bei der Zusammenstellung des Tagungsbandes. Oktober 2010

Felix C. Freiling

Tagungsleitung • Ammar Alkassar, Sirrix AG, Saarbrücken • Ulrich Flegel, SAP Research, Karlsruhe • Felix C. Freiling, Universität Mannheim (Vorsitz) • Michael Waidner, Fraunhofer SIT und TU Darmstadt, CASED

Programmkomitee • Ammar Alkassar (Sirrix AG) • Frederik Armknecht (Universität Bochum) • Michael Backes (Universität des Saarlandes) • Thomas Biege (SUSE Linux Products/Novell GmbH/) • Fevzi Belli (Universität Paderborn) • Zinaida Benenson (Universität Mannheim) • Erik-Oliver Blaß (Institut EURECOM, Frankreich) • Rainer Böhme (ICSI, USA) • Wolfgang Böhmer (TU Darmstadt) • Jens Braband (Siemens) • Arslan Brömme (GI SIG BIOSIG) • Christoph Busch (Hochschule Darmstadt) • Jana Dittmann (Universität Magdeburg) • Falko Dressler (Universität Erlangen) • Thomas Dübendorfer (Google Switzerland GmbH, Schweiz) • Peter Ebinger (Fraunhofer IGD) • Klaus Echtle (Universität Duisburg-Essen) • Claudia Eckert (TU München) • Wolfgang Ehrenberger (Hochschule Fulda) • Bernhard Fechner (FernUniversität Hagen)

• Hannes Federrath (Universität Regensburg) • Simone Fischer-Hübner (Karlstad University, Schweden) • Marc Fischlin (TU Darmstadt) • Ulrich Flegel (SAP Research) • Felix C. Freiling (Universität Mannheim, Vorsitz) • Willi Geiselmann (Universität Karlsruhe) • Sabine Glesner (TU Berlin) • Dieter Gollmann (TU Hamburg-Harburg) • Christian Gorecki (Universität Mannheim) • Ulrich Greveler (FH Münster) • Rüdiger Grimm (Universität Koblenz) • Karl-Erwin Großpietsch (Fraunhofer AIS) • Bernhard Hämmerli (Acris GmbH & Hochschule Luzern, Schweiz) • Maritta Heisel (Universität Duisburg-Essen) ¨ • Eckehard Hermann (FH Oberösterreich Studienbetriebs GmbH, Osterreich) • Florian Heß (Otto-von-Guericke-Universität Magdeburg) ¨ • Thorsten Holz (TU Wien, Osterreich) • Detlef Hühnlein (secunet Security Networks AG) • Dieter Hutter (DFKI) • Luigi Lo Iacono (NEC Labs Europe) • Jan Jürjens (TU Dortmund und Fraunhofer ISST) • Jörg Kaiser (Universität Magdeburg) • Stefan Katzenbeisser (TU Darmstadt) • Jörg Keller (FernUniversität Hagen) • Dogan Kesdogan (Universität Siegen) • Matthias Krause (Universität Mannheim) • Ioannis Krontiris (Universität Mannheim)

• Ulrich Kühn (DZ Bank AG) • Ralf Küsters (Universität Trier) • Hanno Langweg (eQ-3 Entwicklung GmbH) • Pavel Laskov (Universität Tübingen) • Kerstin Lemke-Rust (Hochschule Bonn-Rhein-Sieg) • Stefan Lucks (Universität Weimar) • Erik Mähle (Universität Lübeck) • Heiko Mantel (TU Darmstadt) • Mark Manulis (TU Darmstadt) • Michael Meier (TU Dortmund) • Ulrike Meyer (RWTH Aachen) • Martin Mink (TU Darmstadt) • Holger Morgenstern (Sachverständigenbüro Morgenstern) • Günter Müller (Universität Freiburg) • Isabel Münch (BSI) • Jens Nedon (ConSecur GmbH) • Edgar Nett (Universität Magdeburg) • Alexander Nouak (Fraunhofer IGD) • Michael Nüsken (Universität Bonn) • Rolf Oppliger (eSECURITY Technologies, Schweiz) • Daniel Pähler (Universität Koblenz) • Günther Pernul (Universität Regensburg) • Andreas Pfitzmann (TU Dresden) • Norbert Pohlmann (FH Gelsenkirchen) • Joachim Posegga (Universität Passau) • Kai Rannenberg (Goethe-Universität Frankfurt) • Rolf Reinema (Vodafone D2 GmbH)

• Konrad Rieck (TU Berlin) • Heiko Roßnagel (Fraunhofer IAO) • Ahmad-Reza Sadeghi (Universität Bochum) • Francesca Saglietti (Universität Erlangen-Nürnberg) • Dirk Schadt (SPOT Consulting) • Werner Schindler (BSI) • Sebastian Schmerl (Universität Cottbus) • Guido Schryen (RWTH Aachen) • Jörg Schwenk (Universität Bochum) • Jean-Pierre Seifert (TU Berlin und T-Labs) • Peter Sobe (Universität Lübeck) • Hans von Sommerfeld (Rohde und Schwarz) • Martin Steinebach (Fraunhofer SIT) • Werner Stephan (DFKI) • Helmut G. Stiegler (STI Consulting) • Bernhard Tellenbach (ETH Zürich, Schweiz) • Roland Vogt (DFKI) • Melanie Volkamer (TU Darmstadt) • Horst Wedde (Universität Dortmund) • Andreas Westfeld (HTW Dresden) • Carsten Willems (CWSE GmbH) • Bernhard C. Witt (it.sec GmbH & Co. KG) • Christopher Wolf (Ruhr-Universität Bochum) • Xuebing Zhou (Fraunhofer IGD)

Zusätzliche Gutachter • Timo Bartkewitz (Ruhr-Universität Bochum) • Sebastian Clauß (TU Dresden) • Andreas Dewald (Universität Mannheim) • Christian Dietrich (Fachhochschule Gelsenkirchen) • Markus Engelberth (Universität Mannheim) • Stephan Faßbender (TU Dortmund) • Elke Franz (TU Dresden) • Jan Göbel (Universität Mannheim) • Martin Hirsch (Fraunhofer ISST) • Matthias Kirchner (TU Dresden) • Stefan Köpsell (TU Dresden) • Michael Müter (Daimler AG) • Dennis Royer (Goethe-Universität Frankfurt, Sirrix AG) • Holger Schmidt (TU Dortmund) • Jan Stijohann (Universität Duisburg-Essen) • Henning Sudbrock (TU Darmstadt) • Philipp Trinius (Universität Mannheim) • Christian Weber (Goethe-Universität Frankfurt) • Jan Zibuschka (Fraunhofer IAO)

Organisation der Special Sessions BIOSIG - Biometrics and Digital Signatures • Alexander Nouak (Chair) • Heiko Roßnagel (Co-Chair) FERS - Dependability and Fault-Tolerance • Jörg Keller (Chair) • Karl-Erwin Großpietsch (Co-Chair) CRYPTO - Theory and Practice of Cryptography • Christopher Wolf (Chair) • Frederik Armknecht (Co-Chair) STEWA - Multimedia Security • Martin Steinebach (Chair) • Jana Dittmann (Co-Chair) SIDAR - Reactive Security • Michael Meier (Chair) • Sebastian Schmerl (Co-Chair)

Inhaltsverzeichnis

Biometrics and Digital Signatures Busch Christoph, Abt Sebastian, Nickel Claudia, Korte Ulrike, Zhou Xuebing Biometrische Template-Protection-Verfahren und Interoperabilitätsstrategien

1

Busch Christoph, Hartung Daniel Biometrische Nachrichten-Authentisierung

13

Hühnlein Detlef, Roßnagel Heiko, Zibuschka Jan Diffusion of Federated Identity Management

25

Dependability and Fault-Tolerance Güdemann Matthias, Ortmeier Frank Quantitative Model-Based Safety Analysis: A Case Study

37

Messmer Roman, Keller Jörg Real-Time Fault-Tolerant Routing in High-Availability Multicast-Aware Video Networks

49

Distler Tobias, Kapitza Rüdiger, Reiser Hans P. State Transfer for Hypervisor-Based Proactive Recovery of Heterogeneous Replicated Services

61

Security Systems Kastl Wolfgang, Loimayr Thomas A Parallel Computing System with Specialized Coprocessors for Cryptanalytic Algorithms

73

Weis Rüdiger, Schüler Brian, Flemming Stefan A. Towards Secure and Reliable Firewall Systems based on MINIX3

85

Kiltz Stefan, Hildebrandt Mario, Altschaffel Robert, Dittmann Jana A Transparent Bridge for Forensic Sound Network Traffic Data Acquisition

93

Multimedia Security Christlein Vincent, Riess Christian, Angelopoulou Elli A Study on Features for the Detection of Copy-Move Forgeries

105

Kirchner Matthias Lineare Zeilen- und Spaltenprädiktoren zur Erkennung von Bildskalierungen

117

Schäfer Marcel, Berchtold Waldemar, Steinebach Martin, Zmudzinski Sascha, Heilmann Margareta, Katzenbeisser Stefan Collusion-Secure Fingerprint Watermarking for Real World Applications

129

Reactive Security Rietz René, Schmerl Sebastian, Vogel Michael, König Hartmut Iterative präzisionsbewertende Signaturgenerierung

141

Hoppe Tobias, Holthusen Sönke, Tuchscheerer Sven, Kiltz Stefan, Dittmann Jana Sichere Datenhaltung im Automobil am Beispiel eines Konzepts zur forensisch sicheren Datenspeicherung

153

Spreitzenbarth Michael, Holz Thorsten Towards Secure Deletion on Smartphones

165

Göbel Jan Amun: Automatic Capturing of Malicious Software

177

Göbel Jan, Trinius Philipp Towards Optimal Sensor Placement Strategies for Early Warning Systems

191

Trinius Philipp, Willems Carsten, Holz Thorsten, Rieck Konrad A Malware Instruction Set for Behavior-Based Analysis

205

Theory and Practice of Cryptography Stelte Björn, Saxe Björn State-of-the-Art Kryptoverfahren für drahtlose Sensornetze – Eine Krypto-Bibliothek für MantisOS

217

Kühn Ulrich On Security Protocols for Desktop Sharing

229

Schneider Michael, Buchmann Johannes Extended Lattice Reduction Experiments Using the BKZ Algorithm

241

Development of Secure Systems Schwab Fabian, Findeisen Alexander, Sakal Peter, Pohl Hartmut Bedrohungsmodellierung (Threat Modeling) in der Softwareentwicklung

253

Pöhls Henrich C. Why Showing One TLS Certificate is not Enough Towards a Browser Feedback for Multiple TLS Certificate Verifications

265

Ristig Christian, Fritzsche René, Siemers Christian WatchCop - Safer Software Execution through Hardware/Software Co-Design

277

Models and Metrics for Secure Systems Schryen Guido A Fuzzy Model for IT Security Investments

289

Heumann Thomas, Türpe Sven, Keller Jörg Quantifying the Attack Surface of a Web Application

305

Böhme Rainer, Pötzsch Stefanie Social Lending aus der Perspektive des Datenschutzes

317

Network Security Sovis Pavol, Kohlar Florian, Schwenk Jörg Security Analysis of OpenID

329

Schrank Michael, Braun Bastian, Johns Martin, Posegga Joachim Session Fixation - The Forgotten Vulnerability?

341

Baecher Paul, Fischlin Marc, Gordon Lior, Langenberg Robert, Lützow Michael, Schröder Dominique CAPTCHAs: The Good, the Bad, and the Ugly

353

Biometrische Template-Protection-Verfahren und Interoperabilitätsstrategien Christoph Busch 1, Sebastian Abt 1, Claudia Nickel 1, Ulrike Korte 2, Xuebing Zhou 3 1: Hochschule Darmstadt / CASED Haardtring 100, 64295 Darmstadt [email protected] 2: Bundesamt für Sicherheit in der Informationstechnik (BSI) 3: Fraunhofer-Institut für Graphische Datenverarbeitung (IGD) Abstract: Biometrische Authentisierung wird häufig zur Verbesserung der Identitätsverifikation eingesetzt. Durch die Nutzung biometrischer Verfahren entstehen neue Herausforderungen an den Schutz der Privatsphäre betroffener Personen. In biometrischen Systemen gespeicherte Referenzdaten enthalten Informationen, die aus den biometrischen Charakteristika einer Person abgeleitet wurden. Das Speichern von Abbildern einer biometrischen Charakteristik (z.B. Fingerbilder) in einer Datenbank ist aus Datenschutzsicht ungeeignet, da die Charakteristik selbst nach einer etwaigen Korrumpierung der Datenbank nicht ersetzt werden kann. Des Weiteren ist die Anzahl der biometrischen Charakteristika eines Nutzers begrenzt. Biometrische Merkmale werden z.B. aus einem Fingerbild extrahiert und in einem Template gespeichert. Eine Mehrfachnutzung von Templates in verschiedenen Anwendungen kann zu sog. Cross-Matching-Problemen führen, wenn Anwendungen miteinander verknüpft werden. Darüber hinaus können Referenzdaten für die Authentisierung irrelevante Informationen enthalten (z.B. ethnische Zugehörigkeit, Krankheiten). Zur Lösung dieser Herausforderungen hat sich mit den Template-Protection-Verfahren eine Technologie entwickelt, die den Anforderungen des Datenschutzes gerecht wird. Offene Systeme erfordern jedoch die Möglichkeit zum Austausch von interoperablen Referenzdatensätzen. Dieser Beitrag betrachtet daher Sicherheitsanforderungen an biometrische Systeme, behandelt die aktuellen Standardisierungsbemühungen zu Biometric-Template-Protection und schlägt eine weitere Vorgehensweise vor.

1 Einführung Die steigende Nachfrage an Verbesserungen der Sicherheit in der Grenzkontrolle und die zunehmende Anzahl elektronischer Transaktionen, die über kabelgebundene und drahtlose Netzwerke getätigt werden, haben einen starken Bedarf an einem zuverlässigeren Identitätsmanagement erweckt. Existierende, besitzbasierte Identifikationsmethoden (zum Beispiel eine ID Karte) oder wissensbasierte Methoden (z.B. PIN oder Passwort) sind mit Nachteilen verbunden: Diese Authentisierungsfaktoren können vergessen, verloren, verteilt oder gestohlen werden. Biometrie als ergänzender oder ersetzender Faktor kann zu einer höheren Zuverlässigkeit der Verifikation von Identitätsbehauptungen beitragen und im gleichen Zuge einen

2

Biometrische Template-Protection-Verfahren und Interoperabilitätsstrat.

höheren Nutzerkomfort bedeuten, da biometrische Charakteristika nur schwer vergessen werden oder verloren gehen können. Die Nutzung von Biometrie zur Identitätsverifikation hat jedoch auch Bedenken aufgeworfen. Die enge Verbindung biometrischer Verifikationsmethoden zu physikalischen, anatomischen Eigenschaften der betroffenen Personen ermöglicht die Nutzung biometrischer Messdaten für andere als die beabsichtigten Verwendungszwecke und kann somit eine Gefährdung der Privatsphäre darstellen, die sich in die folgenden vier Kategorien unterteilen lässt: Nichtauthorisierte Erfassung: Erfassung biometrischer Samples ohne das Wissen der betroffenen Person, zum Beispiel durch Verwendung versteckter Kameras. Unnötige Erfassung: Anwendung biometrischer Methoden ohne oder mit nur wenig zusätzlichem Nutzen im Vergleich zu gewöhnlicher Nutzerverifikation. Nichtauthorisierte Verwendung und Preisgabe: Nutzung biometrischer Verfahren für andere als die von der betroffenen Person genehmigten Zwecke. Schleichende Erweiterung des Verwendungsrahmens: Erweiterung eines Systems in Bereiche, in denen die Verwendung ursprünglich nicht vorgesehen war. Die für das Verarbeiten biometrischer Daten zu beachtende Direktive 95/46/EC über den Schutz personenbezogener Daten und über die freie Verfügbarkeit derartiger Daten gibt keine eindeutige Vorgabe zum Einsatz von biometrischen Verfahren. Der Artikel 29 EU Beratungsausschuss für Datenschutz und Privatsphäre hat daher in seinem im Jahre 2003 veröffentlichten Arbeitspapier über Biometrie [Par03] die Bedeutung von den Schutz der Privatsphäre verbessernden Technologien hervorgehoben, um hierdurch biometrische Systeme zu fördern, die eine dem Schutz der Privatsphäre und dem Schutz der Daten freundliche Architektur aufweisen und übermäßiges Sammeln von Daten und einen ungesetzmäßigen Umgang mit diesen Daten erschweren bzw. verhindern. Dieser Beitrag widmet sich dem Schutz von biometrischen Referenzdaten und daraus abgeleiteten Interoperabilitätsstrategien. Dazu werden zunächst in Kapitel 2 die Sicherheitseigenschaften biometrischer Systeme betrachtet. In Kapitel 3 wird die für ein offenes, interoperables System notwendige Standardisierung zusammengefasst und in Kapitel 4 besondere Fragen im Zusammenhang mit dem Schutz von Referenzdaten diskutiert. Das Kapitel 5 gibt einen Ausblick auf die weitere Vorgehensweise in der Standardisierung.

2 Sicherheitsaspekte biometrischer Systeme Die primäre Motivation beim Einsatz biometrischer Verfahren ist die Steigerung der Sicherheit einer Anwendung durch genauere und zuverlässigere Identifikation. Ein möglicher Vorbehalt gegen die Verwendung biometrischer Verfahren ist, dass die erreichte erhöhte Sicherheit mit einem verminderten Schutz der Privatsphäre


einhergehen kann [CS07]. Die Einbeziehung biometrischer Verfahren kann jedoch darüber hinaus in neuen Schwachstellen resultieren. Nach Jain [Jain08] kann das Sicherheitsrisiko eines biometrischen Systems in vier Kategorien unterteilt werden: •

Immanente biometrische Fehler, die häufig durch Wahrscheinlichkeitswerte für Falsch-Akzeptanz und/oder Falsch-Rückweisung ausgedrückt werden.

•

Angriff auf die Systemverwaltung.

•

Unzulänglich geschützte Infrastruktur, resultierend in Schwachstellen im Zusammenhang mit nicht hinreichend gesicherter Hardware, Software oder Kommunikationskanälen.

•

Öffentlichkeit von biometrischen Charakteristika, die versteckte Gewinnung biometrischer Samples und die Erzeugung von Plagiaten ermöglicht.

Die Beständigkeit biometrischer Charakteristika ist eine für die Erkennungsleistung erstrebenswerte Eigenschaft, hat aber auch Auswirkungen auf die eingeschränkten Möglichkeiten der Risikominimierung in Bezug auf einen Identitätsmissbrauch. Sobald ein biometrisches Charakteristikum einem Diebstahl zum Opfer gefallen ist und einem potentiellen Angreifer in Form eines Plagiates zur Verfügung steht, ist es so gut wie unmöglich, dieses Charakteristikum zu erneuern. Eine Verminderung der einhergehenden Risiken kann jedoch dadurch erreicht werden, dass die Erneuerbarkeit biometrischer Templates 1 in einem Identitätsverifikationssystem, sichergestellt wird. Durch die Erneuerbarkeit wird das Risiko einer unzulänglich geschützten Infrastruktur / Systemverwaltung minimiert und damit auch mittelbar das Risiko einer PlagiatErzeugung reduziert. 2.1 Sicherheitsanforderungen Zur Analyse möglicher Angriffsvektoren auf biometrische Systeme sind zunächst grundlegende Sicherheitsanforderungen zu betrachten. Die Sicherheitsanforderungen lassen sich in die Teilaspekte Vertraulichkeit, Integrität, Verfügbarkeit sowie Erneuerbarkeit und Widerrufbarkeit unterteilen. Vertraulichkeit ist die Eigenschaft, die den Schutz von Informationen vor nicht autorisiertem Zugriff und unerlaubter Veröffentlichung beschreibt. Integrität ist die Eigenschaft, die die Unversehrtheit und Korrektheit von Daten und Verfahren sicherstellt. Durch die Überprüfung der Integrität wird eine beabsichtigte oder unbeabsichtigte Modifikation einer biometrischen Referenz oder das Ersetzen einer gespeicherten biometrischen Referenz zum Zwecke eines Angriffs ausgeschlossen. Verfügbarkeit ist die Eigenschaft eines Systems, bei Bedarf zugänglich und funktionsfähig zu sein. Eine Beeinträchtigung der Funktionsfähigkeit eines 1

ISO/IEC SC37 Harmonized Biometric Vocabulary: http://www.3dface.org/media/vocabulary.html

3

4


biometrischen Systems kann z.B. durch von einem Angreifer vorgenommenes Löschen notwendiger, in einer biometrischen Referenzdatenbank gespeicherter, biometrischer Daten erfolgen. Erneuerbarkeit und Widerrufbarkeit von biometrischen Referenzen bietet einen Schutz bei einer Kompromittierung des biometrischen Datenspeichers. 2.2 Erzeugung von geschützten biometrischen Referenzen Bei Erneuerbarkeit und Widerrufbarkeit biometrischer Referenzen handelt es sich um bedeutende Maßnahmen zur Wahrung der Privatsphäre eines Individuums durch Vermeidung unerwünschter Verknüpfungen über Datenbanken hinweg. Erneuerbare biometrische Referenzen werden durch Diversifikation im Erstellungsprozess erzeugt und erlauben das Generieren mehrerer unterschiedlicher biometrischer Referenzen, die sämtlich aus einem Charakteristikum abgeleitet wurden [Bre08]. Dazu werden sogenannte Template-Protection-Verfahren eingesetzt. Die Transformation von biometrischen Templates in geschützte Templates (Referenzen) erfolgt mittels einer Einweg-Funktion, sodass eine Rekonstruktion des ursprünglichen Samples unmöglich wird. Somit erlauben Referenzen, die in unterschiedlichen Anwendungen für eine betroffene Person gespeichert werden, keinerlei Querbezüge zwischen den Anwendungen und geben keine unerwünschte Information über die betroffene Person preis.

3 Standardisierung biometrischer Systeme Bei der gegebenen großen Bandbreite biometrischer Modalitäten, Sensortypen, Merkmalsextraktionsverfahren und Templateformaten ist für große offene Anwendungen (wie zum Beispiel biometrische Reisepässe, Bürgerkarten oder biometrische Bankkarten) die Interoperabilität gleichzeitig eine große Herausforderung und zwingend erforderlich. Durch den Einsatz standardisierter Technologien reduziert sich für den Betreiber das Risiko einer sich einstellenden Herstellerabhängigkeit. Bei einem ggf. notwendigen Wechsel eines Herstellers kann der Betreiber des biometrischen Systems daher beträchtliche Migrationskosten sparen, wenn etablierte Standards bei der Einrichtung des Systems berücksichtigt wurden. 3.1 Zusammenwirken der Standardisierungsgremien Die Standardisierung im Bereich der Informationstechnologie wird von einem Joint Technical Committee (JTC) zwischen der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) erarbeitet. Mit der Biometriestandardisierung beauftragt wurde das im Jahr 2002 etablierte Subcommittee SC37. Parallel dazu werden im Subcommittee SC27 die Sicherheitsverfahren sowie im Subcommittee SC17 SmartCards und deren Kommunikationsprotokollen bearbeitet.


Das SC37 formuliert Datenaustauschformate, nach denen die Repräsentation einer biometrischen Charakteristik, z.B. eines Gesichtsbilds, in einem spezifizierten Datensatz kodiert werden kann. Für den Bereich Biometrische Systeme ist die wichtigste Tätigkeit des SC17 die Bearbeitung des On-Card-Comparison Standards ISO/IEC 24787, der für Token-basierte Systeme relevant ist. Das SC27 beschäftigt sich in der Working Group 5 mit Identity Management Systemen und Privacy-Enhancing-Technologies und behandelt in diesem Kontext auch biometrische Verfahren und den Schutz von biometrischen Referenzdaten im Rahmen der Standardentwicklung des ISO/IEC 24745 „Information technology – Security techniques – Biometric template protection“ [ISOtp]. Mit beiden Standards werden wesentliche Grundlagen für die Sicherheitseigenschaften eines biometrischen Systems definiert.

4 Biometrische Systeme nach ISO/IEC 24745 Biometrische Systeme werden im Wesentlichen zur Authentisierung und Identifikation eines Individuums eingesetzt. Hierzu vergleicht ein biometrisches System eine vom Individuum genommene Probe mit einer oder mehreren gespeicherten biometrischen Referenzen. Bei einer biometrischen Referenz (BR) handelt es sich um ein biometrisches Sample, ein biometrisches Template oder ein biometrisches Modell, das ein Individuum eindeutig innerhalb eines bestimmten Kontextes identifizieren kann.

Abbildung 1: Struktur eines biometrischen Systems Die Architektur eines biometrischen Systems gliedert sich nach [ISOtp] in die folgenden fünf Subsysteme, die in Abbildung 1 dargestellt sind: Biometrisches Erfassungssubsystem: Beinhaltet Sensoren und bildet die erfassten biometrischen Charakteristika auf biometrische Samples ab.

5

6


Signalverarbeitungssubsystem: biometrischen Samples.

Extrahiert

biometrische

Merkmalsdaten

aus

Datenspeichersubsystem: Dient zur Speicherung erfasster biometrischer Referenzen und Identitätsreferenzen, meist in separaten Datenbanken. Vergleichssubsystem: Vergleicht erfasste biometrische Samples mit gespeicherten biometrischen Referenzen und liefert ein Ähnlichkeitsmaß (Vergleichswert). Entscheidungssubsystem: Entscheidet auf Grund des Ähnlichkeitsmaßes über die Identität des zum erfassten biometrischen Sample gehörenden Individuums. Biometrische Referenzen stellen sensible personenbezogene Daten dar, die entweder unmittelbar (z.B. Gesichtsfoto) oder indirekt (z.B. Fingerabdruck-Minutien) zur Identifizierung einer Person und auf Grund deren Eindeutigkeit potenziell als eindeutiger Identifikator (Universal Unique Identifier - UUID) zur datenbankübergreifenden Verknüpfung von Daten genutzt werden können. Dies stellt eine Gefährdung der Privatsphäre des Individuums dar. Insbesondere sollten biometrische Daten im Besitz und unter Kontrolle der betroffenen Person bleiben und biometrische Samples von biometrischen Systemen nur gespeichert werden, wenn dies dringend erforderlich ist. Weiterhin sollte ein biometrisches System Mechanismen zum Erzeugen diversifizierbarer Referenzen zur Verfügung stellen, um das Widerrufen und Erneuern biometrischer Referenzen zu ermöglichen. 4.1 Sicherheitsgefährdungen und Gegenmaßnahmen Jedes der im vorigen Abschnitt beschriebenen Subsysteme (Datenerfassungssubsystem, Signalverarbeitungssubsystem, Datenspeichersubsystem, Vergleichssubsystem, Entscheidungssubsystem) sowie die zwischen den Subsystemen liegenden Kommunikationskanäle besitzen eigene Angriffsvektoren. Tabelle 1 gibt eine Übersicht über Gefährdungen der Subsysteme und die in ISO/IEC 24745 vorgeschlagenen Gegenmaßnahmen. Subsystem

Gefährdungen

Gegenmaßnahmen

Erfassungssubsystem

Sensor Spoofing mit Plagiaten

- Lebenderkennung - Multimodale Biometrie - Challenge/Response

Signalverarbeitungssubsystem

Einfügen gefälschter Daten

- Verwendung geprüfter und freigegebener Algorithmen

Vergleichssubsystem

Manipulation von Ähnlichkeitsmaßen - Sicherung des Servers (berechneten Vergleichswerten) und/oder Clients - Geschützte Implementierung (z.B. On- Card-Comparison)

Datenspeichersubsystem

Kompromittierung der Datenbank

- Verwendung erneuerbarer biometrischer Referenzen

Biometrische Template-Protection-Verfahren und Interoperabilitätsstrat. Subsystem

Gefährdungen

Gegenmaßnahmen - Datenseparation - Zugriffskontrolle

Entscheidungssubsystem

- Unautorisierte Veröffentlichung personenbezogener Daten - Unautorisiertes Austauschen von gespeicherten Daten (BR, IR) - Unautorisierte Modifikation von BR, IR

- Zugriffskontrollen - Sicherung von BR, IR durch elektronische Signaturen - Sicherung von BR, IR durch Verschlüsselung

Kontinuierliche Modifikation eines biometrischen Samples zur Erreichung der notwendigen Entscheidungsgrenzwerte (HillClimbing Attacke)

- Verwendung grob quantisierter Vergleichswerte - Sichere Kommunikationskanäle

Tabelle 1: Gefährdungen biometrischer Subsysteme und Gegenmaßnahmen. Oft sind biometrische Systeme als verteilte Implementierungen realisiert, so dass sensible Daten zwischen den Subsystemen ausgetauscht werden. Tabelle 2 beschreibt während der Datenübertragung entstehende Gefährdungen und Gegenmaßnahmen. Kommunikationsverbindung(en)

Übertragene Daten

DatenerfassungsBiometrisches subsystem ↔ Sample und Signalverarbeitungs- Merkmalsdaten subsystem ↔ Vergleichssubsystem Datenspeichersubsystem ↔ Vergleichssubsystem

Vergleichssubsystem ↔ Entscheidungssubsystem

Biometrische Referenz

Gefährdungen

Gegenmaßnahmen

Abhören der Daten

Einsatz einer verschlüsselten Kommunikationsverbindung

Wiederholung (Replay-Attacke)

Einsatz von ChallengeResponse-Verfahren

Brute Force

Fehlbedienungszähler

Abhören der Daten


Wiederholte Datenübermittlung (Replay-Attacke)

Einsatz von ChallengeResponse-Verfahren

Man-in-the-middle Angriff

Einsatz einer Ende-zu-Ende verschlüsselten Kommunikationsverbindung und Authentifikation der Teilnehmer

Hill-Climbing Attacke

Verwendung grob dargestellter Vergleichswerte

Vergleichswert Manipulation des Vergleichswertes


Tabelle 2: Durch Datenübertragung auftretende Gefährdungen und Gegenmaßnahmen.

7

8


Zusätzlich zu den in Tabelle 1 und 2 dargestellten technischen Gegenmaßnahmen existieren weitere administrative Gegenmaßnahmen zum Schutz biometrischer Systeme und Daten. Siehe hierzu ITU-T X.tpp-1 [ISOe] und ISO 19092:2008 [ISOf]. 4.2 Erneuerbare biometrische Referenzen Erneuerbare biometrische Referenzen bestehen aus einem pseudonymen Identifikator (PI) sowie dazugehörenden unterstützenden Daten (Auxilliary Data - AD), die während des Enrolmentprozesses aus einem oder mehreren biometrischen Samples erzeugt werden. Pseudonyme Identifikatoren (PI) sind diversifizierbare, geschützte binäre Strings. Ein pseudonymer Identifikator gibt keine Informationen preis, die Aufschluss über die ursprünglich erhobenen Daten, das zu Grunde liegende biometrische Template oder die wahre Identität dessen Besitzers geben. Der Prozess zur Erzeugung pseudonymer Identifikatoren wird in Abbildung 2 dargestellt. Während einer Enrolmentphase wird für ein Individuum eine biometrische Referenz generiert. Innerhalb dieses Prozesses werden von einem Sensor ein oder mehrere biometrische Samples erzeugt und im Anschluss von einem FeatureExtraktor zur Erzeugung biometrischer Merkmale verwendet. Abschließend werden von einem PseudonymousIdentifikator-Encoder (PIE) ein pseudonymer Identifikator sowie Abbildung 2: Erzeugung geschützter Templates möglicherweise benötigte unterstützende Daten erzeugt. In den Prozess einfließende ergänzende Daten (Supplementary Data - SD) können Sicherheitsverbesserungen durch besitz- oder wissensbasierte Schlüssel bewirken, die vom Enrollee eingegeben werden müssen (z.B. biometrisch gehärtete Kennwörter). Alternativ können benutzer-spezifische Parameter als SD gespeichert werden. Die Kombination von pseudonymem Identifikator und unterstützenden Daten wird als ein geschütztes Template bezeichnet. Sowohl der pseudonyme Identifikator, als auch die unterstützenden Daten werden nach deren Erzeugung gespeichert, wohingegen die

Abbildung 3: Referenzarchitektur eines Systems zum Schutz biometrischer Templates.


9

erfassten biometrischen Merkmale zerstört werden. Für die Verifikation wird ein pseudonymer Identifikator neu erzeugt, der dann mit dem während des Enrolments erzeugten PI verglichen wird. Dazu wurden in den letzten zehn Jahren etliche Verfahren vorgeschlagenz.B. [SRS+98], [JW99], [DRS04], [TAK+05], [ST06], [NJP07], [RCCB07]. Die Verifikation wird hierbei durch die Transformation eines Proben-Samples in einen neuen pseudonymen Identifikator PI* unter Verwendung der bereitgestellten unterstützenden Daten erreicht. Ergänzende Daten aus der Enrolmentphase müssen auch dem Pseudonymer-Identifikator-Recoder (PIR) während des Erzeugens des rekonstruierten PI* zur Verfügung gestellt werden. Nach dem Erzeugen von PI* durch den PIR werden alle Eingabedaten, d.h. das biometrische Sample, die Merkmalsdaten und die ergänzenden Daten gelöscht und PI* wird an den Pseudonymen Identifikator-Comparator (PIC) übergeben, der PI mit PI* vergleicht. Abbildung 3 gibt einen Überblick über die Gesamtarchitektur zum Erstellen, Speichern und Verifizieren von pseudonymen Identifikatoren. Der pseudonyme Identifikator und die unterstützenden Daten werden auf einem passenden Medium oder auf unterschiedlichen Medien, wie zum Beispiel Datenbanken, Smartcards, Barcodes, etc., gespeichert. 4.3 Anwendungsmodelle biometrischer Systeme Das Speichern von PI und AD kann auf unterschiedlichen Wegen stattfinden, die sich wie folgt in drei Kategorien einteilen lassen: zentrales Speichern (sowohl PI, als auch AD werden in einer Datenbank gespeichert), lokales Speichern (PI und AD werden gemeinsam auf einem Token gespeichert) und hybrides Speichern durch Separierung von PI und AD (zum Beispiel durch Speichern der unterstützenden Daten auf einem Token und des pseudonymen Identifikators in einer Datenbank). Vorteile des zentralen Speicherns zumindest einer der beiden Datenelemente liegen in der Möglichkeit des Erstellens einer schwarzen Liste, des Realisierens von Prüf-Funktionalitäten (Audits) und des Ermöglichens eines simplen Widerruf-Prozesses. Die Vorteile des lokalen Speicherns sind das Nichtvorhandensein von für zentrale Datenbanken spezifischen Sicherheitsrisiken sowie der vollständige Besitz der Kontrolle über Referenzdaten bei der betroffenen Person. Das hybride Speichern zeichnet sich dadurch aus, dass sowohl die betroffene Person, als auch der Anbieter Kontrolle über die Nutzung der Templatedaten besitzt und die durch eine zentrale Datenspeicherung potentiell entstehenden Sicherheitsrisiken reduziert werden können.) Notwendige Schutzmaßnahmen für ein biometrisches System können oft erst in der Analyse des Anwendungskontextes ausgewählt werden. Zu diesem Zweck beschreibt ISO/IEC 24745 verschiedene Anwendungsmodelle und unterscheidet diese auf Basis des Speicherortes der Referenzdaten sowie des Vergleichsortes. Die hierbei verwendeten Standorte lassen sich wie folgt beschreiben: Client: Bei einem Client handelt es sich um einen Arbeitsplatzrechner oder äquivalentes Endgerät (z.B. PDA, Smartphone) und angeschlossene Sensoren.

ein

10


Server: Ein Server ist ein System, das über ein Netzwerk mit einem Client kommuniziert und Daten zur Verfügung stellt bzw. Operationen ausführt. Token: Ein Token (z.B. SmartCard) kann biometrische Daten speichern und in manchen Fällen auch vergleichen (z.B. On-Card-Comparison). Die in ISO/IEC 24745 beschriebenen Modelle A bis F sind anwendbar auf erneuerbare biometrische Referenzen unter der Annahme, dass PI und AD am gleichen Ort gespeichert werden. Die Modelle G und H hingegen sind ausschließlich für den Einsatz mit erneuerbaren biometrischen Referenzen anwendbar und beschreiben Modelle der Separation von PI und AD. Modell A – Speichern und Vergleich auf Server Modell B – Speichern auf Token, Vergleich auf Server Modell C – Speichern auf Server, Vergleich auf Client Modell D – Speichern und Vergleich auf Client Modell E – Speichern auf Token, Vergleich auf Client Modell F – Speichern und Vergleich auf Token Modell G – Verteiltes Speichern auf Token und Server, Vergleich auf Server Modell H – Verteiltes Speichern auf Token und Client, Vergleich auf Client Die Modelle G und H beziehen sich ausschließlich auf erneuerbare biometrische Referenzen. Das Konzept der Datenseparierung wird durch verteiltes Speichern der Komponenten erneuerbarer biometrischer Referenzen (IR, PI, AD) umgesetzt. Nach diesem Modell wird ein pseudonymer Identifikator in einem Server-seitigen Datenspeicher hinterlegt. Die hierzu gehörenden unterstützenden Daten (AD) werden jedoch zusammen mit der Identitätsreferenz (IR) auf einem benutzerspezifischen Token gespeichert. Durch die Verteilung der erneuerbaren biometrischen Referenz auf unterschiedliche Systeme wird bei der Durchführung einer Verifikation zwingend das Vorliegen korrekter Daten von beiden Systemen notwendig. Diese Vorgehensweise setzt zur Authentisierung immer die Zustimmung der betroffenen Person voraus. Darüber hinaus ermöglicht dieses Modell ein serverseitiges Widerrufen biometrischer Referenzdaten (PI), ohne hierzu Zugriff auf das Token zu benötigen.

5 Interoperabilität von erneuerbaren Referenzen Durch die bisherigen Standardisierungsaktivitäten im Rahmen von ISO/IEC 24745 wurde ein Rahmen für ein biometrisches System mit Mechanismen zum Erzeugen diversifizierbarer Referenzen definiert. Dieser Architekturrahmen ist ein normativer Bestandteil von ISO/IEC 24745 geworden. Konforme Implementierungen müssen daher die beschriebenen Anforderungen zum Widerrufen und Erneuern biometrischer Referenzen erfüllen. Damit ist jedoch nicht sichergestellt, dass Referenzdaten auch zwischen unterschiedlichen Anwendungen ausgetauscht werden können. Die Vielfalt heute angebotener Template-Protection-Verfahren ist per se nicht interoperabel. Um eine Interoperabilität wie bei bildbasierten Referenzen zu erreichen, sollte für die zukünftige Standardisierungsarbeit ein zwei-stufiger Ansatz verfolgt werden.


11

In der ersten Stufe sollte mittelfristig ein Datenaustauschformat als Element des ISO/IEC 19794 Multipart-Standards definiert werden, der die relevanten Datenelemente PI und AD kodiert, wobei für herstellereigene Kodierungen der beiden Elemente entsprechende dynamische Datenfelder vorgesehen werden sollten, wie dies auch bei ISO/IEC 19794-2 definiert wurde. Eine Interoperabilität kann erreicht werden, wenn der Record zusätzlich eine registrierte Hersteller-Identifikationsnummer enthält, so dass ein Verifikationssystem den zum PIE korrespondierenden PIR auswählen und den PI* an den Comparator übergeben kann. Ein entsprechender pragmatischer Ansatz wurde von SC37 bereits für die Kodierung von Bildqualitätswerten unterschiedlicher Hersteller eingesetzt. In einer zweiten Stufe sollte langfristig ein Auswahl-Wettbewerb zu einem standardisierten Verfahren gestartet werden, wie er ähnlich in der Vergangenheit mit dem Advanced Encryption Standard (AES) durchgeführt wurde und derzeit mit der Cryptographic Hash Algorithm Competition durchgeführt wird. Ein solcher AuswahlWettbewerb verlangt transparente Algorithmen, die eine Sicherheitsevaluierung des Template-Protection-Verfahrens ermöglichen. In der Evaluierung sollte der Nachweis der Einweg-Eigenschaft (ENW) geprüft werden, um eine Rekonstruktion des Samples auszuschließen. In einer vergleichenden Evaluierung sollten mindestens die Kriterien Entropie (ENT) des erzeugten Referenzdatensatzes, die Diversifikationseigenschaft (DIV) sowie die Undichtigkeit (DIC) geprüft und bewertetet werden. Darüber hinaus ist eine Evaluierung der Erkennungsleistung nach ISO/IEC 19795-1 erforderlich, um die Performanz (PER) zu bewerten. Ein Ranking von Kandidaten kann erfolgen, in dem die Systemgüte durch Score = 0,5 PER + 0,2 ENT + 0,2 DIV + 0,1 DIC gewichtet bewertet wird. Erkennungsleistung und Sicherheitseigenschaften eines Verfahrens werden dabei gleichgewichtet gefordert. Dieses Maß für die Systemgüte verfolgt den Zweck, einen Zugewinn an Template-Sicherheit nicht auf Kosten der Erkennungsleistung zu bewerten.

6 Zusammenfassung Mit der Standardisierung in ISO/IEC 24745 wurde ein einheitliches Verständnis für Sicherheitsanforderungen an biometrische Systeme sowie für Risiken und empfohlene Gegenmaßnahmen erreicht. Mit der Integration der normativen Anforderung von erneuerbaren biometrischen Referenzen wurden wesentliche Datenschutzmechanismen im Standard verankert. Für System-Betreiber ist neben der Sicherheit aber auch die Interoperabilität von Austauschformaten und damit die Reduzierung von Hersteller-Abhängigkeiten ein wichtiges Ziel. Durch den vorgeschlagenen Auswahl-Wettbewerb kann dieses Ziel langfristig verfolgt und sichere, datenschutzfreundliche und performante biometrische Systeme ermöglicht werden.

12


7 Danksagung Diese Arbeit wurde durchgeführt im Rahmen des Projekts "BioKeyS- Pilot-DB” des Bundesamtes für Sicherheit in der Informationstechnik.

Literaturverzeichnis [Bre08] [CS07] [DRS04] [ISOe] [ISOf] [ISOtp] [Jain08] [JW99] [NJP07] [Par03]

[RCCB07] [SRS+98]

[ST06] [TAK+05]

J. Breebaart, C. Busch, J. Grave, E. Kindt: A Reference Architecture for Biometric Template Protection based on Pseudo Identities, in Proceedings BIOSIG 2008 A. Cavoukian und A. Stoianov: Biometric encryption: a positive-sum technology that achieves strong authentication, security and privacy. Whitepaper information and Privacy Commissioner/Ontario, 2007. available from www.ipc.on.ca. Yevgeniy Dodis, Leonid Reyzin, Adam Smith: Fuzzy extractors: How to generate strong keys from biometrics and other noisy data. In EUROCRYPT, pages 523–540, 2004. ISO/IEC 9594-2, ITU-T X.tpp-1 (Telebiometric Protection Procedure-Part1): A guideline of technical and managerial countermeasures for biometric data security ISO 19092:2008, Financial Services – Biometrics – Security framework ISO/IEC CD 24745 Information technology - Security techniques - Biometric template protection A. Jain, K. Nandakumar, A. Nagar: Biometric Template Security, EURASIP Journal on Advances in Signal Processing, Volume 2008 A. Juels und M. Wattenberg: A fuzzy commitment scheme. In Proc. 6th ACMCCCS, pages 28–36, 1999. K. Nandakumar, A.K. Jain, S. Pankanti: Fingerprint-based fuzzy vault: Implementation and performance. Information Forensics and Security, IEEE Transactions on, 2(4):744–757, Dec. 2007. ARTICLE 29 Data Protection Working Party. Working document on biometrics working document on biometrics. http://ec.europa.eu/justice_home/fsj/privacy/docs/wpdocs/2003/wp80_en.pdf, 2003. Last visited: November 26, 2009 N. K. Ratha, S. Chikkerur, J. H. Connell, R. M. Bolle: Generating cancelable fingerprint templates. IEEE Trans. pattern analysis and machine intelligence, 29(4):561–572, 2007. C. Soutar, D. Roberge, A. Stoianov, R. Gilroy, B. V. K. Vijaya Kumar: In R. L. van Renesse, editor, Society of Photo-Optical Instrumentation Engineers (SPIE) Conference Series, volume 3314 of Society of Photo-Optical Instrumentation Engineers (SPIE) Conference Series, pages 178–188, April 1998. Berry Schoenmakers, Pim Tuyls: Efficient binary conversion for paillier encrypted values. In EUROCRYPT, pages 522–537, 2006. P. Tuyls, A. H. M. Akkermans, T. A. M. Kevenaar, G. J. Schrijen, A. M. Bazen, R. N. J. Veldhuis: Practical biometric authentication with template protection. In Audio and video-based biometric person authentication, pages 436–446.

Biometrische Nachrichten-Authentisierung Christoph Busch1,2, Daniel Hartung2 1

2

Hochschule Darmstadt - CASED Norwegian Information Security Laboratory (NISlab) Teknologiveien 22, 2821 Gjøvik, Norwegen [email protected] [email protected]

Abstract: Bei vielen Anwendungen ist die Integrität und Authentizität übertragener Nachrichten von Interesse. So sind zum Beispiel im Online-Banking sind die relevanten Informationen i) welches Empfänger–Konto eine Gutschrift erhält, ii) welcher Betrag dem Empfänger gutgeschrieben werden soll, iii)) welches Sender-Konto eine Belastung erhält und schließlich iv) welche natürliche Person die Transaktion initiiert und die Transaktionsdaten bestätigt hat. In derzeitig eingesetzten Protokollen sind die Informationen i), ii) und iii) vielfach nur ungenügend geschützt. In keinem der derzeitigen Protokolle wird die Information iv) ausreichend gesichert. Das hier vorgestellte Protokoll zur Biometrischen Nachrichten-Authentisierung realisiert eine Daten-Authentisierung und gleichzeitig eine Personen-Authentisierung. Damit wird eine starke Bindung zwischen einer natürlichen Person und den anderen relevanten Informationen hergestellt und somit für den Ausführenden der Transaktion gesichert nachgewiesen, dass tatsächlich eine berechtigte natürliche Person die Transaktion initiiert und bestätigt hat.

1 Bedrohungen und Vorfälle mit Identitätsmissbrauch Ein Identitätsmissbrauch ist definierbar als Nutzung des Identitätsdiebstahls zum Schaden der betroffenen Person, wobei das vorrangige Interesse des Angreifers in aller Regel eine finanzielle Bereicherung ist. Das Risiko, Opfer eines solchen Ereignisses zu werden, ist in den vergangenen Jahren dramatisch gestiegen. Das Identity Theft Resource Center berichtet für das Jahr 2008 eine Zunahme von 47% im Vergleich zum Vorjahr [Idtc2009a]. Die Liste der Einzelvorfälle dokumentiert zum Beispiel Kreditkartenbetrug, Kontenraub und Bankbetrug und zeigt die zur Beschaffung der notwendigen Informationen eingesetzte Spannbreite von Angriffen. Diese reichen von manipulierten Kartenlesern über Phishing-Angriffe bis hin zu ausgefeilten SocialEngineering-Angriffen, die zur unbedachten Preisgabe von sensitiven Daten motivieren. Diese Gefahren sind auch für Deutschland ein größer werdendes Problem, wie die Statistiken des Bundeskriminalamtes belegen [Bka2008]. Eine Studie des Bundesamtes für Sicherheit in der Informationstechnik prognostiziert, dass die Angriffsszenarien in Zukunft deutlich vielfältiger werden [Bsi2010]. Das Potential für Angriffe steigt durch die zunehmende Nutzung von Online-Banking-Diensten. In Deutschland gab es beispielsweise in den letzten Jahren eine Steigerung von 15 Millionen Online-Konten im Jahr 2000 auf 39 Millionen Online-Konten im Jahr 2008 [Bdb2006], [Grud2009]. Nach einer Studie des BITKOM haben sieben Prozent aller Internet-Nutzer über 14 Jahren

14

Biometrische Nachrichten-Authentisierung

bereits einen finanziellen Schaden beispielsweise durch Viren, bei Online-Auktionen oder Online-Banking erlitten [Bit2008]. Neben Online-Banking Transaktionen sind auch andere sicherheitskritische Anwendungen bedroht, wie beispielsweise die authentische Kommunikation zwischen Einsatzeinheiten eines Krisenstabes im Katastrophenmanagement. Insbesondere bei der Koordination von Einheiten, die ad hoc an einem Katastrophenort zusammengezogen werden wie etwa bei einer terroristisch bedingten Katastrophe ist es essentiell, dass die Authentizität von Nachrichten für den Empfänger einer Handlungsanweisung nachweisbar wird. Nach dem letzten Lagebericht des Bundesamtes für Sicherheit in der Informationstechnik (BSI) geht die Bedrohung weniger von Phishing-Angriffen aus [Bsi2009]. Die Bedrohung wächst vielmehr durch die immer ausgereifteren Mechanismen von bösartiger Software (Malicious Software – Malware), die über verschiedenste Kanäle auf privaten Rechnern installiert wird und dort - ohne Kenntnis des Endanwender - Informationen über verwendete Programme und Nutzdaten wie etwa Finanz-Transaktionen aufzeichnet und an einen entfernten Steuerrechner über das Internet weiterleitet. Zu diesen Malware-Arten zählen Computer-Viren und Trojanische Pferde. Die dabei zum Einsatz kommende Malware ist für das Opfer nur in seltenen Fällen erkennbar. Dies liegt einerseits daran, dass sie ausgefeilte Mechanismen wie Selbstverschlüsselung und Mutation verwenden und somit beim Abgleich mit den Virenmustern in Datenbanken der Anti-Virenhersteller unerkannt bleiben. Andererseits werden Mechanismen wie Rootkits eingesetzt, die das Betriebssystem selbst unterwandern und mit heutigen Methoden kaum zu detektieren sind [Rut2006].

2 Biometrische Authentisierung Unter Biometrie versteht man ein Messverfahren zur Wiedererkennung von Personen. Die Internationale Standardisierung definiert den Begriff biometrics wie folgt: "automated recognition of individuals based on their behavioural and biological characteristics" [Iso-sc37]. Biometrische Verfahren analysieren demnach das Verhalten des Menschen und/oder eine Eigenschaft der biologischen Charakteristika. Die biologischen Charakteristika gliedern sich einerseits in anatomische Charakteristika, die geprägt werden durch Strukturen des Körpers und andererseits in physiologische Charakteristika, die geprägt werden durch Funktionen des Körpers wie beispielsweise die Erkennung der Stimme. Der Vorgang der biometrischen Authentisierung bedingt, dass grundsätzlich eine Person vorab eingelernt wurde (Enrolment), um die notwendigen Referenzdaten zu bilden. Biometrische Authentisierungsverfahren werden in sicherheitsrelevanten Anwendungen substituierend oder ergänzend zu anderen Authentisierungsfaktoren wie Wissens-Authentisierung (Passwort) oder BesitzAuthentisierung über Token (Schlüssel) eingesetzt, um deren Nachteile zu kompensieren. Passworte und Token können – meist unter Missachtung einer Sicherheitsrichtlinie – weitergeben werden, sie werden vergessen oder verloren. Um bei der ansteigenden Zahl der logischen und physikalischen Zugangskontrollen dem Verlust vorzubeugen, werden oft ungeeignete Speicherorte oder identische Passworte verwendet. Im Gegensatz dazu können biometrische Charakteristika nicht vergessen gehen und naturgemäß ist keine Delegation möglich.


15

2.1 Sicherheit biometrischer Systeme Die Bedrohungen der Sicherheit biometrischer Systeme und geeignete Schutzmaßnahmen sind aus der Literatur hinreichend bekannt. Mögliche Angriffe sind denkbar auf den biometrischen Sensor und auf die gespeicherten Referenzdaten [Isosc27]. Die Robustheit des Sensors ist vor allem in einem nicht-überwachten Anwendungsumfeld von Bedeutung; die Sicherheit des Gesamtsystems erfordert, dass von einem Angreifer präsentierte Plagiate (z.B. Gummifinger) einer biometrischen Charakteristik zuverlässig als solche erkannt werden. Alternativ können biometrische Modalitäten wie etwa die Venenerkennung zum Einsatz kommen, bei denen die erfolgreiche Produktion eines Plagiates als unwahrscheinlich eingestuft werden kann. Aus der Sicht einer Betroffenen Person ist die Sicherheit eines biometrischen Systems jedoch auch verbunden mit den Maßnahmen zum Schutz der biometrischen Referenzdaten. Erwartet werden technische Maßnahmen, die es ermöglichen, Referenzdaten zurückzurufen, einen Querbezug zwischen verschiedenen Anwendungen zu verhindern und potentiell in der biometrischen Charakteristik enthaltene Zusatzinformationen nicht zugänglich werden zu lassen. Zur Lösung dieser Anforderungen gibt es verschiedene Ansätze des Biometric Template Protection [Bre2008], die das Speichern von Bild- oder Templatedaten in einer Datenbank entbehrlich machen. Ein bereits kommerziell eingesetztes Verfahren ist das HelperData-Schema [Tak05], das im Folgenden skizziert wird. Proben Merkmalsvektor

Merkmalsvektor

Enrolment

RRV

XRV

Binarisierung

Binarisierung

QBV

QBV’

Datenbank

RBS

RBS U ser ID

RBV

ENC

CBV

XOR

SBV

RNG

SBV

Hashfunktion h(.)

Verifizierung

XBV

AD 1

AD 1

AD 1

AD 2

AD 2 = R BV_ C BV

AD2

PI

PI = h (SBV )

PI

XOR

CBV’

DEC SBV’

=

PI’

Hashfunktion h(.)

JA / NEIN

Abbildung 1: Helper-Data-Schema zum Schutz biometrischer Referenzdaten

16


Um die biometrische Erkennungsleistung zu steigern, wird im Helper-Data-Schema ein Reliable-Bit-Selector (RBS) verwendet. Ein biometrischer Enrolment- und Verifikationsprozess kann in der Folge durch folgende Funktionsblöcke und Variablen beschrieben werden: 2.2 Funktionsblöcke • • • • •

Binarisierung – transformiert realwertigen Merkmalsvektor in binäre Form RBS – Reliable-Bit-Selector (Analysiert Binärvektor nach stabilen Elementen) ECC (ENC/DEC) – Fehlerkorrektur-Block (z.B. BCH-Code) Encoding/Decoding XOR – XOR-Operation auf Binärvektoren Hashfunktion h(.) – Funktion zur Erzeugung von Hashwerten

2.3 Variablen • • • • • •

RRV / XRV – realwertiger Merkmalsvektor (Referenz / Probe) QBV / QBV‘ – quantisierter Merkmalsvektor RBV / XBV – binärer Merkmalsvektor bestehend aus geeigneten Komponenten SBV – binärer Zufalls-Geheimnisvektor CBV – binärer Codevektor (um Fehlerkorrektur erweitertes SBV) AD1 – Auxilliary Data 1: Datensubjekt-spezifischer Indexvektor der geeigneten Komponenten (Reliable Bit Indizes) generiert in RBS • AD2 – Auxiliary Data 2: berechnet aus Geheimnis SBV und biometrischen Daten (AD2 = RBV XOR CBV) • PI – Pseudo-Identifikator berechnet aus dem Hashwert h(.) über dem subjekt- und applikations-spezifischem Geheimnisvektor SBV • Anmerkung: Ein Hochkomma‘ deutet veränderte Version einer Variable an (hervorgerufen durch biometrisches oder sensorbedingtes Rauschen) Wie in klassischen biometrischen Systemen unterscheiden wir zwei Phasen: Die Registrierungsphase (Enrolment) und die eigentliche Verifikationsphase. Zum biometrischen Enrolment sind für das Helper-Data-Schema (HDS) mehrere Präsentationen einer biometrischen Charakteristik erforderlich, so dass Merkmalvektoren gleicher Länge gebildet werden können und als Eingabe für das HDS dienen. Im HDS wird eine binäre Repräsentation durch Quantisierung der biometrischen Daten erzeugt. Die entstandenen quantisierten Binärvektoren werden im Reliable-Bit-Selector-Block (RBS) analysiert, diesmal um Positionen in den Vektoren zu identifizieren, an denen sich Bits befinden, die sich einerseits vom Mittel aller Vektoren der Population unterscheiden aber auch stabil und somit reproduzierbar für ein Subjekt in den Merkmalen vorkamen. Der Binärvektor RBV der die |AD1| stabilsten Komponenten enthält, wird nun mit einem Binärvektor CBV gleicher Länger kombiniert, der im zweiten Prozess generiert wird.


17

In einem parallelen zweiten Prozess wird ein Zufallszahlengenerator (RNG) genutzt um einen binären Geheimnis-Vektor SBV zu erzeugen. Der Hashwert h(.) dieses Vektors wird in der Datenbank gespeichert, ein Berechnen von SBV aus h(SBV) ist somit nicht möglich ohne die Hashfunktion zu brechen. Dieser Wert kann als PseudoIdentifikator (PI) betrachtet werden. SBV wird nun zusätzlich mit dem Binärvektor aus dem ersten Prozess wie folgt verknüpft: Ein Fehlerkorrekturverfahren (ECC-Encoder ENC, z.B. BCH-Codes) wird genutzt um SBV resistent gegen Einzelbitfehler zu machen, die durch die Variation in der biometrischen Probe verursacht werden. Die Kapazität lässt sich leicht variieren, je mehr Fehler korrigiert werden können sollen, desto niedriger ist der Anteil von SBV in dem entstehenden Codewort CBV. Der Fehlerkorrekturcode wird so gewählt, dass CBV und der Binärvektor RBV die gleiche Länge haben. Eine XOR-Verknüpfung dieser beiden Vektoren sorgt dafür, dass ohne das Wissen eines der beiden Eingaben kein Rückschluss auf die andere Eingabe gemacht werden kann. Soll eine Verifikation stattfinden, wird der Datensatz eines Nutzers (AD1, AD2, PI=h(SBV)) geladen und ein frischer Probenvektor XRV verarbeitet. Der Binarisierungs -Block erzeugt daraus den Binärvektor QBV‘. Die Bits an den Positionen die in AD1 gespeichert sind werden durch den RBS-Block extrahiert, so entsteht der Binärvektor XBV. Dieser Vektor sollte bei gleichem Datensubjekt dem Vektor RBV aus der Registrierungsphase sehr ähnlich sein. Durch die erneute XOR-Operation auf AD2 und XBV entsteht CBV‘. Wenn die Hamming-Distanz der Codeworte CBV und CBV‘ kleiner ist als die Kapazität des Fehlerkorrekturverfahrens und wenn die Fehler Einzelbitfehler sind, kann SBV‘=SBV im Fehlerkorrektur-Block (DEC) rekonstruiert werden. Die Entscheidung, ob die Verifikation positiv ist, ergibt der Vergleich von PI‘=h(SBV‘) und dem gespeicherten Wert PI=h(SBV). Um eine Revokation einer biometrischen Referenz durchzuführen, muss ein neuer Geheimnis-Vektor SBV generiert werden, der mit einem frischen Merkmalsvektor (nach Binarisierung und RBS) kombiniert wird. Lediglich AD2 und PI müssen erneut in der Datenbank als Referenz gespeichert werden.

3 Transaktions-Absicherung Bisher werden für Online-Transaktionen eine Reihe von Verfahren eingesetzt, die als nicht ausreichend sicher eingestuft werden müssen bzw. ungewollt eine Delegation der Authentisierungsfaktoren erlauben. Dieser Abschnitt liefert eine Übersicht bekannter Verfahren. Eine vertiefte Diskussion und Sicherheitsanalyse der gegenwärtig eingesetzten Authentisierungsverfahren im Online-Banking findet sich in [Asit08]. PIN/TAN: Zwei-Faktoren-Authentisierung mit Persönlicher Identifikationsnummer (PIN) und Transaktionsnummer (TAN), wobei sich die zu verwendenden TAN’s im Besitz des Bank-Kunden befinden sollen und nach Verwendung (d.h. einer Transkation / Buchung) aus einer Papierliste ausgestrichen werden.

18


PIN/iTAN: Um die Gefahr durch Phishing Angriffe zu reduzieren, wird seit 2006 eine indizierte TAN-Liste verwendet, so dass der Bank-Kunde vom Bank-Server in der Online-Sitzung aufgefordert wird zur Autorisierung einer gewünschten Transaktion eine bestimmte TAN zu verwenden, deren Index (Position) in einer nummerierten Liste von TANs dem Bank-Kunden mitgeteilt wird. Mobile TAN (mTAN): Über einen zweiten Kommunikationskanal werden die relevanten Transaktionsdaten, welche bei der Bank eingetroffen sind per Short Message Service (SMS) Nachricht zum Mobiltelefon des Bank-Kunden übertragen und von ihm durch visuellen Vergleich mit der intendierten Transaktion geprüft. Die Autorisierung der Transaktion geschieht durch Eingabe einer ebenfalls übermittelten mTAN, die nur in einem kurzen Zeitfenster Gültigkeit hat und transaktionsspezifisch ist. TAN-Generatoren: Beim TAN-Generatoren-Verfahren werden mobile Token verwendet, die sequentiell eine TAN elektronisch erzeugen können. Einige TANGeneratoren wie der RSA-Token arbeiten zeitgesteuert. Die Ausprägungsformen sind sm@rt-TAN, eTAN-Generator, chipTAN manuell und chipTAN comfort. Die TAN Generatoren sind dann besonders komfortabel, wenn sie über eine optische Schnittstelle HHD 1.3.2 mit dem Client-PC kommunizieren [Zka2009]. Digitale Signatur / HBCI: Die Digitale Signatur wurde mit dem Homebanking Computer Interface (HBCI) seit 1996 entwickelt und standardisiert1. Damit steht eine Schnittstelle für ein Chipkarten-basiertes Online-Transaktionsprotokoll zur Verfügung. Das Protokoll wurde als Financial Transaction Services (FinTS) vom ZKA weiterentwickelt [Zka2009]. Online-Banking mit USB-Stick: Im Jahr 2009 wurde von IBM mit Zone Trusted Information Channel (ZTIC) ein USB-Stick-Verfahren vorgestellt, dass speziell für sicheres Online-Banking auf Malware-betroffenen Client-Rechnern konzipiert wurde [Wei2008]. Ähnliche Produkte gibt es von den Unternehmen KOBIL und Novosec.

4 Biometrische Transaktions-Authentisierung Vorgestellt wird in diesem Beitrag ein Protokoll zur biometrischen NachrichtenAuthentisierung, exemplarisch dargestellt für die Absicherung von Online-BankingDiensten. Das Protokoll erfüllt die beiden folgenden wesentlichen Anforderungen: 1.) Eine zuverlässige Personen-Authentisierung. Nur die registrierte natürliche Person hat die Transaktion durchgeführt. Das Abstreiten einer tatsächlich durchgeführten Transaktion durch den registrierten Endkunden wird damit unmöglich.

1

HBCI als solches ist kein Sicherheitsverfahren per se sondern ein Standard des ZKA zur Abwicklung von Online-Banking-Transaktionen


19

2.) Eine zuverlässige Daten-Authentisierung. Die registrierte natürliche Person hat die Transaktionsdaten in einer vertrauenswürdigen Umgebung kontrolliert, diese Transaktion autorisiert und die Autorisierung über einen unabhängigen zweiten Kommunikationskanal zum BankServer übertragen. 4.1 Annahmen Auf einem potentiell unsicheren Kundenrechner wird eine Online-Banking-Software (BSW) betrieben, die mit dem Online-Banking-Server (OBS) in der Bank kommuniziert. Die Online-Banking-Software überträgt Transaktionsdaten an den OBS und an das sichere Biometric-Transaction-Device (BTD), auf dem die Bestätigung der Transaktion durch den Endkunden erfolgt. Auf dem BTD wird ein Siegel erzeugt, das als Transaction-Order-Seal (TOS), die Transaktionsdaten mit den biometrischen Daten des Endkunden verknüpft. Für das Biometrische-Nachrichten-Authentisierungs-Protokoll wird von einer Bedrohungs-Situation ausgegangen, die in Abbildung 2 illustriert und im folgenden Abschnitt erläutert wird.

Abbildung 2: Bedrohungs-Situation und Kommunikationswege zwischen OnlineBanking-Software (BSW), Online-Banking-Server (OBS) und Biometric-TransactionDevice (BTD). Die Online-Banking-Software wird auf einem unsicheren Client-Computer betrieben, der Server OBS und das Device BTD werden als sicher eingestuft. 4.2 Komponenten Zur Umsetzung biometrisch sicherer Online-Transaktionen interagieren die folgenden Komponenten, die sich in Bezug auf die Bedrohungssituation unterscheiden: 1.) Ein sicherer Online-Banking-Server (OBS), der folgende Eigenschaften aufweist: • hat Zugriff auf Kundendaten. • etabliert eine Kommunikation mit der Online-Banking-Software (BSW), die auf dem unsicheren Rechner des Kunden betrieben wird. • führt Transaktionen aus.

20


• kann mit einem Biometric-Transaction-Device (BTD) eine Verbindung aufbauen. 2.) Eine Online-Banking-Software (BSW) auf einem unsicherem Kunden-Rechner (Client-Rechner). Die BSW: • wird ausgeführt auf einem Kunden-Rechner, der durch Trojanische Pferde, Root-Kits etc. beliebig gefährdet sein kann. • kann als browserbasierte Applikation ausgeprägt sein. • kommuniziert mit Online-Banking-Server (OBS) und transferiert Aufträge in Form eines Transaction-Order-Record (TOR). Ein TOR beinhaltet: i) Transaktionsidentifikator (TID), ii) Sender-Account-Number (SAN), iii) Receiver-Account-Number (RAN), iv) Ordered Amount (ORA). • Verbunden mit dem Kunden-Rechner ist ein vertrauenswürdiges BiometricTransaction-Device (BTD). 3.) Ein sicheres Biometric-Transaction-Device (BTD), das mit Kunden-Rechner verbunden ist. Das BTD: • ist eine vertrauenswürdige Hardware, die idealer Weise sicherheitsgeprüft wurde (z.B. nach Common Criteria). Die Hardware kann eine dedizierte Komponente, wie etwa ein biometrisch erweiterter Secoder nach ZKA-Anforderungen sein. • kann nicht durch Malware manipuliert werden. • kann eine biometrische Charakteristik erfassen. Dabei wird als BiometricCapture-Device (BCD) ein Sensor eingesetzt, der als überwindungssicher eingestuft werden kann und somit für den nicht-überwachten Betrieb im Heimbereich oder Bürobereich geeignet ist. • kann mit einem Online-Banking-Server (OBS) als Kommunikationspartner eine Verbindung aufbauen. • kann eine Transaction-Order (TRO) von BSW als Transaction-Order-Record (TOR) empfangen und darstellen. • Die Kommunikation zwischen BSW und BTD kann in verschiedenen Optionen ausgeprägt sein. Es kann eine kontaktlose Datenanbindung oder eine optische Schnittstelle (z.B. Flicker-Code) sein. 4.3 Enrolment Zum Enrolment für das Biometrische-Transaktions-Authentisierungs-Protokoll wird das bekannte Helper-Data-Schema wie folgt erweitert (siehe Abbildung 3): 1.) Enrolment-Schritte im Biometric-Transaction-Device (BTD): • Die selbe biometrische Charakteristik des Bank-Kunden wird mit dem BCD erfasst und in Merkmalsvektoren umgewandelt. • Das Hilfsdatum AD1 wird aus Enrolment Samples abgeleitet, wobei charakterisierende Daten zur Verteilung über die Population ebenfalls erforderlich sind. • Ein binarisierter Merkmalsvektor RBV ergibt sich aus den Enrolment-Samples QBV und AD1. • Der Kunde gibt ein Geheimnis SBV ein, das er zusammen mit der ebenfalls vom Server erzeugten Account-Number auf dem Postwege vom OBS erhalten hat. • Der Fehlerkorrektur-Codebookvektor CBV ergibt sich aus: CBV = ENC(SBV) • Die Auxilliary Data AD2 ergibt sich aus CBV und dem binarisierten ReferenzMerkmalsvektor RBV: AD2 = CBV XOR RBV


21

• AD1 und AD2 sind nicht sonderlich schützenswert und werden im BTD oder auf der persönlichen Chipkarte gespeichert 2.) Enrolment-Schritte des Online-Banking-Server (OBS): • Generiert und sendet pre-shared secret (Geheimnis SBV) • Legt Kundenrecord mit den folgenden Daten an: Account-Nummer (AN) und biometrischer Pseudo Identifikator PI = h(SBV) (Hashfunktion h, z.B RIPEMD160, das bereits in der FinTS-Spezifikation genutzt wird) • Sendet SBV samt AN zum Kunden (Postweg)

Bank Kunde

Biometrische Charakteristik

BTD Sensor / BC D

OBS preshared Secret (Geheimnis )

Feature Extraktion

SBV

RRV

Binarisierung

Hashfunktion h(.)RBV

Interner Speicher BTD / Chip Karte

QBV

Datenbank h(SBV )

RBS U ser ID / AN

RBV

ENC

CBV

XOR

AD1

AD 1

U ser ID / AN

AD 2

AD 2 = R BV_ C BV

PI = h( SBV )

SBV

preshared Secret (Geheimnis)

SBV

Abbildung 3: Erweitertes Enrolment

4.4 Prüfung der biometrischen Transaktions-Authentisierung Zur Bestätigung einer vom Bank-Kunden gewünschten Transaktion wird für das Biometrische Nachrichten-Authentisierungs-Protokoll die klassische biometrische Verifikation erweitert. Zur Bestätigung der Transaktion wird lokal, d.h. im Home- oder Office-Umfeld des Bank-Kunden ein Transaction-Order-Seal (TOS‘) berechnet, der dann statt einer TAN an den Bank-Server übertragen wird. Die Arbeitsschritte sind wie folgt (siehe Abbildung 4):

22


1.) Operationen, die in der unsicheren Online-Banking-Software (BSW) durchgeführt werden sind: • Der Kunde erstellt durch Interaktion mit der BSW-Software einen TransactionOrder-Record (TOR). • Der BSW überträgt den TOR an den Online-Banking-Server (OBS) • Der BSW überträgt den TOR an das Biometric-Transaction-Device (BTD). 2.) Operationen, die im Biometric-Transaction-Device (BTD) durchgeführt werden: • Die relevante Information aus dem Transaction-Order-Record (TOR) wird im Display des BTD angezeigt: Receiver-Account-Number (RAN), Ordered-Amount (ORA). Die Ausprägung der Darstellung kann ähnlich wie mit den bereits am Markt erhältlichen chipTAN comfort Token erfolgen. • Zur Bestätigung der gewünschten Transaktion präsentiert der Initiator seine nichtreplizierbare biometrische Charakteristik dem Biometric-Capture-Device. Durch diesen Schritt wird ein Probe Image Sample mit dem BCD erfasst. • Die Auxilliary Data AD1 wird aus dem BTD-Speicher abgerufen • Ein binarisierter Probe-Merkmalsvektor XBV ergibt sich aus dem ProbeSample QBV‘ und AD1 • Ein Codebookvektor CBV‘ wird rekonstruiert aus im BTD gespeicherter Auxilliary Data AD2 und dem binarisierten Probe-Merkmalsvektor XBV: CBV‘ = AD2 XOR XBV • Das Secret SBV‘ wird aus CBV‘ berechnet: SBV‘ = DEC(CBV‘) • Die Pseudo-Identifikator PI‘ wird aus SBV‘ berechnet: PI‘=h(SBV‘) • Es wird ein Transaction-Order-Seal (TOS‘) berechnet aus Transaction-OrderRecord TOR und rekonstruiertem PI‘: TOS‘ = MAC(h(TOR), PI‘) • Das TOS‘ verknüpft als Siegel die Daten eindeutig mit der bestätigenden natürlichen Person. Der berechnete Transaction-Order-Seal kann auch als Message Authentication Code (MAC) bezeichnet werden. Als MAC-Verfahren kann beispielsweise ein HMAC-Verfahren eingesetzt werden, das auf der Hashfunktion h aufbaut. Die Eingabevektoren TOR und PI‘ entsprechen der Nachricht und dem Schlüssel im HMAC-Verfahren. Der Wert TOS‘ lässt sich nach [Rfc2104] z.B. mit RIPEMD-160 als Hashfunktion wie folgt berechnen: • TOS‘ = h(PI‘ XOR OPAD, h(PI’ XOR IPAD, TOR)) • Das Transaction-Order-Seal (TOS‘) wird zum Online-Banking-Server übertragen und gegebenenfalls vorab mit asymmetrischer Kryptographie verschlüsselt. Die Übertragung kann über den unsicheren Client-Rechner getunnelt werden oder alternativ (und bevorzugt) über einen zweiten unabhängigen Kanal. Dieser zweite unabhängige Kanal kann beispielsweise über das GSM-Netz realisiert werden. Diese Variante wird insbesondere dann bevorzugt werden, wenn das BTD in einem marktüblichen Mobiltelefon / Smartphone hardwaretechnisch integriert wird. 3.) Operationen, die im Online-Banking-Server (OBS) durchgeführt werden. Der OBS: • hat den Transaction-Order-Record (TOR) von der Banking-Software (BSW) erhalten. • hat den Transaction-Order-Seal (TOS‘) von dem Biometric-Transaction-Device (BTD) erhalten • hat den PI zum Kunden vorliegen PI=h(SBV) • rekonstruiert den TOS: TOS = MAC(h(TOR), PI)


23

• vergleicht den rekonstruierten TOS mit dem vom BTD gelieferten TOS‘: • TOS = = TOS‘? Die Transaktion ist personen- und datenauthentisch, wenn TOS und TOS‘ identisch sind. In diesem Fall und nur in diesem Fall gilt der im Transaktions-Record kodierte Auftrag als authentisch und bestätigt und wird vom OBS ausgeführt. Die notwendigen Verifikations-Schritte im BTD und auf dem OBS zur Bestätigung der Transaktion und zur gleichzeitigen Prüfung von Personen-Authentizität und DatenAuthentizität werden in der folgenden Abbildung dargestellt.

Bank Kunde

Biometrische Charakteristik

Interaktion TOR = TID , SAN , RAN, ORA

Display Unit

BTD Sensor / BC D

OK?: Initiali sierung

BSW RAN, ORA

Feature Extraktion

OBS

TOR (TID, SAN, RAN, ORA)

Hashfunktion h(.)

TOR

Interner Speicher BTD / Chip Karte

XRV

Binarisierung

Datenbank

h(TOR)

QBV’

U ser ID / AN

RBS

AD 1

AD 1 AD 2 = R BV _ C BV

XBV

U ser ID / AN

TOR

PI = h (SBV )

AD2

DEC

CBV’

PI

MAC

XOR TOR TOS

SBV’

Hashfunktion h(.)

PI’ = h(SBV’ ) h(TOR)

MAC

=

TOS’

Ja / Nein

Abbildung 4: Prüfschritte einer biometrischen Transaktions-Authentisierung

5 Zusammenfassung und Ausblick Durch das hier vorgelegte Transaktionsprotokoll wird die Personen-Authentisierung mit der Daten-Authentisierung verknüpft und damit die Forderung des Bundesverbandes Deutscher Banken erfüllt, dass durch die Nutzung der Biometrie im Online-Banking „eine Bindung des eineindeutigen biometrischen Merkmals des Kunden an seine gewollte Transaktion“ erreicht wird [Grud2009]. Sicherheitsrelevante Funktionalität

24


wird in einem Biometric-Transaction-Device gekapselt, das auch als biometrischer Secoder verstanden werden kann. Der wesentliche Sicherheitsgewinn im Vergleich zu existierenden Protokollen besteht darin, dass eine unerlaubte Delegation von Authentisierungsfaktoren ausgeschlossen werden kann. Weitere Anwendungsfelder ergeben sich z.B. in der Nachrichtenkommunikation im KRITIS- und Katastrophenmanagement. Durch den geringen Funktionsumfang des BTD ist eine Ausprägung in Hardware leicht realisierbar und eine Common-Criteria-konforme Sicherheitsprüfung dieser Komponente möglich.

Literaturverzeichnis [Asit08]

A-SIT: Secure Information Technology Center Austria, Österreichische Nationalbank. Risikoanalyse – E-Banking Angebote Österreichischer Kreditinstitute, 2008 [Bdb2006] Bundesverband Deutscher Banken: „Anzahl der Online-Konten“, http://www.bankenverband.de/downloads/112007/1ta0711-pr-onlinekonten.pdf [Bit2008] Branchenverband BITKOM: „Fast 4 Millionen Opfer von Computer- und InternetKriminalität“, http://www.bitkom.org/de/presse/56204_53100.aspx [Bka2008] Bundeskriminalamt: „Aktuelle Herausforderungen in der Kriminalitätsbekämpfung“, http://www.bka.de/pressemitteilungen/2008/pm080328.html, März 2008 [Bre2008] J. Breebaart, C. Busch, J. Grave, E. Kindt: „A Reference Architecture for Biometric Template Protection based on Pseudo Identities“, in Proceedings BIOSIG2008, pages 25-37, GI-LNI, (2008) [Bsi2009] Bundesamt für Sicherheit in der Informationstechnik: „Die Lage der IT-Sicherheit in Deutschland 2009“, https://www.bsi.bund.de/Lageberichte [Bsi2010] Bundesamt für Sicherheit in der Informationstechnik: „Identitätsdiebstahl und Identitätsmissbrauch im Internet “, https://www.bsi.bund.de/Studien [Grud2009] W. Grudzien: „Sicherheit in der Kreditwirtschaft“, Vortrag auf der Fachtagung für FinanzDL am 22.09.2009 [Iso-sc37] ISO/IEC JTC1 SC37 SD2 Harmonized Biometric Vocabulary, September 2009 http://www.3dface.org/media/vocabulary.html [Iso-sc27] ISO/IEC JTC1 2ndCD 24745: Biometric Template Protection, Januar 2010 [Idtc2009a] Identity Theft Resource Center: Security Breaches 2008, http://www.idtheftcenter.org/artman2/publish/lib_survey/Breaches_2008.shtml [Rfc2104] H. Krawczyk, M. Bellare, R. Canetti. “RFC2104 - HMAC: Keyed-Hashing for Message Authentication”, 1997, http://www.faqs.org/rfcs/rfc2104.html [Rut2006] J. Rutkowska: „Introducing Stealth Malware Taxonomy“, http://www.invisiblethings.org/papers/malware-taxonomy.pdf [Tak05] P. Tuyls, A. H. M. Akkermans, T. A. M. Kevenaar, G. J. Schrijen, A. M. Bazen, and R. N. J. Veldhuis. “Practical biometric authentication with template protection.” In Audio and video-based biometric person authentication, pages 436–446. Springer, Berlin, Germany, 2005. [Wei2008] T. Weigold et al.: „The Zurich Trusted Information Channel – An Efficient Defence against Man-in-the-Middle and Malicious Software Attacks“, in : TRUST 2008, LNCS 4968, pp. 75–91, http://www.zurich.ibm.com/pdf/csc/ZTIC-Trust-2008final.pdf [Zka2009] Zentraler Kreditausschuss: „FinTS Spezifikation“, Version vom 02.02.2009, http://www.hbci-zka.de/dokumente/aenderungen/V3.0/HKTAN4_zur_Unterstuetzung_von_HHD_UC.pdf

Diffusion of Federated Identity Management 1

2

Detlef Hühnlein1 , Heiko Roßnagel2 , Jan Zibuschka2 secunet Security Networks AG, Sudetenstraße 16, 96247 Michelau, [email protected]

Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Nobelstr. 12, 70569 Stuttgart {heiko.rossnagel,jan.zibuschka}@iao.fraunhofer.de

Abstract: In this work, we discuss the diffusion of federated identity management. We base our research on Roger’s diffusion of innovation theory, and derive generic factors influencing the diffusion of federated identity management solutions. To validate our model and investigate specific contributions of parameters in specific usage scenarios, we investigate market success of federated identity management systems. We examine several application scenarios in the fields of e-business, Web, and e-government.

1 Introduction Identity Management (IdM) has emerged as a promising technology to distribute identity information across security domains [MR08]. In e-business scenarios, federated identity management is used to connect enterprises along the value chain and enables them to reduce transaction costs significantly. On the web it offers the promise of single sign on for different domains and service providers, offering a common authentication and authorisation infrastructure that eliminates the neccessity of using passwords. This would on one hand provide improved ease of use for the users and at the same time eliminate problems that are caused by password management issues, password reuse [IWS04], and passwords’ security flaws [Neu94]. Therefore, it could make a major contribution to improvement of security on the web. In the e-government domain, Identity Management Systems (IMS) could help to introduce the necessary security infrastructure enabling online services that so far could not have been offered by public administration due to security constraints. Several different solutions for Federated Identity Management (FIM) have emerged over the last couple of years such as Microsofts Passport and Cardspace, Liberty Alliance and OpenID. The success of these systems in the marketplace has been very diverse. Some Systems, such as Passport, have not been successful and have been replaced [CJ07]. Other systems have been highly succesfull in particular domains, such as SAML in e-business scenarios. In other domains, however, the same systems have not achieved this kind of success. In this contribution we will examine the market success of FIM systems in different application domains. In particular we want to explore how economic principles affect this success. Since federated identity management is a complex technology that can be applied to several different domains, we distinguish three different usage scenarios and perfom

26

Diffusion of Federated Identity Management

a cross-case study. To do this we apply Roger’s diffusion of innovation theory [Rog03], which is a proven economic theory for explaining the market success or failure of innovations, to each scenario and compare and discuss the results. The rest of the paper is structured as follows. In section 2 we will provide an overview on FIM and diffusion theory in general. We will apply this diffusion theory to FIM and discuss the factors influencing the adoption in section 3. We then validate our arguments from section 3 by taking a close look at three different usage scenario case studies in section 4. Our results are discussed in section 5, concluding our findings.

2 Background and Related Work 2.1

Federated Identity Management

Among the important Identity Management processes is the authentication, identification and authorization of Users (U) who want to access some resource offered by some Service Provider (SP). For this purpose U is equipped with one or more Credentials, which are presented to the SP. While the SP in a classical IdM scenario must itself understand, verify and accept U’s Credentials, those tasks may be delegated to a specialized Identity Provider (IdP) in a federated setup. Hence a FIM system may be viewed as a sequence of entities that transform a Source Credential of U into a Session Credential that is consumable by a SP who makes a decision on whether to grant access to a sensitive service. Before U is able to use the service offered by the SP, the following steps are typically performed: 1. U A → SP : The User Agent (UA) contacts the SP and requests some service. 2. SP → U A: The SP answers the request, possibly including additional information about supported protocols, appropriate IdPs, necessary authentication assurance levels, requested attributes etc. 3. U A → IdP : The UA connects to the IdP in order to authenticate with the Source Credential and request a Session Credential that can be presented to the SP. 4. IdP : The IdP authenticates U based on the Source Credential, uses an existing session in which authentication has already been performed previously or further delegates the authentication to another IdP. 5. IdP → U A: If the authentication was successful, the IdP returns a Session Credential to the UA. 6. U A → SP : The UA sends the Session Credential received from the IdP to the SP. 7. SP : The SP validates the Session Credential and verifies the access rights of the now authenticated U.


27

8. SP → U A: The SP serves the requested resource to the UA. Furthermore, there may be additional steps for identity selection (IS), in which U, UA, and/or the SP interact in order to select an appropriate electronic identity and hence IdP to be contacted in step 3. In addition, there typically is some sort of trust relationship (T) between the SP and the IdP, which allows to verify the integrity and authenticity of the Session Credential. Federated authentication and SSO systems are around for quite a while [SNS88]. and the most important protocols in this area comprise the Security Assertion Markup Language (SAML) [CKPM05], the WS-* series of standards [NKMHB06] together with the Identity Metasystem Interoperability profile [JM09] and last but not least OpenID [Fou]. Please refer to [LOP04, MR08] for a more complete survey.

2.2

Diffusion Theory

In the information systems literature, a variety of theoretical perspectives have been advanced to provide an understanding of the determinants of usage. An important line of research has examined the adoption and usage of information technology from a diffusion of innovation perspective [Rog03]. This research examines a variety of factors, which have been shown to be determinants of IT adoption and usage, and has been applied to explain the adoption and diffusion of a great variety of innovations ranging from new methods of agriculture to modern communication technology. In his seminal work Rogers defines five attributes of innovations, as perceived by the members of the social system that determine the rate of adoption of an innovation [Rog03]: Relative advantage. is the degree to which an innovation is perceived as better than the idea it supersedes. It is not so important if the innovation has an objective advantage, but rather if the individual perceives the innovation as advantageous. Advantages can be measured in economic terms, but social prestige, convenience, and satisfaction also can play an important role. Compatibility. is the degree to which an innovation is perceived as being consistent with the existing values, past experiences, and needs of potential adopters. An Innovation that is consistent with the existing values will diffuse more rapidly than one that is incompatible with the norms and values of the social system. Complexity. is the degree to which an innovation is perceived as difficult to understand and use. Innovations that are easier to understand will be adopted more rapidly than those which require the adopter to develop new skills and understandings.

28


Triability. is the degree to which an innovation may be experimented with on a limited basis. New ideas that can be tried before the potential adopter has to make a significant investment in the innovation are adopted more quickly. Observability. is the degree to which the results of an innovation are visible to others. The easier it is for individual to observe the results of an innovation, the more likely they are to adopt [Rog03]. An interactive innovation is an innovation that is of little use to an adopting individual unless other individuals with whom the adopter wants to communicate also adopt. Thus a critical mass of individuals has to adopt the innovation before it is of use for the average member of the system [MR99]. The individuals who have adopted an innovation form a network and with each new member the overall value of the network increases [MR99]. This fundamental value proposition is being called network effects, network externalities, and demand side economics of scale [SV99]. Until a critical mass occurs in the diffusion process the rate of adoption is relatively slow [MR99]. After the critical mass is achieved the rate of adoption accelerates and leads to a take off in the adoption curve. The diffusion of security technologies has been discussed by various authors in the context of TOR [ADS03], electronic signatures [Roß06] and smartcards, as well as certificates for web sites [OS06]. Economic aspects of IdM systems have been addressed in the context of possible hindrances for the success of such systems [DD08], and network effects and compatibility have been identified as a decisive factor in the context of certificates and security technologies in general [OS06], however, to our knowledge, no broader discussion of this problem exists, especially covering not only one specific use case (i.e. the Web), but a broader range of identity management deployments.

3 Diffusion of Federated Identity Management Relative advantage. In the context of identity management, relative advantage is the utility that an IMS can offer to its stakeholders, including both end users, SPs, enterprises, and other players, compared to the previous state of the art (e.g. passwords on the Web). Examples of how a IMS can offer utility include: • Reduced sign on is one of the main benefits provided by IMS. In the enterprise case, it lowers help desk costs, while on the web, it unburdens users of password management worries. • Privacy is also often mentioned as one of the issues IMS can help address. Integration of anonymization and privacy-enhancing technologies into an IMS [HBC+ 01] offers value to privacy-sensitive users. • Reduction of user interaction Form-filling reduces the time users have to spend while registering. e-government applications may enable users to carry out admin-


29

istrative tasks online, rather than at the local authority offices. In the context of Web services, this may also lead to a larger registered user base, as the effort necessary for registration is lowered. • Security IMS have the potential to alleviate common security risks of passwords [Neu94]. However, as SSO also adds a single point of failure, IMS also have higher security requirements than analogous decentralized password systems. • Identity Intermediation Identity intermediation, the outsourcing of user identity storage and part of the authentication process, offers cost reductions, compliance risk reduction, and increased identity quality to service providers [ZFR+ 07]. So, all in all, IMS can offer competitive advantage on several levels. However, an IMS may also decrease utility for several reasons. • Liability: Depending on contract, an identity provider may be held liable for the identities it provides. A user employing a signature card rather than a password may find himself bound by contracts and held liable in a way that would not be possible with password-based authentication. • Costs of certification, implementation and other IdM processes may eat up the advantage gained from the other factors. It should be noted that network effects play a huge role in each scenario because FIM is by nature an interactive innovation. It is quite obvious that a system with a larger user base would be more appealing to service providers, while a system supported by a larger set of services would be of a higher utility to users, offering a meaningful reduction of sign-on processes. (Social) Compatibility. In the context of IMS, compatibility refers mainly to privacy/trust questions. Trust is a key inhibitor of the broader success of e-business systems, which may be addressed using privacy-enhancing IMS [HBC+ 01]. However, trust-related previous work shows that 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]. Also, trust in the SP influences the trust in the system much stronger than the trustworthiness of the system influences trust towards the SP [MCK02]. With regard to compatibility with user expectations, passwords are still dominant. Especially in the web case, passwords will have to be offered simultaniously to reach compatibility with users’ authentication expectations. Compatibility could also be an issue for service providers depending on the business model of the IdP. Complexity. Usability also has a major influence on the perceived complexity of an innovation by users. Many systems require the users to learn a new authentication interaction

30


paradigm, causing new usability problems [MR08]. If the users have the impression that the system is difficult to use or to obtain, they are unlikely to adopt unless the perceived relative advantage significally outweighs these hindrances. On the other hand, IMS have the potential to offer a significant reduction of complexity to end users, with SSO relieving the users of password management problems, and form filling reducing the time spent while registering. For SPs the perceived complexity of FIM is not a question of using this technology but rather a question on how easily such systems can be implemented on the server side. This includes potential sunk cost for installing the infrastructure and the operation of several different authentication systems. Even if SPs switch to FIM for user authentication they will still have to support password authentication, because otherwise they would exclude a huge amount of potential customers of using their services. For enterprises that want to adopt a IMS, a major factor influencing the perceived complexity will be how easily the system can be adapted to and integrated in existing business processes. If major adjustments to existing processes have to be made, the complexity of adopting the innovation increases significally and the costs of adoption will also increase. Triability. is generally not an issue, as many IMS can be experimented with on a limited basis. However, there are also areas where triability is problematic. In the context of enterprise identity management, complete deployments cannot be easily evaluated, and assumptions about the cost savings have to be made. In national e-government IMS, such as eIDs, ex ante costs such as the price of card readers may inhibit users from trying out the system. On the SP side, it may not be trivial to integrate IMS. Even where modular encapsulated interoperable IMS modules for SPs exist, usability issues add another layer of cost and risk to lose users. Observability. Signalling quality is a problem for FIM [BHTB05]. It’s hard to understand and to see the differences in applied security solutions for users. This could lead to a lemons market, which was defined in [Ake70]. In this pioneering article the author argues that information asymmetry and uncertainty about the product quality will lead to a market failure, unless appropriate counteracting mechanisms are undertaken. In a market that contains good and bad (lemons) FIMs, imperfect information about service quality causes the user to average the quality and price of the service used. The information gap enables the opportunistic behaviour of the owner of a lemon to sell it at average price. As a result, the better quality service will not be used since the price it deserves can not be obtained. The consequence of such practice will lead to a continuous fall of both quality and value of services. On the other hand, the advantages of SSO are easily observed by users. The same applies for cost reductions in the helpdesk area reached through enterprise SSO systems. However, the lemon market problem applies, at the very least, to certification authorities acting as a stakeholder in IMS.


31

4 Case Studies The specific factors influencing diffusion of IMS are dependent on the usage scenario. In the case of Relative Advantage/Usefulness, the main drivers seem to be help desk cost reduction in enterprise settings, SSO in Web scenarios, and security (as enabler for new services) in e-government. Therefore, different systems, which emphasise different characteristics have prevailed in different scenarios. This section investigates e-business, Web and e-government scenarios, and illustrates the effects described in a more general manner in the earlier sections.

4.1

Case 1: E-Business - Circle of Trust

Real world examples can be found in the automotive industry. For example there is a technical recommendation [ODE09] based on SAML v2.0 [CKPM05], which has been developed by an Odette1 working group consisting of leading automotive enterprises2 and technical supporters3 and provides guidance for the implementation of federated SSO scenarios between companies in the automotive sector. In a similar fashion SAML has been proposed for cross-enterprise rights management in the automotive industry [iA09]. In these e-business scenarios federated identity management succeeds along the valuenetworks forming a circle of trust between the participating enterprises. It is mainly aligned to existing business and trust relationships between enterprises, which act as SP and IdP respectively, and U is typically an employee of either company. In these valuenetworks dominant stakeholders exist that can act as a champion for the technology influencing other stakeholders to adopt the same technology more rapidly [Rog03]. The dominating driving force for the adoption of federation techniques is the general wish to minimize transaction costs. In particular the SP will spare to issue Credentials to Users at business partners, if there is an IdP, which already did that, supports the same federation protocol as the SP and last but not least may be trusted to perform the authentication on behalf of the SP. Therefore, the perceived relative advantage mainly comprises of cost reduction (due to reduced sign on) and identity intermediation.

4.2

Case 2: Web Identity Management

Passwords have long been the predominant means for user authentication on the web. This is also true for other scenarios, however, in the Web scenario, even adopters of IMS mostly still support passwords. This may be because the lack of coordination in this scenario 1 See

http://www.odette.org/. BMW Group, Bosch GmbH, Daimer AG, Hella KGaA Hueck & Co, Volvo Personbilar Sverige AB and ZF Friedrichshafen AG. 3 Including Covisint Compuware GmbH, iC Consult GmbH, Microsoft AG, PingIdentity Corporation and Siemens AG. 2 Including

32


makes a timed adoption across users unlikely, and gaining a user base is central to the business goals of many Web services. Consequently, the advantage offered by an IMS on the Web would have to outweigh lost users who do not use it. As this is unlikely, passwords will likely not be superseded completely. Microsoft Passport [Mic] was one of the first deployed systems to translate the idea of SSO to the web. It was based on the architecture of centralized intra-organizational SSO systems geared towards managing user access to individual services within an enterprise. Passport was rolled out as part of the infamous HailStorm initiative, and was soon criticized for privacy and security shortcomings. Those problems were insecurities of the system design [KR00], and the centralized storage of identity information requiring trust in Microsoft. Although Passport had originally been adopted by several big players (such as eBay and monster.com), the infrastructure did not take off, and eventually the early adopter services left. The conventional wisdom from this case study is that insecurity and trust issues can make IMS fail, which was one of the motivators for the privacy-enhancing IdM movement [HBC+ 01]. However, Passport has recently made quite a comeback under the new name of Windows Live ID [Mic], mainly used for internal SSO across all Live services, and has become one of the top 5 most successful Web IMS (see Figure 1). As a follow-up to Passport, Microsoft presented the CardSpace IMS [CJ07]. CardSpace is based on the concept of InfoCards, which allow the user to choose the identity to present to a service from a set of partial identities for different use cases. The CardSpace user interface presents a rolodex-like screen for selection of the appropriate InfoCard after the user has (typically) clicked on the log-in icon at a web site. While CardSpace is technologically superior to the original Passport [MR08], CardSpace has not fared any better than Passport during the adoption process, and early adopters are already leaving again. Whether it will see a comeback similar to Passport remains to be seen, however, there is no obvious alternative application case. OpenID [Fou] was originally developed for use in the LiveJournal online community as a lightweight, decentralized way to authenticate commenters [MR08]. It is a web-centric FIM protocol that uses user-supplied web addresses for identifying IdPs, and supports self-hosted IdPs. The user enters the URL of her IdP, and is then logged into a service via the IdP provided. While there have been several security problems with OpenID [MR08], OpenID has still seen quite a broad adoption, easily outperforming Live ID and going head-to-head with Google ID, the SSO system used for Google services such as GMail (see Figure 1). What set OpenID and Passport apart may well have been the ability to freely choose (or self-host) the IdP instead of being bound to Microsoft, a compatibility factor. However, online community sites like Facebook and Twitter have recently implemented their own SSO solutions, specific to their platforms, and transmitting the user’s social graph along with classical identity information. As Figure 1 shows, those systems have gained an even stronger traction than OpenID. As of such, the misfortune of Passport should probably be attributed to distrust in Microsoft, rather than generic compatibility/privacy issues. The Web is an open scenario, with relatively little coordination and trust between enti-


33

Figure 1: Diffusion of leading Web-scale IMS

ties (compared to the e-business and e-government scenarios). In this application field, lightweight IMS integrating directly with web user interface paradigms have dominated more elaborate systems offering more advanced security guarantees for several generations. Recent developments seem to demonstrate that systems making available the user’s social graph to third parties have a considerably higher adoption rate. This supports the theory that in the Web case, compatibility issues are dominated by complexity issues (on the user side) along with the competetive advantage of user information that can be used e.g. for personalization. Additionally, the case of CardSpace may be taken to illustrate that making an IMS more secure cannot replace trust in the operator of the system, even if the system is privacy-friendly (fully client-side anonymous credentials) and open (e.g. with regards to third party certificates). Rather, those technological complexities seem to put extra burden on those systems.

4.3

Case 3: E-Government

There are several services in e-government scenarios that, if they are performed online by citizens, could lead to a major cost reduction within the public administration. So far many of these services can not be offered to a broad audience, because the technology to address the neccessary security requirements has not been adopted by the general population. In the past electronic signatures have been proposed as a suitable solution to address the

34


demanding security requirements of e-government processes. However, they have not been successful on the market. An analysis of the reasons for their lack of market success can be found in [Roß06]. As is evident by the various real world projects listed in the following, FIM could provide a major contribution to close this gap: Secure idenTity acrOss boRders linKed (STORK) is a project, which aims at establishing a European eID Interoperability Platform, which allows cross-border recognition of national eID tokens. For this purpose there will be Pan-European Proxy Services (PEPS) in the different EU member states, which are connected through a SAML-based interface as specified in [AMHAJ+ 09]. SuisseID uses hardware tokens and X.509-based certificates for authentication as core of a more comprehensive ”Claim Assertion Infrastructure” based on SAML [CKPM05] and WS-Trust [NGG+ 07]. German eID-Server is necessary for accessing the identity attributes stored on the forthcoming German eID-card and provides a SAML-based interface [BSI10]. Secure Access to Federated e-Justice/e-Government (S.A.F.E.) aims at providing a scalable Federated Identity Management architecture for the German e-justice sector, which complements the existing OSCI-based infrastructures with components based on international standards. The success of FIM systems in E-government scenarios will highly depend on the services that can be offered based on this technology and the perceived relative advantage these services can provide to the citizens. In use cases where security requirements and the perceived value are high, FIM solutions that are issued by the government could be very successfull, as from a users perspective the relative advantage of FIM in E-government mainly comprises of form-filling and security. In comparison to solutions that are prevailant in the web scenario, infrastructures that are supported by the government do not face the problem of signaling their quality, as citizens tend to put more trust into those solutions. There is hope that once adopted in an e-government scenario the same technology will spread to other use cases and in particular to the web use case. From a technological perspective this assumption is very sound, since secure solutions can also be applied to scenarios that do not require such an amount of security. However, from an economic perspective the success of these systems in other domains such as the web scenario is rather unlikely, because they have to compete with incumbent technologies, that already offer similar services. The main relative advantage of e-government solutions compared with other FIM systems will then be the higher degree of security. However, it is rather unlikely that this will be a driving factor for user adoption.

5 Conclusion Federated identity management systems are a promising technology to achieve cross domain user authentication. Several different systems have emerged and have achieved a


35

mixed success in the marketplace. We examined the market uptake of FIM, by applying the diffusion of innovations theory to explain the success (and lack thereof) of various FIM-Systems in different usage scenarios. Our results show that in enterprise scenarios the diffusion of FIM follows established trust and business relationships along the valuenetwork. In the web scenario we conclude that reducing complexity is by far more important than achieving a high degree of compatibility. In The most promising e-government scenarios are those that provide a high value to users while at the same time demand high security standards.

References [ADS03]

Alessandro Acquisti, Roger Dingledine, and Paul Syverson. On the Economics of Anonymity. In Financial Cryptography, pages 84–102. 2003.

[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.

[AMHAJ+ 09] J. Alcalde-Morańo, J. L. Hernández-Ardieta, A. Johnston, D. Martinez, and B. Zwattendorfer. Interface Specification. STORK Deliverable D5.8.1b, 08.09.2009, September 2009. [BHTB05]

James Backhouse, Carol Hsu, Jimmy C. Tseng, and John Baptista. A question of trust. Commun. ACM, 48(9):87–91, 2005.

[BSI10]

BSI. eID-Server. Technical Directive (BSI-TR-031030), Version 1.1, 08.02.2010, 2010.

[CJ07]

Kim Cameron and Michael B. Jones. Design Rationale behind the Identity Metasystem Architecture. In ISSE/SECURE 2007 Securing Electronic Business Processes, pages 117–129. 2007.

[CKPM05]

Scott Cantor, John Kemp, Rob Philpott, and Eve Maler. Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS Standard, 15.03.2005, 2005.

[DD08]

Rachna Dhamija and Lisa Dusseault. The Seven Flaws of Identity Management: Usability and Security Challenges. IEEE Security & Privacy Magazine, 6(2):24–29, 2008.

[Fou]

OpenID Foundation. OpenID Authentication 2.0. Final, December 5, 2007. http: //openid.net/specs/openid-authentication-2_0.html.

[HBC+ 01]

Marit Hansen, Peter Berlich, Jan Camenisch, Sebastian Clauß, Andreas Pfitzmann, and Michael Waidner. Privacy-enhancing identity management. Information Security Technical Report, 9(1):35–44, 2001.

[iA09]

ProSTEP iViP Assocation. Enterprise Rights Management. PSI-Recommendation 7, Version v0.9, Annex B, Cross-Enterprise-ID, 2009.

[IWS04]

Blake Ives, Kenneth R. Walsh, and Helmut Schneider. The domino effect of password reuse. Commun. ACM, 47(4):75–78, 2004.

36


[JM09]

Michael B. Jones and Michael McIntosh. Identity Metasystem Interoperability Version 1.0. OASIS Standard, July 2009.

[KR00]

David P. Kormann and Aviel D. Rubin. Risks of the Passport single signon protocol. Computer Networks, 33(1-6):51–58, June 2000.

[LOP04]

Javier Lopez, Rolf Oppliger, and Günther Pernul. Authentication and authorization infrastructures (AAIs): a comparative survey. Computers & Security, 23(7):578– 590, October 2004.

[LT01]

M.K.O. Lee and E. Turban. A trust model for consumer Internet shopping. International Journal of Electronic Commerce, 6(1):75–91, 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.

[Mic]

Microsoft. Windows Live ID/Passport Network. https://accountservices.passport.net/ppnetworkhome.srf?vv=700&lc=1031.

[MR99]

Alwin Mahler and Everett M. Rogers. The diffusion of interactive communication innovations and the critical mass - The adoption of telecommunication services by German banks. Telecommunications Policy, (23):719–740, 1999.

[MR08]

Eve Maler and Drummond Reed. The Venn of Identity: Options and Issues in Federated Identity Management. IEEE Security & Privacy Magazine, 6(2):16–23, 2008.

[Neu94]

Peter G. Neumann. Risks of passwords. Commun. ACM, 37(4):126, 1994.

+

[NGG 07]

Anthony Nadalin, Marc Goodner, Martin Gudgin, Abbie Barbir, and Hans Granqvist. WS-Trust 1.3. OASIS Standard, 19.03.2007, 2007.

[NKMHB06] Anthony Nadalin, Chris Kaler, Ronald Monzillo, and Phillip Hallam-Baker. Web Services Security: SOAP Message Security 1.1. OASIS Standard, 01.02.2006, 2006. [ODE09]

ODETTE. SESAM specification for building up federated Single-Sign-On (SSO) scenarios between companies in the automotive sector. ODETTE Recommendation, Draft of 15.07.2009, July 2009.

[OS06]

A. Ozment and S. E Schechter. Bootstrapping the adoption of Internet security protocols. In Fifth Workshop on the Economics of Information Security, Cambridge, UK, 2006.

[Rog03]

Everett M. Rogers. Diffusion of Innovations. Free Press, New York, 5 edition, 2003.

[Roß06]

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

[SNS88]

J.G. Steiner, B.C. Neuman, and J.I. Schiller. Kerberos: An Authentication Service for Open Network Systems. Usenix Conference Proceedings, 1988.

[SV99]

Carl Shapiro and Hal R. Varian. Information Rules - A Strategic Guide to the Network Economy. Harvard Business School Press, Boston, 1999.

[ZFR+ 07]

Jan Zibuschka, Lothar Fritsch, Mike Radmacher, Tobias Scherner, and Kai Rannenberg. Enabling Privacy of Real-Life LBS. In New Approaches for Security, Privacy and Trust in Complex Environments, pages 325–336. 2007.

Quantitative Model-Based Safety Analysis: A Case Study Matthias Güdemann∗, Frank Ortmeier [email protected], [email protected] Abstract: The rising complexity of many safety-critical systems necessitates new analysis methods. Model-based safety analysis approaches aim at finding critical failure combinations by analysis of models of the whole system (i.e. software, hardware, and failure modes). The big advantage of these methods compared to traditional approaches is that the results are of very high significance. Until now, model-based approaches have only to a limited extent been applied to answer quantitative questions in safety analysis. Model-based approaches in this context are often limited to analysis of specific failure propagation models. They do not include system dynamics and behavior. A consequence is, that the methods are very error-prone because of wrong assumptions. New achievements in the domain of (probabilistic) model-checking now allow for overcoming this problem. This paper illustrates how such an approach for quantitative model-based safety analysis is used to model and analyze a real-world case study from the railway domain.

1 Introduction Due to the rising complexity and basically ubiquitous application, more and more software intensive systems become safety-critical. The amount of software in such systems is increasing at the same time, posing an additional challenge to build these dependable and fault-tolerant. In order to prevent as many accidents as possible, a lot of effort is being put into safety in many domains. Requirements for the development and life cycle of safety-critical systems are now specified in many different norms like the general IEC 61508 [Lad08], DO178B [RTC92] for aviation or ISO 26262 [ISO09] for automotive. In addition to requirements, they present guidelines to make systems more fault-tolerant. All these norms require some sort of safety assessment before a system is put into operation. Many of these methods have a long history (some dating back to the 60ies). However, they are more or less only methodologies and purely rely on skill and expertise of the safety engineer. A potential source of safety-critical problems can only be anticipated if an engineer thinks of it a design time. But this foreseeing becomes ever harder, because of rising hardware and software complexity. ∗ Acknowledgement: Matthias G¨ udemann is funded by the German Ministry of Education and Science (BMBF) within the ViERforES project (no. 01IM08003C)

38

Quantitative Model-Based Safety Analysis: A Case Study

To counter these problems, new model-based safety analysis methods get applied. This means that a model of the system under consideration as well as its environment is built. Then the analysis is not solely based on the engineer’s skill but also on the formal analysis of this model. Some examples of such methods are explained in [ABB+ 06, ORS06, ADS+ 04, BV03]. In some cases it is even possible to semi-automatically deduce causeconsequence relationships between component failures and loss of system. These are mostly qualitative methods, which can only show fault tolerance by giving critical combinations of failure modes. But for the assessment of the dependability the most important question is: “What is/are the probabilities of any of the systems hazards?” For a satisfying answer, accurate quantitative safety analysis methods must be applied. In this paper we show the application of a new, quantitative model-based safety analysis technique – probabilistic deductive cause-consequence analysis [GO10] – to a real-world case study and report on our experiences. The paper starts with a short presentation of the case study (Sect. 2). Sect. 3 explains the formal modeling and analysis of the case study and observations made from a comparison to a traditional safety analysis, Sect. 4 discusses some related work and Sect. 5 concludes the paper.

2 Case Study The following case study of a radio-based railroad control was used as a reference case study used in the priority research program 1064 “Integrating software specifications techniques for engineering applications” of the German Research foundation (DFG), it was supplied by the German railway organization, Deutsche Bahn. The scenario addresses a novel technique for controlling railroad crossings. This technique aims at medium speed routes, i.e. routes with maximum speed of 160 km/h. An overview is given in [KT02]. radio communication

central office route profile

defects

Figure 1: Radio-based railroad crossing

The main difference between this technology and the traditional control of railroad crossings is that signals and sensors on the route are replaced by radio communication and software computations in the train and railroad crossing. This offers cheaper and more flexible solutions, but also shifts safety critical functionality from hardware to software. Instead of detecting an approaching train by a fixed sensor on the track, the train continuously computes the position where it has to send a signal to secure the level crossing. To calculate this activation point the train uses data about its position, maximum deceleration and the position of the crossing. Therefore the train has to know the position of


39

the railroad crossing, the time needed to secure the railroad crossing, and its current speed and position. The first two items are memorized in a data store and the last two items are measured by an odometer. For safety reasons a safety margin is added to the activation distance. This allows compensating some deviations in the odometer. The system works as follows: The train continuously computes its position. When it approaches a crossing, it broadcasts a ‘secure’-request to the crossing. When the railroad crossing receives the command ‘secure’, it switches on the traffic lights, first the ‘yellow’ light, then the ‘red’ light, and finally closes the barriers. When they are closed, the railroad crossing is ‘secured’ for a certain period of time. The ‘stop’ signal on the train route, indicating an insecure crossing, is also substituted by computation and communication. Shortly before the train reaches the ‘latest braking point’ (latest point, where it is possible for the train to stop in front of the crossing), it requests the status of the railroad crossing. When the crossing is secured, it responds with a ‘release’ signal which indicates, that the train may pass the crossing. Otherwise the train has to brake and stop before the crossing. Behind the crossing, a sensor detects that the train has passed and an ‘open’ signal is sent to the crossing. The railroad crossing periodically performs self-diagnosis and automatically informs the central office about defects and problems. The central office is responsible for repair and provides route descriptions for trains.

3 Model-Based Safety Analysis Our model-based safety analysis consists of building a formal system model which can then be analyzed using formal analysis techniques based on temporal logics and model checking. The accuracy of the formal system model is the most important factor in the accuracy of the whole analysis, especially the modeling of the probabilistic behavior.

3.1 Building a formal model For model-based safety analysis it is necessary to model (a) the controlling software, (b) the controlled hardware, (c) the environment and (d) possible failure modes. We can not show the full case study here, but only show one part of it. Fig. 2 shows a model of the crossing in state charts notation1. Initially the barriers (of the crossing) are opened. When the crossing receives a close request from an arriving train - i.e. condition Close becomes true, the barriers start closing. This process takes some time. After a certain amount of time the barriers are closed. They will remain closed until the train has passed the crossing (detected by a sensor). The barriers reopen automatically after a defined time interval. This is a standard procedure in railroad organization, as car drivers tend to ignore closed barriers at a railroad crossing if 1 In this paper, we use a basic (but very precise) semantics for state charts. Basically no queues are allowed, events do not persist and parallel composition is synchronous. This semantics is very intuitive on the one hand and very easy to translate into model checker input languages on the other hand.

40


Close

TimerClosing = 0

Closed

Closing

Opened

Crossing

Open OR TimerClosed = 0

Figure 2: Model of the crossing

the barriers are closed too long. So it is better to reopen the barriers, than having car drivers slowly driving around the closed barriers. Analogously the other parts of the system (i.e. the train, radio communication, brakes, cars, control software) are modeled. Together this forms a functional model of the system. This means it is a model of the system in an ideal world, where no errors occur. The safety goal of the system is clear: it must never happen that the train is on the crossing and a car is passing the crossing at the same time. A well designed control system must assure this property at least as long as no component failures occur. The corresponding hazard H is “a train passes the crossing and the crossing is not secured”. This is the only hazard which we will consider in this paper.

3.2 Modeling failure modes The next step is to extend this model such that failures are also correctly described. In this paper we do not address the question which failure modes are necessary to model2 , we assume, that this has already been determined. For the example the following six failure modes are considered: failure of the brakes (error brake) which describes the failure of the brakes, failure of the communication (error comm) which describes the failure of the radio communication, failure of the barriers closed sensor (error closed) which describes that the crossing signals closed, although it is not closed, failure of the barriers’ actuator (error actuator) which describes that the actuator of the crossing fails, failure of the train passed sensor (error passed) which describes that the sensor detecting trains which passed the crossing fails and deviation in the odometer (error odo) which describes that the odometer does not give 100% precise data. These failure modes are integrated into the formal model. Modeling of failures can always be split into two (sub-)tasks: modeling of the occurrence pattern and modeling of the direct effect of the failure mode. Occurrence patterns describe how and when a given failure mode may occur and are modeled by failure charts. The most basic failure chart has two states, one state yes modeling the presence of the failure and one state no modeling its absence. The transitions between these states determine 2 There are numerous other techniques for answering this question. They range from experienced based approaches like component specific list of failure modes to formally grounded methods like failure-sensitive specification [OR04].


41

the type of failure mode. For example: if the state yes can never be left once it became active, the failure mode is called persistent. If the state may non-deterministically switch between yes and no, it is called transient. More complex occurrence patterns (e.g. broken until repair) are also possible. Which occurrence pattern is best fitting for a given failure mode is a design/analysis decision. Modeling of the direct effects of the failures of a failure mode basically comes down to adding transitions and/or states to the functional model, which are activated or in the case of additional states, reachable, if the failure occurs (resp. if the corresponding failure automaton is in state “yes”). Correct modeling of failures is a difficult and error-prone task. From a formal point of view the semantics of the original model (without failure modes) and the extended model have little to do with each other. From an intuitive point of view, one would expect some sort of trace-inclusion, i.e. the original behavior of the functional system must still be possible in the extended system model. This property can be assured, if some syntactic rules are followed during modeling of failure modes’ direct effects [OGR07]. Fig. 3(b) shows the modeling of the failure effect of the failure modes error comm and error passed for the crossing, Fig. 3(a) shows the transient failure automaton for error comm. If it is active then state Opened will not be left although a Close signal was sent, i.e. the communication failed. The failure effect of error passed is modeled such that state Closed may be left if the corresponding failure automaton is in state yes, i.e. a misdetection of the sensor happened.

no

(a) Failure Automaton

TimerClosing = 0 Close AND ErrrorComm = no

Closed

Closing

yes

Opened

Error_Comm

Crossing

Open OR TimerClosed = 0 OR ! ErrrorPassed = no

(b) Failure Effects Modeling

Figure 3: Modeling of error comm failure mode

3.3 Modeling for Quantitative Safety Analysis For an accurate quantitative model-based analysis, probabilistic information must be added to the extended system model. Accurate modeling of the occurrence pattern and the occurrence probability of failure modes is very important. There exist two main types of failure probabilities. The first is per demand failure probability, which is the probability of the system component failing its function at a given demand (comparable to low demand mode in IEC 61508). The second is per time probability, which is the rate of failures over a given time interval (comparable to high demand or continuous mode in IEC 61508). Which type of failure probability is best fitting for a given failure mode can only be decided on a case-by-case basis. Transient sensor failures will very often be modeled as a

42


per time failure mode, as they are active the whole time. Other failure modes, like the activation of a mechanical device, will often be modeled as a per demand failure, as a clear moment of activation exists. Per demand failures often are of persistent nature3 . 3.3.1 Discrete Time Model The underlying semantics of the formal model is a discrete time model in which the temporal behavior of the failure modes and system model must be integrated. For each time step the system performs, an equal amount of time δt passes, which is called the temporal resolution. For the example case study, the formal model consists of 10km of railroad tracks. The average speed is 115 km h . The formal system model in built in a way that this translates to a temporal resolution of δt = 5s, i.e. for every system time step, 5s pass. 3.3.2 Modeling per time failure modes Transitions of the failure automata are labeled with constraints of the form (p : φ) which translates to: “If φ holds, then the transition is taken with probability p”. This can be abbreviated by omitting p which then results in probability 1. In order to be a well defined probabilistic model, for each transition label, the outgoing transition probabilities must always sum up to 1. This assures that a valid probability measure is defined. A per time failure mode can be modeled by adding the failure probability to the transition from state no to state yes as shown in Fig. 4(a). Making its potentially non-deterministic behavior probabilistic. The activation condition is always true and the sum of probabilities of outgoing transitions is always 1. In the case shown, the failure automaton enters state yes with a probability p, stays in this state with the same probability and enters (and stays in) state no with probability 1 − p. The parameter for a per-time failure is normally given as a failure rate λ and interpreted as the parameter for the exponential distribution function (Eq. 1) which computes the probability that a failure occurs before time t. This continuous function can be approximated in discrete time using a per-time failure automaton as shown in Fig. 4(a). This leads to a geometric distribution function (Eq. 2) which computes the probability that a per-time failure appears in at most k time-steps. Setting time t = k · δt, gives a good discrete time approximation of the exponential distribution [GO10]. + t P (X ≤ t) = e−λt dt (1) P (X ≤ k) = 1 − (1 − p)k (2) 0

With the given δt, the failure rates for the per-time failures can be converted to transition probabilities for per-time failure automata. Modeling the error passed as per time failure mode with a failure rate of 7e−9 1s and the failure of the odometer with a failure rate of 6e−5 1s , the transition failure probabilities are 3.5e−8 for error passed and 3e−4 for error odo. The deviation of the odometer is then modeled by choosing a deviation from the set {−3, −2, −1, 0, 1, 2, 3}. The probability of the deviation is modeled to be normally m distributed with µ = 0 m s and σ = 1 s . 3 But there exist of course other failure modes, which are transient and should be modeled as per demand probabilities resp. persistent failure modes, which should be modeled with per time failure rates.


Per Demand Failure

Per Time Failure

(p : demand)

no

(1−p : true)

yes

yes

no (p : demand)

(p : true)

(a) Per-time

not demand OR (1−p : demand)

not demand OR (1−p : demand)

(1−p : true) (p : true)

43

(b) Per-demand

Figure 4: Failure Automata for quantitative failure mode modeling

3.3.3 Modeling per-demand failure modes Correct modeling of a per demand failure mode is more complex. The challenge is to specify a correct occurrence pattern such that assures that the failure mode can only appear if a demand to the component is given and is then taken only with the given failure probability. To accomplish this, the failure probability is first added to the transitions to state yes and the state no may only be left if there is a demand to the component. In other words, a predicate demand is a necessary condition for the occurrence of the failure mode. A failure automaton for a per demand failure mode is shown in Fig. 4(b). The failure mode error comm is integrated in this way. In this case, there is a demand if the crossing is in state Opened and the Close signal is sent. If error comm is not present, then the crossing enters state Closing, if the failure mode is present or no Close signal is sent, the state Opened is not left. When demand holds ((Crossing = Opened) ∧ Close), the failure automaton can change to state yes with probability p or stay in state no with probability 1 − p. This means that in the next time step, it is possible that the crossing is either in Opened or Closing. To model this correctly, the state Undecided is introduced which represent either of these states. In addition a decide automaton as shown in Fig. 5(b) is added, which changes from state undef to [Opn, Clg] if demand holds. Based on these two automata the predicates in(Opened) and in(Closing) are defined as shown in equation (3) and (4) which indicate the “real” state of the crossing, Crossing’ refers to the model of the crossing with per-demand failure mode modeling. in(Opened) := Crossing . = Opened ∨ (Crossing . = undecided ∧decide = [Opn, Clg] ∧ ¬f ailure = no) in(Closing) := Crossing . = Opened ∨ (Crossing . = undecided ∧decide = [Opn, Clg] ∧ f ailure = no)

(3) (4)

As Undecided represents either state Opened or Closing, depending on the state of the failure automaton, the transitions of these states must be added to the state Undecided , in conjunction with the the above predicates. • For the state Opened

44

Quantitative Model-Based Safety Analysis: A Case Study – to state Opened, activation condition ¬Close ∧ in(Opened), i.e. in state Opened and there is no demand – to state Undecided, activation condition Close ∧ in(Opened), i.e. there is a demand that possibly fails • For the state Closing the following transitions must be added to Undecided: – to state Closing, activation condition ¬T imer = 0 ∧ in(Closing) – to state Closed, activation condition T imer = 0 ∧ in(Closing)

The complete modeling of the per demand failure effect for error passed is shown in Fig. 5(a). The decide automaton, Crossing and the per-demand failure automaton together show the same observable behavior as the qualitative failure modeling. It becomes clear why such a complex construction is necessary: the state Opened has successor states if there is a demand and successors states if there is no demand. Therefore only being in state Opened is not sufficient to specify the demand predicate, because the failure automaton could then make a transition at the wrong time, resulting in wrong overall probabilities, especially important for persistent failures which cannot disappear after their occurrence. We give an example trace that shows the relevant predicates and states of the automata to illustrate that the resulting traces of the probabilistically modeled system are the same as for the system for qualitative analysis, if the per demand failure modes are correctly integrated as described. The first trace shows the behavior of the extended system model Crossing’

Undecided

Closed TimerClosing = 0 AND in(Closing)

(a) Failure Effects Modeling (Crossing’)

Decide demand undef

[Opn, Clg]

demand

not TimerClosing = 0 AND in(Closing)

Closing

not demand

not Close AND in(Opened)

TimerClosing = 0

Close AND in(Opened)

Opened

Open OR TimerClosed = 0 OR not ErrrorPassed = no

Close

not demand

(b) Decide Automaton

Figure 5: Modeling of per-demand failure mode error com

without explicit modeling of the per demand failure mode. The failure appears after the first time step, but has no effect there because there no Close command was sent. At the third time step, the failure appears again, now it has an effect (Close command was sent) causing the crossing to stay in state Opened. Afterwards the failure disappears, Close is sent again and the crossing enters state Closing. The following trace is the corresponding trace of the extended system model with probabilistic modeling of the per demand failure. Here the failure can only appear at the fourth time step, as there was no demand before. This causes the decide automaton to enter the state [Opn,Clg] and the crossing to enter

Quantitative Model-Based Safety Analysis: A Case Study time-step error comm Crossing Close

1 no Opened f alse

2 yes Opened f alse

3 yes Opened true

4 no Opened true

45

5 no Closing f alse

state Undecided. The failure is active at the fourth time step, therefore in(Opened) holds and the “real” state of the crossing is Opened. At the fifth time step, the Close command is sent again, this time the failure disappears and in(Closing) holds. Both traces show the time-step error comm Crossing’ decide in(Opened) in(Closing) Close

1 no Opened undef true f alse f alse

2 no Opened undef true f alse f alse

3 no Opened undef true f alse true

4 yes Undecided [Opn,Clg] true f alse true

5 no Undecided [Opn,Clg] f alse true f alse

same observable behavior, i.e. the states of the crossing and therefore the failure effects are the same in both cases. Nevertheless it can easily be seen that the failure mode can only appear at the time of a demand, whereas in the modeling without per demand failures the failure can appear at any time, but its effect manifests only at certain time steps (the demands in the probabilistic modeling). This illustrates again that in order to compute accurate probabilities, this distinction is necessary although the correct integration in not trivial. A much more detailed discussion about the integration of both per-demand and per-time failure modes can be found in [GO10].

3.4 Analysis Results The constructed probabilistic model was analyzed using the PRISM model checker using hybrid models (sparse matrices and MTBDDs) on an Athlon 64 X2 4800+ CPU with 2 Gbyte of RAM. The overall model consisted of 11295021 reachable states and 518674960 transitions resulting from the parallel composition of the state machines of the model description. The duration of the analysis was approx. 190 minutes and 279.7 MByte of RAM were allocated. The hazard H was defined as “the position of the train is on the crossing and the crossing is not in state closed”. Equation (5) shows the result of the quantitative analysis. The probabilistic temporal logic formula is explained in [GO10]. P (H) = 4.47363 · 10−6

(5)

Compared to a more traditional analysis method based on the a-posteriori estimation of the hazard probability on the resulting critical combinations of failures (for details see [ORS05]), this result is much more accurate. The following equation shows the result using the standard approach for quantitative fault tree analysis (FTA) [VDF+ 02] as

46


shown in formula (6). PF T A (H)

K =

≤

P (δ)

(6)

Δ∈mcs δ∈Δ

PF T A (H) PF T A (H)

≤ P (error passed) + P (error odo) + P (cut sets of size ≥ 2) ≤ 2.8 · 10−6 + 2.5 · 10−2 + O(1 · 10−14 ) ≈ 2.5 · 10−2 (7)

For this calculations, the probabilities for error passed and error odo must be estimated for one train passing the crossing. In the example, it was assumed that the train needs roughly4 400s. These coarse results (Eq. (7)) could then be refined with constraint probabilities. For example, one could deduce that only deviations of at least 2 m s are dangerous. This would then lower the probability for error odo by the order of 2. It is still rather obvious that this estimation is very coarse compared to quantitative model based analysis. Another drawback of the traditional approach is that if the system is not carefully analyzed for temporal behavior, the estimation can easily be too optimistic. Just try to decide if a deviation of 3 m s could also be justified or not. The biggest advantage of the model-based quantitative analysis is that the stochastic dependencies5 which often are inherent in such a system are automatically considered in the system model, whereas all a-posteriori methods depend on the stochastic independence which is often not satisfied.

4 Related Work Some related model-based analysis methods like [BV03, ABB+ 06, ADS+ 04] have already been mentioned. Together with basic fault tree analysis [VDF+ 02] they have the disadvantage that the results of a qualitative analysis are used for quantitative estimations. As already discussed, these estimations rely on the assumption of stochastic independence, which is often not fulfilled. Notable approaches for doing quantitative safety analysis directly on a formal system model is presented in [BPRW08]. In this work, critical combinations of failures, analogously to the minimal cut sets of FTA or minimal critical sets of DCCA are analyzed for their relative impact. They are sorted according to their contribution to the overall hazard probability. The difference is that the analyzed system behavior is limited to allow only failure modes in such a set. This alters the set of possible traces of the system models and the probabilities in such a way that no overall hazard probability can be computed. Very interesting approaches are developed in the COMPASS [BCK+ 09a] project with its SLIM modeling language [BCK+ 09b] and in [GCW07]. Both approaches are similar to ours in analyzing whole system models. The difference is, that solely continuous time models are used. This is well suited to asynchronous interleaved systems but not to syn4 Derived

from the formal model of the railroad crossing. for example that the faster the train, the more likely is the situation that the sensor is passed without sensor failure. A slower train speed translates to a higher probability of a error passed failure mode, as the more time passes the more the probability shrinks that the failure does not occur. 5 Consider


47

chronous parallel systems [HKMKS00]. This also means that per-demand failure modes are not supported, as these are not directly expressible in the continuous time semantics.

5 Conclusion The quantitative model-based safety analysis method presented in [GO10] was applied to a real world case study of a radio-based railroad crossing. The modeling included both per-time and per-demand failure modes and normally distributed deviations of a sensor. The limiting factor of the analysis method is the size of the state space (which is larger for probabilistic analyses than for qualitative analyses) and the running time of the modelchecking. But as we have shown, a realistic case study is analyzable in that way and probabilistic model-checking is an active research area. Different abstractions to reduce the state space have been proposed, multi-terminal BDDs [KNP02] are already in use in PRISM, bisimulation- based abstractions are integrated in MRMC [KKZJ07] and the necessary numerical analysis can be moved to massive parallel GPU computation [BES09]. The analysis results are very promising, as all the stochastic dependencies are automatically reflected in the analysis, resulting from the analysis using probabilistic modelchecking techniques. The different types of failure modes can be integrated into the model and although the system is modeled in a discrete time context, accurate continuous time approximation is possible. Future work will include developing a modeling framework for the combined usage of qualitative safety analysis, to compute the critical combinations and quantitative safety analysis to compute the overall hazard probabilities.

References [ABB+ 06]

O. Akerlund, P. Bieber, E. Boede, M. Bozzano, M. Bretschneider, C. Castel, A. Cavallo, M. Cifaldi, J. Gauthier, A. Griffault, O. Lisagor, A. Luedtke, S. Metge, C. Papadopoulos, T. Peikenkamp, L. Sagaspe, C. Seguin, H. Trivedi, and L. Valacca. ISAAC, a framework for integrated safety analysis of functional, geometrical and human aspects. In Proceedings of ERTS 2006, 2006.

[ADS+ 04]

Parosh Aziz Abdulla, Johann Deneux, Gunnar Stalmarck, Herman Agren, and Ove Akerlund. Designing Safe, Reliable Systems using SCADE. In Proceedings of ISOLA’04. Springer-Verlag, 2004.

[BCK+ 09a]

Marco Bozzano, Alessandro Cimatti, Joost-Pieter Katoen, Viet Yen Nguyen, Thomas Noll, and Marco Roveri. COMPASS project webpage. http://compass.informatik.rwth-aachen.de/, 2009.

[BCK+ 09b] Marco Bozzano, Alessandro Cimatti, Joost-Pieter Katoen, Viet Yen Nguyen, Thomas Noll, and Marco Roveri. Model-Based Codesign of Critical Embedded Systems. In 2nd International Workshop on Model Based Architecting and Construction of Embedded Systems, pages 87–91. CEUR-WS.org, 2009. [BES09]

D. Bosnacki, S. Edelkamp, and D. Sulewski. Efficient Probabilistic Model Checking on General Purpose Graphics Processors. In C. Pasareanu, editor, Proc. 16th International SPIN Workshop, volume 5578 of LNCS, pages 32–49. Springer, 2009.

48


[BPRW08]

Eckard Böde, Thomas Peikenkamp, Jan Rakow, and Samuel Wischmeyer. Model Based Importance Analysis for Minimal Cut Sets. Reports of SFB/TR 14 AVACS 29, SFB/TR 14 AVACS, Apr 2008. ISSN: 1860-9821, http://www.avacs.org.

[BV03]

M. Bozzano and Adolfo Villafiorita. Improving System Reliability via Model Checking: theFSAP/NuSMV-SA Safety Analysis Platform. In Proceedings of SAFECOMP’03, pages 49–62. Springer, 2003.

[GCW07]

L. Grunske, R. Colvin, and K. Winter. Probabilistic Model-Checking Support for FMEA. In Proc. 4th International Conference on Quantitative Evaluation of Systems (QEST’07), 2007.

[GO10]

Matthias Güdemann and Frank Ortmeier. Probabilistic Model-based Safety Analysis. In Proceedings of the 8th Workshop on Quantitative Aspects of Programming Languages (QAPL10). EPTCS, 2010.

[HKMKS00] Holger Hermanns, Joost-Pieter Katoen, Joachim Meyer-Kayser, and Markus Siegle. A Markov Chain Model Checker. In TACAS ’00: Proceedings of the 6th International Conference on Tools and Algorithms for Construction and Analysis of Systems, pages 347–362, London, UK, 2000. Springer-Verlag. [ISO09]

ISO/WD 26262: Road Vehicles-Functional Safety, 2009.

[KKZJ07]

Joost-Pieter Katoen, Tim Kemna, Ivan S. Zapreev, and David N. Jansen. Bisimulation Minimisation Mostly Speeds Up Probabilistic Model Checking. In TACAS, pages 87– 101, 2007.

[KNP02]

M. Z. Kwiatkowska, G. Norman, and D. Parker. Probabilistic Symbolic Model Checking with PRISM: A Hybrid Approach. In TACAS ’02: Proceedings of the 8th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, pages 52–66, London, UK, 2002. Springer-Verlag.

[KT02]

J. Klose and A. Thums. The STATEMATE Reference Model of the Reference Case Study ‘Verkehrsleittechnik’. Technical Report 2002-01, Universität Augsburg, 2002.

[Lad08]

Peter B. Ladkin. An Overview of IEC 61508 on EEPE Functional Safety, 2008.

[OGR07]

Frank Ortmeier, Matthias Güdemann, and Wolfgang Reif. Formal Failure Models. In First IFAC Workshop on Dependable Control of Discrete Systems (DCDS 07). Elsevier, 2007.

[OR04]

F. Ortmeier and W. Reif. Failure-Sensitive Specification: A Formal Method for Finding Failure Modes. Technical Report 3, Institut für Informatik, Universität Augsburg, 2004.

[ORS05]

F. Ortmeier, W. Reif, and G. Schellhorn. Formal safety analysis of a radio-based railroad crossing using Deductive Cause-Consequence Analysis (DCCA). In Proceedings of 5th European Dependable Computing Conference EDCC, volume 3463 of LNCS. Springer, 2005.

[ORS06]

F. Ortmeier, W. Reif, and G. Schellhorn. Deductive Cause-Consequence Analysis (DCCA). In Proceedings of IFAC World Congress. Elsevier, 2006.

[RTC92]

RTCA. DO-178B: Software Considerations in Airborne Systems and Equipment Certification, December, 1st 1992.

[VDF+ 02]

Dr. W. Vesley, Dr. Joanne Dugan, J. Fragole, J. Minarik II, and J. Railsback. Fault Tree Handbook with Aerospace Applications. NASA Office of Safety and Mission Assurance, August 2002.

Real-Time Fault-Tolerant Routing in High-Availability Multicast-Aware Video Networks Roman Messmer ORF Austrian Broadcasting Corporation Broadcast Production Systems A-1136 Vienna, Austria [email protected]

Jörg Keller FernUniversität in Hagen Dept. of Mathematics and Computer Science 58084 Hagen, Germany [email protected]

Abstract: Live-videostream networks based on multimedia switches are the most recent products used in television production and distribution facilities to transport the live signal from sources like cameras or microphones to dedicated sinks like video monitors, loudspeakers and transmission lines. To switch signals from a single source to several destinations multicasting or point-to-multipoint technology is considered. To compute multicast trees for multimedia communication, constrained shortest paths algorithms are needed. They are fundamental to important network functionality such as Quality of Service (QoS) routing or Multiprotocol label switching (MPLS) path selection and the problems they attempt to solve are known to be NP-complete. In previous work, we have introduced a heuristic called Multimedia Multicast algorithm (MulMic), which delivers nearly optimal multicast trees in a short time. Here, we propose the combination of MulMic and two models for fault-tolerant routing: disjoint paths and reservation of backup paths. Furthermore we introduce a realtime algorithm we call ZirkumFlex to handle one or even several simultaneous node or line failures in a multicast network by a local search to bypass the failed node or line. We also apply our algorithm to example graphs to demonstrate its feasibility.

1 Introduction Implementing distributed media applications like high-resolution video routing on switched packet networks faces several obstacles. The most difficult but essential problem concerns ensuring quality of service (QoS). One precondition is knowing the constrained shortest path, i.e. the cheapest path that satisfies a number of constraints, especially the number of routing hops. Depending on the hardware each single hop adds up several microseconds to the total delay time of the signal path and leads to problems in terms of signal synchronization or even causes frame delayed videos which have to be processed together in follow-up working steps in the video and audio domain. The scale of the problem is better understood when the hop time of a switch is compared with the duration of a video line at the usual high definition video format 720p/60 which lasts about 23 microseconds. Most devices can cope with a time window of several lines without having to synchronize the input signal to an external clock and increase the total transfer time of the video signal additionally. Depending on the video product a delay of up to 200 microseconds is acceptable which makes the minimization of hops an important factor. In most cases one

50

Realtime Fault-Tolerant Routing in Video Networks

source has to distribute a signal to a multitude of destinations, e.g. a video signal from a camera is transported to studio monitors and live video mixers at the same time. Thus, we have a multicast or point-to-multipoint routing problem with constraints. We will use the two terms interchangeably. In previous work, we have proposed an algorithm for this problem called MulMic that combines preprocessing with very fast path calculation upon connection requests [MK09]. The failure of nodes in switched packet networks often leads to unacceptable delays or total failure of running processes. Therefore, we investigate fault-tolerance measures in this scenario. We present three algorithms to tolerate node or link failures: (1) by allocating with every multicast tree a backup multicast tree on disjoint paths, (2) by reserving shareable backup trees and (3) introduce an online algorithm that on occurrence of a failure performs a graph search from surrounding graph nodes to bypass the failed node as quickly as possible. To the best of our knowledge all previous work that investigates fault tolerance without extensive a priori resource consumption refer to point-to-point routing only. Of most interest in our paper is the avoidance of perceptible interruptions of the affected media signals with as little overhead as possible. This is what we mean by “real-time” in our scenario. The remainder of this article is organized as follows. In Section 2 we discuss related work. In Section 3 we briefly review the MulMic algorithm. In Section 4 we present the various fault-tolerance algorithms, and in Section 5 we apply our algorithm to example graphs. We conclude in Section 6.

2 Related Work In multicast-aware IT networks the fault tolerance aspect differs slightly from high speed media networks in terms of the importance of continuity of streams. Video streams may not be interrupted, frozen displays are very unwanted events. In [UZ06] a heuristic called Adaptive distributed Concurrent Shortest Path heuristic is presented which generates delayaware constrained multicast trees. After removing the failed subtree the source node is informed about the former covered subtree and its destinations. Then a new loop-free subtree from (subtree-)source to destination nodes is established. This procedure delivers a nearly optimal routed multicast tree, but its calculation is very time-consuming. A very effective distributed algorithm was introduced in [Gu03], where parts of the network were analyzed for backup routes which could be used in case of a node failure. This approach extends the resource reservation protocol (RSVP, RFC2208) to improve resource utilization, higher call acceptance rate and better quality of service (QoS). The level of fault tolerance of each connection can be controlled separately. Earlier works as [Gr89], [Ch93a] and [Ch93b] used distributed algorithms to restore point-to-point connections after network failures. Their work does not mention point-to-multipoint connections. [ZS92] presented algorithms for realtime communication together with fault tolerance aspects using the multiple paths between a pair of communicating nodes to make more efficient use of the network. While most of the mentioned papers treat link failures, [Ko90] also an-


51

alyzes node failures. Communication for restoration bases on network flooding and path route monitoring. [RM03] analyzed multiple segmented backup scenarios for mission critical applications. In [YH88] failure immunization technology for the use in the fiber optic domain is presented and analyzed.

3 Realtime Routing Algorithm In [MK09] we proposed an algorithm called Multimedia Multicast Algorithm (MulMic) which calculates a multicast tree in O(|V | + |E| + |M | · log |M |) time where V , E and M represent the set of vertices, edges and multicast destination nodes, respectively. Experiments with different graphs demonstrated not only the favorable runtime of the algorithm but also another important property of the calculated routing. The result of a rerouting after eliminating a failed node is in many cases very similar to the original routing. So there are only few routing commands necessary to restore a multicast path. In Fig. 1 this property is illustrated. A 10 × 10 grid network1 was set up with 14 multicast destination nodes in different portions of the graph. Some are far apart, e.g. (10) or (36), and some form groups, such as (77, 78, 87, 88). Then a MulMic run was started with source node (55). The resulting routing to node (10) starts at (55), leading upwards to (5) and to the right to (10). For destination (91) the routing starts at (55) leading left to (51) and down to (91). Then a node failure at (7) and a line failure (61-71) were simulated. Failure (7) brought up a rerouting of the path to (10) using (15) to (18), then (8) to (10) to reach its destination. The new routing even leaves the routing from (5) to (6) untouched. A similar case appears with the path from (51) to (91). The new routing results in a path (52) to (72), (71) to (91) which leaves the majority of line routings untouched. Combined with the fault tolerance procedures in Section 4, most of the nodes affected by failure of a node can be supported by a new signal path without noticeable interruption. We now present the algorithm in detail. To achieve the necessary realtime behavior, the proposed algorithm is divided into a time-consuming offline part and a fast online part. The offline part constructs a routing table for each node of the graph beforehand. The local routing table is then computed in parallel at each switch of the network. The data is updated by accessing a common database containing the local network topology information. The switches listen for node-state and line-state information from other links to update the local routing table and bandwidth consumption. After processing a point-to-multipoint connection request, the common database and the local routing information are updated synchronously. The Floyd-Warshall algorithm, an all-pairs shortest path algorithm with complexity O(n3), can be applied to compute the distances and paths between all nodes of the network graph. In our example a cost of 1 is assigned to every link between routing nodes, because the constant major signal delay occurs during the opto-electronic conversion in the switches (several microseconds), not on the fibre-optic line (nanoseconds, less than a microsecond even for long distance links). After finishing the first part every router has knowledge about the network, e.g. the number of nodes and their connections. 1 The

grid topology is used throughout the paper for the sake of simplicity.

52


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

Figure 1: Property of MulMic routing algorithm

The online part starts with a request for a point-to-multipoint path calculation. Let G = (V, E) be the graph representation of the network, V the set of all nodes, E the set of all edges, M = {v1 , . . . , vm } the set of destination nodes, and s the source node. The online part of the algorithm proceeds as follows: 1. Retrieve all distances d(s, v1 ), . . . , d(s, vm ), i.e. the distances of all destinations from the source, from the routing table, together with the corresponding paths. and sort the distance values in ascending order. From now on we will assume v1 , . . . , vm to represent this order, i.e. v1 has the shortest distance from s, and vm has the largest distance from s. 2. Start the Multipoint path M P AT H with M P AT H = path(s, vm ). Let i be a loop index counting down from m = |M | to 2, to add node vi−1 to the multicast tree. (a) If dist(vi , vi−1 ) < dist(vi−1 , s) then add path(vi , vi−1 ) to M P AT H else add path(s, vi−1 ) to M P AT H. Information about the path length between vi to vi−1 is retrieved from the local routing table. (b) (optional) If other destination nodes vj , where j < i − 1, are already covered by the existing path, they are no longer considered for future calculation. (c) A variable which calculates the number of hops is increased when the if-case has been taken, i.e. if the shortest path to the next destination is shorter than to the source. The variable is reset to zero otherwise. If the maximum hop count is reached, the next destination node must be connected to the source. So an unacceptable delay time due to the accumulation of hop time is avoided. This way the routing propagation is limited. 3. As there is the possibility of loops in the constructed graph M P AT H, a general spanningtree algorithm realized by a depth-first search is used to eliminate them.

The implementation of this algorithm delivers a single point-to-multipoint routing result in record low time O(|V | + |E| + |M | · log |M |). See [MK09] for a proof.


53

4 Fault-Tolerance Concepts We now present three concepts to add fault tolerance to the routing method we mentioned above. The concepts differ in the amount of additional bandwidth that they allocate in the fault-free case, and the amount of calculation necessary in the presence of a fault.

4.1

Backup path model

This approach tries to establish redundancy by a backup multicast tree with paths disjoint from the multicast tree calculated by the MulMic algorithm, as far as is possible, since the graph is not required to be 2-connected. Its advantage is that in case of a failure, shifting transmission to the backup tree is all that needs to be done. This comes at the cost of doubling the bandwidth consumption. First the primary routing path is to be calculated. The MulMic algorithm from Section 3 is used for realtime calculation of the point-tomultipoint path. The calculated path is transformed into routing commands, which are then sent to the routers along the multicast path. Next the backup routing path is calculated. A graph with modified edge cost is used to calculate disjoint paths between source and destination. Links used in step 2 get a high cost value (e.g. edge cost set to number of total graph edges), so that a shortest-path algorithm calculates paths disjoint from the primary path whenever possible. If there is no disjoint path alternative, the original path must be used to transport the media stream. At least the source router as well as the destination routers are always examples of such non-disjoint paths if they don’t provide multiple network interfaces. The calculated secondary path is then transformed into routing commands and sent to the routers. After positive switch confirmation the bandwidth management (BM) is called to update the database. Next we concern the failure management of the backup path model. Immediately (usually within microseconds) after a router or a link failure the destination nodes detect an error2 , the redundant secondary channel immediately is being activated for resuming the transfer of media over the backup path. The defective lines or nodes of the graph are removed from the routing table (locally and in the remote database) and an all-pairs shortest path algorithm with complexity O(n3) is called again afterwards, i.e. offline, to update the topological information base for the multicast algorithm. To select disjoint paths we recommended to set the link cost of the primary path to a certain high value. This is also used to recalculate a connected primary path. The algorithm presented in section 3 is appropriate because in most cases it leaves the already working routed links in place and only presents backup routings for the defective line or node. 2 Physical

detection via Loss Of Light (LOL) or CRC error.

54 4.2

Realtime Fault-Tolerant Routing in Video Networks Reservation model

Instead of actually establishing backup paths one can also simply reserve such paths by means of Resource ReSerVation Protocol (RSVP) [RS06]. The advantage of this variant is that backup path reservations can be shared between trees that use disjoint links that never will both be affected by a node or link failure. The disadvantage is the overhead to establish the reserved backup path in case of a failure. The network design which uses a number n of backup paths for m signal paths is called n : m p-cycle and has been studied extensively. There are concepts like shared link risk groups (SLRG) [Ru05] which consider a set of links that may fail simultaneously because of a common risk they share on the network. For example, they may all be less prioritized destinations. In [RC08] a dual link failure resiliency is considered in a project called backup link mutual exclusion (BLME). P-Cycle in multidomain networks are surveyed in [Dr09].

4.3

Online failure management model

This proposal does not assume any additional reserved or switched redundancy path. Instead it assumes that there is additional bandwidth available in the network that can be used for a failure-triggered routing. The basic idea of this model which we will call ZirkumFlex is a combination of the MulMic routing algorithm together with a rapid calculation of a path alternative in case of a node or link failure. The alternative path changes only those routes directly affected by the failure. In Fig. 2 there is an example for the ZirkumFlex algorithm operating in a common graph. The upper image shows a part of the network graph, the lower the multicast tree only. The node s represents the source node, routing starts from there. Destination nodes d1 , . . . , d6 are in dark gray. The figure shows the moment when a failure occurs at the node with the flash symbol. Because the multicast tree is loop-free per definition there is only one single predecessor of any node in the tree. We begin at the already established multicast path. An additional feature of the MulMic algorithm sets the variable for the distance from the source node d in each node without extra cost in a depth-first search. Every node holds its number/name, distance d, the multicast call number (to distinguish between several multicast routings per node) and finally a linked list with its source name/number initially filled in plus a rendezvous field containing encountered successor names. A node list holds node names not yet connected to the predecessor. After a failure has been detected the predecessor and the successors of the failed node(s) is/are determined. A following test of the predecessor (pre) node being a member of a unicast or multicast routing determines if rerouting activity is to be set. If the pre node is not a member, only the central database is to be informed about the failure and no other action is taken. Else if the local node indeed is a member, start the ZirkumFlex-algorithm detailed in Fig. 4. To achieve link and path restoration on large graphs in short time and avoiding the O(n3 ) all pairs shortest path algorithm over the whole graph we propose

Realtime Fault-Tolerant Routing in Video Networks d1

II

II

d6

II II

I

succ1

I

succ2

I

d2

II

I

II s

II

55

I

pre

II

I

I

II

I

II

II

d3

succ3

I

II

I

d4

II

d5

d1

d2

succ1

d6

pre

s

d3

succ2

succ3 d4 d5

Figure 2: Heuristics example: standard graph and multicast-path

ZircumFlex path

Old routing untouched

src

1

5

Discard old routing 4>5 Original path

2 Displayed node index represent distance to source node src

3

4 Old routing untouched

6

Set new Routing 5>4

5 destinations

Figure 3: Online Failure Graph

using local graph breadth first searches (BFS) running only on the predecessor node of the failed node/link. As long as there are unreached successors do the following: • do a simple BFS-run (only direct neighbors) and mark the linked list of the reached

56

Realtime Fault-Tolerant Routing in Video Networks nodes with the path to the origin, i.e. the first detected node gets the predecessor or successor node name in its linked list, respectively. In the next run there are two entries in the list and so on. • if a previously predecessor-BFS-marked node is reached, the path from the predecessor to the affected successor is taken into an emerging regional graph3 . Then the successor node is marked as reached. Running BFSs of known successor nodes are terminated, their corresponding node names are taken out of the node list. Already visited nodes/edges are then excluded from further BFS-runs. • if another successor-BFS-marked node is reached the path between both successors is taken into the regional graph again. Already visited nodes/edges are again excluded from further BFS-runs.

This procedure puts up a local subgraph of the network graph (regional graph) and delivers a spanning tree containing shortest paths between successors and predecessor within the regional graph in a few microseconds, therefore we speak of real-time property. Our preliminary tests indicate that only a few BFS steps are necessary in general graphs. ZirkumFlex allows to eliminate links of pathological (after a failure no longer signalsupported) nodes by iteratively starting at predecessor and successor nodes and eliminating the connected edges as long as the outdeg of the referring nodes equals one4 or until a multicast-destination is reached. A following DFS-run within the regional graph starting at the pre node sets the correct routing direction in the regional graph. In some network layouts there appears the effect of the signal path having to be routed forward and backward for a minor number of hops, which consumes unnecessary bandwidth to support nodes which lie closer to the failed node than the bypass. Figure 3 shows the details. This problem can easily be solved by utilizing the already mentioned sourcedistance information gathered during the MulMic-DFS-run. Routing from a higher node number to a lower one means that the old routing has to be terminated and a reverse link direction has to be applied for this graph edge when applying the new routing. The major advantage for this model is that the successor node and therefore the destination nodes get the original signal as quickly as technically possible and the not directly affected nodes are not disconnected for rerouting purposes.

5 Example Graphs As an example of the proposed algorithm, Fig. 5 shows a relevant part of a large network graph (hundreds of nodes) and the resulting regional graph with predecessor, failed node and some multicast destinations. In this case (grid-topology) one BFS step (12 links affected) only is necessary to get the whole regional graph. This rerouting can be done in a few microseconds. 3 A simple concatenation of the reached node’s path lists (linked list) and the node-BFS’s path lists in inverted visit order delivers the path. 4 as there is no forking in the network which could be necessary to support another destination node

Realtime Fault-Tolerant Routing in Video Networks // // // //

pre: predecessor node, n: number of successor nodes succ(i): i th successor nodes, i=1 to n LinkedList PL for the path list information in every node nodelist for remaining successor nodes

procedure LBFS (Graph G, Node nod) //LBFS = Labeling BFS do a BFS starting at nod; // do only one level of stepping down For all nodes discovered during BFS do if node has been reached by an already pre-node-derived search then build part of MPath by concatenating the meeting PLs. // delivers a shortest path from pre to current succ Lookup nodes in rendezvous list, terminate their BFS and delete them from nodelist. Ignore already marked links. If there is no more unmarked link available, stop the affected BFS-run. elseif reached node is already marked by another succ node then build part of MPath by concatenating the meeting PLs. Set rendezvous information (local succ-name) in each other node. Ignore already marked links. If there is no more unmarked link available, stop the affected BFS-run. else add the already reached nodename(s) to the linked list PL of the reached node to setup the routing information. od end LBFS algorithm online_rerouting(Graph G, Node failed_node, Node pre, Node[] succ(i), Integer n) // main algorithm remove failed_node from G; while nodelist != empty do LBFS(G, pre); //iterate one step of BFS started from the pre node while there are successors j do LBFS(G, succ(j)); od od // remove pathological edges For all succ’s and pre do remove nodes in direction of old multicast path (in opposite direction for pre node) until following node has outdeg != 1 or until the following node is a destination node. Start DFS over MPath to eliminate loops, correct routing directions //correct loops If the routing for a link would be issued against a falling number pair (di, di+1) (i.e. old routing direction was in opp. dir.) then cancel old routing, establish new connection in new routing dir. Calculate routing commands with information gathered in the linkedLists consider that no command necessary for an already switched link end online_rerouting

Figure 4: Pseudo code for ZirkumFlex algorithm

57

58


Border of regional graph

d1 I

I

succ(1) I

I .?7#88) $38 $31!=!1#5) C H,B%1)=) ")7?). U'9/13)00) >7")#1). T#) U9!*MW :)#?).+ A$%% >3%T#7/3.?). "#% 2#. $38 A#) 0)#"0#62) ,#62)72)#1 X,$8)1BY A)7 C.%$%%). :3.)2=).A 7)$0#%1#%62 T)7A).P @!H A)7.) $31!=!1#5) C 5)7$7")#1)1 3.A %()#62)71 :3.)2=).A $362 ()7%!.)."):#)2"$H 7) 3%(7E?3.?). C H"$%#)71)7 >.?7#88) $38 $31!=!1#5) ,B%1)=) $"P \#.#?) Z)#%(#)0) $3% D!7%623.? 3.A [7$i#% %#.A A$% ^!71E3%62). A)7 /!77)/1). D3./1#!. A)8)/H 1)7 !A)7 ).18)7.1)7 >#7"$?% U'97")#1). ")7)#1% J.1)7%3623.?). :37 >.($%%3.? 5!. C.173%#!. .T).A3.?%8$00 A)7 J.1)7%1F1:3.? )#.)7 J.8$007)/!.H %173/1#!. %()#62)71 )#. J.8!7A)73.H ?). $. A#) "%62.#11 K 5!7?)%1)001 3.A #. >"%62.#11 n $.2$.A A)7 (7!1!1B(#%62). J=%)1:3.? 3.A $3%?)TE201). Z)#%(#)0). #003%17#)71P \#.) .8!7A)73.H ?). 3.A $3%?)TE201)7 ^!7H 3.A `$621)#0) 8!0?1 #. >"%62.#11 o+ ")5!7 )#.) _3%$==).8$%H %3.? 3.A )#. >3%"0#6/ #. >"%62.#11 N A#)%). Z)#17$? %620#)b1P

E /,3-$FG#+)$ /*F$*B,*-38G++$ ,*B !#%$ /*80%B$%,*-$* Z:?0P A)7 A3762 A$% DD.T).A3.?%:T)6/) 8F7 )#. ).1%(7)H 62).A)% ]!??#.?H,B%1)=+ )1T$ :37 \7%1)003.? )#.)% A#?#1$0). D$271)."362% !A)7 ,1$1#%1#H /). :3 %)#.)7 D$27T)#%)+ :PZP 3= 9!%1). 3.A ,62$A%1!88)=#%%#!.). :3 =#.#=#)7).P >362 /$.. )7 A#) ?)0!??1). "%62.#11 *P*Y+ A#) $38 A$% \#.A7#.?). )#.)% >.?7)#8)7% 2#.T)#%). /-..). !A)7 A3762 #2. (!1).1#)00 $3%?)8F271) >/1#!.). $38:)#?).P /1!7). 3=8$%%).P >362 :37 ]$38:)#1 .#621 .E2)7 %():#8#:#)7"$7) >.!=$0#). /-..). $0% (!1).H 1#)00) >.:)#62). %)637#1BH7)0)5$.1)7 >/1#5#1E1). 5!7%!7?0#62 ?)%#62)71 T)7A).P I0++$ IP J Q$%D3)())9 \7?E.:).A :3 ")%1)2).A). D)20)76!A)% X%P >"%62.#11 *Y /-..). 7)?)0=Eb#? (7!1!/!00#)71) C.8!7=$1#!.). 3.A >.!=$0#). $362 c)7/%1E11). ")# A)7 J7%$H 62).$.$0B%) 7)#. %$8)1BH"):!?).)7 ,1-73.?). 3.1)7%1F1:).P cE27).A D)20)76!A)% !81 .37 G71+ _)#1(3./1 3.A >71 )#.)% $388E00#?). _3%1$.A)% 5)7=)7/).+ /$.. #. A). ]!?A$1). ?):#)01 .$62 :)#10#62 3.A /$3%$0 /!77)0#)7).A). \7)#?.#%%). ?)%3621 T)7A).P 312).1#:#1E1+ C.1)?7#1E1 3.A ^)717$30#62/)#1P 0% %)/3.AE7) >.8!7A)73.?). %)#.)7%)#1% /-..). A#) C.1)?7#1E1 3.A

Sichere Datenhaltung im Automobil

157

A#) >312).1#:#1E1 A)7 ]!?A$1). 2#.:3 /!==).+ T).. )7 #= \#.:)08$00 A#) @-?0#62/)#1 2$"). T#00+ 8F7 #2. ?)%()#62)71) 312).1#:#1E1 A)7 ]!?A$1). $0% (7#=E7) >.8!7A)73.? :3 %)2).f _3= 5)70E%%0#62). 38?$") XAP2P :37 \7=#11H 03.? A)7 ^)7%#62)73.?%")17E?)+ d)/!.%173/1#!. 5!. J.8E00). 3.A C H^!78E00). %!T#) :37 D)20)7%362)Y AF78). A#)%) 312).1#:#1E1 ^)717$30#62/)#1

Q$3$*)+!"#$ 5()$-0%!$* 40)$*)!$++ 7, $%F(%)$*B$% /*-%!88$ = /*-%$!8$% \#.%)2). A)7 "%62.#11 nY A#) 8F7 Q)A). $38 A)= DD38:)#62.). 5!. D$27:)3?A$1). $.=)0A).+ /$.. A#)% F")7 )#.) 5)717$3).%TF7A#?)+ A7#11) C.%1$.: )78!0?).P >0% )#. Z)#%(#)0 =-621) %#62 $= DD"%62.#11) n 3.A oP

N ;H$.4+(%!3"#$ M.3$)7,*- ,*B O++,3)%()!0* C= d$2=). 5!. U'!*MW T37A) )#. )7%1)7 [7!1!1B( $0% )i)=(0$7#%62) J=%)1:3.? A)% 9!.:)(1)% #=(0)=).1#)71P 7)$ `)1T!7/ Xa>`Y+ A$ )% #= >31!=!"#0")7)#62 A#) :37:)#1 $= 2E38#?%1). )#.?)%)1:1) D)0A"3%H )62.!0!?#) A$7%1)001 U_,MVWP >3% >.T).A)7%#621 ")%1)21 )#.) a>`HZ!1%62$81 #= c)H %).10#62). $3% )#.)7 .3=)7#%62). C< X%!?P a>`HC`HZ!1%62$81 Xa>`HC< MiKZj+ K `31:A$1)."B1)% ! "# $!Y+ F")7 A#) ,#?.$0) :37 >.:)#?) $. A$% 9!="##.%173=).1 ?)H %).A)1 T)7A).P C. A#)%)= Z)#%(#)0 %#.A A#)% A#) $/13)00) I)%62T#.A#?/)#1 XV Z#1Y %!T#) Q) )#. *HZ#1HD0$? :3= ,)1:). A)7 >#7"$?T$7.0)3621) 3.A :3= ,#?.$0#%#)7). )#.)% )#.?)H 2).A). >.738%P C%1 A#) d38.3==)7 A)% >.738)7% #= )0)8!."362 ?)%()#62)71+ T#7A #. 0)1:1)7)= D$00 :3%E1:0#62 )#.) 9)..3.? :37 >.:)#?) %)#.)% `$=).% $.?)?)").P 2T)$ U9 UH/L * M M M * I)%62T#.A#?/)#1

*

*

* >.738

M

>#7"$?

*

2T)$ :9 UHV: M M M M M

2T)$ E9 UHPL * M * M * M M >.738)7/)..3.? X )0)8!."362HC.A)iY

*

*

>""#0A3.? 4f >381)#03.? A)7 `31:A$1). )#.)7 8#/1#5). a>`HZ!1%62$81 A)% B(% MiKZj

c#) :35!7 $.=!1#5#)71+ ").-1#?). 5)7%62#)A).) d!00). 8F7 #27) _T)6/) .37 )#.). )#0 A)7 /!==3.#:#)71). C.8!7=$1#!.). 3.A %!001). .37 ).1%(7)62).A) _3?7#88) )72$01). X[7#.:#( A)% .!1T).A#?). c#%%).%+ 5?0P U\6/MKWYP >= Z)#%(#)0 A)7 Z3%.$627#621). !P?P B(% 0#)8)71 $")00) 4 )#.) )i)=(0$7#%62) _3!7A.3.? A)7 ).12$01).). ,#?.$0) 8F7 A#)

160


d!00). Z)%#1:)7 Xd*Y+ c)7/%1$11 XdoY 3.A ^)7%#62)73.? Xd4+ 8F7 A#) 7)%10#62). d!00). $3% >"%62.#11 4 0#)b) %#62 A#)% Et3#5$0).1 5!7.)2=).YP Z)#%(#)0%T)#%) %!001). %).%#"0) .738)7/)..3.?). X()7%!.)."):#)2"$7) ` [7!1!/!00% )78!0?1 A#) C=(0)H =).1#)73.? :3.E62%1 $0% aww [7!?7$== 3.1)7 ]#.3iP H4oN X'$%283./1#!.Y ?)TE201 X5?0P $362 UZ3*MWYP "%62.#11 K 5!7?)%1)001). 9!.:)(1P `H`$627#621). "$%#)7).A).Y [7!1!/!00)#.17E?) "0!6/!7#).1#)71 %#.A+ )78!0?1 A#) %B==)17#%62) >\,H^)7%620F%%)03.? $0% Z0!6/62#887) #= aZa @!A3% Xa#(2)7 Z0!6/ a2$#.#.?YP .?7#88) $38 A#) 5)7%620F%%)01). 3%.$2=) %!062)7 \#.17E?)+ 8F7 A#) .!62 A)7 $/13)00) ,)%%#!.H 9)B ?#01YP '#)78F7 ").-1#?1 )7 A#) ?)2)#=). ,620F%%)0 A)7 `31:)7+ A#) :3 /)#.)7 _)#1 $38 A)= ,B%1)= 5!7?)2$01). T)7A).P >0% `$621)#0 /$.. A$?)?). $.?)%)2). T)7A).+ A$%% A)7 DD.?7)#8)7 $. A#)%).+ /$.. )7 X:3%$==). =#1 A). [3"0#6 9)B% A)7 `31:)7Y ")0#)"#?) %#?.#)71) ]!?A$H 1)#). )7:)3?). X)#. %)0)/1#5)% ^)78E0%62). ")%1)2).A)7 C.2$01) ?)%1$01)1 %#62 =$.?)0% @-?0#62/)#1 A)7 \.1%620F%%)03.? Q)A!62 %62T#)7#?+ %P!PYP ""P KY )7H /$..1 T)7A).m )#.) \7T)#1)73.? 3= ,)t3).:.3==)7. #%1 :3A)= =-?0#62P !"#$%#$!) D%T4)0-%(4#!3"#$% K$%8(#%$*9 _3/F.81#? /-..1). >.?7#88) $38 A#) )#.?)H %)1:1). /7B(1!?7$(2#%62). ^)78$27). )88)/1#5)7 T)7A).P I)0$.?1 )#. >.?7)#8)7 ")#H %(#)0%T)#%) F")7 9.!T.H[0$#.1)i1H>.?7#88) UZ3*MW $. A#) %B==)17#%62). ,620F%%)0 !A)7 A3762 D$/1!7#%#)73.? UZ3*MW 5!. d,> [3"0#6 9)B% $. A#) [7#5$1) 9)B% A)7 7)?#%17#)71). `31:)7+ /-..1). A#) ?)8!7A)71). ,6231::#)0) .#621 =)27 ?)TE270)#%1)1 T)7A).P cE27).A A)7 ])").%:B/03% /7B(1!?7$(2#%62)7 ^)78$27). $/13)00 A)310#62 3.1)7 A)= ])").%:B/03% =!A)7.)7 >31!=!"#0) 0#)?1 X!81 *oH4M ;$27)Y+ /$.. %#62 :PZP )#. .$6217E?0#62)7 c)62%)0 A)7 /7B(1!?7$(2#%62). >0?!7#12=). $38?73.A A)7 )#.?)%627E./1). ,B%1)=7)%%!376). %62T#)7#? ?)%1$01).P [!1).1#$0 "#)1)1 2#)7 :PZP %():#)00 $38 )#.?)")11)1) X$31!=!1#5)Y ,B%H 1)=) :3?)%62.#11).) C*4+$>5#*4+$ 97B(1!?7$(2#) X5?0P TTTP)67B(1P)3P!7?k0#?21T)#?21kYP /,)#$*)!7!)G) ,*B O*)$-%!)G) B$% ;!*-(*-3B()$*9 ')31#?) $31!=!1#5) Z3%.)1:T)7/) "#)1). .!62 /)#.) ,6231:=)62$.#%=).+ A#) A). >.8!7A)73.?). A)7 C H,)637#1B ?).F?). X:PZP 8F7 >312).1#:#1E1%H 3.A 5)70E%%0#62) C.1)?7#1E1%(7F83.?).YP >38 2)31#?) D$27:)3?) $.?)T$.A1+ /$.. A)7 DD%H ()/1) :3 )7T)#1)7.P Z)#%(#)0%T)#%) %!001) :37 ")T)#%/7E81#?). ^)7T)713.? A)7 ]!?A$1). )#. ")%!.A)7)% >3?).=)7/ $38 A#) _)#1%B.627!.#1E1 ?)%)1:1 T)7A).P \#. T)#1)7)7 [3./1 #%1+ A$%% Q) .$62 >.:$20 A)7 7)?#%17#)71). `31:)7 3.A J=8$.? A)7 :3 %#62)7.A). .8!7A)73.?). $. A#) :3 %#62)7.A). 362 T)#1)7) !88).) [3./1) %!001). #. :3/F.81#?). >7")#1). .!62 5)71#)81 $A7)%%#)71 T)7H A).P '#.%#6210#62 A)% [7!1!1B(% #%1 A)7 d)%%!376).")A$78 A)% DD`H9!==3.#/$1#!. :3 3.1)7%3H 62).P C.%")%!.A)7) $38?73.A A)% 2!2). 9!%1).A736/% #. A)7 >31!=!"#0#.A3%17#) #%1 A#)% )%%).1#)00 8F7 A#) d)6218)71#?3.? )#.)% (7$/1#%62). \#.%$1:)%P 7")#1 ).1%1$.A). $3% A)7 Z)$7")#13.? )#.)% [7!H Q)/1)% A)% Z3.A)%$=1% 8F7 ,#62)72)#1 #. A)7 C.8!7=$1#!.%1)62.!0!?#) XZ,CYP 2) T!7/ A)%67#")A #.

164


12#% ($()7 2$% ")). %3((!71)A #. ($71 "B 12) \37!()$. a!==#%%#!. 127!3?2 12) Ca (7!?7$==) 3.A)7 6!.17$61 Ca H4MMjH4*NNjN \adx[ CCP

]!)$%(),%?$%7$!"#*!3 U'9P X'7%?PYf '$.A"362 ^)7/)27%3.8$007)/!.%173/1#!.+ 4P+ $/13$0#%#)71) >380$?)+ ^)70$? ^#)T)? w )3".)7+ C,Z` LjVHKHVKnVHMonNH*+ 4MMLP UZ!MVW Z!7?))%1+ 9Pf \0)/17!.#/ #. A)7 D$27:)3?1)62.#/ H '$7AT$7)+ ,!81T$7)+ ,B%1)=) 3.A [7!Q)/1=$.$?)=).1+ *P >380$?) 4MMV+ ^#)T)? ^)70$?+ C,Z` LjVHKHVKnVHM4MjH*+ 4MMVP UZPm Z#$.6!+ 3%1#.f '$6/)7 MLW9#01:+ ,Pm '#0A)"7$.A1+ @Pm >01%62$88)0+ dPm @H >.$0B%). 3.A D#0)6$75#.? =#1 '#08) )#.)% 8!7).%#%62). H4MMNH4oNNN+ 4MMNP U_,MVW _#==)7=$..+ cPm ,62=#A?$00+ dPf Z3%%B%1)=) #. A)7 D$27:)3?1)62.#/ H [7!1!/!00) 3.A ,1$.A$7A%+ KP+ >380$?)+ ^#)T)? ^)70$?+ C,Z` LjVHKVKnVMnnj*+ 4MMVP U@d*MW @Bd$1) [7!?7$=+ 211(fkkTTTP(7!?7)%%#5)P6!=k=B7$1)k+ ])1:1)7 _3?7#88f *NPNP4M*MP U9'M4W 973%)+ cPm ')#%)7+ ;Pf a!=(31)7 D!7).%#6% e C.6#A).1 d)%(!.%) \%%).1#$0%+ >AA#%!. c)%0)B+ C,Z` M4M*jMj*Lo+ 4MM4P UZ3*MW Z362=$..+ ;Pf \#.8F273.? #. A#) 97B(1!?7$(2#)+ oP >380$?)+ ,(7#.?)7H^)70$?+ C,Z` LjVH KHNn4H***VoHK+ 4M*MP U\6/MKW \6/)71+ aPf C H,#62)72)#1+ G0A)."!37?+ C,Z` KHnVNH4j4MoHn+ 4MMKP UZ_MVW 31!/0$3+ ')#%) `)T%1#6/)7 oPKP4MMV+ 211(fkkTTTP2)#%)PA)k.)T%1#6/)7k=)0A3.?k*MnoLK+ 4MMVP Uc)MLW c)B0+ ZP )1P $0Pf ,)637#.? ^)2#630$7 G.HZ!$7A C ,B%1)=%f 2) \^C > [7!Q)61P C.f 4oP ^31!=!1#5) ,)637#1B Xa