Mobile Payment - Entwurf und Implementierung einer HBCI-FinTS-Banking Lösung für mobile Geräte

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Aufbau der Arbeit

2 Grundlagen
2.1 Homebanking Computer Interface
2.1.1 Einführung
2.1.2 Syntax
2.1.3 Kommunikation
2.1.4 Sicherheit
2.2 Near Field Communication
2.2.1 Einführung
2.2.2 Active Mode
2.2.3 Passive Mode
2.3 Verteilte Systeme
2.3.1 Einführung
2.3.2 Fehlannahmen
2.3.3 Multithreading und Race Conditions .

3 Anforderungsanalyse
3.1 Mobile Payment
3.1.1 Akzeptanz von Zahlungsmethoden
3.1.2 Kategorisierung von Zahlungssystemen .
3.1.3 Phasen des Mobilen Payments
3.1.4 Ausblick
3.2 Betrachtung existierender Lösungen
3.2.1 Bewertung der Systeme
3.2.2 Fazit

4 Anforderungsdefinition
4.1 Systembeschreibung
4.2 Festlegung der Zielgruppe
4.3 Abgrenzung des Systems
4.4 Anforderungen an die Softwarequalität
4.5 Anforderungen an die Benutzeroberfläche
4.6 Funktionale Anforderungen
4.7 Nicht-Funktionale Anforderungen

5 Entwurf
5.1 Evaluierung benötigter Frameworks
5.2 Beschreibung der Systemarchitektur
5.3 Entwurf der Benutzeroberfläche
5.3.1 Admin Client
5.3.2 Mobiler Client
5.4 Entwurf des Datenbankmodells
5.4.1 Entity-Relationship-Modell
5.4.2 Überführung in das relationale Modell . .
5.5 Entwurf der Schnittstellen
5.5.1 Payment Server und Admin Client
5.5.2 Payment Server und mobiler Client
5.6 Entwurf der Geschäftslogik
5.6.1 Erzeugung einer RDH-Schlüsseldatei
5.6.2 Anlegen eines neuen Kontos

6 Implementierung
6.1 Vereinbarungen vor Beginn der Implementierung
6.1.1 Allgemeines
6.1.2 Projektarchitektur
6.1.3 Fehlerbehandlung
6.2 Implementierung des Payment Servers
6.2.1 Erzeugen der Datenbank
6.2.2 Stellen von SQL-Anfragen
6.2.3 Gewährleistung der Sicherheit
6.2.4 Kommunikation der Komponenten
6.2.5 Erweiterung von HBCI4Java
6.2.6 Das Payment Framework
6.3 Implementierung des Admin Clients
6.3.1 Implementierung des Oberflächenlayouts
6.3.2 Nutzung des Notification Musters
6.3.3 Validieren der Nutzereingaben
6.4 Implementierung des mobilen Clients
6.4.1 Implementierung des Oberflächenlayouts .
6.4.2 Implementierung des NFC-Authenticator
6.4.3 Nutzung des Payment-Frameworks
6.5 Probleme und Lösungen
6.5.1 Filtern gleicher Umsätze eines Kontos
6.5.2 Relation zwischen Umsatz und Transaktion erzeugen

7 Test
7.1 Verwendung von Testmethoden
7.2 Demonstration der Funktionalität des Prototypen

8 Ergebnis
8.1 Abschließende Betrachtung
8.2 Veröffentlichung
8.3 Ausblick

A Liste der Funktionalen Anforderungen

B Screenshots und Grafiken

C Sonstige Anlagen

Abbildungsverzeichnis

Tabellenverzeichnis

Literaturverzeichnis

1 Einleitung

1.1 Motivation

Die rasante Verbreitung von Smartphones hat den Markt des Mobilen Payments bedeutend verändert.¹ So ist es heute nichts Besonderes mehr ein Buch oder einen Film von der Couch aus, direkt über ein Smartphone zu kaufen und zu bezahlen. Eine Studie des Handelsblatts² geht davon aus, dass die Verbreitung von mobilen Geräten in den nächsten Jahren noch deutlich zunehmen wird. Gemäß dieses Trends wird klar, wieso der Bereich des Mobilen Payments in der Forschung und Wirtschaft aktuell so heiß diskutiert wird.

Das Bezahlen mit dem Smartphone soll immer mehr in den Alltag der Menschen rücken und zwangsläufig die klassische Geldbörse ersetzen. Die Chancen dafür stehen gut, denn bereits 83% aller Deutschen ab 14 Jahren besitzen ein Mobiltelefon. Da zahlreiche Nutzer ein Zweitgerät haben, gibt es insgesamt sogar mehr Endgeräte als Einwohner.³

Aufgrund der zunehmenden Bedeutung des Mobilen Payments versuchen Anbieter be- stehender Zahlungssysteme ihre Softwaresysteme so zu erweitern, dass sie neben dem digitalen Markt auch den analogen Markt abdecken können. Unter dem Begriff des analogen Marktes versteht man die Menge der im Ladengeschäft über ein Smartphone abgewickelten Bezahlvorgänge. Diese Fortentwicklung der Systeme ist nachvollziehbar, denn zum einen erhoffen sich die Unternehmen eine Vergrößerung der potenziellen Ziel- gruppe und des resultierenden Umsatzes, zeitgleich wollen sie aber auch dafür sorgen, dass das Bezahlen für die Verbraucher sicherer und einfacher wird.

