IIlustration: D. Jokisch
Unterthema: iX-TRACT
Unterthema: Direkter Münztransfer
Unterthema: Münztransfer bei Firewall
Unterthema: Sicherheit gefragt
Unterthema: Münzen drucken im Cyberspace
Unterthema: LINKS UND HOTLINE
Einkaufen per Mausklick beginnt, Wirklichkeit zu werden. Nach gründlichen Probeläufen und Tests mit `Spielgeld' können seit dem 1. Oktober bis zu 1500 Kunden an einem Pilotversuch der Deutschen Bank teilnehmen und, mit Cybercoins ausgestattet, ihren Internet-Einkaufsbummel in verschiedenen Shops starten. Eine ganze Reihe von Online-Läden haben bereits ihre Tore geöffnet, unter anderem der Shop des dpunkt-Verlags (ecash-dpunkt.de), in dem Kunden Screen-Design-Vorlagen oder Buchkapitel erwerben können. Für den Käufer genügt neben dem WWW-Zugang ein ecash-Konto bei der Bank und eine elektronische Geldbörse (Wallet) auf dem Rechner.
Etwas aufwendiger ist es, einen virtuellen Shop zu eröffnen. Bei den ersten Schritten hilft die Bank: Sie stellt die Software und Anleitungen zur Verfügung. Der Händler installiert das Programm auf seinem Webserver und läßt die Module von einem CGI-Script mit entsprechenden Parametern aufrufen. Den Münztransfer zwischen Kunden- und Händlerbörse übernimmt die Software, zum Beispiel das Händlermodul DBecash: Sie fragt bei der Geldbörsensoftware des Kunden an, ob diese bereit und fähig ist, Münz-Strings zu übersenden. Wenn der Kunde zustimmt, werden diese aus seiner Börse gelöscht und in die des Händlers hinzugefügt. Die Bank überwacht mit dem `Double-Spending-Server', daß sich niemand durch Kopieren neue Münzen erzeugt. Mehr hierzu im Kasten `Münzen drucken im Cyberspace'.
Schwieriger wird es bei harter Ware, zum Beispiel Büchern. Bei Lieferproblemen müßte der Händler das bereits gezahlte Geld per EMail zurücksenden. Dieses ist zwar möglich, aber umständlich und für beide Seiten enttäuschend. Besonders für wertvollere Ware ist daher die Kreditkarte oder Rechnung sinnvoller als ecash. Praktisch sind die Cybermünzen für kleinere Beträge, sogenannte Micropayments zwischen 1 Pfennig und etwa 30 Mark - immer dann, wenn die Abbuchung über Kreditkarte oder das Schreiben einer Rechnung teurer wird als die verkaufte Ware. Auch für Beträge unter 1 Pfennig - sogenannte Picopayments - gibt es bereits Ansätze; damit wird sich einer unserer nächsten Artikel beschäftigen.
Der Händler muß sich entscheiden, welche Produkte er im WWW anbieten will. Gut geeignet für den Online-Handel sind digitale Waren, hier Grafiken. Der Kunde zahlt mit ecash-Münzen aus seiner Geldbörse (Abb. 1).
Das Problem liegt bei diesem Verfahren in erster Linie in der Münzübertragung. Sie geht üblicherweise über eine direkte TCP/IP-Verbindung via Port 5654 und wird durch ein CGI-Script initiiert. (siehe Kasten `Direkter Münztransfer'). Das ist allerdings nur möglich, wenn das CGI-Script die IP-Adresse des Kunden (HTTP-Client) erkennen kann. Kommt die Anfrage des Kunden über einen Proxy oder sitzt er hinter einem Firewall, kann er nicht mehr identifiziert werden, da der eigentliche Aufruf des Scripts nun nicht mehr direkt von ihm, sondern von der Software des Firewalls/Proxies erfolgt. Das gleiche gilt für den Fall, daß die IP-Adresse des Kunden durch IP-Masquerading verschleiert wird, oder daß der Server selber hinter einem Proxy-Server und/oder einer Firewall steht.
Über 90 Prozent der Benutzer kommen über einen Proxy oder Firewall zu den Webservern und wären wohl nur in den seltensten Fällen dazu bereit oder fähig, für die Überweisung ihren Proxy/Firewall auszuschalten. Da der Server in diesem Fall nicht die Möglichkeit hat, eine Verbindung mit dem Client neu zu initiieren, muß die Software ausweichen. Bekommt das Programm auf dem direkten Weg keine Antwort, nutzt es die bereits bestehende Verbindung und wechselt auf den MIME-Typ multipart/x-mixed-replace (Multipart-Dokument) zur Übertragung (siehe Kasten `Münztransfer bei Firewall').
Bei diesem ersten Übertragungsschritt muß der Händler darauf achten, daß die MIME-Dokumente nicht vom Server geparsed und gepuffert, sondern sofort weitergegeben werden. Um dies zu gewährleisten, muß entweder der Name des Scriptes mit `nph-` anfangen (non-parsed-header) oder der Puffer mit Leerzeichen vollgeschrieben werden. Der zweite Teil des Dokuments wird erst geschickt, wenn die Börse des Kunden die Anweisungen erfolgreich bearbeitet hat. Der daraufhin vom Server gesendete Dokumentteil enthält entweder die Ware, wenn die Überweisung ausgeführt wurde, oder eine entsprechende Meldung.
Im Supermarkt kleben die Verkäuferinnen auf Waren Preisschilder, die Standard-Shop-Lösung von DigiCash sieht eine Preistafel vor, aus der die Händlersoftware die Preise für die jeweilige Ware entnehmen kann. Diese Tafel (Textdatei: price_conf) muß vor Zugriffen von außen gut geschützt auf dem Server liegen. Sie enthält den Dateiname der Ware, den Preis und nach Möglichkeit eine kurze Produktbeschreibung. Dieser einfache Aufbau hat den Vorteil, daß sich ecash leicht einrichten und benutzen läßt. Der Nachteil besteht darin, daß der übliche Online-Shop oft anders konzipiert ist. Was der Händler meist haben möchte, ist ein System, das dynamische Preise und Produkte, zum Beispiel Warenkörbe, zuläßt.
Dazu bedarf es eines Scriptsystems, das Warenkörbe nicht nur dynamisch erzeugt, sondern auch mit einem Preis `etikettieren' kann. Es muß so ausgelegt sein, daß diese Warenpakete zum Schluß von einem einfachen ecash-Verkaufs-Script zum Download angeboten werden können. Das System kann also in zwei voneinander unabhängige Module zerlegt werden. Das eine Modul `schnürt' das Warenpaket und `etikettiert' es mit dem entsprechenden Preis. Das andere Modul ist für den Verkauf des Paketes mit ecash verantwortlich und muß den Preis des Paketes schnell, zuverlässig und unproblematisch `ablesen' können.
Da das Erzeugen dieser Pakete möglicherweise Minuten in Anspruch nehmen kann, sollen die Geldtransferroutinen in einem völlig getrennten CGI-Aufruf geschehen. Das ecash-Modul muß deshalb wissen, was und für wieviel verkauft werden soll. Die Etikettierung muß also persistent sein. Eine Möglichkeit ist, daß die Download-Datei, zum Beispiel mit ihrem Namen, in einer Datenbank mitgeführt wird. Ein Nachteil entsteht durch den zusätzlichen Pflegeaufwand. Außerdem hängen Produkt und Preis so nicht unmittelbar zusammen. Damit steigen die Möglichkeiten eines Mißbrauchs. Beim Shop des dpunkt-Verlags wird der Preis der Download-Datei in ihren Namen einkodiert. Die Werte hätten auch dem Archiv als Kommentar oder kurze Textdatei beigefügt werden können, das wäre allerdings weit aufwendiger gewesen.
<a href="/cgi/nph-download?file=
1.00-9918-971023-1405-4:7.zip">
die Graphiken 4 bis 7 à 1.00 DM
</a>
Der Kunde kann sich die gewünschte Ware herunterladen. Das Geschäft ist gemacht. (bl)
ist Leiter des Internet-Servicecenter (hd-web) der Hüthig Fachverlage und Webmaster des dpunkt.Verlags.
studiert Mathematik an der Universität Heidelberg und arbeitet als Systemadministrator und Webadmin von hd-web (dpunkt.Verlag).
[2] Klaus-Peter Boden, Michael Barabas (Hrsg.); Internet von der Technologie zum Wirtschaftsfaktor, Deutscher Internet Kongress 1997; dpunkt, 1997
[3] Markus Stolpmann; Elektronisches Geld im Internet, Grundlagen, Konzepte Perspektiven; O'Reilly, 1997
[4] Stefan Mintert; JavaScript; Sonst noch etwas?; Warenangebot im World Wide Web; iX 6/97; S. 134 ff.
1. Der Browser löst den CGI-Aufruf aus.
2. Der HTTP-Server ruft daraufhin das CGI-Script auf.
3. Das CGI-Script ruft über eine Schnittstelle das entsprechende ecash-Modul auf.
4. Das ecash-Händlermodul stellt über einen Socket auf Port 5654 mit der ecash-Börse des Clients eine Verbindung her mit dem Ziel, die Überweisung auszuführen.
5. Nachdem der Benutzer dies bewilligt hat, gibt die Börse die Bestätigung an das ecash-Händlerprogramm des Servers zurück.
6. Diese erreicht das CGI-Script, das mit einer entsprechenden Antwort (Bestätigung/Verweigerung. reagiert. Diese erreicht dann über
7. den HTTP-Server;
8. den Browser des Kunden.
1) Der Browser löst einen CGI-Aufruf aus.
2. Der HTTP-Server ruft das CGI-Script auf.
3. Das CGI-Script ruft das ecash-Händlerprogramm auf, mit der Anweisung, auf eine Geldübergabe auf dem ersten freien Port zwischen 1100 und 1199 zu warten. Zusätzliche Aufrufparameter sind unter anderem die zu erwartende Geldmenge und eine Beschreibung der Ware.
4. ecash (Händlerprogramm) schreibt nach STDOUT einen circa 200 Zeichen langen chiffrierten Schlüssel. Dieser erklärt, wofür wieviel Geld auf welchem Weg überwiesen werden soll. Das Programm wartet auf eine Verbindung und beendet sie erst, nachdem die Überweisung stattgefunden hat oder ein Timeout kommt.
5. Der Schlüssel wird vom CGI-Script als MIME-Application/ecash-Dokument mit Multipart-Trenner an STDOUT geschrieben. Das CGI-Script wartet, bis das ecash-Händlerprogramm beendet ist.
7. Der Browser bekommt das MIME-Application/ecash-Dokument und ruft das Frontend mit dem entsprechenden Schlüssel aus dem Dokument auf.
8. Das Frontend steuert die ecash-Börse.
9. Schließlich initiiert die ecash-Börse die Überweisung mit dem wartenden ecash- Händlerprogramm.
10. Das ecash-Händlerprogramm meldet den Erfolg der Überweisung.
11. Das CGI-Script schickt nun ein zweites MIME-Dokument (die bezahlte Ware, falls Überweisung erfolgreich).
12) Der Server leitet weiter.
Mit geschickten Tricks ist es nicht nur möglich, dem Kunden zuviel oder schlechte Ware zu verkaufen. Der Händler könnte nach der Zahlung einfach Produkte liefern, die der Kunde gar nicht wollte - ein weites Feld für Juristen und internationale Rechtskonflikte. Der Kunde muß sich bewußt sein, daß auf seinem Rechner, den er unter Umständen früher nur zum Spielen verwendet hat, nach der Installation der Geldbörse echtes Geld liegt. Ein völlig neues Sicherheitsverständnis muß wachsen. So sollte er auf einem Rechner mit ecash-Börse nicht unkritisch alle verfügbaren Programme vom Internet herunterladen und testen.
Ständiger Virenschutz und das Ausschalten von Active/X sind unumgänglich. Denn via Active/X, Viren und Trojanischen Pferden - Programme, die so tun, als ob sie zum Beispiel das ecash-Programm wären - könnte ein Hacker das Paßwort zum Abbuchen vom Bankkonto oder den Private-Key bei einem Recover der Geldbörse aus dem Fenster der ecash-Software auslesen. Auch ist es wohl möglich, über den Internet Explorer ein Active/X-Programm beim Client laufen zu lassen, das den Bestätigungsknopf bei der ecash-Überweisung automatisch drückt. Diese Gefahr ist allerdings dadurch verringert, daß der Internet Explorer MIME-Type-multipart nicht vollständig beherrscht, und deshalb für einen ecash-Benutzer als Browser kaum in Frage kommt.
Sie wird zufällig erzeugt. Da die Zahl sehr groß ist, besteht kaum die Gefahr, daß zweimal die gleiche Nummer erzeugt wird. In diese Seriennummer ist der öffentliche Schlüssel der Bank einkodiert, zusätzlich wird sie verschlüsselt. Der gesamte Münzrohling wird mit dem öffentlichen Schlüssel der Bank kodiert und danach mit dem privaten Schlüssel des Kunden signiert. Dann kommt der Münzrohling zur Bank. Nur sie kann ihn lesen und feststellen, ob die Münze tatsächlich von dem Kunden stammt. Die Bank kennt den Wert der Münze, nicht aber die Seriennummer.
Digitale ecash-Münzen verhalten sich wie `echtes' Geld. So ist es nicht möglich - wie beim Picopayment - kleinere Beträge als 1 Pfennig zu verlangen. Um mit möglichst wenig Münzen jeden Betrag abzudecken, sind die verschiedenen Werte in Zweierpotenzen gestaffelt: 1 Pfennig, gefolgt von 2, 4, 8 und so weiter. Hat ein Kunde zum Bezahlen eines bestimmten Betrags nicht mehr genügend passende Münzen parat, muß er bei der Bank wechseln.
http://home.netscape.com/assist/net_sites/dynamic_docs.html
http://www.digicash.com/ecash/
http://www.deutsche-bank.de/wwwforum/ecash/
Hotline der Deutschen Bank: 018 05/22 42 00