Diplomarbeit

Eberhard-Karls-Universitt Tbingen Fakultt fr Informations- und Kognitionswissenschaften Wilhelm-Schickard-Institut fr Informatik Arbeitsbereich fr Theoretische Informatik / Formale Sprachen
Peer-to-Peer Payment via NFC

Diplomarbeit
im Fachgebiet Informatik
Stefan Gfrrer 20. April 2012
Betreuer: Dr. Bernd Borchert Prof. Dr. Klaus Reinhardt
Zusammenfassung
Die vorliegende Arbeit erforscht die Umsetzung eines mobilen Bezahlsystems mittels dem eKaay Verfahren. Es soll direkte Transaktionen zwischen zwei Benutzern von Smartphones ermglichen und dabei einen guten Kompromiss aus Sicherheit und Benutzerfreundlichkeit bieten. Die Sicherheit muss in einer Analyse nachgewiesen und mit weiteren Verfahren verglichen werden. Beide Ziele wurden erreicht. Dabei ist es gelungen neben dem Bezahlverfahren auch eine Erweiterung fr Online Shop Systeme zu entwickeln. Die Analyse ergab eine Reihe von hnlichen Problemen und Lsungsanstzen in verschiedenen mobilen Peer-to-Peer Bezahlsystemen. Aus diesen Gemeinsamkeiten konnten verschiedene Empfehlungen fr die Entwicklung weiterer Verfahren abgeleitet werden.
Stefan Gfrrer
Eidesstattliche Erklrung
Ich, Stefan Gfrrer, versichere hiermit, dass ich meine Diplomarbeit mit dem Thema Peer-to-Peer Payment via NFC selbstndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, wobei ich alle wrtlichen und sinngemen Zitate als solche gekennzeichnet habe. Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch nicht verentlicht. Tbingen, den 20. April 2012
Stefan Gfrrer
Stefan Gfrrer
Peer-to-Peer Payment via NFC Inhaltsverzeichnis
Inhaltsverzeichnis
Abkrzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Listings 1. Einleitung 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Voraussetzungen zum Verstndnis der Arbeit . . . . . . . . . . . . . 1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Grundlagen und Hintergrnde 2.1. eKaay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Near Field Communication (NFC) . . . . . . . . . . . . . . . . . . . 2.3. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Mobile Payment (MP) . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Peer-to-Peer Payment mit eKaay 3.1. Formulierung der Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Entwurf einer Testumgebung . . . . . . . . . . . . . . . . . . . . . . 3.3. Entwurf von eKaayCash . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Peer-to-Peer Kommunikation . . . . . . . . . . . . . . . . . . 3.3.3. Verbesserung der Sicherheit . . . . . . . . . . . . . . . . . . . 3.4. Erweiterung fr Online Shop Systeme . . . . . . . . . . . . . . . . . 3.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Analyse bestehender mobiler Bezahlsysteme 4.1. Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Auswahl der Verfahren und Kriterien . . . . . . . . . . . . . . 4.1.2. Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V VII XI XIII 1 1 2 2 3 3 5 5 9 11 12 17 17 18 19 19 21 24 25 27 29 29 29 30
Stefan Gfrrer

4.2. Mgliche Angrispunkte in Mobile Payment Lsungen . . . . . . . . 4.3. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.1. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.2. Erweiterung fr Online Shop Systeme . . . . . . . . 4.3.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. PayPal Mobile Payments . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.4.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.4.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 4.4.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Google wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.5.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.5.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 4.5.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Bitcoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.6.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.6.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 4.6.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7. A 2D Barcode-Based Mobile Payment System . . . . . . . . . . . 4.7.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.7.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.7.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 4.7.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.7.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8. A Wireless Payment System . . . . . . . . . . . . . . . . . . . . . 4.8.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.8.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.8.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 4.8.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.8.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9. Entwurf einer Smartphone basierten Geldkarte . . . . . . . . . . . . 4.9.1. Beschreibung des Verfahrens . . . . . . . . . . . . . . . . . . 4.9.2. Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . 4.9.3. Verbreitung und Akzeptanz durch Benutzer . . . . . . . . . . 31 40 40 40 42 42 43 43 45 46 47 49 49 49 51 52 52 54 54 54 55 57 57 59 59 59 60 62 62 63 64 64 64 66 66 67 68 68 69 70
Stefan Gfrrer
II

4.9.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.9.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10. Weitere Mobile Payment Lsungen . . . . . . . . . . . . . . . . . . . 4.10.1. Secure Mobile Payment via Trusted Computing . . . . . . 4.10.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Implementierung von eKaayCash 5.1. Erzeugung einer berweisung . . . . . . . . . . . . . . . . . . . . . . 5.2. Erweiterung der eKaay App . . . . . . . . . . . . . . . . . . . . . . . 5.3. Server/Client Kommunikation . . . . . . . . . . . . . . . . . . . . . . 6. Schluss 6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literaturverzeichnis A. Anhang 70 71 71 71 72 72 72 74 77 77 78 79 81 81 82 85 i
III
Stefan Gfrrer
Peer-to-Peer Payment via NFC Abkrzungsverzeichnis
Abkrzungsverzeichnis
AES . . . . . . . . . . . . . . . Advanced Encryption Standard API . . . . . . . . . . . . . . . . Application Programming Interface (engl. fr Programmierschnittstelle) ASK . . . . . . . . . . . . . . . Amplitude Shift Keying C2C . . . . . . . . . . . . . . . . Consumer-to-Consumer CNP . . . . . . . . . . . . . . . Card not present transaction ECC . . . . . . . . . . . . . . . Elliptic Curve Cryptography (engl. fr Elliptische-KurvenKryptographie) EDGE . . . . . . . . . . . . . Enhanced Data Rates for GSM Evolution EMV . . . . . . . . . . . . . . . Europay, MasterCard, Visa GSM . . . . . . . . . . . . . . . Global System for Mobile Communications HMAC . . . . . . . . . . . . . Keyed-Hash Message Authentication Code ID . . . . . . . . . . . . . . . . . Identication (engl. fr Identikator oder Kennung) IMEI . . . . . . . . . . . . . . . International Mobile Equipment Identity LTE . . . . . . . . . . . . . . . . Long Term Evolution MITM . . . . . . . . . . . . . Man-in-the-middle attack (engl. fr Man-in-the-middle-Angri) MP . . . . . . . . . . . . . . . . Mobile Payment NDEF . . . . . . . . . . . . . NFC Data Exchange Format NFC . . . . . . . . . . . . . . . Near Field Communication (engl. fr Nahfeld-Kommunikation) P2P . . . . . . . . . . . . . . . . Peer-to-Peer oder Person-to-Person PIN . . . . . . . . . . . . . . . . Personal Identication Number (engl. fr Persnliche Identikationsnummer) POS . . . . . . . . . . . . . . . Point of Sale QR Code . . . . . . . . . . . Quick Response Code RFID . . . . . . . . . . . . . . Radio-Frequency Identication SDP . . . . . . . . . . . . . . . Service Discovery Protocol SE . . . . . . . . . . . . . . . . . Secure Element SMS . . . . . . . . . . . . . . . Short Message Service (engl. fr Kurznachrichtendienst) SSL . . . . . . . . . . . . . . . . Secure Sockets Layer
Stefan Gfrrer
Peer-to-Peer Payment via NFC Abkrzungsverzeichnis