In Japan existieren bereits seit Anfang 2004 Anbieter von Zahlungssystemen, die die Initiierung des Bezahlvorgangs per Near Field Communication für den analogen sowie digitalen Markt unterstützen. Das Unternehmen FeliCa Networks wurde Ende 2003 gegründet und ist ein Joint Venture von Sony, NTT DoCoMo und Japan Railways. FeliCa Networks agiert als Trusted Service Manager und bildet das neutrale, vertrauenswürdige Bindeglied zwischen den verschiedenen Dienstleistern, die für die Abwicklung des Be- zahlvorgangs per NFC⁴ benötigt werden. Der Dienst FeliCa Mobile wurde im Juni 2004 gelauncht und von Vodafone und KDDI im Februar 2005 adaptiert. FeliCa Mobile gilt als der De-facto-Standard in der japanischen NFC-Industrie, denn inzwischen wurden bereits über 53 Mio. Handys mit FeliCa verkauft und über 70 Firmen bieten FeliCa-basierte Applikationen aus dem Bereich Payment, Ticketing oder Loyalty⁵ an. Der durch das System generierte Umsatz lag 2006 bei umgerechnet 900 Mio. USD, wobei sich die Zahl der Transaktionen alle vier Jahre um den Faktor 10 erhöht.⁶

Nach einer Studie des Unternehmens Capgemini⁷ aus dem Jahr 2009 besteht ein unge- brochenes Interesse an einer Mobilen Payment Lösung für den deutschen Markt. Etwa 1,3 Mio. Deutsche würden sogar bis zu 5,00 EUR pro Monat für die Nutzung eines M-Payment-Dienstes ausgeben, um so die marktreife Etablierung des Systems zu fördern.

Das Beratungsunternehmen schätzt das mögliche Marktvolumen in Deutschland auf 600 Mio. Euro allein durch Endkundengebühren, das heißt ohne Transaktionsgebühren.

Demnach besteht langfristig ein großes Potenzial für das Mobile Payment als Ersatz oder Ergänzung existierender Zahlungsmittel wie Bargeld. Ein Drittel der Bevölkerung ist zwar noch unentschieden, könnte aber durch einen höheren Bekanntheitsgrad für den neuen Zahlungsweg gewonnen werden.

1.2 Zielsetzung

Ziel der Arbeit ist es, einen Prototypen zur Abwicklung eines Bezahlvorgangs mithilfe eines mobilen Gerätes zu entwickeln. Im ersten Schritt soll das Softwaresystem für den digitalen Markt konzipiert werden. Es soll aber die technische Möglichkeit bestehen, das System ebenfalls für den analogen Markt einzusetzen. Die Identifizierung des Nutzers gegenüber dem System soll auf generische Weise erfolgen.

Abhängig vom Einsatz des Systems kann sich der Nutzer z.B. über ein NFC-basiertes Legitimationsmittel oder einen bestehenden Nutzeraccount eines anderen PaymentDienstleisters⁸ legitimieren.

Das System soll auf einer dezentralen Architektur basieren, d.h. die Software wird von den Händlern direkt betrieben und verzichtet auf einen zentralen Dienstleister. Die Software soll den Bezahlvorgang direkt mit dem Bankserver realisieren, sodass keine Transaktionsgebühren an einen dritten Dienstleister zu zahlen sind. Durch die Nutzung einer dezentralen Architektur ist auch eine Erhöhung der Datensicherheit gegeben, da die sensiblen Abrechnungsdaten nicht auf einem zentralen Server hinterlegt werden und daher kein zentraler Angriffspunkt für einen Datendiebstahl existiert.

Nachfolgend wird die Software entsprechend als Zahlungssystem bezeichnet. Grundlegend soll der zu entwickelnde Prototyp die folgenden Anforderungen erfüllen:

- Unterstützung des digitalen und analogen Marktes
- Möglichkeit der generischen Identifizierung des Nutzers
- Nutzung der Near Field Communication
- Unterstützung akzeptierter Zahlungsmethoden
- Verwendung einer dezentralen Architektur
- Direkte Realisierung der Zahlung
- Geringe Kosten für Händler
- Hohe Sicherheit

Der entstandene Prototyp soll mit einer Beispielapplikation getestet und die Funkti- onsweise vorgeführt werden. Für das Testszenario soll neben dem Zahlungssystem eine Android-Applikation entwickelt werden, mit der die Studenten der HTW-Berlin Sport- kurse buchen und direkt über das Smartphone bezahlen können. Die Legitimierung der Studenten soll über ein NFC-basiertes Identifikationsmittel erfolgen.

Im theoretischen Teil der Arbeit soll untersucht werden, was unter dem Begriff des Mobilen Payments zu verstehen ist. Dabei sollen die verschiedenen Phasen des Bezahlvorgangs vorgestellt und ein Ausblick auf neue Techniken und Lösungen gegeben werden. Des Weiteren werden bestehende Zahlungssysteme und Einflussfaktoren auf deren Akzeptanz beleuchtet. Die vorgestellten Zahlungssysteme sollen kategorisiert und anhand verschie- dener Kriterien wie Sicherheit, unterstützte Zahlungsverfahren, Marktdurchdringung, Kosten für den Händler, Unterstützung des NFC-Payments, Risikomanagement, Integra- tion, Unterstützung mobiler Techniken und Gewährleistung der Anonymität bewertet werden.

Abschließend soll überprüft werden, ob die bestehenden Zahlungssysteme in Deutschland die Brieftasche bereits ersetzen können oder falls nicht, wie es lange es dauern wird, bevor ein solches System am Markt zu etablieren ist.

1.3 Aufbau der Arbeit

Der folgende Hauptteil der Arbeit ist in sieben logische Kapitel gegliedert: Grundla- gen, Anforderungsanalyse, Anforderungsdefinition, Entwurf, Implementierung, Test und Ergebnis.

Zu Beginn der Arbeit sollen die erforderlichen Grundlagen vorgestellt und erläutert werden, um einen gemeinsamen Wissensstand zu schaffen, auf dem die restliche Arbeit aufbauen kann.

In der darauf folgenden Anforderungsanalyse wird der Themenkomplex des Mobilen Payments gemäß der in der Zielsetzung definierten Punkte beleuchtet. Mit den gewonnenen Erkenntnissen werden in der Anforderungsdefinition die Anforderungen an den Prototypen hinsichtlich der Systemarchitektur, der Softwarequalität und des Funktionsumfanges festgelegt.

