Docstoc

part_1_A5_weitere_zahlungsmittel

Document Sample
part_1_A5_weitere_zahlungsmittel Powered By Docstoc
					A.5 Weitere Zahlungsmittel für digitale
    Märkte: Konzepte und Produkte

1       Zahlungsmittel für digitale Märkte: digitales Geld                                                          7

1.1     Anforderungen an elektronische Zahlungssysteme ..............................9
1.1.1   Allgemeine Anforderungen .......................................................................9
1.1.2   Technische Anforderungen ......................................................................10
1.1.3   Betriebswirtschaftliche Rahmenbedingungen .........................................15
1.1.4   Anforderungen der beteiligten Parteien...................................................20
1.2     Billing-Systeme und Pay-per-use-Mechanismen.................................22
1.3     Elektronische Zahlungssysteme ...........................................................23
1.4     Zahlungssysteme auf Basis elektronischer Münzen ...........................24
1.4.1   eCash .......................................................................................................24
1.4.2   NetCash ...................................................................................................32
1.5     Zahlungssysteme auf Basis von Kreditkarten.....................................35
1.5.1   First Virtual..............................................................................................37
1.5.2   CyberCash ...............................................................................................41
1.6     Weitere Zahlungssysteme auf Kreditkarten-Basis..............................49
1.7     Zahlungssysteme auf Scheck-Basis ......................................................50
1.7.1   NetCheque ...............................................................................................50
1.7.2   NetBill .....................................................................................................55
1.8     Weitere Zahlungssysteme auf Scheck-Basis ........................................58
1.9     Zahlungssysteme auf SmartCard-Basis...............................................59
1.10    Zahlungssysteme auf EDI-Basis ...........................................................61

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
VI                                                                                              J. Anton Illik

1.10.1   TeleCounter............................................................................................. 61
1.11     Zahlungssysteme auf Kontenbasis....................................................... 65
1.11.1   CyberCoin ............................................................................................... 65
1.11.2   Digitales Lastschriftverfahren pay-on.net/ELV....................................... 65
1.12     Weitere Zahlungssysteme ..................................................................... 67
1.12.1   Zahlung über Handy: das Zahlungssystem Paybox................................. 67
1.12.2   Zahlung über das Telefonnetz: das Zahlungssystem net900 ................... 70
1.13     Zahlungsprotokolle ............................................................................... 71
1.13.1   S-HTTP: Secure Hypertext Transfer Protocol......................................... 72
1.13.2   iKP: Internet Keyed Payment Protocols.................................................. 72
1.13.3   STT: Secure Transaction Technology...................................................... 73
1.13.4   SEPP: Secure Electronic Payment Protocol............................................ 73
1.13.5   SET: Secure Electronic Transactions ...................................................... 74
1.13.6   SSL: Secure Socket Layer....................................................................... 77
1.13.7   MilliCent Protokoll ................................................................................. 81
1.13.8   Zusammenfassung................................................................................... 82
1.14     Integration elektronischer Zahlungssysteme ...................................... 82
1.14.1   JEPI: Joint Electronic Payment Initiative............................................... 83
1.14.2   OTP: Open Trading Protocol .................................................................. 84
1.14.3   OBI: Open Buying on the Internet .......................................................... 84
1.14.4   HBCI: Homebanking Computer Interface .............................................. 84
1.14.5   BIPS: Bank Internet Payment System..................................................... 85
1.15     Zusammenfassung und Ausblick ......................................................... 85




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
5 Zahlungsmittel für digitale
Märkte: digitales Geld
Je mehr sich die Geschäftstätigkeit eines Anbieters oder Nutzers in den Keine Medien-
elektronischen Marktplatz hineinverlagert, um so mehr werden für die und
Abwicklung von Kauftransaktionen Verfahren ohne Medien- und Metho- Methodenbrüche
denbrüche benötigt, die nicht über bestehende, traditionelle Finanznetz-
werke abgewickelt werden, sondern vollständig in das Netz integriert sind.
Warum reichen konventionelle Zahlungsmittel nicht mehr aus? Nun, in Kleinstkäufe
allen Fällen, bei denen eine Web-Kauftransaktion über Kreditkarten, (micropayments)
Scheck, Rechnung und Überweisung oder traditionelle EDI-Strukturen der adäquat bezahlen
Transaktionspreis höher als der Preis der bezogenen Leistung ist, wird sich
ziemlich rasch das software-basierte elektronische Geld durchsetzen. Da-
mit lassen sich Mikrotransaktionen und Kleinstkäufe adäquat bezahlen und
Zahlungseingänge werden gehäufelt, bis sich die Konvertierung in „ech-
tes“ Geld lohnt.
Nehmen wir mal an, wir wollen über das Internet ein paar maßgeschnei- Angebotssondie-
derte Jeans bestellen. Wir können nun selbst von allen Anbietern die Preis- rung vor dem
informationen einsehen oder wir erwerben zum Beispiel für ein paar Pfen- Kauf
nige von einem elektronischen Informations-Broker die aktuelle Zusam-
menstellung derjenigen Firmen, die über das Web Jeans anbieten. Sparen
wir mit dieser Auskunft mehr als die eingesetzten paar Pfennige ein, so
werden wir gerne bereit sein, bei der nächsten Kaufabsicht wieder auf die
Dienste des Brokers zurückzugreifen. Durch die Automatisierung der Aus-
kunft und die große Zahl der Informationsbedürftigen können die wie Pilze
aus dem Boden schießenden Informations-Broker und Betreiber von Ver-
zeichnisdiensten und Suchmaschinen ihre Leistungen günstig anbieten.
Um aktuelle Dimensionen zu verdeutlichen, hier einige Kennzahlen zu der
Suchmaschine AltaVista (http://www.altavista.com): In der Datenbank von
AltaVista sind über 30 Millionen Web-Seiten von über 250.000 Web-

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   8                                                                    J. Anton Illik

                   Servern und 4 Millionen Artikel von 14.000 Usenet-Foren registriert. Täg-
                   lich wird AltaVista nach eigenen Angaben bis zu 21 Millionen Mal kontak-
                   tiert!
Quasi kostenlos    Heute sind die von den Suchmaschinen gelieferten Informationen für den
                   Suchenden frei. Finanzieren kann sich der Betreiber über das Schalten von
                   Anzeigen in seiner Suchmaschinen-Home-Page. Bei täglich 21 Millionen
                   Kontakten im Fall von AltaVista macht das für Werbetreibende Sinn. Sinn
                   macht aber auch, dass ein solcher Informations-Broker für seine Auskünfte
                   pro Aussage einen Preis berechnet, der im Bereich von zehntel oder hun-
                   dertstel Pfennigen liegt, so dass der Konsument nach wie vor den Eindruck
                   hat, dass die gelieferte Information kostenfrei ist. Für den Verkäufer ergibt
                   sich der Gewinn aus einer entsprechend hohen Anfragefrequenz.
Geldgeschäfte      Bei Kleinsttransaktionen macht die Einschaltung Dritter zur traditionellen
ohne Einschal-     Zahlungsabwicklung, beispielsweise einer Bank, keinen Sinn. Dann sind
tung von Finanz-   möglicherweise schon die Überweisungskosten höher als evtl. der Ertrag
Intermediären      aus dem Informationsverkauf. So gesehen sind typische Bankgeschäfte wie
                   die Zahlungsüberweisungen auch in Web und Internet unerlässlich. Wozu
                   aber brauchen wir die Bank in ihrer heutigen Form, wenn das software-
                   basierte elektronische Geld allgemein verfügbar ist und damit die Zah-
                   lungstransaktion der Web-Kunden an der Bank vorbeilaufen kann? Auch
                   aus diesem Grund steht die Finanzbranche mitten in Veränderungen. Was
                   aber für die Bank gilt, gilt gleichermaßen für alle anderen Teilnehmer des
                   modernen Wirtschaftskreislaufs: Electronic Business sorgt nicht nur für
                   Wirbel in Marketing und Vertrieb, sondern drückt mit Vehemenz auf das
                   Leistungsangebot ganzer Konzerne und erzwingt auch die Umstrukturie-
                   rung ganzer Branchen und Märkte.
Mittel und         Wir betrachten im Folgenden elektronische Zahlungssysteme als Mittel
Verfahren zum      und Verfahren für den Transfer von Werten und Wertversprechen zwischen
Transfer von       den an einer Handelstransaktion beteiligten Parteien. Als potenzielle, betei-
Werten und         ligte Parteien sehen wir den Verkäufer (in der Regel der Zahlungsempfän-
Wertversprechen    ger), den Käufer (in der Regel der Zahlungspflichtige) und Finanz-
                   Intermediäre, wie beispielsweise Banken, die bei einer kontenbasierenden
                   Bezahlung die Umbuchungen vornehmen. Weitere an einer Handelstrans-
                   aktion beteiligte Einrichtungen im elektronischen Markt können die Anbie-
                   ter neuer Zahlungssysteme sowie unabhängige Dritte sein, sogenannte
                   Notariatsdienste, die beispielsweise Einzelschritte einer Handelstransakti-
                   on so bescheinigen, dass sie in einem Streitfall vor Gericht nicht abstreit-
                   bar sind. Alle an der Handelstransaktion beteiligten Parteien müssen über
                   den elektronischen Markt erreichbar sein, da ja Werte und Werteverspre-
                   chen ohne Medienbruch innerhalb des elektronischen Marktes transferiert
                   werden müssen.

                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                                9


5.1 Anforderungen an elektronische
    Zahlungssysteme
Die elektronischen Zahlungssysteme lassen sich in mehrere Kategorien                   Vielfältige
aufsplitten. Diese betrachten wir weiter unten systematisch, wollen hier               Anforderungen
aber erwähnen, dass neben dem digitalen „Nachbau“ der altvertrauten                    und neue
Münze auch neue Prozessformen für den Wertetransfer vorgestellt werden.                Prozessformen
Für alle Kategorien gelten vielfältige Anforderungen. Vom elektronischen
Substitut digitale Münze erwarten wir die Übernahme sämtlicher Funktio-
nen ihres realen, konventionellen Vorbildes. So muss eine digitale Münze
beispielsweise einen standardisierten, invarianten Wert besitzen, der für
alle an der Handelstransaktion beteiligen Parteien einsichtig ist. Wichtig in
diesem Zusammenhang ist, dass die digitale Münze fälschungssicher ist
und nur von autorisierter Stelle „geprägt“ werden kann. Vor diesem Hin-
tergrund lassen sich dann auch Wechselkurse gegenüber realen Währungen
definieren, um die digitale Münze jederzeit einlösen zu können.
Für die neuen Prozessformen des Wertetransfers lassen sich die Anforde-                Technische
rungen mangels bisheriger Vorbilder nicht so einfach skizzieren. Wir wer-              und betriebs-
den aus diesem Grund alle Bereiche, aus denen Anforderungen an elektro-                wirtschaftliche
nische Zahlungsmittel resultieren, systematisch durchleuchten: Welche                  Anforderungen
technischen und betriebswirtschaftlichen Anforderungen gibt es, welche
Anforderungen haben die an der Handelstransaktion beteiligten Partner?

5.1.1        Allgemeine Anforderungen
Offener Standardisierungsprozess
Nicht nur bei technischen Produkten ist – dank erfolgreicher Marketingan-              Einflussnahme
strengungen – das Phänomen zu beobachten, dass die Reputation des nam-                 aller
haften Herstellers sich automatisch auf das Produkt überträgt, so dass die             interessierten
Systemakzeptanz von vornherein größer ist – häufig eben unabhängig von                 Parteien
der tatsächlichen technischen Qualität des Produktes. Um diese technische
Qualität aber verifizierbar zu halten, ist es notwendig, dass Zahlungssys-
teme offenen Standardisierungsprozessen folgen. Dann ist gewährleistet,
dass alle an einem konkreten Zahlungssystem interessierten Marktteilneh-
mer im Bedarfsfall den Entwicklungsfortschritt beobachten und gegebe-
nenfalls beeinflussen können!




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  10                                                                   J. Anton Illik

                  5.1.2        Technische Anforderungen
Sicherheit und    Neben inneren technischen Qualitäten gibt es eine Reihe äußerer techni-
Integrations-     scher Qualitätsmerkmale, die für alle beteiligen Nutzer eines elektroni-
fähigkeit         schen Zahlungssystems sichtbar sind. Diese betreffen unter anderem die
                  Sicherheit, die Integrationsmöglichkeiten und die Betriebsarten eines e-
                  lektronischen Zahlungssystems.
Garantie für      Da die inneren technischen Qualitiätsmerkmale nicht so ohne weiteres
innere Werte      sichtbar sind, ist der oben geschilderte offene Standardisierungsprozess
                  unerlässlich. Wir werden auf innere Qualitätsmerkmale hier nicht weiter
                  eingehen, da uns solche Bertrachtungen zu weit auf das Gebiet des Soft-
                  ware-Engineerings führen würden.

                  5.1.2.1       Sicherheit geht über alles
Basissicherheit   Hier, im Zusammenhang mit elektronischen Zahlungssystemen interessiert
                  uns Sicherheit zunächst auf relativ hoher Ebene. Wir werden also im Fol-
                  genden nicht darüber sprechen, wie durch Sicherheitsmaßnahmen die „Pri-
                  vatsphäre“ eines Computers oder Netzwerkes geschützt werden kann. Wir
                  melden allerdings einen hohen Schutzanspruch an, um Computer- und
                  Netzwerk-Nutzer, die Datenbestände, die Software und Hardware vor Ein-
                  dringlingen und ungebetenen Gästen, deren illegales, in jedem Fall uner-
                  wünschtes Treiben, das uns einen unmittelbaren oder mittelbaren Schaden
                  zufügt, zu schützen.
Verfügbarkeit     Alle teilnehmenden Parteien möchten in der Lage sein, jederzeit Zahlun-
                  gen auszuführen oder zu erhalten. Deshalb müssen elektronische Zah-
                  lungssysteme elektronischer Märkte stets aktiv oder aktivierbar sein.
Zuverlässigkeit   Kein Teilnehmer wird einen Geldverlust akzeptieren, der durch Störungen
durch Trans-      des elektronischen Zahlungssystems bedingt ist. Beim Transfer elektroni-
aktionalität      scher Münzen können Verlust oder Duplikation auftreten. Um das zu ver-
                  hindern, bedarf es eines transaktional gesicherten Protokolls, das alle tech-
                  nischen Eigenschaften einer Transaktion – Atomarität, Konsistenz, Isolati-
                  on und Dauerhaftigkeit (ACID) – garantiert.
Vertraulichkeit   Bestimmte Einzelheiten der Transaktion, wie z. B. Käufer-, Verkäufer-
bei Bedarf        identität, Transaktionsinhalt (Produkt oder Dienstleistung) sowie der
                  Transaktionspreis und das Transaktionsdatum sind nur den beteiligten Par-
                  teien bekannt. Die Informationen bleiben gegenüber Unbeteiligten vertrau-
                  lich und geheim. Die Vertraulichkeit kann sich auch nur auf einzelne Teil-
                  nehmer beschränken und sollte mindestens dann Anwendung finden, wenn
                  Anonymität oder Geheimhaltung gefordert wird. Vertraulichkeit wird be-
                  sonders von Konsumenten gewünscht, da sie durch ihre getätigten Einkäu-


                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               11

fe im elektronischen Markt nicht zum „gläsernen Menschen“ werden
möchten. Andererseits gibt es Transaktionssituationen, wo Anonymität
wiederum aus Sicherheitsgründen nicht angebracht ist, um das Potenzial
für Betrug, Erpressung und Geldwäsche zu reduzieren.
Der Mittelweg liegt hier in der Aufzeichnung von Transaktionsdaten durch Notariatsdienst
externe, unparteiliche, vertrauenswürdige Dritte (trusted third parties,
kurz: TTP), so dass diese Daten im Falle eines gerichtlichen Prozesses
ermittelbar sind. Solche autorisierten Stellen können beispielsweise Nota-
riatsdienste sein. Notariatsdienste übernehmen als softwaremäßige Ent-
sprechungen üblicher Notare die Aufgabe, Transaktionen mit Vertragscha-
rakter zwischen Client und Server so zu registrieren, dass sie nicht ab-
streitbar sind und von allen Beteiligten als verbindlich akzeptiert werden.
Darüberhinaus kann ein Notariatsdienst die Authentisierung, die Zertifizie-
rung und in bestimmten Fällen die Dokumentenarchivierung übernehmen.
Unter Integrität versteht man Nachrichtenunversehrtheit, d. h. dass die Integrität
gesendete Nachricht mit der empfangenen Nachricht identisch ist. Beson-
ders im Hinblick auf Zahlungstransaktionen muss die Unversehrtheit der
übertragenen Daten gewährleistet werden, um zu verhindern, dass Dritte
Nachrichten duplizieren, abändern, einfügen, zerstören und/oder umordnen
können. Die Integrität kann mit digitalen Signaturen gewährleistet werden.
Integrität in Bezug auf Zahlungssysteme bedeutet aber auch, dass kein
Teilnehmer ohne vorherige Zahlungsautorisierung Geld transferieren muss,
und – um passive Bestechung zu verhindern – keine Partei ohne ihre Zu-
stimmung Werte übermittelt bekommt. Diese Art der Integrität wird durch
besondere Gestaltung der Zahlungsabläufe und Autorisierungsverfahren
erreicht. Als Beispiel hierfür kann das später noch genauer vorgestellte
elektronische Zahlungssystem ECash genannt werden.
Das Internet lässt als offenes Netzwerk jeden Teilnehmer unabhängig von Authentisierung
Ort, Alter, Vorstrafen u. a. zu. Durch Modifikationen von E-Mail- oder
Adressen, durch Benutzung von Anonymisierungs-Servern oder auch Authentifizierung
durch entsprechende WWW-Publikationen kann praktisch jede beliebige
Identität vorgetäuscht werden. Bei Handelstransaktionen müssen aber die
Geschäftspartner in bestimmten Fällen darauf vertrauen können, dass die
Vortäuschung einer falschen Identität unmöglich ist. Der Verifika-
tionsprozess dieser Teilnehmer-Identitäten wird als Authentifizierung be-
zeichnet. Authentifizierung lässt sich technisch mit digitalen Signaturen
und Zertifikaten realisieren. Möglicherweise muss die Authentifizierung
wieder mit Hilfe eines TTP abgewickelt werden, denn über die Authentifi-
zierung geht die Anonymität verloren.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  12                                                                   J. Anton Illik

Autorisierung     Eine bedeutende Rolle in Client-Server-Architekturen und somit auch im
und Zugriffs-     Internet spielt der Schutz gegen unberechtigten Zugriff auf Resourcen. Um
kontrolle         einen unberechtigten Zugriff auf Daten, Programme und andere Resourcen
                  zu vermeiden, muss anhand der Autorisierung geregelt werden, wer auf
                  eine Resource wie zugreifen darf. Eine vertrauenswürdige Instanz verwal-
                  tet die Zugriffsrechte auf Resourcen i. d .R. in Form von Zugriffslisten
                  (Access Lists, kurz: ACL), in denen zum Beispiel Lese-, Schreib-, Lösch-
                  und Ausführungsrechte definiert werden. Um Autorisierungs-
                  entscheidungen auszuführen, braucht der kontrollierende Prozess ein si-
                  cheres Wissen über die Personenidentität. Im Zusammenhang mit elektro-
                  nischen Zahlungssystemen reguliert die Autorisierung zum Beispiel die
                  Frage, wer zur Scheckausstellung oder zum Zugriff auf das elektronische
                  Münzkonto berechtigt ist.
Abstreitbarkeit   Die Kommunikation über einen unsicheren Kanal mit einem potenziell
                  nicht vertrauenswürdigen Partner zieht verschiedene Probleme nach sich:
                  Was ist, wenn der Partner den Empfang des gelieferten Produkts abstreitet?
                  Hier besteht der Bedarf zur Einbeziehung eines vertrauenswürdigen Drit-
                  ten, der Handlungen so bezeugen kann, dass zu einem späteren Zeitpunkt
                  der Transaktionsverlauf zuverlässig nachvollzogen werden kann und damit
                  die Nichtabstreitbarkeit (Non-Repudiation) gegeben ist. Oder der Zah-
                  lungsempfänger den Eingang der Zahlung leugnet? Hans Meli-Isch unter-
                  scheidet mehrere Arten der Non-Repudiation [100]:
                  • Mit der Nichtabstreitbarkeit der Absendung (Non-Repudiation of
                    Origin, kurz: NRO) wird der Nachrichtenempfänger gegenüber dem
                    Nachrichtensender geschützt, der die Nachricht bzw. deren Inhalt leug-
                    nen will.
                  • Die Nichtabstreitbarkeit des Empfangs (Non-Repudiation of Delive-
                    ry, kurz: NRD) ermöglicht den Schutz des Nachrichtensenders gegen-
                    über dem Empfänger, der den Empfang der Nachricht oder deren Inhalt
                    leugnen will.
                  • Die Nichtabstreitbarkeit der Annahme und Übertragung (Non-
                    Repudiation of Submission, kurz: NRS) verhindert für den Transport-
                    dienst die Abstreitbarkeit, eine Nachricht vom Sender entgegengenom-
                    men zu haben.
                  • Die Nichtabstreitbarkeit der Übertragung und Abgabe (Non-
                    Repudiation of Transmission, kurz: NRT) verhindert für den Transport-
                    dienst die Abstreitbarkeit, eine Nachricht übertragen und beim Empfän-
                    ger abgeliefert zu haben.




                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               13

Die vier oben vorgestellten NR-Dienste erlauben damit in einem Umfeld Typische
gegenseitigen Misstrauens jedem Transaktionspartner den Nachweis der Notariatsdienste
Durchführung eigener oder fremder Handlung. Diese NR-Dienste fallen in
das Aufgabenfeld von TTPs und sind typische Notariatsdienste. Technisch
realisiert wird die Non-Repudiation mit Hilfe von digitalen Signaturen und
zertifizierten öffentlichen Schlüsseln. Beispielsweise werden in SET (siehe
Kapitel 5.13.5 SET: Secure Electronic Transactions) kritische Informatio-
nen der ausgetauschte Nachrichten von beiden beteiligten Seiten gleichzei-
tig (im gleichen Record) signiert. Hierdurch sind beide Seiten in der Lage,
unabhängig voneinander rechtsverbindlich nachzuweisen, dass eine Trans-
aktion zu betimmten Bedingungen zustande gekommen ist.
Netzwerke sind als räumlich verteilte Kommunikationsgeflechte per se Abwehr von
gefährdet und aktiven wie passiven Angriffen ausgesetzt. Passive Angriffe Attacken
bedrohen die Vertraulichkeit der Kommunikation. Es wird zwar in diesem
Fall keine Änderung der übertragenen Nachricht oder der für die Übertra-
gung der Nachricht eingesetzten Komponenten vorgenommen, aber es
werden Nachrichten ausgespäht und nicht legalen Empfängern zugeleitet.
Mit aktiven Angriffen werden Nachrichten oder Komponenten eines
Kommunikationssystems verändert und verfälscht. Oder es werden durch
fingierte Nachrichten Sachverhalte vorgetäuscht. Der empfindlichste Teil
des Gesamtsystems ist der (private) Rechner, auf dem das Geld bzw. die
Kontoinformationen gespeichert sind. Ihn gilt es besonders zu schützen.
Um Attacken erfolgreich abwehren zu können, sind Autorisierungs- und
Authentisierungsmechanismen besonders wichtig.

5.1.2.2       Integrationsfähigkeit: Zahlungsmittel sind keine Stand-
              Alone-Applikationen
Oben haben wir gefordert, dass elektronische Zahlungsmittel helfen müs- Bruchlose
sen, einen Methoden-, Medien- und Verfahrensbruch bei der Abwicklung Einbettung
von digitalen Handelstransaktionen zu vermeiden. Dies geht nur mit einer
bruchlosen Einbettung in das digitale Umfeld des elektronischen Markt-
platzes.
Technische Integration des Zahlungssystems wird von allen Teilnehmern Technische
an Handelstransaktionen im elektronischen Markt gefordert. Hierzu sind Integrations-
definierte Schnittstellen erforderlich, die das Zahlungssystem mit dem fähigkeit
Gesamtsystem kommunizieren lassen. Technologien, die hierfür genutzt
werden können, sind beispielsweise CORBA (Common Object Request
Broker Architecture), RPC (Remote Procedure Call), JavaBeans/Enterprise
JavaBeans oder COM/DCOM (Common Object Model/Distributed Com-
mon Object Model), sowie das ab Windows 2000 implementierte COM+,
das COM und DCOM zusammenführt.

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  14                                                                   J. Anton Illik

Integration in    Voraussetzung für die Integration von Zahlungssystemen in Applikationen
Applikationen     ist die technische Integrationsfähigkeit. Möglich soll sein, dass das Zah-
                  lungssystem beispielsweise an die Buchhaltungs-Systeme der Transakti-
                  onspartner die Zahlungstransaktionsdaten in einem definierten Format
                  übergibt, so dass diese Softwaresysteme eine Verarbeitung der relevanten
                  Daten ohne weiteren Aufwand vornehmen können.
                  Besonders Anbieter und Verkäufer sind an der automatischen Übernahme
                  der elektronischen Zahlungstransaktionsdaten interessiert, um Fehler durch
                  Neueingaben zu verhindern. Bei dem „klassischen“ elektronischen Zah-
                  lungsverkehr mittels EDI ist diese Art der Integration schon seit mehreren
                  Jahren gegeben.
Durchgängigkeit   Die Durchgängigkeit muss über alle Phasen der elektronischen Markt-
der IT            transaktion reichen. Auch innerhalb der Abwicklung ist deshalb ein ein-
                  heitliches IT-Mittel gefordert. Alle Beteiligten einer Handelstransaktion
                  müssen die Zahlungstransaktion, begonnen mit der Kontoeröffnung, Geld-
                  transfer auf das Konto und die Zahlungen selbst durchgängig über das
                  Internet erledigen. Medienbrüche wie zum Beispiel die Übermittlung der
                  Kreditkartennummer per Telefon oder die Versendung von Bankkonto-
                  Informationen auf dem klassischen Postweg werden als negativ empfun-
                  den, da die Transaktionskosten nach oben getrieben werden

                  5.1.2.3       Unterschiedliche Betriebsarten müssen unterstützt
                                werden
Online-Betrieb    Während des Zahlungsprozesses sind alle Beteiligten miteinander verbun-
                  den und können kommunizieren. In der Regel wird die Hilfe eines entfern-
                  ten Rechners benötigt, der die Kontrolle bzw. Steuerung des Dialogs über-
                  nimmt. Als Resultat ergibt sich eine hohe Belastung für den Zahlungsser-
                  ver. Es entstehen Verbindungskosten für die Leitung, jedoch ist die Prü-
                  fung des elektronischen Geldes sofort möglich. Mehrfachausgaben können
                  verhindert werden (z. B. mittels Zahlung mit kopierten Münzen). Die hohe
                  Beanspruchung von Kommunikationsresourcen ist oft ein Grund für die
                  Verwendung von Offline-Systemen .
Offline-Betrieb   Der Zahlungsprozess findet ohne Teilnahme einer Clearingstelle direkt
                  vom Kunden zum Verkäufer statt. Peter Wayner ist der Ansicht, dass es
                  kein echtes Offline-Cash gibt. Diese Systeme sind in gewisser Hinsicht
                  auch online, die Interaktion zur Bank verschiebt sich nur um einige Zeit.
                  Vorteil des Offline-Betriebs sind die relativ geringen Kommunikationskos-
                  ten. Ein potenzielles Problem ist die Frage der Mehrfachausgabe einer
                  elektronischen Münze. Gelöst wird dieses Problem bei SmartCards zum
                  Beispiel mit Sicherheitsmodulen, PC-Card-Slots oder SmartDisks, welche
                  die Authentisierung der elektronischen Münzen bzw. Karten ermöglichen.

                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               15

Bei anderen Zahlungssystemen kann die Prüfung des Geldes bzw. die Be-
rechtigung der Kontobelastung prinzipiell auch im Nachhinein erfolgen.
Wird für ein elektronisches Zahlungssystem zusätzliche Hardware benötigt, Zusatz-Hardware
stellt dies kundenseitig eine gewisse Hemmschwelle dar, weil zusätzliche
Investitionen für die Anschaffung der Hardware notwendig sind. Bei allen
SmartCards wird ein separater oder in der Tastatur integrierter Kartenleser
benötigt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI)
publiziert regelmäßig zertifizierte Produkte im Bereich IT-Sicherheit, worun-
ter sich auch eine große Anzahl zertifizierter Kartenleser befindet.
Eine weitere technische Anforderung an Zahlungssysteme ist die Portabili- Portabilität
tät. Dies bedeutet, dass das elektronische Zahlungssystem unabhängig von
einer bestimmten Prozessor- oder Betriebssystem-Architektur lauffähig ist.
Um die Kommunikationskosten nicht in die Höhe zu treiben, sollte eine Performance
definierte Durchsatzgeschwindigkeit von Zahlungstransaktionen gewähr-
leistet sein. Die Durchsatzgeschwindigkeit ist abhängig von der Übertra-
gungsrate des zugrundeliegenden Netzes, der Anzahl der Zahlungs-Server,
die der Zahlungssystem-Anbieter installiert hat. Die Gewährleistung der
Durchsatzgeschwindigkeit spielt bei Online-Zahlungssystemen eine große
Rolle. Geringere Prioriät hat diese Anforderung bei Offline-
Zahlungssystemen.

