Dipl. - Universität Tübingen

Transcrição

Eberhard Karls Universität Tübingen
Wilhelm-Schickard-Institut für Informatik
Arbeitsbereich fü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 Funktionalitä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 betrügerischen Ü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 für den Entwurf neuer Token . . . . . . . . . . . . . . . . 77
5.3 Kriterien fü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
Übersicht der Transaktionen beim Online-Banking . . . . . . . . . . . . .
13
5.1
Übersicht der Bewertung der Legitimationsverfahren
76
. . . . . . . . . . .
5
Tabellenverzeichnis
6
Abbildungsverzeichnis
2.1
Phishing-E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1
Vier mögliche Schnittstellen des Gerä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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
verschlü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 . . . . . . . . . . . . . . . . . . . .
Verschlüsselung der Bildpunkte bei der visuellen TAN; Quelle: RheinischWestfä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 . . . . . . . . . . . . . . . . . . .
Mögliche Ausführung eines Monitor-Dongles; Quelle: Wikipedia . . . . .
Ablauf des Monitor-TAN-Verfahrens . . . . . . . . . . . . . . . . . . . .
Ablauf des WYSIWYS-Verfahrens . . . . . . . . . . . . . . . . . . . . . .
Ablauf von HBCI mit Schlü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
Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 1 oder 2 . . . . .
Theoretisch möglicher Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.33 Skizze der Chipkarte mit Display im Einsatz . . . . . . . . . . . . . . . .
5.1
8
Gegenüberstellung des Zeitbedarfs und der Kosten der MITM-resistenten
Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
67
68
69
72
78
1 Einleitung
Neben der Abwicklung von Bankgeschä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 geführt. Die Anzahl der
Online-Ü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 Betrugsfälle registriert. Von 2006 auf 2007 stieg die Anzahl der InternetNutzer, deren Konten mit geklauten Passwörtern geplündert wurden um 23% auf mehr
als 3.250 Fälle [Bun07]. Da die Banken den resultierenden Vertrauensschaden begrenzen
wollen, werden vermutlich nicht alle Schäden angezeigt, so dass die tatsächliche Zahl
viel höher liegen dürfte. Täglich werden neue Meldungen über Sicherheitslücken in Betriebsystemen, Browsern oder anderer Software berichtet. Die Begriffe Phishing, Viren
und Trojanische Pferde kennt heute jeder Computernutzer, und die Tricks der Betrüger
werden immer raffinierter. Das sind Gründe genug, um sich mit den Sicherheitsaspekten
des Online-Bankings genauer auseinander zu setzen.
1.1 Motivation
Die Abwicklung von Bankgeschäften sollte beim Online-Banking ähnlich sicher sein wie
beim herkömmlichen, beleghaften Banking. Die Sicherheit hängt dabei online und offline
zentral vom eingesetzten Legitimationsverfahren ab, also von der Art und Weise, wie
Transaktionen durchgeführt werden. Überprüft eine Bank zum Beispiel generell keine
Unterschriften auf Überweisungsaufträgen, könnte ein Betrüger Aufträge mit gefä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 Betrüger unter anderem Namen Aufträge zu seinen Gunsten und zu
Lasten eines ahnungslosen Bankkunden tätigen.
Es gibt heute eine Vielzahl unterschiedlicher Methoden, die die Sicherheit beim OnlineBanking garantieren sollen. PIN/TAN-Verfahren, Chipkartenleser, SMS-TANs für das
Handy und HBCI stellen nur eine kleine Auswahl der verfügbaren Verfahren dar. Dabei
stellen sich einige Fragen: Sind diese Verfahren wirklich sicher vor den immer tückischeren
und ausgefeilteren Angriffsmethoden der Betrüger? Welche Vor- und Nachteile haben die
Legitimationsverfahren? Welche Verfahren gibt es überhaupt?
Online-Banking-Verfahren stellen immer einen Kompromiss zwischen Sicherheit, Kosten und Aufwand für den Benutzer dar. Selbst ein extrem sicheres Verfahren wird
9
1 Einleitung
möglicherweise nicht zur Anwendung kommen, wenn es mit zu hohen Kosten oder zu hohem Aufwand für den Benutzer verbunden ist. Leider sind gerade die sicheren Verfahren
oft teuer oder kompliziert zu bedienen. Für eine umfassende Beurteilung und einen fairen Vergleich der Verfahren ist eine Analyse der Kosten und der Benutzerfreundlichkeit
daher unumgänglich.
Die vorliegende Arbeit soll systematisch gä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 erklärt für das Verstä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 aufgeführt und diese Arbeit von den bisher erschienenen abgegrenzt. Weiter werden für
das Verständnis der Arbeit wichtige Grundlagen erläutert und einschrä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 Veröffentlichungen aufgeführt.
In seiner Arbeit Why Cryptosystems Fail [And93] beschreibt Anderson, wie die Sicherheit von Informationssystemen in der Realitä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 stützt sich auf die Untersuchung der Sicherheit
von Geldautomaten und der damit zusammenhängenden Infrastruktur. Die gefundenen
Probleme - wie zum Beispiel Betrug durch Bankangestellte - lassen sich teilweise auch
auf den Bereich des Online-Bankings übertragen. Im weiteren Verlauf dieser Arbeit werden diese Aspekte allerdings nicht betrachtet, da sie unabhängig von den verschiedenen
Online-Banking-Verfahren sind und somit keinen Einfluss auf die Vergleichbarkeit haben.
Das Fraunhofer-Institut für Sichere Informationstechnologie SIT untersuchte im Rahmen einer Studie im Jahr 2004 die Online-Banking-Systeme von zwö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 Würmern,
Viren und Trojanischen Pferden.
Hole et al. untersuchen in dem Artikel Case Study: Online Banking Security [HMT06]
verschiedene Sicherheitslü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 stößt ein Forscher bei den Unternehmen auf taube Ohren, wenn er ihnen entdeckte Sicherheitslücken
mitteilen möchte. So wird das Beheben der Probleme erschwert.
Die Fülle an Arbeiten zum Thema Sicherheit beim Online-Banking zeigt, dass sich
11
2 Grundlagen
die Forschergemeinde und auch Bankkunden stark für dieses Themengebiet interessieren.
Die Sichtung der Literatur hat aber auch ergeben, dass es bislang noch keine öffentliche,
detaillierte Beschreibung der eingesetzten Online-Banking-Verfahren gibt. Diese Lücke
soll die vorliegende Arbeit nun fü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 Funktionalität, die das System dem Anwender bietet, zugrundeliegende
Hardware wie etwa der Computer des Anwenders, der Server der Bank, die physischen
Kommunikationskanäle und gegebenenfalls weitere technische Geräte wie Mobiltelefone
und Chipkartenleser. Weitere Komponenten sind die verwendete Computerprogramme
und schließlich auch die verwendeten Legitimationsverfahren. Ausprägungen dieser Elemente werden im folgenden erlä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 über keine tiefen
Kenntnisse in der IT-Sicherheit verfügt. Auch die in dieser Arbeit erwähnten Geschäftsvorfälle
richten sich vornehmlich an Privatkunden. Geschäftsvorfälle, die in erster Linie für
Geschäftskunden und Unternehmen interessant sind - wie zum Beispiel verteilte Unterschriften und Sammelüberweisungen - werden hier nicht behandelt.
Die Arbeit betrachtet nur Angriffe auf das Online-Banking-System. Ein Bankrä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, gefälschte Überweisungsaufträ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 über das Internet durchführt. Dabei hat der Angreifer
insbesondere Kenntnis über die technischen Einzelheiten des Online-Banking-Systems.
Einzig explizite Geheimnisse wir PINs, TANs und elektronische Schlüssel besitzt er zu
Beginn seines Angriffes nicht.
Heute geht die Gefahr nicht mehr in erster Linie von Einzeltätern, sondern von organisierten Verbrecherbanden aus.
12
2.2 Online-Banking-Systeme
Kommunikationspartner sind neben Menschen und Unternehmen auch technische Geräte,
wie etwa Computer, Geldautomaten, Chipkarten, Mobiltelefone, die miteinander Informationen austauschen, die für sie eine Bedeutung haben.
2.2.2 Funktionalität eines Online-Banking-Systems
Ein Online-Banking-System stellt dem Anwender eine Vielzahl an Funktionen zur Verfügung,
die zur Erledigung der Bankgeschäfte dienen. Diese Funktionen werden in Form von
Transaktionen durchgeführt. Beim Online-Banking für Privatkunden der Dresdner Bank
beispielsweise stehen die in Tabelle 2.1 aufgeführten Transaktionen zur Verfügung: Zu
Tabelle 2.1: Übersicht der Transaktionen beim Online-Banking
Beginn einer Online-Banking-Sitzung muss sich der Anwender am System anmelden.
Das geschieht üblicherweise durch Eingabe einer Benutzerkennung und eines Passwortes oder einer PIN. Nach dem Anmelden stehen dem Anwender die Funktionen des
Systems zur Verfügung. Einige Transaktionen kann der Anwender ohne weitere Sicherheitsüberprüfungen durchfü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 für den Kunden entstehen. Eine manipulierte Überweisung indes fü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 fü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 Überweisungsauftrag.
13
2 Grundlagen
2.2.3 Hardware
Für die Online-Banking-Verfahren wird wie bei jedem Client-Server-System verschiedene
Hardware benötigt. An dieser Stelle soll nur auf zwei Komponenten näher eingegangen
werden, nämlich auf den Rechner des Kunden und auf technische Geräte, die der Kunde
zur Absicherung sicherheitskritischer Transaktionen zur Verfügung hat.
Der Kundenrechner muss zur Kommunikation mit dem Bankserver über eine Anbindung an das Internet verfügen. In dieser Arbeit wird davon ausgegangen, dass Computer
generell durch Schadsoftware kompromittiert werden kö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 Möglichkeit, das System als Web-Anwendung ü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 durchgefü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 möchte und äußert. Andererseits
gibt es der Bank die Sicherheit, dass sie nur Transaktionen ausführt, die nachweisbar
vom Kunden gewollt und geäußert wurden.
Anders gesagt gibt es bei der Sicherheit vier Aspekte: Vertraulichkeit, Verbindlichkeit,
Integrität und Verfügbarkeit. Vertraulichkeit: Informationen werden nur denjenigen bekannt, die die Infos erhalten sollen. Verbindlichkeit: Eine verbindliche Aussage kann im
Nachhinein nicht bestritten werden. Integrität: Autor und Inhalt einer Nachricht stehen
fest und können nicht unbemerkt verändert werden. Verfügbarkeit: Immer dann, wenn
zwei Parteien miteinander kommunizieren wollen, können sie dies. Die Übartragung kann
nicht blockiert werden.
Eine Gefä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 nä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 übertragen werden, werden von Unbefugten abgehört. Diese Gefahr ist ein Problem fehlender
Vertraulichkeit.
2. Ein vom Kunden gewünschter und geäußerter Transaktionsauftrag wird nicht ausgeführt. Diese Gefahr ist ein Problem fehlender Verfügbarkeit. Ein Denial-of-ServiceAngriff kann das erreichen.
3. Ein bei der Bank korrekt eingereichter Transaktionsauftrag wird ausgeführt. Nachher wird vom Kunden bestritten, diesen Autrag erteilt zu haben. Diese Gefahr ist
ein Problem der Verbindlichkeit.
4. Ein vom Kunden gewünschter und geäußerter Transaktionsauftrag wird mehrfach
ausgeführt. Ein Replay-Angriff kann das erreichen.
5. Ein vom Kunden ungewollter aber geäußerter Transaktionsauftrag wird ausgeführt.
Das kann beispielsweise bei einer Erpressung, einem Irrtum oder einer Fehlerhaften
Dateneingabe eintreten. Eine automatische Erkennung von Diskrepanz zwischen
Willen und Äußerung eines Kunden ist technisch schwierig zu realisieren. Allerdings läß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 geäußerter Transaktionsauftrag wird verändert
ausgeführt. Ein Man-in-the-Middle-Angriff kann das erreichen.
7. Ein vom Kunden weder gewollter noch geäußerter Transaktionsauftrag wird durchgeführt. Ein Identitätsdiebstahl durch Phishing kann das ermö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 für den Kunden normalerweise
mit keinem direkten finanziellen Schaden verknüpft und können effektiver durch andere
Maßnahmen abgewehrt werden. Überhaupt kann die Vertraulichkeit der übertragenen
Daten bei dem hier angenommenen Angreifermodell prinzipiell nicht sichergestellt werden, da die Daten am Bildschirm angezeigt oder über die Tastatur eingegeben werden
und von einem Trojaner abgehört werden kö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 näher erläutert.
2.3.1 Phishing
Phishing ist ein Angriff auf den Anwendereines Online-Banking-Systems, der diesen mit
einbezieht und ihn bewusst austrickst. Damit gehö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. Häufig erhält der Angreifer dadurch sensible Daten wie Benutzernamen, Passwörter oder TANs.
Der Phishing-Angriff wird am Beispiel des klassischen PIN-TAN-Verfahrens beschrieben. Zunächst erhä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 Gründen oder Drohungen Nachdruck verliehen (siehe Abbildung 2.1).
Abbildung 2.1: Phishing-E-Mail; Quelle: Wikipedia
Auf der gefälschten Webseite wird dann vom Kunden gefordert, seinen Benutzernamen, seine PIN und eine TAN einzugeben; vermeintlich mit dem Zweck, drohende Gefahr
abzuwenden. Die Webseite enthält Merkmale wie Firmenlogo und Corporate Design der
Bank des Kunden, so dass dieser glaubt, sich tatsächlich auf einer Webseite seiner Bank
zu befinden. Der Angreifer erhält die eingegebenen Zugangsdaten und kann damit zu
einem späteren Zeitpunkt online auf das Kundenkonto zugreifen und eine betrügerische
Transaktion durchführen.
Das gutgläubige Verhalten des Kunden ermöglicht den Phishing-Angriff. Daher kann
man den Angriff nur verhindern, indem man den Anwender aufklärt, oder indem technische Möglichkeiten die Täuschung fü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 für den jeweils anderen aus. Beispielsweise könnte sich bei einer Internet-Verbindung zwischen Kunde und Bank ein Trojaner
gegenüber der Bank als Kunde und gegenüber dem Kunden als Bank ausgeben, so dass
sämtliche Daten über den Trojaner weitergeleitet, aber auch gelesen, manipuliert und
unterdrückt werden können. Der MITM-Angriff ist gefährlich, weil er oft nur mit großem
Aufwand verhindert werden kann. Solange keine Daten verändert werden, kann er außerdem fast gar nicht entdeckt werden. Andererseits ist auch der Angreifer bei dieser
Angriffsart etwas eingeschränkt: Der Angriff kann nämlich nur dann stattfinden, wenn
die beiden Parteien auch tatsä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 läuft. Wenn der Kunde Online-Banking machen möchte, meldet
er sich zunächst mit Login und PIN auf der Webseite der Bank an. Der Trojaner ist solange inaktiv, bis der Benutzer eine Überweisung eingeben möchte und auf den Link des
entsprechenden Online-Formulars klickt. Dann gibt der Kunde die Überweisungsdaten
in die Maske ein. Wenn er das Formular aber absendet, speichert der Trojaner die Daten
des Kunden und ändert diese im Hintergrund so um, dass z. B. ein höherer Betrag auf
das Konto des Angreifers übertragen wird. Diese manipulierte Überweisung wird an die
Bank weitergeleitet. Die Bank fragt nach einer bestimmten indizierten TAN und schickt
die Anfrage an den Kunden zurück. In dem Moment wird der Trojaner wieder aktiv: Er
fängt die Anfrage der Bank ab, ändert diese wieder in die ursprüngliche vom Kunden
erwartete Form. Der Kunde sieht eine Authentifizierungsaufforderung fü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 Überweisung zu unterschreiben. In Wirklichkeit aber unterschreibt er die vom Trojaner fingierte Überweisung.
Die Bank erhält einen korrekt aussehenden Auftrag und führt diesen aus. Der Benutzer
bemerkt die Manipulation erst auf dem Kontoauszug. Theoretisch kö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 gefälschten Website, die so aussieht, als wä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. Gefä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 ursprünglichen Senders. Gibt beispielsweise ein Kunde eine
Überweisung in ein vor Replay-Angriffen ungeschütztes Online-Banking-System ein, so
könnte ein Angreifer den Datenstrom zum Bankserver aufzeichnen und hinterher mehrmals erneut senden. Dadurch würden mehrere gleichartige Überweisungen ausgeführt,
so dass vom Kundenkonto insgesamt ein Vielfaches des vom Kunden gewollten Betrags
überwiesen wird.
Replay-Angriffe lassen sich verhindern, indem in der Kommunikation Codes verwendet werden, die nur ein einziges Mal benutzt werden dürfen - sogenannte Nonces
footnoteAus dem Englischen: Number used once. Nonces werden beispielsweise als Zufallszahlen generiert, von denen man ausgeht, dass sie sich mit genügend hoher Wahrscheinlichkeit nicht wiederholen werden. Sendet Alice eine Nonce und bekommt diese
Nonce im Laufe der Kommunikation verknü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 Zähler und Zeitstempel vermeiden, deren Einmaligkeit durch
die konstante Erhöhung sichergestellt ist.
2.4 Rechtliche Situation bei betrügerischen
Überweisungen
Eine ausgeführte Überweisung lässt sich nicht mehr widerrufen oder durch die beteiligten
Banken rückgängig machen.[BGB08, §676a] Möchte ein Kunde eine Rücküberweisung
erhalten, so muss er sich direkt an den ursprünglichen Zahlungsempfänger wenden und
sich mit ihm einigen. Speziell bei betrügerischen Überweisungen lassen sich aber die
wirklichen Empfänger für den Kunden nur schwer ermitteln, vor allem, wenn die Betrüger im Ausland sind oder geschickte Geldwäsche betreiben. Üblicherweise läuft der
Geldfluss über Mittelsmänner, die das Geld an das Finanzunternehmen Western Uni”
on“ überweisen. Die Betrüger erhalten das Geld von Western Union gegen Vorlage einer
zehnstelligen Geldüberweisungskontrollnummer bar ausgezahlt. Sie müssen sich dabei
nicht ausweisen und bleiben so anonym [Bac05].
Entdeckt ein Kunde eine betrügerische Überweisung zu seinen Lasten, kann er den
Betrug zur Anzeige bringen und hoffen, dass der Betrüger ausfindig gemacht wird. Durch
die geschickte Geldwäsche ist es aber unwahrscheinlich, dass der Kunde auf diesem Wege
sein Geld zurückbekommt. Oft wendet sich der Kunde daher an seine Bank. Banken
18
2.4 Rechtliche Situation bei betrügerischen Überweisungen
ersetzen entstandene Schäden oft aus Kulanz. 1 Falls nicht, kann der Kunde seine Bank
auf Schadenersatz verklagen. Nach einem Urteil des Landgerichts Köln werden dem
Kunden beim Online-Banking folgende Sorgfaltspflichten auferlegt:
Für den konkreten Fall des Online-Bankings kann man von einem verständigen, tech”
nisch durchschnittlich begabten Anwender fordern, dass er eine aktuelle Virenschutzsoftware und eine Firewall verwendet und regelmäßig Sicherheitsupdates fü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
können, dass er deutliche Hinweise auf gefälschte E-Mails und Internetseiten seiner Bank
erkennt (sprachliche Mängel, deutlich falsche Internet-Adresse, Adresse ohne https://,
kein Schlüsselsymbol in der Statusleiste). Weitergehende Sicherheitsmaßnahmen wie etwa die Verwendung bestimmter, besonders leistungsfähiger Virenschutzprogramme oder
spezialisierter Programme zum Schutz gegen bestimmte Schadsoftware, die Veränderung
der Standard-Sicherheitseinstellungen von Betriebssystem und Programmen, das Arbeiten ohne Administratorrechte, die ständige Überprüfung der Zertifikate oder auch das
Erkennen subtiler Abweichungen in der Internetadresse, würden die Sorgfaltsanforderungen dagegen überspannen.“[Lan07, Absatz 47]
Laut einem noch nicht rechtskräftigen Urteil des Amtsgerichts Wiesloch haften Banken
für Schä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
ermöglichte.[Spi08]
Es ist unerheblich, wer letztendlich für den entstandenen Schaden aufkommt. Die Betrüger lassen sich meist nicht ermitteln, so dass am Ende oft ein Geschädigter übrig
bleibt. Ob das nun der Kunde, die Bank oder eine Versicherung ist, ist egal. Daher darf
es erst gar nicht zum Betrug kommen können. Technische Mittel, wie sichere Transaktionsverfahren, sind hierfür ein wesentlicher Bestandteil.
1
2
nach Aussage von Detlev Mergemeier, GAD
Keylogger sind versteckte Programme, die Tastatureingaben aufzeichnen und über das Internet versenden können.
19
2 Grundlagen
20
Die Beschreibung eines Verfahrens dient als Grundlage für die anschließenden Analyse
und die Diskussion der resultierenden Sicherheit. Um die Beschreibungen systematisch
zu halten, ist ihre Struktur immer gleich. Zunächst wird das Verfahren grob skizziert.
Dabei wird darauf eingeganen, was die hauptsächliche Motivation fü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 Prüfungen in ihrer Reihenfolge
genannt.
Anwender und Banken haben die Möglichkeit, sich für ein Online-Banking-Verfahren
zu entscheiden. Die Banken haben dabei die direkte Entscheidungsgewalt. Die Anwender
können zwischen den von den Banken angebotenen Verfahren wählen und ihre Entscheidung für eine bestimmte Bank auch von den angebotenen Online-Banking-Verfahren
abhängig machen. Ein systematischer Vergleich der Verfahren bietet eine Grundlage für
eine Entscheidung. Dieses Kapitel beschreibt, wie ein solcher Vergleich durchgefü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
Geräte geordnet. Prinzipiell kann ein Gerät über seine Schnittstellen Informationen direkt mit dem Anwender oder mit seinem Computer austauschen. Informationen können
sowohl vom Gerät weg als auch in das Gerät hinein fließen, so dass sich vier mögliche
Schnittstellen ergeben. Die meisten verwendeten sicheren Gerä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 Fälle denkbar.
Abbildung 3.1 zeigt durch die vier Pfeile die möglichen Schnittstellen.
Jedes Online-Banking-Verfahren verwendet ein bestimmtes physikalisches Authentifikationsmerkmal. Jedes dieser Geräte hat leicht zu identifizierende Schnittstellen, so
dass sich die Geräte und mit ihnen die Verfahren klassifizieren lassen. Nicht alle der 16
möglichen Klassen existieren tatsächlich. Alle Klassen, die keine vom Gerät ausgehenden
Schnittstellen besitzen, können keine Information nach außen und damit keine Authentifizierungsmöglichkeit liefern. Die in dieser Arbeit vorgestellten Verfahren belegen sechs
21
Abbildung 3.1: Vier mögliche Schnittstellen des Gerä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
Gerät, an zweiter Stelle die zwischen Gerät und Computer. Eingehend“ und Ausge”
”
hend“ beziehen sich immer auf das Gerä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 lässt sich auf verschiedene
Weisen durchfü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 begründen, warum bekannte Angriffe ausgeschlossen sind. Ein Beweis der Sicherheit
lässt sich ohne formale Methoden praktisch nicht führen.
3.2.2 Formale Sicherheitsanalyse
Nachdem nun dargestellt wurde, wie sich die Sicherheit von Legitimationsverfahren
hinsichtlich bekannter Angriffsarten praktisch testen lässt, wird in diesem Abschnitt
23
eine theoretische, formale Sicherheitsanalyse vorgestellt. Man kann die Kommunikationsablä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
prü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 möglichen Zustände durchgespielt, die im Rahmen der Spezifikation
erreichbar sind, und es wird geprüft, ob das Sicherheitsziel verletzt wird. Findet das
Tool eine Sicherheitsverletzung, so gibt es den Kommunikationsablauf aus, der zu der
Verletzung führt. Wenn die Anzahl der Zustände hinreichend klein für die Analyse ist,
so können alle Zustände geprü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 Möglichkeiten
durchzuprobieren. So können auch bislang unbekannte Angriffe entdeckt werden. Für
eine begrenzte Anzahl an parallel laufenden Sitzungen und eine endliche Anzahl an
möglichen Protokollschritten pro Sitzung ist die Frage nach der Sicherheit bzw. nach
einem möglichen Angriff entscheidbar - wenn auch NP-vollständig [RT03].
Diese Analysemethode hat allerdings auch einige Nachteile und Schwächen. Zunächst
muss das Verfahren in einer Spezifikationssprache (HLPSL) beschrieben werden. Das ist
nicht trivial. Dieser Prozess ähnelt dem Programmieren, und ähnlich wie bei diesem sind
auch hier Programmierfehler möglich. Die Ergebnisse der Sicherheitsanalyse könnten
hierdurch verfälscht werden. Die eingesetzte Beschreibungssprache kann nicht alle Sachverhalte und Elemente der untersuchten Online-Banking-Protokolle ohne Umwege modellieren. Insbesondere Zeitstempel, Zählerstände, TAN-Listen und sichere Kommunikationskanäle zwischen Anwender und Token können nicht direkt modelliert werden. Aus
diesen Gründen wird in dieser Arbeit weitgehend darauf verzichtet, die Verfahren formal
zu analysieren, die bereits bei der praktischen Analyse erhebliche Sicherheitsschwächen
zeigen. Fü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 Könnens des Angreifers (intruder
knowledge) und Spezifikation des Sicherheitsziels (goal ).
Für die Modellierung der Legitimationsverfahren ergeben sich einige konkrete Parameter. Die relevanten Kommunikationspartner sind hier Anwender, Bank und sicherheitsrelevante Gegenstä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 Ausfü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 Gerä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 Gerät Gi nutzt.
Das Sicherheitsziel ist in unserem Fall immer das gleiche: Die Bank soll den Kunden
und dessen Transaktionsdaten authentisieren.
3.3 Kosten
Bezüglich der Kosten werden nur die Punkte aufgeführt, die direkt von der Anzahl der
Nutzer und der Anzahl der Transaktionen abhängen. Als Beispiel seien hierzu die Kosten
für die Postzustellung einer TAN-Liste oder für das Versenden einer SMS genannt. Die
Betrachtung ist aber unabhängig davon, ob die Bank oder der Benutzer für die Kosten
aufkommt.
Nicht betrachtet wird dagegen den Aufwand fü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 abhängig ist. Außerdem betrachte ich nicht
die Betriebskosten fü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 gegenüberstellen zu können, wird
davon ausgegangen, dass ein Anwender im Schnitt 50 Transaktionen pro Jahr durchführt.
Diese Anzahl ergibt sich aus den Statistiken der Deutschen Bundesbank [Deu08], wobei
angenommen wird, dass die meisten Transaktionen Überweisungen sind. Die Banken
geben für die Lebensdauer verschiedener TAN-Generatoren eine Dauer etwa fünf Jahren
an (beispielsweise TAN-Generator der BW-Bank [Bad07]). Daraus ergeben sich eine
Gesamtzahl von 250 Transaktionen pro Gerä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 Überforderung des Benutzers kann dazu führen, dass der Benutzer Fehler macht, Zeit verschwendet, sein Ziel
nicht erreicht, frustriert wird und möglicherweise das System zukünftig nicht mehr nutzt.
Bankkunden benutzen ein spezielles Online-Banking-System freiwillig. Falls sie damit
unzufrieden sind, können sie die Bank (und damit das Online-Banking-System) wechseln
oder auf das Online-Banking an sich verzichten. Daher mü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
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 können, werden die Verfahren zunä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 nächste Kapitel am
Beispiel eines momentan häufig eingesetzten Verfahrens - des sogenannten indizierten
TAN-Verfahrens - erläutert.
Zur Bewertung der Benutzerfreundlichkeit stehen zwei Arten von Ansätzen zur Verfügung,
nämlich eine empirische und eine analytische. Bei den empirischen Verfahren lässt man
Anwender das zu bewertende System testen. Dabei beobachtet oder befragt man sie.
Diese Verfahren haben den Vorteil, dass sie realistische und ü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 überschaubare Teile zerlegen
und Teilaspekte einzeln betrachten. Der Vorteil ist hier die leichte, ressourcenschonende
Durchführung. Nachteilig ist, dass durch Betriebsblindheit eventuell wichtige Teilaspekte
übersehen werden könnten.
In dieser Arbeit habe ich mich wegen des geringeren Aufwandes für den analytischen
Ansatz entschieden. Es geht hier nicht darum, die Benutzerfreundlichkeit möglichst exakt
absolut darzustellen, es reicht eine grobe, relative Unterscheidungsmöglichkeit zu liefern.
Im Fokus der Bewertung soll das Charakteristische eines Verfahrens liegen. Elemente,
die für alle Verfahren annähernd gleich oder unabhängig von den Verfahren sind, sollen nicht in die Bewertung einfließen. Insbesondere sind dies die Ergonomie der für das
Online-Banking benutzten Computer, Monitore und Tastaturen und die Dialogführung
der Online-Banking-Programme. Diese Aspekte sind zwar wichtig für die Gesamtbeurteilung der Ergonomie eines bestimmten Systems, aber wegen der mangelnden Differenzierungsfähigkeit zwischen den Verfahren nicht Gegenstand dieser Arbeit. Zur umfassenden
Beurteilung steht vor allem die Norm DIN EN ISO 9241 Ergonomische Anforderungen
für Bürotätigkeiten mit Bildschirmgeräten mit ihren zahlreichen Teilen zur Verfügung.
Die charakteristischen Elemente eines Legitimationsverfahrens sind im Rahmen dieser
Arbeit zum einen der signaturrelevante Kommunikationsablauf, sowie die Ergonomie des
verwendeten, sicherheitsrelevanten Gegenstandes.
Cakir schlägt eine Reihe von Kriterien vor, anhand derer sich die Ergonomie physischer
Eingabegeräte messen lä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 Gegenstände benutzt werden.
Eine pragmatische Möglichkeit, die Qualitätsmerkmale der Dimension Durchführung
zu messen, ist das Keystroke-Level-Modell (KLM) von Card[CMN83, Seite 259 ff]. Die-
26
3.4 Benutzerfreundlichkeit
ses Modell eignet sich für die Messung der Ergonomie sowohl des sicherheitsrelevanten
Kommunikationsablaufs als auch des sicherheitsrelevanten Gegenstandes. Hierbei wird
die Zeit geschätzt, die ein geübter Benutzer benötigt, um einen fehlerfreien Vorgang
durchzuführen. Dafü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
Ausfü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 Eingabegeräts : 0,4
Mentale Vorbereitung : 1,35
Antwortzeit des Systems : ?
Die Antwortzeit ist systemabhängig und nicht näher beschrieben. Eigene Messungen
(20facher Aufruf des Online-Banking-Startseite der Dresdner Bank) ergaben eine durchschnittliche Antwortzeit von 2 Sekunden, die hier zugrundegelegt wird. Geübte Benutzer
benötigen für das Drücken der Maustaste wenig Zeit, weshalb an dieser Stelle dafür 0,1
Sekunden angenommen werden. Ein Vorgang bestehend aus Zeigen und Klicken benötigt
somit 1,2 Sekunden. Für das Tippen auf der Tastatur des Computers oder eines externen
Gerätes wird pauschal ein mittlerer Wert von 0,5 Sekunden angenommen. Die mentale
Vorbereitung umfasst Schritte, bei denen der Anwender etwas lesen, vergleichen oder
prüfen muss. Auf eine Nachkommastelle gerundet ergibt sich hierfür pauschal ein Wert
von 1,4 Sekunden. Die Elementaroperationen des KLM sind nicht für alle Verfahren
ausreichend. Insbesondere spezielle Manipulationen am Gerät - wie zum Beispiel Einstecken einer Chipkarte in einen Chipkartenleser - fehlen und werden im Einzelfall geschätzt.
Außerdem soll nur der Zeitbedarf ermittelt werden, der ausschließlich der Authentifizierung dient. Es wird angenommen, dass die Eingabe der reinen Transaktionsdaten für
alle Verfahren gleich lange dauert. Daher wird diese Zeit nicht berücksichtigt. Weiter
wird angenommen, dass die Antwortzeiten der Online-Banking-Systeme gleich sind, und
dass die Qualität der Menüführung bei allen Systemen so ähnlich ist, dass sich daraus
keine zeitlichen Unterschiede bei der Benutzung ergeben. Auch die Bestätigungsantwort
für die erfolgreiche Eingabe einer Transaktion wird nicht berücksichtigt.
Die Verfahren werden somit bezüglich ihrer Durchführungsqualität anhand folgender
Einzeloperationen gemessen:
Schritt : Abkürzung : Zeitbedarf in Sekunden
27
Tastendruck : T : 0,5
Ziehen und Klicken mit Maus : K : 1,2
Wechsel des Eingabegeräts : W : 0,4
Mentale Vorbereitung : M : 1,4
Antwortzeit des Systems : A : 2
Manipulation des Gerätes : G : abhängig vom Einzelfall
Die Analyse sei kurz am Beispiel des klassischen TAN-Verfahrens erklä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 für die Durchführung
eines Verfahrens durch einen geübten Benutzer stark korreliert mit dem Aufwand für
einen ungeübten Benutzer, die korrekte Bedienung des Verfahrens zu erlernen. Deshalb
wird hierfür kein neues Beurteilungskriterium eingeführt. Außerdem wird angenommen,
dass komplizierte, benutzerunfreundliche Verfahren einen höheren Zeitwert als einfacher
zu bedienenden Verfahren aufweisen.
Neben der benötigten Ausführungzeit unterscheiden sich die Verfahren noch hinsichtlich der Möglichkeit, sie auch außerhalb des Anwendercomputers nutzen zu können.
Vorteilhaft für den Benutzer ist, wenn er auch an fremden Rechnern - beispielsweise im
Internetcafé - sicheres Online-Banking betreiben kann. Daher wird in die Betrauchtung
der Benutzerfreundlichkeit auch dieser Aspekt berücksichtigt.
28
Heutzutage verlässt man sich beim Online-Banking nicht mehr nur auf die einmalige Eingabe einer PIN zu Beginn einer Sitzung. Vorgänge, die einen Geldabfluss vom Kundenkonto zur Folge haben oder sicherheitstechnisch kritisch sind verlangen zur Ausführung
eine separate Bestätigung. Diese Bestätigung kommt der eigenhändigen Unterschrift bei
papierhaften Bankgeschäften gleich.
Die Funktion der Unterschrift wird auf elektronischem Wege mit zwei verschiedenen
Ansätzen realisiert. Zum einen gibt es jene Verfahren, die auf Transaktionsnummern
(TANs) beruhen. Diese TANs bestehen üblicherweise aus sechs Ziffern. Eine OnlineTransaktion wird hier durch die zusä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 angefügt, die einer realen Unterschrift gleichkommt.
Insbesondere kann die Unterschrift von der Bank leicht überprüft und nur durch den
Kunden erzeugt werden. Außerdem bezieht sich diese elektronische Unterschrift genau
auf den angegebenen Text, so dass nach einer Veränderung der Transaktion die Unterschrift nicht mehr zu dem Text passt und Manipulationen so erkannt werden können.
Im Folgenden werden zunächst die Verfahren erklärt, die auf Transaktionsnummern beruhen. Anschließend folgen die auf elektronischen Signaturen beruhenden Verfahren.
Unter den TAN-basierten Verfahren finden sich die einfachsten und ältesten Verfahren
zum Unterschreiben von Transaktionen beim Online-Banking. Fü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 herkömmliche PIN/TAN-Verfahren. Hier
verwendet der Benutzer seine PIN, um sich einmalig zu Beginn einer Sitzung beim
Online-Banking-System anzumelden. Möchte er dann eine Transaktion ausführen, so
gibt er zusätzlich zu den Transaktionsdaten eine unverbrauchte TAN ein. Diese TANs
erfü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 gültige
TANs eingeben können. Die TANs sollten daher nicht erraten, vorhergesagt oder leicht
entwendet werden können. Viele Banken benutzen zufällige TANs mit einer Länge von
sechs Stellen. Will man solch eine TAN erraten, so hat man nur in einem von möglichen
1.000.000 Fällen Erfolg. Diese Wahrscheinlichkeit gilt als klein genug, um ausreichende
Sicherheit zu gewährleisten. Wenn aber vom Online-Banking-System nicht eine bestimmte TAN erwartet wird, sondern eine beliebige Transaktionsnummer aus einer Liste einge-
29
geben werden kann, steigt die Wahrscheinlichkeit für erfolgreiches Erraten entsprechend.
Kann man beispielsweise aus 100 gültigen TANs eine beliebige aussuchen, beträgt die
Erfolgswahrscheinlichkeit fü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 erhöht sich ebenfalls multiplikativ mit der Anzahl
der zulässigen Versuche. Wird eine sechstellige TAN von einer Liste mit 100 gültigen
TANs verlangt, und hat man 5 Versuche, eine korrekte TAN einzugeben, beträgt die Erfolgswahrscheinlichkeit für das Raten - man probiert bei jedem Versuch eine andere TAN
aus - fünf zu 10.000 oder 0,05%. Im Jahr 2006 betrug die durchschnittliche Höhe von
betrügerischen Online-Überweisungen knapp 5000 ¿. Bei einem Legitimationsverfahren,
das eine Erfolgswahrscheinlichkeit von 0,05% für das Erraten von TANs hat, könnte ein
Betrü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
üblicherweise auf Papier gedruckt und enthält etwa hundert TANs. Der Kunde erhält die
Liste per Post als Brief zugeschickt. Sobald der Kunde eine Online-Transaktion ausführen
möchte, wird er vom Online-Banking-System aufgefordert, eine beliebige, unverbrauchte
TAN anzugeben. Der Kunde schaut auf seine TAN-Liste, wä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 Gültigkeit überprüfen. Nur wenn die eingegebene TAN auf der Liste zu finden ist und
noch nicht benutzt wurde wird die Transaktion durchgeführt. Das System benachrichtigt
den Kunden ü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 ausführen kann.
Abbildung 4.2 verdeutlicht den Ablauf:
1. Der Kunde wählt eine unbenutzte TAN von seiner TAN-Liste aus und streicht sie
dort durch.
2. Der Kunde gibt die Transaktionsdaten und die gewählte TAN in den Computer
ein.
3. Der Computer schickt die Transaktionsdaten zusammen mit der TAN zum Server
der Bank.
4. Der Bankserver überprüft die Gültigkeit der TAN und führt die Transaktion gegebenenfalls aus.
30
”
Abbildung 4.1: TAN-Liste der Citibank; Quelle: [hei06]
Abbildung 4.2: Ablauf des klassischen TAN-Verfahrens
31
Die Abkü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 abhängig ist von x
{x}: Daten x, die signiert oder verschlüselt wurden
PIN: PIN-Code
Keypad(x): Eine Permutation der Ziffern 0 bis 9, angezeigt als Zifferntastatur und
abhängig unter anderem von x
Am Ende der Kommunikation führt die Bank stets eine Gültigkeitsüberprüfung für die
eingereichte Transaktion aus. Dieser letzte Schritt ist in den Kommunikationsablaufdiagrammen nicht dargestellt. Zwar bestätigen die Bankserver normalerweise den korrekten
Eingang einer Transaktion, aber der Kunde hat in keinem der hier dargestellten Verfahren die Möglichkeit, die Authentizität und Integrität dieser letzten Bestätigungsmeldung
sicher zu überprüfen. Eine sichere Bestätigungsmeldung könnte auch keinen Betrug verhindern, sondern nur helfen, ihn nachträglich leichter zu entdecken. Sinn und Zweck der
Legitimationsverfahren ist es aber, im Vornherein schon keine betrügerischen Transaktionen zuzulassen.
Analyse der Sicherheit
Für das klassische TAN-Verfahren sind mehrere Schwachstellen und wirksame Angriffe bekannt. Es ist für einen Angreifer möglich, durch Phishing an Zugangsdaten und
TANs eines Kunden zu gelangen und damit beliebige Transaktionen in seinem Namen
durchzuführen. Weiter ist es durch einen MITM-Angriff möglich, Transaktionen eines
Kunden zu manipulieren. Außerdem kam es bei mindestens einer Bank infolge schlechter Implementierung der TAN-Erzeugung zu einer geringen Zufälligkeit und damit guten
Vorhersagbarkeit unbenutzter TANs.[hei06] So konnte man mit Hilfe von einigen verbrauchten TANs mit hoher Wahrscheinlichkeit neue, gültige TANs berechnen.
Bei einem kompromittierten Rechner bietet das klassiche TAN-Verfahren also keinen
wirksamen Schutz vor Betrug.
32
”
Analyse der Benutzerfreundlichkeit
Das Verfahren ist mobil einsetzbar. Neben dem Computer wird als einziger Gegenstand
die TAN-Liste benötigt, die problemlos überall hin mitgenommen werden kann.
Die KLM-Schritte fü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 für einen geübten Benutzer ein Zeitaufwand von 6T + 2K + 2W +
3M + A + G = 15,4 Sekunden fü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 fü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 Gerät angezeigt
werden können. Durch einen Knopfdruck wird eine gültige TAN generiert und auf einem Display angezeigt. Der Ablauf zur Ausfü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 zunächst die Bankkarte des Kunden in den Ge-
33
nerator gesteckt werden. Der Generator schaltet sich hierdurch automatisch ein. Auf
Knopfdruck wird die nächste, gültige TAN angezeigt. Die TANs werden auf dem Chip der
Karte erzeugt und können mit dem Generator lediglich ausgegeben werden. Somit ist der
Generator selbst kein sicherheitskritisches Gerät und kann für alle Kunden in identischer
Bauweise ausgegeben werden. Die Reihenfolge der TANs spielt bei diesem Verfahren eine Rolle: Wenn eine gültige TAN im Online-Banking-System verwendet wurde, werden
mit ihr auch alle vorher erzeugten TANs ungü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 Durchführung einer
TAN-pflichtigen Transaktion mit einer frisch generierten TAN die entwendeten TANs
ungü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 überprüft die Gültigkeit der TAN und fü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 Gerät. Durch eine eingebaute Uhr hängen die
TANs von der aktuellen Zeit ab und haben dadurch eine zeitlich begrenzte Gültigkeit.
Der Ablauf des Verfahrens ist analog zum sm@rtTAN-Verfahren.
34
”
Abbildung 4.5: TAN-Generator Bankey“; Quelle: www.modern-banking.de
”
Das eTAN-Verfahren erschwert gegenüber dem klassischen TAN-Verfahren PhishingAngriffe geringfügig. Im Gegensatz zur klassischen TAN verliert eine elektronische TAN
nämlich ihre Gültigkeit, nachdem der legitime Benutzer eine neue Transaktion ausführt
(gilt für die sm@rtTAN) oder nachdem eine bestimmte Zeit abgelaufen ist (gilt für den
Bankey). Ein Phishing-Angriff ist aber immer noch möglich, wenn der Angreifer die
entwendeten eTANs sofort für einen Betrug verwendet.
Das eTAN-Verfahren schützt ebenfalls nicht vor einem MITM-Angriff.
Die Token zur Erzeugung der elektronischen TANs sind klein und problemlos zu transportieren. Somit eignet sich das elektronische TAN-Verfahren auch für den mobilen Einsatz.
Die KLM-Schritte fü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 drü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 für einen geübten Benutzer ein Zeitaufwand von 7T + 2K + 2W + 3M + A + G
= 15,9 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Beim Verfahren mit dem Bankey entfällt das einstecken der Karte. Die Zeit verkürzt
sich gegenü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
bereits in diesen Preisen enthalten.
4.2 Schnittstellenklasse Bidirektional - Keine“
”
4.2.1 Indizierte TAN
Indizierte TANs (iTANs) werden ähnlich wie beim klassischen TAN-Verfahren auf eine
Papierliste gedruckt. Die iTANs sind im Gegensatz zum TAN-Verfahren durchnummeriert. Zur Durchführung einer Transaktion kann nicht eine beliebige iTAN aus der Liste ausgewählt werden, sondern es muss eine bestimmte, von der Bank geforderte und
durch die laufende Nummer gekennzeichnete iTAN eingegeben werden. Ä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
”
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 zufä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. erhä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 überprüft die Gültigkeit der iTAN und fü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 ausgewählte Positionsnummer in ein Captcha1 eingebettet, das die Transaktionsdetails sowie das Geburtsdatum des Kunden enthält.[hei07]
Abbildung 4.8: Captcha beim iTANplus-Verfahren; Quelle: Fiducia IT AG
Das iTAN-Verfahren wurde als Verbesserung zum klassischen TAN-Verfahren eingeführt.
Ein Phishing-Angriff wird stark erschwert, da für eine Transaktion immer eine bestimmte iTAN eingegeben werden muss. Hat ein Betrüger nur eine iTAN zur Verfügung, so ist
die Wahrscheinlichkeit, dass die Bank bei der Durchführung einer betrü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 überlassen. Dagegen schützt
das iTAN-Verfahren nicht.
1
Ein Captcha ist ein Bild, das für Menschen lesbaren Text enthält, der aber nicht oder nur schwer
automatisch erkannt werden kann. Captchas sollen erzwingen, dass nur Menschen und keine Computerprogramme einen Online-Dienst nutzen können.
37
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
Angriffsmö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 müsste ein Angreifer die Informationen auf dem
Captcha unauffällig ändern. Diese Manipulation ist manuell durchaus möglich, aber maschinell bei automatisierten Angriffen schwierig. Prinzipiell ist ein MITM-Angriff auch
bei diesem Verfahren nicht ausgeschlossen. Die einfachste Möglicheit funktioniert wie
folgt: Sobald der Kunde eine Transaktion eingibt, erzeugt der Angreifer eine zweite, betrügerische Transaktion. Beide Aufträge werden bei der Bank eingereicht, und für beide
liefert die Bank ein entsprechendes Captcha zurü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 betrügerischen Überweisung
ersetzen. Befinden sich die Indexnummern stets an der gleichen Stelle auf dem Bild, ist
die Manipulation auch automatisch leicht durchführbar.
Die indizierte TAN-Liste kann problemlos transportiert werden und erlaubt somit einen
mobilen Einsatz dieses Verfahrens.
Die KLM-Schritte fü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 für einen geübten Benutzer ein
Zeitaufwand von 6T + 2K + 2W + 5M + A = 15,2 Sekunden für das Durchlaufen des
sicherheitsrelevanten Teils des Verfahrens.
Beim iTANplus-Verfahren muss der Anwender zusätzlich noch das Captcha kontrollieren. Dafür muss er das angegebene Geburtsdatum (M) und die Transaktionsdaten (M)
überprüfen. Das iTANplus-Verfahren dauert also 18 Sekunden.
Falls die Bank nach der TAN-Eingabe eine Bestätigungsnummer anzeigt, so fallen
zusätzlich 3,2 Sekunden für deren Prü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.2 Dynamische TAN
Eine ganze Reihe von Verfahren verwenden TAN-Generatoren, die zur Erzeugung der
TAN Daten der Transaktion mit einbeziehen. Dazu verfügen diese Geräte neben einem
Display ü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 enhält hierzu Spezifikationen und Empfehlungen. Die
so erzeugten TANs heißen wegen des Transaktionsbezugs dynamische TANs. Der Transaktionsbezug sorgt auch für eine hö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
Gültigkeit besitzen. Außerdem hängt die TAN noch von einem geheimen Schlü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 (üblicherweise die Zielkontonummer) in seinen TAN-Generator ein.
39
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
”
2. Der TAN-Generator erzeugt eine TAN, die abhängig von der aktuellen Zeit, den
eingegebenen Ziffern und einem internen, geheimen Schlü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 überprüft, ob die TAN zum aktuellen Auftrag, zum Benutzer und
zur aktuellen Zeit passt und fü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 übernimmt
der Chip auf der Bankkarte die Berechnung der TAN. Die sm@rtTANplus-Generatoren
selbst enthalten weder geheime Schlüssel noch eine eingebaute Uhr. Replay-Angriffe werden hier auf anderem Weg verhindert: Der Chip speichert einen Zählerstand, der sich bei
jeder TAN-Generierung erhöht und mit in die Berechnung der TAN eingeht. Zusätzlich
zu den ausgewählten Transaktionsdaten muss der Kunde eine von der Bank für die bestimmte Transaktion gültige fünfstellige Zufallszahl in den Generator eingeben.[Vol07]
Die Bank merkt sich, bis wann eine ausgegebene Zufallszahl und eine dazugehörige TAN
gültig ist. Abbildung 4.12 erläutert den genauen Kommunikationsablauf.
Abbildung 4.12: Ablauf beim sm@rtTANplus-Verfahren der Volks- und Raiffeisenbanken
41
1. Der Kunde gibt die Transaktionsdaten in seinen Rechner ein.
2. Der Rechner leitet die Transaktionsdaten an den Bankserver weiter.
3. Der Bankserver generiert für diese Transaktion eine Zufallszahl und sendet diese
Zahl zurü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 abhängig von der eingegebenen Zufallszahl, den eingegebenen Transaktionsdaten und einem internen, geheimen Schlü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 überprüft, ob die TAN zum aktuellen Auftrag, zum Benutzer,
zum aktuellen Zählerstand und zur Zufallszahl passt und führt die Transaktion
gegebenenfalls aus und speichert den neuen Zählerstand.
Einige Sparkassen bieten das chipTAN-Verfahren an, ein zum sm@rtTANplus analoges Verfahren.[Ber08] Dabei kommen neuerdings auch Tan-Generatoren zum Einsatz,
die über eine optische Schnittstelle verfügen, die Daten direkt vom Bildschirm einlesen
kann. Dadurch braucht der Anwender keine Daten doppelt einzugeben.[REI08] Die Datenübertragung vom Bildschirm in den TAN-Generator erfolgt mit einem Flickercode.
Dieser besteht aus einem Bild mit mehreren schwarz-weiß blinkenden Flächen, die durch
ihr Zusammenspiel die Informationen ähnlich wie beim Morsen übertragen.
Die dynamischen TAN-Verfahren sind sicher vor klassischen Phishing-Angriffen, da die
TANs eine begrenzte Gültigkeit haben und direkt von Teilen der Transaktionsdaten
abhängen. Auch ein Transaktionsdaten manipulierender MITM-Angriff scheitert, wenn
die Daten geändert werden, die in den Generator eingegeben werden. Die formale Sicherheitsanalyse mit AVISPA bestätigt die Sicherheit des spezifizierten Protokolls (siehe
Anhang).
42
”
Allerdings sind einige Angriffsszenarien möglich, die Elemente des MITM und des
Phishing kombinieren. Durch eine betrügerische E-Mail oder eine gefälschte Website könnte ein unachtsamer Benutzer dazu gebracht werden, beliebige Daten in seinen
TAN-Generator einzugeben. So kann der Kunde dazu gebracht werden, eine TAN für
eine betrügerische Transaktion zu erzeugen. Wenn ein MITM diese Transaktion ohne
Verzögerung ausführt, hilft auch die Zeitbeschränkung der TANs nichts. Abbildung 4.13
zeigt ein Beispiel fü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 Empfängers - in den Generator eingeben
kann. Die Berechnung der TAN hängt dann nur von diesem eingegebenen Teil der Transaktionsdaten ab. Eine Manipulation der übrigen Transaktionsdaten durch einen MITMAngriff kann also nicht ausgeschlossen werden. Denkbar wäre beispielsweise, dass ein
Betrüger Zugang zu einem Konto hat, dessen Kontonummer identisch mit der Kontonummer eines Unternehmen ist, bei dem sehr viele Überweisungen eingehen. Solche
Unternehmen sind beispielsweise die Gebühreneinzugszentrale, Stadtwerke und Telekommunikationsunternehmen. Falls ein Kunde dann eine Überweisung zu Gunsten eines
43
solchen Unternehmens eingeben möchte, könnte ein MITM zwar die Kontonummer beibehalten, Betrag und Bankleitzahl aber ändern und so eine betrügerische Überweisung
veranlassen.
Durch die ungezielte Manipulation der ungeschützten Teile der Transaktionsdaten
kann ein MITM auch einen Schaden beim Kunden (finanziell) und eventuell beim ahnungslosen Zahlungsempfänger (durch anschließende polizeiliche Ermittlungen) verursachen. Der MITM hat dabei keinen unmittelbaren finanziellen Vorteil. Mögliche Motive
für diesen Angriff sind Rufschädigung, Rache oder Sabotage.
Trotz der geschilderten Schwachstellen sind die dynamischen TAN-Verfahren relativ
sicher, weil Angriffe auf andere Verfahren viel leichter möglich und somit für Angreifer
günstiger sind.
Die GAD plant, den sm@rtTANplus-Generator um einige Sicherheitsmerkmale zu
erweitern. So soll zukünftig die Eingabe der Transaktionsdaten durch eine optische
Übertragung vom Bildschirm aus per Flicker-Code erfolgen - ä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 bestätigenden Daten um einen angeblichen Sicherheitscode oder um eine Kontonummer handelt.
Die TAN-Generatoren können überall benutzt werden, so dass die dynamischen TANVerfahren mobil einsetzbar sind.
Die KLM-Schritte fü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 drücken (T), sich an Code erinnern (M), Code eingeben und bestätigen (6T), sich
an Transaktionsdaten erinnern (M), Transaktionsdaten eingeben und bestä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 für einen geübten Benutzer ein Zeitaufwand von 19T + 2K + 2W + 6M + A
+ G = 26,1 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Das TAN-Verfahren der BW-Bank kommt ohne einen Code und ohne Karte aus. Somit
entfallen gegenü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 benötigt insgesamt 19,3 Sekunden.
Das neue sm@rtTANplus-Verfahren, bei dem die Informationen per Flickercode über
den Bildschirm übertragen werden, benötigt folgende KLM-Schritte: Systemantwort abwarten (A), TAN-Eingabeaufforderung verstehen (M), zum TAN-Generator wechseln
(W), Karte einstecken (G = 3 Sekunden), Taste drücken (T), Gerät an Bildschirm halten
und Flickercode einlesen (G = 3 Sekunden), angezeigte Transaktionsdaten kontrollieren
44
”
(M), Knopf drü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 für einen geübten Benutzer ein Zeitaufwand von 7T
+ 2K + 2W + 4M + A + 2G = 16,3 Sekunden fü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
erhältlich. Der Preis dürfte leicht ü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, Beträ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 Schaltflächen geklickt wird. Die Bedeutung der Schaltflä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 zusätzlich zu den Ziffern noch blau hinterlegte Felder vorhanden. Diese dienen zur wiederholten Eingabe bereits eingegebener
Ziffern. Eine einmal gedrückte Schaltfläche kann nämlich aus Sicherheitsgründen nicht
ein zweites Mal angeklickt werden. Soll nun beispielsweise die Zahl 575 eingegeben werden, so werden zunächst die Ziffern 5 und 7 durch klicken auf die Schaltflächen fü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 Kästchen, das auf die erste
Position verweist - p1.
Das Verfahren ist neu und wird derzeit von keiner Bank eingesetzt.
Abbildung 4.15 gibt eine mö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 für die
kommende Transaktion benutzen soll.
45
Abbildung 4.14: verschlüsselte Dateneingabe beim pTAN-Verfahren; Quelle: Bernd Borchert
Abbildung 4.15: Ablauf beim pTAN-Verfahren
46
”
3. Der Kunde sucht ziffernweise auf dem pTAN-Bogen, welche Schaltfläche zu drücken
ist und
4. gibt einen Teil der Transaktionsdaten durch Drücken dieser Schaltflächen so verschlüsselt in den Rechner ein.
5. Die Information, welche Schaltfläche gedrückt wurde, wird vom Rechner zum
Bankserver gesendet.
6. Der Server ermittelt die entsprechende Ziffer, speichert sie und schickt sie zurü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 Schaltflä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, erhält so die kompletten erforderlichen Daten und führt den Auftrag aus.
Dieses Verfahren ist sicher vor herkömmlichen Phishing-Angriffen. Ebenfalls sicher ist
es vor manipulierenden MITM-Angriffen.
Allerdings kö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 für die dynamische TAN möglich ist. Dem Benutzer wird vorgespielt, er gäbe
einen Sicherheitscode mit Hilfe der pTAN ein. In Wirklichkeit handelt es sich aber bei
dem angeblichen Sicherheitscode um die Kontonummer des Betrügers.
Ein sabotierender Angreifer, der sich Zugang zum System verschafft hat, könnte auch
eine zufällige, aber gültige Eingabe erzeugen, ohne die zu verwendende Permutation zu
kennen. Dazu klickt er auf zufällige Schaltflächen. Eine gü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, führt ein Klick auf P3 zu einem Fehler
und einem Abbruch der Eingabe. Außerdem muss die Eingabe durch einen Klick auf OK
bestätigt werden, ohne dass die Eingabe vorher durch einen Fehler oder durch Drücken
von K abgebrochen wurde. Die Gesamtwahrscheinlichkeit für eine erfolgreiche Eingabe
durch pures Raten beträgt etwa 1,5% für bis zu 19 Stellen lange Zahlen. Für maximal
10 Stellen lange Zahlen beträgt die Wahrscheinlichkeit etwa 0,3%. Zum Vergleich: Die
Wahrscheinlichkeit, eine sechsstellige TAN zu erraten, beträgt lediglich 0,0001%.
47
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 umständliche, gewöhnungbedürftige Eingabe.
Die KLM-Schritte fü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), Größe der Eingabefelder anpassen (K), Kontonummer ziffernweise verschlüsseln und eingeben (10M + 10K), OK klicken (K). Somit
ergibt sich für einen geübten Benutzer ein Zeitaufwand von 12K + 2W + 13M + A +
G = 40,4 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Analyse der Kosten
Beim Permutations-TAN-Verfahren fallen Kosten fü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.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 zufällige Transaktionsnummer und sendet diese zusammen mit den Transaktionsdaten in einer SMS an das Mobiltelefon des Kunden.
4. Der Kunde erhält die SMS, prü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
”
Abbildung 4.16: Ablauf des mobile TAN-Verfahrens
7. Der Bankserver überprüft, ob die erhaltene mTAN der per SMS gesendeten entspricht und führt die Transaktion gegebenenfalls aus.
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 Übertragung der SMS
lässt sich zwar im Prinzip belauschen [BBK03], der Aufwand hierfü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 Gerät erfolgen, etwa in einem Laptop mit GPRS-Empfang,
das SMS empfängt, oder in einem internetfähigen Mobiltelefon wie dem iPhone von
Apple, von dem aus das Online-Banking-System genutzt wird. Ein Trojaner könnte hier
sowohl die Internet-Kommunikation als auch die SMS manipulieren und so einen MITMAngriff ermöglichen.
Die formale Analyse mit AVISPA zeigt eine Angriffsmöglichkeit, wenn der Anwender nicht überprüfen kann, von wem die erhaltenen SMS stammt. Hat der Anwender
Konten bei zwei verschiedenen Banken, so könnte ein MITM-Angreifer bei Eingabe einer legitimen Transaktion das zu Grunde liegende Konto auf das jeweils andere ändern
(siehe B.3). Diese Sicherheitslücke ließe sich leicht beheben, indem in der SMS auch die
Kontodaten des Kunden angezeigt werden.
Das Verfahren ist wegen der Verwendung eines Mobiltelefons von jedem beliebigen PC
aus nutzbar.
49
Die KLM-Schritte für das mobile TAN-Verfahren sind: SMS-Eingang abwarten (G =
10 Sekunden), Knopf zum Anzeigen der SMS drücken (T), Transaktionsdaten kontrollieren (M), Knopf zum Anzeigen der TAN drü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 für einen geübten Benutzer ein Zeitaufwand
von 8T + 2K + W + 3M + G = 21 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Analyse der Kosten
Bei dem mobilen TAN-Verfahren fallen Kosten für die Zustellung der SMS an. Die
Volksbanken berechnen hierfür 10 Cent pro Überweisung. Bei der Postbank ist das Verfahren für den Kunden zwar kostenlos, aber für die Bank dürften Kosten in ähnlicher
Größenordnung anfallen. Es ist davon auszugehen, dass Nutzer des mobilen TAN-Verfahrens
bereits ein Mobiltelefon besitzen. Deshalb werden die Anschaffungskosten für das Mobiltelefon hier nicht berücksichtigt.
4.3.2 Cardano-TAN
Das Cardano-TAN-Verfahren besteht aus einer Papierkarte, in die an unterschiedlichen
Stellen Löcher gestanzt sind. Der Kunde erhält von seiner Bank einen Block solcher
Karten. In einem Kommunikationsschritt schickt die Bank ein Bild mit Zahlenblöcken
an den Kunden. Der kann dann durch Auflegen einer bestimmten Cardano-TAN-Karte
in den Löchern die eingegebenen Transaktionsdaten überprüfen und die zugehörige TAN
ablesen und zur Bestätigung des Auftrags zur Bank zurückschicken. Abbildung 4.17 zeigt
die Verwendung der Cardano-TAN.
In diesem Beispiel kann die Zielkontonummer von oben nach unten auf den weißen
Kästchen abgelesen werden. Die TAN wird ebenfalls von oben nach unten auf den roten
Kästchen abgelesen und lautet hier 2239. Jede Karte kann nur ein einziges Mal benutzt
werden.
Der Kommunikationsablauf funktioniert wie folgt (Abbildung 4.18):
2. Der Rechner sendet die Transaktionsdaten an den Bankserver.
3. Der Bankserver wählt eine zufällige TAN und die nächste zu benutzende CardanoKarte und erzeugt daraus und aus Teilen der Transaktionsdaten ein Bild mit Zahlenblö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 Zahlenblöcken und die Nummer der zu
verwendenden Cardano-Karte angezeigt.
50
”
Abbildung 4.17: Funktionsweise des Cardano-TAN-Verfahrens; Quelle: Bernd Borchert
Abbildung 4.18: Ablauf des Cardano-TAN-Verfahrens
51
5. Der Kunde legt die entsprechende Cardano-Karte auf den Bildschirm und liest mit
deren Hilfe die ü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 bestätigen.
7. Der Rechner sendet die Transaktionsdaten und die TAN an den Bankserver.
8. Der Bankserver prüft die erhaltene TAN und führt dann gegegenenfalls die Transaktion aus.
Das Cardano-TAN-Verfahren ist sicher gegenüber herkömmlichen Phishing- und MITMAngriffen. Ein Angreifer kennt die Position der Löcher in der Karte nicht, und kann somit
nicht die erforderliche TAN auslesen. Andererseits kann er auch die im Bild verschlüsselt
enthaltenen Transaktionsdaten nicht ändern.
Wegen der fehlenden Bedeutungsinformationen ist beim Cardano-TAN-Verfahren auch
der in Abbildung 4.13 beschriebene kombinierte Phishing-MITM-Angriff möglich.
Ein Nachteil besteht in der komplizierten Bedienung: Die verwendeten Folien müssen
exakt über das auf dem Computerbildschirm angezeigte Bild passen. Da die tatsächliche
Bildgröße von der Auflösung und den Abmessungen des Bildschirms abhängen, muss
die Bildgröße im Einzelfall manuell angepasst werden. Außerdem muss der Benutzer
die Folie genau ausrichten. Größenänderung und Ausrichtung sind in diesem Verfahren
zusätzliche Arbeitsschritte des Benutzers.
Das Verfahren lä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), Größe des Anzeigefeldes anpassen (K), Transaktionsdaten prü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 für einen geübten Benutzer ein Zeitaufwand von
6T + 3K + 2W + 6M + A + G = 22,8 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Analyse der Kosten
Beim Cardano-TAN-Verfahren fallen Kosten an für die Herstellung und Zusendung des
TAN-Blocks. Der Einfachheit halber wird angenommen, dass 20 lose, bedruckte Folien
52
”
im Format DIN A7 in einem Brief verschickt werden und insgesamt dafür 60 Cent an
Kosten anfallen. Damit ergäben sich Kosten in Höhe von 3 Cent pro Transaktion.
4.3.3 Visuelle TAN
Die visuelle TAN (vTAN) benutzt mit kleinen schwarzen Punkten bedruckte Folien zur
sicheren Datenübertragung von der Bank zum Kunden. Diese Schlüssel-Folien ergeben
in Überlagerung mit einem korrespondierendem Bild auf dem Computerbildschirm eine
Anzeige, auf der Informationen wie Transaktionsdaten oder TANs angezeigt werden
kö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 Einmalschlüssel dar. Durch
die Überlagerung der Folien- und der Bildschirmpixel ergibt sich durch eine geschickte
Anordnung eine XOR-Verknüpfung der Bildpunkte, so dass ein schwarzer Text vor einem
50% grauen Hintergrund erscheint. Dazu werden Blö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 über ihn eine Folie mit einem
identischen Block, so ergibt sich ein Block mit 2 weißen und zwei schwarzen Pixeln.
Bei genügend kleiner Blockgröße erscheint dem menschlichen Betrachter dieser Block
als grauer Punkt. Ist die Folie aber komplementär zum Bildschirmblock, also die weißen
und schwarzen Pixel vertauscht, so erscheint der Block völlig schwarz. Abbildung 4.19
verdeutlicht dieses Prinzip.
Abbildung 4.19: Verschlüsselung der Bildpunkte bei der visuellen TAN; Quelle:
Rheinisch-Westfälische Technische Hochschule Aachen
Um das Verfahren nutzen zu können, wird zunächst zufällig eine Schlüsselfolie mit
2x2-Blöcken generiert. Jeder Block besteht aus zwei weißen und zwei schwarzen Pixeln,
und für jeden Block gibt es zwei mögliche, komplementäre Belegungen, die je mit gleicher Wahrscheinlichkeit auftreten. Ein gegebenes Scharz-Weiß-Bild lässt sich dann ver-
53
schlüsseln, indem für jedes Pixel des Bildes durch einen 2x2-Block ersetzt wird. Zur Darstellung eines schwarzen Pixels wird ein zum darüberliegenden Block auf der Folie komplementärer Block erzeugt, zur Darstellung eines weißen Pixels wird der darüberliegende
Folienblock kopiert. Da die Anordnung der Blöcke auf der Folie zufällig gewählt wird,
erscheint die Anordnung der Blöcke auf dem Bildschirm ebenfalls zufällig. Ohne die
Entschlüsselungsinformation, die die Folie bietet, könnte jeder Block des verschlü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 ähnlich dem des Cardano-TAN-Verfahrens:
2. Der Rechner sendet die Transaktionsdaten an den Bankserver.
3. Der Bankserver wählt eine zufällige TAN und die nächste zu benutzende SchlüsselFolie und erzeugt daraus und aus Teilen der Transaktionsdaten ein verschlüsseltes
Bild. Dieses Bild wird zusammen mit der Nummer der zu verwendenden SchlüsselFolie an den Rechner geschickt.
54
”
Abbildung 4.21: Ablauf des visuellen TAN-Verfahrens
4. Auf dem Rechner wird das verschlüsselte Bild und die Nummer der zu verwendenden Folie angezeigt.
5. Der Kunde legt die entsprechende Schlüssel-Folie auf den Bildschirm und liest mit
deren Hilfe die ü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 bestätigen.
7. Der Rechner sendet die Transaktionsdaten und die TAN an den Bankserver.
8. Der Bankserver prüft die erhaltene TAN und führt dann gegegenenfalls die Transaktion aus.
Diese Verfahren ist sicher vor Phishing- und MITM-Angriffen. Ein Angreifer kann die
TAN nicht ohne Kenntnis der Schlü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 fälschen.
55
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), Größe des Anzeigefeldes anpassen (K), Transaktionsdaten prü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 für einen geübten
Benutzer ein Zeitaufwand von 6T + 3K + 2W + 6M + A + G = 27,8 Sekunden für das
Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Analyse der Kosten
Beim visuellen TAN-Verfahren fallen Kosten für die Herstellung und den Versandt der
Folien an. Nimmt man ähnlich wie beim Cardano-TAN-Verfahren an, dass 20 Folien
in einem Brief verschickt werden und dafür insgesamt Kosten in Höhe von 60 Cent
entstehen, so ergeben sich auch hier Kosten in Höhe von 3 Cent pro Transaktion.
4.3.4 Fotohandy-TAN
Das an der Universität Tübingen entwickelte Kamera-TAN-Verfahren benutzt zur Erzeugung dynamischer TANs ein Mobiltelefon mit integrierter Kamera bzw. eine Digitalkamera. Transaktionsdaten werden zunä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 prü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 benötigt man keine kostenpflichtige, mobilfunknetzabhängige Übertragung
per SMS.
Das Verfahren lä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
enthält. Dieses Bild schickt der Server zurü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
”
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 abhängig ist von den extrahierten Daten und einem im Mobiltelefon gespeicherten geheimen Schlüssel. Die
dynamische TAN wird dem Benutzer ebenfalls auf dem Telefondisplay angezeigt.
6. Der Benutzer prü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 überprüft, ob Transaktionsdaten und TAN zusammen passen. Im
positiven Fall wird die Transaktion ausgeführt.
Dieses Verfahren funktioniert im Prinzip ähnlich wie das sm@rtTANplus-Verfahren, nur
dass hier nicht der Anwender die Eingabe der Daten in das Gerät vornimmt, sondern
die Daten vom Computerbildschirm eingelesen werden. Eine Manipulation der Daten
bemerkt der Anwender.
Die formale Sicherheitsanalyse mit AVISPA findet ebenfalls keine Angriffsmöglichkeiten
(siehe Anhang).
57
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 prüfen (M), Taste
zum Anzeigen der TAN drü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 für einen geübten Benutzer ein Zeitaufwand von 8T +
2K + W + 3M + 2A + G = 18 Sekunden für das Durchlaufen des sicherheitsrelevanten
Teils des Verfahrens.
Analyse der Kosten
Wenn man davon ausgeht, das der Benutzer bereits ein Mobiltelefon besitzt, dann fallen dafür im Rahmen dieses Verfahrens keine Kosten an. Es fallen nur Kosten für die
Bereitstellung der Software an. Bei genügend vielen Kunden sind die Kosten für jeden
einzelnen vernachlä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 Gerät, das speziell für den Einsatz
im Internet entwickelt wurde. Mit ihm lässt sich die Identität von Benutzern biometrisch
verifizieren, und es können Transaktionen auf sichere Weise durchgeführt werden. Der
Internetpassport hat etwa die Größe einer Kreditkarte. Er verfügt ü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 Durchführen von Transaktionen verwendet werden. Dazu
werden zunächst Transaktionsdaten in einen Computer eingegeben. Diese Daten werden über einen Flicker-Code vom Bildschirm in das Gerä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 lä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 verschlüsselter Form enthält.
4. Der Kunde aktiviert seinen Internetpassport, indem er seinen Finger über den
Fingerabdrucksensor streift. Der Flicker-Code wird am Bildschirm angezeigt und
vom Internetpassport eingelesen.
58
”
Abbildung 4.23: Ablauf des Internetpassport-Verfahrens
5. Der Internetpassport entschlüsselt die Daten mit Hilfe des gespeicherten, geheimen Schlü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 bestä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 prüft, ob TAN und Transaktionsdaten zusammen passen. Im positiven Fall wird die Transaktion durchgeführt.
Dieses Verfahren ist sicher gegenüber Phishing- und MITM-Angriffen. Die Bank führt
die Transaktion nur nach Erhalt der korrekten TAN aus. Die TAN kann nur vom InternetPassport entschlü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.
Die KLM-Schritte des InternetPassport-Verfahrens sind: Systemantwort abwarten (A),
InternetPassport einschalten (T), Fingerabdruck einlesen (G = 3 Sekunden), Gerät an
59
Bildschirm halten (G = 3 Sekunden), Antwort des Gerätes abwarten (A), Transaktionsdaten prü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 für einen geübten Benutzer ein Zeitaufwand von 7T + 2K + W
+ 3M + 2A + 2G = 20,5 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils
des Verfahrens.
Analyse der Kosten
Für den InternetPassport ist noch kein Preis festgesetzt, da das Produkt noch nicht verkauft wird. Der Preis dürfte aber höher sein als der für den ähnlich gebauten sm@rtTANplusGenerator mit Flickercode, der in 4.2.2 mit 20 ¿ geschätzt wurde. Beim InternetPassport
fallen höhere Kosten an für das besser auflösende Display und den Fingerabdruckleser.
Nimmt man daher 30 ¿ als Preis an, dann kostet eine Transaktion 12 Cent.
4.3.6 Monitor-TAN
Eine Möglichkeit, Transaktionen sicher vor Angriffen zu machen, ohne dass der Kunde
die gewohnte Arbeitsumgebung seines Rechners verlassen mü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 verschlüsselte Bilder senden, die nur vom Gerät entschlüsselt werden können. Dazu filtert
das Gerät den Datenstrom zum Monitor. Sobald es ein verschlüsseltes Bild vorfindet,
entschlüsselt es dies. Am Bildschirm wird dann das entschlüsselte Bild angezeigt. Das
Gerät könnte ähnlich aussehen wie in Abbildung 4.24 gezeigt.
Abbildung 4.24: Mögliche Ausführung eines Monitor-Dongles; Quelle: Wikipedia
60
”
Ein möglicher Kommunikationsablauf ist der mobile TAN nachempfunden. Dabei werden eingegebene Transaktionsdaten zunächst zur Bank geschickt. Dort werden sie zusammen mit einer TAN in einem verschlüsselten Bild gespeichert und zurückgeschickt.
Der Computer behandelt das verschlüsselte wie ein normales Bild und sendet die Darstellung an den Monitor. Das zwischengeschaltete Gerät erkennt das verschlü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 zufällige Transaktionsnummer und erzeugt ein verschlüsseltes Bild, in dem die Transaktionsdaten und die Transaktionsnummer stehen. Das verschlüsselte Bild wird zurück zum Rechner geschickt.
4. Der Rechner leitet das verschlüsselte Bild an den Monitor-Dongle.
5. Der Monitor-Dongle entschlüsselt die Daten und sendet das entschlüsselte Bild an
den Bildschirm.
6. Der Benutzer sieht die Transaktionsdaten und die TAN am Bildschirm.
7. Nachdem der Benutzer die Transaktionsdaten kontrolliert und für richtig befunden
hat, gibt er die TAN in den Rechner ein.
8. Der Rechner sendet die TAN und die Überweisungsdaten an den Server der Bank.
9. Die Bank prüft, ob die TAN zu den Überweisungsdaten passt und führt gegebenenfalls die Transaktion aus.
61
Dieses Verfahren ist sicher vor Phishing- und MITM-Angriffen. Ein auf dem Rechner
befindlicher Trojaner kann das verschlüsselte Bild weder lesen noch unbemerkt manipulieren. Dadurch gelangt der Trojaner weder an die TAN, noch kann er die Transaktionsdaten unbemerkt ä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 über den tatsächlichen Inhalt der
manipulierten Transaktion täuschen und ihn so zum Ablesen und zur Eingabe der TAN
bringen, da jener die Transaktionsdaten im verschlüsselten Bild nicht ändern kann und
dieser so eine Manipulation bemerkt.
Die Sicherheit dieses Verfahrens setzt voraus, dass nach der Entschlüsselung des Bildes
- im Monitor also - keine betrügerischen Prozesse mehr ablaufen. Ein manipulierter
Bildschirm könnte das entschlüsselte Bild unbemerkt auslesen und manipulieren, so dass
ein MITM-Angriff hier denkbar wäre. Somit ist der Monitor-Dongle nur in einer sicheren
Umgebung einsetzbar und sollte nicht in Internet-Cafés verwendet werden.
Das Verfahren lässt sich nicht leicht an jedem beliebigen PC einsetzen. Benutzer von
Laptops ohne externem Display können den Dongle nirgendwo anschließen. Bei fremden
Rechnern könnten die Anschlüsse unpassend sein. Außerdem ist das Umstecken der
Kabel umständlich. Dieses Verfahren ist also nicht mobil einsetzbar.
Die KLM-Schritte des Monitor-Dongle-Verfahrens sind: Systemantwort abwarten (A),
Transaktionsdaten prüfen (M), auf das TAN-Eingabefeld klicken (K), TAN ablesen (M),
TAN eingeben (6T), OK klicken (K). Somit ergibt sich für einen geübten Benutzer
ein Zeitaufwand von 6T + 2K + 2M + A = 10,2 Sekunden für das Durchlaufen des
sicherheitsrelevanten Teils des Verfahrens.
Analyse der Kosten
Der für dieses Verfahren benötigte Monitor-Dongle existiert bisher nur als Idee, weshalb
eine Kostenabschätzung schwierig ist. Ein dem Dongle ähnliches Produkt ist eine externe,
per USB-Schnittstelle anschließbare Grafikkarte. Günstige externe Grafikkarten kosten
im Handel etwa 40 ¿. Wenn der Monitor-Dongle genauso teuer ist, dann ergeben sich
Kosten in Höhe von 16 Cent pro Überweisung.
62
4.4 Schnittstellenklasse Bidirektional - Bidirektional“
”
”
4.4.1 WYSIWYS
What you see is what you sign (WYSIWYS) ist ein an der Universität Karlsruhe entwickeltes Verfahren, das zur Erzeugung einer Signatur ein Mobiltelefon mit eingebauter
Kamera nutzt.[Deu06b] Der Benutzer überprüft zunächst die zu unterschreibenden Daten auf dem normalen Computerbildschirm. Dann fotografiert er diese Daten direkt
vom Bildschirm ab. Außerdem überträgt der Rechner die Daten auf elektronischem Weg
(beispielsweise per Bluetooth) in das Mobiltelefon. Hier prüft ein Programm, ob das
aufgenommene Bild zu den elektronisch ü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 zurück an den Computer.
Das Verfahren kann beliebige Übermittlungsdaten authentifizieren und ist nicht nur
fü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 übermittelt die Daten per Bluetooth an das
Mobiltelefon.
63
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 überträ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 führt die
Transaktion im positiven Fall durch.
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, möglich ist, den Datenvergleich schnell und zuverlässig durchzuführen. Vor allem
Überweisungen beim Online-Banking könnten manipuliert werden, wenn sich Manipulationen bei einzelnen Ziffern und Kommata nicht sicher erkennen lassen. Aus einem
Betrag von 00012,00 ¿ könnten so beispielsweise 80012,00 ¿ oder 0001200 ¿ werden.
Diese kleinen Unterschiede müsste das Verfahren sicher erkennen, ohne dabei legitime
Transaktionen zu behindern.
Die Patentschrift enthält keine explizite Empfehlung, während der Kommunikation
eine Nonce zu verwenden. Für die gleiche Transaktion würde somit immer die gleiche dynamische TAN generiert. Somit könnte ein Betrüger einen Replay-Angriff durchführen.
Dies lässt sich leicht verhindern, indem Bank und Kamera einen gemeinsamen Zähler
verwenden, der in die Berechnung der TAN mit einfließt und der sich nach jedem Gebrauch erhöht. Eine andere Möglichkeit, hier einen Replay-Angriff zu verhindern ist, die
aktuelle Zeit mit in die Berechnung der TAN einfließen zu lassen.
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 prüfen (M), Taste
zum Anzeigen der TAN drü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 für einen geübten Benutzer ein Zeitaufwand von 8T +
2K + W + 3M + 2A + G = 18 Sekunden für das Durchlaufen des sicherheitsrelevanten
64
”
Analyse der Kosten
Genau wie bei der Fotohandy-TAN aus Abschnitt 4.3.4 kann davon ausgegangen werden,
dass für das WYSIWYS-Verfahren keine transaktions- oder kundenabhängigen Kosten
anfallen.
4.4.2 HBCI-Verfahren
FinTS ist ein vom ZKA (Zentraler Kreditausschuss) veröffentlichter Standard für sicheres
Online-Banking [Zen06a]. Dieser Standard ist eine Weiterentwicklung des Homebanking
Computer Interface (HBCI) und umfasst Spezifikationen zu Kommunikationsabläufen,
zu Geschäftsvorfällen und zur Sicherheit. Banken können damit Online-Banking in einer
standardisierten Weise anbieten. Über 2000 deutsche Banken bieten dies an [Zen06b].
Für Bankkunden gibt es viele Softwareprogramme, die FinTS unterstützen. Die Standardisierung erlaubt es also, dass Bankkunden gleich welcher Bank mit einem HomebankingProgramm ihrer Wahl arbeiten kö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 können. Die Spezifikation von FinTS PIN/TAN lä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 näher auf diesen Teil des Standards eingegangen. Zum Einsatz kommen vor allem die indizierte TAN, die mobile TAN und die elektronische, dynamische
TAN.
Für HBCI gibt es ebenfalls mehrere Betriebsmöglichkeiten. Bei der einfachsten und
ältesten werden die elektronischen Signaturen direkt auf dem Rechner des Kunden erstellt. Der dazu nötige geheime Schlüssel befindet sich auf einem externen Speichermedium, üblicherweise auf einer Diskette oder einem USB-Stick. Weitere Verfahren benutzen
Chipkartenleser und Chipkarten, auf denen der geheime Schlüssel gespeichert ist.
Der Kommunkationsablauf des Verfahrens mit Schlüsseldiskette ist simpel (siehe Abbildung 4.27):
Abbildung 4.27: Ablauf von HBCI mit Schlüsseldiskette
65
Bei den Chipkarten-Verfahren kommen verschiedene Chipkarten zum Einsatz. Die geheimen Schlüsel sind in dem Chip der Karte gespeichert. Kryptographische Funktionen
wie Ver- und Entschlüsselung und Erstellung von Signaturen werden von dem in der
Karte integrierten Mikroprozessor durchgeführt. Es gibt DES-Chipkarten, die auf der
Two-key-triple-DES-Verschlüsselung beruhen. RSA-Chipkarten verwenden die asymmetrische RSA-Verschlüsselung. Die neuere ZKA Banken-Signaturkarte (auch SECCOSChipkarte genannt) benutzt ebenfalls die RSA-Verschlüsselung, kann daneben aber auch
noch andere Funktionen wie z. B. elektronische Geldbörse oder einfache Datenspeicherung enthalten. All den Chipkarten ist gemein, dass die kryptographischen Funktionen
innerhalb des Chips ablaufen. Die in ihnen gespeicherten geheimen Schlüssel lassen sich
nicht direkt auslesen. Insbesondere können dadurch die Schlüssel auch nicht durch einen
mit einem Trojaner infizierten Kundenrechner gestohlen werden.
Ob ein MITM-Angriff bei Benutzung von HBCI mit Chipkarte möglich ist, hängt vom
verwendeten Kartenleser ab. Der ZKA unterscheidet drei Klassen von Kartenlesern:
einfache Kartenleser ohne weitere Ein- oder Ausgabemö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 für die Chipkartenleser der Klasse 1 und 2 identisch mit dem Ablauf des HBCI-Verfahrens mit Schlü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.
66
”
67
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. (entfällt bei Klasse 1)
4. Nach der Eingabe der korrekten PIN (entfällt bei Klasse 1) signiert der Kartenleser
die Transaktionsdaten und sendet sie zurück an den Rechner.
5. Der Rechner leitet die signierten Transaktionsdaten an den Server der Bank.
6. Der Bankserver prüft die Gültigkeit der Signatur und führt die Transaktion gegebenenfalls durch.
Chipkartenleser der Sicherheitsklasse 3 bieten durch ihr eingebautes Display theoretisch die Möglichkeit, Tansaktionsdaten vor dem Unterschreiben anzeigen zu lassen. Somit könnten Manipulationen, die auf einem trojanerbefallenen Kundenrechner stattfinden, auf dem sicheren Lesegerät entdeckt werden. Allerdings bieten die heutigen HBCIfähigen Online-Banking-Programme diese Überprüfungsmöglichkeit nicht an. Trotz der
prinzipiellen Angriffsmöglichkeit ist es aber bislang noch zu keinem derartigen Betrugsfall gekommen.2 Theoretisch wäre folgender, sicherer Kommunikationsablauf möglich
(Abbildung 4.32):
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
”
Abbildung 4.32: Theoretisch möglicher Ablauf von HBCI mit Kartenleser der Sicherheitsklasse 3
4. Wenn der Kunde die im Kartenleser angezeigte Transaktion durchführen möchte,
gibt er zur Bestätigung seine PIN in den Kartenleser ein.
5. Der Kartenleser signiert nach der Eingabe der korrekten PIN die Transaktionsdaten und sendet sie zurück an den Rechner.
6. Der Rechner leitet die signierten Transaktionsdaten an den Server der Bank.
7. Der Bankserver prüft die Gültigkeit der Signatur und führt die Transaktion gegebenenfalls durch.
Das HBCI-Verfahren mit Schlüsseldiskette ist sicher vor einfachen Phishing-Angriffen,
da es bei diesem Verfahren keine Transaktionsnummern gibt. Theoretisch könnte aber
ein Benutzer dazu gebracht werden, die Datei, die den geheimen Schlüssel enthält sowie
die dazugehörige PIN an einen Angreifer zu senden. Ein mit einem Trojaner befallener
Kundenrechner stellt ein hohes Risiko dar: Es lässt sich dann nicht nur ein MITMAngriff durchführen, sondern auch der geheime Schlüssel der Schlüsseldiskette kann leicht
ausgespäht werden und stünde damit für uneingeschränkte, betrügerische Transaktionen
zur Verfügung.
Das HBCI-Verfahren mit Kartenlesern der Klasse 1 und 2 ist sicher vor PhishingAngriffen, da keine Transaktionsnummern verwendet werden, die gestohlen werden könnten.
Auch die geheimen Schlüssel können nicht entwendet werden, da sie nie die Chipkarte verlassen. Ein MITM-Angriff kann aber trotzdem noch unbemerkt ablaufen. Dabei
ändert ein Trojaner auf dem Kundenrechner eine vom Kunden eingegebene Transaktion zu Gunsten des Angreifers. Diese manipulierte Transaktion wird von der HBCI-
69
Chipkarte signiert, ohne dass der Kunde die Möglichkeit hä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
verlässt den Kartenleser nicht. Der geheime Schlüssel verlässt zu keiner Zeit den Chip
der Chipkarte. Ein Phisher kann also keine geheimen Daten erbeuten, die ihn befähigen
würden, eine korrekt signierte, betrügerische Transaktion zu erstellen. Ein MITM-Angriff,
der eine vom Kunden eingegebene Transaktion manipuliert, ist auch ausgeschlossen,
wenn der Kunde sä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 verändert werden. Schadsoftware, die auf dem
Kundenrechner installiert sein könnte, kann das Lesegerätes ebenfalls nicht umprogrammieren. Die Lesegeräte können zwar durch Firmware-Updates umprogrammiert werden,
aber sie akzeptieren nur sichere, zertifizierte Updates.
AVISPA findet für das spezifizierte HBCI 3-Verfahren keine Angriffe.
Die speziellen Online-Banking-Programme erlauben es, mehrere Transaktionen zusammen auszuführen und nur einmal unterschreiben zu müssen. Dadurch werden die Verfahren aber eventuell unsicherer. Der Anwender kontrolliert bei Sammelüberweisungen
nä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 könnte sich diese Tatsache zu Nutze machen,
indem er zwei Überweisungen innerhalb einer Sammelüberweisung so manipuliert, dass
die Summe der Kontonummern unverändert bleibt, aber eine Kontonummer der zwei
manipulierten Überweisungen einen beliebig manipulierten Wert erhält. Deshalb und
aus Gründen der besseren Vergleichbarkeit mit den anderen Verfahren wird hier davon
ausgegangen, dass der Benutzer jede Transaktion einzeln signiert.
Die hier beschriebenen HBCI-Verfahren setzen zum Betrieb eine spezielle Online-BankingSoftware und installierte Gerätetreiber für die Kartenleser voraus und können nicht von
jedem beliebigen PC aus eingesetzt werden.
Die KLM-Schritte des HBCI-Verfahrens mit Schlüsseldiskette und mit Chipkartenleser der Klasse 1 sind: Systemantwort abwarten (A), PIN-Eingabeaufforderung verstehen (M), zum Diskettenlaufwerk oder Kartenleser wechseln (W), Schlü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 für einen geübten Benutzer ein Zeitaufwand
von 6T + 2K + 2W + 2M + A + G = 16 Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
70
”
Beim Verfahren mit dem einem Kartenleser der Klasse 2 gibt der Benutzer seine PIN
direkt in den Kartenleser ein. Folgende Schritte durchlä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 drücken (T). Somit ergibt
sich für einen geübten Benutzer ein Zeitaufwand von 7T + W + 2M + A + G = 13,7
Sekunden für das Durchlaufen des sicherheitsrelevanten Teils des Verfahrens.
Beim Verfahren mit einem Kartenleser der Klasse 3 muss der Benutzer zusätzlich die
Transaktionsdaten im Display kontrollieren. Er führt folgende Schritte aus: Systemantwort abwarten (A), PIN-Eingabeaufforderung verstehen (M), zum Kartenleser wechseln
(W), Chipkarte einstecken (G = 5 Sekunden), Transaktionsdaten kontrollieren (M), OK
drücken (T), sich an die PIN erinnern (M), PIN eingeben (6T bei sechstelliger PIN),
OK drücken (T). Somit ergibt sich für einen geübten Benutzer ein Zeitaufwand von 8T
+ W + 3M + A + G = 15,6 Sekunden für das Durchlaufen des sicherheitsrelevanten
Analyse der Kosten
Im Rahmen des Online-Banking mit HBCI fallen Kosten fü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 gü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 ungefähr 50 ¿.
Es gibt aber auch kostenlose Open-Source-Programme, zum Beispiel GnuCash. In den
günstigsten Varianten kostet somit das HBCI-Verfahren mit Schlü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 Erhöhung der Sicherheit bei der
”
Erstellung elektronischer Signaturen mittels Chipkarte“[Deu06a] funktioniert ä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 über eine Zifferntastatur des Lesegerä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
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.
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 könnte somit auch in nicht vertrauenswürdiger Umgebung eingesetzt werden,
etwa in Geschäften oder Internet-Cafés.
Die PIN des Benutzers ließe sich aber mit einem manipulierten Kartenleser immer
noch abhören. So wäre es denkbar, dass ein Kunde zunächst eine korrekte Transaktion
an einem betrügerischen Rechner mit einem angeschlossenen, betrügerischen Kartenleser
durchführt und dabei seine PIN preisgibt. Anschließend könnte eine zweite, betrü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 Angriffsmöglichkeit ausgeschaltet werden, so muß der Kunde entweder den Signiervorgang direkt auf der Karte bestätigen ein Knopfdruck wü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
”
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
für einen sicheren Betrieb einen Bestätigungsknopf auf der Karte drücken muss. Somit
ist das Verfahren nicht mobil, und analog zur Ausführungszeit des HBCI-Verfahrens der
Sicherheitsklasse 3 und zuzüglich eines Tastendrucks zur Bestätigung auf der Karte (T)
ergeben sich für einen geübten Benutzer 16,1 Sekunden.
Analyse der Kosten
Da die Karte mit Display bislang noch nicht konkret realisiert wurde, ist es schwer,
die Kosten hierfür zu schätzen. Die benötigte Hard- und Software ist ähnlich wie beim
HBCI-Verfahren der Sicherheitsklasse 3, aber die Karte selbst wäre vermutlich teurer.
HBCI-Chipkarten werden von den Banken für etwa 10 ¿ ausgegeben. Wenn man für
eine Display-Chipkarte einen Preis von 20 ¿ annimmt, ergeben sich insgesamt Anschaffungskosten in Höhe von 60 ¿ oder 24 Cent pro Transaktion.
73
74
Aus der Analyse der Online-Banking-Verfahren ergeben sich zunächst die geforderten
Vergleichsmöglichkeiten. Darüberhinaus ließen sich bislang unbekannte Sicherheitslücken
und mögliche Reparaturen finden. In diesem Kapitel werden die Ergebnisse des Vergleichs und weiterfü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 für
das iTAN-Verfahren unter einem Cent pro Transaktion, für das HBCI 3-Verfahren aber
bei 20 Cent pro Transaktion. Die benutzten Maße bieten somit eine hinreichende Trennschärfe,
um die Verfahren untereinander vergleichen zu kö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 können. Insbesondere Manipulationen durch MITM-Angriffe
können hiermit nicht verhindert werden. Weiter gibt es Verfahren, bei denen herkömmliche
Phishing- und MITM-Angriffe erfolglos bleiben. Allerdings könnte ein Angriff wie in
Abbildung 4.13 gezeigt bei einem gutgläubigen Anwender Erfolg haben, da die Art der
Transaktion nicht manipuliersicher zum Anwender übertragen wird. Schließlich gibt es
noch die Klasse an Verfahren, bei denen neben den Transaktionsdaten auch die Art der
Transaktion für den Anwender zweifelsfrei erkannt werden kann. Die Klassen werden
der Ü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.
Demgegenü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 verblüfft daher nicht, dass es kein Verfahren gibt, das allen anderen in allen Kategorien
überlegen ist. Diese Aussage lä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
Tabelle 5.1: Übersicht der Bewertung der Legitimationsverfahren
76
5.2 Empfehlungen für den Entwurf neuer Token
trieren. So gibt es Verfahren, die zwar eine hohe Benutzerfreundlichkeit in Form eines
niedrigen KLM-Wertes aufweisen, dafür aber überdurchschnittlich teuer sind, wie zum
Beispiel HBCI 3 oder der Monitor-Dongle.
Ideal wäre hier ein Verfahren, dass zur Sicherheitsklasse A gehört, mobil ist und im
Diagramm möglichst weit unten links positioniert ist. Bewertet man die Werte der Transaktionskosten in Cent und die Werte der Ausführungszeit in Sekunden zu gleichen Gewichten, so schneiden Fotohandy-TAN und das WYSIWYS-Verfahren am besten ab.
An dritter Stelle käme das in Vorbereitung befindliche sm@rtTANplus-Verfahren mit
Flickercode. Alle drei Verfahren gehören zur Sicherheitskategorie A und sind mobil benutzbar.
5.2 Empfehlungen für den Entwurf neuer Token
Aus der Analyse der Verfahren und deren Schwachstellen lassen sich einige DesignRichtlinien für den Entwurf neuer Token gewinnen, die sicher vor Phishing und MITMAngriffen sind.
1. Die Transaktionsdaten müssen in das Gerät gelangen.
2. Der Anwender muss die Transaktionsdaten im Gerät kontrollieren können, und
zwar indem er die Daten direkt in das Gerät eingibt oder indem er sich die Daten
auf einem sicheren Display anzeigen lässt.
3. Die TAN / Signatur und die Transaktionsdaten müssen miteinander verknü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 abhör- und manipuliersicher
zum Gerät übertragen. Oder das Gerät berechnet die Signatur / TAN unter Einbeziehung der Transaktionsdaten und eines geheimen Schlüssels selbst.
4. Zum Abschluss einer Transaktion muss das Verfahren die Interaktion zwischen
Anwender und Gerät erzwingen. Das geht, indem der Anwender eine TAN im
Gerät ablesen und in den Computer eingeben muss, indem der Anwender einen
Bestätigungsknopf am Gerät drücken muss, oder indem er seine PIN in das Gerät
eingeben muss.
5. Die Bedeutung der Daten soll Teil der Transaktionsdaten sein, und das Gerät
soll die Bedeutung der Daten zusammen mit den Daten anzeigen. So kann der
Anwender nicht über die Bedeutung der Daten getäuscht werden.
6. Die erzeugten TANs oder Signaturen sollen sich für identische Transaktionsdaten
unterscheiden, um Replay-Angriffe zu verhindern. Die Verwendung von Nonces,
Zeitstempeln oder Zählerständen kann das ermö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
Abbildung 5.1: Gegenüberstellung des Zeitbedarfs und der Kosten der MITMresistenten Verfahren
Transaktionskosten [Cent]
5.3 Kriterien für sichere Online-Banking-Verfahren
7. Nach mehreren falschen Eingaben (ü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 für eine bestimmte Zeit, oder bis der Anwender sich persönlich
mit seiner Bankfiliale in Verbindung gesetzt hat, gesperrt werden.
5.3 Kriterien für sichere Online-Banking-Verfahren
Vergleicht man die Verfahren, die resistent gegen MITM-Angriffe sind, so lässt sich
feststellen, dass die Sicherheit auf drei unterschiedliche Weisen erreicht werden kann.
Die erste Möglichkeit ist die Verwendung eines Tokens, der aus Transaktionsdaten,
einer Nonce und einem geheimen Schlüssel eine TAN generiert. Die Transaktionsdaten
müssen dabei direkt in dem Gerät vom Anwender überprüft werden können. Der Prototyp dieses Protokolls ist das sm@rtTANplus-Verfahren, dass sich bereits in der formalen
Sicherheitsanalyse bewährt hat. Token dieser Variant müssen also zur Klasse bidirek”
tional - keine“ oder zu ausgehend - eingehend“ gehören.
”
Die zweite Möglichkeit ist, ein Token zu nutzen, dass Nachrichten entschlüsseln kann.
Dazu sendet der Anwender zunächst unverschlüsselte Transaktionsdaten zur Bank. Diese generiert eine zufällige TAN und speichert TAN und Daten intern ab. Außerdem
sendet sie die Daten zusammen mit der TAN verschlüsselt an den Token zurück. Der
Token entschlüsselt die Nachricht und prä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 zurück zur Bank. Der Prototyp dieser
Variante ist das mobile TAN-Verfahren, das sich - nach kleiner Modifikation - ebenfalls
in der formalen Sicherheitanalyse bewährt hat. Token dieser Variante gehören zur Klasse
ausgehend - eingehend“.
”
Die dritte Möglichkeit ist die Nutzung der digitalen Signatur. Diese Variante ähnelt
der ersten, nur dass keine TAN erzeugt wird, die vom Anwender abgetippt werden muss,
sondern eine digitale Signatur direkt vom Gerät ohne Umweg über den Anwender zusammen mit den Transaktionsdaten zur Bank geschickt wird. Hierbei muss der Anwender
die Daten in dem Gerät kontrollieren können und die Signatur durch einen Knopfdruck
am Gerät freigeben. Der Prototyp dieser Variante ist das HBCI-3-Verfahren, das auch
den formalen Sicherheitstest von AVISTA überstanden hat. Die Token dieser Variante
gehören zur Klasse bidirektional - bidirektional“.
”
79
80
In dieser Arbeit wurden alte und neue Transaktions-Verfahren fü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 Einschränkungen zugrunde. Nachfolgende
Arbeiten könnten vor allem die Aspekte Benutzerfreundlichkeit und Kosten nicht nur
analytisch, sondern auch empirisch untersuchen. Weiter wäre es wünschenswert, auch
Möglichkeiten zu finden, Angriffe auf die Verfügbarkeit des Online-Baning-Services abzuwehren.Außerdem kann untersucht werden, welche indirekten Schäden bei Anwendern
und Banken durch Betrug im Online-Banking resultieren, und ob die Einteilung der Banken in sicherheitkritische und nicht-sicherheitskritische Transaktionen sinnvoll gewählt
wurde.
81
82
[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, Bauernfänger: Risiken beim OnlineBanking. c’t, 22:148, 2005.
[Bad07]
Baden-Wü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] Bürgerliches Gesetzbuch in der Fassung der Bekanntmachung vom 2. Januar
2002 (BGBl. I S. 42, 2909; 2003 I S. 738), zuletzt geä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 Schäfer: Normative Anforderungen für IT-Produkte. Wirtschaftsverlag NW, Verlag fü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
[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 ü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 für Sichere Informationstechnologie SIT:
Phishing-Schutz im Online-Banking: Hilfe zum Selbstschutz für Nutzer. www.
sit.fraunhofer.de/Images/phishing_studie_04_tcm105-98166.pdf,
2004. [Online; Stand 27. August 2008].
[Gem07] Gemeinschaftsbank für Leihen und Schenken: Sm@rt TAN
- Die hä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
Beiträge der 37. Jahrestagung der Gesellschaft fü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 würfelt nicht - Unsichere TANs bei der Citibank. http://www.heise.de/security/artikel/print/78939, Oktober
[hei07]
heise online: Verbessertes iTAN-Verfahren soll vor Manipulationen durch
Trojaner schü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 Kö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
[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 für Schä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,
[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 Lü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-fähiger Kreditinstitute.
http://www.hbci-zka.de/institute/2006-12-31%20FinTS-faehige%
20Institute.pdf, 2006. [Online; Stand 2. August 2008].
85
86
Anhang A
Formale Protokollspezifikationen in
HLPSL
Die folgenden formalen Protokollspezifikationen sind in der Beschreibungssprache HLPSL
geschrieben. Jeder Spezifikation liegt das gleiche Grundmuster zugrunde. Für eine grobe Erläuterung dieses Musters und der HLPSL-Sprache siehe die mit % eingeleiteten
Kommentare in der Spezifikation der indizierten TAN im folgenen Abschnitt A.1. Eine ausführliche Beschreibung von HLPSL findet sich im AVISPA-Benutzerhandbuch
[AVI06].
Für alle Spezifikationen gilt die Annahme, dass der Angreifer vollständige Kontrolle
über das Netzwerk und den Computer des Anwenders hat. Er kann also sämtliche unverschlüsselte Nachrichten lesen, verändern, unterdrü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
% 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
0 . S t a t e = 0 /\ RCV( s t a r t ) =|>
State ’:= 2
/\ Data ’ := new ( )
/\ SND( 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 ,
local
S t a t e : nat ,
TAN : message ,
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 ,
played by B
d e f=
local
S t a t e : nat ,
TAN : message ,
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 ( )
/\ SND( Code ’ )
5 . S t a t e = 5 /\ RCV(TAN) =|>
State ’:= 8
end r o l e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
role session (
A, B, G : agent ,
Kgb , Kga : symmetric key )
d e f=
local
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
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
/\ s e s s i o n ( i , b1 , g i , kgbi , k g i )
end r o l e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
goal
end g o a l
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
environment ( )
A.3 Mobile TAN
r o l e mobile (
A, B,M: agent ,
Kmb, Kma: symmetric key ,
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 ,
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 ’ )
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 ,
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
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
95
d e f=
const
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
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 ,
init
S t a t e := 1
transition
1 . S t a t e = 1 /\ RCV( Code ’ ) =|>
State ’:= 3
/\ Data ’ := new ( )
/\ SND( Code ’ . 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 ,
local
S t a t e : nat ,
TAN : message ,
init
S t a t e := 2
transition
2 . S t a t e = 2 /\ RCV( Code ’ . Data ’ ) =|>
State ’:= 5
/\ SND({ Data ’ . TAN’ } Kga )
end r o l e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
r o l e bank (
A, B,G : agent ,
Kgb : symmetric key ,
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
/\ 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
composition
/\ 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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d e f=
const
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
end g o a l
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
98
A.5 HBCI 2
environment ( )
A.5 HBCI 2
r o l e acustomer (
A, B, G
: agent ,
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 ’ )
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 ,
local
S t a t e : nat ,
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
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 ,
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 ,
Kga : symmetric key )
d e f=
local
composition
/\ 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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d e f=
const
kp1 , kp2 , k p i
: public key ,
kga , k g i
: symmetric key ,
a , b1 , b2 , g1 , g2 , g i
: agent
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 ( i , b1 , g i , kpi , k g i )
end r o l e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
goal
end g o a l
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
environment ( )
A.6 HBCI 3
r o l e acustomer (
A, B, G
: agent ,
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
State ’:= 2
/\ Data ’ := new ( )
/\ SND( 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 ,
local
S t a t e : nat ,
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 ,
102
A.6 HBCI 3
played by B
d e f=
local
S t a t e : nat ,
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 ,
Kga : symmetric key )
d e f=
local
composition
/\ 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
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
d e f=
const
kp1 , kp2 , k p i
: public key ,
kga , k g i
: symmetric key ,
103
% 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
composition
s e s s i o n ( a , b1 , g1 , kp1 , kga )
/\ s e s s i o n ( i , b1 , g i , kpi , k g i )
end r o l e
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
goal
end g o a l
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
environment ( )
104
Anhang B
Ausgaben von AVISPA
Die Ausführbarkeit der Protokollspezifikationen aus Anhang A wurde zunächst mit
dem Programmaufruf avispa –ofmc -sessco überprüft. Diese Überprüfung ist wichtig,
da AVISPA für nicht ausfü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 überprüft. Die Option -ns verhindert, dass AVISPA die Spezifikation vor der Auswertung vereinfacht. In einigen Fällen wurden bei eingeschalteter
Vereinfachung ein unsicheres Verfahren als sicher eingestuft. Die Option -short veranlasst
AVISPA, eine möglichst kurze Angriffsfolge zu finden.
Im folgenden finden sich die Resultate dieser Aufrufe mit kurzen Erlä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 läuft wie folgt ab: Zunächst sendet der Angreifer i betrügerische
Ü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 zurück. Nun wartet der Angreifer darauf, dass der Anwender eine
Überweisung eingibt. Sobald er dies tut, unterdrü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
führe damit seinen Auftrag aus. In Wirklichkeit aber fü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 für das mobile TAN-Verfahren eine Angriffmöglichkeit. Man beachte den
Unterschied in der Witness- und der Request-Angabe: Der Anwender möchte sich von
der Bank b1 authentisieren, in Wirklichkeit wird er aber von b2 authentisiert.
SUMMARY
UNSAFE
DETAILS
107
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 )
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 läuft wie folgt ab: Der Kunde mö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 erhä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 ausführt. Diese Sicherheitslü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
Sicherheitslücke zunächst unkritisch erscheint, so lässt sich doch ein Angriff konstruieren,
der dem Kunden tatsächlich schadet (siehe 4.3.1).
B.4 Fotohandy-TAN
Das Fotohandy-TAN-Verfahren wird von AVISPA als sicher eingestuft.
SUMMARY
SAFE
DETAILS
TYPED MODEL
PROTOCOL
.// t e s t s u i t e / r e s u l t s / protokollfotoTAN . txt . i f
GOAL
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 erwartungsgemäß die in Abschnitt 4.4.2 beschriebene Sicherheitslücke.
SUMMARY
109
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
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)
können ignoriert werden, da diese Teilnehmer innerhalb dieser Sitzungen nicht weiter am
Protokollablauf beteiligt sind. Der Angriff läuft folgendermaßen ab: Zunächst schickt die
Bank b1 die Nonce n17. Der Angreifer sendet betrügerische Transaktionsdaten zusammen mit n17 an die Chipkarte und wartet, bis der Anwender eine Überweisung ausführen
will. Sobald dies geschieht, unterdrückt der Angreifer die Datenü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 prüft und ausführt.
B.6 HBCI 3
Das HBCI-Verfahren mit einem Kartenleser der Sicherheitsklasse 3, auf dem sich der
Anwender vor der Auftragsbestätigung nochmal die Transaktionsdaten zur Kontrolle
anzeigen lassen kann, wird von AVISPA als sicher eingestuft.
SUMMARY
SAFE
DETAILS
TYPED MODEL
PROTOCOL
.// t e s t s u i t e / r e s u l t s / protokollhbci3 . txt . i f
GOAL
111
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

Dipl. - Universität Tübingen

Transcrição

Documentos relacionados

Flyer - unsere Sicherheitsverfahren_juli2011.pub

Im Wagen vor mir.mus

93 Im Wagen vor mir

Dumm gelaufen, lieber Datenklauer – die neuen TANs sind einfach

W~nderkind aß} Petrof

0. Kreisberechnung: Reichen nicht die Formeln? 1. Kreisumfang

Versand DTAUS – Datei im Online-Banking

2009 TAN BIZ - Look@Yourself

Hinweise für mehr Sicherheit im Internet

Wan Tan for Four