Im anschließenden Entwurf werden diese Anforderungen technisch analysiert und in geeignete Modelle gegossen. Hierzu gehören u.a. eine geeignete Systemarchitektur, das Datenbankmodell, die benötigten Schnittstellen für die Kommunikation zwischen den Systemkomponenten sowie die grafischen Benutzeroberflächen. Des Weiteren sollen die zu verwendenden Technologien hinsichtlich ihrer Eigenschaften und ihrer Eignung beleuchtet werden.

Im Anschluss werden Details und Besonderheiten der Implementierung des Zahlungssys- tems vorgestellt. Trotz einer ausführlichen Analyse und eines sauberen Entwurfs sind nicht alle Probleme während der Implementierung vorhersehbar. Diese Probleme und vor allem die entsprechenden Lösungen werden ebenfalls in diesem Kapitel vorgestellt.

Im anschließenden Test werden die verwendeten Testmethoden vorgestellt, die Funktio- nalität des Prototypen demonstriert und für den Leser dokumentiert.

Am Ende der Arbeit wird im Kapitel Ergebnis ein Fazit gezogen und überprüft, ob die gesteckten Ziele erreicht wurden. Weiterhin wird die Zukunft des Projekts und eine mögliche Veröffentlichung des Prototypen beleuchtet, um das Ergebnis für alle Interessierten frei nutzbar zu machen.

Der abschließende Anhang enthält eine Liste der funktionalen Anforderungen, Abbildun- gen, Screenshots sowie sonstige, nicht in den Fließtext gehörende Dokumente.

2 Grundlagen

Dieser Kapitelabschnitt soll den Leser in die Technologie des Homebanking Computer Interface und der Near Field Communication sowie in die Entwicklung eines verteilten Systems einführen.

2.1 Homebanking Computer Interface

2.1.1 Einführung

Das Homebanking-Computer-Interface¹ wurde vom Zentralen Kreditausschuss² erstmalig im Jahr 1998 vorgestellt. Der ZKA ist ein Zusammenschluss deutscher Banken, der es sich u.a. zur Aufgabe gemacht hat, standardisierte Schnittstellen für den Zahlungsverkehr zu entwickeln.

Die erste praxistaugliche Version des HBCI-Standards folgte Anfang 1999 in der Version HBCI V2.1. Im Jahr 2000 wurde die Version HBCI V2.2 vorgestellt, die sich lediglich durch ergänzte Geschäftsvorfälle von der Vorgängerversion unterschied.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 HBCI als einheitliche Schnittstelle

Die grobe Architektur des HBCI-Standards ist der Abbildung 1 zu entnehmen. Das Endgerät kommuniziert unter Verwendung der Sicherheitsverfahren über das HBCI- Protokoll mit dem entfernten Bankserver. Die verwendeten Sicherheitsverfahren RDH und DDV werden im Abschnitt 2.1.4 genauer vorgestellt. Auf das Sicherheitsverfahren Pin-Tan wird nicht näher eingegangen, da es sich nicht für die automatisierte Abwicklung eines Bezahlvorgangs eignet.

Bei der Entwicklung des Standards hat sich der ZKA die folgenden Punkte³ zum Ziel gesetzt:

- Unabhängigkeit vom Endgerätetyp und vom Transportnetz
- Verbesserung des Bedienungskomforts für den Endkunden
- Gewährleistung der Betriebssicherheit
- Multibankfähigkeit durch standardisierte Schnittstelle
- Attraktivität durch die Erschließung neuer Geschäftsarten
- Integration in die Struktur der Kundensysteme
- Erschließung neuer Geschäftsfelder im E-Commerce Bereich

Um den Standard an aktuelle Sicherheitsmerkmale und Kommunikationsstandards anzu- passen, wurde die Nachfolgerversion V3.0 im Jahr 2002 veröffentlicht. In dieser Version wurde der HBCI-Standard in Financial Transaction Services⁴ umbenannt und FinTS V3.0 ist die inzwischen am Markt etablierte Version des ehemaligen HBCI-Standards. Er enthält neben einer redaktionellen Neustrukturierung der Dokumentation eine Einführung von Sicherheitsklassen für die Geschäftsvorfälle. Sicherheitsverfahren mit elektronischer Signatur wie Chipkarten oder selbst erzeugte RSA-Schlüsseldisketten wurden erstmals offiziell freigegeben. Auch das Sicherheitsverfahren PIN-TAN steht seit dieser Version als Zwei-Schritt-Verfahren für die verschiedenen Ausprägungen iTAN, chipTAN und mobileTAN zur Verfügung.

FinTS V4.0 ist die aktuellste Version der FinTS-Spezifikation, die 2006 eingeführt wurde.

Sie berücksichtigt erstmalig auch Internettechnologien wie HTTPS, XML und XML- Sicherheitstechniken. Auch innerhalb des Protokolls sind zahlreiche Verbesserungen umgesetzt worden. Zum Beispiel können Geschäftsvorfälle bereits mit der Initialisierung mitgeschickt werden und die Dialogendenachricht⁵ entfällt komplett. Im Extremfall schrumpft so ein gesamter Dialog zu einem sogenannten FinTS-Datagramm zusammen, was den Weg für asynchrone Übertragungswege wie E-Mail öffnet. Mit dieser Technik werden auch Abonnements möglich, um z.B. automatisch Umsatzübersichten zugesandt zu bekommen.

Von den rund 4500 Banken in Deutschland unterstützen offiziell 10 Banken den FinTS- Standard V4.0 und das rund 5 Jahre nach seiner Einführung⁶. Im Gegensatz dazu unterstützen rund 91% der Banken den FinTS-Standard V3.0. Aus diesem Grund wird fortab die Version FinTS V3.0 als Referenz für diese Arbeit gewählt.

2.1.2 Syntax

Zeichensatz

