Diplomarbeit

Eberhard-Karls-Universität Tübingen

Fakultät für Informations- und KognitionswissenschaftenWilhelm-Schickard-Institut für Informatik

Arbeitsbereich für Theoretische Informatik / Formale Sprachen

Peer-to-Peer Payment via NFC

Diplomarbeit

im Fachgebiet Informatik

Stefan Gfrörer20. April 2012

Betreuer:

Dr. Bernd BorchertProf. Dr. Klaus Reinhardt


Zusammenfassung

Die vorliegende Arbeit erforscht die Umsetzung eines mobilen Bezahlsystems mittelsdem eKaay Verfahren. Es soll direkte Transaktionen zwischen zwei Benutzern vonSmartphones ermöglichen und dabei einen guten Kompromiss aus Sicherheit undBenutzerfreundlichkeit bieten. Die Sicherheit muss in einer Analyse nachgewiesenund mit weiteren Verfahren verglichen werden. Beide Ziele wurden erreicht. Dabeiist es gelungen neben dem Bezahlverfahren auch eine Erweiterung für Online ShopSysteme zu entwickeln. Die Analyse ergab eine Reihe von ähnlichen Problemen undLösungsansätzen in verschiedenen mobilen Peer-to-Peer Bezahlsystemen. Aus diesenGemeinsamkeiten konnten verschiedene Empfehlungen für die Entwicklung weitererVerfahren abgeleitet werden.

© Stefan Gfrörer


Eidesstattliche Erklärung

Ich, Stefan Gfrörer, versichere hiermit, dass ich meine Diplomarbeit mit dem The-ma


selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittelbenutzt habe, wobei ich alle wörtlichen und sinngemäßen Zitate als solche gekenn-zeichnet habe. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegtund auch nicht veröffentlicht.

Tübingen, den 20. April 2012

Stefan Gfrörer

© Stefan Gfrörer


Inhaltsverzeichnis

Inhaltsverzeichnis

Abkürzungsverzeichnis V

Abbildungsverzeichnis VII

Tabellenverzeichnis XI

Verzeichnis der Listings XIII

