Eberhard-Karls-Universität Tübingen Fakultät für Informations- und Kognitionswissenschaften Wilhelm-Schickard-Institut für Informatik Arbeitsbereich

für Theoretische Informatik / Formale Sprachen

Peer-to-Peer Payment via NFC
Diplomarbeit
im Fachgebiet Informatik

Stefan Gfrörer 20. April 2012

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

Peer-to-Peer Payment via NFC

Zusammenfassung
Die vorliegende Arbeit erforscht die Umsetzung eines mobilen Bezahlsystems mittels dem eKaay Verfahren. Es soll direkte Transaktionen zwischen zwei Benutzern von Smartphones ermöglichen 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 für Online Shop Systeme zu entwickeln. Die Analyse ergab eine Reihe von ähnlichen Problemen und Lösungsansätzen in verschiedenen mobilen Peer-to-Peer Bezahlsystemen. Aus diesen Gemeinsamkeiten konnten verschiedene Empfehlungen für die Entwicklung weiterer Verfahren abgeleitet werden.

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

Eidesstattliche Erklärung
Ich, Stefan Gfrörer, versichere hiermit, dass ich meine Diplomarbeit mit dem Thema Peer-to-Peer Payment via NFC selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, wobei ich alle wörtlichen und sinngemäßen Zitate als solche gekennzeichnet habe. Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht. Tübingen, den 20. April 2012

Stefan Gfrörer

© Stefan Gfrörer

Peer-to-Peer Payment via NFC Inhaltsverzeichnis

Inhaltsverzeichnis
Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Listings 1. Einleitung 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Voraussetzungen zum Verständnis der Arbeit . . . . . . . . . . . . . 1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Grundlagen und Hintergründe 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 für 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

I

© Stefan Gfrörer

Peer-to-Peer Payment via NFC Inhaltsverzeichnis
4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen . . . . . . . . 4.3. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.1. eKaayCash . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.2. Erweiterung für 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 Gfrörer

II

Peer-to-Peer Payment via NFC Inhaltsverzeichnis
4.9.4. Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 4.9.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10. Weitere Mobile Payment Lösungen . . . . . . . . . . . . . . . . . . . 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 Gfrörer

Peer-to-Peer Payment via NFC Abkürzungsverzeichnis