Der Basiszeichensatz baut auf dem international normierten Zeichensatz ISO-8859⁷ auf. Ferner wird in den Bankparameterdaten⁸ der sprachspezifische Subset des ISO-8859 eingestellt. Codeset und Subset definieren gemeinsam den FinTS-Basiszeichensatz. Dieser gilt grundsätzlich für sämtliche nicht-binären Datenelemente. Trennzeichensyntax FinTS verwendet eine Trennzeichensyntax zur Darstellung der Daten innerhalb einer Nachricht. Eine Trennzeichensyntax hat den Vorteil der Flexibilität und Minimierung des Datenvolumens, denn es werden nur Daten für die aktuell benötigte Länge übertragen.

Beschreibende Informationen wie Feldnamen und Feldlängen sind implizit in der jeweiligen Segmentdefinition enthalten. Optionale Felder einer Datenstruktur stehen jeweils am Ende und können so problemlos weggelassen werden.

Mithilfe der Trennzeichen⁹ aus der Tabelle 1 können syntaktische Einheiten innerhalb einer Nachricht gebildet werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Definierte Trennzeichen und deren Bedeutung in FinTS

Syntaktische Einheiten

Datenelemente entsprechen den einzelnen Feldern eines Segmentes. Im einfachsten Fall wird durch ein Datenelement z.B. eine Bankleitzahl codiert. Datenelemente besitzen keinen Overhead in Form eines Headers. Die Felder und deren Eigenschaften sind implizit über die Position innerhalb des Segmentes beschrieben.

Datenelementgruppen sind logisch zusammengehörige Datenelemente. Die in den Daten- elementgruppen enthaltenden Elemente werden als Gruppendatenelemente¹⁰ bezeichnet.

Segmente fassen alle logisch zusammengehörigen Datenelemente¹¹ und Datenelementgruppen¹² zusammen. Im bankfachlichen Sinn entspricht ein Segment im Allgemeinen einem Geschäftsvorfall, z.B. einer Lastschrift.

Nachrichtenaufbau

Der allgemeine Aufbau einer FinTS-Nachricht kann Abbildung 2 entnommen werden. Jede FinTS-Nachricht beginnt mit dem Nachrichtenkopf, welcher ein spezielles Steuersegment ist und am Anfang aller Kreditinstituts- und Kundennachrichten steht. Er beinhaltet z.B. die Nachrichtengröße, die Nachrichtennummer und die genutzte FinTS-Version.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Aufbau einer FinTS Nachricht (Stein 2011)

Optional enthält die Nachricht einen Chiffrierkopf, der für die Verschlüsselung der Nach- richt genutzt wird. Er enthält Informationen über die Art des Sicherheitsverfahrens, die Verschlüsselungsfunktion und die zu verwendenden Chiffrierschlüssel. Mithilfe der optionalen Signaturköpfe wird die Nachricht signiert und so gegen nachträgliche Verände- rungen geschützt. Zusätzlich enthält der Signaturkopf eine eindeutige Referenznummer, die zur Doppeleinreichungskontrolle seitens des Kreditinstituts genutzt wird.

Erst die Kombination von mehreren Segmenten bildet eine FinTS-Nachricht, die als abge- schlossene Einheit an das Kreditinstitutssystem übertragen werden kann. Im Gegensatz zu den Einheiten DE und DEG wird ein Segment zusätzlich durch einen administrativen Header beschrieben, den sogenannten Segmentkopf. Darin befindet sich eine eindeutige Segmentkennung, über die auf den Inhalt des Segmentes geschlossen werden kann. So beschreibt die Segmentkennung HKLAS z.B. die Kundennachricht für eine Lastschrift. Seg- mente werden durch das Segmentende-Zeichen abgeschlossen. Innerhalb einer Nachricht können sich mehrere gleichartige Geschäftsvorfall-Segmente, also z.B. fünf Lastschriften, befinden.

Im Signaturabschluss wird die Signatur des Übermittlers übertragen, mit der die sig- nierte Nachricht vom Empfänger überprüft werden kann. Durch den anschließenden Nachrichtenabschluss wird die entsprechende Nachricht beendet.

2.1.3 Kommunikation

FinTS ist ein dialogorientiertes Protokoll. Innerhalb eines Dialoges werden zwischen dem System des Kunden und dem Bankserver die FinTS-Nachrichten ausgetauscht. Der Aufbau eines solchen Dialoges vollzieht sich nach einem bestimmten Schema, welches in Abbildung 3 dargestellt ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Schematischer Aufbau eines FinTS-Dialoges (Stein 2011)

Der FinTS-Client eröffnet den Dialog durch eine Dialoginitialisierungsnachricht. Im Rah- men der Dialoginitialisierung werden die Verschlüsselungs- und Komprimierungsverfahren ausgehandelt und die Stände der Bankparameterdaten¹³ und Userparameterdaten¹⁴ ab- geglichen. Nach erfolgreicher Initialisierung des Dialoges werden die Aufträge durch Auftragsnachrichten erteilt, die anschließend vom Banksystem beantwortet werden. Der dargestellte Ablauf zeigt, dass ein FinTS-Dialog grundsätzlich synchron abläuft, d.h. jede Nachricht vom Kreditinstitut beantwortet werden muss, bevor eine neue Kundennachricht gesendet werden kann. Für die entsprechende Nutzerkennung darf immer nur ein aktiver Dialog geöffnet sein, da andernfalls die Ausführung der FinTS-Nachrichten durch den Bankserver verweigert wird. Wenn alle Auftragsnachrichten abgearbeitet sind, schließt der FinTS-Client die Verbindung durch eine Dialogbeendigungsnachricht.

Bankparameterdaten

In den Bankparameterdaten wird dem FinTS-Client die Infrastruktur des jeweiligen

Kreditinstituts mitgeteilt. Es werden dort u.a. die folgenden Informationen ausgetauscht:

- Exakter Name des Instituts, unterstützte Sprachen und Zeichensatz
- Verfügbare Transportmedien und Verschlüsselungs- und Komprimierungsverfahren
- Restriktionen zu Geschäftsvorfällen (max. Anzahl von Verwendungszweckzeilen)

