Robert Rex Proseminar Electronic Banking Protokolle bei Kreditkarten Seite 1 von 5

Transkript

1 Protokolle bei Kreditkarten Seite 1 von 5 1. Einführung Mit der Entwicklung des Internets in den letzten Jahrzehnten hat auch die Bedeutung des E- Commerce immer mehr zugenommen. Um online bestellte Waren auch online bezahlen zu können, (und nicht den Umweg über klassische Bezahlsysteme, wie zum Beispiel Überweisungen zu gehen) ist es notwendig, Ersatzsysteme zur Hand zu haben, die den Anforderungen der Kunden, Händler und Banken gerecht werden. 1.1 Kreditkarten Seit Mitte der 60er Jahre gibt es Kreditkarten. Die Bezahlung mit diesem System erfolgt relativ einfach: Der Karteninhaber erteilt seiner Bank den Auftrag, bei einem Händler seine Schulden zu begleichen. Der Händler lässt sich dann das ihm zustehende Geld durch Vorlage eines Belastungsbeleges auszahlen. Ein solcher Beleg ist nur gültig, wenn: er vom Kunden unterschrieben wurde, oder die geheime 16-stellige PIN vom Kunden eingegeben wurde. Kreditkarten können auch im Internet eingesetzt werden. Im Allgemeinen sieht das Bezahlen damit noch so aus, dass der Kunde seine Kreditkartendaten zuzüglich einiger Validierungsdaten (Adresse des Besitzers, Gültigkeit der Karte) angeben muss. Durch Abgleich der Daten mit der Bank kann der Händler die Richtigkeit der Daten überprüfen, jedoch Missbrauchsfällen nicht vorbeugen. Die Vorteile des Online-Bezahlens (schnelle unkomplizierte Bezahlung) müssen gegen die Nachteile (Möglichkeit des Ausspähens von Kreditkarteninformationen, fehlende Anonymität) aufgewogen werden. 2. Sichere Übertragung von Daten im Internet mit SSL Da die vertraulichen Daten bei einer Kreditkartentransaktion im Internet geschützt werden müssen, werden kryptographische Verfahren bei der Übertragung eingesetzt. Um allgemein den sicheren Transport von Daten zwischen verschiedenen Computern zu gewährleisten, wurde von Netscape im Jahre 1994 SSL (Secure Socket Layer) entwickelt. Der Nachfolger des Standards SSL 3.0 TLS 1.0 weist nur geringe und damit vernachlässigbare Unterschiede zu der hier vorgestellten Methode auf. 1 Wie der Name schon sagt, ist SSL eine Schicht (Layer), die zwischen anderen Protokollen eingeschoben wird. Alles, was über SSL steht, ist geschützt. Das bedeutet gleichzeitig, dass auch andere Anwendungsdaten hiervon profitieren können. Abb. 1: SSL arbeitet über TCP/IP, und unter der Anwendungsschicht. 2 1 jedoch reichen diese geringen Unterschiede schon aus, um beide Standards inkompatibel zueinander zu machen 2 aus:

2 Protokolle bei Kreditkarten Seite 2 von Verbindungsaufbau zwischen 2 Rechnern mit dem SSL-Protokoll Um eine SSL-geschützte Verbindung zwischen 2 Computern herzustellen, muss ein Rechner als Client und der andere als Server arbeiten. Es bietet sich an, den Kundenrechner als Client, und den Händlerrechner als Server laufen zu lassen. Der Client startet dann die Verbindungsanfrage mit einem client hello. Im Folgenden ist nun der schematische Aufbau des sogenannten Handshakes, also des Herstellens einer gesicherten Verbindung mit SSL gezeigt: 1. Der Client schickt seine SSL-Version, die unterstützten Cipher-Suites 3 und 28-Byte Zufallszahlen an den Server. 2. Der Server antwortet mit seiner SSL-Version, seinen unterstützten Cipher-Suites, Zufallsdaten und seinem Zertifikat. Optional kann er ein Zertifikat des Clients anfordern. Weiterhin richtet er eine eindeutige Verbindungsnummer zur Kommunikation mit dem Client ein. 3. Der Client prüft das Zertifikat des Servers auf den Gültigkeitszeitraum, die Vertrauenswürdigkeit des Ausstellers, die digitale Signatur und den Domainnamen. Aus den verfügbaren Daten wird der sogenannte Premaster Secret erstellt, mit dem öffentlichen Schlüssel des Servers verschlüsselt und an den Server gesandt. 4. Der Server entschlüsselt den Premaster Secret mit seinem Private Key, und stellt aus diesem den Master Secret her. Der Client erstellt ebenfalls den Master Secret, welcher dann den Schlüssel für das eingesetzte Verschlüsselungsverfahren bildet. Weiterhin wird auf der Client- Seite entschieden, welche Sicherheitsalgorithmen nun zum Einsatz kommen. 5. Jetzt schicken sich beide Seiten Daten zu, die schon vorher ausgetauscht worden, allerdings jetzt mit dem Master Secret verschlüsselt. Damit können Client und Server überprüfen, ob auf der anderen Seite auch derselbe Schlüssel erzeugt wurde. 6. Danach bestätigen beide Seiten, dass ab sofort alle Daten mit dem Master Secret verschlüsselt werden. Der Handshake ist damit beendet und die Verbindung aufgebaut. 2.2 Das Record-Protokoll Das Record-Protokoll stellt die unterste Ebene von SSL dar. Alle gesendeten Daten (auch die des Handshakes) lassen sich in das folgende Schema einordnen: Content Type: Hier ist das nächsthöhere Protokoll angegeben, mit dem die Daten des Fragments weiterverarbeitet werden sollen. Major Version & Minor Version: Gibt die Version des verwendeten SSL an. Compressed Length: Gibt die Länge der nun folgenden verschlüsselten Nachricht an. 4 MAC: (message authentication code) Dient als Signatur, und liegt ebenfalls verschlüsselt vor. Abb. 2: Aufbau einer SSL-Nachricht 5 3 als Cipher-Suite wird die Zusammenfassung der verfügbaren Schlüsselaustauschalgorithmen (, DSS), Verschlüsselungsalgorithmen (DES, 3DES) und MAC-Funktionen (MD5, SHA1) bezeichnet 4 in SSL können die Daten auch komprimiert werden. In der Spezifikation dieses Standards ist aber nur die NULL-Komprimierung spezifiert, was keiner Komprimierung entspricht.

3 Protokolle bei Kreditkarten Seite 3 von Fazit bei der Nutzung von SSL im Zusammenspiel mit Kreditkartenzahlungen Durch die Benutzung von SSL wird effektiv verhindert, dass Kreditkartendaten auf dem Weg vom Sender zum Empfänger verändert oder abgehorcht werden können. Jedoch reicht dies in der Regel als Sicherheit nicht aus, da sich: 1. der Kunde nicht sicher sein kann, was auf Seiten des Händlers mit seinen Daten passiert, und 2. der Händler nicht nachvollziehen kann, ob der Kunde der rechtmäßige Inhaber der Kreditkarte ist. 3. SET Um die Nachteile von SSL bei Kreditkartenzahlungen im Internet zu beheben, wurde 1996 das SET- Protokoll (Secure Electronic Transaction) entwickelt, welches genau auf diese Form der Bezahlung zugeschnitten ist. Es bietet folgende Eigenschaften: sichere Identifizierung des Kunden und des Händlers Einsicht der Daten nur an den vorgesehenen Stellen (Bank, Händler) Bindung einer Zahlung an eine Bestellung, sowie Bindung des Kunden an die Zahlung 3.1 Zertifikate bei SET Um die Vertrauenswürdigkeit der beteiligten Stellen bei einer SET-Transaktion im Internet sicherzustellen, gibt es hier für jede Seite ein Zertifikat. Dieses Modell wird als Hierarchy of Trust bezeichnet, und enthält folgende Komponenten: Root-CA-Certificate Selbstzertifikat des Zertifizierungsstelle (Certificate Authority) Cardholder Certificate: Zertifikat des Karteninhabers; von der Bank bzw. einer beauftragten CA ausgestellt; enthält Hash-Wert der Kartendaten und eines geheimen Wertes Merchant Certificate: von Bank des Händlers ausgestellt bestätigt Recht des Händlers zur Abwicklung von Zahlungen einer bestimmten Kreditkartenmarke Payment Gateway Cert.: Zertifikat des Payment Gateways 6 Aquirer Certificate: Zertifikat der Bank des Händlers Issuer Certificate: zur Zertifizierung der Bank des Kunden 3.2 Grundlegende Komponenten Zur Funktion von SET sind drei wichtige Komponenten erforderlich: Wallet: dient als die elektronische Brieftasche des Kunden. Diese Anwendung führt die SET-Transaktion auf Seiten des Karteninhabers durch Merchant Server: auf Händlerseite als Online-Kasse eingesetzt. Nimmt die Zahlungsanweisungen des Kunden entgegen, und gibt diese an den Aquirer weiter. Payment Gateway: der Payment Gateway bildet die Schnittstelle zwischen dem internen Bankennetzwerk und dem Internet. Er wird vom jeweiligen Aquirer betrieben, um Zahlungsanweisungen vom Merchant Server entgegenzunehmen. 5 aus: 6 Als Payment Gate wird die Schnittstelle zwischen dem internen Bankennetzwerk und dem Internet bezeichnet. Der Aquirer, also die Bank des Händlers, zeichnet sich hierfür verantwortlich. (Näheres dazu siehe 3.2)