Abkürzungsverzeichnis
AES . . . . . . . . . . . . . . . Advanced Encryption Standard API . . . . . . . . . . . . . . . . Application Programming Interface (engl. für Programmierschnittstelle) ASK . . . . . . . . . . . . . . . Amplitude Shift Keying C2C . . . . . . . . . . . . . . . . Consumer-to-Consumer CNP . . . . . . . . . . . . . . . Card not present transaction ECC . . . . . . . . . . . . . . . Elliptic Curve Cryptography (engl. für 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 . . . . . . . . . . . . . . . . . Identification (engl. für Identifikator oder Kennung) IMEI . . . . . . . . . . . . . . . International Mobile Equipment Identity LTE . . . . . . . . . . . . . . . . Long Term Evolution MITM . . . . . . . . . . . . . Man-in-the-middle attack (engl. für Man-in-the-middle-Angriff) MP . . . . . . . . . . . . . . . . Mobile Payment NDEF . . . . . . . . . . . . . NFC Data Exchange Format NFC . . . . . . . . . . . . . . . Near Field Communication (engl. für Nahfeld-Kommunikation) P2P . . . . . . . . . . . . . . . . Peer-to-Peer oder Person-to-Person PIN . . . . . . . . . . . . . . . . Personal Identification Number (engl. für Persönliche Identifikationsnummer) POS . . . . . . . . . . . . . . . Point of Sale QR Code . . . . . . . . . . . Quick Response Code RFID . . . . . . . . . . . . . . Radio-Frequency Identification SDP . . . . . . . . . . . . . . . Service Discovery Protocol SE . . . . . . . . . . . . . . . . . Secure Element SMS . . . . . . . . . . . . . . . Short Message Service (engl. für Kurznachrichtendienst) SSL . . . . . . . . . . . . . . . . Secure Sockets Layer

V

© Stefan Gfrörer

Peer-to-Peer Payment via NFC Abkürzungsverzeichnis
TAN . . . . . . . . . . . . . . . Transaction Authentication Number (engl. für Transaktionsnummer) TLS . . . . . . . . . . . . . . . . Transport Layer Security UMTS . . . . . . . . . . . . . Universal Mobile Telecommunications System URL . . . . . . . . . . . . . . . Uniform Resource Locators WLAN . . . . . . . . . . . . . Wireless Local Area Network (engl. für drahtloses lokales Netzwerk) WOT . . . . . . . . . . . . . . Web of Trust (engl. für Netz des Vertrauens)

© Stefan Gfrörer

VI

Peer-to-Peer Payment via NFC Abbildungsverzeichnis

Abbildungsverzeichnis

2.1. Verwendung von eKaay als alternatives Loginverfahren im Webmail Angebot der Universität Tübingen (Quelle: ZDV Tübingen [2012]). . 2.2. Das eKaay TAN Verfahren im Detail. Das Versenden der Bestätigung ist nicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . 2.3. Das eKaay PIN Verfahren aus Sicht des Benutzers. Links ist ein Handy mit permutiertem Ziffernfeld und rechts das Formular im Browser mit QR Code und Zifferneingabefeld 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 Geldempfänger (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Formular für eine mobile Überweisung. Geldempfänger und Zahlender werden automatisch erfasst (eigene Darstellung). . . . . . . . . . . . 3.2. Ablauf einer Transaktion mittels eKaayCash. Bestätigungen nach erfolgreicher Durchführung an beide Parteien sind der Übersicht wegen nicht enthalten (eigene Darstellung). . . . . . . . . . . . . . . . . . . 3.3. Beispiel für einen Artikel mit der dazugehörenden 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 Angriff auf eine Server-Client Verbindung. Der Angreifer Mallory kann den Kommunikationsfluss zwischen Alice und Bob vollständig kontrollieren (eigene Darstellung). . 4.2. Der Angreifer Eve hat zwar keinen direkten Einfluss 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 Gfrörer

Peer-to-Peer Payment via NFC Abbildungsverzeichnis
4.3. Der Angreifer Mallory manipuliert eine Überweisung, welche außer einer vom Inhalt unabhängigen TAN keinen weiteren Schutz aufweist (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Der Bestätigungsdialog von eKaay für eine Transaktion (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Versuch eines Angreifers einem Shop eine Transaktion vorzutäuschen (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 Bestätigung wurde aus Gründen der Übersicht entfernt (eigene Darstellung). 45 4.8. Bezahlung an einem NFC-fähigen Terminal mit PayPal Mobile Payments (Quelle: PayPal [2011b]). . . . . . . . . . . . . . . . . . . . . . 4.9. Gemäß A2 kann ein Schadprogramm auf dem Smartphone des Geldempfängers 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. Grafische 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 Bestätigungen an Kunden und Händler (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14. Ablauf einer P2P Überweisung mit Hilfe von Bluetooth. Die Bestätigung 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. Aktivitätsdiagramm, welches die Generierung einer Überweisung zeigt (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 73 70

© Stefan Gfrörer

VIII

Peer-to-Peer Payment via NFC Abbildungsverzeichnis
5.2. Das Aktivitätsdiagramm 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 dazugehörenden Webseiten im eKaayCash System (eigene Darstellung). . . . . . . . . . . . . . . . . A.2. Der vollständige Ablauf einer Peer-to-Peer Transaktion mit eKaayCash (eigene Darstellung). . . . . . . . . . . . . . . . . . . . . . . . . A.3. Der vollständige Ablauf eines Einkaufs in einem Shop mit der Erweiterung für eKaayCash (eigene Darstellung). . . . . . . . . . . . . . . v iv iii 80 78

IX

© Stefan Gfrörer

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 Angriffsmethoden auf mobile Bezahlsysteme (eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Der Sicherheitsheader für Nachrichten im Verfahren mit Bluetooth. Er wird an die eigentlichen Nutzdaten angehängt (vgl. Gao u. a. [2006]; [Übersetzung durch Verfasser]). . . . . . . . . . . . . . . . . . . . . . 65 39 22

XI

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

Verzeichnis der Listings
3.1. Beispiel für 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 Ziffern der Kartennummer (Quelle: Viaforensics [2011]; im Auszug). . . . . . . . . . . . . . . . . . . . . . 5.1. Auszug aus der AndroidManifest.xml. Gezeigt wird der Filter für ein benutzerdefiniertes URL Scheme (eigene Darstellung). . . . . . . . . 78 54 23

XIII

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

1. Einleitung
1.1. Motivation
Bargeldloser Zahlungsverkehr erfährt in regelmäßigem Abstand neue Entwicklungen. Das Ziel der Finanzinstitute ist es benutzerfreundliche, einfache und sichere Bezahlsysteme als Ersatz für das klassische Bargeld einzusetzen. Während das Bezahlen bei Händlern mit Hilfe von Kredit- und Geldkarten umgesetzt werden kann, ist der direkte Austausch von Beträgen zwischen einzelnen Personen deutlich komplizierter und wird von vielen Systemen nicht vorgesehen. Gerade dieser Punkt ist jedoch für 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 möglich und gleichzeitig können fortschrittliche Sicherheitsmechanismen angewandt werden. Des Weiteren lassen sich zusätzliche Dienste wie die Einsicht von Kontoständen und Sonderangebote mit dem Bezahlsystem verknüpfen. Allerdings sind zur Realisierung solcher bargeldloser Systeme Endgeräte notwendig, welche gegenüber einfachen Geldkarten einen größeren Funktionsumfang haben und eigenständig operieren können. Diese Bedingungen werden unter anderem von Mobiltelefonen erfüllt. Aus diesem Grund existieren verschiedene Bestrebungen für die Umsetzung von mobilen Bezahlsystemen auf Handys. In klassischen Mobiltelefonen werden diese Systeme häufig wegen der begrenzten technischen Möglichkeiten ohne eine P2P Funktion umgesetzt (vgl. Choi u. a. [2007]). Moderne Smartphones erlauben hingegen neue Kommunikationsformen und bieten eine Plattform für neue mobile Bezahlsysteme. Besonders die Entwicklung in Nahfunksysteme zur Datenübermittlung kann direkte Geldüberweisungen zwischen einzelnen Personen ohne dritte Instanz stark vereinfachen. Smartphones ermöglichen mit ihrem wachsenden Funktionsumfang aber auch neue Angriffe auf die Plattform. Gerade für Systeme, welche den Zugriff auf finanzielle Mittel ermöglichen, ist die Sicherheit jedoch von wesentlicher Bedeutung. Um sowohl der gewünschten Benutzerfreundlichkeit in einer Peer-to-Peer Umgebung gerecht zu werden und gleichzeitig ein sicheres Bezahlen zu ermöglichen, baut die vorliegende Arbeit auf das eKaay Verfahren auf. Dieses Verfahren wurde an

© Stefan Gfrörer

1

Peer-to-Peer Payment via NFC 1. Einleitung
der Eberhard-Karls-Universität Tübingen entwickelt und erlaubt die einfache Umsetzung von sicheren Bestätigungen für Transaktionen (vgl. Borchert [2012a] und Günther [2011]).

1.2. Ziel der Arbeit
Auf der Basis der zum Zeitpunkt dieser Arbeit aktuellen Smartphones soll ein bequemes mobiles Bezahlsystem mit P2P Funktionalität 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 vernachlässigt wird. Als Grundlage soll das bereits erwähnte eKaay Verfahren dienen. Die Sicherheit muss in einer ausführlichen 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 großem Umfang in der Arbeit von Günther [2011] vorgestellt. Diese umfasst auch eine Sicherheitsanalyse des Verfahrens und stellt Lösungen für aufgedeckte Probleme vor. Die Sicherheit von modernen, mobilen Plattformen im Zusammenhang mit Bezahlsystemen wurde von Agarwal u. a. [2007] und Kadhiwal u. Zulfiquar [2007] untersucht. Ihre Analysen dienen in der vorliegenden Arbeit als Grundlage für die Entwicklung eines sicheren Bezahlsystems. Eine Reihe von technischen Lösungen für mobile Bezahlsysteme werden in der Übersichtsarbeit von Mobey Forum Mobile Financial Services Ltd [2010] vorgestellt. Sie stellen einen Kontrast zu auf Software basierten Lösungen in dieser Arbeit dar. Eine Reihe von Wissenschaftlern haben in jüngerer Zeit die Umsetzung von mobilen Bezahlsystemen erforscht und Lösungsvorschläge erarbeitet. Diese umfassen zum Teil P2P Verfahren, aber auch Terminal basierte Lösungen. Zu diesen Arbeiten gehören Gao u. a. [2006], Li u. a. [2008], Pasquet u. a. [2008] und Gao u. a. [2009]. Die Ergebnisse und die darin entwickelten Verfahren werden teilweise in der Sicherheitsanalyse aufgegriffen und ebenfalls untersucht.

2

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 1.4. Voraussetzungen zum Verständnis der Arbeit

1.4. Voraussetzungen zum Verständnis der Arbeit
Die vorliegende Arbeit verwendet eine Reihe von Begriffen und Konventionen, welche im Folgenden kurz erläutert werden. Dies dient dem Verständnis des Lesers. Der Begriff „mobiles Bezahlsystem“ bezieht sich im weiteren Verlauf vorwiegend auf Systeme, welche Smartphones als wichtigstes Endgerät setzen. Diese Festlegung ist von Bedeutung, da andere Arbeiten mit dem Begriff unter anderem auf Systeme mit Geldkarten und ähnlichem verweisen und der Begriff 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 Geldbeträgen zwischen zwei Personen, welche sich in physikalischer Nähe befinden, verstanden. Dies steht im Gegensatz zu klassischen Überweisungen in Online Banking Systemen. Die Begriffe „Geldempfänger“ und „Zahlender“ beziehen sich auf die beiden Parteien in einer P2P Umgebung. Sie werden Geschlechtsneutral verwendet. Verschiedene Abläufe werden im Laufe dieser Arbeit sowohl textuell als auch grafisch dargestellt. Die Grafik dient dabei, wie in wissenschaftlichen Arbeiten üblich, der zusätzlichen Verdeutlichung. Die Nummerierung der einzelnen Schritte in Text und Bild kann divergieren, da im Text häufig Schritte logisch zusammengefasst werden. Einzelne Abläufe werden in vergrößerten Grafiken in Anhang A verdeutlicht. Diese sind jedoch nicht zum Verständnis notwendig, sondern dienen auschließlich der Ergänzung und Vertiefung.

1.5. Aufbau der Arbeit
In Kapitel 2 werden die für diese Arbeit relevanten Grundlagen und Technologien vorgestellt. Des Weiteren wird eine Einführung in mobiles Bezahlen gegeben. In Kapitel 3 folgt der Entwurf des mobilen Bezahlsystems eKaayCash. Dieses Kapitel enthält noch keine Sicherheitsanalyse zum Verfahren. Sie folgt in Kapitel 4, welches eine Reihe von mobilen Bezahlsystemen ausführlich untersucht und Sicherheitsprobleme hervorhebt. Einzelne Aspekte der Implementierung von eKaayCash werden in Kapitel 5 diskutiert. Abschließend werden in Kapitel 6 noch einmal alle Ergebnisse zusammengefasst, offene Probleme angesprochen und ein Ausblick gegeben.

© Stefan Gfrörer

3

Peer-to-Peer Payment via NFC

2. Grundlagen und Hintergründe
Die folgenden Abschnitte vermitteln wichtige Grundlagen und Konzepte für das Verständnis der weiteren Arbeit. Sie bilden eine Basis, auf welches in späteren 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 können leicht durch Social Engineering gebrochen werden (vgl. Jakobsson u. Myers [2006]). Das Verfahren eKaay versucht diese Problematik durch die Einführung eines zweiten Kanals in Form eines Smartphones zu umgehen. Anstelle einer Eingabemaske erhält der Benutzer auf dem Bildschirm des Computers einen 2D Code (vgl. Abbildung 2.1). Dieser Code enthält unter anderem eine Challenge in Form einer Nonce. Der Inhalt des 2D-Codes muss dabei nicht geheim bleiben. Fotografiert der Benutzer den 2D-Code mit Hilfe des Smartphones und der darauf installierten eKaay App ab, liest diese den Inhalt des Codes zunächst aus. Der Benutzer muss dann die Anmeldung auf dem Smartphone bestätigen. 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 prüft die Response auf Korrektheit und meldet den Benutzer im Erfolgsfall an. Voraussetzung für den beschriebenen Ablauf ist eine vorherige Registrierung des Benutzerkontos in der eKaay App und damit Hinterlegung der nötigen Kontodaten einschließlich des geteilten Geheimnisses. Einzelne Konten können auf dem Handy mit Hilfe einer Personal Identification Number (PIN) gesichert werden. Die Funktionalität von eKaay wird von zwei Komponenten zur Verfügung gestellt. Einerseits ist auf dem Smartphone die eKaay App installiert. Anderseits muss der Kontoserver über die Serverkomponente von eKaay verfügen. Diese erzeugt den 2D-Code und initiiert und validiert dann das Challenge-Response-Verfahren. Die App wurde bereits für 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 Günther [2011]).

© Stefan Gfrörer

5

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe

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

Günther [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 gültige Anmeldungen generieren. Beispielsweise sind alle auf dem Smartphone gespeicherten Daten nie vollkommen geschützt (vgl. Abschnitt 2.3). Dieses Sicherheitsrisiko lässt sich durch die Abfrage einer PIN vermindern, jedoch ist auch diese durch ein Schadprogramm angreifbar. Als Lösung für diese Gefahr schlägt Günther [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 empfängt 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 Bestätigung von Transaktionsdaten dient. Es kann unter anderem bei der Bestätigung einer Überweisung im Onlinebanking verwendet werden. Der Hauptunterschied zum klassischen Anmeldeverfahren ist die Erweiterung der Challenge um die Daten der Transaktion.

6

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 2.1. eKaay
Das Geheimnis bestätigt dann nicht nur die Nonce sondern zusätzlich die Daten (vgl. Borchert [2012a]). Dieses Verfahren ähnelt der Verwendung einer dynamischen Transaction Authentication Number (TAN) (vgl. Baden-Württembergische 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 erhält ein Formular mit den notwendigen Daten. Er füllt das Formular aus und sendet es zur Validierung an den Server. 2. Der Server prüft die eingegebenen Daten und erzeugt mit Hilfe der Serverkomponente von eKaay einen 2D-Code. Der Code enthält unter anderem die Nonce und die Transaktionsdaten in einer kompakten, aber für Menschen lesbaren Form. Zusätzlich speichert er sämtliche 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 prüfen, ob die vom Server empfangenen und validierten Daten mit der ursprünglichen Eingabe übereinstimmen. Abhängig von der Entscheidung des Benutzers wird der Vorgang anschließend abgebrochen oder durch Generierung der Response auf dem Smartphone abgeschlossen. 5. Das Smartphone überträgt die Response über eine eigene Internetverbindung an den Server. Der Server prüft die Response und vergleicht, ob die bestätigten Transaktionsdaten mit den ursprünglich empfangenen übereinstimmen. Im Erfolgsfall wird die Überweisung ausgeführt und der Benutzer bekommt eine Bestätigung angezeigt. Die Variante eKaay TAN basiert auf dem klassischen eKaay Verfahren. Der einzige Unterschied liegt in der zusätzlichen Verwendung der Transaktionsdaten in der Challenge. Damit gelten die Ergebnisse der Sicherheitsanalyse von Günther [2011] auch für eKaay TAN. Die Sicherheit einer Überweisung wird durch die folgenden beiden Mechanismen erreicht (vgl. Borchert [2012a] und Günther [2011]). 1. Der Server erhält zu Beginn alle Daten und kann nach Abschluss prüfen, ob der Benutzer diese Daten bestätigt hat oder ob sie durch fremden Zugriff verändert wurden. 2. Um den Server zu täuschen muss ein Angreifer im Zeitraum zwischen dem Abschicken der Transaktionsdaten durch den Benutzer und dem Empfang durch

© Stefan Gfrörer

7

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe
den Server eine Manipulation durchführen. Diese Manipulation kann vom Benutzer aber wiederum erkannt werden, wenn er die Überweisungsdaten auf seinem Smartphone verifiziert. Als Restrisiko verbleibt ein Schadprogramm auf dem Smartphone, welches zunächst den Server täuscht und bei der anschließenden Verifizierung durch den Benutzer eine gefälschte Anzeige erzeugt (vgl. Günther [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. Prüfung der Daten und Response Generierung 6. Einlesen

3. Validierung und 2D Code Generierung

8. Response 9. Validierung und Ausführung der Überweisung Smartphone des Kunden

Server mit eKaay

Abbildung 2.2.: Das eKaay TAN Verfahren im Detail. Das Versenden der Bestätigung ist nicht enthalten (eigene Darstellung). Eine weitere, für 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 Ziffern. Diese Permutation basiert auf dem Schlüssel des Benutzerkontos und der Challenge und ist somit für jeden Vorgang individuell. Die Permutation – in Form von vertauschten Zahlen in einem Ziffernfeld – wird dem Benutzer auf dem Handy angezeigt. Im Browser des Computers sieht er des Weiteren ein Zifferneingabefeld ohne Beschriftung. Basierend auf der angezeigten Permutation muss der Benutzer die entsprechenden Buttons im Einga-

8

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 2.2. Near Field Communication (NFC)
befeld auswählen. Im Anschluss überträgt der Browser die Position und Reihenfolge der ausgewählten 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 überprüfen (vgl. Borchert [2012a] und Günther [2011]). In Abbildung 2.3 sind eine Permutation auf dem Smartphone und das dazu gehörige Eingabefeld im Browser dargestellt. Günther [2011] zeigt, dass eKaay PIN vor einem Schadprogramm auf dem Smartphone des Benutzers schützt. Damit ist das eKaay Verfahren auch dann sicher, wenn der Schlüssel 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 Ziffernfeld und rechts das Formular im Browser mit QR Code und Zifferneingabefeld ohne Beschriftung dargestellt (Quelle: Borchert [2012a]). Zusammenfassend lässt sich sagen, dass eKaay ein Rahmenwerk für sichere Anmeldungen und Bestätigungen von Daten darstellt. Aufgrund der Verwendung von QR Codes bietet es den Anwendern Vorteile in der Benutzbarkeit und macht das Merken von komplizierten Passwörtern überflüssig.

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

© Stefan Gfrörer

9

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe
– 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 beträgt bis zu zwanzig Zentimeter. In der Praxis ist aber häufig ein deutlich geringerer Abstand zwischen den Antennen notwendig (vgl. Günther [2011] und Van Damme u. a. [2005]). Der NFC Standard verfügt über drei Modi in denen ein NFC-fähiges Gerät betrieben werden kann. Sie unterscheiden sich in der Verteilung der Rollen und dem Sendemodus, d. h. darin ob sich das Gerät aktiv oder passiv an der Kommunikation beteiligt. Die Modi werden abhängig von der gewünschten Anwendung ausgewählt (vgl. Van Damme u. a. [2005]). Card Emulation Mode. In diesem Modus verhält sich das Gerät vollkommen passiv und simuliert das Verhalten einer NFC-fähigen Karte wie beispielsweise MasterCard PayPass Kreditkarten (vgl. MasterCard [2012]). Reader/Writer Mode. Das Gerät arbeitet als aktives Lesegerät für RFID oder NFC Tags. Das passive Tag wird mit Hilfe magnetischer Induktion mit der nötigen Energie versorgt. Peer-to-Peer Mode. Zwei NFC Geräte kommunizieren miteinander. Sie können dabei sowohl aktiv als auch passiv sein. Es erfolgt eine Rollenverteilung nach dem Master/Slave-Prinzip. NFC unterstützt drei verschiedene Datenraten. Abhängig von der Datenrate kommt eine modifizierte 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 modifizierte Miller-Kodierung wird nur von aktiven Geräten in der geringsten Datenrate eingesetzt. In allen anderen Fällen arbeiten die Geräte mit der Manchester-Kodierung (vgl. Van Damme u. a. [2005]). Zur Erleichterung der Kommunikation zwischen zwei Endgeräten hat das NFC Forum [2012] das NFC Data Exchange Format (NDEF) spezifiziert. Es beschreibt einen standardisierten Aufbau für Datenpakete im Nahfunk und muss von jedem NFC-fähigen Gerät unterstützt werden (ebd.). Die Benutzerakzeptanz von Nahfunk Systemen ist noch nicht komplett erforscht. Deshalb besteht die Möglichkeit, dass Benutzer dieser Technik ablehnend gegenüber stehen. Dies kann mit der Unwissenheit über die Leserechte eines NFC-fähigen

10

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 2.3. Android

Modifizierte Miller-Kodierung, 100% ASK

1

0

1

0

Manchester-Kodierung, 10% ASK

1

0

1

0

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

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

2.3. Android
Android ist zum Zeitpunkt der Entstehung dieser Arbeit eines der wenigen mobilen Betriebssysteme, welches NFC unterstützt. Zudem ist es eines der ersten Systeme, für welches man NFC-fähige Smartphones erwerben kann (vgl. NFC Forum [2012]). Zum Zeitpunkt der Entstehung dieser Arbeit steht die mit Android Version 2.3 Gingerbread eingeführte Programmierschnittstelle (API) für Nahfunk zur Verfügung (vgl. Google [2012a]). Eine vereinfachte API für Peer-to-Peer Verbindungen wird mit Android Version 4 Ice Cream Sandwich verfügbar werden. Die Schnittstelle aus Version 2.3 bleibt aber erhalten und ist auch in späteren Versionen gültig (vgl. Google [2012b]). Android sichert Daten auf dem Smartphone durch eine Reihe von Mechanismen ab. Die grundlegende Sicherheit entsteht durch eine strikte Abschottung einzelner Applikationen von einander. Dazu gehören neben der Kommunikation zwischen einzelnen Programmen auch der Zugriff auf das Dateisystem. Zusätzlich werden einzelne Funktionen nur durch explizite Anfrage und Erlaubnis durch den Benutzer bewilligt. Beispielsweise muss eine Applikation für die Nutzung der NFC Schnittstelle freigegeben werden. Diese Sicherheitsmechanismen können aufgrund von bisher unerkannten Fehlern umgangen werden. Zusätzlich können Benutzer das Betriebssystem unter bestimmten Bedingungen neu installieren und ihrem Benutzerkonto

© Stefan Gfrörer

11

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe
umfassende Rechte erteilen. Eine Applikation, die mit diesen Rechten ausgeführt wird, kann normale Beschränkungen umgehen (vgl. Google [2012d]). Applikationen unter Android müssen aufgrund der Abschottung bestimmte Ressourcen oder Rechte für fremde Informationen explizit anfordern. Beispiele dafür sind der Zugriff auf Netzwerkverbindungen oder die Daten des Telefonbuchs. Die Anforderung geschieht mittels der Datei AndroidManifest.xml, welche in jeder App vorhanden sein muss. Diese Datei enthält Metainformationen über die Applikation, definiert die Rechte der Applikation – unter der Bedingung, dass der jeweilige Benutzer diese Rechte vergibt – und enthält Filter und Regeln für den Umgang von Android mit der Applikation (vgl. Google [2012c]).

2.4. Mobile Payment (MP)
Durch die Verbreitung von Funktelefonen wächst auch die Nutzung derselben zum Bezahlen von beliebigen Gütern. 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 gegenüber klassischem Geld und Geldkarten. Das Handy wird in vielen Fällen leicht erreichbar getragen und ermöglicht so einen wesentlich schnelleren Bezahlvorgang. Dieser Vorteil steigt mit wachsender Leistungsfähigkeit und technischen Fähigkeiten jüngerer 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 Durchführung von Überweisungen (vgl. Gao u. a. [2009]). Konto basiert. Das Benutzerkonto beim Anbieter der Bezahllösung wird an ein Bankkonto bei einer dritten Partei – meist einer reellen Bank – gebunden. Der Anbieter und die Bank können dabei dieselbe Partei sein, für den Ablauf spielt das aber keine Rolle. Der Dienstanbieter agiert mit seinem System als eine Art Koordinator zur Bank. Abhängig vom zugrunde liegenden Prinzip werden die eigentlichen Überweisungen bei der Bank zeitversetzt zur mobilen Transaktion durchgeführt. Die mobile Transaktion innerhalb des Systems des Dienstanbieters repräsentiert eine virtuelle – und von allen beteiligten Parteien, inklusive Geldempfänger und Zahlender, als reell akzeptierte – Überweisung.

12

© Stefan Gfrörer

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 Geldbeträge als auch die für eine Überweisung nötigen Kontodaten enthalten kann. Abhängig 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 Lösungen unterscheiden zwei Umsetzungen. Einerseits kann die eigentliche Wallet beim Dienstanbieter auf dem Server verwaltet, anderseits kann sie auch auf dem gewünschten mobilen Endgerät abgelegt werden (vgl. Abschnitt 4.5). In letzterem Fall muss die Wallet besonders vor Fremdzugriffen geschützt werden. Wie zu Beginn der Arbeit angesprochen ist die Benutzerfreundlichkeit ein wichtiges Kriterium für den Erfolg eines mobilen Bezahlsystems. Dazu gehören sowohl die Bedienung der Applikation als auch der Austausch der notwendigen Kontoinformationen. Eine manuelle Eingabe einzelner Daten ist in vielen Fällen langsamer als das automatische Einlesen mittels einer einfachen Schnittstelle wie NFC in neueren Smartphones. Zusätzlich ermöglicht bargeldloses Zahlen mit einer eigenständigen Hardware in Form des Smartphones die Möglichkeit, weitere Dienste und vereinfachte Abläufe anzubieten (vgl. Massoth u. Bingel [2009] und Karnouskos [2004]). Beispielsweise können Informationen über Sonderangebote direkt auf das Handy übertragen werden (ebd.). Gao u. a. [2009] schlägt das Einkaufen ohne Kasse vor (ebd.). Des Weiteren ist die Sicherheit sowohl für den Dienstanbieter als auch für den Kunden von Bedeutung. Mobile Bezahlsysteme sind in vielen Fällen ä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 Fällen ist ein Missbrauch der Informationen möglich. 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 schlägt es die Verwendung von Secure Elements (SE) vor (ebd.). Verschiedener Angriffspunkte werden in Abschnitt 4.2 ausführlich behandelt. Die Vielzahl der mobilen Bezahllösungen basiert auf Point of Sale (POS) Systemen. Ein POS besteht meist aus einem Terminal, dass über Schnittstellen mit der Kasse und dem Identifikationselement – der Geldkarte, dem Smartphone usw. – des Kunden kommuniziert und die Überweisung durchführt (vgl. Choi u. a. [2007]). POS Terminals bestehen größtenteils aus einer eigenständigen und speziell für das

© Stefan Gfrörer

13

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe
Bezahlen entwickelten Hardware, die das sichere Überweisen in einem prinzipiell unsicheren Umfeld ermöglicht (vgl. EMVCo [2008]). Andere Bezahlsysteme ermöglichen die direkte Überweisung zwischen zwei Kunden des Dienstleisters. Beim sogenannten Peer-to-Peer Payment werden Transaktionen direkt zwischen zwei Personen durchgeführt. Teilweise wird auch der Begriff des Consumer-to-Consumer (C2C) Payment verwendet (vgl. [Choi u. a. 2007, Seite 6ff.]). Im Gegensatz zur klassischen Überweisung im Onlinebanking bezieht eine P2P Überweisung die physikalische Nähe beider Parteien mit ein. Die rudimentäre Form einer P2P Bezahlung ist das Zahlen mit reellem Geld in Münz- oder Papierform. In mobilen Systemen tritt das Smartphone an die Stelle des Geldes und es werden keine physikalischen Objekte übergeben, sondern es findet ein Informationsaustausch zwischen den Smartphones statt. Die Benutzerinteraktion beschränkt sich dann auf die Initiierung des Vorgangs, die Eingabe der Daten – meist nur der Betrag – und die manuelle Bestätigung (vgl. Karnouskos [2004]). Eine P2P Überweisung kann sowohl vom Zahlenden als auch vom Geldempfänger ausgehen. Im Folgenden wird der Ablauf ausgehend vom Zahlenden beschrieben. Abbildung 2.5 visualisiert dies. 1. Der Zahlende drückt seinen Zahlungswunsch durch Erstellung einer Anfrage aus. Diese kann bereits den Betrag enthalten. Die Anfrage wird an das Smartphone des Geldempfängers übertragen. 2. Sofern noch kein Betrag in der Anfrage festgelegt wurde, setzt ihn der Geldempfänger ein und leitet die Anfrage an den Server des Dienstanbieters weiter. 3. Der Server verifiziert die Anfrage und stellt eine Bestätigungsanfrage an den Zahlenden. Dabei handelt es sich im Normalfall um eine Form von Challenge, welche die Transaktionsdaten enthält. 4. Der Zahlende bestätigt die Zahlung, die im Anschluss vom Server durchgeführt wird. Des Weiteren der Ablauf initiiert durch den Geldempfänger und grafisch dargestellt in Abbildung 2.6. Da eine Überweisung nicht erst über den Geldempfänger transferiert werden muss, verringert sich die Anzahl der notwendigen Schritte. 1. Der Geldempfänger erstellt eine Zahlungsanfrage mit dem gewünschten Betrag und übermittelt diese an den Zahlenden. 2. Der Zahlende prüft die Anfrage, bestätigt sie und leitet die bestätigte Zahlungsanfrage an den Server weiter.

14

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 2.4. Mobile Payment (MP)
3. Der Server prüft die eingegangene Überweisung und führt sie im Erfolgsfall aus. Die beschriebene Variante kommt ohne Challenge von Seiten des Servers aus. Es ist aber auch möglich, dass der Geldempfänger ä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 Geldempfänger

3a. Bestätigungsanfrage

3b. Bestätigung

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 Gfrörer

15

Peer-to-Peer Payment via NFC 2. Grundlagen und Hintergründe

1. Zahlungsanfrage Geldempfänger Zahlender

2. Bestätigte Zahlungsanfrage

3. Abschluss der Transaktion Zahlungsserver
Abbildung 2.6.: Eine Peer-to-Peer Überweisung ausgehend vom Geldempfänger (eigene Darstellung).

16

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

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 zunächst eine Reihe von Zielen für das fertige Produkt formuliert. Daraufhin folgt die Vorstellung einer Testumgebung, welche an reelle Banksysteme angelehnt ist. Anschließend wird zunächst der Entwurf des reinen Bezahlsystems und dann eine Erweiterung für Online Shop Systeme erläutert. 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 müssen die Rahmenbedingungen festgelegt werden. Sie definieren die Ziele, welche zum Schluss erfüllt sein müssen. Des Weiteren geben sie einen Leitfaden vor, der beim Entwurf unterstützen kann. Grundarchitektur ist eKaay. Zur Umsetzung eines Bezahlsystems eignet sich eKaay, da es mit eKaay TAN bereits eine notwendige Komponente zur Verfügung stellt. Mittels eKaay TAN ist ein Challenge-Response-Verfahren möglich, welches Transaktionsdaten enthält (vgl. Abschnitt 2.1). Auf diese Weise lassen sich Überweisungen sicher verifizieren. Kommunikation mittels NFC. Zur Erforschung von Near Field Communication und der Präsentation einer Anwendung soll das Bezahlsystem den Einsatz von NFC zur Kommunikation ermöglichen. In bereits bestehenden Arbeiten konnte gezeigt werden, dass NFC insbesondere im Bereich der mobilen Bezahlsystemen Vorteile – beispielsweise in Sicherheit und Benutzerfreundlichkeit – gegenüber anderen Technologien aufweist (vgl. Ondrus u. Pigneur [2007]). Da die Applikation per Definition einen P2P Kontakt vorsieht, sollte der gleichnamige Peer-to-Peer Mode (vgl. Abschnitt 2.2) verwendet werden. Kompatibilität mit iOS und Android. Aus der Anforderung eines mobilen Betriebssystems, welches sowohl NFC unterstützt als auch einen Client für eKaay besitzt, ergibt sich die Verwendung von Android als mobile Plattform. Trotzdem soll auch die aus eKaay bekannte Kompatibilität mit iOS bestehen bleiben.

© Stefan Gfrörer

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 beschränken, sondern muss auch Alternativen bieten. Der in eKaay verwendete QR Code bietet sich für diesen Zweck an.

Änderungen an der Architektur vermeiden. Die Implementierung des eigentlichen Bezahlverfahren muss möglichst ohne Änderung der Architektur durchgeführt werden. Dies betrifft insbesondere eKaay. Dies setzt eine Trennung des Bezahlsystems von eKaay voraus und ermöglicht so eine unabhängige 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 möglich. Dafür steht ein Überweisungsformular zur Verfügung, welches neben Empfänger und Betrag auch die Eingabe eines Verwendungszweck vorsieht. Anstelle eines klassischen TAN Verfahrens wird der Einfachheit halber das eKaay TAN Verfahren eingesetzt. Es ermöglicht die Bestätigung 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 möglich. Um eKaay einsetzen zu können, wurde die Serverkomponente von eKaay nach Anleitung parallel zum Server der Bank installiert (vgl. Borchert [2012a]). Damit eine Anbindung des Kontos an eKaay möglich ist, kann ein Benutzer in seinen persönlichen Kontoeinstellungen das Smartphone und damit auch das Konto für eKaay registrieren. Mit Ausnahme der Anmeldung und der TAN-Abfrage implementiert die Bank keinerlei Sicherheitsmechanismen wie sie für Finanzinstitute vorgeschrieben sind. Dies ist nicht Inhalt dieser Arbeit und würde den Rahmen übersteigen. Um dem Zweck einer Testumgebung gerecht zu werden, stellt der Server eine Reihe von Ausgaben zur Verfügung. Diese Ausgaben ermöglichen die Beobachtung aller Konten und aller durchgeführten Transaktionen. Der Server ist wie eKaay komplett in PHP entwickelt. Eine Übersicht ist in Anhang A in Abbildung A.1.

18

© Stefan Gfrörer

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. Zunächst wird das Verfahren vorgestellt und das Gesamtkonzept beschrieben. Im Anschluss werden die Umsetzung der Kommunikation und ein zusätzlicher Sicherheitsmechanismus erläutert. Das Verfahren wird ab diesem Zeitpunkt als eKaayCash bezeichnet. Die Partei, welche eKaayCash als Bezahlsystem anbietet, erhält 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, können in Konto basierenden Verfahren die eigentliche Bank und der Dienstanbieter für 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 bestätigten Überweisungen an die Bank durchführt. Das hat den Vorteil, dass das Verfahren die Verifizierungsmechanismen der Bank verwenden kann. Diese Festlegung folgt den in Abschnitt 3.1 beschriebenen Regeln. Insbesondere ist keine Implementierung einer gesonderten Verifizierung in eKaay notwendig. Unabhängig vom eigentlichen Ablauf muss das Verfahren eine Reihe von Daten von den Benutzern erfassen. Essentiell sind der Bezeichner des Geldempfängers, der Bezeichner des Zahlende und der Betrag. Optional und üblichen Überweisungsformularen folgend wird auch die Eingabe eines Verwendungszweck ermöglicht (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 erhöht 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 benötigt ein Smartphone. Im Gegensatz zu einem klassischen Überweisungsformular müssen nicht alle Daten manuell abgefragt werden. Im klassischen Verfahren ist der Zahlende bekannt, da er die Überweisung erstellt. In einer mobilen Variante mit eKaay fällt zusätzlich die zweite Partei weg, da sie durch das in der eKaay App gespeicherten Konto identifiziert werden kann (vgl. Abschnitt 2.1). Das Formular muss dann nur noch den Betrag und den optionalen Verwendungszweck abfragen (vgl. Abbildung 3.1).

© Stefan Gfrörer

19

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

P2P Überweisung
Betrag: 0,00 € Verwendungszweck (optional):

Abbildung 3.1.: Formular für eine mobile Überweisung. Geldempfänger und Zahlender werden automatisch erfasst (eigene Darstellung). Mit der Festlegung der Art des mobilen Bezahlsystems und dem Entwurf eines Formulars für mobile Überweisungen auf Seiten der Bank, kann der eigentliche Ablauf einer Transaktion bestimmt werden. Wie in Abschnitt 2.4 erläutert, kann eine Transaktion vom Zahlendem oder vom Geldempfänger ausgehen. Der in Abbildung 2.2 dargestellte Ablauf für eKaay TAN entspricht der in Abschnitt 2.4 beschriebenen, vom Geldempfänger ausgehenden, Variante. Ein Ablauf vom Geldempfänger aus ist auch aufgrund des Webformulars notwendig. Beim Aufruf des Formulars hat der Geldempfänger sich am Server der Bank angemeldet. Nach Eingabe aller Daten erhält der Server somit Informationen über Geldempfänger, Betrag und Verwendungszweck. Durch die Bestätigung der eKaay TAN Challenge durch den Zahlenden erhält der Server den fehlenden Identifikator (ID) des Zahlenden und kann im Anschluss eine vollständige Überweisung durchführen. Der Ablauf mit eKaay ist zwar auch vom Zahlenden ausgehend durchführbar, in diesem Fall muss er aber die ID des Geldempfängers entweder manuell eingeben oder es ist eine zusätzliche Kommunikation zwischen beiden Smartphones notwendig, welche den ID Austausch beinhaltet. Des Weiteren kann der vorgeschlagene Ablauf in einer späteren Variante von eKaayCash verwendet werden (vgl. Abschnitt 3.4). Der im Folgenden beschriebene und in Abbildung 3.2 grafisch dargestellte Ablauf berücksichtigt somit die in Abschnitt 3.1 festgelegten Punkte Grundarchitektur und Vermeidung von Änderungen in derselben. Eine ausführliche Darstellung befindet sich im Anhang A in Abbildung A.2. 1. Der Geldempfänger 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 Identifikator des Geldempfänger aus. Aus ID, Betrag und Verwendungszweck generiert er unter Verwendung von eKaay eine Challenge und überträgt diese in Form eines QR Codes oder kodiert für eine Übertragung via NFC an den Geldempfänger.

20

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash
3. Die Challenge wird auf dem Bildschirm des Empfängers 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 überprüfen und ablehnen oder bestätigen. Im Fall einer Bestätigung 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 prüft die Response und die Transaktion im Gesamten. Im Erfolgsfall führt er sie aus. Sowohl der Geldempfänger als auch der Zahlende erhalten eine Bestätigung.
3. Challenge von eKaay TAN Geldempfänger Zahlender 4. Prüfen und Bestätigen 2. Challenge von eKaay TAN 5. Response

1. Überweisungsformular

6. Abschluss der Transaktion

Server der Bank

Abbildung 3.2.: Ablauf einer Transaktion mittels eKaayCash. Bestätigungen nach erfolgreicher Durchführung 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. Gegenüber einem klassischen Client-Server-Modell steht die Rollenverteilung nicht fest, sondern muss aus dem Kontext bestimmt werden. Dies ergibt häufig wechselnde

© Stefan Gfrörer

21

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay
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 stattfindet. Diese Kommunikation überträgt die Challenge vom Smartphone des Geldempfängers auf das Smartphone des Zahlenden. Eine Bestätigung des erfolgreichen Empfangs ist nicht nötig, da beide Parteien in physikalischer Nähe zueinander stehen und somit den Vorgang im Fall eines Fehlers jederzeit neu starten können. Aus dem eKaay Verfahren ergibt sich der Datenaustausch mit Hilfe eines QR Codes. Er wird nach vollständigem Ausfüllen des Überweisungsformulars vom Server erzeugt und auf dem Bildschirm des Geldempfängers angezeigt. Der QR Code enthält in der Variante eKaay TAN neben Metadaten für 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 vollständige 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 abfotografiert werden. Die App liest anschließend die enthaltenen Daten aus und führt den nächsten Schritt des eKaay TAN Verfahrens durch. Da die Applikation für 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 Kompatibilität aus Abschnitt 3.1 erfüllt. Das zweite Kommunikationsmedium ist die Übertragung mittels Near Field Communication. Um den QR Code einzulesen müssen die Smartphones in einer bestimm-

22

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 3.3. Entwurf von eKaayCash
te Art und Weise zueinander gehalten werden. Dadurch wird jedoch die Benutzerfreundlichkeit der Anwendung verringert. Eine einfachere Bedienung ermöglicht NFC, da es lediglich eine physikalische Nähe beider Geräte für einen kurzen Zeitraum benötigt. Die Haltung ist dabei unspezifischer als bei der Verwendung des QR Code. Damit NFC im bestehenden Ablauf verwendet werden kann, ist eine Erweiterung von eKaay nötig. Dazu wird in die Webseite, welche den QR Code anzeigt, ein Link integriert. Er enthält die Daten für die Übertragung via NFC. Es handelt sich dabei um dieselben Informationen wie in Tabelle 3.1. Sie werden gemäß dem Standard für Uniform Resource Locators (URL) kodiert (vgl. Lee u. a. [1994]). Des Weiteren wird der Link mit einem für eKaayCash festgelegten Scheme ausgezeichnet. Die Form eines Scheme wurde von Lee u. a. [1994] definiert. Um den Anforderungen des Standards zu entsprechen, wurde der Begriff „ekaaycash“ in Kleinbuchstaben als aussagekräftiges Scheme gewählt. In Listing 3.1 ist der Beginn eines Links mit vollständigem Scheme dargestellt. Er wird vom Server nur in den Quellcode integriert, wenn ein NFC-fähiges Endgerät die Webseite aufruft. Aufgrund von Beschränkungen durch viele Hersteller kann die Unterstützung anhand des User-Agent nur eingeschränkt 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 vollständig.
1

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

Listing 3.1: Beispiel für einen eKaayCash NFC Link kodiert gemäß Lee u. a. [1994] (eigene Darstellung). Zur Benutzung von NFC muss der Anwender nur diesen Link ausführen. Dies startet automatisch die eKaay App aufgrund folgender Erweiterung. Die Erweiterung verknüpft die App mit dem implementierten Scheme. Dazu wird das in Abschnitt 2.3 vorgestellte Manifest um einen Filter für benutzerdefinierte URL Schemes erweitert. Der Filter gibt an, dass das Programm ein neues Scheme registriert und dieses verarbeiten kann. Das Betriebssystem erhält damit die Information, welches Programm bei Aufruf eines bestimmten Schemes ausgeführt werden muss. Wurde der NFC Link von der eKaay App empfangen und wurden die kodierten Nutzdaten extrahiert, können 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 anschließend an den NFC Adapter von Android übermittelt, welcher sie im Fall eines Kontakts überträgt. Die App aktiviert gleichzeitig den Empfang von Nachrichten. Auf diese Weise müssen sowohl der Geldempfänger als auch der Zahlende keine weiteren Schritte unternehmen. Die Datenübertragung findet statt, sobald sich beide Smartphones in einem ausreichend geringen Abstand zueinander befinden.

© Stefan Gfrörer

23

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay
Die in diesem Abschnitt vorgestellten Änderungen erfüllen das Kriterium der Verwendung von NFC in Abschnitt 3.1. Sie erfordern zwar geringfügige Anpassungen an der Serverkomponente von eKaay und an der Applikation und widersprechen somit der Vermeidungen von Änderungen, allerdings sind die Änderungen vollständig optional. Die Verwendung von NFC erhöht die Benutzerfreundlichkeit für die Anwender durch eine Vereinfachung der Bedienung und zeigt Vorteile gegenüber 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 Bestätigung der Transaktion verbessert werden. Die Eingabe einer PIN vermindert jedoch wiederum die Benutzerfreundlichkeit. Zudem ist sie bei Kleinstbeträgen häufig nicht notwendig, da der Aufwand für einen Angreifer höher zu bewerten ist, als der Gewinn aus diesen Summen. Im Zuge der Einführung des kontaktlosen girogo Verfahrens hat die Deutsche Kreditwirtschaft [2012] eine Höchstgrenze von zwanzig Euro für Transaktionen ohne PIN festgelegt. Höhere Beträge müssen 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 Bestätigung der Transaktion durch den Zahlenden stellt die eKaay Server Komponente eine Anfrage an den Server des Dienstanbieters, ob eine PIN für die vorliegende Überweisung notwendig ist. Diese Funktionalität ist bereits in eKaay integriert und benötigt 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 großen Anzahl kleinerer Beträge 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 flexibel erweiterbar. Durch die Verwendung von eKaay PIN kann die PIN zudem nicht durch ein Schadprogramm auf dem Handy gestohlen werden.

24

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 3.4. Erweiterung für Online Shop Systeme

3.4. Erweiterung für Online Shop Systeme
In seiner beschriebenen Form ist eKaayCash ein vollwertiges mobiles Bezahlsystem mit Peer-to-Peer Funktionalität. 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 ermöglicht. 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 benötigt außer bei eKaayCash selbst keine weitere Registrierung. Im Gegensatz zum reinen P2P Verfahren füllt nicht ein Mensch das Überweisungsformular aus. Aus diesem Grund wird es so angepasst, dass auch von einer Software Überweisungen generiert werden können. Das Programm auf dem Server, welches das Formular verarbeitet, wird darum um einen zusätzlichen Parameter erweitert. In der ursprünglichen Variante erwartet das Programm den Betrag und den optionalen Verwendungszweck. Dazu kommt die ID des Geldempfängers, welche automatisch ausgelesen wird, da der Geldempfänger sich zuvor anmelden muss. Die Anmeldung entfällt bei einem Online Shop und wird durch einen neuen Parameter für die ID des Shops – also des Geldempfängers – ersetzt. Das Konto mit dieser ID muss zuvor beim Dienstanbieter für 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 für 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 Datenübertragung möglich. Nach der Durchführung einer Transaktion, d. h. nach Kauf durch einen Kunden, sendet der Server des Dienstanbieters eine Bestätigung für die Bezahlung an den Server des Online Shops. Diese Bestätigung enthält 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 Bestätigung verifizieren. Ein vergleichbares Verfahren wird von PayPal

© Stefan Gfrörer

25

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

Abbildung 3.3.: Beispiel für einen Artikel mit der dazugehörenden 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 Prüfung zwingend notwendig. Für die Art der Kontrolle existieren verschiedene Möglichkeiten. 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 grafisch dargestellt. In Anhang A in Abbildung A.3 befindet sich eine Grafik des vollständigen Ablaufs. 1. Der Kunde liest den QR Code mit seinem Smartphone ein und bestätigt den Kauf durch die Bestätigung der Transaktion. 2. Die erzeugte Response wird an den Server des Dienstanbieters übertragen und verifiziert. Im Erfolgsfall führt der Server die Transaktion durch und sendet eine Bestätigung an den Server des Online Shops. 3. Der Server des Online Shops nutzt die in der Bestätigung enthaltenen Daten und sendet eine weitere Anfrage an den Server des Dienstanbieters. 4. Der Server des Dienstanbieter kontrolliert die Daten und bestätigt diese gegenüber dem Online Shop. Wie zu Beginn dieses Abschnitts erklärt, benötigt der Online Shop keine Registrierung. Die für den Versand benötigten Kundendaten erhält er stattdessen zusammen mit der Bestätigung der Transaktion vom Server des Dienstanbieters. Für einen Kunden hat dies den Vorteil, dass er nicht in jedem Online Shop eine Registrierung durchführen muss. Dadurch wird sowohl die Benutzerfreundlichkeit als auch die Sicherheit erhöht, da die Daten nur beim Dienstanbieter gespeichert werden müssen.

26

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 3.5. Fazit
Produktcode 1. Einlesen Kunde

2. Response

4. Transaktionsbestätigung 5. Daten zur Überprüfung 6. Echtheitsbestätigung 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 für die Sicherheit der Kundendaten verantwortlich – mit Ausnahme des Zeitraums zwischen Kauf und Versand – und hat gleichzeitig eine bestätigte Bindung von Kontodaten an Kundendaten durch den Dienstanbieter. Die in diesem Abschnitt vorgestellte Erweiterung für eKaayCash ermöglicht ein einfaches Bezahlsystem für Online Shops. Die Verwendung an Kassen und Automaten ist – vorausgesetzt eine Verbindung zum Internet besteht – ebenfalls möglich. Aufgrund der Bindung von Bezahlung und Kundendaten werden Betrugsversuche erschwert. Gleichzeitig steigt die Benutzerfreundlichkeit sowohl für den Kunden als auch für den Händler.

3.5. Fazit
In diesem Kapitel wurde eine erste Anwendung für das eKaay TAN Verfahren demonstriert und seine Vorteile in Bezahlsystemen dargestellt. Dabei wurden alle zuvor definierten Ziele für eKaayCash eingehalten. Das Verfahren verwendet eKaay als zentrale Verifizierungsinstanz und zur Absicherung aller Transaktionen. Dabei wird eKaay eingesetzt ohne verändert zu werden. Aus diesem Grund ist eKaayCash auch vollkommen kompatibel mit der eKaay Implementierung auf anderen Betriebssys-

© Stefan Gfrörer

27

Peer-to-Peer Payment via NFC 3. Peer-to-Peer Payment mit eKaay
temen wie iOS. Zudem konnte auch der Einsatz von Nahfunk präsentiert werden. Die optionalen Änderungen sind nur geringfügig und ändern das Prinzip von eKaay nicht. Es wird lediglich um einen weiteren Kommunikationskanal zum QR Code ergänzt. Die Verwendung von eKaay ermöglicht 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 für Online Shops dargelegt werden. Die Erweiterung ist auch ein Beweis für die Trennung von eKaay und eKaayCash. Es war keine Änderung an eKaay notwendig, um die Erweiterung umzusetzen. Diese Trennung bietet auch den Vorteil, dass verschiedene Mechanismen von eKaay in eKaayCash verwendet werden können. Einen Hinweis darauf gibt bereits die Einbindung von eKaay PIN. Möglich ist aber auch die Verwendung von eKaayCard vorgestellt von Günther [2011]. Dadurch kann die Sicherheit weiter erhöht werden, bzw. kann dies eine Alternative zur PIN darstellen und so die Benutzerfreundlichkeit verbessern, da das Merken der PIN entfallen würde. Zudem muss die Verwendung von eKaay PIN in einem P2P System kritisch betrachtet werden. Es macht die Eingabe der permutierten PIN im Smartphone des Geldempfängers notwendig. Dieser muss sein Smartphone gegebenenfalls aus der Hand geben oder zumindest dem Zahlenden zur Eingabe der PIN hinhalten. Der Ablauf minimiert die nötige Benutzerinteraktion auf das Notwendige. Eine mögliche Ablehnung gegenüber NFC durch Anwender wird mit der Verfügbarkeit von QR Codes begegnet. Die eKaay Basis vereinfacht die Installation der nötigen Software und Konten auf dem Smartphone. Diese Aspekte können folglich zu einer hohen Benutzerakzeptanz führen.

28

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

4. Analyse bestehender mobiler Bezahlsysteme
Im zweiten Hauptteil der vorliegenden Diplomarbeit wird das entwickelte Verfahren eKaayCash auf mögliche Sicherheitslücken und Angriffspunkte untersucht. Dieselben Untersuchungsschritte werden für eine Reihe weiterer Verfahren durchgeführt, welche sich zum Zeitpunkt der Entstehung dieser Arbeit bereits im Einsatz oder in der Endphase ihrer Entwicklung befinden. Die einzelnen Ergebnisse werden, sofern möglich, miteinander verglichen.

4.1. Vorgehen
4.1.1. Auswahl der Verfahren und Kriterien
Mit dem Aufkommen moderner Smartphones und neuer Technologien – beispielsweise NFC und höher auflösenden Kameras – wächst auch die Anzahl verschiedener kommerzieller Systeme für den mobilen Einsatz (vgl. Shinder [2011]). Für die in der vorliegenden Arbeit anzustellende Analyse wurde eine repräsentative Auswahl von Verfahren nach folgenden Kriterien getroffen. Verfügbarkeit. Es wurden nur Verfahren ausgewählt, über welche ausreichend Informationen zur Verfügung stehen. Zum Entstehungszeitpunkt dieser Arbeit befanden sich viele Lösungsansätze erst in der Entwicklung und wurden darum nicht in die Betrachtung mitaufgenommen (vgl. Abschnitt 4.10). Es wurde darauf geachtet, dass offizielle Quellen verfügbar sind, die durch eigene Beobachtungen gestützt werden können. Verfahren mit wissenschaftlichem Informationsmaterial oder ausführbaren Applikationen wurden bevorzugt ausgewählt. Smartphone basierend. Es werden nur Systeme einbezogen, die auf modernen Smartphones lauffähig 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 früh in der Entwicklung mobiler Telefone begonnen (vgl. Fenner [1992]). Zu den Zielen dieser Arbeit gehört aber unter anderem die Verwendung moderner Technologien, wie sie erst mit neuesten Smartphones möglich

© Stefan Gfrörer

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 auflösenden Kameras in Verbindung mit Barcodes stellt ein modernes System dar (vgl. Abschnitt 3.1). Dies schließt insbesondere ältere Verfahren, welche SMS Nachrichten zur Datenübertragung verwenden, aus. Stattdessen sind internetbasierte Dienste erwünscht. P2P Payment. Das grundlegende Ziel für eKaayCash ist die Entwicklung eines Peer-to-Peer Payment Systems. Zu vergleichende Fremdsysteme sollten entsprechend über die Möglichkeit, oder zumindest über die nötige technische Basis für eine zukünftige Implementierung verfügen. Besonders die Kriterien Verfügbarkeit und Aktuelle Technologie führen zu einer starken Einschränkung der verfügbaren 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 mögliche Punkte gesucht, welche in mobilen Bezahlsystemen angegriffen werden können. Diese müssen nicht in jedem der vorgestellten Systeme vorkommen. Besonders Verfahren mit Peer-to-Peer Funktionalität bieten Angreifern mehr Angriffspunkte als zum Beispiel ein E-Wallet System. Viele der Angriffe sind jedoch aufgrund der gemeinsamen Plattform und geteilter Kommunikationswege in jeder mobilen Bezahllösung zumindest theoretisch möglich. Anschließend kann mit Hilfe der gefundenen Angriffsvektoren 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 ausschließlich die Bezahlabläufe betrachtet und theoretische Überlegungen zu kritischen Punkten angestellt.

30

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen
Die Untersuchung eines einzelnen Verfahrens läuft wie folgt ab. 1. Zunächst wird das Bezahlsystem allgemein vorgestellt. Ein Bezahlvorgang wird aus Sicht der Benutzer erläutert und beschrieben. 2. Im zweiten Abschnitt erfolgt eine technische Beschreibung aller für die Sicherheitsanalyse relevanten Punkte. 3. Im Anschluss wird kurz auf marktwirtschaftliche Aspekte eingegangen. Insbesondere werden Benutzerfreundlichkeit und mögliche Akzeptanz durch Benutzer hervorgehoben. 4. In der eigentlichen Sicherheitsanalyse werden die allgemeinen Angriffspunkte auf die Abläufe und auf die verwendeten Techniken im Bezahlsystem angewandt und erläutert. 5. Die einzelnen Angriffspunkte werden – gekürzt zu Ax, wobei x für eine Zahl steht – durchnummeriert. Im jeweiligen Fazit eines Verfahrens wird zusammengefasst, welche Angriffe unter welchen Bedingungen möglich sind.

4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen
In einem mobilen System, welches mit anderen Systemen kommuniziert, existieren folgende beiden Arten von Angriffen: • Informationsdiebstahl • Manipulation von Informationen Beide Angriffsformen können jeweils auf dem mobilen Gerät und auf dem Kommunikationskanal erfolgen. Daraus ergeben sich für einen Angreifer insgesamt vier Möglichkeiten. Diese können mit verschiedenen Mitteln realisiert werden, welche im Folgenden betrachtet werden. Die einzelnen Angriffsmöglichkeiten können dann bei der Untersuchung der mobilen Bezahlverfahren auf ihre Anwendbarkeit überprüft werden. Dies schließt eine Untersuchung von denkbaren oder bereits vorhandenen Gegenmaßnahmen mit ein. Des Weiteren wird auf die Gefahr eines physikalische Zugriffs auf das Gerät und auf die Gefahr des Social Engineering eingegangen. A1: Informationsdiebstahl durch Schadprogramme. Bereits 2010 wurde auf Kaspersky Lab [2010] der erste Trojaner für Android basierte Smartphones gemeldet. Da moderne Betriebssysteme für mobile Endgeräte einen ähnlichen Funktionsumfang haben wie Desktop- und Serversysteme (vgl. Google [2012b]) und ihre Verbreitung stark zugenommen hat, steigt die Attraktivität für Entwickler von Schadsoftware. Informationsdiebstahl ist dabei die einfachste Variante.

© Stefan Gfrörer

31

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
Besonders die Finanzwelt muss sich gegen die Entwendung von kritischen Daten wehren. Sowohl in der Vergangenheit als auch in der Gegenwart betrifft das hauptsächlich Kreditkarten- und Kontoinformationen. Mit mobilen Lösungen kommen weitere Angriffspunkte hinzu. Die unterschiedlichen Verfahren bieten eine Vielzahl an potentiell interessanten Daten. Dazu gehören Zugangsdaten zu Diensten und Informationen, welche Rückschlüsse auf das Kaufverhalten des Benutzers zulassen. Sicherheitslücken, welche den Zugriff auf Informationen dieser Art erlauben, wurden bereits unter Viaforensics [2011] für Google wallet veröffentlicht. Andere mobile Verfahren können ebenso gefährdet sein. Zusätzlich besteht die Gefahr, dass Schadprogramme kritische Daten wie eine PIN während der Eingabe abhören und sie anschließend ohne das Wissen des Benutzers einsetzen. Einen Schutz vor Angriff dieser Art bietet die sichere Verschlüsselung der gefährdeten Daten. Dabei darf der verwendete Schlüssel nicht selbst auf dem Endgerät gespeichert werden. Dieses Problem kann mit einer sogenannte AppPIN gelöst werden. Diese PIN muss beim Zugriff 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 unterstützt. Systeme wie Android isolieren alle Apps voneinander (vgl. Abschnitt 2.3). Diese Maßnahme kann jedoch aufgrund von Sicherheitslücken umgangen werden. Aus diesem Grund sollten Entwickler weitere Mechanismen wie die oben erwähnte Verschlüsselung implementieren. Es bleibt also festzuhalten, dass sensible Daten von mobilen Plattformen gestohlen werden können. A2: Manipulation durch Schadprogramme. Neben dem Diebstahl von Informationen können Schadprogramme Daten manipulieren. Während einer finanziellen Transaktion werden unabhängig vom tatsächlichen Verfahren bestimmte Informationen immer wieder verwendet. Zumindest der Empfänger, der Zahlende und der Betrag müssen bekannt sein. Je nach Bezahlsystem können noch weitere Daten hinzukommen. Ein Schadprogramm kann hier einzelne Informationen auszutauschen. Als einfaches Beispiel bietet sich die Manipulation des Empfängers einer Geldsumme an. Wenn diese Änderung unbemerkt vom Benutzer geschieht und im kompletten Verfahren keine Absicherung existiert, kann auf diese Weise der Geldfluss 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 Gfrörer

Peer-to-Peer Payment via NFC 4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen
Benutzer bestätigen zu lassen. Abhängig von der Variante des eingesetzten Schutzes kann ein Schadprogramm an dieser Stelle – wie im vorherigen Punkt beschrieben – einen Informationsdiebstahl durchführen 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 ungültig und kann somit erkannt werden (vgl. Gupta u. a. [2005]). Fortgeschrittene TAN Verfahren basieren bereits auf dieser Idee und bieten auf diese Weise einen höheren Schutz (vgl. Baden-Württembergische Bank [2006]). Daraus kann gefolgert werden, dass Datenmanipulation ein einfacher Weg für Angreifer ist, um vollständige Transaktionen zu erzeugen und dass eine Absicherung über dynamische Schutzmechanismen unerlässlich ist. A3: Abhören der Kommunikationsverbindung. Informationen können nicht nur direkt auf dem Smartphone gesammelt werden, sondern auch während der aktiven Datenübertragung zwischen einem Server und dem Client abgehört werden. Moderne Smartphones verfügen über verschiedene Kommunikationssysteme. Für die vorliegende Arbeit sind kabellose Netzwerke mit Anbindung an das Internet von Interesse. Dazu gehören vorwiegend moderne Mobilfunkstandards wie Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS) und Long Term Evolution (LTE). Aktuelle Smartphones unterstützen zumindest eine Auswahl dieser Standards für mobile Internetverbindungen. Um Kosten zu sparen greifen viele Anwender außerdem auf ein verfügbares drahtloses lokales Netzwerk (WLAN) zurück. Als lokale Kommunikationsschnittstelle zwischen mobilen Endgeräten kommt zudem häufig der Bluetooth Standard zum Einsatz (vgl. Pehl [2004]). Angriffe auf eine Kommunikationsverbindung werden mittels eines Man-in-the-Middle (MITM) ausgeführt. Dabei versucht ein Angreifer den Kommunikationskanal zwischen zwei Parteien aufzuteilen und sich selbst an dieser Stelle einzufügen. Er kann anschließend den Kommunikationsfluss steuern, übertragene Daten lesen und sie nach eigenem Ermessen weiterleiten. Für den Informationsdiebstahl ist nur das Abhören der übertragenen Daten relevant. Eine Darstellung dieser Situation findet sich in Abbildung 4.1. Neben dieser aktiven Variante besteht auch die Möglichkeit eines passiven Lauschangriffs. Dies ist besonders bei nicht geschützten Kommunikationskanä-

© Stefan Gfrörer

33

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme

Alice (Client)

Mallory (aktiver Angreifer) Bob (Server)

Abbildung 4.1.: Erfolgreicher Man-in-the-Middle Angriff auf eine Server-Client Verbindung. Der Angreifer Mallory kann den Kommunikationsfluss zwischen Alice und Bob vollständig kontrollieren (eigene Darstellung). len möglich. Dazu gehören ungesicherte WLAN Verbindungen (vgl. Abbildung 4.2).

Alice (Client)

Bob (Server)

Eve (passiver Angreifer)

Abbildung 4.2.: Der Angreifer Eve hat zwar keinen direkten Einfluss auf den Kommunikationskanal, kann aber die Verbindung zwischen Alice und Bob unbemerkt belauschen (eigene Darstellung). Zur Durchführung von Angriffen dieser Art gibt es eine Reihe allgemeiner Techniken wie das Vortäuschen eines WLAN Access Point, DNS Cache Poisoning (vgl. Son u. Shmatikov) oder ARP Spoofing (vgl. Eriksson u. Johansson [2007]). In der Arbeit von Eriksson u. Johansson [2007] wird zudem die Angreifbarkeit von verschlüsselten Verbindungen demonstriert. Des Weiteren gibt es eine Reihe von erfolgreichen MITM Angriffen auf bekannte Mobilfunkstandards. Mun u. a. [2009] zeigen in ihrer Analyse, dass die mögliche Zusammenarbeit von UMTS- und WLAN-Netzen einen Angriffspunkt bietet. Dieser Befund wird von Zhang u. a. [2010] bestätigt. Sie schleusten erfolgreich ein Programm zum Belauschen der Kommunikationsverbindungen in die für die Zusammenarbeit verantwortliche Middleware ein (ebd.). Eine größere Gefahr besteht für Schnittstellen zwischen Global System for Mobile Communications (GSM) und UMTS-Netzwerken (vgl. Meyer u. Wetze [2004]). Da GSM eine nur schwache Verschlüsselung aufweist, kann diese besonders leicht angegriffen werden. Gleichzeitig bildet dieses System nach wie vor die Grundlage der meisten Mobilfunknetze (ebd.).

34

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen
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 zusätzlichen symmetrischen oder asymmetrischen Verschlüsslung der Daten sein. Die PIN kann im Fall der symmetrischen Verschlüsselung das geteilte Geheimnis darstellen. Dieser Angriffspunkt zeigt zusammengefasst die Bedeutung des Kommunikationskanals für den Angreifer und dem zufolge auch für den Entwickler einer Anwendung mit kritischen Daten. Durch die physische Trennung von mobilem Endgerät und Übertragungsweg müssen die übertragenen Daten vor unerwünschtem Einblick geschützt werden. A4: Manipulation von Daten während der Kommunikationsverbindung. Wie im vorherigen Abschnitt bereits beschrieben, existieren aktive und passive Angriffe auf den Kommunikationskanal. Während der passive nur für reine Lauschangriffe geeignet ist, bietet ein aktiver MITM Angriff weitaus mehr Möglichkeiten. Der Angreifer kontrolliert, wie in Abbildung 4.1 dargestellt, den kompletten Kommunikationsfluss. Dies ermöglicht nicht nur einen Einblick in die übertragenen Informationen, sondern lässt auch die Veränderung aller Daten zu. Damit erhält ein Angreifer die gleichen Fähigkeiten wie ein aktives Schadprogramm, welches Manipulationen durchführt. Wenn der Inhalt nicht geschützt ist oder der Schutz – in Form einer Prüfnummer – nicht von den zu schützenden Informationen abhängt, kann ein solcher Angriff erfolgreich sein. Ältere, statische TAN-Verfahren verfügen ü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 außer einer vom Inhalt unabhängigen TAN keinen weiteren Schutz aufweist (eigene Darstellung). Wie bereits bei Schadprogrammen, lässt sich auch die Manipulation im Kommunikationskanal durch kryptographische Signaturen aufdecken und somit verhindern.

© Stefan Gfrörer

35

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
A5: Physischer Zugriff auf das mobile Endgerät. Neben indirekten Zugriffen auf das Smartphone über Schadprogramme usw. ist für Menschen auch der direkte Zugriff möglich, wenn sie in dessen physische Nähe gelangen. Neben den für den Besitzer erkennbaren potentiellen Fremdzugriffen im Fall eines Verlustes oder Diebstahls des Geräts kann eine unbefugte Person bereits in kurzer Abwesenheit des Besitzers Schaden auf einem Smartphone anrichten. Abhängig von der Dauer des Zugriffs hat der Angreifer verschiedene Möglichkeiten. Er kann in aktiven Applikationen Befehle ausführen oder an geringfügig geschützten Stellen nach Informationen suchen. Sein Handeln ähnelt damit dem eines Schadprogramms. Sofern eine Transaktion nicht durch eine PIN geschützt ist, ist eine Transaktion in einer Finanz-Applikation möglich oder es kann beispielsweise der Browserverlauf durchsucht werden. Diese Informationen können teils direkt Schaden verursachen (vgl. Viaforensics [2011]), teils können sie zur Vorbereitung weiterer Angriffe verwenden werden. Bei einem längeren Zugriff kann ein Angreifer nach tiefer gehenden Informationen suchen. Viaforensics [2011] hat gezeigt, dass sich dabei wichtige Daten finden lassen. Mit entsprechenden Kenntnissen kann ein Angreifer auch versuchen den Schutz verschiedener Systeme anzugreifen. Die Offenlegung der PIN und ähnlicher Geheimnisse ist dabei ein wesentlicher Gefahrenpunkt. Apps können als Schutz für kritische Befehle die Verwendung einer PIN oder Ähnlichem verwenden. Informationen sollten wie beim Schutz vor Trojanern verschlüsselt abgelegt werden. Zum Schutz vor Verlust oder Diebstahl des Smartphones sollte die entfernte Sperrung oder Deaktivierung des Geräts und wichtiger Apps bzw. hinterlegter Benutzerkonten möglich sein. Bei einer entfernten Sperrung kann ein mobiles Endgerät oder eine einzelne Applikation ohne physikalischen Kontakt vom Dienstanbieter deaktiviert werden. Es bleibt festzuhalten, dass insbesondere Informationsdiebstahl von Menschen direkt auf dem Endgerät durchgeführt werden kann und dass dieselben Schutzmechanimen wie gegen Schadprogramme gelten müssen. A6: Social Engineering. Durch das verstärkte Aufkommen internetbasierter Dienste mit persönlichen Benutzerkonten wurden gleichzeitig Angriffe entwickelt, um Kontrolle über diese zu erhalten. Es werden nicht nur technische Sicherheitslücken 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 Spoffing auf eine gefälschte Seite gelockt. Diese Seite gleicht in den meisten Fällen der echten Seite des Dienstes. Sie fordert den Be-

36

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen
nutzer aus unterschiedlichen Gründen zur Eingabe sicherheitsrelevanter Daten wie Benutzername und Passwort auf. Erkennt das Opfer die gefälschte Seite nicht und gibt seine Daten ein, erhält der Angreifer Zugriff auf das Benutzerkonto des Opfers (ebd.). Auf diese Weise lassen sich auch statische TANs erschleichen. Die Sicherheitsmechanismen der meisten mobilen Apps sind ihren Webäquivalenten ähnlich oder gar identisch. So werden in vielen Fällen dieselben Anmeldeinformationen verwendet. Aus diesem Grund sind auch dieselben Social Engineering Angriffe möglich. Onlinebanking Dienste schützen sich vor Phishing und Pharming mittels moderner TAN Verfahren, welche die TAN dynamisch für die jeweilige Transaktion berechnen (vgl. Baden-Württembergische Bank [2006]). In mobilen Anwendungen kann man den Zugriff auf den Dienst einschränken 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 Angriff Entwickler von sicheren Anwendungen vor besondere Herausforderungen stellt und diese explizit behandelt werden müssen. A7: Abhören der NFC-Verbindung. Near Field Communication ist zunächst ein kabelloses Kommunikationsmedium. Es ähnelt insofern Verbindungen via WLAN und erlaubt ähnliche Angriffe. Aufgrund seiner sehr geringen, effektiven Sendereichweite von zwanzig Zentimetern und Besonderheiten in der Architektur werden tatsächliche Angriffe hingegen deutlich erschwert. NFC verwendet zur Darstellung einzelner Bits eine modifizierte 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 Angriff unmöglich. Diese Problematik für einen Angreifer wird ausführlich von Haselsteiner u. Breitfuß [2006] beschrieben. Während eine aktive Manipulation nicht möglich ist, kann ein Angreifer jeodch immer noch passiv den Datenverkehr abhören. Wie Eingangs beschrieben, haben die meisten NFC-fähigen Endgeräte eine maximale Reichweite von zwanzig Zentimetern. Haselsteiner u. Breitfuß [2006] gehen allerdings davon aus, dass aktive Empfangsgeräte bei idealen Bedingungen Daten in bis zu zehn Metern Entfernung erfassen können. In einem einfachen Aufbau wird von Kortvedt u. Mjølsnes [2009] in einem durchschnittlichen Abstand von zwanzig Zentimetern die komplette Kommunikation zwischen einem Tag und einem NFC-fähigen Handy mitgelesen. Bereits

© Stefan Gfrörer

37

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
dieser Abstand genügt um beispielsweise in der Nähe eines NFC Terminals eine Sonde anzubringen. Wie bei Angriff A1 erklärt, bietet nur eine verschlüsselte Übertragung Schutz vor Laufangriffen. Aufgrund des technisch bedingten Schutzes vor Manipulation ist die Entwicklung eines sicheren Übertragungsprotokolls für Near Field Communication sehr einfach. Ein solches Protokoll wird in der Arbeit von Van Damme u. a. [2005] vorgestellt. Zu den Schwierigkeiten der Implementierung gehören Limitierungen der verwendeten Java Umgebung und die zum Zeitpunkt der Arbeit geringe Rechenleistung von mobilen Endgeräten (ebd.). Diese Schwierigkeiten lassen sich mittels modernen mobilen Betriebssystemen und der deutlich höheren Rechenleistung aktueller Smartphones lösen. Nahfunk ist aus den beschriebenen Gründen ein sicheres Kommunikationsmedium und bedarf nur geringer zusätzlicher Absicherung durch den Entwickler. Eine weitere Angriffsmöglichkeit ist das externe Beobachten des Bildschirms durch Drittpersonen oder entsprechendes Überwachungsequipment. Aufgrund der grundsätzlichen Notwendigkeit von Benutzereingaben bestehen für Entwickler jedoch nur geringe Schutzmöglichkeiten. Wie bei der klassischen PIN Eingabe am Geldautomaten liegt die Verantwortlichkeit hier beim Benutzer. Aus diesem Grund wird diese Art von Angriff bei der Untersuchung ausgeschlossen. Ebenfalls werden Angriffe auf die Infrastruktur in Form von Servern und Ahnlichem außer 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. Angriffe dieser Art können in zwei Formen auftreten. Einerseits können direkt falsche Angaben gemacht werden. Dazu gehört beispielsweise ein zu hoher Betrag. Die Verantwortung liegt hier ebenfalls bei den Benutzern und der manuellen Überprüfung der Transaktion. Des Weiteren kann eine der Parteien versuchen, manipulierend auf die Geldüberweisung einzuwirken. Diese Art von Angriff ist aber nur mit bereits beschriebenen Mechanismen wie Schadprogrammen möglich und wurde somit bereits erläutert. Alle Angriffsmöglichkeiten werden in Tabelle 4.1 noch einmal zusammengefasst. Bei der Vorstellung der einzelnen Angriffsmethoden wurden ausschließlich spezialisierte Schutzmechanismen erwähnt. 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). Unabhängig vom technischen Standpunkt existiert auch der Faktor Gewinn. Angreifer zielen mit ihren Aktionen in vielen Fällen auf einen monetären Gewinn ab. Dieser Gewinn muss in

38

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.2. Mögliche Angriffspunkte in Mobile Payment Lösungen

Name A1: Informationsdiebstahl durch Schadprogramme. A2: Manipulation durch Schadprogramme.

Beschreibung Ein Trojaner auf dem mobilen Endgerät kann theoretisch alle Daten abhören und auslesen. Daten können von Schadprogrammen aktiv geändert werden. Mittels aktivem oder passivem Eingriff in einen Kommunikationskanal ist das Abhören aller Informationen möglich. Aktiver Eingriff – sogenannter Man-in-the-Middle – ermöglicht die Manipulation von Daten auf dem Kommunikationskanal. Informationsdiebstahl und Nutzung aktiver Applikationen; bei längerem Zugriff sind tiefergehende Untersuchungen und zeitaufwendige Angriffe möglich. Durch einfache und in der Vergangenheit häufig erfolgreiches Phishing und Pharming, erhält ein Angreifer leicht Zugang zu kritischen Daten wie Passwörtern. Versteckte Sonden können auf bestimmte Entfernungen einzelne NFC Verbindungen abhören.

A3: Abhören der Kommunikationsverbindung.

Schutz Verschlüsselung mit externem Geheimnis und Prozessisolierung durch Betriebssystem. Kryptographische Signatur für kritische Informationen und Prozessisolierung durch Betriebssystem. Verschlüsselung der Daten und sichere Verbindung mittels SSL oder TLS.

A4: Manipulation von Daten während der Kommunikationsverbindung.

Kryptographische Signaturen und sichere Verbindungen mittels SSL oder TLS.

A5: Physischer Zugriff auf das mobile Endgerät.

A6: Social Engineering.

A7: Abhören der NFCVerbindung.

Verschlüsselung von Daten. Kritische Befehle mittels PIN absichern. Entfernte Deaktivierung von Applikationen, Benutzerkonten und Smartphone. Nur registrierte Endgeräte für einen Dienst erlauben. Befehle mittels dynamischer, von Eingabedaten abhängigen Transaktionsnummern absichern. Verschlüsselung der Daten und die Verwendung von sicheren Verbindungen.

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

© Stefan Gfrörer

39

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
einem positiven Verhältnis zum nötigen Aufwand stehen. Entwickler und Betreiber mobiler Bezahlsysteme können dieses Verhältnis auf zwei Wegen beeinflussen. Die Verwendung sicherer Techniken und Algorithmen erhöht den Aufwand und somit die Kosten für den Angreifer. Gleichzeitig kann der finanzielle Gewinn verringert werden. Viele Bezahlsysteme sind nur für geringe Beträge freigegeben. Ein Angreifer hat somit keine Möglichkeit, durch einen einzelnen Angriff einen größeren Gewinn zu erhalten. Multiple Angriffe auf verschiedene Benutzer erhöhen aber gleichzeitig den Aufwand und die Gefahr einer Entdeckung. Die Handlung wird für den Angreifer also unattraktiv. Da die Limitierungen auf Kleinstbeträge durch den jeweiligen Dienstanbieter festgelegt werden muss und unabhängig von der Technik ist, wird dies in die folgende Analyse der einzelnen Bezahlsysteme nicht miteinbezogen. Zusätzlich bilden viele Verfahren in sich abgeschlossene Systeme, die ein Aufladen des Kontos mit Geld durch ein externes Finanzinstitut voraussetzen. Gestohlene Beträge müssen denselben Ablauf in umgekehrter Reihenfolge durchlaufen. Ein Angriff 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 für Online Shop Systeme auf ihre Sicherheit untersucht.

4.3.1. Sicherheitsanalyse
4.3.1.1. eKaayCash Die grundlegenden Sicherheitsmechanismen für eKaayCash werden vom eKaay Verfahren geliefert. In Abschnitt 2.1 wurde bereits auf das Ergebnis der Sicherheitsanalyse von Günther [2011] verwiesen. Es wurde eine Reihe von Problemen aufgedeckt, welche zeigen, dass ein Schadprogramm unter bestimmten Bedingungen kritische Operationen ausführen kann. Beispielsweise kann ein Schadprogamm das Geheimnis eines Benutzers auslesen und damit beliebige Transaktionen signieren. Diese Sicherheitslücken gelten auch für eKaayCash. Allerdings bietet eKaay zusätzliche Mechanismen, welche vor den beschriebenen Angriffen schützen. Dazu gehören eKaay PIN und eKaayCard. Beide Verfahren können 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 Ausfüllen des Überweisungsformulars die darin enthaltenen Daten an den Server übertragen. Ein Schadprogramm auf dem

40

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.3. eKaayCash
Smartphone des Geldempfängers kann die übertragenen Daten manipulieren und beispielsweise die ID des Empfängers gegen die eines Angreifers austauschen. Auch ein MITM Angriff auf den Übertragungskanal kann zu diesem Ergebnis führen. Ein ähnlicher Angriff ist auf den generierten QR Code bzw. NFC Link möglich, welche jeweils ein Containerformat für die eigentlichen Daten darstellen (vgl. Abschnitt 3.3.2). Zwar bietet die Manipulation beider Container keinen Vorteil (vgl. Abschnitt 2.1), jedoch ist ein Austausch durch ein Schadprogramm möglich. Sowohl das Smartphone des Geldempfängers als auch das des Zahlenden verfügen im Regelfall über eine Internetverbindung, da diese für die Verwendung von eKaayCash wichtig ist. Entsprechend kann ein Schadprogramm eine eigene Transaktion initiieren und den QR Code sowie den NFC Link ersetzen. Dieser Angriff ist direkt vor der P2P Verbindung zwischen beiden Smartphones möglich, 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 Absätzen beschriebenen Angriffe zielen auf den Austausch einer Transaktion ab. Die Transaktion des Benutzers soll gegen eine weitere Transaktion des Angreifers ausgetauscht werden. Während die Durchführung durch Schadprogramme von eKaayCash nicht verhindert werden kann, wird zumindest ein Manin-the-Middle auf die Kommunikation zwischen Server und Geldempfänger aufgrund der Verwendung von verschlüsselten Verbindungen erschwert. Der eigentliche Schutz findet aber in Form der Überprüfung durch den Zahlenden statt. Eine Transaktion wird erst abgeschlossen, wenn sie vom Zahlenden bestätigt wurde. Dieser muss sowohl die ID des Geldempfängers 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 bestätigen
Datum: 20.4.2012 Uhrzeit: 10:00:00 Empfaenger: Mallory Betrag: 100.00 Euro

abbrechen

OK

Abbildung 4.4.: Der Bestätigungsdialog von eKaay für eine Transaktion (eigene Darstellung). Die P2P Übertragung zwischen beiden Smartphones bietet keine Angriffsmöglichkeiten. Sowohl der QR Code als auch die NFC Verbindung erlauben nur das Abhören

© Stefan Gfrörer

41

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
der Daten, welche nicht geheim bleiben müssen (vgl. Abschnitt 2.1 und Abschnitt 2.2). Durch physischen Zugriff hat ein Angreifer die Möglichkeit eine Überweisung durchzuführen. Dieser Gefahr kann durch Schutz des Benutzerkontos mit einer PIN und der eKaay PIN für die Bestätigung der Transaktion begegnet werden (vgl. Abschnitt 2.1). Da für das P2P Verfahren keine unsichere Eingabe von kritischen Daten benötigt wird, ist ein Angriff mittels Social Engineering nicht möglich.

4.3.1.2. Erweiterung für Online Shop Systeme Die Erweiterung erlaubt prinzipiell dieselben Angriffe wie eKaayCash selbst. Allerdings sind darüber hinaus noch weitere Angriffspunkte vorhanden. Der Kauf und die gleichzeitige Bezahlung werden durch das Einlesen des QR Codes mit der eKaay App durchgeführt. Ein Schadprogramm auf dem Computer des Kunden kann diesen QR Code gegen einen eigenen austauschen und auf diese Weise die Bestätigung einer einer gefälschten Überweisung erreichen. Es gelten jedoch dieselben Einschränkungen wie im vorherigen Abschnitt. Wenn der Kunde die Überweisung prüft und nicht bestätigt wird der Angriff abgewehrt. Neben Schadprogrammen können auch Angriffe auf die Webseite beziehungsweise den Server des Shops zum Austausch des QR Codes führen. Zu Angriffen dieser Art zählt unter anderem Cross-Site-Scripting (vgl. Grossman u. a. [2007]). Bei korrekter Implementierung der Schnittstellen hingegen ist ein Shop gegen eine gefälschte Transaktionsbestätigung abgesichert. Beliebige Benutzer können zwar eine Bestätigung an den Server versenden, diese wird jedoch nicht akzeptiert, da die Verifizierung durch den Server von eKaayCash fehlschlägt (vgl. Abbildung 4.5).

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

42

© Stefan Gfrörer

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 ungültig Server des Shops Server der Bank

Abbildung 4.5.: Versuch eines Angreifers einem Shop eine Transaktion vorzutäuschen (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 für verschiedene, meist internetbasierte Dienste. Die Konto- und Bezahlfunktionalität ist komplett Webbasiert (vgl. PayPal [2012a]). Inzwischen ermöglicht PayPal auch einen direkten Zugang für mobile Endgeräte in Form von speziellen Apps. Wie von PayPal [2012b] beschrieben, müssen Benutzer ein unterstütztes Handy zunächst für den Service aktivieren – dadurch wird eine Bindung des Smartphones an ein bestimmtes Konto ermöglicht – und können dann über eine spezielle App klassische Bezahlvorgänge vornehmen. Diese Apps sprechen dabei nur das bekannte Webinterface an und fügen keine weitere Funktionalität hinzu. Da gerade bei mobilen Geräten die Gefahr besteht, dass das Gerät entweder verloren geht oder gestohlen wird, müssen alle Transaktionen mit Hilfe einer PIN bestätigt werden (ebd.). In dieser Hinsicht erfüllt PayPal Mobile Payments die in Abschnitt 4.1 beschriebenen Kriterien noch nicht. Möglich wird dies erst durch folgende Änderungen. Am 13. Juli 2011 wurde für Android basierte Smartphones eine neue Version der App von Hardawar [2011] angekündigt. Sie wurde am 8. November 2011 von Samuel [2011] als Version 3 veröffentlicht. NFC-fähige Geräte erhalten nach einem Update die Fähigkeit Peer-to-Peer Transaktionen durchzuführen. Das Ziel des Unternehmens ist die Vereinfachung einer Überweisung zwischen zwei Personen. Dies wird unter anderem

© Stefan Gfrörer

43

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
dadurch erreicht, dass ein Aufruf der eigentlichen App nicht mehr nötig ist. Stattdessen erhält 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 für europäische Benutzer noch nicht zur Verfügung, sondern ist nur in den USA einsetzbar. Die vorhandenen Informationen genügen jedoch, um den Ablauf einer Transaktion zu bestimmen. Die folgende Beschreibung stützt sich auf Angaben aus der Pressemitteilung von PayPal (vgl. Hardawar [2011]). Sie ist aus Sicht der Benutzer, d. h. des Geldempfängers und des Zahlenden, beschrieben. 1. Im ersten Schritt gibt der Geldempfänger den gewünschten Betrag in das Widget ein. 2. Nach Bestätigung der Eingabe erhält er die Aufforderung sein eigenes Smartphone an das des Zahlenden zu halten. 3. Beide Benutzer müssen nun einen Moment warten, während der Datenaustausch via NFC zwischen beiden Smartphones statt findet. 4. Beide Handys bestätigen den Erfolg der Datenübertragung mit einem – von PayPal „Buzz“ getauften – Vibrationsalarm.

44

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.4. PayPal Mobile Payments
5. Für den Geldempfänger ist zu diesem Zeitpunkt die aktive Handlung abgeschlossen. Er wird nach Bestätigung durch den Zahlenden mit einer E-Mail über den erfolgreichen Abschluss der Transaktion informiert. 6. Der Zahlende muss die Überweisung mit Eingabe seiner PIN bestätigen oder kann den gesamten Vorgang abbrechen. 7. Die App baut eine Verbindung zum Server auf und überträgt die Transaktionsdaten. Der Server führt dann die eigentliche Geldüberweisung durch und sendet eine Bestätigungsmail an den Geldempfänger. 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) Geldempfänger 1. Eingabe Zahlender 3. Bestätigung

5. Verifikation und Geldüberweisung

4. Bestätigte Zahlungsanfrage (Internet)

Zahlungsserver

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

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

© Stefan Gfrörer

45

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
nachvollziehen (vgl. PayPal [2011a]). Eine genauere Untersuchung wird möglich sein, sobald das Verfahren in Europa zur Verfügung steht. 1. Nach der Eingabe des Betrags durch den Geldempfänger ergeben sich zwei Möglichkeiten für die Weiterverarbeitung der Daten (Name des Geldempfängers 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 erhält 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 stattfindet. Das lässt sich vermuten, da die App keine Aufforderung zum Warten anzeigt und der Vorgang verzögerungsfrei 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 verschlüsselt wird, ist nicht bekannt. 3. Die aktiven Schritte des Zahlenden werden lokal auf dessen Smartphone im Rahmen der App ausgeführt. Erst mit der Übertragung der abgeschlossenen Transaktion zum Server findet der letzte, technisch interessante Vorgang statt. Da die P2P Funktionalität eine Erweiterung der bestehenden PayPal Mobile Payments App darstellt, ist anzunehmen, dass dabei die gleichen Sicherheitsmechanismen zum Einsatz kommen. Dazu gehört als wichtigsten Punkt eine verschlüsselte Ü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
Gegenüber anderen Anbietern, welche den mobilen Markt für Bezahlsysteme im Zuge neuer Technologien entdecken, hat PayPal dank seines bereits existierenden mobilen Bezahlsystems für Smartphones auf Basis von Android, iOS oder BlackBerry einen Vorteil in der Verbreitung (vgl. PayPal [2012b]). Für Android, welches Near Field Communication unterstützt, erschien die Erweiterung der App als einfaches Update. Die Verbreitung wird theoretisch nur durch das Vorhandensein von NFC-fähigen Smartphones eingeschränkt. Zusätzlich wirkt als künstliche Grenze die vorläufige Einschränkung auf die USA für das Peer-to-Peer System. Ein erster Test in Schweden, welcher von Rao [2011] vorgestellt wurde, zeigt, dass eine uneingeschränkte Nutzung in anderen Ländern geplant ist. Der schwedische Versuch weist außerdem auf eine potentielle Ausweitung des Systems hin. Wie eKaayCash soll das NFC-System in Zukunft für die Bezahlung in reellen Geschäften verfügbar werden.

46

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.4. PayPal Mobile Payments
Dabei werden – wie in Abbildung 4.8 gezeigt – NFC-fähige Terminals zum Einsatz kommen (ebd.).

Abbildung 4.8.: Bezahlung an einem NFC-fähigen Terminal mit PayPal Mobile Payments (Quelle: PayPal [2011b]). Das P2P Verfahren selbst ist sowohl für den Geldempfänger, als auch für den Zahlenden einfach zu bedienen. Die Handhabung entspricht in großen 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 entfällt eine mögliche Misstrauensquelle gegenüber dem Verfahren. Eine Studie von „Ogilvy & Mather“, veröffentlicht von Patel [2011], zeigt zudem, dass PayPal ein ähnlich hohes Vertrauen bei seinen Kunden genießt wie MasterCard und American Express.

4.4.4. Sicherheitsanalyse
Der erste Angriff ist im Zeitraum zwischen der Eingabe des Betrags durch den Geldempfänger und der Anzeige der Bestätigung auf dem Smartphone des Zahlenden möglich. Dabei kann entweder ein Schadprogramm auf einem der beiden Smartphones zum Einsatz kommen oder ein Lauschangriff auf die NFC-Verbindung erfolgen. Bei letzterem können, soweit bekannt, der Geldbetrag und der Identifikator des Empfängers abgehört werden. Diese Daten sind nur von begrenzter Relevanz. Ob die Verbindung verschlüsselt 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 großen Gefahr der Erkennung durch den Zahlenden verbunden ist. Eine Änderung der ID kann aber – trotz Kontrolle durch den Zahlenden während der Bestätigung – in vielen Fällen unerkannt bleiben, da die ID nicht sprechend sein muss. In Abbildung 4.9 ist dieser Angreif beispielhaft dargestellt.

© Stefan Gfrörer

47

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
Der Schutz durch eine Signatur hilft begrenzt. Ein Schadprogramm auf dem Smartphone des Geldempfängers kann das Geheimnis der Signatur theoretisch auslesen und eine gültige 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 Prüfung der ID eingreifen und den Vorgang gegebenenfalls abbrechen.
Übertragen: 10 Euro an Mallory Alice (Geldempfänger) Eingabe: 10 Euro Empfänger: Alice Bob (Zahlender)

Mallory (Angreifer)

Abbildung 4.9.: Gemäß A2 kann ein Schadprogramm auf dem Smartphone des Geldempfängers die Transaktionsdaten vor der Übertragung manipulieren (eigene Darstellung). Beginnend mit der Anzeige des Betrags und des Geldempfängers bis zur Ankunft aller Daten am Server bietet sich dem Angreifer die zweite Möglichkeit für einen Angriff auf das Peer-to-Peer Bezahlsystem. Es ist anzunehmen, dass die ID des Geldempfängers, der Betrag und die ID des Zahlenden mit Hilfe der PIN des Zahlenden gesichert werden. Die eigentliche Übertragung auf den Kommunikationskanal erfolgt, wie bereits erwähnt, ü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 für 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 Geldempfänger enthält. PayPal sichert kritische Punkte während der kompletten Transaktion aktiv ab. Dies betrifft insbesondere die Übertragung über den Kanal. Zusätzlich verlässt es sich auf die Sicherheit des Betriebssystems. Sowohl ein Geheimnis zum Schutz vor Datenmanipulation während der Übertragung zwischen Geldempfänger und Zahlenden, als auch die Eingabe der PIN werden durch das Betriebssystem geschützt. Google selbst gibt an, dass dieser Schutz durch Systemlücken, welche Root-Rechte ermöglichen, umgangen werden kann. Ein Bezahlvorgang mit PayPals Peer-to-Peer Variante ist folgerichtig zumindest theoretisch angreifbar.

48

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.5. Google wallet
Ein Konto bei PayPal lässt sich für einen Angreifer ohne technischen Aufwand mittels Social Engineering kompromittieren. Ein Phishingangriff, welcher die Zugangsdaten für das Konto abfragt, genügt bereits, um eine Überweisung durchzuführen. Ein direkter Angriff auf das mobile Bezahlsystem und insbesondere auf die P2P Variante ist nicht nötig. Ein Physikalischer Zugriff auf das Smartphone ist auch bei angemeldetem Benutzerkonto nur geringfügig gefährlich. Ohne PIN können nur bestehende Kontoauszüge abgerufen, jedoch keine Überweisungen getätigt werden.

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

4.5. Google wallet
4.5.1. Beschreibung des Verfahrens
Die Firmen MasterCard und Visa haben unabhängig 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]), während Visa den Standard in payWave umsetzt (vgl. VISA [2012]). Die Karten sind vollkommen kompatibel zu den Spezifikationen für Zahlungskarten von Europay, MasterCard und Visa (EMV). Beide Unternehmen möchten eine Vereinfachung des Bezahlvorgang erreichen. Mittels einer kontaktlosen, auf Radio-Frequency Identification basierten Technologie soll das unnötige Einschieben in ein Lesegerät verhindert werden. Auch müssen Kreditkarten mit dieser Technologie nicht mehr aus der Hand gegeben werden. Ein weiterer Vorteil besteht in der Unabhängigkeit von klassischen Kreditkarten. Der RFID-Chip kann theoretisch in ein beliebiges Trägerelement eingebaut werden (vgl. VISA [2012], MasterCard [2012] und ISO [2000a]). Die Trennung von klassischer Kreditkarte und eigentlichem Chip hat Google in seinem mobilen Bezahlsystem für Smartphones – Google wallet – erreicht. Google wallet

© Stefan Gfrörer

49

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
speichert die für eine Transaktion nötigen Kreditkarten-Daten auf dem Smartphone und ist sowohl mit MasterCard PayPass als auch mit Visa payWave kompatibel. Die notwendigen Kreditkarten-Daten können 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 unterstützt keine Peer-to-Peer Überweisungen zwischen einzelnen Clients. Es sind ausschließlich Transaktionen zu Point of Sale Terminals vorgesehen und möglich (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 möglich sind, allerdings demonstriert Google wallet die Speicherung klassischer Kreditkartendaten auf einem mobilen Endgerät. 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 unterstützen (vgl. Google [2011] und EMVCo [2008]). Er läuft für den Kunden folgendermaßen ab. 1. In der Standardeinstellung muss vor jeder Transaktion die App mittels der PIN freigeschaltet werden. Dieses Verhalten lässt sich dahingehend ändern, dass die PIN nur noch beim ersten Start der App notwendig ist.

50

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.5. Google wallet
2. Der Benutzer hat anschließend Zugriff auf Informationen über vergangene Transaktionen, Gutscheine und weitere Funktionen. Außerdem wird die NFC Antenne für eine einzige Überweisung aktiviert. 3. Wie eine normale Kreditkarte mit NFC muss das Smartphone jetzt an das Terminal gehalten werden. 4. Das Smartphone überträgt via NFC die gespeicherten Kreditkarten Informationen an das Terminal. 5. Der Bezahlvorgang wird im Hintergrund abgeschlossen. Sowohl der Kunde als auch der Händler erhalten eine Bestätigung.

4.5.2. Technische Umsetzung
Für eine gültige Überweisung sind nur wenige Informationen einer Kreditkarte notwendig. In der Regel genügen die Kreditkartennummer und die Kreditkartenprüfnummer. Gegebenenfalls wird auch das Ablaufdatum der Kreditkarte abgefragt. Nur in wenigen Fällen ist eine PIN für den Abschluss der Transaktion notwendig. Bei virtuellen Einkäufen im Internet entfällt sie völlig. Aus diesem Grund ist es um so wichtiger, dass die kritischen Informationen auf einem Smartphone gesichert werden ohne dass ein Angriff möglich 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 eigenständigen und gesicherten Speicher, der unabhängig vom restlichen System ist (vgl. Google [2011] und Mobey Forum Mobile Financial Services Ltd [2010]). Die Kommunikation zwischen Terminal und Kreditkarte, bzw. Smartphone mit Google wallet, findet 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 geschützt. Es dient zur Signierung und damit zur Bestätigung der Überweisung und wird jeweils dynamisch für eine einzelne Transaktion berechnet (vgl. EMVCo [2008]). Near Field Communication kann in drei verschiedenen Modi ausgeführt werden (vgl. Abschnitt 2.2). Es kann als Terminal agieren. In diesem Modus werden RFID-Tags ausgelesen. Zwischen zwei aktiven Geräten ist zudem ein Peer-to-Peer Modus möglich, welcher nach einem Master-Slave-Prinzip funktioniert. Beim dritten Modus –

© Stefan Gfrörer

51

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
der von Google wallet genutzt wird – verhält sich das NFC-fähige Endgerät passiv. In diesem sogenannten Card Emulation Mode wird das Verhalten einer NFC-fähigen 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 Funktionalität und Kompatibilität einer echten kontaktlosen Kreditkarte mit NFC ist auf diese Weise sichergestellt. Aus diesem Grund müssen Terminals von MasterCard und Visa für Google wallet nicht extra angepasst werden (vgl. Google [2011]). Google wallet baut während einer Transaktion keine eigene Kommunikationsverbindung auf. Das Terminal verwaltet die Datenübertragung und übernimmt deren Absicherung gegen unbefugten Zugriff (vgl. EMVCo [2008]).

4.5.3. Verbreitung und Akzeptanz durch Benutzer
Zum Zeitpunkt der Entstehung dieser Arbeit ist Google wallet nur für die Smartphones Nexus S 4G und Galaxy Nexus verfügbar. Das Nexus S 4G ist eine Variante des Nexus S mit integriertem Secure Element, während das Galaxy Nexus direkt über ein SE verfügt. Dies schränkt die Verbreitung von Google wallet zunächst ein (vgl. Google [2011]). Nach Kincaid [2011] ist aus diesem Grund die Verwendung von RFID-Tags in Form eines Aufklebers für beliebige Smartphones als Übergangslösung geplant. Ein Aufkleber steht dabei für eine Kreditkarte. Die Absicherung über die PIN entfällt (ebd.). Wie PayPal kann auch Google auf eine bestehende Infrastruktur und Marktverbreitung setzen. Visa und MasterCard sind verantwortlich für die Verbreitung der POS Terminals. Google wallet selbst ist als eine offene Plattform entwickelt worden und ermöglicht 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 dazugehörigen Abrechnungen, sondern ermöglicht auch das Auffinden von unterstützten Geschäften und die Anzeige von Sonderangeboten (vgl. Google [2011]). Gegenüber anderen Anbietern weist Google den Nachteil eines geringeren Vertrauens im Bereich finanzieller Anwendungen auf (vgl. Patel [2011]).

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

52

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.5. Google wallet
wird das Point of Sale Terminal im Sinne einer Gegenstelle wie einem Zahlungsserver betrachten. Während der unverschlüsselten Übertragung zwischen Smartphone und Terminal werden eine Reihe von Kreditkarten- und Transaktionsdaten ausgetauscht. Das Abhören dieser Daten ist zwar mit einer Sonde in der Nähe des Terminals möglich, allerdings sind diese Daten nicht ausreichend um eine gültige Transaktion zu erzeugen. Ohne das in Abschnitt 4.5.2 beschriebene Geheimnis kann die Transaktion nicht signiert werden. Das Abhören der NFC Schnittstelle bietet somit für den Angreifer nur einen geringen Wert. Um eine unerwünschte Transaktion durchführen zu können, muss ein Schadprogramm ein Terminal auf dem Smartphone simulieren. Dieses müsste zudem vom Finanzinstitut akzeptiert werden. Entsprechend ist ein aktiver Angriff durch ein Schadprogramm nicht möglich. Obwohl Google wallet weitestgehend wie eine echte Kreditkarte funktioniert, bietet es einen zusätzlichen Schutz in Form der PIN Abfrage vor jedem Geldtransfer. Klassische Kreditkarten können in verschiedenen Szenarien ohne Bestätigung mit einer PIN genutzt werden. Dies ist bei Google wallet nicht möglich. Ein Angreifer mit physikalischem Zugriff kann die NFC Übertragung mit Google wallet ohne das Wissen um die PIN nicht aktivieren. Eine geringfügig größere Gefahr besteht, wenn die Einstellung für die PIN-Abfrage geändert wird. In diesem Fall ist die PIN nur noch für die Aktivierung der Applikation nötig. Sobald dies geschehen ist, können beliebig viele Transaktionen durchgeführt werden. Die Sicherheit der PIN ist für den Betrieb von Google wallet essentiell. Eine Untersuchung von Rubin [2012] zeigt, dass ein Angreifer mit ausreichendem Zugriff die PIN trotzdem auslesen kann. Die PIN wird nicht auf dem Secure Element gespeichert, sondern in einer zu Google wallet gehörenden lokalen Datenbank auf dem Smartphone. Die PIN findet sich darin als Hash mit dem dazugehörendem Salt. Ein Schadprogramm oder ein fremder Nutzer mit ausreichend Zeit kann den Hash und den Salt auslesen und mittels Brute Force die dazugehörige in das Secure Element verschoben wird (ebd.). Eine frühere Untersuchung von Viaforensics [2011] stellt die tatsächliche Nutzung des Secure Element infrage. Innerhalb der bereits erwähnten Datenbank konnten verschiedene Kreditkarteninformationen aufgefunden werden. Auch wenn diese Daten nicht für die Herstellung einer gefälschten Kreditkarte nutzbar sind, bieten sie trotzdem ausreichend Informationen für die Durchführung einer Card not present transaction (CNP). Eine CNP ist eine Geldüberweisung in welche die physikalische Kreditkarte nicht involviert ist, sondern nur eine Reihe von Informationen derselbigen. Diese Daten können wiederum von einem reellen Angreifer oder durch ein

© Stefan Gfrörer

53

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
Schadprogramm ausgelesen werden. Listing 4.1 zeigt einen Ausschnitt von Informationen, die in der Datenbank gefunden werden können (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 Ziffern der Kartennummer (Quelle: Viaforensics [2011]; im Auszug).

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

4.6. Bitcoins
4.6.1. Beschreibung des Verfahrens
Elektronische Geldsysteme, welche dezentral ohne Bank als kontrollierende dritte Partei arbeiten, müssen sich mit der Problematik des mehrfachen Ausgebens von Geldeinheiten auseinandersetzen. Nakamoto [2009] hat mit Bitcoin einen Peer-toPeer basierten Lösungsansatz 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 geprüften Transaktionen eingebunden. Eine Überweisung kann nur geändert werden, wenn die komplette Kette manipuliert wird. Diese Kette wird des Weiteren dadurch geschützt, dass das Netzwerk nur die längste Kette akzeptiert. Die längste Kette wird per Definition durch die Gruppe mit der größten Rechenleistung generiert. Nakamoto [2009] geht davon aus, dass die größte Gruppe nie aus Angreifern bestehen kann, da andernfalls ein Großteil des Netzwerks korrumpiert sein muss. Dies folgt

54

© Stefan Gfrörer

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 Rückbuchung nicht möglich. Geldeinheiten – sogenannte Bitcoins – werden durch Berechnung eines initialen Hash und damit durch eine erste Transaktion erzeugt. Der Aufwand für die Erzeugung steigt in regelmäßigem Abstand. Die Zahl an möglichen Bitcoins ist limitiert. Zusätzliche Einnahmen sind durch geringe Gebühren möglich. Ein Nutzer erhält die Gebühr für die Bearbeitung einer Transaktion. Teilnehmer im Netzwerk werden über eine Bitcoin Adresse – eine kodierte Zeichenkette – referenziert (vgl. Nakamoto [2009] und Bitcoin Project [2012]). Für das Bitcoin Netzwerk gibt es eine Reihe von Clientprogrammen für verschiedene Betriebssysteme und Plattformen. Für Android basierte Smartphones stehen eine Reihe von Apps zur Verfügung. Die vorliegende Arbeit untersucht Bitcoin Android (vgl. Armstrong [2012]) und Bitcoin Wallet (vgl. Schildbach [2012]), welche jeweils neben der reinen Funktionalität als Bitcoin Client alle in Abschnitt 4.1 beschriebenen Kriterien für ein mobiles Bezahlsystem mit Peer-to-Peer Funktion erfüllen. Sie werden unabhängig voneinander entwickelt und stehen jeweils als Quellcode für die Untersuchung zur Verfügung. Der folgende Ablauf trifft auf beide Apps zu. In Abbildung 4.11 wird er visuell dargestellt. 1. Der Geldempfänger teilt dem Zahlenden seine Bitcoin Adresse mit. Optional kann er den gewünschten Betrag angeben. 2. Der Zahlende gibt nach Empfang der Bitcoin Adresse den Betrag ein und schließt dadurch die Transaktion ab. 3. Die Transaktion wird vom Client des Zahlenden dem Bitcoin Netzwerk mitgeteilt. 4. Das Netzwerk verifiziert die Transaktion. Gleichzeitig informiert sich der Client des Geldempfängers über neue Transaktionen und erhält auf diesem Weg Informationen über den empfangenen Betrag.

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

© Stefan Gfrörer

55

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
3. Bitcoin Adresse übertragen (QR Code, NFC, Bluetooth...) Geldempfänger 1. Bitcoin Adresse senden, optional Betrag 4. Bestätigen, 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 Rückschlüsse auf die wahre Identität 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 verifizierten Transaktionen, sondern nutzt eine vereinfachte Variante, die von Nakamoto [2009] zusammen mit der ausführlichen Methode vorgestellt wurde. Dies verringert die nötige Datenmenge für den Betrieb von Bitcoin und eignet sich damit besonders für mobile Systeme. BitCoinJ bietet Klassen für die Wallet und den Umgang mit Transaktionen. Die ermöglicht den Entwicklern durch reine Implementierung einer Programmoberfläche eine komplette Anwendung für das Bitcoin Netzwerk zu entwickeln (vgl. Hearn u. a. [2012]). Beide Applikationen verbreiten die Bitcoin Adresse standardmäßig durch einen QR Code, welcher zusätzlich den gewünschten Betrag enthalten kann. Bitcoin Wallet bietet zudem die native Unterstützung von NFC. Unabhängig davon nutzen beide Apps aber auch die Möglichkeiten des Betriebssystems. Unter Android können sich Programme für 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. Abhängig von

56

© Stefan Gfrörer

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]).

4.6.3. Verbreitung und Akzeptanz durch Benutzer
Bitcoin ist eine komplett virtuelle Währung und besitzt ursprünglich keinen reellen Gegenwert. Aufgrund der steigenden Bekanntheit, den geringen Transaktionsgebühren und der möglichen Anonymität akzeptieren verschiedene Dienstanbieter Bitcoins als Zahlungsmittel. Dazu gehören sowohl Dienste im Internet als auch Händler mit materiellen Artikeln und Dienstleistern. Auf dieser Basis ist ein Tauschhandel gegen reelle Währungen entstanden, der ähnlich der Börse Kursschwankungen unterliegt (vgl. Bitcoin.it Wiki [2012]).

4.6.4. Sicherheitsanalyse
Die folgende Analyse untersucht nicht die Sicherheit von Bitcoin. Es werden ausschließlich Angriffe auf die vorgestellten Android Apps durchgeführt. 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 betreffen darum beide Programme gleichermaßen. Unabhängig 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 Beträge auf der Wallet des Smartphones zu hinterlegen. Einerseits besteht die Gefahr, dass das mobile Endgerät verloren geht. Anderseits steigt für Angreifer die Attraktivität aufgrund des möglichen finanziellen Gewinns durch den Besitz von Bitcoins. Ein Schadprogramm kann die Wallet entsprechend kopieren und das Original löschen. Die Sicherheit hängt in diesem Fall von einer Verschlüsselung der Wallet mit einem externem Geheimnis – beispielsweise einer PIN – und den Mechanismen des Betriebssystems ab. BitCoinJ nutzt nur letzteres und speichert die Wallet unverschlüsselt im internen Speicher des Smartphones. Ähnliche Möglichkeiten hat auch ein Angreifer mit physikalischem Zugriff auf das Handy. Unter Nutzung von entsprechenden Rechten kann er die Wallet manuell auslesen und entfernen. Des Weiteren schützt keine der beiden Apps die Programmoberfläche und die möglichen Aktionen. Ein Angreifer kann aus diesem Grund

© Stefan Gfrörer

57

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
Beträge durch eine einfache Transaktion stehlen. Durch die Unumkehrbarkeit aller Transaktionen im Bitcoin Netzwerk ist dieser Diebstahl nicht mehr rückgängig zu machen. Die Oberfläche und damit auch das Versenden von Beträgen könnte unabhängig von BitCoinJ durch Abfrage eines Geheimnisses geschützt werden. Nativ sehen beide Apps zur Übertragung der Bitcoin Adresse nur QR Codes oder, im Fall von Bitcoin Wallet, zusätzlich 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 Empfänger für Texte registrieren und durch den Namen eine Applikation zum Versenden von Bitcoin Adressen vortäuschen. 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 müssen, ist eine Verschlüsselung der Adresse nur bedingt möglich. Dasselbe gilt für 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 können die Anmeldedaten zu diesen Diensten ermittelt und die Wallet gestohlen werden. Allerdings ist dies mit den vorgestellten Apps nicht möglich, da sie die Wallet im internen Speicher des Smartphones speichern. Dieser ist für einen normalen Anwender nicht erreichbar (vgl. Google [2012d]). In vorherigen Abschnitten wurde die mögliche Anonymität 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 trifft auch zu wenn kein Kontakt zu personenbezogenen Informationen stattfindet. Reid u. Harrigan [2011] zeigen, dass durch die Veröffentlichung der Bitcoin Adresse und deren Verwendung zum Bezahlen eine Verknüpfung zwischen einer Person und all ihren Bitcoin Adressen möglich ist. Die Anonymität 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 große Anzahl an Überweisungen erhalten hat. Er wurde als die Webseite Wikileaks identifziert (vgl. Reid u. Harrigan [2011]).

58

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.7. „A 2D Barcode-Based Mobile Payment System“

Wikileaks

Abbildung 4.12.: Grafische 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 Angriffen A2, A4 und A5 ungeschützt. Keine Bedeutung haben A1, A3 und A7, da übertragene und gespeicherte Daten ohne Gefahr für das Verfahren gelesen werden können. Unter der Voraussetzung, dass der normale Anwender keinen Zugriff auf die Wallet erhält, sind beide Verfahren vor A6 sicher. Als zusätzlicher Angriff kommt die Offenlegung der reellen Identität der Anwender hinzu. Applikationen für Bitcoin sind somit zwar gegen passive Angreifer geschützt, allerdings sehr anfällig für aktive Manipulation.

4.7. „A 2D Barcode-Based Mobile Payment System“
4.7.1. Beschreibung des Verfahrens
Gao u. a. [2009] haben ein mobiles Bezahlsystem unter Verwendung von 2D Barcodes entwickelt. Es ähnelt eKaayCash und ist für die Bezahlung von Produkten in Geschäften 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 Gfrörer

59

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
für mögliche Anwendungen von 2D Barcodes. Das Verfahren unterstützt keine Peerto-Peer Transaktionen (ebd.). Aufgrund der Ähnlichkeit mit eKaayCash ist aber eine Implementierung möglich. Dazu wird eine Webseite benötigt, 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 für Händler und Kunden begründet. Ein 2D Barcode könne alle notwendigen Daten zur Identifizierung eines Produktes enthalten und erlaube zusätzlich erste Informationen, welche dem Kunden angezeigt werden könnten (vgl. [Gao u. a. 2009, Seite 322]). Diese Begründung deckt sich mit der Verwendung von 2D Barcodes in eKaay und damit auch in eKaayCash. Für die Anwender – Händler und Kunde – stellt sich der Ablauf des Verfahrens folgendermaßen dar: es wird davon ausgegangen, dass sich der Kunde bereits in der App angemeldet hat und vom Händler ein 2D Barcode für das Produkt erstellt wurde. 1. Der Kunde fotografiert den 2D Barcode eines Produktes ab. Dieser Barcode enthält einen Verweis auf die Produktseite des Händler im Internet. 2. Die Produktseite wird vom Kunden aufgerufen. 3. Der Benutzer erzeugt eine Kaufanfrage für das Produkt und sendet diese an den Händlerserver. 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 führt die Transaktion durch und sendet eine Bestätigung an den Kunden und an den Händler. Der Ablauf ist in Abbildung 4.13 graphisch dargestellt.

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

60

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.7. „A 2D Barcode-Based Mobile Payment System“
Produktcode 2. Einlesen 1. Anmeldung Kunde

5. Bezahlanfrage 3. Kaufanfrage

4. Rechnung

6. Verifikation und Geldüberweisung

Zahlungsserver Händlerserver

Abbildung 4.13.: Ablauf eines Produktkaufs mit Hilfe des 2D Barcode Verfahren. Nicht enthalten sind die Bestätigungen an Kunden und Händler (eigene Darstellung). (HMAC) sichergestellt. Die individuelle PIN kommt dabei als Schlüssel zum Einsatz (vgl. Gao u. a. [2009]). Als Implementierung des 2D Barcodes wird die von der Firma RVSI/Acuity 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 Verfügung, andererseits werden alle Kommunikationsdaten vor ihrer Übertragung mit Hilfe einer DataMatrix kodiert (ebenda). Der Einsatz der DataMatrix als Kommunikationskodierung wird in der Arbeit nicht schlüssig begründet. Sie bietet keinen Vorteil gegenüber anderen Kodierungen. Da eine Kodierung jedoch keinen Einfluss auf die eigentliche Sicherheit hat, wird dieses Faktum im weiteren Verlauf ignoriert. Im Folgenden wird der detaillierte, technische Ablauf erläutert. Er umfasst als ersten Schritt auch die Anmeldung des Kunden beim Zahlungsserver. Dieser Schritt entfällt bei nachfolgenden Transaktionen. 1. Ein registrierter Kunde meldet sich mit seinem Benutzerkonto und der PIN beim Zahlungsserver an. Der Server bestätigt die Anmeldung mit der ID des Serverzertifikats, der Session ID und einem öffentlichen Schlüssel für die weitere Kommunikation. Er wird vom mobilen Client unter Nutzung des Serverzertifikats und des öffentlichen Schlüssel authentifiziert.

© Stefan Gfrörer

61

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
2. Der Kunde liest einen 2D Barcode ein. Dieser enthält neben dem bereits erwähnten Verweis zur Produktseite des Händlers auch allgemeine Informationen über das Produkt. Der Benutzer ruft die Produktseite auf und erstellt einen Kaufanfrage für den Händler. Die Anfrage wird digital signiert und an den Händler übertragen. 3. Der Händlerserver verarbeitet die Kaufanfrage. Er authentifiziert dabei den Kunden mittels der Session ID und dem öffentlichen Schlüssel. Die digitale Signatur wird mittels des geheimen Schlüssels 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 Schlüssel des Kunden signiert. Vor der Übertragung wird eine sichere Verbindung zwischen mobilem Client und Zahlungsserver aufgebaut. Nach Erhalt der Zahlungsanfrage überprüft der Server die Daten und verarbeitet die Anfrage. Nach erfolgreichem Abschluss der Transaktion sendet er eine unsignierte Bestätigung an den Kunden und an den Händler.

4.7.3. Verbreitung und Akzeptanz durch Benutzer
Da es sich bei der Veröffentlung um eine reine Forschungsarbeit handelt, wird das Verfahren nicht reell eingesetzt. Dies ist jedoch möglich. Dabei stellt sich die Einbindung für den Händler als einfach dar. Dieser muss einen Server mit der notwendigen Software zur Verfügung stellen und die Produkte mit dem jeweiligen 2D Barcode kennzeichnen. Für einen Kunden ist die Installation der App notwendig. Der Einkauf und das Bezahlen einzelner Produkte erfolgt durch abfotografieren des Codes und benötigt nur geringe Interaktion von Seiten des Benutzers. Sowohl für den Händler als auch für den Kunden ist ein Konto auf dem Zahlungsserver Voraussetzung.

4.7.4. Sicherheitsanalyse
Aufgrund der Verwendung von ECC zur Verschlüsselung und Signierung der übertragenen Daten, sind die Kommunikationskanäle 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 anschließend Zugriff auf die verschlüsselten sicherheitsrelevanten Daten, wie der private Schlüssel des Kunden, welche auf dem Handy gespeichert werden, zu bekommen. Unabhängig von Transaktionen des Kunden kann das Schadprogramm anschließend für

62

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.7. „A 2D Barcode-Based Mobile Payment System“
den Zahlungsserver valide Transaktionen durchführen. Das Schadprogramm kann einerseits ferngesteuert Bezahlvorgänge für den Angreifer vornehmen oder anderseits Einkäufe bei einem vom Angreifer gefälschten Händler durchführen. Bei längerem Zugriff auf ein Handy mit angemeldetem Benutzerkonto sind reguläre Bezahlvorgänge für einen Angreifer theoretisch möglich. Aus der Beschreibung des Verfahrens geht nicht hervor, wann die Eingabe der PIN notwendig ist. Die Gefahr des physikalischen Zugriffs auf das Endgerät 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 findet mit Hilfe der Kontodaten und der PIN statt. Diese können von einem Angreifer mittels Social Engineering ermittelt werden. Das Wissen um die Anmeldedaten allein ermöglicht jedoch noch nicht die Durchführung einer Transaktion. Bei der Registrierung für das Verfahren wird unter anderem der private Schlüssel des Kunden auf dessen Handy abgelegt. Ohne diesen Schlüssel kann ein Angreifer keine Transaktion signieren und durchführen. Das Verfahren wird mit dem Fotografieren des Produkt-Barcodes initiiert. Dieser Barcode kann von einem Angreifer physikalisch oder mit Hilfe eines Schadprogramms auf dem mobilen Endgerät ausgetauscht werden. Der gefälschte 2D-Code kann sämtliche Informationen des Originals enthalten, verweist aber auf eine gefälschte Produktseite. Das Händlerkonto hinter dieser Produktseite muss regulär beim Zahlungsserver registriert sein. Diese Art von Angriff wird im Normalfall sehr schnell auffallen, da keines der scheinbar bezahlten Produkte tatsächlich 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 möglich. Des Weiteren bietet das Verfahren durch die Aufteilung des Geheimnisses in Wissen – Anmeldedaten und PIN – und Besitz – der private Schlüssel auf dem Smartphone – einen guten Schutz vor A6. Allerdings kann ein Schadprogramm zunächst die PIN auslesen und dann selbst eine Transaktion ausführen. Außerdem ist der Austausch des 2D-Codes vor Beginn einer Transaktion möglich. Ähnliche Angriffe können auch durch physikalischen Zugriff ausgeführt werden. Damit ist das Verfahren durch A1, A2 und A5 angreifbar.

© Stefan Gfrörer

63

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme

4.8. „A Wireless Payment System“
4.8.1. Beschreibung des Verfahrens
In mobilen Endgeräten, welche kein NFC unterstützen, dient in vielen Fällen Bluetooth als Standard für Kurzstreckenkommunikation. Mutchukota u. a. [2011] haben gezeigt, dass Bluetooth durch Man-in-the-Middle angreifbar ist und somit ein sicherer Kanal nötig wird. In einer Analyse kann eine Verbindung via Bluetooth somit als ein Kommunikationsweg betrachtet werden, welcher durch Lauschangriffe und Manipulation bedroht wird. Gleichzeitig ist eine Nutzung für P2P Applikationen möglich. Von Gao u. a. [2006] wird Bluetooth aus diesem Grund für ein mobiles Peer-to-Peer Bezahlsystem verwendet, welches eine hohe Kompatibilität zu bestehenden mobilen Endgeräten bietet. Im Folgenden wird der Ablauf beschrieben. Dieser findet sich auch in Abbildung 4.14. Voraussetzung für den Vorgang ist, dass sich beide Teilnehmer der Transaktion mit Hilfe ihrer P2PID – einer individuellen ID im Bezahlsystem – und ihrem Passwort anmelden. Für zukünftige Implementierungen ist zusätzlich eine Verifikation über die Stimme des Nutzers geplant (vgl. [Gao u. a. 2006, Abschnitt 4]). 1. Im ersten Schritt müssen Zahlender und Geldempfänger ihre Rolle in der Transaktion auswählen. Dies geschieht über die Programmoberfläche. 2. Nach Identifizierung aller erkannten Geldempfänger in Reichweite muss der Zahlende den korrekten Empfänger auswählen. 3. Der Zahlende muss die Transaktion im folgenden Schritt durch Eingabe des Betrags abschließen. 4. Das mobile Endgerät sendet die Daten der Transaktion an den Zahlungsserver. Dieser verifiziert sie und führt die eigentliche Geldüberweisung durch. Sowohl der Geldempfänger als auch der Zahlende erhalten eine Bestätigung.

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

64

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.8. „A Wireless Payment System“
3. P2PID übertragen (Bluetooth) Geldempfänger 1. P2PID über Bluetooth senden 4. Betrag eingeben Zahlender 2. Empfang via Bluetooth aktivieren

6. Verifikation und Geldüberweisung

5. Bestätigte Zahlungsanfrage (Internet)

Zahlungsserver

Abbildung 4.14.: Ablauf einer P2P Überweisung mit Hilfe von Bluetooth. Die Bestätigung 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 Verschlüsselung. Dazu wird im Zuge der Registrierung ein individueller Schlüssel generiert. Er wird kodiert auf dem Endgerät gespeichert. Für einzelne Sitzungen wird aus diesem Schlüssel ein weiterer generiert, welcher zum Schutz der kritischen Daten der Transaktion dient. Der Sitzungsschlüssel wird dem Server mit Hilfe eines an jede Nachricht angehängten Header mitgeteilt. Dieser Header enthält in der ersten Nachricht den Schlüssel und seine Länge. Die Information über den Schlüssel enfällt in den weiteren Nachrichten. Enthalten ist aber immer eine Signatur und die Information, welche Datenfelder in der jeweiligen Nachricht verschlüsselt sind. Die Signatur wird aus den Nutzdaten und dem bei der Registrierung erzeugten Schlüssel berechnet (vgl. Gao u. a. [2006]). Der Aufbau des Header ist in Tabelle 4.2 dargestellt. Signatur Schlüssel Schlüssellänge verschlüsselte Felder

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

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

© Stefan Gfrörer

65

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
2006, Seite 4]). Der Vorteil von biometrischen Daten liegt in ihrem hohem Fälschungsschutz gegenüber klassischen Passwort-Systemen. Aus technischer Sicht lässt sich der Ablauf des Bezahlsystems in zwei grundlegende Phasen aufteilen. Der erste Abschnitt umfasst die Phase der Veröffentlichung der P2PID via Bluetooth bis zum Punkt an dem der Zahlende die Transaktion mit Eingabe des Betrags abschließt. 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 bestätigten Transaktion an den Server. Neben dem Schutz durch den Sicherheitsheader und die Verschlüsselung mittels symmetrischem Verfahren sollen auch sichere Verbindungen mittels SSL oder TLS zum Einsatz kommen (vgl. [Gao u. a. 2006, Seite 3]).

4.8.3. Verbreitung und Akzeptanz durch Benutzer
Als theoretische Arbeit wird dieses Verfahren in der vorliegenden Form außerhalb eines Prototyps nicht eingesetzt. Für Benutzer des Dienstes kann vor allem die Verzögerung durch den Verbindungsaufbau von Bluetooth und durch die verschiedenen notwendigen Interaktionen mit der Programmoberfläche störend wirken. Vorteilhaft ist die sehr hohe Kompatibilität mit älteren und neueren Handys, welche selbst von Verfahren auf Basis von Kameras nicht erreicht werden kann. Für diese ist zudem ein ausreichend großer und verhältnismäßig hochauflösender Bildschirm nötig, wie er erst in jüngeren Smartphones existiert.

4.8.4. Sicherheitsanalyse
Der Aufteilung des Verfahrens in zwei Phasen, wie in Abschnitt 4.8.2 dargestellt, folgend, besteht der erste mögliche Angriff im Austausch der P2PID vor Bestätigung der Transaktion. Dieser Angriff entspricht dem in Abschnitt 4.4.4 beschriebenem Szenario. Ein Schadprogramm auf dem Handy des Geldempfängers oder des Zahlenden kann die ID vor dem Versenden oder direkt nach dem Empfang gegen die P2PID des Angreifers austauschen. Dieser Angriff 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 möglich. Der Austausch der ID kann nicht nur durch ein Schadprogramm erfolgen, sondern ist mittels Man-in-the-Middle auch während der Bluetooth Verbindung möglich. Wie auch bei PayPal kann die Signierung der ID begrenzten Schutz vor Manipulation

66

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.8. „A Wireless Payment System“
der Daten bieten. Für ein Schadprogramm auf dem Handy des Geldempfängers stellt dies jedoch kein Hindernis dar. Nach Bestätigung der Transaktion durch den Zahlenden kann ein Schadprogramm die signierten und verschlüsselten Daten manipulieren, wenn es Zugriff auf den Schlüssel hat. Die Sicherheit hängt also von den Mechanismen des Betriebssystems ab. Die eigentliche Übertragung zum Server erfolgt wie beschrieben mittels sicherer Verbindungen zusätzlich zum Schutz durch den Sicherheitsheader. Sofern ein erfolgreicher Man-in-the-Middle Angriff auf die SSL oder TLS Verschlüsselung durchgeführt wurde, besteht die Gefahr, dass das erste Datenpaket mit dem Schlüssel für die Transaktion mitgelesen wird. In diesem Fall kann ein Angreifer die Transaktionsdaten auslesen. Eine Manipulation ist weiterhin nicht möglich, da die Signatur mit dem Registrierungsschlüssel erzeugt wurde. Der symmetrische Registrierungsschlüssel ist in der vorliegenden Version die kritische Komponente im System. Wenn der mobile Client angemeldet ist, kann bei erfolgreichem Diebstahl dieses Schlüssels jede beliebige Transaktion ohne Mitwirken des Benutzers ausgeführt werden. Gao u. a. [2006] bezieht sich zwar auf eine Kodierung des Schlüssels, diese wird jedoch nicht näher erläutert und die Nutzung eines externen Geheimnisses – beispielsweise eine PIN – ist nicht vorgesehen. Aufgrund des Verzichts auf eine Bestätigung der Transaktion mittels PIN, erlaubt der physische Zugriff die Durchführung einer Überweisung. Dazu muss der Client angemeldet sein. Ist dies nicht Fall, hat sowohl ein physischer Angreifer als auch ein Schadprogramm keine Möglichkeit eine Transaktion zu erzeugen. Die Anmeldedaten können zwar mittels Social Engineering ermittelt werden, jedoch wird dies bei Einführung der Stimmverifizierung erschwert. Der technische Aufwand ist in diesem Fall für einen Angreifer deutlich höher.

4.8.5. Fazit
Dieses Verfahren bietet eine Reihe von Sicherheitsmechanismen, welche teilweise angegriffen werden können. Zwar ist A7 nicht möglich und A6 kann nach Einführung der Stimmverifizierung als sicher betrachtet werden, dennoch bieten sich sowohl für Schadprogramme als auch für Man-in-the-Middle Angriffe eine Reihe von Möglichkeiten zur Manipulation und zur Erzeugung eigener Transaktionen. Letzteres ist auch für einen physikalischen Angreifer möglich, wenn die App angemeldet ist. Daraus folgt das A1, A2, A4 und A5 erfolgreich durchgeführt werden können. Mittels A3 können zudem vollständige Transaktionen mitgelesen werden, dies setzt jedoch umfassende Angriffe auf den Kommunikationskanal voraus.

© Stefan Gfrörer

67

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme

4.9. Entwurf einer Smartphone basierten Geldkarte
4.9.1. Beschreibung des Verfahrens
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 für Smartphones, welches die Funktionalität einer Geldkarte mit NFC und eines POS auf ein Smartphone überträgt und auf diese Weise Peer-to-Peer Bezahlvorgänge erlaubt. Das Verfahren wurde im Zuge dieser Arbeit entworfen und stützt sich auf die Arbeit von Cheng u. a. [2011] und auf Schnittstellenspezifikationen für Geldkarten (vgl. Deutsche Kreditwirtschaft [2011]). Die folgenden Erläuterungen und Abläufe stellen entsprechend keine technische Implementierung vor. Sie beschreiben stattdessen die möglichen Abläufe, mit welchen ein P2P System auf Basis der klassischen Geldkarte auf Smartphones umgesetzt werden kann. Es wird auf explizite Erklärungen zu den Schritten einer Bezahlung mittels Geldkarte verzichtet, das gilt insbesondere für die eigentliche Kommunikation zwischen Terminal und Karte. Die Erklärungen können in den Schnittstellenspezifikationen für Geldkarten eingesehen werden (vgl. Deutsche Kreditwirtschaft [2011]). Die deutsche Geldkarte, welche als girogo weiterentwickelt wurde, ermöglicht bargeldlose Bezahlvorgänge ohne Kommunikationsverbindung zu einer Bank. Dies wird auch als Offline Vorgang bezeichnet. Geldbeträge werden direkt auf der Geldkarte gespeichert. Bei einem Bezahlvorgang findet keine weitere Authentisierung des Benutzers statt und entsprechend ist das Verfahren nur für Kleinstbeträge vorgesehen. Der Geldempfänger – im klassischen Fall ist dies ein Händler mit POS Terminal – erhält das Geld nicht sofort, sondern erst nach dem Abgleich mit der Bank. Der Abgleich ist dabei unabhängig vom Bezahlvorgang und findet im Regelfall zu einem späteren 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-Funktionalität installiert ist. Der Zahlende muss des Weiteren den notwendigen Betrag auf das Handy geladen haben. Das Aufladen kann, wie bei klassischen Geldkarten, durch die Bank oder an entsprechenden Automaten erfolgen. 1. Der Geldempfänger 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 Gfrörer

Peer-to-Peer Payment via NFC 4.9. Entwurf einer Smartphone basierten Geldkarte
3. Er bestätigt 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 führen die eigentliche Geldüberweisung durch. 5. Der Abschluss des Vorgangs wird durch eine Benachrichtigung an beide Benutzer signalisiert.

4.9.2. Technische Umsetzung
Um die Sicherheit eines auf dem Smartphone gespeicherten Geldbetrags zu gewährleisten, setzt das Verfahren auf die Verwendung eines Secure Elements. Die SoftwareApplikation dient als grafische Oberfläche für den Benutzer und startet das SE. Der eigentliche Bezahlvorgang wird vom SE über die NFC Schnittstelle durchgeführt. Der Betrag befindet 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 Zugriff auf kritische Operationen wird vom SE nur durch Eingabe der PIN erlaubt. Im Rahmen dieses Entwurfs zählt dazu nur die Initiierung einer Geldüberweisung 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 empfängt. Aufgrund dieser Entscheidung ist das Verfahren kompatibel mit bestehenden Geldkarten. Ein Bezahlvorgang läuft 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 Bestätigung mit der PIN notwendig. Beides wird vom SE verifiziert. 2. Die Smartphones treten in Kontakt und bauen eine sichere Verbindung auf. 3. Gemäß der Spezifikation einer Geldkarte wird der Geldbetrag übertragen (vgl. Deutsche Kreditwirtschaft [2011]). 4. Beide SE beenden die Kommunikation und zeigen dem jeweiligen Benutzer eine Bestätigung über den Erfolg der Transaktion an.

© Stefan Gfrörer

69

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
Geldempfänger 1a. Aktivierung des Geldempfangs Zahlender 2a. Eingabe Betrag und PIN

1b. Aktivierung App 5. Bestätigung SE NFC

4. Transaktion
NFC

2b. Aktivierung SE 5. Bestätigung App

3. Prüfung von Betrag und PIN

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

4.9.3. Verbreitung und Akzeptanz durch Benutzer
Wie in Abschnitt 4.5.3 bereits erläutert, 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 müsste. Entsprechend stellt die mangelnde Hardwareunterstützung keine Einschränkung dar. Ein Vorteil dieses Verfahrens ist die Abwärtskompatibilität zum bestehenden Geldkarten System. Aus diesem Grund besteht schon eine marktwirtschaftliche Basis in Form von teilnehmenden Händlern. Das System bietet somit sowohl einen einfachen P2P Vorgang als auch das klassische bargeldlose Bezahlen mit einer Geldkarte an.

4.9.4. Sicherheitsanalyse
Durch die Auslagerung aller sicherheitsrelevanten Vorgänge 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 abhören, allerdings kann mit dieser Information kein Bezahlvorgang durchgeführt werden. Für eine Transaktion ist immer ein Terminal notwendig. Ein Angreifer mit physischem Zugriff besitzt hingegen die Möglichkeit ein Terminal zur Verfügung 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. Abhängig vom Finanzinstitut kann dies zum Verlust des Geldbetrags führen.

70

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 4.10. Weitere Mobile Payment Lösungen
Da im Geldkarten System keine Authentisierung vorgesehen ist, können mittels Social Engineering keine kritischen Informationen abgefragt werden. Die PIN ist, wie schon im Zusammenhang mit Schadprogrammen erklärt, ohne das Smartphone ohne weiteren Nutzen. Das hier vorgestellte Verfahren sieht die verschlüsselte Kommunikation via NFC mittels einer sicheren Verbindung vor. Eine solche Ende zu Ende Verschlüsselung wurde bereits von Van Damme u. a. [2005] vorgestellt und lässt sich leicht mit NFC umsetzen. Der Kommunikationskanal beider SEs kann also als nicht angreifbar gelten. Da keine weitere Kommunikation zu einer externen Gegenstelle stattfindet, sind MITM Angriffe ohne von Bedeutung.

4.9.5. Fazit
Es lässt sich abschließend feststellen, dass das vorgestellte Verfahren eine sichere Implementierung für ein bargeldloses Bezahlsystem mit P2P Funktionalität bietet. Die Angriffe A3, A4, A6 und A7 sind nicht möglich 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 Zugriff gemäß A5 bietet ohne die PIN ebenfalls keine Möglichkeit für eine Überweisung.

4.10. Weitere Mobile Payment Lösungen
In diesem Abschnitt werden zwei mobile Bezahlsysteme vorgestellt, die nicht in 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 vollständig abgesicherten Umgebung aus Software und Hardware, welche kritische Operationen nur nach Kontrolle der Systemintegrität erlaubt. Dies soll den Einfluss durch Fremdzugriffe erkennen und verhindern und auf diese Weise sichere Bezahlvorgänge erlauben. Dies stellt zwar einen interessanten Ansatz dar, allerdings wurde das Verfahren aus zwei Gründen nicht untersucht. Zunächst wird es als reines POS System beschrieben. Es ermöglicht somit keine Peer-to-Peer Bezahlvorgänge. Des Weiteren konzentriert sich die Arbeit auf die Nutzung von Trusted Computing. Das eigentliche Bezahlverfahren wird jedoch nur in groben Zügen beschrieben. Auf dieser Basis

© Stefan Gfrörer

71

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
ist zwar eine Analyse von Trusted Computing in mobilen Endgeräten möglich, 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 ermöglichen und dient als reines POS System. Im Gegensatz zu Google wallet wurde ISIS noch nicht veröffentlicht und es existieren keine technischen Informationen zu Abläufen und verwendeten Verfahren. Aus diesem Grund ist eine Untersuchung nicht möglich (vgl. JVL Ventures, LLC [2012]).

4.11. Zusammenfassung
Dieser Abschnitt bietet mit Abbildung 4.16 eine Zusammenfassung der obigen Analysen. Die Sicherheit wird folgendermaßen bewertet: kann ein bestimmter Angriff ohne weitere Bedingung erfolgreich ausgeführt werden wird er mit −− markiert. im Gegensatz dazu steht die Wertung ++, welche einen nicht möglichen Angriff bezeichnet. Die Abstufungen − und + werden vergeben, wenn bestimmte Voraussetzungen erfüllt sein müssen. Eine Sonderrolle spielt die neutrale Wertung ◦. Sie wird vergeben, wenn der jeweilige Angriff ohne Bedeutung für das Verfahren ist. Beispielsweise unterstützt 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 während der Analyse die angewandten Methoden bewertet. Die Analyse hat gezeigt, dass sich die einzelnen Bezahlsysteme anhand der bekannten Abläufe untersuchen lassen. Die Angreifbarkeit durch bestimmte Ansätze konnte mit gewissen Einschränkungen nachgewiesen oder widerlegt werden. Allerdings bleiben

72

© Stefan Gfrörer

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 offen, wenn keine Einsicht in die detaillierte technische Implementierung vorliegt. Dies deckt sich mit den in Abschnitt 4.1 erläuterten Kriterien und Vorbedingungen. Unabhängig von den einzelnen Sicherheitsproblemen ermöglicht die Analyse nur geringe Aussagen zu kombinierten Angriffen. 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 zutreffen. Ein Beispiel hierfür ist die PIN Abfrage vor einer Transaktion. Zwar verhindert sie einen Angriff durch physischen Zugriff, allerdings nur wenn der Angreifer kein Wissen über die PIN hat. Wurde das Geheimnis hingegen zuvor beispielsweise durch Social Engineering gestohlen, kann die Transaktion ausgeführt werden. Dies muss als Restrisiko behandelt werden und bietet Möglichkeiten für weitere Untersuchungen. Die Analyse zeigt, dass sich die Abläufe der einzelnen Verfahren weitestgehend gleichen. Dies bestätigen die in Abschnitt 2.4 vorgestellten Prozesse für mobile Bezahlverfahren. Diese Ähnlichkeiten übertragen sich somit auch auf die Anwendbarkeit von Angriffen. Technische Unterschiede spielen nur eine untergeordnete Rolle. Die folgenden Absätze fassen die erhaltenen Erkenntnisse zusammen. Mobile Bezahlsysteme – unabhängig davon ob sie elektronisch oder mit klassischem Bargeld durchgeführt werden – stellen den Besitz der Werteinheit in den Vordergrund. Bei Bargeld sind die einzelnen Werteinheiten Geldstücke und Scheine. In elektronischen Systemen stellen Smartphones die Werteinheiten dar. Sie weisen den Benutzer aus und stellen die Verbindung zum tatsächlichen Geld her. Der Besitz eines Smartphones ist also essentiell für den Besitz des Geldes. Gegenüber Bargeld

© Stefan Gfrörer

73

Peer-to-Peer Payment via NFC 4. Analyse bestehender mobiler Bezahlsysteme
verfügen elektronische Bezahlsysteme über den Vorteil, dass der eigentliche Betrag nicht direkt mit dem Verlust des Smartphones verloren geht. Um dies zu gewährleisten muss die Bezahlapp abgesichert sein. Des Weiteren sollte der Zugriff auf das Konto vom Dienstanbieter gesperrt werden. Die Mehrheit der vorgestellten Verfahren verhindert Transaktionen durch nicht berechtige Personen nur unzureichend. Dies ist gut an Angriff A5 in Abbildung 4.16 zu erkennen. Zukünftige Verfahren sollten aus diesem Grund eine Authentisierung des Benutzers vor der Durchführung einer Überweisung erzwingen. Hier genügt beispielsweise bereits die Abfrage der PIN. Eine weitere übergreifende Bedrohung stellen Schadprogramme dar. Sie können sowohl passiv als auch aktiv kritische Informationen auslesen und manipulieren. Dieser Gefahr begegnend müssen Bezahlsysteme immer davon ausgehen, dass das Smartphone, auf dem sie ausgeführt 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 Einführung von sicheren Elementen in Form von Secure Elements oder externen Geheimnissen – beispielsweise eKaayCard (vgl. Günther [2011]) – kann effektiv vor Schadprogrammen schützen. NFC hingegen hat sich als sicher erwiesen. Mit Ausnahme von Google wallet überträgt kein Verfahren mit Hilfe von Nahfunk ungeschützt 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, können leicht mit Hilfe von geteilten Geheimnissen abgesichert werden. Im Gegensatz zu Schadprogrammen hat ein Manin-the-Middle keine Möglichkeit, das Geheimnis auszulesen oder mitzuhören, da es im Normalfall nicht mitübertragen wird. Wie bei klassischen Onlineüberweisungen bietet das manuelle Überprüfen der Transaktion einen hohen Schutz und kann in Kombination mit einem externen Geheimnis eine Vielzahl von Angriffen 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. Günther [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 Funktionalität umsetzt. Das sichere Framework in Form von eKaay hat nicht nur die einfache Entwicklung des Verfahrens ermöglicht, sondern auch die Gefahr durch verschiedene Angriffe

74

© Stefan Gfrörer

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 für diese Anwendung führen kann. Das Verfahren eKaayCash kann diese Probleme jedoch mit Hilfe von eKaay lösen. Dies betrifft insbesondere die Involvierung des Zahlenden in die Bestätigung der Transaktion. Es kann also festgestellt werden, dass eKaayCash ein sicheres mobiles Bezahlsystem für Smartphones ist. Anhand der weiteren Sicherheitsanalyse konnte ebenfalls erfolgreich gezeigt werden, dass mittels konzeptueller Abläufe bereits verschiedene Angriffe erkannt werden können. Des Weiteren wurde eine große Zahl an Gemeinsamkeiten in unterschiedlichen Systemen aufgedeckt. Daraus lassen sich allgemeine Empfehlungen für neue Bezahlverfahren und die Verbesserung bestehender Verfahren ableiten.

© Stefan Gfrörer

75

Peer-to-Peer Payment via NFC

5. Implementierung von eKaayCash
In diesem Kapitel werden einzelne Abschnitte der Implementierung von eKaayCash verdeutlicht. Es wird auf Probleme und ihre Lösungen eingegangen, aber kein vollständiger Einblick in den Quellcode gegeben. Weitere Implementierungsdetails können 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. Zunächst prüft es, ob Eingabedaten, wie der Betrag und die ID des Geldempfängers, vorhanden sind. 2. Im dem Fall, dass die ID fehlt, wird das Programm abgebrochen, da eine Transaktion ohne gültigen Empfänger nicht erzeugt werden darf. 3. Sind keine Überweisungsdaten vorhanden, wird das Formular angezeigt und das Programm endet. Wurden hingegen Daten für eine Transaktion eingeben, erstellt das Programm aus diesen Informationen eine neue Überweisung. 4. Dazu wird zunächst eine einzigartige Transaktionsnummer als ID generiert. 5. Die Überweisungsdaten werden anschließend für die Anzeige auf dem Smartphone aufbereitet. 6. Der Server der Bank speichert die Überweisung für die spätere Durchführung nach der Bestätigung durch die Benutzer. 7. Aus dem für 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 vollständige Ablauf wurde mit Hilfe von Aktivitätsdiagrammen in den Abbildungen 5.1 und 5.2 visualisiert.

© Stefan Gfrörer

77

Peer-to-Peer Payment via NFC 5. Implementierung von eKaayCash
[überweisen]

Überweisung erzeugen

Eingabe prüfen Start [nicht angemeldet]

[angemeldet] Ausgabe

[nicht überweisen]
Fehler

Formular erstellen

Abbildung 5.1.: Aktivitätsdiagramm, welches die Generierung einer Überweisung zeigt (eigene Darstellung).
ID erzeugen Start Daten aufbereiten

eKaay Ausgabe

Überweisung speichern

Abbildung 5.2.: Das Aktivitätsdiagramm 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 benutzerdefinierte 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 für ein benutzerdefiniertes URL Scheme (eigene Darstellung).

78

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 5.3. Server/Client Kommunikation

5.3. Server/Client Kommunikation
Im vollständigen eKaayCash Verfahren mit der Erweiterung für Online Shops gibt es folgende Entitäten. • Die Serverkomponente von eKaay. • Der Server des Dienstanbieters bzw. der Bank. • Das Smartphone des Geldempfängers. • Das Smartphone des Zahlenden. • Der Server des Online Shops. Der Vereinfachung wegen werden der Geldempfänger und der Zahlende zusammengefasst. Dies ist möglich, da beide ähnliche Informationen mit den Servern austauschen. Abbildung 5.3 zeigt alle Kommunikationsverbindungen. Die gerichteten Pfeile geben dabei an, von welcher Entität die Kommunikation ausgeht. Die Verbindungen werden im Folgenden erläutert. 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. Bestätigung der Überweisung. Nach der Bestätigung durch den Zahlenden, leitet eKaay diese an den Server der Bank weiter. Dieser kann die Transaktion abschließen. 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 ausgefüllt sein und der Server der Bank antwortet in diesem Fall mit der generierten Transaktion. Zahlungsbestätigung. Nach der Eingang einer Zahlung an einen Shop informiert der Server der Bank den Server des Online Shops.

© Stefan Gfrörer

79

Peer-to-Peer Payment via NFC 5. Implementierung von eKaayCash
Verifizierung der Bestätigung. Der Eingang einer Zahlung kann vom Server des Shops mit Hilfe der in Abschnitt 3.4 beschriebenen Schnittstelle verifiziert werden.

Registrierung/Anmeldung Bestätigung der Überweisung Nutzung von eKaay PIN

eKaay Server

Server der Bank

Challenge/ Response/ PIN Permutation

Verifizierung der Bestätigung Überweisungsformular

Zahlungsbestätigung

Überweisungformular

Smartphone Client

Server des Shops

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

80

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

6. Schluss
6.1. Zusammenfassung
Das Ziel der Arbeit war die Entwicklung eines sicheren, mobilen Bezahlsystems mit Peer-to-Peer Funktionalität 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 schließlich miteinander verglichen werden. Zunächst wurden eine Reihe von Bedingungen für das mobile Bezahlsystem festgelegt, in deren Rahmen das Verfahren umgesetzt werden sollte. Im folgenden Entwurf des Verfahrens konnten die Bedingungen fast vollständig eingehalten werden. Lediglich für 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 befindliche Praxis der Banken wurde zudem das eKaay PIN Verfahren für den Übergang von Kleinstbeträgen zu größeren Summen eingebunden. In einem zweiten Schritt wurde das vorgestellte Verfahren eKaayCash weiterentwickelt und für den Einsatz in Online Shop Systeme erweitert. Dies ermöglicht die einfache Einbindung des mobilen Bezahlsystems in eine bestehende Verkaufsplattform. Es konnte gezeigt werden, dass sowohl für den Kunden als auch für den Händler eine einfachere Bedienung des Shops möglich ist. Die Sicherheit für den Händler wird durch einen einfachen Bestätigungsprozess gewährleistet. Ein Austausch gegen ein beliebiges anderes Bestätigungsverfahren ist vorgesehen und möglich. Zur Überprüfung der Sicherheit beider Systeme wurden zunächst mögliche Angriffspunkte in Bezahlsystemen mit besonderem Hinblick auf die mobile Plattform identifiziert. Sie wurden ausführlich erläutert und auf mögliche Folgen im finanziellen Umfeld geprüft. Anschließend konnten eKaayCash und die Erweiterung für 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 abhängig ist.

© Stefan Gfrörer

81

Peer-to-Peer Payment via NFC 6. Schluss
Aufbauend auf die Untersuchung von eKaayCash wurden im Anschluss weitere mobile Bezahlverfahren ausgewählt, vorgestellt und untersucht. Die Einzelergebnisse ergaben einen Überblick über verschiedene gemeinsame Probleme in elektronischen Geldsystemen in mobilen Umgebungen. Diese Probleme konnten in einer abschließenden Diskussion aufgezeigt werden. Dabei wurden Vorschläge für ihre Lösungen oder zumindest für 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 für Smartphones entwickelt. Es besteht aus einem einfachen Verfahren, welches die direkte Überweisung von Beträgen 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 erläutert. Um eine unnötige Beschreibung eines austauschbaren Quellcodes zu vermeiden, wurde die Implementierung auf einer abstrakten Ebene erläutert. Das Ergebnis dieser Arbeit ist ein funktionierendes mobiles Bezahlsystem, welches eine P2P Kommunikation mittels NFC ermöglicht. Es ist innerhalb einer simulierten Bankumgebung voll funktionsfähig. Des Weiteren wurde ein lauffähiges Beispiel für eine Erweiterung für Online Shops vorgestellt. Diese Erweiterung demonstriert auch die hohe Flexibilität des Bezahlsystems, welches sich leicht anpassen ließ. Die Sicherheit von eKaayCash wurde in einer ausführlichen Analyse demonstriert und mit anderen existierenden und theoretischen Verfahren verglichen. Zusammen mit dem Entwurf des Geldkarten Systems für Smartphones bieten die Analyse und das eKaayCash Verfahren eine Reihe von Hinweisen für die Entwicklung weiterer, sicherer Bezahlsysteme für das mobile Umfeld.

6.2. Ausblick
Unabhängig von den erzielten Ergebnissen ergeben sich durch diese Arbeit neue Ansätze für weitere Untersuchungen. Erweiterte Analyse. Die Analyse in dieser Arbeit hat die Auswirkung einzelner Angriffe untersucht. Eine Kombination von verschiedenen Angriffen und die Auswirkung des Restrisikos wurde jedoch nicht beachtet. Für eine Anwendung,

82

© Stefan Gfrörer

Peer-to-Peer Payment via NFC 6.2. Ausblick
welche die Überweisung von Geldbeträgen ermöglicht, 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 abhängig 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 Günther [2011] in Form einer externen Karte verfolgt. Zwar bietet eine Karte ein hohes Maß an Sicherheit durch den Faktor Besitz, allerdings verringert sie die Benutzerfreundlichkeit. Ein Geheimnis, welches in einem sicheren Bereich des Smartphones gespeichert ist, könnte sowohl einen hohen Sicherheitsfaktor stellen, als auch die Benutzerfreundlichkeit von eKaay ohne externe Karte beibehalten. Abschließend lässt sich festhalten, dass die gesetzten Ziele erreicht wurden und die Zielsetzung zum Teil – beispielsweise mit dem Entwurf eines Geldkarten Systems für Smartphones – ausgeweitet wurde. Anhand der Analyse ließen sich weitere Ziele für zukünftige Arbeiten in diesem Themengebiet finden.

© Stefan Gfrörer

83

Peer-to-Peer Payment via NFC

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-Württembergische Bank 2006 Baden-Württembergische Bank: TAN-Generator der BW-Bank zertifiziert - Erfolg für 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 Gfrörer

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 Pacific / KPMG. 2007. – Report Deutsche Kreditwirtschaft 2011 Deutsche Kreditwirtschaft: Schnittstellenspezifikation für die ec-Karte mit Chip Version 2.2. 2011 Deutsche Kreditwirtschaft 2012 Deutsche Kreditwirtschaft: Händlerinfo: girogo.de. Online. http:// girogo.de/4-0-Haendlerinfo.html. Version: Mar 2012 EMVCo 2008 EMVCo: EMV Integrated Circuit Card Specifications 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 978–0–7695–3658–3, 320-329 Version: Jul

86

© Stefan Gfrörer

Peer-to-Peer Payment via NFC Literaturverzeichnis
Günther 2011 Günther, Max: Sicheres Online Banking via Smartphone mit Nahfunk (NFC) , Uni Tübingen, 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 ; Møller, Jan ; Nagele, Prentice-Hall Of India Pvt. Ltd., 2005. – ISBN

© Stefan Gfrörer

87

Peer-to-Peer Payment via NFC Literaturverzeichnis
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. Identification 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. Zulfiquar 2007 Kadhiwal, Saleem ; Zulfiquar, Anwar Usman S.: Analysis of mobile payment security measures and different standards. In: Computer Fraud Security 6 (2007), Jun, Nr. 6, S. 12–16 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. 44–66 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 Gfrörer

Peer-to-Peer Payment via NFC Literaturverzeichnis
Kortvedt u. Mjølsnes 2009 Kortvedt, Henning S. ; Mjølsnes, 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-Pacific Trusted Infrastructure Technologies Conference. Washington, DC, USA : IEEE Computer Society, 2008. – ISBN 978–0–7695–3363–6, 98–112 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 Different 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 978–0–7695–3613–2, 205–210 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 offer 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 Gfrörer

89

Peer-to-Peer Payment via NFC Literaturverzeichnis
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 (WTS’09). – ISBN 978–1–4244–2588–4, 309–316 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: ICMB’07, 2007 Pasquet u. a. 2008 Pasquet, Marc ; Reynaud, Joan ; Rosenberger, Christophe: Secure payment with NFC mobile phone in the SmartTouch project. IEEE, 2008. – 121–126 S. Patel 2011 Patel, Kunur: Survey: Consumers Don’t 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 Gfrörer

Peer-to-Peer Payment via NFC Literaturverzeichnis
bin/?cmd=_render-content&content_ID=marketing_us/mobile_payments. Version: Jan 2012 PayPal 2012c PayPal: Sofortige Zahlungsbestätigung (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 : Vorträge der 9. ITG-Fachtagung vom 16. bis 17. Juni 2004 in Osnabrück. 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 978–1–4577–1931–8, 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 Gfrörer

91

Peer-to-Peer Payment via NFC Literaturverzeichnis
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 Hitchhiker’s Guide to DNS Cache Poisoning Suchy 2007 Suchy, T.: Bluetoothbasiertes Informationssystem- Konzeption und Realisation eines Prototypen für 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. 1–13 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 Tübingen 2012 ZDV Tübingen: Login Webmail Universität Tübingen. 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 978–0–7695– 3989–8, 121–125 ZKA 2009 ZKA: Richtlinien für einheitliche Zahlungsverkehrsvordrucke. 2009

92

© Stefan Gfrörer

Peer-to-Peer Payment via NFC

A. Anhang

© Stefan Gfrörer

i

Peer-to-Peer Payment via NFC A. Anhang

ii

© Stefan Gfrörer

Bank-Modul eKaay Token Prüft, ob PIN Eingabe benötigt wird Bestätigt Transaktion eKaay PIN Bestätigt Login Weiterleitung eKaay TAN Fordert Challenge für Registrierung von eKaay an Login Fordert Challenge für TAN an Fordert Challenge für TAN an Konto-Einstellungen Bestätigt Transaktion Überweisungsformular Shop-Modul Shopseite Fordert Überweisung für Produkt an eKaayCash Formular Fordert Challenge für Login an Proxy Prüft, ob Registrierungstoken abgelaufen ist eKaay

© Stefan Gfrörer
eKaay-Modul Transaktionsbestätigung Transaktionsbestätigung Fragt Korrektheit der Transaktion ab

Hauptseite

Logout

im eKaayCash System (eigene Darstellung).

Der Anwender ruft Webseiten auf und führt einzelne Aktionen aus.

Registrierung

Peer-to-Peer Payment via NFC

Abbildung A.1.: Die unterschiedlichen Module mit den dazugehörenden Webseiten

Konten- und TransaktionsÜbersicht

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 prüfen und bestätigen.
eKaay

A. Anhang

Alice (Geldempfänger)

Bitte bestätigen
Datum: 20.4.2012 Uhrzeit: 10:00:00 Empfaenger: Alice Betrag: 100.00 Euro

Peer-to-Peer Payment via NFC

Cash (eigene Darstellung).
2. Der Server antwortet mit der Challenge in Form des QR Codes und des NFC Links. Die Challenge enthält eine Nonce und die Transaktionsdaten als Text. 5. Nach Bestätigung der Transaktion erzeugt die eKaay App eine Response zu der Challenge und überträgt diese an den Server. abbrechen 6. Der Server prüft die Response und führt die Transaktion bei Korrektheit aus. Server der Bank 7. Mit Abschluss der Transaktion erhalten der Geldempfänger und der Zahlende eine Bestätigung.

OK

1. Der Geldempfänger füllt das Überweisungsformular aus und übeträgt den Betrag und den Verwendungszweck an den Server.

Abbildung A.2.: Der vollständige Ablauf einer Peer-to-Peer Transaktion mit eKaay-

© Stefan Gfrörer

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 prüfen und bestätigen.
eKaay

Kunde

© Stefan Gfrörer
Bitte bestätigen
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 für die Überweisung ab.

weiterung für eKaayCash (eigene Darstellung).
4. Der Server der Bank antwortet mit der Challenge in Form des QR. Die Challenge enthält eine Nonce und die Transaktionsdaten als Text. 8. Der Server der Bank informiert den Server des Shops über die abgeschlossene Überweisung. Die Bestätigung enthält alle Überweisungsdaten. 9. Der Server des Shops stellt eine Anfrage an den Server der Bank mit den erhaltenen Überweisungsdaten. 10. Der Server der Bank prüft die Überweisungsdaten und bestätigt die Korrektheit. Server der Bank

1. Der Kunde ruft den Shop auf.

7. Nach Bestätigung der Transaktion erzeugt die eKaay App eine Response zu der Challenge und überträgt diese an den Server der Bank.

Peer-to-Peer Payment via NFC

Server des Shops

Abbildung A.3.: Der vollständige Ablauf eines Einkaufs in einem Shop mit der Er-

v