Userparameterdaten

Mithilfe der Userparameterdaten werden dem FinTS-Client spezifische Daten über das

Bankprofil des Users mitgeteilt. Diese beinhalten im Allgemeinen:

- Benutzerkennung und Daten zur Versionskontrolle
- Erlaubte Geschäftsvorfälle für die Benutzerkennung
- Konto- und Produktinformationen (z.B. Limit des Kontos)

2.1.4 Sicherheit

Durch die Nutzung des Internets als unsicheres Kommunikationsmedium musste bei der Entwicklung des Standards ein besonderes Augenmerk auf die Erhöhung der Sicherheit gelegt werden. Zeitgleich sollten die verwendeten Verfahren aber handhabbar für den Endnutzer bleiben. In der FinTS-Spezifikation¹⁵ werden deshalb die beiden Verfahren Message Authentication Code¹⁶ und Rivest-Shamir-Adleman¹⁷ vereinbart, welche in den folgenden Abschnitten erläutert werden. Folgende Kernaspekte¹⁸ werden mit den beiden Verfahren erreicht:

Herkunftsnachweis: Durch die elektronische Signatur kann die Herkunft der eingereichten Aufträge eindeutig bestimmt werden.

Geheimhaltung: Die Geheimhaltung bleibt durch die Verschlüsselung der Nachrichten zwischen den Kommunikationspartnern gewahrt.

Validität: Durch einen Sequenzzähler können doppelt eingereichte Nachrichten gefiltert werden. So kann verhindert werden, dass ein Angreifer Nachrichten verfälschen und erneut

einreichen kann.

Integrität: Durch die elektronische Signatur und einen Hashwert über die gesamte Nachricht kann die Integrität der Nachricht sichergestellt werden.

Authentizität: Beide Kommunikationspartner können die jeweiligen Signaturen überprüfen und sichergehen mit der korrekten Gegenstelle zu kommunizieren.

RSA-Verfahren (Rivest-Shamir-Adleman)

Im folgenden Abschnitt wird die erstmalige Einrichtung des RSA-Verfahrens gemäß

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 beschrieben. Das nach seinen Erfindern benannte asymmetrische Verfahren verwendet Schlüsselpaare, welche aus einem privaten Schlüssel und einem öffentlichen Schlüssel bestehen. Das RSA-Verfahren wird u.a. auch für SSL¹⁹ verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Schlüsselverteilung beim RSA-Verfahren (Hermanns 2001)

Nachdem der Kunde einen formlosen Antrag auf Nutzung der FinTS-Kommunikation (1) eingereicht hat, erhält er per Post den öffentlichen Schlüssel (2) und die Kommunikations- parameter der Bank. Ein Exemplar der Deutschen Bank ist dieser Arbeit als Anlage 47ff.

beigefügt. Im nächsten Schritt erzeugt der Kunde per FinTS-Software seine persönlichen Schlüsselpaare (3), indem er die von der Bank erhaltenen Daten in die entsprechenden Felder der Software eingibt und versendet im vierten Schritt (4) seine öffentlichen Schlüs- sel an den Bankserver. Aus den generierten Daten wird ein INI-Brief²⁰ erzeugt (5), der unterschrieben an die Bank gesendet werden muss. Der INI-Brief wird zur Validierung der öffentlichen Schlüssel und zur anschließenden Freischaltung des FinTS-Zugangs benö- tigt. Die Bank vergleicht die auf dem INI-Brief vermerkten Hashwerte²¹ der öffentlichen

Nutzerschlüssel und kann somit den korrekten Empfang der Schlüssel bestätigen (6). Im Anschluss schaltet die Bank den FinTS-Zugang (7) frei.

Bei FinTS werden zwei verschiedene Schlüsselpaare verwendet, ein Signierschlüsselpaar zum Signieren der Daten und ein Chiffrierschlüsselpaar zum Verschlüsseln der Daten. Der Kunde signiert die Aufträge mit seinem privaten Schlüssel. Die Bank kann mittels des zuvor legitimierten öffentlichen Schlüssels die elektronische Unterschrift auf Korrektheit prüfen. Der öffentliche Schlüssel muss, wie es der Name andeutet, nicht geheim gehalten werden, da mit ihm nur Signaturen überprüft, aber nicht erzeugt werden können. Analog dazu kann der Kunde vertrauliche Informationen an die Bank mit dem öffentlichen Schlüssel der Bank verschlüsseln. Nur diese kann anschließend die Daten mit ihrem privaten Schlüssel wieder entschlüsseln.

Das RSA-Verfahren wird oft auch als RDH-Verfahren (RSA-DES-Hybrid) bezeichnet. Die erzeugten Schlüsselpaare können auf einer Chipkarte, Diskette oder in einer pass- wortgeschützten Datei gespeichert werden. MAC-Verfahren (Message Authentication Code) Das symmetrische MAC-Verfahren verwendet für beide Kommunikationspartner einen gemeinsamen Schlüssel, der nur beiden Partnern bekannt sein darf (secret key). In Abbildung 5 wird die Verteilung der Schlüssel beschrieben. Wie bereits im RSA-Verfahren werden auch hier zwei Schlüsselpaare verwendet, der Signier- und Chiffrierschlüssel. Die bei diesem Ansatz eingesetzten Verschlüsselungsverfahren basieren auf dem Triple-DES- Verfahren und die erzeugten Schlüssel werden auf einer Chipkarte verteilt und verlassen diese aus Sicherheitsgründen niemals. In der Spezifikation wird das Verfahren oft auch als DES-DES-Verfahren (DDV) bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Schlüsselverteilung beim MAC-Verfahren (Hermanns 2001)

Im weiteren Verlauf der Arbeit wird nur noch das RDH-Verfahren betrachtet, da dieses Verfahren ohne Chipkarte und damit für einen entfernten Serverbetrieb einsetzbar ist. Es kann nicht davon ausgegangen werden, einen Chipkartenleser im entfernten Rechenzen- trum installieren zu können.