4 Protokolle bei Kreditkarten Seite 4 von Erstellung des Cardholder Certificate Im Folgenden ist die Zertifizierung des Kunden dargestellt: 1. Der Kunde schickt ein Initiate-Request an die Zertifizierungsstelle (z.b. seine Bank), und bekommt daraufhin das Zertifikat der CA zugesandt. 2. Jetzt werden die Zertifikatssignaturen bis zum Root-Zertifikat zurückverfolgt; bei erfolgreicher Beendigung dieses Vorgangs schickt der Kunde ein Registration Form Request an die CA; dieses beinhaltet einen zufälligen symmetrischen Schlüssel sowie die mit dem symmetrischen Schlüssel verschlüsselte Kreditkartennummer. Diese Daten werden mit dem Public-Key der CA verschlüsselt 3. Die CA macht die Verschlüsselungen wieder rückgängig und ermittelt anhand der ersten Ziffern der Kreditkartennummer die Bank des Kunden und schickt das richtige Registrierungsformular mit Signierung zurück. 4. Der Kunde erstellt jetzt ein Private-Public-Schlüsselpaar für sich. Den Public-Key und das ausgefüllte Registrierungsformular verschlüsselt er mit einem neuen symmetrischen Schlüssel, welcher wiederum mit dem Public-Key der CA verschlüsselt ist. 5. Die CA lässt sich nun vom Kreditinstitut des Kunden den Antrag bestätigen und erstellt danach ein Zertifikat für den Kunden, welches einen Hashwert der Kartendaten und eines nur dem Karteninhaber bekannten Wertes enthält. Die vom Kunden benötigten Daten sind bei SET nicht spezifiziert. Nur der Ablauf der Registrierung ist fest vorgeschrieben. Die Registrierung des Händlers erfolgt nach ähnlichem Muster. Auch hier ist nur der Ablauf der Registrierung vorgegeben. 3.4 Ablauf eines Bezahlvorganges mit SET Nachdem sich alle beteiligten Instanzen registriert haben, kann ein Kauf getätigt werden. Der Kunde sucht sich zunächst die gewünschten Waren oder Dienstleistungen vom Händler heraus, und beginnt dann mit dem eigentlichen Kaufvorgang nach SET-Spezifikation. 1. Der Kunde sendet ein Initiate-Request an den Händler. 2. Der Händler weist jetzt dem Vorgang eine eindeutige Transaktionsnummer zu, und sendet sein eigenes Zertifikat, als auch das Zertifikat des Payment-Gateways an den Kunden. 3. Dieser prüft die Zertifikate, stellt die Bestellinformationen (Order Informations = OI) und die Zahlungsanweisungen (Payment Instructions = PI) zusammen und verknüpft beide mit der zugewiesenen Transaktionsnummer. Der Kunde erstellt weiterhin einen zufälligen symmetrischen Schlüssel, mit dem er die PI verschlüsselt. Der Schlüssel selbst wird mit dem Public-Key des Payment-Gateways kryptografisch gesichert. Als Signatur der jetzt zu sendenden Daten (OI, verschlüsselte PI, symm. Schlüssel), die jetzt mit dem Public-Key des Händlers geschützt werden, wird das Konzept der dualen Signatur benutzt (siehe 3.5). 4. Der Händler überprüft jetzt die OI und sendet die verschlüsselte PI sowie den dazugehörigen Schlüssel weiter an den Payment Gateway. Von dort wird die Prüfung der Kundendaten durch das bankeninterne Netz durchgeführt, und bei erfolgreichem Abschluss das OK an den Händler gesendet. 5. Der Händler schickt dann an dem Kunden die Mitteilung, dass die Bestellung akzeptiert ist. 3.5 Duale Signaturen Um die Daten des Kunden nur an die gewünschten Instanzen weiterzugeben - Bestellinformationen an den Händler, Zahlungsinstruktionen an die Bank wird bei SET das Konzept der dualen Signatur benutzt. Der Kunde allein kennt sowohl PI als auch OI, und kann beiden jeweils einen Hash-Wert, nämlich H(PI) und H(OI) zuordnen. Er konkateniert diese Werte, und erstellt daraus nochmals einen Hashwert, also H( H(PI) & H(PI) ) = H3. Dann fügt er noch das Ergebnis der Funktion H(PI) XOR H(OI) an. Die duale Signatur besteht jetzt aus H3 und H(PI) XOR (OI).