5.1.3        Betriebswirtschaftliche Rahmenbedingungen
In diesem Kapitel werden organisatorische und funktionale Anforderungen
untersucht, die in einem betriebswirtschaftlichen Zusammenhang stehen.
Die zunehmende Internationalisierung wirtschaftlicher Aktivitäten zieht Lokale und
die Forderung der internationalen Anwendbarkeit von Zahlungssystemen internationale
nach sich. Bisher ist für den Retail-Kunden lediglich die Kreditkarte als Anwendbarkeit
internationales Zahlungssystem ökonomisch sinnvoll anwendbar. Auch in
regionalen Märkten spielt die grenzüberschreitende Anwendbarkeit von
Zahlungssystemen eine wichtige Rolle: Denn, wie wir weiter oben schon
festgestellt haben, auch regionale Angebote sind in einem elektronischen
Markt idealerweise weltweit sichtbar und sollen im Interesse des Anbieters
natürlich auch genutzt werden.
Zahlungen sind Bestandteile der Abwicklungphase von Markttransaktio- Betriebs-
nen. Der Zahlungsprozess wird bereits in der vorangegangenen Vereinba- wirtschaftliche
rungsphase initiiert und spielt dann eine zentrale Rolle bei der Abwicklung Integration
der jeweiligen Geschäftstransaktion.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  16                                                                   J. Anton Illik

                  Die Integration von Finanzdienstleistern in die Abwicklungsphase einer
                  Transaktion innerhalb der Wertschöpfungskette beinhaltet bisher nicht
                  ausgeschöpfte Potenziale von elektronischen Märkten.
Zahlungs-         Anhand des Kriteriums „Zeitpunkt der Zahlung“ können laut Phil Janson
zeitpunkt         und Michael Waidner [1996a] drei unterschiedliche Arten von Zahlungs-
                  systemen definiert werden. Der Zahlungszeitpunkt bezieht sich auf die
                  Zeit, die zwischen dem Auslösen einer Zahlungstransaktion und der tat-
                  sächlichen Belastung auf dem Kundenkonto liegt.
                  • Pre-paid-System. Bei Pre-paid-Systemen muss der Kunde, bevor er
                    eine Zahlung ausführt, ein Guthaben auf sein Konto oder seine Karte
                    einzahlen, d. h. es entsteht eine gewisse Zeitspanne zwischen dem Ein-
                    zahlen des Geldes und der Ausgabe (z. B. Telefonkarten, Electronic
                    Cash). Für Pre-paid-Systeme wird im Folgenden auch der Ausdruck
                    „bargeld-ähnlich“ verwendet.
                  • Pay-now-System. Mit dem Auslösen einer Zahlung wird sofort die Be-
                    lastung auf dem Kundenkonto ausgeführt, d. h. es ist keine „Zwischen-
                    lagerung“ des Geldes nötig. Ein Beispiel für ein Pay-now-System ist
                    ein ATM-basiertes Kartensystem wie das EC-Direct.
                  • Pay-later-System. Die Zahlung ist genau gesehen ein Zahlungsverspre-
                    chen, da erst nach einem bestimmten Zeitintervall, oder nach Kumulie-
                    rung von Beträgen, die Abbuchung auf dem Kundenkonto erfolgt. Kre-
                    ditkarten- und Schecksysteme sind typische Pay-later-Systeme.

Darlehen kontra   Pay-now- und Pay-later-Systeme sind „kontenbasierende“ Systeme. Die
Liquidität        Anforderungen der Marktteilnehmer in Bezug auf den Zeitpunkt der Zah-
                  lung sind unterschiedlich. So werden beispielsweise Pay-later-Systeme von
                  Kunden bevorzugt, da das Geld aufgrund des Darlehenscharakters erst im
                  Nachhinein vom Konto abgebucht wird. Anbieter präferieren Pre-paid- und
                  Pay-now-Systeme, da diese die Liquidität steigern.
Vermeidung von    Die Forderung nach der Transaktionalität wurde schon weiter oben gestellt
Geldverlust       („Technische Anforderungen“). Bei allen Zahlungssystemen sollte gewähr-
                  leistet sein, dass die Transaktion vollständig ausgeführt oder wieder zu-
                  rückgesetzt wird, falls eine Störung eintritt (ACID-Prinzip). Damit soll ein
                  konsistenter Zustand bei allen Teilnehmern bestehen bleiben. Weiterhin
                  sollte das elektronische Zahlungssystem über Sicherheitsfunktionen verfü-
                  gen, damit der Benutzer beispielsweise nicht etwa versehentlich seine
                  Münzdateien löschen kann. Bei SmartCards ist der Kartenverlust oft mit
                  Geldverlust gleichzusetzen, da in den häufigsten Fällen der Restbetrag
                  nicht ermittelt werden kann und der Finder (falls die Karte nicht über ein
                  Passwort geschützt ist) über das Geld verfügen kann. Eng in Verbindung

                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               17

mit dem Beurteilungskriterium Geldverlust steht die Kulanz des involvier-
ten Finanzintermediärs. Haftet das Finanzinstitut bei Missbrauch (z. B.
haften Kreditkartenunternehmen ab bestimmten Beträgen), so wird der
Kunde entlastet und ein potenzieller Geldverlust nicht zu stark gewichtet.
Das kann die Akzeptanz des elektronischen Zahlungsmittels deutlich stei-
gern.
Der Austausch von Geldmitteln und Waren erfolgt in aller Regel asyn-                   Minimierung der
chron. Üblicherweise wird zuerst bezahlt, danach die Information bzw. das              Abhängigkeit von
Gut zur Lieferung freigeschaltet oder die Versendung veranlasst. Eine Ab-              Anbietern gegen-
hängigkeit der Anbieter ist daher nicht vorhanden bzw. minimal. Eventuell              über Nach-
benachteiligt ist der Nachfrager.                                                      fragern

Bei den Käufern verhält es sich genau umgekehrt. Das Verhältnis der Ge-                Minimierung der
schäftspartner wird von Michael Waidner mit „master-slave relation bet-                Abhängigkeit von
ween seller’s server and buyer’s browser“ beschrieben. Das Zahlungssys-                Nachfragern
tem NetCash ist bisher das einzige, das die erläuterte Abhängigkeit durch              gegenüber
ein spezielles Verfahren, in welchem Münzen mit gleicher Seriennummer                  Anbietern
ausgegeben werden, eliminiert [Medvinsky/Neuman, 1993, 4].

5.1.3.1       Funktionale Vielfalt
Der Funktionsumfang von elektronischen Zahlungssystemen beschränkt Je mehr desto
sich oft auf das Ausführen von Zahlungen, Geld abheben und deponieren besser
(bei Cash-Systemen) und die Erstellung eines Kontoauszugs. Nachfolgen-
de funktionale Anforderungen resultieren aus bereits erläuterten techni-
schen und betriebswirtschaftlichen Anforderungen:
Um einem Konsumenten Flexibilität in höchstem Maße zu bieten, muss er Konvertibilität
in der Lage sein, sein Geld zwischen verschiedenen Zahlungssystemen zu
transferieren und somit Cyber-Währungen zu konvertieren. Er kann durch
diese Funktion seine Einkaufsmöglichkeiten um ein Vielfaches erhöhen.
Auch für die Anbieter liefert die Konvertierbarkeit von Zahlungssystemen
Vorteile, da der erreichbare Kundenkreis vergrößert wird.
Die Flexibilität erhöht sich, indem Geld an beliebige Marktteilnehmer Übertragbarkeit
übertragen werden kann, also auch eine Kunde-zu-Kunde-Zahlung mög-
lich ist (Peer-to-Peer-Zahlung). Bei vielen Systemen ist jedoch nur eine
Zahlung vom Kunden zum Anbieter vorgesehen.
Wie bei einem konventionellen Einkauf sollte auch der elektronische Ein- Quittungen
kauf quittiert werden. Dies ist einerseits für den Anbieter von Bedeutung,
da der Umsatz eventuell der Umsatzsteuer unterliegt und auch zur Ermitt-
lung des Unternehmens-Ergebnisses erfasst werden muss. Auch für den
Kunden spielen steuerliche und auch rechtliche Aspekte (wie z. B. Garan-
tie) eine entscheidende Rolle. Um die Glaubwürdigkeit von Quittungen zu

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                 18                                                                   J. Anton Illik

                 erhöhen, sollten sie mit zertifizierten Schlüsseln unterzeichnet oder von
                 TTPs erstellt werden.
Rückerstattung   Zahlungssysteme sind fast ausschließlich so konzipiert, dass sie lediglich
                 Zahlungsaufträge generieren bzw. eine Zahlung veranlassen können. Auch
                 beim elektronischen Einkauf kann es vorkommen, dass Produkte beschä-
                 digt werden oder gar nicht beim Kunden ankommen. Eventuell ist der
                 Kunde mit dem Produkt nicht zufrieden, was bei vorausbezahlter Ware
                 eine Rückerstattung erfordert.
Mehrere          Aufgrund der bereits erwähnten Globalisierung der Märkte sind mehrere
Währungen        Währungen notwendig. Bei Kreditkarten-Zahlungssystemen besteht die
                 Möglichkeit, in Landeswährung zu bezahlen. Auch bei elektronischen
                 Schecks und anderen kontenbasierten Systemen sind mehrere Währungen
                 möglich. Diese Anforderung betrifft hauptsächlich bargeldähnliche Zah-
                 lungssysteme.
Micropayments    Da das Internet als Vertriebskanal von Informationen (z. B. einzelne Arti-
                 kel) prädestiniert ist, ist eine der Anforderungen, dass das Zahlungssystem
                 über kleine Geldeinheiten verfügt. Dies kann durch eine Stückelung der
                 Münzen bei Ausgabe („Prägung“) erfolgen. Die andere Anforderung ist,
                 dass das Zahlungssystem eine ökonomische Ausführung von Zahlungen im
                 Micropayment-Bereich erledigen kann. Dies bedeutet eine kurze Durch-
                 satzgeschwindigkeit der Transaktion und niedrige Gebühren.
Warenkörbe       Zahlungssysteme sollten eine Funktion Rechnungserstellung beinhalten
                 oder an eine solche geknüpft werden können, damit der Kunde sich in
                 Ruhe einen Einkaufskorb zusammenstellen kann. Zahlungssysteme, die
                 eine Zahlungstransaktion per Produkt auslösen, sind nur beschränkt geeig-
                 net für einen „Einkaufsbummel“ in elektronischen Märkten.

                 5.1.3.2       Das Kosten-/Nutzen-Verhältnis
Notwendig:       Alle Marktteilnehmer fordern günstige Kosten für die Zahlungsabwicklung
 niedrige        im Internet. Nachfolgend werden Kosten, die in Verbindung mit Zahlungs-
Transaktions-    systemen und dem tatsächlichen Einkauf stehen, benannt.
kosten
                 • Registrierungskosten (Konto Setup-Gebühr) sind beim Einrichten des
                   Zahlungssystems einmalig zu leisten.
                 • Kontoführungsgebühren und Kontoauszugsgebühren fallen i. d. R. mo-
                   natlich an, wenn ein Konto für den Benutzer eingerichtet wird bzw. der
                   Inhaber die Buchungen abruft.
Transaktions-    Die Transaktionskosten können sich aus Kundensicht aus folgenden Kos-
kosten aus       ten zusammensetzen:
Kundensicht


                 Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                 chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               19

• Kosten für die Nutzung des elektronischen Marktes. In speziellen Fäl-
  len ist es denkbar, dass dem Besucher eines elektronischen Marktes
  Nutzungskosten entstehen. Ein elektronischer Markt, der sich an das
  allgemeine Publikum wendet, wird keine Nutzungskosten durchsetzen
  können.
• Kosten des Finanz-Intermediärs für die Erstellung und Übertragung von
  digitalen Münzen oder das Clearing eines elektronischen Schecks.
• Kosten für die Kommunikationsverbindung.
Heute tragen die Kommunikationskosten, die sich aus anteiligen Provider- Transaktions-
gebühren und Telekommunikationskosten zusammensetzen, einen nicht zu kosten noch zu
vernachlässigenden Anteil zu den gesamten Kosten bei. Mit Blick auf die hoch
Zukunft lässt sich jedoch sagen, dass sich diese Kosten aufgrund zuneh-
menden Wettbewerbs zwischen den Providern und Telekommunikations-
unternehmen und aufgrund zunehmend besserer Übertragungsraten verrin-
gern werden. Dies führt zur Verminderung der Transaktionsdauer und so-
mit zur Senkung der Transaktionskosten.
Auch auf Anbieterseite sind heute noch relativ hohe Zahlungstransaktions- Transaktions-
und Zahlungssystemkosten vorhanden. Verglichen mit der herkömmlichen kosten aus
Kreditkarten-Zahlung, bei welcher üblicherweise zwei bis drei Prozent des Anbietersicht
Zahlbetrages durch das Kreditkartenunternehmen einbehalten werden, sind
diese Prozentsätze höher.
Die Eignung der Zahlungssysteme für den Einkauf im Internet ist letztend-
lich auch abhängig vom Preis und der Beschaffenheit des Gutes.
Oben haben wir Beispiele gesehen, die zeigen, dass es Sinn macht, Dienst- Micropayments
leistungen und Produkte anzubieten, die nur einstellige DM-Beträge, oder
gar nur Pfennige oder Zehntelpfennige kosten. Handelstransaktionen, bei
denen der Preis für das Transaktionsgut in dieser Größenordnung liegt,
werden als Kleinstkäufe und deren Bezahlung als Micropayments bezeich-
net. Solche Kleinstkäufe funktionieren nur mit elektronischen Zahlungs-
systemen, die die Transaktionskosten nicht dergestalt nach oben treiben,
dass Käufe von Objekten mit einem Wert von z. B. unter einer DM sinn-
voll ökonomisch abgerechnet werden können. Billing-Systeme rechnen
Micropayments kostengünstig ab.
Typisch ist hier, dass die Lieferung des gekauften Gutes zu einem späteren Kauf materieller
Zeitpunkt als die Zahlung stattfindet. Für diese Art von Güterkauf eignen Güter
sich Kreditkarten-Zahlungssysteme sehr, da die Kreditinstitute die Zah-
lungstransaktionen aufzeichnen und somit bei ausbleibender Lieferung des
Anbieters für den Kunden eine Sicherheit besteht. Nach der Zahlung wird
ein Logistikprozess angestoßen; hier spielt die Integration in das IT-


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  20                                                                   J. Anton Illik

                  System des Anbieters (z. B. in das Produktionsplanung- und Steuerungs-
                  system) eine große Rolle.
Kauf digitaler    Falls der Preis im richtigen Verhältnis zu den Zahlungstransaktionskosten
Güter             steht, eignet sich grundsätzlich jedes Zahlungssystem. Besonderheiten
                  beim Kauf digitaler Güter sind die prompte Abwicklung dieser Markt-
                  transaktionen. Nach der Bezahlung kann das Produkt unverzüglich ausge-
                  liefert werden. Bei eventueller Beschädigung des Produkts ist eine Wie-
                  derholung der Lieferung mit minimalen Mehrkosten möglich, da keine
                  Verpackungs- und Logistikkosten anfallen.

                  5.1.4        Anforderungen der beteiligten Parteien
                  In diesem Kapitel wird auf die individuellen bzw. besonders stark ausge-
                  prägten Anforderungen von Kunden, Anbietern und Finanzdienstleistern
                  eingegangen.

                  5.1.4.1       Kunden und Verbraucher
Anonymität        Für den Kunden ist im Vergleich zum Anbieter und Finanzintermediär die
                  Anonymität wichtig, da er seine Kaufgewohnheiten (Kauf von Produkten,
                  Einkaufszeit, Einkaufshäufigkeit usw.) i. d. R. nicht publik machen will.
                  Die meisten Zahlungssysteme wie Kreditkartensysteme, EDI mit E-Mail
                  und Schecksysteme sind nicht anonym, weder im Internet noch bei der
                  klassischen Zahlungsweise.
                  Henrik Czurda [1996, 48] sieht als weitere Anforderung von Zahlungssys-
                  temen eine Wahlmöglichkeit der optionalen Anonymität. Die Option der
                  wahlweisen Anonymität wurde beispielsweise beim elektronischen Zah-
                  lungssystem CAFE realisiert
Benutzerfreund-   R. M. Weiler hat im August 1995 eine Studie über die Befragung nach den
lichkeit          wichtigsten Nutzungskriterien von erfahrenen Internet-Benutzern erstellt.
                  Bei den Befragten dieser Studie handelt es sich um Personen aus Großbri-
                  tannien (24,5%), USA (39,7%) und 22 anderen Ländern bzw. Kontinenten,
                  wobei der Hauptanteil aus Männern bestand (87,7%). 75% sind der Alters-
                  klasse 18 Jahre bis 35 Jahre zuzuordnen.
                  Die Benutzerfreundlichkeit – also die komfortable und einfache Bedienung
                  des Systems durch den Benutzer – hat dabei mit 78,9% den zweiten Platz
                  erreicht.
                  Ebenso fällt unter den Begriff der Benutzerfreundlichkeit die Existenz von
                  Kommunikationskanälen zur Benutzergemeinde:
                  • Help-Hotline zum Systemanbieter (für dringende Individual-Beratung),


                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               21

• Installationshilfen, Handbücher und ein generelles Online-Hilfe-
  System,
• WWW-Homepages, E-Mail-Diskussions-Listen und Newsgroups und
  (um mit anderen Benutzern zu diskutieren)
• garantierte Updates.

5.1.4.2       Hersteller und Anbieter
So paradox es klingen mag, aber technische Sicherheit lässt sich nicht al- Maximierung
leine mit technischen Maßnahmen herbeiführen. Autorisierung, Authentifi- technischer
zierung und Firewalls sind zwar unerlässlich, reichen aber alleine nicht Sicherheit
aus, um die gewünschte Sicherheit zu gewährleisten. Insidern ist längst
bekannt: Attacken kommen in aller Regel nicht von „außen“, sondern wer-
den in über 60% aller Fälle aus den eigenen Reihen heraus vorgenommen!
Dies macht deutlich, dass sich Sicherheit nur in der Konzeptionierung und
Implementierung einer umfassenden Sicherheitspolitik erreichen lässt. Wir
gehen darauf im Kapitel Fehler! Verweisquelle konnte nicht gefunden
werden. Fehler! Verweisquelle konnte nicht gefunden werden. ein.
Für die Anbieter und Geschäftskunden ist die Einbindung des Zahlungs- Integration in
systems in den gesamten Geschäftsablauf von vorrangigem Interesse. So den Geschäfts-
sollen Transaktionsdaten beispielsweise in einem standardisierten Format prozess
(z. B. UN/Edifact) in das eigene DV-System eingehen, um im Sinne des
Workflow-Gedanken folgende Vorteile aufgrund der überflüssig geworde-
nen Neuerfassung, zu erhalten: Kostenersparnis, Zeitersparnis, Fehlerre-
duktion.

5.1.4.3       Finanz-Intermediäre
Der Wunsch nach sicherheitstechnischer Risikominimierung gilt hier im
gleichen Umfang wie für Anbieter.
Die Investitionen in elektronische Zahlungssysteme im Internet sind we- Wirtschaftliche
gen der sich soeben erst etablierenden Standards langfristig zu sehen. Ap- Risiko-
plikationen im Bereich des SET-Standards (Secure Electronic Transacti- minimierung
ons) tauchen auch erst allmählich auf und erfordern zunächst ein nicht
kleinlich dimensioniertes Investitionsbudget. Im Hinblick auf die aktuelle
Teilnahme am E-Commerce verlangt die Implementierung eines elektroni-
schen Zahlungssystems eine stabile finanzelle Ausstattung und eine auf
Dauer ausgelegte Strategie.
Eine Anforderung, die besonders von den Finanz-Intermediären betont                    Nicht-Duplizier-
wird, ist, dass keine Möglichkeit der Duplizierbarkeit des elektronischen              barkeit des
Geldes besteht. Daher begrüssen die Finanz-Intermediäre Zahlungssyste-                 elektronischen
me, deren Transaktionen bei Banken beginnen und enden (z. B. Kreditkar-                Zahlungsmittels

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   22                                                                   J. Anton Illik

                   ten-Zahlungen). Damit elektronisches Geld nicht dupliziert werden kann,
                   sind bestimmte Sicherheitsmechanismen in das Zahlungssystem zu integ-
                   rieren, wie z. B. Authentisierung von Teilnehmern bzw. Münzen und Ver-
                   schlüsselung der elektronischen Münzen bzw. des elektronischen Geldver-
                   sprechens.
Kontrolle durch Aufgrund der Existenz der Zahlungssysteme im Internet machten sich
Zentralbank oder anfänglich Ängste breit, dass das elektronische Geld an den Banken „vor-
Regierung        beiläuft“, und die Deutsche Bundesbank mit ihrer Zinspolitik an Wirkung
                   einbüßen würde [Jünemann/Schütte/Wolf-Doettinchem, 12]. Die Möglich-
                   keit zur Geldwäsche darf bei elektonischen Zahlungssystemen nicht beste-
                   hen.
Höhere Instanz     Durch die Gelderstellung und Kontrolle (sowohl bei der Auszahlung als
gefragt?           auch bei der Einzahlung/Überprüfung) durch eine höhere Instanz wie die
                   Zentralbank oder die Regierung könnten die erwähnten Probleme einfa-
                   cher überwacht werden. Dies entspricht jedoch nicht dem offenen, dezen-
                   tralisierten Internet-Charakter und wird sich deshalb vermutlich nicht
                   durchsetzen.


                   5.2 Billing-Systeme und Pay-per-use-
                       Mechanismen