2.2 Near Field Communication

2.2.1 Einführung

Near Field Communication ist eine drahtlose Kommunikationstechnik, mit welcher im Nahbereich Daten zwischen elektronischen Geräten ausgetauscht werden können. So wer- den in der Praxis z.B. Telefonnummern oder Visitenkarten ausgetauscht oder bestimmte Dienste abgerufen oder angestoßen.

Der Unterschied zu klassischen RFID-Systemen ist, dass die strikte Trennung zwischen Lesegerät und Transponder aufgehoben ist. Bei RFID-Systemen gibt es immer eine aktive und passive Komponente und der Datenaustausch erfolgt nach dem Frage-Antwort- Prinzip, bei dem immer das Lesegerät den Nachrichtenaustausch beginnt. Das Lesegerät vertritt dabei immer die aktive Seite und versorgt den passiven RFID-Chip mit Strom.²² Ein NFC-System integriert hingegen beide Zustände, die des Lesegerätes und des Chips und ermöglicht so eine bidirektionale Kommunikation zwischen den NFC-Geräten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Die Rollen beim NFC-Verfahren (Langer 2010)

Der NFC-Funktechnik liegt die Induktion zugrunde. Dabei erfolgt der Datenaustausch über die induktive Kopplung zwischen zwei Induktivitäten. Die eine Induktivität ist die des sogenannten Initiators, die andere die des Targets. Die magnetischen Felder strahlen mit Hochfrequenz von 13,56 MHz vom Initiator zum Target.²³ Die Technik erzielt eine Übertragungsrate von 106 kBit/s bis zu maximal 424 kBit/s und ist nach ISO 18092 standardisiert.²⁴

In der Literatur²⁵ wird zwischen zwei verschiedenen Übertragungsverfahren unterschieden, welche im Folgenden kurz erläutert werden.

2.2.2 Active Mode

Bei einem aktiven Übertragungsverfahren zwischen zwei NFC-fähigen Schnittstellen übernimmt eines der Geräte den Part des Initiators, indem die Schnittstelle ihren Sender aktiviert. Beim aktiven Verfahren müssen beide Schnittstellen mit externer Energie versorgt werden, welche sie durch die Spannungsversorgung des jeweiligen Geräts beziehen, in dem sie verbaut sind.

Sowohl der Initiator als auch das Target sind so in der Lage ein Radiofrequenz-Magnetfeld durch den fließenden Strom zu erzeugen. Erfasst die zweite NFC-Schnittstelle das vom Initiator erzeugte magnetische Feld durch seine Antennenschleife, so nimmt dieses Interface automatisch die Rolle des NFC-Targets ein. Anschließend startet die Konfiguration zwischen den beiden Schnittstellen, indem das NFC-Target Antworten auf die Fragen des Initiators gibt. Sobald die Konfigurationsphase abgeschlossen ist, kann der eigentliche Datenaustausch beginnen. Die Rollen der beiden NFC-Schnittstellen können getauscht werden, indem die Senderichtung der beiden Antennen umgekehrt wird. Um dieses zu ermöglichen, muss das NFC-Target den Sender aktivieren und wird somit zum NFCInitiator. Auf diese Weise können Daten wechselseitig übertragen werden.²⁶

2.2.3 Passive Mode

Beim passiven Übertragungsverfahren wird ebenfalls ein magnetisches Wechselfeld erzeugt, welches auch durch den NFC-Initiator ausgelöst wird. Das passive NFC-Target selbst erzeugt kein magnetisches Feld, sondern moduliert das existierende magnetische Feld des Initiators. Durch diese Modulation des bestehenden Magnetfelds werden die eigentlichen Daten übertragen. Das NFC-Target benötigt dazu keine eigene Energiezufuhr, da „es die benötigte Energie aus dem elektromagnetischen Feld des Initiators - z.B. mithilfe eines auf die Funkfrequenz eingestellten Schwingkreises - induktiv beziehen kann.“²⁷ Dieses Vorgehen findet ebenfalls bei den klassischen RFID-Systemen Anwendung.

2.3 Verteilte Systeme

2.3.1 Einführung

Bei der Implementierung eines mobilen Zahlungssystems muss zwangsweise auf die Architektur eines verteilten Systems zurückgegriffen werden, da eine örtliche Trennung der mobilen Clients und des Dienstservers gegeben ist. Aufgrund der Wichtigkeit einzelner Aspekte verteilter Systeme im Rahmen der Implementierung sollen diese im folgenden Abschnitt kurz erläutert werden.

Ein verteiltes System ist dabei als eine Ansammlung unabhängiger Computer zu ver- stehen, die dem Nutzer als einzelnes kohärentes System erscheinen.²⁸ Die grundlegende Architektur kann der Abbildung 7 entnommen werden. In einem verteilten System sind mehrere Rechner, die über eine spezifische Rechnerarchi Architektur übergreifende Kommunikation ermöglichen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Architektur eines verteilten Systems

2.3.2 Fehlannahmen

Für verteilte Systeme sind viele Aspekte gleichzeitig zu beachten, denn im Unterschied zu herkömmlicher Software sind die einzelnen Komponenten im Netzwerk verstreut. Diese Verteilung während des Entwurfes nicht zu berücksichtigen, macht viele Systeme unnötig komplex und führt zu Fehlern bei der Wartung und Weiterentwicklung. Peter Deutsch, damals Softwareentwickler bei Sun Microsystems, formulierte aus diesem Grund die folgenden Fehlannahmen²⁹, die jedem unterlaufen, der zum ersten Mal eine verteilte Anwendung entwickelt:

- Das Netzwerk ist zuverlässig, sicher und homogen.
- Die Topologie ändert sich nicht.
- Die Latenzzeit beträgt null.
- Die Bandbreite ist unbegrenzt.
- Die Übertragungskosten sind null.