TAN . . . . . . . . . . . . . . . Transaction Authentication Number (engl. fr Transaktionsnummer) TLS . . . . . . . . . . . . . . . . Transport Layer Security UMTS . . . . . . . . . . . . . Universal Mobile Telecommunications System URL . . . . . . . . . . . . . . . Uniform Resource Locators WLAN . . . . . . . . . . . . . Wireless Local Area Network (engl. fr drahtloses lokales Netzwerk) WOT . . . . . . . . . . . . . . Web of Trust (engl. fr Netz des Vertrauens)
Stefan Gfrrer
VI
Peer-to-Peer Payment via NFC Abbildungsverzeichnis
Abbildungsverzeichnis
2.1. Verwendung von eKaay als alternatives Loginverfahren im Webmail Angebot der Universitt Tbingen (Quelle: ZDV Tbingen [2012]). . 2.2. Das eKaay TAN Verfahren im Detail. Das Versenden der Besttigung ist nicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . 2.3. Das eKaay PIN Verfahren aus Sicht des Benutzers. Links ist ein Handy mit permutiertem Ziernfeld und rechts das Formular im Browser mit QR Code und Zierneingabefeld ohne Beschriftung dargestellt (Quelle: Borchert [2012a]). . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Die von NFC verwendeten Kodierungen (Quelle: Van Damme u. a. [2005]; [bersetzung durch Verfasser]). . . . . . . . . . . . . . . . . . 2.5. Eine Peer-to-Peer berweisung ausgehend vom Zahlenden (Quelle: Agarwal u. a. [2007]; [bersetzung durch Verfasser]). . . . . . . . . . 2.6. Eine Peer-to-Peer berweisung ausgehend vom Geldempfnger (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Formular fr eine mobile berweisung. Geldempfnger und Zahlender werden automatisch erfasst (eigene Darstellung). . . . . . . . . . . . 3.2. Ablauf einer Transaktion mittels eKaayCash. Besttigungen nach erfolgreicher Durchfhrung an beide Parteien sind der bersicht wegen nicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . . . 3.3. Beispiel fr einen Artikel mit der dazugehrenden eKaayCash Transaktion zum gleichzeitigen Kaufen und Bezahlen (eigene Darstellung). 3.4. Ablauf eines Einkaufs im Online Shop mit eKaayCash. Es wird davon ausgegangen, dass die Transaktion bereits erzeugt wurde (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Erfolgreicher Man-in-the-Middle Angri auf eine Server-Client Verbindung. Der Angreifer Mallory kann den Kommunikationsuss zwischen Alice und Bob vollstndig kontrollieren (eigene Darstellung). . 4.2. Der Angreifer Eve hat zwar keinen direkten Einuss auf den Kommunikationskanal, kann aber die Verbindung zwischen Alice und Bob unbemerkt belauschen (eigene Darstellung). . . . . . . . . . . . . . . 34 34 27 26 21 20 16 15 11 9 8 6
VII
Stefan Gfrrer

4.3. Der Angreifer Mallory manipuliert eine berweisung, welche auer einer vom Inhalt unabhngigen TAN keinen weiteren Schutz aufweist (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Der Besttigungsdialog von eKaay fr eine Transaktion (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Versuch eines Angreifers einem Shop eine Transaktion vorzutuschen (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Das installierte PayPal Mobile Payments Widget auf dem Homescreen eines Android basierten Smartphones (Quelle: Chambers [2011]). . . 4.7. Ablauf einer P2P Transaktion mit PayPal. Das Versenden der Besttigung wurde aus Grnden der bersicht entfernt (eigene Darstellung). 45 4.8. Bezahlung an einem NFC-fhigen Terminal mit PayPal Mobile Payments (Quelle: PayPal [2011b]). . . . . . . . . . . . . . . . . . . . . . 4.9. Gem A2 kann ein Schadprogramm auf dem Smartphone des Geldempfngers die Transaktionsdaten vor der bertragung manipulieren (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10. Ein Nexus S 4G mit aktiver Google wallet App. Das Konto ist mit einer Citi MasterCard aufgeladen. Daneben ein MasterCard paypass Terminal, welches mit Google wallet genutzt werden kann (Quelle: Google [2011]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11. Ablauf einer mobilen berweisung im Bitcoin-Netzwerk (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Grasche Darstellung eines Ausschnitts des Bitcoin Netzwerks rund um Wikileaks (Quelle: Reid u. Harrigan [2011]; [Hervorhebung durch Verfasser]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Ablauf eines Produktkaufs mit Hilfe des 2D Barcode Verfahren. Nicht enthalten sind die Besttigungen an Kunden und Hndler (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14. Ablauf einer P2P berweisung mit Hilfe von Bluetooth. Die Besttigung wurde entfernt (eigene Darstellung). . . . . . . . . . . . . . . . 65 61 59 56 50 48 47 44 43 41 35
4.15. Ablauf einer Transaktion zwischen zwei Smartphones nach dem GeldkartenPrinzip (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . 4.16. Die Ergebnisse der Sicherheitsanalyse im berblick (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Aktivittsdiagramm, welches die Generierung einer berweisung zeigt (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 73 70
Stefan Gfrrer
VIII

5.2. Das Aktivittsdiagramm zeigt die Zwischenschritte von Eingabe der der berweisungsdaten bis zur Anzeige des von eKaay erzeugten QR Codes. Es zeigt den Schritt berweisung erzeugen aus Abbildung 5.1 im Detail (eigene Darstellung). . . . . . . . . . . . . . . . . . . . 5.3. Kommunikation der verschiedenen Komponenten im eKaayCash Verfahren (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . A.1. Die unterschiedlichen Module mit den dazugehrenden Webseiten im eKaayCash System (eigene Darstellung). . . . . . . . . . . . . . . . . A.2. Der vollstndige Ablauf einer Peer-to-Peer Transaktion mit eKaayCash (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . A.3. Der vollstndige Ablauf eines Einkaufs in einem Shop mit der Erweiterung fr eKaayCash (eigene Darstellung). . . . . . . . . . . . . . . v iv iii 80 78
IX
Stefan Gfrrer
Peer-to-Peer Payment via NFC Tabellenverzeichnis
Tabellenverzeichnis
3.1. Syntax der Daten von eKaay TAN aus einem QR Code (Quelle: Borchert [2012a]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. bersicht aller Angrismethoden auf mobile Bezahlsysteme (eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Der Sicherheitsheader fr Nachrichten im Verfahren mit Bluetooth. Er wird an die eigentlichen Nutzdaten angehngt (vgl. Gao u. a. [2006]; [bersetzung durch Verfasser]). . . . . . . . . . . . . . . . . . . . . . 65 39 22
XI
Stefan Gfrrer
Verzeichnis der Listings

3.1. Beispiel fr einen eKaayCash NFC Link kodiert gem Lee u. a. [1994] (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Informationen aus der Datenbank von Google wallet. Von oben nach unten: Bezeichner der Karte, Name des Besitzer, Kreditlimit, aktuelles Guthaben und die letzten vier Ziern der Kartennummer (Quelle: Viaforensics [2011]; im Auszug). . . . . . . . . . . . . . . . . . . . . . 5.1. Auszug aus der AndroidManifest.xml. Gezeigt wird der Filter fr ein benutzerdeniertes URL Scheme (eigene Darstellung). . . . . . . . . 78 54 23
XIII
Stefan Gfrrer
1. Einleitung
1.1. Motivation
Bargeldloser Zahlungsverkehr erfhrt in regelmigem Abstand neue Entwicklungen. Das Ziel der Finanzinstitute ist es benutzerfreundliche, einfache und sichere Bezahlsysteme als Ersatz fr das klassische Bargeld einzusetzen. Whrend das Bezahlen bei Hndlern mit Hilfe von Kredit- und Geldkarten umgesetzt werden kann, ist der direkte Austausch von Betrgen zwischen einzelnen Personen deutlich komplizierter und wird von vielen Systemen nicht vorgesehen. Gerade dieser Punkt ist jedoch fr elektronisches Bargeld von essentieller Bedeutung. Diese sogenannten Peer-to-Peer (P2P) berweisungen verbinden die direkte Anwendung von klassischem Bargeld mit den Vorteilen moderner bargeldloser Systeme. Ein Geldaustausch ist damit jederzeit in Echtzeit mglich und gleichzeitig knnen fortschrittliche Sicherheitsmechanismen angewandt werden. Des Weiteren lassen sich zustzliche Dienste wie die Einsicht von Kontostnden und Sonderangebote mit dem Bezahlsystem verknpfen. Allerdings sind zur Realisierung solcher bargeldloser Systeme Endgerte notwendig, welche gegenber einfachen Geldkarten einen greren Funktionsumfang haben und eigenstndig operieren knnen. Diese Bedingungen werden unter anderem von Mobiltelefonen erfllt. Aus diesem Grund existieren verschiedene Bestrebungen fr die Umsetzung von mobilen Bezahlsystemen auf Handys. In klassischen Mobiltelefonen werden diese Systeme hug wegen der begrenzten technischen Mglichkeiten ohne eine P2P Funktion umgesetzt (vgl. Choi u. a. [2007]). Moderne Smartphones erlauben hingegen neue Kommunikationsformen und bieten eine Plattform fr neue mobile Bezahlsysteme. Besonders die Entwicklung in Nahfunksysteme zur Datenbermittlung kann direkte Geldberweisungen zwischen einzelnen Personen ohne dritte Instanz stark vereinfachen. Smartphones ermglichen mit ihrem wachsenden Funktionsumfang aber auch neue Angrie auf die Plattform. Gerade fr Systeme, welche den Zugri auf nanzielle Mittel ermglichen, ist die Sicherheit jedoch von wesentlicher Bedeutung. Um sowohl der gewnschten Benutzerfreundlichkeit in einer Peer-to-Peer Umgebung gerecht zu werden und gleichzeitig ein sicheres Bezahlen zu ermglichen, baut die vorliegende Arbeit auf das eKaay Verfahren auf. Dieses Verfahren wurde an
Stefan Gfrrer
Peer-to-Peer Payment via NFC 1. Einleitung

der Eberhard-Karls-Universitt Tbingen entwickelt und erlaubt die einfache Umsetzung von sicheren Besttigungen fr Transaktionen (vgl. Borchert [2012a] und Gnther [2011]).
1.2. Ziel der Arbeit

Auf der Basis der zum Zeitpunkt dieser Arbeit aktuellen Smartphones soll ein bequemes mobiles Bezahlsystem mit P2P Funktionalitt entworfen werden. Die Aufgabenstellung erfordert dabei explizit die Nutzung neuer Kommunikationsmedien wie Nahfunk. Voraussetzung ist, dass das entwickelte System von Anwendern leicht bedient werden kann, dabei aber die Sicherheit nicht vernachlssigt wird. Als Grundlage soll das bereits erwhnte eKaay Verfahren dienen. Die Sicherheit muss in einer ausfhrlichen Sicherheitsanalyse belegt werden. Ein Vergleich der Sicherheit und eine Umsetzung der Analyse mit weiteren Verfahren ist ebenfalls notwendig. Damit sollen Gemeinsamkeiten und Unterschiede erforscht und hervorgehoben werden.
1.3. Verwandte Arbeiten

Das eKaay Verfahren wird das erste Mal wissenschaftlich und in groem Umfang in der Arbeit von Gnther [2011] vorgestellt. Diese umfasst auch eine Sicherheitsanalyse des Verfahrens und stellt Lsungen fr aufgedeckte Probleme vor. Die Sicherheit von modernen, mobilen Plattformen im Zusammenhang mit Bezahlsystemen wurde von Agarwal u. a. [2007] und Kadhiwal u. Zulquar [2007] untersucht. Ihre Analysen dienen in der vorliegenden Arbeit als Grundlage fr die Entwicklung eines sicheren Bezahlsystems. Eine Reihe von technischen Lsungen fr mobile Bezahlsysteme werden in der bersichtsarbeit von Mobey Forum Mobile Financial Services Ltd [2010] vorgestellt. Sie stellen einen Kontrast zu auf Software basierten Lsungen in dieser Arbeit dar. Eine Reihe von Wissenschaftlern haben in jngerer Zeit die Umsetzung von mobilen Bezahlsystemen erforscht und Lsungsvorschlge erarbeitet. Diese umfassen zum Teil P2P Verfahren, aber auch Terminal basierte Lsungen. Zu diesen Arbeiten gehren 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 Sicherheitsanalyse aufgegrien und ebenfalls untersucht.
Stefan Gfrrer
Peer-to-Peer Payment via NFC 1.4. Voraussetzungen zum Verstndnis der Arbeit
1.4. Voraussetzungen zum Verstndnis der Arbeit

Die vorliegende Arbeit verwendet eine Reihe von Begrien und Konventionen, welche im Folgenden kurz erlutert werden. Dies dient dem Verstndnis des Lesers. Der Begri mobiles Bezahlsystem bezieht sich im weiteren Verlauf vorwiegend auf Systeme, welche Smartphones als wichtigstes Endgert setzen. Diese Festlegung ist von Bedeutung, da andere Arbeiten mit dem Begri unter anderem auf Systeme mit Geldkarten und hnlichem verweisen und der Begri im Allgemeinen eine sehr breite Bedeutung hat. Um Unklarheiten zu vermeiden, wird die Bedeutung darum fokussiert. Unter einer Peer-to-Peer berweisung wird in diese Arbeit eine berweisung von Geldbetrgen zwischen zwei Personen, welche sich in physikalischer Nhe benden, verstanden. Dies steht im Gegensatz zu klassischen berweisungen in Online Banking Systemen. Die Begrie Geldempfnger und Zahlender beziehen sich auf die beiden Parteien in einer P2P Umgebung. Sie werden Geschlechtsneutral verwendet. Verschiedene Ablufe werden im Laufe dieser Arbeit sowohl textuell als auch grasch dargestellt. Die Grak dient dabei, wie in wissenschaftlichen Arbeiten blich, der zustzlichen Verdeutlichung. Die Nummerierung der einzelnen Schritte in Text und Bild kann divergieren, da im Text hug Schritte logisch zusammengefasst werden. Einzelne Ablufe werden in vergrerten Graken in Anhang A verdeutlicht. Diese sind jedoch nicht zum Verstndnis notwendig, sondern dienen auschlielich der Ergnzung und Vertiefung.
1.5. Aufbau der Arbeit

In Kapitel 2 werden die fr diese Arbeit relevanten Grundlagen und Technologien vorgestellt. Des Weiteren wird eine Einfhrung in mobiles Bezahlen gegeben. In Kapitel 3 folgt der Entwurf des mobilen Bezahlsystems eKaayCash. Dieses Kapitel enthlt noch keine Sicherheitsanalyse zum Verfahren. Sie folgt in Kapitel 4, welches eine Reihe von mobilen Bezahlsystemen ausfhrlich untersucht und Sicherheitsprobleme hervorhebt. Einzelne Aspekte der Implementierung von eKaayCash werden in Kapitel 5 diskutiert. Abschlieend werden in Kapitel 6 noch einmal alle Ergebnisse zusammengefasst, oene Probleme angesprochen und ein Ausblick gegeben.
Stefan Gfrrer
2. Grundlagen und Hintergrnde

Die folgenden Abschnitte vermitteln wichtige Grundlagen und Konzepte fr das Verstndnis der weiteren Arbeit. Sie bilden eine Basis, auf welches in spteren Kapiteln aufgebaut wird.
2.1. eKaay
Ein wiederkehrendes Problem in der Sicherheit von Computersystemen ist die Umsetzung sicherer Anmeldeverfahren. Klassische Abfragen von Benutzername und Kennwort knnen leicht durch Social Engineering gebrochen werden (vgl. Jakobsson u. Myers [2006]). Das Verfahren eKaay versucht diese Problematik durch die Einfhrung eines zweiten Kanals in Form eines Smartphones zu umgehen. Anstelle einer Eingabemaske erhlt der Benutzer auf dem Bildschirm des Computers einen 2D Code (vgl. Abbildung 2.1). Dieser Code enthlt unter anderem eine Challenge in Form einer Nonce. Der Inhalt des 2D-Codes muss dabei nicht geheim bleiben. Fotograert der Benutzer den 2D-Code mit Hilfe des Smartphones und der darauf installierten eKaay App ab, liest diese den Inhalt des Codes zunchst aus. Der Benutzer muss dann die Anmeldung auf dem Smartphone besttigen. Die eKaay App berechnet daraufhin aus der Nonce und einem auf dem Smartphone gespeicherten und mit dem Server geteilten Geheimnis eine Response. Diese Response wird zusammen mit den Benutzerdaten an den Kontoserver bermittelt. Er prft die Response auf Korrektheit und meldet den Benutzer im Erfolgsfall an. Voraussetzung fr den beschriebenen Ablauf ist eine vorherige Registrierung des Benutzerkontos in der eKaay App und damit Hinterlegung der ntigen Kontodaten einschlielich des geteilten Geheimnisses. Einzelne Konten knnen auf dem Handy mit Hilfe einer Personal Identication Number (PIN) gesichert werden. Die Funktionalitt von eKaay wird von zwei Komponenten zur Verfgung gestellt. Einerseits ist auf dem Smartphone die eKaay App installiert. Anderseits muss der Kontoserver ber die Serverkomponente von eKaay verfgen. Diese erzeugt den 2D-Code und initiiert und validiert dann das Challenge-Response-Verfahren. Die App wurde bereits fr Apple iOS und Google Android umgesetzt. Der Server wurde mit PHP entwickelt. Als 2DCode kommt ein Quick Response Code (QR Code) zum Einsatz (vgl. ISO [2000b], Borchert [2012a] und Gnther [2011]).
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde
Abbildung 2.1.: Verwendung von eKaay als alternatives Loginverfahren im Webmail Angebot der Universitt Tbingen (Quelle: ZDV Tbingen [2012]).
Gnther [2011] zeigt in einer Sicherheitsanalyse von eKaay, dass das Verfahren den Anmeldevorgang an sich in der Tat sicherer gestaltet, als zum Beispiel die klassische Anmeldung mit Benutzername und Passwort. Allerdings weist er auch auf eine Reihe von Problemen hin. Ein auf dem Smartphone installiertes Schadprogramm kann in verschiedenen Szenarien das geteilte Geheimnis lesen und damit selbst gltige Anmeldungen generieren. Beispielsweise sind alle auf dem Smartphone gespeicherten Daten nie vollkommen geschtzt (vgl. Abschnitt 2.3). Dieses Sicherheitsrisiko lsst sich durch die Abfrage einer PIN vermindern, jedoch ist auch diese durch ein Schadprogramm angreifbar. Als Lsung fr diese Gefahr schlgt Gnther [2011] die Verwendung einer programmierbaren Karte mit Funkverbindung vor (vgl. Abschnitt 2.2). Das Geheimnis kann auf diese Karte ausgelagert werden. In diesem Szenario leitet das Smartphone die Challenge an die Karte ber die Funkverbindung weiter. Die Challenge wird von der Karte beantwortet und das Smartphone empfngt die generierte Response. Das Geheimnis verbleibt somit auf der Karte und kann von keinem Schadprogramm auf dem Smartphone ausgelesen werden (ebd.). Eine Variante von eKaay ist eKaay TAN, welches zur Besttigung von Transaktionsdaten dient. Es kann unter anderem bei der Besttigung einer berweisung im Onlinebanking verwendet werden. Der Hauptunterschied zum klassischen Anmeldeverfahren ist die Erweiterung der Challenge um die Daten der Transaktion.
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2.1. eKaay

Das Geheimnis besttigt dann nicht nur die Nonce sondern zustzlich die Daten (vgl. Borchert [2012a]). Dieses Verfahren hnelt der Verwendung einer dynamischen Transaction Authentication Number (TAN) (vgl. Baden-Wrttembergische Bank [2006]). Der Ablauf wird im Folgenden am Beispiel einer berweisung im Onlinebanking vorgestellt. Abbildung 2.2 verdeutlicht den Ablauf visuell. 1. Der Benutzer ruft die berweisungsseite auf und erhlt ein Formular mit den notwendigen Daten. Er fllt das Formular aus und sendet es zur Validierung an den Server. 2. Der Server prft die eingegebenen Daten und erzeugt mit Hilfe der Serverkomponente von eKaay einen 2D-Code. Der Code enthlt unter anderem die Nonce und die Transaktionsdaten in einer kompakten, aber fr Menschen lesbaren Form. Zustzlich speichert er smtliche Daten. 3. Der 2D-Code wird anstelle eines TAN-Eingabefelds am Bildschirm des Benutzers angezeigt. Dieser liest den Code mit Hilfe seines Smartphones und der eKaay App ein. 4. Die Applikation zeigt die Transaktionsdaten in ihrer kompakten, lesbaren Form auf dem Bildschirm des Smartphones an. Der Benutzer kann auf diese Weise prfen, ob die vom Server empfangenen und validierten Daten mit der ursprnglichen Eingabe bereinstimmen. Abhngig von der Entscheidung des Benutzers wird der Vorgang anschlieend abgebrochen oder durch Generierung der Response auf dem Smartphone abgeschlossen. 5. Das Smartphone bertrgt die Response ber eine eigene Internetverbindung an den Server. Der Server prft die Response und vergleicht, ob die besttigten Transaktionsdaten mit den ursprnglich empfangenen bereinstimmen. Im Erfolgsfall wird die berweisung ausgefhrt und der Benutzer bekommt eine Besttigung angezeigt. Die Variante eKaay TAN basiert auf dem klassischen eKaay Verfahren. Der einzige Unterschied liegt in der zustzlichen Verwendung der Transaktionsdaten in der Challenge. Damit gelten die Ergebnisse der Sicherheitsanalyse von Gnther [2011] auch fr eKaay TAN. Die Sicherheit einer berweisung wird durch die folgenden beiden Mechanismen erreicht (vgl. Borchert [2012a] und Gnther [2011]). 1. Der Server erhlt zu Beginn alle Daten und kann nach Abschluss prfen, ob der Benutzer diese Daten besttigt hat oder ob sie durch fremden Zugri verndert wurden. 2. Um den Server zu tuschen muss ein Angreifer im Zeitraum zwischen dem Abschicken der Transaktionsdaten durch den Benutzer und dem Empfang durch
Stefan Gfrrer

den Server eine Manipulation durchfhren. Diese Manipulation kann vom Benutzer aber wiederum erkannt werden, wenn er die berweisungsdaten auf seinem Smartphone veriziert. Als Restrisiko verbleibt ein Schadprogramm auf dem Smartphone, welches zunchst den Server tuscht und bei der anschlieenden Verizierung durch den Benutzer eine geflschte Anzeige erzeugt (vgl. Gnther [2011]).
Computer des Kunden 1. Eingabe der berweisung 5. Anzeige des Code 2D Code
2. bertragung der berweisung 4. Challenge in Form des 2D Code 7. Prfung der Daten und Response Generierung 6. Einlesen
3. Validierung und 2D Code Generierung
8. Response 9. Validierung und Ausfhrung der berweisung Smartphone des Kunden
Server mit eKaay
Abbildung 2.2.: Das eKaay TAN Verfahren im Detail. Das Versenden der Besttigung ist nicht enthalten (eigene Darstellung). Eine weitere, fr diese Arbeit relevante, Technik von eKaay ist die Erweiterung eKaay PIN. Sie erweitert das eKaay Verfahren um einen wissensbasierten Schutz. Entgegen klassischer PIN Verfahren wird aber nicht die PIN eingegeben, da diese immer von einem Schadprogramm mitgelesen werden kann. Stattdessen berechnet das Smartphone eine Permutation der Ziern. Diese Permutation basiert auf dem Schlssel des Benutzerkontos und der Challenge und ist somit fr jeden Vorgang individuell. Die Permutation in Form von vertauschten Zahlen in einem Ziernfeld wird dem Benutzer auf dem Handy angezeigt. Im Browser des Computers sieht er des Weiteren ein Zierneingabefeld ohne Beschriftung. Basierend auf der angezeigten Permutation muss der Benutzer die entsprechenden Buttons im Einga-
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2.2. Near Field Communication (NFC)

befeld auswhlen. Im Anschluss bertrgt der Browser die Position und Reihenfolge der ausgewhlten Buttons in kodierter Form an den Server. Dieser hat bereits die Permutation vom Smartphone erhalten und kann mit Hilfe der kodierten Daten die eigentliche PIN wiederherstellen und berprfen (vgl. Borchert [2012a] und Gnther [2011]). In Abbildung 2.3 sind eine Permutation auf dem Smartphone und das dazu gehrige Eingabefeld im Browser dargestellt. Gnther [2011] zeigt, dass eKaay PIN vor einem Schadprogramm auf dem Smartphone des Benutzers schtzt. Damit ist das eKaay Verfahren auch dann sicher, wenn der Schlssel eines Kontos einem Angreifer bekannt ist, da weiterhin das Wissen des Anwenders fehlt (ebd.).
Abbildung 2.3.: Das eKaay PIN Verfahren aus Sicht des Benutzers. Links ist ein Handy mit permutiertem Ziernfeld und rechts das Formular im Browser mit QR Code und Zierneingabefeld ohne Beschriftung dargestellt (Quelle: Borchert [2012a]). Zusammenfassend lsst sich sagen, dass eKaay ein Rahmenwerk fr sichere Anmeldungen und Besttigungen von Daten darstellt. Aufgrund der Verwendung von QR Codes bietet es den Anwendern Vorteile in der Benutzbarkeit und macht das Merken von komplizierten Passwrtern berssig.
2.2. Near Field Communication (NFC)

Near Field Communication (NFC) basiert auf dem Radio-Frequency Identication (RFID) Standard und der Implementierung fr kontaktlose Karten im ISO/IEC 14443 Standard (vgl. ISO [2000a]). Es berfhrt beide Standards auf moderne Smartphones und bietet eine Alternative zu klassischen kontaktlosen Kommunikationsstandards wie Bluetooth. Seine Entwicklung wird aktiv durch das NFC Forum
Stefan Gfrrer

einem Zusammenschluss von verschiedenen Firmen und Interessenteilnehmern wie Sony, Nokia und Philips vorangetrieben (vgl. NFC Forum [2012]). Wie RFID sendet NFC im weltweit unlizenzierten 13.56 MHz Frequenzband und verwendet das im ISO/IEC 18000-3 Standard beschriebene Interface (vgl. ISO [2004]). Die Reichweite von NFC betrgt bis zu zwanzig Zentimeter. In der Praxis ist aber hug ein deutlich geringerer Abstand zwischen den Antennen notwendig (vgl. Gnther [2011] und Van Damme u. a. [2005]). Der NFC Standard verfgt ber drei Modi in denen ein NFC-fhiges Gert betrieben werden kann. Sie unterscheiden sich in der Verteilung der Rollen und dem Sendemodus, d. h. darin ob sich das Gert aktiv oder passiv an der Kommunikation beteiligt. Die Modi werden abhngig von der gewnschten Anwendung ausgewhlt (vgl. Van Damme u. a. [2005]). Card Emulation Mode. In diesem Modus verhlt sich das Gert vollkommen passiv und simuliert das Verhalten einer NFC-fhigen Karte wie beispielsweise MasterCard PayPass Kreditkarten (vgl. MasterCard [2012]). Reader/Writer Mode. Das Gert arbeitet als aktives Lesegert fr RFID oder NFC Tags. Das passive Tag wird mit Hilfe magnetischer Induktion mit der ntigen Energie versorgt. Peer-to-Peer Mode. Zwei NFC Gerte kommunizieren miteinander. Sie knnen dabei sowohl aktiv als auch passiv sein. Es erfolgt eine Rollenverteilung nach dem Master/Slave-Prinzip. NFC untersttzt drei verschiedene Datenraten. Abhngig von der Datenrate kommt eine modizierte Miller-Kodierung mit einem Amplitude Shift Keying (ASK) von hundert Prozent oder eine Manchester-Kodierung mit einem ASK von zehn Prozent zum Einsatz (vgl. Abbildung 2.4). Die modizierte Miller-Kodierung wird nur von aktiven Gerten in der geringsten Datenrate eingesetzt. In allen anderen Fllen arbeiten die Gerte mit der Manchester-Kodierung (vgl. Van Damme u. a. [2005]). Zur Erleichterung der Kommunikation zwischen zwei Endgerten hat das NFC Forum [2012] das NFC Data Exchange Format (NDEF) speziziert. Es beschreibt einen standardisierten Aufbau fr Datenpakete im Nahfunk und muss von jedem NFC-fhigen Gert untersttzt werden (ebd.). Die Benutzerakzeptanz von Nahfunk Systemen ist noch nicht komplett erforscht. Deshalb besteht die Mglichkeit, dass Benutzer dieser Technik ablehnend gegenber stehen. Dies kann mit der Unwissenheit ber die Leserechte eines NFC-fhigen
10
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2.3. Android
Modifizierte Miller-Kodierung, 100% ASK
Manchester-Kodierung, 10% ASK
Abbildung 2.4.: Die von NFC verwendeten Kodierungen (Quelle: Van Damme u. a. [2005]; [bersetzung durch Verfasser]).
Gerts gegenber einem anderen erklrt werden. Eine Studie des Marktforschungsinstituts Heute und Morgen gibt an, dass ein Teil der Befragten die fehlende Transparenz bemngelt (vgl. Unrath [2012]).
2.3. Android
Android ist zum Zeitpunkt der Entstehung dieser Arbeit eines der wenigen mobilen Betriebssysteme, welches NFC untersttzt. Zudem ist es eines der ersten Systeme, fr welches man NFC-fhige Smartphones erwerben kann (vgl. NFC Forum [2012]). Zum Zeitpunkt der Entstehung dieser Arbeit steht die mit Android Version 2.3 Gingerbread eingefhrte Programmierschnittstelle (API) fr Nahfunk zur Verfgung (vgl. Google [2012a]). Eine vereinfachte API fr Peer-to-Peer Verbindungen wird mit Android Version 4 Ice Cream Sandwich verfgbar werden. Die Schnittstelle aus Version 2.3 bleibt aber erhalten und ist auch in spteren Versionen gltig (vgl. Google [2012b]). Android sichert Daten auf dem Smartphone durch eine Reihe von Mechanismen ab. Die grundlegende Sicherheit entsteht durch eine strikte Abschottung einzelner Applikationen von einander. Dazu gehren neben der Kommunikation zwischen einzelnen Programmen auch der Zugri auf das Dateisystem. Zustzlich werden einzelne Funktionen nur durch explizite Anfrage und Erlaubnis durch den Benutzer bewilligt. Beispielsweise muss eine Applikation fr die Nutzung der NFC Schnittstelle freigegeben werden. Diese Sicherheitsmechanismen knnen aufgrund von bisher unerkannten Fehlern umgangen werden. Zustzlich knnen Benutzer das Betriebssystem unter bestimmten Bedingungen neu installieren und ihrem Benutzerkonto
Stefan Gfrrer
11

umfassende Rechte erteilen. Eine Applikation, die mit diesen Rechten ausgefhrt wird, kann normale Beschrnkungen umgehen (vgl. Google [2012d]). Applikationen unter Android mssen aufgrund der Abschottung bestimmte Ressourcen oder Rechte fr fremde Informationen explizit anfordern. Beispiele dafr sind der Zugri auf Netzwerkverbindungen oder die Daten des Telefonbuchs. Die Anforderung geschieht mittels der Datei AndroidManifest.xml, welche in jeder App vorhanden sein muss. Diese Datei enthlt Metainformationen ber die Applikation, deniert die Rechte der Applikation unter der Bedingung, dass der jeweilige Benutzer diese Rechte vergibt und enthlt Filter und Regeln fr den Umgang von Android mit der Applikation (vgl. Google [2012c]).
2.4. Mobile Payment (MP)

Durch die Verbreitung von Funktelefonen wchst auch die Nutzung derselben zum Bezahlen von beliebigen Gtern. Anfangs wurde dies durch Belastung der normalen Telefonrechnung erreicht. Die Kommunikation mit dem Dienstanbieter und gleichzeitige Bezahlung erfolgte unter anderem mit Kurznachrichten (SMS), deren Einzelpreis dem Kaufobjekt entsprachen. Besonders im asiatischen Raum sind mobile Bezahlsysteme erfolgreich (vgl. [Choi u. a. 2007, Seite 12]). Der Vorteil dieser Systemen liegt in der vereinfachten Bedienung gegenber klassischem Geld und Geldkarten. Das Handy wird in vielen Fllen leicht erreichbar getragen und ermglicht so einen wesentlich schnelleren Bezahlvorgang. Dieser Vorteil steigt mit wachsender Leistungsfhigkeit und technischen Fhigkeiten jngerer Smartphones (vgl. Mobey Forum Mobile Financial Services Ltd [2010], Karnouskos [2004] und Choi u. a. [2007]). Mobile Bezahlsysteme lassen sich in zwei grundlegende Kategorien aufteilen. Diese unterscheiden sich in der Verwaltung und Durchfhrung von berweisungen (vgl. Gao u. a. [2009]). Konto basiert. Das Benutzerkonto beim Anbieter der Bezahllsung wird an ein Bankkonto bei einer dritten Partei meist einer reellen Bank gebunden. Der Anbieter und die Bank knnen dabei dieselbe Partei sein, fr den Ablauf spielt das aber keine Rolle. Der Dienstanbieter agiert mit seinem System als eine Art Koordinator zur Bank. Abhngig vom zugrunde liegenden Prinzip werden die eigentlichen berweisungen bei der Bank zeitversetzt zur mobilen Transaktion durchgefhrt. Die mobile Transaktion innerhalb des Systems des Dienstanbieters reprsentiert eine virtuelle und von allen beteiligten Parteien, inklusive Geldempfnger und Zahlender, als reell akzeptierte berweisung.
12
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2.4. Mobile Payment (MP)

E-Wallet. Eine E-Wallet ist eine Art von virtuellem Geldbeutel, welcher sowohl reelle Geldbetrge als auch die fr eine berweisung ntigen Kontodaten enthalten kann. Abhngig von der Variante kann die eigentliche E-Wallet mit einem Geldbetrag aufgeladen werden hnlich dem Guthaben in Telefonsystemen oder sie wird mit einem Konto bei einer Bank verlinkt. Der letztere Fall entspricht einem bergang zum bereits beschriebenen, Konto basierten System. E-Wallet Lsungen unterscheiden zwei Umsetzungen. Einerseits kann die eigentliche Wallet beim Dienstanbieter auf dem Server verwaltet, anderseits kann sie auch auf dem gewnschten mobilen Endgert abgelegt werden (vgl. Abschnitt 4.5). In letzterem Fall muss die Wallet besonders vor Fremdzugrien geschtzt werden. Wie zu Beginn der Arbeit angesprochen ist die Benutzerfreundlichkeit ein wichtiges Kriterium fr den Erfolg eines mobilen Bezahlsystems. Dazu gehren sowohl die Bedienung der Applikation als auch der Austausch der notwendigen Kontoinformationen. Eine manuelle Eingabe einzelner Daten ist in vielen Fllen langsamer als das automatische Einlesen mittels einer einfachen Schnittstelle wie NFC in neueren Smartphones. Zustzlich ermglicht bargeldloses Zahlen mit einer eigenstndigen Hardware in Form des Smartphones die Mglichkeit, weitere Dienste und vereinfachte Ablufe anzubieten (vgl. Massoth u. Bingel [2009] und Karnouskos [2004]). Beispielsweise knnen Informationen ber Sonderangebote direkt auf das Handy bertragen werden (ebd.). Gao u. a. [2009] schlgt das Einkaufen ohne Kasse vor (ebd.). Des Weiteren ist die Sicherheit sowohl fr den Dienstanbieter als auch fr den Kunden von Bedeutung. Mobile Bezahlsysteme sind in vielen Fllen hnlich angreifbar wie klassische Onlinebanking Angebote. Besonders Social Engineering bedeutet eine Gefahr, da die Mehrheit der Systeme eine Form von Anmeldung beim Dienstanbieter erfordert. Hinzu kommt die Gefahr durch die verwendete Plattform. Ein Handy kann inklusive der darauf gespeicherten Daten verloren gehen oder gestohlen werden. In beiden Fllen ist ein Missbrauch der Informationen mglich. Mobey Forum Mobile Financial Services Ltd [2010] weist aber auch auf neuere Mechanismen hin, welche gerade vor letzterem Risiko durch physikalischen Schutz absichern sollen. Beispielsweise schlgt es die Verwendung von Secure Elements (SE) vor (ebd.). Verschiedener Angrispunkte werden in Abschnitt 4.2 ausfhrlich behandelt. Die Vielzahl der mobilen Bezahllsungen basiert auf Point of Sale (POS) Systemen. Ein POS besteht meist aus einem Terminal, dass ber Schnittstellen mit der Kasse und dem Identikationselement der Geldkarte, dem Smartphone usw. des Kunden kommuniziert und die berweisung durchfhrt (vgl. Choi u. a. [2007]). POS Terminals bestehen grtenteils aus einer eigenstndigen und speziell fr das
Stefan Gfrrer
13

Bezahlen entwickelten Hardware, die das sichere berweisen in einem prinzipiell unsicheren Umfeld ermglicht (vgl. EMVCo [2008]). Andere Bezahlsysteme ermglichen die direkte berweisung zwischen zwei Kunden des Dienstleisters. Beim sogenannten Peer-to-Peer Payment werden Transaktionen direkt zwischen zwei Personen durchgefhrt. Teilweise wird auch der Begri des Consumer-to-Consumer (C2C) Payment verwendet (vgl. [Choi u. a. 2007, Seite 6.]). Im Gegensatz zur klassischen berweisung im Onlinebanking bezieht eine P2P berweisung die physikalische Nhe beider Parteien mit ein. Die rudimentre Form einer P2P Bezahlung ist das Zahlen mit reellem Geld in Mnz- oder Papierform. In mobilen Systemen tritt das Smartphone an die Stelle des Geldes und es werden keine physikalischen Objekte bergeben, sondern es ndet ein Informationsaustausch zwischen den Smartphones statt. Die Benutzerinteraktion beschrnkt sich dann auf die Initiierung des Vorgangs, die Eingabe der Daten meist nur der Betrag und die manuelle Besttigung (vgl. Karnouskos [2004]). Eine P2P berweisung kann sowohl vom Zahlenden als auch vom Geldempfnger ausgehen. Im Folgenden wird der Ablauf ausgehend vom Zahlenden beschrieben. Abbildung 2.5 visualisiert dies. 1. Der Zahlende drckt seinen Zahlungswunsch durch Erstellung einer Anfrage aus. Diese kann bereits den Betrag enthalten. Die Anfrage wird an das Smartphone des Geldempfngers bertragen. 2. Sofern noch kein Betrag in der Anfrage festgelegt wurde, setzt ihn der Geldempfnger ein und leitet die Anfrage an den Server des Dienstanbieters weiter. 3. Der Server veriziert die Anfrage und stellt eine Besttigungsanfrage an den Zahlenden. Dabei handelt es sich im Normalfall um eine Form von Challenge, welche die Transaktionsdaten enthlt. 4. Der Zahlende besttigt die Zahlung, die im Anschluss vom Server durchgefhrt wird. Des Weiteren der Ablauf initiiert durch den Geldempfnger und grasch dargestellt in Abbildung 2.6. Da eine berweisung nicht erst ber den Geldempfnger transferiert werden muss, verringert sich die Anzahl der notwendigen Schritte. 1. Der Geldempfnger erstellt eine Zahlungsanfrage mit dem gewnschten Betrag und bermittelt diese an den Zahlenden. 2. Der Zahlende prft die Anfrage, besttigt sie und leitet die besttigte Zahlungsanfrage an den Server weiter.
14
Stefan Gfrrer
Peer-to-Peer Payment via NFC 2.4. Mobile Payment (MP)

3. Der Server prft die eingegangene berweisung und fhrt sie im Erfolgsfall aus. Die beschriebene Variante kommt ohne Challenge von Seiten des Servers aus. Es ist aber auch mglich, dass der Geldempfnger hnlich wie beim ersten Verfahren zuerst eine Challenge vom Server abfragt und diese dann zusammen mit den Transaktionsdaten an den Zahlenden bermittelt.
1a. Zahlungsanfrage Zahlender Geldempfnger
3a. Besttigungsanfrage
3b. Besttigung
1b. Zahlungsanfrage
4. Abschluss der Transaktion Zahlungsserver
2. Verifikation
Abbildung 2.5.: Eine Peer-to-Peer berweisung ausgehend vom Zahlenden (Quelle: Agarwal u. a. [2007]; [bersetzung durch Verfasser]).
Stefan Gfrrer
15
1. Zahlungsanfrage Geldempfnger Zahlender
2. Besttigte Zahlungsanfrage
3. Abschluss der Transaktion Zahlungsserver

Abbildung 2.6.: Eine Peer-to-Peer berweisung ausgehend vom Geldempfnger (eigene Darstellung).
16
Stefan Gfrrer
3. Peer-to-Peer Payment mit eKaay

Der erste Teil dieser Arbeit stellt den Entwurf eines mobilen Peer-to-Peer Bezahlsystems auf der Basis von eKaay vor. Es werden zunchst eine Reihe von Zielen fr das fertige Produkt formuliert. Daraufhin folgt die Vorstellung einer Testumgebung, welche an reelle Banksysteme angelehnt ist. Anschlieend wird zunchst der Entwurf des reinen Bezahlsystems und dann eine Erweiterung fr Online Shop Systeme erlutert. Den Abschluss bildet eine Diskussion ber das Verfahren. Eine Sicherheitsanalyse folgt in Kapitel 4 in Abschnitt 4.3.
3.1. Formulierung der Ziele

Vor dem Entwurf eines P2P Bezahlsystems mssen die Rahmenbedingungen festgelegt werden. Sie denieren die Ziele, welche zum Schluss erfllt sein mssen. Des Weiteren geben sie einen Leitfaden vor, der beim Entwurf untersttzen kann. Grundarchitektur ist eKaay. Zur Umsetzung eines Bezahlsystems eignet sich eKaay, da es mit eKaay TAN bereits eine notwendige Komponente zur Verfgung stellt. Mittels eKaay TAN ist ein Challenge-Response-Verfahren mglich, welches Transaktionsdaten enthlt (vgl. Abschnitt 2.1). Auf diese Weise lassen sich berweisungen sicher verizieren. Kommunikation mittels NFC. Zur Erforschung von Near Field Communication und der Prsentation einer Anwendung soll das Bezahlsystem den Einsatz von NFC zur Kommunikation ermglichen. In bereits bestehenden Arbeiten konnte gezeigt werden, dass NFC insbesondere im Bereich der mobilen Bezahlsystemen Vorteile beispielsweise in Sicherheit und Benutzerfreundlichkeit gegenber anderen Technologien aufweist (vgl. Ondrus u. Pigneur [2007]). Da die Applikation per Denition einen P2P Kontakt vorsieht, sollte der gleichnamige Peer-to-Peer Mode (vgl. Abschnitt 2.2) verwendet werden. Kompatibilitt mit iOS und Android. Aus der Anforderung eines mobilen Betriebssystems, welches sowohl NFC untersttzt als auch einen Client fr eKaay besitzt, ergibt sich die Verwendung von Android als mobile Plattform. Trotzdem soll auch die aus eKaay bekannte Kompatibilitt mit iOS bestehen bleiben.
Stefan Gfrrer
17
Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay

Aus diesem Grund darf sich die Kommunikation nicht nur auf NFC beschrnken, sondern muss auch Alternativen bieten. Der in eKaay verwendete QR Code bietet sich fr diesen Zweck an.
nderungen an der Architektur vermeiden. Die Implementierung des eigentlichen Bezahlverfahren muss mglichst ohne nderung der Architektur durchgefhrt werden. Dies betrit insbesondere eKaay. Dies setzt eine Trennung des Bezahlsystems von eKaay voraus und ermglicht so eine unabhngige Weiterentwicklung beider Systeme.
3.2. Entwurf einer Testumgebung
Damit das Bezahlsystem unter realistischen Bedingungen getestet werden kann, wird ein einfaches Onlinebanking System umgesetzt. Es dient als Testumgebung und stellt die grundlegende Architektur auf Seiten der Bank. Das System wird im Folgenden als Server bezeichnet. Er bietet ein einfaches, auf einer Datenbank basierendes Kontensystem an. Jedes Konto erfordert individuelle Anmeldedaten und besitzt ein Guthaben. berweisungen sind innerhalb der Bank von einem Konto zu einem anderen mglich. Dafr steht ein berweisungsformular zur Verfgung, welches neben Empfnger und Betrag auch die Eingabe eines Verwendungszweck vorsieht. Anstelle eines klassischen TAN Verfahrens wird der Einfachheit halber das eKaay TAN Verfahren eingesetzt. Es ermglicht die Besttigung ohne externe TAN Liste oder dynamische TAN Systeme wie z. B. einem TAN Generator. Die Anmeldung zum Konto ist sowohl durch manuelle Eingabe von Benutzername und Passwort als auch durch eKaay mglich. Um eKaay einsetzen zu knnen, wurde die Serverkomponente von eKaay nach Anleitung parallel zum Server der Bank installiert (vgl. Borchert [2012a]). Damit eine Anbindung des Kontos an eKaay mglich ist, kann ein Benutzer in seinen persnlichen Kontoeinstellungen das Smartphone und damit auch das Konto fr eKaay registrieren. Mit Ausnahme der Anmeldung und der TAN-Abfrage implementiert die Bank keinerlei Sicherheitsmechanismen wie sie fr Finanzinstitute vorgeschrieben sind. Dies ist nicht Inhalt dieser Arbeit und wrde den Rahmen bersteigen. Um dem Zweck einer Testumgebung gerecht zu werden, stellt der Server eine Reihe von Ausgaben zur Verfgung. Diese Ausgaben ermglichen die Beobachtung aller Konten und aller durchgefhrten Transaktionen. Der Server ist wie eKaay komplett in PHP entwickelt. Eine bersicht ist in Anhang A in Abbildung A.1.
18
Stefan Gfrrer
Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash
3.3. Entwurf von eKaayCash

Dieser Abschnitt widmet sich dem Entwurf des Peer-to-Peer Verfahrens. Zunchst wird das Verfahren vorgestellt und das Gesamtkonzept beschrieben. Im Anschluss werden die Umsetzung der Kommunikation und ein zustzlicher Sicherheitsmechanismus erlutert. Das Verfahren wird ab diesem Zeitpunkt als eKaayCash bezeichnet. Die Partei, welche eKaayCash als Bezahlsystem anbietet, erhlt im Folgenden die Bezeichnung Dienstanbieter.
3.3.1. Verfahren
Zur Vereinfachung wird eKaayCash als ein Konto basierendes mobiles Bezahlsystem umgesetzt. Wie in Abschnitt 2.4 beschrieben, knnen in Konto basierenden Verfahren die eigentliche Bank und der Dienstanbieter fr das mobile Bezahlsystem ein und dieselbe Partei sein. Das Verfahren muss in diesem Fall keine eigene Verwaltung von Guthaben implementieren, da es lediglich eine Weiterleitung der besttigten berweisungen an die Bank durchfhrt. Das hat den Vorteil, dass das Verfahren die Verizierungsmechanismen der Bank verwenden kann. Diese Festlegung folgt den in Abschnitt 3.1 beschriebenen Regeln. Insbesondere ist keine Implementierung einer gesonderten Verizierung in eKaay notwendig. Unabhngig vom eigentlichen Ablauf muss das Verfahren eine Reihe von Daten von den Benutzern erfassen. Essentiell sind der Bezeichner des Geldempfngers, der Bezeichner des Zahlende und der Betrag. Optional und blichen berweisungsformularen folgend wird auch die Eingabe eines Verwendungszweck ermglicht (vgl. ZKA [2009]). Das entstehende Formular kann auf zwei Arten dargestellt werden. Es kann entweder direkt in einer Applikation auf dem Smartphone des Benutzers integriert werden. Das erhht jedoch den Aufwand im Falle einer Portierung auf andere Betriebssystem. Oder eine einfachere Variante ist die Darstellung einer in die Bank integrierten Webseite. In diesem Fall entspricht das Formular weitestgehend einem klassischen berweisungsformular im Onlinebanking. Das Formular kann dann nicht nur auf Smartphones in einem mobilen Umfeld genutzt werden, sondern auch von einem klassischen Computer mit Bildschirm. Lediglich die zweite beteiligte Partei bentigt ein Smartphone. Im Gegensatz zu einem klassischen berweisungsformular mssen nicht alle Daten manuell abgefragt werden. Im klassischen Verfahren ist der Zahlende bekannt, da er die berweisung erstellt. In einer mobilen Variante mit eKaay fllt zustzlich die zweite Partei weg, da sie durch das in der eKaay App gespeicherten Konto identiziert werden kann (vgl. Abschnitt 2.1). Das Formular muss dann nur noch den Betrag und den optionalen Verwendungszweck abfragen (vgl. Abbildung 3.1).
Stefan Gfrrer
19
P2P berweisung
Betrag: 0,00 Verwendungszweck (optional):
Abbildung 3.1.: Formular fr eine mobile berweisung. Geldempfnger und Zahlender werden automatisch erfasst (eigene Darstellung). Mit der Festlegung der Art des mobilen Bezahlsystems und dem Entwurf eines Formulars fr mobile berweisungen auf Seiten der Bank, kann der eigentliche Ablauf einer Transaktion bestimmt werden. Wie in Abschnitt 2.4 erlutert, kann eine Transaktion vom Zahlendem oder vom Geldempfnger ausgehen. Der in Abbildung 2.2 dargestellte Ablauf fr eKaay TAN entspricht der in Abschnitt 2.4 beschriebenen, vom Geldempfnger ausgehenden, Variante. Ein Ablauf vom Geldempfnger aus ist auch aufgrund des Webformulars notwendig. Beim Aufruf des Formulars hat der Geldempfnger sich am Server der Bank angemeldet. Nach Eingabe aller Daten erhlt der Server somit Informationen ber Geldempfnger, Betrag und Verwendungszweck. Durch die Besttigung der eKaay TAN Challenge durch den Zahlenden erhlt der Server den fehlenden Identikator (ID) des Zahlenden und kann im Anschluss eine vollstndige berweisung durchfhren. Der Ablauf mit eKaay ist zwar auch vom Zahlenden ausgehend durchfhrbar, in diesem Fall muss er aber die ID des Geldempfngers entweder manuell eingeben oder es ist eine zustzliche Kommunikation zwischen beiden Smartphones notwendig, welche den ID Austausch beinhaltet. Des Weiteren kann der vorgeschlagene Ablauf in einer spteren Variante von eKaayCash verwendet werden (vgl. Abschnitt 3.4). Der im Folgenden beschriebene und in Abbildung 3.2 grasch dargestellte Ablauf bercksichtigt somit die in Abschnitt 3.1 festgelegten Punkte Grundarchitektur und Vermeidung von nderungen in derselben. Eine ausfhrliche Darstellung bendet sich im Anhang A in Abbildung A.2. 1. Der Geldempfnger ruft das berweisungsformular auf und gibt den Betrag und optional den Verwendungszweck ein. Er sendet das Formular an den Server. 2. Der Server liest den Identikator des Geldempfnger aus. Aus ID, Betrag und Verwendungszweck generiert er unter Verwendung von eKaay eine Challenge und bertrgt diese in Form eines QR Codes oder kodiert fr eine bertragung via NFC an den Geldempfnger.
20
Stefan Gfrrer

3. Die Challenge wird auf dem Bildschirm des Empfngers angezeigt. Sie kann jetzt mit Hilfe des QR Code oder via NFC an das Smartphone des Zahlenden versandt werden. 4. Das Smartphone des Zahlenden zeigt die Transaktionsdaten an. Der Zahlende kann die Informationen berprfen und ablehnen oder besttigen. Im Fall einer Besttigung wird aus der Challenge und dem Geheimnis des Zahlenden die Response erzeugt und zusammen mit der ID des Zahlenden an den Server verschickt. 5. Der Server prft die Response und die Transaktion im Gesamten. Im Erfolgsfall fhrt er sie aus. Sowohl der Geldempfnger als auch der Zahlende erhalten eine Besttigung.
3. Challenge von eKaay TAN Geldempfnger Zahlender 4. Prfen und Besttigen 2. Challenge von eKaay TAN 5. Response
1. berweisungsformular
6. Abschluss der Transaktion
Server der Bank
Abbildung 3.2.: Ablauf einer Transaktion mittels eKaayCash. Besttigungen nach erfolgreicher Durchfhrung an beide Parteien sind der bersicht wegen nicht enthalten (eigene Darstellung).
3.3.2. Peer-to-Peer Kommunikation

In einem Peer-to-Peer System spielt die Kommunikation eine wichtige Rolle. Gegenber einem klassischen Client-Server-Modell steht die Rollenverteilung nicht fest, sondern muss aus dem Kontext bestimmt werden. Dies ergibt hug wechselnde
Stefan Gfrrer
21

Rollen (vgl. Mahlmann u. Schindelhauer [2007]). Der im vorherigen Abschnitt vorgestellte Ablauf vereinfacht das Szenario, da zwischen beiden Benutzern nur eine Kommunikation in eine Richtung stattndet. Diese Kommunikation bertrgt die Challenge vom Smartphone des Geldempfngers auf das Smartphone des Zahlenden. Eine Besttigung des erfolgreichen Empfangs ist nicht ntig, da beide Parteien in physikalischer Nhe zueinander stehen und somit den Vorgang im Fall eines Fehlers jederzeit neu starten knnen. Aus dem eKaay Verfahren ergibt sich der Datenaustausch mit Hilfe eines QR Codes. Er wird nach vollstndigem Ausfllen des berweisungsformulars vom Server erzeugt und auf dem Bildschirm des Geldempfngers angezeigt. Der QR Code enthlt in der Variante eKaay TAN neben Metadaten fr das Verfahren eine Session-ID und einen Text. Der Text ist eine lesbare Form der berweisungsdaten und bildet zusammen mit der Session-ID die Challenge. In Tabelle 3.1 wird der vollstndige Inhalt eines QR Codes von eKaay TAN vorgestellt. Syntax Versionsnummer: Modus: Untermodus: Session-ID: Server-Name: Benutzer-ID: Text: Beispiel EKAAY V1 TAN 2F h4U2jsin89iQalP9 www.ekaay.com/Foto-PIN 12121212 Bitte bestaetigen Sie folgende Ueberweisungsdaten: Kontonummer: 272625311 Bankleitzahl: 20052222 Betrag: 20,45 Euro Tabelle 3.1.: Syntax der Daten von eKaay TAN aus einem QR Code (Quelle: Borchert [2012a]).
Wie in Abschnitt 2.1 dargelegt, muss der QR Code vom Zahlenden unter Verwendung der eKaay App abfotograert werden. Die App liest anschlieend die enthaltenen Daten aus und fhrt den nchsten Schritt des eKaay TAN Verfahrens durch. Da die Applikation fr diesen Zweck nicht angepasst werden muss, ist eKaayCash aus diesem Grund sowohl mit Android basierten, als auch mit iOS basierten Smartphones kompatibel. Damit ist der Aspekt der Kompatibilitt aus Abschnitt 3.1 erfllt. Das zweite Kommunikationsmedium ist die bertragung mittels Near Field Communication. Um den QR Code einzulesen mssen die Smartphones in einer bestimm-
22
Stefan Gfrrer

te Art und Weise zueinander gehalten werden. Dadurch wird jedoch die Benutzerfreundlichkeit der Anwendung verringert. Eine einfachere Bedienung ermglicht NFC, da es lediglich eine physikalische Nhe beider Gerte fr einen kurzen Zeitraum bentigt. Die Haltung ist dabei unspezischer als bei der Verwendung des QR Code. Damit NFC im bestehenden Ablauf verwendet werden kann, ist eine Erweiterung von eKaay ntig. Dazu wird in die Webseite, welche den QR Code anzeigt, ein Link integriert. Er enthlt die Daten fr die bertragung via NFC. Es handelt sich dabei um dieselben Informationen wie in Tabelle 3.1. Sie werden gem dem Standard fr Uniform Resource Locators (URL) kodiert (vgl. Lee u. a. [1994]). Des Weiteren wird der Link mit einem fr eKaayCash festgelegten Scheme ausgezeichnet. Die Form eines Scheme wurde von Lee u. a. [1994] deniert. Um den Anforderungen des Standards zu entsprechen, wurde der Begri ekaaycash in Kleinbuchstaben als aussagekrftiges Scheme gewhlt. In Listing 3.1 ist der Beginn eines Links mit vollstndigem Scheme dargestellt. Er wird vom Server nur in den Quellcode integriert, wenn ein NFC-fhiges Endgert die Webseite aufruft. Aufgrund von Beschrnkungen durch viele Hersteller kann die Untersttzung anhand des User-Agent nur eingeschrnkt erkannt werden (vgl. Bray [2010]). Der Link wird aus diesem Grund auf jedem Smartphone angezeigt, welches Android als Betriebssystem angibt. Die serverseitige Implementierung von NFC ist damit vollstndig.
1
ekaaycash://EKAAY%250D%250AV1%250D%250ASESAME (...)
Listing 3.1: Beispiel fr einen eKaayCash NFC Link kodiert gem Lee u. a. [1994] (eigene Darstellung). Zur Benutzung von NFC muss der Anwender nur diesen Link ausfhren. Dies startet automatisch die eKaay App aufgrund folgender Erweiterung. Die Erweiterung verknpft die App mit dem implementierten Scheme. Dazu wird das in Abschnitt 2.3 vorgestellte Manifest um einen Filter fr benutzerdenierte URL Schemes erweitert. Der Filter gibt an, dass das Programm ein neues Scheme registriert und dieses verarbeiten kann. Das Betriebssystem erhlt damit die Information, welches Programm bei Aufruf eines bestimmten Schemes ausgefhrt werden muss. Wurde der NFC Link von der eKaay App empfangen und wurden die kodierten Nutzdaten extrahiert, knnen diese mittels NFC bertragen werden. Dazu werden die Nutzdaten dekodiert und in eine Nachricht nach dem NFC Data Exchange Format eingebettet (vgl. Abschnitt 2.2). Diese wird anschlieend an den NFC Adapter von Android bermittelt, welcher sie im Fall eines Kontakts bertrgt. Die App aktiviert gleichzeitig den Empfang von Nachrichten. Auf diese Weise mssen sowohl der Geldempfnger als auch der Zahlende keine weiteren Schritte unternehmen. Die Datenbertragung ndet statt, sobald sich beide Smartphones in einem ausreichend geringen Abstand zueinander benden.
Stefan Gfrrer
23

Die in diesem Abschnitt vorgestellten nderungen erfllen das Kriterium der Verwendung von NFC in Abschnitt 3.1. Sie erfordern zwar geringfgige Anpassungen an der Serverkomponente von eKaay und an der Applikation und widersprechen somit der Vermeidungen von nderungen, allerdings sind die nderungen vollstndig optional. Die Verwendung von NFC erhht die Benutzerfreundlichkeit fr die Anwender durch eine Vereinfachung der Bedienung und zeigt Vorteile gegenber anderen 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 einer PIN zur Besttigung der Transaktion verbessert werden. Die Eingabe einer PIN vermindert jedoch wiederum die Benutzerfreundlichkeit. Zudem ist sie bei Kleinstbetrgen hug nicht notwendig, da der Aufwand fr einen Angreifer hher zu bewerten ist, als der Gewinn aus diesen Summen. Im Zuge der Einfhrung des kontaktlosen girogo Verfahrens hat die Deutsche Kreditwirtschaft [2012] eine Hchstgrenze von zwanzig Euro fr Transaktionen ohne PIN festgelegt. Hhere Betrge mssen durch eine klassische Transaktion mit Eingabe der PIN versandt werden. Dieses Prinzip verbindet Benutzerfreundlichkeit mit einer hohen Sicherheit (ebd.). In das eKaayCash Verfahren kann derselbe Mechanismus integriert werden. Anstelle einer normalen PIN, welche von einem Schadprogramm ausgelesen werden kann, verwendet es jedoch das eKaay PIN Verfahren (vgl. Abschnitt 2.1). Nach Besttigung der Transaktion durch den Zahlenden stellt die eKaay Server Komponente eine Anfrage an den Server des Dienstanbieters, ob eine PIN fr die vorliegende berweisung notwendig ist. Diese Funktionalitt ist bereits in eKaay integriert und bentigt dementsprechend keine weitere nderungen am System. Der Server des Dienstanbieter muss auf Basis der bertragenen Parameter, welche unter anderem die Transaktions ID enthalten, entscheiden ob eine PIN notwendig ist. Wie bei girogo wird als Entscheidungsgrund der Betrag mit einem Grenzwert verglichen. Mit diesem Ablauf sind allerdings weitere Kriterien umsetzbar. Beispielsweise kann der Dienstanbieter bei einer groen Anzahl kleinerer Betrge innerhalb eines kurzen Zeitraums ebenfalls eine PIN verlangen. Die vorgeschlagene Erweiterung verbessert die Sicherheit des eKaayCash Verfahrens ohne nderungen am zugrundeliegenden System. Dabei ist es exibel erweiterbar. Durch die Verwendung von eKaay PIN kann die PIN zudem nicht durch ein Schadprogramm auf dem Handy gestohlen werden.
24
Stefan Gfrrer
Peer-to-Peer Payment via NFC 3.4. Erweiterung fr Online Shop Systeme
3.4. Erweiterung fr Online Shop Systeme

In seiner beschriebenen Form ist eKaayCash ein vollwertiges mobiles Bezahlsystem mit Peer-to-Peer Funktionalitt. Seine Verwendbarkeit kann allerdings noch erweitert werden. Zu diesem Zweck wird in diesem Abschnitt eine Anpassung vorgenommen, welche die Bezahlung mittels eKaayCash in Online Shop Systemen ermglicht. Zur Demonstration wird ein einfacher Shop implementiert. Er speichert neben beschreibenden Informationen zum Beispiel Bild und Artikelbeschreibung auch einen kurzen Text als Verwendungszweck in einer berweisung und den Preis. Aufgrund des folgenden Aufbaus der Shop Komponente von eKaayCash wird auf einen Warenkorb oder hnliche Bestellformulare verzichtet. Der Online Shop wird komplett ohne Benutzerkonten umgesetzt und bentigt auer bei eKaayCash selbst keine weitere Registrierung. Im Gegensatz zum reinen P2P Verfahren fllt nicht ein Mensch das berweisungsformular aus. Aus diesem Grund wird es so angepasst, dass auch von einer Software berweisungen generiert werden knnen. Das Programm auf dem Server, welches das Formular verarbeitet, wird darum um einen zustzlichen Parameter erweitert. In der ursprnglichen Variante erwartet das Programm den Betrag und den optionalen Verwendungszweck. Dazu kommt die ID des Geldempfngers, welche automatisch ausgelesen wird, da der Geldempfnger sich zuvor anmelden muss. Die Anmeldung entfllt bei einem Online Shop und wird durch einen neuen Parameter fr die ID des Shops also des Geldempfngers ersetzt. Das Konto mit dieser ID muss zuvor beim Dienstanbieter fr die Online Shop Erweiterung aktiviert werden, andernfalls wird die berweisung nicht erzeugt. Mit der beschriebenen nderung kann der Server des Shopanbieters beim Aufruf der Webseite fr jeden Artikel eine Transaktion generieren. Diese kann beispielsweise direkt neben dem jeweiligen Artikel platziert werden (vgl. Abbildung 3.3). Ein Kunde kann diesen Artikel kaufen und gleichzeitig bezahlen in dem er mit eKaay den jeweiligen QR Code einliest. Sofern die Webseite des Shops auf einem Smartphone angezeigt wird, ist auch die Verwendung von NFC zur Datenbertragung mglich. Nach der Durchfhrung einer Transaktion, d. h. nach Kauf durch einen Kunden, sendet der Server des Dienstanbieters eine Besttigung fr die Bezahlung an den Server des Online Shops. Diese Besttigung enthlt die ID des Zahlenden, den Betrag, den Verwendungszweck und den Zeitpunkt der berweisung. ber eine weitere Schnittstelle kann der Shop eine Anfrage an den eKaayCash Server senden und die Echtheit der Besttigung verizieren. Ein vergleichbares Verfahren wird von PayPal
Stefan Gfrrer
25
Abbildung 3.3.: Beispiel fr einen Artikel mit der dazugehrenden eKaayCash Transaktion zum gleichzeitigen Kaufen und Bezahlen (eigene Darstellung). angeboten (vgl. PayPal [2012c]). Wie in der Sicherheitsanalyse noch deutlich werden wird (vgl. Abschnitt 4.3.1.2), ist diese Prfung zwingend notwendig. Fr die Art der Kontrolle existieren verschiedene Mglichkeiten. So ist auch die Verwendung eines Public-Key-Verfahrens denkbar. Die vorliegende Arbeit hat, der Vereinfachung wegen, das oben beschriebene Verfahren umgesetzt. Der folgende Ablauf beschreibt einen Einkauf mit Hilfe von eKaayCash in einem Online Shop. Die Generierung der Transaktion und der Challenge ist nicht enthalten, da sie mit Abbildung 3.2 bereinstimmt. Der Ablauf beginnt mit dem Einlesen der Challenge durch den Zahlenden. Er ist in Abbildung 3.4 grasch dargestellt. In Anhang A in Abbildung A.3 bendet sich eine Grak des vollstndigen Ablaufs. 1. Der Kunde liest den QR Code mit seinem Smartphone ein und besttigt den Kauf durch die Besttigung der Transaktion. 2. Die erzeugte Response wird an den Server des Dienstanbieters bertragen und veriziert. Im Erfolgsfall fhrt der Server die Transaktion durch und sendet eine Besttigung an den Server des Online Shops. 3. Der Server des Online Shops nutzt die in der Besttigung enthaltenen Daten und sendet eine weitere Anfrage an den Server des Dienstanbieters. 4. Der Server des Dienstanbieter kontrolliert die Daten und besttigt diese gegenber dem Online Shop. Wie zu Beginn dieses Abschnitts erklrt, bentigt der Online Shop keine Registrierung. Die fr den Versand bentigten Kundendaten erhlt er stattdessen zusammen mit der Besttigung der Transaktion vom Server des Dienstanbieters. Fr einen Kunden hat dies den Vorteil, dass er nicht in jedem Online Shop eine Registrierung durchfhren muss. Dadurch wird sowohl die Benutzerfreundlichkeit als auch die Sicherheit erhht, da die Daten nur beim Dienstanbieter gespeichert werden mssen.
26
Stefan Gfrrer
Peer-to-Peer Payment via NFC 3.5. Fazit

Produktcode 1. Einlesen Kunde
2. Response
4. Transaktionsbesttigung 5. Daten zur berprfung 6. Echtheitsbesttigung 3. Abschluss der Transaktion
Server des Shops
Server der Bank
Abbildung 3.4.: Ablauf eines Einkaufs im Online Shop mit eKaayCash. Es wird davon ausgegangen, dass die Transaktion bereits erzeugt wurde (eigene Darstellung). Der Inhaber des Online Shops ist nicht fr die Sicherheit der Kundendaten verantwortlich mit Ausnahme des Zeitraums zwischen Kauf und Versand und hat gleichzeitig eine besttigte Bindung von Kontodaten an Kundendaten durch den Dienstanbieter. Die in diesem Abschnitt vorgestellte Erweiterung fr eKaayCash ermglicht ein einfaches Bezahlsystem fr Online Shops. Die Verwendung an Kassen und Automaten ist vorausgesetzt eine Verbindung zum Internet besteht ebenfalls mglich. Aufgrund der Bindung von Bezahlung und Kundendaten werden Betrugsversuche erschwert. Gleichzeitig steigt die Benutzerfreundlichkeit sowohl fr den Kunden als auch fr den Hndler.
3.5. Fazit
In diesem Kapitel wurde eine erste Anwendung fr das eKaay TAN Verfahren demonstriert und seine Vorteile in Bezahlsystemen dargestellt. Dabei wurden alle zuvor denierten Ziele fr eKaayCash eingehalten. Das Verfahren verwendet eKaay als zentrale Verizierungsinstanz und zur Absicherung aller Transaktionen. Dabei wird eKaay eingesetzt ohne verndert zu werden. Aus diesem Grund ist eKaayCash auch vollkommen kompatibel mit der eKaay Implementierung auf anderen Betriebssys-
Stefan Gfrrer
27

temen wie iOS. Zudem konnte auch der Einsatz von Nahfunk prsentiert werden. Die optionalen nderungen sind nur geringfgig und ndern das Prinzip von eKaay nicht. Es wird lediglich um einen weiteren Kommunikationskanal zum QR Code ergnzt. Die Verwendung von eKaay ermglicht eine getrennte Weiterentwicklung der grundlegenden Architektur namentlich eKaay und des eigentlichen Verfahrens eKaayCash. Dies umfasst insbesondere die Sicherheit, welche von eKaay geliefert wird. Der Vorteil ist eine Vereinfachung der Implementierung und Weiterentwicklung von eKaayCash, welches ein simples Interface aufweist. Besonders das Kritierum der Weiterentwicklung konnte mit der Erweiterung fr Online Shops dargelegt werden. Die Erweiterung ist auch ein Beweis fr 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 eKaay in eKaayCash verwendet werden knnen. Einen Hinweis darauf gibt bereits die Einbindung von eKaay PIN. Mglich ist aber auch die Verwendung von eKaayCard vorgestellt von Gnther [2011]. Dadurch kann die Sicherheit weiter erhht werden, bzw. kann dies eine Alternative zur PIN darstellen und so die Benutzerfreundlichkeit verbessern, da das Merken der PIN entfallen wrde. Zudem muss die Verwendung von eKaay PIN in einem P2P System kritisch betrachtet werden. Es macht die Eingabe der permutierten PIN im Smartphone des Geldempfngers notwendig. Dieser muss sein Smartphone gegebenenfalls aus der Hand geben oder zumindest dem Zahlenden zur Eingabe der PIN hinhalten. Der Ablauf minimiert die ntige Benutzerinteraktion auf das Notwendige. Eine mgliche Ablehnung gegenber NFC durch Anwender wird mit der Verfgbarkeit von QR Codes begegnet. Die eKaay Basis vereinfacht die Installation der ntigen Software und Konten auf dem Smartphone. Diese Aspekte knnen folglich zu einer hohen Benutzerakzeptanz fhren.
28
Stefan Gfrrer
4. Analyse bestehender mobiler Bezahlsysteme

Im zweiten Hauptteil der vorliegenden Diplomarbeit wird das entwickelte Verfahren eKaayCash auf mgliche Sicherheitslcken und Angrispunkte untersucht. Dieselben Untersuchungsschritte werden fr eine Reihe weiterer Verfahren durchgefhrt, welche sich zum Zeitpunkt der Entstehung dieser Arbeit bereits im Einsatz oder in der Endphase ihrer Entwicklung benden. Die einzelnen Ergebnisse werden, sofern mglich, miteinander verglichen.
4.1. Vorgehen
4.1.1. Auswahl der Verfahren und Kriterien
Mit dem Aufkommen moderner Smartphones und neuer Technologien beispielsweise NFC und hher ausenden Kameras wchst auch die Anzahl verschiedener kommerzieller Systeme fr den mobilen Einsatz (vgl. Shinder [2011]). Fr die in der vorliegenden Arbeit anzustellende Analyse wurde eine reprsentative Auswahl von Verfahren nach folgenden Kriterien getroen. Verfgbarkeit. Es wurden nur Verfahren ausgewhlt, ber welche ausreichend Informationen zur Verfgung stehen. Zum Entstehungszeitpunkt dieser Arbeit befanden sich viele Lsungsanstze erst in der Entwicklung und wurden darum nicht in die Betrachtung mitaufgenommen (vgl. Abschnitt 4.10). Es wurde darauf geachtet, dass ozielle Quellen verfgbar sind, die durch eigene Beobachtungen gesttzt werden knnen. Verfahren mit wissenschaftlichem Informationsmaterial oder ausfhrbaren Applikationen wurden bevorzugt ausgewhlt. Smartphone basierend. Es werden nur Systeme einbezogen, die auf modernen Smartphones lauhig sind. Shinder [2011] geht davon aus, dass Smartphones in Zukunft immer mehr zu allumfassenden, mobilen Werkzeugen werden. Eine Betrachtung lterer Handysysteme ist aus diesem Grund nicht sinnvoll (ebd.). Aktuelle Technologie. Mit der Forschung im Bereich mobiler Bezahlsysteme wurde bereits frh in der Entwicklung mobiler Telefone begonnen (vgl. Fenner [1992]). Zu den Zielen dieser Arbeit gehrt aber unter anderem die Verwendung moderner Technologien, wie sie erst mit neuesten Smartphones mglich
Stefan Gfrrer
29
Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme

werden (vgl. Abschnitt 1.2). Besonderes Augenmerk wird dabei auf die Verwendung von NFC gesetzt. Aber auch der Einsatz von hoch ausenden Kameras in Verbindung mit Barcodes stellt ein modernes System dar (vgl. Abschnitt 3.1). Dies schliet insbesondere ltere Verfahren, welche SMS Nachrichten zur Datenbertragung verwenden, aus. Stattdessen sind internetbasierte Dienste erwnscht. P2P Payment. Das grundlegende Ziel fr eKaayCash ist die Entwicklung eines Peer-to-Peer Payment Systems. Zu vergleichende Fremdsysteme sollten entsprechend ber die Mglichkeit, oder zumindest ber die ntige technische Basis fr eine zuknftige Implementierung verfgen. Besonders die Kriterien Verfgbarkeit und Aktuelle Technologie fhren zu einer starken Einschrnkung der verfgbaren mobilen Bezahlsysteme. Eine Reihe ausgeschlossener 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 mgliche Punkte gesucht, welche in mobilen Bezahlsystemen angegrien werden knnen. Diese mssen nicht in jedem der vorgestellten Systeme vorkommen. Besonders Verfahren mit Peer-to-Peer Funktionalitt bieten Angreifern mehr Angrispunkte als zum Beispiel ein E-Wallet System. Viele der Angrie sind jedoch aufgrund der gemeinsamen Plattform und geteilter Kommunikationswege in jeder mobilen Bezahllsung zumindest theoretisch mglich. Anschlieend kann mit Hilfe der gefundenen Angrisvektoren jedes System untersucht werden. Dabei zeigt sich eine besondere Schwierigkeit: einige der Systeme bieten keinen Einblick in die verwendeten Technologien, Algorithmen und Protokolle. Aus diesem Grund werden an diesen Stellen ausschlielich die Bezahlablufe betrachtet und theoretische berlegungen zu kritischen Punkten angestellt.
30
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.2. Mgliche Angrispunkte in Mobile Payment Lsungen
Die Untersuchung eines einzelnen Verfahrens luft wie folgt ab. 1. Zunchst wird das Bezahlsystem allgemein vorgestellt. Ein Bezahlvorgang wird aus Sicht der Benutzer erlutert und beschrieben. 2. Im zweiten Abschnitt erfolgt eine technische Beschreibung aller fr die Sicherheitsanalyse relevanten Punkte. 3. Im Anschluss wird kurz auf marktwirtschaftliche Aspekte eingegangen. Insbesondere werden Benutzerfreundlichkeit und mgliche Akzeptanz durch Benutzer hervorgehoben. 4. In der eigentlichen Sicherheitsanalyse werden die allgemeinen Angrispunkte auf die Ablufe und auf die verwendeten Techniken im Bezahlsystem angewandt und erlutert. 5. Die einzelnen Angrispunkte werden gekrzt zu Ax, wobei x fr eine Zahl steht durchnummeriert. Im jeweiligen Fazit eines Verfahrens wird zusammengefasst, welche Angrie unter welchen Bedingungen mglich sind.
4.2. Mgliche Angrispunkte in Mobile Payment Lsungen

In einem mobilen System, welches mit anderen Systemen kommuniziert, existieren folgende beiden Arten von Angrien: Informationsdiebstahl Manipulation von Informationen Beide Angrisformen knnen jeweils auf dem mobilen Gert und auf dem Kommunikationskanal erfolgen. Daraus ergeben sich fr einen Angreifer insgesamt vier Mglichkeiten. Diese knnen mit verschiedenen Mitteln realisiert werden, welche im Folgenden betrachtet werden. Die einzelnen Angrismglichkeiten knnen dann bei der Untersuchung der mobilen Bezahlverfahren auf ihre Anwendbarkeit berprft werden. Dies schliet eine Untersuchung von denkbaren oder bereits vorhandenen Gegenmanahmen mit ein. Des Weiteren wird auf die Gefahr eines physikalische Zugris auf das Gert und auf die Gefahr des Social Engineering eingegangen. A1: Informationsdiebstahl durch Schadprogramme. Bereits 2010 wurde auf Kaspersky Lab [2010] der erste Trojaner fr Android basierte Smartphones gemeldet. Da moderne Betriebssysteme fr mobile Endgerte einen hnlichen Funktionsumfang haben wie Desktop- und Serversysteme (vgl. Google [2012b]) und ihre Verbreitung stark zugenommen hat, steigt die Attraktivitt fr Entwickler von Schadsoftware. Informationsdiebstahl ist dabei die einfachste Variante.
Stefan Gfrrer
31

Besonders die Finanzwelt muss sich gegen die Entwendung von kritischen Daten wehren. Sowohl in der Vergangenheit als auch in der Gegenwart betrit das hauptschlich Kreditkarten- und Kontoinformationen. Mit mobilen Lsungen kommen weitere Angrispunkte hinzu. Die unterschiedlichen Verfahren bieten eine Vielzahl an potentiell interessanten Daten. Dazu gehren Zugangsdaten zu Diensten und Informationen, welche Rckschlsse auf das Kaufverhalten des Benutzers zulassen. Sicherheitslcken, welche den Zugri auf Informationen dieser Art erlauben, wurden bereits unter Viaforensics [2011] fr Google wallet verentlicht. Andere mobile Verfahren knnen ebenso gefhrdet sein. Zustzlich besteht die Gefahr, dass Schadprogramme kritische Daten wie eine PIN whrend der Eingabe abhren und sie anschlieend ohne das Wissen des Benutzers einsetzen. Einen Schutz vor Angri dieser Art bietet die sichere Verschlsselung der gefhrdeten Daten. Dabei darf der verwendete Schlssel nicht selbst auf dem Endgert gespeichert werden. Dieses Problem kann mit einer sogenannte AppPIN gelst werden. Diese PIN muss beim Zugri auf die Daten vom Benutzer eingegeben werden. Die Eingabe selbst ist zwar wiederum angreifbar, allerdings verringert sich der unsichere Zeitraum auf einen einzelnen Zeitpunkt. Dieser Schutz wird durch das mobile Betriebssystem untersttzt. Systeme wie Android isolieren alle Apps voneinander (vgl. Abschnitt 2.3). Diese Manahme kann jedoch aufgrund von Sicherheitslcken umgangen werden. Aus diesem Grund sollten Entwickler weitere Mechanismen wie die oben erwhnte Verschlsselung implementieren. Es bleibt also festzuhalten, dass sensible Daten von mobilen Plattformen gestohlen werden knnen. A2: Manipulation durch Schadprogramme. Neben dem Diebstahl von Informationen knnen Schadprogramme Daten manipulieren. Whrend einer nanziellen Transaktion werden unabhngig vom tatschlichen Verfahren bestimmte Informationen immer wieder verwendet. Zumindest der Empfnger, der Zahlende und der Betrag mssen bekannt sein. Je nach Bezahlsystem knnen noch weitere Daten hinzukommen. Ein Schadprogramm kann hier einzelne Informationen auszutauschen. Als einfaches Beispiel bietet sich die Manipulation des Empfngers einer Geldsumme an. Wenn diese nderung unbemerkt vom Benutzer geschieht und im kompletten Verfahren keine Absicherung existiert, kann auf diese Weise der Gelduss zum Vorteil des Angreifers umgelenkt werden. Ein bekannter und seit langem verwendeter Schutz ist die Authentisierung mittels einer TAN oder einer PIN. Finanzinstitute setzen diesen Schutz besonders im Onlinebanking ein, um eine Transaktion vor Abschluss durch den
32
Stefan Gfrrer
Benutzer besttigen zu lassen. Abhngig von der Variante des eingesetzten Schutzes kann ein Schadprogramm an dieser Stelle wie im vorherigen Punkt beschrieben einen Informationsdiebstahl durchfhren und dann wiederum selbst in Form einer falschen Transaktion aktiv werden. Die Angreifbarkeit unterschiedlicher TAN und PIN Implementierungen wird aus diesem Grund beim jeweiligen Bezahlsystem individuell untersucht. Eine sichere Variante ist die Verwendung kryptographischer Signaturen. Dabei wird von zu sichernden Daten, mit Hilfe eines von Client und Server geteilten Geheimnisses, eine Art digitaler Fingerabdruck berechnet. Eine Manipulation der Daten macht diesen Fingerabdruck ungltig und kann somit erkannt werden (vgl. Gupta u. a. [2005]). Fortgeschrittene TAN Verfahren basieren bereits auf dieser Idee und bieten auf diese Weise einen hheren Schutz (vgl. Baden-Wrttembergische Bank [2006]). Daraus kann gefolgert werden, dass Datenmanipulation ein einfacher Weg fr Angreifer ist, um vollstndige Transaktionen zu erzeugen und dass eine Absicherung ber dynamische Schutzmechanismen unerlsslich ist. A3: Abhren der Kommunikationsverbindung. Informationen knnen nicht nur direkt auf dem Smartphone gesammelt werden, sondern auch whrend der aktiven Datenbertragung zwischen einem Server und dem Client abgehrt werden. Moderne Smartphones verfgen ber verschiedene Kommunikationssysteme. Fr die vorliegende Arbeit sind kabellose Netzwerke mit Anbindung an das Internet von Interesse. Dazu gehren vorwiegend moderne Mobilfunkstandards wie Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS) und Long Term Evolution (LTE). Aktuelle Smartphones untersttzen zumindest eine Auswahl dieser Standards fr mobile Internetverbindungen. Um Kosten zu sparen greifen viele Anwender auerdem auf ein verfgbares drahtloses lokales Netzwerk (WLAN) zurck. Als lokale Kommunikationsschnittstelle zwischen mobilen Endgerten kommt zudem hug der Bluetooth Standard zum Einsatz (vgl. Pehl [2004]). Angrie auf eine Kommunikationsverbindung werden mittels eines Man-in-the-Middle (MITM) ausgefhrt. Dabei versucht ein Angreifer den Kommunikationskanal zwischen zwei Parteien aufzuteilen und sich selbst an dieser Stelle einzufgen. Er kann anschlieend den Kommunikationsuss steuern, bertragene Daten lesen und sie nach eigenem Ermessen weiterleiten. Fr den Informationsdiebstahl ist nur das Abhren der bertragenen Daten relevant. Eine Darstellung dieser Situation ndet sich in Abbildung 4.1. Neben dieser aktiven Variante besteht auch die Mglichkeit eines passiven Lauschangris. Dies ist besonders bei nicht geschtzten Kommunikationskan-
Stefan Gfrrer
33
Alice (Client)
Mallory (aktiver Angreifer) Bob (Server)
Abbildung 4.1.: Erfolgreicher Man-in-the-Middle Angri auf eine Server-Client Verbindung. Der Angreifer Mallory kann den Kommunikationsuss zwischen Alice und Bob vollstndig kontrollieren (eigene Darstellung). len mglich. Dazu gehren ungesicherte WLAN Verbindungen (vgl. Abbildung 4.2).
Alice (Client)
Bob (Server)
Eve (passiver Angreifer)
Abbildung 4.2.: Der Angreifer Eve hat zwar keinen direkten Einuss auf den Kommunikationskanal, kann aber die Verbindung zwischen Alice und Bob unbemerkt belauschen (eigene Darstellung). Zur Durchfhrung von Angrien dieser Art gibt es eine Reihe allgemeiner Techniken wie das Vortuschen eines WLAN Access Point, DNS Cache Poisoning (vgl. Son u. Shmatikov) oder ARP Spoong (vgl. Eriksson u. Johansson [2007]). In der Arbeit von Eriksson u. Johansson [2007] wird zudem die Angreifbarkeit von verschlsselten Verbindungen demonstriert. Des Weiteren gibt es eine Reihe von erfolgreichen MITM Angrien auf bekannte Mobilfunkstandards. Mun u. a. [2009] zeigen in ihrer Analyse, dass die mgliche Zusammenarbeit von UMTS- und WLAN-Netzen einen Angrispunkt bietet. Dieser Befund wird von Zhang u. a. [2010] besttigt. Sie schleusten erfolgreich ein Programm zum Belauschen der Kommunikationsverbindungen in die fr die Zusammenarbeit verantwortliche Middleware ein (ebd.). Eine grere Gefahr besteht fr Schnittstellen zwischen Global System for Mobile Communications (GSM) und UMTS-Netzwerken (vgl. Meyer u. Wetze [2004]). Da GSM eine nur schwache Verschlsselung aufweist, kann diese besonders leicht angegrien werden. Gleichzeitig bildet dieses System nach wie vor die Grundlage der meisten Mobilfunknetze (ebd.).
34
Stefan Gfrrer
Obwohl sichere Verbindungen unter Verwendung von Secure Sockets Layer (SSL) oder Transport Layer Security (TLS) theoretisch angreifbar sind, bieten sie trotzdem einen Schutz vor den meisten Angreifern. Ein weiterer Sicherheitsfaktor kann die Verwendung einer zustzlichen symmetrischen oder asymmetrischen Verschlsslung der Daten sein. Die PIN kann im Fall der symmetrischen Verschlsselung das geteilte Geheimnis darstellen. Dieser Angrispunkt zeigt zusammengefasst die Bedeutung des Kommunikationskanals fr den Angreifer und dem zufolge auch fr den Entwickler einer Anwendung mit kritischen Daten. Durch die physische Trennung von mobilem Endgert und bertragungsweg mssen die bertragenen Daten vor unerwnschtem Einblick geschtzt werden. A4: Manipulation von Daten whrend der Kommunikationsverbindung. Wie im vorherigen Abschnitt bereits beschrieben, existieren aktive und passive Angriffe auf den Kommunikationskanal. Whrend der passive nur fr reine Lauschangrie geeignet ist, bietet ein aktiver MITM Angri weitaus mehr Mglichkeiten. Der Angreifer kontrolliert, wie in Abbildung 4.1 dargestellt, den kompletten Kommunikationsuss. Dies ermglicht nicht nur einen Einblick in die bertragenen Informationen, sondern lsst auch die Vernderung aller Daten zu. Damit erhlt ein Angreifer die gleichen Fhigkeiten wie ein aktives Schadprogramm, welches Manipulationen durchfhrt. Wenn der Inhalt nicht geschtzt ist oder der Schutz in Form einer Prfnummer nicht von den zu schtzenden Informationen abhngt, kann ein solcher Angri erfolgreich sein. ltere, statische TAN-Verfahren verfgen ber eine solche lose Bindung von Schutz der TAN und Transaktionsdaten (vgl. Borchert [2012b] und Abbildung 4.3).
berweisung von 100 Euro an Carol. TAN: 1234 berweisung von 900 Euro an Mallory. TAN: 1234
Alice (Client)
Mallory (aktiver Angreifer) Bob (Server)
Abbildung 4.3.: Der Angreifer Mallory manipuliert eine berweisung, welche auer einer vom Inhalt unabhngigen TAN keinen weiteren Schutz aufweist (eigene Darstellung). Wie bereits bei Schadprogrammen, lsst sich auch die Manipulation im Kommunikationskanal durch kryptographische Signaturen aufdecken und somit verhindern.
Stefan Gfrrer
35

A5: Physischer Zugri auf das mobile Endgert. Neben indirekten Zugrien auf das Smartphone ber Schadprogramme usw. ist fr Menschen auch der direkte Zugri mglich, wenn sie in dessen physische Nhe gelangen. Neben den fr den Besitzer erkennbaren potentiellen Fremdzugrien im Fall eines Verlustes oder Diebstahls des Gerts kann eine unbefugte Person bereits in kurzer Abwesenheit des Besitzers Schaden auf einem Smartphone anrichten. Abhngig von der Dauer des Zugris hat der Angreifer verschiedene Mglichkeiten. Er kann in aktiven Applikationen Befehle ausfhren oder an geringfgig geschtzten Stellen nach Informationen suchen. Sein Handeln hnelt damit dem eines Schadprogramms. Sofern eine Transaktion nicht durch eine PIN geschtzt ist, ist eine Transaktion in einer Finanz-Applikation mglich oder es kann beispielsweise der Browserverlauf durchsucht werden. Diese Informationen knnen teils direkt Schaden verursachen (vgl. Viaforensics [2011]), teils knnen sie zur Vorbereitung weiterer Angrie verwenden werden. Bei einem lngeren Zugri kann ein Angreifer nach tiefer gehenden Informationen suchen. Viaforensics [2011] hat gezeigt, dass sich dabei wichtige Daten nden lassen. Mit entsprechenden Kenntnissen kann ein Angreifer auch versuchen den Schutz verschiedener Systeme anzugreifen. Die Oenlegung der PIN und hnlicher Geheimnisse ist dabei ein wesentlicher Gefahrenpunkt. Apps knnen als Schutz fr kritische Befehle die Verwendung einer PIN oder hnlichem verwenden. Informationen sollten wie beim Schutz vor Trojanern verschlsselt abgelegt werden. Zum Schutz vor Verlust oder Diebstahl des Smartphones sollte die entfernte Sperrung oder Deaktivierung des Gerts und wichtiger Apps bzw. hinterlegter Benutzerkonten mglich sein. Bei einer entfernten Sperrung kann ein mobiles Endgert oder eine einzelne Applikation ohne physikalischen Kontakt vom Dienstanbieter deaktiviert werden. Es bleibt festzuhalten, dass insbesondere Informationsdiebstahl von Menschen direkt auf dem Endgert durchgefhrt werden kann und dass dieselben Schutzmechanimen wie gegen Schadprogramme gelten mssen. A6: Social Engineering. Durch das verstrkte Aufkommen internetbasierter Dienste mit persnlichen Benutzerkonten wurden gleichzeitig Angrie entwickelt, um Kontrolle ber diese zu erhalten. Es werden nicht nur technische Sicherheitslcken im eigentlichen Dienst verwendet. Mittels Social Engineering nutzt der Angreifer die Unwissenheit vieler Internetnutzer aus. Bekannte Techniken sind Phishing oder das fortgeschrittene Pharming (vgl. Jakobsson u. Myers [2006]). Der Benutzer wird mittels scheinbar echter E-Mails vom Dienstanbieter oder mittels DNS Spong auf eine geflschte Seite gelockt. Diese Seite gleicht in den meisten Fllen der echten Seite des Dienstes. Sie fordert den Be-
36
Stefan Gfrrer
nutzer aus unterschiedlichen Grnden zur Eingabe sicherheitsrelevanter Daten wie Benutzername und Passwort auf. Erkennt das Opfer die geflschte Seite nicht und gibt seine Daten ein, erhlt der Angreifer Zugri auf das Benutzerkonto des Opfers (ebd.). Auf diese Weise lassen sich auch statische TANs erschleichen. Die Sicherheitsmechanismen der meisten mobilen Apps sind ihren Webquivalenten hnlich oder gar identisch. So werden in vielen Fllen dieselben Anmeldeinformationen verwendet. Aus diesem Grund sind auch dieselben Social Engineering Angrie mglich. Onlinebanking Dienste schtzen sich vor Phishing und Pharming mittels moderner TAN Verfahren, welche die TAN dynamisch fr die jeweilige Transaktion berechnen (vgl. Baden-Wrttembergische Bank [2006]). In mobilen Anwendungen kann man den Zugri auf den Dienst einschrnken indem nur registrierte Smartphones erlaubt werden. Die Erkennung kann mittels der Telefonnummer, der International Mobile Equipment Identity (IMEI) oder hnlichen, eindeutigen Daten erfolgen (vgl. PayPal [2012b]). Es konnte aufgezeigt werden, dass Social Engineering als nicht technischer Angri Entwickler von sicheren Anwendungen vor besondere Herausforderungen stellt und diese explizit behandelt werden mssen. A7: Abhren der NFC-Verbindung. Near Field Communication ist zunchst ein kabelloses Kommunikationsmedium. Es hnelt insofern Verbindungen via WLAN und erlaubt hnliche Angrie. Aufgrund seiner sehr geringen, eektiven Sendereichweite von zwanzig Zentimetern und Besonderheiten in der Architektur werden tatschliche Angrie hingegen deutlich erschwert. NFC verwendet zur Darstellung einzelner Bits eine modizierte Miller-Kodierung oder eine Manchester-Kodierung (vgl. Abschnitt 2.2). Diese erlauben praktisch keine Manipulation von Daten. Gleichzeitig wird aufgrund des geringen Abstands und spezieller Anforderungen an das Timing ein Man-in-the-Middle Angri unmglich. Diese Problematik fr einen Angreifer wird ausfhrlich von Haselsteiner u. Breitfu [2006] beschrieben. Whrend eine aktive Manipulation nicht mglich ist, kann ein Angreifer jeodch immer noch passiv den Datenverkehr abhren. Wie Eingangs beschrieben, haben die meisten NFC-fhigen Endgerte eine maximale Reichweite von zwanzig Zentimetern. Haselsteiner u. Breitfu [2006] gehen allerdings davon aus, dass aktive Empfangsgerte bei idealen Bedingungen Daten in bis zu zehn Metern Entfernung erfassen knnen. In einem einfachen Aufbau wird von Kortvedt u. Mjlsnes [2009] in einem durchschnittlichen Abstand von zwanzig Zentimetern die komplette Kommunikation zwischen einem Tag und einem NFC-fhigen Handy mitgelesen. Bereits
Stefan Gfrrer
37

dieser Abstand gengt um beispielsweise in der Nhe eines NFC Terminals eine Sonde anzubringen. Wie bei Angri A1 erklrt, bietet nur eine verschlsselte bertragung Schutz vor Laufangrien. Aufgrund des technisch bedingten Schutzes vor Manipulation ist die Entwicklung eines sicheren bertragungsprotokolls fr Near Field Communication sehr einfach. Ein solches Protokoll wird in der Arbeit von Van Damme u. a. [2005] vorgestellt. Zu den Schwierigkeiten der Implementierung gehren Limitierungen der verwendeten Java Umgebung und die zum Zeitpunkt der Arbeit geringe Rechenleistung von mobilen Endgerten (ebd.). Diese Schwierigkeiten lassen sich mittels modernen mobilen Betriebssystemen und der deutlich hheren Rechenleistung aktueller Smartphones lsen. Nahfunk ist aus den beschriebenen Grnden ein sicheres Kommunikationsmedium und bedarf nur geringer zustzlicher Absicherung durch den Entwickler. Eine weitere Angrismglichkeit ist das externe Beobachten des Bildschirms durch Drittpersonen oder entsprechendes berwachungsequipment. Aufgrund der grundstzlichen Notwendigkeit von Benutzereingaben bestehen fr Entwickler jedoch nur geringe Schutzmglichkeiten. Wie bei der klassischen PIN Eingabe am Geldautomaten liegt die Verantwortlichkeit hier beim Benutzer. Aus diesem Grund wird diese Art von Angri bei der Untersuchung ausgeschlossen. Ebenfalls werden Angrie auf die Infrastruktur in Form von Servern und Ahnlichem auer Acht gelassen. Diese erfordern gesonderte Sicherheitsmechanismen und haben nur indirekt mit dem Thema des mobilen Bezahlens zu tun. Des Weiteren sind auch Betrugsversuche durch eine der an einer Transaktion beteiligten Parteien nicht Bestandteil der folgenden Untersuchungen. Angrie dieser Art knnen in zwei Formen auftreten. Einerseits knnen direkt falsche Angaben gemacht werden. Dazu gehrt beispielsweise ein zu hoher Betrag. Die Verantwortung liegt hier ebenfalls bei den Benutzern und der manuellen berprfung der Transaktion. Des Weiteren kann eine der Parteien versuchen, manipulierend auf die Geldberweisung einzuwirken. Diese Art von Angri ist aber nur mit bereits beschriebenen Mechanismen wie Schadprogrammen mglich und wurde somit bereits erlutert. Alle Angrismglichkeiten werden in Tabelle 4.1 noch einmal zusammengefasst. Bei der Vorstellung der einzelnen Angrismethoden wurden ausschlielich spezialisierte Schutzmechanismen erwhnt. Die einzige Ausnahme bilden Schutzfaktoren in der Architektur des Betriebssystems. Bei der Isolation einzelner Prozesse durch Android handelt es sich um einen solcher Schutz (vgl. Abschnitt 2.3). Unabhngig vom technischen Standpunkt existiert auch der Faktor Gewinn. Angreifer zielen mit ihren Aktionen in vielen Fllen auf einen monetren Gewinn ab. Dieser Gewinn muss in
38
Stefan Gfrrer
Name A1: Informationsdiebstahl durch Schadprogramme. A2: Manipulation durch Schadprogramme.
Beschreibung Ein Trojaner auf dem mobilen Endgert kann theoretisch alle Daten abhren und auslesen. Daten knnen von Schadprogrammen aktiv gendert werden. Mittels aktivem oder passivem Eingri in einen Kommunikationskanal ist das Abhren aller Informationen mglich. Aktiver Eingri sogenannter Man-in-the-Middle ermglicht die Manipulation von Daten auf dem Kommunikationskanal. Informationsdiebstahl und Nutzung aktiver Applikationen; bei lngerem Zugri sind tiefergehende Untersuchungen und zeitaufwendige Angrie mglich. Durch einfache und in der Vergangenheit hug erfolgreiches Phishing und Pharming, erhlt ein Angreifer leicht Zugang zu kritischen Daten wie Passwrtern. Versteckte Sonden knnen auf bestimmte Entfernungen einzelne NFC Verbindungen abhren.
A3: Abhren der Kommunikationsverbindung.
Schutz Verschlsselung mit externem Geheimnis und Prozessisolierung durch Betriebssystem. Kryptographische Signatur fr kritische Informationen und Prozessisolierung durch Betriebssystem. Verschlsselung der Daten und sichere Verbindung mittels SSL oder TLS.
A4: Manipulation von Daten whrend der Kommunikationsverbindung.
Kryptographische Signaturen und sichere Verbindungen mittels SSL oder TLS.
A5: Physischer Zugri auf das mobile Endgert.
A6: Social Engineering.
A7: Abhren der NFCVerbindung.
Verschlsselung von Daten. Kritische Befehle mittels PIN absichern. Entfernte Deaktivierung von Applikationen, Benutzerkonten und Smartphone. Nur registrierte Endgerte fr einen Dienst erlauben. Befehle mittels dynamischer, von Eingabedaten abhngigen Transaktionsnummern absichern. Verschlsselung der Daten und die Verwendung von sicheren Verbindungen.
Tabelle 4.1.: bersicht aller Angrismethoden auf mobile Bezahlsysteme (eigene Darstellung)
Stefan Gfrrer
39

einem positiven Verhltnis zum ntigen Aufwand stehen. Entwickler und Betreiber mobiler Bezahlsysteme knnen dieses Verhltnis auf zwei Wegen beeinussen. Die Verwendung sicherer Techniken und Algorithmen erhht den Aufwand und somit die Kosten fr den Angreifer. Gleichzeitig kann der nanzielle Gewinn verringert werden. Viele Bezahlsysteme sind nur fr geringe Betrge freigegeben. Ein Angreifer hat somit keine Mglichkeit, durch einen einzelnen Angri einen greren Gewinn zu erhalten. Multiple Angrie auf verschiedene Benutzer erhhen aber gleichzeitig den Aufwand und die Gefahr einer Entdeckung. Die Handlung wird fr den Angreifer also unattraktiv. Da die Limitierungen auf Kleinstbetrge durch den jeweiligen Dienstanbieter festgelegt werden muss und unabhngig von der Technik ist, wird dies in die folgende Analyse der einzelnen Bezahlsysteme nicht miteinbezogen. Zustzlich bilden viele Verfahren in sich abgeschlossene Systeme, die ein Auaden des Kontos mit Geld durch ein externes Finanzinstitut voraussetzen. Gestohlene Betrge mssen denselben Ablauf in umgekehrter Reihenfolge durchlaufen. Ein Angri kann dem zufolge noch innerhalb des Systems des Anbieters erkannt werden.
4.3. eKaayCash
In diesem Abschnitt werden das in Kapitel 3 vorgestellte eKaayCash Verfahren und dessen Erweiterung fr Online Shop Systeme auf ihre Sicherheit untersucht.
4.3.1. Sicherheitsanalyse
4.3.1.1. eKaayCash Die grundlegenden Sicherheitsmechanismen fr eKaayCash werden vom eKaay Verfahren geliefert. In Abschnitt 2.1 wurde bereits auf das Ergebnis der Sicherheitsanalyse von Gnther [2011] verwiesen. Es wurde eine Reihe von Problemen aufgedeckt, welche zeigen, dass ein Schadprogramm unter bestimmten Bedingungen kritische Operationen ausfhren kann. Beispielsweise kann ein Schadprogamm das Geheimnis eines Benutzers auslesen und damit beliebige Transaktionen signieren. Diese Sicherheitslcken gelten auch fr eKaayCash. Allerdings bietet eKaay zustzliche Mechanismen, welche vor den beschriebenen Angrien schtzen. Dazu gehren eKaay PIN und eKaayCard. Beide Verfahren knnen auch mit eKaayCash kombiniert werden und den Schutz verbessern (ebd.). Des Weiteren ist auch der Ablauf einer Peer-to-Peer berweisung angreifbar. Wie in Abschnitt 3.3.1 beschrieben, werden nach dem Ausfllen des berweisungsformulars die darin enthaltenen Daten an den Server bertragen. Ein Schadprogramm auf dem
40
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.3. eKaayCash

Smartphone des Geldempfngers kann die bertragenen Daten manipulieren und beispielsweise die ID des Empfngers gegen die eines Angreifers austauschen. Auch ein MITM Angri auf den bertragungskanal kann zu diesem Ergebnis fhren. Ein hnlicher Angri ist auf den generierten QR Code bzw. NFC Link mglich, welche jeweils ein Containerformat fr die eigentlichen Daten darstellen (vgl. Abschnitt 3.3.2). Zwar bietet die Manipulation beider Container keinen Vorteil (vgl. Abschnitt 2.1), jedoch ist ein Austausch durch ein Schadprogramm mglich. Sowohl das Smartphone des Geldempfngers als auch das des Zahlenden verfgen im Regelfall ber eine Internetverbindung, da diese fr die Verwendung von eKaayCash wichtig ist. Entsprechend kann ein Schadprogramm eine eigene Transaktion initiieren und den QR Code sowie den NFC Link ersetzen. Dieser Angri ist direkt vor der P2P Verbindung zwischen beiden Smartphones mglich, oder auch im Anschluss vor der Anzeige der Transaktion auf dem Handy des Zahlenden. Des Weiteren kann wiederum ein MITM die Challenge vom Server des Dienstanbieters durch die Challenge einer anderen Transaktion ersetzen. Die in den vorherigen Abstzen beschriebenen Angrie zielen auf den Austausch einer Transaktion ab. Die Transaktion des Benutzers soll gegen eine weitere Transaktion des Angreifers ausgetauscht werden. Whrend die Durchfhrung durch Schadprogramme von eKaayCash nicht verhindert werden kann, wird zumindest ein Manin-the-Middle auf die Kommunikation zwischen Server und Geldempfnger aufgrund der Verwendung von verschlsselten Verbindungen erschwert. Der eigentliche Schutz ndet aber in Form der berprfung durch den Zahlenden statt. Eine Transaktion wird erst abgeschlossen, wenn sie vom Zahlenden besttigt wurde. Dieser muss sowohl die ID des Geldempfngers als auch den Betrag kontrollieren und kann einen Austausch entsprechend erkennen und abwehren. Der dabei angezeigte Dialog ist in Abbildung 4.4 dargestellt.
eKaay
Bitte besttigen
Datum: 20.4.2012 Uhrzeit: 10:00:00 Empfaenger: Mallory Betrag: 100.00 Euro
abbrechen
OK
Abbildung 4.4.: Der Besttigungsdialog von eKaay fr eine Transaktion (eigene Darstellung). Die P2P bertragung zwischen beiden Smartphones bietet keine Angrismglichkeiten. Sowohl der QR Code als auch die NFC Verbindung erlauben nur das Abhren
Stefan Gfrrer
41

der Daten, welche nicht geheim bleiben mssen (vgl. Abschnitt 2.1 und Abschnitt 2.2). Durch physischen Zugri hat ein Angreifer die Mglichkeit eine berweisung durchzufhren. Dieser Gefahr kann durch Schutz des Benutzerkontos mit einer PIN und der eKaay PIN fr die Besttigung der Transaktion begegnet werden (vgl. Abschnitt 2.1). Da fr das P2P Verfahren keine unsichere Eingabe von kritischen Daten bentigt wird, ist ein Angri mittels Social Engineering nicht mglich.
4.3.1.2. Erweiterung fr Online Shop Systeme Die Erweiterung erlaubt prinzipiell dieselben Angrie wie eKaayCash selbst. Allerdings sind darber hinaus noch weitere Angrispunkte vorhanden. Der Kauf und die gleichzeitige Bezahlung werden durch das Einlesen des QR Codes mit der eKaay App durchgefhrt. Ein Schadprogramm auf dem Computer des Kunden kann diesen QR Code gegen einen eigenen austauschen und auf diese Weise die Besttigung einer einer geflschten berweisung erreichen. Es gelten jedoch dieselben Einschrnkungen wie im vorherigen Abschnitt. Wenn der Kunde die berweisung prft und nicht besttigt wird der Angri abgewehrt. Neben Schadprogrammen knnen auch Angrie auf die Webseite beziehungsweise den Server des Shops zum Austausch des QR Codes fhren. Zu Angrien dieser Art zhlt unter anderem Cross-Site-Scripting (vgl. Grossman u. a. [2007]). Bei korrekter Implementierung der Schnittstellen hingegen ist ein Shop gegen eine geflschte Transaktionsbesttigung abgesichert. Beliebige Benutzer knnen zwar eine Besttigung an den Server versenden, diese wird jedoch nicht akzeptiert, da die Verizierung durch den Server von eKaayCash fehlschlgt (vgl. Abbildung 4.5).
4.3.2. Fazit
Es kann folgendes Fazit gezogen werden: das Verfahren ist begrenzt durch die Angrie A2 und A4 bedroht. Die Verantwortung liegt in beiden Fllen beim Zahlenden, welcher eine Transaktion immer berprfen muss. Der Angri A5 kann durch Verwendung einer PIN fr das auf dem Handy gespeicherte Konto abgewehrt werden. Diese muss jedoch vom Benutzer explizit aktiviert werden. Die Angrie A1, A3, A6 und A7 sind fr eKaayCash nicht relevant. Durch die Erweiterung fr Online Shops wird keine weitere Schwachstelle hinzugefgt.
42
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.4. PayPal Mobile Payments

Mallory (Kunde) 1. Einlesen
Produktcode
2. Zahlender: Mallory Betrag: 5
3. Zahlender: Mallory Betrag: 5 4. Transaktion ungltig Server des Shops Server der Bank
Abbildung 4.5.: Versuch eines Angreifers einem Shop eine Transaktion vorzutuschen (eigene Darstellung).
4.4. PayPal Mobile Payments

4.4.1. Beschreibung des Verfahrens
PayPal ist eine Tochtergesellschaft des US-Unternehmens eBay und bietet ein Bezahlsystem fr verschiedene, meist internetbasierte Dienste. Die Konto- und Bezahlfunktionalitt ist komplett Webbasiert (vgl. PayPal [2012a]). Inzwischen ermglicht PayPal auch einen direkten Zugang fr mobile Endgerte in Form von speziellen Apps. Wie von PayPal [2012b] beschrieben, mssen Benutzer ein untersttztes Handy zunchst fr den Service aktivieren dadurch wird eine Bindung des Smartphones an ein bestimmtes Konto ermglicht und knnen dann ber eine spezielle App klassische Bezahlvorgnge vornehmen. Diese Apps sprechen dabei nur das bekannte Webinterface an und fgen keine weitere Funktionalitt hinzu. Da gerade bei mobilen Gerten die Gefahr besteht, dass das Gert entweder verloren geht oder gestohlen wird, mssen alle Transaktionen mit Hilfe einer PIN besttigt werden (ebd.). In dieser Hinsicht erfllt PayPal Mobile Payments die in Abschnitt 4.1 beschriebenen Kriterien noch nicht. Mglich wird dies erst durch folgende nderungen. Am 13. Juli 2011 wurde fr Android basierte Smartphones eine neue Version der App von Hardawar [2011] angekndigt. Sie wurde am 8. November 2011 von Samuel [2011] als Version 3 verentlicht. NFC-fhige Gerte erhalten nach einem Update die Fhigkeit Peer-to-Peer Transaktionen durchzufhren. Das Ziel des Unternehmens ist die Vereinfachung einer berweisung zwischen zwei Personen. Dies wird unter anderem
Stefan Gfrrer
43

dadurch erreicht, dass ein Aufruf der eigentlichen App nicht mehr ntig ist. Stattdessen erhlt der Benutzer ein einfaches Widget, welches er auf dem Homescreen seines Smartphones platzieren kann (vgl. Abbildung 4.6). Das Widget erlaubt die Eingabe eines Geldbetrags und damit die Initiierung einer P2P Transaktion (ebd.).
Abbildung 4.6.: Das installierte PayPal Mobile Payments Widget auf dem Homescreen eines Android basierten Smartphones (Quelle: Chambers [2011]). Zum Zeitpunkt der Entstehung dieser Arbeit stand das Verfahren fr europische Benutzer noch nicht zur Verfgung, sondern ist nur in den USA einsetzbar. Die vorhandenen Informationen gengen jedoch, um den Ablauf einer Transaktion zu bestimmen. Die folgende Beschreibung sttzt sich auf Angaben aus der Pressemitteilung von PayPal (vgl. Hardawar [2011]). Sie ist aus Sicht der Benutzer, d. h. des Geldempfngers und des Zahlenden, beschrieben. 1. Im ersten Schritt gibt der Geldempfnger den gewnschten Betrag in das Widget ein. 2. Nach Besttigung der Eingabe erhlt er die Auorderung sein eigenes Smartphone an das des Zahlenden zu halten. 3. Beide Benutzer mssen nun einen Moment warten, whrend der Datenaustausch via NFC zwischen beiden Smartphones statt ndet. 4. Beide Handys besttigen den Erfolg der Datenbertragung mit einem von PayPal Buzz getauften Vibrationsalarm.
44
Stefan Gfrrer

5. Fr den Geldempfnger ist zu diesem Zeitpunkt die aktive Handlung abgeschlossen. Er wird nach Besttigung durch den Zahlenden mit einer E-Mail ber den erfolgreichen Abschluss der Transaktion informiert. 6. Der Zahlende muss die berweisung mit Eingabe seiner PIN besttigen oder kann den gesamten Vorgang abbrechen. 7. Die App baut eine Verbindung zum Server auf und bertrgt die Transaktionsdaten. Der Server fhrt dann die eigentliche Geldberweisung durch und sendet eine Besttigungsmail an den Geldempfnger. Das Peer-to-Peer Verfahren von PayPal Mobile Payments ist somit in vielen Bereichen mit eKaayCash vergleichbar. Der komplette Ablauf ist in Abbildung 4.7 dargestellt.
2. Zahlungsanfrage (NFC) Geldempfnger 1. Eingabe Zahlender 3. Besttigung
5. Verifikation und Geldberweisung
4. Besttigte Zahlungsanfrage (Internet)
Zahlungsserver
Abbildung 4.7.: Ablauf einer P2P Transaktion mit PayPal. Das Versenden der Besttigung wurde aus Grnden der bersicht entfernt (eigene Darstellung).
4.4.2. Technische Umsetzung

PayPal hat ber das eigentliche Verfahren und die Hintergrnde nur wenig verentlicht. Eine exakte Wiedergabe der technischen Umsetzung ist nicht mglich. Der Vorgang fr die Benutzer hnelt aber dem von eKaayCash. Mit diesem Wissen und durch genaue Betrachtung des Ablaufs in einem von PayPal mit einer Pressemitteilung verentlichten Video, lsst sich der technischen Ablauf in groben Zgen
Stefan Gfrrer
45

nachvollziehen (vgl. PayPal [2011a]). Eine genauere Untersuchung wird mglich sein, sobald das Verfahren in Europa zur Verfgung steht. 1. Nach der Eingabe des Betrags durch den Geldempfnger ergeben sich zwei Mglichkeiten fr die Weiterverarbeitung der Daten (Name des Geldempfngers d. h. des Inhabers des aktiven Kontos und Geldbetrag). In eKaayCash werden die Informationen an den Server gesendet. Er verarbeitet und speichert sie. Zum Schluss erhlt das Smartphone die Serverantwort in Form des QR Code und des kodierten NFC Payload. Bei PayPal ist es wahrscheinlicher, dass keine Kommunikation mit dem Server stattndet. Das lsst sich vermuten, da die App keine Auorderung zum Warten anzeigt und der Vorgang verzgerungsfrei fortgesetzt wird. 2. Im folgenden Schritt der bertragung der Daten via NFC kommt die in Abschnitt 2.3 beschriebene API von Android Version 2.3 zum Einsatz. Ob die bertragung verschlsselt wird, ist nicht bekannt. 3. Die aktiven Schritte des Zahlenden werden lokal auf dessen Smartphone im Rahmen der App ausgefhrt. Erst mit der bertragung der abgeschlossenen Transaktion zum Server ndet der letzte, technisch interessante Vorgang statt. Da die P2P Funktionalitt eine Erweiterung der bestehenden PayPal Mobile Payments App darstellt, ist anzunehmen, dass dabei die gleichen Sicherheitsmechanismen zum Einsatz kommen. Dazu gehrt als wichtigsten Punkt eine verschlsselte bertragung. Zum Zeitpunkt der Entstehung dieser Arbeit kommt TLS in der Version 1.0 zum Einsatz (vgl. PayPal [2012a]).
4.4.3. Verbreitung und Akzeptanz durch Benutzer

Gegenber anderen Anbietern, welche den mobilen Markt fr Bezahlsysteme im Zuge neuer Technologien entdecken, hat PayPal dank seines bereits existierenden mobilen Bezahlsystems fr Smartphones auf Basis von Android, iOS oder BlackBerry einen Vorteil in der Verbreitung (vgl. PayPal [2012b]). Fr Android, welches Near Field Communication untersttzt, erschien die Erweiterung der App als einfaches Update. Die Verbreitung wird theoretisch nur durch das Vorhandensein von NFC-fhigen Smartphones eingeschrnkt. Zustzlich wirkt als knstliche Grenze die vorluge Einschrnkung auf die USA fr das Peer-to-Peer System. Ein erster Test in Schweden, welcher von Rao [2011] vorgestellt wurde, zeigt, dass eine uneingeschrnkte Nutzung in anderen Lndern geplant ist. Der schwedische Versuch weist auerdem auf eine potentielle Ausweitung des Systems hin. Wie eKaayCash soll das NFC-System in Zukunft fr die Bezahlung in reellen Geschften verfgbar werden.
46
Stefan Gfrrer

Dabei werden wie in Abbildung 4.8 gezeigt NFC-fhige Terminals zum Einsatz kommen (ebd.).
Abbildung 4.8.: Bezahlung an einem NFC-fhigen Terminal mit PayPal Mobile Payments (Quelle: PayPal [2011b]). Das P2P Verfahren selbst ist sowohl fr den Geldempfnger, als auch fr den Zahlenden einfach zu bedienen. Die Handhabung entspricht in groen Teilen dem Bezahlen mit einer bei Banken blichen Geldkarte unter der Verwendung von Terminals zur PIN Eingabe. Auch wird kein Geldbetrag auf dem Smartphone gespeichert. Dadurch entfllt eine mgliche Misstrauensquelle gegenber dem Verfahren. Eine Studie von Ogilvy & Mather, verentlicht von Patel [2011], zeigt zudem, dass PayPal ein hnlich hohes Vertrauen bei seinen Kunden geniet wie MasterCard und American Express.
Der erste Angri ist im Zeitraum zwischen der Eingabe des Betrags durch den Geldempfnger und der Anzeige der Besttigung auf dem Smartphone des Zahlenden mglich. Dabei kann entweder ein Schadprogramm auf einem der beiden Smartphones zum Einsatz kommen oder ein Lauschangri auf die NFC-Verbindung erfolgen. Bei letzterem knnen, soweit bekannt, der Geldbetrag und der Identikator des Empfngers abgehrt werden. Diese Daten sind nur von begrenzter Relevanz. Ob die Verbindung verschlsselt wird, ist nicht bekannt. Von Bedeutung ist viel mehr die Manipulation durch ein Schadprogramm. Es kann die ID und den Betrag ndern, wobei letzteres mit einer groen Gefahr der Erkennung durch den Zahlenden verbunden ist. Eine nderung der ID kann aber trotz Kontrolle durch den Zahlenden whrend der Besttigung in vielen Fllen unerkannt bleiben, da die ID nicht sprechend sein muss. In Abbildung 4.9 ist dieser Angreif beispielhaft dargestellt.
Stefan Gfrrer
47

Der Schutz durch eine Signatur hilft begrenzt. Ein Schadprogramm auf dem Smartphone des Geldempfngers kann das Geheimnis der Signatur theoretisch auslesen und eine gltige Signatur erzeugen. Dieser Schritt bietet lediglich Schutz vor einem Schadprogramm auf dem Smartphone des Zahlenden. Bei einer nicht erkannten Manipulation kann nur der Zahlende durch Prfung der ID eingreifen und den Vorgang gegebenenfalls abbrechen.
bertragen: 10 Euro an Mallory Alice (Geldempfnger) Eingabe: 10 Euro Empfnger: Alice Bob (Zahlender)
Mallory (Angreifer)
Abbildung 4.9.: Gem A2 kann ein Schadprogramm auf dem Smartphone des Geldempfngers die Transaktionsdaten vor der bertragung manipulieren (eigene Darstellung). Beginnend mit der Anzeige des Betrags und des Geldempfngers bis zur Ankunft aller Daten am Server bietet sich dem Angreifer die zweite Mglichkeit fr einen Angri auf das Peer-to-Peer Bezahlsystem. Es ist anzunehmen, dass die ID des Geldempfngers, der Betrag und die ID des Zahlenden mit Hilfe der PIN des Zahlenden gesichert werden. Die eigentliche bertragung auf den Kommunikationskanal erfolgt, wie bereits erwhnt, ber eine gesicherte Verbindung. Damit bleibt dem Angreifer nur die Manipulation der Daten durch ein Schadprogramm auf dem Smartphone des Zahlenden. Dieser muss die PIN bei der Eingabe mitlesen und den fr den Benutzer sichtbaren Vorgang steuern. Mit Hilfe der PIN kann er dann einen eigenen Zahlungsauftrag erstellen, welcher die ID des Zahlenden und einen beliebigen Betrag sowie Geldempfnger enthlt. PayPal sichert kritische Punkte whrend der kompletten Transaktion aktiv ab. Dies betrit insbesondere die bertragung ber den Kanal. Zustzlich verlsst es sich auf die Sicherheit des Betriebssystems. Sowohl ein Geheimnis zum Schutz vor Datenmanipulation whrend der bertragung zwischen Geldempfnger und Zahlenden, als auch die Eingabe der PIN werden durch das Betriebssystem geschtzt. Google selbst gibt an, dass dieser Schutz durch Systemlcken, welche Root-Rechte ermglichen, umgangen werden kann. Ein Bezahlvorgang mit PayPals Peer-to-Peer Variante ist folgerichtig zumindest theoretisch angreifbar.
48
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.5. Google wallet

Ein Konto bei PayPal lsst sich fr einen Angreifer ohne technischen Aufwand mittels Social Engineering kompromittieren. Ein Phishingangri, welcher die Zugangsdaten fr das Konto abfragt, gengt bereits, um eine berweisung durchzufhren. Ein direkter Angri auf das mobile Bezahlsystem und insbesondere auf die P2P Variante ist nicht ntig. Ein Physikalischer Zugri auf das Smartphone ist auch bei angemeldetem Benutzerkonto nur geringfgig gefhrlich. Ohne PIN knnen nur bestehende Kontoauszge abgerufen, jedoch keine berweisungen gettigt werden.
4.4.5. Fazit
Wie eKaayCash ist auch das Verfahren von PayPal gegenber Angri A2 verwundbar. Der Zahlende kann dies durch eine Prfung der berweisung vor der Besttigung verhindern. Im Gegensatz zu eKaayCash ist aber auch A1 mglich. Durch Abhren der PIN Eingabe und der Anmeldedaten erhlt ein Angreifer die notwendigen Informationen zur Erzeugung eigener, gltiger berweisungen. Aufgrund des PIN Schutzes sind A3, A4 und A5 nicht mglich. A7 bietet fr einen Angreifer keine Vorteile. Allerdings kann mittels A6 leicht ein Konto bernommen werden.
4.5. Google wallet

Die Firmen MasterCard und Visa haben unabhngig voneinander auf dem ISO [2000a] Standard basierte Kreditkarten entwickelt, die einen kontaktlosen Bezahlvorgang erlauben. Bei MasterCard handelt es sich um das PayPass System (vgl. MasterCard [2012]), whrend Visa den Standard in payWave umsetzt (vgl. VISA [2012]). Die Karten sind vollkommen kompatibel zu den Spezikationen fr Zahlungskarten von Europay, MasterCard und Visa (EMV). Beide Unternehmen mchten eine Vereinfachung des Bezahlvorgang erreichen. Mittels einer kontaktlosen, auf Radio-Frequency Identication basierten Technologie soll das unntige Einschieben in ein Lesegert verhindert werden. Auch mssen Kreditkarten mit dieser Technologie nicht mehr aus der Hand gegeben werden. Ein weiterer Vorteil besteht in der Unabhngigkeit von klassischen Kreditkarten. Der RFID-Chip kann theoretisch in ein beliebiges Trgerelement eingebaut werden (vgl. VISA [2012], MasterCard [2012] und ISO [2000a]). Die Trennung von klassischer Kreditkarte und eigentlichem Chip hat Google in seinem mobilen Bezahlsystem fr Smartphones Google wallet erreicht. Google wallet
Stefan Gfrrer
49

speichert die fr eine Transaktion ntigen Kreditkarten-Daten auf dem Smartphone und ist sowohl mit MasterCard PayPass als auch mit Visa payWave kompatibel. Die notwendigen Kreditkarten-Daten knnen von einer kompatiblen Kreditkarte direkt eingelesen werden. Alternativ bietet Google auch den Kauf einer virtuellen Prepaid Card an, mit welcher die Nutzung beliebiger Kreditkarten erlaubt wird (vgl. Google [2011]). Google wallet untersttzt keine Peer-to-Peer berweisungen zwischen einzelnen Clients. Es sind ausschlielich Transaktionen zu Point of Sale Terminals vorgesehen und mglich (vgl. Google [2011]). In Abbildung 4.10 ist ein MasterCard paypass Terminal dargestellt. Es widerspricht zwar den Auswahlkriterien in Abschnitt 4.1.1, dass keine P2P Transaktionen mglich sind, allerdings demonstriert Google wallet die Speicherung klassischer Kreditkartendaten auf einem mobilen Endgert. Aus diesem Grund wurde es in die Untersuchung mit aufgenommen.
Abbildung 4.10.: Ein Nexus S 4G mit aktiver Google wallet App. Das Konto ist mit einer Citi MasterCard aufgeladen. Daneben ein MasterCard paypass Terminal, welches mit Google wallet genutzt werden kann (Quelle: Google [2011]). Ein Bezahlvorgang unterscheidet sich nur in der Eingabe der PIN von berweisungen mit Kreditkarten, welche NFC untersttzen (vgl. Google [2011] und EMVCo [2008]). Er luft fr den Kunden folgendermaen ab. 1. In der Standardeinstellung muss vor jeder Transaktion die App mittels der PIN freigeschaltet werden. Dieses Verhalten lsst sich dahingehend ndern, dass die PIN nur noch beim ersten Start der App notwendig ist.
50
Stefan Gfrrer

2. Der Benutzer hat anschlieend Zugri auf Informationen ber vergangene Transaktionen, Gutscheine und weitere Funktionen. Auerdem wird die NFC Antenne fr eine einzige berweisung aktiviert. 3. Wie eine normale Kreditkarte mit NFC muss das Smartphone jetzt an das Terminal gehalten werden. 4. Das Smartphone bertrgt via NFC die gespeicherten Kreditkarten Informationen an das Terminal. 5. Der Bezahlvorgang wird im Hintergrund abgeschlossen. Sowohl der Kunde als auch der Hndler erhalten eine Besttigung.

Fr eine gltige berweisung sind nur wenige Informationen einer Kreditkarte notwendig. In der Regel gengen die Kreditkartennummer und die Kreditkartenprfnummer. Gegebenenfalls wird auch das Ablaufdatum der Kreditkarte abgefragt. Nur in wenigen Fllen ist eine PIN fr den Abschluss der Transaktion notwendig. Bei virtuellen Einkufen im Internet entfllt sie vllig. Aus diesem Grund ist es um so wichtiger, dass die kritischen Informationen auf einem Smartphone gesichert werden ohne dass ein Angri mglich ist. Google wallet nutzt zu diesem Zweck ein spezialisiertes System das sogenannte Secure Element (vgl. Google [2011] und Abschnitt 2.4). Mobey Forum Mobile Financial Services Ltd [2010] unterscheidet drei Arten von SE. Es gibt entfernbare SE (z. B. Aufkleber), eingebettete SE, sowie SE, welche Kombinationen aus Software und Hardware sind. Google wallet verwendet SE der zweiten Kategorie. Der Hardwarechip also das Secure Element kann nur von autorisierten Applikationen angesprochen werden und besitzt einen eigenstndigen und gesicherten Speicher, der unabhngig vom restlichen System ist (vgl. Google [2011] und Mobey Forum Mobile Financial Services Ltd [2010]). Die Kommunikation zwischen Terminal und Kreditkarte, bzw. Smartphone mit Google wallet, ndet kontaktlos ber NFC statt. Der EMV Standard, auf dem Kreditkarten basieren, sieht keine gesicherte Verbindung vor. Die Transaktion wird jedoch durch ein Geheimnis auf der Karte geschtzt. Es dient zur Signierung und damit zur Besttigung der berweisung und wird jeweils dynamisch fr eine einzelne Transaktion berechnet (vgl. EMVCo [2008]). Near Field Communication kann in drei verschiedenen Modi ausgefhrt werden (vgl. Abschnitt 2.2). Es kann als Terminal agieren. In diesem Modus werden RFID-Tags ausgelesen. Zwischen zwei aktiven Gerten ist zudem ein Peer-to-Peer Modus mglich, welcher nach einem Master-Slave-Prinzip funktioniert. Beim dritten Modus
Stefan Gfrrer
51

der von Google wallet genutzt wird verhlt sich das NFC-fhige Endgert passiv. In diesem sogenannten Card Emulation Mode wird das Verhalten einer NFC-fhigen Karte simuliert. Da Google wallet die gleichen Daten wie eine echte Kreditkarte besitzt, kann es ein POS Terminal nicht von einer reellen Karte unterscheiden. Die Funktionalitt und Kompatibilitt einer echten kontaktlosen Kreditkarte mit NFC ist auf diese Weise sichergestellt. Aus diesem Grund mssen Terminals von MasterCard und Visa fr Google wallet nicht extra angepasst werden (vgl. Google [2011]). Google wallet baut whrend einer Transaktion keine eigene Kommunikationsverbindung auf. Das Terminal verwaltet die Datenbertragung und bernimmt deren Absicherung gegen unbefugten Zugri (vgl. EMVCo [2008]).

Zum Zeitpunkt der Entstehung dieser Arbeit ist Google wallet nur fr die Smartphones Nexus S 4G und Galaxy Nexus verfgbar. Das Nexus S 4G ist eine Variante des Nexus S mit integriertem Secure Element, whrend das Galaxy Nexus direkt ber ein SE verfgt. Dies schrnkt die Verbreitung von Google wallet zunchst ein (vgl. Google [2011]). Nach Kincaid [2011] ist aus diesem Grund die Verwendung von RFID-Tags in Form eines Aufklebers fr beliebige Smartphones als bergangslsung geplant. Ein Aufkleber steht dabei fr eine Kreditkarte. Die Absicherung ber die PIN entfllt (ebd.). Wie PayPal kann auch Google auf eine bestehende Infrastruktur und Marktverbreitung setzen. Visa und MasterCard sind verantwortlich fr die Verbreitung der POS Terminals. Google wallet selbst ist als eine oene Plattform entwickelt worden und ermglicht die Einbindung weiterer Dienstanbieter. Verschiedene Gutscheinanbieter stehen bereits in Partnerschaft mit Google. Ebenso integriert sich Google wallet in eine Reihe weiterer Dienste von Google, z. B. Google Places. Die Applikation verwaltet somit nicht nur Kreditkarten und die dazugehrigen Abrechnungen, sondern ermglicht auch das Aunden von untersttzten Geschften und die Anzeige von Sonderangeboten (vgl. Google [2011]). Gegenber anderen Anbietern weist Google den Nachteil eines geringeren Vertrauens im Bereich nanzieller Anwendungen auf (vgl. Patel [2011]).
In der folgenden Sicherheitsanalyse werden nur Komponenten betrachtet, die Google wallet direkt betreen. Eine allgemeine Untersuchung von MasterCard PayPass oder Visa payWave bersteigt den Umfang und das Ziel dieser Arbeit. Die Untersuchung
52
Stefan Gfrrer

wird das Point of Sale Terminal im Sinne einer Gegenstelle wie einem Zahlungsserver betrachten. Whrend der unverschlsselten bertragung zwischen Smartphone und Terminal werden eine Reihe von Kreditkarten- und Transaktionsdaten ausgetauscht. Das Abhren dieser Daten ist zwar mit einer Sonde in der Nhe des Terminals mglich, allerdings sind diese Daten nicht ausreichend um eine gltige Transaktion zu erzeugen. Ohne das in Abschnitt 4.5.2 beschriebene Geheimnis kann die Transaktion nicht signiert werden. Das Abhren der NFC Schnittstelle bietet somit fr den Angreifer nur einen geringen Wert. Um eine unerwnschte Transaktion durchfhren zu knnen, muss ein Schadprogramm ein Terminal auf dem Smartphone simulieren. Dieses msste zudem vom Finanzinstitut akzeptiert werden. Entsprechend ist ein aktiver Angri durch ein Schadprogramm nicht mglich. Obwohl Google wallet weitestgehend wie eine echte Kreditkarte funktioniert, bietet es einen zustzlichen Schutz in Form der PIN Abfrage vor jedem Geldtransfer. Klassische Kreditkarten knnen in verschiedenen Szenarien ohne Besttigung mit einer PIN genutzt werden. Dies ist bei Google wallet nicht mglich. Ein Angreifer mit physikalischem Zugri kann die NFC bertragung mit Google wallet ohne das Wissen um die PIN nicht aktivieren. Eine geringfgig grere Gefahr besteht, wenn die Einstellung fr die PIN-Abfrage gendert wird. In diesem Fall ist die PIN nur noch fr die Aktivierung der Applikation ntig. Sobald dies geschehen ist, knnen beliebig viele Transaktionen durchgefhrt werden. Die Sicherheit der PIN ist fr den Betrieb von Google wallet essentiell. Eine Untersuchung von Rubin [2012] zeigt, dass ein Angreifer mit ausreichendem Zugri die PIN trotzdem auslesen kann. Die PIN wird nicht auf dem Secure Element gespeichert, sondern in einer zu Google wallet gehrenden lokalen Datenbank auf dem Smartphone. Die PIN ndet sich darin als Hash mit dem dazugehrendem Salt. Ein Schadprogramm oder ein fremder Nutzer mit ausreichend Zeit kann den Hash und den Salt auslesen und mittels Brute Force die dazugehrige in das Secure Element verschoben wird (ebd.). Eine frhere Untersuchung von Viaforensics [2011] stellt die tatschliche Nutzung des Secure Element infrage. Innerhalb der bereits erwhnten Datenbank konnten verschiedene Kreditkarteninformationen aufgefunden werden. Auch wenn diese Daten nicht fr die Herstellung einer geflschten Kreditkarte nutzbar sind, bieten sie trotzdem ausreichend Informationen fr die Durchfhrung einer Card not present transaction (CNP). Eine CNP ist eine Geldberweisung in welche die physikalische Kreditkarte nicht involviert ist, sondern nur eine Reihe von Informationen derselbigen. Diese Daten knnen wiederum von einem reellen Angreifer oder durch ein
Stefan Gfrrer
53

Schadprogramm ausgelesen werden. Listing 4.1 zeigt einen Ausschnitt von Informationen, die in der Datenbank gefunden werden knnen (ebd.).
1 2 3 4 5
MasterCard-xxx-9999" Andrew HoogP 99,999.99 2,222.22 9999
Listing 4.1: Informationen aus der Datenbank von Google wallet. Von oben nach unten: Bezeichner der Karte, Name des Besitzer, Kreditlimit, aktuelles Guthaben und die letzten vier Ziern der Kartennummer (Quelle: Viaforensics [2011]; im Auszug).
4.5.5. Fazit
Der Umgang mit kritischen Informationen in Google wallet ermglicht die Angrie A1 und A5. Whrend einer Transaktion knnen weitere Daten abgehrt werden, entsprechend ist auch A7 mglich. Da eine berweisung nur mittels POS Terminal durchgefhrt werden kann, ist A2 nicht von Bedeutung. Dasselbe gilt fr A3 und A4, da nur eine Kommunikation mit dem Terminal stattndet. Social Engineering gem A6 ist fr Google wallet nicht mglich, da keine Anmeldedaten existieren. Zwar kann die PIN abgefragt werden, diese ist ohne das eigentliche Smartphone jedoch ohne Nutzen.
4.6. Bitcoins
Elektronische Geldsysteme, welche dezentral ohne Bank als kontrollierende dritte Partei arbeiten, mssen sich mit der Problematik des mehrfachen Ausgebens von Geldeinheiten auseinandersetzen. Nakamoto [2009] hat mit Bitcoin einen Peer-toPeer basierten Lsungsansatz vorgestellt. An die Stelle einer Kontrollinstanz tritt ein Netzwerk, welches Aufzeichnungen ber jede Transaktion speichert. Diese Aufzeichnungen werden in Form eines Hash in eine fortlaufende Kette von bereits geprften Transaktionen eingebunden. Eine berweisung kann nur gendert werden, wenn die komplette Kette manipuliert wird. Diese Kette wird des Weiteren dadurch geschtzt, dass das Netzwerk nur die lngste Kette akzeptiert. Die lngste Kette wird per Denition durch die Gruppe mit der grten Rechenleistung generiert. Nakamoto [2009] geht davon aus, dass die grte Gruppe nie aus Angreifern bestehen kann, da andernfalls ein Groteil des Netzwerks korrumpiert sein muss. Dies folgt
54
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.6. Bitcoins

der kryptologischen Idee des Web of Trust (WOT). Das Einbetten einer Transaktion in die Kette ist aufgrund der verwendeten Einwegfunktionen nicht umkehrbar. Damit ist auch eine Rckbuchung nicht mglich. Geldeinheiten sogenannte Bitcoins werden durch Berechnung eines initialen Hash und damit durch eine erste Transaktion erzeugt. Der Aufwand fr die Erzeugung steigt in regelmigem Abstand. Die Zahl an mglichen Bitcoins ist limitiert. Zustzliche Einnahmen sind durch geringe Gebhren mglich. Ein Nutzer erhlt die Gebhr fr die Bearbeitung einer Transaktion. Teilnehmer im Netzwerk werden ber eine Bitcoin Adresse eine kodierte Zeichenkette referenziert (vgl. Nakamoto [2009] und Bitcoin Project [2012]). Fr das Bitcoin Netzwerk gibt es eine Reihe von Clientprogrammen fr verschiedene Betriebssysteme und Plattformen. Fr Android basierte Smartphones stehen eine Reihe von Apps zur Verfgung. Die vorliegende Arbeit untersucht Bitcoin Android (vgl. Armstrong [2012]) und Bitcoin Wallet (vgl. Schildbach [2012]), welche jeweils neben der reinen Funktionalitt als Bitcoin Client alle in Abschnitt 4.1 beschriebenen Kriterien fr ein mobiles Bezahlsystem mit Peer-to-Peer Funktion erfllen. Sie werden unabhngig voneinander entwickelt und stehen jeweils als Quellcode fr die Untersuchung zur Verfgung. Der folgende Ablauf trit auf beide Apps zu. In Abbildung 4.11 wird er visuell dargestellt. 1. Der Geldempfnger teilt dem Zahlenden seine Bitcoin Adresse mit. Optional kann er den gewnschten Betrag angeben. 2. Der Zahlende gibt nach Empfang der Bitcoin Adresse den Betrag ein und schliet dadurch die Transaktion ab. 3. Die Transaktion wird vom Client des Zahlenden dem Bitcoin Netzwerk mitgeteilt. 4. Das Netzwerk veriziert die Transaktion. Gleichzeitig informiert sich der Client des Geldempfngers ber neue Transaktionen und erhlt auf diesem Weg Informationen ber den empfangenen Betrag.

Benutzer innerhalb des Bitcoin Netzwerks werden anhand einer Bitcoin Adresse identiziert. Diese Adresse dient zum Empfangen und Senden von Bitcoins. Sie wird in der sogenannten Wallet zusammen mit den zur Adresse gehrenden Schlsseln gespeichert. Ein Benutzer, und somit auch dessen Wallet, kann beliebig viele Bitcoin Adressen besitzen. Der Verlust oder Diebstahl der Wallet fhrt zum Verlust des gesamten Guthabens. Bitcoin Adressen sind in ihrer Form vollkommen anonym und
Stefan Gfrrer
55

3. Bitcoin Adresse bertragen (QR Code, NFC, Bluetooth...) Geldempfnger 1. Bitcoin Adresse senden, optional Betrag 4. Besttigen, optional Betrag und Zweck
Zahlender 2. Empfang aktivieren
6b. Mitteilung ber Empfang
5. Abgeschlossene Transaktion
6a. Verifikation durch andere Clients
Abbildung 4.11.: Ablauf einer mobilen berweisung im Bitcoin-Netzwerk (eigene Darstellung). lassen keine Rckschlsse auf die wahre Identitt des Benutzers zu (vgl. Bitcoin.it Wiki [2012]). Beide in dieser Arbeit vorgestellten Apps basieren auf BitCoinJ, einer Implementierung von Bitcoin in Java. BitCoinJ verzichtet auf die Verwendung der kompletten Kette von verizierten Transaktionen, sondern nutzt eine vereinfachte Variante, die von Nakamoto [2009] zusammen mit der ausfhrlichen Methode vorgestellt wurde. Dies verringert die ntige Datenmenge fr den Betrieb von Bitcoin und eignet sich damit besonders fr mobile Systeme. BitCoinJ bietet Klassen fr die Wallet und den Umgang mit Transaktionen. Die ermglicht den Entwicklern durch reine Implementierung einer Programmoberche eine komplette Anwendung fr das Bitcoin Netzwerk zu entwickeln (vgl. Hearn u. a. [2012]). Beide Applikationen verbreiten die Bitcoin Adresse standardmig durch einen QR Code, welcher zustzlich den gewnschten Betrag enthalten kann. Bitcoin Wallet bietet zudem die native Untersttzung von NFC. Unabhngig davon nutzen beide Apps aber auch die Mglichkeiten des Betriebssystems. Unter Android knnen sich Programme fr die Behandlung von bestimmten Dateiformaten anmelden. Diese Programme werden bei Aufruf eines entsprechenden Formats automatisch gestartet oder im Fall von mehreren Programmen dem Benutzer zur Auswahl angeboten. Beide Apps bieten die Verteilung der Bitcoin Adresse als Text an. Abhngig von
56
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.6. Bitcoins

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

Bitcoin ist eine komplett virtuelle Whrung und besitzt ursprnglich keinen reellen Gegenwert. Aufgrund der steigenden Bekanntheit, den geringen Transaktionsgebhren und der mglichen Anonymitt akzeptieren verschiedene Dienstanbieter Bitcoins als Zahlungsmittel. Dazu gehren sowohl Dienste im Internet als auch Hndler mit materiellen Artikeln und Dienstleistern. Auf dieser Basis ist ein Tauschhandel gegen reelle Whrungen entstanden, der hnlich der Brse Kursschwankungen unterliegt (vgl. Bitcoin.it Wiki [2012]).
Die folgende Analyse untersucht nicht die Sicherheit von Bitcoin. Es werden ausschlielich Angrie auf die vorgestellten Android Apps durchgefhrt. Eine Untersuchung von Bitcoin selbst entspricht der in Abschnitt 4.2 ausgeschlossenen Analyse der Infrastruktur und ist somit nicht Teil dieser Arbeit. In Abschnitt 4.6.2 wurde bereits darauf hingewiesen, dass beide vorgestellten Apps auf Basis von BitCoinJ entwickelt wurden. Die folgenden Untersuchungen betreen darum beide Programme gleichermaen. Unabhngig von der Sicherheit der eigentlichen Transaktion stellt die Sicherheit der Wallet eine kritische Komponente im Bitcoin Netzwerk dar. Sowohl Armstrong [2012] als auch Schildbach [2012] empfehlen deswegen nur geringe Betrge auf der Wallet des Smartphones zu hinterlegen. Einerseits besteht die Gefahr, dass das mobile Endgert verloren geht. Anderseits steigt fr Angreifer die Attraktivitt aufgrund des mglichen nanziellen Gewinns durch den Besitz von Bitcoins. Ein Schadprogramm kann die Wallet entsprechend kopieren und das Original lschen. Die Sicherheit hngt in diesem Fall von einer Verschlsselung der Wallet mit einem externem Geheimnis beispielsweise einer PIN und den Mechanismen des Betriebssystems ab. BitCoinJ nutzt nur letzteres und speichert die Wallet unverschlsselt im internen Speicher des Smartphones. hnliche Mglichkeiten hat auch ein Angreifer mit physikalischem Zugri auf das Handy. Unter Nutzung von entsprechenden Rechten kann er die Wallet manuell auslesen und entfernen. Des Weiteren schtzt keine der beiden Apps die Programmoberche und die mglichen Aktionen. Ein Angreifer kann aus diesem Grund
Stefan Gfrrer
57

Betrge durch eine einfache Transaktion stehlen. Durch die Unumkehrbarkeit aller Transaktionen im Bitcoin Netzwerk ist dieser Diebstahl nicht mehr rckgngig zu machen. Die Oberche und damit auch das Versenden von Betrgen knnte unabhngig von BitCoinJ durch Abfrage eines Geheimnisses geschtzt werden. Nativ sehen beide Apps zur bertragung der Bitcoin Adresse nur QR Codes oder, im Fall von Bitcoin Wallet, zustzlich NFC vor. Durch die beschriebene Verwendung der Textversendung ber weitere, installierte Programme steigt jedoch die Gefahr eines Man-in-the-Middle. Verschiedene Kommunikationswege wie Bluetooth sind angreifbar und erlauben die Manipulation der bertragenen Daten (vgl. Mutchukota u. a. [2011]). Ein Schadprogramm kann sich in Android auch als Empfnger fr Texte registrieren und durch den Namen eine Applikation zum Versenden von Bitcoin Adressen vortuschen. Die Adresse wird dann gegen die eines Angreifers ausgetauscht und ber vorhandene Kommunikationsmittel an den Zahlenden bergeben. Da die Bitcoin Adresse nicht sprechend ist, ist die Gefahr eines unerkannten Austauschs hoch. Da beide Apps kompatibel mit bestehenden Bitcoin Clients sein mssen, ist eine Verschlsselung der Adresse nur bedingt mglich. Dasselbe gilt fr eine Signatur. Das Bitcoin Netzwerk sieht zwar keinerlei Anmeldemechanismen vor, allerdings gibt es eine Reihe von Diensten, welche die Weitergabe der Wallet voraussetzen. Dabei handelt es sich beispielsweise um die Onlinespeicherung der Wallet (vgl. Bitcoin Project [2012] und Bitcoin.it Wiki [2012]). Unter Anwendung von Social Engineering knnen die Anmeldedaten zu diesen Diensten ermittelt und die Wallet gestohlen werden. Allerdings ist dies mit den vorgestellten Apps nicht mglich, da sie die Wallet im internen Speicher des Smartphones speichern. Dieser ist fr einen normalen Anwender nicht erreichbar (vgl. Google [2012d]). In vorherigen Abschnitten wurde die mgliche Anonymitt als ein Vorteil von Bitcoin dargestellt. Eine Bitcoin Adresse basiert nicht auf reellen Daten und jeder Benutzer kann sich eine beliebige Anzahl von Adressen erzeugen. Dies trit auch zu wenn kein Kontakt zu personenbezogenen Informationen stattndet. Reid u. Harrigan [2011] zeigen, dass durch die Verentlichung der Bitcoin Adresse und deren Verwendung zum Bezahlen eine Verknpfung zwischen einer Person und all ihren Bitcoin Adressen mglich ist. Die Anonymitt des Netzwerks hebt sich somit durch dessen Nutzung auf (ebd.). In Abbildung 4.12 sind Benutzer als Knoten und Transaktionen als Kanten dargestellt. Es ist erkennbar, dass ein zentraler Knoten eine groe Anzahl an berweisungen erhalten hat. Er wurde als die Webseite Wikileaks identifziert (vgl. Reid u. Harrigan [2011]).
58
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.7. A 2D Barcode-Based Mobile Payment System
Wikileaks
Abbildung 4.12.: Grasche Darstellung eines Ausschnitts des Bitcoin Netzwerks rund um Wikileaks (Quelle: Reid u. Harrigan [2011]; [Hervorhebung durch Verfasser]).
4.6.5. Fazit
Sowohl eine Transaktion als auch die Wallet selbst sind vor den Angrien A2, A4 und A5 ungeschtzt. Keine Bedeutung haben A1, A3 und A7, da bertragene und gespeicherte Daten ohne Gefahr fr das Verfahren gelesen werden knnen. Unter der Voraussetzung, dass der normale Anwender keinen Zugri auf die Wallet erhlt, sind beide Verfahren vor A6 sicher. Als zustzlicher Angri kommt die Oenlegung der reellen Identitt der Anwender hinzu. Applikationen fr Bitcoin sind somit zwar gegen passive Angreifer geschtzt, allerdings sehr anfllig fr aktive Manipulation.
4.7. A 2D Barcode-Based Mobile Payment System

Gao u. a. [2009] haben ein mobiles Bezahlsystem unter Verwendung von 2D Barcodes entwickelt. Es hnelt eKaayCash und ist fr die Bezahlung von Produkten in Geschften gedacht. Das Verfahren wurde im Zuge der Erforschung von 2D Barcodes in kommerziellen System entwickelt. Obwohl ein funktionierender Prototyp umgesetzt wurde, ist die Arbeit rein theoretischer Natur und dient als Untersuchungsobjekt
Stefan Gfrrer
59

fr mgliche Anwendungen von 2D Barcodes. Das Verfahren untersttzt keine Peerto-Peer Transaktionen (ebd.). Aufgrund der hnlichkeit mit eKaayCash ist aber eine Implementierung mglich. Dazu wird eine Webseite bentigt, welche wie bei eKaayCash aus Eingabedaten dynamisch einen 2D Barcode erzeugt und anzeigt. Die Verwendung von 2D Barcodes als grundlegende Technik wird mit der vereinfachten Anwendung des Verfahrens fr Hndler und Kunden begrndet. Ein 2D Barcode knne alle notwendigen Daten zur Identizierung eines Produktes enthalten und erlaube zustzlich erste Informationen, welche dem Kunden angezeigt werden knnten (vgl. [Gao u. a. 2009, Seite 322]). Diese Begrndung deckt sich mit der Verwendung von 2D Barcodes in eKaay und damit auch in eKaayCash. Fr die Anwender Hndler und Kunde stellt sich der Ablauf des Verfahrens folgendermaen dar: es wird davon ausgegangen, dass sich der Kunde bereits in der App angemeldet hat und vom Hndler ein 2D Barcode fr das Produkt erstellt wurde. 1. Der Kunde fotograert den 2D Barcode eines Produktes ab. Dieser Barcode enthlt einen Verweis auf die Produktseite des Hndler im Internet. 2. Die Produktseite wird vom Kunden aufgerufen. 3. Der Benutzer erzeugt eine Kaufanfrage fr das Produkt und sendet diese an den Hndlerserver. 4. Der Server antwortet mit einer Rechnung. 5. Die Rechnung wird vom Handy des Kunden in Form einer Zahlungsanfrage an den Zahlungsserver weitergeleitet. 6. Der Zahlungsserver fhrt die Transaktion durch und sendet eine Besttigung an den Kunden und an den Hndler. Der Ablauf ist in Abbildung 4.13 graphisch dargestellt.

Das Verfahren verschlsselt und signiert den Datenverkehr zwischen den einzelnen Parteien mobiler Endnutzer, Server des Hndlers und Zahlungsserver mittels asynchroner Verschlsselung, die auf auf Elliptic Curve Cryptography (ECC) basiert. Alle Schlssel, welche fr die Verschlsselung der Datenbertragung notwendig sind, werden auf dem Handy des Kunden mit dem Advanced Encryption Standard (AES) geschtzt und die Integritt wird mittels Keyed-Hash Message Authentication Code
60
Stefan Gfrrer

Produktcode 2. Einlesen 1. Anmeldung Kunde
5. Bezahlanfrage 3. Kaufanfrage
4. Rechnung
Zahlungsserver Hndlerserver
Abbildung 4.13.: Ablauf eines Produktkaufs mit Hilfe des 2D Barcode Verfahren. Nicht enthalten sind die Besttigungen an Kunden und Hndler (eigene Darstellung). (HMAC) sichergestellt. Die individuelle PIN kommt dabei als Schlssel zum Einsatz (vgl. Gao u. a. [2009]). Als Implementierung des 2D Barcodes wird die von der Firma RVSI/Acuity CiMatrix entwickelte DataMatrix verwendet (vgl. [Gao u. a. 2009, Seite 321]). Sie kommt im mobilen Bezahlsystem an zwei Stellen zum Einsatz. Einerseits stellt sie dem Kunden alle wichtigen Informationen ber das Produkt zur Verfgung, andererseits werden alle Kommunikationsdaten vor ihrer bertragung mit Hilfe einer DataMatrix kodiert (ebenda). Der Einsatz der DataMatrix als Kommunikationskodierung wird in der Arbeit nicht schlssig begrndet. Sie bietet keinen Vorteil gegenber anderen Kodierungen. Da eine Kodierung jedoch keinen Einuss auf die eigentliche Sicherheit hat, wird dieses Faktum im weiteren Verlauf ignoriert. Im Folgenden wird der detaillierte, technische Ablauf erlutert. Er umfasst als ersten Schritt auch die Anmeldung des Kunden beim Zahlungsserver. Dieser Schritt entfllt bei nachfolgenden Transaktionen. 1. Ein registrierter Kunde meldet sich mit seinem Benutzerkonto und der PIN beim Zahlungsserver an. Der Server besttigt die Anmeldung mit der ID des Serverzertikats, der Session ID und einem entlichen Schlssel fr die weitere Kommunikation. Er wird vom mobilen Client unter Nutzung des Serverzertikats und des entlichen Schlssel authentiziert.
Stefan Gfrrer
61

2. Der Kunde liest einen 2D Barcode ein. Dieser enthlt neben dem bereits erwhnten Verweis zur Produktseite des Hndlers auch allgemeine Informationen ber das Produkt. Der Benutzer ruft die Produktseite auf und erstellt einen Kaufanfrage fr den Hndler. Die Anfrage wird digital signiert und an den Hndler bertragen. 3. Der Hndlerserver verarbeitet die Kaufanfrage. Er authentiziert dabei den Kunden mittels der Session ID und dem entlichen Schlssel. Die digitale Signatur wird mittels des geheimen Schlssels validiert. Der Server antwortet mit einer wiederum digital signierten Rechnung mit einer Transaktions ID an den mobilen Client. 4. Auf Basis der Transaktions ID erzeugt der mobile Client eine Zahlungsanfrage. Sie wird mit dem geheimen Schlssel des Kunden signiert. Vor der bertragung wird eine sichere Verbindung zwischen mobilem Client und Zahlungsserver aufgebaut. Nach Erhalt der Zahlungsanfrage berprft der Server die Daten und verarbeitet die Anfrage. Nach erfolgreichem Abschluss der Transaktion sendet er eine unsignierte Besttigung an den Kunden und an den Hndler.

Da es sich bei der Verentlung um eine reine Forschungsarbeit handelt, wird das Verfahren nicht reell eingesetzt. Dies ist jedoch mglich. Dabei stellt sich die Einbindung fr den Hndler als einfach dar. Dieser muss einen Server mit der notwendigen Software zur Verfgung stellen und die Produkte mit dem jeweiligen 2D Barcode kennzeichnen. Fr einen Kunden ist die Installation der App notwendig. Der Einkauf und das Bezahlen einzelner Produkte erfolgt durch abfotograeren des Codes und bentigt nur geringe Interaktion von Seiten des Benutzers. Sowohl fr den Hndler als auch fr den Kunden ist ein Konto auf dem Zahlungsserver Voraussetzung.
Aufgrund der Verwendung von ECC zur Verschlsselung und Signierung der bertragenen Daten, sind die Kommunikationskanle im Verfahren als sicher zu betrachten. Ein Schadprogramm auf dem Smartphone des Kunden kann hingegen sofern die Sicherheitsmechanismen des Betriebssystems umgangen sind eigene Transaktionen abwickeln. Zu diesem Zweck muss es die PIN bei ihrer Eingabe abfangen, um anschlieend Zugri auf die verschlsselten sicherheitsrelevanten Daten, wie der private Schlssel des Kunden, welche auf dem Handy gespeichert werden, zu bekommen. Unabhngig von Transaktionen des Kunden kann das Schadprogramm anschlieend fr
62
Stefan Gfrrer

den Zahlungsserver valide Transaktionen durchfhren. Das Schadprogramm kann einerseits ferngesteuert Bezahlvorgnge fr den Angreifer vornehmen oder anderseits Einkufe bei einem vom Angreifer geflschten Hndler durchfhren. Bei lngerem Zugri auf ein Handy mit angemeldetem Benutzerkonto sind regulre Bezahlvorgnge fr einen Angreifer theoretisch mglich. Aus der Beschreibung des Verfahrens geht nicht hervor, wann die Eingabe der PIN notwendig ist. Die Gefahr des physikalischen Zugris auf das Endgert kann durch eine PIN Abfrage bei jedem Bezahlvorgang, wie auch bei PayPal Mobile Payments, abgewehrt werden (vgl. Abschnitt 4.4.4). Die Anmeldung beim Zahlungsserver ndet mit Hilfe der Kontodaten und der PIN statt. Diese knnen von einem Angreifer mittels Social Engineering ermittelt werden. Das Wissen um die Anmeldedaten allein ermglicht jedoch noch nicht die Durchfhrung einer Transaktion. Bei der Registrierung fr das Verfahren wird unter anderem der private Schlssel des Kunden auf dessen Handy abgelegt. Ohne diesen Schlssel kann ein Angreifer keine Transaktion signieren und durchfhren. Das Verfahren wird mit dem Fotograeren des Produkt-Barcodes initiiert. Dieser Barcode kann von einem Angreifer physikalisch oder mit Hilfe eines Schadprogramms auf dem mobilen Endgert ausgetauscht werden. Der geflschte 2D-Code kann smtliche Informationen des Originals enthalten, verweist aber auf eine geflschte Produktseite. Das Hndlerkonto hinter dieser Produktseite muss regulr beim Zahlungsserver registriert sein. Diese Art von Angri wird im Normalfall sehr schnell auallen, da keines der scheinbar bezahlten Produkte tatschlich gekauft wurde.
4.7.5. Fazit
Die Kommunikation ist sicher in diesem Verfahren und NFC wird in diesem Fall nicht angewandt. Aus diesen Grund sind A3, A4 und A7 nicht mglich. Des Weiteren bietet das Verfahren durch die Aufteilung des Geheimnisses in Wissen Anmeldedaten und PIN und Besitz der private Schlssel auf dem Smartphone einen guten Schutz vor A6. Allerdings kann ein Schadprogramm zunchst die PIN auslesen und dann selbst eine Transaktion ausfhren. Auerdem ist der Austausch des 2D-Codes vor Beginn einer Transaktion mglich. hnliche Angrie knnen auch durch physikalischen Zugri ausgefhrt werden. Damit ist das Verfahren durch A1, A2 und A5 angreifbar.
Stefan Gfrrer
63
4.8. A Wireless Payment System

In mobilen Endgerten, welche kein NFC untersttzen, dient in vielen Fllen Bluetooth als Standard fr Kurzstreckenkommunikation. Mutchukota u. a. [2011] haben gezeigt, dass Bluetooth durch Man-in-the-Middle angreifbar ist und somit ein sicherer Kanal ntig wird. In einer Analyse kann eine Verbindung via Bluetooth somit als ein Kommunikationsweg betrachtet werden, welcher durch Lauschangrie und Manipulation bedroht wird. Gleichzeitig ist eine Nutzung fr P2P Applikationen mglich. Von Gao u. a. [2006] wird Bluetooth aus diesem Grund fr ein mobiles Peer-to-Peer Bezahlsystem verwendet, welches eine hohe Kompatibilitt zu bestehenden mobilen Endgerten bietet. Im Folgenden wird der Ablauf beschrieben. Dieser ndet sich auch in Abbildung 4.14. Voraussetzung fr den Vorgang ist, dass sich beide Teilnehmer der Transaktion mit Hilfe ihrer P2PID einer individuellen ID im Bezahlsystem und ihrem Passwort anmelden. Fr zuknftige Implementierungen ist zustzlich eine Verikation ber die Stimme des Nutzers geplant (vgl. [Gao u. a. 2006, Abschnitt 4]). 1. Im ersten Schritt mssen Zahlender und Geldempfnger ihre Rolle in der Transaktion auswhlen. Dies geschieht ber die Programmoberche. 2. Nach Identizierung aller erkannten Geldempfnger in Reichweite muss der Zahlende den korrekten Empfnger auswhlen. 3. Der Zahlende muss die Transaktion im folgenden Schritt durch Eingabe des Betrags abschlieen. 4. Das mobile Endgert sendet die Daten der Transaktion an den Zahlungsserver. Dieser veriziert sie und fhrt die eigentliche Geldberweisung durch. Sowohl der Geldempfnger als auch der Zahlende erhalten eine Besttigung.

Da Bluetooth im Gegensatz zu NFC unabhngig von der physikalischen Nhe ist, sind zunchst Verbindungen zu beliebigen, aktiven Endgerten mit Bluetooth mglich. Aus diesem Grund bietet das Service Discovery Protocol (SDP) Schnittstellen, um bestimmte Dienste in einer unbekannten Umgebung aufzunden (vgl. Suchy [2007]). Im vorliegenden Verfahren ndet es alle Endgerte mit installiertem Client, welcher aktiv die P2PID sendet. Diese ID identiziert die Benutzer des Bezahlsystems und wird nur von Geldempfngern verteilt. Gleichzeitig bildet diese ID den
64
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.8. A Wireless Payment System

3. P2PID bertragen (Bluetooth) Geldempfnger 1. P2PID ber Bluetooth senden 4. Betrag eingeben Zahlender 2. Empfang via Bluetooth aktivieren
5. Besttigte Zahlungsanfrage (Internet)
Zahlungsserver
Abbildung 4.14.: Ablauf einer P2P berweisung mit Hilfe von Bluetooth. Die Besttigung wurde entfernt (eigene Darstellung).
sprechenden Namen, welcher dem Zahlenden zusammen mit allen gefundenen Teilnehmern in Reichweite zur Auswahl aufgelistet wird (vgl. Gao u. a. [2006]). Das Verfahren arbeitet mit einer symmetrischen Verschlsselung. Dazu wird im Zuge der Registrierung ein individueller Schlssel generiert. Er wird kodiert auf dem Endgert gespeichert. Fr einzelne Sitzungen wird aus diesem Schlssel ein weiterer generiert, welcher zum Schutz der kritischen Daten der Transaktion dient. Der Sitzungsschlssel wird dem Server mit Hilfe eines an jede Nachricht angehngten Header mitgeteilt. Dieser Header enthlt in der ersten Nachricht den Schlssel und seine Lnge. Die Information ber den Schlssel enfllt in den weiteren Nachrichten. Enthalten ist aber immer eine Signatur und die Information, welche Datenfelder in der jeweiligen Nachricht verschlsselt sind. Die Signatur wird aus den Nutzdaten und dem bei der Registrierung erzeugten Schlssel berechnet (vgl. Gao u. a. [2006]). Der Aufbau des Header ist in Tabelle 4.2 dargestellt. Signatur Schlssel Schlssellnge verschlsselte Felder
Tabelle 4.2.: Der Sicherheitsheader fr Nachrichten im Verfahren mit Bluetooth. Er wird an die eigentlichen Nutzdaten angehngt (vgl. Gao u. a. [2006]; [bersetzung durch Verfasser]).
Wie im vorherigen Abschnitt bereits erwhnt, soll in zuknftigen Versionen des Verfahrens eine Verikation der Stimme des Nutzers implementiert werden. Aufgrund von Limitierungen von mobilen Endgerten zum Zeitpunkt der Verentlichung des Verfahrens msse ein neues, optimiertes Verfahren entwickelt werden (vgl. [Gao u. a.
Stefan Gfrrer
65

2006, Seite 4]). Der Vorteil von biometrischen Daten liegt in ihrem hohem Flschungsschutz gegenber klassischen Passwort-Systemen. Aus technischer Sicht lsst sich der Ablauf des Bezahlsystems in zwei grundlegende Phasen aufteilen. Der erste Abschnitt umfasst die Phase der Verentlichung der P2PID via Bluetooth bis zum Punkt an dem der Zahlende die Transaktion mit Eingabe des Betrags abschliet. Aus der Arbeit geht nicht hervor, inwiefern die Kommunikation mittels Bluetooth abgesichert ist. Die Verwendung des bekannten Sicherheitsheaders ist jedoch angedacht. ber diesen Kanal werden keine kritischen Daten bermittelt, da er rein zum Austausch der P2PID dient. Die zweite Phase im Verfahren ist die bermittlung der besttigten Transaktion an den Server. Neben dem Schutz durch den Sicherheitsheader und die Verschlsselung mittels symmetrischem Verfahren sollen auch sichere Verbindungen mittels SSL oder TLS zum Einsatz kommen (vgl. [Gao u. a. 2006, Seite 3]).

Als theoretische Arbeit wird dieses Verfahren in der vorliegenden Form auerhalb eines Prototyps nicht eingesetzt. Fr Benutzer des Dienstes kann vor allem die Verzgerung durch den Verbindungsaufbau von Bluetooth und durch die verschiedenen notwendigen Interaktionen mit der Programmoberche strend wirken. Vorteilhaft ist die sehr hohe Kompatibilitt mit lteren und neueren Handys, welche selbst von Verfahren auf Basis von Kameras nicht erreicht werden kann. Fr diese ist zudem ein ausreichend groer und verhltnismig hochausender Bildschirm ntig, wie er erst in jngeren Smartphones existiert.
Der Aufteilung des Verfahrens in zwei Phasen, wie in Abschnitt 4.8.2 dargestellt, folgend, besteht der erste mgliche Angri im Austausch der P2PID vor Besttigung der Transaktion. Dieser Angri entspricht dem in Abschnitt 4.4.4 beschriebenem Szenario. Ein Schadprogramm auf dem Handy des Geldempfngers oder des Zahlenden kann die ID vor dem Versenden oder direkt nach dem Empfang gegen die P2PID des Angreifers austauschen. Dieser Angri kann bei sprechenden IDs zwar vom Zahlenden durch eine manuelle Kontrolle erkannt werden, die Erzeugung eines neuen Kontos mit einer visuell hnlichen ID ist aber theoretisch mglich. Der Austausch der ID kann nicht nur durch ein Schadprogramm erfolgen, sondern ist mittels Man-in-the-Middle auch whrend der Bluetooth Verbindung mglich. Wie auch bei PayPal kann die Signierung der ID begrenzten Schutz vor Manipulation
66
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.8. A Wireless Payment System

der Daten bieten. Fr ein Schadprogramm auf dem Handy des Geldempfngers stellt dies jedoch kein Hindernis dar. Nach Besttigung der Transaktion durch den Zahlenden kann ein Schadprogramm die signierten und verschlsselten Daten manipulieren, wenn es Zugri auf den Schlssel hat. Die Sicherheit hngt also von den Mechanismen des Betriebssystems ab. Die eigentliche bertragung zum Server erfolgt wie beschrieben mittels sicherer Verbindungen zustzlich zum Schutz durch den Sicherheitsheader. Sofern ein erfolgreicher Man-in-the-Middle Angri auf die SSL oder TLS Verschlsselung durchgefhrt wurde, besteht die Gefahr, dass das erste Datenpaket mit dem Schlssel fr die Transaktion mitgelesen wird. In diesem Fall kann ein Angreifer die Transaktionsdaten auslesen. Eine Manipulation ist weiterhin nicht mglich, da die Signatur mit dem Registrierungsschlssel erzeugt wurde. Der symmetrische Registrierungsschlssel ist in der vorliegenden Version die kritische Komponente im System. Wenn der mobile Client angemeldet ist, kann bei erfolgreichem Diebstahl dieses Schlssels jede beliebige Transaktion ohne Mitwirken des Benutzers ausgefhrt werden. Gao u. a. [2006] bezieht sich zwar auf eine Kodierung des Schlssels, diese wird jedoch nicht nher erlutert und die Nutzung eines externen Geheimnisses beispielsweise eine PIN ist nicht vorgesehen. Aufgrund des Verzichts auf eine Besttigung der Transaktion mittels PIN, erlaubt der physische Zugri die Durchfhrung einer berweisung. Dazu muss der Client angemeldet sein. Ist dies nicht Fall, hat sowohl ein physischer Angreifer als auch ein Schadprogramm keine Mglichkeit eine Transaktion zu erzeugen. Die Anmeldedaten knnen zwar mittels Social Engineering ermittelt werden, jedoch wird dies bei Einfhrung der Stimmverizierung erschwert. Der technische Aufwand ist in diesem Fall fr einen Angreifer deutlich hher.
4.8.5. Fazit
Dieses Verfahren bietet eine Reihe von Sicherheitsmechanismen, welche teilweise angegrien werden knnen. Zwar ist A7 nicht mglich und A6 kann nach Einfhrung der Stimmverizierung als sicher betrachtet werden, dennoch bieten sich sowohl fr Schadprogramme als auch fr Man-in-the-Middle Angrie eine Reihe von Mglichkeiten zur Manipulation und zur Erzeugung eigener Transaktionen. Letzteres ist auch fr einen physikalischen Angreifer mglich, wenn die App angemeldet ist. Daraus folgt das A1, A2, A4 und A5 erfolgreich durchgefhrt werden knnen. Mittels A3 knnen zudem vollstndige Transaktionen mitgelesen werden, dies setzt jedoch umfassende Angrie auf den Kommunikationskanal voraus.
Stefan Gfrrer
67
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 girogo Verfahrens vorgestellt (vgl. Deutsche Kreditwirtschaft [2012]). Es handelt sich um ein rein theoretisches Verfahren fr Smartphones, welches die Funktionalitt einer Geldkarte mit NFC und eines POS auf ein Smartphone bertrgt und auf diese Weise Peer-to-Peer Bezahlvorgnge erlaubt. Das Verfahren wurde im Zuge dieser Arbeit entworfen und sttzt sich auf die Arbeit von Cheng u. a. [2011] und auf Schnittstellenspezikationen fr Geldkarten (vgl. Deutsche Kreditwirtschaft [2011]). Die folgenden Erluterungen und Ablufe stellen entsprechend keine technische Implementierung vor. Sie beschreiben stattdessen die mglichen Ablufe, mit welchen ein P2P System auf Basis der klassischen Geldkarte auf Smartphones umgesetzt werden kann. Es wird auf explizite Erklrungen zu den Schritten einer Bezahlung mittels Geldkarte verzichtet, das gilt insbesondere fr die eigentliche Kommunikation zwischen Terminal und Karte. Die Erklrungen knnen in den Schnittstellenspezikationen fr Geldkarten eingesehen werden (vgl. Deutsche Kreditwirtschaft [2011]). Die deutsche Geldkarte, welche als girogo weiterentwickelt wurde, ermglicht bargeldlose Bezahlvorgnge ohne Kommunikationsverbindung zu einer Bank. Dies wird auch als Oine Vorgang bezeichnet. Geldbetrge werden direkt auf der Geldkarte gespeichert. Bei einem Bezahlvorgang ndet keine weitere Authentisierung des Benutzers statt und entsprechend ist das Verfahren nur fr Kleinstbetrge vorgesehen. Der Geldempfnger im klassischen Fall ist dies ein Hndler mit POS Terminal erhlt das Geld nicht sofort, sondern erst nach dem Abgleich mit der Bank. Der Abgleich ist dabei unabhngig vom Bezahlvorgang und ndet im Regelfall zu einem spteren Zeitpunkt statt (vgl. Deutsche Kreditwirtschaft [2012]). Der folgende Ablauf beschreibt das Verfahren aus Sicht der Anwender. Beide Benutzer besitzen ein Smartphone, auf welchem die App mit der Geldkarten-Funktionalitt installiert ist. Der Zahlende muss des Weiteren den notwendigen Betrag auf das Handy geladen haben. Das Auaden kann, wie bei klassischen Geldkarten, durch die Bank oder an entsprechenden Automaten erfolgen. 1. Der Geldempfnger startet die Applikation und aktiviert den Empfang eines Geldbetrags. 2. Der Zahlende startet ebenfalls die Applikation und leitet einen Bezahlvorgang durch Eingabe des Betrags ein.
68
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.9. Entwurf einer Smartphone basierten Geldkarte
3. Er besttigt den Zahlvorgang mittels Eingabe seiner PIN. Das Smartphone ist jetzt sendebereit. 4. Wie in anderen NFC basierten P2P Verfahren, werden beide Smartphones in Kontakt gebracht. Sie fhren die eigentliche Geldberweisung durch. 5. Der Abschluss des Vorgangs wird durch eine Benachrichtigung an beide Benutzer signalisiert.

Um die Sicherheit eines auf dem Smartphone gespeicherten Geldbetrags zu gewhrleisten, setzt das Verfahren auf die Verwendung eines Secure Elements. Die SoftwareApplikation dient als grasche Oberche fr den Benutzer und startet das SE. Der eigentliche Bezahlvorgang wird vom SE ber die NFC Schnittstelle durchgefhrt. Der Betrag bendet sich dabei zu keinem Zeitpunkt innerhalb der SoftwareUmgebung des Betriebssystem, sondern wird ber einen sicheren Kanal direkt in das SE geladen. Diese Aufteilung von Software, SE und NFC Schnittstelle entspricht dem Entwurf von Cheng u. a. [2011]. Der Zugri auf kritische Operationen wird vom SE nur durch Eingabe der PIN erlaubt. Im Rahmen dieses Entwurfs zhlt dazu nur die Initiierung einer Geldberweisung auf dem Smartphone des Zahlenden. Die Implementierung des Verfahrens setzt die Nutzung des Card Emulation Mode und des Read/Write Mode von NFC voraus (vgl. Abschnitt 2.2). Ersteres simuliert eine klassische Geldkarte mit NFC Schnittstelle, letzteres ein POS Terminal, welches den Geldbetrag empfngt. Aufgrund dieser Entscheidung ist das Verfahren kompatibel mit bestehenden Geldkarten. Ein Bezahlvorgang luft technisch wie folgt ab. Der Ablauf ist in Abbildung 4.15 visualisiert. 1. Das Secure Element wird vom jeweiligen Benutzer aktiviert. Von Seiten des Zahlenden ist dazu die Eingabe des Betrags und die Besttigung mit der PIN notwendig. Beides wird vom SE veriziert. 2. Die Smartphones treten in Kontakt und bauen eine sichere Verbindung auf. 3. Gem der Spezikation einer Geldkarte wird der Geldbetrag bertragen (vgl. Deutsche Kreditwirtschaft [2011]). 4. Beide SE beenden die Kommunikation und zeigen dem jeweiligen Benutzer eine Besttigung ber den Erfolg der Transaktion an.
Stefan Gfrrer
69

Geldempfnger 1a. Aktivierung des Geldempfangs Zahlender 2a. Eingabe Betrag und PIN
1b. Aktivierung App 5. Besttigung SE NFC
4. Transaktion
NFC
2b. Aktivierung SE 5. Besttigung App
3. Prfung von Betrag und PIN
Abbildung 4.15.: Ablauf einer Transaktion zwischen zwei Smartphones nach dem Geldkarten-Prinzip (eigene Darstellung).

Wie in Abschnitt 4.5.3 bereits erlutert, gibt es zum Zeitpunkt der Entstehung dieser Arbeit nur zwei Smartphones mit Secure Element und NFC. Allerdings handelt es sich um ein rein theoretisches Verfahren, welches erst von den verantwortlichen Finanzinstituten umgesetzt werden msste. Entsprechend stellt die mangelnde Hardwareuntersttzung keine Einschrnkung dar. Ein Vorteil dieses Verfahrens ist die Abwrtskompatibilitt zum bestehenden Geldkarten System. Aus diesem Grund besteht schon eine marktwirtschaftliche Basis in Form von teilnehmenden Hndlern. Das System bietet somit sowohl einen einfachen P2P Vorgang als auch das klassische bargeldlose Bezahlen mit einer Geldkarte an.
Durch die Auslagerung aller sicherheitsrelevanten Vorgnge auf das SE bietet das Verfahren eine hohe Sicherheit. Ein Schadprogramm auf dem Smartphone kann auf Ebene der Software d. h. der Applikation zwar die PIN abhren, allerdings kann mit dieser Information kein Bezahlvorgang durchgefhrt werden. Fr eine Transaktion ist immer ein Terminal notwendig. Ein Angreifer mit physischem Zugri besitzt hingegen die Mglichkeit ein Terminal zur Verfgung zu stellen, jedoch fehlt ihm das Wissen um die PIN und er kann keinen Zahlvorgang initiieren. Der Verlust oder Diebstahl des Smartphone sollte jedoch vermieden werden. Abhngig vom Finanzinstitut kann dies zum Verlust des Geldbetrags fhren.
70
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.10. Weitere Mobile Payment Lsungen

Da im Geldkarten System keine Authentisierung vorgesehen ist, knnen mittels Social Engineering keine kritischen Informationen abgefragt werden. Die PIN ist, wie schon im Zusammenhang mit Schadprogrammen erklrt, ohne das Smartphone ohne weiteren Nutzen. Das hier vorgestellte Verfahren sieht die verschlsselte Kommunikation via NFC mittels einer sicheren Verbindung vor. Eine solche Ende zu Ende Verschlsselung wurde bereits von Van Damme u. a. [2005] vorgestellt und lsst sich leicht mit NFC umsetzen. Der Kommunikationskanal beider SEs kann also als nicht angreifbar gelten. Da keine weitere Kommunikation zu einer externen Gegenstelle stattndet, sind MITM Angrie ohne von Bedeutung.
4.9.5. Fazit
Es lsst sich abschlieend feststellen, dass das vorgestellte Verfahren eine sichere Implementierung fr ein bargeldloses Bezahlsystem mit P2P Funktionalitt bietet. Die Angrie A3, A4, A6 und A7 sind nicht mglich bzw. werden durch das System abgewehrt. Mittels A1 und A2 kann zwar ein Bezahlvorgang gestartet werden, es fehlt jedoch die Gegenstelle, welche den Betrag in Empfang nimmt. Ein physischer Zugri gem A5 bietet ohne die PIN ebenfalls keine Mglichkeit fr eine berweisung.
4.10. Weitere Mobile Payment Lsungen

In diesem Abschnitt werden zwei mobile Bezahlsysteme vorgestellt, die nicht in die Analyse aufgenommen wurden. Es wird gezeigt, nach welchen Kriterien der Ausschluss 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 Trusted Computing vorgestellt. Trusted Computing verfolgt die Idee einer vollstndig abgesicherten Umgebung aus Software und Hardware, welche kritische Operationen nur nach Kontrolle der Systemintegritt erlaubt. Dies soll den Einuss durch Fremdzugrie erkennen und verhindern und auf diese Weise sichere Bezahlvorgnge erlauben. Dies stellt zwar einen interessanten Ansatz dar, allerdings wurde das Verfahren aus zwei Grnden nicht untersucht. Zunchst wird es als reines POS System beschrieben. Es ermglicht somit keine Peer-to-Peer Bezahlvorgnge. Des Weiteren konzentriert sich die Arbeit auf die Nutzung von Trusted Computing. Das eigentliche Bezahlverfahren wird jedoch nur in groben Zgen beschrieben. Auf dieser Basis
Stefan Gfrrer
71

ist zwar eine Analyse von Trusted Computing in mobilen Endgerten mglich, allerdings keine Untersuchung des eigentlichen Bezahlsystems mit Absicherung durch Trusted Computing (ebd.).
4.10.2. ISIS
ISIS ist ein Joint Venture zwischen AT&T, T-Mobile und Verizon Wireless und hat das Ziel ein mobiles Bezahlsystem zu entwickeln. Es soll hnlich wie Google wallet mit Kreditkarteninformationen auf dem Smartphone funktionieren. Zum Zeitpunkt der Entstehung dieser Arbeit ist noch nicht bekannt, ob die Daten auf einem Secure Element gespeichert oder ob andere Mechanismen zum Schutz eingesetzt werden. Das Verfahren wird wie Google wallet voraussichtlich keine P2P berweisungen ermglichen und dient als reines POS System. Im Gegensatz zu Google wallet wurde ISIS noch nicht verentlicht und es existieren keine technischen Informationen zu Ablufen und verwendeten Verfahren. Aus diesem Grund ist eine Untersuchung nicht mglich (vgl. JVL Ventures, LLC [2012]).
4.11. Zusammenfassung
Dieser Abschnitt bietet mit Abbildung 4.16 eine Zusammenfassung der obigen Analysen. Die Sicherheit wird folgendermaen bewertet: kann ein bestimmter Angri ohne weitere Bedingung erfolgreich ausgefhrt werden wird er mit markiert. im Gegensatz dazu steht die Wertung ++, welche einen nicht mglichen Angri bezeichnet. Die Abstufungen und + werden vergeben, wenn bestimmte Voraussetzungen erfllt sein mssen. Eine Sonderrolle spielt die neutrale Wertung . Sie wird vergeben, wenn der jeweilige Angri ohne Bedeutung fr das Verfahren ist. Beispielsweise untersttzt nicht jedes Verfahren NFC und entsprechend wird A7 neutral bewertet.
4.12. Diskussion
Auf Basis der untersuchten Verfahren und ermittelten Ergebnissen werden in diesem Abschnitt Gemeinsamkeiten und Unterschiede diskutiert. Des Weiteren werden whrend der Analyse die angewandten Methoden bewertet. Die Analyse hat gezeigt, dass sich die einzelnen Bezahlsysteme anhand der bekannten Ablufe untersuchen lassen. Die Angreifbarkeit durch bestimmte Anstze konnte mit gewissen Einschrnkungen nachgewiesen oder widerlegt werden. Allerdings bleiben
72
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.12. Diskussion

Name eKaayCash PayPal Mobile Payments Google wallet Bitcoins A 2D Barcode-Based Mobile Payment System A Wireless Payment System Entwurf einer Smartphone basierten Geldkarte
Legende:
A1 + + - + + +
A2 + + + + - - - +
A3 + +
A4 +
A5
A6 - + + + + + +
A7 + + + +
-/+ + + + + - -
+ + + + + + + + + - - - - +
+ + + +
+ + + +
- - leicht angreifbar, - angreifbar,
neutral,
+ sicher, + + sehr sicher
Abbildung 4.16.: Die Ergebnisse der Sicherheitsanalyse im berblick (eigene Darstellung). einzelne Punkte oen, wenn keine Einsicht in die detaillierte technische Implementierung vorliegt. Dies deckt sich mit den in Abschnitt 4.1 erluterten Kriterien und Vorbedingungen. Unabhngig von den einzelnen Sicherheitsproblemen ermglicht die Analyse nur geringe Aussagen zu kombinierten Angrien. Insbesondere die Konzentration auf einen bestimmten Nutzer kann trotz allgemeiner Sicherheit erfolgreich sein. Dies ergibt sich daraus, dass einzelne Sicherheitsmechanismen ihren Schutz unter bestimmten Annahmen einhalten. Dieser Schutz hebt sich dementsprechend auf, wenn diese Annahmen nicht mehr zutreen. Ein Beispiel hierfr ist die PIN Abfrage vor einer Transaktion. Zwar verhindert sie einen Angri durch physischen Zugri, allerdings nur wenn der Angreifer kein Wissen ber die PIN hat. Wurde das Geheimnis hingegen zuvor beispielsweise durch Social Engineering gestohlen, kann die Transaktion ausgefhrt werden. Dies muss als Restrisiko behandelt werden und bietet Mglichkeiten fr weitere Untersuchungen. Die Analyse zeigt, dass sich die Ablufe der einzelnen Verfahren weitestgehend gleichen. Dies besttigen die in Abschnitt 2.4 vorgestellten Prozesse fr mobile Bezahlverfahren. Diese hnlichkeiten bertragen sich somit auch auf die Anwendbarkeit von Angrien. Technische Unterschiede spielen nur eine untergeordnete Rolle. Die folgenden Abstze fassen die erhaltenen Erkenntnisse zusammen. Mobile Bezahlsysteme unabhngig davon ob sie elektronisch oder mit klassischem Bargeld durchgefhrt werden stellen den Besitz der Werteinheit in den Vordergrund. Bei Bargeld sind die einzelnen Werteinheiten Geldstcke und Scheine. In elektronischen Systemen stellen Smartphones die Werteinheiten dar. Sie weisen den Benutzer aus und stellen die Verbindung zum tatschlichen Geld her. Der Besitz eines Smartphones ist also essentiell fr den Besitz des Geldes. Gegenber Bargeld
Stefan Gfrrer
73

verfgen elektronische Bezahlsysteme ber den Vorteil, dass der eigentliche Betrag nicht direkt mit dem Verlust des Smartphones verloren geht. Um dies zu gewhrleisten muss die Bezahlapp abgesichert sein. Des Weiteren sollte der Zugri auf das Konto vom Dienstanbieter gesperrt werden. Die Mehrheit der vorgestellten Verfahren verhindert Transaktionen durch nicht berechtige Personen nur unzureichend. Dies ist gut an Angri A5 in Abbildung 4.16 zu erkennen. Zuknftige Verfahren sollten aus diesem Grund eine Authentisierung des Benutzers vor der Durchfhrung einer berweisung erzwingen. Hier gengt beispielsweise bereits die Abfrage der PIN. Eine weitere bergreifende Bedrohung stellen Schadprogramme dar. Sie knnen sowohl passiv als auch aktiv kritische Informationen auslesen und manipulieren. Dieser Gefahr begegnend mssen Bezahlsysteme immer davon ausgehen, dass das Smartphone, auf dem sie ausgefhrt werden, nicht sicher ist. Der Entwurf neuer Systeme sollte dies stets beachten. Nur eKaayCash und das theoretische System auf der Basis von Geldkarten bieten eine relative Sicherheit vor Schadprogrammen. Allein die Einfhrung von sicheren Elementen in Form von Secure Elements oder externen Geheimnissen beispielsweise eKaayCard (vgl. Gnther [2011]) kann eektiv vor Schadprogrammen schtzen. NFC hingegen hat sich als sicher erwiesen. Mit Ausnahme von Google wallet bertrgt kein Verfahren mit Hilfe von Nahfunk ungeschtzt kritische Daten. Auch normale Kommunikationsverbindungen beispielsweise die Kommunikation mit dem Server des Dienstanbieters sind allgemein nur schwer angreifbar. Daten, welche ber diese Verbindungen gesendet werden, knnen leicht mit Hilfe von geteilten Geheimnissen abgesichert werden. Im Gegensatz zu Schadprogrammen hat ein Manin-the-Middle keine Mglichkeit, das Geheimnis auszulesen oder mitzuhren, da es im Normalfall nicht mitbertragen wird. Wie bei klassischen Onlineberweisungen bietet das manuelle berprfen der Transaktion einen hohen Schutz und kann in Kombination mit einem externen Geheimnis eine Vielzahl von Angrien unwirksam machen. Entsprechend sollten beide Mechanismen in mobilen Peer-to-Peer Bezahlsystemen eingesetzt werden. Dies deckt sich auch mit anderen Sicherheitsanalysen von mobilen Systemen (vgl. Gnther [2011]).
4.13. Fazit
In Anlehnung an das Fazit aus Abschnitt 3.5 hat die Analyse gezeigt, dass eKaayCash ein sicheres mobiles Bezahlverfahren mit Peer-to-Peer Funktionalitt umsetzt. Das sichere Framework in Form von eKaay hat nicht nur die einfache Entwicklung des Verfahrens ermglicht, sondern auch die Gefahr durch verschiedene Angrie
74
Stefan Gfrrer
Peer-to-Peer Payment via NFC 4.13. Fazit

minimiert. Dabei hat sich gezeigt, dass die Implementierung von eKaay in eine reelle Anwendung zu neuen Sicherheitsproblemen speziell fr diese Anwendung fhren kann. Das Verfahren eKaayCash kann diese Probleme jedoch mit Hilfe von eKaay lsen. Dies betrit insbesondere die Involvierung des Zahlenden in die Besttigung der Transaktion. Es kann also festgestellt werden, dass eKaayCash ein sicheres mobiles Bezahlsystem fr Smartphones ist. Anhand der weiteren Sicherheitsanalyse konnte ebenfalls erfolgreich gezeigt werden, dass mittels konzeptueller Ablufe bereits verschiedene Angrie erkannt werden knnen. Des Weiteren wurde eine groe Zahl an Gemeinsamkeiten in unterschiedlichen Systemen aufgedeckt. Daraus lassen sich allgemeine Empfehlungen fr neue Bezahlverfahren und die Verbesserung bestehender Verfahren ableiten.
Stefan Gfrrer
75
5. Implementierung von eKaayCash

In diesem Kapitel werden einzelne Abschnitte der Implementierung von eKaayCash verdeutlicht. Es wird auf Probleme und ihre Lsungen eingegangen, aber kein vollstndiger Einblick in den Quellcode gegeben. Weitere Implementierungsdetails knnen dem Anhang A entnommen werden.
5.1. Erzeugung einer berweisung

Das Programm, welches das berweisungsformular darstellt und aus den Eingabedaten eine berweisung generiert, ist wie folgt aufgebaut: 1. Zunchst prft es, ob Eingabedaten, wie der Betrag und die ID des Geldempfngers, vorhanden sind. 2. Im dem Fall, dass die ID fehlt, wird das Programm abgebrochen, da eine Transaktion ohne gltigen Empfnger nicht erzeugt werden darf. 3. Sind keine berweisungsdaten vorhanden, wird das Formular angezeigt und das Programm endet. Wurden hingegen Daten fr eine Transaktion eingeben, erstellt das Programm aus diesen Informationen eine neue berweisung. 4. Dazu wird zunchst eine einzigartige Transaktionsnummer als ID generiert. 5. Die berweisungsdaten werden anschlieend fr die Anzeige auf dem Smartphone aufbereitet. 6. Der Server der Bank speichert die berweisung fr die sptere Durchfhrung nach der Besttigung durch die Benutzer. 7. Aus dem fr Menschen lesbaren Transaktionstext erzeugt der eKaay Server eine Challenge inklusive QR Code und gegebenenfalls einen NFC Link. 8. Die Challenge wird im Browser des Benutzers angezeigt und das Programm endet. Der vollstndige Ablauf wurde mit Hilfe von Aktivittsdiagrammen in den Abbildungen 5.1 und 5.2 visualisiert.
Stefan Gfrrer
77
Peer-to-Peer Payment via NFC 5. Implementierung von eKaayCash

[berweisen]
berweisung erzeugen
Eingabe prfen Start [nicht angemeldet]
[angemeldet] Ausgabe
[nicht berweisen]
Fehler
Formular erstellen
Abbildung 5.1.: Aktivittsdiagramm, welches die Generierung einer berweisung zeigt (eigene Darstellung).
ID erzeugen Start Daten aufbereiten
eKaay Ausgabe
berweisung speichern
Abbildung 5.2.: Das Aktivittsdiagramm zeigt die Zwischenschritte von Eingabe der der berweisungsdaten bis zur Anzeige des von eKaay erzeugten QR Codes. Es zeigt den Schritt berweisung erzeugen aus Abbildung 5.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. Dazu muss die App das notwendige benutzerdenierte URL Scheme akzeptieren. Dies wird durch eine Erweiterung der Datei AndroidManifest.xml um den in Listing 5.1 dargestellten Filter erreicht. Es ist wichtig, dass die Applikation als BROWSABLE ausgewiesen wird, da dies den Aufruf durch einen Browser erlaubt (vgl. Google [2012c]). Dies leitet sich aus der Entwurfsentscheidung in Abschnitt 3.3.1 ab, welche besagt, dass das berweisungsformular und die erzeugte Challenge in einem Browser dargestellt werden.
1 2 3 4 5 6
<intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="ekaaycash" /> </intent-filter>
Listing 5.1: Auszug aus der AndroidManifest.xml. Gezeigt wird der Filter fr ein benutzerdeniertes URL Scheme (eigene Darstellung).
78
Stefan Gfrrer
Peer-to-Peer Payment via NFC 5.3. Server/Client Kommunikation
5.3. Server/Client Kommunikation

Im vollstndigen eKaayCash Verfahren mit der Erweiterung fr Online Shops gibt es folgende Entitten. Die Serverkomponente von eKaay. Der Server des Dienstanbieters bzw. der Bank. Das Smartphone des Geldempfngers. Das Smartphone des Zahlenden. Der Server des Online Shops. Der Vereinfachung wegen werden der Geldempfnger und der Zahlende zusammengefasst. Dies ist mglich, da beide hnliche Informationen mit den Servern austauschen. Abbildung 5.3 zeigt alle Kommunikationsverbindungen. Die gerichteten Pfeile geben dabei an, von welcher Entitt die Kommunikation ausgeht. Die Verbindungen werden im Folgenden erlutert. Registrierung/Anmeldung. Dies sind allgemeine Verbindungen von eKaay. Sie entsprechen der von Borchert [2012a] beschriebenen Kommunikation zwischen dem Server von eKaay und dem Benutzerkontenserver. Zur Vereinfachung wurden Registrierung und Anmeldung in Abbildung 5.3 zusammengefasst. Besttigung der berweisung. Nach der Besttigung durch den Zahlenden, leitet eKaay diese an den Server der Bank weiter. Dieser kann die Transaktion abschlieen. Nutzung von eKaay PIN. Wie in Abschnitt 3.3.3 beschrieben, soll eKaay erst ab einem bestimmten Betrag eine PIN abfragen. Der Server von eKaay fragt zu diesem Zweck die Nutzung der PIN bei der Bank an. Challenge/Response/PIN Permutation. Dies sind allgemeine Verbindungen von eKaay, wie sie jeweils von einem Smartphone verwendet werden. Sowohl der Abruf der Challenge, als auch das Senden der Response und der PIN Permutation, gehen von der eKaay App auf dem Smartphone aus. berweisungsformular. Das berweisungsformular wird von Smartphone und Server des Online Shops direkt beim Server der Bank abgerufen. Es kann bereits ausgefllt sein und der Server der Bank antwortet in diesem Fall mit der generierten Transaktion. Zahlungsbesttigung. Nach der Eingang einer Zahlung an einen Shop informiert der Server der Bank den Server des Online Shops.
Stefan Gfrrer
79
Peer-to-Peer Payment via NFC 5. Implementierung von eKaayCash

Verizierung der Besttigung. Der Eingang einer Zahlung kann vom Server des Shops mit Hilfe der in Abschnitt 3.4 beschriebenen Schnittstelle veriziert werden.
Registrierung/Anmeldung Besttigung der berweisung Nutzung von eKaay PIN
eKaay Server
Server der Bank
Challenge/ Response/ PIN Permutation
Verifizierung der Besttigung berweisungsformular
Zahlungsbesttigung
berweisungformular
Smartphone Client
Server des Shops
Abbildung 5.3.: Kommunikation der verschiedenen Komponenten im eKaayCash Verfahren (eigene Darstellung).
80
Stefan Gfrrer
6. Schluss
6.1. Zusammenfassung
Das Ziel der Arbeit war die Entwicklung eines sicheren, mobilen Bezahlsystems mit Peer-to-Peer Funktionalitt unter Verwendung von eKaay und NFC. Des Weiteren sollte das Verfahren auf seine Sicherheit hin untersucht werden. Diese Analyse sollte auch auf eine Reihe weiterer mobiler Bezahlsysteme angewandt und die Ergebnisse schlielich miteinander verglichen werden. Zunchst wurden eine Reihe von Bedingungen fr das mobile Bezahlsystem festgelegt, in deren Rahmen das Verfahren umgesetzt werden sollte. Im folgenden Entwurf des Verfahrens konnten die Bedingungen fast vollstndig eingehalten werden. Lediglich fr die Einbindung der P2P Kommunikation via NFC musste die bestehende eKaay App erweitert werden. Das Verfahren lie sich wegen der Grundarchitektur eKaay leicht nachvollziehbar umsetzen und bildet trotzdem eine von eKaay getrennt entwickelte Applikation. Gleichzeitig demonstriert es die Anwendung von eKaay TAN. In Anlehnung an die bereits im Einsatz bendliche Praxis der Banken wurde zudem das eKaay PIN Verfahren fr den bergang von Kleinstbetrgen zu greren Summen eingebunden. In einem zweiten Schritt wurde das vorgestellte Verfahren eKaayCash weiterentwickelt und fr den Einsatz in Online Shop Systeme erweitert. Dies ermglicht die einfache Einbindung des mobilen Bezahlsystems in eine bestehende Verkaufsplattform. Es konnte gezeigt werden, dass sowohl fr den Kunden als auch fr den Hndler eine einfachere Bedienung des Shops mglich ist. Die Sicherheit fr den Hndler wird durch einen einfachen Besttigungsprozess gewhrleistet. Ein Austausch gegen ein beliebiges anderes Besttigungsverfahren ist vorgesehen und mglich. Zur berprfung der Sicherheit beider Systeme wurden zunchst mgliche Angrispunkte in Bezahlsystemen mit besonderem Hinblick auf die mobile Plattform identiziert. Sie wurden ausfhrlich erlutert und auf mgliche Folgen im nanziellen Umfeld geprft. Anschlieend konnten eKaayCash und die Erweiterung fr Online Shop Systeme auf ihre Sicherheit hin analysiert werden. Dabei konnte gezeigt werden, dass beide Systeme sicher sind und das Restrisiko vom Verhalten des Benutzers abhngig ist.
Stefan Gfrrer
81
Peer-to-Peer Payment via NFC 6. Schluss

Aufbauend auf die Untersuchung von eKaayCash wurden im Anschluss weitere mobile Bezahlverfahren ausgewhlt, vorgestellt und untersucht. Die Einzelergebnisse ergaben einen berblick ber verschiedene gemeinsame Probleme in elektronischen Geldsystemen in mobilen Umgebungen. Diese Probleme konnten in einer abschlieenden Diskussion aufgezeigt werden. Dabei wurden Vorschlge fr ihre Lsungen oder zumindest fr die Minimierung des Risikos gemacht. Sie basieren auf den Erfahrungen aus dem Entwurf von eKaayCash und der Analyse aller Verfahren. Im Verlauf der Analyse wurde als Gegenbeispiel zu den Konto basierten Verfahren ein E-Wallet Verfahren als Weiterentwicklung des deutschen Geldkarten Systems fr Smartphones entwickelt. Es besteht aus einem einfachen Verfahren, welches die direkte berweisung von Betrgen zwischen zwei mit Secure Element ausgestatteten Smartphones erlaubt. Es weist eine mit eKaayCash vergleichbar hohe Sicherheit auf. Zum Abschluss dieser Arbeit wurden einzelne Punkte in der Implementierung von eKaayCash vorgestellt. Sie haben besondere Aspekte in der reellen Umsetzung des Verfahrens aufgezeigt und erlutert. Um eine unntige Beschreibung eines austauschbaren Quellcodes zu vermeiden, wurde die Implementierung auf einer abstrakten Ebene erlutert. Das Ergebnis dieser Arbeit ist ein funktionierendes mobiles Bezahlsystem, welches eine P2P Kommunikation mittels NFC ermglicht. Es ist innerhalb einer simulierten Bankumgebung voll funktionsfhig. Des Weiteren wurde ein lauhiges Beispiel fr eine Erweiterung fr Online Shops vorgestellt. Diese Erweiterung demonstriert auch die hohe Flexibilitt des Bezahlsystems, welches sich leicht anpassen lie. Die Sicherheit von eKaayCash wurde in einer ausfhrlichen Analyse demonstriert und mit anderen existierenden und theoretischen Verfahren verglichen. Zusammen mit dem Entwurf des Geldkarten Systems fr Smartphones bieten die Analyse und das eKaayCash Verfahren eine Reihe von Hinweisen fr die Entwicklung weiterer, sicherer Bezahlsysteme fr das mobile Umfeld.
6.2. Ausblick
Unabhngig von den erzielten Ergebnissen ergeben sich durch diese Arbeit neue Anstze fr weitere Untersuchungen. Erweiterte Analyse. Die Analyse in dieser Arbeit hat die Auswirkung einzelner Angrie untersucht. Eine Kombination von verschiedenen Angrien und die Auswirkung des Restrisikos wurde jedoch nicht beachtet. Fr eine Anwendung,
82
Stefan Gfrrer
Peer-to-Peer Payment via NFC 6.2. Ausblick

welche die berweisung von Geldbetrgen ermglicht, sollte dies jedoch untersucht werden. Dabei ist besonders in Hinblick auf eKaayCash die Angreifbarkeit des Benutzers von Bedeutung, da ein wichtiger Teil der Sicherheit von dessen Aufmerksamkeit abhngig ist. Secure Elements in eKaay. Verschiedene Verfahren in dieser Arbeit haben Secure Elements auf Smartphones als eine Form von sicherer Umgebung eingesetzt. Ein hnlicher Ansatz wurde mit dem eKaayCard Verfahren von Gnther [2011] in Form einer externen Karte verfolgt. Zwar bietet eine Karte ein hohes Ma an Sicherheit durch den Faktor Besitz, allerdings verringert sie die Benutzerfreundlichkeit. Ein Geheimnis, welches in einem sicheren Bereich des Smartphones gespeichert ist, knnte sowohl einen hohen Sicherheitsfaktor stellen, als auch die Benutzerfreundlichkeit von eKaay ohne externe Karte beibehalten. Abschlieend lsst sich festhalten, dass die gesetzten Ziele erreicht wurden und die Zielsetzung zum Teil beispielsweise mit dem Entwurf eines Geldkarten Systems fr Smartphones ausgeweitet wurde. Anhand der Analyse lieen sich weitere Ziele fr zuknftige Arbeiten in diesem Themengebiet nden.
Stefan Gfrrer
83
Literaturverzeichnis
Agarwal u. a. 2007 Agarwal, Shivani ; Khapra, Mitesh ; Menezes, Bernard ; Uchat, Nirav: Security Issues in Mobile Payment Systems. 2007 Armstrong 2012 Armstrong, Brian: Homepage Bitcoin Android. Online. https://github. com/barmstrong/bitcoin-android. Version: Feb 2012 Baden-Wrttembergische Bank 2006 Baden-Wrttembergische Bank: TAN-Generator der BW-Bank zertiziert - Erfolg fr sicheres Onlinebanking. Online. http://www.bw-bank.de/ bwbankde/1000005999-s1463-de.html. Version: Dec 2006 Bitcoin Project 2012 Bitcoin Project: Version: Feb 2012 Bitcoin.it Wiki 2012 Bitcoin.it Wiki: Bitcoin.it Wiki. Online. https://en.bitcoin.it/wiki/ Main_Page. Version: Feb 2012 Borchert 2012a Borchert, Bernd: Version: Feb 2012 Borchert 2012b Borchert, Bernd: Version: Mar 2012 Bray 2010 Bray, Tim: Android Browser User-Agent Issues. Online. http://androiddevelopers.blogspot.com/2010/12/android-browser-user-agentissues.html. Version: Dec 2010 Chambers 2011 Chambers, Laura: PayPal Uses NFC to Make Peer-to-Peer Payments Easier than Ever. Online. https://www.thepaypalblog.com/2011/07/paypal-usesOnline Banking Verfahren. Online. http://www-fs. informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml. Homepage eKaay. Online. http://www.ekaay.com/. Homepage Bitcoin. Online. http://bitcoin.org/.
Stefan Gfrrer
85
Peer-to-Peer Payment via NFC Literaturverzeichnis

nfc-to-make-peer-to-peer-payments-easier-than-ever/. 2011 Cheng u. a. 2011 Cheng, Hsu-Chen ; Liao, Wen-Wei ; Chi, Tian-Yow ; Wei, Siao-Yun: A secure and practical key management mechanism for NFC read-write mode. In: Advanced Communication Technology (ICACT), 2011 13th International Conference on 13 (2011), Feb, S. 1095 1011 Choi u. a. 2007 Choi, Seung H. ; Collins, David ; Ure, John ; Lovelock, Peter: Mobile payments in Asia Pacic / KPMG. 2007. Report Deutsche Kreditwirtschaft 2011 Deutsche Kreditwirtschaft: Schnittstellenspezikation fr die ec-Karte mit Chip Version 2.2. 2011 Deutsche Kreditwirtschaft 2012 Deutsche Kreditwirtschaft: Hndlerinfo: girogo.de. Online. http:// girogo.de/4-0-Haendlerinfo.html. Version: Mar 2012 EMVCo 2008 EMVCo: EMV Integrated Circuit Card Specications for Payment Systems Book 2 - Security and Key Management. Jun 2008 Eriksson u. Johansson 2007 Eriksson, Mattias ; Johansson, Tutor T.: An Example of a Man-in-the-middle Attack Against Server Authenticated SSL-sessions. Jan 2007 Fenner 1992 Fenner, P.R.: Mobile address management and billing for personal communications. In: Universal Personal Communications, 1992. ICUPC 92 Proceedings., 1st International Conference on, 1992, 09.06/1 - 09.06/5 Gao u. a. 2006 Gao, Jerry ; Cai, Jacky ; Patel, Kiran ; Shim, Simon: A Wireless Payment System / San Jose State University, Computer Engineering. 2006. Forschungsbericht Gao u. a. 2009 Gao, Jerry ; Kulkarni, Vijay ; Ranavat, Himanshu ; Chang, Lee ; Mei, Hsing: A 2D Barcode-Based Mobile Payment System. In: MUE, IEEE Computer Society, 2009. ISBN 9780769536583, 320-329 Version: Jul
86
Stefan Gfrrer

Gnther 2011 Gnther, Max: Sicheres Online Banking via Smartphone mit Nahfunk (NFC) , Uni Tbingen, Diplom, Sep 2011 Google 2011 Google: Homepage Google Wallet. Online. http://www.google.com/wallet/. Version: 2011 Google 2012a Google: Android 2.3 Platform Highlights. Online. http://developer. android.com/sdk/android-2.3-highlights.html. Version: Jan 2012 Google 2012b Google: Android 4.0 Platform Highlights. Online. http://developer. android.com/sdk/android-4.0-highlights.html. Version: Jan 2012 Google 2012c Google: Android Developers References. Online. http://developer. android.com/reference/packages.html. Version: Jan 2012 Google 2012d Google: Android Security. Online. http://source.android.com/tech/ security/index.html. Version: Jan 2012 Grossman u. a. 2007 Grossman, J. ; Fogie, S. ; Hansen, R.: XSS attacks: cross-site scripting exploits and defense. Syngress, 2007 (Syngress Media). ISBN 9781597491549 Gupta u. a. 2005 Gupta, K.N. ; Agarwala, K.N. ; Agarwala, P.A.: Digital Signature: Network Security Practices. 9788120325999 Hardawar 2011 Hardawar, Devindra: PayPal brings NFC money transfers to Android, starting with Nexus S. Online. http://venturebeat.com/2011/07/13/paypalandroid-nfc/. Version: Jul 2011 Haselsteiner u. Breitfu 2006 Haselsteiner, Ernst ; Breitfu, Klemens: Security in Near Field Communication ( NFC ) Strengths and Weaknesses. In: Semiconductors 11 (2006), S. 71 Hearn u. a. 2012 Hearn, Mike ; Cuperman, Miron ; Guo, Xiaofeng ; Planz, Thilo ; Swiggs, Micheal ; Rowe, Gary ; Resare, Noa ; Sample, John ; Mller, Jan ; Nagele, Prentice-Hall Of India Pvt. Ltd., 2005. ISBN
Stefan Gfrrer
87

Wolfgang ; Heggheim, Jonny ; Coughlan, Steve ; Mandeleil, Roman ; Rico, Chris ; Rotaru, Vasile: Homepage bitcoinj. Online. http://code.google.com/ p/bitcoinj/. Version: Feb 2012 ISO 2000a Norm ISO/IEC 14443 2000. Identication cards - Contactless integrated circuit(s) cards - Proximity cards ISO 2000b Norm ISO/IEC 18004 2000. Quick Response Code ISO 2004 Norm ISO/IEC 18000-3 2004. ISO/IEC 18000-3 Jakobsson u. Myers 2006 Jakobsson, M. ; Myers, S.: Phishing and Countermeasures: Understanding the Increasing Problem of Electronic Identity Theft. John Wiley & Sons, 2006. ISBN 9780471782452 JVL Ventures, LLC 2012 JVL Ventures, LLC: Homepage ISIS. Online. http://www.paywithisis. com/home.xhtml. Version: Mar 2012 Kadhiwal u. Zulquar 2007 Kadhiwal, Saleem ; Zulfiquar, Anwar Usman S.: Analysis of mobile payment security measures and dierent standards. In: Computer Fraud Security 6 (2007), Jun, Nr. 6, S. 1216 Karnouskos 2004 Karnouskos, Stamatis: Mobile payment: A journey through existing procedures and standardization initiatives. In: IEEE Communications Surveys and Tutorials 6 (2004), Nr. 1-4, S. 4466 Kaspersky Lab 2010 Kaspersky Lab: First SMS Trojan detected for smartphones running Android. Online. http://www.kaspersky.com/news?id=207576158. Version: Aug 2010 Kincaid 2011 Kincaid, Jason: Special Stickers Will Bring Google Wallet To Android Phones That Lack NFC. Online. http://techcrunch.com/2011/05/26/specialstickers-will-bring-google-wallet-to-android-phones-that-lacknfc/. Version: May 2011
88
Stefan Gfrrer

Kortvedt u. Mjlsnes 2009 Kortvedt, Henning S. ; Mjlsnes, Stig F.: Eavesdropping Near Field Communication. In: The Norwegian Information Security Conference (NISK) 2009, 2009, 57-68 Lee u. a. 1994 Lee, Berners T. ; Masinter, L. ; Mccahill, M.: Version: Aug 1994 Li u. a. 2008 Li, Qi ; Zhang, Xinwen ; Seifert, Jean-Pierre ; Zhong, Hulin: Secure Mobile Payment via Trusted Computing. In: Proceedings of the 2008 Third Asia-Pacic Trusted Infrastructure Technologies Conference. Washington, DC, USA : IEEE Computer Society, 2008. ISBN 9780769533636, 98112 Mahlmann u. Schindelhauer 2007 Mahlmann, P. ; Schindelhauer, C.: Peer-To-Peer-Netzwerke: Algorithmen Und Methoden. Springer, 2007 (EXamen. press Series). ISBN 9783540339915 Massoth u. Bingel 2009 Massoth, Michael ; Bingel, Thomas: Performance of Dierent Mobile Payment Service Concepts Compared with a NFC-Based Solution. In: Proceedings of the 2009 Fourth International Conference on Internet and Web Applications and Services. Washington, DC, USA : IEEE Computer Society, 2009. ISBN 9780769536132, 205210 MasterCard 2012 MasterCard: Version: 2012 Meyer u. Wetze 2004 Meyer, Ulrike ; Wetze, Susanne: On the impact of GSM Encryption and Manin-the-Middle Attacks on the Security of Interoperating GSM/UMTS Networks. In: Proceedings of IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC2004), September 2004, IEEE, 2004. http://www.cdc.informatik.tu-darmstadt.de/ umeyer/UliPIMRC04.pdf, 2004 Mobey Forum Mobile Financial Services Ltd 2010 Mobey Forum Mobile Financial Services Ltd: Alternatives for Banks to oer Secure Mobile Payments. http://www.mobeyforum.org/PressDocuments/Press-Releases/Alternatives-for-Banks-to-offer-SecureMobile-Payments. Version: Mar 2010. Online Homepage MasterCard PayPass. Online. http://www. mastercard.com/de/privatkunden/products/products_paypass.html. RFC 1738: Uniform Resource Locator (URL). Online. http://www.ietf.org/rfc/rfc1738.txt.
Stefan Gfrrer
89

Mun u. a. 2009 Mun, Hyeran ; Han, Kyusuk ; Kim, Kwangjo: 3G-WLAN interworking: security analysis 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 (WTS09). ISBN 9781424425884, 309316 Mutchukota u. a. 2011 Mutchukota, Thrinatha R. ; Panigrahy, Saroj K. ; Jena, Sanjay K.: Man-inthe-Middle Attack and its Countermeasure in Bluetooth Secure Simple Pairing. May 2011. Department of Computer Science & Engineering, National Institute of Technology Rourkela Nakamoto 2009 Nakamoto, Satoshi: Bitcoin: A Peer-to-Peer Electronic Cash System. May 2009. bitcoin.org NFC Forum 2012 NFC Forum: Homepage NFC Forum. Online. http://www.nfc-forum.org/ home/. Version: Feb 2012 Ondrus u. Pigneur 2007 Ondrus, Jan ; Pigneur, Yves: An Assessment of NFC for Future Mobile Payment Systems. In: ICMB07, 2007 Pasquet u. a. 2008 Pasquet, Marc ; Reynaud, Joan ; Rosenberger, Christophe: Secure payment with NFC mobile phone in the SmartTouch project. IEEE, 2008. 121126 S. Patel 2011 Patel, Kunur: Survey: Consumers Dont Trust Google or Apple With Mobile Payments. Online. http://adage.com/article/digital/consumers-trustgoogle-apple-mobile-payments/229163/. Version: Aug 2011 PayPal 2011a PayPal: PayPal Mobile - Peer-to-Peer NFC Solutions. Online. http://youtu. be/ovxA35hQ058. Version: Jul 2011 PayPal 2012a PayPal: Homepage PayPal. Online. https://www.paypal.com/. Version: Mar 2012 PayPal 2012b PayPal: PayPal Mobile. Online. https://personal.paypal.com/us/cgi-
90
Stefan Gfrrer

bin/?cmd=_render-content&content_ID=marketing_us/mobile_payments. Version: Jan 2012 PayPal 2012c PayPal: Sofortige Zahlungsbesttigung (IPN). Online. https: //www.paypalobjects.com/de_DE/html/IntegrationCenter/ic_ipn.html. Version: Mar 2012 PayPal 2011b PayPal, Schweden: Betala Med Mobilen I Kassan! Online. https://www. paypal-sverige.se/swe/december/julkampanj.html. Version: Dec 2011 Pehl 2004 Pehl, E.: Mobilfunk: Stand der Technik und Zukunftsperspektiven : Vortrge der 9. ITG-Fachtagung vom 16. bis 17. Juni 2004 in Osnabrck. VDE, 2004 (ITG-Fachberichte). ISBN 9783800728398 Rao 2011 Rao, Leena: ne. PayPal Tests In-Store NFC Payments App With SweOnlidish Retailers, Similar Mobile Experiments To Roll Out Soon.
http://techcrunch.com/2011/12/20/paypal-tests-in-store-nfc-
payments-app-with-swedish-retailers-similar-mobile-experimentsto-roll-out-soon/. Version: Dec 2011 Reid u. Harrigan 2011 Reid, Fergal ; Harrigan, Martin: An Analysis of Anonymity in the Bitcoin System. In: SocialCom/PASSAT, IEEE, 2011. ISBN 9781457719318, 1318-1326 Rubin 2012 Rubin, Joshua: Online. Google Wallet Security: PIN Exposure Vulnerability. https://zvelo.com/blog/entry/google-wallet-security-pin-
exposure-vulnerability. Version: Feb 2012 Samuel 2011 Samuel, Shimone: New in the Android Market: Updated PayPal Mobile App Featuring P2P NFC Capabilities. Online. https://www.thepaypalblog. com/2011/11/new-in-the-android-market-updated-paypal-mobile-appfeaturing-p2p-nfc-capabilities-2/. Version: Nov 2011 Schildbach 2012 Schildbach, Andreas: Homepage Bitcoin Wallet. Online. http://code. google.com/p/bitcoin-wallet/. Version: Feb 2012
Stefan Gfrrer
91

Shinder 2011 Shinder, Debra L.: ne. Smartphone technology of the future. Onlihttp://www.techrepublic.com/blog/smartphones/smartphone-
technology-of-the-future/3735. Version: Oct 2011 Son u. Shmatikov Son, Sooel ; Shmatikov, Vitaly: The Hitchhikers Guide to DNS Cache Poisoning Suchy 2007 Suchy, T.: Bluetoothbasiertes Informationssystem- Konzeption und Realisation eines Prototypen fr einen Stadtinformationsdienst. GRIN Verlag GmbH, 2007. ISBN 9783638833141 Unrath 2012 Unrath, Dieter N.: Verbraucher misstrauen Zahlung per Funk. Online. http: //www.pressetext.com/main#news/20120302004. Version: Mar 2012 Van Damme u. a. 2005 Van Damme, Gauthier ; Wouters, Karel ; Preneel, Bart: Practical Experiences with NFC Security on mobile Phones. In: Workshop on RFID Security RFIDSec09 5 (2005), S. 113 Viaforensics 2011 Viaforensics: line. Forensic security analysis of Google Wallet. Onhttp://viaforensics.com/mobile-security/forensics-security-
analysis-google-wallet.html. Version: Dec 2011 VISA 2012 VISA: Homepage VISA payWave. Online. http://www.visaeurope.com/en/ cardholders/visa_paywave.aspx. Version: 2012 ZDV Tbingen 2012 ZDV Tbingen: Login Webmail Universitt Tbingen. Online. GrundlageneKaay-1. Version: Mar 2012 Zhang u. a. 2010 Zhang, Lizhuo ; Jia, Weijia ; Wen, Sheng ; Yao, Di: A Man-in-the-Middle Attack on 3G-WLAN Interworking. In: Proceedings of the 2010 International Conference on Communications and Mobile Computing - Volume 01. Washington, DC, USA : IEEE Computer Society, 2010 (CMC 10). ISBN 97807695 39898, 121125 ZKA 2009 ZKA: Richtlinien fr einheitliche Zahlungsverkehrsvordrucke. 2009
92
Stefan Gfrrer
A. Anhang
Stefan Gfrrer
Peer-to-Peer Payment via NFC A. Anhang
ii
Stefan Gfrrer
Bank-Modul eKaay Token Prft, ob PIN Eingabe bentigt wird Besttigt Transaktion eKaay PIN Besttigt Login Weiterleitung eKaay TAN Fordert Challenge fr Registrierung von eKaay an Login Fordert Challenge fr TAN an Fordert Challenge fr TAN an Konto-Einstellungen Besttigt Transaktion berweisungsformular Shop-Modul Shopseite Fordert berweisung fr Produkt an eKaayCash Formular Fordert Challenge fr Login an Proxy Prft, ob Registrierungstoken abgelaufen ist eKaay
Stefan Gfrrer
eKaay-Modul Transaktionsbesttigung Transaktionsbesttigung Fragt Korrektheit der Transaktion ab
Hauptseite
Logout
im eKaayCash System (eigene Darstellung).
Der Anwender ruft Webseiten auf und fhrt einzelne Aktionen aus.
Registrierung
Abbildung A.1.: Die unterschiedlichen Module mit den dazugehrenden Webseiten
Konten- und Transaktionsbersicht
iii
iv
3. Durch abfotografieren oder ber eine NFC Verbindung wird die Challenge an den Zahlenden weitergeleitet. Bob (Zahlender) 4. Der Zahlende kann die Transaktion ber unten stehendes Dialog prfen und besttigen.
eKaay
A. Anhang
Alice (Geldempfnger)
Bitte besttigen
Datum: 20.4.2012 Uhrzeit: 10:00:00 Empfaenger: Alice Betrag: 100.00 Euro
Cash (eigene Darstellung).

2. Der Server antwortet mit der Challenge in Form des QR Codes und des NFC Links. Die Challenge enthlt eine Nonce und die Transaktionsdaten als Text. 5. Nach Besttigung der Transaktion erzeugt die eKaay App eine Response zu der Challenge und bertrgt diese an den Server. abbrechen 6. Der Server prft die Response und fhrt die Transaktion bei Korrektheit aus. Server der Bank 7. Mit Abschluss der Transaktion erhalten der Geldempfnger und der Zahlende eine Besttigung.
OK
1. Der Geldempfnger fllt das berweisungsformular aus und betrgt den Betrag und den Verwendungszweck an den Server.
Abbildung A.2.: Der vollstndige Ablauf einer Peer-to-Peer Transaktion mit eKaay-
Stefan Gfrrer
Smartphone des Kunden 5. Durch abfotografieren liest der Kunde die Challenge in sein Smartphone ein. Dies ist gleichbedeutend mit dem Kauf der Ware. 6. Der Kunde kann die Transaktion ber unten stehendes Dialog prfen und besttigen.
eKaay
Kunde
Stefan Gfrrer
Bitte besttigen
Datum: 20.4.2012 Uhrzeit: 10:00:00 Empfaenger: Shop Betrag: 1.00 Euro Verwendungszweck: 1kg pfel
abbrechen
OK
2. Der Server des Shops liefert Webseite mit eingebetteter berweisung aus. 3. Der Browser des Kunden ruft die Challenge fr die berweisung ab.
weiterung fr eKaayCash (eigene Darstellung).

4. Der Server der Bank antwortet mit der Challenge in Form des QR. Die Challenge enthlt eine Nonce und die Transaktionsdaten als Text. 8. Der Server der Bank informiert den Server des Shops ber die abgeschlossene berweisung. Die Besttigung enthlt alle berweisungsdaten. 9. Der Server des Shops stellt eine Anfrage an den Server der Bank mit den erhaltenen berweisungsdaten. 10. Der Server der Bank prft die berweisungsdaten und besttigt die Korrektheit. Server der Bank
1. Der Kunde ruft den Shop auf.
7. Nach Besttigung der Transaktion erzeugt die eKaay App eine Response zu der Challenge und bertrgt diese an den Server der Bank.
Server des Shops
Abbildung A.3.: Der vollstndige Ablauf eines Einkaufs in einem Shop mit der Er-

Diplomarbeit

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit

Hochgeladen von

Copyright:

Verfügbare Formate

Eberhard-Karls-Universitt Tbingen Fakultt fr Informations- und Kognitionswissenschaften Wilhelm-Schickard-Institut fr Informatik Arbeitsbereich fr Theoretische Informatik / Formale Sprachen

Peer-to-Peer Payment via NFC

Stefan Gfrrer 20. April 2012

Betreuer: Dr. Bernd Borchert Prof. Dr. Klaus Reinhardt

Peer-to-Peer Payment via NFC

Peer-to-Peer Payment via NFC

Peer-to-Peer Payment via NFC Inhaltsverzeichnis

Peer-to-Peer Payment via NFC Inhaltsverzeichnis

Peer-to-Peer Payment via NFC Inhaltsverzeichnis

Peer-to-Peer Payment via NFC Abkrzungsverzeichnis

Peer-to-Peer Payment via NFC Abkrzungsverzeichnis

Peer-to-Peer Payment via NFC Abbildungsverzeichnis

Peer-to-Peer Payment via NFC Abbildungsverzeichnis

Peer-to-Peer Payment via NFC Abbildungsverzeichnis

Peer-to-Peer Payment via NFC Tabellenverzeichnis

Peer-to-Peer Payment via NFC

Verzeichnis der Listings

Peer-to-Peer Payment via NFC

Peer-to-Peer Payment via NFC 1. Einleitung

1.2. Ziel der Arbeit

1.3. Verwandte Arbeiten

1.4. Voraussetzungen zum Verstndnis der Arbeit

1.5. Aufbau der Arbeit

Peer-to-Peer Payment via NFC

2. Grundlagen und Hintergrnde

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

Peer-to-Peer Payment via NFC 2.1. eKaay

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

3. Validierung und 2D Code Generierung

8. Response 9. Validierung und Ausfhrung der berweisung Smartphone des Kunden

Server mit eKaay

Peer-to-Peer Payment via NFC 2.2. Near Field Communication (NFC)

2.2. Near Field Communication (NFC)

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

Peer-to-Peer Payment via NFC 2.3. Android

Modifizierte Miller-Kodierung, 100% ASK

Manchester-Kodierung, 10% ASK

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

2.4. Mobile Payment (MP)

Peer-to-Peer Payment via NFC 2.4. Mobile Payment (MP)

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

Peer-to-Peer Payment via NFC 2.4. Mobile Payment (MP)

1a. Zahlungsanfrage Zahlender Geldempfnger

4. Abschluss der Transaktion Zahlungsserver

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergrnde

1. Zahlungsanfrage Geldempfnger Zahlender

3. Abschluss der Transaktion Zahlungsserver

Peer-to-Peer Payment via NFC

3. Peer-to-Peer Payment mit eKaay

3.1. Formulierung der Ziele

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay

3.2. Entwurf einer Testumgebung

Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash

3.3. Entwurf von eKaayCash

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay

Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash

6. Abschluss der Transaktion

Server der Bank

3.3.2. Peer-to-Peer Kommunikation

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay

Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay

3.3.3. Verbesserung der Sicherheit

Peer-to-Peer Payment via NFC 3.4. Erweiterung fr Online Shop Systeme