1. Einleitung 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4. Voraussetzungen zum Verständnis der Arbeit . . . . . . . . . . . . . 31.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Grundlagen und Hintergründe 52.1. eKaay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Near Field Communication (NFC) . . . . . . . . . . . . . . . . . . . 92.3. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4. Mobile Payment (MP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Peer-to-Peer Payment mit eKaay 173.1. Formulierung der Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2. Entwurf einer Testumgebung . . . . . . . . . . . . . . . . . . . . . . 183.3. Entwurf von eKaayCash . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1. Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.2. Peer-to-Peer Kommunikation . . . . . . . . . . . . . . . . . . 213.3.3. Verbesserung der Sicherheit . . . . . . . . . . . . . . . . . . . 24

3.4. Erweiterung für Online Shop Systeme . . . . . . . . . . . . . . . . . 253.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4. Analyse bestehender mobiler Bezahlsysteme 294.1. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1. Auswahl der Verfahren und Kriterien . . . . . . . . . . . . . . 294.1.2. Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

I © Stefan Gfrörer


Inhaltsverzeichnis

4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen . . . . . . . . 314.3. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.1. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 404.3.1.1. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . 404.3.1.2. Erweiterung für Online Shop Systeme . . . . . . . . 42

4.3.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4. PayPal Mobile Payments . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 434.4.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 454.4.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 464.4.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 474.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5. Google wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.5.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 494.5.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 514.5.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 524.5.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 524.5.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.6. Bitcoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 544.6.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 554.6.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 574.6.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 574.6.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.7. „A 2D Barcode-Based Mobile Payment System“ . . . . . . . . . . . 594.7.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 594.7.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 604.7.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 624.7.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 624.7.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.8. „A Wireless Payment System“ . . . . . . . . . . . . . . . . . . . . . 644.8.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 644.8.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 644.8.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 664.8.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 664.8.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.9. Entwurf einer Smartphone basierten Geldkarte . . . . . . . . . . . . 684.9.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 684.9.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 694.9.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 70

© Stefan Gfrörer II


Inhaltsverzeichnis

4.9.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 704.9.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.10. Weitere Mobile Payment Lösungen . . . . . . . . . . . . . . . . . . . 714.10.1. „Secure Mobile Payment via Trusted Computing“ . . . . . . 714.10.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.11. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.12. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.13. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5. Implementierung von eKaayCash 775.1. Erzeugung einer Überweisung . . . . . . . . . . . . . . . . . . . . . . 775.2. Erweiterung der eKaay App . . . . . . . . . . . . . . . . . . . . . . . 785.3. Server/Client Kommunikation . . . . . . . . . . . . . . . . . . . . . . 79

6. Schluss 816.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Literaturverzeichnis 85

A. Anhang i

III © Stefan Gfrörer


Abkürzungsverzeichnis


AES . . . . . . . . . . . . . . . Advanced Encryption Standard

API . . . . . . . . . . . . . . . . Application Programming Interface (engl. für Programmier-schnittstelle)

ASK . . . . . . . . . . . . . . . Amplitude Shift Keying

C2C . . . . . . . . . . . . . . . . Consumer-to-Consumer

CNP . . . . . . . . . . . . . . . Card not present transaction

ECC . . . . . . . . . . . . . . . Elliptic Curve Cryptography (engl. für Elliptische-Kurven-Kryptographie)

EDGE . . . . . . . . . . . . . Enhanced Data Rates for GSM Evolution

EMV . . . . . . . . . . . . . . . Europay, MasterCard, Visa

GSM . . . . . . . . . . . . . . . Global System for Mobile Communications

HMAC . . . . . . . . . . . . . Keyed-Hash Message Authentication Code

ID . . . . . . . . . . . . . . . . . Identification (engl. für Identifikator oder Kennung)

IMEI . . . . . . . . . . . . . . . International Mobile Equipment Identity

LTE . . . . . . . . . . . . . . . . Long Term Evolution

MITM . . . . . . . . . . . . . Man-in-the-middle attack (engl. für Man-in-the-middle-Angriff)

MP . . . . . . . . . . . . . . . . Mobile Payment

NDEF . . . . . . . . . . . . . NFC Data Exchange Format

NFC . . . . . . . . . . . . . . . Near Field Communication (engl. für Nahfeld-Kommunikation)

P2P . . . . . . . . . . . . . . . . Peer-to-Peer oder Person-to-Person

PIN . . . . . . . . . . . . . . . . Personal Identification Number (engl. für Persönliche Identi-fikationsnummer)

POS . . . . . . . . . . . . . . . Point of Sale

QR Code . . . . . . . . . . . Quick Response Code

RFID . . . . . . . . . . . . . . Radio-Frequency Identification

SDP . . . . . . . . . . . . . . . Service Discovery Protocol

SE . . . . . . . . . . . . . . . . . Secure Element

SMS . . . . . . . . . . . . . . . Short Message Service (engl. für Kurznachrichtendienst)

SSL . . . . . . . . . . . . . . . . Secure Sockets Layer

V © Stefan Gfrörer



TAN . . . . . . . . . . . . . . . Transaction Authentication Number (engl. für Transaktions-nummer)

TLS . . . . . . . . . . . . . . . . Transport Layer SecurityUMTS . . . . . . . . . . . . . Universal Mobile Telecommunications SystemURL . . . . . . . . . . . . . . . Uniform Resource LocatorsWLAN . . . . . . . . . . . . . Wireless Local Area Network (engl. für drahtloses lokales

Netzwerk)WOT . . . . . . . . . . . . . . Web of Trust (engl. für Netz des Vertrauens)

© Stefan Gfrörer VI


Abbildungsverzeichnis


2.1. Verwendung von eKaay als alternatives Loginverfahren im WebmailAngebot der Universität Tübingen (Quelle: ZDV Tübingen [2012]). . 6

2.2. Das eKaay TAN Verfahren im Detail. Das Versenden der Bestätigungist nicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . 8

2.3. Das eKaay PIN Verfahren aus Sicht des Benutzers. Links ist ein Han-dy mit permutiertem Ziffernfeld und rechts das Formular im Browsermit QR Code und Zifferneingabefeld ohne Beschriftung dargestellt(Quelle: Borchert [2012a]). . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4. Die von NFC verwendeten Kodierungen (Quelle: Van Damme u. a.[2005]; [Übersetzung durch Verfasser]). . . . . . . . . . . . . . . . . . 11

2.5. Eine Peer-to-Peer Überweisung ausgehend vom Zahlenden (Quelle:Agarwal u. a. [2007]; [Übersetzung durch Verfasser]). . . . . . . . . . 15

2.6. Eine Peer-to-Peer Überweisung ausgehend vom Geldempfänger (eige-ne Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1. Formular für eine mobile Überweisung. Geldempfänger und Zahlenderwerden automatisch erfasst (eigene Darstellung). . . . . . . . . . . . 20

3.2. Ablauf einer Transaktion mittels eKaayCash. Bestätigungen nach er-folgreicher Durchführung an beide Parteien sind der Übersicht wegennicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . . . 21

3.3. Beispiel für einen Artikel mit der dazugehörenden eKaayCash Trans-aktion zum gleichzeitigen Kaufen und Bezahlen (eigene Darstellung). 26

3.4. Ablauf eines Einkaufs im Online Shop mit eKaayCash. Es wird da-von ausgegangen, dass die Transaktion bereits erzeugt wurde (eigeneDarstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1. Erfolgreicher Man-in-the-Middle Angriff auf eine Server-Client Ver-bindung. Der Angreifer Mallory kann den Kommunikationsfluss zwi-schen Alice und Bob vollständig kontrollieren (eigene Darstellung). . 34

4.2. Der Angreifer Eve hat zwar keinen direkten Einfluss auf den Kom-munikationskanal, kann aber die Verbindung zwischen Alice und Bobunbemerkt belauschen (eigene Darstellung). . . . . . . . . . . . . . . 34

VII © Stefan Gfrörer



4.3. Der Angreifer Mallory manipuliert eine Überweisung, welche außereiner vom Inhalt unabhängigen TAN keinen weiteren Schutz aufweist(eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4. Der Bestätigungsdialog von eKaay für eine Transaktion (eigene Dar-stellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5. Versuch eines Angreifers einem Shop eine Transaktion vorzutäuschen(eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.6. Das installierte PayPal Mobile Payments Widget auf dem Homescreeneines Android basierten Smartphones (Quelle: Chambers [2011]). . . 44

4.7. Ablauf einer P2P Transaktion mit PayPal. Das Versenden der Bestä-tigung wurde aus Gründen der Übersicht entfernt (eigene Darstellung). 45

4.8. Bezahlung an einem NFC-fähigen Terminal mit PayPal Mobile Pay-ments (Quelle: PayPal [2011b]). . . . . . . . . . . . . . . . . . . . . . 47

4.9. Gemäß A2 kann ein Schadprogramm auf dem Smartphone des Geld-empfängers die Transaktionsdaten vor der Übertragung manipulieren(eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.10. Ein Nexus S 4G mit aktiver Google wallet App. Das Konto ist miteiner Citi MasterCard aufgeladen. Daneben ein MasterCard paypassTerminal, welches mit Google wallet genutzt werden kann (Quelle:Google [2011]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.11. Ablauf einer mobilen Überweisung im Bitcoin-Netzwerk (eigene Dar-stellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.12. Grafische Darstellung eines Ausschnitts des Bitcoin Netzwerks rundum Wikileaks (Quelle: Reid u. Harrigan [2011]; [Hervorhebung durchVerfasser]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.13. Ablauf eines Produktkaufs mit Hilfe des 2D Barcode Verfahren. Nichtenthalten sind die Bestätigungen an Kunden und Händler (eigeneDarstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.14. Ablauf einer P2P Überweisung mit Hilfe von Bluetooth. Die Bestäti-gung wurde entfernt (eigene Darstellung). . . . . . . . . . . . . . . . 65

4.15. Ablauf einer Transaktion zwischen zwei Smartphones nach dem Geldkarten-Prinzip (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . 70

4.16. Die Ergebnisse der Sicherheitsanalyse im Überblick (eigene Darstel-lung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1. Aktivitätsdiagramm, welches die Generierung einer Überweisung zeigt(eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

© Stefan Gfrörer VIII



5.2. Das Aktivitätsdiagramm zeigt die Zwischenschritte von Eingabe derder Überweisungsdaten bis zur Anzeige des von eKaay erzeugten QRCodes. Es zeigt den Schritt „Überweisung erzeugen“ aus Abbildung5.1 im Detail (eigene Darstellung). . . . . . . . . . . . . . . . . . . . 78

5.3. Kommunikation der verschiedenen Komponenten im eKaayCash Ver-fahren (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . 80

A.1. Die unterschiedlichen Module mit den dazugehörenden Webseiten imeKaayCash System (eigene Darstellung). . . . . . . . . . . . . . . . . iii

A.2. Der vollständige Ablauf einer Peer-to-Peer Transaktion mit eKaay-Cash (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . iv

A.3. Der vollständige Ablauf eines Einkaufs in einem Shop mit der Erwei-terung für eKaayCash (eigene Darstellung). . . . . . . . . . . . . . . v

IX © Stefan Gfrörer


Tabellenverzeichnis

Tabellenverzeichnis

3.1. Syntax der Daten von eKaay TAN aus einem QR Code (Quelle: Bor-chert [2012a]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1. Übersicht aller Angriffsmethoden auf mobile Bezahlsysteme (eigeneDarstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2. Der Sicherheitsheader für Nachrichten im Verfahren mit Bluetooth. Erwird an die eigentlichen Nutzdaten angehängt (vgl. Gao u. a. [2006];[Übersetzung durch Verfasser]). . . . . . . . . . . . . . . . . . . . . . 65

XI © Stefan Gfrörer


Verzeichnis der Listings

3.1. Beispiel für einen eKaayCash NFC Link kodiert gemäß Lee u. a. [1994](eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1. Informationen aus der Datenbank von Google wallet. Von oben nachunten: Bezeichner der Karte, Name des Besitzer, Kreditlimit, aktuel-les Guthaben und die letzten vier Ziffern der Kartennummer (Quelle:Viaforensics [2011]; im Auszug). . . . . . . . . . . . . . . . . . . . . . 54

5.1. Auszug aus der AndroidManifest.xml. Gezeigt wird der Filter für einbenutzerdefiniertes URL Scheme (eigene Darstellung). . . . . . . . . 78

XIII © Stefan Gfrörer


1. Einleitung

1.1. Motivation

Bargeldloser Zahlungsverkehr erfährt in regelmäßigem Abstand neue Entwicklungen.Das Ziel der Finanzinstitute ist es benutzerfreundliche, einfache und sichere Bezahl-systeme als Ersatz für das klassische Bargeld einzusetzen. Während das Bezahlenbei Händlern mit Hilfe von Kredit- und Geldkarten umgesetzt werden kann, ist derdirekte Austausch von Beträgen zwischen einzelnen Personen deutlich komplizierterund wird von vielen Systemen nicht vorgesehen. Gerade dieser Punkt ist jedoch fürelektronisches Bargeld von essentieller Bedeutung. Diese sogenannten Peer-to-Peer(P2P) Überweisungen verbinden die direkte Anwendung von klassischem Bargeldmit den Vorteilen moderner bargeldloser Systeme. Ein Geldaustausch ist damit je-derzeit in Echtzeit möglich und gleichzeitig können fortschrittliche Sicherheitsme-chanismen angewandt werden. Des Weiteren lassen sich zusätzliche Dienste wie dieEinsicht von Kontoständen und Sonderangebote mit dem Bezahlsystem verknüp-fen.

Allerdings sind zur Realisierung solcher bargeldloser Systeme Endgeräte notwen-dig, welche gegenüber einfachen Geldkarten einen größeren Funktionsumfang habenund eigenständig operieren können. Diese Bedingungen werden unter anderem vonMobiltelefonen erfüllt. Aus diesem Grund existieren verschiedene Bestrebungen fürdie Umsetzung von mobilen Bezahlsystemen auf Handys. In klassischen Mobiltele-fonen werden diese Systeme häufig wegen der begrenzten technischen Möglichkeitenohne eine P2P Funktion umgesetzt (vgl. Choi u. a. [2007]). Moderne Smartphoneserlauben hingegen neue Kommunikationsformen und bieten eine Plattform für neuemobile Bezahlsysteme. Besonders die Entwicklung in Nahfunksysteme zur Daten-übermittlung kann direkte Geldüberweisungen zwischen einzelnen Personen ohnedritte Instanz stark vereinfachen. Smartphones ermöglichen mit ihrem wachsendenFunktionsumfang aber auch neue Angriffe auf die Plattform. Gerade für Systeme,welche den Zugriff auf finanzielle Mittel ermöglichen, ist die Sicherheit jedoch vonwesentlicher Bedeutung.

Um sowohl der gewünschten Benutzerfreundlichkeit in einer Peer-to-Peer Umge-bung gerecht zu werden und gleichzeitig ein sicheres Bezahlen zu ermöglichen, bautdie vorliegende Arbeit auf das eKaay Verfahren auf. Dieses Verfahren wurde an

© Stefan Gfrörer 1


1. Einleitung

der Eberhard-Karls-Universität Tübingen entwickelt und erlaubt die einfache Um-setzung von sicheren Bestätigungen für Transaktionen (vgl. Borchert [2012a] undGünther [2011]).

1.2. Ziel der Arbeit

Auf der Basis der zum Zeitpunkt dieser Arbeit aktuellen Smartphones soll ein be-quemes mobiles Bezahlsystem mit P2P Funktionalität entworfen werden. Die Auf-gabenstellung erfordert dabei explizit die Nutzung neuer Kommunikationsmedienwie Nahfunk. Voraussetzung ist, dass das entwickelte System von Anwendern leichtbedient werden kann, dabei aber die Sicherheit nicht vernachlässigt wird. Als Grund-lage soll das bereits erwähnte eKaay Verfahren dienen.

Die Sicherheit muss in einer ausführlichen Sicherheitsanalyse belegt werden. EinVergleich der Sicherheit und eine Umsetzung der Analyse mit weiteren Verfahren istebenfalls notwendig. Damit sollen Gemeinsamkeiten und Unterschiede erforscht undhervorgehoben werden.

1.3. Verwandte Arbeiten

Das eKaay Verfahren wird das erste Mal wissenschaftlich und in großem Umfang inder Arbeit von Günther [2011] vorgestellt. Diese umfasst auch eine Sicherheitsanalysedes Verfahrens und stellt Lösungen für aufgedeckte Probleme vor.

Die Sicherheit von modernen, mobilen Plattformen im Zusammenhang mit Bezahl-systemen wurde von Agarwal u. a. [2007] und Kadhiwal u. Zulfiquar [2007] unter-sucht. Ihre Analysen dienen in der vorliegenden Arbeit als Grundlage für die Ent-wicklung eines sicheren Bezahlsystems.

Eine Reihe von technischen Lösungen für mobile Bezahlsysteme werden in der Über-sichtsarbeit von Mobey Forum Mobile Financial Services Ltd [2010] vorgestellt. Siestellen einen Kontrast zu auf Software basierten Lösungen in dieser Arbeit dar.

Eine Reihe von Wissenschaftlern haben in jüngerer Zeit die Umsetzung von mo-bilen Bezahlsystemen erforscht und Lösungsvorschläge erarbeitet. Diese umfassenzum Teil P2P Verfahren, aber auch Terminal basierte Lösungen. Zu diesen Arbeitengehören Gao u. a. [2006], Li u. a. [2008], Pasquet u. a. [2008] und Gao u. a. [2009].Die Ergebnisse und die darin entwickelten Verfahren werden teilweise in der Sicher-heitsanalyse aufgegriffen und ebenfalls untersucht.

2 © Stefan Gfrörer


1.4. Voraussetzungen zum Verständnis der Arbeit

1.4. Voraussetzungen zum Verständnis der Arbeit

Die vorliegende Arbeit verwendet eine Reihe von Begriffen und Konventionen, welcheim Folgenden kurz erläutert werden. Dies dient dem Verständnis des Lesers.

Der Begriff „mobiles Bezahlsystem“ bezieht sich im weiteren Verlauf vorwiegend aufSysteme, welche Smartphones als wichtigstes Endgerät setzen. Diese Festlegung istvon Bedeutung, da andere Arbeiten mit dem Begriff unter anderem auf Systememit Geldkarten und ähnlichem verweisen und der Begriff im Allgemeinen eine sehrbreite Bedeutung hat. Um Unklarheiten zu vermeiden, wird die Bedeutung darumfokussiert.

Unter einer „Peer-to-Peer Überweisung“ wird in diese Arbeit eine Überweisung vonGeldbeträgen zwischen zwei Personen, welche sich in physikalischer Nähe befinden,verstanden. Dies steht im Gegensatz zu klassischen Überweisungen in Online Ban-king Systemen.

Die Begriffe „Geldempfänger“ und „Zahlender“ beziehen sich auf die beiden Parteienin einer P2P Umgebung. Sie werden Geschlechtsneutral verwendet.

Verschiedene Abläufe werden im Laufe dieser Arbeit sowohl textuell als auch gra-fisch dargestellt. Die Grafik dient dabei, wie in wissenschaftlichen Arbeiten üblich,der zusätzlichen Verdeutlichung. Die Nummerierung der einzelnen Schritte in Textund Bild kann divergieren, da im Text häufig Schritte logisch zusammengefasst wer-den. Einzelne Abläufe werden in vergrößerten Grafiken in Anhang A verdeutlicht.Diese sind jedoch nicht zum Verständnis notwendig, sondern dienen auschließlichder Ergänzung und Vertiefung.

1.5. Aufbau der Arbeit

In Kapitel 2 werden die für diese Arbeit relevanten Grundlagen und Technologi-en vorgestellt. Des Weiteren wird eine Einführung in mobiles Bezahlen gegeben. InKapitel 3 folgt der Entwurf des mobilen Bezahlsystems eKaayCash. Dieses Kapitelenthält noch keine Sicherheitsanalyse zum Verfahren. Sie folgt in Kapitel 4, welcheseine Reihe von mobilen Bezahlsystemen ausführlich untersucht und Sicherheitspro-bleme hervorhebt. Einzelne Aspekte der Implementierung von eKaayCash werden inKapitel 5 diskutiert. Abschließend werden in Kapitel 6 noch einmal alle Ergebnissezusammengefasst, offene Probleme angesprochen und ein Ausblick gegeben.



2. Grundlagen und Hintergründe

Die folgenden Abschnitte vermitteln wichtige Grundlagen und Konzepte für das Ver-ständnis der weiteren Arbeit. Sie bilden eine Basis, auf welches in späteren Kapitelnaufgebaut wird.

2.1. eKaay

Ein wiederkehrendes Problem in der Sicherheit von Computersystemen ist die Um-setzung sicherer Anmeldeverfahren. Klassische Abfragen von Benutzername undKennwort können leicht durch Social Engineering gebrochen werden (vgl. Jakobs-son u. Myers [2006]). Das Verfahren eKaay versucht diese Problematik durch dieEinführung eines zweiten Kanals in Form eines Smartphones zu umgehen. Anstelleeiner Eingabemaske erhält der Benutzer auf dem Bildschirm des Computers einen2D Code (vgl. Abbildung 2.1). Dieser Code enthält unter anderem eine Challengein Form einer Nonce. Der Inhalt des 2D-Codes muss dabei nicht geheim bleiben.Fotografiert der Benutzer den 2D-Code mit Hilfe des Smartphones und der dar-auf installierten eKaay App ab, liest diese den Inhalt des Codes zunächst aus. DerBenutzer muss dann die Anmeldung auf dem Smartphone bestätigen. Die eKaayApp berechnet daraufhin aus der Nonce und einem auf dem Smartphone gespeicher-ten und mit dem Server geteilten Geheimnis eine Response. Diese Response wirdzusammen mit den Benutzerdaten an den Kontoserver übermittelt. Er prüft die Re-sponse auf Korrektheit und meldet den Benutzer im Erfolgsfall an. Voraussetzungfür den beschriebenen Ablauf ist eine vorherige Registrierung des Benutzerkontosin der eKaay App und damit Hinterlegung der nötigen Kontodaten einschließlichdes geteilten Geheimnisses. Einzelne Konten können auf dem Handy mit Hilfe ei-ner Personal Identification Number (PIN) gesichert werden. Die Funktionalität voneKaay wird von zwei Komponenten zur Verfügung gestellt. Einerseits ist auf demSmartphone die eKaay App installiert. Anderseits muss der Kontoserver über dieServerkomponente von eKaay verfügen. Diese erzeugt den 2D-Code und initiiert undvalidiert dann das Challenge-Response-Verfahren. Die App wurde bereits für AppleiOS und Google Android umgesetzt. Der Server wurde mit PHP entwickelt. Als 2D-Code kommt ein Quick Response Code (QR Code) zum Einsatz (vgl. ISO [2000b],Borchert [2012a] und Günther [2011]).




Abbildung 2.1.: Verwendung von eKaay als alternatives Loginverfahren im WebmailAngebot der Universität Tübingen (Quelle: ZDV Tübingen [2012]).

Günther [2011] zeigt in einer Sicherheitsanalyse von eKaay, dass das Verfahren denAnmeldevorgang an sich in der Tat sicherer gestaltet, als zum Beispiel die klassischeAnmeldung mit Benutzername und Passwort. Allerdings weist er auch auf eine Rei-he von Problemen hin. Ein auf dem Smartphone installiertes Schadprogramm kannin verschiedenen Szenarien das geteilte Geheimnis lesen und damit selbst gültigeAnmeldungen generieren. Beispielsweise sind alle auf dem Smartphone gespeicher-ten Daten nie vollkommen geschützt (vgl. Abschnitt 2.3). Dieses Sicherheitsrisikolässt sich durch die Abfrage einer PIN vermindern, jedoch ist auch diese durch einSchadprogramm angreifbar. Als Lösung für diese Gefahr schlägt Günther [2011] dieVerwendung einer programmierbaren Karte mit Funkverbindung vor (vgl. Abschnitt2.2). Das Geheimnis kann auf diese Karte ausgelagert werden. In diesem Szenarioleitet das Smartphone die Challenge an die Karte über die Funkverbindung weiter.Die Challenge wird von der Karte beantwortet und das Smartphone empfängt diegenerierte Response. Das Geheimnis verbleibt somit auf der Karte und kann vonkeinem Schadprogramm auf dem Smartphone ausgelesen werden (ebd.).

Eine Variante von eKaay ist eKaay TAN, welches zur Bestätigung von Transak-tionsdaten dient. Es kann unter anderem bei der Bestätigung einer Überweisungim Onlinebanking verwendet werden. Der Hauptunterschied zum klassischen An-meldeverfahren ist die Erweiterung der Challenge um die Daten der Transaktion.



2.1. eKaay

Das Geheimnis bestätigt dann nicht nur die Nonce sondern zusätzlich die Daten(vgl. Borchert [2012a]). Dieses Verfahren ähnelt der Verwendung einer dynamischenTransaction Authentication Number (TAN) (vgl. Baden-Württembergische Bank[2006]). Der Ablauf wird im Folgenden am Beispiel einer Überweisung im Online-banking vorgestellt. Abbildung 2.2 verdeutlicht den Ablauf visuell.

1. Der Benutzer ruft die Überweisungsseite auf und erhält ein Formular mit dennotwendigen Daten. Er füllt das Formular aus und sendet es zur Validierungan den Server.

2. Der Server prüft die eingegebenen Daten und erzeugt mit Hilfe der Server-komponente von eKaay einen 2D-Code. Der Code enthält unter anderem dieNonce und die Transaktionsdaten in einer kompakten, aber für Menschen les-baren Form. Zusätzlich speichert er sämtliche Daten.

3. Der 2D-Code wird anstelle eines TAN-Eingabefelds am Bildschirm des Benut-zers angezeigt. Dieser liest den Code mit Hilfe seines Smartphones und dereKaay App ein.

4. Die Applikation zeigt die Transaktionsdaten in ihrer kompakten, lesbarenForm auf dem Bildschirm des Smartphones an. Der Benutzer kann auf die-se Weise prüfen, ob die vom Server empfangenen und validierten Daten mitder ursprünglichen Eingabe übereinstimmen. Abhängig von der Entscheidungdes Benutzers wird der Vorgang anschließend abgebrochen oder durch Gene-rierung der Response auf dem Smartphone abgeschlossen.

5. Das Smartphone überträgt die Response über eine eigene Internetverbindungan den Server. Der Server prüft die Response und vergleicht, ob die bestätig-ten Transaktionsdaten mit den ursprünglich empfangenen übereinstimmen. ImErfolgsfall wird die Überweisung ausgeführt und der Benutzer bekommt eineBestätigung angezeigt.

Die Variante eKaay TAN basiert auf dem klassischen eKaay Verfahren. Der einzi-ge Unterschied liegt in der zusätzlichen Verwendung der Transaktionsdaten in derChallenge. Damit gelten die Ergebnisse der Sicherheitsanalyse von Günther [2011]auch für eKaay TAN. Die Sicherheit einer Überweisung wird durch die folgendenbeiden Mechanismen erreicht (vgl. Borchert [2012a] und Günther [2011]).

1. Der Server erhält zu Beginn alle Daten und kann nach Abschluss prüfen, ob derBenutzer diese Daten bestätigt hat oder ob sie durch fremden Zugriff verändertwurden.

2. Um den Server zu täuschen muss ein Angreifer im Zeitraum zwischen dem Ab-schicken der Transaktionsdaten durch den Benutzer und dem Empfang durch




den Server eine Manipulation durchführen. Diese Manipulation kann vom Be-nutzer aber wiederum erkannt werden, wenn er die Überweisungsdaten aufseinem Smartphone verifiziert.

Als Restrisiko verbleibt ein Schadprogramm auf dem Smartphone, welches zunächstden Server täuscht und bei der anschließenden Verifizierung durch den Benutzer einegefälschte Anzeige erzeugt (vgl. Günther [2011]).

Smartphone des Kunden

7. Prüfung der Datenund Response Generierung

Server mit eKaay

5. Anzeige des Code

6. Einlesen

2. Übertragung derÜberweisung

1. Eingabe der Überweisung

3. Validierung und 2D Code Generierung

4. Challenge in Form des 2D Code

Computer des Kunden 2D Code

8. Response

9. Validierung und Ausführung der Überweisung

Abbildung 2.2.: Das eKaay TAN Verfahren im Detail. Das Versenden der Bestäti-gung ist nicht enthalten (eigene Darstellung).

Eine weitere, für diese Arbeit relevante, Technik von eKaay ist die ErweiterungeKaay PIN. Sie erweitert das eKaay Verfahren um einen wissensbasierten Schutz.Entgegen klassischer PIN Verfahren wird aber nicht die PIN eingegeben, da dieseimmer von einem Schadprogramm mitgelesen werden kann. Stattdessen berechnetdas Smartphone eine Permutation der Ziffern. Diese Permutation basiert auf demSchlüssel des Benutzerkontos und der Challenge und ist somit für jeden Vorgangindividuell. Die Permutation – in Form von vertauschten Zahlen in einem Ziffern-feld – wird dem Benutzer auf dem Handy angezeigt. Im Browser des Computerssieht er des Weiteren ein Zifferneingabefeld ohne Beschriftung. Basierend auf derangezeigten Permutation muss der Benutzer die entsprechenden Buttons im Einga-



2.2. Near Field Communication (NFC)

befeld auswählen. Im Anschluss überträgt der Browser die Position und Reihenfolgeder ausgewählten Buttons in kodierter Form an den Server. Dieser hat bereits diePermutation vom Smartphone erhalten und kann mit Hilfe der kodierten Daten dieeigentliche PIN wiederherstellen und überprüfen (vgl. Borchert [2012a] und Gün-ther [2011]). In Abbildung 2.3 sind eine Permutation auf dem Smartphone und dasdazu gehörige Eingabefeld im Browser dargestellt. Günther [2011] zeigt, dass eKaayPIN vor einem Schadprogramm auf dem Smartphone des Benutzers schützt. Damitist das eKaay Verfahren auch dann sicher, wenn der Schlüssel eines Kontos einemAngreifer bekannt ist, da weiterhin das Wissen des Anwenders fehlt (ebd.).

Abbildung 2.3.: Das eKaay PIN Verfahren aus Sicht des Benutzers. Links ist einHandy mit permutiertem Ziffernfeld und rechts das Formular imBrowser mit QR Code und Zifferneingabefeld ohne Beschriftungdargestellt (Quelle: Borchert [2012a]).

Zusammenfassend lässt sich sagen, dass eKaay ein Rahmenwerk für sichere Anmel-dungen und Bestätigungen von Daten darstellt. Aufgrund der Verwendung von QRCodes bietet es den Anwendern Vorteile in der Benutzbarkeit und macht das Merkenvon komplizierten Passwörtern überflüssig.

2.2. Near Field Communication (NFC)

Near Field Communication (NFC) basiert auf dem Radio-Frequency Identification(RFID) Standard und der Implementierung für kontaktlose Karten im ISO/IEC14443 Standard (vgl. ISO [2000a]). Es überführt beide Standards auf moderneSmartphones und bietet eine Alternative zu klassischen kontaktlosen Kommunika-tionsstandards wie Bluetooth. Seine Entwicklung wird aktiv durch das NFC Forum




– einem Zusammenschluss von verschiedenen Firmen und Interessenteilnehmern wieSony, Nokia und Philips – vorangetrieben (vgl. NFC Forum [2012]).

Wie RFID sendet NFC im weltweit unlizenzierten 13.56 MHz Frequenzband und ver-wendet das im ISO/IEC 18000-3 Standard beschriebene Interface (vgl. ISO [2004]).Die Reichweite von NFC beträgt bis zu zwanzig Zentimeter. In der Praxis ist aberhäufig ein deutlich geringerer Abstand zwischen den Antennen notwendig (vgl. Gün-ther [2011] und Van Damme u. a. [2005]).

Der NFC Standard verfügt über drei Modi in denen ein NFC-fähiges Gerät be-trieben werden kann. Sie unterscheiden sich in der Verteilung der Rollen und demSendemodus, d. h. darin ob sich das Gerät aktiv oder passiv an der Kommunikationbeteiligt. Die Modi werden abhängig von der gewünschten Anwendung ausgewählt(vgl. Van Damme u. a. [2005]).

Card Emulation Mode. In diesem Modus verhält sich das Gerät vollkommen pas-siv und simuliert das Verhalten einer NFC-fähigen Karte wie beispielsweiseMasterCard PayPass Kreditkarten (vgl. MasterCard [2012]).

Reader/Writer Mode. Das Gerät arbeitet als aktives Lesegerät für RFID oder NFCTags. Das passive Tag wird mit Hilfe magnetischer Induktion mit der nötigenEnergie versorgt.

Peer-to-Peer Mode. Zwei NFC Geräte kommunizieren miteinander. Sie können da-bei sowohl aktiv als auch passiv sein. Es erfolgt eine Rollenverteilung nach demMaster/Slave-Prinzip.

NFC unterstützt drei verschiedene Datenraten. Abhängig von der Datenrate kommteine modifizierte Miller-Kodierung mit einem Amplitude Shift Keying (ASK) vonhundert Prozent oder eine Manchester-Kodierung mit einem ASK von zehn Prozentzum Einsatz (vgl. Abbildung 2.4). Die modifizierte Miller-Kodierung wird nur vonaktiven Geräten in der geringsten Datenrate eingesetzt. In allen anderen Fällenarbeiten die Geräte mit der Manchester-Kodierung (vgl. Van Damme u. a. [2005]).

Zur Erleichterung der Kommunikation zwischen zwei Endgeräten hat das NFC Fo-rum [2012] das NFC Data Exchange Format (NDEF) spezifiziert. Es beschreibteinen standardisierten Aufbau für Datenpakete im Nahfunk und muss von jedemNFC-fähigen Gerät unterstützt werden (ebd.).

Die Benutzerakzeptanz von Nahfunk Systemen ist noch nicht komplett erforscht.Deshalb besteht die Möglichkeit, dass Benutzer dieser Technik ablehnend gegen-über stehen. Dies kann mit der Unwissenheit über die Leserechte eines NFC-fähigen



2.3. Android

1 0 1 0

Modifizierte Miller-Kodierung, 100% ASK

1 0 1 0

Manchester-Kodierung, 10% ASK

Abbildung 2.4.: Die von NFC verwendeten Kodierungen (Quelle: Van Damme u. a.[2005]; [Übersetzung durch Verfasser]).

Geräts gegenüber einem anderen erklärt werden. Eine Studie des Marktforschungs-instituts „Heute und Morgen“ gibt an, dass ein Teil der Befragten die fehlendeTransparenz bemängelt (vgl. Unrath [2012]).

2.3. Android

Android ist zum Zeitpunkt der Entstehung dieser Arbeit eines der wenigen mobilenBetriebssysteme, welches NFC unterstützt. Zudem ist es eines der ersten Systeme,für welches man NFC-fähige Smartphones erwerben kann (vgl. NFC Forum [2012]).Zum Zeitpunkt der Entstehung dieser Arbeit steht die mit Android Version 2.3Gingerbread eingeführte Programmierschnittstelle (API) für Nahfunk zur Verfügung(vgl. Google [2012a]). Eine vereinfachte API für Peer-to-Peer Verbindungen wirdmit Android Version 4 Ice Cream Sandwich verfügbar werden. Die Schnittstelleaus Version 2.3 bleibt aber erhalten und ist auch in späteren Versionen gültig (vgl.Google [2012b]).

Android sichert Daten auf dem Smartphone durch eine Reihe von Mechanismenab. Die grundlegende Sicherheit entsteht durch eine strikte Abschottung einzelnerApplikationen von einander. Dazu gehören neben der Kommunikation zwischen ein-zelnen Programmen auch der Zugriff auf das Dateisystem. Zusätzlich werden ein-zelne Funktionen nur durch explizite Anfrage und Erlaubnis durch den Benutzerbewilligt. Beispielsweise muss eine Applikation für die Nutzung der NFC Schnitt-stelle freigegeben werden. Diese Sicherheitsmechanismen können aufgrund von bisherunerkannten Fehlern umgangen werden. Zusätzlich können Benutzer das Betriebs-system unter bestimmten Bedingungen neu installieren und ihrem Benutzerkonto




umfassende Rechte erteilen. Eine Applikation, die mit diesen Rechten ausgeführtwird, kann normale Beschränkungen umgehen (vgl. Google [2012d]).

Applikationen unter Android müssen aufgrund der Abschottung bestimmte Res-sourcen oder Rechte für fremde Informationen explizit anfordern. Beispiele dafürsind der Zugriff auf Netzwerkverbindungen oder die Daten des Telefonbuchs. DieAnforderung geschieht mittels der Datei AndroidManifest.xml, welche in jeder Appvorhanden sein muss. Diese Datei enthält Metainformationen über die Applikation,definiert die Rechte der Applikation – unter der Bedingung, dass der jeweilige Be-nutzer diese Rechte vergibt – und enthält Filter und Regeln für den Umgang vonAndroid mit der Applikation (vgl. Google [2012c]).

2.4. Mobile Payment (MP)

Durch die Verbreitung von Funktelefonen wächst auch die Nutzung derselben zumBezahlen von beliebigen Gütern. Anfangs wurde dies durch Belastung der normalenTelefonrechnung erreicht. Die Kommunikation mit dem Dienstanbieter und gleichzei-tige Bezahlung erfolgte unter anderem mit Kurznachrichten (SMS), deren Einzelpreisdem Kaufobjekt entsprachen. Besonders im asiatischen Raum sind mobile Bezahlsys-teme erfolgreich (vgl. [Choi u. a. 2007, Seite 12]). Der Vorteil dieser Systemen liegt inder vereinfachten Bedienung gegenüber klassischem Geld und Geldkarten. Das Han-dy wird in vielen Fällen leicht erreichbar getragen und ermöglicht so einen wesentlichschnelleren Bezahlvorgang. Dieser Vorteil steigt mit wachsender Leistungsfähigkeitund technischen Fähigkeiten jüngerer Smartphones (vgl. Mobey Forum Mobile Fi-nancial Services Ltd [2010], Karnouskos [2004] und Choi u. a. [2007]).

Mobile Bezahlsysteme lassen sich in zwei grundlegende Kategorien aufteilen. Dieseunterscheiden sich in der Verwaltung und Durchführung von Überweisungen (vgl.Gao u. a. [2009]).

Konto basiert. Das Benutzerkonto beim Anbieter der Bezahllösung wird an einBankkonto bei einer dritten Partei – meist einer reellen Bank – gebunden. DerAnbieter und die Bank können dabei dieselbe Partei sein, für den Ablauf spieltdas aber keine Rolle. Der Dienstanbieter agiert mit seinem System als eine ArtKoordinator zur Bank. Abhängig vom zugrunde liegenden Prinzip werden dieeigentlichen Überweisungen bei der Bank zeitversetzt zur mobilen Transaktiondurchgeführt. Die mobile Transaktion innerhalb des Systems des Dienstanbie-ters repräsentiert eine virtuelle – und von allen beteiligten Parteien, inklusiveGeldempfänger und Zahlender, als reell akzeptierte – Überweisung.




E-Wallet. Eine E-Wallet ist eine Art von virtuellem Geldbeutel, welcher sowohlreelle Geldbeträge als auch die für eine Überweisung nötigen Kontodaten ent-halten kann. Abhängig von der Variante kann die eigentliche E-Wallet miteinem Geldbetrag aufgeladen werden – ähnlich dem Guthaben in Telefonsys-temen – oder sie wird mit einem Konto bei einer Bank verlinkt. Der letztereFall entspricht einem Übergang zum bereits beschriebenen, Konto basiertenSystem. E-Wallet Lösungen unterscheiden zwei Umsetzungen. Einerseits kanndie eigentliche Wallet beim Dienstanbieter auf dem Server verwaltet, anderseitskann sie auch auf dem gewünschten mobilen Endgerät abgelegt werden (vgl.Abschnitt 4.5). In letzterem Fall muss die Wallet besonders vor Fremdzugriffengeschützt werden.

Wie zu Beginn der Arbeit angesprochen ist die Benutzerfreundlichkeit ein wichtigesKriterium für den Erfolg eines mobilen Bezahlsystems. Dazu gehören sowohl dieBedienung der Applikation als auch der Austausch der notwendigen Kontoinforma-tionen. Eine manuelle Eingabe einzelner Daten ist in vielen Fällen langsamer alsdas automatische Einlesen mittels einer einfachen Schnittstelle wie NFC in neuerenSmartphones. Zusätzlich ermöglicht bargeldloses Zahlen mit einer eigenständigenHardware in Form des Smartphones die Möglichkeit, weitere Dienste und verein-fachte Abläufe anzubieten (vgl. Massoth u. Bingel [2009] und Karnouskos [2004]).Beispielsweise können Informationen über Sonderangebote direkt auf das Handyübertragen werden (ebd.). Gao u. a. [2009] schlägt das Einkaufen ohne Kasse vor(ebd.).

Des Weiteren ist die Sicherheit sowohl für den Dienstanbieter als auch für den Kun-den von Bedeutung. Mobile Bezahlsysteme sind in vielen Fällen ähnlich angreifbarwie klassische Onlinebanking Angebote. Besonders Social Engineering bedeutet eineGefahr, da die Mehrheit der Systeme eine Form von Anmeldung beim Dienstanbietererfordert. Hinzu kommt die Gefahr durch die verwendete Plattform. Ein Handy kanninklusive der darauf gespeicherten Daten verloren gehen oder gestohlen werden. Inbeiden Fällen ist ein Missbrauch der Informationen möglich. Mobey Forum MobileFinancial Services Ltd [2010] weist aber auch auf neuere Mechanismen hin, welchegerade vor letzterem Risiko durch physikalischen Schutz absichern sollen. Beispiels-weise schlägt es die Verwendung von Secure Elements (SE) vor (ebd.). VerschiedenerAngriffspunkte werden in Abschnitt 4.2 ausführlich behandelt.

Die Vielzahl der mobilen Bezahllösungen basiert auf Point of Sale (POS) Syste-men. Ein POS besteht meist aus einem Terminal, dass über Schnittstellen mit derKasse und dem Identifikationselement – der Geldkarte, dem Smartphone usw. –des Kunden kommuniziert und die Überweisung durchführt (vgl. Choi u. a. [2007]).POS Terminals bestehen größtenteils aus einer eigenständigen und speziell für das




Bezahlen entwickelten Hardware, die das sichere Überweisen in einem prinzipiellunsicheren Umfeld ermöglicht (vgl. EMVCo [2008]).

Andere Bezahlsysteme ermöglichen die direkte Überweisung zwischen zwei Kun-den des Dienstleisters. Beim sogenannten Peer-to-Peer Payment werden Transak-tionen direkt zwischen zwei Personen durchgeführt. Teilweise wird auch der Begriffdes Consumer-to-Consumer (C2C) Payment verwendet (vgl. [Choi u. a. 2007, Seite6ff.]). Im Gegensatz zur klassischen Überweisung im Onlinebanking bezieht eine P2PÜberweisung die physikalische Nähe beider Parteien mit ein. Die rudimentäre Formeiner P2P Bezahlung ist das Zahlen mit reellem Geld in Münz- oder Papierform. Inmobilen Systemen tritt das Smartphone an die Stelle des Geldes und es werden kei-ne physikalischen Objekte übergeben, sondern es findet ein Informationsaustauschzwischen den Smartphones statt. Die Benutzerinteraktion beschränkt sich dann aufdie Initiierung des Vorgangs, die Eingabe der Daten – meist nur der Betrag – unddie manuelle Bestätigung (vgl. Karnouskos [2004]).

Eine P2P Überweisung kann sowohl vom Zahlenden als auch vom Geldempfängerausgehen. Im Folgenden wird der Ablauf ausgehend vom Zahlenden beschrieben.Abbildung 2.5 visualisiert dies.

1. Der Zahlende drückt seinen Zahlungswunsch durch Erstellung einer Anfrageaus. Diese kann bereits den Betrag enthalten. Die Anfrage wird an das Smart-phone des Geldempfängers übertragen.

2. Sofern noch kein Betrag in der Anfrage festgelegt wurde, setzt ihn der Geld-empfänger ein und leitet die Anfrage an den Server des Dienstanbieters weiter.

3. Der Server verifiziert die Anfrage und stellt eine Bestätigungsanfrage an denZahlenden. Dabei handelt es sich im Normalfall um eine Form von Challenge,welche die Transaktionsdaten enthält.

4. Der Zahlende bestätigt die Zahlung, die im Anschluss vom Server durchgeführtwird.

Des Weiteren der Ablauf initiiert durch den Geldempfänger und grafisch dargestelltin Abbildung 2.6. Da eine Überweisung nicht erst über den Geldempfänger transfe-riert werden muss, verringert sich die Anzahl der notwendigen Schritte.

1. Der Geldempfänger erstellt eine Zahlungsanfrage mit dem gewünschten Betragund übermittelt diese an den Zahlenden.

2. Der Zahlende prüft die Anfrage, bestätigt sie und leitet die bestätigte Zah-lungsanfrage an den Server weiter.




3. Der Server prüft die eingegangene Überweisung und führt sie im Erfolgsfallaus.

Die beschriebene Variante kommt ohne Challenge von Seiten des Servers aus. Esist aber auch möglich, dass der Geldempfänger ähnlich wie beim ersten Verfahrenzuerst eine Challenge vom Server abfragt und diese dann zusammen mit den Trans-aktionsdaten an den Zahlenden übermittelt.

Zahlender

1a. Zahlungsanfrage

1b. Zahlungsanfrage

3a. Bestätigungs-anfrage

3b. Bestätigung

2. Verifikation4. Abschluss der Transaktion

Zahlungsserver

Geldempfänger

Abbildung 2.5.: Eine Peer-to-Peer Überweisung ausgehend vom Zahlenden (Quelle:Agarwal u. a. [2007]; [Übersetzung durch Verfasser]).




Zahlender

1. Zahlungsanfrage

2. BestätigteZahlungsanfrage

3. Abschluss der Transaktion

Zahlungsserver

Geldempfänger

Abbildung 2.6.: Eine Peer-to-Peer Überweisung ausgehend vom Geldempfänger (ei-gene Darstellung).



3. Peer-to-Peer Payment mit eKaay

Der erste Teil dieser Arbeit stellt den Entwurf eines mobilen Peer-to-Peer Bezahl-systems auf der Basis von eKaay vor. Es werden zunächst eine Reihe von Zielenfür das fertige Produkt formuliert. Daraufhin folgt die Vorstellung einer Testum-gebung, welche an reelle Banksysteme angelehnt ist. Anschließend wird zunächstder Entwurf des reinen Bezahlsystems und dann eine Erweiterung für Online ShopSysteme erläutert. Den Abschluss bildet eine Diskussion über das Verfahren. EineSicherheitsanalyse folgt in Kapitel 4 in Abschnitt 4.3.

3.1. Formulierung der Ziele

Vor dem Entwurf eines P2P Bezahlsystems müssen die Rahmenbedingungen fest-gelegt werden. Sie definieren die Ziele, welche zum Schluss erfüllt sein müssen. DesWeiteren geben sie einen Leitfaden vor, der beim Entwurf unterstützen kann.

Grundarchitektur ist eKaay. Zur Umsetzung eines Bezahlsystems eignet sich eKaay,da es mit eKaay TAN bereits eine notwendige Komponente zur Verfügungstellt. Mittels eKaay TAN ist ein Challenge-Response-Verfahren möglich, wel-ches Transaktionsdaten enthält (vgl. Abschnitt 2.1). Auf diese Weise lassensich Überweisungen sicher verifizieren.

Kommunikation mittels NFC. Zur Erforschung von Near Field Communication undder Präsentation einer Anwendung soll das Bezahlsystem den Einsatz von NFCzur Kommunikation ermöglichen. In bereits bestehenden Arbeiten konnte ge-zeigt werden, dass NFC insbesondere im Bereich der mobilen BezahlsystemenVorteile – beispielsweise in Sicherheit und Benutzerfreundlichkeit – gegenüberanderen Technologien aufweist (vgl. Ondrus u. Pigneur [2007]). Da die Ap-plikation per Definition einen P2P Kontakt vorsieht, sollte der gleichnamigePeer-to-Peer Mode (vgl. Abschnitt 2.2) verwendet werden.

Kompatibilität mit iOS und Android. Aus der Anforderung eines mobilen Betriebs-systems, welches sowohl NFC unterstützt als auch einen Client für eKaay be-sitzt, ergibt sich die Verwendung von Android als mobile Plattform. Trotzdemsoll auch die aus eKaay bekannte Kompatibilität mit iOS bestehen bleiben.




Aus diesem Grund darf sich die Kommunikation nicht nur auf NFC beschrän-ken, sondern muss auch Alternativen bieten. Der in eKaay verwendete QRCode bietet sich für diesen Zweck an.

Änderungen an der Architektur vermeiden. Die Implementierung des eigentlichenBezahlverfahren muss möglichst ohne Änderung der Architektur durchgeführtwerden. Dies betrifft insbesondere eKaay. Dies setzt eine Trennung des Be-zahlsystems von eKaay voraus und ermöglicht so eine unabhängige Weiterent-wicklung beider Systeme.

3.2. Entwurf einer Testumgebung

Damit das Bezahlsystem unter realistischen Bedingungen getestet werden kann, wirdein einfaches Onlinebanking System umgesetzt. Es dient als Testumgebung und stelltdie grundlegende Architektur auf Seiten der Bank. Das System wird im Folgen-den als Server bezeichnet. Er bietet ein einfaches, auf einer Datenbank basierendesKontensystem an. Jedes Konto erfordert individuelle Anmeldedaten und besitzt einGuthaben. Überweisungen sind innerhalb der Bank von einem Konto zu einem an-deren möglich. Dafür steht ein Überweisungsformular zur Verfügung, welches nebenEmpfänger und Betrag auch die Eingabe eines Verwendungszweck vorsieht. Anstel-le eines klassischen TAN Verfahrens wird der Einfachheit halber das eKaay TANVerfahren eingesetzt. Es ermöglicht die Bestätigung ohne externe TAN Liste oderdynamische TAN Systeme wie z. B. einem TAN Generator. Die Anmeldung zumKonto ist sowohl durch manuelle Eingabe von Benutzername und Passwort als auchdurch eKaay möglich. Um eKaay einsetzen zu können, wurde die Serverkomponentevon eKaay nach Anleitung parallel zum Server der Bank installiert (vgl. Borchert[2012a]). Damit eine Anbindung des Kontos an eKaay möglich ist, kann ein Benut-zer in seinen persönlichen Kontoeinstellungen das Smartphone und damit auch dasKonto für eKaay registrieren. Mit Ausnahme der Anmeldung und der TAN-Abfrageimplementiert die Bank keinerlei Sicherheitsmechanismen wie sie für Finanzinstitu-te vorgeschrieben sind. Dies ist nicht Inhalt dieser Arbeit und würde den Rahmenübersteigen. Um dem Zweck einer Testumgebung gerecht zu werden, stellt der Servereine Reihe von Ausgaben zur Verfügung. Diese Ausgaben ermöglichen die Beobach-tung aller Konten und aller durchgeführten Transaktionen. Der Server ist wie eKaaykomplett in PHP entwickelt. Eine Übersicht ist in Anhang A in Abbildung A.1.



3.3. Entwurf von eKaayCash


Dieser Abschnitt widmet sich dem Entwurf des Peer-to-Peer Verfahrens. Zunächstwird das Verfahren vorgestellt und das Gesamtkonzept beschrieben. Im Anschlusswerden die Umsetzung der Kommunikation und ein zusätzlicher Sicherheitsmecha-nismus erläutert. Das Verfahren wird ab diesem Zeitpunkt als eKaayCash bezeichnet.Die Partei, welche eKaayCash als Bezahlsystem anbietet, erhält im Folgenden dieBezeichnung Dienstanbieter.

3.3.1. Verfahren

Zur Vereinfachung wird eKaayCash als ein Konto basierendes mobiles Bezahlsystemumgesetzt. Wie in Abschnitt 2.4 beschrieben, können in Konto basierenden Verfah-ren die eigentliche Bank und der Dienstanbieter für das mobile Bezahlsystem einund dieselbe Partei sein. Das Verfahren muss in diesem Fall keine eigene Verwaltungvon Guthaben implementieren, da es lediglich eine Weiterleitung der bestätigtenÜberweisungen an die Bank durchführt. Das hat den Vorteil, dass das Verfahren dieVerifizierungsmechanismen der Bank verwenden kann. Diese Festlegung folgt den inAbschnitt 3.1 beschriebenen Regeln. Insbesondere ist keine Implementierung einergesonderten Verifizierung in eKaay notwendig.

Unabhängig vom eigentlichen Ablauf muss das Verfahren eine Reihe von Datenvon den Benutzern erfassen. Essentiell sind der Bezeichner des Geldempfängers, derBezeichner des Zahlende und der Betrag. Optional und üblichen Überweisungsfor-mularen folgend wird auch die Eingabe eines Verwendungszweck ermöglicht (vgl.ZKA [2009]). Das entstehende Formular kann auf zwei Arten dargestellt werden. Eskann entweder direkt in einer Applikation auf dem Smartphone des Benutzers inte-griert werden. Das erhöht jedoch den Aufwand im Falle einer Portierung auf andereBetriebssystem. Oder eine einfachere Variante ist die Darstellung einer in die Bankintegrierten Webseite. In diesem Fall entspricht das Formular weitestgehend einemklassischen Überweisungsformular im Onlinebanking. Das Formular kann dann nichtnur auf Smartphones in einem mobilen Umfeld genutzt werden, sondern auch voneinem klassischen Computer mit Bildschirm. Lediglich die zweite beteiligte Parteibenötigt ein Smartphone. Im Gegensatz zu einem klassischen Überweisungsformularmüssen nicht alle Daten manuell abgefragt werden. Im klassischen Verfahren ist derZahlende bekannt, da er die Überweisung erstellt. In einer mobilen Variante miteKaay fällt zusätzlich die zweite Partei weg, da sie durch das in der eKaay Appgespeicherten Konto identifiziert werden kann (vgl. Abschnitt 2.1). Das Formularmuss dann nur noch den Betrag und den optionalen Verwendungszweck abfragen(vgl. Abbildung 3.1).




P2P ÜberweisungBetrag:

Verwendungszweck (optional):

0,00 €

Abbildung 3.1.: Formular für eine mobile Überweisung. Geldempfänger und Zahlen-der werden automatisch erfasst (eigene Darstellung).

Mit der Festlegung der Art des mobilen Bezahlsystems und dem Entwurf eines For-mulars für mobile Überweisungen auf Seiten der Bank, kann der eigentliche Ablaufeiner Transaktion bestimmt werden. Wie in Abschnitt 2.4 erläutert, kann eine Trans-aktion vom Zahlendem oder vom Geldempfänger ausgehen. Der in Abbildung 2.2dargestellte Ablauf für eKaay TAN entspricht der in Abschnitt 2.4 beschriebenen,vom Geldempfänger ausgehenden, Variante. Ein Ablauf vom Geldempfänger aus istauch aufgrund des Webformulars notwendig. Beim Aufruf des Formulars hat derGeldempfänger sich am Server der Bank angemeldet. Nach Eingabe aller Daten er-hält der Server somit Informationen über Geldempfänger, Betrag und Verwendungs-zweck. Durch die Bestätigung der eKaay TAN Challenge durch den Zahlenden erhältder Server den fehlenden Identifikator (ID) des Zahlenden und kann im Anschluss ei-ne vollständige Überweisung durchführen. Der Ablauf mit eKaay ist zwar auch vomZahlenden ausgehend durchführbar, in diesem Fall muss er aber die ID des Geld-empfängers entweder manuell eingeben oder es ist eine zusätzliche Kommunikationzwischen beiden Smartphones notwendig, welche den ID Austausch beinhaltet. DesWeiteren kann der vorgeschlagene Ablauf in einer späteren Variante von eKaayCashverwendet werden (vgl. Abschnitt 3.4). Der im Folgenden beschriebene und in Ab-bildung 3.2 grafisch dargestellte Ablauf berücksichtigt somit die in Abschnitt 3.1festgelegten Punkte Grundarchitektur und Vermeidung von Änderungen in dersel-ben. Eine ausführliche Darstellung befindet sich im Anhang A in Abbildung A.2.

1. Der Geldempfänger ruft das Überweisungsformular auf und gibt den Betragund optional den Verwendungszweck ein. Er sendet das Formular an den Ser-ver.

2. Der Server liest den Identifikator des Geldempfänger aus. Aus ID, Betrag undVerwendungszweck generiert er unter Verwendung von eKaay eine Challengeund überträgt diese in Form eines QR Codes oder kodiert für eine Übertragungvia NFC an den Geldempfänger.




3. Die Challenge wird auf dem Bildschirm des Empfängers angezeigt. Sie kannjetzt mit Hilfe des QR Code oder via NFC an das Smartphone des Zahlendenversandt werden.

4. Das Smartphone des Zahlenden zeigt die Transaktionsdaten an. Der Zahlendekann die Informationen überprüfen und ablehnen oder bestätigen. Im Falleiner Bestätigung wird aus der Challenge und dem Geheimnis des Zahlendendie Response erzeugt und zusammen mit der ID des Zahlenden an den Serververschickt.

5. Der Server prüft die Response und die Transaktion im Gesamten. Im Erfolgsfallführt er sie aus. Sowohl der Geldempfänger als auch der Zahlende erhalten eineBestätigung.

Geldempfänger Zahlender

3. Challenge voneKaay TAN

1. Überweisungs-formular

5. Response


Server der Bank

2. Challenge voneKaay TAN

4. Prüfen und Bestätigen

Abbildung 3.2.: Ablauf einer Transaktion mittels eKaayCash. Bestätigungen nacherfolgreicher Durchführung an beide Parteien sind der Übersichtwegen nicht enthalten (eigene Darstellung).

3.3.2. Peer-to-Peer Kommunikation

In einem Peer-to-Peer System spielt die Kommunikation eine wichtige Rolle. Gegen-über einem klassischen Client-Server-Modell steht die Rollenverteilung nicht fest,sondern muss aus dem Kontext bestimmt werden. Dies ergibt häufig wechselnde




Rollen (vgl. Mahlmann u. Schindelhauer [2007]). Der im vorherigen Abschnitt vor-gestellte Ablauf vereinfacht das Szenario, da zwischen beiden Benutzern nur eineKommunikation in eine Richtung stattfindet. Diese Kommunikation überträgt dieChallenge vom Smartphone des Geldempfängers auf das Smartphone des Zahlenden.Eine Bestätigung des erfolgreichen Empfangs ist nicht nötig, da beide Parteien inphysikalischer Nähe zueinander stehen und somit den Vorgang im Fall eines Fehlersjederzeit neu starten können.

Aus dem eKaay Verfahren ergibt sich der Datenaustausch mit Hilfe eines QR Codes.Er wird nach vollständigem Ausfüllen des Überweisungsformulars vom Server erzeugtund auf dem Bildschirm des Geldempfängers angezeigt. Der QR Code enthält in derVariante eKaay TAN neben Metadaten für das Verfahren eine Session-ID und einenText. Der Text ist eine lesbare Form der Überweisungsdaten und bildet zusammenmit der Session-ID die Challenge. In Tabelle 3.1 wird der vollständige Inhalt einesQR Codes von eKaay TAN vorgestellt.

Syntax BeispielEKAAY

Versionsnummer: V1Modus: TANUntermodus: 2FSession-ID: h4U2jsin89iQalP9Server-Name: www.ekaay.com/Foto-PINBenutzer-ID: 12121212Text: Bitte bestaetigen Sie folgende Ueberweisungsdaten:

Kontonummer: 272625311Bankleitzahl: 20052222Betrag: 20,45 Euro

Tabelle 3.1.: Syntax der Daten von eKaay TAN aus einem QR Code (Quelle: Bor-chert [2012a]).

Wie in Abschnitt 2.1 dargelegt, muss der QR Code vom Zahlenden unter Verwen-dung der eKaay App abfotografiert werden. Die App liest anschließend die enthalte-nen Daten aus und führt den nächsten Schritt des eKaay TAN Verfahrens durch. Dadie Applikation für diesen Zweck nicht angepasst werden muss, ist eKaayCash ausdiesem Grund sowohl mit Android basierten, als auch mit iOS basierten Smartpho-nes kompatibel. Damit ist der Aspekt der Kompatibilität aus Abschnitt 3.1 erfüllt.

Das zweite Kommunikationsmedium ist die Übertragung mittels Near Field Commu-nication. Um den QR Code einzulesen müssen die Smartphones in einer bestimm-




te Art und Weise zueinander gehalten werden. Dadurch wird jedoch die Benut-zerfreundlichkeit der Anwendung verringert. Eine einfachere Bedienung ermöglichtNFC, da es lediglich eine physikalische Nähe beider Geräte für einen kurzen Zeit-raum benötigt. Die Haltung ist dabei unspezifischer als bei der Verwendung des QRCode. Damit NFC im bestehenden Ablauf verwendet werden kann, ist eine Erwei-terung von eKaay nötig. Dazu wird in die Webseite, welche den QR Code anzeigt,ein Link integriert. Er enthält die Daten für die Übertragung via NFC. Es handeltsich dabei um dieselben Informationen wie in Tabelle 3.1. Sie werden gemäß demStandard für Uniform Resource Locators (URL) kodiert (vgl. Lee u. a. [1994]). DesWeiteren wird der Link mit einem für eKaayCash festgelegten Scheme ausgezeichnet.Die Form eines Scheme wurde von Lee u. a. [1994] definiert. Um den Anforderungendes Standards zu entsprechen, wurde der Begriff „ekaaycash“ in Kleinbuchstaben alsaussagekräftiges Scheme gewählt. In Listing 3.1 ist der Beginn eines Links mit voll-ständigem Scheme dargestellt. Er wird vom Server nur in den Quellcode integriert,wenn ein NFC-fähiges Endgerät die Webseite aufruft. Aufgrund von Beschränkun-gen durch viele Hersteller kann die Unterstützung anhand des User-Agent nur ein-geschränkt erkannt werden (vgl. Bray [2010]). Der Link wird aus diesem Grundauf jedem Smartphone angezeigt, welches Android als Betriebssystem angibt. Dieserverseitige Implementierung von NFC ist damit vollständig.

1 ekaaycash://EKAAY%250D%250AV1%250D%250ASESAME (...)

Listing 3.1: Beispiel für einen eKaayCash NFC Link kodiert gemäß Lee u. a. [1994](eigene Darstellung).

Zur Benutzung von NFC muss der Anwender nur diesen Link ausführen. Dies star-tet automatisch die eKaay App aufgrund folgender Erweiterung. Die Erweiterungverknüpft die App mit dem implementierten Scheme. Dazu wird das in Abschnitt2.3 vorgestellte Manifest um einen Filter für benutzerdefinierte URL Schemes er-weitert. Der Filter gibt an, dass das Programm ein neues Scheme registriert unddieses verarbeiten kann. Das Betriebssystem erhält damit die Information, welchesProgramm bei Aufruf eines bestimmten Schemes ausgeführt werden muss.

Wurde der NFC Link von der eKaay App empfangen und wurden die kodiertenNutzdaten extrahiert, können diese mittels NFC übertragen werden. Dazu werdendie Nutzdaten dekodiert und in eine Nachricht nach dem NFC Data Exchange For-mat eingebettet (vgl. Abschnitt 2.2). Diese wird anschließend an den NFC Adaptervon Android übermittelt, welcher sie im Fall eines Kontakts überträgt. Die Appaktiviert gleichzeitig den Empfang von Nachrichten. Auf diese Weise müssen sowohlder Geldempfänger als auch der Zahlende keine weiteren Schritte unternehmen. DieDatenübertragung findet statt, sobald sich beide Smartphones in einem ausreichendgeringen Abstand zueinander befinden.




Die in diesem Abschnitt vorgestellten Änderungen erfüllen das Kriterium der Ver-wendung von NFC in Abschnitt 3.1. Sie erfordern zwar geringfügige Anpassungenan der Serverkomponente von eKaay und an der Applikation und widersprechensomit der Vermeidungen von Änderungen, allerdings sind die Änderungen vollstän-dig optional. Die Verwendung von NFC erhöht die Benutzerfreundlichkeit für dieAnwender durch eine Vereinfachung der Bedienung und zeigt Vorteile gegenüber an-deren Kommunikationsformen wie 2D Barcodes (vgl. Ondrus u. Pigneur [2007]).

3.3.3. Verbesserung der Sicherheit

Die Sicherheit von mobilen Bezahlsystemen kann durch die zwingende Eingabe ei-ner PIN zur Bestätigung der Transaktion verbessert werden. Die Eingabe einer PINvermindert jedoch wiederum die Benutzerfreundlichkeit. Zudem ist sie bei Kleinstbe-trägen häufig nicht notwendig, da der Aufwand für einen Angreifer höher zu bewertenist, als der Gewinn aus diesen Summen. Im Zuge der Einführung des kontaktlosengirogo Verfahrens hat die Deutsche Kreditwirtschaft [2012] eine Höchstgrenze vonzwanzig Euro für Transaktionen ohne PIN festgelegt. Höhere Beträge müssen durcheine klassische Transaktion mit Eingabe der PIN versandt werden. Dieses Prinzipverbindet Benutzerfreundlichkeit mit einer hohen Sicherheit (ebd.).

In das eKaayCash Verfahren kann derselbe Mechanismus integriert werden. Anstel-le einer normalen PIN, welche von einem Schadprogramm ausgelesen werden kann,verwendet es jedoch das eKaay PIN Verfahren (vgl. Abschnitt 2.1). Nach Bestä-tigung der Transaktion durch den Zahlenden stellt die eKaay Server Komponenteeine Anfrage an den Server des Dienstanbieters, ob eine PIN für die vorliegendeÜberweisung notwendig ist. Diese Funktionalität ist bereits in eKaay integriert undbenötigt dementsprechend keine weitere Änderungen am System. Der Server desDienstanbieter muss auf Basis der übertragenen Parameter, welche unter anderemdie Transaktions ID enthalten, entscheiden ob eine PIN notwendig ist. Wie bei gi-rogo wird als Entscheidungsgrund der Betrag mit einem Grenzwert verglichen. Mitdiesem Ablauf sind allerdings weitere Kriterien umsetzbar. Beispielsweise kann derDienstanbieter bei einer großen Anzahl kleinerer Beträge innerhalb eines kurzenZeitraums ebenfalls eine PIN verlangen.

Die vorgeschlagene Erweiterung verbessert die Sicherheit des eKaayCash Verfahrensohne Änderungen am zugrundeliegenden System. Dabei ist es flexibel erweiterbar.Durch die Verwendung von eKaay PIN kann die PIN zudem nicht durch ein Schad-programm auf dem Handy gestohlen werden.



3.4. Erweiterung für Online Shop Systeme

3.4. Erweiterung für Online Shop Systeme

In seiner beschriebenen Form ist eKaayCash ein vollwertiges mobiles Bezahlsys-tem mit Peer-to-Peer Funktionalität. Seine Verwendbarkeit kann allerdings nocherweitert werden. Zu diesem Zweck wird in diesem Abschnitt eine Anpassung vor-genommen, welche die Bezahlung mittels eKaayCash in Online Shop Systemen er-möglicht.

Zur Demonstration wird ein einfacher Shop implementiert. Er speichert neben be-schreibenden Informationen – zum Beispiel Bild und Artikelbeschreibung – aucheinen kurzen Text als Verwendungszweck in einer Überweisung und den Preis. Auf-grund des folgenden Aufbaus der Shop Komponente von eKaayCash wird auf einenWarenkorb oder ähnliche Bestellformulare verzichtet. Der Online Shop wird kom-plett ohne Benutzerkonten umgesetzt und benötigt außer bei eKaayCash selbst keineweitere Registrierung.

Im Gegensatz zum reinen P2P Verfahren füllt nicht ein Mensch das Überweisungs-formular aus. Aus diesem Grund wird es so angepasst, dass auch von einer SoftwareÜberweisungen generiert werden können. Das Programm auf dem Server, welchesdas Formular verarbeitet, wird darum um einen zusätzlichen Parameter erweitert. Inder ursprünglichen Variante erwartet das Programm den Betrag und den optionalenVerwendungszweck. Dazu kommt die ID des Geldempfängers, welche automatischausgelesen wird, da der Geldempfänger sich zuvor anmelden muss. Die Anmeldungentfällt bei einem Online Shop und wird durch einen neuen Parameter für die IDdes Shops – also des Geldempfängers – ersetzt. Das Konto mit dieser ID muss zuvorbeim Dienstanbieter für die Online Shop Erweiterung aktiviert werden, andernfallswird die Überweisung nicht erzeugt.

Mit der beschriebenen Änderung kann der Server des Shopanbieters beim Aufrufder Webseite für jeden Artikel eine Transaktion generieren. Diese kann beispielswei-se direkt neben dem jeweiligen Artikel platziert werden (vgl. Abbildung 3.3). EinKunde kann diesen Artikel kaufen und gleichzeitig bezahlen in dem er mit eKaay denjeweiligen QR Code einliest. Sofern die Webseite des Shops auf einem Smartphoneangezeigt wird, ist auch die Verwendung von NFC zur Datenübertragung möglich.

Nach der Durchführung einer Transaktion, d. h. nach Kauf durch einen Kunden,sendet der Server des Dienstanbieters eine Bestätigung für die Bezahlung an denServer des Online Shops. Diese Bestätigung enthält die ID des Zahlenden, den Be-trag, den Verwendungszweck und den Zeitpunkt der Überweisung. Über eine weitereSchnittstelle kann der Shop eine Anfrage an den eKaayCash Server senden und dieEchtheit der Bestätigung verifizieren. Ein vergleichbares Verfahren wird von PayPal




Abbildung 3.3.: Beispiel für einen Artikel mit der dazugehörenden eKaayCashTransaktion zum gleichzeitigen Kaufen und Bezahlen (eigeneDarstellung).

angeboten (vgl. PayPal [2012c]). Wie in der Sicherheitsanalyse noch deutlich wer-den wird (vgl. Abschnitt 4.3.1.2), ist diese Prüfung zwingend notwendig. Für die Artder Kontrolle existieren verschiedene Möglichkeiten. So ist auch die Verwendung ei-nes Public-Key-Verfahrens denkbar. Die vorliegende Arbeit hat, der Vereinfachungwegen, das oben beschriebene Verfahren umgesetzt.

Der folgende Ablauf beschreibt einen Einkauf mit Hilfe von eKaayCash in einemOnline Shop. Die Generierung der Transaktion und der Challenge ist nicht enthalten,da sie mit Abbildung 3.2 übereinstimmt. Der Ablauf beginnt mit dem Einlesen derChallenge durch den Zahlenden. Er ist in Abbildung 3.4 grafisch dargestellt. InAnhang A in Abbildung A.3 befindet sich eine Grafik des vollständigen Ablaufs.

1. Der Kunde liest den QR Code mit seinem Smartphone ein und bestätigt denKauf durch die Bestätigung der Transaktion.

2. Die erzeugte Response wird an den Server des Dienstanbieters übertragen undverifiziert. Im Erfolgsfall führt der Server die Transaktion durch und sendeteine Bestätigung an den Server des Online Shops.

3. Der Server des Online Shops nutzt die in der Bestätigung enthaltenen Datenund sendet eine weitere Anfrage an den Server des Dienstanbieters.

4. Der Server des Dienstanbieter kontrolliert die Daten und bestätigt diese ge-genüber dem Online Shop.

Wie zu Beginn dieses Abschnitts erklärt, benötigt der Online Shop keine Registrie-rung. Die für den Versand benötigten Kundendaten erhält er stattdessen zusammenmit der Bestätigung der Transaktion vom Server des Dienstanbieters. Für einenKunden hat dies den Vorteil, dass er nicht in jedem Online Shop eine Registrierungdurchführen muss. Dadurch wird sowohl die Benutzerfreundlichkeit als auch die Si-cherheit erhöht, da die Daten nur beim Dienstanbieter gespeichert werden müssen.



3.5. Fazit

Kunde


Server des Shops Server der Bank

1. Einlesen

Produktcode

2. Response

4. Transaktionsbestätigung

5. Daten zur Überprüfung

6. Echtheitsbestätigung

Abbildung 3.4.: Ablauf eines Einkaufs im Online Shop mit eKaayCash. Es wird da-von ausgegangen, dass die Transaktion bereits erzeugt wurde (eigeneDarstellung).

Der Inhaber des Online Shops ist nicht für die Sicherheit der Kundendaten ver-antwortlich – mit Ausnahme des Zeitraums zwischen Kauf und Versand – und hatgleichzeitig eine bestätigte Bindung von Kontodaten an Kundendaten durch denDienstanbieter.

Die in diesem Abschnitt vorgestellte Erweiterung für eKaayCash ermöglicht ein ein-faches Bezahlsystem für Online Shops. Die Verwendung an Kassen und Automa-ten ist – vorausgesetzt eine Verbindung zum Internet besteht – ebenfalls möglich.Aufgrund der Bindung von Bezahlung und Kundendaten werden Betrugsversucheerschwert. Gleichzeitig steigt die Benutzerfreundlichkeit sowohl für den Kunden alsauch für den Händler.

3.5. Fazit

In diesem Kapitel wurde eine erste Anwendung für das eKaay TAN Verfahren de-monstriert und seine Vorteile in Bezahlsystemen dargestellt. Dabei wurden alle zu-vor definierten Ziele für eKaayCash eingehalten. Das Verfahren verwendet eKaay alszentrale Verifizierungsinstanz und zur Absicherung aller Transaktionen. Dabei wirdeKaay eingesetzt ohne verändert zu werden. Aus diesem Grund ist eKaayCash auchvollkommen kompatibel mit der eKaay Implementierung auf anderen Betriebssys-




temen wie iOS. Zudem konnte auch der Einsatz von Nahfunk präsentiert werden.Die optionalen Änderungen sind nur geringfügig und ändern das Prinzip von eKaaynicht. Es wird lediglich um einen weiteren Kommunikationskanal zum QR Codeergänzt.

Die Verwendung von eKaay ermöglicht eine getrennte Weiterentwicklung der grund-legenden Architektur – namentlich eKaay – und des eigentlichen Verfahrens eKaay-Cash. Dies umfasst insbesondere die Sicherheit, welche von eKaay geliefert wird.Der Vorteil ist eine Vereinfachung der Implementierung und Weiterentwicklung voneKaayCash, welches ein simples Interface aufweist. Besonders das Kritierum derWeiterentwicklung konnte mit der Erweiterung für Online Shops dargelegt werden.Die Erweiterung ist auch ein Beweis für die Trennung von eKaay und eKaayCash.Es war keine Änderung an eKaay notwendig, um die Erweiterung umzusetzen.

Diese Trennung bietet auch den Vorteil, dass verschiedene Mechanismen von eKaayin eKaayCash verwendet werden können. Einen Hinweis darauf gibt bereits die Ein-bindung von eKaay PIN. Möglich ist aber auch die Verwendung von eKaayCardvorgestellt von Günther [2011]. Dadurch kann die Sicherheit weiter erhöht werden,bzw. kann dies eine Alternative zur PIN darstellen und so die Benutzerfreundlichkeitverbessern, da das Merken der PIN entfallen würde. Zudem muss die Verwendungvon eKaay PIN in einem P2P System kritisch betrachtet werden. Es macht dieEingabe der permutierten PIN im Smartphone des Geldempfängers notwendig. Die-ser muss sein Smartphone gegebenenfalls aus der Hand geben oder zumindest demZahlenden zur Eingabe der PIN hinhalten.

Der Ablauf minimiert die nötige Benutzerinteraktion auf das Notwendige. Eine mög-liche Ablehnung gegenüber NFC durch Anwender wird mit der Verfügbarkeit vonQR Codes begegnet. Die eKaay Basis vereinfacht die Installation der nötigen Softwa-re und Konten auf dem Smartphone. Diese Aspekte können folglich zu einer hohenBenutzerakzeptanz führen.



4. Analyse bestehender mobiler Bezahlsysteme

Im zweiten Hauptteil der vorliegenden Diplomarbeit wird das entwickelte VerfahreneKaayCash auf mögliche Sicherheitslücken und Angriffspunkte untersucht. Diesel-ben Untersuchungsschritte werden für eine Reihe weiterer Verfahren durchgeführt,welche sich zum Zeitpunkt der Entstehung dieser Arbeit bereits im Einsatz oder inder Endphase ihrer Entwicklung befinden. Die einzelnen Ergebnisse werden, sofernmöglich, miteinander verglichen.

4.1. Vorgehen

4.1.1. Auswahl der Verfahren und Kriterien

Mit dem Aufkommen moderner Smartphones und neuer Technologien – beispiels-weise NFC und höher auflösenden Kameras – wächst auch die Anzahl verschiedenerkommerzieller Systeme für den mobilen Einsatz (vgl. Shinder [2011]). Für die in dervorliegenden Arbeit anzustellende Analyse wurde eine repräsentative Auswahl vonVerfahren nach folgenden Kriterien getroffen.

Verfügbarkeit. Es wurden nur Verfahren ausgewählt, über welche ausreichend In-formationen zur Verfügung stehen. Zum Entstehungszeitpunkt dieser Arbeitbefanden sich viele Lösungsansätze erst in der Entwicklung und wurden dar-um nicht in die Betrachtung mitaufgenommen (vgl. Abschnitt 4.10). Es wurdedarauf geachtet, dass offizielle Quellen verfügbar sind, die durch eigene Beob-achtungen gestützt werden können. Verfahren mit wissenschaftlichem Informa-tionsmaterial oder ausführbaren Applikationen wurden bevorzugt ausgewählt.

Smartphone basierend. Es werden nur Systeme einbezogen, die auf modernen Smart-phones lauffähig sind. Shinder [2011] geht davon aus, dass Smartphones inZukunft immer mehr zu allumfassenden, mobilen Werkzeugen werden. EineBetrachtung älterer Handysysteme ist aus diesem Grund nicht sinnvoll (ebd.).

Aktuelle Technologie. Mit der Forschung im Bereich mobiler Bezahlsysteme wur-de bereits früh in der Entwicklung mobiler Telefone begonnen (vgl. Fenner[1992]). Zu den Zielen dieser Arbeit gehört aber unter anderem die Verwen-dung moderner Technologien, wie sie erst mit neuesten Smartphones möglich




werden (vgl. Abschnitt 1.2). Besonderes Augenmerk wird dabei auf die Verwen-dung von NFC gesetzt. Aber auch der Einsatz von hoch auflösenden Kamerasin Verbindung mit Barcodes stellt ein modernes System dar (vgl. Abschnitt3.1). Dies schließt insbesondere ältere Verfahren, welche SMS Nachrichten zurDatenübertragung verwenden, aus. Stattdessen sind internetbasierte Diensteerwünscht.

P2P Payment. Das grundlegende Ziel für eKaayCash ist die Entwicklung einesPeer-to-Peer Payment Systems. Zu vergleichende Fremdsysteme sollten ent-sprechend über die Möglichkeit, oder zumindest über die nötige technischeBasis für eine zukünftige Implementierung verfügen.

Besonders die Kriterien Verfügbarkeit und Aktuelle Technologie führen zu einer star-ken Einschränkung der verfügbaren mobilen Bezahlsysteme. Eine Reihe ausgeschlos-sener Verfahren wird darum in Abschnitt 4.10 dieses Kapitels kurz vorgestellt.

Untersucht werden neben dem eKaayCash Verfahren die folgenden Bezahlsysteme:

• PayPal Mobile Payments

• Google wallet

• Bitcoins

• „A 2D Barcode-Based Mobile Payment System“ vorgestellt von Gao u. a.[2009].

• „A Wireless Payment System“ vorgestellt von Gao u. a. [2006].

• Entwurf einer Smartphone basierten Geldkarte

4.1.2. Ablauf

Vor der eigentlichen Analyse werden mögliche Punkte gesucht, welche in mobilenBezahlsystemen angegriffen werden können. Diese müssen nicht in jedem der vorge-stellten Systeme vorkommen. Besonders Verfahren mit Peer-to-Peer Funktionalitätbieten Angreifern mehr Angriffspunkte als zum Beispiel ein E-Wallet System. Vieleder Angriffe sind jedoch aufgrund der gemeinsamen Plattform und geteilter Kom-munikationswege in jeder mobilen Bezahllösung zumindest theoretisch möglich.

Anschließend kann mit Hilfe der gefundenen Angriffsvektoren jedes System unter-sucht werden. Dabei zeigt sich eine besondere Schwierigkeit: einige der Systemebieten keinen Einblick in die verwendeten Technologien, Algorithmen und Proto-kolle. Aus diesem Grund werden an diesen Stellen ausschließlich die Bezahlabläufebetrachtet und theoretische Überlegungen zu kritischen Punkten angestellt.



4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen

Die Untersuchung eines einzelnen Verfahrens läuft wie folgt ab.

1. Zunächst wird das Bezahlsystem allgemein vorgestellt. Ein Bezahlvorgang wirdaus Sicht der Benutzer erläutert und beschrieben.

2. Im zweiten Abschnitt erfolgt eine technische Beschreibung aller für die Sicher-heitsanalyse relevanten Punkte.

3. Im Anschluss wird kurz auf marktwirtschaftliche Aspekte eingegangen. Insbe-sondere werden Benutzerfreundlichkeit und mögliche Akzeptanz durch Benut-zer hervorgehoben.

4. In der eigentlichen Sicherheitsanalyse werden die allgemeinen Angriffspunkteauf die Abläufe und auf die verwendeten Techniken im Bezahlsystem ange-wandt und erläutert.

5. Die einzelnen Angriffspunkte werden – gekürzt zu Ax, wobei x für eine Zahlsteht – durchnummeriert. Im jeweiligen Fazit eines Verfahrens wird zusam-mengefasst, welche Angriffe unter welchen Bedingungen möglich sind.


In einem mobilen System, welches mit anderen Systemen kommuniziert, existierenfolgende beiden Arten von Angriffen:

• Informationsdiebstahl

• Manipulation von Informationen

Beide Angriffsformen können jeweils auf dem mobilen Gerät und auf dem Kom-munikationskanal erfolgen. Daraus ergeben sich für einen Angreifer insgesamt vierMöglichkeiten. Diese können mit verschiedenen Mitteln realisiert werden, welche imFolgenden betrachtet werden. Die einzelnen Angriffsmöglichkeiten können dann beider Untersuchung der mobilen Bezahlverfahren auf ihre Anwendbarkeit überprüftwerden. Dies schließt eine Untersuchung von denkbaren oder bereits vorhandenenGegenmaßnahmen mit ein. Des Weiteren wird auf die Gefahr eines physikalischeZugriffs auf das Gerät und auf die Gefahr des Social Engineering eingegangen.

A1: Informationsdiebstahl durch Schadprogramme. Bereits 2010 wurde auf Kas-persky Lab [2010] der erste Trojaner für Android basierte Smartphones gemel-det. Da moderne Betriebssysteme für mobile Endgeräte einen ähnlichen Funk-tionsumfang haben wie Desktop- und Serversysteme (vgl. Google [2012b]) undihre Verbreitung stark zugenommen hat, steigt die Attraktivität für Entwick-ler von Schadsoftware. Informationsdiebstahl ist dabei die einfachste Variante.




Besonders die Finanzwelt muss sich gegen die Entwendung von kritischen Da-ten wehren. Sowohl in der Vergangenheit als auch in der Gegenwart betrifft dashauptsächlich Kreditkarten- und Kontoinformationen. Mit mobilen Lösungenkommen weitere Angriffspunkte hinzu. Die unterschiedlichen Verfahren bieteneine Vielzahl an potentiell interessanten Daten. Dazu gehören Zugangsdatenzu Diensten und Informationen, welche Rückschlüsse auf das Kaufverhaltendes Benutzers zulassen. Sicherheitslücken, welche den Zugriff auf Informatio-nen dieser Art erlauben, wurden bereits unter Viaforensics [2011] für Googlewallet veröffentlicht. Andere mobile Verfahren können ebenso gefährdet sein.Zusätzlich besteht die Gefahr, dass Schadprogramme kritische Daten wie einePIN während der Eingabe abhören und sie anschließend ohne das Wissen desBenutzers einsetzen.

Einen Schutz vor Angriff dieser Art bietet die sichere Verschlüsselung der ge-fährdeten Daten. Dabei darf der verwendete Schlüssel nicht selbst auf demEndgerät gespeichert werden. Dieses Problem kann mit einer sogenannte App-PIN gelöst werden. Diese PIN muss beim Zugriff auf die Daten vom Benutzereingegeben werden. Die Eingabe selbst ist zwar wiederum angreifbar, allerdingsverringert sich der unsichere Zeitraum auf einen einzelnen Zeitpunkt. DieserSchutz wird durch das mobile Betriebssystem unterstützt. Systeme wie Andro-id isolieren alle Apps voneinander (vgl. Abschnitt 2.3). Diese Maßnahme kannjedoch aufgrund von Sicherheitslücken umgangen werden. Aus diesem Grundsollten Entwickler weitere Mechanismen wie die oben erwähnte Verschlüsselungimplementieren.

Es bleibt also festzuhalten, dass sensible Daten von mobilen Plattformen ge-stohlen werden können.

A2: Manipulation durch Schadprogramme. Neben dem Diebstahl von Informatio-nen können Schadprogramme Daten manipulieren. Während einer finanziellenTransaktion werden unabhängig vom tatsächlichen Verfahren bestimmte Infor-mationen immer wieder verwendet. Zumindest der Empfänger, der Zahlendeund der Betrag müssen bekannt sein. Je nach Bezahlsystem können noch weite-re Daten hinzukommen. Ein Schadprogramm kann hier einzelne Informationenauszutauschen. Als einfaches Beispiel bietet sich die Manipulation des Emp-fängers einer Geldsumme an. Wenn diese Änderung unbemerkt vom Benutzergeschieht und im kompletten Verfahren keine Absicherung existiert, kann aufdiese Weise der Geldfluss zum Vorteil des Angreifers umgelenkt werden.

Ein bekannter und seit langem verwendeter Schutz ist die Authentisierungmittels einer TAN oder einer PIN. Finanzinstitute setzen diesen Schutz be-sonders im Onlinebanking ein, um eine Transaktion vor Abschluss durch den




Benutzer bestätigen zu lassen. Abhängig von der Variante des eingesetztenSchutzes kann ein Schadprogramm an dieser Stelle – wie im vorherigen Punktbeschrieben – einen Informationsdiebstahl durchführen und dann wiederumselbst in Form einer falschen Transaktion aktiv werden. Die Angreifbarkeit un-terschiedlicher TAN und PIN Implementierungen wird aus diesem Grund beimjeweiligen Bezahlsystem individuell untersucht. Eine sichere Variante ist dieVerwendung kryptographischer Signaturen. Dabei wird von zu sichernden Da-ten, mit Hilfe eines – von Client und Server geteilten – Geheimnisses, eine Artdigitaler Fingerabdruck berechnet. Eine Manipulation der Daten macht die-sen Fingerabdruck ungültig und kann somit erkannt werden (vgl. Gupta u. a.[2005]). Fortgeschrittene TAN Verfahren basieren bereits auf dieser Idee undbieten auf diese Weise einen höheren Schutz (vgl. Baden-WürttembergischeBank [2006]).

Daraus kann gefolgert werden, dass Datenmanipulation ein einfacher Weg fürAngreifer ist, um vollständige Transaktionen zu erzeugen und dass eine Absi-cherung über dynamische Schutzmechanismen unerlässlich ist.

A3: Abhören der Kommunikationsverbindung. Informationen können nicht nur di-rekt auf dem Smartphone gesammelt werden, sondern auch während der ak-tiven Datenübertragung zwischen einem Server und dem Client abgehört wer-den. Moderne Smartphones verfügen über verschiedene Kommunikationssys-teme. Für die vorliegende Arbeit sind kabellose Netzwerke mit Anbindung andas Internet von Interesse. Dazu gehören vorwiegend moderne Mobilfunkstan-dards wie Enhanced Data Rates for GSM Evolution (EDGE), Universal MobileTelecommunications System (UMTS) und Long Term Evolution (LTE). Ak-tuelle Smartphones unterstützen zumindest eine Auswahl dieser Standards fürmobile Internetverbindungen. Um Kosten zu sparen greifen viele Anwenderaußerdem auf ein verfügbares drahtloses lokales Netzwerk (WLAN) zurück.Als lokale Kommunikationsschnittstelle zwischen mobilen Endgeräten kommtzudem häufig der Bluetooth Standard zum Einsatz (vgl. Pehl [2004]). Angriffeauf eine Kommunikationsverbindung werden mittels eines Man-in-the-Middle(MITM) ausgeführt. Dabei versucht ein Angreifer den Kommunikationskanalzwischen zwei Parteien aufzuteilen und sich selbst an dieser Stelle einzufügen.Er kann anschließend den Kommunikationsfluss steuern, übertragene Datenlesen und sie nach eigenem Ermessen weiterleiten. Für den Informationsdieb-stahl ist nur das Abhören der übertragenen Daten relevant. Eine Darstellungdieser Situation findet sich in Abbildung 4.1.

Neben dieser aktiven Variante besteht auch die Möglichkeit eines passivenLauschangriffs. Dies ist besonders bei nicht geschützten Kommunikationskanä-




Alice (Client)Mallory (aktiver Angreifer)

Bob (Server)

Abbildung 4.1.: Erfolgreicher Man-in-the-Middle Angriff auf eine Server-Client Ver-bindung. Der Angreifer Mallory kann den Kommunikationsfluss zwi-schen Alice und Bob vollständig kontrollieren (eigene Darstellung).

len möglich. Dazu gehören ungesicherte WLAN Verbindungen (vgl. Abbildung4.2).

Alice (Client)

Eve (passiver Angreifer)

Bob (Server)

Abbildung 4.2.: Der Angreifer Eve hat zwar keinen direkten Einfluss auf den Kom-munikationskanal, kann aber die Verbindung zwischen Alice undBob unbemerkt belauschen (eigene Darstellung).

Zur Durchführung von Angriffen dieser Art gibt es eine Reihe allgemeinerTechniken wie das Vortäuschen eines WLAN Access Point, DNS Cache Poi-soning (vgl. Son u. Shmatikov) oder ARP Spoofing (vgl. Eriksson u. Johans-son [2007]). In der Arbeit von Eriksson u. Johansson [2007] wird zudem dieAngreifbarkeit von verschlüsselten Verbindungen demonstriert. Des Weiterengibt es eine Reihe von erfolgreichen MITM Angriffen auf bekannte Mobilfunk-standards. Mun u. a. [2009] zeigen in ihrer Analyse, dass die mögliche Zusam-menarbeit von UMTS- und WLAN-Netzen einen Angriffspunkt bietet. DieserBefund wird von Zhang u. a. [2010] bestätigt. Sie schleusten erfolgreich einProgramm zum Belauschen der Kommunikationsverbindungen in die für dieZusammenarbeit verantwortliche Middleware ein (ebd.). Eine größere Gefahrbesteht für Schnittstellen zwischen Global System for Mobile Communicati-ons (GSM) und UMTS-Netzwerken (vgl. Meyer u. Wetze [2004]). Da GSMeine nur schwache Verschlüsselung aufweist, kann diese besonders leicht ange-griffen werden. Gleichzeitig bildet dieses System nach wie vor die Grundlageder meisten Mobilfunknetze (ebd.).




Obwohl sichere Verbindungen unter Verwendung von Secure Sockets Layer(SSL) oder Transport Layer Security (TLS) theoretisch angreifbar sind, bie-ten sie trotzdem einen Schutz vor den meisten Angreifern. Ein weiterer Si-cherheitsfaktor kann die Verwendung einer zusätzlichen symmetrischen oderasymmetrischen Verschlüsslung der Daten sein. Die PIN kann im Fall der sym-metrischen Verschlüsselung das geteilte Geheimnis darstellen.

Dieser Angriffspunkt zeigt zusammengefasst die Bedeutung des Kommunika-tionskanals für den Angreifer und dem zufolge auch für den Entwickler einerAnwendung mit kritischen Daten. Durch die physische Trennung von mobi-lem Endgerät und Übertragungsweg müssen die übertragenen Daten vor un-erwünschtem Einblick geschützt werden.

A4: Manipulation von Daten während der Kommunikationsverbindung. Wie imvorherigen Abschnitt bereits beschrieben, existieren aktive und passive Angrif-fe auf den Kommunikationskanal. Während der passive nur für reine Lausch-angriffe geeignet ist, bietet ein aktiver MITM Angriff weitaus mehr Möglich-keiten. Der Angreifer kontrolliert, wie in Abbildung 4.1 dargestellt, den kom-pletten Kommunikationsfluss. Dies ermöglicht nicht nur einen Einblick in dieübertragenen Informationen, sondern lässt auch die Veränderung aller Da-ten zu. Damit erhält ein Angreifer die gleichen Fähigkeiten wie ein aktivesSchadprogramm, welches Manipulationen durchführt. Wenn der Inhalt nichtgeschützt ist oder der Schutz – in Form einer Prüfnummer – nicht von denzu schützenden Informationen abhängt, kann ein solcher Angriff erfolgreichsein. Ältere, statische TAN-Verfahren verfügen über eine solche lose Bindungvon Schutz – der TAN – und Transaktionsdaten (vgl. Borchert [2012b] undAbbildung 4.3).

Alice (Client)Mallory (aktiver Angreifer)

Bob (Server)

Überweisung von 100 Euro an Carol.TAN: 1234

Überweisung von 900 Euro an Mallory.TAN: 1234

Abbildung 4.3.: Der Angreifer Mallory manipuliert eine Überweisung, welche außereiner vom Inhalt unabhängigen TAN keinen weiteren Schutz auf-weist (eigene Darstellung).

Wie bereits bei Schadprogrammen, lässt sich auch die Manipulation im Kom-munikationskanal durch kryptographische Signaturen aufdecken und somitverhindern.




A5: Physischer Zugriff auf das mobile Endgerät. Neben indirekten Zugriffen aufdas Smartphone über Schadprogramme usw. ist für Menschen auch der direk-te Zugriff möglich, wenn sie in dessen physische Nähe gelangen. Neben den fürden Besitzer erkennbaren potentiellen Fremdzugriffen im Fall eines Verlustesoder Diebstahls des Geräts kann eine unbefugte Person bereits in kurzer Ab-wesenheit des Besitzers Schaden auf einem Smartphone anrichten. Abhängigvon der Dauer des Zugriffs hat der Angreifer verschiedene Möglichkeiten. Erkann in aktiven Applikationen Befehle ausführen oder an geringfügig geschütz-ten Stellen nach Informationen suchen. Sein Handeln ähnelt damit dem einesSchadprogramms. Sofern eine Transaktion nicht durch eine PIN geschützt ist,ist eine Transaktion in einer Finanz-Applikation möglich oder es kann bei-spielsweise der Browserverlauf durchsucht werden. Diese Informationen kön-nen teils direkt Schaden verursachen (vgl. Viaforensics [2011]), teils könnensie zur Vorbereitung weiterer Angriffe verwenden werden. Bei einem längerenZugriff kann ein Angreifer nach tiefer gehenden Informationen suchen. Viafo-rensics [2011] hat gezeigt, dass sich dabei wichtige Daten finden lassen. Mitentsprechenden Kenntnissen kann ein Angreifer auch versuchen den Schutzverschiedener Systeme anzugreifen. Die Offenlegung der PIN und ähnlicherGeheimnisse ist dabei ein wesentlicher Gefahrenpunkt.

Apps können als Schutz für kritische Befehle die Verwendung einer PIN oderÄhnlichem verwenden. Informationen sollten wie beim Schutz vor Trojanernverschlüsselt abgelegt werden. Zum Schutz vor Verlust oder Diebstahl desSmartphones sollte die entfernte Sperrung oder Deaktivierung des Geräts undwichtiger Apps bzw. hinterlegter Benutzerkonten möglich sein. Bei einer ent-fernten Sperrung kann ein mobiles Endgerät oder eine einzelne Applikationohne physikalischen Kontakt vom Dienstanbieter deaktiviert werden.

Es bleibt festzuhalten, dass insbesondere Informationsdiebstahl von Menschendirekt auf dem Endgerät durchgeführt werden kann und dass dieselben Schutz-mechanimen wie gegen Schadprogramme gelten müssen.

A6: Social Engineering. Durch das verstärkte Aufkommen internetbasierter Diens-te mit persönlichen Benutzerkonten wurden gleichzeitig Angriffe entwickelt,um Kontrolle über diese zu erhalten. Es werden nicht nur technische Sicher-heitslücken im eigentlichen Dienst verwendet. Mittels Social Engineering nutztder Angreifer die Unwissenheit vieler Internetnutzer aus. Bekannte Technikensind Phishing oder das fortgeschrittene Pharming (vgl. Jakobsson u. Myers[2006]). Der Benutzer wird mittels scheinbar echter E-Mails vom Dienstanbie-ter oder mittels DNS Spoffing auf eine gefälschte Seite gelockt. Diese Seitegleicht in den meisten Fällen der echten Seite des Dienstes. Sie fordert den Be-




nutzer aus unterschiedlichen Gründen zur Eingabe sicherheitsrelevanter Datenwie Benutzername und Passwort auf. Erkennt das Opfer die gefälschte Seitenicht und gibt seine Daten ein, erhält der Angreifer Zugriff auf das Benut-zerkonto des Opfers (ebd.). Auf diese Weise lassen sich auch statische TANserschleichen. Die Sicherheitsmechanismen der meisten mobilen Apps sind ihrenWebäquivalenten ähnlich oder gar identisch. So werden in vielen Fällen diesel-ben Anmeldeinformationen verwendet. Aus diesem Grund sind auch dieselbenSocial Engineering Angriffe möglich.

Onlinebanking Dienste schützen sich vor Phishing und Pharming mittels mo-derner TAN Verfahren, welche die TAN dynamisch für die jeweilige Transakti-on berechnen (vgl. Baden-Württembergische Bank [2006]). In mobilen Anwen-dungen kann man den Zugriff auf den Dienst einschränken indem nur regis-trierte Smartphones erlaubt werden. Die Erkennung kann mittels der Telefon-nummer, der International Mobile Equipment Identity (IMEI) oder ähnlichen,eindeutigen Daten erfolgen (vgl. PayPal [2012b]).

Es konnte aufgezeigt werden, dass Social Engineering als nicht technischer An-griff Entwickler von sicheren Anwendungen vor besondere Herausforderungenstellt und diese explizit behandelt werden müssen.

A7: Abhören der NFC-Verbindung. Near Field Communication ist zunächst einkabelloses Kommunikationsmedium. Es ähnelt insofern Verbindungen viaWLAN und erlaubt ähnliche Angriffe. Aufgrund seiner sehr geringen, effek-tiven Sendereichweite von zwanzig Zentimetern und Besonderheiten in derArchitektur werden tatsächliche Angriffe hingegen deutlich erschwert. NFCverwendet zur Darstellung einzelner Bits eine modifizierte Miller-Kodierungoder eine Manchester-Kodierung (vgl. Abschnitt 2.2). Diese erlauben prak-tisch keine Manipulation von Daten. Gleichzeitig wird aufgrund des geringenAbstands und spezieller Anforderungen an das Timing ein Man-in-the-MiddleAngriff unmöglich. Diese Problematik für einen Angreifer wird ausführlich vonHaselsteiner u. Breitfuß [2006] beschrieben. Während eine aktive Manipulationnicht möglich ist, kann ein Angreifer jeodch immer noch passiv den Daten-verkehr abhören. Wie Eingangs beschrieben, haben die meisten NFC-fähigenEndgeräte eine maximale Reichweite von zwanzig Zentimetern. Haselsteineru. Breitfuß [2006] gehen allerdings davon aus, dass aktive Empfangsgeräte beiidealen Bedingungen Daten in bis zu zehn Metern Entfernung erfassen kön-nen. In einem einfachen Aufbau wird von Kortvedt u. Mjølsnes [2009] in einemdurchschnittlichen Abstand von zwanzig Zentimetern die komplette Kommuni-kation zwischen einem Tag und einem NFC-fähigen Handy mitgelesen. Bereits




dieser Abstand genügt um beispielsweise in der Nähe eines NFC Terminalseine Sonde anzubringen.

Wie bei Angriff A1 erklärt, bietet nur eine verschlüsselte Übertragung Schutzvor Laufangriffen. Aufgrund des technisch bedingten Schutzes vor Manipula-tion ist die Entwicklung eines sicheren Übertragungsprotokolls für Near FieldCommunication sehr einfach. Ein solches Protokoll wird in der Arbeit vonVan Damme u. a. [2005] vorgestellt. Zu den Schwierigkeiten der Implementie-rung gehören Limitierungen der verwendeten Java Umgebung und die zumZeitpunkt der Arbeit geringe Rechenleistung von mobilen Endgeräten (ebd.).Diese Schwierigkeiten lassen sich mittels modernen mobilen Betriebssystemenund der deutlich höheren Rechenleistung aktueller Smartphones lösen.

Nahfunk ist aus den beschriebenen Gründen ein sicheres Kommunikationsme-dium und bedarf nur geringer zusätzlicher Absicherung durch den Entwickler.

Eine weitere Angriffsmöglichkeit ist das externe Beobachten des Bildschirms durchDrittpersonen oder entsprechendes Überwachungsequipment. Aufgrund der grund-sätzlichen Notwendigkeit von Benutzereingaben bestehen für Entwickler jedoch nurgeringe Schutzmöglichkeiten. Wie bei der klassischen PIN Eingabe am Geldautoma-ten liegt die Verantwortlichkeit hier beim Benutzer. Aus diesem Grund wird dieseArt von Angriff bei der Untersuchung ausgeschlossen. Ebenfalls werden Angriffe aufdie Infrastruktur in Form von Servern und Ahnlichem außer Acht gelassen. Dieseerfordern gesonderte Sicherheitsmechanismen und haben nur indirekt mit dem The-ma des mobilen Bezahlens zu tun. Des Weiteren sind auch Betrugsversuche durcheine der an einer Transaktion beteiligten Parteien nicht Bestandteil der folgendenUntersuchungen. Angriffe dieser Art können in zwei Formen auftreten. Einerseitskönnen direkt falsche Angaben gemacht werden. Dazu gehört beispielsweise ein zuhoher Betrag. Die Verantwortung liegt hier ebenfalls bei den Benutzern und dermanuellen Überprüfung der Transaktion. Des Weiteren kann eine der Parteien ver-suchen, manipulierend auf die Geldüberweisung einzuwirken. Diese Art von Angriffist aber nur mit bereits beschriebenen Mechanismen wie Schadprogrammen möglichund wurde somit bereits erläutert.

Alle Angriffsmöglichkeiten werden in Tabelle 4.1 noch einmal zusammengefasst.

Bei der Vorstellung der einzelnen Angriffsmethoden wurden ausschließlich speziali-sierte Schutzmechanismen erwähnt. Die einzige Ausnahme bilden Schutzfaktoren inder Architektur des Betriebssystems. Bei der Isolation einzelner Prozesse durch An-droid handelt es sich um einen solcher Schutz (vgl. Abschnitt 2.3). Unabhängig vomtechnischen Standpunkt existiert auch der Faktor Gewinn. Angreifer zielen mit ihrenAktionen in vielen Fällen auf einen monetären Gewinn ab. Dieser Gewinn muss in




Name Beschreibung SchutzA1: Informationsdieb-stahl durch Schadpro-gramme.

Ein Trojaner auf dem mo-bilen Endgerät kann theore-tisch alle Daten abhören undauslesen.

Verschlüsselung mit exter-nem Geheimnis und Prozes-sisolierung durch Betriebs-system.

A2: Manipulation durchSchadprogramme.

Daten können von Schad-programmen aktiv geändertwerden.

Kryptographische Signaturfür kritische Informationenund Prozessisolierung durchBetriebssystem.

A3: Abhören der Kom-munikationsverbindung.

Mittels aktivem oder pas-sivem Eingriff in einenKommunikationskanal istdas Abhören aller Informa-tionen möglich.

Verschlüsselung der Datenund sichere Verbindung mit-tels SSL oder TLS.

A4: Manipulation vonDaten während der Kom-munikationsverbindung.

Aktiver Eingriff – sogenann-ter Man-in-the-Middle – er-möglicht die Manipulationvon Daten auf dem Kommu-nikationskanal.

Kryptographische Signatu-ren und sichere Verbindun-gen mittels SSL oder TLS.

A5: Physischer Zugriffauf das mobile Endgerät.

Informationsdiebstahl undNutzung aktiver Applika-tionen; bei längerem Zugriffsind tiefergehende Untersu-chungen und zeitaufwendigeAngriffe möglich.

Verschlüsselung von Daten.Kritische Befehle mittelsPIN absichern. EntfernteDeaktivierung von Applika-tionen, Benutzerkonten undSmartphone.

A6: Social Engineering. Durch einfache und in derVergangenheit häufig erfolg-reiches Phishing und Phar-ming, erhält ein Angreiferleicht Zugang zu kritischenDaten wie Passwörtern.

Nur registrierte Endgerätefür einen Dienst erlauben.Befehle mittels dynamischer,von Eingabedaten abhän-gigen Transaktionsnummernabsichern.

A7: Abhören der NFC-Verbindung.

Versteckte Sonden könnenauf bestimmte Entfernungeneinzelne NFC Verbindungenabhören.

Verschlüsselung der Datenund die Verwendung von si-cheren Verbindungen.

Tabelle 4.1.: Übersicht aller Angriffsmethoden auf mobile Bezahlsysteme (eigeneDarstellung)




einem positiven Verhältnis zum nötigen Aufwand stehen. Entwickler und Betreibermobiler Bezahlsysteme können dieses Verhältnis auf zwei Wegen beeinflussen. DieVerwendung sicherer Techniken und Algorithmen erhöht den Aufwand und somit dieKosten für den Angreifer. Gleichzeitig kann der finanzielle Gewinn verringert wer-den. Viele Bezahlsysteme sind nur für geringe Beträge freigegeben. Ein Angreiferhat somit keine Möglichkeit, durch einen einzelnen Angriff einen größeren Gewinnzu erhalten. Multiple Angriffe auf verschiedene Benutzer erhöhen aber gleichzeitigden Aufwand und die Gefahr einer Entdeckung. Die Handlung wird für den Angrei-fer also unattraktiv. Da die Limitierungen auf Kleinstbeträge durch den jeweiligenDienstanbieter festgelegt werden muss und unabhängig von der Technik ist, wirddies in die folgende Analyse der einzelnen Bezahlsysteme nicht miteinbezogen. Zu-sätzlich bilden viele Verfahren in sich abgeschlossene Systeme, die ein Aufladen desKontos mit Geld durch ein externes Finanzinstitut voraussetzen. Gestohlene Beträgemüssen denselben Ablauf in umgekehrter Reihenfolge durchlaufen. Ein Angriff kanndem zufolge noch innerhalb des Systems des Anbieters erkannt werden.

4.3. eKaayCash

In diesem Abschnitt werden das in Kapitel 3 vorgestellte eKaayCash Verfahren unddessen Erweiterung für Online Shop Systeme auf ihre Sicherheit untersucht.

4.3.1. Sicherheitsanalyse

4.3.1.1. eKaayCash

Die grundlegenden Sicherheitsmechanismen für eKaayCash werden vom eKaay Ver-fahren geliefert. In Abschnitt 2.1 wurde bereits auf das Ergebnis der Sicherheitsana-lyse von Günther [2011] verwiesen. Es wurde eine Reihe von Problemen aufgedeckt,welche zeigen, dass ein Schadprogramm unter bestimmten Bedingungen kritischeOperationen ausführen kann. Beispielsweise kann ein Schadprogamm das Geheimniseines Benutzers auslesen und damit beliebige Transaktionen signieren. Diese Sicher-heitslücken gelten auch für eKaayCash. Allerdings bietet eKaay zusätzliche Mecha-nismen, welche vor den beschriebenen Angriffen schützen. Dazu gehören eKaay PINund eKaayCard. Beide Verfahren können auch mit eKaayCash kombiniert werdenund den Schutz verbessern (ebd.).

Des Weiteren ist auch der Ablauf einer Peer-to-Peer Überweisung angreifbar. Wie inAbschnitt 3.3.1 beschrieben, werden nach dem Ausfüllen des Überweisungsformularsdie darin enthaltenen Daten an den Server übertragen. Ein Schadprogramm auf dem



4.3. eKaayCash

Smartphone des Geldempfängers kann die übertragenen Daten manipulieren undbeispielsweise die ID des Empfängers gegen die eines Angreifers austauschen. Auchein MITM Angriff auf den Übertragungskanal kann zu diesem Ergebnis führen.

Ein ähnlicher Angriff ist auf den generierten QR Code bzw. NFC Link möglich,welche jeweils ein Containerformat für die eigentlichen Daten darstellen (vgl. Ab-schnitt 3.3.2). Zwar bietet die Manipulation beider Container keinen Vorteil (vgl.Abschnitt 2.1), jedoch ist ein Austausch durch ein Schadprogramm möglich. Sowohldas Smartphone des Geldempfängers als auch das des Zahlenden verfügen im Re-gelfall über eine Internetverbindung, da diese für die Verwendung von eKaayCashwichtig ist. Entsprechend kann ein Schadprogramm eine eigene Transaktion initiie-ren und den QR Code sowie den NFC Link ersetzen. Dieser Angriff ist direkt vor derP2P Verbindung zwischen beiden Smartphones möglich, oder auch im Anschluss vorder Anzeige der Transaktion auf dem Handy des Zahlenden. Des Weiteren kann wie-derum ein MITM die Challenge vom Server des Dienstanbieters durch die Challengeeiner anderen Transaktion ersetzen.

Die in den vorherigen Absätzen beschriebenen Angriffe zielen auf den Austauscheiner Transaktion ab. Die Transaktion des Benutzers soll gegen eine weitere Trans-aktion des Angreifers ausgetauscht werden. Während die Durchführung durch Schad-programme von eKaayCash nicht verhindert werden kann, wird zumindest ein Man-in-the-Middle auf die Kommunikation zwischen Server und Geldempfänger aufgrundder Verwendung von verschlüsselten Verbindungen erschwert. Der eigentliche Schutzfindet aber in Form der Überprüfung durch den Zahlenden statt. Eine Transaktionwird erst abgeschlossen, wenn sie vom Zahlenden bestätigt wurde. Dieser muss so-wohl die ID des Geldempfängers als auch den Betrag kontrollieren und kann einenAustausch entsprechend erkennen und abwehren. Der dabei angezeigte Dialog ist inAbbildung 4.4 dargestellt.

eKaay

Bitte bestätigenDatum: 20.4.2012Uhrzeit: 10:00:00Empfaenger: MalloryBetrag: 100.00 Euro

abbrechen OK

Abbildung 4.4.: Der Bestätigungsdialog von eKaay für eine Transaktion (eigeneDarstellung).

Die P2P Übertragung zwischen beiden Smartphones bietet keine Angriffsmöglichkei-ten. Sowohl der QR Code als auch die NFC Verbindung erlauben nur das Abhören




der Daten, welche nicht geheim bleiben müssen (vgl. Abschnitt 2.1 und Abschnitt2.2).

Durch physischen Zugriff hat ein Angreifer die Möglichkeit eine Überweisung durch-zuführen. Dieser Gefahr kann durch Schutz des Benutzerkontos mit einer PIN undder eKaay PIN für die Bestätigung der Transaktion begegnet werden (vgl. Abschnitt2.1).

Da für das P2P Verfahren keine unsichere Eingabe von kritischen Daten benötigtwird, ist ein Angriff mittels Social Engineering nicht möglich.

4.3.1.2. Erweiterung für Online Shop Systeme

Die Erweiterung erlaubt prinzipiell dieselben Angriffe wie eKaayCash selbst. Aller-dings sind darüber hinaus noch weitere Angriffspunkte vorhanden.

Der Kauf und die gleichzeitige Bezahlung werden durch das Einlesen des QR Co-des mit der eKaay App durchgeführt. Ein Schadprogramm auf dem Computer desKunden kann diesen QR Code gegen einen eigenen austauschen und auf diese Wei-se die Bestätigung einer einer gefälschten Überweisung erreichen. Es gelten jedochdieselben Einschränkungen wie im vorherigen Abschnitt. Wenn der Kunde die Über-weisung prüft und nicht bestätigt wird der Angriff abgewehrt. Neben Schadprogram-men können auch Angriffe auf die Webseite beziehungsweise den Server des Shopszum Austausch des QR Codes führen. Zu Angriffen dieser Art zählt unter anderemCross-Site-Scripting (vgl. Grossman u. a. [2007]).

Bei korrekter Implementierung der Schnittstellen hingegen ist ein Shop gegen einegefälschte Transaktionsbestätigung abgesichert. Beliebige Benutzer können zwar eineBestätigung an den Server versenden, diese wird jedoch nicht akzeptiert, da dieVerifizierung durch den Server von eKaayCash fehlschlägt (vgl. Abbildung 4.5).

4.3.2. Fazit

Es kann folgendes Fazit gezogen werden: das Verfahren ist begrenzt durch die An-griffe A2 und A4 bedroht. Die Verantwortung liegt in beiden Fällen beim Zahlenden,welcher eine Transaktion immer überprüfen muss. Der Angriff A5 kann durch Ver-wendung einer PIN für das auf dem Handy gespeicherte Konto abgewehrt werden.Diese muss jedoch vom Benutzer explizit aktiviert werden. Die Angriffe A1, A3, A6und A7 sind für eKaayCash nicht relevant. Durch die Erweiterung für Online Shopswird keine weitere Schwachstelle hinzugefügt.



4.4. PayPal Mobile Payments

Mallory (Kunde)

Server des Shops Server der Bank

1. Einlesen

Produktcode

2. Zahlender: MalloryBetrag: 5€

3. Zahlender: MalloryBetrag: 5€

4. Transaktion ungültig

Abbildung 4.5.: Versuch eines Angreifers einem Shop eine Transaktion vorzutäu-schen (eigene Darstellung).


4.4.1. Beschreibung des Verfahrens

PayPal ist eine Tochtergesellschaft des US-Unternehmens eBay und bietet ein Be-zahlsystem für verschiedene, meist internetbasierte Dienste. Die Konto- und Bezahl-funktionalität ist komplett Webbasiert (vgl. PayPal [2012a]). Inzwischen ermöglichtPayPal auch einen direkten Zugang für mobile Endgeräte in Form von speziellen Ap-ps. Wie von PayPal [2012b] beschrieben, müssen Benutzer ein unterstütztes Handyzunächst für den Service aktivieren – dadurch wird eine Bindung des Smartphonesan ein bestimmtes Konto ermöglicht – und können dann über eine spezielle Appklassische Bezahlvorgänge vornehmen. Diese Apps sprechen dabei nur das bekannteWebinterface an und fügen keine weitere Funktionalität hinzu. Da gerade bei mobi-len Geräten die Gefahr besteht, dass das Gerät entweder verloren geht oder gestohlenwird, müssen alle Transaktionen mit Hilfe einer PIN bestätigt werden (ebd.).

In dieser Hinsicht erfüllt PayPal Mobile Payments die in Abschnitt 4.1 beschriebe-nen Kriterien noch nicht. Möglich wird dies erst durch folgende Änderungen. Am 13.Juli 2011 wurde für Android basierte Smartphones eine neue Version der App vonHardawar [2011] angekündigt. Sie wurde am 8. November 2011 von Samuel [2011] alsVersion 3 veröffentlicht. NFC-fähige Geräte erhalten nach einem Update die Fähig-keit Peer-to-Peer Transaktionen durchzuführen. Das Ziel des Unternehmens ist dieVereinfachung einer Überweisung zwischen zwei Personen. Dies wird unter anderem




dadurch erreicht, dass ein Aufruf der eigentlichen App nicht mehr nötig ist. Stattdes-sen erhält der Benutzer ein einfaches Widget, welches er auf dem Homescreen seinesSmartphones platzieren kann (vgl. Abbildung 4.6). Das Widget erlaubt die Eingabeeines Geldbetrags und damit die Initiierung einer P2P Transaktion (ebd.).

Abbildung 4.6.: Das installierte PayPal Mobile Payments Widget auf dem Home-screen eines Android basierten Smartphones (Quelle: Chambers[2011]).

Zum Zeitpunkt der Entstehung dieser Arbeit stand das Verfahren für europäischeBenutzer noch nicht zur Verfügung, sondern ist nur in den USA einsetzbar. Dievorhandenen Informationen genügen jedoch, um den Ablauf einer Transaktion zubestimmen. Die folgende Beschreibung stützt sich auf Angaben aus der Pressemit-teilung von PayPal (vgl. Hardawar [2011]). Sie ist aus Sicht der Benutzer, d. h. desGeldempfängers und des Zahlenden, beschrieben.

1. Im ersten Schritt gibt der Geldempfänger den gewünschten Betrag in das Wid-get ein.

2. Nach Bestätigung der Eingabe erhält er die Aufforderung sein eigenes Smart-phone an das des Zahlenden zu halten.

3. Beide Benutzer müssen nun einen Moment warten, während der Datenaus-tausch via NFC zwischen beiden Smartphones statt findet.

4. Beide Handys bestätigen den Erfolg der Datenübertragung mit einem – vonPayPal „Buzz“ getauften – Vibrationsalarm.




5. Für den Geldempfänger ist zu diesem Zeitpunkt die aktive Handlung abge-schlossen. Er wird nach Bestätigung durch den Zahlenden mit einer E-Mailüber den erfolgreichen Abschluss der Transaktion informiert.

6. Der Zahlende muss die Überweisung mit Eingabe seiner PIN bestätigen oderkann den gesamten Vorgang abbrechen.

7. Die App baut eine Verbindung zum Server auf und überträgt die Transakti-onsdaten. Der Server führt dann die eigentliche Geldüberweisung durch undsendet eine Bestätigungsmail an den Geldempfänger.

Das Peer-to-Peer Verfahren von PayPal Mobile Payments ist somit in vielen Be-reichen mit eKaayCash vergleichbar. Der komplette Ablauf ist in Abbildung 4.7dargestellt.


2. Zahlungsanfrage (NFC)

4. BestätigteZahlungsanfrage(Internet)

5. Verifikation undGeldüberweisung

Zahlungsserver

1. Eingabe 3. Bestätigung

Abbildung 4.7.: Ablauf einer P2P Transaktion mit PayPal. Das Versenden derBestätigung wurde aus Gründen der Übersicht entfernt (eigeneDarstellung).

4.4.2. Technische Umsetzung

PayPal hat über das eigentliche Verfahren und die Hintergründe nur wenig ver-öffentlicht. Eine exakte Wiedergabe der technischen Umsetzung ist nicht möglich.Der Vorgang für die Benutzer ähnelt aber dem von eKaayCash. Mit diesem Wissenund durch genaue Betrachtung des Ablaufs in einem von PayPal mit einer Presse-mitteilung veröffentlichten Video, lässt sich der technischen Ablauf in groben Zügen




nachvollziehen (vgl. PayPal [2011a]). Eine genauere Untersuchung wird möglich sein,sobald das Verfahren in Europa zur Verfügung steht.

1. Nach der Eingabe des Betrags durch den Geldempfänger ergeben sich zweiMöglichkeiten für die Weiterverarbeitung der Daten (Name des Geldempfän-gers d. h. des Inhabers des aktiven Kontos und Geldbetrag). In eKaayCashwerden die Informationen an den Server gesendet. Er verarbeitet und spei-chert sie. Zum Schluss erhält das Smartphone die Serverantwort in Form desQR Code und des kodierten NFC Payload. Bei PayPal ist es wahrscheinlicher,dass keine Kommunikation mit dem Server stattfindet. Das lässt sich vermu-ten, da die App keine Aufforderung zum Warten anzeigt und der Vorgangverzögerungsfrei fortgesetzt wird.

2. Im folgenden Schritt – der Übertragung der Daten via NFC – kommt die inAbschnitt 2.3 beschriebene API von Android Version 2.3 zum Einsatz. Ob dieÜbertragung verschlüsselt wird, ist nicht bekannt.

3. Die aktiven Schritte des Zahlenden werden lokal auf dessen Smartphone imRahmen der App ausgeführt. Erst mit der Übertragung der abgeschlossenenTransaktion zum Server findet der letzte, technisch interessante Vorgang statt.Da die P2P Funktionalität eine Erweiterung der bestehenden PayPal Mobi-le Payments App darstellt, ist anzunehmen, dass dabei die gleichen Sicher-heitsmechanismen zum Einsatz kommen. Dazu gehört als wichtigsten Punkteine verschlüsselte Übertragung. Zum Zeitpunkt der Entstehung dieser Arbeitkommt TLS in der Version 1.0 zum Einsatz (vgl. PayPal [2012a]).

4.4.3. Verbreitung und Akzeptanz durch Benutzer

Gegenüber anderen Anbietern, welche den mobilen Markt für Bezahlsysteme imZuge neuer Technologien entdecken, hat PayPal dank seines bereits existierendenmobilen Bezahlsystems für Smartphones auf Basis von Android, iOS oder Black-Berry einen Vorteil in der Verbreitung (vgl. PayPal [2012b]). Für Android, welchesNear Field Communication unterstützt, erschien die Erweiterung der App als ein-faches Update. Die Verbreitung wird theoretisch nur durch das Vorhandensein vonNFC-fähigen Smartphones eingeschränkt. Zusätzlich wirkt als künstliche Grenze dievorläufige Einschränkung auf die USA für das Peer-to-Peer System. Ein erster Testin Schweden, welcher von Rao [2011] vorgestellt wurde, zeigt, dass eine uneinge-schränkte Nutzung in anderen Ländern geplant ist. Der schwedische Versuch weistaußerdem auf eine potentielle Ausweitung des Systems hin. Wie eKaayCash soll dasNFC-System in Zukunft für die Bezahlung in reellen Geschäften verfügbar werden.




Dabei werden – wie in Abbildung 4.8 gezeigt – NFC-fähige Terminals zum Einsatzkommen (ebd.).

Abbildung 4.8.: Bezahlung an einem NFC-fähigen Terminal mit PayPal Mobile Pay-ments (Quelle: PayPal [2011b]).

Das P2P Verfahren selbst ist sowohl für den Geldempfänger, als auch für den Zahlen-den einfach zu bedienen. Die Handhabung entspricht in großen Teilen dem Bezahlenmit einer bei Banken üblichen Geldkarte unter der Verwendung von Terminals zurPIN Eingabe. Auch wird kein Geldbetrag auf dem Smartphone gespeichert. Dadurchentfällt eine mögliche Misstrauensquelle gegenüber dem Verfahren. Eine Studie von„Ogilvy & Mather“, veröffentlicht von Patel [2011], zeigt zudem, dass PayPal einähnlich hohes Vertrauen bei seinen Kunden genießt wie MasterCard und AmericanExpress.


Der erste Angriff ist im Zeitraum zwischen der Eingabe des Betrags durch den Gel-dempfänger und der Anzeige der Bestätigung auf dem Smartphone des Zahlendenmöglich. Dabei kann entweder ein Schadprogramm auf einem der beiden Smartpho-nes zum Einsatz kommen oder ein Lauschangriff auf die NFC-Verbindung erfolgen.Bei letzterem können, soweit bekannt, der Geldbetrag und der Identifikator desEmpfängers abgehört werden. Diese Daten sind nur von begrenzter Relevanz. Obdie Verbindung verschlüsselt wird, ist nicht bekannt. Von Bedeutung ist viel mehrdie Manipulation durch ein Schadprogramm. Es kann die ID und den Betrag än-dern, wobei letzteres mit einer großen Gefahr der Erkennung durch den Zahlendenverbunden ist. Eine Änderung der ID kann aber – trotz Kontrolle durch den Zahlen-den während der Bestätigung – in vielen Fällen unerkannt bleiben, da die ID nichtsprechend sein muss. In Abbildung 4.9 ist dieser Angreif beispielhaft dargestellt.




Der Schutz durch eine Signatur hilft begrenzt. Ein Schadprogramm auf dem Smart-phone des Geldempfängers kann das Geheimnis der Signatur theoretisch auslesenund eine gültige Signatur erzeugen. Dieser Schritt bietet lediglich Schutz vor einemSchadprogramm auf dem Smartphone des Zahlenden. Bei einer nicht erkannten Ma-nipulation kann nur der Zahlende durch Prüfung der ID eingreifen und den Vorganggegebenenfalls abbrechen.

Alice (Geldempfänger) Bob (Zahlender)

Eingabe: 10 EuroEmpfänger: Alice

Mallory (Angreifer)

Übertragen:10 Euro an Mallory

Abbildung 4.9.: Gemäß A2 kann ein Schadprogramm auf dem Smartphone des Gel-dempfängers die Transaktionsdaten vor der Übertragung manipu-lieren (eigene Darstellung).

Beginnend mit der Anzeige des Betrags und des Geldempfängers bis zur Ankunftaller Daten am Server bietet sich dem Angreifer die zweite Möglichkeit für einenAngriff auf das Peer-to-Peer Bezahlsystem. Es ist anzunehmen, dass die ID des Gel-dempfängers, der Betrag und die ID des Zahlenden mit Hilfe der PIN des Zahlendengesichert werden. Die eigentliche Übertragung auf den Kommunikationskanal erfolgt,wie bereits erwähnt, über eine gesicherte Verbindung. Damit bleibt dem Angreifernur die Manipulation der Daten durch ein Schadprogramm auf dem Smartphone desZahlenden. Dieser muss die PIN bei der Eingabe mitlesen und den für den Benutzersichtbaren Vorgang steuern. Mit Hilfe der PIN kann er dann einen eigenen Zahlungs-auftrag erstellen, welcher die ID des Zahlenden und einen beliebigen Betrag sowieGeldempfänger enthält.

PayPal sichert kritische Punkte während der kompletten Transaktion aktiv ab. Diesbetrifft insbesondere die Übertragung über den Kanal. Zusätzlich verlässt es sich aufdie Sicherheit des Betriebssystems. Sowohl ein Geheimnis zum Schutz vor Datenma-nipulation während der Übertragung zwischen Geldempfänger und Zahlenden, alsauch die Eingabe der PIN werden durch das Betriebssystem geschützt. Google selbstgibt an, dass dieser Schutz durch Systemlücken, welche Root-Rechte ermöglichen,umgangen werden kann. Ein Bezahlvorgang mit PayPals Peer-to-Peer Variante istfolgerichtig zumindest theoretisch angreifbar.



4.5. Google wallet

Ein Konto bei PayPal lässt sich für einen Angreifer ohne technischen Aufwand mit-tels Social Engineering kompromittieren. Ein Phishingangriff, welcher die Zugangs-daten für das Konto abfragt, genügt bereits, um eine Überweisung durchzuführen.Ein direkter Angriff auf das mobile Bezahlsystem und insbesondere auf die P2PVariante ist nicht nötig.

Ein Physikalischer Zugriff auf das Smartphone ist auch bei angemeldetem Benutzer-konto nur geringfügig gefährlich. Ohne PIN können nur bestehende Kontoauszügeabgerufen, jedoch keine Überweisungen getätigt werden.

4.4.5. Fazit

Wie eKaayCash ist auch das Verfahren von PayPal gegenüber Angriff A2 verwund-bar. Der Zahlende kann dies durch eine Prüfung der Überweisung vor der Bestä-tigung verhindern. Im Gegensatz zu eKaayCash ist aber auch A1 möglich. DurchAbhören der PIN Eingabe und der Anmeldedaten erhält ein Angreifer die notwen-digen Informationen zur Erzeugung eigener, gültiger Überweisungen. Aufgrund desPIN Schutzes sind A3, A4 und A5 nicht möglich. A7 bietet für einen Angreifer keineVorteile. Allerdings kann mittels A6 leicht ein Konto übernommen werden.

4.5. Google wallet


Die Firmen MasterCard und Visa haben unabhängig voneinander auf dem ISO[2000a] Standard basierte Kreditkarten entwickelt, die einen kontaktlosen Bezahl-vorgang erlauben. Bei MasterCard handelt es sich um das PayPass System (vgl.MasterCard [2012]), während Visa den Standard in payWave umsetzt (vgl. VISA[2012]). Die Karten sind vollkommen kompatibel zu den Spezifikationen für Zah-lungskarten von Europay, MasterCard und Visa (EMV). Beide Unternehmen möch-ten eine Vereinfachung des Bezahlvorgang erreichen. Mittels einer kontaktlosen, aufRadio-Frequency Identification basierten Technologie soll das unnötige Einschiebenin ein Lesegerät verhindert werden. Auch müssen Kreditkarten mit dieser Techno-logie nicht mehr aus der Hand gegeben werden. Ein weiterer Vorteil besteht in derUnabhängigkeit von klassischen Kreditkarten. Der RFID-Chip kann theoretisch inein beliebiges Trägerelement eingebaut werden (vgl. VISA [2012], MasterCard [2012]und ISO [2000a]).

Die Trennung von klassischer Kreditkarte und eigentlichem Chip hat Google in sei-nem mobilen Bezahlsystem für Smartphones – Google wallet – erreicht. Google wallet




speichert die für eine Transaktion nötigen Kreditkarten-Daten auf dem Smartphoneund ist sowohl mit MasterCard PayPass als auch mit Visa payWave kompatibel. Dienotwendigen Kreditkarten-Daten können von einer kompatiblen Kreditkarte direkteingelesen werden. Alternativ bietet Google auch den Kauf einer virtuellen PrepaidCard an, mit welcher die Nutzung beliebiger Kreditkarten erlaubt wird (vgl. Google[2011]).

Google wallet unterstützt keine Peer-to-Peer Überweisungen zwischen einzelnen Cli-ents. Es sind ausschließlich Transaktionen zu Point of Sale Terminals vorgesehenund möglich (vgl. Google [2011]). In Abbildung 4.10 ist ein MasterCard paypassTerminal dargestellt. Es widerspricht zwar den Auswahlkriterien in Abschnitt 4.1.1,dass keine P2P Transaktionen möglich sind, allerdings demonstriert Google walletdie Speicherung klassischer Kreditkartendaten auf einem mobilen Endgerät. Ausdiesem Grund wurde es in die Untersuchung mit aufgenommen.

Abbildung 4.10.: Ein Nexus S 4G mit aktiver Google wallet App. Das Konto istmit einer Citi MasterCard aufgeladen. Daneben ein MasterCardpaypass Terminal, welches mit Google wallet genutzt werden kann(Quelle: Google [2011]).

Ein Bezahlvorgang unterscheidet sich nur in der Eingabe der PIN von Überweisungenmit Kreditkarten, welche NFC unterstützen (vgl. Google [2011] und EMVCo [2008]).Er läuft für den Kunden folgendermaßen ab.

1. In der Standardeinstellung muss vor jeder Transaktion die App mittels derPIN freigeschaltet werden. Dieses Verhalten lässt sich dahingehend ändern,dass die PIN nur noch beim ersten Start der App notwendig ist.



4.5. Google wallet

2. Der Benutzer hat anschließend Zugriff auf Informationen über vergangeneTransaktionen, Gutscheine und weitere Funktionen. Außerdem wird die NFCAntenne für eine einzige Überweisung aktiviert.

3. Wie eine normale Kreditkarte mit NFC muss das Smartphone jetzt an dasTerminal gehalten werden.

4. Das Smartphone überträgt via NFC die gespeicherten Kreditkarten Informa-tionen an das Terminal.

5. Der Bezahlvorgang wird im Hintergrund abgeschlossen. Sowohl der Kunde alsauch der Händler erhalten eine Bestätigung.


Für eine gültige Überweisung sind nur wenige Informationen einer Kreditkarte not-wendig. In der Regel genügen die Kreditkartennummer und die Kreditkartenprüf-nummer. Gegebenenfalls wird auch das Ablaufdatum der Kreditkarte abgefragt. Nurin wenigen Fällen ist eine PIN für den Abschluss der Transaktion notwendig. Beivirtuellen Einkäufen im Internet entfällt sie völlig. Aus diesem Grund ist es um sowichtiger, dass die kritischen Informationen auf einem Smartphone gesichert werdenohne dass ein Angriff möglich ist. Google wallet nutzt zu diesem Zweck ein speziali-siertes System – das sogenannte Secure Element (vgl. Google [2011] und Abschnitt2.4). Mobey Forum Mobile Financial Services Ltd [2010] unterscheidet drei Artenvon SE. Es gibt entfernbare SE (z. B. Aufkleber), eingebettete SE, sowie SE, welcheKombinationen aus Software und Hardware sind. Google wallet verwendet SE derzweiten Kategorie. Der Hardwarechip – also das Secure Element – kann nur vonautorisierten Applikationen angesprochen werden und besitzt einen eigenständigenund gesicherten Speicher, der unabhängig vom restlichen System ist (vgl. Google[2011] und Mobey Forum Mobile Financial Services Ltd [2010]).

Die Kommunikation zwischen Terminal und Kreditkarte, bzw. Smartphone mit Goo-gle wallet, findet kontaktlos über NFC statt. Der EMV Standard, auf dem Kredit-karten basieren, sieht keine gesicherte Verbindung vor. Die Transaktion wird jedochdurch ein Geheimnis auf der Karte geschützt. Es dient zur Signierung und damit zurBestätigung der Überweisung und wird jeweils dynamisch für eine einzelne Trans-aktion berechnet (vgl. EMVCo [2008]).

Near Field Communication kann in drei verschiedenen Modi ausgeführt werden (vgl.Abschnitt 2.2). Es kann als Terminal agieren. In diesem Modus werden RFID-Tagsausgelesen. Zwischen zwei aktiven Geräten ist zudem ein Peer-to-Peer Modus mög-lich, welcher nach einem Master-Slave-Prinzip funktioniert. Beim dritten Modus –




der von Google wallet genutzt wird – verhält sich das NFC-fähige Endgerät passiv.In diesem sogenannten Card Emulation Mode wird das Verhalten einer NFC-fähigenKarte simuliert. Da Google wallet die gleichen Daten wie eine echte Kreditkarte be-sitzt, kann es ein POS Terminal nicht von einer reellen Karte unterscheiden. DieFunktionalität und Kompatibilität einer echten kontaktlosen Kreditkarte mit NFCist auf diese Weise sichergestellt. Aus diesem Grund müssen Terminals von Master-Card und Visa für Google wallet nicht extra angepasst werden (vgl. Google [2011]).

Google wallet baut während einer Transaktion keine eigene Kommunikationsver-bindung auf. Das Terminal verwaltet die Datenübertragung und übernimmt derenAbsicherung gegen unbefugten Zugriff (vgl. EMVCo [2008]).


Zum Zeitpunkt der Entstehung dieser Arbeit ist Google wallet nur für die Smart-phones Nexus S 4G und Galaxy Nexus verfügbar. Das Nexus S 4G ist eine Variantedes Nexus S mit integriertem Secure Element, während das Galaxy Nexus direktüber ein SE verfügt. Dies schränkt die Verbreitung von Google wallet zunächst ein(vgl. Google [2011]). Nach Kincaid [2011] ist aus diesem Grund die Verwendung vonRFID-Tags in Form eines Aufklebers für beliebige Smartphones als Übergangslösunggeplant. Ein Aufkleber steht dabei für eine Kreditkarte. Die Absicherung über diePIN entfällt (ebd.).

Wie PayPal kann auch Google auf eine bestehende Infrastruktur und Marktverbrei-tung setzen. Visa und MasterCard sind verantwortlich für die Verbreitung der POSTerminals. Google wallet selbst ist als eine offene Plattform entwickelt worden undermöglicht die Einbindung weiterer Dienstanbieter. Verschiedene Gutscheinanbieterstehen bereits in Partnerschaft mit Google. Ebenso integriert sich Google wallet ineine Reihe weiterer Dienste von Google, z. B. Google Places. Die Applikation ver-waltet somit nicht nur Kreditkarten und die dazugehörigen Abrechnungen, sondernermöglicht auch das Auffinden von unterstützten Geschäften und die Anzeige vonSonderangeboten (vgl. Google [2011]). Gegenüber anderen Anbietern weist Googleden Nachteil eines geringeren Vertrauens im Bereich finanzieller Anwendungen auf(vgl. Patel [2011]).


In der folgenden Sicherheitsanalyse werden nur Komponenten betrachtet, die Googlewallet direkt betreffen. Eine allgemeine Untersuchung von MasterCard PayPass oderVisa payWave übersteigt den Umfang und das Ziel dieser Arbeit. Die Untersuchung



4.5. Google wallet

wird das Point of Sale Terminal im Sinne einer Gegenstelle wie einem Zahlungsserverbetrachten.

Während der unverschlüsselten Übertragung zwischen Smartphone und Terminalwerden eine Reihe von Kreditkarten- und Transaktionsdaten ausgetauscht. Das Ab-hören dieser Daten ist zwar mit einer Sonde in der Nähe des Terminals möglich,allerdings sind diese Daten nicht ausreichend um eine gültige Transaktion zu erzeu-gen. Ohne das in Abschnitt 4.5.2 beschriebene Geheimnis kann die Transaktion nichtsigniert werden. Das Abhören der NFC Schnittstelle bietet somit für den Angreifernur einen geringen Wert.

Um eine unerwünschte Transaktion durchführen zu können, muss ein Schadpro-gramm ein Terminal auf dem Smartphone simulieren. Dieses müsste zudem vomFinanzinstitut akzeptiert werden. Entsprechend ist ein aktiver Angriff durch einSchadprogramm nicht möglich.

Obwohl Google wallet weitestgehend wie eine echte Kreditkarte funktioniert, bie-tet es einen zusätzlichen Schutz in Form der PIN Abfrage vor jedem Geldtransfer.Klassische Kreditkarten können in verschiedenen Szenarien ohne Bestätigung miteiner PIN genutzt werden. Dies ist bei Google wallet nicht möglich. Ein Angreifermit physikalischem Zugriff kann die NFC Übertragung mit Google wallet ohne dasWissen um die PIN nicht aktivieren. Eine geringfügig größere Gefahr besteht, wenndie Einstellung für die PIN-Abfrage geändert wird. In diesem Fall ist die PIN nurnoch für die Aktivierung der Applikation nötig. Sobald dies geschehen ist, könnenbeliebig viele Transaktionen durchgeführt werden.

Die Sicherheit der PIN ist für den Betrieb von Google wallet essentiell. Eine Unter-suchung von Rubin [2012] zeigt, dass ein Angreifer mit ausreichendem Zugriff diePIN trotzdem auslesen kann. Die PIN wird nicht auf dem Secure Element gespei-chert, sondern in einer zu Google wallet gehörenden lokalen Datenbank auf demSmartphone. Die PIN findet sich darin als Hash mit dem dazugehörendem Salt. EinSchadprogramm oder ein fremder Nutzer mit ausreichend Zeit kann den Hash undden Salt auslesen und mittels Brute Force die dazugehörige in das Secure Elementverschoben wird (ebd.).

Eine frühere Untersuchung von Viaforensics [2011] stellt die tatsächliche Nutzungdes Secure Element infrage. Innerhalb der bereits erwähnten Datenbank konntenverschiedene Kreditkarteninformationen aufgefunden werden. Auch wenn diese Da-ten nicht für die Herstellung einer gefälschten Kreditkarte nutzbar sind, bieten sietrotzdem ausreichend Informationen für die Durchführung einer Card not presenttransaction (CNP). Eine CNP ist eine Geldüberweisung in welche die physikalischeKreditkarte nicht involviert ist, sondern nur eine Reihe von Informationen dersel-bigen. Diese Daten können wiederum von einem reellen Angreifer oder durch ein




Schadprogramm ausgelesen werden. Listing 4.1 zeigt einen Ausschnitt von Informa-tionen, die in der Datenbank gefunden werden können (ebd.).

1 MasterCard-xxx-9999"2 Andrew HoogP3 99,999.994 2,222.225 9999

Listing 4.1: Informationen aus der Datenbank von Google wallet. Von oben nachunten: Bezeichner der Karte, Name des Besitzer, Kreditlimit, aktuellesGuthaben und die letzten vier Ziffern der Kartennummer (Quelle:Viaforensics [2011]; im Auszug).

4.5.5. Fazit

Der Umgang mit kritischen Informationen in Google wallet ermöglicht die AngriffeA1 und A5. Während einer Transaktion können weitere Daten abgehört werden,entsprechend ist auch A7 möglich. Da eine Überweisung nur mittels POS Terminaldurchgeführt werden kann, ist A2 nicht von Bedeutung. Dasselbe gilt für A3 undA4, da nur eine Kommunikation mit dem Terminal stattfindet. Social Engineeringgemäß A6 ist für Google wallet nicht möglich, da keine Anmeldedaten existieren.Zwar kann die PIN abgefragt werden, diese ist ohne das eigentliche Smartphonejedoch ohne Nutzen.

4.6. Bitcoins


Elektronische Geldsysteme, welche dezentral ohne Bank als kontrollierende drittePartei arbeiten, müssen sich mit der Problematik des mehrfachen Ausgebens vonGeldeinheiten auseinandersetzen. Nakamoto [2009] hat mit Bitcoin einen Peer-to-Peer basierten Lösungsansatz vorgestellt. An die Stelle einer Kontrollinstanz tritt einNetzwerk, welches Aufzeichnungen über jede Transaktion speichert. Diese Aufzeich-nungen werden in Form eines Hash in eine fortlaufende Kette von bereits geprüftenTransaktionen eingebunden. Eine Überweisung kann nur geändert werden, wenndie komplette Kette manipuliert wird. Diese Kette wird des Weiteren dadurch ge-schützt, dass das Netzwerk nur die längste Kette akzeptiert. Die längste Kette wirdper Definition durch die Gruppe mit der größten Rechenleistung generiert. Naka-moto [2009] geht davon aus, dass die größte Gruppe nie aus Angreifern bestehenkann, da andernfalls ein Großteil des Netzwerks korrumpiert sein muss. Dies folgt



4.6. Bitcoins

der kryptologischen Idee des Web of Trust (WOT). Das Einbetten einer Transaktionin die Kette ist aufgrund der verwendeten Einwegfunktionen nicht umkehrbar. Da-mit ist auch eine Rückbuchung nicht möglich. Geldeinheiten – sogenannte Bitcoins –werden durch Berechnung eines initialen Hash und damit durch eine erste Transak-tion erzeugt. Der Aufwand für die Erzeugung steigt in regelmäßigem Abstand. DieZahl an möglichen Bitcoins ist limitiert. Zusätzliche Einnahmen sind durch geringeGebühren möglich. Ein Nutzer erhält die Gebühr für die Bearbeitung einer Trans-aktion. Teilnehmer im Netzwerk werden über eine Bitcoin Adresse – eine kodierteZeichenkette – referenziert (vgl. Nakamoto [2009] und Bitcoin Project [2012]).

Für das Bitcoin Netzwerk gibt es eine Reihe von Clientprogrammen für verschiede-ne Betriebssysteme und Plattformen. Für Android basierte Smartphones stehen eineReihe von Apps zur Verfügung. Die vorliegende Arbeit untersucht Bitcoin Android(vgl. Armstrong [2012]) und Bitcoin Wallet (vgl. Schildbach [2012]), welche jeweilsneben der reinen Funktionalität als Bitcoin Client alle in Abschnitt 4.1 beschriebe-nen Kriterien für ein mobiles Bezahlsystem mit Peer-to-Peer Funktion erfüllen. Siewerden unabhängig voneinander entwickelt und stehen jeweils als Quellcode für dieUntersuchung zur Verfügung.

Der folgende Ablauf trifft auf beide Apps zu. In Abbildung 4.11 wird er visuelldargestellt.

1. Der Geldempfänger teilt dem Zahlenden seine Bitcoin Adresse mit. Optionalkann er den gewünschten Betrag angeben.

2. Der Zahlende gibt nach Empfang der Bitcoin Adresse den Betrag ein undschließt dadurch die Transaktion ab.

3. Die Transaktion wird vom Client des Zahlenden dem Bitcoin Netzwerk mitge-teilt.

4. Das Netzwerk verifiziert die Transaktion. Gleichzeitig informiert sich der Cli-ent des Geldempfängers über neue Transaktionen und erhält auf diesem WegInformationen über den empfangenen Betrag.


Benutzer innerhalb des Bitcoin Netzwerks werden anhand einer Bitcoin Adresseidentifiziert. Diese Adresse dient zum Empfangen und Senden von Bitcoins. Sie wirdin der sogenannten Wallet zusammen mit den zur Adresse gehörenden Schlüsselngespeichert. Ein Benutzer, und somit auch dessen Wallet, kann beliebig viele BitcoinAdressen besitzen. Der Verlust oder Diebstahl der Wallet führt zum Verlust desgesamten Guthabens. Bitcoin Adressen sind in ihrer Form vollkommen anonym und





3. Bitcoin Adresse übertragen (QR Code, NFC, Bluetooth...)

5. AbgeschlosseneTransaktion

6a. Verifikation durch andere Clients

1. Bitcoin Adressesenden, optional Betrag

2. Empfang aktivieren

4. Bestätigen,optional Betrag und Zweck

6b. Mitteilung überEmpfang

Abbildung 4.11.: Ablauf einer mobilen Überweisung im Bitcoin-Netzwerk (eigeneDarstellung).

lassen keine Rückschlüsse auf die wahre Identität des Benutzers zu (vgl. Bitcoin.itWiki [2012]).

Beide in dieser Arbeit vorgestellten Apps basieren auf BitCoinJ, einer Implementie-rung von Bitcoin in Java. BitCoinJ verzichtet auf die Verwendung der komplettenKette von verifizierten Transaktionen, sondern nutzt eine vereinfachte Variante, dievon Nakamoto [2009] zusammen mit der ausführlichen Methode vorgestellt wurde.Dies verringert die nötige Datenmenge für den Betrieb von Bitcoin und eignet sichdamit besonders für mobile Systeme. BitCoinJ bietet Klassen für die Wallet undden Umgang mit Transaktionen. Die ermöglicht den Entwicklern durch reine Imple-mentierung einer Programmoberfläche eine komplette Anwendung für das BitcoinNetzwerk zu entwickeln (vgl. Hearn u. a. [2012]).

Beide Applikationen verbreiten die Bitcoin Adresse standardmäßig durch einen QRCode, welcher zusätzlich den gewünschten Betrag enthalten kann. Bitcoin Walletbietet zudem die native Unterstützung von NFC. Unabhängig davon nutzen beideApps aber auch die Möglichkeiten des Betriebssystems. Unter Android können sichProgramme für die Behandlung von bestimmten Dateiformaten anmelden. DieseProgramme werden bei Aufruf eines entsprechenden Formats automatisch gestar-tet oder im Fall von mehreren Programmen dem Benutzer zur Auswahl angeboten.Beide Apps bieten die Verteilung der Bitcoin Adresse als Text an. Abhängig von



4.6. Bitcoins

den installierten Applikationen und Technik des Smartphone kann die Adresse viaE-Mail, Bluetooth, Kurzmitteilung und beliebigen anderen Kommunikationsplatt-formen übertragen werden (vgl. Armstrong [2012] und Schildbach [2012]).


Bitcoin ist eine komplett virtuelle Währung und besitzt ursprünglich keinen reellenGegenwert. Aufgrund der steigenden Bekanntheit, den geringen Transaktionsgebüh-ren und der möglichen Anonymität akzeptieren verschiedene Dienstanbieter Bitcoinsals Zahlungsmittel. Dazu gehören sowohl Dienste im Internet als auch Händler mitmateriellen Artikeln und Dienstleistern. Auf dieser Basis ist ein Tauschhandel gegenreelle Währungen entstanden, der ähnlich der Börse Kursschwankungen unterliegt(vgl. Bitcoin.it Wiki [2012]).


Die folgende Analyse untersucht nicht die Sicherheit von Bitcoin. Es werden aus-schließlich Angriffe auf die vorgestellten Android Apps durchgeführt. Eine Untersu-chung von Bitcoin selbst entspricht der in Abschnitt 4.2 ausgeschlossenen Analyseder Infrastruktur und ist somit nicht Teil dieser Arbeit.

In Abschnitt 4.6.2 wurde bereits darauf hingewiesen, dass beide vorgestellten Appsauf Basis von BitCoinJ entwickelt wurden. Die folgenden Untersuchungen betreffendarum beide Programme gleichermaßen.

Unabhängig von der Sicherheit der eigentlichen Transaktion stellt die Sicherheit derWallet eine kritische Komponente im Bitcoin Netzwerk dar. Sowohl Armstrong [2012]als auch Schildbach [2012] empfehlen deswegen nur geringe Beträge auf der Walletdes Smartphones zu hinterlegen. Einerseits besteht die Gefahr, dass das mobile End-gerät verloren geht. Anderseits steigt für Angreifer die Attraktivität aufgrund desmöglichen finanziellen Gewinns durch den Besitz von Bitcoins. Ein Schadprogrammkann die Wallet entsprechend kopieren und das Original löschen. Die Sicherheithängt in diesem Fall von einer Verschlüsselung der Wallet mit einem externem Ge-heimnis – beispielsweise einer PIN – und den Mechanismen des Betriebssystems ab.BitCoinJ nutzt nur letzteres und speichert die Wallet unverschlüsselt im internenSpeicher des Smartphones.

Ähnliche Möglichkeiten hat auch ein Angreifer mit physikalischem Zugriff auf dasHandy. Unter Nutzung von entsprechenden Rechten kann er die Wallet manuellauslesen und entfernen. Des Weiteren schützt keine der beiden Apps die Program-moberfläche und die möglichen Aktionen. Ein Angreifer kann aus diesem Grund




Beträge durch eine einfache Transaktion stehlen. Durch die Unumkehrbarkeit al-ler Transaktionen im Bitcoin Netzwerk ist dieser Diebstahl nicht mehr rückgängigzu machen. Die Oberfläche und damit auch das Versenden von Beträgen könnteunabhängig von BitCoinJ durch Abfrage eines Geheimnisses geschützt werden.

Nativ sehen beide Apps zur Übertragung der Bitcoin Adresse nur QR Codes oder, imFall von Bitcoin Wallet, zusätzlich NFC vor. Durch die beschriebene Verwendung derTextversendung über weitere, installierte Programme steigt jedoch die Gefahr einesMan-in-the-Middle. Verschiedene Kommunikationswege wie Bluetooth sind angreif-bar und erlauben die Manipulation der übertragenen Daten (vgl. Mutchukota u. a.[2011]). Ein Schadprogramm kann sich in Android auch als Empfänger für Texte re-gistrieren und durch den Namen eine Applikation zum Versenden von Bitcoin Adres-sen vortäuschen. Die Adresse wird dann gegen die eines Angreifers ausgetauscht undüber vorhandene Kommunikationsmittel an den Zahlenden übergeben. Da die Bit-coin Adresse nicht sprechend ist, ist die Gefahr eines unerkannten Austauschs hoch.Da beide Apps kompatibel mit bestehenden Bitcoin Clients sein müssen, ist eineVerschlüsselung der Adresse nur bedingt möglich. Dasselbe gilt für eine Signatur.

Das Bitcoin Netzwerk sieht zwar keinerlei Anmeldemechanismen vor, allerdings gibtes eine Reihe von Diensten, welche die Weitergabe der Wallet voraussetzen. Dabeihandelt es sich beispielsweise um die Onlinespeicherung der Wallet (vgl. BitcoinProject [2012] und Bitcoin.it Wiki [2012]). Unter Anwendung von Social Enginee-ring können die Anmeldedaten zu diesen Diensten ermittelt und die Wallet gestohlenwerden. Allerdings ist dies mit den vorgestellten Apps nicht möglich, da sie die Wal-let im internen Speicher des Smartphones speichern. Dieser ist für einen normalenAnwender nicht erreichbar (vgl. Google [2012d]).

In vorherigen Abschnitten wurde die mögliche Anonymität als ein Vorteil von Bit-coin dargestellt. Eine Bitcoin Adresse basiert nicht auf reellen Daten und jeder Be-nutzer kann sich eine beliebige Anzahl von Adressen erzeugen. Dies trifft auch zuwenn kein Kontakt zu personenbezogenen Informationen stattfindet. Reid u. Har-rigan [2011] zeigen, dass durch die Veröffentlichung der Bitcoin Adresse und derenVerwendung zum Bezahlen eine Verknüpfung zwischen einer Person und all ihrenBitcoin Adressen möglich ist. Die Anonymität des Netzwerks hebt sich somit durchdessen Nutzung auf (ebd.).

In Abbildung 4.12 sind Benutzer als Knoten und Transaktionen als Kanten darge-stellt. Es ist erkennbar, dass ein zentraler Knoten eine große Anzahl an Überwei-sungen erhalten hat. Er wurde als die Webseite Wikileaks identifziert (vgl. Reid u.Harrigan [2011]).



4.7. „A 2D Barcode-Based Mobile Payment System“

Wikileaks

Abbildung 4.12.: Grafische Darstellung eines Ausschnitts des Bitcoin Netzwerksrund um Wikileaks (Quelle: Reid u. Harrigan [2011]; [Hervorhe-bung durch Verfasser]).

4.6.5. Fazit

Sowohl eine Transaktion als auch die Wallet selbst sind vor den Angriffen A2, A4und A5 ungeschützt. Keine Bedeutung haben A1, A3 und A7, da übertragene undgespeicherte Daten ohne Gefahr für das Verfahren gelesen werden können. Unterder Voraussetzung, dass der normale Anwender keinen Zugriff auf die Wallet erhält,sind beide Verfahren vor A6 sicher. Als zusätzlicher Angriff kommt die Offenlegungder reellen Identität der Anwender hinzu. Applikationen für Bitcoin sind somit zwargegen passive Angreifer geschützt, allerdings sehr anfällig für aktive Manipulation.



Gao u. a. [2009] haben ein mobiles Bezahlsystem unter Verwendung von 2D Barcodesentwickelt. Es ähnelt eKaayCash und ist für die Bezahlung von Produkten in Ge-schäften gedacht. Das Verfahren wurde im Zuge der Erforschung von 2D Barcodes inkommerziellen System entwickelt. Obwohl ein funktionierender Prototyp umgesetztwurde, ist die Arbeit rein theoretischer Natur und dient als Untersuchungsobjekt




für mögliche Anwendungen von 2D Barcodes. Das Verfahren unterstützt keine Peer-to-Peer Transaktionen (ebd.). Aufgrund der Ähnlichkeit mit eKaayCash ist abereine Implementierung möglich. Dazu wird eine Webseite benötigt, welche wie beieKaayCash aus Eingabedaten dynamisch einen 2D Barcode erzeugt und anzeigt.

Die Verwendung von 2D Barcodes als grundlegende Technik wird mit der vereinfach-ten Anwendung des Verfahrens für Händler und Kunden begründet. Ein 2D Barcodekönne alle notwendigen Daten zur Identifizierung eines Produktes enthalten und er-laube zusätzlich erste Informationen, welche dem Kunden angezeigt werden könnten(vgl. [Gao u. a. 2009, Seite 322]). Diese Begründung deckt sich mit der Verwendungvon 2D Barcodes in eKaay und damit auch in eKaayCash.

Für die Anwender – Händler und Kunde – stellt sich der Ablauf des Verfahrensfolgendermaßen dar: es wird davon ausgegangen, dass sich der Kunde bereits inder App angemeldet hat und vom Händler ein 2D Barcode für das Produkt erstelltwurde.

1. Der Kunde fotografiert den 2D Barcode eines Produktes ab. Dieser Barcodeenthält einen Verweis auf die Produktseite des Händler im Internet.

2. Die Produktseite wird vom Kunden aufgerufen.

3. Der Benutzer erzeugt eine Kaufanfrage für das Produkt und sendet diese anden Händlerserver.

4. Der Server antwortet mit einer Rechnung.

5. Die Rechnung wird vom Handy des Kunden in Form einer Zahlungsanfrage anden Zahlungsserver weitergeleitet.

6. Der Zahlungsserver führt die Transaktion durch und sendet eine Bestätigungan den Kunden und an den Händler.

Der Ablauf ist in Abbildung 4.13 graphisch dargestellt.


Das Verfahren verschlüsselt und signiert den Datenverkehr zwischen den einzelnenParteien – mobiler Endnutzer, Server des Händlers und Zahlungsserver – mittelsasynchroner Verschlüsselung, die auf auf Elliptic Curve Cryptography (ECC) basiert.Alle Schlüssel, welche für die Verschlüsselung der Datenübertragung notwendig sind,werden auf dem Handy des Kunden mit dem Advanced Encryption Standard (AES)geschützt und die Integrität wird mittels Keyed-Hash Message Authentication Code




Kunde


Händlerserver

Zahlungsserver

2. Einlesen

1. Anmeldung

Produktcode

3. Kaufanfrage

4. Rechnung

5. Bezahlanfrage

Abbildung 4.13.: Ablauf eines Produktkaufs mit Hilfe des 2D Barcode Verfahren.Nicht enthalten sind die Bestätigungen an Kunden und Händler(eigene Darstellung).

(HMAC) sichergestellt. Die individuelle PIN kommt dabei als Schlüssel zum Einsatz(vgl. Gao u. a. [2009]).

Als Implementierung des 2D Barcodes wird die von der Firma RVSI/Acuity CiMa-trix entwickelte DataMatrix verwendet (vgl. [Gao u. a. 2009, Seite 321]). Sie kommtim mobilen Bezahlsystem an zwei Stellen zum Einsatz. Einerseits stellt sie demKunden alle wichtigen Informationen über das Produkt zur Verfügung, andererseitswerden alle Kommunikationsdaten vor ihrer Übertragung mit Hilfe einer DataMa-trix kodiert (ebenda). Der Einsatz der DataMatrix als Kommunikationskodierungwird in der Arbeit nicht schlüssig begründet. Sie bietet keinen Vorteil gegenüberanderen Kodierungen. Da eine Kodierung jedoch keinen Einfluss auf die eigentlicheSicherheit hat, wird dieses Faktum im weiteren Verlauf ignoriert.

Im Folgenden wird der detaillierte, technische Ablauf erläutert. Er umfasst als erstenSchritt auch die Anmeldung des Kunden beim Zahlungsserver. Dieser Schritt entfälltbei nachfolgenden Transaktionen.

1. Ein registrierter Kunde meldet sich mit seinem Benutzerkonto und der PINbeim Zahlungsserver an. Der Server bestätigt die Anmeldung mit der ID desServerzertifikats, der Session ID und einem öffentlichen Schlüssel für die weitereKommunikation. Er wird vom mobilen Client unter Nutzung des Serverzerti-fikats und des öffentlichen Schlüssel authentifiziert.




2. Der Kunde liest einen 2D Barcode ein. Dieser enthält neben dem bereits er-wähnten Verweis zur Produktseite des Händlers auch allgemeine Informationenüber das Produkt. Der Benutzer ruft die Produktseite auf und erstellt einenKaufanfrage für den Händler. Die Anfrage wird digital signiert und an denHändler übertragen.

3. Der Händlerserver verarbeitet die Kaufanfrage. Er authentifiziert dabei denKunden mittels der Session ID und dem öffentlichen Schlüssel. Die digitaleSignatur wird mittels des geheimen Schlüssels validiert. Der Server antwortetmit einer wiederum digital signierten Rechnung mit einer Transaktions ID anden mobilen Client.

4. Auf Basis der Transaktions ID erzeugt der mobile Client eine Zahlungsanfrage.Sie wird mit dem geheimen Schlüssel des Kunden signiert. Vor der Übertragungwird eine sichere Verbindung zwischen mobilem Client und Zahlungsserveraufgebaut. Nach Erhalt der Zahlungsanfrage überprüft der Server die Datenund verarbeitet die Anfrage. Nach erfolgreichem Abschluss der Transaktionsendet er eine unsignierte Bestätigung an den Kunden und an den Händler.


Da es sich bei der Veröffentlung um eine reine Forschungsarbeit handelt, wird dasVerfahren nicht reell eingesetzt. Dies ist jedoch möglich. Dabei stellt sich die Einbin-dung für den Händler als einfach dar. Dieser muss einen Server mit der notwendigenSoftware zur Verfügung stellen und die Produkte mit dem jeweiligen 2D Barcodekennzeichnen. Für einen Kunden ist die Installation der App notwendig. Der Einkaufund das Bezahlen einzelner Produkte erfolgt durch abfotografieren des Codes undbenötigt nur geringe Interaktion von Seiten des Benutzers. Sowohl für den Händlerals auch für den Kunden ist ein Konto auf dem Zahlungsserver Voraussetzung.


Aufgrund der Verwendung von ECC zur Verschlüsselung und Signierung der übertra-genen Daten, sind die Kommunikationskanäle im Verfahren als sicher zu betrachten.Ein Schadprogramm auf dem Smartphone des Kunden kann hingegen – sofern dieSicherheitsmechanismen des Betriebssystems umgangen sind – eigene Transaktionenabwickeln. Zu diesem Zweck muss es die PIN bei ihrer Eingabe abfangen, um an-schließend Zugriff auf die verschlüsselten sicherheitsrelevanten Daten, wie der privateSchlüssel des Kunden, welche auf dem Handy gespeichert werden, zu bekommen. Un-abhängig von Transaktionen des Kunden kann das Schadprogramm anschließend für




den Zahlungsserver valide Transaktionen durchführen. Das Schadprogramm kann ei-nerseits ferngesteuert Bezahlvorgänge für den Angreifer vornehmen oder anderseitsEinkäufe bei einem vom Angreifer gefälschten Händler durchführen.

Bei längerem Zugriff auf ein Handy mit angemeldetem Benutzerkonto sind reguläreBezahlvorgänge für einen Angreifer theoretisch möglich. Aus der Beschreibung desVerfahrens geht nicht hervor, wann die Eingabe der PIN notwendig ist. Die Gefahrdes physikalischen Zugriffs auf das Endgerät kann durch eine PIN Abfrage bei je-dem Bezahlvorgang, wie auch bei PayPal Mobile Payments, abgewehrt werden (vgl.Abschnitt 4.4.4).

Die Anmeldung beim Zahlungsserver findet mit Hilfe der Kontodaten und der PINstatt. Diese können von einem Angreifer mittels Social Engineering ermittelt werden.Das Wissen um die Anmeldedaten allein ermöglicht jedoch noch nicht die Durchfüh-rung einer Transaktion. Bei der Registrierung für das Verfahren wird unter anderemder private Schlüssel des Kunden auf dessen Handy abgelegt. Ohne diesen Schlüsselkann ein Angreifer keine Transaktion signieren und durchführen.

Das Verfahren wird mit dem Fotografieren des Produkt-Barcodes initiiert. DieserBarcode kann von einem Angreifer physikalisch oder mit Hilfe eines Schadpro-gramms auf dem mobilen Endgerät ausgetauscht werden. Der gefälschte 2D-Codekann sämtliche Informationen des Originals enthalten, verweist aber auf eine ge-fälschte Produktseite. Das Händlerkonto hinter dieser Produktseite muss regulärbeim Zahlungsserver registriert sein. Diese Art von Angriff wird im Normalfall sehrschnell auffallen, da keines der scheinbar bezahlten Produkte tatsächlich gekauftwurde.

4.7.5. Fazit

Die Kommunikation ist sicher in diesem Verfahren und NFC wird in diesem Fall nichtangewandt. Aus diesen Grund sind A3, A4 und A7 nicht möglich. Des Weiteren bie-tet das Verfahren durch die Aufteilung des Geheimnisses in Wissen – Anmeldedatenund PIN – und Besitz – der private Schlüssel auf dem Smartphone – einen gutenSchutz vor A6. Allerdings kann ein Schadprogramm zunächst die PIN auslesen unddann selbst eine Transaktion ausführen. Außerdem ist der Austausch des 2D-Codesvor Beginn einer Transaktion möglich. Ähnliche Angriffe können auch durch physi-kalischen Zugriff ausgeführt werden. Damit ist das Verfahren durch A1, A2 und A5angreifbar.




4.8. „A Wireless Payment System“


In mobilen Endgeräten, welche kein NFC unterstützen, dient in vielen Fällen Blue-tooth als Standard für Kurzstreckenkommunikation. Mutchukota u. a. [2011] habengezeigt, dass Bluetooth durch Man-in-the-Middle angreifbar ist und somit ein siche-rer Kanal nötig wird. In einer Analyse kann eine Verbindung via Bluetooth somit alsein Kommunikationsweg betrachtet werden, welcher durch Lauschangriffe und Mani-pulation bedroht wird. Gleichzeitig ist eine Nutzung für P2P Applikationen möglich.Von Gao u. a. [2006] wird Bluetooth aus diesem Grund für ein mobiles Peer-to-PeerBezahlsystem verwendet, welches eine hohe Kompatibilität zu bestehenden mobilenEndgeräten bietet.

Im Folgenden wird der Ablauf beschrieben. Dieser findet sich auch in Abbildung 4.14.Voraussetzung für den Vorgang ist, dass sich beide Teilnehmer der Transaktion mitHilfe ihrer P2PID – einer individuellen ID im Bezahlsystem – und ihrem Passwortanmelden. Für zukünftige Implementierungen ist zusätzlich eine Verifikation überdie Stimme des Nutzers geplant (vgl. [Gao u. a. 2006, Abschnitt 4]).

1. Im ersten Schritt müssen Zahlender und Geldempfänger ihre Rolle in derTransaktion auswählen. Dies geschieht über die Programmoberfläche.

2. Nach Identifizierung aller erkannten Geldempfänger in Reichweite muss derZahlende den korrekten Empfänger auswählen.

3. Der Zahlende muss die Transaktion im folgenden Schritt durch Eingabe desBetrags abschließen.

4. Das mobile Endgerät sendet die Daten der Transaktion an den Zahlungsserver.Dieser verifiziert sie und führt die eigentliche Geldüberweisung durch. Sowohlder Geldempfänger als auch der Zahlende erhalten eine Bestätigung.


Da Bluetooth im Gegensatz zu NFC unabhängig von der physikalischen Nähe ist,sind zunächst Verbindungen zu beliebigen, aktiven Endgeräten mit Bluetooth mög-lich. Aus diesem Grund bietet das Service Discovery Protocol (SDP) Schnittstellen,um bestimmte Dienste in einer unbekannten Umgebung aufzufinden (vgl. Suchy[2007]). Im vorliegenden Verfahren findet es alle Endgeräte mit installiertem Client,welcher aktiv die P2PID sendet. Diese ID identifiziert die Benutzer des Bezahlsys-tems und wird nur von Geldempfängern verteilt. Gleichzeitig bildet diese ID den





3. P2PID übertragen (Bluetooth)

5. BestätigteZahlungsanfrage(Internet)


Zahlungsserver

1. P2PIDüber Bluetoothsenden

2. Empfang viaBluetooth aktivieren

4. Betrag eingeben

Abbildung 4.14.: Ablauf einer P2P Überweisung mit Hilfe von Bluetooth. Die Be-stätigung wurde entfernt (eigene Darstellung).

sprechenden Namen, welcher dem Zahlenden zusammen mit allen gefundenen Teil-nehmern in Reichweite zur Auswahl aufgelistet wird (vgl. Gao u. a. [2006]).

Das Verfahren arbeitet mit einer symmetrischen Verschlüsselung. Dazu wird im Zu-ge der Registrierung ein individueller Schlüssel generiert. Er wird kodiert auf demEndgerät gespeichert. Für einzelne Sitzungen wird aus diesem Schlüssel ein weite-rer generiert, welcher zum Schutz der kritischen Daten der Transaktion dient. DerSitzungsschlüssel wird dem Server mit Hilfe eines an jede Nachricht angehängtenHeader mitgeteilt. Dieser Header enthält in der ersten Nachricht den Schlüssel undseine Länge. Die Information über den Schlüssel enfällt in den weiteren Nachrichten.Enthalten ist aber immer eine Signatur und die Information, welche Datenfelder inder jeweiligen Nachricht verschlüsselt sind. Die Signatur wird aus den Nutzdatenund dem bei der Registrierung erzeugten Schlüssel berechnet (vgl. Gao u. a. [2006]).Der Aufbau des Header ist in Tabelle 4.2 dargestellt.

Signatur Schlüssel Schlüssellänge verschlüsselte Felder

Tabelle 4.2.: Der Sicherheitsheader für Nachrichten im Verfahren mit Bluetooth. Erwird an die eigentlichen Nutzdaten angehängt (vgl. Gao u. a. [2006];[Übersetzung durch Verfasser]).

Wie im vorherigen Abschnitt bereits erwähnt, soll in zukünftigen Versionen des Ver-fahrens eine Verifikation der Stimme des Nutzers implementiert werden. Aufgrundvon Limitierungen von mobilen Endgeräten zum Zeitpunkt der Veröffentlichung desVerfahrens müsse ein neues, optimiertes Verfahren entwickelt werden (vgl. [Gao u. a.




2006, Seite 4]). Der Vorteil von biometrischen Daten liegt in ihrem hohem Fäl-schungsschutz gegenüber klassischen Passwort-Systemen.

Aus technischer Sicht lässt sich der Ablauf des Bezahlsystems in zwei grundlegen-de Phasen aufteilen. Der erste Abschnitt umfasst die Phase der Veröffentlichungder P2PID via Bluetooth bis zum Punkt an dem der Zahlende die Transaktion mitEingabe des Betrags abschließt. Aus der Arbeit geht nicht hervor, inwiefern dieKommunikation mittels Bluetooth abgesichert ist. Die Verwendung des bekanntenSicherheitsheaders ist jedoch angedacht. Über diesen Kanal werden keine kritischenDaten übermittelt, da er rein zum Austausch der P2PID dient. Die zweite Phase imVerfahren ist die Übermittlung der bestätigten Transaktion an den Server. Nebendem Schutz durch den Sicherheitsheader und die Verschlüsselung mittels symme-trischem Verfahren sollen auch sichere Verbindungen mittels SSL oder TLS zumEinsatz kommen (vgl. [Gao u. a. 2006, Seite 3]).


Als theoretische Arbeit wird dieses Verfahren in der vorliegenden Form außerhalbeines Prototyps nicht eingesetzt. Für Benutzer des Dienstes kann vor allem die Ver-zögerung durch den Verbindungsaufbau von Bluetooth und durch die verschiedenennotwendigen Interaktionen mit der Programmoberfläche störend wirken. Vorteilhaftist die sehr hohe Kompatibilität mit älteren und neueren Handys, welche selbst vonVerfahren auf Basis von Kameras nicht erreicht werden kann. Für diese ist zudemein ausreichend großer und verhältnismäßig hochauflösender Bildschirm nötig, wieer erst in jüngeren Smartphones existiert.


Der Aufteilung des Verfahrens in zwei Phasen, wie in Abschnitt 4.8.2 dargestellt, fol-gend, besteht der erste mögliche Angriff im Austausch der P2PID vor Bestätigungder Transaktion. Dieser Angriff entspricht dem in Abschnitt 4.4.4 beschriebenemSzenario. Ein Schadprogramm auf dem Handy des Geldempfängers oder des Zah-lenden kann die ID vor dem Versenden oder direkt nach dem Empfang gegen dieP2PID des Angreifers austauschen. Dieser Angriff kann bei sprechenden IDs zwarvom Zahlenden durch eine manuelle Kontrolle erkannt werden, die Erzeugung ei-nes neuen Kontos mit einer visuell ähnlichen ID ist aber theoretisch möglich. DerAustausch der ID kann nicht nur durch ein Schadprogramm erfolgen, sondern istmittels Man-in-the-Middle auch während der Bluetooth Verbindung möglich. Wieauch bei PayPal kann die Signierung der ID begrenzten Schutz vor Manipulation




der Daten bieten. Für ein Schadprogramm auf dem Handy des Geldempfängers stelltdies jedoch kein Hindernis dar.

Nach Bestätigung der Transaktion durch den Zahlenden kann ein Schadprogrammdie signierten und verschlüsselten Daten manipulieren, wenn es Zugriff auf denSchlüssel hat. Die Sicherheit hängt also von den Mechanismen des Betriebssystemsab. Die eigentliche Übertragung zum Server erfolgt wie beschrieben mittels sichererVerbindungen zusätzlich zum Schutz durch den Sicherheitsheader. Sofern ein erfolg-reicher Man-in-the-Middle Angriff auf die SSL oder TLS Verschlüsselung durchge-führt wurde, besteht die Gefahr, dass das erste Datenpaket mit dem Schlüssel fürdie Transaktion mitgelesen wird. In diesem Fall kann ein Angreifer die Transakti-onsdaten auslesen. Eine Manipulation ist weiterhin nicht möglich, da die Signaturmit dem Registrierungsschlüssel erzeugt wurde.

Der symmetrische Registrierungsschlüssel ist in der vorliegenden Version die kri-tische Komponente im System. Wenn der mobile Client angemeldet ist, kann beierfolgreichem Diebstahl dieses Schlüssels jede beliebige Transaktion ohne Mitwirkendes Benutzers ausgeführt werden. Gao u. a. [2006] bezieht sich zwar auf eine Kodie-rung des Schlüssels, diese wird jedoch nicht näher erläutert und die Nutzung einesexternen Geheimnisses – beispielsweise eine PIN – ist nicht vorgesehen.

Aufgrund des Verzichts auf eine Bestätigung der Transaktion mittels PIN, erlaubtder physische Zugriff die Durchführung einer Überweisung. Dazu muss der Clientangemeldet sein. Ist dies nicht Fall, hat sowohl ein physischer Angreifer als auch einSchadprogramm keine Möglichkeit eine Transaktion zu erzeugen. Die Anmeldeda-ten können zwar mittels Social Engineering ermittelt werden, jedoch wird dies beiEinführung der Stimmverifizierung erschwert. Der technische Aufwand ist in diesemFall für einen Angreifer deutlich höher.

4.8.5. Fazit

Dieses Verfahren bietet eine Reihe von Sicherheitsmechanismen, welche teilweise an-gegriffen werden können. Zwar ist A7 nicht möglich und A6 kann nach Einführungder Stimmverifizierung als sicher betrachtet werden, dennoch bieten sich sowohl fürSchadprogramme als auch für Man-in-the-Middle Angriffe eine Reihe von Möglich-keiten zur Manipulation und zur Erzeugung eigener Transaktionen. Letzteres istauch für einen physikalischen Angreifer möglich, wenn die App angemeldet ist. Dar-aus folgt das A1, A2, A4 und A5 erfolgreich durchgeführt werden können. MittelsA3 können zudem vollständige Transaktionen mitgelesen werden, dies setzt jedochumfassende Angriffe auf den Kommunikationskanal voraus.




4.9. Entwurf einer Smartphone basierten Geldkarte


Bei den bisher vorgestellten Verfahren handelt es sich um Konto basierte Systeme.Um den Einsatz einer E-Wallet ohne Bindung an ein Konto zu demonstrieren (vgl.Abschnitt 2.4), wird in diesem Abschnitt ein System auf Basis des deutschen girogoVerfahrens vorgestellt (vgl. Deutsche Kreditwirtschaft [2012]). Es handelt sich umein rein theoretisches Verfahren für Smartphones, welches die Funktionalität einerGeldkarte mit NFC und eines POS auf ein Smartphone überträgt und auf diese WeisePeer-to-Peer Bezahlvorgänge erlaubt. Das Verfahren wurde im Zuge dieser Arbeitentworfen und stützt sich auf die Arbeit von Cheng u. a. [2011] und auf Schnitt-stellenspezifikationen für Geldkarten (vgl. Deutsche Kreditwirtschaft [2011]). Diefolgenden Erläuterungen und Abläufe stellen entsprechend keine technische Imple-mentierung vor. Sie beschreiben stattdessen die möglichen Abläufe, mit welchen einP2P System auf Basis der klassischen Geldkarte auf Smartphones umgesetzt werdenkann. Es wird auf explizite Erklärungen zu den Schritten einer Bezahlung mittelsGeldkarte verzichtet, das gilt insbesondere für die eigentliche Kommunikation zwi-schen Terminal und Karte. Die Erklärungen können in den Schnittstellenspezifika-tionen für Geldkarten eingesehen werden (vgl. Deutsche Kreditwirtschaft [2011]).

Die deutsche Geldkarte, welche als girogo weiterentwickelt wurde, ermöglicht bar-geldlose Bezahlvorgänge ohne Kommunikationsverbindung zu einer Bank. Dies wirdauch als Offline Vorgang bezeichnet. Geldbeträge werden direkt auf der Geldkartegespeichert. Bei einem Bezahlvorgang findet keine weitere Authentisierung des Be-nutzers statt und entsprechend ist das Verfahren nur für Kleinstbeträge vorgesehen.Der Geldempfänger – im klassischen Fall ist dies ein Händler mit POS Terminal –erhält das Geld nicht sofort, sondern erst nach dem Abgleich mit der Bank. DerAbgleich ist dabei unabhängig vom Bezahlvorgang und findet im Regelfall zu einemspäteren Zeitpunkt statt (vgl. Deutsche Kreditwirtschaft [2012]).

Der folgende Ablauf beschreibt das Verfahren aus Sicht der Anwender. Beide Benut-zer besitzen ein Smartphone, auf welchem die App mit der Geldkarten-Funktionalitätinstalliert ist. Der Zahlende muss des Weiteren den notwendigen Betrag auf dasHandy geladen haben. Das Aufladen kann, wie bei klassischen Geldkarten, durchdie Bank oder an entsprechenden Automaten erfolgen.

1. Der Geldempfänger startet die Applikation und aktiviert den Empfang einesGeldbetrags.

2. Der Zahlende startet ebenfalls die Applikation und leitet einen Bezahlvorgangdurch Eingabe des Betrags ein.



4.9. Entwurf einer Smartphone basierten Geldkarte

3. Er bestätigt den Zahlvorgang mittels Eingabe seiner PIN. Das Smartphone istjetzt sendebereit.

4. Wie in anderen NFC basierten P2P Verfahren, werden beide Smartphones inKontakt gebracht. Sie führen die eigentliche Geldüberweisung durch.

5. Der Abschluss des Vorgangs wird durch eine Benachrichtigung an beide Be-nutzer signalisiert.


Um die Sicherheit eines auf dem Smartphone gespeicherten Geldbetrags zu gewähr-leisten, setzt das Verfahren auf die Verwendung eines Secure Elements. Die Software-Applikation dient als grafische Oberfläche für den Benutzer und startet das SE.Der eigentliche Bezahlvorgang wird vom SE über die NFC Schnittstelle durchge-führt. Der Betrag befindet sich dabei zu keinem Zeitpunkt innerhalb der Software-Umgebung des Betriebssystem, sondern wird über einen sicheren Kanal direkt in dasSE geladen. Diese Aufteilung von Software, SE und NFC Schnittstelle entspricht demEntwurf von Cheng u. a. [2011]. Der Zugriff auf kritische Operationen wird vom SEnur durch Eingabe der PIN erlaubt. Im Rahmen dieses Entwurfs zählt dazu nur dieInitiierung einer Geldüberweisung auf dem Smartphone des Zahlenden.

Die Implementierung des Verfahrens setzt die Nutzung des Card Emulation Modeund des Read/Write Mode von NFC voraus (vgl. Abschnitt 2.2). Ersteres simu-liert eine klassische Geldkarte mit NFC Schnittstelle, letzteres ein POS Terminal,welches den Geldbetrag empfängt. Aufgrund dieser Entscheidung ist das Verfahrenkompatibel mit bestehenden Geldkarten.

Ein Bezahlvorgang läuft technisch wie folgt ab. Der Ablauf ist in Abbildung 4.15visualisiert.

1. Das Secure Element wird vom jeweiligen Benutzer aktiviert. Von Seiten desZahlenden ist dazu die Eingabe des Betrags und die Bestätigung mit der PINnotwendig. Beides wird vom SE verifiziert.

2. Die Smartphones treten in Kontakt und bauen eine sichere Verbindung auf.

3. Gemäß der Spezifikation einer Geldkarte wird der Geldbetrag übertragen (vgl.Deutsche Kreditwirtschaft [2011]).

4. Beide SE beenden die Kommunikation und zeigen dem jeweiligen Benutzereine Bestätigung über den Erfolg der Transaktion an.





1a. Aktivierung des Geldempfangs

2a. Eingabe Betrag und PIN

App SE

NFC

1b. Aktivierung

5. Bestätigung NFC

SE App

5. Bestätigung

2b. Aktivierung4. Transaktion

3. Prüfung von Betrag und PIN

Abbildung 4.15.: Ablauf einer Transaktion zwischen zwei Smartphones nach demGeldkarten-Prinzip (eigene Darstellung).


Wie in Abschnitt 4.5.3 bereits erläutert, gibt es zum Zeitpunkt der Entstehungdieser Arbeit nur zwei Smartphones mit Secure Element und NFC. Allerdings han-delt es sich um ein rein theoretisches Verfahren, welches erst von den verantwortli-chen Finanzinstituten umgesetzt werden müsste. Entsprechend stellt die mangelndeHardwareunterstützung keine Einschränkung dar. Ein Vorteil dieses Verfahrens istdie Abwärtskompatibilität zum bestehenden Geldkarten System. Aus diesem Grundbesteht schon eine marktwirtschaftliche Basis in Form von teilnehmenden Händlern.Das System bietet somit sowohl einen einfachen P2P Vorgang als auch das klassischebargeldlose Bezahlen mit einer Geldkarte an.


Durch die Auslagerung aller sicherheitsrelevanten Vorgänge auf das SE bietet dasVerfahren eine hohe Sicherheit. Ein Schadprogramm auf dem Smartphone kann aufEbene der Software – d. h. der Applikation – zwar die PIN abhören, allerdings kannmit dieser Information kein Bezahlvorgang durchgeführt werden. Für eine Transak-tion ist immer ein Terminal notwendig.

Ein Angreifer mit physischem Zugriff besitzt hingegen die Möglichkeit ein Terminalzur Verfügung zu stellen, jedoch fehlt ihm das Wissen um die PIN und er kannkeinen Zahlvorgang initiieren. Der Verlust oder Diebstahl des Smartphone solltejedoch vermieden werden. Abhängig vom Finanzinstitut kann dies zum Verlust desGeldbetrags führen.



4.10. Weitere Mobile Payment Lösungen

Da im Geldkarten System keine Authentisierung vorgesehen ist, können mittels So-cial Engineering keine kritischen Informationen abgefragt werden. Die PIN ist, wieschon im Zusammenhang mit Schadprogrammen erklärt, ohne das Smartphone ohneweiteren Nutzen.

Das hier vorgestellte Verfahren sieht die verschlüsselte Kommunikation via NFCmittels einer sicheren Verbindung vor. Eine solche Ende zu Ende Verschlüsselungwurde bereits von Van Damme u. a. [2005] vorgestellt und lässt sich leicht mit NFCumsetzen. Der Kommunikationskanal beider SEs kann also als nicht angreifbar gel-ten. Da keine weitere Kommunikation zu einer externen Gegenstelle stattfindet, sindMITM Angriffe ohne von Bedeutung.

4.9.5. Fazit

Es lässt sich abschließend feststellen, dass das vorgestellte Verfahren eine sichere Im-plementierung für ein bargeldloses Bezahlsystem mit P2P Funktionalität bietet. DieAngriffe A3, A4, A6 und A7 sind nicht möglich bzw. werden durch das System ab-gewehrt. Mittels A1 und A2 kann zwar ein Bezahlvorgang gestartet werden, es fehltjedoch die Gegenstelle, welche den Betrag in Empfang nimmt. Ein physischer Zugriffgemäß A5 bietet ohne die PIN ebenfalls keine Möglichkeit für eine Überweisung.

4.10. Weitere Mobile Payment Lösungen

In diesem Abschnitt werden zwei mobile Bezahlsysteme vorgestellt, die nicht in dieAnalyse aufgenommen wurden. Es wird gezeigt, nach welchen Kriterien der Aus-schluss dieser Verfahren stattgefunden hat.

4.10.1. „Secure Mobile Payment via Trusted Computing“

In der Arbeit von Li u. a. [2008] wird ein mobiles Bezahlsystem auf Basis von Trus-ted Computing vorgestellt. Trusted Computing verfolgt die Idee einer vollständigabgesicherten Umgebung aus Software und Hardware, welche kritische Operatio-nen nur nach Kontrolle der Systemintegrität erlaubt. Dies soll den Einfluss durchFremdzugriffe erkennen und verhindern und auf diese Weise sichere Bezahlvorgängeerlauben. Dies stellt zwar einen interessanten Ansatz dar, allerdings wurde das Ver-fahren aus zwei Gründen nicht untersucht. Zunächst wird es als reines POS Systembeschrieben. Es ermöglicht somit keine Peer-to-Peer Bezahlvorgänge. Des Weiterenkonzentriert sich die Arbeit auf die Nutzung von Trusted Computing. Das eigentli-che Bezahlverfahren wird jedoch nur in groben Zügen beschrieben. Auf dieser Basis




ist zwar eine Analyse von Trusted Computing in mobilen Endgeräten möglich, al-lerdings keine Untersuchung des eigentlichen Bezahlsystems mit Absicherung durchTrusted Computing (ebd.).

4.10.2. ISIS

ISIS ist ein Joint Venture zwischen AT&T, T-Mobile und Verizon Wireless und hatdas Ziel ein mobiles Bezahlsystem zu entwickeln. Es soll ähnlich wie Google walletmit Kreditkarteninformationen auf dem Smartphone funktionieren. Zum Zeitpunktder Entstehung dieser Arbeit ist noch nicht bekannt, ob die Daten auf einem SecureElement gespeichert oder ob andere Mechanismen zum Schutz eingesetzt werden.Das Verfahren wird wie Google wallet voraussichtlich keine P2P Überweisungenermöglichen und dient als reines POS System. Im Gegensatz zu Google wallet wurdeISIS noch nicht veröffentlicht und es existieren keine technischen Informationen zuAbläufen und verwendeten Verfahren. Aus diesem Grund ist eine Untersuchung nichtmöglich (vgl. JVL Ventures, LLC [2012]).

4.11. Zusammenfassung

Dieser Abschnitt bietet mit Abbildung 4.16 eine Zusammenfassung der obigen Ana-lysen. Die Sicherheit wird folgendermaßen bewertet: kann ein bestimmter Angriffohne weitere Bedingung erfolgreich ausgeführt werden wird er mit −− markiert.im Gegensatz dazu steht die Wertung ++, welche einen nicht möglichen Angriffbezeichnet. Die Abstufungen − und + werden vergeben, wenn bestimmte Voraus-setzungen erfüllt sein müssen. Eine Sonderrolle spielt die neutrale Wertung ◦. Siewird vergeben, wenn der jeweilige Angriff ohne Bedeutung für das Verfahren ist. Bei-spielsweise unterstützt nicht jedes Verfahren NFC und entsprechend wird A7 neutralbewertet.

4.12. Diskussion

Auf Basis der untersuchten Verfahren und ermittelten Ergebnissen werden in die-sem Abschnitt Gemeinsamkeiten und Unterschiede diskutiert. Des Weiteren werdenwährend der Analyse die angewandten Methoden bewertet.

Die Analyse hat gezeigt, dass sich die einzelnen Bezahlsysteme anhand der bekanntenAbläufe untersuchen lassen. Die Angreifbarkeit durch bestimmte Ansätze konnte mitgewissen Einschränkungen nachgewiesen oder widerlegt werden. Allerdings bleiben



4.12. Diskussion

eKaayCash

A 2D Barcode-Based Mobile Payment System

A1 A2 A3 A4 A5 A6 A7

+

PayPal Mobile Payments

Google wallet

Bitcoins

A Wireless Payment System

Entwurf einer Smartphone basierten Geldkarte

Name

Legende: leicht angreifbar, angreifbar, neutral, sicher, sehr sicher- - -

+

+ +

++ + + + + + + +-

+- + + + + + + + +- -

- - - - -+ + + +

- - - - - -+ + + + + ++

+ + + + + +- - - - -

-- +

+

- - - -

+/

+ + + + + + +

Abbildung 4.16.: Die Ergebnisse der Sicherheitsanalyse im Überblick (eigeneDarstellung).

einzelne Punkte offen, wenn keine Einsicht in die detaillierte technische Implemen-tierung vorliegt. Dies deckt sich mit den in Abschnitt 4.1 erläuterten Kriterien undVorbedingungen.

Unabhängig von den einzelnen Sicherheitsproblemen ermöglicht die Analyse nur ge-ringe Aussagen zu kombinierten Angriffen. Insbesondere die Konzentration auf einenbestimmten Nutzer kann trotz allgemeiner Sicherheit erfolgreich sein. Dies ergibtsich daraus, dass einzelne Sicherheitsmechanismen ihren Schutz unter bestimmtenAnnahmen einhalten. Dieser Schutz hebt sich dementsprechend auf, wenn diese An-nahmen nicht mehr zutreffen. Ein Beispiel hierfür ist die PIN Abfrage vor einerTransaktion. Zwar verhindert sie einen Angriff durch physischen Zugriff, allerdingsnur wenn der Angreifer kein Wissen über die PIN hat. Wurde das Geheimnis hinge-gen zuvor beispielsweise durch Social Engineering gestohlen, kann die Transaktionausgeführt werden. Dies muss als Restrisiko behandelt werden und bietet Möglich-keiten für weitere Untersuchungen.

Die Analyse zeigt, dass sich die Abläufe der einzelnen Verfahren weitestgehend glei-chen. Dies bestätigen die in Abschnitt 2.4 vorgestellten Prozesse für mobile Bezahl-verfahren. Diese Ähnlichkeiten übertragen sich somit auch auf die Anwendbarkeitvon Angriffen. Technische Unterschiede spielen nur eine untergeordnete Rolle. Diefolgenden Absätze fassen die erhaltenen Erkenntnisse zusammen.

Mobile Bezahlsysteme – unabhängig davon ob sie elektronisch oder mit klassischemBargeld durchgeführt werden – stellen den Besitz der Werteinheit in den Vorder-grund. Bei Bargeld sind die einzelnen Werteinheiten Geldstücke und Scheine. Inelektronischen Systemen stellen Smartphones die Werteinheiten dar. Sie weisen denBenutzer aus und stellen die Verbindung zum tatsächlichen Geld her. Der Besitzeines Smartphones ist also essentiell für den Besitz des Geldes. Gegenüber Bargeld




verfügen elektronische Bezahlsysteme über den Vorteil, dass der eigentliche Betragnicht direkt mit dem Verlust des Smartphones verloren geht. Um dies zu gewähr-leisten muss die Bezahlapp abgesichert sein. Des Weiteren sollte der Zugriff auf dasKonto vom Dienstanbieter gesperrt werden. Die Mehrheit der vorgestellten Verfahrenverhindert Transaktionen durch nicht berechtige Personen nur unzureichend. Diesist gut an Angriff A5 in Abbildung 4.16 zu erkennen. Zukünftige Verfahren solltenaus diesem Grund eine Authentisierung des Benutzers vor der Durchführung einerÜberweisung erzwingen. Hier genügt beispielsweise bereits die Abfrage der PIN.

Eine weitere übergreifende Bedrohung stellen Schadprogramme dar. Sie können so-wohl passiv als auch aktiv kritische Informationen auslesen und manipulieren. DieserGefahr begegnend müssen Bezahlsysteme immer davon ausgehen, dass das Smart-phone, auf dem sie ausgeführt werden, nicht sicher ist. Der Entwurf neuer Systemesollte dies stets beachten. Nur eKaayCash und das theoretische System auf der Ba-sis von Geldkarten bieten eine relative Sicherheit vor Schadprogrammen. Allein dieEinführung von sicheren Elementen in Form von Secure Elements oder externenGeheimnissen – beispielsweise eKaayCard (vgl. Günther [2011]) – kann effektiv vorSchadprogrammen schützen.

NFC hingegen hat sich als sicher erwiesen. Mit Ausnahme von Google wallet über-trägt kein Verfahren mit Hilfe von Nahfunk ungeschützt kritische Daten. Auch nor-male Kommunikationsverbindungen – beispielsweise die Kommunikation mit demServer des Dienstanbieters – sind allgemein nur schwer angreifbar. Daten, welcheüber diese Verbindungen gesendet werden, können leicht mit Hilfe von geteilten Ge-heimnissen abgesichert werden. Im Gegensatz zu Schadprogrammen hat ein Man-in-the-Middle keine Möglichkeit, das Geheimnis auszulesen oder mitzuhören, da esim Normalfall nicht mitübertragen wird.

Wie bei klassischen Onlineüberweisungen bietet das manuelle Überprüfen der Trans-aktion einen hohen Schutz und kann in Kombination mit einem externen Geheimniseine Vielzahl von Angriffen unwirksam machen. Entsprechend sollten beide Me-chanismen in mobilen Peer-to-Peer Bezahlsystemen eingesetzt werden. Dies decktsich auch mit anderen Sicherheitsanalysen von mobilen Systemen (vgl. Günther[2011]).

4.13. Fazit

In Anlehnung an das Fazit aus Abschnitt 3.5 hat die Analyse gezeigt, dass eKaay-Cash ein sicheres mobiles Bezahlverfahren mit Peer-to-Peer Funktionalität umsetzt.Das sichere Framework in Form von eKaay hat nicht nur die einfache Entwicklungdes Verfahrens ermöglicht, sondern auch die Gefahr durch verschiedene Angriffe



4.13. Fazit

minimiert. Dabei hat sich gezeigt, dass die Implementierung von eKaay in eine reel-le Anwendung zu neuen Sicherheitsproblemen speziell für diese Anwendung führenkann. Das Verfahren eKaayCash kann diese Probleme jedoch mit Hilfe von eKaay lö-sen. Dies betrifft insbesondere die Involvierung des Zahlenden in die Bestätigung derTransaktion. Es kann also festgestellt werden, dass eKaayCash ein sicheres mobilesBezahlsystem für Smartphones ist.

Anhand der weiteren Sicherheitsanalyse konnte ebenfalls erfolgreich gezeigt werden,dass mittels konzeptueller Abläufe bereits verschiedene Angriffe erkannt werden kön-nen. Des Weiteren wurde eine große Zahl an Gemeinsamkeiten in unterschiedlichenSystemen aufgedeckt. Daraus lassen sich allgemeine Empfehlungen für neue Bezahl-verfahren und die Verbesserung bestehender Verfahren ableiten.



5. Implementierung von eKaayCash

In diesem Kapitel werden einzelne Abschnitte der Implementierung von eKaayCashverdeutlicht. Es wird auf Probleme und ihre Lösungen eingegangen, aber kein voll-ständiger Einblick in den Quellcode gegeben. Weitere Implementierungsdetails kön-nen dem Anhang A entnommen werden.

5.1. Erzeugung einer Überweisung

Das Programm, welches das Überweisungsformular darstellt und aus den Eingabe-daten eine Überweisung generiert, ist wie folgt aufgebaut:

1. Zunächst prüft es, ob Eingabedaten, wie der Betrag und die ID des Geldemp-fängers, vorhanden sind.

2. Im dem Fall, dass die ID fehlt, wird das Programm abgebrochen, da eineTransaktion ohne gültigen Empfänger nicht erzeugt werden darf.

3. Sind keine Überweisungsdaten vorhanden, wird das Formular angezeigt unddas Programm endet. Wurden hingegen Daten für eine Transaktion eingeben,erstellt das Programm aus diesen Informationen eine neue Überweisung.

4. Dazu wird zunächst eine einzigartige Transaktionsnummer als ID generiert.

5. Die Überweisungsdaten werden anschließend für die Anzeige auf dem Smart-phone aufbereitet.

6. Der Server der Bank speichert die Überweisung für die spätere Durchführungnach der Bestätigung durch die Benutzer.

7. Aus dem für Menschen lesbaren Transaktionstext erzeugt der eKaay Servereine Challenge inklusive QR Code und gegebenenfalls einen NFC Link.

8. Die Challenge wird im Browser des Benutzers angezeigt und das Programmendet.

Der vollständige Ablauf wurde mit Hilfe von Aktivitätsdiagrammen in den Abbil-dungen 5.1 und 5.2 visualisiert.




Eingabe prüfen[angemeldet]

[nicht angemeldet]

Fehler

[überweisen]

[nicht überweisen]

Überweisung erzeugen

Formular erstellen

AusgabeStart

Abbildung 5.1.: Aktivitätsdiagramm, welches die Generierung einer Überweisungzeigt (eigene Darstellung).

ID erzeugen

Ausgabe

Start

Daten aufbereiten

Überweisung speicherneKaay

Abbildung 5.2.: Das Aktivitätsdiagramm zeigt die Zwischenschritte von Eingabe derder Überweisungsdaten bis zur Anzeige des von eKaay erzeugten QRCodes. Es zeigt den Schritt „Überweisung erzeugen“ aus Abbildung5.1 im Detail (eigene Darstellung).

5.2. Erweiterung der eKaay App

In Abschnitt 3.3.2 wurde die Erweiterung der eKaay App um NFC beschrieben. Dazumuss die App das notwendige benutzerdefinierte URL Scheme akzeptieren. Dieswird durch eine Erweiterung der Datei AndroidManifest.xml um den in Listing 5.1dargestellten Filter erreicht. Es ist wichtig, dass die Applikation als BROWSABLEausgewiesen wird, da dies den Aufruf durch einen Browser erlaubt (vgl. Google[2012c]). Dies leitet sich aus der Entwurfsentscheidung in Abschnitt 3.3.1 ab, welchebesagt, dass das Überweisungsformular und die erzeugte Challenge in einem Browserdargestellt werden.

1 <intent-filter>2 <action android:name="android.intent.action.VIEW" />3 <category android:name="android.intent.category.DEFAULT" />4 <category android:name="android.intent.category.BROWSABLE" />5 <data android:scheme="ekaaycash" />6 </intent-filter>

Listing 5.1: Auszug aus der AndroidManifest.xml. Gezeigt wird der Filter für einbenutzerdefiniertes URL Scheme (eigene Darstellung).



5.3. Server/Client Kommunikation

5.3. Server/Client Kommunikation

Im vollständigen eKaayCash Verfahren mit der Erweiterung für Online Shops gibtes folgende Entitäten.

• Die Serverkomponente von eKaay.

• Der Server des Dienstanbieters bzw. der Bank.

• Das Smartphone des Geldempfängers.

• Das Smartphone des Zahlenden.

• Der Server des Online Shops.

Der Vereinfachung wegen werden der Geldempfänger und der Zahlende zusammen-gefasst. Dies ist möglich, da beide ähnliche Informationen mit den Servern austau-schen. Abbildung 5.3 zeigt alle Kommunikationsverbindungen. Die gerichteten Pfeilegeben dabei an, von welcher Entität die Kommunikation ausgeht. Die Verbindungenwerden im Folgenden erläutert.

Registrierung/Anmeldung. Dies sind allgemeine Verbindungen von eKaay. Sie ent-sprechen der von Borchert [2012a] beschriebenen Kommunikation zwischendem Server von eKaay und dem Benutzerkontenserver. Zur Vereinfachung wur-den Registrierung und Anmeldung in Abbildung 5.3 zusammengefasst.

Bestätigung der Überweisung. Nach der Bestätigung durch den Zahlenden, leiteteKaay diese an den Server der Bank weiter. Dieser kann die Transaktion ab-schließen.

Nutzung von eKaay PIN. Wie in Abschnitt 3.3.3 beschrieben, soll eKaay erst abeinem bestimmten Betrag eine PIN abfragen. Der Server von eKaay fragt zudiesem Zweck die Nutzung der PIN bei der Bank an.

Challenge/Response/PIN Permutation. Dies sind allgemeine Verbindungen voneKaay, wie sie jeweils von einem Smartphone verwendet werden. Sowohl derAbruf der Challenge, als auch das Senden der Response und der PIN Permu-tation, gehen von der eKaay App auf dem Smartphone aus.

Überweisungsformular. Das Überweisungsformular wird von Smartphone und Ser-ver des Online Shops direkt beim Server der Bank abgerufen. Es kann bereitsausgefüllt sein und der Server der Bank antwortet in diesem Fall mit der ge-nerierten Transaktion.

Zahlungsbestätigung. Nach der Eingang einer Zahlung an einen Shop informiertder Server der Bank den Server des Online Shops.




Verifizierung der Bestätigung. Der Eingang einer Zahlung kann vom Server desShops mit Hilfe der in Abschnitt 3.4 beschriebenen Schnittstelle verifiziertwerden.

eKaay Server Server der Bank

Server des Shops

Registrierung/Anmeldung

Bestätigung der Überweisung

Nutzung von eKaay PIN

Smartphone Client

Challenge/Response/PIN Permutation

Überweisung-formular

Überweisungs-formular

Zahlungs-bestätigung

Verifizierung derBestätigung

Abbildung 5.3.: Kommunikation der verschiedenen Komponenten im eKaayCashVerfahren (eigene Darstellung).



6. Schluss

6.1. Zusammenfassung

Das Ziel der Arbeit war die Entwicklung eines sicheren, mobilen Bezahlsystems mitPeer-to-Peer Funktionalität unter Verwendung von eKaay und NFC. Des Weiterensollte das Verfahren auf seine Sicherheit hin untersucht werden. Diese Analyse sollteauch auf eine Reihe weiterer mobiler Bezahlsysteme angewandt und die Ergebnisseschließlich miteinander verglichen werden.

Zunächst wurden eine Reihe von Bedingungen für das mobile Bezahlsystem festge-legt, in deren Rahmen das Verfahren umgesetzt werden sollte. Im folgenden Entwurfdes Verfahrens konnten die Bedingungen fast vollständig eingehalten werden. Ledig-lich für die Einbindung der P2P Kommunikation via NFC musste die bestehendeeKaay App erweitert werden. Das Verfahren ließ sich wegen der GrundarchitektureKaay leicht nachvollziehbar umsetzen und bildet trotzdem eine von eKaay getrenntentwickelte Applikation. Gleichzeitig demonstriert es die Anwendung von eKaayTAN. In Anlehnung an die bereits im Einsatz befindliche Praxis der Banken wurdezudem das eKaay PIN Verfahren für den Übergang von Kleinstbeträgen zu größerenSummen eingebunden.

In einem zweiten Schritt wurde das vorgestellte Verfahren eKaayCash weiterentwi-ckelt und für den Einsatz in Online Shop Systeme erweitert. Dies ermöglicht dieeinfache Einbindung des mobilen Bezahlsystems in eine bestehende Verkaufsplatt-form. Es konnte gezeigt werden, dass sowohl für den Kunden als auch für den Händlereine einfachere Bedienung des Shops möglich ist. Die Sicherheit für den Händler wirddurch einen einfachen Bestätigungsprozess gewährleistet. Ein Austausch gegen einbeliebiges anderes Bestätigungsverfahren ist vorgesehen und möglich.

Zur Überprüfung der Sicherheit beider Systeme wurden zunächst mögliche Angriffs-punkte in Bezahlsystemen mit besonderem Hinblick auf die mobile Plattform iden-tifiziert. Sie wurden ausführlich erläutert und auf mögliche Folgen im finanziellenUmfeld geprüft. Anschließend konnten eKaayCash und die Erweiterung für OnlineShop Systeme auf ihre Sicherheit hin analysiert werden. Dabei konnte gezeigt wer-den, dass beide Systeme sicher sind und das Restrisiko vom Verhalten des Benutzersabhängig ist.



6. Schluss

Aufbauend auf die Untersuchung von eKaayCash wurden im Anschluss weitere mo-bile Bezahlverfahren ausgewählt, vorgestellt und untersucht. Die Einzelergebnisseergaben einen Überblick über verschiedene gemeinsame Probleme in elektronischenGeldsystemen in mobilen Umgebungen. Diese Probleme konnten in einer abschlie-ßenden Diskussion aufgezeigt werden. Dabei wurden Vorschläge für ihre Lösungenoder zumindest für die Minimierung des Risikos gemacht. Sie basieren auf den Er-fahrungen aus dem Entwurf von eKaayCash und der Analyse aller Verfahren.

Im Verlauf der Analyse wurde als Gegenbeispiel zu den Konto basierten Verfahrenein E-Wallet Verfahren als Weiterentwicklung des deutschen Geldkarten Systemsfür Smartphones entwickelt. Es besteht aus einem einfachen Verfahren, welches diedirekte Überweisung von Beträgen zwischen zwei mit Secure Element ausgestattetenSmartphones erlaubt. Es weist eine mit eKaayCash vergleichbar hohe Sicherheitauf.

Zum Abschluss dieser Arbeit wurden einzelne Punkte in der Implementierung voneKaayCash vorgestellt. Sie haben besondere Aspekte in der reellen Umsetzung desVerfahrens aufgezeigt und erläutert. Um eine unnötige Beschreibung eines austausch-baren Quellcodes zu vermeiden, wurde die Implementierung auf einer abstraktenEbene erläutert.

Das Ergebnis dieser Arbeit ist ein funktionierendes mobiles Bezahlsystem, welcheseine P2P Kommunikation mittels NFC ermöglicht. Es ist innerhalb einer simulier-ten Bankumgebung voll funktionsfähig. Des Weiteren wurde ein lauffähiges Beispielfür eine Erweiterung für Online Shops vorgestellt. Diese Erweiterung demonstriertauch die hohe Flexibilität des Bezahlsystems, welches sich leicht anpassen ließ. DieSicherheit von eKaayCash wurde in einer ausführlichen Analyse demonstriert undmit anderen existierenden und theoretischen Verfahren verglichen. Zusammen mitdem Entwurf des Geldkarten Systems für Smartphones bieten die Analyse und daseKaayCash Verfahren eine Reihe von Hinweisen für die Entwicklung weiterer, siche-rer Bezahlsysteme für das mobile Umfeld.

6.2. Ausblick

Unabhängig von den erzielten Ergebnissen ergeben sich durch diese Arbeit neueAnsätze für weitere Untersuchungen.

Erweiterte Analyse. Die Analyse in dieser Arbeit hat die Auswirkung einzelner An-griffe untersucht. Eine Kombination von verschiedenen Angriffen und die Aus-wirkung des Restrisikos wurde jedoch nicht beachtet. Für eine Anwendung,



6.2. Ausblick

welche die Überweisung von Geldbeträgen ermöglicht, sollte dies jedoch un-tersucht werden. Dabei ist besonders in Hinblick auf eKaayCash die Angreif-barkeit des Benutzers von Bedeutung, da ein wichtiger Teil der Sicherheit vondessen Aufmerksamkeit abhängig ist.

Secure Elements in eKaay. Verschiedene Verfahren in dieser Arbeit haben SecureElements auf Smartphones als eine Form von sicherer Umgebung eingesetzt.Ein ähnlicher Ansatz wurde mit dem eKaayCard Verfahren von Günther [2011]in Form einer externen Karte verfolgt. Zwar bietet eine Karte ein hohes Maßan Sicherheit durch den Faktor Besitz, allerdings verringert sie die Benutzer-freundlichkeit. Ein Geheimnis, welches in einem sicheren Bereich des Smart-phones gespeichert ist, könnte sowohl einen hohen Sicherheitsfaktor stellen, alsauch die Benutzerfreundlichkeit von eKaay ohne externe Karte beibehalten.

Abschließend lässt sich festhalten, dass die gesetzten Ziele erreicht wurden und dieZielsetzung zum Teil – beispielsweise mit dem Entwurf eines Geldkarten Systemsfür Smartphones – ausgeweitet wurde. Anhand der Analyse ließen sich weitere Zielefür zukünftige Arbeiten in diesem Themengebiet finden.



Literaturverzeichnis

Agarwal u. a. 2007Agarwal, Shivani ; Khapra, Mitesh ; Menezes, Bernard ; Uchat, Nirav:Security Issues in Mobile Payment Systems. 2007

Armstrong 2012Armstrong, Brian: Homepage Bitcoin Android. Online. https://github.

com/barmstrong/bitcoin-android. Version: Feb 2012

Baden-Württembergische Bank 2006Baden-Württembergische Bank: TAN-Generator der BW-Bank zertifi-ziert - Erfolg für sicheres Onlinebanking. Online. http://www.bw-bank.de/

bwbankde/1000005999-s1463-de.html. Version:Dec 2006

Bitcoin Project 2012Bitcoin Project: Homepage Bitcoin. Online. http://bitcoin.org/.Version: Feb 2012

Bitcoin.it Wiki 2012Bitcoin.it Wiki: Bitcoin.it Wiki. Online. https://en.bitcoin.it/wiki/

Main_Page. Version: Feb 2012

Borchert 2012aBorchert, Bernd: Homepage eKaay. Online. http://www.ekaay.com/.Version: Feb 2012

Borchert 2012bBorchert, Bernd: Online Banking Verfahren. Online. http://www-fs.

informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml.Version:Mar 2012

Bray 2010Bray, Tim: Android Browser User-Agent Issues. Online. http://android-

developers.blogspot.com/2010/12/android-browser-user-agent-

issues.html. Version:Dec 2010

Chambers 2011Chambers, Laura: PayPal Uses NFC to Make Peer-to-Peer Payments Easierthan Ever. Online. https://www.thepaypalblog.com/2011/07/paypal-uses-


https://github.com/barmstrong/bitcoin-android

https://github.com/barmstrong/bitcoin-android

http://www.bw-bank.de/bwbankde/1000005999-s1463-de.html

http://www.bw-bank.de/bwbankde/1000005999-s1463-de.html

http://bitcoin.org/

https://en.bitcoin.it/wiki/Main_Page

https://en.bitcoin.it/wiki/Main_Page

http://www.ekaay.com/

http://www-fs.informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml

http://www-fs.informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml

http://android-developers.blogspot.com/2010/12/android-browser-user-agent-issues.html



https://www.thepaypalblog.com/2011/07/paypal-uses-nfc-to-make-peer-to-peer-payments-easier-than-ever/




nfc-to-make-peer-to-peer-payments-easier-than-ever/. Version: Jul2011

Cheng u. a. 2011Cheng, Hsu-Chen ; Liao, Wen-Wei ; Chi, Tian-Yow ; Wei, Siao-Yun: A secureand practical key management mechanism for NFC read-write mode. In: Advan-ced Communication Technology (ICACT), 2011 13th International Conferenceon 13 (2011), Feb, S. 1095 – 1011

Choi u. a. 2007Choi, Seung H. ; Collins, David ; Ure, John ; Lovelock, Peter: Mobilepayments in Asia Pacific / KPMG. 2007. – Report

Deutsche Kreditwirtschaft 2011Deutsche Kreditwirtschaft: Schnittstellenspezifikation für die ec-Kartemit Chip Version 2.2. 2011

Deutsche Kreditwirtschaft 2012Deutsche Kreditwirtschaft: Händlerinfo: girogo.de. Online. http://

girogo.de/4-0-Haendlerinfo.html. Version:Mar 2012

EMVCo 2008EMVCo: EMV Integrated Circuit Card Specifications for Payment Systems -Book 2 - Security and Key Management. Jun 2008

Eriksson u. Johansson 2007Eriksson, Mattias ; Johansson, Tutor T.: An Example of a Man-in-the-middleAttack Against Server Authenticated SSL-sessions. Jan 2007

Fenner 1992Fenner, P.R.: Mobile address management and billing for personal communica-tions. In: Universal Personal Communications, 1992. ICUPC ’92 Proceedings.,1st International Conference on, 1992, 09.06/1 - 09.06/5

Gao u. a. 2006Gao, Jerry ; Cai, Jacky ; Patel, Kiran ; Shim, Simon: A Wireless PaymentSystem / San Jose State University, Computer Engineering. 2006. – Forschungs-bericht

Gao u. a. 2009Gao, Jerry ; Kulkarni, Vijay ; Ranavat, Himanshu ; Chang, Lee ; Mei,Hsing: A 2D Barcode-Based Mobile Payment System. In:MUE, IEEE ComputerSociety, 2009. – ISBN 978–0–7695–3658–3, 320-329




http://girogo.de/4-0-Haendlerinfo.html

http://girogo.de/4-0-Haendlerinfo.html



Günther 2011Günther, Max: Sicheres Online Banking via Smartphone mit Nahfunk (NFC) ,Uni Tübingen, Diplom, Sep 2011

Google 2011Google: Homepage Google Wallet. Online. http://www.google.com/wallet/.Version: 2011

Google 2012aGoogle: Android 2.3 Platform Highlights. Online. http://developer.

android.com/sdk/android-2.3-highlights.html. Version: Jan 2012

Google 2012bGoogle: Android 4.0 Platform Highlights. Online. http://developer.

android.com/sdk/android-4.0-highlights.html. Version: Jan 2012

Google 2012cGoogle: Android Developers References. Online. http://developer.

android.com/reference/packages.html. Version: Jan 2012

Google 2012dGoogle: Android Security. Online. http://source.android.com/tech/

security/index.html. Version: Jan 2012

Grossman u. a. 2007Grossman, J. ; Fogie, S. ; Hansen, R.: XSS attacks: cross-site scriptingexploits and defense. Syngress, 2007 (Syngress Media). – ISBN 9781597491549

Gupta u. a. 2005Gupta, K.N. ; Agarwala, K.N. ; Agarwala, P.A.: Digital Signature: Net-work Security Practices. Prentice-Hall Of India Pvt. Ltd., 2005. – ISBN9788120325999

Hardawar 2011Hardawar, Devindra: PayPal brings NFC money transfers to Android, star-ting with Nexus S. Online. http://venturebeat.com/2011/07/13/paypal-

android-nfc/. Version: Jul 2011

Haselsteiner u. Breitfuß 2006Haselsteiner, Ernst ; Breitfuß, Klemens: Security in Near Field Commu-nication ( NFC ) Strengths and Weaknesses. In: Semiconductors 11 (2006),S. 71

Hearn u. a. 2012Hearn, Mike ; Cuperman, Miron ; Guo, Xiaofeng ; Planz, Thilo ; Swiggs,Micheal ; Rowe, Gary ; Resare, Noa ; Sample, John ; Møller, Jan ; Nagele,


http://www.google.com/wallet/

http://developer.android.com/sdk/android-2.3-highlights.html




http://developer.android.com/reference/packages.html

http://developer.android.com/reference/packages.html

http://source.android.com/tech/security/index.html

http://source.android.com/tech/security/index.html

http://venturebeat.com/2011/07/13/paypal-android-nfc/

http://venturebeat.com/2011/07/13/paypal-android-nfc/



Wolfgang ; Heggheim, Jonny ; Coughlan, Steve ; Mandeleil, Roman ; Rico,Chris ; Rotaru, Vasile: Homepage bitcoinj. Online. http://code.google.com/

p/bitcoinj/. Version: Feb 2012

ISO 2000aNorm ISO/IEC 14443 2000. Identification cards - Contactless integrated cir-cuit(s) cards - Proximity cards

ISO 2000bNorm ISO/IEC 18004 2000. Quick Response Code

ISO 2004Norm ISO/IEC 18000-3 2004. ISO/IEC 18000-3

Jakobsson u. Myers 2006Jakobsson, M. ; Myers, S.: Phishing and Countermeasures: Understandingthe Increasing Problem of Electronic Identity Theft. John Wiley & Sons, 2006.– ISBN 9780471782452

JVL Ventures, LLC 2012JVL Ventures, LLC: Homepage ISIS. Online. http://www.paywithisis.

com/home.xhtml. Version:Mar 2012

Kadhiwal u. Zulfiquar 2007Kadhiwal, Saleem ; Zulfiquar, Anwar Usman S.: Analysis of mobile paymentsecurity measures and different standards. In: Computer Fraud Security 6 (2007),Jun, Nr. 6, S. 12–16

Karnouskos 2004Karnouskos, Stamatis: Mobile payment: A journey through existing proce-dures and standardization initiatives. In: IEEE Communications Surveys andTutorials 6 (2004), Nr. 1-4, S. 44–66

Kaspersky Lab 2010Kaspersky Lab: First SMS Trojan detected for smartphones running Android.Online. http://www.kaspersky.com/news?id=207576158. Version:Aug 2010

Kincaid 2011Kincaid, Jason: Special Stickers Will Bring Google Wallet To Android PhonesThat Lack NFC. Online. http://techcrunch.com/2011/05/26/special-

stickers-will-bring-google-wallet-to-android-phones-that-lack-

nfc/. Version:May 2011


http://code.google.com/p/bitcoinj/

http://code.google.com/p/bitcoinj/

http://www.paywithisis.com/home.xhtml

http://www.paywithisis.com/home.xhtml

http://www.kaspersky.com/news?id=207576158

http://techcrunch.com/2011/05/26/special-stickers-will-bring-google-wallet-to-android-phones-that-lack-nfc/





Kortvedt u. Mjølsnes 2009Kortvedt, Henning S. ; Mjølsnes, Stig F.: Eavesdropping Near Field Com-munication. In: The Norwegian Information Security Conference (NISK) 2009,2009, 57-68

Lee u. a. 1994Lee, Berners T. ; Masinter, L. ; Mccahill, M.: RFC 1738: UniformResource Locator (URL). Online. http://www.ietf.org/rfc/rfc1738.txt.Version:Aug 1994

Li u. a. 2008Li, Qi ; Zhang, Xinwen ; Seifert, Jean-Pierre ; Zhong, Hulin: Secure MobilePayment via Trusted Computing. In: Proceedings of the 2008 Third Asia-PacificTrusted Infrastructure Technologies Conference. Washington, DC, USA : IEEEComputer Society, 2008. – ISBN 978–0–7695–3363–6, 98–112

Mahlmann u. Schindelhauer 2007Mahlmann, P. ; Schindelhauer, C.: Peer-To-Peer-Netzwerke: AlgorithmenUnd Methoden. Springer, 2007 (EXamen. press Series). – ISBN 9783540339915

Massoth u. Bingel 2009Massoth, Michael ; Bingel, Thomas: Performance of Different Mobile Pay-ment Service Concepts Compared with a NFC-Based Solution. In: Proceedingsof the 2009 Fourth International Conference on Internet and Web Applicationsand Services. Washington, DC, USA : IEEE Computer Society, 2009. – ISBN978–0–7695–3613–2, 205–210

MasterCard 2012MasterCard: Homepage MasterCard PayPass. Online. http://www.

mastercard.com/de/privatkunden/products/products_paypass.html.Version: 2012

Meyer u. Wetze 2004Meyer, Ulrike ; Wetze, Susanne: On the impact of GSM Encryption and Man-in-the-Middle Attacks on the Security of Interoperating GSM/UMTS Networks.In: Proceedings of IEEE International Symposium on Personal, Indoor andMobile Radio Communications (PIMRC2004), September 2004, IEEE, 2004.http://www.cdc.informatik.tu-darmstadt.de/ umeyer/UliPIMRC04.pdf, 2004

Mobey Forum Mobile Financial Services Ltd 2010Mobey Forum Mobile Financial Services Ltd: Alternatives for Banksto offer Secure Mobile Payments. http://www.mobeyforum.org/Press-

Documents/Press-Releases/Alternatives-for-Banks-to-offer-Secure-

Mobile-Payments. Version:Mar 2010. – Online


http://www.ietf.org/rfc/rfc1738.txt

http://www.mastercard.com/de/privatkunden/products/products_paypass.html

http://www.mastercard.com/de/privatkunden/products/products_paypass.html

http://www.mobeyforum.org/Press-Documents/Press-Releases/Alternatives-for-Banks-to-offer-Secure-Mobile-Payments





Mun u. a. 2009Mun, Hyeran ; Han, Kyusuk ; Kim, Kwangjo: 3G-WLAN interworking: securityanalysis and new authentication and key agreement based on EAP-AKA. In:Proceedings of the 2009 conference on Wireless Telecommunications Symposium.Piscataway, NJ, USA : IEEE Press, 2009 (WTS’09). – ISBN 978–1–4244–2588–4,309–316

Mutchukota u. a. 2011Mutchukota, Thrinatha R. ; Panigrahy, Saroj K. ; Jena, Sanjay K.: Man-in-the-Middle Attack and its Countermeasure in Bluetooth Secure Simple Pairing.May 2011. – Department of Computer Science & Engineering, National Instituteof Technology Rourkela

Nakamoto 2009Nakamoto, Satoshi: Bitcoin: A Peer-to-Peer Electronic Cash System. May2009. – bitcoin.org

NFC Forum 2012NFC Forum: Homepage NFC Forum. Online. http://www.nfc-forum.org/

home/. Version: Feb 2012

Ondrus u. Pigneur 2007Ondrus, Jan ; Pigneur, Yves: An Assessment of NFC for Future MobilePayment Systems. In: ICMB’07, 2007

Pasquet u. a. 2008Pasquet, Marc ; Reynaud, Joan ; Rosenberger, Christophe: Secure paymentwith NFC mobile phone in the SmartTouch project. IEEE, 2008. – 121–126 S.

Patel 2011Patel, Kunur: Survey: Consumers Don’t Trust Google or Apple With MobilePayments. Online. http://adage.com/article/digital/consumers-trust-

google-apple-mobile-payments/229163/. Version:Aug 2011

PayPal 2011aPayPal: PayPal Mobile - Peer-to-Peer NFC Solutions. Online. http://youtu.

be/ovxA35hQ058. Version: Jul 2011

PayPal 2012aPayPal: Homepage PayPal. Online. https://www.paypal.com/. Version:Mar2012

PayPal 2012bPayPal: PayPal Mobile. Online. https://personal.paypal.com/us/cgi-


http://www.nfc-forum.org/home/

http://www.nfc-forum.org/home/

http://adage.com/article/digital/consumers-trust-google-apple-mobile-payments/229163/

http://adage.com/article/digital/consumers-trust-google-apple-mobile-payments/229163/

http://youtu.be/ovxA35hQ058

http://youtu.be/ovxA35hQ058

https://www.paypal.com/

https://personal.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=marketing_us/mobile_payments




bin/?cmd=_render-content&content_ID=marketing_us/mobile_payments.Version: Jan 2012

PayPal 2012cPayPal: Sofortige Zahlungsbestätigung (IPN). Online. https:

//www.paypalobjects.com/de_DE/html/IntegrationCenter/ic_ipn.html.Version:Mar 2012

PayPal 2011bPayPal, Schweden: Betala Med Mobilen I Kassan! Online. https://www.

paypal-sverige.se/swe/december/julkampanj.html. Version:Dec 2011

Pehl 2004Pehl, E.: Mobilfunk: Stand der Technik und Zukunftsperspektiven : Vorträgeder 9. ITG-Fachtagung vom 16. bis 17. Juni 2004 in Osnabrück. VDE, 2004(ITG-Fachberichte). – ISBN 9783800728398

Rao 2011Rao, Leena: PayPal Tests In-Store NFC Payments App With Swe-dish Retailers, Similar Mobile ’Experiments’ To Roll Out Soon. Onli-ne. http://techcrunch.com/2011/12/20/paypal-tests-in-store-nfc-

payments-app-with-swedish-retailers-similar-mobile-experiments-

to-roll-out-soon/. Version:Dec 2011

Reid u. Harrigan 2011Reid, Fergal ; Harrigan, Martin: An Analysis of Anonymity in the BitcoinSystem. In: SocialCom/PASSAT, IEEE, 2011. – ISBN 978–1–4577–1931–8,1318-1326

Rubin 2012Rubin, Joshua: Google Wallet Security: PIN Exposure Vulnerability.Online. https://zvelo.com/blog/entry/google-wallet-security-pin-

exposure-vulnerability. Version: Feb 2012

Samuel 2011Samuel, Shimone: New in the Android Market: Updated PayPal Mobile AppFeaturing P2P NFC Capabilities. Online. https://www.thepaypalblog.

com/2011/11/new-in-the-android-market-updated-paypal-mobile-app-

featuring-p2p-nfc-capabilities-2/. Version:Nov 2011

Schildbach 2012Schildbach, Andreas: Homepage Bitcoin Wallet. Online. http://code.

google.com/p/bitcoin-wallet/. Version: Feb 2012




https://www.paypalobjects.com/de_DE/html/IntegrationCenter/ic_ipn.html

https://www.paypalobjects.com/de_DE/html/IntegrationCenter/ic_ipn.html

https://www.paypal-sverige.se/swe/december/julkampanj.html

https://www.paypal-sverige.se/swe/december/julkampanj.html

http://techcrunch.com/2011/12/20/paypal-tests-in-store-nfc-payments-app-with-swedish-retailers-similar-mobile-experiments-to-roll-out-soon/



https://zvelo.com/blog/entry/google-wallet-security-pin-exposure-vulnerability

https://zvelo.com/blog/entry/google-wallet-security-pin-exposure-vulnerability

https://www.thepaypalblog.com/2011/11/new-in-the-android-market-updated-paypal-mobile-app-featuring-p2p-nfc-capabilities-2/



http://code.google.com/p/bitcoin-wallet/

http://code.google.com/p/bitcoin-wallet/



Shinder 2011Shinder, Debra L.: Smartphone technology of the future. Onli-ne. http://www.techrepublic.com/blog/smartphones/smartphone-

technology-of-the-future/3735. Version:Oct 2011

Son u. ShmatikovSon, Sooel ; Shmatikov, Vitaly: The Hitchhiker’s Guide to DNS Cache Poi-soning

Suchy 2007Suchy, T.: Bluetoothbasiertes Informationssystem- Konzeption und Realisationeines Prototypen für einen Stadtinformationsdienst. GRIN Verlag GmbH, 2007.– ISBN 9783638833141

Unrath 2012Unrath, Dieter N.: Verbraucher misstrauen Zahlung per Funk. Online. http:

//www.pressetext.com/main#news/20120302004. Version:Mar 2012

Van Damme u. a. 2005Van Damme, Gauthier ; Wouters, Karel ; Preneel, Bart: Practical Expe-riences with NFC Security on mobile Phones. In: Workshop on RFID SecurityRFIDSec09 5 (2005), S. 1–13

Viaforensics 2011Viaforensics: Forensic security analysis of Google Wallet. On-line. http://viaforensics.com/mobile-security/forensics-security-

analysis-google-wallet.html. Version:Dec 2011

VISA 2012VISA: Homepage VISA payWave. Online. http://www.visaeurope.com/en/

cardholders/visa_paywave.aspx. Version: 2012

ZDV Tübingen 2012ZDV Tübingen: Login Webmail Universität Tübingen. Online. Grundlagen-

eKaay-1. Version:Mar 2012

Zhang u. a. 2010Zhang, Lizhuo ; Jia, Weijia ; Wen, Sheng ; Yao, Di: A Man-in-the-MiddleAttack on 3G-WLAN Interworking. In: Proceedings of the 2010 InternationalConference on Communications and Mobile Computing - Volume 01. Washing-ton, DC, USA : IEEE Computer Society, 2010 (CMC ’10). – ISBN 978–0–7695–3989–8, 121–125

ZKA 2009ZKA: Richtlinien für einheitliche Zahlungsverkehrsvordrucke. 2009


http://www.techrepublic.com/blog/smartphones/smartphone-technology-of-the-future/3735

http://www.techrepublic.com/blog/smartphones/smartphone-technology-of-the-future/3735

http://www.pressetext.com/main#news/20120302004

http://www.pressetext.com/main#news/20120302004

http://viaforensics.com/mobile-security/forensics-security-analysis-google-wallet.html

http://viaforensics.com/mobile-security/forensics-security-analysis-google-wallet.html

http://www.visaeurope.com/en/cardholders/visa_paywave.aspx

http://www.visaeurope.com/en/cardholders/visa_paywave.aspx

Grundlagen-eKaay-1

Grundlagen-eKaay-1


A. Anhang

© Stefan Gfrörer i


A. Anhang

ii © Stefan Gfrörer


Bank-Modul

Shop-Modul

Sho

psei

te

Tra

nsak

tions

-be

stät

igun

g

eKaay-Modul

Pro

xy

eKaa

y

Wei

terle

itung

Hau

ptse

ite

eKaa

y T

AN

eKaa

y P

IN

eKaa

y T

oken

Kon

to-E

inst

ellu

ngen

Logi

n

Logo

ut

Reg

istr

ieru

ng

Kon

ten-

und

Tra

nsak

tions

-Ü

bers

icht

Tra

nsak

tions

best

ätig

ung

Übe

rwei

sung

sfor

mul

ar

eKaa

yCas

h F

orm

ular

For

dert

Cha

lleng

e fü

r Lo

gin

an

Bes

tätig

t Log

in

For

dert

Cha

lleng

e fü

r R

egis

trie

rung

von

eK

aay

an

For

dert

Cha

lleng

e fü

r T

AN

an

Bes

tätig

t Tra

nsak

tion

Prü

ft, o

b R

egis

trie

rung

stok

en

abge

lauf

en is

t

Prü

ft, o

b P

IN E

inga

be b

enöt

igt w

ird

For

dert

Cha

lleng

e fü

r T

AN

an

For

dert

Übe

rwei

sung

fü

r P

rodu

kt a

n

Fra

gt K

orre

kthe

it de

r T

rans

aktio

n ab

Bes

tätig

t T

rans

aktio

n

Der

Anw

ende

r ru

ft W

ebse

iten

auf u

ndfü

hrt e

inze

lne

Akt

ione

n au

s.

Abbildung A.1.: Die unterschiedlichen Module mit den dazugehörenden Webseitenim eKaayCash System (eigene Darstellung).

© Stefan Gfrörer iii


A. Anhang

Alic

e (G

elde

mpf

änge

r)B

ob (

Zah

lend

er)

1. D

er G

elde

mpf

änge

r fü

llt d

as Ü

berw

eisu

ngs-

form

ular

aus

und

übe

träg

tde

n B

etra

g un

d de

n V

erw

endu

ngsz

wec

k an

de

n S

erve

r.

Ser

ver

der

Ban

k

3. D

urch

abf

otog

rafie

ren

oder

über

ein

e N

FC

Ver

bind

ung

wird

die

Cha

lleng

e an

den

Z

ahle

nden

wei

terg

elei

tet.

5. N

ach

Bes

tätig

ung

der

Tra

nsak

tion

erze

ugt

die

eKaa

y A

pp e

ine

Res

pons

e zu

der

Cha

lleng

e un

d üb

ertr

ägt

dies

e an

den

Ser

ver.

6. D

er S

erve

r pr

üft d

ie

Res

pons

e un

d fü

hrt

die

Tra

nsak

tion

bei

Kor

rekt

heit

aus.

2. D

er S

erve

r an

twor

tet

mit

der

Cha

lleng

e in

For

m

des

QR

Cod

es u

nd d

es N

FC

Li

nks.

Die

Cha

lleng

e en

thäl

t ei

ne N

once

und

die

T

rans

aktio

nsda

ten

als

Tex

t.

4. D

er Z

ahle

nde

kann

die

T

rans

aktio

n üb

er u

nten

ste

hend

esD

ialo

g pr

üfen

und

bes

tätig

en.

eKaa

y

Bitt

e be

stät

igen

Dat

um: 2

0.4.

2012

Uhr

zeit:

10:

00:0

0E

mpf

aeng

er: A

lice

Bet

rag:

100

.00

Eur

o

abbr

eche

nO

K

7. M

it A

bsch

luss

der

T

rans

aktio

n er

halte

n de

rG

elde

mpf

änge

r un

d de

r Z

ahle

nde

eine

Bes

tätig

ung.

Abbildung A.2.: Der vollständige Ablauf einer Peer-to-Peer Transaktion mit eKaay-Cash (eigene Darstellung).

iv © Stefan Gfrörer


Sm

artp

hone

des

Kun

den

1. D

er K

unde

ruft

den

Sho

pau

f.

Ser

ver

der

Ban

k

7. N

ach

Bes

tätig

ung

der

Tra

nsak

tion

erze

ugt

die

eKaa

y A

pp e

ine

Res

pons

e zu

der

C

halle

nge

und

über

träg

t die

se a

n de

n S

erve

r de

r B

ank.

4. D

er S

erve

r de

r B

ank

antw

orte

t mit

der

Cha

lleng

e in

For

m d

es Q

R. D

ie C

halle

nge

enth

ält e

ine

Non

ce u

nd d

ie

Tra

nsak

tions

date

n al

s T

ext.

6. D

er K

unde

kan

n di

e T

rans

aktio

n üb

er u

nten

ste

hend

esD

ialo

g pr

üfen

und

bes

tätig

en.

5. D

urch

abf

otog

rafie

ren

liest

der

Kun

de d

ie C

halle

nge

in s

ein

Sm

artp

hone

ein

. Die

s is

t gle

ichb

edeu

tend

mit

dem

Kau

f der

War

e.

eKaa

y

Bitt

e be

stät

igen

Dat

um: 2

0.4.

2012

Uhr

zeit:

10:

00:0

0E

mpf

aeng

er: S

hop

Bet

rag:

1.0

0 E

uro

Ver

wen

dung

szw

eck:

1kg

Äpf

el

abbr

eche

nO

K

Ser

ver

des

Sho

ps

Kun

de 2. D

er S

erve

r de

s S

hops

lief

ert W

ebse

ite

mit

eing

ebet

tete

rÜ

berw

eisu

ng a

us.

3. D

er B

row

ser

des

Kun

den

ruft

die

Cha

lleng

e fü

r di

e Ü

berw

eisu

ng a

b.

8. D

er S

erve

r de

r B

ank

info

rmie

rt d

en S

erve

r de

s S

hops

üb

er d

ie a

bges

chlo

ssen

e Ü

berw

eisu

ng. D

ie B

estä

tigun

g en

thäl

t alle

Übe

rwei

sung

sdat

en.

9. D

er S

erve

r de

s S

hops

ste

llt e

ine

Anf

rage

an

den

Ser

ver

der

Ban

k m

it de

n er

halte

nen

Übe

rwei

sung

sdat

en.

10. D

er S

erve

r de

r B

ank

prüf

t die

Übe

rwei

sung

sdat

en

und

best

ätig

t die

Kor

rekt

heit.

Abbildung A.3.: Der vollständige Ablauf eines Einkaufs in einem Shop mit der Er-weiterung für eKaayCash (eigene Darstellung).

© Stefan Gfrörer v