Die entsprechenden Lösungsstrategien zur Umgehung dieser Fehlannahmen werden in den Kapiteln Entwurf und Implementierung vorgestellt.

2.3.3 Multithreading und Race Conditions

Die Kommunikationsschnittstelle zwischen Client und Server innerhalb eines verteilten Systems wird in der Regel nach dem Dispatcher-Worker-Modell (vgl. Abbildung 8) entwickelt. Das Dispatcher-Worker-Modell sieht vor, dass jede eingehende Anfrage in einem eigenen Worker-Thread vom Server verarbeitet wird. Dieses Vorgehen hat den Vorteil, dass der Server sofort neue Anfragen anderer Clients entgegen nehmen kann und diese nicht auf die Abarbeitung der vorherigen Anfrage warten müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 Das Dispatcher-Worker-Modell (Tanenbaum 2008)

Sobald in einem solchen System eine gemeinsam genutzte Ressource (z.B. Datenbank) verwendet wird, können sogenannte Race Conditions auftreten. Situationen, in denen zwei oder mehrere Prozesse bzw. Threads auf gemeinsame Ressourcen lesend oder schreibend zugreifen und das Endergebnis davon abhängt, welcher Prozess bzw. Thread wann genau läuft, werden Race Conditions genannt.³⁰ Vereinfacht gesprochen wechselt die CPU innerhalb eines Prozesses zwischen den Threads hin und her. Wann ein Thread aktive Arbeitszeit erhält, wird durch den Scheduler des Betriebssystems bestimmt und ist sehr schwer reproduzierbar. Die Threads eines Prozesses teilen sich nicht nur einen Adressraum, sondern können sich auch zusätzlich den gleichen Satz an geöffneten Dateien, Kindprozessen, Alarmen, Signalen usw. teilen. Es kann also sein, dass ein Thread gerade bei einem wichtigen Schreibvorgang inaktiv gesetzt wird und ein anderer Thread die bisherige Arbeit überschreibt.

Um eine Race Condition zu verhindern, wird ein wechselseitiger Ausschluss³¹ auf gemein- sam genutzte Ressourcen benötigt. Die Teile eines Programms, in denen auf gemeinsam genutzte Ressourcen zugegriffen wird, nennt man kritische Region oder kritischen Ab- schnitt.³² Zur Realisierung eines wechselseitigen Ausschlusses wurde das Konzept des Semaphors von Edsger Wybe Dijkstra im Jahre 1962 vorgestellt. Dieses Konzept soll im weiteren Verlauf der Arbeit genutzt werden, um die kritischen Regionen zu synchronisieren.

3 Anforderungsanalyse

3.1 Mobile Payment

Der Begriff Mobiles Payment beschreibt die Technik, mit einem mobilen Endgerät einen elektronischen Bezahlvorgang mittels spezieller technischer Verfahren einzuleiten.

So definiert Key Pousttchi, Wirtschaftsinformatiker an der Universität Augsburg, den Begriff Mobiles Payment (M-Payment) im Jahr 2005 wie folgt: „Der Begriff Mobiles Payment beschreibt diejenige Art der Abwicklung von Bezahlvorgängen, bei der im Rahmen eines elektronischen Verfahrens mindestens der Zahlungspflichtige mobile Kom- munikationstechniken für die Initiierung, Autorisierung und Realisierung der Zahlung einsetzt.“¹

3.1.1 Akzeptanz von Zahlungsmethoden

Abbildung 9 zeigt das Ergebnis einer Expertenumfrage² zu den beliebtesten Zahlungsmethoden im Mobilen Payment.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9 Bevorzugte Zahlungsmethoden für M-Payment in Prozent (Seewald 2010) Bei der Bewertung der einzelnen Methoden stand neben der Transparenz auch die Si- cherheit des Verfahrens im Vordergrund. Wie man der Grafik entnehmen kann, ist das Lastschriftverfahren die am häufigsten präferierte Zahlungsmethode. Dies ist nicht erstaun- lich, da die Abwicklung direkt durch die Banken erfolgt und kein weiterer Dienstleister dazwischen geschaltet ist. Zudem besteht für den Nutzer die komfortable Möglichkeit, die Zahlung sechs Wochen lang zurückzufordern.

Einflussfaktoren auf die Akzeptanz eines Zahlungssystems Ein Zahlungssystem kann nur erfolgreich sein, wenn es sowohl von Kunden als auch Händlern angenommen wird. Um diese Voraussetzung zu erreichen, sind gewisse Einfluss- faktoren zu berücksichtigen.

Abbildung 10 zeigt, dass sich die Bedürfnisse an ein Zahlungssystem mehrheitlich entspre- chen. In zwei dieser Faktoren besteht jedoch ein Zielkonflikt. Die Kundenseite besteht auf eine Möglichkeit des Widerrufs einer Transaktion und würde am liebsten anonym bleiben.

Hingegen besteht die Händlerseite auf eine Zahlungsgarantie sowie die Gewinnung von möglichst vielen Informationen über den Kunden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10 Anforderungen von Kunden und Händlern (Dombret 2008)

Es kann festgehalten werden, dass die Befragten ein besonderes Augenmerk auf die technische Sicherheit von Zahlungssystemen legen. Zudem soll es schnell und einfach zu nutzen sein. Ein weiterer Aspekt sind die resultierenden Kosten, die möglichst gering gehalten werden müssen, um das System erfolgreich am Markt platzieren zu können.

3.1.2 Kategorisierung von Zahlungssystemen

Kategorisierung nach Höhe der Zahlung Ein Ansatz zur Kategorisierung von Zahlungssystemen basiert auf der Höhe der Abrech- nungsbeträge. Demnach können Zahlungssysteme in die folgenden Kategorien unterteilt werden:

Pico-Payment Die kleinsten Beträge werden als Pico-Payment bezeichnet. Hierbei handelt es sich meistens um Cent-Beträge, also Beträge kleiner einem Euro. Da die Beträge gering sind, stehen die anfallenden Kosten meistens in keiner Relation zum Nutzen für den Anbieter.