Kleinstverbind-    Billing-Systeme stellen eine effiziente Möglichkeit zur Abrechnung von
lichkeiten         Micropayments dar. Ein Billing-System sammelt die Micro-
sammeln            Verbindlichkeiten innerhalb einer definierten Zeitperiode und stellt dann
                   dem Schuldner statt vieler Kleinstrechnungen eine einzige Rechnung aus.
                   Diese Art der Abrechnung findet sich beispielsweise bei Online-Diensten
                   wieder: AOL, T-Online und andere häufeln Kleinbeträge und stellen diese
                   in Summe einmal monatlich in Rechnung.
Charging,          Ist das Billing-System in einem offenen elektronischen Markt installiert, so
Billing, Revenue   ist der technische Anspruch an das Billing-System höher. Es muss die
Collection         Transaktionen anbieterspezifisch kategorisiert registrieren (charging), mit
                   dem Kunden abrechnen (billing) und die durch das Billing eingehenden
                   Zahlungsströme an die Verkäufer verteilen (revenue collection).
Beispiel           Ein Sammlung von konkreten Beispielen für den Einsatz von Billing-
                   Systemen im Internet ist unter http://http://home.clickshare.com/ zu finden.
                   Diese Verrechnungsweise wird auch als Pay-per-view oder Pay-per-click
                   bezeichnet, da pro WWW-Seite ein bestimmter Betrag in Rechnung ge-
                   stellt wird. Das Inkasso realisiert der Billing-Server beispielsweise über
                   die Kreditkarte des Lesers oder über ein Lastschriftverfahren.

                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               23

Pay-per-use-Mechanismen ermöglichen eine nutzungsbezogene Abrech- Pay-per-use
nung von digitalen Gütern oder Dienstleistungen. Beim Pay-per-use-
Konzept, das sich für den Bezug von Informationen und anderen digitalen
Produkten besonders eignet, wird der Anwendernutzen in die Preisgestal-
tung einbezogen. Hierfür werden bestimmte Indikatoren festgelegt. Bei-
spiele für diese Messgrößen sind Zeiteinheiten, Prozessor-Nutzung, Spei-
cherbedarf, übertragenes Datenvolumen, Anzahl der Zugriffe auf Informa-
tionen, Anzahl der Treffer bei Suchen und gegebenenfalls gelieferte Daten-
sätze, Verbindungsdauer usw. Die Bezahlung einer Pay-per-use-Nutzung
kann unverzüglich erfolgen oder über ein Billing-System abgerechnet
werden. Beide Abrechnungsarten können sowohl vom Anbieter selbst als
auch von einem Intermediär, wie bspw. dem Provider oder einer Electronic
Mall, abgewickelt werden.
Grundsätzlich besteht bei Pay-per-use-Konzepten die Möglichkeit, vor,                  Zahlung vor,
während oder nach der Nutzung zu bezahlen. Die Zahlung vor der Nut-                    während oder
zung ist besonders aus der Sicht des Nutzers problematisch, da der An-                 nach der
wender seinen erwarteten Nutzen vorher nur schwer abschätzen kann. Die                 Nutzung
Zahlung während der Nutzung (pay continously) besteht aus einem konti-
nuierlichen Geldfluss, der sich aus kleinsten Einheiten zusammensetzt.
Somit wird für diese Zahlungsart ein Zahlungssystem vorausgesetzt, das
diese Kleinsteinheiten messen, protokollieren und abrechnen kann und
dessen Transaktionskosten minimal sind. Bei der Zahlung nach der Nut-
zung muss der Anwender registriert sein und die Geschäftsbedingungen
anerkannt haben, damit ihm der Anbieter im Nachhinein eine Rechnung
stellen kann. Ebenso muss der Anbieter für jeden Kunden ein Konto ein-
richten, um die Nutzungsgebühren eindeutig und unverzüglich zuordnen
zu können.


5.3 Elektronische Zahlungssysteme
In Analogie zur realen Welt haben sich in der virtuellen Welt der elektroni- Vertraute und
schen Märkte im Internet mehrere Zahlungssysteme eingestellt. Die Münze neue Zahlungs-
und der Scheck werden nachgebildet. Auch die Nutzung der Kreditkarte ist paradigmen
naheliegend, da für eine Zahlung ohnehin nur eine Nummer zusammen mit
einer Verbindlichkeitserklärung vom Käufer zum Verkäufer wechselt. Die
im Folgenden skizzierten Protokolle und Algorithmen sollen einen Ein-
druck vermitteln, welch unterschiedliche Verfahren für die Abwicklung
von Handelstransaktionen möglich sind. Die Auswahl der Verfahren ist
dabei nicht erschöpfend.



Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   24                                                                   J. Anton Illik


                   5.4 Zahlungssysteme auf Basis elektronischer
                       Münzen
Höchstmaß an       In diesem Kapitel gehen wir zunächst auf die Eigenschaften von Zahlungs-
Anonymität         systemen ein, die auf elektronischen Münzen basieren. Diese bieten dem
                   Benutzer eine hohe Flexibilität und Sicherheit. Münzen, die durch Dateien
                   dargestellt werden [Beutelspacher, 153], sind in kleinen Einheiten vorhan-
                   den und ermöglichen den ökonomischen Kauf von Gütern, deren Preis im
                   Micropayment-Bereich liegt. Sie sind mit den SmartCards gleichzusetzen,
                   da sie ebenso wie diese ein Höchstmaß an Anonymität bieten [Frotscher].
                   Der Konsument kann durch die Nutzung von Zahlungssystemen auf Basis
                   elektronischer Münzen auch gegenüber dem Finanz-Intermediär anonym
                   bleiben. Im Gegensatz zu anderen Zahlungssystemen werden die elektroni-
                   schen Münzen und nicht die Konsumenten authentifiziert.
                   Generell enthält die Datenstruktur einer elektronischen Münze folgende
                   Informationen:
                   • Seriennummer (zur Überprüfung auf Mehrfachausgaben),
                   • Geldwert,
                   • Erstellungsort (wenn mehrere Banken für die Münzerstellung autori-
                     siert sind),
                   • Gültigkeitsdatum (bestimmt den spätesten Zeitpunkt der Münzeinlö-
                     sung) und
                   • Zeitstempel (entspricht dem Erstellungsdatum).
Münzdateien        Der Konsument kann die Münz-Dateien über das World Wide Web oder
werden lokal       mit der speziellen Zahlungs-Software über das Internet von der Bank oder
gehalten           einem Währungs-Server herunterladen. Danach speichert er sie auf dem
                   eigenen Rechner, bis er sie zum Kauf verwendet.
Jede Münze muss    Nachteil von diesen Zahlungssystemen ist das Problem der prinzipiellen
bei jeder          Duplizierbarkeit von elektronischen Münzen und die daraus resultierende
Verwendung         aufwendige Münzüberprüfung, wie sie von Beutelspacher/Hueske/Pfau
validiert werden   und David Chaum [1987] ausführlich diskutiert wird.

                   5.4.1          eCash
Deutsche Bank      Anfang 1997 startete die Deutsche Bank zusammen mit der holländischen
setzte auf eCash   Firma DigiCash (die in der Zwischenzeit von eCash Technologies1 Inc.

                   1
                       www.ecash.net oder www.ecashtechnologies.com


                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               25

übernommen wurde), dem Hersteller von eCash, eine Kooperation. Das
operative Geschäft bekam die Deutsche Bank 24 übertragen. Für kurze
Zeit! Im April 2001 gingen die Kündigungen der eCash-Konten an die
Kunden: „Sehr geehrter Kunde, das Internet-Zahlungsvefahren eCashTM ist
leider bei dem überwiegenden Teil unserer Kunden nicht auf das ge-
wünschte Interesse gestossen. Daher sehen wir uns veranlasst, den Betrieb
der eCashTM-Plattform einzustellen. Mit diesem Schreiben kündigen wir
fristgerecht den mit Ihnen geschlossenen eCashTM-Vertrag mit Wirkung
zum 25. Mai 2001. ...“. Nachdem Rückzug der Deutschen Bank gibt es
derzeit keine eCash-Vertragsbank in Deutschland.
Nun zum eCash-Verfahren. Gegen Belastung des Girokontos erhält der Ohne Girokonto
Bankkunde elektronische eCash-Münzen, die zunächst in einem Depot auf geht es nicht
dem Bank-Server gehalten werden und von dort aus auf den PC in die
elektronische Geldbörse geladen werden. Mit eCash kann man dann auf
allen Web-Seiten einkaufen, die mit der Miniatur-Grafik „We accept e-
cash“ gekennzeichnet sind.
eCash besteht im Wesentlichen aus drei Komponenten: Der virtuellen Drei
Bank, den eCash-Konten und den elektronischen Geldbörsen für Endkun- Komponenten
den und Händler. Die virtuelle Bank entspricht hierbei einem Internet-
Server, welcher die Verwaltung sämtlicher eCash-Konten abwickelt. Die-
ser Server liegt in der Verantwortung der Bank, die für die Sicherheit der
jeweiligen Zahlungen mit eCash garantiert. Die virtuelle Bank gibt über
die eCash-Konten elektronische Münzen heraus und garantiert für deren
Sicherheit und Echtheit. Die eCash-Geldbörse entspricht wie im normalen
Zahlungsverkehr mit Bargeld einer Geldbörse, in der Münzen verschiede-
ner Stückelung bereitgehalten werden. Die eCash-Geldbörse wird als Pro-
gramm auf dem Rechner installiert.


