Dipl. - Universität Tübingen
Transcrição
Dipl. - Universität Tübingen
Eberhard Karls Universität Tübingen Wilhelm-Schickard-Institut für Informatik Arbeitsbereich für Theoretische Informatik / Formale Sprachen Diplomarbeit Sichere Transaktionen beim Online-Banking Jan Vitense 27. August 2008 Betreuer: Privatdozent Dr. Klaus Reinhardt Inhaltsverzeichnis 1 Einleitung 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 10 2 Grundlagen 2.1 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . 2.2 Online-Banking-Systeme . . . . . . . . . . . . . . . . . 2.2.1 Kommunikationsteilnehmer . . . . . . . . . . . 2.2.2 Funktionalität eines Online-Banking-Systems . . 2.2.3 Hardware . . . . . . . . . . . . . . . . . . . . . 2.2.4 Software . . . . . . . . . . . . . . . . . . . . . . 2.3 Gefahren . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Phishing . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Man-in-the-Middle-Angriff . . . . . . . . . . . . 2.3.3 Replay-Angriff . . . . . . . . . . . . . . . . . . . 2.4 Rechtliche Situation bei betrügerischen Überweisungen . . . . . . . . . . . 11 11 12 12 13 14 14 14 15 17 18 18 3 Systematik des Vergleichs 3.1 Kategorisierung . . . . . . . . . . . . 3.2 Sicherheit . . . . . . . . . . . . . . . 3.2.1 Praktische Sicherheitsanalyse 3.2.2 Formale Sicherheitsanalyse . . 3.3 Kosten . . . . . . . . . . . . . . . . . 3.4 Benutzerfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 23 23 23 25 25 4 Legitimationsverfahren 4.1 Schnittstellenklasse Ausgehend - Keine“ . . . ” 4.1.1 Klassische TAN . . . . . . . . . . . . . 4.1.2 Elektronische TAN . . . . . . . . . . . 4.2 Schnittstellenklasse Bidirektional - Keine“ . . ” 4.2.1 Indizierte TAN . . . . . . . . . . . . . 4.2.2 Dynamische TAN . . . . . . . . . . . . 4.2.3 Permutations-TAN . . . . . . . . . . . 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 30 30 33 36 36 39 45 48 . . . . . . . . . . . . . . . . . . . . . . . . 3 Inhaltsverzeichnis 4.4 4.3.1 Mobile TAN . . . . . . . . 4.3.2 Cardano-TAN . . . . . . . 4.3.3 Visuelle TAN . . . . . . . 4.3.4 Fotohandy-TAN . . . . . . 4.3.5 Internetpassport . . . . . 4.3.6 Monitor-TAN . . . . . . . Schnittstellenklasse Bidirektional ” 4.4.1 WYSIWYS . . . . . . . . 4.4.2 HBCI-Verfahren . . . . . . 4.4.3 Chipkarte mit Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - Bidirektional“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 50 53 56 58 60 63 63 65 71 5 Ergebnisse der Analyse 75 5.1 Interpretation der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2 Empfehlungen für den Entwurf neuer Token . . . . . . . . . . . . . . . . 77 5.3 Kriterien für sichere Online-Banking-Verfahren . . . . . . . . . . . . . . . 79 6 Zusammenfassung und Ausblick 81 Literaturverzeichnis 83 A Formale Protokollspezifikationen in A.1 Indizierte TAN . . . . . . . . . A.2 Sm@rtTanplus . . . . . . . . . . A.3 Mobile TAN . . . . . . . . . . . A.4 Fotohandy-TAN . . . . . . . . . A.5 HBCI 2 . . . . . . . . . . . . . A.6 HBCI 3 . . . . . . . . . . . . . HLPSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 87 91 94 96 99 101 B Ausgaben von AVISPA B.1 indizierte TAN . . B.2 Sm@rtTanplus . . . B.3 Mobile TAN . . . . B.4 Fotohandy-TAN . . B.5 HBCI 2 . . . . . . B.6 HBCI 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 105 107 107 109 109 111 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabellenverzeichnis 2.1 Übersicht der Transaktionen beim Online-Banking . . . . . . . . . . . . . 13 5.1 Übersicht der Bewertung der Legitimationsverfahren 76 . . . . . . . . . . . 5 Tabellenverzeichnis 6 Abbildungsverzeichnis 2.1 Phishing-E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1 Vier mögliche Schnittstellen des Geräts . . . . . . . . . . . . . . . . . . . 22 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 TAN-Liste der Citibank . . . . . . . . . . . . . . . . . . . . . . . . . . . Ablauf des klassischen TAN-Verfahrens . . . . . . . . . . . . . . . . . . . sm@rtTAN-Generator mit eingesteckter Bankkarte . . . . . . . . . . . . Ablauf des sm@rtTAN-Verfahrens . . . . . . . . . . . . . . . . . . . . . . TAN-Generator Bankey“ . . . . . . . . . . . . . . . . . . . . . . . . . . ” Beispiel einer iTAN-Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . Ablauf des iTAN-Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . . Captcha beim iTANplus-Verfahren . . . . . . . . . . . . . . . . . . . . . TAN-Generator der BW-Bank; Quelle: www.cio.de . . . . . . . . . . . . TAN-Generator der Volks- und Raiffeisenbanken; Quelle: Volksbank Bonn Rhein-Sieg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ablauf beim dynamischen TAN-Verfahren der BW-Bank . . . . . . . . . Ablauf beim sm@rtTANplus-Verfahren der Volks- und Raiffeisenbanken . Potentieller Angriff auf das sm@rtTANplus-Verfahren; Quelle: eigene Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . verschlüsselte Dateneingabe beim pTAN-Verfahren; Quelle: Bernd Borchert Ablauf beim pTAN-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . Ablauf des mobile TAN-Verfahrens . . . . . . . . . . . . . . . . . . . . . Funktionsweise des Cardano-TAN-Verfahrens; Quelle: Bernd Borchert . . Ablauf des Cardano-TAN-Verfahrens . . . . . . . . . . . . . . . . . . . . Verschlüsselung der Bildpunkte bei der visuellen TAN; Quelle: RheinischWestfälische Technische Hochschule Aachen . . . . . . . . . . . . . . . . Funktionsweise der visuellen TAN; Quelle: Bernd Borchert . . . . . . . . Ablauf des visuellen TAN-Verfahrens . . . . . . . . . . . . . . . . . . . . Ablauf des Fotohandy-TAN-Verfahrens . . . . . . . . . . . . . . . . . . . Ablauf des Internetpassport-Verfahrens . . . . . . . . . . . . . . . . . . . Mögliche Ausführung eines Monitor-Dongles; Quelle: Wikipedia . . . . . Ablauf des Monitor-TAN-Verfahrens . . . . . . . . . . . . . . . . . . . . Ablauf des WYSIWYS-Verfahrens . . . . . . . . . . . . . . . . . . . . . . Ablauf von HBCI mit Schlüsseldiskette . . . . . . . . . . . . . . . . . . . Chipkartenleser der Sicherheitsklasse 1; Quelle: Wikipedia . . . . . . . . 31 31 33 34 35 36 36 37 39 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 40 40 41 43 46 46 49 51 51 53 54 55 57 59 60 61 63 65 66 7 Abbildungsverzeichnis 4.29 4.30 4.31 4.32 Chipkartenleser der Sicherheitsklasse 2; Quelle: Wikipedia . . . . . . . . Chipkartenleser der Sicherheitsklasse 3; Quelle: Wikipedia . . . . . . . . Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 1 oder 2 . . . . . Theoretisch möglicher Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.33 Skizze der Chipkarte mit Display im Einsatz . . . . . . . . . . . . . . . . 5.1 8 Gegenüberstellung des Zeitbedarfs und der Kosten der MITM-resistenten Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 67 68 69 72 78 1 Einleitung Neben der Abwicklung von Bankgeschäften auf klassische Art mit Papier und Bankpersonal hat der Einsatz von Online-Banking in Deutschland große Bedeutung gewonnen. Bereits im Jahre 2006 wurden 40% aller Girokonten online geführt. Die Anzahl der Online-Überweisungen beliefen sich im selben Jahr auf 1,8 Millionen [Deu08], und ihr Gesamtwert betrug knapp 1,7 Billionen ¿. Gleichzeitig werden in diesem Bereich auch immer mehr Betrugsfälle registriert. Von 2006 auf 2007 stieg die Anzahl der InternetNutzer, deren Konten mit geklauten Passwörtern geplündert wurden um 23% auf mehr als 3.250 Fälle [Bun07]. Da die Banken den resultierenden Vertrauensschaden begrenzen wollen, werden vermutlich nicht alle Schäden angezeigt, so dass die tatsächliche Zahl viel höher liegen dürfte. Täglich werden neue Meldungen über Sicherheitslücken in Betriebsystemen, Browsern oder anderer Software berichtet. Die Begriffe Phishing, Viren und Trojanische Pferde kennt heute jeder Computernutzer, und die Tricks der Betrüger werden immer raffinierter. Das sind Gründe genug, um sich mit den Sicherheitsaspekten des Online-Bankings genauer auseinander zu setzen. 1.1 Motivation Die Abwicklung von Bankgeschäften sollte beim Online-Banking ähnlich sicher sein wie beim herkömmlichen, beleghaften Banking. Die Sicherheit hängt dabei online und offline zentral vom eingesetzten Legitimationsverfahren ab, also von der Art und Weise, wie Transaktionen durchgeführt werden. Überprüft eine Bank zum Beispiel generell keine Unterschriften auf Überweisungsaufträgen, könnte ein Betrüger Aufträge mit gefälschter Unterschrift einreichen und so von jedem beliebigen Konto auf jedes beliebige Konto Geld transferieren. Sind die Signaturprozesse beim Online-Banking schlecht implementiert, kann auch hier ein Betrüger unter anderem Namen Aufträge zu seinen Gunsten und zu Lasten eines ahnungslosen Bankkunden tätigen. Es gibt heute eine Vielzahl unterschiedlicher Methoden, die die Sicherheit beim OnlineBanking garantieren sollen. PIN/TAN-Verfahren, Chipkartenleser, SMS-TANs für das Handy und HBCI stellen nur eine kleine Auswahl der verfügbaren Verfahren dar. Dabei stellen sich einige Fragen: Sind diese Verfahren wirklich sicher vor den immer tückischeren und ausgefeilteren Angriffsmethoden der Betrüger? Welche Vor- und Nachteile haben die Legitimationsverfahren? Welche Verfahren gibt es überhaupt? Online-Banking-Verfahren stellen immer einen Kompromiss zwischen Sicherheit, Kosten und Aufwand für den Benutzer dar. Selbst ein extrem sicheres Verfahren wird 9 1 Einleitung möglicherweise nicht zur Anwendung kommen, wenn es mit zu hohen Kosten oder zu hohem Aufwand für den Benutzer verbunden ist. Leider sind gerade die sicheren Verfahren oft teuer oder kompliziert zu bedienen. Für eine umfassende Beurteilung und einen fairen Vergleich der Verfahren ist eine Analyse der Kosten und der Benutzerfreundlichkeit daher unumgänglich. Die vorliegende Arbeit soll systematisch gängige und neue Online-Banking-Verfahren vorstellen und hinsichtlich der Sicherheit vor Man-in-the-Middle-Angriffen und hinsichtlich der Benutzerfreundlichkeit vergleichen. 1.2 Vorgehensweise Das Kapitel 2 gibt einen Einblick in den aktuellen Stand der Literatur und Forschung zu dem Thema Sicherheit beim Online-Banking und erklärt für das Verständnis dieser Arbeit voraussetzende Grundlagen. In Kapitel 3 wird die Systematik vorgestellt, anhand der der Vergleich der Verfahren vollzogen wird. Die Vorstellung und Analyse der Verfahren ist Gegenstand des Kapitels 4. Kapitel 5 diskutiert die Ergebnisse aus dem vorigen Kapitel. Die Arbeit schließt mit Zusammenfassung und Aublick in Kapitel 6. 10 2 Grundlagen In diesem Kapitel werden Arbeiten zum Thema Sicherheit im Online-Banking aufgeführt und diese Arbeit von den bisher erschienenen abgegrenzt. Weiter werden für das Verständnis der Arbeit wichtige Grundlagen erläutert und einschränkende Annahmen getroffen. 2.1 Verwandte Arbeiten Es gibt bereits einige Publikationen, die sich mit der Sicherheit beim Online-Banking befassen. Im folgenden sind einige relevante Veröffentlichungen aufgeführt. In seiner Arbeit Why Cryptosystems Fail [And93] beschreibt Anderson, wie die Sicherheit von Informationssystemen in der Realität kompromittiert wird. Er stellt fest, dass die meisten Angriffe nicht auf dem Aufbrechen der kryptographischen Methoden basieren, sondern dass Schwachstellen durch Implementierungsfehler oder schlechte Organisation ausgenutzt werden. Die Analyse stützt sich auf die Untersuchung der Sicherheit von Geldautomaten und der damit zusammenhängenden Infrastruktur. Die gefundenen Probleme - wie zum Beispiel Betrug durch Bankangestellte - lassen sich teilweise auch auf den Bereich des Online-Bankings übertragen. Im weiteren Verlauf dieser Arbeit werden diese Aspekte allerdings nicht betrachtet, da sie unabhängig von den verschiedenen Online-Banking-Verfahren sind und somit keinen Einfluss auf die Vergleichbarkeit haben. Das Fraunhofer-Institut für Sichere Informationstechnologie SIT untersuchte im Rahmen einer Studie im Jahr 2004 die Online-Banking-Systeme von zwölf deutschen Banken auf ihre Sicherheit vor Phishing-Angriffen [Fra04]. Die Ergebnisse ließen die Banken in keinem guten Licht erscheinen. Keine einzige Bank erhielt eine gute oder sehr gute Bewertung. Bewusst nicht untersucht wurde die Gefahr durch Schadsoftware wie Würmern, Viren und Trojanischen Pferden. Hole et al. untersuchen in dem Artikel Case Study: Online Banking Security [HMT06] verschiedene Sicherheitslücken im Online-Banking norwegischer Banken. Sie schildern Brute-Force-Angriffe auf Login-Namen, verteilte Angriffe von mehreren Computern aus gleichzeitig und verschiedene Denial-of-Service-Angriffe. Eine Bedrohung durch Trojanische Pferde und Man-in-the-Middle-Angriffe wird allerdings dort nicht beschrieben. Allerdings benennen sie ein generelles Problem in der Bankenbranche: Oft stößt ein Forscher bei den Unternehmen auf taube Ohren, wenn er ihnen entdeckte Sicherheitslücken mitteilen möchte. So wird das Beheben der Probleme erschwert. Die Fülle an Arbeiten zum Thema Sicherheit beim Online-Banking zeigt, dass sich 11 2 Grundlagen die Forschergemeinde und auch Bankkunden stark für dieses Themengebiet interessieren. Die Sichtung der Literatur hat aber auch ergeben, dass es bislang noch keine öffentliche, detaillierte Beschreibung der eingesetzten Online-Banking-Verfahren gibt. Diese Lücke soll die vorliegende Arbeit nun füllen. 2.2 Online-Banking-Systeme In dieser Arbeit wird unter einem Online-Banking-System ein Client-Server-Informationssystem verstanden, das zum Datenaustausch zwischen einem Anwender und einem Server der Bank das Internet benutzt. Teile des Systems sind die Kommunikationspartner Anwender und Bank, die Funktionalität, die das System dem Anwender bietet, zugrundeliegende Hardware wie etwa der Computer des Anwenders, der Server der Bank, die physischen Kommunikationskanäle und gegebenenfalls weitere technische Geräte wie Mobiltelefone und Chipkartenleser. Weitere Komponenten sind die verwendete Computerprogramme und schließlich auch die verwendeten Legitimationsverfahren. Ausprägungen dieser Elemente werden im folgenden erläutert. 2.2.1 Kommunikationsteilnehmer An der Kommunikation im Rahmen eines Online-Bankin-Systems nehmen Banken und Anwender teil. Eine Bank hat zumeist genau ein Online-Banking-System, an dem viele verschiede Anwender teilnehmen. Außerdem gibt es Angreifer, die versuchen, auf illegalem Weg an das Geld der Kunden oder der Bank zu gelangen. Die Begriffe Anwender, Benutzer und Kunde werden in dieser Arbeit synonym verwendet. Gemeint ist damit vor allem der Privatkunde einer Bank, der über keine tiefen Kenntnisse in der IT-Sicherheit verfügt. Auch die in dieser Arbeit erwähnten Geschäftsvorfälle richten sich vornehmlich an Privatkunden. Geschäftsvorfälle, die in erster Linie für Geschäftskunden und Unternehmen interessant sind - wie zum Beispiel verteilte Unterschriften und Sammelüberweisungen - werden hier nicht behandelt. Die Arbeit betrachtet nur Angriffe auf das Online-Banking-System. Ein Bankräuber, der mit Gewalt in eine Filiale einer Bank eindringt und durch Geiselnahme die Herausgabe von Bargeld fordert, kann nicht von einem Online-Banking-System gestoppt werden. Ebensowenig kann ein Online-Banking-System einen kriminellen Bankangestellten davor hindern, gefälschte Überweisungsaufträge freizugeben. Ein Angreifer kann aber durchaus aus den Reihen der Kunden oder der Bank kommen. Es wird aber davon ausgegangen, dass ein Angreifer seinen Angriff über das Internet durchführt. Dabei hat der Angreifer insbesondere Kenntnis über die technischen Einzelheiten des Online-Banking-Systems. Einzig explizite Geheimnisse wir PINs, TANs und elektronische Schlüssel besitzt er zu Beginn seines Angriffes nicht. Heute geht die Gefahr nicht mehr in erster Linie von Einzeltätern, sondern von organisierten Verbrecherbanden aus. 12 2.2 Online-Banking-Systeme Kommunikationspartner sind neben Menschen und Unternehmen auch technische Geräte, wie etwa Computer, Geldautomaten, Chipkarten, Mobiltelefone, die miteinander Informationen austauschen, die für sie eine Bedeutung haben. 2.2.2 Funktionalität eines Online-Banking-Systems Ein Online-Banking-System stellt dem Anwender eine Vielzahl an Funktionen zur Verfügung, die zur Erledigung der Bankgeschäfte dienen. Diese Funktionen werden in Form von Transaktionen durchgeführt. Beim Online-Banking für Privatkunden der Dresdner Bank beispielsweise stehen die in Tabelle 2.1 aufgeführten Transaktionen zur Verfügung: Zu Tabelle 2.1: Übersicht der Transaktionen beim Online-Banking Beginn einer Online-Banking-Sitzung muss sich der Anwender am System anmelden. Das geschieht üblicherweise durch Eingabe einer Benutzerkennung und eines Passwortes oder einer PIN. Nach dem Anmelden stehen dem Anwender die Funktionen des Systems zur Verfügung. Einige Transaktionen kann der Anwender ohne weitere Sicherheitsüberprüfungen durchführen, andere nicht. Der Grund, warum verschiedene Transaktionen unterschiedliche Sicherheitsmechanismen verlangen, liegt darin, dass das Risiko und der Schaden bei einem Betrug unterschiedlich sind. So kann durch das unbefugte Abrufen eines Kontoauszugs noch kein direkter finanzieller Schaden für den Kunden entstehen. Eine manipulierte Überweisung indes führt zu einem direkten Geldverlust beim Kunden oder anschließend bei der Bank, wenn diese dem Kunden den Schaden ersetzt. Im Fall des vorgestellten Online-Banking-Systems muss der Anwender für jede sicherheitskritische Transaktion eine Transaktionsnummer eingeben. Die Einteilung, welche Transaktionen sicherheitskritisch sind, muss die Bank im Vorfeld festlegen. Im folgenden werden unter Transaktionen nur sicherheitskritische Transaktionen verstanden. Der Stereotyp dieser Transaktion ist der Überweisungsauftrag. 13 2 Grundlagen 2.2.3 Hardware Für die Online-Banking-Verfahren wird wie bei jedem Client-Server-System verschiedene Hardware benötigt. An dieser Stelle soll nur auf zwei Komponenten näher eingegangen werden, nämlich auf den Rechner des Kunden und auf technische Geräte, die der Kunde zur Absicherung sicherheitskritischer Transaktionen zur Verfügung hat. Der Kundenrechner muss zur Kommunikation mit dem Bankserver über eine Anbindung an das Internet verfügen. In dieser Arbeit wird davon ausgegangen, dass Computer generell durch Schadsoftware kompromittiert werden können. Eine solche Schadsoftware kann 2.2.4 Software Der Anwender kann auf das Online-Banking-System prinzipiell auf zwei Arten zugreifen. Zum einen gibt es die Möglichkeit, das System als Web-Anwendung über einen InternetBrowser zu bedienen. Zum anderen gibt es Systeme, die den Einsatz einer speziellen Online-Banking-Software fordern. Im Rahmen dieser Arbeit wird angenommen, dass sich diese verschiedenen Software-Optionen nicht in Bezug auf Benutzerfreundlichkeit und Sicherheit unterscheiden. 2.3 Gefahren Ein perfekt sicheres Online-Banking-Verfahren sollte garantieren, dass eine Transaktion dann und nur dann durchgeführt wird, wenn der Bankkunde sie bewusst und willentlich eingegeben hat. Dies gibt einerseits dem Bankkunden die Sicherheit, dass im Rahmen des Online-Banking genau das geschieht, was er selbst möchte und äußert. Andererseits gibt es der Bank die Sicherheit, dass sie nur Transaktionen ausführt, die nachweisbar vom Kunden gewollt und geäußert wurden. Anders gesagt gibt es bei der Sicherheit vier Aspekte: Vertraulichkeit, Verbindlichkeit, Integrität und Verfügbarkeit. Vertraulichkeit: Informationen werden nur denjenigen bekannt, die die Infos erhalten sollen. Verbindlichkeit: Eine verbindliche Aussage kann im Nachhinein nicht bestritten werden. Integrität: Autor und Inhalt einer Nachricht stehen fest und können nicht unbemerkt verändert werden. Verfügbarkeit: Immer dann, wenn zwei Parteien miteinander kommunizieren wollen, können sie dies. Die Übartragung kann nicht blockiert werden. Eine Gefährdung dieser Sicherheit ist bei realen Systemen durch beabsichtigte Angriffe oder durch unbeabsichtigte Ereignisse gegeben. Dem ersten Fall wird im Rahmen der IT-Security“ begegnet, die auch zentrales Thema dieser Arbeit ist. Im Folgenden wird ” Sicherheit“ mit dieser IT-Security“ gleichgesetzt. Dem zweiten Fall wird im Rahmen ” ” der IT-Safety“ begegnet, worauf an dieser Stelle nicht näher eingegangen wird. ” Die Sicherheit von Online-Banking-Systemen kann auf unterschiedliche Arten kompromittiert werden. Dabei bestehen folgende Gefahren: 14 2.3 Gefahren 1. Vertrauliche Informationen, die zwischen Kunde und Bankserver übertragen werden, werden von Unbefugten abgehört. Diese Gefahr ist ein Problem fehlender Vertraulichkeit. 2. Ein vom Kunden gewünschter und geäußerter Transaktionsauftrag wird nicht ausgeführt. Diese Gefahr ist ein Problem fehlender Verfügbarkeit. Ein Denial-of-ServiceAngriff kann das erreichen. 3. Ein bei der Bank korrekt eingereichter Transaktionsauftrag wird ausgeführt. Nachher wird vom Kunden bestritten, diesen Autrag erteilt zu haben. Diese Gefahr ist ein Problem der Verbindlichkeit. 4. Ein vom Kunden gewünschter und geäußerter Transaktionsauftrag wird mehrfach ausgeführt. Ein Replay-Angriff kann das erreichen. 5. Ein vom Kunden ungewollter aber geäußerter Transaktionsauftrag wird ausgeführt. Das kann beispielsweise bei einer Erpressung, einem Irrtum oder einer Fehlerhaften Dateneingabe eintreten. Eine automatische Erkennung von Diskrepanz zwischen Willen und Äußerung eines Kunden ist technisch schwierig zu realisieren. Allerdings läßt - und sollte - sich durch transparente Mensch-Computer-Interaktion die Wahrscheinlichkeit von Irrtum und Fehlern reduzieren. Ein Phishing-Angriff kann diese Gefahr ausnutzen. 6. Ein vom Kunden gewollter und geäußerter Transaktionsauftrag wird verändert ausgeführt. Ein Man-in-the-Middle-Angriff kann das erreichen. 7. Ein vom Kunden weder gewollter noch geäußerter Transaktionsauftrag wird durchgeführt. Ein Identitätsdiebstahl durch Phishing kann das ermöglichen. Die hier diskutierten Online-Banking-Verfahren sollen die Gefahren 3, 4, 5, 6 und 7 erschweren oder verhindern. Die Gefahren 1 und 2 sind für den Kunden normalerweise mit keinem direkten finanziellen Schaden verknüpft und können effektiver durch andere Maßnahmen abgewehrt werden. Überhaupt kann die Vertraulichkeit der übertragenen Daten bei dem hier angenommenen Angreifermodell prinzipiell nicht sichergestellt werden, da die Daten am Bildschirm angezeigt oder über die Tastatur eingegeben werden und von einem Trojaner abgehört werden können. Die Gefahr 6 ist hier von großer Bedeutung, weil sie von vielen momentan eingesetzten Verfahren nicht verhindert wird. Im folgenden werden einzelne Angriffe näher erläutert. 2.3.1 Phishing Phishing ist ein Angriff auf den Anwendereines Online-Banking-Systems, der diesen mit einbezieht und ihn bewusst austrickst. Damit gehört diese Angriffsart zum Social Engineering. Durch Vorspiegelung falscher Tatsachen, durch Erzeugen von Angst, Druck, 15 2 Grundlagen Hoffnung etc. wird der Anwender dazu bewegt, etwas zu tun, was die Sicherheit eines Systems kompromittiert. Häufig erhält der Angreifer dadurch sensible Daten wie Benutzernamen, Passwörter oder TANs. Der Phishing-Angriff wird am Beispiel des klassischen PIN-TAN-Verfahrens beschrieben. Zunächst erhält der Kunde eine Aufforderung, sich auf eine Phishing-Website zu begeben. Die Aufforderung wird beispielsweise per E-Mail oder Instant Messaging versandt. Der Aufforderung wird mit plausiblen Gründen oder Drohungen Nachdruck verliehen (siehe Abbildung 2.1). Abbildung 2.1: Phishing-E-Mail; Quelle: Wikipedia Auf der gefälschten Webseite wird dann vom Kunden gefordert, seinen Benutzernamen, seine PIN und eine TAN einzugeben; vermeintlich mit dem Zweck, drohende Gefahr abzuwenden. Die Webseite enthält Merkmale wie Firmenlogo und Corporate Design der Bank des Kunden, so dass dieser glaubt, sich tatsächlich auf einer Webseite seiner Bank zu befinden. Der Angreifer erhält die eingegebenen Zugangsdaten und kann damit zu einem späteren Zeitpunkt online auf das Kundenkonto zugreifen und eine betrügerische Transaktion durchführen. Das gutgläubige Verhalten des Kunden ermöglicht den Phishing-Angriff. Daher kann man den Angriff nur verhindern, indem man den Anwender aufklärt, oder indem technische Möglichkeiten die Täuschung für den Kunden offensichtlicher machen. 16 2.3 Gefahren 2.3.2 Man-in-the-Middle-Angriff Ein weiterer Angriff auf Computer und Netzwerke ist der sogenannte Man-in-the-MiddleAngriff (MITM-Angriff). Wenn zwei Parteien kommunizieren, klinkt sich ein Angreifer unbemerkt in die Kommunikation ein und gibt sich für den jeweils anderen aus. Beispielsweise könnte sich bei einer Internet-Verbindung zwischen Kunde und Bank ein Trojaner gegenüber der Bank als Kunde und gegenüber dem Kunden als Bank ausgeben, so dass sämtliche Daten über den Trojaner weitergeleitet, aber auch gelesen, manipuliert und unterdrückt werden können. Der MITM-Angriff ist gefährlich, weil er oft nur mit großem Aufwand verhindert werden kann. Solange keine Daten verändert werden, kann er außerdem fast gar nicht entdeckt werden. Andererseits ist auch der Angreifer bei dieser Angriffsart etwas eingeschränkt: Der Angriff kann nämlich nur dann stattfinden, wenn die beiden Parteien auch tatsächlich miteinander kommunizieren und in Verbindung stehen. Solange ein Angreifer also noch mit einem unkomplizierteren Angriff zu seinen Zielen gelangt, wird er den MITM nicht einsetzen. Das folgende Beispiel aus dem Bereich des Online-Banking mit dem PIN / iTANVerfahren verdeutlicht den MITM-Angriff. Der MITM ist in diesem Fall ein Trojaner, der auf dem Kundenrechner läuft. Wenn der Kunde Online-Banking machen möchte, meldet er sich zunächst mit Login und PIN auf der Webseite der Bank an. Der Trojaner ist solange inaktiv, bis der Benutzer eine Überweisung eingeben möchte und auf den Link des entsprechenden Online-Formulars klickt. Dann gibt der Kunde die Überweisungsdaten in die Maske ein. Wenn er das Formular aber absendet, speichert der Trojaner die Daten des Kunden und ändert diese im Hintergrund so um, dass z. B. ein höherer Betrag auf das Konto des Angreifers übertragen wird. Diese manipulierte Überweisung wird an die Bank weitergeleitet. Die Bank fragt nach einer bestimmten indizierten TAN und schickt die Anfrage an den Kunden zurück. In dem Moment wird der Trojaner wieder aktiv: Er fängt die Anfrage der Bank ab, ändert diese wieder in die ursprüngliche vom Kunden erwartete Form. Der Kunde sieht eine Authentifizierungsaufforderung für den von ihm eingegebenen Auftrag. Er sucht die passende iTAN aus seiner Liste aus und gibt sie ein. Der Kunde glaubt, damit die auf dem Bildschirm angezeigte Überweisung zu unterschreiben. In Wirklichkeit aber unterschreibt er die vom Trojaner fingierte Überweisung. Die Bank erhält einen korrekt aussehenden Auftrag und führt diesen aus. Der Benutzer bemerkt die Manipulation erst auf dem Kontoauszug. Theoretisch könnte der MITM auch diese Anzeige manipulieren, solange sie online abgefragt wird. Der MITM kann an verschiedenen Stellen sitzen: Auf dem Rechner des Kunden. Das geht beispielsweise mit einem Trojaner (s. o.) oder einem schadhaften Browser-Plugin. Auf einer gefälschten Website, die so aussieht, als wäre sie von der Bank. Ein Link in einer Spam-E-Mail oder eine Nachricht in einem Instant-Messenging-Programm lotst den Kunden auf die falsche Seite. Gefälschte DNS-Daten, die zu einer eingegebenen URL eine falsche IP-Adresse liefern, kommen ebenfalls zum Einsatz. Das 17 2 Grundlagen kann durch Manipulation der Einstellungen am Rechner oder am DSL-Router des Kunden geschehen. 2.3.3 Replay-Angriff Bei einem Replay-Angriff belauscht ein Angreifer eine Kommunikation und sendet Teile davon erneut im Namen des ursprünglichen Senders. Gibt beispielsweise ein Kunde eine Überweisung in ein vor Replay-Angriffen ungeschütztes Online-Banking-System ein, so könnte ein Angreifer den Datenstrom zum Bankserver aufzeichnen und hinterher mehrmals erneut senden. Dadurch würden mehrere gleichartige Überweisungen ausgeführt, so dass vom Kundenkonto insgesamt ein Vielfaches des vom Kunden gewollten Betrags überwiesen wird. Replay-Angriffe lassen sich verhindern, indem in der Kommunikation Codes verwendet werden, die nur ein einziges Mal benutzt werden dürfen - sogenannte Nonces footnoteAus dem Englischen: Number used once. Nonces werden beispielsweise als Zufallszahlen generiert, von denen man ausgeht, dass sie sich mit genügend hoher Wahrscheinlichkeit nicht wiederholen werden. Sendet Alice eine Nonce und bekommt diese Nonce im Laufe der Kommunikation verknüpft mit einer Nachricht wieder, so kann Alice davon ausgehen, dass diese Nachricht erst nach dem Senden ihrer Nonce erstellt wurde und nicht aus vorausgegangenen Kommunikationen stammt. Replay-Angriffe lassen sich außerdem durch Zähler und Zeitstempel vermeiden, deren Einmaligkeit durch die konstante Erhöhung sichergestellt ist. 2.4 Rechtliche Situation bei betrügerischen Überweisungen Eine ausgeführte Überweisung lässt sich nicht mehr widerrufen oder durch die beteiligten Banken rückgängig machen.[BGB08, §676a] Möchte ein Kunde eine Rücküberweisung erhalten, so muss er sich direkt an den ursprünglichen Zahlungsempfänger wenden und sich mit ihm einigen. Speziell bei betrügerischen Überweisungen lassen sich aber die wirklichen Empfänger für den Kunden nur schwer ermitteln, vor allem, wenn die Betrüger im Ausland sind oder geschickte Geldwäsche betreiben. Üblicherweise läuft der Geldfluss über Mittelsmänner, die das Geld an das Finanzunternehmen Western Uni” on“ überweisen. Die Betrüger erhalten das Geld von Western Union gegen Vorlage einer zehnstelligen Geldüberweisungskontrollnummer bar ausgezahlt. Sie müssen sich dabei nicht ausweisen und bleiben so anonym [Bac05]. Entdeckt ein Kunde eine betrügerische Überweisung zu seinen Lasten, kann er den Betrug zur Anzeige bringen und hoffen, dass der Betrüger ausfindig gemacht wird. Durch die geschickte Geldwäsche ist es aber unwahrscheinlich, dass der Kunde auf diesem Wege sein Geld zurückbekommt. Oft wendet sich der Kunde daher an seine Bank. Banken 18 2.4 Rechtliche Situation bei betrügerischen Überweisungen ersetzen entstandene Schäden oft aus Kulanz. 1 Falls nicht, kann der Kunde seine Bank auf Schadenersatz verklagen. Nach einem Urteil des Landgerichts Köln werden dem Kunden beim Online-Banking folgende Sorgfaltspflichten auferlegt: Für den konkreten Fall des Online-Bankings kann man von einem verständigen, tech” nisch durchschnittlich begabten Anwender fordern, dass er eine aktuelle Virenschutzsoftware und eine Firewall verwendet und regelmäßig Sicherheitsupdates für sein Betriebssystem und die verwendete Software einspielt. Ebenso muss ein Kontoinhaber die Warnungen der Banken beachten, PIN und TAN niemals auf telefonische Anforderung oder Anforderung per E-Mail herauszugeben. Außerdem wird man von ihm erwarten können, dass er deutliche Hinweise auf gefälschte E-Mails und Internetseiten seiner Bank erkennt (sprachliche Mängel, deutlich falsche Internet-Adresse, Adresse ohne https://, kein Schlüsselsymbol in der Statusleiste). Weitergehende Sicherheitsmaßnahmen wie etwa die Verwendung bestimmter, besonders leistungsfähiger Virenschutzprogramme oder spezialisierter Programme zum Schutz gegen bestimmte Schadsoftware, die Veränderung der Standard-Sicherheitseinstellungen von Betriebssystem und Programmen, das Arbeiten ohne Administratorrechte, die ständige Überprüfung der Zertifikate oder auch das Erkennen subtiler Abweichungen in der Internetadresse, würden die Sorgfaltsanforderungen dagegen überspannen.“[Lan07, Absatz 47] Laut einem noch nicht rechtskräftigen Urteil des Amtsgerichts Wiesloch haften Banken für Schäden durch Phishing auch dann, wenn der betrogene Kunde als einzige Sicherheitsmaßname lediglich eine aktuelle Virenschutzsoftware installiert hat. Im angegebenen Fall befanden sich trotz der installierten Virenschutzsoftware 14 schadhafte Programme auf dem Kundenrechner, unter ihnen ein Keylogger2 , der den Phishing-Angriff ermöglichte.[Spi08] Es ist unerheblich, wer letztendlich für den entstandenen Schaden aufkommt. Die Betrüger lassen sich meist nicht ermitteln, so dass am Ende oft ein Geschädigter übrig bleibt. Ob das nun der Kunde, die Bank oder eine Versicherung ist, ist egal. Daher darf es erst gar nicht zum Betrug kommen können. Technische Mittel, wie sichere Transaktionsverfahren, sind hierfür ein wesentlicher Bestandteil. 1 2 nach Aussage von Detlev Mergemeier, GAD Keylogger sind versteckte Programme, die Tastatureingaben aufzeichnen und über das Internet versenden können. 19 2 Grundlagen 20 3 Systematik des Vergleichs Die Beschreibung eines Verfahrens dient als Grundlage für die anschließenden Analyse und die Diskussion der resultierenden Sicherheit. Um die Beschreibungen systematisch zu halten, ist ihre Struktur immer gleich. Zunächst wird das Verfahren grob skizziert. Dabei wird darauf eingeganen, was die hauptsächliche Motivation für dieses Verfahren ist. Dann folgt eine Beschreibung des Besitzmerkmals und seiner Eigenschaften. Dann wird der Ablauf des Verfahrens detailliert in Bild und Schrift beschrieben. Dabei werden die Kommunikationsschritte und eventuell stattfindende Prüfungen in ihrer Reihenfolge genannt. Anwender und Banken haben die Möglichkeit, sich für ein Online-Banking-Verfahren zu entscheiden. Die Banken haben dabei die direkte Entscheidungsgewalt. Die Anwender können zwischen den von den Banken angebotenen Verfahren wählen und ihre Entscheidung für eine bestimmte Bank auch von den angebotenen Online-Banking-Verfahren abhängig machen. Ein systematischer Vergleich der Verfahren bietet eine Grundlage für eine Entscheidung. Dieses Kapitel beschreibt, wie ein solcher Vergleich durchgeführt werden kann. Dazu werden eine Kategorisierung sowie Beurteilungskriterien aus den Bereichen Sicherheit, Benutzerfreundlichkeit und Kosten vorgestellt. 3.1 Kategorisierung Zur Analyse der Sicherheit und zur Klassifikation der Verfahren wird folgende Systematik verwendet: Die Verfahren werden hinsichtlich der Schnittstellen der in ihnen verwendeten Geräte geordnet. Prinzipiell kann ein Gerät über seine Schnittstellen Informationen direkt mit dem Anwender oder mit seinem Computer austauschen. Informationen können sowohl vom Gerät weg als auch in das Gerät hinein fließen, so dass sich vier mögliche Schnittstellen ergeben. Die meisten verwendeten sicheren Geräte besitzen weniger als vier Schnittstellen. Im Fall der klassischen TAN-Liste beispielsweise fließen Informationen nur von der Liste zum Anwender. Insgesamt sind 2 hoch 4 = 16 Fälle denkbar. Abbildung 3.1 zeigt durch die vier Pfeile die möglichen Schnittstellen. Jedes Online-Banking-Verfahren verwendet ein bestimmtes physikalisches Authentifikationsmerkmal. Jedes dieser Geräte hat leicht zu identifizierende Schnittstellen, so dass sich die Geräte und mit ihnen die Verfahren klassifizieren lassen. Nicht alle der 16 möglichen Klassen existieren tatsächlich. Alle Klassen, die keine vom Gerät ausgehenden Schnittstellen besitzen, können keine Information nach außen und damit keine Authentifizierungsmöglichkeit liefern. Die in dieser Arbeit vorgestellten Verfahren belegen sechs 21 3 Systematik des Vergleichs Abbildung 3.1: Vier mögliche Schnittstellen des Geräts 22 3.2 Sicherheit verschiedene Klassen. A“ bedeutet Anwender, G“ Gegenstand und C“ Computer. Die ” ” ” Klassennamen enthalten an erster Stelle die Art der Verbindung zwischen Anwender und Gerät, an zweiter Stelle die zwischen Gerät und Computer. Eingehend“ und Ausge” ” hend“ beziehen sich immer auf das Gerät, Bidirektional“ bezeichnet Verbindungen in ” beide Richtung und Keine“ deutet auf fehlende Verbindung hin. ” 1. Ausgehend - Keine A ← G C: Vom Gegenstand zum Anwender 2. Bidirektional - Keine A ↔ G Gegenstand zum Anwender C: Vom Anwender zum Gegenstand und vom 3. Ausgehend - Eingehend A ← G ← C: Vom Computer zum Gegenstand und vom Gegenstand zum Anwender 4. Bidirektional - Bidiretional A ↔ G ↔ C: Vom Anwender zum Gegenstand und vom Gegenstand zum Anwender und vom Computer zum Gegenstand und vom Gegenstand zum Computer 5. Keine - Bidirektional A Gegenstand zum Computer G ↔ C: Vom Computer zum Gegenstand und vom 6. Eingehend - Bidirektional A → G ↔ C: Vom Anwender zum Gegenstand und vom Computer zum Gegenstand und vom Gegenstand zum Computer 3.2 Sicherheit Die Beurteilung der Sicherheit von Informationssystemen lässt sich auf verschiedene Weisen durchführen. Im Wesentlichen gibt es zwei Herangehensweisen: eine theoretische, formale und eine praktische, experimentelle. 3.2.1 Praktische Sicherheitsanalyse Die praktis che Sicherheitsanalyse untersucht, ob ein System vor bekannten Angriffsarten sicher ist oder nicht. Dabei untersucht man ein gegebenes Verfahren auf generell bekannte Schwachstellen und Angriffe. Findet man einen Angriff, so ist das Verfahren unsicher. Findet sich kein Angriff, so kann man nur im Rahmen von gewissen Annahmen begründen, warum bekannte Angriffe ausgeschlossen sind. Ein Beweis der Sicherheit lässt sich ohne formale Methoden praktisch nicht führen. 3.2.2 Formale Sicherheitsanalyse Nachdem nun dargestellt wurde, wie sich die Sicherheit von Legitimationsverfahren hinsichtlich bekannter Angriffsarten praktisch testen lässt, wird in diesem Abschnitt 23 3 Systematik des Vergleichs eine theoretische, formale Sicherheitsanalyse vorgestellt. Man kann die Kommunikationsabläufe eines Verfahrens auch als eine Art Computerprogramm darstellen. Man beschreibt so formal, was jeder am Verfahren Beteiligte tut, also insbesondere, welche Nachrichten er schickt, auf welche Nachrichten er wartet und welche Information er wie prüft oder verarbeitet. Außerdem spezifiziert man ein Sicherheitsziel. Dann steckt man dieses Programm, diese Spezifikation in ein Tool, das das Verfahren dann durchspielt. Dabei werden alle möglichen Zustände durchgespielt, die im Rahmen der Spezifikation erreichbar sind, und es wird geprüft, ob das Sicherheitsziel verletzt wird. Findet das Tool eine Sicherheitsverletzung, so gibt es den Kommunikationsablauf aus, der zu der Verletzung führt. Wenn die Anzahl der Zustände hinreichend klein für die Analyse ist, so können alle Zustände geprüft werden. Findet sich dann keine Sicherheitsverletzung, so ist das Verfahren innerhalb der Spezifikation sicher. Wie auch bei der praktischen Analyse wird hier davon ausgegangen, dass die kryptographischen Methoden sicher sind. Der Vorteil der automatischen Analyse besteht darin, systematisch alle Möglichkeiten durchzuprobieren. So können auch bislang unbekannte Angriffe entdeckt werden. Für eine begrenzte Anzahl an parallel laufenden Sitzungen und eine endliche Anzahl an möglichen Protokollschritten pro Sitzung ist die Frage nach der Sicherheit bzw. nach einem möglichen Angriff entscheidbar - wenn auch NP-vollständig [RT03]. Diese Analysemethode hat allerdings auch einige Nachteile und Schwächen. Zunächst muss das Verfahren in einer Spezifikationssprache (HLPSL) beschrieben werden. Das ist nicht trivial. Dieser Prozess ähnelt dem Programmieren, und ähnlich wie bei diesem sind auch hier Programmierfehler möglich. Die Ergebnisse der Sicherheitsanalyse könnten hierdurch verfälscht werden. Die eingesetzte Beschreibungssprache kann nicht alle Sachverhalte und Elemente der untersuchten Online-Banking-Protokolle ohne Umwege modellieren. Insbesondere Zeitstempel, Zählerstände, TAN-Listen und sichere Kommunikationskanäle zwischen Anwender und Token können nicht direkt modelliert werden. Aus diesen Gründen wird in dieser Arbeit weitgehend darauf verzichtet, die Verfahren formal zu analysieren, die bereits bei der praktischen Analyse erhebliche Sicherheitsschwächen zeigen. Für die formale Analyse der Online-Banking-Verfahren wurde das AVISPA Tool benutzt. Die Funktionsweise und Bedienung kann [AVI06] entnommen werden. Die Spezifikation gliedert sich grob in die Teile: Beschreibung der Kommunikationspartner (roles genannt), Zusammensetzen der Kommunikationspartner zu Protokollsitzungen (sessions), Spezifikation des Wissens und Könnens des Angreifers (intruder knowledge) und Spezifikation des Sicherheitsziels (goal ). Für die Modellierung der Legitimationsverfahren ergeben sich einige konkrete Parameter. Die relevanten Kommunikationspartner sind hier Anwender, Bank und sicherheitsrelevante Gegenstände. Eine einzelne Protokollsitzung besteht aus je einem Anwender, einer Bank und einem Gegenstand. Untersucht werden immer mehrere parallel stattfindende Sitzungen zusammen, denn oft ergeben sich bei kryptographischen Protokollen gerade aus der parallelen Ausführung Sicherheitsprobleme (zu sehen beispielsweise bei der Analyse des mobilen TAN-Verfahrens, 4.3.1). Konkret sind das folgende Sitzungen: 24 3.3 Kosten Zwei Sitzungen mit gleichem Anwender A1, gleichem Gerät G1 und gleicher Bank B1, eine Sitzung mit A1, G1 und einer anderen Bank B2, und eine Sitzung, in der der Angreifer Ai auch Kunde von Bank B1 ist und sein eigenes Gerät Gi nutzt. Das Sicherheitsziel ist in unserem Fall immer das gleiche: Die Bank soll den Kunden und dessen Transaktionsdaten authentisieren. 3.3 Kosten Bezüglich der Kosten werden nur die Punkte aufgeführt, die direkt von der Anzahl der Nutzer und der Anzahl der Transaktionen abhängen. Als Beispiel seien hierzu die Kosten für die Postzustellung einer TAN-Liste oder für das Versenden einer SMS genannt. Die Betrachtung ist aber unabhängig davon, ob die Bank oder der Benutzer für die Kosten aufkommt. Nicht betrachtet wird dagegen den Aufwand für die Umstellung von einem System auf ein anderes auf Seiten der Bank, da davon ausgegangen werden kann, dass der Einsatz eines Verfahrens nicht von diesem Aspekt abhängig ist. Außerdem betrachte ich nicht die Betriebskosten für die Infrastruktur der Bank, sondern setze vielmehr voraus, dass sich die Verfahren in diesem Punkt nur unwesentlich voneinander unterscheiden. Um Anschaffungskosten und laufende Kosten besser gegenüberstellen zu können, wird davon ausgegangen, dass ein Anwender im Schnitt 50 Transaktionen pro Jahr durchführt. Diese Anzahl ergibt sich aus den Statistiken der Deutschen Bundesbank [Deu08], wobei angenommen wird, dass die meisten Transaktionen Überweisungen sind. Die Banken geben für die Lebensdauer verschiedener TAN-Generatoren eine Dauer etwa fünf Jahren an (beispielsweise TAN-Generator der BW-Bank [Bad07]). Daraus ergeben sich eine Gesamtzahl von 250 Transaktionen pro Gerät. 3.4 Benutzerfreundlichkeit Die Benutzerfreundlichkeit eines Systems bezeichnet, wie leicht ein Anwender das System benutzen kann. Wichtig ist die Betrachtung der Benutzerfreundlichkeit, weil Anwender nur benutzerfreundliche Systeme auf Dauer akzeptieren. Eine Überforderung des Benutzers kann dazu führen, dass der Benutzer Fehler macht, Zeit verschwendet, sein Ziel nicht erreicht, frustriert wird und möglicherweise das System zukünftig nicht mehr nutzt. Bankkunden benutzen ein spezielles Online-Banking-System freiwillig. Falls sie damit unzufrieden sind, können sie die Bank (und damit das Online-Banking-System) wechseln oder auf das Online-Banking an sich verzichten. Daher müssen Online-Banking-Systeme eine ausreichende Benutzerfreundlichkeit garantieren. Was in diesem Zusammenhang ausreichend“ bedeutet, muss jede Bank selbst entscheiden. ” Da die vorgestellten Online-Banking-Verfahren einen Einfluss auf die Benutzerfreundlichkeit des gesamten Online-Banking-Systems haben und da sich die Benutzerfreund- 25 3 Systematik des Vergleichs lichkeit der Verfahren unterscheiden, wird die Benutzerfreundlichkeit analysiert. Dabei werden nur die Elemente betrachtet, die die Verfahren direkt ausmachen: das Authentifizierungsmerkmal Besitzt“ und den Protokollablauf. Die Gestaltung der Websiten oder ” der benutzten Computersoftware geht nicht in die Betrachtung ein. Um die Legitimationsverfahren vergleichen zu können, werden die Verfahren zunächst beschrieben und anschließend hinsichtlich relevanter Merkmale analysiert. Dieses Kapitel stellt eine Methodik vor, mit der sich Legitimationsverfahren beschreiben und analysieren lassen. Die Methodik wird durch einen Vorgriff auf das nächste Kapitel am Beispiel eines momentan häufig eingesetzten Verfahrens - des sogenannten indizierten TAN-Verfahrens - erläutert. Zur Bewertung der Benutzerfreundlichkeit stehen zwei Arten von Ansätzen zur Verfügung, nämlich eine empirische und eine analytische. Bei den empirischen Verfahren lässt man Anwender das zu bewertende System testen. Dabei beobachtet oder befragt man sie. Diese Verfahren haben den Vorteil, dass sie realistische und überzeugende Ergebnisse liefern. Der Nachteil besteht in ihrem hohen personellen und zeitlichen Aufwand. Die analytischen Verfahren kommen ohne eine große Anwenderschar aus. Hier evaluieren Experten die Benutzerfreundlichkeit, indem sie das System in überschaubare Teile zerlegen und Teilaspekte einzeln betrachten. Der Vorteil ist hier die leichte, ressourcenschonende Durchführung. Nachteilig ist, dass durch Betriebsblindheit eventuell wichtige Teilaspekte übersehen werden könnten. In dieser Arbeit habe ich mich wegen des geringeren Aufwandes für den analytischen Ansatz entschieden. Es geht hier nicht darum, die Benutzerfreundlichkeit möglichst exakt absolut darzustellen, es reicht eine grobe, relative Unterscheidungsmöglichkeit zu liefern. Im Fokus der Bewertung soll das Charakteristische eines Verfahrens liegen. Elemente, die für alle Verfahren annähernd gleich oder unabhängig von den Verfahren sind, sollen nicht in die Bewertung einfließen. Insbesondere sind dies die Ergonomie der für das Online-Banking benutzten Computer, Monitore und Tastaturen und die Dialogführung der Online-Banking-Programme. Diese Aspekte sind zwar wichtig für die Gesamtbeurteilung der Ergonomie eines bestimmten Systems, aber wegen der mangelnden Differenzierungsfähigkeit zwischen den Verfahren nicht Gegenstand dieser Arbeit. Zur umfassenden Beurteilung steht vor allem die Norm DIN EN ISO 9241 Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten mit ihren zahlreichen Teilen zur Verfügung. Die charakteristischen Elemente eines Legitimationsverfahrens sind im Rahmen dieser Arbeit zum einen der signaturrelevante Kommunikationsablauf, sowie die Ergonomie des verwendeten, sicherheitsrelevanten Gegenstandes. Cakir schlägt eine Reihe von Kriterien vor, anhand derer sich die Ergonomie physischer Eingabegeräte messen lässt [CCS04, Seite 122 ff]. Unter anderem sind dies movement time und task primitive, also die Bewegungszeit und die Elementaroperationen. Diese Kriterien sind leicht messbar und sollen im folgenden zur Beurteilung der Ergonomie der sicherheitsrelevanten Gegenstände benutzt werden. Eine pragmatische Möglichkeit, die Qualitätsmerkmale der Dimension Durchführung zu messen, ist das Keystroke-Level-Modell (KLM) von Card[CMN83, Seite 259 ff]. Die- 26 3.4 Benutzerfreundlichkeit ses Modell eignet sich für die Messung der Ergonomie sowohl des sicherheitsrelevanten Kommunikationsablaufs als auch des sicherheitsrelevanten Gegenstandes. Hierbei wird die Zeit geschätzt, die ein geübter Benutzer benötigt, um einen fehlerfreien Vorgang durchzuführen. Dafür zerlegt man den Vorgang in elementare Schritte mit bekanntem Zeitbedarf und summiert am Ende die einzelnen Zeiten auf. Je weniger Zeit ein Benutzer braucht desto besser. Das KLM ist zwar einfach und grob, beschreibt aber die Ausführungszeit zufriedenstellend genau. Die elementaren Schritte decken sowohl die operative Ebene als auch die der Ein- und Ausgabe ab. Card nennt folgende Elementaroperationen mit experimentell ermittelten, typischen Zeiten: Schritt : Zeitbedarf in Sekunden Tasten- oder Knopfdruck : 0,08 - 1,2 Zeigen auf Ziel mit Maus : 1,1 Handbewegung bei Wechsel des Eingabegeräts : 0,4 Mentale Vorbereitung : 1,35 Antwortzeit des Systems : ? Die Antwortzeit ist systemabhängig und nicht näher beschrieben. Eigene Messungen (20facher Aufruf des Online-Banking-Startseite der Dresdner Bank) ergaben eine durchschnittliche Antwortzeit von 2 Sekunden, die hier zugrundegelegt wird. Geübte Benutzer benötigen für das Drücken der Maustaste wenig Zeit, weshalb an dieser Stelle dafür 0,1 Sekunden angenommen werden. Ein Vorgang bestehend aus Zeigen und Klicken benötigt somit 1,2 Sekunden. Für das Tippen auf der Tastatur des Computers oder eines externen Gerätes wird pauschal ein mittlerer Wert von 0,5 Sekunden angenommen. Die mentale Vorbereitung umfasst Schritte, bei denen der Anwender etwas lesen, vergleichen oder prüfen muss. Auf eine Nachkommastelle gerundet ergibt sich hierfür pauschal ein Wert von 1,4 Sekunden. Die Elementaroperationen des KLM sind nicht für alle Verfahren ausreichend. Insbesondere spezielle Manipulationen am Gerät - wie zum Beispiel Einstecken einer Chipkarte in einen Chipkartenleser - fehlen und werden im Einzelfall geschätzt. Außerdem soll nur der Zeitbedarf ermittelt werden, der ausschließlich der Authentifizierung dient. Es wird angenommen, dass die Eingabe der reinen Transaktionsdaten für alle Verfahren gleich lange dauert. Daher wird diese Zeit nicht berücksichtigt. Weiter wird angenommen, dass die Antwortzeiten der Online-Banking-Systeme gleich sind, und dass die Qualität der Menüführung bei allen Systemen so ähnlich ist, dass sich daraus keine zeitlichen Unterschiede bei der Benutzung ergeben. Auch die Bestätigungsantwort für die erfolgreiche Eingabe einer Transaktion wird nicht berücksichtigt. Die Verfahren werden somit bezüglich ihrer Durchführungsqualität anhand folgender Einzeloperationen gemessen: Schritt : Abkürzung : Zeitbedarf in Sekunden 27 3 Systematik des Vergleichs Tastendruck : T : 0,5 Ziehen und Klicken mit Maus : K : 1,2 Wechsel des Eingabegeräts : W : 0,4 Mentale Vorbereitung : M : 1,4 Antwortzeit des Systems : A : 2 Manipulation des Gerätes : G : abhängig vom Einzelfall Die Analyse sei kurz am Beispiel des klassischen TAN-Verfahrens erklärt: 1. Ablauf (nach Eingabe der Transaktionsdaten) angeben: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), zur TAN-Liste wechseln (W), TAN aussuchen (M), TAN durchstreichen (G = 3 Sekunden), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T bei sechstelliger TAN), OK klicken (K). 2. Zeitbedarf Z berechnen: Z = 6T + 2K + 2W + 3M + A + G = 15,4 Sekunden Im Rahmen dieser Arbeit wird angenommen, dass der Zeitbedarf für die Durchführung eines Verfahrens durch einen geübten Benutzer stark korreliert mit dem Aufwand für einen ungeübten Benutzer, die korrekte Bedienung des Verfahrens zu erlernen. Deshalb wird hierfür kein neues Beurteilungskriterium eingeführt. Außerdem wird angenommen, dass komplizierte, benutzerunfreundliche Verfahren einen höheren Zeitwert als einfacher zu bedienenden Verfahren aufweisen. Neben der benötigten Ausführungzeit unterscheiden sich die Verfahren noch hinsichtlich der Möglichkeit, sie auch außerhalb des Anwendercomputers nutzen zu können. Vorteilhaft für den Benutzer ist, wenn er auch an fremden Rechnern - beispielsweise im Internetcafé - sicheres Online-Banking betreiben kann. Daher wird in die Betrauchtung der Benutzerfreundlichkeit auch dieser Aspekt berücksichtigt. 28 4 Legitimationsverfahren Heutzutage verlässt man sich beim Online-Banking nicht mehr nur auf die einmalige Eingabe einer PIN zu Beginn einer Sitzung. Vorgänge, die einen Geldabfluss vom Kundenkonto zur Folge haben oder sicherheitstechnisch kritisch sind verlangen zur Ausführung eine separate Bestätigung. Diese Bestätigung kommt der eigenhändigen Unterschrift bei papierhaften Bankgeschäften gleich. Die Funktion der Unterschrift wird auf elektronischem Wege mit zwei verschiedenen Ansätzen realisiert. Zum einen gibt es jene Verfahren, die auf Transaktionsnummern (TANs) beruhen. Diese TANs bestehen üblicherweise aus sechs Ziffern. Eine OnlineTransaktion wird hier durch die zusätzliche Eingabe einer TAN unterschrieben“. Neben ” den TAN-Verfahren gibt es jene andere Verfahren, die auf einer elektronischen Signatur beruhen. Hierbei wird dem zu unterschreibenden Text mit Hilfe von kryptographischen Methoden eine Zusatzinformation angefügt, die einer realen Unterschrift gleichkommt. Insbesondere kann die Unterschrift von der Bank leicht überprüft und nur durch den Kunden erzeugt werden. Außerdem bezieht sich diese elektronische Unterschrift genau auf den angegebenen Text, so dass nach einer Veränderung der Transaktion die Unterschrift nicht mehr zu dem Text passt und Manipulationen so erkannt werden können. Im Folgenden werden zunächst die Verfahren erklärt, die auf Transaktionsnummern beruhen. Anschließend folgen die auf elektronischen Signaturen beruhenden Verfahren. Unter den TAN-basierten Verfahren finden sich die einfachsten und ältesten Verfahren zum Unterschreiben von Transaktionen beim Online-Banking. Für jede Transaktion ist die Eingabe einer neuen TAN erforderlich, so dass eine TAN nur ein einziges Mal benutzt werden kann. Das bekannteste ist wohl das herkömmliche PIN/TAN-Verfahren. Hier verwendet der Benutzer seine PIN, um sich einmalig zu Beginn einer Sitzung beim Online-Banking-System anzumelden. Möchte er dann eine Transaktion ausführen, so gibt er zusätzlich zu den Transaktionsdaten eine unverbrauchte TAN ein. Diese TANs erfüllen den Zweck eines Einmalpasswortes und sind im einfachsten Fall als Papierliste gegeben. Wie sich in Theorie und Praxis herausstellte, sind die einfacheren Verfahren oft unsicher, so dass immer neue TAN-Verfahren und Varianten entstanden. Die Sicherheit der TAN-basierten Verfahren beruht darauf, dass nur Befugte gültige TANs eingeben können. Die TANs sollten daher nicht erraten, vorhergesagt oder leicht entwendet werden können. Viele Banken benutzen zufällige TANs mit einer Länge von sechs Stellen. Will man solch eine TAN erraten, so hat man nur in einem von möglichen 1.000.000 Fällen Erfolg. Diese Wahrscheinlichkeit gilt als klein genug, um ausreichende Sicherheit zu gewährleisten. Wenn aber vom Online-Banking-System nicht eine bestimmte TAN erwartet wird, sondern eine beliebige Transaktionsnummer aus einer Liste einge- 29 4 Legitimationsverfahren geben werden kann, steigt die Wahrscheinlichkeit für erfolgreiches Erraten entsprechend. Kann man beispielsweise aus 100 gültigen TANs eine beliebige aussuchen, beträgt die Erfolgswahrscheinlichkeit für das Raten eins zu 10.000. In der Regel erlaubt ein OnlineBanking-System mehrere falsche Eingaben, bis der Zugang oder eine TAN-Liste gesperrt werden. Die Erfolgswahrscheinlichkeit erhöht sich ebenfalls multiplikativ mit der Anzahl der zulässigen Versuche. Wird eine sechstellige TAN von einer Liste mit 100 gültigen TANs verlangt, und hat man 5 Versuche, eine korrekte TAN einzugeben, beträgt die Erfolgswahrscheinlichkeit für das Raten - man probiert bei jedem Versuch eine andere TAN aus - fünf zu 10.000 oder 0,05%. Im Jahr 2006 betrug die durchschnittliche Höhe von betrügerischen Online-Überweisungen knapp 5000 ¿. Bei einem Legitimationsverfahren, das eine Erfolgswahrscheinlichkeit von 0,05% für das Erraten von TANs hat, könnte ein Betrüger pro Online-Banking-Account im Schnitt 2,50 ergaunern. 4.1 Schnittstellenklasse Ausgehend - Keine“ ” 4.1.1 Klassische TAN Das klassische TAN-Verfahren nutzt eine Liste mit Transaktionsnummern. Diese Liste ist üblicherweise auf Papier gedruckt und enthält etwa hundert TANs. Der Kunde erhält die Liste per Post als Brief zugeschickt. Sobald der Kunde eine Online-Transaktion ausführen möchte, wird er vom Online-Banking-System aufgefordert, eine beliebige, unverbrauchte TAN anzugeben. Der Kunde schaut auf seine TAN-Liste, wählt eine unbenutzte TAN aus, gibt sie ins System ein und streicht sie auf der TAN-Liste durch. Die Bank besitzt eine elektronisch gespeicherte Kopie der TAN-Liste und kann die eingegebene TAN auf ihre Gültigkeit überprüfen. Nur wenn die eingegebene TAN auf der Liste zu finden ist und noch nicht benutzt wurde wird die Transaktion durchgeführt. Das System benachrichtigt den Kunden über den Erfolg bzw. den Misserfolg der eingegebenen Transaktion. Die Idee hinter den Transaktionsnummern ist die, dass ein Unbefugter nicht alleine mit Kenntnis der PIN eines Kunden in dessen Namen Transaktionen ausführen kann. Abbildung 4.2 verdeutlicht den Ablauf: 1. Der Kunde wählt eine unbenutzte TAN von seiner TAN-Liste aus und streicht sie dort durch. 2. Der Kunde gibt die Transaktionsdaten und die gewählte TAN in den Computer ein. 3. Der Computer schickt die Transaktionsdaten zusammen mit der TAN zum Server der Bank. 4. Der Bankserver überprüft die Gültigkeit der TAN und führt die Transaktion gegebenenfalls aus. 30 4.1 Schnittstellenklasse Ausgehend - Keine“ ” Abbildung 4.1: TAN-Liste der Citibank; Quelle: [hei06] Abbildung 4.2: Ablauf des klassischen TAN-Verfahrens 31 4 Legitimationsverfahren Die Abkürzungen in den weiteren Ablaufgrafiken haben die folgende Bedeutung: Nummerierung: Reihenfolge der Kommunikationsschritte T: Transaktionsdaten TAN: Transaktionsnummer N: Zahl, die nur einmal verwendet werden darf (Nonce, Index einer TAN) TAN(x): Transaktionsnummer, die unter anderem abhängig ist von x {x}: Daten x, die signiert oder verschlüselt wurden PIN: PIN-Code Keypad(x): Eine Permutation der Ziffern 0 bis 9, angezeigt als Zifferntastatur und abhängig unter anderem von x Am Ende der Kommunikation führt die Bank stets eine Gültigkeitsüberprüfung für die eingereichte Transaktion aus. Dieser letzte Schritt ist in den Kommunikationsablaufdiagrammen nicht dargestellt. Zwar bestätigen die Bankserver normalerweise den korrekten Eingang einer Transaktion, aber der Kunde hat in keinem der hier dargestellten Verfahren die Möglichkeit, die Authentizität und Integrität dieser letzten Bestätigungsmeldung sicher zu überprüfen. Eine sichere Bestätigungsmeldung könnte auch keinen Betrug verhindern, sondern nur helfen, ihn nachträglich leichter zu entdecken. Sinn und Zweck der Legitimationsverfahren ist es aber, im Vornherein schon keine betrügerischen Transaktionen zuzulassen. Analyse der Sicherheit Für das klassische TAN-Verfahren sind mehrere Schwachstellen und wirksame Angriffe bekannt. Es ist für einen Angreifer möglich, durch Phishing an Zugangsdaten und TANs eines Kunden zu gelangen und damit beliebige Transaktionen in seinem Namen durchzuführen. Weiter ist es durch einen MITM-Angriff möglich, Transaktionen eines Kunden zu manipulieren. Außerdem kam es bei mindestens einer Bank infolge schlechter Implementierung der TAN-Erzeugung zu einer geringen Zufälligkeit und damit guten Vorhersagbarkeit unbenutzter TANs.[hei06] So konnte man mit Hilfe von einigen verbrauchten TANs mit hoher Wahrscheinlichkeit neue, gültige TANs berechnen. Bei einem kompromittierten Rechner bietet das klassiche TAN-Verfahren also keinen wirksamen Schutz vor Betrug. 32 4.1 Schnittstellenklasse Ausgehend - Keine“ ” Analyse der Benutzerfreundlichkeit Das Verfahren ist mobil einsetzbar. Neben dem Computer wird als einziger Gegenstand die TAN-Liste benötigt, die problemlos überall hin mitgenommen werden kann. Die KLM-Schritte für das Verfahren sind: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), zur TAN-Liste wechseln (W), TAN aussuchen (M), TAN durchstreichen (G = 3 Sekunden), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T bei sechstelliger TAN), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 2K + 2W + 3M + A + G = 15,4 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Beim klassischen TAN-Verfahren entstehen transaktionsbezogene Kosten nur durch den Druck und den Versandt der TAN-Listen. Nimmt man für Porto und Druck Kosten von zusammen 60 Cent an, so ergeben sich bei einer TAN-Liste mit 100 TANs Kosten von 0,6 Cent pro Transaktion. 4.1.2 Elektronische TAN Die elektronische TAN (eTAN) ist ein Verfahren, bei dem die Transaktionsnummern in elektronischer Form gespeichert sind und auf einem kleinen, mobilen Gerät angezeigt werden können. Durch einen Knopfdruck wird eine gültige TAN generiert und auf einem Display angezeigt. Der Ablauf zur Ausführung einer Transaktion ist analog zum klassischen TAN-Verfahren. Es gibt mehrere Varianten der eTAN. Bei den Volksbanken kommt noch bis zum Jahr 2009 der sm@rtTAN-Generator zum Einsatz. Abbildung 4.3: sm@rtTAN-Generator mit eingesteckter Bankkarte; Quelle: ReinerSCT Der in Abbildung 4.3 gezeigte sm@rtTAN-Generator arbeitet zusammen mit der Bankkarte des Kunden. Zum Betrieb muss zunächst die Bankkarte des Kunden in den Ge- 33 4 Legitimationsverfahren nerator gesteckt werden. Der Generator schaltet sich hierdurch automatisch ein. Auf Knopfdruck wird die nächste, gültige TAN angezeigt. Die TANs werden auf dem Chip der Karte erzeugt und können mit dem Generator lediglich ausgegeben werden. Somit ist der Generator selbst kein sicherheitskritisches Gerät und kann für alle Kunden in identischer Bauweise ausgegeben werden. Die Reihenfolge der TANs spielt bei diesem Verfahren eine Rolle: Wenn eine gültige TAN im Online-Banking-System verwendet wurde, werden mit ihr auch alle vorher erzeugten TANs ungültig - auch, wenn die vorher erzeugten TANs eventuell noch nicht verwendet wurden. Vermutet also ein Kunde, dass er Opfer eines Phishing-Angriffes geworden ist, kann er mit der erfolgreichen Durchführung einer TAN-pflichtigen Transaktion mit einer frisch generierten TAN die entwendeten TANs ungültig machen.[Gem07] Abbildung 4.4 beschreibt den Abflauf des sm@rtTAN-Verfahrens. Abbildung 4.4: Ablauf des sm@rtTAN-Verfahrens 1. Der Kunde steckt seine Bankkarte in den sm@rtTAN-Generator und erzeugt auf Knopfdruck eine TAN. 2. Der Kunde gibt die Transaktionsdaten und die TAN in den Computer ein. 3. Der Computer schickt die Transaktionsdaten zusammen mit der TAN zum Server der Bank. 4. Der Bankserver überprüft die Gültigkeit der TAN und führt die Transaktion gegebenenfalls aus. Ein anderer Generator ist der sogenannte Bankey, den beispielsweise die Volkswagenbank verwendet (siehe Abbildung 4.5). Der Bankey erzeugt die TANs direkt im Gerät. Durch eine eingebaute Uhr hängen die TANs von der aktuellen Zeit ab und haben dadurch eine zeitlich begrenzte Gültigkeit. Der Ablauf des Verfahrens ist analog zum sm@rtTAN-Verfahren. 34 4.1 Schnittstellenklasse Ausgehend - Keine“ ” Abbildung 4.5: TAN-Generator Bankey“; Quelle: www.modern-banking.de ” Analyse der Sicherheit Das eTAN-Verfahren erschwert gegenüber dem klassischen TAN-Verfahren PhishingAngriffe geringfügig. Im Gegensatz zur klassischen TAN verliert eine elektronische TAN nämlich ihre Gültigkeit, nachdem der legitime Benutzer eine neue Transaktion ausführt (gilt für die sm@rtTAN) oder nachdem eine bestimmte Zeit abgelaufen ist (gilt für den Bankey). Ein Phishing-Angriff ist aber immer noch möglich, wenn der Angreifer die entwendeten eTANs sofort für einen Betrug verwendet. Das eTAN-Verfahren schützt ebenfalls nicht vor einem MITM-Angriff. Analyse der Benutzerfreundlichkeit Die Token zur Erzeugung der elektronischen TANs sind klein und problemlos zu transportieren. Somit eignet sich das elektronische TAN-Verfahren auch für den mobilen Einsatz. Die KLM-Schritte für das sm@rtTAN-Verfahren sind: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), zum TAN-Generator wechseln (W), Karte einstecken (G = 3 Sekunden), Knopf zur TAN-Erzeugung drücken (T), TAN merken (M), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T bei sechstelliger TAN), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 7T + 2K + 2W + 3M + A + G = 15,9 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Beim Verfahren mit dem Bankey entfällt das einstecken der Karte. Die Zeit verkürzt sich gegenüber dem sm@rtTAN-Verfahren entsprechend um drei Sekunden auf insgesamt 12,9 Sekunden. Analyse der Kosten Der sm@rtTAN-Generator kostet 5 ¿ [Vol08, Seite 31]. Zum Bankey habe ich keine Preise gefunden. Ich nehme an, dass der ebenfalls etwa 5 ¿ kostet. Unter den Annahmen aus 3.3 ergeben sich hiermit Kosten von 2 Cent pro Transaktion. Die Versandtkosten sind 35 4 Legitimationsverfahren bereits in diesen Preisen enthalten. 4.2 Schnittstellenklasse Bidirektional - Keine“ ” 4.2.1 Indizierte TAN Indizierte TANs (iTANs) werden ähnlich wie beim klassischen TAN-Verfahren auf eine Papierliste gedruckt. Die iTANs sind im Gegensatz zum TAN-Verfahren durchnummeriert. Zur Durchführung einer Transaktion kann nicht eine beliebige iTAN aus der Liste ausgewählt werden, sondern es muss eine bestimmte, von der Bank geforderte und durch die laufende Nummer gekennzeichnete iTAN eingegeben werden. Ähnlich wie beim klassischen TAN-Verfahren wird jede iTAN nur ein Mal benutzt und daher nach einer Eingabe vom Online-Banking-System nicht wieder abgefragt. Der genaue Ablauf ist in Abbildung 4.7 dargestellt. Abbildung 4.6: Beispiel einer iTAN-Liste; Quelle: Sparkasse Oder-Spree Abbildung 4.7: Ablauf des iTAN-Verfahrens 36 4.2 Schnittstellenklasse Bidirektional - Keine“ ” 1. Der Kunde gibt die Transaktionsdaten in den Rechner ein. 2. Der Rechner leitet die Transaktionsdaten an den Server der Bank weiter. 3. Die Bank schickt eine zufällige Positionsnummer zum Rechner des Kunden. 4. Die Positionsnummer wird dem Kunden auf dem Computerbildschirm angezeigt. 5. Der Kunde sucht auf seiner iTAN-Liste diese Positionsnummer und 6. erhält die nebenstehende iTAN. 7. Der Kunde gibt die zur geforderten Positionsnummer passende iTAN in seinen Rechner ein. 8. Der Rechner schickt die Transaktionsdaten und die iTAN an den Bankserver. 9. Der Bankserver überprüft die Gültigkeit der iTAN und führt die Transaktion gegebenenfalls aus. Eine weitere Variante des iTAN-Verfahrens ist das iTANplus-Verfahren, das von einigen Volks- und Raiffeisenbanken eingesetzt wird. Hierbei wird die von der Bank ausgewählte Positionsnummer in ein Captcha1 eingebettet, das die Transaktionsdetails sowie das Geburtsdatum des Kunden enthält.[hei07] Abbildung 4.8: Captcha beim iTANplus-Verfahren; Quelle: Fiducia IT AG Analyse der Sicherheit Das iTAN-Verfahren wurde als Verbesserung zum klassischen TAN-Verfahren eingeführt. Ein Phishing-Angriff wird stark erschwert, da für eine Transaktion immer eine bestimmte iTAN eingegeben werden muss. Hat ein Betrüger nur eine iTAN zur Verfügung, so ist die Wahrscheinlichkeit, dass die Bank bei der Durchführung einer betrügerischen Transaktion nach genau dieser iTAN fragt eins zur Anzahl der iTANs in der Liste, also etwa 1 : 100 bis 1 : 200. Es gibt allerdings Phishing-Angriffe, bei denen Kunden bereit waren, ihre gesamte iTAN-Liste abzutippen und dem Angreifer zu überlassen. Dagegen schützt das iTAN-Verfahren nicht. 1 Ein Captcha ist ein Bild, das für Menschen lesbaren Text enthält, der aber nicht oder nur schwer automatisch erkannt werden kann. Captchas sollen erzwingen, dass nur Menschen und keine Computerprogramme einen Online-Dienst nutzen können. 37 4 Legitimationsverfahren Weiterhin ist das iTAN-Verfahren auch nicht vor einem MITM-Angriff sicher, wie eingangs bereits gezeigt wurde. Auch die formale Analyse mit AVISPA offenbart die Angriffsmöglichkeit. Das Ergebnis dieser Analyse findet sich im Anhang B.1. Der MITM-Angriff soll mit Hilfe des iTANplus-Verfahrens erschwert werden. Ein aufmerksamer Benutzer vorrausgesetzt müsste ein Angreifer die Informationen auf dem Captcha unauffällig ändern. Diese Manipulation ist manuell durchaus möglich, aber maschinell bei automatisierten Angriffen schwierig. Prinzipiell ist ein MITM-Angriff auch bei diesem Verfahren nicht ausgeschlossen. Die einfachste Möglicheit funktioniert wie folgt: Sobald der Kunde eine Transaktion eingibt, erzeugt der Angreifer eine zweite, betrügerische Transaktion. Beide Aufträge werden bei der Bank eingereicht, und für beide liefert die Bank ein entsprechendes Captcha zurück. Der Angreifer muss nun lediglich bei dem Captcha, das der legitimen Transaktion zugeordnet ist, die Indexnummer austauschen und durch die Indexnummer des Captchas der betrügerischen Überweisung ersetzen. Befinden sich die Indexnummern stets an der gleichen Stelle auf dem Bild, ist die Manipulation auch automatisch leicht durchführbar. Analyse der Benutzerfreundlichkeit Die indizierte TAN-Liste kann problemlos transportiert werden und erlaubt somit einen mobilen Einsatz dieses Verfahrens. Die KLM-Schritte für das indizierte TAN-Verfahren sind: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), Indexnummer merken (M), zur TANListe wechseln (W), TAN suchen (M), TAN merken (M), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T bei sechstelliger TAN), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 2K + 2W + 5M + A = 15,2 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Beim iTANplus-Verfahren muss der Anwender zusätzlich noch das Captcha kontrollieren. Dafür muss er das angegebene Geburtsdatum (M) und die Transaktionsdaten (M) überprüfen. Das iTANplus-Verfahren dauert also 18 Sekunden. Falls die Bank nach der TAN-Eingabe eine Bestätigungsnummer anzeigt, so fallen zusätzlich 3,2 Sekunden für deren Prüfung an: BEN merken (M), zur TAN-Liste wechseln (W), BEN vergleichen (M). Analyse der Kosten Das indizierte TAN-Verfahren verursacht die gleichen Kosten wie das klassische TANVerfahren. Daher ergeben sich auch hier Kosten von 0,6 Cent pro Transaktion. 38 4.2 Schnittstellenklasse Bidirektional - Keine“ ” 4.2.2 Dynamische TAN Eine ganze Reihe von Verfahren verwenden TAN-Generatoren, die zur Erzeugung der TAN Daten der Transaktion mit einbeziehen. Dazu verfügen diese Geräte neben einem Display über eine Ziffern-Tastatur. Zum Einsatz kommt dieses Verfahren beispielsweise bei der BW-Bank, bei Sparkassen sowie bei Volks- und Raiffeisenbanken. Das dynamische Tan-Verfahren kann mittlerweile auch im Rahmen von FinTS (siehe 4.4.2) benutzt werden. Der offene FinTS-Standard enhält hierzu Spezifikationen und Empfehlungen. Die so erzeugten TANs heißen wegen des Transaktionsbezugs dynamische TANs. Der Transaktionsbezug sorgt auch für eine höhere Sicherheit vor Phishing- und MITM-Angriffen. Zum Einsatz kommt dieses Verfahren beispielsweise bei der BW-Bank, bei Sparkassen sowie bei Volks- und Raiffeisenbanken. Abbildung 4.9: TAN-Generator der BW-Bank; Quelle: www.cio.de Der TAN-Generator der BW-Bank hat eine eingebaute Uhr. Die aktuelle Zeit fließt bei der Berechnung der TAN mit ein, so dass diese TANs nur eine zeitlich begrenzte Gültigkeit besitzen. Außerdem hängt die TAN noch von einem geheimen Schlüssel ab, der im Generator gespeichert ist[Bad07]. Daher ist der sicherheitskritische Gegenstand bei diesem Verfahren der TAN-Generator. Der Hersteller dieser Generatoren ist VASCO Data Security International Inc. [VAS02]. Das Verfahren der BW-Bank funktioniert wie in Abbildung 4.11 beschrieben: 1. Der Kunde gibt einen Teil der Transaktionsdaten (üblicherweise die Zielkontonummer) in seinen TAN-Generator ein. 39 4 Legitimationsverfahren Abbildung 4.10: TAN-Generator der Volks- und Raiffeisenbanken; Quelle: Volksbank Bonn Rhein-Sieg Abbildung 4.11: Ablauf beim dynamischen TAN-Verfahren der BW-Bank 40 4.2 Schnittstellenklasse Bidirektional - Keine“ ” 2. Der TAN-Generator erzeugt eine TAN, die abhängig von der aktuellen Zeit, den eingegebenen Ziffern und einem internen, geheimen Schlüssel ist. Diese TAN wird dem Kunden auf dem Display des Generators angezeigt. 3. Der Kunde gibt die Transaktionsdaten und die TAN in den Rechner ein. 4. Der Rechner schickt die Transaktionsdaten zusammen mit der passenden TAN an den Bankserver. 5. Der Bankserver überprüft, ob die TAN zum aktuellen Auftrag, zum Benutzer und zur aktuellen Zeit passt und führt die Transaktion gegebenenfalls aus. Das Verfahren der Volks- und Raiffeisenbanken nennt sich sm@rtTANplus. Der benutzte Generator funktioniert zusammen mit der Bankkarte des Kunden. Dabei übernimmt der Chip auf der Bankkarte die Berechnung der TAN. Die sm@rtTANplus-Generatoren selbst enthalten weder geheime Schlüssel noch eine eingebaute Uhr. Replay-Angriffe werden hier auf anderem Weg verhindert: Der Chip speichert einen Zählerstand, der sich bei jeder TAN-Generierung erhöht und mit in die Berechnung der TAN eingeht. Zusätzlich zu den ausgewählten Transaktionsdaten muss der Kunde eine von der Bank für die bestimmte Transaktion gültige fünfstellige Zufallszahl in den Generator eingeben.[Vol07] Die Bank merkt sich, bis wann eine ausgegebene Zufallszahl und eine dazugehörige TAN gültig ist. Abbildung 4.12 erläutert den genauen Kommunikationsablauf. Abbildung 4.12: Ablauf beim sm@rtTANplus-Verfahren der Volks- und Raiffeisenbanken 41 4 Legitimationsverfahren 1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein. 2. Der Rechner leitet die Transaktionsdaten an den Bankserver weiter. 3. Der Bankserver generiert für diese Transaktion eine Zufallszahl und sendet diese Zahl zurück an den Rechner. 4. Der Rechner fordert den Kunden auf, die Zufallszahl und anschließend einen Teil der Transaktionsdaten (z. B. die ersten 6 Ziffern der Zielkontonummer) in den TAN-Generator einzugeben. 5. Der Kunde steckt seine Bankkarte in den TAN-Generator und gibt die Zufallszahl sowie den geforderten Teil der Transaktionsdaten ein. 6. Der Chip auf der Kundenkarte erzeugt eine TAN, die abhängig von der eingegebenen Zufallszahl, den eingegebenen Transaktionsdaten und einem internen, geheimen Schlüssel ist. Diese TAN wird dem Kunden auf dem Display des Generators angezeigt. 7. Der Kunde gibt die TAN unter den bereits eingegebenen Transaktionsdaten in den Rechner ein. 8. Der Rechner schickt die Transaktionsdaten zusammen mit der passenden TAN an den Bankserver. 9. Der Bankserver überprüft, ob die TAN zum aktuellen Auftrag, zum Benutzer, zum aktuellen Zählerstand und zur Zufallszahl passt und führt die Transaktion gegebenenfalls aus und speichert den neuen Zählerstand. Einige Sparkassen bieten das chipTAN-Verfahren an, ein zum sm@rtTANplus analoges Verfahren.[Ber08] Dabei kommen neuerdings auch Tan-Generatoren zum Einsatz, die über eine optische Schnittstelle verfügen, die Daten direkt vom Bildschirm einlesen kann. Dadurch braucht der Anwender keine Daten doppelt einzugeben.[REI08] Die Datenübertragung vom Bildschirm in den TAN-Generator erfolgt mit einem Flickercode. Dieser besteht aus einem Bild mit mehreren schwarz-weiß blinkenden Flächen, die durch ihr Zusammenspiel die Informationen ähnlich wie beim Morsen übertragen. Analyse der Sicherheit Die dynamischen TAN-Verfahren sind sicher vor klassischen Phishing-Angriffen, da die TANs eine begrenzte Gültigkeit haben und direkt von Teilen der Transaktionsdaten abhängen. Auch ein Transaktionsdaten manipulierender MITM-Angriff scheitert, wenn die Daten geändert werden, die in den Generator eingegeben werden. Die formale Sicherheitsanalyse mit AVISPA bestätigt die Sicherheit des spezifizierten Protokolls (siehe Anhang). 42 4.2 Schnittstellenklasse Bidirektional - Keine“ ” Allerdings sind einige Angriffsszenarien möglich, die Elemente des MITM und des Phishing kombinieren. Durch eine betrügerische E-Mail oder eine gefälschte Website könnte ein unachtsamer Benutzer dazu gebracht werden, beliebige Daten in seinen TAN-Generator einzugeben. So kann der Kunde dazu gebracht werden, eine TAN für eine betrügerische Transaktion zu erzeugen. Wenn ein MITM diese Transaktion ohne Verzögerung ausführt, hilft auch die Zeitbeschränkung der TANs nichts. Abbildung 4.13 zeigt ein Beispiel für einen derartigen Betrug. Abbildung 4.13: Potentieller Angriff auf das sm@rtTANplus-Verfahren; Quelle: eigene Darstellung Eine weitere Schwachstelle besteht darin, dass der Kunde nur einen Teil der Transaktionsdaten - beispielsweise die Kontonummer des Empfängers - in den Generator eingeben kann. Die Berechnung der TAN hängt dann nur von diesem eingegebenen Teil der Transaktionsdaten ab. Eine Manipulation der übrigen Transaktionsdaten durch einen MITMAngriff kann also nicht ausgeschlossen werden. Denkbar wäre beispielsweise, dass ein Betrüger Zugang zu einem Konto hat, dessen Kontonummer identisch mit der Kontonummer eines Unternehmen ist, bei dem sehr viele Überweisungen eingehen. Solche Unternehmen sind beispielsweise die Gebühreneinzugszentrale, Stadtwerke und Telekommunikationsunternehmen. Falls ein Kunde dann eine Überweisung zu Gunsten eines 43 4 Legitimationsverfahren solchen Unternehmens eingeben möchte, könnte ein MITM zwar die Kontonummer beibehalten, Betrag und Bankleitzahl aber ändern und so eine betrügerische Überweisung veranlassen. Durch die ungezielte Manipulation der ungeschützten Teile der Transaktionsdaten kann ein MITM auch einen Schaden beim Kunden (finanziell) und eventuell beim ahnungslosen Zahlungsempfänger (durch anschließende polizeiliche Ermittlungen) verursachen. Der MITM hat dabei keinen unmittelbaren finanziellen Vorteil. Mögliche Motive für diesen Angriff sind Rufschädigung, Rache oder Sabotage. Trotz der geschilderten Schwachstellen sind die dynamischen TAN-Verfahren relativ sicher, weil Angriffe auf andere Verfahren viel leichter möglich und somit für Angreifer günstiger sind. Die GAD plant, den sm@rtTANplus-Generator um einige Sicherheitsmerkmale zu erweitern. So soll zukünftig die Eingabe der Transaktionsdaten durch eine optische Übertragung vom Bildschirm aus per Flicker-Code erfolgen - ähnlich wie beim InternetPassport. Außerdem soll im Display angezeigt werden, welche Bedeutung die zu kontrollierenden Daten innerhalb des Kommunikationsablauf haben. So kann der Kunde erkennen, ob es sich bei den zu bestätigenden Daten um einen angeblichen Sicherheitscode oder um eine Kontonummer handelt. Analyse der Benutzerfreundlichkeit Die TAN-Generatoren können überall benutzt werden, so dass die dynamischen TANVerfahren mobil einsetzbar sind. Die KLM-Schritte für das sm@rtTANplus-Verfahren sind: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), Transaktionsdaten kontrollieren (M), Code merken (M), zum TAN-Generator wechseln (W), Karte einstecken (G = 3 Sekunden), Taste drücken (T), sich an Code erinnern (M), Code eingeben und bestätigen (6T), sich an Transaktionsdaten erinnern (M), Transaktionsdaten eingeben und bestätigen (7T), TAN ablesen und merken (M), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 19T + 2K + 2W + 6M + A + G = 26,1 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Das TAN-Verfahren der BW-Bank kommt ohne einen Code und ohne Karte aus. Somit entfallen gegenüber dem sm@rtTANplus-Verfahren die Schritte, die den Code (2M und 6T) und die Karte (G) betreffen. Allerdings wird die Kontonummer als ganze eingegeben. Bei einer zehnstelligen Kontonummer kommen somit wieder 4T hinzu. Das Verfahren ist 6,8 Sekunden schneller und benötigt insgesamt 19,3 Sekunden. Das neue sm@rtTANplus-Verfahren, bei dem die Informationen per Flickercode über den Bildschirm übertragen werden, benötigt folgende KLM-Schritte: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), zum TAN-Generator wechseln (W), Karte einstecken (G = 3 Sekunden), Taste drücken (T), Gerät an Bildschirm halten und Flickercode einlesen (G = 3 Sekunden), angezeigte Transaktionsdaten kontrollieren 44 4.2 Schnittstellenklasse Bidirektional - Keine“ ” (M), Knopf drücken (T), TAN ablesen und merken (M), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an die TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 7T + 2K + 2W + 4M + A + 2G = 16,3 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Der sm@rtTANplus-Generator kostet 12,25 ¿ [Vol08, Seite 31], womit sich unter den Annahmen aus Abschnitt 3.3 5 Cent pro Transaktion ergeben. Der TAN-Generator der BW-Bank kostet 15 ¿ [Bad07, Seite 3], also 6 Cent pro Transaktion. Angaben zu den Kosten des neuen sm@rtTANplus-Generators mit Flickercode-Eingabe waren noch nicht erhältlich. Der Preis dürfte leicht über dem der anderen Generatoren liegen. Geht man von einem Preis von 20 ¿ aus, so ergeben sich Kosten von 8 Cent pro Transaktion. Die Versandtkosten sind bereits in diesen Preisen enthalten. 4.2.3 Permutations-TAN Die Permutations-TAN (pTAN) ist ein Verfahren zur sicheren Eingabe von Zahlen wie Kontonummern, Bankleitzahlen, Beträgen oder auch PINs. Dieses Verfahren benutzt als sicherheitsrelevanten Gegenstand eine Papierliste von Permutationen der Ziffern 0-9. Die sichere Eingabe der Daten erfolgt, indem die Papierliste an den Computerbildschirm angelegt und auf unbeschriftete Schaltflächen geklickt wird. Die Bedeutung der Schaltflächen ergibt sich aus dem angelegten pTAN-Bogen. Das Verfahren wird bisher noch nicht eingesetzt. Abbildung 4.14 illustriert die Dateneingabe. Wie zu sehen ist, sind auf dem pTAN-Bogen zusätzlich zu den Ziffern noch blau hinterlegte Felder vorhanden. Diese dienen zur wiederholten Eingabe bereits eingegebener Ziffern. Eine einmal gedrückte Schaltfläche kann nämlich aus Sicherheitsgründen nicht ein zweites Mal angeklickt werden. Soll nun beispielsweise die Zahl 575 eingegeben werden, so werden zunächst die Ziffern 5 und 7 durch klicken auf die Schaltflächen für die Ziffern 5 und 7 eingegeben. Die letzte 5 wird nun als Referenz auf die erste Position (die ebenfalls 5 ist) eingegeben. Es folgt ein Klick auf das Kästchen, das auf die erste Position verweist - p1. Das Verfahren ist neu und wird derzeit von keiner Bank eingesetzt. Abbildung 4.15 gibt eine mögliche Implementierung der pTAN an. 1. Vor der Eingabe einer Transaktion sendet der Bankserver die Positionsnummer einer beliebigen, unverbrauchten pTAN an den Kundenrechner. 2. Auf dem Computerbildschirm wird angezeigt, welche pTAN der Kunde für die kommende Transaktion benutzen soll. 45 4 Legitimationsverfahren Abbildung 4.14: verschlüsselte Dateneingabe beim pTAN-Verfahren; Quelle: Bernd Borchert Abbildung 4.15: Ablauf beim pTAN-Verfahren 46 4.2 Schnittstellenklasse Bidirektional - Keine“ ” 3. Der Kunde sucht ziffernweise auf dem pTAN-Bogen, welche Schaltfläche zu drücken ist und 4. gibt einen Teil der Transaktionsdaten durch Drücken dieser Schaltflächen so verschlüsselt in den Rechner ein. 5. Die Information, welche Schaltfläche gedrückt wurde, wird vom Rechner zum Bankserver gesendet. 6. Der Server ermittelt die entsprechende Ziffer, speichert sie und schickt sie zurück zum Rechner. 7. Die Ziffer wird auf dem Computerbildschirm angezeigt. Die Schritte 3 bis 7 wiederholen sich solange, bis der Kunde die ganze Zahl eingegeben hat und den Vorgang durch Auswahl der Schaltfläche OK“ abschließt. ” 8. Der Kunde gibt die restlichen Transaktionsdaten direkt in den Rechner ein. 9. Der Rechner schickt die restlichen Transaktionsdaten zur Bank. 10. Die Bank setzt die gespeicherten Ziffern und die restlichen Transaktionsdaten zusammen, erhält so die kompletten erforderlichen Daten und führt den Auftrag aus. Analyse der Sicherheit Dieses Verfahren ist sicher vor herkömmlichen Phishing-Angriffen. Ebenfalls sicher ist es vor manipulierenden MITM-Angriffen. Allerdings könnte der Kunde durch einen Phishing-Angriff dazu gebracht werden, eine pTAN zu verraten. Ebenfalls denkbar ist ein kombinierter Phishing-MITM-Angriff, wie er auch für die dynamische TAN möglich ist. Dem Benutzer wird vorgespielt, er gäbe einen Sicherheitscode mit Hilfe der pTAN ein. In Wirklichkeit handelt es sich aber bei dem angeblichen Sicherheitscode um die Kontonummer des Betrügers. Ein sabotierender Angreifer, der sich Zugang zum System verschafft hat, könnte auch eine zufällige, aber gültige Eingabe erzeugen, ohne die zu verwendende Permutation zu kennen. Dazu klickt er auf zufällige Schaltflächen. Eine gültige Eingabe wird erzeugt, wenn Positionsnummern erst dann verwendet werden, wenn die referenzierte Position bereits belegt wurde. Beispielsweise bezieht sich P3 auf die dritte Position der Eingabe. Wenn noch keine drei Ziffern eingegeben wurden, führt ein Klick auf P3 zu einem Fehler und einem Abbruch der Eingabe. Außerdem muss die Eingabe durch einen Klick auf OK bestätigt werden, ohne dass die Eingabe vorher durch einen Fehler oder durch Drücken von K abgebrochen wurde. Die Gesamtwahrscheinlichkeit für eine erfolgreiche Eingabe durch pures Raten beträgt etwa 1,5% für bis zu 19 Stellen lange Zahlen. Für maximal 10 Stellen lange Zahlen beträgt die Wahrscheinlichkeit etwa 0,3%. Zum Vergleich: Die Wahrscheinlichkeit, eine sechsstellige TAN zu erraten, beträgt lediglich 0,0001%. 47 4 Legitimationsverfahren Analyse der Benutzerfreundlichkeit Die TAN-Liste ist leicht zu transportieren und kann an jedem beliebigen Rechner verwendet werden. Das Verfahren ist somit mobil einsetzbar. Nachteilig an diesem Verfahren ist die umständliche, gewöhnungbedürftige Eingabe. Die KLM-Schritte für das Permutations-TAN-plus-Verfahren sind bei Eingabe einer zehnstelligen Kontonummer: Systemantwort abwarten (A), Indexnummer lesen und merken (M), zur TAN-Liste wechseln (W), sich an Indexnummer erinnern (M), Indexnummer auf TAN-Liste finden (M), TAN-Liste knicken und am Bildschirm anlegen (G = 5 Sekunden), zum Computer wechseln (W), Größe der Eingabefelder anpassen (K), Kontonummer ziffernweise verschlüsseln und eingeben (10M + 10K), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 12K + 2W + 13M + A + G = 40,4 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Beim Permutations-TAN-Verfahren fallen Kosten für den Druck und den Versandt der TAN-Liste an. Wie beim klassischen TAN-Verfahren wird angenommen, dass eine TANListe somit 60 Cent kostet. Auf eine beidseitig bedruckte Liste passen etwa 40 PermutationsTANs, so dass sich Kosten von 1,5 Cent pro Transaktion ergeben. 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” 4.3.1 Mobile TAN Der sicherheitskritische Gegenstand beim mobile-TAN-Verfahren (mTAN, SMS-TAN) ist das Mobiltelefon des Bankkunden. Bei diesem Verfahren wird in einem Kommunikationsschritt die von der Bank geforderte TAN per SMS an den Kunden gesendet und zwar zusammen mit dem Text der betreffenden Transaktion. 1. Der Kunde gibt die Transaktionsdaten in den Rechner ein. 2. Der Rechner leitet die Transaktionsdaten an den Server der Bank weiter. 3. Der Server generiert eine zufällige Transaktionsnummer und sendet diese zusammen mit den Transaktionsdaten in einer SMS an das Mobiltelefon des Kunden. 4. Der Kunde erhält die SMS, prüft die Transaktionsdaten und liest die mTAN. 5. Nur, wenn die Transaktionsdaten in der SMS den eingegebenen Daten von Schritt 1 entsprechen gibt der Kunde die mTAN in seinen Rechner ein. 6. Der Rechner schickt die Transaktionsdaten und die mTAN an den Server der Bank. 48 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Abbildung 4.16: Ablauf des mobile TAN-Verfahrens 7. Der Bankserver überprüft, ob die erhaltene mTAN der per SMS gesendeten entspricht und führt die Transaktion gegebenenfalls aus. Analyse der Sicherheit Dieses mobile TAN-Verfahren ist sicher vor bekannten Phishing- und MITM-Angriffen. Wenn allerdings Anwender aus Bequemlichkeit darauf verzichten, die Transaktionsdaten in der SMS zu kontrollieren, ist die Sicherheit nicht gegeben. Die Übertragung der SMS lässt sich zwar im Prinzip belauschen [BBK03], der Aufwand hierfür ist jedoch wegen der fehlenden Automatisierbarkeit des Angriffes sehr hoch. Problematisch ist der Einsatz des mobile TAN-Verfahrens, wenn die Abwicklung der Transaktion und der Empfang der SMS in ein und demselben Gerät erfolgen, etwa in einem Laptop mit GPRS-Empfang, das SMS empfängt, oder in einem internetfähigen Mobiltelefon wie dem iPhone von Apple, von dem aus das Online-Banking-System genutzt wird. Ein Trojaner könnte hier sowohl die Internet-Kommunikation als auch die SMS manipulieren und so einen MITMAngriff ermöglichen. Die formale Analyse mit AVISPA zeigt eine Angriffsmöglichkeit, wenn der Anwender nicht überprüfen kann, von wem die erhaltenen SMS stammt. Hat der Anwender Konten bei zwei verschiedenen Banken, so könnte ein MITM-Angreifer bei Eingabe einer legitimen Transaktion das zu Grunde liegende Konto auf das jeweils andere ändern (siehe B.3). Diese Sicherheitslücke ließe sich leicht beheben, indem in der SMS auch die Kontodaten des Kunden angezeigt werden. Analyse der Benutzerfreundlichkeit Das Verfahren ist wegen der Verwendung eines Mobiltelefons von jedem beliebigen PC aus nutzbar. 49 4 Legitimationsverfahren Die KLM-Schritte für das mobile TAN-Verfahren sind: SMS-Eingang abwarten (G = 10 Sekunden), Knopf zum Anzeigen der SMS drücken (T), Transaktionsdaten kontrollieren (M), Knopf zum Anzeigen der TAN drücken (T), TAN merken (M), zum Computer wechseln (W), auf TAN-Eingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 8T + 2K + W + 3M + G = 21 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Bei dem mobilen TAN-Verfahren fallen Kosten für die Zustellung der SMS an. Die Volksbanken berechnen hierfür 10 Cent pro Überweisung. Bei der Postbank ist das Verfahren für den Kunden zwar kostenlos, aber für die Bank dürften Kosten in ähnlicher Größenordnung anfallen. Es ist davon auszugehen, dass Nutzer des mobilen TAN-Verfahrens bereits ein Mobiltelefon besitzen. Deshalb werden die Anschaffungskosten für das Mobiltelefon hier nicht berücksichtigt. 4.3.2 Cardano-TAN Das Cardano-TAN-Verfahren besteht aus einer Papierkarte, in die an unterschiedlichen Stellen Löcher gestanzt sind. Der Kunde erhält von seiner Bank einen Block solcher Karten. In einem Kommunikationsschritt schickt die Bank ein Bild mit Zahlenblöcken an den Kunden. Der kann dann durch Auflegen einer bestimmten Cardano-TAN-Karte in den Löchern die eingegebenen Transaktionsdaten überprüfen und die zugehörige TAN ablesen und zur Bestätigung des Auftrags zur Bank zurückschicken. Abbildung 4.17 zeigt die Verwendung der Cardano-TAN. In diesem Beispiel kann die Zielkontonummer von oben nach unten auf den weißen Kästchen abgelesen werden. Die TAN wird ebenfalls von oben nach unten auf den roten Kästchen abgelesen und lautet hier 2239. Jede Karte kann nur ein einziges Mal benutzt werden. Das Verfahren ist neu und wird derzeit von keiner Bank eingesetzt. Der Kommunikationsablauf funktioniert wie folgt (Abbildung 4.18): 1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein. 2. Der Rechner sendet die Transaktionsdaten an den Bankserver. 3. Der Bankserver wählt eine zufällige TAN und die nächste zu benutzende CardanoKarte und erzeugt daraus und aus Teilen der Transaktionsdaten ein Bild mit Zahlenblöcken. Dieses Bild wird zusammen mit der Nummer der zu verwendenden Cardano-Karte an den Rechner geschickt. 4. Auf dem Rechner wird das Bild mit den Zahlenblöcken und die Nummer der zu verwendenden Cardano-Karte angezeigt. 50 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Abbildung 4.17: Funktionsweise des Cardano-TAN-Verfahrens; Quelle: Bernd Borchert Abbildung 4.18: Ablauf des Cardano-TAN-Verfahrens 51 4 Legitimationsverfahren 5. Der Kunde legt die entsprechende Cardano-Karte auf den Bildschirm und liest mit deren Hilfe die übermittelten Transaktionsdaten und die TAN ab. Er kontrolliert die Transaktionsdaten. 6. Nach einer positiven Kontrolle gibt der Kunde die TAN in den Rechner ein, um die Transaktion zu bestätigen. 7. Der Rechner sendet die Transaktionsdaten und die TAN an den Bankserver. 8. Der Bankserver prüft die erhaltene TAN und führt dann gegegenenfalls die Transaktion aus. Analyse der Sicherheit Das Cardano-TAN-Verfahren ist sicher gegenüber herkömmlichen Phishing- und MITMAngriffen. Ein Angreifer kennt die Position der Löcher in der Karte nicht, und kann somit nicht die erforderliche TAN auslesen. Andererseits kann er auch die im Bild verschlüsselt enthaltenen Transaktionsdaten nicht ändern. Wegen der fehlenden Bedeutungsinformationen ist beim Cardano-TAN-Verfahren auch der in Abbildung 4.13 beschriebene kombinierte Phishing-MITM-Angriff möglich. Analyse der Benutzerfreundlichkeit Ein Nachteil besteht in der komplizierten Bedienung: Die verwendeten Folien müssen exakt über das auf dem Computerbildschirm angezeigte Bild passen. Da die tatsächliche Bildgröße von der Auflösung und den Abmessungen des Bildschirms abhängen, muss die Bildgröße im Einzelfall manuell angepasst werden. Außerdem muss der Benutzer die Folie genau ausrichten. Größenänderung und Ausrichtung sind in diesem Verfahren zusätzliche Arbeitsschritte des Benutzers. Das Verfahren lässt sich von jedem beliebigen PC einsetzen. Die KLM-Schritte des Cardano-TAN-Verfahrens sind: Systemantwort abwarten (A), Indexnummer lesen und merken (M), zum TAN-Block wechseln (W), sich an Indexnummer erinnern (M), Indexnummer auf TAN-Block finden (M), Cardano-TAN-Karte heraussuchen und am Bildschirm anlegen (G = 5 Sekunden), zum Computer wechseln (W), Größe des Anzeigefeldes anpassen (K), Transaktionsdaten prüfen (M), TAN ablesen (M), auf das TAN-Eingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 3K + 2W + 6M + A + G = 22,8 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Beim Cardano-TAN-Verfahren fallen Kosten an für die Herstellung und Zusendung des TAN-Blocks. Der Einfachheit halber wird angenommen, dass 20 lose, bedruckte Folien 52 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” im Format DIN A7 in einem Brief verschickt werden und insgesamt dafür 60 Cent an Kosten anfallen. Damit ergäben sich Kosten in Höhe von 3 Cent pro Transaktion. 4.3.3 Visuelle TAN Die visuelle TAN (vTAN) benutzt mit kleinen schwarzen Punkten bedruckte Folien zur sicheren Datenübertragung von der Bank zum Kunden. Diese Schlüssel-Folien ergeben in Überlagerung mit einem korrespondierendem Bild auf dem Computerbildschirm eine Anzeige, auf der Informationen wie Transaktionsdaten oder TANs angezeigt werden können. Jede Folie kann nur einmal verwendet werden. [Gre07] Das Verfahren ist neu und wird derzeit von keiner Bank eingesetzt. Es basiert auf einer Idee von Naor und Shamir [NS95]. Die Folie stellt einen Einmalschlüssel dar. Durch die Überlagerung der Folien- und der Bildschirmpixel ergibt sich durch eine geschickte Anordnung eine XOR-Verknüpfung der Bildpunkte, so dass ein schwarzer Text vor einem 50% grauen Hintergrund erscheint. Dazu werden Blöcke aus zwei mal zwei Pixeln als eine Einheit gesehen. Zwei der vier Pixel sind schwarz, die anderen beiden weiß. Zeigt man einen solchen Block am Bildschirm an und legt über ihn eine Folie mit einem identischen Block, so ergibt sich ein Block mit 2 weißen und zwei schwarzen Pixeln. Bei genügend kleiner Blockgröße erscheint dem menschlichen Betrachter dieser Block als grauer Punkt. Ist die Folie aber komplementär zum Bildschirmblock, also die weißen und schwarzen Pixel vertauscht, so erscheint der Block völlig schwarz. Abbildung 4.19 verdeutlicht dieses Prinzip. Abbildung 4.19: Verschlüsselung der Bildpunkte bei der visuellen TAN; Quelle: Rheinisch-Westfälische Technische Hochschule Aachen Um das Verfahren nutzen zu können, wird zunächst zufällig eine Schlüsselfolie mit 2x2-Blöcken generiert. Jeder Block besteht aus zwei weißen und zwei schwarzen Pixeln, und für jeden Block gibt es zwei mögliche, komplementäre Belegungen, die je mit gleicher Wahrscheinlichkeit auftreten. Ein gegebenes Scharz-Weiß-Bild lässt sich dann ver- 53 4 Legitimationsverfahren schlüsseln, indem für jedes Pixel des Bildes durch einen 2x2-Block ersetzt wird. Zur Darstellung eines schwarzen Pixels wird ein zum darüberliegenden Block auf der Folie komplementärer Block erzeugt, zur Darstellung eines weißen Pixels wird der darüberliegende Folienblock kopiert. Da die Anordnung der Blöcke auf der Folie zufällig gewählt wird, erscheint die Anordnung der Blöcke auf dem Bildschirm ebenfalls zufällig. Ohne die Entschlüsselungsinformation, die die Folie bietet, könnte jeder Block des verschlüsselten Bildes mit gleicher Wahrscheinlichkeit schwarz oder grau sein. Die Abbildung 4.20 zeigt, wie Folie und Pixel-Bild zusammen eine sinnvolle Anzeige ergeben. Abbildung 4.20: Funktionsweise der visuellen TAN; Quelle: Bernd Borchert Der Kommunikationsablauf ist ähnlich dem des Cardano-TAN-Verfahrens: 1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein. 2. Der Rechner sendet die Transaktionsdaten an den Bankserver. 3. Der Bankserver wählt eine zufällige TAN und die nächste zu benutzende SchlüsselFolie und erzeugt daraus und aus Teilen der Transaktionsdaten ein verschlüsseltes Bild. Dieses Bild wird zusammen mit der Nummer der zu verwendenden SchlüsselFolie an den Rechner geschickt. 54 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Abbildung 4.21: Ablauf des visuellen TAN-Verfahrens 4. Auf dem Rechner wird das verschlüsselte Bild und die Nummer der zu verwendenden Folie angezeigt. 5. Der Kunde legt die entsprechende Schlüssel-Folie auf den Bildschirm und liest mit deren Hilfe die übermittelten Transaktionsdaten und die TAN ab. Er kontrolliert die Transaktionsdaten. 6. Nach einer positiven Kontrolle gibt der Kunde die TAN in den Rechner ein, um die Transaktion zu bestätigen. 7. Der Rechner sendet die Transaktionsdaten und die TAN an den Bankserver. 8. Der Bankserver prüft die erhaltene TAN und führt dann gegegenenfalls die Transaktion aus. Analyse der Sicherheit Diese Verfahren ist sicher vor Phishing- und MITM-Angriffen. Ein Angreifer kann die TAN nicht ohne Kenntnis der Schlüsselfolie und ohne Mitwirken des Anwenders erfahren. Der Anwender aber gibt die TAN nur preis, wenn er die korrekten Transaktionsdaten angezeigt bekommt. Diese lassen sich ebenfalls nicht fälschen. Analyse der Benutzerfreundlichkeit Das Verfahren lässt sich von jedem beliebigen PC einsetzen. 55 4 Legitimationsverfahren Die KLM-Schritte des visuellen TAN-Verfahrens sind: Systemantwort abwarten (A), Indexnummer lesen und merken (M), zum TAN-Block wechseln (W), sich an Indexnummer erinnern (M), Indexnummer auf TAN-Block finden (M), TAN-Karte heraussuchen und am Bildschirm anlegen (G = 10 Sekunden, da das genaue Positionieren schwierig ist), zum Computer wechseln (W), Größe des Anzeigefeldes anpassen (K), Transaktionsdaten prüfen (M), TAN ablesen (M), auf das TAN-Eingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 3K + 2W + 6M + A + G = 27,8 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Beim visuellen TAN-Verfahren fallen Kosten für die Herstellung und den Versandt der Folien an. Nimmt man ähnlich wie beim Cardano-TAN-Verfahren an, dass 20 Folien in einem Brief verschickt werden und dafür insgesamt Kosten in Höhe von 60 Cent entstehen, so ergeben sich auch hier Kosten in Höhe von 3 Cent pro Transaktion. 4.3.4 Fotohandy-TAN Das an der Universität Tübingen entwickelte Kamera-TAN-Verfahren benutzt zur Erzeugung dynamischer TANs ein Mobiltelefon mit integrierter Kamera bzw. eine Digitalkamera. Transaktionsdaten werden zunächst wie gewohnt in den Computer eingegeben. Die Daten werden dann in einem 2D-Barcode am Bildschirm dargestellt. Mit einer Mobiltelefonkamera wird der Barcode abfotografiert und die Daten daraus extrahiert. Das Mobiltelefon generiert eine zu den Daten passende dynamische TAN und stellt dann die Daten zusammen mit der TAN auf seinem Display dar. Der Benutzer prüft die Daten und verwendet im positiven Fall die angezeigte TAN zum Unterschreiben der Transaktion in seinem Computer. Somit gleicht dieses Verfahren dem der mobile TAN. Anders als dort wird aber die TAN nicht bankseitig, sondern kundenseitig im Mobiltelefon generiert. Somit benötigt man keine kostenpflichtige, mobilfunknetzabhängige Übertragung per SMS. Das Verfahren ist neu und wird derzeit von keiner Bank eingesetzt. Das Verfahren läuft im Einzelnen wie in Abbildung 4.22 beschrieben ab. 1. Der Benutzer gibt die Auftragsdaten in den Rechner ein. 2. Der Rechner leitet die Daten an den Bankserver weiter. 3. Der Bankserver generiert ein Bild eines 2D-Barcodes, der die Daten und eine Nonce enthält. Dieses Bild schickt der Server zurück zum Rechner. 4. Der Rechner stellt den 2D-Barcode auf dem Computerbildschirm dar. Die Kamera des Mobiltelefons nimmt das Bild des Barcodes auf. 56 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Abbildung 4.22: Ablauf des Fotohandy-TAN-Verfahrens 5. Das Mobiltelefon verarbeitet das Bild und extrahiert die in ihm enthaltenen Daten. Diese Daten werden dem Benutzer auf dem Telefondisplay angezeigt. Außerdem generiert das Mobiltelefon eine dynamische TAN, die abhängig ist von den extrahierten Daten und einem im Mobiltelefon gespeicherten geheimen Schlüssel. Die dynamische TAN wird dem Benutzer ebenfalls auf dem Telefondisplay angezeigt. 6. Der Benutzer prüft die auf dem Mobiltelefondisplay angezeigten Daten. Im positiven Fall gibt der Benutzer die dynamische TAN in den Computer ein und schickt die Transaktion ab. 7. Der Rechner leitet die Transaktionsdaten zusammen mit der dynamischen TAN an den Bankserver weiter. 8. Der Bankserver überprüft, ob Transaktionsdaten und TAN zusammen passen. Im positiven Fall wird die Transaktion ausgeführt. Analyse der Sicherheit Dieses Verfahren funktioniert im Prinzip ähnlich wie das sm@rtTANplus-Verfahren, nur dass hier nicht der Anwender die Eingabe der Daten in das Gerät vornimmt, sondern die Daten vom Computerbildschirm eingelesen werden. Eine Manipulation der Daten bemerkt der Anwender. Die formale Sicherheitsanalyse mit AVISPA findet ebenfalls keine Angriffsmöglichkeiten (siehe Anhang). Analyse der Benutzerfreundlichkeit Das Verfahren lässt sich von jedem beliebigen PC einsetzen. 57 4 Legitimationsverfahren Die KLM-Schritte des Fotohandy-TAN-Verfahrens sind: Systemantwort abwarten (A), TAN-Funktion des Mobiltelefons aktivieren (T), Barcode abfotografieren (G = 3 Sekunden), Antwort des Mobiltelefons abwarten (A), Transaktionsdaten prüfen (M), Taste zum Anzeigen der TAN drücken (T), TAN ablesen (M), zum Computer wechseln (W), auf das TAN-Eingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 8T + 2K + W + 3M + 2A + G = 18 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Wenn man davon ausgeht, das der Benutzer bereits ein Mobiltelefon besitzt, dann fallen dafür im Rahmen dieses Verfahrens keine Kosten an. Es fallen nur Kosten für die Bereitstellung der Software an. Bei genügend vielen Kunden sind die Kosten für jeden einzelnen vernachlässigbar klein, so dass dieses Verfahren kostenlos in Bezug auf die Anzahl der Transaktionen und Kunden ist. 4.3.5 Internetpassport Der Internetpassport ist ein mobiles elektronisches Gerät, das speziell für den Einsatz im Internet entwickelt wurde. Mit ihm lässt sich die Identität von Benutzern biometrisch verifizieren, und es können Transaktionen auf sichere Weise durchgeführt werden. Der Internetpassport hat etwa die Größe einer Kreditkarte. Er verfügt über ein Mikroprozessor, ein Display, einen Fingerabdrucksensor und einen optischen Dateneingang.[Sie07] Im Bereich des Online-Banking kann der Internetpassport zur Generierung einer dynamischen TAN zum sicheren Durchführen von Transaktionen verwendet werden. Dazu werden zunächst Transaktionsdaten in einen Computer eingegeben. Diese Daten werden über einen Flicker-Code vom Bildschirm in das Gerät eingelesen, an dessen Display angezeigt und kontrolliert. Außerdem erzeugt der Internetpassport eine zu den Daten passende dynamische TAN und zeigt diese an. Der Internetpassport lässt sich nur benutzen, wenn er vom entsprechenden Benutzer mit dessen Fingerabdruck aktiviert wird. Der Internetpassport wird derzeit von keiner Bank eingesetzt. Das Verfahren funktioniert wie in Abbildung 4.23 beschrieben. 1. Der Benutzer gibt die Transaktionsdaten in den Rechner ein. 2. Der Rechner schickt die Transaktionsdaten an den Server der Bank. 3. Die Bank erstellt eine TAN und generiert einen Bild mit einem Flicker-Code, das die Transaktionsdaten und die TAN in verschlüsselter Form enthält. 4. Der Kunde aktiviert seinen Internetpassport, indem er seinen Finger über den Fingerabdrucksensor streift. Der Flicker-Code wird am Bildschirm angezeigt und vom Internetpassport eingelesen. 58 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Abbildung 4.23: Ablauf des Internetpassport-Verfahrens 5. Der Internetpassport entschlüsselt die Daten mit Hilfe des gespeicherten, geheimen Schlüssels. Dann zeigt er dem Kunden die Transaktionsdaten und die dazu passende TAN auf dem integrierten Display an. 6. Der Kunde kontrolliert die Transaktionsdaten. Im positiven Fall bestätigt er die Transaktion im Computer durch die Eingabe der dynamischen TAN und schickt die Transaktion ab. 7. Der Computer schickt die Transaktionsdaten zusammen mit der dynamischen TAN zum Bankserver. 8. Der Bankserver prüft, ob TAN und Transaktionsdaten zusammen passen. Im positiven Fall wird die Transaktion durchgeführt. Analyse der Sicherheit Dieses Verfahren ist sicher gegenüber Phishing- und MITM-Angriffen. Die Bank führt die Transaktion nur nach Erhalt der korrekten TAN aus. Die TAN kann nur vom InternetPassport entschlüsselt und vom Anwender gelesen werden. Der Anwender gibt die TAN aber nur dann preis, wenn die angezeigten Transaktionsdaten korrekt sind. Diese lassen sich ebenfalls nicht manipulieren. Somit ist ein Angriff ausgeschlossen. Analyse der Benutzerfreundlichkeit Das Verfahren lässt sich von jedem beliebigen PC einsetzen. Die KLM-Schritte des InternetPassport-Verfahrens sind: Systemantwort abwarten (A), InternetPassport einschalten (T), Fingerabdruck einlesen (G = 3 Sekunden), Gerät an 59 4 Legitimationsverfahren Bildschirm halten (G = 3 Sekunden), Antwort des Gerätes abwarten (A), Transaktionsdaten prüfen (M), TAN ablesen (M), zum Computer wechseln (W), auf das TANEingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 7T + 2K + W + 3M + 2A + 2G = 20,5 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Für den InternetPassport ist noch kein Preis festgesetzt, da das Produkt noch nicht verkauft wird. Der Preis dürfte aber höher sein als der für den ähnlich gebauten sm@rtTANplusGenerator mit Flickercode, der in 4.2.2 mit 20 ¿ geschätzt wurde. Beim InternetPassport fallen höhere Kosten an für das besser auflösende Display und den Fingerabdruckleser. Nimmt man daher 30 ¿ als Preis an, dann kostet eine Transaktion 12 Cent. 4.3.6 Monitor-TAN Eine Möglichkeit, Transaktionen sicher vor Angriffen zu machen, ohne dass der Kunde die gewohnte Arbeitsumgebung seines Rechners verlassen müsste, ist die Verwendung eines kryptographischen Moduls, das zwischen Rechner und Computerbildschirm geschaltet wird. Im normalen Betrieb leitet dieser Dongle die ankommenden Bildschirmsignale einfach an den Monitor weiter. Im Rahmen sicheren Online-Bankings kann die Bank verschlüsselte Bilder senden, die nur vom Gerät entschlüsselt werden können. Dazu filtert das Gerät den Datenstrom zum Monitor. Sobald es ein verschlüsseltes Bild vorfindet, entschlüsselt es dies. Am Bildschirm wird dann das entschlüsselte Bild angezeigt. Das Gerät könnte ähnlich aussehen wie in Abbildung 4.24 gezeigt. Abbildung 4.24: Mögliche Ausführung eines Monitor-Dongles; Quelle: Wikipedia 60 4.3 Schnittstellenklasse Ausgehend - Eingehend“ ” Ein möglicher Kommunikationsablauf ist der mobile TAN nachempfunden. Dabei werden eingegebene Transaktionsdaten zunächst zur Bank geschickt. Dort werden sie zusammen mit einer TAN in einem verschlüsselten Bild gespeichert und zurückgeschickt. Der Computer behandelt das verschlüsselte wie ein normales Bild und sendet die Darstellung an den Monitor. Das zwischengeschaltete Gerät erkennt das verschlüsselte Bild und rekonstruiert es. So stellt der Bildschirm die Transaktionsdaten zusammen mit der TAN lesbar als Bild dar. Diesen Ablauf gibt Abbildung 4.25 wieder. Abbildung 4.25: Ablauf des Monitor-TAN-Verfahrens 1. Der Benutzer gibt die Transaktionsdaten in seinen Rechner ein. 2. Der Rechner sendet die Transaktionsdaten an den Server der Bank. 3. Der Bankserver generiert eine zufällige Transaktionsnummer und erzeugt ein verschlüsseltes Bild, in dem die Transaktionsdaten und die Transaktionsnummer stehen. Das verschlüsselte Bild wird zurück zum Rechner geschickt. 4. Der Rechner leitet das verschlüsselte Bild an den Monitor-Dongle. 5. Der Monitor-Dongle entschlüsselt die Daten und sendet das entschlüsselte Bild an den Bildschirm. 6. Der Benutzer sieht die Transaktionsdaten und die TAN am Bildschirm. 7. Nachdem der Benutzer die Transaktionsdaten kontrolliert und für richtig befunden hat, gibt er die TAN in den Rechner ein. 8. Der Rechner sendet die TAN und die Überweisungsdaten an den Server der Bank. 9. Die Bank prüft, ob die TAN zu den Überweisungsdaten passt und führt gegebenenfalls die Transaktion aus. 61 4 Legitimationsverfahren Analyse der Sicherheit Dieses Verfahren ist sicher vor Phishing- und MITM-Angriffen. Ein auf dem Rechner befindlicher Trojaner kann das verschlüsselte Bild weder lesen noch unbemerkt manipulieren. Dadurch gelangt der Trojaner weder an die TAN, noch kann er die Transaktionsdaten unbemerkt ändern. Wird also eine manipulierte Transaktion eingereicht, so kann der Trojaner die Transaktion in Ermangelung der geforderten TAN nicht abschließen. Der Trojaner kann aber auch nicht den Benutzer über den tatsächlichen Inhalt der manipulierten Transaktion täuschen und ihn so zum Ablesen und zur Eingabe der TAN bringen, da jener die Transaktionsdaten im verschlüsselten Bild nicht ändern kann und dieser so eine Manipulation bemerkt. Die Sicherheit dieses Verfahrens setzt voraus, dass nach der Entschlüsselung des Bildes - im Monitor also - keine betrügerischen Prozesse mehr ablaufen. Ein manipulierter Bildschirm könnte das entschlüsselte Bild unbemerkt auslesen und manipulieren, so dass ein MITM-Angriff hier denkbar wäre. Somit ist der Monitor-Dongle nur in einer sicheren Umgebung einsetzbar und sollte nicht in Internet-Cafés verwendet werden. Analyse der Benutzerfreundlichkeit Das Verfahren lässt sich nicht leicht an jedem beliebigen PC einsetzen. Benutzer von Laptops ohne externem Display können den Dongle nirgendwo anschließen. Bei fremden Rechnern könnten die Anschlüsse unpassend sein. Außerdem ist das Umstecken der Kabel umständlich. Dieses Verfahren ist also nicht mobil einsetzbar. Die KLM-Schritte des Monitor-Dongle-Verfahrens sind: Systemantwort abwarten (A), Transaktionsdaten prüfen (M), auf das TAN-Eingabefeld klicken (K), TAN ablesen (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 2K + 2M + A = 10,2 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Der für dieses Verfahren benötigte Monitor-Dongle existiert bisher nur als Idee, weshalb eine Kostenabschätzung schwierig ist. Ein dem Dongle ähnliches Produkt ist eine externe, per USB-Schnittstelle anschließbare Grafikkarte. Günstige externe Grafikkarten kosten im Handel etwa 40 ¿. Wenn der Monitor-Dongle genauso teuer ist, dann ergeben sich Kosten in Höhe von 16 Cent pro Überweisung. 62 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” 4.4.1 WYSIWYS What you see is what you sign (WYSIWYS) ist ein an der Universität Karlsruhe entwickeltes Verfahren, das zur Erzeugung einer Signatur ein Mobiltelefon mit eingebauter Kamera nutzt.[Deu06b] Der Benutzer überprüft zunächst die zu unterschreibenden Daten auf dem normalen Computerbildschirm. Dann fotografiert er diese Daten direkt vom Bildschirm ab. Außerdem überträgt der Rechner die Daten auf elektronischem Weg (beispielsweise per Bluetooth) in das Mobiltelefon. Hier prüft ein Programm, ob das aufgenommene Bild zu den elektronisch übermittelten Daten passt. Falls das der Fall ist, erzeugt die Software auf dem Mobiltelefon eine dynamische TAN oder signiert die Daten elektronisch und schickt sie auf elektronischem Weg zurück an den Computer. Das Verfahren kann beliebige Übermittlungsdaten authentifizieren und ist nicht nur für den Einsatz beim Online-Banking geeignet. Allerdings setzt es derzeit keine Bank ein. Abbildung 4.26 stellt den Kommunikationsablauf der TAN-basierten Variante des Verfahrens dar. Abbildung 4.26: Ablauf des WYSIWYS-Verfahrens 1. Der Kunde gibt die Transaktionsdaten in den Computer ein. 2. Die Daten werden auf dem Computerbildschirm angezeigt, und der Kunde kontrolliert die Daten auf dem Bildschirm. 3. Bei positivem Ergebnis macht der Kunde mit der Mobiltelefonkamera ein Foto vom Bildschirminhalt. Der Computer übermittelt die Daten per Bluetooth an das Mobiltelefon. 63 4 Legitimationsverfahren 4. Das Mobiltelefon vergleicht das Foto mit den elektronisch erhaltenen Daten. Im positiven Fall generiert es eine entsprechende dynamische TAN. Das Mobiltelefondisplay zeigt dem Benutzer dann diese TAN an. 5. Der Benutzer gibt die angegebene TAN in den Computer ein und schickt die Transaktion ab. 6. Der Computer überträgt die Transaktionsdaten und die dazu passende dynamische TAN an den Server der Bank. 7. Die Bank kontrolliert, ob die TAN zu den Transaktionsdaten passt und führt die Transaktion im positiven Fall durch. Analyse der Sicherheit Wird davon ausgegangen, dass das eingesetzte Mobiltelefon nicht manipuliert wurde, ist dieses Verfahren sicher vor Phishing- und MITM-Angriffen. Es stellt sich allerdings die Frage, ob es mit der heutigen Technik der Mobiltelefone, insbesondere ihrer Rechenleistung, möglich ist, den Datenvergleich schnell und zuverlässig durchzuführen. Vor allem Überweisungen beim Online-Banking könnten manipuliert werden, wenn sich Manipulationen bei einzelnen Ziffern und Kommata nicht sicher erkennen lassen. Aus einem Betrag von 00012,00 ¿ könnten so beispielsweise 80012,00 ¿ oder 0001200 ¿ werden. Diese kleinen Unterschiede müsste das Verfahren sicher erkennen, ohne dabei legitime Transaktionen zu behindern. Die Patentschrift enthält keine explizite Empfehlung, während der Kommunikation eine Nonce zu verwenden. Für die gleiche Transaktion würde somit immer die gleiche dynamische TAN generiert. Somit könnte ein Betrüger einen Replay-Angriff durchführen. Dies lässt sich leicht verhindern, indem Bank und Kamera einen gemeinsamen Zähler verwenden, der in die Berechnung der TAN mit einfließt und der sich nach jedem Gebrauch erhöht. Eine andere Möglichkeit, hier einen Replay-Angriff zu verhindern ist, die aktuelle Zeit mit in die Berechnung der TAN einfließen zu lassen. Analyse der Benutzerfreundlichkeit Das Verfahren lässt sich von jedem beliebigen PC einsetzen. Die KLM-Schritte des WYSIWYS-Verfahrens sind: Systemantwort abwarten (A), TANFunktion des Mobiltelefons aktivieren (T), Bildschirminhalt abfotografieren (G = 3 Sekunden), Antwort des Mobiltelefons abwarten (A), Transaktionsdaten prüfen (M), Taste zum Anzeigen der TAN drücken (T), TAN ablesen (M), zum Computer wechseln (W), auf das TAN-Eingabefeld klicken (K), sich an TAN erinnern (M), TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 8T + 2K + W + 3M + 2A + G = 18 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. 64 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” Analyse der Kosten Genau wie bei der Fotohandy-TAN aus Abschnitt 4.3.4 kann davon ausgegangen werden, dass für das WYSIWYS-Verfahren keine transaktions- oder kundenabhängigen Kosten anfallen. 4.4.2 HBCI-Verfahren FinTS ist ein vom ZKA (Zentraler Kreditausschuss) veröffentlichter Standard für sicheres Online-Banking [Zen06a]. Dieser Standard ist eine Weiterentwicklung des Homebanking Computer Interface (HBCI) und umfasst Spezifikationen zu Kommunikationsabläufen, zu Geschäftsvorfällen und zur Sicherheit. Banken können damit Online-Banking in einer standardisierten Weise anbieten. Über 2000 deutsche Banken bieten dies an [Zen06b]. Für Bankkunden gibt es viele Softwareprogramme, die FinTS unterstützen. Die Standardisierung erlaubt es also, dass Bankkunden gleich welcher Bank mit einem HomebankingProgramm ihrer Wahl arbeiten können. Im Rahmen der Spezifikation werden zwei verschiedene Legitimationsverfahren angeboten. FinTS PIN/TAN ist ein Verfahren, das auf Transaktionsnummern basiert. FinTS HBCI benutzt einen speziellen Kartenleser und eine Chipkarte, mit denen elektronische Signaturen erzeugt werden können. Die Spezifikation von FinTS PIN/TAN lässt Wahl des TAN-Verfahrens offen. Jede Bank kann sich selbst entscheiden, welche der oben beschriebenen TAN-Verfahren es im Rahmen des FinTS PIN/TAN anbietet. Daher wird an dieser Stelle nicht näher auf diesen Teil des Standards eingegangen. Zum Einsatz kommen vor allem die indizierte TAN, die mobile TAN und die elektronische, dynamische TAN. Für HBCI gibt es ebenfalls mehrere Betriebsmöglichkeiten. Bei der einfachsten und ältesten werden die elektronischen Signaturen direkt auf dem Rechner des Kunden erstellt. Der dazu nötige geheime Schlüssel befindet sich auf einem externen Speichermedium, üblicherweise auf einer Diskette oder einem USB-Stick. Weitere Verfahren benutzen Chipkartenleser und Chipkarten, auf denen der geheime Schlüssel gespeichert ist. Der Kommunkationsablauf des Verfahrens mit Schlüsseldiskette ist simpel (siehe Abbildung 4.27): Abbildung 4.27: Ablauf von HBCI mit Schlüsseldiskette 65 4 Legitimationsverfahren Bei den Chipkarten-Verfahren kommen verschiedene Chipkarten zum Einsatz. Die geheimen Schlüsel sind in dem Chip der Karte gespeichert. Kryptographische Funktionen wie Ver- und Entschlüsselung und Erstellung von Signaturen werden von dem in der Karte integrierten Mikroprozessor durchgeführt. Es gibt DES-Chipkarten, die auf der Two-key-triple-DES-Verschlüsselung beruhen. RSA-Chipkarten verwenden die asymmetrische RSA-Verschlüsselung. Die neuere ZKA Banken-Signaturkarte (auch SECCOSChipkarte genannt) benutzt ebenfalls die RSA-Verschlüsselung, kann daneben aber auch noch andere Funktionen wie z. B. elektronische Geldbörse oder einfache Datenspeicherung enthalten. All den Chipkarten ist gemein, dass die kryptographischen Funktionen innerhalb des Chips ablaufen. Die in ihnen gespeicherten geheimen Schlüssel lassen sich nicht direkt auslesen. Insbesondere können dadurch die Schlüssel auch nicht durch einen mit einem Trojaner infizierten Kundenrechner gestohlen werden. Ob ein MITM-Angriff bei Benutzung von HBCI mit Chipkarte möglich ist, hängt vom verwendeten Kartenleser ab. Der ZKA unterscheidet drei Klassen von Kartenlesern: einfache Kartenleser ohne weitere Ein- oder Ausgabemöglichkeit (Sicherheitsklasse 1, Abbildung 4.28), Kartenleser mit Zifferntastatur (Sicherheitsklasse 2, Abbildung 4.29) und Kartenleser mit Zifferntastatur und Display (Sicherheitsklasse 3, Abbildung 4.30). Abbildung 4.28: Chipkartenleser der Sicherheitsklasse 1; Quelle: Wikipedia Der Kommunikationsablauf bei einer Transaktion ist für die Chipkartenleser der Klasse 1 und 2 identisch mit dem Ablauf des HBCI-Verfahrens mit Schlüsseldiskette, nur dass die Unterschrift außerhalb des Rechners in dem Chip der Chipkarte erzeugt wird (Abbildung 4.31). Die Tastatur des Kartenlesers der Klasse 2 wird lediglich zur Eingabe einer PIN benutzt, die den Chip auf der Chipkarte am Anfang einer Online-Banking-Sitzung aktiviert. 1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein. 66 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” Abbildung 4.29: Chipkartenleser der Sicherheitsklasse 2; Quelle: Wikipedia Abbildung 4.30: Chipkartenleser der Sicherheitsklasse 3; Quelle: Wikipedia 67 4 Legitimationsverfahren Abbildung 4.31: Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 1 oder 2 2. Der Rechner schickt die Transaktionsdaten an den HBCI-Kartenleser. 3. Der Kunde gibt seine PIN in den Kartenleser ein, um die Signierfunktion der Chipkarte zu aktivieren. (entfällt bei Klasse 1) 4. Nach der Eingabe der korrekten PIN (entfällt bei Klasse 1) signiert der Kartenleser die Transaktionsdaten und sendet sie zurück an den Rechner. 5. Der Rechner leitet die signierten Transaktionsdaten an den Server der Bank. 6. Der Bankserver prüft die Gültigkeit der Signatur und führt die Transaktion gegebenenfalls durch. Chipkartenleser der Sicherheitsklasse 3 bieten durch ihr eingebautes Display theoretisch die Möglichkeit, Tansaktionsdaten vor dem Unterschreiben anzeigen zu lassen. Somit könnten Manipulationen, die auf einem trojanerbefallenen Kundenrechner stattfinden, auf dem sicheren Lesegerät entdeckt werden. Allerdings bieten die heutigen HBCIfähigen Online-Banking-Programme diese Überprüfungsmöglichkeit nicht an. Trotz der prinzipiellen Angriffsmöglichkeit ist es aber bislang noch zu keinem derartigen Betrugsfall gekommen.2 Theoretisch wäre folgender, sicherer Kommunikationsablauf möglich (Abbildung 4.32): 1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein. 2. Der Rechner schickt die Transaktionsdaten an den HBCI-Kartenleser. 3. Das Display des HBCI-Kartenlesers zeigt dem Kunden die Transaktionsdaten zur Kontrolle an. 2 Laut Aussage von Herrn Rauchbach, Mitarbeiters der Sicherheitsfirma Reiner SCT 68 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” Abbildung 4.32: Theoretisch möglicher Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 3 4. Wenn der Kunde die im Kartenleser angezeigte Transaktion durchführen möchte, gibt er zur Bestätigung seine PIN in den Kartenleser ein. 5. Der Kartenleser signiert nach der Eingabe der korrekten PIN die Transaktionsdaten und sendet sie zurück an den Rechner. 6. Der Rechner leitet die signierten Transaktionsdaten an den Server der Bank. 7. Der Bankserver prüft die Gültigkeit der Signatur und führt die Transaktion gegebenenfalls durch. Analyse der Sicherheit Das HBCI-Verfahren mit Schlüsseldiskette ist sicher vor einfachen Phishing-Angriffen, da es bei diesem Verfahren keine Transaktionsnummern gibt. Theoretisch könnte aber ein Benutzer dazu gebracht werden, die Datei, die den geheimen Schlüssel enthält sowie die dazugehörige PIN an einen Angreifer zu senden. Ein mit einem Trojaner befallener Kundenrechner stellt ein hohes Risiko dar: Es lässt sich dann nicht nur ein MITMAngriff durchführen, sondern auch der geheime Schlüssel der Schlüsseldiskette kann leicht ausgespäht werden und stünde damit für uneingeschränkte, betrügerische Transaktionen zur Verfügung. Das HBCI-Verfahren mit Kartenlesern der Klasse 1 und 2 ist sicher vor PhishingAngriffen, da keine Transaktionsnummern verwendet werden, die gestohlen werden könnten. Auch die geheimen Schlüssel können nicht entwendet werden, da sie nie die Chipkarte verlassen. Ein MITM-Angriff kann aber trotzdem noch unbemerkt ablaufen. Dabei ändert ein Trojaner auf dem Kundenrechner eine vom Kunden eingegebene Transaktion zu Gunsten des Angreifers. Diese manipulierte Transaktion wird von der HBCI- 69 4 Legitimationsverfahren Chipkarte signiert, ohne dass der Kunde die Möglichkeit hätte, die Manipulation zu bemerken. Dieser Angriff wird im Rahmen der formalen Sicherheitsanalyse auch von AVISPA gefunden. Die Anwendung des geschilderten HBCI-Verfahrens der Sicherheitsklasse 3 ist sicher vor Phishing- und MITM-Angriffen. Transaktionsnummern gibt es nicht. Die PIN verlässt den Kartenleser nicht. Der geheime Schlüssel verlässt zu keiner Zeit den Chip der Chipkarte. Ein Phisher kann also keine geheimen Daten erbeuten, die ihn befähigen würden, eine korrekt signierte, betrügerische Transaktion zu erstellen. Ein MITM-Angriff, der eine vom Kunden eingegebene Transaktion manipuliert, ist auch ausgeschlossen, wenn der Kunde sämtliche Transaktionsdetails im sicheren Display des Kartenlesers kontrolliert und wenn der Kartenleser korrekt funktioniert. Eine Sabotage des Lesers ist unwahrscheinlich. Der Leser wird normalerweise nur zu Hause eingesetzt und kann so weder unbemerkt ausgetausch noch verändert werden. Schadsoftware, die auf dem Kundenrechner installiert sein könnte, kann das Lesegerätes ebenfalls nicht umprogrammieren. Die Lesegeräte können zwar durch Firmware-Updates umprogrammiert werden, aber sie akzeptieren nur sichere, zertifizierte Updates. AVISPA findet für das spezifizierte HBCI 3-Verfahren keine Angriffe. Die speziellen Online-Banking-Programme erlauben es, mehrere Transaktionen zusammen auszuführen und nur einmal unterschreiben zu müssen. Dadurch werden die Verfahren aber eventuell unsicherer. Der Anwender kontrolliert bei Sammelüberweisungen nämlich nicht die einzelnen Transaktionsdaten, sondern nur eine Zusammenfassung. Diese Zusammenfassung kann laut dem FinTS-Standard beispielsweise aus der Summe der Kontonummern bestehen. Ein Angreifer könnte sich diese Tatsache zu Nutze machen, indem er zwei Überweisungen innerhalb einer Sammelüberweisung so manipuliert, dass die Summe der Kontonummern unverändert bleibt, aber eine Kontonummer der zwei manipulierten Überweisungen einen beliebig manipulierten Wert erhält. Deshalb und aus Gründen der besseren Vergleichbarkeit mit den anderen Verfahren wird hier davon ausgegangen, dass der Benutzer jede Transaktion einzeln signiert. Analyse der Benutzerfreundlichkeit Die hier beschriebenen HBCI-Verfahren setzen zum Betrieb eine spezielle Online-BankingSoftware und installierte Gerätetreiber für die Kartenleser voraus und können nicht von jedem beliebigen PC aus eingesetzt werden. Die KLM-Schritte des HBCI-Verfahrens mit Schlüsseldiskette und mit Chipkartenleser der Klasse 1 sind: Systemantwort abwarten (A), PIN-Eingabeaufforderung verstehen (M), zum Diskettenlaufwerk oder Kartenleser wechseln (W), Schlüsseldiskette oder Chipkarte einstecken (G = 5 Sekunden), zum Computer wechseln (W), auf das PINEingabefeld klicken (K), sich an die PIN erinnern (M), PIN eingeben (6T bei sechstelliger PIN), OK klicken (K). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 6T + 2K + 2W + 2M + A + G = 16 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. 70 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” Beim Verfahren mit dem einem Kartenleser der Klasse 2 gibt der Benutzer seine PIN direkt in den Kartenleser ein. Folgende Schritte durchläuft der Benutzer bei diesem Verfahren: Systemantwort abwarten (A), PIN-Eingabeaufforderung verstehen (M), zum Kartenleser wechseln (W), Chipkarte einstecken (G = 5 Sekunden), sich an die PIN erinnern (M), PIN eingeben (6T bei sechstelliger PIN), OK drücken (T). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 7T + W + 2M + A + G = 13,7 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Beim Verfahren mit einem Kartenleser der Klasse 3 muss der Benutzer zusätzlich die Transaktionsdaten im Display kontrollieren. Er führt folgende Schritte aus: Systemantwort abwarten (A), PIN-Eingabeaufforderung verstehen (M), zum Kartenleser wechseln (W), Chipkarte einstecken (G = 5 Sekunden), Transaktionsdaten kontrollieren (M), OK drücken (T), sich an die PIN erinnern (M), PIN eingeben (6T bei sechstelliger PIN), OK drücken (T). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 8T + W + 3M + A + G = 15,6 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens. Analyse der Kosten Im Rahmen des Online-Banking mit HBCI fallen Kosten für die Chipkarte, den Kartenleser und die verwendete Online-Banking-Software an. Die Deutsche Bank und die Dresdner Bank bieten die Chipkarte zu einem Preis von 10 ¿ an. Die günstgsten Chipkartenleser der Klasse 1 kosten bei amazon.de 11 ¿ (HBCI SMART Card Reader USB 2.0 Chip-Drive), die der Klasse 2 25 ¿ (SCM CHIPDRIVE Pinpad Pro A-TRUST) und die der Klasse 3 40 ¿ (KAAN Trib@nk von Kobil). Kommerzielle Online-BankingSoftware wie etwa WISO Mein Geld, Quicken oder StarMoney kosten ungefähr 50 ¿. Es gibt aber auch kostenlose Open-Source-Programme, zum Beispiel GnuCash. In den günstigsten Varianten kostet somit das HBCI-Verfahren mit Schlüsseldiskette nichts, das Verfahren der Sicherheitsklasse 1 einmalig 21 ¿, also etwa 8 Cent pro Transaktion, das der Klasse 2 35 ¿ oder 14 Cent pro Transaktion und das der Klasse 3 50 ¿ oder 20 Cent pro Transaktion. 4.4.3 Chipkarte mit Display Das als Patent eingereichte Verfahren und System zur Erhöhung der Sicherheit bei der ” Erstellung elektronischer Signaturen mittels Chipkarte“[Deu06a] funktioniert ähnlich wie das HBCI-Verfahren mit einem Kartenleser der Sicherheitsklasse 3. Transaktionsdaten werden von einer Chipkarte elektronisch signiert. Jenes Verfahren verwendet zur sicheren Anzeige der zu signierenden Daten ein auf der Chipkarte angebrachtes Display. Nach der Kontrolle der Daten kann der Benutzer durch Eingabe seiner PIN über eine Zifferntastatur des Lesegerätes die Signierfunktion des Chips aktivieren. Der Kommunikationsablauf ist analog zu dem des HBCI-Verfahrens mit einem Kartenleser der Klasse 3. Siehe hier zu die Abbildung 4.32. Die Abbildung 4.33 skizziert den 71 4 Legitimationsverfahren Einsatz der Display-Chipkarte. Abbildung 4.33: Skizze der Chipkarte mit Display im Einsatz; Quelle: [Deu06a] Die Patentschrift beinhaltet keine Details, wie eine solche Chipkarte mit integriertem Display hergestellt werden kann. Bislang benutzt keine Bank das in der Patentschrift vorgeschlagene Verfahren. Analyse der Sicherheit In puncto Sicherheit unterscheidet sich dieses Verfahren kaum vom genannten HBCIVerfahren. Der einzige relevante Unterschied besteht im Ort der Kontrollanzeige der Transaktionsdaten. Durch die Anzeige im Chip kann eine manipulierte Transaktion auch dann entdeckt werden, wenn der Kartenleser selbst kompromittiert worden ist. Dieses Verfahren könnte somit auch in nicht vertrauenswürdiger Umgebung eingesetzt werden, etwa in Geschäften oder Internet-Cafés. Die PIN des Benutzers ließe sich aber mit einem manipulierten Kartenleser immer noch abhören. So wäre es denkbar, dass ein Kunde zunächst eine korrekte Transaktion an einem betrügerischen Rechner mit einem angeschlossenen, betrügerischen Kartenleser durchführt und dabei seine PIN preisgibt. Anschließend könnte eine zweite, betrügerische Transaktion erstellt werden, die so schnell automatisch auf der noch eingesteckten Chipkarte mit Hilfe der kompromittierten PIN unterschrieben wird, dass der Benutzer die zweite Transaktion gar nicht bemerkt. Soll diese Angriffsmöglichkeit ausgeschaltet werden, so muß der Kunde entweder den Signiervorgang direkt auf der Karte bestätigen ein Knopfdruck würde hier ausreichen. Oder man erzwingt die Mitarbeit des Kunden durch eine Umstellung auf ein dynamisches TAN-Verfahren, bei dem der Kunde eine TAN vom Display der Chipkarte abliest und in den Rechner eingibt. 72 4.4 Schnittstellenklasse Bidirektional - Bidirektional“ ” Analyse der Benutzerfreundlichkeit Die Handhabung des Verfahrens, das auf der Chipkarte mit Display basiert, entspricht der des HBCI-Verfahrens der Klasse 3. Der einzige Unterschied besteht darin, dass sich das Display nicht im Kartenleser, sondern auf der Karte befindet, und dass der Benutzer für einen sicheren Betrieb einen Bestätigungsknopf auf der Karte drücken muss. Somit ist das Verfahren nicht mobil, und analog zur Ausführungszeit des HBCI-Verfahrens der Sicherheitsklasse 3 und zuzüglich eines Tastendrucks zur Bestätigung auf der Karte (T) ergeben sich für einen geübten Benutzer 16,1 Sekunden. Analyse der Kosten Da die Karte mit Display bislang noch nicht konkret realisiert wurde, ist es schwer, die Kosten hierfür zu schätzen. Die benötigte Hard- und Software ist ähnlich wie beim HBCI-Verfahren der Sicherheitsklasse 3, aber die Karte selbst wäre vermutlich teurer. HBCI-Chipkarten werden von den Banken für etwa 10 ¿ ausgegeben. Wenn man für eine Display-Chipkarte einen Preis von 20 ¿ annimmt, ergeben sich insgesamt Anschaffungskosten in Höhe von 60 ¿ oder 24 Cent pro Transaktion. 73 4 Legitimationsverfahren 74 5 Ergebnisse der Analyse Aus der Analyse der Online-Banking-Verfahren ergeben sich zunächst die geforderten Vergleichsmöglichkeiten. Darüberhinaus ließen sich bislang unbekannte Sicherheitslücken und mögliche Reparaturen finden. In diesem Kapitel werden die Ergebnisse des Vergleichs und weiterführende Ideen, die sich aus der Analyse ergaben, vorgestellt. 5.1 Interpretation der Ergebnisse Die vorgestellten Online-Banking-Verfahren unterscheiden sich teilweise deutlich hinsichtlich der analysierten Kriterien. So lagen beispielsweise die Transaktionskosten für das iTAN-Verfahren unter einem Cent pro Transaktion, für das HBCI 3-Verfahren aber bei 20 Cent pro Transaktion. Die benutzten Maße bieten somit eine hinreichende Trennschärfe, um die Verfahren untereinander vergleichen zu können. Im Rahmen der Sicherheitsanalyse kann man die gefundenen Ergebnisse grob in drei Klassen einteilen: Es gibt Verfahren, die bei einem kompromittierten Computer keine Sicherheit garantieren können. Insbesondere Manipulationen durch MITM-Angriffe können hiermit nicht verhindert werden. Weiter gibt es Verfahren, bei denen herkömmliche Phishing- und MITM-Angriffe erfolglos bleiben. Allerdings könnte ein Angriff wie in Abbildung 4.13 gezeigt bei einem gutgläubigen Anwender Erfolg haben, da die Art der Transaktion nicht manipuliersicher zum Anwender übertragen wird. Schließlich gibt es noch die Klasse an Verfahren, bei denen neben den Transaktionsdaten auch die Art der Transaktion für den Anwender zweifelsfrei erkannt werden kann. Die Klassen werden der Übersichtlichkeit halber in aufsteigender Sicherheitsreihenfolge Klasse C, B und A genannt. Die Darstellung der Benutzerfreundlichkeit anhand der KLM-Zeiten entspricht der eingangs formulierten Annahme, dass intuitiv bewertet kompliziertere Verfahren wie die Permutations-TAN oder die visuelle TAN einen hohen KLM-Zeitwert erhalten. Das in dieser Hinsicht schnellste Verfahren ist mit etwa 10 Sekunden der Monitor-Dongle. Demgegenüber steht das Permutations-TAN-Verfahren mit etwa 40 Sekunden auf dem letzten Platz. Die Ergebnisse der Analyse sind in der folgenden Tabelle 5.1 zusammengefasst. Wie in der Einleitung bereits geschrieben, stellen Online-Banking-Verfahren immer einen Kompromiss zwischen Sicherheit, Benutzerfreundlichkeit und Kosten dar. Es verblüfft daher nicht, dass es kein Verfahren gibt, das allen anderen in allen Kategorien überlegen ist. Diese Aussage lässt sich anschaulich auch mit der Abbildung 5.1 demons- 75 Transaktionskosten [Cent] Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nein Ja Nein Nein Nein Nein Nein Anschaffungskosten [Euro] C C C C C B A B B A B A A A A A C C C A A 15,4 15,9 5 12,9 5 15,2 18 26,1 12,25 16,3 20 19,3 15 40,4 21 22,8 27,8 18 20,5 30 10,2 40 18 16 16 21 13,7 35 15,6 50 16,1 60 0,6 2 2 0,6 0,6 5 8 6 1,5 10 3 3 0 12 16 0 0 8 14 20 24 KLM-Zeit [Sekunden] Mobilität Verfahren klassische TAN sm@rt TAN Bankey indizierte TAN indizierte TAN plus sm@rt TAN plus sm@rt TAN Flicker eTAN der BW Bank Permutations-TAN mobile TAN Cardano-TAN visuelle TAN Fotohandy-TAN InternetPassport Monitor-Dongle WYSIWYS HBCI Schlüsseldiskette HBCI Klasse 1 HBCI Klasse 2 HBCI Klasse 3 Chipkarte mit Display Sicherheitsklasse 5 Ergebnisse der Analyse Tabelle 5.1: Übersicht der Bewertung der Legitimationsverfahren 76 5.2 Empfehlungen für den Entwurf neuer Token trieren. So gibt es Verfahren, die zwar eine hohe Benutzerfreundlichkeit in Form eines niedrigen KLM-Wertes aufweisen, dafür aber überdurchschnittlich teuer sind, wie zum Beispiel HBCI 3 oder der Monitor-Dongle. Ideal wäre hier ein Verfahren, dass zur Sicherheitsklasse A gehört, mobil ist und im Diagramm möglichst weit unten links positioniert ist. Bewertet man die Werte der Transaktionskosten in Cent und die Werte der Ausführungszeit in Sekunden zu gleichen Gewichten, so schneiden Fotohandy-TAN und das WYSIWYS-Verfahren am besten ab. An dritter Stelle käme das in Vorbereitung befindliche sm@rtTANplus-Verfahren mit Flickercode. Alle drei Verfahren gehören zur Sicherheitskategorie A und sind mobil benutzbar. 5.2 Empfehlungen für den Entwurf neuer Token Aus der Analyse der Verfahren und deren Schwachstellen lassen sich einige DesignRichtlinien für den Entwurf neuer Token gewinnen, die sicher vor Phishing und MITMAngriffen sind. 1. Die Transaktionsdaten müssen in das Gerät gelangen. 2. Der Anwender muss die Transaktionsdaten im Gerät kontrollieren können, und zwar indem er die Daten direkt in das Gerät eingibt oder indem er sich die Daten auf einem sicheren Display anzeigen lässt. 3. Die TAN / Signatur und die Transaktionsdaten müssen miteinander verknüpft sein, so dass eine bestimmte TAN nur zu einer bestimmten Transaktion passt. Dazu kann die Bank die TAN erzeugen, zusammen mit den Transaktionsdaten zwischenspeichern und TAN und Transaktionsdaten abhör- und manipuliersicher zum Gerät übertragen. Oder das Gerät berechnet die Signatur / TAN unter Einbeziehung der Transaktionsdaten und eines geheimen Schlüssels selbst. 4. Zum Abschluss einer Transaktion muss das Verfahren die Interaktion zwischen Anwender und Gerät erzwingen. Das geht, indem der Anwender eine TAN im Gerät ablesen und in den Computer eingeben muss, indem der Anwender einen Bestätigungsknopf am Gerät drücken muss, oder indem er seine PIN in das Gerät eingeben muss. 5. Die Bedeutung der Daten soll Teil der Transaktionsdaten sein, und das Gerät soll die Bedeutung der Daten zusammen mit den Daten anzeigen. So kann der Anwender nicht über die Bedeutung der Daten getäuscht werden. 6. Die erzeugten TANs oder Signaturen sollen sich für identische Transaktionsdaten unterscheiden, um Replay-Angriffe zu verhindern. Die Verwendung von Nonces, Zeitstempeln oder Zählerständen kann das ermöglichen. 77 78 0 5 10 15 20 25 30 0 5 15 WYSIWYS20 Fotohandy-TAN 25 30 visuelle TAN sm@rt TAN plus Cardano-TAN eTAN der BW Bank sm@rt TAN Flicker mobile TAN InternetPassport Ausführungszeit [Sekunden] 10 Monitor-Dongle HBCI Klasse 3 Chipkarte mit Display 35 40 Permutations-TAN Sicherheitsklasse A Sicherheitsklasse B 45 5 Ergebnisse der Analyse Abbildung 5.1: Gegenüberstellung des Zeitbedarfs und der Kosten der MITMresistenten Verfahren Transaktionskosten [Cent] 5.3 Kriterien für sichere Online-Banking-Verfahren 7. Nach mehreren falschen Eingaben (üblicherweise drei) soll das Online-BankingSystem weitere Eingaben bis auf weiteres nicht mehr akzeptieren, um Brute-ForceAngriffe zu verhindern. Dazu kann der Zugang zum System mit der verwenderten Benutzerkennung für eine bestimmte Zeit, oder bis der Anwender sich persönlich mit seiner Bankfiliale in Verbindung gesetzt hat, gesperrt werden. 5.3 Kriterien für sichere Online-Banking-Verfahren Vergleicht man die Verfahren, die resistent gegen MITM-Angriffe sind, so lässt sich feststellen, dass die Sicherheit auf drei unterschiedliche Weisen erreicht werden kann. Die erste Möglichkeit ist die Verwendung eines Tokens, der aus Transaktionsdaten, einer Nonce und einem geheimen Schlüssel eine TAN generiert. Die Transaktionsdaten müssen dabei direkt in dem Gerät vom Anwender überprüft werden können. Der Prototyp dieses Protokolls ist das sm@rtTANplus-Verfahren, dass sich bereits in der formalen Sicherheitsanalyse bewährt hat. Token dieser Variant müssen also zur Klasse bidirek” tional - keine“ oder zu ausgehend - eingehend“ gehören. ” Die zweite Möglichkeit ist, ein Token zu nutzen, dass Nachrichten entschlüsseln kann. Dazu sendet der Anwender zunächst unverschlüsselte Transaktionsdaten zur Bank. Diese generiert eine zufällige TAN und speichert TAN und Daten intern ab. Außerdem sendet sie die Daten zusammen mit der TAN verschlüsselt an den Token zurück. Der Token entschlüsselt die Nachricht und präsentiert dem Anwender Transaktionsdaten und TAN. Ist der Anwender mit den Transaktionsdaten einverstanden, gibt er die TAN in sein Online-Banking-System ein und schickt sie zurück zur Bank. Der Prototyp dieser Variante ist das mobile TAN-Verfahren, das sich - nach kleiner Modifikation - ebenfalls in der formalen Sicherheitanalyse bewährt hat. Token dieser Variante gehören zur Klasse ausgehend - eingehend“. ” Die dritte Möglichkeit ist die Nutzung der digitalen Signatur. Diese Variante ähnelt der ersten, nur dass keine TAN erzeugt wird, die vom Anwender abgetippt werden muss, sondern eine digitale Signatur direkt vom Gerät ohne Umweg über den Anwender zusammen mit den Transaktionsdaten zur Bank geschickt wird. Hierbei muss der Anwender die Daten in dem Gerät kontrollieren können und die Signatur durch einen Knopfdruck am Gerät freigeben. Der Prototyp dieser Variante ist das HBCI-3-Verfahren, das auch den formalen Sicherheitstest von AVISTA überstanden hat. Die Token dieser Variante gehören zur Klasse bidirektional - bidirektional“. ” 79 5 Ergebnisse der Analyse 80 6 Zusammenfassung und Ausblick In dieser Arbeit wurden alte und neue Transaktions-Verfahren für das Online-Banking vorgestellt und formal spezifiziert. Die Verfahren wurden hinsichtlich der Benutzerfreundlichkeit, Kosten und Sicherheit im Bezug auf den Man-in-the-Middel-Angriff analysiert und verglichen. Dabei wurden auch Erkenntnisse zum Design neuer, sicherer Verfahren gewonnen. Außerdem wurden einige neue Angriffe entdeckt. Dieser Arbeit lagen einige Annahmen und Einschränkungen zugrunde. Nachfolgende Arbeiten könnten vor allem die Aspekte Benutzerfreundlichkeit und Kosten nicht nur analytisch, sondern auch empirisch untersuchen. Weiter wäre es wünschenswert, auch Möglichkeiten zu finden, Angriffe auf die Verfügbarkeit des Online-Baning-Services abzuwehren.Außerdem kann untersucht werden, welche indirekten Schäden bei Anwendern und Banken durch Betrug im Online-Banking resultieren, und ob die Einteilung der Banken in sicherheitkritische und nicht-sicherheitskritische Transaktionen sinnvoll gewählt wurde. 81 6 Zusammenfassung und Ausblick 82 Literaturverzeichnis [And93] Anderson, Ross: Why cryptosystems fail. In: CCS ’93: Proceedings of the 1st ACM conference on Computer and communications security, Seiten 215–227, New York, 1993. ACM. [AVI06] AVISPA Team: AVISPA v1.1 User Manual. http://www.avispa-project. org/package/user-manual.pdf, Juni 2006. [Online; Stand 22. August 2008]. [Bac05] Bachfeld, Daniel: Nepper, Schlepper, Bauernfänger: Risiken beim OnlineBanking. c’t, 22:148, 2005. [Bad07] Baden-Württembergische Bank: FAQ TAN-Generator. www. bw-bank.de/imperia/md/content/privatkunden/direktbanking/faq_ allg_tangenerator.pdf, April 2007. [Online; Stand 22. August 2008]. [BBK03] Barkan, Elad, Eli Biham und Nathan Keller: Instant ciphertext-only cryptanalysis of GSM encrypted communication. In: Advances in Cryptology – CRYPTO 2003, Seiten 600–616, Berlin, 2003. Springer. [Ber08] Berliner Sparkasse: chipTAN. http://www.berliner-sparkasse.de/ chiptan, Juli 2008. [Online; Stand 22. August 2008]. [BGB08] Bürgerliches Gesetzbuch in der Fassung der Bekanntmachung vom 2. Januar 2002 (BGBl. I S. 42, 2909; 2003 I S. 738), zuletzt geändert durch Artikel 1 des Gesetzes vom 4. Juli 2008 (BGBl. I S. 1188). 2008. [Bun07] Bundesverband Informationswirtschaft Telekommunikation und neue Medien e. V.: Zahl der Phishing-Opfer steigt in Deutschland weiter. http://www.bitkom.org/de/presse/43000_47739.aspx, August 2007. [Online; Stand 5. August 2008]. [CCS04] Cakir, Ahmet, Gisela Cakir und Peter Schäfer: Normative Anforderungen für IT-Produkte. Wirtschaftsverlag NW, Verlag für neue Wissenschaft, Berlin, 2004. [CMN83] Card, Stuart K., Thomas P. Moran und Allen Newell: The psychology of human-computer interaction. Erlbaum, Hillsdale, New Jersey, 1983. 83 Literaturverzeichnis [Deu06a] Deutsches Patent- und Markenamt: Offenlegungsschrift DE 10 2006 062 046 A1, 2006. [Deu06b] Deutsches Patent- und Markenamt: Patentschrift DE 10 2006 037 260 B3, 2006. [Deu08] Deutsche Bundesbank: Statistiken über den Zahlungsverkehr in Deutschland: 2002 - 2006. www.bundesbank.de/download/zahlungsverkehr/zv_ statistik.pdf, Januar 2008. [Online; Stand 5. August 2008]. [Fra04] Fraunhofer-Institut für Sichere Informationstechnologie SIT: Phishing-Schutz im Online-Banking: Hilfe zum Selbstschutz für Nutzer. www. sit.fraunhofer.de/Images/phishing_studie_04_tcm105-98166.pdf, 2004. [Online; Stand 27. August 2008]. [Gem07] Gemeinschaftsbank für Leihen und Schenken: Sm@rt TAN - Die häufigsten Fragen. http://www.gls.de/fileadmin/media/pdf_ onlinebanking/faq_smart_tan.pdf, 2007. [Online; Stand 10. August 2008]. [Gre07] Greveler, Ulrich: VTANs – Eine Anwendung visueller Kryptographie in der Online-Sicherheit. In: INFORMATIK 2007 - Informatik trifft Logistik Beiträge der 37. Jahrestagung der Gesellschaft für Informatik e.V. (GI) 24.27. September 2007 in Bremen (Band 2) Lecture Notes in Informatics, Band P-110, 2007. [hei06] heise security: Citibank würfelt nicht - Unsichere TANs bei der Citibank. http://www.heise.de/security/artikel/print/78939, Oktober 2006. [Online; Stand 5. August 2008]. [hei07] heise online: Verbessertes iTAN-Verfahren soll vor Manipulationen durch Trojaner schützen. http://www.heise.de/newsticker/meldung/print/ 98025, Oktober 2007. [Online; Stand 3. August 2008]. [HMT06] Hole, Kjell J., Vebjørn Moen und Thomas Tjøstheim: Case Study: Online Banking Security. IEEE Security and Privacy, 4:14–20, 2006. [Lan07] Landgericht Köln: Urteil 9 S 195/07 zum Phishing. http: //www.justiz.nrw.de/nrwe/lgs/koeln/lg_koeln/j2007/9_S_195_ 07urteil20071205.html, Dezember 2007. [Online; Stand 4. August 2008]. [NS95] Naor, Moni und Adi Shamir: Visual Cryptography. In: Advances in Cryptology – Eurocrypt ’94, Seiten 1–12, Berlin, 1995. Springer. 84 Literaturverzeichnis [REI08] REINERSCT: Schutz vor Trojanern: Neues chipTAN-Verfahren macht Homebanking sicher. http://www.reiner-sct.com/content/view/156/107/, Juni 2008. [Online; Stand 22. August 2008]. [RT03] Rusinowitch, Michael und Mathieu Turuani: Protocol insecurity with a finite number of sessions and composed keys is NP-complete. Theoretical Computer Science, 299:451–475, 2003. [Sie07] Siemens AG: Pressemitteilung. http://www.axsionics.com/tce/frame/ main/471.htm, 6. Dezember 2007. [Online; Stand 22. August 2008]. [Spi08] Spiegel Online: Banken haften für Schäden bei Phishing-Attacken. http: //www.spiegel.de/wirtschaft/0,1518,druck-563606,00.html, Juli 2008. [VAS02] VASCO Data Security International Inc.: Product Literature - Digipass 250. http://www.vasco.com/products/fetch.html?literature=46, 2002. [Online; Stand 22. August 2008]. [Vol07] Volksbank Bonn Rhein-Sieg: Anleitung Sm@rt-TAN plus-Leser. http: //www.vobaworld.de/privatkunden0/hilfe/internetbanking_faq.html, Juni 2007. [Online; Stand 22. August 2008]. [Vol08] Volksbank Lüneburg: Preis- und Leistungsverzeichnis. www. vblueneburg.de/etc/medialib/I500M0005/pdf.Par.0001.File.tmp/ PLV_29022008.pdf, Februar 2008. [Online; Stand 25. August 2008]. [Zen06a] Zentraler Kreditausschuss: Financial Transaction Services (FinTS) Security - Sicherheitsverfahren PIN/TAN inklusive Zwei-Schritt-TANVerfahren. http://www.hbci-zka.de/dokumente/spezifikation_deutsch/ FinTS_3.0_Security_Sicherheitsverfahren_PINTAN_Rel_20060209.pdf, Februar 2006. [Online; Stand 5. August 2008]. [Zen06b] Zentraler Kreditausschuss: Liste FinTS-fähiger Kreditinstitute. http://www.hbci-zka.de/institute/2006-12-31%20FinTS-faehige% 20Institute.pdf, 2006. [Online; Stand 2. August 2008]. 85 Literaturverzeichnis 86 Anhang A Formale Protokollspezifikationen in HLPSL Die folgenden formalen Protokollspezifikationen sind in der Beschreibungssprache HLPSL geschrieben. Jeder Spezifikation liegt das gleiche Grundmuster zugrunde. Für eine grobe Erläuterung dieses Musters und der HLPSL-Sprache siehe die mit % eingeleiteten Kommentare in der Spezifikation der indizierten TAN im folgenen Abschnitt A.1. Eine ausführliche Beschreibung von HLPSL findet sich im AVISPA-Benutzerhandbuch [AVI06]. Für alle Spezifikationen gilt die Annahme, dass der Angreifer vollständige Kontrolle über das Netzwerk und den Computer des Anwenders hat. Er kann also sämtliche unverschlüsselte Nachrichten lesen, verändern, unterdrücken und neue Nachrichten generieren. Außerdem wird angenommen, dass der Anwender sich bereits im Online-Banking-System angemeldet hat und der Angreifer somit beliebig im Namen des Anwenders mit der Bank kommunizieren kann. A.1 Indizierte TAN r o l e acustomer ( \% R o l l e n b e s c h r e i b u n g des B e n u t z e r s A, B, G : agent , Kga : symmetric \ key , \% d i e s e r S c h l u e s s e l d i e n t de r \% M o d e l l i e r u n g e i n e r s i c h e r e n Verbindung \% z w i s c h e n Benutzer und TAN−L i s t e ( l e i d e r \% u n t e r s t u e t z t HLPSL k e i n e s i c h e r e n Kanaele , \% daher d i e s e r Workaround ) . SND, RCV : c h a n n e l ( dy ) ) \% d i e Kanaele , ueber d i e d er \% Anwender mit d e r Bank und d er TAN−L i s t e kommuniziert played by A d e f= local State : nat , % P r o t o k o l l z u s t a n d , i n dem s i c h d e r Anwender % waehrend des P r o t o k o l l a b l a u f s b e f i n d e t 87 Anhang A Formale Protokollspezifikationen in HLPSL % ( S t a r t , a u f Index von de r Bank wartend , F e r t i g ) Tan : message , % Die TAN, d i e an d i e Bank g e s e n d e t wird Data , Index : t e x t % T r a n s a k t i o n s d a t e n und Indexnummer init S t a t e := 0 % d er Anfangszustand t r a n s i t i o n % Uebergangsregeln % Regel 0 : Sende am Anfang d i e T r a n s a k t i o n d a t e n % zu r Bank und warte a u f d i e Bankantwort 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> State ’:= 2 /\ Data ’ := new ( ) /\ SND( Data ’ ) % Witness bedeutet , d a s s de r Anwender mit den Daten von d er Banking % a u t h e n t i s i e r t werden moechte /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) % Regel 2 : Wenn d i e Bank e i n e Indexnummer z u r u e c k s c h i c k t , % suche d i e s e n Index a u f d er TAN−L i s t e 2 . S t a t e = 2 /\ RCV( Index ’ ) =|> State ’:= 4 /\ SND({ Index ’ } Kga ) % Regel 4 : Wenn d i e e n t s p r e c h e n d e TAN a u f d e r % TAN−L i s t e gefunden wurde , s c h i c k e d i e TAN % zu r Bank 4 . S t a t e = 4 /\ RCV({ Tan ’ } Kga ) =|> S t a t e ’ := 7 /\ SND( Data . Tan ’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e g e n e r a t o r ( % R o l l e n b e s c h r e i b u n g d er TAN−L i s t e A, B, G : agent , Ktan , Kga : symmetric key , % Kga d i e n t z u r M o d e l l i e r u n g des s i c h e r e n Kanals z w i s c h e n % Anwender und TAN−L i s t e , Ktan z u r M o d e l l i e r u n g d er v o r h e r % pe r P a p i e r l i s t e u e b e r m i t t e l t e n TAN. Die TAN−L i s t e l i e f e r t % so e i n e zum Index p a s s e n d e TAN. Der Workaround b e s t e h t hier % d a r i n , d a s s d i e TAN l e d i g l i c h e i n e n S c h l u e s s e l Ktan kennt 88 A.1 Indizierte TAN , mit % dem TANs anhand von Indexnummern e r z e u g t werden koennen . SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y G d e f= local S t a t e : nat , Index : t e x t init S t a t e := 3 transition % Regel 3 : L i e f e r e f u e r e i n e n Index d i e p a s s e n d e TAN zurueck 3 . S t a t e = 3 /\ RCV({ Index ’ } Kga ) =|> State ’:= 6 /\ SND({{ Index ’ } Ktan } Kga ) % Tan i s { Index ’ } Ktan end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e bank ( % d i e R o l l e d er Bank A, B,G : agent , % d i e Bank kennt d i e TAN−L i s t e Ktan : symmetric key , % b e z i e h u n g s w e i s e den S c h l u e s s e l z ur TAN−Erzeugung SND,RCV : c h a n n e l ( dy ) ) played by B d e f= local S t a t e : nat , Data , Index : t e x t init S t a t e := 1 transition % Regel 1 : Wenn T r a n s a k t i o n s d a t e n empfangen werden , % sende e i n e n z u f a e l l i g e n , noch n i c h t b e n u t z t e n Index 1 . S t a t e = 1 /\ RCV( Data ’ ) =|> S t a t e ’ := 5 /\ Index ’ := new ( ) /\ SND( Index ’ ) % Regel 5 : Wenn d i e e r w a r t e t e n T r a n s a k t i o n s d a t e n % zusammen mit e i n e r TAN kommen , p r u e f e , ob d i e TAN % g u e l t i g i s t und a u t h e n t i s i e r e Anwender und Daten . 5 . S t a t e = 5 /\ RCV( Data . { Index } Ktan ) =|> State ’:= 8 % Request bedeutet , d a s s d i e Bank den B e t e i l i g t e n A mit den 89 Anhang A Formale Protokollspezifikationen in HLPSL % Daten Data a u t h e n t i s i e r t . Genau dann , wenn d i e Elemte von request % mit den Elementen von w i t n e s s uebereinstimmen , wird das % Sicherheitsziel erreicht . /\ r e q u e s t (B, A, bank acustomer T , Data ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e s e s s i o n ( % die Beschreibung e i n e r e i n z e l n e n Sitzung A, B, G : agent , Ktan , Kga : symmetric key ) d e f= local SA , RA, SB , RB, SG, RG : c h a n n e l ( dy ) composition % Eine S i t z u n g b e s t e h t aus genau einem Kunden , % e i n e r Bank und e i n e r TAN−L i s t e acustomer (A, B, G, Kga , SA , RA) /\ bank (A, B, G, Ktan , SB , RB) /\ g e n e r a t o r (A, B, G, Ktan , Kga , SG, RG) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e environment ( ) % B e s c h r e i b u n g de r Gesamtumgebung d e f= const bank acustomer T : p r o t o c o l i d , ktan1 , ktan2 , k t a n i , kga , k g i : symmetric key , % a i s t d er Anwender , b1 und b2 s i n d zwe i v e r s c h i e d e n e % Banken , b e i denen a Kunde i s t , g1 und g2 d i e % e n t s p r e c h e n d e n TAN−L i s t e n , und g i d i e TAN−L i s t e % des A n g r e i f e r s a , b1 , b2 , g1 , g2 , g i : agent % Das Wissen des A n g r e i f e r s : Er kennt a , b1 , b2 , s e i n e % TAN−L i s t e und den S c h l u e s s e l , mit dem e r s i c h e r mit letzterer % kommunizieren kann 90 A.2 Sm@rtTanplus i n t r u d e r k n o w l e d g e = {a , b1 , b2 , g i , k g i } % Es werden h i e r s t e t s v i e r p a r a l l e l l a u f e n d e S i t z u n g e n untersucht composition s e s s i o n ( a , b1 , g1 , ktan1 , kga ) % e r s t e S i t z u n g von a und b1 /\ s e s s i o n ( a , b1 , g1 , ktan1 , kga ) % z w e i t e S i t z u n g von a und b1 /\ s e s s i o n ( a , b2 , g2 , ktan2 , kga ) % S i t z u n g von a und e i n e r anderen Bank b2 /\ s e s s i o n ( i , b1 , g i , k t a n i , k g i ) % S i t z u n g vom A n g r e i f e r und b1 end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % das S i c h e r h e i t s z i e l d i e s e s V e r f a h r e n s goal % Die Bank s o l l den Kunden mit den Ueberweisungsdaten authentisieren . a u t h e n t i c a t i o n o n bank acustomer T end g o a l %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% environment ( ) A.2 Sm@rtTanplus r o l e acustomer ( A, B, G : agent , Kgb , Kga : symmetric key , SND, RCV : c h a n n e l ( dy ) ) played by A d e f= local State : nat , TAN : message , Data , Code : t e x t c o n s t bank acustomer T : p r o t o c o l i d init S t a t e := 0 transition 91 Anhang A Formale Protokollspezifikationen in HLPSL 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> State ’:= 2 /\ Data ’ := new ( ) /\ SND( Data ’ ) /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) 2 . S t a t e = 2 /\ RCV( Code ’ ) =|> State ’:= 4 /\ SND({ Code ’ . Data} Kga ) 4 . S t a t e = 4 /\ RCV({TAN’ } Kga ) =|> State ’:= 7 /\ SND(TAN’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role generator ( A, B, G : agent , Kgb , Kga : symmetric key , SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y G d e f= local S t a t e : nat , TAN : message , Data , Code : t e x t init S t a t e := 3 transition 3 . S t a t e = 3 /\ RCV({ Code ’ . Data ’ } Kga ) =|> State ’:= 6 /\ TAN’ : = {Code ’ . Data ’ } Kgb /\ SND({TAN’ } Kga ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e bank ( A, B,G : agent , Kgb , Kga : symmetric key , SND,RCV : c h a n n e l ( dy ) ) played by B d e f= local S t a t e : nat , TAN : message , Data , Code : t e x t 92 A.2 Sm@rtTanplus init S t a t e := 1 transition 1 . S t a t e = 1 /\ RCV( Data ’ ) =|> State ’:= 5 /\ Code ’ : = new ( ) /\ TAN’ : = {Code ’ . Data ’ } Kgb /\ SND( Code ’ ) 5 . S t a t e = 5 /\ RCV(TAN) =|> State ’:= 8 /\ r e q u e s t (B, A, bank acustomer T , Data ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role session ( A, B, G : agent , Kgb , Kga : symmetric key ) d e f= local SA , RA, SB , RB, SG, RG : c h a n n e l ( dy ) composition acustomer (A, B, G, Kgb , Kga , SA , RA) /\ bank (A, B, G, Kgb , Kga , SB , RB) /\ g e n e r a t o r (A, B, G, Kgb , Kga , SG, RG) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e environment ( ) d e f= const bank acustomer T : p r o t o c o l i d , kgb1 , kgb2 , kga1 , kga2 , k g i : symmetric key , a , b1 , b2 , g1 , g2 , g i : agent i n t r u d e r k n o w l e d g e = {a , b1 , b2 , g i , kgbi , k g i } composition s e s s i o n ( a , b1 , g1 , kgb1 , kga1 ) /\ s e s s i o n ( a , b1 , g1 , kgb1 , kga1 ) /\ s e s s i o n ( a , b2 , g2 , kgb2 , kga2 ) 93 Anhang A Formale Protokollspezifikationen in HLPSL /\ s e s s i o n ( i , b1 , g i , kgbi , k g i ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% goal a u t h e n t i c a t i o n o n bank acustomer T end g o a l %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% environment ( ) A.3 Mobile TAN r o l e mobile ( A, B,M: agent , Kmb, Kma: symmetric key , SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y M d e f= local State : nat , Data , TAN : text init S t a t e := 2 transition 2 . S t a t e = 2 /\ RCV({ Data ’ . TAN’ } Kmb) =|> S t a t e ’ := 5 /\ SND({ Data ’ . TAN’ } Kma) end r o l e r o l e acustomer ( A, B,M : agent , Kma : symmetric key , SND,RCV : c h a n n e l ( dy ) ) p l a y e d b y A d e f= local State : nat , Data , TAN : text init S t a t e := 0 transition 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> State ’:= 3 94 A.3 Mobile TAN /\ Data ’ := new ( ) /\ SND( Data ’ ) /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) 3 . S t a t e = 3 /\ RCV({ Data .TAN’ } Kma) =|> State ’:= 6 /\ SND(TAN’ ) % change t o . . . Data ’ . . . t o show % an a t t a c k due t o an u n p e r c e p t i v e u s e r end r o l e r o l e bank ( A, B,M : agent , Kmb : symmetric key , SND,RCV : c h a n n e l ( dy ) ) p l a y e d b y B d e f= local State : nat , Data , TAN : text init S t a t e := 1 transition 1 . S t a t e = 1 /\ RCV( Data ’ ) =|> State ’:= 4 /\ TAN’ := new ( ) /\ SND({ Data ’ . TAN’ } Kmb) 4 . S t a t e = 4 /\ RCV(TAN) =|> State ’:= 7 /\ r e q u e s t (B, A, bank acustomer T , Data ) end r o l e role session ( A, B,M : agent , Kma,Kmb : symmetric key ) d e f= local SA , RA, SB , RB, SM, RM: c h a n n e l ( dy ) composition acustomer (A, B, M, Kma, SA , RA) /\ bank (A, B, M, Kmb, SB , RB) /\ mo bile (A, B, M, Kmb, Kma, SM, RM) end r o l e r o l e environment ( ) 95 Anhang A Formale Protokollspezifikationen in HLPSL d e f= const bank acustomer T : p r o t o c o l i d , kma1 , kmb1 , kmb2 , kmbi , kmi : symmetric key , a , b1 , b2 , m1, mi : agent i n t r u d e r k n o w l e d g e = {a1 , b1 , b2 , m1, m2, kmi} % add kmb1 o r kma1 t o show an a t t a c k due t o % i n s e c u r e SMS r e l a y o r due t o a compromised mobile phone composition s e s s i o n ( a , b1 , m1, kmb1 , kma1 ) /\ s e s s i o n ( a , b1 , m1, kmb1 , kma1 ) /\ s e s s i o n ( a , b2 , m1, kmb2 , kma1 ) /\ s e s s i o n ( i , b1 , mi , kmbi , kmi ) end r o l e goal a u t h e n t i c a t i o n o n bank acustomer T end g o a l environment ( ) A.4 Fotohandy-TAN r o l e acustomer ( A, B, G : agent , Kga : symmetric key , SND, RCV : c h a n n e l ( dy ) ) played by A d e f= local State : nat , TAN : message , Data , Code : t e x t init S t a t e := 1 transition 1 . S t a t e = 1 /\ RCV( Code ’ ) =|> State ’:= 3 /\ Data ’ := new ( ) /\ SND( Code ’ . Data ’ ) /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) 3 . S t a t e = 3 /\ RCV({ Data .TAN’ } Kga ) =|> State ’:= 6 96 A.4 Fotohandy-TAN /\ SND( Data .TAN’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role generator ( A, B, G : agent , Kgb , Kga : symmetric key , SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y G d e f= local S t a t e : nat , TAN : message , Data , Code : t e x t init S t a t e := 2 transition 2 . S t a t e = 2 /\ RCV( Code ’ . Data ’ ) =|> State ’:= 5 /\ TAN’ : = {Code ’ . Data ’ } Kgb /\ SND({ Data ’ . TAN’ } Kga ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e bank ( A, B,G : agent , Kgb : symmetric key , SND,RCV : c h a n n e l ( dy ) ) played by B d e f= local S t a t e : nat , TAN : message , Data , Code , Egal : t e x t init S t a t e := 0 transition 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> S t a t e ’ := 4 /\ Code ’ := new ( ) /\ SND( Code ’ ) 4 . S t a t e = 4 /\ RCV( Data ’ . TAN’ ) /\ TAN’ = {Code . Data ’ } Kgb =|> State ’:= 7 97 Anhang A Formale Protokollspezifikationen in HLPSL /\ r e q u e s t (B, A, bank acustomer T , Data ’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role session ( A, B, G : agent , Kgb , Kga : symmetric key ) d e f= local SA , RA, SB , RB, SG, RG : c h a n n e l ( dy ) composition acustomer (A, B, G, Kga , SA , RA) /\ bank (A, B, G, Kgb , SB , RB) /\ g e n e r a t o r (A, B, G, Kgb , Kga , SG, RG) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e environment ( ) d e f= const bank acustomer T : p r o t o c o l i d , kgb1 , kgb2 , kga , kgbi , k g i : symmetric key , a , b1 , g1 , g i : agent i n t r u d e r k n o w l e d g e = {a , b1 , b2 , g1 , g i , kgbi , k g i } composition s e s s i o n ( a , b1 , g1 , kgb1 , kga ) /\ s e s s i o n ( a , b1 , g1 , kgb1 , kga ) /\ s e s s i o n ( a , b2 , g1 , kgb2 , kga ) /\ s e s s i o n ( i , b1 , g i , kgbi , k g i ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% goal a u t h e n t i c a t i o n o n bank acustomer T end g o a l %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 98 A.5 HBCI 2 environment ( ) A.5 HBCI 2 r o l e acustomer ( A, B, G : agent , Kga : symmetric key , SND, RCV : c h a n n e l ( dy ) ) played by A d e f= local State : nat , TAN : message , Data , Code , Ng : t e x t init S t a t e := 1 transition 1 . S t a t e = 1 /\ RCV( Code ’ ) =|> State ’:= 3 /\ Data ’ := new ( ) /\ SND( Code ’ . Data ’ ) /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) 3 . S t a t e = 3 /\ RCV({Ng ’ . A} Kga ) =|> State ’:= 6 /\ SND({Ng ’ . G} Kga ) % A i s p r e s s i n g OK end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role generator ( A, B, G : agent , Kg : p u b l i c k e y , Kga : symmetric key , SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y G d e f= local S t a t e : nat , Data , Code , Ng : t e x t init S t a t e := 2 transition 2 . S t a t e = 2 /\ RCV( Code ’ . Data ’ ) =|> State ’:= 4 /\ Ng ’ := new ( ) /\ SND({Ng ’ . A} Kga ) % Should mean : P l e a s e push OK 99 Anhang A Formale Protokollspezifikationen in HLPSL 4 . S t a t e = 4 /\ RCV({Ng .G} Kga ) =|> State ’:= 7 /\ SND({ Code . Data} i n v (Kg) ) % A p r e s s e d OK end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e bank ( A, B,G : agent , Kg : p u b l i c k e y , SND,RCV : c h a n n e l ( dy ) ) played by B d e f= local S t a t e : nat , Data , Code , Egal : t e x t init S t a t e := 0 transition 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> S t a t e ’ := 5 /\ Code ’ := new ( ) /\ SND( Code ’ ) 5 . S t a t e = 5 /\ RCV( Egal ’ ) /\ Egal ’= {Code . Data ’ } i n v (Kg) =|> S t a t e ’ : = 8 /\ r e q u e s t (B, A, bank acustomer T , Data ’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role session ( A, B, G : agent , Kg : p u b l i c k e y , Kga : symmetric key ) d e f= local SA , RA, SB , RB, SG, RG : c h a n n e l ( dy ) composition acustomer (A, B, G, Kga , SA , RA) /\ bank (A, B, G, Kg , SB , RB) /\ g e n e r a t o r (A, B, G, Kg , Kga , SG, RG) end r o l e 100 A.6 HBCI 3 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e environment ( ) d e f= const bank acustomer T : p r o t o c o l i d , kp1 , kp2 , k p i : public key , kga , k g i : symmetric key , a , b1 , b2 , g1 , g2 , g i : agent i n t r u d e r k n o w l e d g e = {a , b1 , b2 , g i , k g i } composition s e s s i o n ( a , b1 , g1 , kp1 , kga ) /\ s e s s i o n ( a , b1 , g1 , kp1 , kga ) /\ s e s s i o n ( a , b2 , g2 , kp2 , kga ) /\ s e s s i o n ( i , b1 , g i , kpi , k g i ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% goal a u t h e n t i c a t i o n o n bank acustomer T end g o a l %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% environment ( ) A.6 HBCI 3 r o l e acustomer ( A, B, G : agent , Kga : symmetric key , SND, RCV : c h a n n e l ( dy ) ) played by A d e f= local State : nat , Data , Ng : t e x t init S t a t e := 0 transition 0 . S t a t e = 0 /\ RCV( s t a r t ) =|> 101 Anhang A Formale Protokollspezifikationen in HLPSL State ’:= 2 /\ Data ’ := new ( ) /\ SND( Data ’ ) /\ w i t n e s s (A, B, bank acustomer T , Data ’ ) 2 . S t a t e = 2 /\ RCV({B . Ng ’ . Data} Kga ) =|> State ’:= 7 /\ SND({Ng ’ } Kga ) % A c h e c k s data and e n t e r s PIN end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role generator ( A, B, G : agent , Kg : p u b l i c k e y , Kga : symmetric key , SND, RCV: c h a n n e l ( dy ) ) p l a y e d b y G d e f= local S t a t e : nat , Data , Code , Ng : t e x t init S t a t e := 1 transition 1 . S t a t e = 1 /\ RCV( Data ’ ) =|> State ’:= 3 /\ Ng ’ := new ( ) /\ SND({B . Ng ’ . Data ’ } Kga ) % Should mean : P l e a s e check Data and e n t e r PIN 3 . S t a t e = 3 /\ RCV({Ng} Kga ) =|> State ’:= 5 /\ SND(B) 5 . S t a t e = 5 /\ RCV( Code ’ ) =|> S t a t e ’ := 8 /\ SND({B . Code ’ . Data} i n v (Kg) ) % A e n t e r e d PIN end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e bank ( A, B,G : agent , Kg : p u b l i c k e y , SND,RCV : c h a n n e l ( dy ) ) 102 A.6 HBCI 3 played by B d e f= local S t a t e : nat , Data , Code : t e x t init S t a t e := 4 transition 4 . S t a t e = 4 /\ RCV(B) =|> S t a t e ’ := 6 /\ Code ’ := new ( ) /\ SND( Code ’ ) % S i n c e I cannot model c o u n t e r s i n HLPSL, % I use t h i s nonce−workaround 6 . S t a t e = 6 /\ RCV({B . Code . Data ’ } i n v (Kg) ) =|> State ’:= 9 /\ r e q u e s t (B, A, bank acustomer T , Data ’ ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% role session ( A, B, G : agent , Kg : p u b l i c k e y , Kga : symmetric key ) d e f= local SA , RA, SB , RB, SG, RG : c h a n n e l ( dy ) composition acustomer (A, B, G, Kga , SA , RA) /\ bank (A, B, G, Kg , SB , RB) /\ g e n e r a t o r (A, B, G, Kg , Kga , SG, RG) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% r o l e environment ( ) d e f= const bank acustomer T : p r o t o c o l i d , kp1 , kp2 , k p i : public key , kga , k g i : symmetric key , 103 Anhang A Formale Protokollspezifikationen in HLPSL % Only used t o s i m u l a t e a s e c u r e c h a n n e l % between c a r d r e a d e r and customer a , b1 , b2 , g1 , g2 , g i : agent i n t r u d e r k n o w l e d g e = {a , b1 , b2 , g i , k g i } composition s e s s i o n ( a , b1 , g1 , kp1 , kga ) /\ s e s s i o n ( a , b1 , g1 , kp1 , kga ) /\ s e s s i o n ( a , b2 , g2 , kp2 , kga ) /\ s e s s i o n ( i , b1 , g i , kpi , k g i ) end r o l e %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% goal a u t h e n t i c a t i o n o n bank acustomer T end g o a l %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% environment ( ) 104 Anhang B Ausgaben von AVISPA Die Ausführbarkeit der Protokollspezifikationen aus Anhang A wurde zunächst mit dem Programmaufruf avispa –ofmc -sessco überprüft. Diese Überprüfung ist wichtig, da AVISPA für nicht ausführbare Protokolle auch keinen Angriff findet und sie somit in jedem Fall als sicher einstuft. Anschließend wurde mit dem Programmaufruf avispa –cl-atse -ns -short die Einhaltung des Sicherheitsziels überprüft. Die Option -ns verhindert, dass AVISPA die Spezifikation vor der Auswertung vereinfacht. In einigen Fällen wurden bei eingeschalteter Vereinfachung ein unsicheres Verfahren als sicher eingestuft. Die Option -short veranlasst AVISPA, eine möglichst kurze Angriffsfolge zu finden. Im folgenden finden sich die Resultate dieser Aufrufe mit kurzen Erläuterungen. Falls AVISPA einen Verstoß gegen das definierte Sicherheitsziel findet, stuft es das Modell als unsicher ein und beschreibt die Abfolge der Protokollschritte des Angriffs. B.1 indizierte TAN Wie bereits in Abschnitt 4.2.1 geschildert ist das indizierte TAN-Verfahren unsicher bei kompromittiertem Anwenderrechner. Der oben beschriebene MITM-Angriff findet sich in der folgende AVISPA-Ausgabe wieder. SUMMARY UNSAFE DETAILS ATTACK FOUND TYPED MODEL PROTOCOL .// t e s t s u i t e / r e s u l t s / protokollitan . txt . i f GOAL A u t h e n t i c a t i o n a t t a c k on ( a . b2 . bank acustomer T . Data ( 3 1 ) ) 105 Anhang B Ausgaben von AVISPA BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 3648 1914 0.02 0.83 states states seconds seconds ATTACK TRACE i −> ( b2 , 1 2 ) : ( b2 , 1 2 ) −> i : Data ( 3 1 ) n31 ( Index ) i −> ( a , 3 ) : ( a , 3 ) −> i : start n1 ( Data ) & Witness ( a , b1 , bank acustomer T , n1 ( Data ) ) ; i −> ( a , 3 ) : ( a , 3 ) −> i : n31 ( Index ) { n31 ( Index ) } kg a i −> ( g2 , 1 3 ) : ( g2 , 1 3 ) −> i : i −> ( a , 3 ) : ( a , 3 ) −> i : i −> ( b2 , 1 2 ) : ( b2 , 1 2 ) −> i : { n31 ( Index ) } kg a {{ n31 ( Index ) } k t a n 2 } kg a {{ n31 ( Index ) } k t a n 2 } kg a n1 ( Data ) . { n31 ( Index ) } k t a n 2 Data ( 3 1 ) . { n31 ( Index ) } k t a n 2 () & Request ( b2 , a , bank acustomer T , Data ( 3 1 ) ) ; Der beschriebene Angriff läuft wie folgt ab: Zunächst sendet der Angreifer i betrügerische Überweisungsdaten Data(31) an den Bankserver b2. Die Angabe (b2,12) bedeutet, dass der Bankserver b2 diese Sitzung mit der Nummer 12 bezeichnet. So kann zwischen verschiedenen, parallel ablaufenden Sitzungen unterchieden werden. Er sendet dann eine Indexnummer zurück. Nun wartet der Angreifer darauf, dass der Anwender eine Überweisung eingibt. Sobald er dies tut, unterdrückt der Angreifer die Weiterleitung der Daten an die Bank und sendet stattdessen im Namen der Bank die vorher erhaltene Indexnummer an den Anwender. Der sucht auf seiner iTAN-Liste nach der passenden Transaktionsnummer und schickt diese an die Bank. Der Anwender glaubt, die Bank 106 B.2 Sm@rtTanplus führe damit seinen Auftrag aus. In Wirklichkeit aber führt sie den vom Angreifer eingereichten Auftrag aus. B.2 Sm@rtTanplus AVISPA stuft das sm@rtTANplus-Verfahren als sicher im Rahmen der Protokollspezifikationen ein: SUMMARY SAFE DETAILS BOUNDED NUMBER OF SESSIONS TYPED MODEL PROTOCOL . / / t e s t s u i t e / r e s u l t s / protokollsmartTANplus . t x t . i f GOAL As S p e c i f i e d BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 139881 s t a t e s 45958 s t a t e s 0.00 seconds 35.39 seconds B.3 Mobile TAN AVISPA findet für das mobile TAN-Verfahren eine Angriffmöglichkeit. Man beachte den Unterschied in der Witness- und der Request-Angabe: Der Anwender möchte sich von der Bank b1 authentisieren, in Wirklichkeit wird er aber von b2 authentisiert. SUMMARY UNSAFE DETAILS 107 Anhang B Ausgaben von AVISPA ATTACK FOUND TYPED MODEL PROTOCOL . / / t e s t s u i t e / r e s u l t s /mTANns . i f GOAL A u t h e n t i c a t i o n a t t a c k on ( a . b1 . bank acustomer T . n21 ( Data ) ) BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 6144 2449 0.00 0.21 states states seconds seconds ATTACK TRACE i −> ( a , 1 1 ) : ( a , 1 1 ) −> i : start n21 ( Data ) & Witness ( a , b2 , bank acustomer T , n21 ( Data ) ) ; i −> ( b1 , 4 ) : ( b1 , 4 ) −> i : n21 ( Data ) { n21 ( Data ) . n5 (TAN) } kma1 i −> (m1, 1 3 ) : (m1, 1 3 ) −> i : { n21 ( Data ) . n5 (TAN) } kma1 { n21 ( Data ) . n5 (TAN) } kmb2 i −> ( a , 1 1 ) : ( a , 1 1 ) −> i : { n21 ( Data ) . n5 (TAN) } kmb2 n5 (TAN) i −> ( b1 , 4 ) : ( b1 , 4 ) −> i : n5 (TAN) () & Request ( b1 , a , bank acustomer T , n21 ( Data ) ) ; Der festgestellte Angriff läuft wie folgt ab: Der Kunde möchte einen Transaktionsauftrag bei der Bank b2 einreichen und versendet die entsprechenden Transaktionsdaten. Der Angreifer schickt die Daten allerdings nicht zu b2, sondern zu b1, einer Bank, bei der der 108 B.4 Fotohandy-TAN Anwender ebenfalls Kunde ist. Die Bank b1 sendet dem Anwender daraufhin eine SMS mit den Transaktionsdaten und einer Transaktionsnummer. Der Anwender erhält die erwarteten Daten und sendet die TAN vermeintlich an b2. Der Angreifer leitet aber die TAN um zur Bank b1, die dann den Auftrag ausführt. Diese Sicherheitslücke resultiert daraus, dass der Anwender nicht kontrollieren kann, welche Bank ihm die SMS geschickt hat beziehungsweise auf welches seiner Konten sich der Auftrag bezieht. Auch wenn diese Sicherheitslücke zunächst unkritisch erscheint, so lässt sich doch ein Angriff konstruieren, der dem Kunden tatsächlich schadet (siehe 4.3.1). B.4 Fotohandy-TAN Das Fotohandy-TAN-Verfahren wird von AVISPA als sicher eingestuft. SUMMARY SAFE DETAILS BOUNDED NUMBER OF SESSIONS TYPED MODEL PROTOCOL .// t e s t s u i t e / r e s u l t s / protokollfotoTAN . txt . i f GOAL As S p e c i f i e d BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 153386 s t a t e s 353186479 s t a t e s 0.04 seconds 36.35 seconds B.5 HBCI 2 Avispa findet erwartungsgemäß die in Abschnitt 4.4.2 beschriebene Sicherheitslücke. SUMMARY 109 Anhang B Ausgaben von AVISPA UNSAFE DETAILS ATTACK FOUND TYPED MODEL PROTOCOL .// t e s t s u i t e / r e s u l t s / protokollhbci2 . txt . i f GOAL A u t h e n t i c a t i o n a t t a c k on ( a . b1 . bank acustomer T . Data ( 1 8 ) ) BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 281 s t a t e s 120 s t a t e s 0.02 seconds 0.01 seconds ATTACK TRACE i −> ( b1 , 1 6 ) : ( b1 , 1 6 ) −> i : start n37 ( Code ) i −> ( b2 , 1 2 ) : ( b2 , 1 2 ) −> i : start n29 ( Code ) i −> ( b1 , 8 ) : ( b1 , 8 ) −> i : start n17 ( Code ) i −> ( b1 , 4 ) : ( b1 , 4 ) −> i : start n5 ( Code ) i −> ( g1 , 5 ) : ( g1 , 5 ) −> i : n17 ( Code ) . Data ( 1 8 ) {n9 (Ng) . a} kg a i −> ( a , 7 ) : ( a , 7 ) −> i : 110 Code ( 1 3 ) Code ( 1 3 ) . n13 ( Data ) B.6 HBCI 3 & Witness ( a , b1 , bank acustomer T , n13 ( Data ) ) ; i −> ( a , 7 ) : ( a , 7 ) −> i : {n9 (Ng) . a} kg a {n9 (Ng) . g1 } kg a i −> ( g1 , 5 ) : ( g1 , 5 ) −> i : {n9 (Ng) . g1 } kg a { n17 ( Code ) . Data ( 1 8 ) } ( i n v ( kp1 ) ) i −> ( b1 , 8 ) : ( b1 , 8 ) −> i : { n17 ( Code ) . Data ( 1 8 ) } ( i n v ( kp1 ) ) () & Request ( b1 , a , bank acustomer T , Data ( 1 8 ) ) ; Die ersten beiden und der vierte Kommunikationsschritt mit (b1,16), (b2,12) und (b1,4) können ignoriert werden, da diese Teilnehmer innerhalb dieser Sitzungen nicht weiter am Protokollablauf beteiligt sind. Der Angriff läuft folgendermaßen ab: Zunächst schickt die Bank b1 die Nonce n17. Der Angreifer sendet betrügerische Transaktionsdaten zusammen mit n17 an die Chipkarte und wartet, bis der Anwender eine Überweisung ausführen will. Sobald dies geschieht, unterdrückt der Angreifer die Datenübertragung zur Chipkarte und sendet die Aufforderung zur PIN-Eingabe an den Anwender. Der Anwender glaubt, mit der Eingabe seiner PIN seinen Transaktionsauftrag zu unterschreiben. Er gibt also seine PIN in den Chipkartenleser ein. Die Chipkarte unterschreibt daraufhin die Transaktionsdaten vom Angreifer und sendet diesen unterschriebenen Auftrag an die Bank, die ihn prüft und ausführt. B.6 HBCI 3 Das HBCI-Verfahren mit einem Kartenleser der Sicherheitsklasse 3, auf dem sich der Anwender vor der Auftragsbestätigung nochmal die Transaktionsdaten zur Kontrolle anzeigen lassen kann, wird von AVISPA als sicher eingestuft. SUMMARY SAFE DETAILS BOUNDED NUMBER OF SESSIONS TYPED MODEL PROTOCOL .// t e s t s u i t e / r e s u l t s / protokollhbci3 . txt . i f GOAL As S p e c i f i e d 111 Anhang B Ausgaben von AVISPA BACKEND CL−AtSe STATISTICS Analysed : Reachable : Translation : Computation : 112 2028622 s t a t e s 713479 s t a t e s 0.04 seconds 57.88 seconds