Micro-Payment Geldbeträge zwischen 1,00 Euro und 10,00 Euro sind dem Micro-Payment anzurechnen. Micro-Payment scheint momentan der Bereich zu sein, der für die mobilen Zahlungssysteme am interessantesten ist. „An der Höhe der Abrechnungsbeträge kann man ablesen, dass eine deutliche Lücke zwischen Bargeld- und Kreditkartenzahlung besteht. Diese Lücke könnte das M-Payment schließen.“³

Macro-Payment Geldbeträge ab 10,00 Euro und mehr werden dem Macro-Payment zugeordnet. Diese Abrechnungsbeträge sind besonders für Zahlungen nicht digitaler Güter, also Waren und Dienstleistungen, von Interesse.

Kategorisierung nach Zeitpunkt der Zahlung Ein weiterer Ansatz zur Kategorisierung von Zahlungssystemen basiert auf dem Zeitpunkt der eigentlichen Zahlung, welcher in Abbildung 11 verdeutlicht wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11 Kategorisierung nach Zeitpunkt der Zahlung

So wird zwischen den Kategorien Pay-Before, Pay-Now und Pay-Later unterschieden. Mit Pay-Before werden Zahlungssysteme beschrieben, bei denen die Belastung des Kontos bereits vor dem eigentlichen Kauf erfolgt und ein sogenanntes Guthaben aufgebaut wird.

Als Beispiel sind die Zahlungssysteme mpass und paysafecard zu nennen, welche in Kapitel 3.2 genauer vorgestellt werden. Pay-Now Systeme sind dadurch gekennzeichnet, dass die Belastung genau zu dem Zeitpunkt des eigentlichen Konsums durchgeführt wird. Als Beispiel ist hier das klassische Lastschriftverfahren per PayPal oder die Online- Überweisung mittels giropay zu nennen. Beide Systeme werden im Kapitel 3.2 genauer vorgestellt. Bei den Pay-Later Systemen wird das Konto des Kunden nach dem eigentlichen Konsum belastet, z.B. bei der monatlichen Mobilfunk- oder Kreditkartenabrechnung. Als Beispiel ist das Zahlungssystem ClickandBuy zu nennen, welches ebenfalls noch genauer vorgestellt wird.

Kategorisierung nach Art der Zahlung Eine sehr transparente Vorgehensweise zur Kategorisierung von Zahlungssystemen führt der Autor Breitschaft ein. Dazu führt der Autor alle Zahlungssysteme zunächst auf die grundlegenden Arten des Geldes zurück und definiert mit Lastschrift, Überweisung und Geldbörsenzahlung drei originäre Zahlungsmethoden⁴, wie in Abbildung 12 zu sehen ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12 Originäre und abgeleitete Zahlungsverfahren (vgl. Breitschaft 2005)

In den weiteren Ausführungen stellt der Autor die Begriffe für die von ihm eingeführten, abgeleiteten Zahlungsverfahren vor. So werden beispielsweise alle Zahlungsmethoden unter der Bezeichnung Inkasso- und Billingverfahren zusammengefasst, bei denen Ab- rechnungsbeträge von einer Inkassostelle wie z.B. einem Telekommunikationsdienstleister eingezogen werden. Billing bezeichnet dabei die optionale Zusammenfassung einzelner Beträge bis zu einem gewissen Zeitpunkt oder Betrag.

[...]

---

¹ vgl. Shahd 2010, S. 1.

² vgl. DPA 2011, S. 1.

³ vgl. Koch 2011, S. 2.

⁴ Near Field Communication (NFC)

⁵ Kundenkarte, Kundenclub und Bonus-/Vorteilsprogramme

⁶ vgl. Hauck 2010, S. 13.

⁷ vgl. Schreiber 2009, S. 3.

⁸ z.B. PayPal

¹ Homebanking-Computer-Interface (HBCI) http://www.hbci-zka.de/spec/2_2.htm

² Zentralen Kreditausschuss (ZKA) http://www.zka-online.de/

³ vgl. Hermanns 2001, S. 4.

⁴ Financial Transaction Services (FinTS) http://www.hbci-zka.de/spec/spezifikation.htm ⁵ vgl. Abschnitt 2.1.2

⁶ vgl. ZKA-Bankenliste, welche nach Registrierung als Entwickler zugesandt wird.

⁷ ISO/IEC 8859-1 für Westeuropäisch

⁸ Bankparameterdaten (BPD) siehe Kapitel 2.1.3

⁹ vgl. Stein 2011, S. 111.

¹⁰ Gruppendatenelemente (GD)

¹¹ Datenelement (DE)

¹² Datenelementgruppen (DEG)

¹³ Bankparameterdaten (BPD)

¹⁴ Userparameterdaten (UPD)

¹⁵ vgl. Stein 2011, S. 256.

¹⁶ Message Authentication Code (MAC)

¹⁷ Rivest-Shamir-Adleman (RSA)

¹⁸ vgl. Stein 2011.

¹⁹ Secure Sockets Layer (SSL) ab Version 3.0 Transport Layer Security (TLS)

²⁰ vgl. Anlage 50

²¹ kryptografische Prüfsumme

²² vgl. Langer 2010, S. 6.

²³ vgl. Lipinski 2010, S. 1.

²⁴ vgl. Langer 2010, S. 7.

²⁵ vgl. Finkenzeller 2008.

²⁶ vgl. Finkenzeller 2008, S. 65f.

²⁷ Finkenzeller 2008, S. 67f.

²⁸ vgl. Tanenbaum 2008, S. 19.

²⁹ vgl. Tanenbaum 2008, S. 33.

³⁰ vgl. Ullenboom 2011.

³¹ mutex exclusion

³² vgl. Ullenboom 2011, S. 99.

¹ Pousttchi 2005, S. 21.

² vgl. Seewald 2010.

³ Seewald 2010, S. 8.

⁴ vgl. Breitschaft 2005, S. 6.