5 Protokolle bei Kreditkarten Seite 5 von 5 Unter Kenntnis der Erstellung des Hashwertes von PI kann jetzt die Bank unter Verwendung des Ergebnisses der XOR-Funktion (dieses liegt den PI bei) H3 überprüfen, ohne in Kenntnis von OI zu sein. Nach demselben Schema kann der Händler die Richtigkeit der Signatur prüfen. 3.6 Autorisierungsanfrage & -antwort Wie bereits in 3.4 gezeigt, lässt der Händler vom Payment-Gateway eine Prüfung der Daten des Kunden vornehmen. Er schickt dazu die für ihn unlesbare, verschlüsselte PI an seine Bank ( Aquirer ). Diese entschlüsselt diese Informationen mit ihrem Private-Key, und sendet eine Autorisierungsanfrage an das interne Bankennetzwerk. Falls diese positiv ausfällt, so kann der Händler zwischen 2 Möglichkeiten wählen: 1. er lässt den Betrag direkt auf sein Konto gutschreiben, oder 2. seine Bank schickt ihm ein Capture-Token, welches mit ihrem eigenen Public-Key verschlüsselt ist, so dass nur sie es wieder lesen kann. Dieses Token kann dann der Händler als Einlösungsgutschein verwenden für die bereits autorisierte Zahlung. 4. Fazit Sicherheitsmechanismus Algorithmus Standard Schlüssellänge Signatur Duale Signatur Datenverschlüsselung Hashing Asymm. Verschlüsselung Zertifikate DES SHA PKCS 7 - PKCS 7 SHA-1 PKCS 1 X.509 v 3 56 Bit 768- Tabelle 1. Eingesetzte Algorithmen und Mechanismen bei SET 7 Bei der Bezahlung mit Kreditkarten im Internet ist eindeutig SET der Vorrang zu geben. SSL schützt nur den Übertragungsweg der sensiblen Kreditkartendaten, verhindert aber keinen Missbrauch, wenn z. B. auf Händlerseite keine Sicherheit der Daten gewährleistet werden kann. SET dagegen stellt ein spezielles Konzept für kreditkartenbasierte Zahlungen dar, welches den Händler und den Kunden eindeutig authentifiziert, sowie die Bestell- und Kreditkarteninformationen voneinander trennt. Quellenangaben Netscape: SSL 3.0 Specification : Introduction to SSL : SET Secure Electronic Transaction LLC: Christian Weissengruber: Beteiligte Komponenten bei SET Transaktionen (Teil 2) : Markus Repges: Einführung in SSL : 7 aus: