Inhaltsverzeichnis Kapitel 1 Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 Kapitel 6 Literaturverzeichnis
SET ist ein offener Standard für das Bezahlen mit Kreditkarten, der von Visa und MasterCard entwickelt wurde.
Abbildung 9: Die SET-Architektur ([LEP99])
Damit der Kunde seine sensiblen Kreditkartendaten nicht direkt dem Händler übergeben muss, aber der Händler auch einer ausreichenden Deckung des Kundenkontos sicher sein kann, übernimmt ein sog. Acquirer die Kommunikation zwischen Kunde und Händler. Die Zertifizierung gewährleistet die Authentifizierbarkeit der Kunden, Händler und Acquirer.
Abbildung 10: Die SET-Zertifizierungshierarchie ([LEP99])
An der Spitze steht die Wurzelzertifizierungsinstanz. Sie vergibt Zertifikate an die Kreditkartenbetreibergesellschaften und achtet auf die Einhaltung bestimmter Richtlinien.
Die Zertifizierungsinstanzen der Kreditkartenbetreiber zertifizieren entweder ihre geopolitischen Zertifizierungsinstanzen, die eine Aufteilung über mehrere Länder/Regionen ermöglichen, oder direkt die Zertifizierungsinstanzen für Kunden, Händler und Acquirer.
Die Zertifizierungsinstanzen für Kunden, Händler und Acquirer werden von den Kreditkartenherausgebern oder beauftragten Geldinstituten der Kreditkartenbetreiber betrieben.
Die Kunden bekommen ein Zertifikat für ihre Kreditkarte ausgestellt, das die Identität des rechtmäßigen Besitzers feststellt und die Gültigkeit der Kreditkarte beweist.
Anhand des Händlerzertifikats kann der Acquirer die Gutschriften im Falle eines Kaufes adressieren. Für den Kunden spielt dieses Zertifikat eher eine untergeordnete Rolle, da ein betrügender Händler sowieso nicht an die Kreditkarteninformationen des Kunden herankommt (Kapitel 5.1.3). Wichtiger für den Kunden ist das Zertifkat des Acquirers, das auf jeden Fall vom Kunden überprüft werden sollte, da ein boshafter Acquirer die Kreditkarteninformationen des Kunden missbrauchen könnte. Der Acquirer übernimmt eine Notarfunktion: er bestätigt dem Händler die Gültigkeit der Kreditkarte und die Deckung des Kundenkontos und schützt gleichzeitig die Kreditkarteninformationen vor dem Zugriff des Händlers.
Abbildung 11: Bezahlvorgang bei SET ([LEP99])
1. | Der Kunde sucht die Ware aus und ordert diese beim Händler. Dabei sendet der Kunde dem Händler sein Kreditkartenzertifikat. |
2. | Der Händler überprüft das Kreditkartenzertifikat und unterbreitet dem Kunden ein Angebot, das den Handel, den Preis und die Menge der Waren beschreibt. Der Kunde bekommt das Zertifikat des Händlers und des Acquirers. |
3. | Der Kunde überprüft die Zertifikate des Händlers und des Acquirers (Kapitel 3.2.4). Der Kunde akzeptiert ggf. das Angebot und bestätigt somit den Kauf (erste SET-Transaktion). Er sendet die Zahlungsanweisung (die Kreditkartendaten verschlüsselt mit dem öffentlichen Schlüssel des Acquirers) und die Orderinformationen (verschlüsselt mit dem öffentlichen Schlüssel des Händlers), die den Handel beschreiben, an den Händler. |
4. | Der Händler überprüft durch eine Anfrage beim Acquirer, ob der Kunde zahlungsfähig ist. |
5. | Der Acquirer überprüft die Gültigkeit der Kreditkarte und die ausreichende Deckung des Kreditkartenkontos. Das Ergebnis der Überprüfung wird dem Händler mitgeteilt. |
6. | Der Händler leitet das Ergebnis der Prüfung an den Kunden weiter. Wenn die Überprüfung der Kreditkarte erfolgreich war, schickt der Händler die Ware an den Kunden. |
7. | Der Händler fordert sein Geld beim Acquirer ein. |
Die Vertraulichkeit wird durch den Einsatz von symmetrischen (DES bzw. CDMF) und asymmetrischen (RSA) kryptographischen Verfahren sichergestellt. Die Integrität der Daten wird durch digitale Signaturen geschützt, die Authentizität durch die Zertifikate nach dem X.509-Standard. Das Hashverfahren zur Erzeugung der digitalen Signaturen ist SHA-1. Ein Vorteil ist, dass die SET-Spezifikation der Allgemeinheit zugänglich ist und somit potenzielle Fehler leichter entdeckt werden können. Ein allgemeines Problem von Kreditkarten ist, dass im Internet sogenannte Kreditkartennummerngeneratoren existieren, von denen einige aus einer gültigen Kreditkartennummer weitere Kreditkartennummern extrapolieren kann, so dass das zu den extrapolierten Nummern gehörende Verfallsdatum mit großer Wahrscheinlichkeit mit dem der gültigen Nummer übereinstimmt. Auf den Webseiten von MasterCard ist eine Demonstration von SET verfügbar ([MAS99]).
Digitales Münzgeld muss wie das gewöhnliche Bargeld anonym und fälschungssicher sein. Anonym bedeutet in diesem Zusammenhang, dass die bei einem Zahlungsvorgang benutzten Münzen keinem Besitzer zugeordnet werden können wie beim gewöhnlichen Bargeld. eCash erreicht die Anonymität durch das Konzept der blinden Signatur (Kapitel 3.1.5), das von David Chaum, dem Entwickler von eCash, entwickelt und patentiert wurde. Die Fälschungssicherheit wird durch den Abgleich mit einer Datenbank gewährleistet, die die Seriennummern bereits verwendeter Münzen enthält (Kapitel 5.2.1).
Angenommen ein Kunde besitzt ein Konto bei einer Bank, die eCash herausgibt. Um mit eCash einkaufen zu können, muss der Kunde zunächst Geld von seinem Konto abheben, d. h. er muss es auf seinen Rechner in seine digitale Geldbörse laden. Das Kundenkonto bei der Bank wird um den Wert der heruntergeladenen Münzen belastet. Der Abhebevorgang läuft in folgenden Schritten ab:
1. | Der Kunde gibt auf seinem Rechner den gewünschten Wert der in seiner digitalen Geldbörse zu plazierenden Münzen in die eCash-Software ein. Die Software erzeugt daraufhin "Münzrohlinge" geeigneter Stückelung lokal auf dem Kundenrechner. Ein Münzrohling ist im wesentlichen eine Struktur, die als Komponenten den Wert des Münzrohlings und eine Seriennummer enthält. Die Seriennummer identifiziert die Münze eindeutig und wird vom Kundenrechner zufällig generiert. Die Seriennummer ist 100 Bit lang, so dass die Wahrscheinlichkeit, dass zweimal dieselbe Seriennummer generiert wird, vernachlässigbar ist. |
2. | Die Kundensoftware überblendet die Seriennummer (Kapitel 3.1.6) und signiert den Münzrohling (Kapitel 3.1.5). Der Münzrohling wird zusammen mit der digitalen Signatur an die Bank geschickt (verschlüsselt mit dem öffentlichen Schlüssel der Bank, damit nur die Bank den Münzrohling entschlüsseln kann). |
3. | Die Banksoftware entschlüsselt die Nachricht und prüft die Signatur des erhaltenen Münzrohlings (Kapitel 3.1.5). |
4. | Die Banksoftware signiert den Münzrohling mit einem privaten Schlüssel der Bank. Für jeden Münzwert existiert ein Schlüsselpaar, mit dessen Hilfe der Wert der Münze bestätigt bzw. überprüft werden kann. Wichtig ist, dass die Bank die Seriennummer des übergebenen Münzrohlings wegen der Überblendung nicht sehen kann (Kapitel 3.1.6). |
5. | Die Banksoftware verschlüsselt die signierte Nachricht mit dem öffentlichen Schlüssel des Kunden und sendet sie an den Kunden zurück. |
6. | Die Kundensoftware entschlüsselt die Nachricht mit dem privaten Schlüssel des Kunden und entfernt die Überblendung. Es ist eine gültige (von der Bank signierte) Münze bestehend aus Seriennummer und Wert entstanden, die in der digitalen Geldbörse des Kunden gespeichert wird. Das Bankkonto des Kunden wird entsprechend des zur digitalen Geldbörse hinzugefügten Geldwertes belastet. |
Damit ein Kunde mit seinem eCash in einem Online-Shop einkaufen kann, muss der Verkäufer ebenfalls eine elektronische Geldbörse besitzen und sein Konto bei derselben Bank wie der Kunde haben. Der Einkauf läuft in folgenden Schritten ab:
1. | Der Kunde sucht sich das Produkt durch Klicken auf einen Link aus. Dadurch wird auf dem Kundenrechner die eCash-Software gestartet, die die digitale Geldbörse des Kunden verwaltet. Dann sendet die eCash-Software des Verkäufers eine Zahlungsaufforderung über den entsprechenden Betrag an den Kunden zusammen mit dem öffentlichen Schlüssel des Verkäufers. |
2. | Wenn der Kunde die Zahlungsaufforderung akzeptiert, verschlüsselt seine eCash-Software Münzen aus der digitalen Geldbörse mit dem öffentlichen Schlüssel des Verkäufers und sendet die entstandene Nachricht an den Verkäufer. |
3. | Der Verkäufer entschlüsselt die Nachricht mit seinem privaten Schlüssel und überprüft die erhaltenen Münzen auf ihre Gültigkeit. Hierzu sendet er die Münzen an die Bank, wobei er die Nachricht mit seinem privaten Schlüssel signiert und mit dem öffentlichen Schlüssel der Bank verschlüsselt. |
4. | Die Bank entschlüsselt die Nachricht und überprüft die Signatur des Verkäufers. Anhand einer Datenbank, die die Seriennummern der schon ausgegebenen Münzen enthält, überprüft die Bank die Einmaligkeit der erhaltenen Münzen. Liegt eine Doppelung vor, wird die Zahlung nicht akzeptiert. Wenn keine Doppelung vorliegt, werden die Seriennummern in die Datenbank der ausgegebenen Münzen eingefügt und der Betrag dem Verkäufer gutgeschrieben. |
Angenommen Person A möchte Person B digitale Münzen übergeben. Dazu zahlt Person A an Person B wie in Kapitel 5.2.2 beschrieben und Person B lässt sich den auf ihrem Konto gutgeschriebenen Betrag nach Kapitel 5.2.1 in digitalen Münzen auszahlen.
eCash bedeutet totale Anonymität für den Käufer gegenüber der Bank (Kapitel 5.2.1) und gegenüber dem Verkäufer, der zwar weiß, von welcher Bank die Münzen stammen, aber nicht von wem, da ihm der öffentliche Schlüssel des Käufers nicht mitgeteilt wird. Wegen der Anonymität von eCash kann im Falle eines Betrugsversuches mit bereits ausgegebenen Münzen nicht festgestellt werden, ob die Münzen vom Kunden oder vom Händler stammen. eCash besitzt derzeit keine Multibankenfähigkeit, d. h. Geschäftspartner, die über eCash Geld tauschen, müssen ihr Konto bei derselben Bank führen. Weitere Nachteile sind die Nicht-Transaktionalität (Elektronische Münzen können verloren gehen), die produktbezogene Zahlung (Einkaufskörbe werden nicht unterstützt) und die Unmöglichkeit der Stornierung von Zahlungen. Auf den Webseiten von eCash ([ECA99]) findet sich eine Demonstration dieses Zahlungssystems.
Das EU-Projekt CAFE (Conditional Access for Europe) ermöglicht anonymes Bezahlen mit Hilfe spezieller Hardware (Offline-Bezahlen). Das Projekt wurde 1995 beendet, seitdem fanden keine weiteren Pilottests mehr statt. Es werden elektronische Brieftaschen (Wallet) und Chipkarten (Guardians) eingesetzt. Die Wallets sind taschenrechnerartige Geräte mit Tastatur, Anzeige und nichtflüchtigem Speicher (ähnlich einem PDA) und einer Infrarot-Schnittstelle. Der Guardian stellt die Verbindung zum Bankkonto des Benutzers her, durch Abbuchung von Geld bei einer Bank bzw. über das Internet kann die Chipkarte "aufgeladen" werden.
Beim Bezahlen wird dann die Chipkarte in die Geldbörse gesteckt und je nach Ausführung der Geldbörse z. B. eine PIN verlangt, bevor die Zahlung erfolgen kann.
Heute basiert Homebanking im allgemeinen auf einer SSL-Verbindung zwischen dem Bankkunden und dem Bankserver, wobei die Kommunikation über die üblichen Formulare von Webseiten abgewickelt wird. Dies ist problematisch, denn einerseits kann ein Webserver die Identität einer Bank vortäuschen (DNS Spoofing, Kapitel 4.2), um an Kontonummer, PIN und TAN zu kommen (dies sollte theoretisch nicht möglich sein, da der Kunde das Zertifikat des Webservers überprüfen kann) und andererseits muss der Rechner des Kunden gut geschützt sein, wozu jedoch nicht alle Kunden willens bzw. fähig sind (z. B. werden PIN's und TAN's häufig auf der Festplatte gespeichert oder ein eingeschleustes trojanisches Pferd protokolliert die Tastatureingaben).
Um eine bankenübergreifende Standardlösung zu schaffen und um das lästige und unter Umständen unsichere System der Authentifizierung durch PIN und TAN aus der Welt zu schaffen, haben die Bundesverbände des Zentralen Kreditausschusses des deutschen Kreditgewerbes (ZKA) den HBCI (Home Banking Computer Interface)-Standard verabschiedet. Durch HBCI soll der volle Leistungsumfang der Kreditinstitute über öffentliche Netze, insbesondere über das Internet, zur Verfügung gestellt werden (z. B. Überweisungen, Daueraufträge oder auch Wertpapierorders). HBCI ist unabhängig von der eingesetzten Hardware, so können Verbindungen z. B. über das Internet, über eine Modemdirektverbindung oder über einen Bankterminal erfolgen. Optional können auch Chipkarten zur Schlüsselspeicherung verwendet werden.
Ein Dialog zwischen dem Kunden und dem Kreditinstitut läuft in folgenden Schritten ab:
1. | Anfang: Der Kunde baut eine Verbindung zum Rechner des Kreditinstituts auf (z. B. über das Internet oder über einen Bankterminal) |
2. | Dialoginitialisierung: Der Kunde authentifiziert sich beim Rechner des Kreditinstituts und sendet seine verfügbaren Verschlüsselungs- und Komprimierungsverfahren. Die Authentifizierung des Kunden kann auch wegfallen, damit sich z. B. Benutzer über ein Institut informieren oder Börsenkurse abfragen können. |
3. | Dialoginitialisierungsantwort: Der Bankrechner weist sich aus und antwortet mit der Festlegung der Verschlüsselungs- und Komprimierungsverfahren. Desweiteren werden die Versionen der sogenannten Userparameterdaten (UDP) und die Bankparameterdaten (BDP) abgeglichen und gegebenenfalls sendet der Bankrechner die neuesten UDP und BDP an den Kunden. In den Bank-Parameterdaten wird die Infrastruktur des jeweiligen Kreditinstitutes beschrieben, so z. B. der Name des Institutes oder zu beachtende Restriktionen (Beispiel: Anzahl der berücksichtigten Verwendungszweckzeilen bei einer Überweisung). In den User-Parameterdaten steht das Profil des jeweiligen Kunden, z. B. die Nummern seiner Konten und deren Limiten. |
4. | Auftrag: Der Kunde kann seine Aufträge geben. Er unterschreibt seinen Auftrag mit seiner digitalen Signatur oder er unterschreibt den Auftrag und überträgt ihn verschlüsselt. |
5. | Auftragsnachricht: Das Kreditinstitut meldet das Gelingen oder Nichtgelingen des Auftrags dem Kunden. |
6. | Dialogende: Der Kunde intiiert das Ende des Dialogs. |
Das Kreditinstitut kann seine öffentlichen Schlüssel (asymmetrische Signier- und Verschlüsselungsschlüssel) entweder dem Kunden direkt über ein Speichermedium mit den anderen notwendigen Daten aushändigen oder es überträgt die öffentlichen Schlüssel beim ersten Einloggen des Kunden. Damit ein Angreifer nicht die Schlüssel auf dem Weg durch das Netzwerk durch seine eigenen ersetzen kann, wird neben dem Schlüssel noch ein sog. Ini-Brief versendet. Der Ini-Brief enthält neben anderen Informationen den Hashwert des übertragenen Schlüssels und eine Unterschrift eines Mitarbeiters des Kreditinstitutes. Der Kunde kann den Schlüssel des Kreditinstitutes durch Vergleich des gesendeten Hash-Wertes mit dem von ihm erzeugten verifizieren (Kapitel 3.1.5). Er überträgt seinen öffentlichen Signierschlüssel und seinen öffentlichen Verschlüsselungsschlüssel mit einem Ini-Brief beim Einloggen über die Netzwerkverbindung an den Bankrechner. Der Kunde bestätigt seine öffentlichen Schlüssel im Ini-Brief mit seiner Unterschrift. Wenn symmetrisch verschlüsselt und signiert werden soll, werden die Schlüssel auf einer Chipkarte aufbewahrt.
Als symmetrisches Verschlüsselungsverfahren kommt 2-Key-Triple-DES und als asymmetrisches Verfahren RSA zum Einsatz. Das benutzte Hashverfahren ist RIPEMD-160.
Der HBCI-Standard ist ein offener Standard, daher können Experten ihn beurteilen und gegebenenfalls Sicherheitsmängel aufdecken. Er erfüllt die in Kapitel 2 aufgestellten Sicherheitsanforderungen, und die lästigen PIN's und TAN's werden durch die Schlüssel ersetzt. Die sicherheitsrelevanten Kundendaten können auf einer Chipkarte gespeichert werden, was zusätzlich die kundenseitige Sicherheit verbessert. Zudem ist der Standard multibankenfähig, der Kunde ist nicht auf proprietäre Einzellösungen angewiesen. Aus diesen Gründen bleibt zu hoffen, dass in absehbarer Zukunft brauchbare Produkte nach dem HBCI-Standard implementiert werden.
Inhaltsverzeichnis Kapitel 1 Kapitel 2 Kapitel 3 Kapitel 4 Kapitel 5 Kapitel 6 Literaturverzeichnis