Abbildung 5.1 We accept ecash [http://www.ecash.net]




Die eCash-Transaktionen werden über elektronische Geldbörsen durchge- Elektronische
führt. Solche eCash-Geldbörsen sind sowohl beim Käufer als auch beim Geldbörse

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                26                                                                   J. Anton Illik

                Verkäufer installiert. Technisch gesehen sind die elektronischen Geldbör-
                sen individuell adressierbare Prozesse. Für die Nutzung von eCash müssen
                sich die Konsumenten und die Verkäufer als Teilnehmer anmelden, bei-
                spielsweise über ein entsprechendes Internet-Portal der Bank.
Ladebeträge sind Elektronische Münzen im eCash-Zahlungssystem werden in der jeweils
auf € 200        gültigen Währung denominiert. Die Ladebeträge für die elektronische
beschränkt       Geldbörse werden auf maximal € 200,-- pro Ladevorgang beschränkt. Das
                eCash-Konto und die eCash-Geldbörse sind jeweils auf ebenfalls € 200,--
                begrenzt. Natürlich behält sich die Bank die Änderung dieser Beträge und
                die Einbeziehung anderer Währungen in das Zahlungssystem vor.
Vernichtete     Interessant: Vernichtete elektronische Münzen – z.B durch Plattendefekt
Münzen lassen   oder ein durch Rechnerdiebstahl abhanden gekommener elektronischer
sich wieder     Geldbeutel (engl. electronic wallet) – lassen sich durch die bei der Installa-
herstellen      tion erzeugte Wiederherstellungszeichenfolge wiederherstellen und auto-
                matisch dem eCash-Konto gutschreiben. Hat der Kunde allerdings die
                Wiederherstellungszeichenfolge vergessen, so ist die Wiederherstellung
                von zerstörten elektronischen Münzen nicht möglich!

                Abbildung 5.2 Historie: das deutsche Portal www.ecash.de wurde im Frühjahr
                            2001 geschlossen




                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               27

Die Anmeldung erfolgt, wie gesagt, über ein entsprechendes eCash-Protal.               Die Anmeldung:
Händler können zunächst über dieses Portal ein Info-Paket anfordern.                   Es geht nicht
Endkunden können sich bei der Regiestrierung online unterstützen lassen.               ohne Medien-
Aus Sicherheitsgründen und wegen gesetzlicher Vorschriften, ist eine rein              bruch
onlinebasierte Anmeldung nicht möglich. Der Interessent kann sich online
über alle Details informieren und auch das Anmeldeformular ausfüllen.
Letztlich muss das Anmeldeformular aber ausgedruckt werden und über
den Identitätsfeststellungsservice eines Dienstleisters oder über eine Filiale
der Bank an die eCash-Betreiberbank zugesandt werden (siehe Abbildung
5.3 Ablauf der Kontoeröffnung bei eCash). Einen Identitätsfeststellungs-
service bietet in Deutschland beispielsweise die Deutsche Post AG mit
ihrem Netz von Postschaltern.

Abbildung 5.3 Ablauf der Kontoeröffnung bei eCash




Nach dem Laden der eCash-Software muss der Kunde mit der Installation Die Installation:
warten, bis er die erforderlichen Zugangsdaten (die eCash-Kontokennung) Berührung mit
von der Bank bereitgestellt bekommen hat. Nach der Installation wird die der Kryptografie

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  28                                                                        J. Anton Illik

                  Geldbörse gestartet und eingerichtet. Einrichtung bedeutet hier, die Sicher-
                  heitsmechanismen der Geldbörse zu aktivieren. Zu diesem Zweck müssen
                  der Münzschlüssel (ein öffentlicher und ein privater Schlüssel) generiert
                  werden, eine Wiederherstellungszeichenfolge und zwei Passwörter: eines
                  für die eCash-Geldbörse und eines für das eCash-Konto.
Das Laden der   Genau wie in der realen Welt muss vor der Online-Shoppingtour im Inter-
eCash-Geldbörse net die eCash-Geldbörse mit einem Guthaben ausgestattet sein. Dies wird
                  bewerkstelligt, indem der gewünschte Betrag vom eCash-Konto in die
                  private eCash-Geldbörse übertragen wird. Die Übertragung selbst wird aus
                  der Geldbörse heraus angestoßen: Man klickt auf das Bankensymbol und
                  anschließend im Menü „Übersicht“ auf den Button „Abhebung“. Nach der
                  Nennung des gewünschten Betrages und der Bestätigung mit dem Konto-
                  passwort kommen die elektronischen Münzen.
Die Bezahlung     Die Sicherheit des eCash-Verfahrens beruht darauf, dass immer alle drei
mit eCash: drei   Transaktionspartner bei einer Zahlung beteiligt sind: der Händler als
Transaktions-     Betreiber des Online-Shops, die Bank als virtuelle Bank und der Kunde.
partner           Der Bank-Server erzeugt und signiert die digitalen Münzen, die der Kunde
                  in seiner elektronischen Geldbörse bereithält. Bei einem Online-Kauf wer-
                  den diese Münzen zum Händler übertragen, der diese sofort bei der Bank –
                  dem sogenannten MINT-Server – einreicht. Der MINT-Server prüft die
                  Echtheit der Münzen und schreibt diese wertmäßig dem eCash-Konto des
                  Händlers gut. Gleichzeitig werden diese Münzen als „verbraucht“ mar-
                  kiert. Die Bank bestätigt dem Händler die Zahlung und dieser stellt dem
                  Kunden die bestellte Ware zur Verfügung.


                  Tabelle 5.1 eCash Kurzcharakteristik



                  Name              eCash
                  Entwickler,       David Chaum, DigiCash, Niederlande; jetzt: eCash Technologies,
                  Hersteller        Bothell, USA
                  Start             Oktober 1994
                  Einführung        Oktober 1995 (Mark Twain Bank2, USA); ab 1997 in Deutschland
                                    von der Deutschen Bank 24. Im Jahr 2001 stellt die Deutsche Bank
                                    24 den Betrieb ein.


                  2
                      Am 25. April 1997 übernahm die Mercantile Bank die Mark Twain Bank. Im September
                       1998 zog sich die Bank aus dem eCash-Geschäft zurück. Ein weiterer Partner war die
                       Firstar Bank ( www.firstar.com).


                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               29

Charakteris-   • Das Zahlungssystem kreiert digitale Münzen. Es ist aufgrund
tik              der angewandten Kryptografie und der von Chaum entwickel-
                 ten und patentierten Blind Signature-Lösung sicher und ano-
                 nym. Geschützt gegen Fälschungsversuche und Mehrfachver-
                 wendung. Die elektronischen Münzen sind dem Absender nicht
                 zuzuordnen, die Zahlung bleibt somit anonym.

Funktionali-   • Geld von der Bank abheben und dort deponieren.
täten von      • Logbuch über ausgeführte und erhaltene Zahlungen, Transakti-
eCash:           onsstatus.
               • Peer-to-Peer-fähig: Per E-Mail können eCash-Münzen an ande-
                 re eCash-Endkunden übertragen werden.
               • Bei defekter Festplatte oder bei Diebstahl des Rechners lassen
                 sich die digitalen Münzen wiederherstellen.
Anmerkung      • Keine Multibanken-Fähigkeit, da eCash in seiner aktuellen
                 Implementierung einen zentralen Bank-Server verlangt. Denk-
                 bar wären jedoch mehrere eCash-Domänen und die Verifikati-
                 on von Münzen aus fremden Domänen mittels eines Clearing-
                 Protokolls.
               • eCash als solches erlaubt uneingeschränkte Anonymität für den
                 Käufer. Dem Verkäufer ist zwar der Inhalt der Transaktion be-
                 kannt, er kann jedoch über die elektronische eCash-Münze
                 nicht auf die Identität des Käufers schließen. Natürlich muss
                 bei der Bestellung physischer Waren dem Händler die Liefer-
                 anschrift angegeben werden. Aber weder eine Kreditkartenge-
                 sellschaft noch die Bank kennt die Transaktionsinhalte (gekauf-
                 tes Produkt oder Dienstleistung). Das Kaufverhalten kann nicht
                 von Dritten analysiert werden. Bei der Zahlung werden keine
                 persönlichen Daten übermittelt.
               • keine Stornierung ausgeführter Zahlungen möglich. (Stornie-
                 rung nur möglich, solange ein Transaktion noch nicht abge-
                 schlossen ist, also wenn bspw. während einer Zahlungstransak-
                 tion die Internetverbindung unterbrochen wird).
               • Einkaufskorb möglich
URL            www.digicash.com, www.ecash.net, www.ecashtechnologies.com



Der Transaktionsablauf
• Bevor der Kunde mit dem Einkaufen beginnen kann, muss er Geld von
  seinem Konto bei der Bank auf seinen lokalen Rechner in sein elektro-
  nisches Portmonee herunterladen. Zu diesem Zweck generiert der Käu-
  fer auf seinem lokalen Computer die Münzrohlinge selbst. Bei diesem


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
30                                                                          J. Anton Illik

      Vorgang erhalten die Münzrohlinge u. a. eine eindeutige Seriennummer.
      Danach wird der Münzrohling durch den privaten Schlüssel des Käu-
      fers signiert, so dass nach dem Einreichen der Münze beim Bank-
      Server dieser anhand des öffentlichen Schlüssels die Zugehörigkeit des
      Münzrohlings zum Käufer verifizieren kann. Bevor jedoch der Münz-
      rohling zur Umwandlung in eine echte Münze zum Bank-Server trans-
      feriert wird, konvertiert die eCash-Software auf der Maschine des Be-
      nutzers die Münz-Datenstruktur in eine Form, die es dem Bank-Server
      unmöglich macht, die Seriennummer zu erkennen (Blinding-Verfahren).
      Der Bank-Server signiert also den Münzbetrag und die Seriennummer
      (blind) durch ein Zertifikat. Dieses Zertifikat ist eine Datenstruktur, die
      in die Münzdatenstruktur integriert wird. So kann der Bank-Server zu
      einem späteren Zeitpunkt, nach der Verwendung der Münze, diese iden-
      tifizieren und ihre Echtheit validieren. Nachdem der Münzrohling mit
      der Blind Signature auf dem Bank-Server versehen wurde, geht dieser
      als gültige Münze zurück auf den Computer in die elektronische Geld-
      börse des Käufers. Die Münze wird jetzt in ihre ursprüngliche Darstel-
      lung zurückkonvertiert unter Beibehaltung des Zertifikats und ihres
      Wertes. Nach dem Prägen und „Scharfmachen“ der Münze weiß der
      Bank-Server zwar, dass der Käufer eine Münze bestimmten Wertes ge-
      neriert hat, der Bank-Server weiß jedoch nicht, um welche konkrete
      Münze es sich dabei handelt.
• Nachfolgend kann der Kunde in einem eCash-Shop Produkte in einem
  virtuellen Warenkorb zusammenstellen.
• Entscheidet sich der Kunde bei der Zahlungsart für eCash, so öffnet
  sich die eCash-Geldbörse und ein Dialogfenster mit einer entsprechen-
  den Zahlungsaufforderung. Wenn der Käufer die Zahlungsaufforderung
  akzeptiert, wird der angezeigte Betrag3 „realtime“ der eCash-Geldbörse
  belastet. Das heißt, die digitale Geldbörse sendet die verschlüsselten e-
  lektronischen Münzen zum Anbieter, der sie unverzüglich zum MINT-
  Server der Bank weiterleitet. Dort wird – basierend auf der Serien-
  nummer und dem Zertifikat – überprüft, ob die gleiche Münze bereits
  eingelöst wurde. Falls dies nicht zutrifft, wird die Münze in der Daten-
  bank als „verbraucht“ gespeichert und der Betrag dem Anbieter wert-
  mäßig gutgeschrieben.
• Sobald der Anbieter die Nachricht über die Gültigkeit der Münzen er-
  hält, schaltet seine Software das digitale Produkt frei. Digitale Güter

3
    Sollte der angezeigte Kaufpreis das aktuelle Guthaben der eCash-Geldbörse überschreiten,
      so schlägt eCash vor, den entsprechenden Differenzbetrag automatisch vom eCash-
      Konto des Käufers in seine eCash-Geldbörse zu übertragen.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               31

   stehen in Form von Downloads in aller Regel sofort nach Bestätigung
   der Zahlungsaufforderung zur Verfügung, wogegen physische Waren an
   die vom Kunden genannte Lieferadresse gesandt werden.
• Ebenso erhält der Kunde eine Quittung, die in Form eines Transaktions-
  satzes in seiner eCash-Software gespeichert wird und auf Abruf sicht-
  bar wird. Die Zahlungstransaktion inklusive der Freischaltung des Pro-
  dukts dauert wenige Sekunden.


Abbildung 5.4 Ablauf der Zahlungstransaktion bei eCash




Eingehende Zahlungen
Der Kunde kann auch Münzen von anderen eCash-Teilnehmern entgegen-
nehmen und seinem Konto gutschreiben lassen. Dies macht z. B. Sinn im
Rahmen einer Rückerstattung von einem Händler oder einer Gewinnaus-
schüttung aus einer Online-Wette. Die eingehende Zahlung kommt als
Anhang einer E-Mail (E-Mail-Attachment). Der Anhang muss von der E-
Mail abgelöst werden und in einem bestimmten Verzeichnis abgelegt wer-


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                32                                                                   J. Anton Illik

                den. Die Übertagung auf das eCash-Konto erfolgt dann mit der eCash-
                Geldbörse.
                Münzen versenden
                eCash ermöglicht auch Zahlungen zwischen Privatpersonen (peer-to-peer
                Zahlungen), sofern alle Beteiligten Teilnehmer des eCash-Verfahrens sind.
                Um eine Zahlung an eine andere Person auszuführen, wird die Schaltfläche
                „Zahlung von Person zu Person“ auf der Übersicht der eCash-Geldbörse
                betätigt. In der Folge werden dann neben der Konntokennung alle zusätzli-
                chen Informationen eingegeben, die dem Empfänger zur Erläuterung der
                Zahlung dienen. Die digitalen Münzen werden dann in einer Datei mit der
                Erweiterung *.eca abgelegt. Wird die Datei nicht explizit benannt, so wird
                sie standardmäßig unter dem Namen payment.eca im Arbeitsverzeichnis
                gespeichert. Um die Datei dem privaten Zahlungsempfänger zukommen zu
                lassen, wird sie als E-Mail-Attachment oder auf Diskette versandt.
                Stornierung von Zahlungen
                Sollte während einer Transaktion die Internet-Verbindung unterbrochen
                werden, so dass über den Erfolg der Zahlung Unklarheit herrscht, kann
                diese Zahlung storniert werden. Zur Stornierung wird mit der eCash-
                Geldbörse aus dem Transaktionsprotokoll die entsprechende Zahlung aus-
                gewählt. Ist die Transaktion mit „ausstehend“ markiert, so ist eine Stornie-
                rung noch möglich. Münzen, die bereits bei der Bank eingelöst wurden,
                können nicht mehr zurückgerufen werden!
                Bewertung
eCash hat die   eCash ist die Bezahlungsmethode Nr.1, wenn es darum geht, dass der Käu-
Nase vorne?     fer nicht zum „gläsernen Kunden“ wird. Bei allen anderen Bezahlungsme-
                thoden kennen Bank oder Kreditkartenorganisation alle Transaktionspart-
                ner und oft auch alle Transaktionsinhalte: „Wer hat was bei wem gekauft“
                – eine in den meisten Fällen für die Finanzinstitute nicht schwer zu beant-
                wortende Frage. Nicht so beim Einsatz von eCash: Da die eCash Münze
                keine Rückschlüsse auf den Absender zulässt, bleibt dieser der Bank ge-
                genüber anonym, sein Kaufverhalten ist nicht analysierbar.

                5.4.2        NetCash
Forschungs-     NetCash stammt von Cliffort Neuman und Gennady Medvinsky vom ISI
prototyp        Information Science Institute der Universität von Süd-Kalifornien und ist
                streng genommen eine Applikation auf der Basis des vorher, ebenfalls von
                Neuman, entwickelten NetCheque-Systems (siehe Kapitel 5.7.1
                NetCheque). Im Gegensatz zu den anderen, hier vorgestellten Zahlungs-



                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               33

systemen, sind die beiden von Neuman entworfenen Systeme Forschungs-
prototypen, die sich heute noch nicht im kommerziellen Einsatz befinden.
Da NetCash auf dem NetCheque-System basiert, kann es auch mit diesem Scheck vor
kombiniert genutzt werden. In Abbildung 5.5 Ablauf der Zahlungstransak- Münze
tion bei NetCash ist ersichtlich, wie das scheckbasierte System NetCheque
einer Zahlungstransaktion mit NetCash vorgeschaltet wird, um elektroni-
sche Münzen vom Währungs-Server (kurz WS genannt) zu erhalten. Mit
NetCash wurde ein Verfahren entwickelt, das den beiderseitigen Schutz der
Marktteilnehmer berücksichtigt.
Der Transaktionsablauf
• Der Kunde sendet eine Münze M an den Währungs-Server, der aus
  dieser Münze mehrere Münzen (M1, M2, M3) mit gleichem Wert und
  gleicher Seriennummer, aber unterschiedlichen Gültigkeitszeiträumen
  kreiert.
• Nachdem der Kunde beim Anbieter ein Produkt ausgewählt hat, bezahlt
  er mit M1, die eine bestimmte Gültigkeitsdauer hat.
• Angenommen, der Anbieter zahlt die Münze innerhalb des Gültigkeits-
  zeitraumes beim Währungs-Server ein, liefert jedoch das Produkt nicht,
  kann der Kunde, nachdem der Gültigkeitszeitraum von M1 abgelaufen
  ist, den Missbrauch durch Nachfrage beim Währungs-Server aufdecken
  und eliminieren lassen.
• Der Währungs-Server gibt in diesem Fall dem Kunden eine neue Mün-
  ze mit dem Wert von M1 aus und belastet sie dem Anbieter-Konto.
Der Mechanismus des beiderseitigen Schutzes bei Zahlungstransaktionen
über das Internet ist in Abbildung 5.5 Ablauf der Zahlungstransaktion bei
NetCash nochmals zusammenfassend dargestellt.

Tabelle 5.2 NetCash Kurzcharakteristik


Name             NetCash
Entwickler,      Clifford Neuman und Gennady Medvinsky; Information Sci-
Hersteller       ences Inst., Univ. of Southern California in Los Angeles
                 (ISI/USC)
Start            1994
Einführung       Ausschließlich als Forschungsprototyp im Einsatz (laut E-Mail
                 von Neuman am 17. Juni 1997)
Charakteris-     NetCash produziert digitale Münzen, die mit Signaturen der
tik              Bank und einem Verfallsdatum versehen sind. Die Infrastruktur
                 basiert auf unabhängigen, verteilten Währungs-Servern (WS)

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
34                                                                   J. Anton Illik

                 und mehreren Accounting-Servern (AS).
                 Aufgaben der Währungs-Server [vergl. Frotscher]:
                 • Überprüfung der Münzen auf Echtheit
                 • Münzaustausch gegen neue Münzen gleichen Wertes, um die
                     Verfolgung der Münzen zu verhindern und somit die Ano-
                     nymität der Besitzer zu wahren
                 • Verkaufen und Einlösen von Münzen
                 Aufgaben der Accounting Server:
                 • führen die WS-Konten
                 • führen die Konsumenten-Konten
                 • lösen Schecks ein
                 • identifizieren bei Scheckeinlösung die WS
                 Das NetCash-Modell kategorisiert Banken in eine „Zentralbank“
                 (federal insurance corporation) und „normale“ Banken (curren-
                 cy server) mit ihren Währungs-Servern (WS).
                 Die WS werden von der „Zentralbank“ überwacht und bekom-
                 men von ihr Erlaubniszertifikate, die sie zur Ausgabe elektroni-
                 scher Münzen befähigt.
Anmerkung        • Basiert auf NetCheque aus dem gleichen Hause
                 • Da die Münze mit dem öffentlichen Schlüssel des Verkäufers
                     kryptiert ist, besteht für den Verkäufer keine Anonymität.
                 • Laut Wayner sind die verwendeten Protokolle recht einfach
                     gestaltet, so dass die Banken möglicherweise die Kunden-
                     spuren zurückverfolgen können [Wayner, 123].
                 • Das Betrugspotenzial ist reduziert durch die eingeschränkte
                     Anonymität des Käufers.
                 • Die Tatsache eines Münzverfallsdatums widerspricht einer-
                     seits der Idee der persistenten Wertaufbewahrung, anderer-
                     seits spricht der Kundenschutz dafür.
                 • NetCash ist multibankenfähig: Es existiert ein Clearing-
                     Protokoll zwischen den Bank-Servern im NetCash-System
                     um ein double-spending zu unterdrücken.
URL              http://gost.isi.edu/info/netcash




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                                                             35

Abbildung 5.5 Ablauf der Zahlungstransaktion bei NetCash




           Kunde              Währungs-Server                        Anbieter              Accounting-Server



     Scheckausstellung         Scheckeinreichung                                                 Clearing



            Münzerhalt           Münzerstellung




     sendet eine Münze        generiert M1, M2, M3
                                  mit gleicher
                                 Seriennummer



    bezahlt Produkt beim
                                                                  überprüft mit öffentl.
      Anbieter mit M1,
                                                                 Schlüssel des WS die
      behält M2 und M3
                                unberechtigte Ein-    entweder   Gültigkeit der Münzen
                               zahlung der Münzen
                                ohne Produktaus-
                  entweder          lieferung


                                 wurden Münzen
         kein Produkterhalt
                                   einbezahlt?
                                                                      oder
  oder                         falls M1 einbezahlt:
                               Abbuchung des Be-
                                 trages auf dem
                                   Anbieterkonto                     Quittung- und
          Quittung- und                                           Produktauslieferung
          Produkterhalt




Bewertung
Voll ausgereift ist der Zahlungsmechanismus jedoch nicht, da bisher noch Wie beweist man
nicht geklärt ist, wie der Kunde beweisen soll, dass er tatsächlich keinen Nepp?
Gegenwert für die Münze M1 von dem Anbieter erhalten hat [Frotscher].
Ob sich das System auf breiter Basis durchsetzen wird, bleibt abzuwarten. Für
Jedoch sprechen die kombinierte Nutzung mit NetCheque, die Offenheit Micropayments
des Systems (mehrere WS und AS) und die Eignung für Micropayments geeignet
zukünftig für die Verbreitung und den erfolgreichen Einsatz.


5.5 Zahlungssysteme auf Basis von Kreditkarten
Entsprechend der Beliebtheit der Kreditkarte in der konventionellen Ein- Datenstruktur
kaufswelt wiederholt sich der Siegeszug dieser Art des Bezahlens auch in statt Plastik
der immateriellen Welt elektronischer Märkte. Die Kreditkarte gehört nach
wie vor zu den beliebtesten Internet-Zahlungsmitteln.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
             36                                                                   J. Anton Illik

             Abbildung 5.6 Gebrauch von Kreditkarten im Internet [vgl. Weiler]




Die Masse    Zahlungen über das Internet wurden bisher überwiegend mit Kreditkarten
macht‘s      getätigt [Weiler] und diese Zahlungsart wird auch in Zukunft dominieren
             [Weisman/Trevino/Sweet], da hier internationale Verbreitung (mehr als
             800 Millionen Kreditkarten weltweit [Foremski]) und Standardisierung
             (siehe Kapitel 5.13.5 SET: Secure Electronic Transactions oder Kapitel
             5.13.6 SSL: Secure Socket Layer) vorhanden sind. Der herkömmliche
             Prozess der Kreditkartenzahlung wird dabei auf das Internet abgebildet
             und ein Zahlungs-Server bedient generell die Schnittstelle zwischen dem
             Internet und dem Finanznetzwerk. Die Bearbeitung von Kreditkarten-
             zahlungen (z. B. das Clearing) ist bisher immer noch zu teuer für Micro-
             payment-Einkäufe. Selbst durch Hinzufügen eines Zertifikats bei Kredit-
             kartenzahlungen (zur Verringerung der Betrugsrate) und der daraus resul-
             tierenden Kostenreduktion ist eine Eignung für Micropayment-Einkäufe
             schwer zu erreichen.
             Die Bezahlung mit der Kreditkarte (VISA, MasterCard, Barclays u. a.) im
             Internet bietet keine Anonymität, da das Finanzunternehmen sämtliche
Keine
             Daten erhält und speichert, wie dies bei der bisherigen Abrechnung auch
Anonymität
             außerhalb des Internet der Fall ist. Weiterhin gilt ein Zahlungvorgang erst
             als genehmigt, wenn innerhalb einer bestimmten Zeit (meistens neunzig
             Tage) keine Einwände des Kunden gegen die monatliche Kreditkarten-
             Abrechnung eingebracht wurden [Janson/Waidner, 1996a, 4]. Einen Vorteil
             bei der Zahlung mit Kreditkarten sehen die Banken darin, dass die Trans-

             Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
             chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                                         37

aktionen bei Kreditinstituten beginnen (Authentifizierung der Kreditkarte)
und auch bei diesen enden (Gutschrift auf dem Anbieterkonto).
Nachteile treten auf, wenn Kreditkartennummern unverschlüsselt über das Vertrauen ist gut,
Internet übertragen werden, denn mit spezieller Software (Paket-Sniffern) Verschlüsselung
können unverschlüsselte Informationen unter bestimmten Voraussetzungen ist besser
gezielt abgehört werden [Reif, 144]. Eine durch das Forschungs- und Bera-
tungsunternehmen Global Concepts in Atlanta erstellte Studie aus dem
Jahre 1995, die für VeriFone und MasterCard erstellt wurde, belegt, dass
viele Konsumenten dem Karten-Missbrauch eine hohe Bedeutung beimes-
sen.4 Jedoch verwenden heute fast alle aktuellen Systeme Verschlüsse-
lungsmechanismen. Einen weiteren Schutz vor dem Abhören bietet das
immens hohe E-Mail-Aufkommen im Internet. Weiterhin ist eine sichere
Speicherung der Kreditkartennummer bei dem Kreditkarteninstitut erfor-
derlich. Ein bekannter Fall von Kreditkarten-Informationsraub ist z. B. der
„Einbruch“ in einen Rechner von Netcom (Internet-Provider) durch Kevin
Mitnick im Jahre 1994. Die Beute belief sich auf 20.000 Datensätze mit
Kreditkarteninformationen [Reif, 145]. Der Vorfall hat die Branche aufge-
schreckt und für das Thema Sicherheit sensibilisiert.

5.5.1           First Virtual
Die First Virtual Holdings Inc. war die erste Gesellschaft, die auf der Basis Frühstarter
von Kreditkarten ein auf das Internet zugeschnittenes Zahlungssystem
angeboten hat. Mitte 1998 stellte First Virtual den Betrieb ein. Die offiziel-
le Begründung lautete, dass sich mit 2000 Akzeptanzstellen im Internet
und 60.000 Nutzern der Service nicht lohne. Das Modell von First Virtual
wurde von anderen Anbietern aufgenommen, so dass sich die Betrachtung
des Modells nach wie vor lohnt.
Eine wesentliche Idee von First Virtual war, dass der Käufer zwar Kredit- Die Idee
kartenbesitzer sein muss, der Verkäufer aber keine Kreditkartenakzeptanz-
stelle! Diese Funktion wurde von der First Virtual-Zentrale wahrgenom-
men. Nach der Kreditkartenbelastung durch First Virtual wurde das Geld
per Banküberweisung dem Verkäufer gutgeschrieben.
Die Entwickler haben First Virtual ganz im Sinne eines verteilten Systems Virtual Company
von unterschiedlichen Orten (San Diego, Orange, Silicon Valley und New
Jersey) aus entwickelt. Physische Büros gab es erst 15 Monate nach Firmen-
gründung und acht Monate, nachdem das System lauffähig war. Probleme


4
    vgl. Money and Concerns found in Internet Commerce. In: Data Storage Report via Dow Jones
    Retrieval, 01.07.96. Publiziert in: „e-payments“-Diskussionsliste am 07.08.96 von Tom Wills


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
              38                                                                   J. Anton Illik

              und Vorteile dieser verteilten Firma sind ausführlich in [Borenstein] erläu-
              tert.
Ablenkungs-   Um die Problematik der fehlenden Verschlüsselungen abzuschwächen,
manöver       zeigte die FV Holdings mit einem Programm auf, dass Verschlüsselung
              allein nicht die Lösung für die garantierte Sicherheit ist, da die Verschlüs-
              selung nicht direkt bei der Eingabe an der Tastatur beginnen kann. Das
              Programm ist eine Art Tastatur-Abhörer: Es beobachtet die Tastatur und
              wartet, bis der Benutzer eine komplette Kreditkartennummer eingegeben
              hat. Theoretisch kann die Nummer an andere Internet-Teilnehmer versen-
              det werden. First Virtual weist mit diesem Programm auf die Sicherheits-
              problematik bei Software-Lösungen hin.


              Tabelle 5.3 Kurzcharakteristik des First Virtual Modells



              Name             First Virtual (FV)
              Entwickler,      Nathaniel S. Borenstein, Marshall T. Rose, Einar A. Stefferud
              Hersteller       und Lee Stein, First Virtual Holdings Inc.
              Start            Mai 1994
              Einführung       15. Oktober 1994; Ende: Mitte 1998
              Charakteris-     • FV ist ein Kreditkarten-Zahlungssystem, welches dem Kun-
              tik                  den ermöglicht, das Produkt vor dem Kauf zu testen.
                               • Für Zahlungen werden E-Mails verwendet, die auf
                                   SMTP/RFC822/MIME und SMXP basieren.
                               • Es wird keine Kryptografie angewandt.
                               • Die Kunden müssen bei der Zentrale (das war FV) eine Vir-
                                   tualPIN beantragen und die Anbieter ihre Bankverbindung
                                   bekanntgeben.
                               • Die Belastung der Kundenkonten und Gutschrift der Anbie-
                                   terkonten erfolgt täglich.
                               • Die Gebühr für eine Zahlungstransaktions-Übersicht belief
                                   sich für den Kunden auf US$ 2, der Anbieter kann für US$
                                   1eine Übersicht seiner Einnahmen beziehen.
                               • Die Registierung bei FV kostete den Anbieter einmalige US$
                                   10, der Kunde musste US$ 2 bezahlen.
              Anmerkung        • FV-Zahlungsserver speichert alle Transaktionsdaten, kennt
                                   also auch den Transaktionsinhalt.
                               • Für einen Kaufvorgang sind eine große Anzahl von Transak-
                                   tionsschritten auszuführen, was die Kommunikationskosten


              Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
              chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               39

                     in die Höhe treibt.
                 •   Abhörgefahr, da keine Verschlüsselungen.
                 •   Geschlossenes System.
                 •   Keine Rückerstattungen.
                 •   Ursprünglich nur produktbezogene Zahlung; kein Einkaufs-
                     korb.
                 •   Keine Stornierung ausgeführter Zahlungen.
                 •   Kein kryptografisches Verfahren zur Erlangung von Anony-
                     mität (des Käufers gegenüber dem Verkäufer) notwendig.
                 • Sehr geringe Rüstkosten bei der Integration des Zahlungsver-
                   fahrens.
                 • Verkäufer trägt das gesamte Transaktionsrisiko. Der Verkäufer
                   kann allerdings das Risiko auf den Käufer abwälzen, in dem
                   digitale Güter zunächst (teil-) verschlüsselt ausgeliefert werden
                   und der Schlüssel erst nach dem Zahlungseingang geliefert
                   wird.
URL              -




Abbildung 5.7 Ablauf des Registrierungsprozesses beim First Virtual-Modell




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                     40                                                                   J. Anton Illik

Statt                Um am FV-System teilnehmen zu können, benötigte der Kunde eine E-
Kreditkarten-        Mail Adresse im Internet und eine gültige Kreditkarte. Ausgehend von der
nummer geht die      First Virtual Web-Seite konnte die Registrierung gestartet werden. Das
VirtualPIN über      Registrierungsformular musste ausgefüllt und an FV gesandt werden. Da-
das Netz             nach erhielt der Kunde seine gültige VirtualPIN, mit der er seine Kredit-
                     kartennummer per Telefon an FV durchgab. Bei FV wurden die Nummern
                     auf separaten Rechnern abgespeichert. Mit der VirtualPIN veranlasste der
                     Kunde nachfolgend die Zahlungen, so dass die Kreditkartennummer nie
                     über das Internet versendet werden musste.
                     Der Transaktionsablauf
Initiiert wird mit   Ein Anbieter musste über ein Bankkonto verfügen, das direkte Gutschrif-
konventionellem      ten zulässt (durch das US ACH5-System, ein US-Banken-Clearing-Netz).
Geld                 Ebenso wie der Kunde musste der Anbieter das Registrierungsformular
                     ausfüllen und an FV senden, wo eine Registrierungsnummer erstellt wurde.
                     Danach sendete der Anbieter einen Scheck über die Registrierungsgebüh-
                     ren zusammen mit der Registrierungsnummer und den Bankkonto-
                     Informationen per Post an FV.
                     Nach erfolgreicher Registrierung konnten Zahlungstransaktionen ausge-
                     führt werden, die sich in folgende Schritte unterteilten:

                     Abbildung 5.8 Ablauf der Zahlungstransaktion beim First Virtual Modell




                     5
                         Automated Clearing Houses


                     Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                     chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               41

• Der Kunde sendet dem Anbieter per E-Mail seine VirtualPIN und bittet
  um Zusendung des gewünschten Produkts. Dieser kann die VirtualPIN
  ohne großen Aufwand als gültig verifizieren.
• Der Anbieter sendet dem Kunden das angeforderte digitale Produkt per
  E-Mail oder das materielle Gut per Post zu.
• Ebenso wird vom Anbieter an First Virtual die Kunden-VirtualPIN
  zusammen mit dem Zahlungsbetrag übermittelt.
• Der Kunde kann nun das Produkt testen.
• Nach angemessener Zeit sendet der FV-Zahlungs-Server dem Kunden eine
  E-Mail, in welcher dieser den Kauf bestätigen und somit die Zahlung ver-
  anlassen soll. Der Anbieter erhält eine Kopie der Kundenreaktion.
• Falls der Kunde den Kauf positiv bestätigt, wird der Betrag noch am
  selben Tag dem Kunden belastet und dem Anbieter abzüglich der FV-
  Gebühren gutgeschrieben.
• Bei einem „Nein“ des Kunden wird die Zahlung nicht ausgeführt. Falls
  dies jedoch häufig geschieht, wird die VirtualPIN des Kunden gelöscht.
• Es besteht auch die Möglichkeit mit „Fraud“ zu antworten, wenn der
  Kunde beispielsweise der Ansicht ist, dass seine VirtualPIN miss-
  bräuchlich verwendet wird. FV löscht auch in diesem Fall die Virtual-
  PIN.
Das Modell unterstützt mehrere Sprachen und, da es auf dem Kreditkarten- Test vor Kauf
Prinzip beruht, auch mehrere Währungen. First Virtual ist das einzige Mo-
dell, das dem Kunden erlaubt, das Produkt vor dem Kauf zu testen.
Bewertung
Obwohl First Virtual keine Verschlüsselung bei Zahlungstransaktionen                   Verkäufer muss
vornimmt, wurde das System rege genutzt. Vermutlich ist das auf den Ab-                keine Kredit-
lauf der Transaktion zurückzuführen und die damit verbundene Produkt-                  kartenakzeptanz-
auslieferung vor der Zahlung. Ein weiteres Argument: Der Verkäufer muss                stelle sein
keine Kreditkartenakzeptanzstelle sein! Der Verkäufer bekommt sein Geld
auf ein konventionelles Konto gutgeschrieben.

5.5.2        CyberCash
Neben der Kreditkartenzahlung unterstützt das CyberCash-System als Drei Zahlungs-
Zahlungsmethoden noch eine Methode, die auf Schattenkonten basiert methoden
(siehe Kapitel 5.11.1 CyberCoin) und EDD (electronic direct debit, elekt-
ronisches Lastschriftverfahren). Im Wesentlichen besteht das System aus
drei Komponenten. Das Zusammenspiel der Komponenten gewährleistet


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  42                                                                   J. Anton Illik

                  den beteiligten Parteien die reibungslose Abwicklung von Zahlungsvor-
                  gängen im Internet.
                  Die CyberCash-Geldbörse (Wallet)
Die Kunden-       Bei der CyberCash-Geldbörse handelt es sich um Software, die auf dem
Schnittstelle     Computer des Online-Konsumenten installiert wird und mit dem jeweili-
                  gen Web-Browser zusammenarbeitet. Jeder Kunde der CyberCash-
                  Lizenzbanken kann die Wallet-Anwendung aus dem Internet holen und
                  sich nach der Installation ohne weitere Kosten eine oder mehrere Cyber-
                  Cash-Geldbörsen einrichten. Jede CyberCash-Geldbörse erhält bei der
                  Online-Inbetriebnahme eine eindeutige Kennung (Wallet-Id) und ein zuge-
                  ordnetes Schlüsselpaar. Beides wird zur Sicherung von Transaktionen ein-
                  gesetzt. Nach der Einrichtung einer Geldbörse legitimiert sich der Kunde
                  gegenüber seiner Bank und schließt den Wallet-Vertrag, der u. a. eine Er-
                  mächtigung für die Bank enthält, sein Bankkonto mit Beträgen aus den
                  von ihm veranlassten CyberCoin- und EDD-Transaktionen zu belasten.
                  Die CyberCash-Kasse (CashRegister)
Die Händler-      Das CashRegister ist das Softwarepaket, das den Online-Händlern von den
Schnittstelle     angeschlossenen CyberCash-Lizenzbanken gegen eine geringe Inbetrieb-
                  nahmegebühr zur Verfügung gestellt wird. Es wird in der Umgebung des
                  Web-Servers des Händlers installiert. Das CashRegister kommuniziert
                  sowohl mit der Wallet-Anwendung des Konsumenten als auch mit dem
                  CyberCash-Gateway (s. u.).
                  Wie bei der CyberCash-Geldbörse werden auch bei der Online-
                  Inbetriebnahme des CashRegisters für einen Händler eine eindeutige Ken-
                  nung (Merchant-CCId) und ein Schlüsselpaar zur Sicherung der Zahlungs-
                  transaktionen erzeugt.
Mall-fähig        Vergleichbar ist das CashRegister mit einem konventionellen Point-of-
                  Sale-System, das aber über spezielle Anpassungen für das Internet verfügt.
                  Es erlaubt eine Nutzung durch mehrere Online-Händler gleichzeitig, z. B.
                  im Rahmen einer virtuellen Shopping-Mall (siehe Kapitel Fehler! Ver-
                  weisquelle konnte nicht gefunden werden.Fehler! Verweisquelle konn-
                  te nicht gefunden werden.). Die Anbindung an bestehende Web-
                  Angebote erfolgt über CGI-Programme, die auf einer in C oder Perl ver-
                  fügbaren API aufbauen. So kann es den individuellen Bedürfnissen des
                  Händlers angepasst werden. Die Administration des CashRegisters erfolgt
                  über einen Web-Browser.
                  Das CyberCash-Gateway
Die Bankennetz-   Das CyberCash-Gateway bildet die Brücke zwischen dem Internet und den
Schnittstelle     Finanzinstitutionen, über welche alle im Internet initiierten Zahlungsvor-
                  gänge abgewickelt werden. Gegenüber Online-Konsumenten und Online-

                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               43

Händlern prüft das CyberCash-Gateway Echtheit und Ursprung aller
Nachrichten. Das Gateway kann in drei Bereiche unterteilt werden:
    •    Firewalls und Frontend-Server: Diese Server-Systeme sichern
         die Verbindung des Gateway-Systems ins Internet ab. Die Fire-
         walls akzeptieren ausschließlich HTTP-Anforderungen. Außerdem
         werden alle Zugriffsversuche – erfolgreiche und abgelehnte – pro-
         tokolliert. Entprechend ihrem Inhalt werden die gültigen Nachrich-
         ten von den Frontend-Servern an das jeweilige Kernsystem wei-
         tergeleitet.
    •    Kernsysteme: In den Kernsystemen ist die gesamte Systemlogik
         enthalten. Für die unterschiedlichen Bereiche wie Konsumenten
         und Händler gibt es auch jeweils verschiedene Prozessoren. Sie
         führen alle Systemfunktionen, wie die Autorisierung der Wallet-Id,
         die Einbindung eines neuen Zahlungsmittels in eine Geldbörse o-
         der die Prüfung und Weiterleitung einer Zahlungstransaktion
         durch. Außerdem unterhalten sie die dazu notwendigen Datenban-
         ken.
    •    Backend-Prozessoren: Die Backend-Prozessoren leiten die zah-
         lungsrelevanten Nachrichten der Kernsysteme in die Netze der an-
         geschlossenen Kreditinstitute und Kreditkartenprozessoren. Dabei
         werden die Nachrichten in die von diesen Institutionen eingesetz-
         ten Protokolle gewandelt. Zu Abrechungszwecken wird über alle
         in die Abrechnungsnetze eingespeisten Transaktionen Buch ge-
         führt.
Der Gateway-Betreiber
Der Gateway-Betreibe besitzt die Lizenzrechte an den CyberCash- Der Lizenzgeber
Systemkomponenten. Während er für die Nutzung von CashRegister- und und Gateway-
Wallet-Anwendungen entsprechende Rechte zu jeweils gleichen Bedin- Betreiber
gungen an die angeschlossenen Kreditinstitute vergibt, betreibt er in deren
Auftrag das Gateway-System. Der Gateway-Betreiber erbringt selbst keine
Zahlungverkehrsdienstleistungen und unterhält auch keine Verrechnungs-
konten; er hat auch keine Vertragsbeziehungen mit Online-Händlern und
Online-Konsumenten.
Die Kreditinstitute
Die an das CyberCash-System angeschlossenen Kreditinstitute (Cyber- Die CyberCash-
Cash-Lizenzbanken) sind die alleinigen Anbieter der CyberCash- Dienstleister
Dienstleistungen. Sie schließen entsprechende Vereinbarungen mit Online-
Händlern und Online-Konsumenten über die Nutzung der Systemkompo-
nenten und der Bezahlverfahren ab. Sie verteilen außerdem die benötigte


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  44                                                                       J. Anton Illik

                  CashRegister- und Wallet-Software und unterhalten sämtliche für die je-
                  weiligen Bezahlverfahren benötigten Verrechnungskonten.
Registrierungs-   Für die Anwendung der kryptografischen Verfahren zur Echtheits- und
instanzen         Ursprungsprüfung von Nachrichten im CyberCash-System übernehmen
                  die Kreditinstitute die Funktion von Registrierungsinstanzen. Sie prüfen
                  und bestätigen die Verfügungsberechtigung des jeweiligen Systemteilneh-
                  mers über die von ihm angewandten Zahlungsmittel (Kontovollmacht,
                  Kreditkarteninhaberschaft) und bestätigen diese gegenüber dem Gateway-
                  Betreiber unter Angabe der bei der Online-Registrierung vergebenen ein-
                  deutigen Kennung der jeweiligen Systemkomponente (Wallet-Id, Mer-
                  chant-CCId).
Acquirer          Eine Sonderrolle nehmen die spezialisierten Kreditinstitute (Acquirer6) ein,
                  denen der Online-Händler gemäß einem speziellen Akzeptanzvertrag
                  (Mailorder-Service-Vereinbarung) die Kreditkartenumsätze einreicht. Das
                  CyberCash-System verhält sich für diese Institute wie ein Netz aus POS-
                  Terminals aus der physischen Geschäftswelt. Zur eindeutigen Kennzeich-
                  nung der jeweiligen Händler-Software, des CashRegisters, vergibt der
                  Gateway-Betreiber an die Online-Händler, die von ihren Kunden Kredit-
                  kartenzahlungen entgegennehmen, eine Terminal-Identifikationsnummer
                  (TID).
Arbeitsgruppen    Auf der CeBIT 1997 gaben die Dresdner Bank (http://www.dresdner-
und Koalitionen   bank.de) und die Landesbank Sachsen (http://www.sachsenlb.de) Projekt-
formieren sich    absichten mit CyberCash Inc. bekannt. Die beiden Banken und CyberCash
                  haben sich zu einer Arbeitsgruppe zusammengefunden, die den Grundstein
                  legen möchte für „eine Kooperation zwischen Banken, Kreditkartenprozes-
                  soren und Händlern in Deutschland ... In einem ersten Schritt ist die Ein-
                  führung des CyberCash-Kreditkarten-Service vorgesehen. Das System
                  ermöglicht den im Internet präsenten Händlern und Dienstleistern zu jeder
                  Tages- und Nachtzeit den Verkauf von Waren sowie die Abrechnung von
                  online erbrachten Leistungen. In den USA wird dieser Service seit 1995
                  von CyberCash betrieben, wobei mehr als 300 Händler dem System ange-
                  schlossen sind. Der CyberCoin-Service7 soll in einem zweiten Schritt an-
                  geboten werden. Dieser ist bereits seit Oktober 1996 in den USA einge-
                  führt und ermöglicht die direkte Bezahlung von Nachrichten, Informatio-
                  nen, Software oder ähnlichen Angeboten, also Leistungen, die für die Be-
                  zahlung mit Kreditkarte nicht geeignet sind.“

                  6
                      Zu deutsch: Kreditkarten-Einreichinstitut.
                  7
                      CyberCash wurde dann tatsächlich angeboten und Anfang 2001 wieder aus dem Angebot
                        genommen: „Akzeptanz zu gering!“. Das „coin“-Verfahren wurde garnicht erst angebo-
                        ten.


                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               45

Tabelle 5.4       Die ursprünglichen8 CyberCash-Lizenzbanken


Commerzbank                               Sparkasse Gelsenkirchen
Dresdner Bank                             Stadtsparkasse Düsseldorf
HypoVereinsbank                           Stadtsparkasse Köln
Landesbank Baden-Württemberg              Stadtsparkasse Wuppertal
Landesbank Sachsen                        Westdeutsche Landesbank
Postbank


CyberCash verwendet Verschlüsselung und digitale Signaturen, um die Hohe Basis-
Integrität und Vertraulichkeit der Transaktion zu sichern, aber auch die sicherheit
Authentizität und Nichtabstreitbarkeit der Transaktion zu garantieren.
Beim CyberCash-System nutzen die Privatkunden die so genannte Cyber- Geldbörse kommt
Cash-Geldbörse (Wallet), die auf dem Computer des Kunden installiert per Download
wird. Die Wallet-Software ist kostenlos auf den Internet-Seiten der Cyber-
Cash-Lizenzbanken per Download erhältlich. In dieser Geldbörse kann der
Kunde sämtliche Daten, die für die Zahlung im Internet benötigt werden,
verschlüsselt und passwort-geschützt verwalten. Die CyberCash-Software
gewährleistet sichere Verbindungen zwischen Händler und Kunden sowie
den Banken und Kreditkartenorganisationen.
Einen weiteren Schutz vor Missbrauch bietet die Anonymität der Kunden- Schutz vor
daten aus dem Zahlungsvorgang. So kann im Gegensatz zur Kreditkarten- Missbrauch
oder Lastschriftbuchung ohne CyberCash-Wallet der Händler diese Daten
aus dem Zahlungsvorgang nicht erkennen. Weitere Sicherheit für den
Kunden bietet die Tatsache, dass alle Händler bei Abschluss des Cyber-
Cash-Vertrags bei einer der Lizenzbanken registriert werden.
Nach der Installation der Wallet-Anwendung und der Einbindung der Zah- Kunden-
lungsmethoden in eine Geldbörse schließt der Kunde mit der CyberCash- registrierung
Lizenzbank, von deren Web-Site er die Wallet-Software übertragen hat,
einen Servicevertrag, den CyberCash-Kundenvertrag. Vertragsformulare
kann er bei einigen Lizenzbanken ebenfalls von der Web-Site laden, bei
anderen kann er sich über ein entsprechendes Formular online anmelden
und erhält auf dem Postweg die Vertragsunterlagen. In den Vertragsunter-
langen erklärt der Kunde, dass er eine durch ihre Kennung (Wallet-Id)
eindeutig identifizierte CyberCash-Geldbörse eingerichtet hat und über
die darin eingebundenen Zahlungsmittel im Rahmen der CyberCash-

8
    Heute sind nur noch die Commerzbank und die Dresdner Bank aktive CyberCash-
     Lizenzbanken.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                46                                                                   J. Anton Illik

                Bezahlverfahrens verfügen will. Die Bank prüft die Identität des Kunden
                anhand des vorgelegten Personalausweises oder Reisepasses. Für diese
                Authentifizierung kann auch der Identitätsfeststellungsservice der Deut-
                schen Post AG genutzt werden. Außerdem erteilt der Kunde seiner Bank
                eine Einzugsermächtigung für das Laden von CyberCoin-Beträgen und die
                Belastung von Umsätzen beim Bezahlen mit dem CyberCoin-EDD-
                Verfahren (electronic direct debit, elektronisches Lastschriftverfahren).
                Der zwischen der Bank und dem Kunden geschlossene Wallet-Vertrag
                regelt die beschriebenen Registrierungsvorgänge und weitere Rechte und
                Pflichten aus der Benutzung des CyberCash-Systems.
Händler-        Der Registrierungsprozess für Online-Händler verläuft in ähnlicher Weise.
registrierung   Statt der Wallet-Id legt der Händler seiner Bank die Kennung für das
                CashRegister (die Merchant-CCId) vor und schließt den Händler-Vertrag,
                welcher detaillierte Regelungen zur Anwendung der CyberCash-
                Bezahlungsverfahren enhält.


                Tabelle 5.5 CyberCash Kurzcharakteristik



                    Name           CyberCash
                    Entwickler,    William Melton, Daniel Lynch, u. a.; CyberCash Inc.9, im Au-
                    Hersteller     gust 1994 von William Melton, Daniel Lynch, Steve Croker und
                                   Donald Eastlake gegründet.
                    Start          1994
                    Einführung     April 1995. In Deutschland 1997. 2001 stellen die deutschen
                                   Lizenzbanken den originären CyberCash-Betrieb ein und steigen
                                   um auf den POSH-Service (siehe hierzu: www.cybercash.de)
                    Charakteris-   Systembeschreibung:
                    tik            • RSA- (768-bit; Ende 1996:1024-bit) und DES- (56-bit) Ver-
                                     schlüsselung, kreiert digitale Signaturen.
                                   • Funktioniert durch Firewalls.
                                   • Kommunikation zwischen Anbieter, Kunde und dem Cyber-
                                     Cash-Server basiert auf HTTP.
                                   • Kommunikation zwischen dem CyberCash-Gateway und den
                                     Kreditkarteninstituten basiert auf dem vorhandenen Finanz-


                9
                    Die CyberCash Inc. wurde im Jahr 2001 von VeriSign Inc. (www.verisign.com) über-
                     nommen. VeriSign integrierte das CyberCash-System in das eigene System namens
                     Payflow.


                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               47

                    netzwerk (Clearing-Netz).
                 • CyberCash ist ein Mittler zwischen dem Verkäufer und der
                   Bank und leistet die Verschlüsselungsarbeit.
                 • US-Kreditkartengesellschaften haften für Schaden über US$
                   50, was die Kundenakzeptanz erhöht.
                 • Kunde-zu-Kunde-Transaktionen sind geplant.
                 • Keine Sicherheitsschwächen bekannt (keine Anonymität).
Anmerkung        • Geschlossenes System.
                 • Für Micropayments bedingt geeignet (durch Häufe-
                     lung/Akkumulation).
                 • Keine Rückerstattungen.
                 • Keine Stornierung ausgeführter Zahlungen.
                 • Seit 1996 gibt es von CyberCash auch das münzbasierende
                     Zahlungssystem CyberCoin und das scheckbasierende Sys-
                     tem PayNow.
URL              http://www.cybercash.com



Der Transaktionsablauf
• Die Zahlungstransaktion wird gestartet, sobald der Nachfrager die ge-
  wünschten Produkte ausgewählt und der Verkäufer die Rechnung gene-
  riert hat.
• Durch Nachrichtenversendung (Rechnung) wird beim Kunden lokal das
  Wallet gestartet. Zukünftig wird der Kunde das Zahlungsmittel in Ab-
  hängigkeit der vom Anbieter unterstützten Zahlungsmittel (zunächst nur
  Kreditkarten, elektronische Schecks oder Münzen) auswählen können.
• Die Kunden-Software verschlüsselt die sensiblen Daten wie z. B. die
  Kreditkartennummer und die Transaktionsdaten mit dem öffentlichen
  Schlüssel des CyberCash-Gateways, unterschreibt die Daten und sendet
  sie zum Verkäufer.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                 48                                                                          J. Anton Illik

                 Abbildung 5.9 Ablauf der kreditkartenbasierten Zahlungstransaktion bei Cyber-
                 Cash



                                                                    CyberCash             Kreditkarten-
                           Kunde               Anbieter
                                                                     Gateway              Unternehmen

                      kennzeichnet die        generiert und
                       Produkte, die er     sendet Rechnung
                       kaufen möchte                              authentifiziert Kunde
                      und klickt auf den                             und Anbieter;
                        "PAY"-Button                                  entschlüsselt
                                                                   Rechnungsbeträge
                                                                     und vergleicht,
                                                                  formatiert Nachricht     Kreditkarten-
                           sendet           fügt Identifikation            um             Authorisierung
                        verschlüßelte          und erneut
                       Zahlungs- und        Rechnungsbetrag
                        Transaktions-         verschlüsselt
                      daten mit digitaler          hinzu
                         Unterschrift
                                            erhält Ergebnis,         erhält Ergebnis,
                                             liefert Produkt        leitet alles weiter
                        erhält Produkt      und Quittung an
                         und Quittung          Kunden aus




                 • Dieser fügt seine Identifizierungsnummer und nochmals den Rech-
                   nungsbetrag hinzu, unterschreibt ebenso, verschlüsselt die Nachricht
                   und sendet sie zum CyberCash-Gateway.
                 • Dieses authentisiert beide Teilnehmer, entschlüsselt die Rechnungsbe-
                   träge, vergleicht sie und sendet die Informationen bei Übereinstimmung
                   und nach Umformatierung zum Kreditkarten-Unternehmen, das die
                   Kreditkarten-Autorisierung vornimmt. Das Resultat wird an das Gate-
                   way rückübermittelt und wieder umformatiert.
                 • Nachdem der Anbieter die Nachricht vom Gateway erhalten hat, wird er
                   das Produkt und eine Bestätigung dem Kunden ausliefern.
                 In Abbildung 5.9 Ablauf der kreditkartenbasierten Zahlungstransaktion bei
                 CyberCash wird nochmals der Ablauf einer Zahlungstransaktion bei Cy-
                 berCash skizziert.
Der Vermittler   Ein CyberCash Gateway-Server verbindet das bestehende Clearing-
sorgt für        Netzwerk der Banken und der Kreditkartengesellschaften mit dem Internet.
Sicherheit       CyberCash ist weder Betreiber (Acquirer), Herausgeber (Issuer) noch
                 Bank, sondern nur Lizenzgeber. Mit dem Cybercash-Gateway ermöglicht
                 CyberCash nur den sicheren Transport von Nachrichten zwischen dem
                 Internet und dem Banken-Netzwerk.




                 Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                 chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               49

Bewertung
Laut CyberCash sind die Kreditkartennummern ausschließlich beim Kun-                   Die
den gespeichert. Der Anbieter hat keine Möglichkeit, die Nummer zu ent-                Kreditkarten-
schlüsseln und kann sie somit nicht für seine eigenen Zwecke nutzen.                   nummer liegt nur
[Wayner, 133] ist allerdings der Ansicht, dass das CyberCash-Gateway                   beim Kunden
durchaus in der Lage ist, die Kreditkartennummern der Kunden als Vorteil
an die Anbieter weiterzuleiten.


5.6 Weitere Zahlungssysteme auf Kreditkarten-
    Basis
Tabelle 5.6 gibt einen Überblick über weitere elektronische Zahlungssys-
teme auf Kreditkarten-Basis und deren Fundstelle im Internet.

Tabelle 5.6 Weitere elektronische Kreditkarten-Systeme



TeleCash Click&Paycredit       http://www.telecash.de
                               Kreditkartenzahlung ohne Käuferzertifikat.
                               Der Kunde benötigt keine zusätzliche Software. Er
                               trägt seine Kreditkartendaten in das Wallet oder ein
                               HTML-Formular ein, welches diese verschlüsselt
                               an TeleCash bzw. den Händler überträgt.

TeleCash Click&PaySET          http://www.telecash.de
                               Kreditkartenzahlung SET.
                               SET ist als ein Standard von VISA und Mastercard
                               sowie führenden IT-Dienstleistern entwickelt wor-
                               den. Kunde, Händler und TeleCash identifizieren
                               sich mit einem Zertifikat, das sie vorher bei Ihrem
                               Kreditinstitut beantragen. Dieses System des "e-
                               lektronischen Ausweisens" gibt allen Parteien Auf-
                               schluss über die Existenz des Gegenübers. Der
                               Kunde benutzt die Wallet-Software zur verschlüs-
                               selten Übertragung seiner Bestelldaten.
                               Für die mit SET abgewickelten Zahlungen erhält
                               der Händler von seinem Kreditkarteninstitut Zah-
                               lungsgarantie.

ECRC E-Payment Service         http://www.ecrc.de
                               Der E-Payment Service via Kreditkarte kann für alle
                               Produkte eingesetzt werden, die über das Internet


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                 50                                                                   J. Anton Illik

                                                vertrieben werden sollen. Dabei wählt der Online-
                                                Kunde aus dem Shop-Angebot die Ware, die er mit
                                                Kreditkarte bezahlen möchte. Über sichere Online-
                                                Formulare autorisiert der Kunde die Bezahlung der
                                                Online-Bestellung an den Cable & Wireless ECRC
                                                Payment-Server. Dieser verfügt über Gateways zu
                                                den wichtigsten Kreditkartenunternehmen. Dazu
                                                zählen     VISA,    American     Express,   Euro-
                                                card/Mastercard, JCB und Diners Club. Nach we-
                                                nigen Sekunden erhalten Händler und Kunde eine
                                                Rückmeldung über die erfolgreiche Kreditkarten-
                                                Transaktion. Danach kann der Shop ein Online-
                                                Fulfilment ausführen oder die Bestellung automa-
                                                tisch an das Warenwirtschaftssystem weiterleiten.
                                                Die Kreditkartengesellschaft schreibt dem Händler-
                                                konto den vom Kunden autorisierten Betrag gut.




                 5.7 Zahlungssysteme auf Scheck-Basis
Keine            Bei einem elektronischen Scheck muss laut [Beutelspacher/Hueske/Pfau,
Anonymität       100] der Scheckaussteller ersichtlich sein. Die digitale Signatur muss
                 zweifelsfrei verifiziert werden können. Zahlungsbetrag und Signatur müs-
                 sen in eindeutiger Beziehung zueinander stehen. Mit Kreditkarten-
                 Zahlungssystemen haben sie die fehlende Anonymität gemeinsam, da die
                 Zahlungen rückverfolgbar sind [Tanaka].
Kunde-zu-Kunde   Zahlungssysteme auf Scheck-Basis liegen aus Transaktionssicht näher bei
                 bargeld-ähnlichen Zahlungsmitteln als Kreditkarten, da ein Kunde-zu-
                 Kunde-Geldtransfer generell möglich ist. Ein möglicher Auslöser für die
                 Durchsetzung von elektronischen Schecks sind die Zahlungsgewohnheiten
                 in den Vereinigten Staaten, wo bereits im Jahre 1988 ca. 50 Milliarden
                 Schecks ausgestellt wurden [Steiner/Teixeira].

                 5.7.1        NetCheque
Tickets to pay   NetCheque stammt wie NetCash aus dem Information Science Institute der
                 University of Southern California. Geleitet wurde das NetCheque-
                 Entwicklungsteam von Clifford Neuman, der auch an der Entwicklung von
                 NetCash (siehe Kapitel5.4.2 NetCash) beteiligt war. NetCheque ist das
                 erste der beiden vom Information Science Institute (kurz: ISI) der Univer-
                 sity of Southern California stammenden digitalen Zahlungssysteme. Die
                 Idee dabei war, ein scheckorientiertes Zahlungsmittel auf der Basis eines
                 bereits vorhandenen, zu diesem Zweck gut geeigneten und sicheren Ba-

                 Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                 chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               51

sismechanismus zu implementieren. Für Clifford Neuman war es nahelie-
gend, als Basissystem die von ihm am Massachusetts Institute of Techno-
logy mitentwickelte Kerberos-Sicherheitstechnologie zu verwenden. Tech-
nisch gesehen ist ein „NetCheque“ ein von einem Kerberos-System er-
zeugtes spezielles „Ticket“.
Kerberos ist ein Authentifizierungs-Service, der mittlerweile für zahlreiche Kerberos
Betriebssysteme implementiert wurde und auch von einigen Anwendungs-
programmen genutzt wird, so zum Beispiel von SAP (ab Version 3.0). Es
handelt sich dabei um ein System, das im Wesentlichen die Identität eines
Benutzers oder eines Prozesses prüft. Kerberos besteht aus drei grundle-
genden Komponenten:
• Die Kerberos Datenbasis enthält die Benutzerdaten, die Passwörter und
  alle für die Anwender verfügbaren Services sowie je einen Schlüssel für
  jeden dieser Services.
• Der Authentifikations-Server stellt sicher, dass ein Anwender, der sich
  für den Zugriff auf einen bestimmten Service als Nutzungsberechtigter
  ausgibt, auch tatsächlich der ist, der er vorgibt zu sein.
• Der Ticket Granting Server fungiert praktisch als „Fahrscheinautomat“
  und stellt die sogenannten Tickets aus. Diese Tickets dienen letztlich
  dazu, dass sich der autorisierte Benutzer oder Prozess einem bean-
  spruchten Dienst gegenüber zweifelsfrei identifizieren kann.
Ein „NetCheque“ ist also ein vom Ticket Granting Server erzeugtes spe- Ticket Granting
zielles Ticket. Das Scheck-Ticket enthält Daten über den               Server
    •    Namen des Ausstellers,
    •    Namen der bezogenen Bank,
    •    Namen des Empfängers,
    •    den Zahlungsbetrag und
    •    die Kontonummer des Ausstellers.
Durch die Unterschrift in Form einer digitalen Signatur des Ausstellers
wird das Ticket zum Namensscheck. Der Namensscheck (Orderscheck)
enthält, wie oben erwähnt, auch den Namen des Scheckempfängers. An
einen Dritten kann der Namensscheck nur durch ein Indossament (Über-
tragungsvermerk) übertragen werden. Auch das wird von NetCheque un-
terstützt. Ein Scheck-Ticket kann durch digitale Indossamente ergänzt und
damit als Zahlungsmittel weitergereicht werden, bis es schließlich der be-
zogenen Bank zur Einlösung vorgelegt wird.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                52                                                                   J. Anton Illik

Kunden-         Die Kundenregistrierung beim NetCheque-System ist einfach und wird per
Registrierung   E-Mail dokumentiert. Die Registrierung beginnt auf der Seite10
online          http://nii.isi.edu/gost/info/netcheque/application.html wo nach den Konto-
                namen, der E-Mail-Adresse, einem Sicherheitsnamen, Sicherheitspasswort
                und verschiedenen Optionen gefragt wird. Abbildung 5.10 Ablauf des
                Kunden-Registrierungsprozesses bei NetCheque erläutert den einfachen
                Registrierungsprozess von Kunden bei NetCheque.


                Tabelle 5.7 NetCheque Kurzcharakteristik



                Name         NetCheque
                Entwickler,  Clifford Neuman, Information Sciences Institute der University of
                Hersteller   Southern California (ISI/USC) in Los Angeles
                Start        Januar 1995
                Einführung   Ausschließlich als Forschungsprototyp im Einsatz (laut E-Mail von
                             Neuman am 17. Juni 1997)
                Charakteris- Mit dem NetCheque Zahlungssystem kann der Benutzer Schecks
                tik          ausstellen, Geld auf bestimmten Konten deponieren und überwei-
                             sen. Der elektronische Scheck muss folgende Daten enthalten
                             [Jansen, 43–44]:
                             • Name des Verkäufers,
                             • Kontonummer des Käufers,
                             • Name des Accounting-Servers (AS),
                             • Rechnungsbetrag,
                             • Währung,
                             • elektronische Signatur des Käufers und
                             • das Verfalldatum.
                             Der Benutzer kann mit den o.a. Daten und der write_cheque-
                             Funktion von NetCheque einen Scheck generieren (http://nii-
                             server.isi.edu/gost-group/products/netcheque/ncgui/wcheque.html )
                             und löst ihn anschließend ein. Das Clearing-System funktioniert
                             wie bei herkömmlichen Schecks über eventuell mehrere Accoun-
                             ting Server (AS-Hierarchie) [Stumpf 96, 38].
                             Wird die Scheckeinreichung per Batch-Verarbeitung erledigt, so ist
                             die Transaktion gebührenfrei, für die Online-Abwicklung besteht
                             Gebührenpflicht. Der Kunden-AS meldet dem Anbieter, sobald die


                10




                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               53

               Zahlung ausgeführt ist, so dass dieser die Lieferung vollziehen
               kann [Jansen]. Die digitale Signatur wird mit Kerberos, das vom
               MIT entwickelt wurde, authentifiziert. Es handelt sich um ein ver-
               teiltes System, da mehrere AS enthalten sind. Eine Kombination
               mit NetCash ist möglich.
Anmerkung      • keine Anonymität
               • Basis für das NetCash-System aus gleichem Hause
URL            http://nii-server.isi.edu/info/NetCheque




Abbildung 5.10 Ablauf des Kunden-Registrierungsprozesses bei NetCheque




Nach dem Versenden dieser Daten über das Internet erhält man postwen-
dend die Kontenbestätigung mit folgenden Anweisungen und Informatio-
nen:
• Der Kunde muss die Datei „.checkbook“ im Hauptverzeichnis mit ei-
   nem bestimmten Inhalt erstellen,
• Installationsanweisung des NetCheque Client-Programms auf dem
  Rechner,
• Informationen über die individuelle Kerberos-Identifikation mit Pass-
  wort,
• im Anhang befindet sich ein elektronischer Scheck im Wert von 10.000
  NCU (Pseudo-Währung), der per „deposit_cheque <Datei>“ bei Net-
  Cheque deponiert werden kann.



Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
54                                                                   J. Anton Illik

Die Registrierung für Anbieter ist auf folgender WWW-Seite erläutert:
http://nii.isi.edu/info/netcheque/license.html
Der Transaktionsablauf
Der Zahlungsprozess von NetCheque läuft folgendermaßen ab:
• Im ersten Schritt erstellt der Kunde mit der write-cheque-Funktion sei-
  ner Client-Software einen elektronischen Scheck, der mit Krypto-
  mechanismen gesichert und zum Anbieter weitergeleitet wird.
• Der Anbieter leitet den Scheck mit der deposit-cheque-Funktion in das
  AS-Netzwerk weiter, in welchem die Überprüfung und Scheck-
  einlösung stattfindet.
• Sowohl Kunde als auch Anbieter erhalten vom AS eine Benachrichti-
  gung, wenn der Scheck weitergeleitet oder eingelöst wird.
• Nach der Scheckeinlösung erfüllt der Anbieter seine Lieferungspflicht.

Abbildung 5.11 Ablauf der Zahlungstransaktion bei NetCheque.




Eine Zusammenfassung über den Zahlungsprozess bei NetCheque gibt
nochmals Abbildung 5.11 Ablauf der Zahlungstransaktion bei NetCheque.

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               55

Bewertung
Die von NetCheque genutzte Basistechnologie Kerberos 5 gilt derzeit als Kerberos als
ausgereift und sicher. Einer der wesentlichen Vorteile von Kerberos ist die Basis
Eigenschaft, dass jedes Ticket nur über eine begrenzte Lebensdauer ver-
fügt. Diese Eigenschaft passt hervorragend zum Scheckparadigma! Ein
Scheck muss bei Sicht von der bezogenen Bank oder Sparkasse eingelöst
werden. Da der Scheck aber nicht als Kreditmittel, sondern als Zahlungs-
mittel verwendet werden soll, bestehen bestimmte Vorlegungs-, bzw. Ein-
lösungsfristen. Damit ist eine wesentliche Eigenschaft der Applikation
bereits auf der darunterliegenden Software-Schicht vorhanden.
In der Datenstruktur des Schecks sind, bis auf den Inhalt einer Transaktion, Scheck enthält
alle Transaktionsdaten gespeichert, so dass Bank, Käufer und Verkäufer Transaktions-
wechselseitig über alle Daten verfügen. Im Streitfall reichen also für eine daten
gerichtliche Beweisaufnahme die Informationen einer der beteiligten In-
stanzen.

5.7.2        NetBill
NetBill wurde in erster Linie für die Zahlungsabwicklung beim Kauf digi-               Transaktions-
taler Güter entwickelt. Ob es sich dabei um komplette elektronische Bü-                orientierter
cher oder auch nur um eine einzelne Web-Seite mit ganz speziellen Infor-               Auslieferungs-
mationen eines Content-Anbieters, einer Beratungsfirma oder eines Ver-                 und Inkasso-
lags handelt, ist belanglos. NetBill sorgt durch seinen transaktionsorientier-         Service
ten Ansatz dafür, dass der Verkäufer für seine zur Verfügung gestellte In-
formation den monetären Gegenwert erhält und dass der Einkäufer mit
Sicherheit das von ihm bezahlte digitale Produkt unversehrt erhält. So
gesehen ist NetBill nicht nur ein Zahlungsabwicklungssystem, sondern es
kann auch als transaktionsorientierter Auslieferungs- und Inkasso-Service
gesehen werden.
Der Transaktionsablauf
Der Einkauf, die Zustellung und die Bezahlung laufen folgendermaßen ab:
• Der Käufer wählt aus einem Angebot das digitale Produkt seiner Wahl.
• Daraufhin meldet sich sofort das Money Tool mit dem Bestätigungsfenster
  und nennt dem Käufer nochmals den Verkäufer, das gewünschte digitale
  Produkt und den Preis. Außerdem wird dem Käufer die Möglichkeit gebo-
  ten, für sich selbst eine private Anmerkung zur angestoßenen Transaktion
  zu notieren. Mit dem „Purchase“-Button wird die eigentliche Kauftransak-
  tion fortgesetzt, mit dem „Cancel“-Button kann abgebrochen werden.
Wenn der Einkauf fortgesetzt wird, laufen die folgenden Schritte ab:


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
56                                                                   J. Anton Illik

• Der Verkäufer sendet das bestellte digitale Produkt in verschlüsselter
  Form an den Computer der Bestellers.
• Das Money Tool auf der Bestellermaschine prüft das eingetroffene digi-
  tale Gut auf Vollständigkeit und Unversehrtheit. Das Ergebnis der Ü-
  berprüfung, die Käufer-Account-Information und der Decryption Key
  werden an den NetBill-Server übertragen.
• Der NetBill-Server überprüft den Kontostand auf das notwendige Gut-
  haben. Ist die Prüfung positiv, so wird der Kaufpreis abgebucht, der
  Decryption Key archiviert und eine Benachrichtigung an den Server des
  Verkäufers geschickt.
• Der Verkäufer sendet den Decryption Key, damit das Money Tool das
  bereits gelieferte digitale Gut entschlüsselt. Danach wird das digitale
  Gut sofort in einem eigenen Browserfenster angezeigt.
• Sollte die Schlüsselübertragung vom Verkäuferserver auf den Kunden-
  rechner aus irgendeinem Grund scheitern, so holt sich das Money Tool
  den Decryption Key direkt vom NetBill-Server.




Tabelle 5.8 NetBill-Kurzcharakteristik



Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               57



Name         NetBill
Entwickler,  Marvin Sirbu, Douglas Tygar; Information Networking Institute
Hersteller   der Carnegie Mellon University (INI/CMU); Mellon Bank und
             CyberCash.
Start        1995
Einführung September 1996
Charakteris- • Bestellte, digitale Güter werden in verschlüsselter Form an
tik               den Besteller übertragen.
             • Das Money Tool (ist die benutzerseitig installierte NetBill-
                  Client-Software) verifiziert den unversehrten Empfang des di-
                  gitalen Produkts.
             • Der Preis wird vom NetBill-Guthaben des Käufers abgebucht
                  und dem Verkäufer gutgeschrieben.
             • Das digitale Produkt wird nach der Auslieferung in einem
                  eigenen Fenster dargestellt.
             • Die Auslieferung des digitalen Produkts und die Zahlungsab-
                  wicklung sind transaktional und atomar.
             • Das NetBill-Guthaben kann durch eine Kreditkartennummer
                  abgedeckt sein oder durch ein Bankkonto.
             • Es sind für den Anbieter Preislisten und Anfragepreise reali-
                  sierbar.
             • Der Verkäufer kann einen artikelorientierten oder einen abon-
                  nement-orientierten Verkauf betreiben.
             • Der Käufer kann mit dem Money Tool die Transaktion verfol-
                  gen, einen Einkauf stornieren und seinen NetBill-Account
                  verwalten.
Anmerkung • NetBill nutzt als Sicherheitstechnologie Kerberos.
             • Es findet ein Transaktions-Logging auch client-seitig statt.
             • Geeignet für Micropayments, da auf dem NetBill-Server ein
                  Billing-System die Micropayments vor der Abrechung kumu-
                  liert.
URL          http://www.netbill.com, www.ini.cmu.edu/NETBILL




Abbildung 5.12 Ablauf der Zahlungstransaktion bei NetBill

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   58                                                                                         J. Anton Illik




                                Kunde                            Anbieter                           Netbill Server


                     wählt digitales Produkt zum Kauf
                     aus




                     Money Tool meldet sich, damit        die Übertragung des dititalen
                     Auswahl bestätigt oder storniert     Produkts an den Kunden
                     werden kann                          wird veranlaßt (verschlüsselt)




                     Money Tool prüft digitales Produkt                                     Kaufpreis abbuchen, wenn
                     auf Unversehrtheit und überträgt                                       Guthaben ausreicht.
                     Ergebnis an NetBill-Server                                             Benachrichtigung an Verkaufsserver



                                                           Falls Abbuchung ok:
                                                           sendet Description Key,
                        digitales Gut entschlüsseln und
                                                           damit Money Tool das
                        anzeigen
                                                           digitale Produkt entschlüsselt

                                                                                            Im Notfall: Description Key senden




                   Bewertung
Zielmarkt:         NetBill ist in erster Linie zweckmäßig für den Einkauf und Verkauf von
Handel mit         Informationen, da das NetBill-Transaktionsmodell für materielle Güter
digitalen Gütern   nicht funktionieren kann. Der Umfang der verkauften Information spielt
                   dabei keine Rolle. Vor diesem Hintergrund mag es vertretbar erscheinen,
                   dass kein Einkaufskorb zur Verfügung steht; Informationen werden in dem
                   Moment über das Netz gekauft, wenn sie benötigt werden. Dann ist es
                   auch zweckmäßig, wenn die gekaufte Info sofort in einem eigenen Brow-
                   ser-Fenster angezeigt wird, bevor sie dann vom Benutzer archiviert wird.


                   5.8 Weitere Zahlungssysteme auf Scheck-Basis
                   Tabelle 5.9 gibt einen Überblick über weitere elektronische Zahlungssys-
                   teme auf Scheck-Basis und deren Fundstelle im Internet.




                   Tabelle 5.9            Weitere elektronische Scheck-Systeme


                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               59



Redi-Check          http://www.redi-check.com
NetChex             http://www.netchex.com
Checkfree           http://www.checkfree.com
FSTC Electronic     http://www.fstc.org
Check Project




5.9 Zahlungssysteme auf SmartCard-Basis
Im Gegensatz zu den anderen bereits erwähnten Zahlungssystemen, die Europas Liebling
überwiegend in den USA entwickelt und genutzt werden, stellt sich die
Entwicklung von Chipkarten bzw. SmartCards (auch als stored value card
oder Elektronische Geldbörse bezeichnet) besonders in Europa in den Vor-
dergrund [Foremski] [Anderer].
SmartCards besitzen einen Chip bzw. bestehen als Übergangslösung aus Krypto-
einem Magnetstreifen zuzüglich Chip. Sie bieten beim Zahlungsverkehr Hardware
durch ihre integrierten Verschlüsselungsmechanismen hohe Sicherheit. integriert
Ebenso zeichnet sich die multifunktionale SmartCard, die beispielsweise
auch als Kreditkarte und Sozialversicherungsausweis dienen kann, durch
Komfort und Anwenderfreundlichkeit aus.
Ein Nachteil der SmartCard-Lösung ist der verhältnismäßig teure Karten- Kartenleser
leser, der am Client-Rechner zu installieren ist [Anderer]. Jedoch kann notwendig
aufgrund des Chips, der die Kryptografieschlüssel gespeichert hat, eine
Transaktion auf hohem Sicherheitsniveau stattfinden [Martin].
Die enorme Entwicklung und Verbreitung der SmartCards spiegelt sich SmartCard im
auch in den seit Mitte der 90er Jahre immer wieder stattfindenden Pilotpro- Internet
jekten wider, welche die Internet-Zukunftsaussichten für dieses Zahlungs-
mittel erhöhen. Hier einige Beispiele für SmartCard-Projekte im Inter-
net/Netzwerken nach [Block / Kingson Bloom / Kutler]:
• VISA International startete im Juli 1996 das Pilot-Projekt VISA Cash
  mit zwei großen Pariser Banken, das den E-Commerce am Heimcom-
  puter mit integrierten Chipkartenlesern demonstrieren soll.
• WebTV Networks Inc. in New York entwarf im Juli 1996 eine „Televisi-
  on Set-Top-Box“ mit SmartCard-Leser, der u. a. für das Internet und
  Online-Banking verwendet werden kann.
• Im Juni 1996 bei der Europay International-Tagung in Spanien initiierte
  die International Business Machines Corp. Cash-Transfers mit Smart-
  Cards (PC und Kartenleser).

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                60                                                                     J. Anton Illik

                • Die ZKA Geldkarte (vgl. www.zka.de) wurde vom Zentralen Kreditaus-
                  schuss des deutschen Bankgewerbes für die Bezahlung im stationären
                  Handel entwickelt. Die Besonderheit des deutschen ZKA Geldkarten-
                  systems ist die Führung von Schattenkonten in der sogenannten Karten-
                  evidenzzentrale. Beim Laden einer Geldkarte wird bei dieser Evidenz-
                  zentrale ein entsprechendes Schattenkonto angelegt und der Ladebetrag
                  auf diesem Schattenkonto verbucht (Ladeavis). Zahlungen mit der
                  Geldkarte werden im entsprechenden Gegenstück zur Kundenkarte, der
                  Händlerkarte, gespeichert. Beim Entladen der Händlerkarte, dem Kas-
                  senschnitt, werden die gegengespeicherten Zahlungen mit den Schat-
                  tenkonten der Geldkarten abgeglichen. Die Evidenzzentrale hat also je-
                  derzeit die Möglichkeit, die Geldmenge festzustellen, die auf einer
                  Geldkarte oder auch auf allen Geldkarten im Umlauf ist [Hammel]. Da
                  der Evidenzzentrale alle Transaktionsdaten und -partner bekannt sind,
                  schaut diese Zentrale den Kunden förmlich in die elektronische Geld-
                  börse.
Für             In jüngerer Zeit werden SmartCards zunehmend über das Internet genutzt.
Micropayments   Wegen ihrer kommerziellen Verbreitung, der hohen Sicherheitsaspekte und
geeignet        der günstigen Abwicklungsmöglichkeiten aufgrund ihrer Offline-Fähigkeit
                bieten SmartCards eine hervorragende Zahlungsmöglichkeit im Internet,
                besonders in Bezug auf Micropayments.
Standard kaum   Andererseits ist nicht zu erwarten, dass sich ein einheitliches System her-
in Sicht        ausbilden wird: Derzeit gibt es weltweit schätzungsweise über 40 Geldkar-
                tensysteme [Hoffmann].

                Tabelle 5.10 Karten-Systeme



                TeleCash                http://www.telecash.de
                Click&Paypurse          Geldkarte
                                        Bei der Geldkarte wird mit Hilfe eines Chipkartenlesers
                                        der Zahlbetrag von der Geldkarte des Käufers abgebucht
                                        und auf das Händlerkonto übertragen. Die Geldkarte eig-
                                        net sich auch für Kleinbeträge und bietet dem Händler
                                        hohe Sicherheit, denn sie ist eine finale Zahlung, d. h. sie
                                        entspricht einer Bargeldzahlung an der Kasse.

                TeleCash                http://www.telecash.de
                Click&Payloyality       Kundenkarte
                                        Die Kundenkarte findet als alternatives Zahlungsmittel zu
                                        herkömmlichen Kartensystemen immer größere Verbrei-
                                        tung. Die Vorteile liegen in der Kundenbindung als auch in
                                        der erleichterten Gewährung von Rabatten.


                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               61




5.10 Zahlungssysteme auf EDI-Basis
Unter Electronic Data Interchange (EDI) versteht man den elektronischen Medienbrüche
Austausch von Daten, Texten oder Multimedia-Komponenten zwischen vermeiden
Rechnern unterschiedlicher Unternehmungen in einem standardisierten
Format. Dabei muss die Syntax und die Semantik der auszutauschenden
Information festgelegt sein. Ziel von EDI ist die Ablösung der papierge-
bundenen Geschäftsabläufe und die Verhinderung von Medienbrüchen.
Der Informationsfluss und die Informationsverwaltung werden verbessert,
denn durch die elektonische Übermittlung wird die Datenerfassung mini-
miert bzw. entfällt und Erfassungsfehler reduzieren sich. Standards für
EDI-Nachrichten sind Edifact und UN/Edifact. Detaillierte Beschreibun-
gen von EDI und Edifact sind in [Krähn, 30ff] und [Hitachi, 93ff.] zu fin-
den. [Lindemann] erläutert detailliert die e-Mail-basierte Nachrichten-
übermittlung im Internet.
Nachdem EDI früher nur in WANs benutzt wurde, wird heute das Internet EDI geht in‘s
als weitere Kommunikations-Infrastruktur untersucht und Pilotversuche Internet
unternommen, z. B. bei Wells Fargo [http://www.wellsfargo.com, Came-
ron, 232] und der NACHA11 (http://www.nacha.org). Dass die Ausrichtung
von EDI und dessen Standards auf den kommerziellen Bereich die Integra-
tion des Privatkunden nicht behindert, zeigt sich am Beispiel des Tele-
Counters.

5.10.1         TeleCounter
TeleCounter ist ein schweizerisches Zahlungssystem, das als zentraler Be-              Private
standteil eines interaktiven Telematiksystems für den Heimbereich (Home                Haushalte als
Oriented Interactive Telematic System ( kurz HIT-System) gedacht ist. Ein              gleichberechtigte
HIT-System ist ein Interorganisationssystem (IOS), das sich durch be-                  Marktteilnehmer
stimmte Eigenschaften von bisher im kommerziellen Bereich vorzufinden-
den IOS unterscheidet, da es speziell für das Retail- und Consumer-
Segment konzipiert ist. Hier wird also bewusst „der private Haushalt als
gleichberechtigter Partner in einem elektronischen Markt behandelt“
[Zimmermann].


11
     Die Nation Automated Clearing House Association (kurz: NACHA) ist der US-
     amerikanische Dachverband für das Automated Clearing House Network (kurz ACH-
     Netwerk), einem amerikanischen Bankennetz.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                62                                                                   J. Anton Illik

Infrastruktur   Aus dem TeleCounter-Pilot ergaben sich folgende Vorteile für den Finanz-
vorhanden       dienstleister: Wie auch bei anderen elektronischen Zahlungssystemen ver-
                mindert sich der Aufwand der bankinternen Erfassung im Vergleich zum
                papiergebundenen Zahlungsverkehr. Weiterhin fallen keine Wartungen und
                Systempflege für Applikationen an, da alle Banken das Edifact-Format
                verarbeiten können und die Infrastruktur somit vorhanden ist. Durch die
                Einführung eines Edifact-Servers könnte eine Bank die Schnittstelle für
                alle Kunden (Großkunde, KMU und Retailbereich) vereinheitlichen.
Multibanken-      Durch die Multibankenfähigkeit des TeleCounters wird dem Kunden die
fähigkeit gegeben gemeinsame Verwaltung von Konten verschiedener Kreditinstitute ermög-
                licht. Von der intelligenten Client-Software wird die Kennung des betref-
                fenden Kreditinstitutes in der zu versendenden Nachricht übernommen.
                Der Kommunikationsmittler leitet den Zahlungsauftrag direkt an die von
                der Client-Software gekennzeichneten Bank; dem Kunden wird somit ein
                hohes Maß an Komfort geboten. Abbildung 5.13 Ablauf der Zahlungs-
                transaktion bei TeleCounter verdeutlicht den Ablauf einer Zahlungstrans-
                aktion mit dem TeleCounter.




                Tabelle 5.11 TeleCounter Kurzcharakteristik




                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               63

Name           TeleCounter
Entwickler,    Beat Schmid, Kompetenzzentrum TeleCounter des Instituts für
Hersteller     Wirtschaftsinformatik an der Hochschule St. Gallen, Schweiz
Start          1994
Einführung     Ausschließlich als Forschungsprototyp im Einsatz
Charakte-      Der TeleCounter ist ein Zahlungsverkehrskonzept, das mit Edifact-
ristik         Nachrichten den klassischen Überweisungsverkehr (Rechnungs-
               Überweisungen, Gutschriften und Belastungen) abbildet und das
               sich in den Gesamtkontext eines elektronischen Marktes einordnen
               lässt [Mausberg, 106]. Mit der TeleCounter Client-Software kann
               der Kunde Zahlungsaufträge ausführen, die durch eine Rechnung
               induziert worden sind. Der Client generiert die Edifact-
               Nachrichten bzw. empfängt und liest sie hinterher. Beteiligte sind
               Finanzdienstleister, welche die Edifact-Nachrichten entgegenneh-
               men. Dazu verwenden sie entweder einen „Vorrechner“, der die
               Nachrichten überprüft, oder einen Edifact-Server, der die Daten via
               EDI-Gateway an das Bankensystem weiterleitet. Kommunikations-
               mittler, die den Finanzdienstleistern vorgeschaltet sind, überneh-
               men die Konvertierung der Daten und leiten sie weiter.
               Auch andere Edifact-Finanzmeldungen, wie sie in [Mausberg, 80]
               erläutert werden, sind möglich. Alle Transaktionen des TeleCoun-
               ters bilden einen geschlossenen elektronischen Kreislauf.
               Hard- und Software-Voraussetzungen, die der Kunde erfüllen
               muss, sind in [Mausberg, 123] ebenfalls ausführlich erläutert.


Anmerkung Für Micropayments ist dieses Zahlungssystem nicht geeignet.
URL            http://www.businessmedia.org




Abbildung 5.13 Ablauf der Zahlungstransaktion bei TeleCounter




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                 64                                                                                         J. Anton Illik


                           Kunde              Anbieter            Kommunikations-       Bank (Kunde)     Bank (Anbieter)
                                                                      mittler

                      kennzeichnet die
                                           generiert und sendet
                      Produkte, die er
                                              die Rechnung
                       kaufen möchte




                       Client-Software
                                                                      konvertiert
                      generiert Payord                                                      überprüft
                                                                   Nachrichtenformat
                      (Zahlungsauftrag)



                                                                                           verarbeitet       verarbeitet




                      erhält Belastungs-                              konvertiert           sendet            sendet
                           anzeige                                 Nachrichtenformat        Debadv            Credadv


                                            erhält Gutschrift-         konvertiert
                                                anzeige             Nachrichtenformat



                          Produkt-              Produkt-
                           erhalt             auslieferung




EDI fürRetail-   Der TeleCounter Pilot hat bewiesen, dass mit einer geeigneten Client-
und Consumer-    Software EDI auch im Retail-Geschäft erfolgreich einsetzbar ist. Den be-
Bereich.         teiligten Banken wurde bei dem Pilotprojekt sehr stark die Offenheit be-
                 wusst, die das Internet mit sich bringt. Trotz der Tatsache, dass die Ab-
                 wicklung von Transaktionen nach dem TeleCounter-Konzept funktioniert
                 und die Banken einen großen Nutzen aus dem System ziehen können (kei-
                 ne Neuerfassung, vorhandene Infrastruktur), möchten sie die Nutzung von
                 EDI bisher auf den Geschäftsbereich beschränken.
Telebanking-     Das TeleCounter-Konzept basiert auf dem Austausch standardisierter
Lösung           Nachrichtenformate mit dem Zweck der Abwicklung von Bankgeschäften,
                 insbesondere dem Zahlungsverkehr. Somit stellt das Konzept eine typische
                 Telebanking-Lösung dar.
                 „Telebanking umfasst alle Möglichkeiten und Techniken, die dem Kunden
                 ermöglichen, von seinem Standort aus, unter Benützung telematischer
                 Systeme, direkt Bankgeschäfte zu erledigen“ [Straub, 132].
                 Diese Definition stammt aus einer Zeit, als Videotext das einzige interakti-
                 ve Telematikmedium für das Retail-Segment war und elektronische Zah-
                 lungssysteme im Internet nicht oder nur kaum diskutiert wurden.




                 Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                 chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               65


5.11 Zahlungssysteme auf Kontenbasis
Ein kontenbasierendes Zahlungssystem ist beispielsweise CyberCoin von
der Firma CyberCash (www.cybercash.com). Anders als der Produktname
dies suggeriert, ist CyberCoin kein münzbasierendes Verfahren, wie etwa
eCash.

5.11.1       CyberCoin
CyberCoin basiert auf Schattenkonten, zwischen denen Geld transferiert Das Schatten-
wird. Das CyberCoin System ist ein geschlossenes System, d. h. der Käu- konto ist die
fer und der Händler müssen bei der gleichen CyberCoin-Bank zur Nutzung Basis
des Services registriert sein. Peer-to-Peer-Zahlungen, bei denen Geld zwi-
schen einzelnen Konsumenten direkt, also ohne Vermittlung der Cyber-
Coin-Bank transferiert wird, ist wegen der Fundierung durch Schattenkon-
ten ebenfalls nicht möglich. Das Geld bleibt im geschlossenen Benutzer-
kreis und wird darin zwischen den Schattenkonten transferiert. Der Kon-
sument hat das Gefühl, das Geld sei in seinem persönlichen Wallet auf
seinem Computer gespeichert; tatsächlich aber verbleibt das Geld bei der
Bank. Das Füllen des Wallets bzw. des Schattenkontos erfolgt über die
Kreditkarte oder von einem realen Girokonto des Konsumenten [Hammel].
Ähnlich wie bei der Geldkarte sind auch hier alle Transaktionsdaten und -
partner der Bank bekannt.
Durch die lokale Ausführung von Transaktionen im geschlossenen Kon- Niedrige
tenkreis einer Bank bleiben die Transaktionskosten niedrig, da die kosten- Transaktionskos-
intensive Nutzung von Bank- und Clearing-Netzen nicht notwendig ist. ten
Kosten für die Nutzung dieser Netze entstehen nur beim Füllen der Schat-
tenkonten durch die Konsumenten und beim Abbuchen durch die Händler.
Aufgrund der niedrigen Transaktionskosten ist das CyberCoin-System für
Micropayments geeignet.

5.11.2       Digitales Lastschriftverfahren pay-on.net/ELV
Beim digitalen Lastschriftverfahren benötigt der Internet-Kunde lediglich Clientseitig ist
ein Girokonto (80% aller Bundesbürger verfügen über ein Girokonto). keine Installation
Eine Kreditkarte kommt nicht zum Einsatz. Auch die Installation client- notwendig
seitiger Software beim Kunden ist nicht notwendig. Es genügt ein Internet-
Browser, der das SSL-Protokoll unterstützt. Beispielsweise der Microsoft
Internet Explorer ab der Version 3 oder der Netscape Navigator, ebenfalls
ab der Version 3, können hier zum Einsatz kommen.



Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   66                                                                   J. Anton Illik

Payment-           Auf der Seite des Händlers wird die Payment-Software installiert. Diese
Software auf der   prüft im Rahmen einer Transaktion, ob die vom Kunden angegebenen Da-
Händlerseite       ten wie Kontonummer und Bankleitzahl den Bestimmungen der Deutschen
                   Bundesbank entsprechen. Im Vergleich zur Kreditkartenzahlung entstehen
                   beim pay-on.net/ELV (www.webtrade.net) geringere Provisionskosten. Für
                   den Kunden ist das elektronische Lastschriftverfahren kostenlos.
                   Bei einer Zahlung laufen im Einzelnen folgende Schritte ab:
                        •   Der Kunde wählt ein Produkt aus dem Sortiment des Händlers und
                            gibt als Zahlungsart das elektronische Lastschriftverfahren an.
                        •   Der Online-Shop leitet den Kunden an ein WebTRADE Payment
                            Gateway (im Folgenden kurz Payment-Server genannt) weiter.
                        •   Dieser Server sendet sein Zertifikat an den Client des Kunden.
                        •   Der Client überprüft, ob das Zertifikat von einer vertrauenswürdi-
                            gen Zertifizierungsstelle (Certificate Authority, Trusted Third Par-
                            ty) herausgegeben wurde.
                        •   Der Client überprüft, ob die Daten im Zertifikat mit den Daten der
                            Site übereinstimmen.
                        •   Der Client meldet dem Server, welche Verschlüsselungsverfahren
                            er beherrscht.
                        •   Der Server wählt daraus das sicherste Verfahren aus und informiert
                            den Client.
                        •   Server und Client tauschen jeweils ihre öffentlichen Schlüssel aus.
                        •   Daraufhin erfolgt die weitere Kommunikation zwischen dem
                            Payment-Server und dem Client verschlüsselt: Jeder verschlüsselt
                            vor dem Versand seine Botschaft mit dem öffenlichen Schlüssel
                            des anderen.
                        •   Nach der sicheren Übertragung der Bankdaten des Kunden an den
                            Payment-Server überprüft dieser, ob die Bankleitzahl und die Kon-
                            tonummer den Regularien der Deutschen Bundesbank entsprechen.
                        •   Ist dies der Fall, so werden die Daten an das Bankensystem wei-
                            tergeleitet. Wenn keine Fehler auftreten, wird die Zahlung ver-
                            bucht.
                        •   Der Shop bekommt vom WebTRADE Payment Gateway das Er-
                            gebnis der Buchung übermittelt.
                        •   Der Kunde erhält eine Bestätigung seines Auftrags oder eine Feh-
                            lermeldung.


                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               67

    •    Nach Abschluss der Transaktion wird der Kunde wieder an den
         Online-Shop zurückgegeben.


5.12 Weitere Zahlungssysteme

5.12.1       Zahlung über Handy: das Zahlungssystem Paybox
Die paybox deutschland AG (www.paybox.de, www.paybox.net) betreibt                     Zahlungsfähig
ein System, durch das bargeldlose Zahlungen mittels Mobiltelefon zwi-                  bei vorhandener
schen dem Endverbraucher und Internet-Händlern, stationären Einzelhänd-                Mobilfunknetz-
lern, mobilen Dienstleistern und zwischen zwei Endverbrauchern einfach                 abdeckung
und sicher unterstützt werden können. Die paybox.net AG benutzt existie-
rende Zahlungsverfahren wie z. B. das Lastschrifteinzugsverfahren, wel-
ches sie mit einer gleichzeitigen Bestätigungsfunktion mittels Mobiltelefon
kombiniert. Die Zahlungsabwicklung erfolgt durch Finanzdienstleister, die
zur Durchführung der entsprechenden Zahlungsverfahren zugelassen sind.
Bei diesem Zahlungssystem wird also während der Zahlungstransaktion Paybox-PIN gibt
auf das Mobilfunknetz zurückgegriffen. Über das Mobilfunknetz werden Zahlung frei
keine sicherheitsrelevanten Daten übertragen, sondern lediglich die Pay-
box-PIN, mit der der Bezahler sein Einverständnis zur Zahlungstransaktion
gibt. Diese PIN ist für potenzielle Lauscher wertlos, da sie nur im Zusam-
menhang mit der registrierten Mobiltelefonnummer verwendbar ist.
Wesentlicher Vorteil dieses Zahlungssystems ist, dass während des Be- Sicher und
stellvorgangs keine sicherheitsrelevanten Daten in das Bestellformular einfach
eingegeben und über das Internet übertragen werden (Bankverbindung,
Kreditkartennummer etc.). Für die Zahlungstransaktion ist nur die Angabe
der Mobilfunknummer notwendig. Die Zahlungstransaktion läuft dann wie
in Abbildung 5.14 Ablauf einer Internet-to-Paybox Zahlungstransaktion
dargestellt ab.
Bei der Anmeldung müssen die relevanten Personendaten (Name, An- Anmeldung
schrift, Familienstand, Berufsstatus, Jahreseinkommen etc.), und die online und mit
Bankverbindung (für das Lastschriftverfahren) angegeben werden. Das Papier
Sammeln der Daten wird abgeschlossen, indem die Geschäftsbedingungen
akzeptiert werden. Sind alle Angaben vollständig, so generiert der Re-
gistrierungs-Server ein Formular, das ausgedruckt, unterschrieben und an
den Paybox-Anfrageservice gefaxt oder geschickt werden muss. Die An-
meldebestätigung und die Paybox-PIN-Nummer kommen daraufhin per
Post.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
68                                                                   J. Anton Illik

Momentan werden drei unterschiedliche Arten von Transaktionen unter-
stützt:
     •   Internet-to-Paybox: Diese Transaktionsart wird bei Zahlungen in
         Internet-Online-Shops verwendet. Der Kunde entscheidet sich für
         Paybox als Zahlungssystem und gibt seine Mobilrufnummer an,
         nachdem er seine Waren im Online-Shop ausgewählt hat. Der An-
         bieter leitet die Transaktion verschlüsselt an das Paybox System
         weiter. Von dort aus wird der Kunde über die angegebene Handy-
         Nummer zurückgerufen und um die Transaktionsfreigabe per Ein-
         gabe seiner PIN gebeten. Nach erfolgreicher Überprüfung der PIN
         erhält der Anbieter eine Benachrichtigung über die abgeschlossene
         Zahlungstransaktion. Die gesamte Zahlungstransaktion dauert in
         der Regel nur wenige Sekunden. Nach Auslieferung der Ware und
         Ablauf einer vom Anbieter definierten Zeitspanne wird der Zah-
         lungsbetrag vom Girokonto des Kunden abgebucht und auf das
         Konto des Anbieters weitergeleitet. Paybox bzw. die Deutsche
         Bank als strategischer Partner, haftet für die Einlösung der Zah-
         lung. Für den Kunden ist die Nutzung des Paybox Systems bis auf
         die Jahresgebühr von fünf Euro kostenlos. Für die beteiligten
         Händler wird eine Transaktionsgebühr von 3% des Umsatzes fäl-
         lig, was in etwa den Kosten für eine Kreditkartenzahlung gleich-
         kommt. Im Falle von Teillieferungen kann der Händler auch Gut-
         schriften generieren.




Abbildung 5.14 Ablauf einer Internet-to-Paybox Zahlungstransaktion




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               69




    •    Paybox-to-Paybox: Bei dieser Transaktionsart ist kein Händler
         beteiligt: Hier führen Endverbraucher untereinander Zahlungs-
         transaktionen durch (peer-to-peer-Zahlung). Dies kann z. B. bei
         der Teilnahme an einer Internet-Online-Auktion sinnvoll sein. Die
         Zahlungstransaktion läuft wie beim oben beschriebenen Verfahren
         ab, nur dass hier die beiden Transaktionspartner zwei beim Paybox
         System registrierte Endverbraucher sind: Der Käufer gibt dem Ver-
         käufer seine Mobilfunknummer bekannt. Der Verkäufer leitet die
         erhaltene Mobilfunknummer an das Paybox System weiter. Dar-
         aufhin wird der Käufer über die angegebene Handy-Nummer zu-
         rückgerufen und um den Transaktionsabschluss per Eingabe seiner
         PIN gebeten. Nach erfolgreicher Prüfung wird die Zahlung per
         Bankeinzug weitergeleitet. Für diesen Service werden 25 Cent je
         angefangene 25 Euro berechnet. Die Limitierung liegt bei 200 Eu-
         ro pro Paybox-to-Paybox-Zahlung.
    •    Mobile-to-Paybox: Bei dieser Transaktionsart wird die Zahlung
         an eine autorisierte Stelle außerhalb des Internet durchgeführt,
         z. B. an Dienstleister wie Taxiunternehmen, Pizzaservices oder
         Kurierdienste. Seit Mitte Juli 2000 akzeptieren beispielsweise ca.
         300 Frankfurter Taxis Paybox als Zahlungssystem. Der Vertrags-


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                70                                                                   J. Anton Illik

                         partner ruft mit seinem Mobiltelefon beim Paybox System an und
                         nennt die Mobilfunknummer des Kunden und den zu zahlenden
                         Betrag. Das Paybox System ruft wiederum beim Kunden an und
                         fordert die PIN zur Bestätigung der Zahlung an. Nach erfolgrei-
                         cher Freigabe der Zahlung wird der entsprechende Betrag vom Gi-
                         rokonto des Kunden abgebucht und an das Dienstleistungsunter-
                         nehmen weitergeleitet. Für den Kunden fallen keine Kosten an,
                         dem Dienstleister werden 3% vom Transaktionsumsatz als Servi-
                         cegebühr berechnet.
                Akzeptanzstellen sind am Paybox-Symbol erkannbar:




                Bewertung
Hitverdächtig   Die hohe Wachstumsdynamik im Bereich der Mobiltelefone macht die M-
                Commerce-kompatible Zahlungsmethode sehr interessant: Alleine in
                Deutschland werden bis Ende 2002 ca. 40 Millionen Handys erwartet. Vor
                allem die einfache Handhabung für Kunden und die Nutzbarkeit innerhalb
                und außerhalb des Internet macht die Paybox-Methode im Bereich Busi-
                ness-to-Consumer hitverdächtig.

                5.12.2       Zahlung über das Telefonnetz: das Zahlungssystem
                             net900
                Bei net900 handelt es sich um ein Zahlungssystem, bei dem eine spezielle
                Software die Anwahl einer kostenpflichtigen 0190er-Telefonnummer aus-
                löst. Die dazu notwendige Software ist kostenlos unter der Internet-
                Addresse www.net900.de erhältlich. Bisher ist das System nur für Micro-
                soft Windows 95/98/NT verfügbar. Außerdem ist derzeit noch ein lokaler
                Zugang vom eigenen PC zum Telefonnetz erforderlich (analog oder
                ISDN), d. h. eine Nutzung des Systems über einen Router oder Proxy-
                Server ist noch nicht möglich. Damit ist das System in erster Linie für den
                Privatkunden nutzbar, da Firmen in aller Regel einen gemeinsamen Inter-
                net-Zugang mittels Router und Firewall betreiben. Diese Einschränkung
                soll für die Weiterentwicklung net900 Kontopass nicht mehr gelten.




                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               71

Für die in Anspruch genommenen Dienste zieht die Deutsche Telekom die
entsprechenden Gebühren über die Telefonrechnung ein. Momentan ist das
System nur innerhalb Deutschlands einsatzfähig.
Nach der erstmaligen Installation der net900 Software auf dem PC des
Kunden läuft eine Zahlungstransaktion wie folgt ab:
    •    Der Kunde ruft eine kostenpflichtige Web-Seite ab (z. B. eine Sei-
         te mit einer abrufbaren Studie).
    •    Nun wird die bestehende Verbindung zum Internet-Provider ge-
         trennt.
    •    Anschließend erfolgt der Anruf bei einer 0190er-Nummer über das
         Netz der Deutschen Telekom. Es folgt der Hinweis, dass Gebühren
         anfallen.
    •    Die gewünschten, kostenpflichtigen Informationen können nun
         abgrufen werden.
    •    Die Deutsche Telekom belastet das Fernmeldekonto mit dem ent-
         sprechenden Betrag.
    •    Nachdem das kostenpflichtige Angebot verlassen wurde, erfolgt
         ein automatischer Wiederaufbau der Verbindung zum Internet-
         Provider.
Die Abrechnung kann entweder pro abgerufener Seite („Pay per Click“)
oder zeitabhängig („Pay per Minute“) erfolgen. Die Minutenpreise können
von 0,30 DM pro Minute bis zu 5 DM pro Minute liegen. Alternativ kann
auch ein bestimmter DM-Betrag pro Abruf fällig werden. Die Preisspanne
reicht hier von 0,30 DM bis 25 DM pro Abruf.


5.13 Zahlungsprotokolle
Derzeit existieren noch keine einheitlich durchgesetzten Standards, um ein Nationale
hohes Sicherheitsniveau unter HTTP umfassend abzudecken. Neben natio- Restriktionen
nalen Restriktionen bezüglich kryptografischer Verfahren wie die Export-
beschränkung von Schlüssellängen, versuchen einige größere Hersteller,
ihre eigenen Lösungsansätze als de-facto-Standards durchzusetzen.
Die weiter oben beschriebenen Zahlungssysteme liegen, eingeordnet in das Protokoll statt
OSI-Referenzmodell, auf der Anwendungsebene (OSI-Schicht 7). Die fertiger
meisten sind mit einer grafischen Benutzeroberfläche versehen und sind Applikation
damit direkt nutzbar im Gegensatz zu den Zahlungsprotokollen, die eine
technische Spezifikation darstellen und die Basis von Zahlungs-
systemapplikationen sind. Zahlungsprotokolle können in Transportproto-

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                72                                                                   J. Anton Illik

                kolle (z. B. SET) und Anwendungsprotokolle (z. B. S-HTTP) aufgeteilt
                werden [Anderer]. Die im Folgenden beschriebenen Protokolle können
                direkt für den Zahlungsverkehr im Internet verwendet werden oder gehen
                als Basisprotokolle in andere Zahlungssysteme ein.

                5.13.1       S-HTTP: Secure Hypertext Transfer Protocol
WWW-            S-HTTP wurde im Herbst 1994 von EIT (Enterprise Integration Technolo-
Sicherheits-    gies), vom National Center for Supercomputing Applications (NCSA) und
verfahren       RSA als sicherheitssteigernde Version von HTTP entwickelt, indem es
                HTTP-Nachrichten kapselt. Es befindet sich ebenso wie HTTP auf der
                Anwendungsebene, gilt als allgemeines WWW-Sicherheitsverfahren und
                wird auch für die sichere Übertragung von Zahlungsinformationen ver-
                wendet [Janson/Waidner, 1996b]. Es unterstützt Authentifikation von In-
                terprozess-Kommunikationen, Nachrichtenintegrität und Non-Repudiation
                (Nicht-Abstreitbarkeit) des Ursprungs (siehe Kapitel 5.1.2.1 Sicherheit
                geht über alles).
Kompatibel zu   Das Protokoll beinhaltet die RSA-Kryptografie und Kerberos-basierende
HTTP            Sicherheitsmechanismen. Im Rahmen der Anwendung werden auch andere
                Kryptografie-Mechanismen zur Auswahl gestellt (z. B. PGP, PEM). Zu
                HTTP besteht Kompatibilität. Wenn nur der Client bzw. Server S-HTTP
                unterstützt, kann dennoch in Form von ungeschützten Verbindungen kom-
                muniziert werden.

                5.13.2       iKP: Internet Keyed Payment Protocols
Kredit und      Bei iKP handelt es sich um eine Zahlungsprotokollfamilie, die auf der
Scheck, aber    RSA-Kryptografie basiert (Schlüssellänge 1.024 Bit bzw. 768 Bit) und von
keine Münze     der Forschungsabteilung der IBM Zürich und Yorktown anfang des Jahres
                1995 entwickelt wurde [Janson/Waidner, 1996a]. Die Architektur ermög-
                licht, dass drei oder mehr Teilnehmer an einer Sitzung (Session) teilneh-
                men und der Zahlungstransfer direkt über Konten bei Banken oder anderen
                Finanzorganisationen abgewickelt wird. Die vorhandene Finanz-
                Infrastruktur soll dabei für die Zahlungsautorisierung und das Clearing
                verwendet      werden.    iKP    unterstützt   Kreditkarten-/Debitkarten-
                Transaktionen und elektronisches Scheck-Clearing, jedoch kein Electronic
                Cash [Linehan/Tsudik].
Verschiedene    Das Protokoll wurde in verschiedenen Varianten (1KP, 2KP und 3KP) ent-
Sicherheits-    wickelt, die sich durch verschiedene Sicherheits-Levels unterscheiden. Die
Levels          Variante 3KP ist die umfangreichste, in welcher ein Zahlungsprozess-



                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               73

Beteiligter einen elektronisch signierten Beweis für seinen relevanten An-
teil am Zahlungsvorgang erhält [Janson/Waidner, 1996b].
iKP ist plattformneutral. Um Sicherheitsrisiken zu minimieren, wurden Kein Umweg
mehrere, paarweise benutzbare Kanäle entwickelt, so dass die sensitiven über Dritte
Informationen direkt zum Zuständigen gesendet werden können und nicht
den Umweg über Dritte machen müssen. Alle Parteien haben eine PIN zur
Bestätigung der Zahlungsautorisation. Abhängig vom Bedarf bezieht das
Protokoll ein, zwei oder drei öffentliche Schlüssel mit ein. Die akqui-
rierende Bank hat in jedem Fall ein öffentlich-privates Schlüsselpaar, um
die vertraulichen Informationen wie z. B. Kreditkartennummern und un-
terzeichnete Autorisierungsnachrichten zu erhalten und entschlüsseln.
Die Zielsetzungen von iKP sind, ein Höchstmaß an Sicherheit für die Be- Sackgasse
teiligten, die Standardisierung des Mechanismus und der Semantik bei
Mehrparteien-Zahlungssitzungen zu erlangen sowie die bestehende Fi-
nanzinfrastruktur einzubeziehen [Janson/Waidner, 1996b]. Im ersten Halb-
jahr 1996 wurde der iKP-Prototyp als Basis für limitierte Versuche fertig-
gestellt und soll sowohl in Europa als auch in Japan getestet werden. Eine
Weiterentwicklung von iKP ist nicht geplant, da zur gleichen Zeit das Pro-
tokoll SET entwickelt wurde, welches iKP12 abgelöst hat.



5.13.3          STT: Secure Transaction Technology
Das STT-Protokoll wurde von Microsoft und VISA zur Unterstützung von Sackgasse von
Zahlungen und Kreditkarten-Transaktionen über elektronische Netzwerke Anfang an
entwickelt, wobei fast komplett auf Standards (z. B. bei den Zertifizie-
rungsformaten) verzichtet wurde. Die Entwicklung „hinter verschlossenen
Türen“ erklärt, dass es bis heute keine bedeutende Diskussion über dieses
Produkt gegeben hat [Janson/Waidner, 1996a].
Ebenso wie iKP ist STT in die SET-Spezifikation mit eingeflossen. Daher
erübrigt sich eine Weiterentwicklung dieses Protokolls.

5.13.4          SEPP: Secure Electronic Payment Protocol
Dieses Protokoll wurde von MasterCard, IBM, Netscape, CyberCash und Die Reaktion auf
GTE entwickelt. Bestandteile des Protokolls sind die Erfahrungen mit Cy- STT

12
     Informationen zum Protokoll sind noch unter folgender Adresse zu finden:
http://www.zurich.ibm.com/csc/infosec



Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                74                                                                                   J. Anton Illik

                berCash, das Protokoll iKP und dem „Secure Courier“ von Netscape
                [Reif].
SEPP lebt in    Durch die Entwicklung des SET-Protokolls, in welches auch die SEPP-
JEPI            Spezifikation eingeflossen ist (siehe Abbildung 5.15 Historie von Zah-
                lungsprotokollen [vgl. Waidner96b]) wird das Protokoll nicht weiterentwi-
                ckelt werden.

                Abbildung 5.15 Historie von Zahlungsprotokollen [vgl. Waidner96b]




                                            1995/2H                       1996/1H               1996/2H

                                                                             iKP-
                     IBM
                                     Mastercard, IBM, Netscape,            Prototyp
                                     CyberCash, GTE

                     iKP                       SEPP


                                                                           SET V0                         SET V1
                 VISA, Microsoft
                                                                  VISA, Mastercard, IBM, GTE,
                     STT                          STT             Microsoft, Netscape, SAIC,
                                                                  Terisa, Verisign




                5.13.5             SET: Secure Electronic Transactions
Dauerhafte      VISA und MasterCard haben dieses Protokoll mit der Zielsetzung ent-
Grundlage?      wickelt, sichere Kreditkarten-Transaktionen über offene Netzwerke zu
                ermöglichen. Insbesondere geht es um die Sicherung und Authentifizie-
                rung von Kreditkartentransaktionen zwischen Web-Browser, Web-Server
                und einem entsprechenden Gateway bei der Händler-Bank. Die Spezifika-
                tion kann für Bankkarten-Zahlungen verwendet werden oder sie kann von
                Software-Herstellern als Grundlage zur Erstellung von Zahlungssystem-
                Software dienen. Im Februar 1996 wurde SET zum offiziellen Standard
                erklärt. GTE, IBM, Microsoft, Netscape Communications Corp., RSA,
                SAIC, Terisa Systems und VeriSign unterstützen VISA und MasterCard bei
                der Entwicklung von SET.
Offener Standard Die Spezifikationen sind unter der URL http://www.visa.com zu finden
                und bestehen aus drei Büchern: einer Business Description, einem Pro-
                grammers Guide und einer Formal Protocol Description. Die Spezifikati-


                Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               75

on ist öffentlich und kann von jedem genutzt werden, der SET-konforme
Software herstellen möchte.
SET wird durch folgende Features gekennzeichnet:
• verschlüsselte Informationsversendung
• Datenintegrität durch digitale Signaturen
• Kartenhalter-, Verkäufer- und Kontenauthentifikation durch digitale
  Signaturen und Zertifikate
• Interoperabilität durch spezielle Protokolle und Nachrichtenformate.
Das konkrete Payment Processing stützt sich im Wesentlichen auf fünf
Protokollfamilien:
• Cardholder registration: Registrierung eines Karteninhabers für die
  Abwicklung von Online-Zahlungstransaktionen.
• Merchant registration: Registrierung eines Händlers für die Abwick-
  lung von Online-Zahlungstransaktionen.
• Purchase request: Kaufanfrage.
• Payment authorization: Zahlungsautorisierung.
• Payment capture: Zahlungseingang.
Bevor ein erster Einkauf getätigt werden kann, muss sich der Kartenbesit- Cardholder
zer mit der für die Kartenemission zuständigen Bank online in Verbindung registration
setzen und ein Online-Formular für die Registrierung ausfüllen. Erfasst
werden Name, Kartennummer, Ablaufdatum der Karte, Rechnungsadresse
und sonstige für die Identifikation notwendige Daten. Die erfassten Infor-
mationen werden verschlüsselt auf einem sicheren Übertragungsweg zum
Computer der Herausgeber-Bank der Kreditkarte übertragen. Die Heraus-
geber-Institution überprüft die Authentizität der Kartennummer. Danach
fügt der Herausgeber seine digitale Signatur in das digitale Zertifikat für
den Kartenbesitzer. Dieses digitale Zertifikat weist ab jetzt die Karte im
Netz als gültig aus. Gespeichert wird das digitale Zertifikat auf dem Com-
puter des Kartenbesitzers.
Um einen sicheren Einkauf im Sinne eines Kundenschutzes zu gewährleis- Merchant
ten, muss auch der Verkäufer registriert werden. Der Verkäufer muss seine registration
Daten online in ein Erfassungsformular eingeben. Von der Bank des Ver-
käufers kommt dann das digitale Zertifikat, das den Verkäufer für die Ab-
wicklung elektronischer SET-Transaktionen autorisiert.
Nach der Registrierung kann der elektronische Einkauf bzw. Verkauf be- Purchase request
ginnen. Um sicher zu sein, von einem registrierten, autorisierten Händler
zu kaufen, wird dessen digitales Zertifikat überprüft, wie wir unten sehen

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   76                                                                   J. Anton Illik

                   werden. Ein autorisierter Händler kann sein digitales Zeritifikat auf Anfor-
                   derung via E-Mail versenden oder so hinterlegen, dass die SET-Software
                   der Käufer es bedarfsweise überprüfen kann. Das Purchase-Request-
                   Protokoll wird initiiert, wenn der Kartenbesitzer seine Produktauswahl
                   getroffen und ein Bestellformular mit den notwendigen Daten ausgefüllt
                   und geprüft hat. Zu diesen Daten gehören bspw. die Anzahl der gewünsch-
                   ten Teilzahlungen und die zu benutzende Kreditkarte. Diese Daten werden
                   wieder verschlüsselt übertragen. Der Händler-Server wird sich mit seinem
                   digitalen Zertifikat gegenüber dem Käufer ausweisen und der Bestellung
                   einen eindeutigen Transaktions-Identifikator zuordnen.
Purchase           Das Payment-Authorization-Protocol bestimmt, wie die Abwicklung einer
authorization      „Kauf-Freigabe“ erfolgt. Vereinfacht ausgedrückt, wird der Kaufbetrag
                   und der Transaktions-Identifikator mit der digitalen Signatur des Händlers
                   versehen und codiert an das Payment Gateway übertragen. Das Payment
                   Gateway decodiert die Anfrage und nimmt alle notwendigen Überprüfun-
                   gen vor, so z. B. ob der Händler autorisiert ist und ob die Karteninformati-
                   onen unverfälscht sind. Hat alles seine Ordnung, so wendet sich das Pay-
                   ment Gateway mit einer Autorisierunganfrage an die Ausgabebank der
                   Kreditkarte. Die Autorisierungsantwort wird nach weiteren Entschlüsse-
                   lungs- und Verschlüsselungsaktionen vom Payment Gateway wieder an
                   den Verkäufer übermittelt.
Payment capture Wurde die Purchase Authorization positiv abgewickelt, so wird der Händler
                   mit der Auslieferung der bestellten Güter beginnen und den Einzug des Gel-
                   des anstoßen. Für letzteres ist das Payment-Capture-Protocol zuständig.
                   Auch hier kommt wieder der Transaktions-Identifikator zur Anwendung.
Zertifizierungs-   Damit SET zum offenen System wird, an dem sich Konsumenten mit un-
hierarchie         terschiedlichen Kreditkarten beteiligen können, ist eine Hierarchie von
                   Trust-Centern notwendig. Das oberste Trust-Center der SET-Infrastruktur,
                   die sogenannte Root Certification Authority (CA), wird von Visa betrieben.
                   Die verschiedenen Kreditkartenunternehmen (Brands), also Visa selbst,
                   MasterCard, American Express usw. müssen eigene Trust Center betrei-
                   ben, die von der Root Certification Authority zertifiziert werden. Diese
                   Brand-CAs wiederum zertifizieren Certificate Authorities, welche im Auf-
                   trag der kartenherausgebenden Banken den Karteninhabern, Händlern und
                   Betreibern (Acquirer) Zertifikate ausstellen. Diese Zertifikate werden beim
                   Zahlungsvorgang zur gegenseitigen Authentifizierung eingesetzt [Ham-
                   mel].
Erweiterungen      Die aktuelle SET-Version (Version 1.0 vom 31. Mai 1997) ist kreditkarten-
vorgesehen         basiert. In einer späteren Version sollen auch SmartCard-Zahlungstrans-
                   aktionen möglich sein.


                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               77

5.13.6       SSL: Secure Socket Layer
Das Protokoll SSL (auch unter der Bezeichnung TLS: Transport Layer Etabliert und
Security bekannt) wurde von der Firma Netscape Communications entwi- bewährt
ckelt und hat sich durch die Implementierung in den Produkten Netscape
Browser und NetSite Commerce Server als eine Art Standard für ver-
schlüsselte Datenübertragung über das Internet etabliert [Reif]. Die erste
Version wurde Ende des Jahres 1994 eingeführt. Es unterstützt beliebige
TCP/IP-basierte Protokolle wie beispielsweise ftp, gopher und telnet.
SSL-gesicherte Übertragungen sind beim Netscape-Navigator an dem ge- Sicherheits-
schlossenen Vorhängeschloss-Symbol im unteren linken Teil des Browsers symbol im
zu erkennen. Durch Anklicken des Symbols gibt der Browser Sicherheits- Browser
informationen zur aktuellen HTML-Seite aus.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   78                                                                   J. Anton Illik

                   Abbildung 5.16 Sicherheitsinformation zu einer HTML-Seite




Zertifizierungs-   Um sicher zu gehen, dass der Besitzer des verwendeten Schlüsselpaares
stellen            auch derjenige ist, für den er sich ausgibt, wurden sogenannte Zertifizie-
                   rungsstellen (Certification Authorities) geschaffen. SSL basiert auf dem
                   ISO-Standard X.509, nach dem die Authentifikation in Netzwerken durch
                   Zertifizierungsstellen ermöglicht wird [Breilmann 102]. Dieser Standard
                   legt neben einer digitalen Unterschrift auch die Authentizität des Zertifika-
                   tes (und damit der Unterschrift) fest. Die Zertifizierungsstellen sind bei
                   diesem Standard (wie bei Privacy Enhanced Mail) in einer Baumstruktur
                   angeordnet. Um die Authentizität des Zertifikats nachzuweisen, müssen
                   gegebenenfalls alle daran beteiligten Zertifizierungsstellen durchlaufen
                   werden [Breilmann 102ff].




                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               79

Abbildung 5.17 Dokumenteninformation einer gesicherten SSL-Übertragung
unter Netscape




Innerhalb des OSI-Schichtenmodells ist SSL auf der Session-Layer einzu- Begrenzt auf
ordnen. Es unterstützt Software-Entwickler von TCP/IP-Anwendungen zwei Parteien
durch die Nutzung fortgeschrittener Sicherheits-Features. Das Sicherheits-
protokoll ermöglicht einen sicheren Verbindungsaufbau zwischen Browser
und Server, ist jedoch auf zwei Parteien limitiert [Waidner]. Es sollen
Lauschangriffe und das Zurückhalten oder Fälschen von Nachrichten ver-
hütet werden. Die Authentifikationen werden via Zertifikat abgehandelt.
Secure Socket Layer übernimmt:
•   Datenverschlüsselungen,
•   Server-Authentifizierungen,
•   optionale Client-Authentifizierungen,
•   Nachrichtenintegrität,
•   Vertraulichkeit der Datenübermittlung und
•   Non-Repudiation des Datenaustausches.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                   80                                                                   J. Anton Illik

Zweitklassiger     Mit dem RC4-Verschlüsselungs-Algorithmus (gewöhnlich 40 Bit Schlüs-
Export?            sellänge; 128 Bit im US-Binnenmarkt) von RSA werden die Daten ver-
                   schlüsselt. Generell gesehen haben „Paketsniffer“ beim Abhören einer
                   SSL-Verbindung wenig Chancen. Jedoch schließt die Verkürzung der
                   Schlüssellänge auf 40 Bit diese Möglichkeit nicht ganz aus [Reif]. Janson
                   und Waidner bezeichnen die exportierfähigen Protokolle als „zweitklassi-
                   ge“ Technologien und halten das Interesse von Banken, Verkäufern und
                   Kunden an solchen für fragwürdig [Janson/Waidner, 1996a und 1996b].
SSL-2 und SSl-3    Unterschieden werden zur Zeit die Protokollvarianten13 SSL-2 und SSL-3
                   (ab dem Netscape Navigator 3 und dem Microsoft Internet Explorer 3.
                          •    SSL-2 verlangt lediglich die Zertifizierung des Servers. Wird ein
                               sicherer SSL-2-Kanal aufgebaut, kann vom Client aus die Identität
                               des Servers zweifelsfrei verifiziert werden. Dies unterbindet bei-
                               spielsweise Täuschungsmanöver wie das sog. IP-Spoofing. In mo-
                               dernen Web-Browsern wie dem Netscape Navigator oder dem
                               Microsoft Internet Explorer sind die digitalen Unterschriften der
                               bekanntesten Zertifizierungsinstanzen bereits hinterlegt, so dass
                               diese für die Kommunikation auf der Basis von SSL-2 auf der
                               Client-Seite nicht mehr angefordert werden müssen.
                          •    SSL-3 verlangt die Zertifizierung von Clients und Servern. Hierzu
                               muss vom Anwender bei einer etablierten Certification Authority
                               ein Client-Zertifikat angefordert und in den Web-Browser einge-
                               spielt werden.
Einfache Client-   Einfache Client-Zertifikate werden von den meisten Zertifizierungsinstan-
Zertifikate        zen für eine begrenzte Laufzeit (ein halbes Jahr oder ein Jahr) kostenfrei
                   ausgestellt. Allerdings wird dabei i. d. R. nur die Korrektheit der E-Mail-
                   Adresse bestätigt. Bei Einsatz von SSL-3 kann vom Server also die Echt-
                   heit einer angegebenen E-Mail-Adresse, nicht aber etwa die eines Kredit-
                   kartenkontos verifiziert werden.
Unterschied zu     Sieht man einmal von möglichen Sicherheitsproblemen aufgrund unzurei-
SET                chender Schlüssellängen ab, so kann festgestellt werden, dass Transaktio-
                   nen mit Kreditkartenbezahlung sicher mittels SSL über das Internet abge-
                   wickelt werden können. Allerdings bekommt der Händler, anders als beim
                   Einsatz von SET, die Kreditkartennummer zu sehen. Des Weiteren fehlen
                   die in SET integrierten Verfahren zur Gewährleistung der Nichtabstreitbar-
                   keit (non-repudiation) (siehe Kapitel 5.1.2.1 Sicherheit geht über alles) der
                   getätigten Geschäfte.


                   13
                        Siehe http://www.mersch.com/research/xchange/ssl.htm


                   Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                   chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               81

Wie funktioniert nun eine SSL-Verbindung? Eine SSL-Verbindung wird Wie SSL
immer über den Client eingeleitet. Indem der Client das Protokoll HTTPS funktioniert
anstatt http benutzt wissen beide Seiten, dass eine sichere Sitzung gefor-
dert wird. Im Detail geschieht folgendes:
      1. Der Client fordert ein sicheres Dokument an, indem er in der URL
         das Protokoll HTTPS spezifiziert: https://server.domain.com/....
      2. Der Server sendet daraufhin sein Zertifikat an den Client.
      3. Der Client überprüft, ob das Zertifikat von einer vertrauenswürdi-
         gen Certificate Authority (CA) ausgegeben wurde.
      4. Der Client überprüft, ob die Daten im Zertifikat mit den Daten der
         Seite übereinstimmen.
      5. Der Client teilt dem Server mit, welche Verschlüsselungsverfahren
         er beherrscht.
      6. Der Server wählt das sicherstmögliche Verfahren aus und infor-
         miert den Client.
      7. Der Client generiert einen Sitzungsschlüssel (session key).
      8. Der Client verschlüsselt diesen Sitzungsschlüssel mit dem abge-
         stimmten Verschlüsselungsverfahren und dem öffentlichen Schlüs-
         sel des Servers und sendet ihm den verschlüsselten Sitzungs-
         schlüssel.
      9. Der Server entschlüsselt den Sitzungsschlüssel mit seinem priva-
         ten Schlüssel.
      10. Nun haben der Client und der Server den sicheren Sit-
          zungsschlüssel und können ihn für den Austausch sensitiver Daten
          verwenden.
Mehr Informationen über SSL sind verfügbar auf der WWW-Seite:
http://home.netscape.com/eng/ssl3/ssl-toc.html.

5.13.7        MilliCent Protokoll
Das MilliCent Protokoll wurde von Digital Equipment14 als Abrechnungs- Für Micro-
möglichkeit für Kleinstbeträge im Cent-Bereich entworfen [Flohr]. Broker payments
übernehmen die Kontenführung von Anbietern und Kunden und erstellen
die Berechtigungsscheine für die Kunden. Die kumulierten Beträge, die
auch eine Broker-Gebühr beinhalten, kann der Kunde dann per elektroni-


14
     Jetzt Compaq. Die Entwicklung erfolgte noch vor der Übernahme durch Com-
      paq.Compaq wurde seinerseits im Sept. 2001 von HP übernommen.


Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                  82                                                                   J. Anton Illik

                  schen Zahlungsmitteln oder auf herkömmlichem Weg bezahlen [Reif]. Die
                  Broker dienen somit als Accouting-Intermediäre zwischen den Kunden
                  und den Anbietern, wobei sich Digital Equipment als Broker seriöse finan-
                  zielle Institutionen wie VISA, MasterCard, Banken oder auch große Inter-
                  net- oder Online-Service Provider wie AOL oder CompuServe vorstellen
                  kann [Glassman/u. a.].
Kein zentraler    Die Überprüfung auf Mehrfachausgaben der Scheine übernimmt der Ver-
Server, keine     käufer selbst, somit entfällt ein zentraler Server. Es werden symmetrische
Anonymität,       Verschlüsselungsverfahren verwendet, das Protokoll bietet keine Anonymi-
keine Krypto-     tät. Aufwendige Kryptografie-Mechanismen werden wegen der geringen
grafie            Beträge nicht angewandt.
In Japan          Das System wurde eine Zeit lang nicht kommerziell genutzt, befindet sich
kommerziell       aber derzeit in Japan im operativen Einsatz. Ein interner Test bei Digital
genutzt           über TCP/IP-Netzwerke ergab, dass schätzungsweise eintausend Anfragen
                  per Sekunde validiert werden können [Flohr]. Weitere Informationen über
                  MilliCent (detaillierte Funktionsweise, Inhalte der Berechtigungsscheine
                  u. a.) sind auf der Web-Seite http://www.millicent.com enthalten.

                  5.13.8       Zusammenfassung
SET dominiert     Wie bereits erläutert, sind einige Protokolle durch die Entwicklung von
                  SET kein Diskussionspunkt mehr. Diese Protokolle (iKP, SEPP und STT)
                  werden mit größter Wahrscheinlichkeit in Zukunft keine Rolle mehr spie-
                  len.
Marktdurchdrin-   SET hat sich für den Bereich Kreditkarten-Transaktionen durchgesetzt.
gung erreicht     Einerseits haben die umfangreichen Sicherheitsmechanismen, andererseits
                  die finanzielle Kraft und Marktmacht von VISA, MasterCard u. a. für den
                  Marktdurchbruch gesorgt.
Von SSL zu TLS    Auch SSL wird zukünftig weiterhin eine große Rolle spielen – jetzt als
                  Internet-Standard RFC2246 mit dem Namen TLS (Transport Layer Securi-
                  ty).


                  5.14 Integration elektronischer Zahlungssysteme
Meta-           Welche Wahlfreiheit soll dem Anwender bezüglich der Zahlungsweise ge-
Zahlungssysteme währt werden? Im Idealfall sollte der Kunde das Zahlungsmittel seiner Wahl
                  verwenden können! Die Forderung nach der Integration der Zahlungssyste-
                  me, so dass der Kunde frei wählen kann, führt zu dem Wunsch nach einem
                  generischen Meta-Zahlungssystem, in das bei Bedarf beliebige konkrete,


                  Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                  chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               83

marktgängige Zahlungssystemprodukte sowohl auf der Anbieterseite wie
auch auf der Käuferseite eingehängt werden können. Eine Anstrengung in
diese Richtung ist die Joint Electronic Payment Initiative (kurz: JEPI), die
von CommerceNet (http://www.commerce.net) und dem World Wide Web-
Consortium (kurz: W3C; http://www.w3.org) getragen wird.

5.14.1       JEPI: Joint Electronic Payment Initiative
JEPI ist ein Projekt zur Lösungsfindung für eine dediziertes Problem zu                Die Vielzahl der
einem ganz bestimmten Zeitpunkt innerhalb der Verkaufsstransaktion.                    Zahlungssysteme
Nachdem der Einkaufskorb gefüllt ist und bevor die Bezahlung beginnt,                  spiegelt die
muss eine Festlegung auf ein elektronisches Zahlungssystem erfolgen.                   Bedarfsvielfalt
Diese Festlegung und Vereinbarung zwischen Käufer und Verkäufer tech-                  wider
nisch zu unterstützen und soweit wie möglich zu automatisieren, ist das
Ziel des JEPI-Projekts. JEPI steht den verschiedenen Zahlungssystemen
positiv gegenüber und sieht ihre Existenzberechtigung in den verschie-
densten Bedürfnissen von Käufern und Verkäufern. Allerdings: JEPI un-
terstützt in seinem jetzigen Ansatz keine Konvertierungsfunktionen. D. h.,
ist in einer Electronic Mall der Zahlungssystem-Server A installiert und der
Kunde hat einen Zahlungssystem-Client B, so hilft JEPI nicht weiter. Hat
dagegen der Verkäufer die Zahlungssystem-Server A, B und C im Einsatz
und verfügt der Kunde über Zahlungssystem-Clients C, D und E, so wird
JEPI das Zahlungsverfahren C wählen und zum Einsatz bringen. Mit Hilfe
von JEPI soll der End-User auch in die Lage versetzt werden, sein Arsenal
an Zahlungssystemen so zu erweitern, dass bisher Installiertes nicht durch
die Installation von Neuem durcheinandergebracht wird.
Die im JEPI-Projekt berücksichtigten Zahlungsprotokolle umfassen unter
anderem:
• den von MasterCard und Visa entwickelten SET-Standard,
• das CyberCash System von Cyber Cash Inc.,
• NetBill von der Carnegie Mellon University,
• First Virtual von FirstVirtual Holdings Inc.




Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
                    84                                                                   J. Anton Illik

                    5.14.2       OTP: Open Trading Protocol
Auf der Basis von   Am Open Trading Protocol versucht sich ein Konsortium bestehend aus
XML mit dem         Technologiefirmen und Finanzinstituten. Synergetische Effekte verspre-
Schwerpunkt         chen sich als Konsortiumsmitglieder die Firmen AT&T, Hewlett-Packard,
Business-to-        IBM, MasterCard International, Mondex International, Open Market, Cy-
Consumer-           ber Cash, First Data, VeriFone, Wells Fargo und andere. Durch die Spezi-
Bereich             fikation eines fundierten Angebots an standardisierten Internet-Handels-
                    transaktionen soll eine sichere und effiziente Geschäftsabwicklung zwi-
                    schen allen Beteiligten ermöglicht werden, unabhängig von einer bestimm-
                    ten Zahlungsmethode. OTP, das speziell für E-Commerce Angebote an
                    Privatkunden zugeschnitten ist, beschäftigt sich mit mehreren Mechanis-
                    men zur elektronischen Zahlung, darunter Kreditkarten, Smartcards und
                    SET. Damit bildet OTP eine direkte Konkurrenz zu JEPI. Technisch will
                    das OTP-Konsortium einen Protokoll-Rahmen (protocol framework) auf
                    der Basis von XML (extensible markup language) modellieren. Als Pro-
                    dukte auf der Basis von OTP kann man sich elektronische Geldbörsen
                    (electronic wallets), Merchant Server als elektronische Handelssysteme
                    und elektronische Zahlungssysteme (financial payment systems) vorstellen.
                    Laut Angaben des Konsortiums fasst OTP die Zahlung mit Angeboten,
                    Rechnungen, Zahlungsbestätigungen und Versand zusammen.

                    5.14.3       OBI: Open Buying on the Internet
EDI-basierend       SupplyWorks ist ein weiteres Konsortium bestehend aus Finanzinstituten
für den Business-   und Technologiefirmen. Ziel ist hier eine Lösung für den Business-to-
to-Business-        Business-Bereich, um Handelstransaktionen auf der Basis von EDI ANSI
Bereich             X12 850 über Internet abzuwickeln. OBI betont als kritischen Erfolgsfaktor
                    für den Markterfolg elektronischer Handelssysteme die inhärente Fähigkeit
                    zur Zahlungsabwicklung in den E-Commerce Software-Paketen der Ver-
                    käufer wie auch der Einkäufer. OBI ist nicht kompatibel mit OTP.

                    5.14.4       HBCI: Homebanking Computer Interface
                    HBCI ist ein Internet-Schnittstellen-Standard für deutsche Banken. Im Juli
                    1997 einigten sich die Spitzenverbände der deutschen Kreditwirtschaft auf
                    den Standard in der Version 2.0. Im Oktober 1998 wurde die Version 2.0.1
                    freigegeben. Der HBCI-Standard unterstützt z. B. terminierte Überweisun-
                    gen, Daueraufträge, Festgeldanlagen und Auslandsüberweisungen. HBCI
                    soll umfassende Sicherheit durch entsprechende Verschlüsselungsverfah-
                    ren garantieren. Der Kunde erhält ein lokales Sicherheitsmedium mit ei-
                    nem privaten Schlüssel in Form einer Diskette oder Chipkarte. Damit iden-

                    Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
                    chen, Wien,2002. http://www.university-web.de/illik/ec2002
Zahlungsmittel für digitale Märkte: digitales Geld                               85

tifiziert sich der Konto-Inhaber am heimischen PC. Ab der Version 3.0
sollen Wertpapiertransaktionen durch HBCI unterstützt werden. Außerdem
sollen Geldkarten online aufgeladen werden können. Auch der sichere
Internet-Einkauf und die Online-Bezahlung sollen ab dann unterstützt
werden. Ein weiterer Vorteil ist die Multibanken- und Multikontenfähig-
keit von HBCI. Der Kunde kann sich mit einem HBCI-fähigen Front-End
Konto bei mehreren Banken bedienen. Mit HBCI wird Internet-Banking
für Kunden deutscher Banken auch im Ausland möglich, ohne an einen
einzelnen Provider gebunden zu sein.

5.14.5       BIPS: Bank Internet Payment System
Ein weiteres Konsortium wird von US-Banken, US-Behörden und Techno- Vertrauens-
logiefirmen gebildet: die FSTC (Financial Services Technology Consorti- würdigkeit ist
um). Durch diese Zusammenstellung der Konsortiumsmitglieder wird be- das A und O
wusst versucht, von Haus aus eine gewisse Vertrauenswürdigkeit in elekt-
ronische Zahlungsmittel hineinzuprojizieren, damit es leichter wird, Fir-
men die Abbildung von Zahlungstransaktionen auf das Internet schmack-
haft zu machen. Konkret arbeitet das BIPS-Konsortium auch an der Spezi-
fikation sicherer Server für die bankseitige Abwicklung von Zahlungs-
transaktionen über das Internet. Über die BIPS-Lösung sollen Käufer und
Anbieter die Zahlungsbedingungen und auch das Zahlungsmittel aushan-
deln können. Insgesamt wird versucht durch eine multibankenfähige Lö-
sung auch hinsichtlich Kosteneffizienz und Geschwindigkeit für Kunden
attraktiv zu sein. Beobachter schätzen die BIPS-Initiative als führend ein,
wenn es um die Abwicklung zwischenbetrieblicher Transaktionen und um
neue Paradigmen eines netzwerkorientierten Bankings geht. Kritiker halten
dem entgegen, dass BIPS zu viele Ziele gleichzeitig angeht und zu viele
separate Interessen verfolgt.


5.15 Zusammenfassung und Ausblick
Mittlere und größere Einkäufe über das Internet werden mit Kreditkarten Mittlere und
abgewickelt. So haben sich Kreditkartenunternehmen und Computer- größere Käufe
Hersteller zusammengetan, um sichere Standards eigens für die Kreditkar-
tenzahlung über das Netz zu entwickeln. Im Herbst 1995 haben Visa und
Microsoft zusammen den Secure Transaction Technology (STT)-
Verschlüsselungsmechanismus entworfen. Zur selben Zeit sahen Master
Card, Netscape, CyberCash, GTE und IBM den Zeitpunkt für ihr Secure
Electronic Payment Protocol (SEPP) gekommen. Auf Druck der Banken
[vgl. Reif, 145] fanden die Konkurrenten letztlich zusammen und spezifi-

Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
chen, Wien,2002. http://www.university-web.de/illik/ec2002
             86                                                                   J. Anton Illik

             zierten SET (Secure Electronic Transactions) als Grundlage für Bankkar-
             tenzahlungen oder, um von Software-Herstellern als Basis für die Entwick-
             lung von Zahlungs-Software genutzt zu werden. Siehe z. B.
             http://www.visa.com. Im Februar 1996 wurde SET zum offiziellen Standard
             erklärt. In späteren Versionen von SET werden auch SmartCard-
             Zahlungstransaktionen möglich sein. Da SET mit Zertifikaten arbeitet, sind
             Trust Center und auch eine Zertifizierungshierarchie, wie sie [Feder-
             rath/Jerichow/Pfitzmann/Pfitzmann] beschreiben, notwendig.
Kleinere     Für kleinere Käufe von digitalen Mitnahmeartikeln, Informationen, Pay-
Einkäufe     per-use-Zugriffe auf kommerzielle Web-Seiten usw. – also dort, wo es um
             Micropayments geht – ist heute häufig First Virtual (FV) zu finden. In
             diesem System wird letztendlich zwar auch über Kreditkarte abgerechnet,
             aber ein Billing-Server kann Micropayments bündeln und im Gegensatz zu
             reinen Kreditkartensystemen (z. B. SET) werden bei Transaktionen keine
             Kreditkartennummern, sondern der VirtualPIN übermittelt. FV sorgt dann
             dafür, dass der Händler sein Geld bekommt. Der Verkäufer braucht keine
             Kreditkartenakzeptanzstelle zu sein, da First Virtual zwar die Belastung
             des Kunden über dessen Kreditkarte vornimmt, dem Verkäufer jedoch, der
             ebenfalls einen FV-Account besitzen muss, den Betrag auf beliebigem
             Weg gutschreibt.
Welches      Stand-alone-Zahlungssysteme sind für sich alleine nicht sonderlich attrak-
Konsortium   tiv. Zum einen sind nicht alle Zahlungssysteme für alle Handelsvarianten
gewinnt?     gleich gut geeignet, zum anderen müsste der Anbieter, um einen möglichst
             breiten, globalisierten Markt bedienen zu können, alle auf der Kundenseite
             genutzten Zahlungssysteme vorhalten. Hinzu kommt, dass E-Commerce zu
             vielschichtig ist, als dass es in das einfache Schema „Ware zu Festpreis
             anbieten – bestellen – bezahlen – liefern“ gepresst werden könnte. Vor dem
             Hintergrund, dass E-Commerce deutlich in Richtung dynamisches Han-
             delsnetzwerk (dynamic trading network, DTN) tendiert, in das sich Anbie-
             ter und Nachfrager spontan einklinken können, sind die oben geschilderten
             Ansätze der Konsortien strategisch bedeutsamer. So ist es auch zu verste-
             hen, dass sich mehrere Konsortien gebildet haben, die versuchen mit ihrem
             Ansatz einen de-facto-Standard zu setzen. Dies wird nicht allen Konsortien
             gelingen.




             Online-Anhang zu Buch „Electronic Commerce“, J. Anton Illik, Oldenbourg Verlag, Mün-
             chen, Wien,2002. http://www.university-web.de/illik/ec2002

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:70
posted:8/28/2011
language:German
pages:82