(ikp = i-key-protocol, i=1,2,3)

Transkript

1 (ikp = i-key-protocol, i=1,2,3) Lehrveranstaltung E-Business-Kommunikation Fachhochschule Bonn-Rhein-Sieg, Prof. Dr. M. Leischner SS 2004 Quelle: Mihir Bellare, Juan A. Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Michael Steiner, Gene Tsudik, Els Van Herreweghen, and Michael Waidner: Design, Implementation, and Deployment of the ikp Secure Electronic Payment System. IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL Allgemeines Modell der Kartenzahlung / Beteiligte Payment System Provider Kartenemittent (Issuer) Clearing-Protokoll Händlerbank (Acquirer) off-line ikp-protokoll Käufer (Buyer) ikp-protokoll Verkäufer (Seller)

2 Anforderungen der Händlerbank (Acquirer) A1: Verbindliche Transaktionsautorisierung durch den Käufer A1a: schwacher Beweise (mittels schwacher Authentisierung) A1b: unabstreitbarer Beweis (mittels starker Authentisierung) A2: Verbindliche Transaktionsautorisierung durch den Verkäufer Anforderungen des Verkäufers (Seller) S1: Verbindliche Transaktionsautorisierung durch den Acquirer S2: Verbindliche Transaktionsautorisierung durch den Käufer

3 Anforderungen des Käufers (Buyer) B1: Unautorisierte Zahlungstransaktionen sind nicht möglich B1a: Unmöglichkeit unter der Voraussetzung, dass der Acquirer vertrauenswürdig ist B1b: Schlichtbarkeit, auch wenn der geheime Schlüssel des Acquirers kompromittiert ist B2: Verbindliche Transaktionsautorisierung durch den Acquirer (nicht unbedingt notwendig) B3: Authentisierung und Zertifizierung des Verkäufers durch den Acquirer B4: Verbindliche Bestätigung (Quittung) vom Verkäufer weitere Anforderungen: B5: Datenschutz (Privacy) B6: Anonymität ikp mit i {1,2,3} i=1 : 1KP-Protokoll Nur der Acquirer besitzt ein Schlüsselpaar für Signatur und Verschlüsselung. Sehr einfache PKI Karteninhaber werden anhand ihrer Kreditkartennummer und optional einer PIN authentifiziert i=2 : 2KP-Protokoll Zusätzlich besitzt der Seller ein Schlüsselpaar für Signatur einfache PKI i=3 : 3KP-Protokoll Auch der Buyer besitzt ein Schlüsselpaar für Signatur Aufwendige PKI (Zertifikate für Acquirer, Seller und insbes. Buyer)

4 Schlüssel und Funktionen PK X der Public Key von X mit X {CA, A, S, B} SK X der Secret Key von X mit X {CA, A, S, B} Cert X das Zertifikat zum Public Key von X mit X {CA, A, S, B} unterschrieben durch eine Certification Authority CA, H(.) eine stark kollisionsresistente Hashfunktion H k (K,. ) eine kollisionsresistente Hashfunktion mit zwei Argumenten, die 'unabhängig' voneinander sind. z.b. H k (K,. ) = HMAC (Hashed Message Authentication Code) = H(K, H(K,. )) E X (.) Verschlüsselung mit dem Public Key PK X mit X {CA, A, S, B} S X (.) Unterschreiben mit dem Secret Key SK X mit X {CA, A, S, B} R X SALT X von X erzeugte Zufallszahl von X erzeugte Zufallszahl zum Salzen von Nachrichten Abkürzungen BAN DESC EXPIRATION PIN SLIP T Preisbetrag der gekauften Produkte und Währung Buyer's Account Number (Kreditkartennummer) Datum (des Verkäufers) Beschreibung des Einkaufs (Produkte, Lieferadresse des Käufers). Enthält auch Name der Kreditkarte, Währung. Gültigkeitszeitsdatum der Kreditkarte Identifikator des Buyers (transaktionsabhängig) Identifikator des Sellers (gegenüber dem Acquirer) Zufallzahl, die in Kombination mit zur eindeutigen Transaktionsidentifizierung beim Acquirer dient. Geheimzahl der Kreditkarte Payment Slip (Einzahlungsschein) Transaktionsidentifikationsnummer des Verkäufers. Wird benötigt, um die Transaktion schnell und eindeutig einem bestimmten Kontext zuzuordnen

5 Grundsätzlicher Protokollablauf für ikp (i {1,2,3}) Buyer Seller Acquirer Initiate Invoice (Rechnungsstellung) Initialisierung Payment (Zahlung) Authorization Request Zahlung Autorisierung out of scope Kreditkarteninstitut Authorization Response Autorisierungsbestätigung Confirm Bestätigung an den Kunden Startinformationen beim 3KP-Protokoll Buyer Seller Acquirer CERT CA durch Seller während Protokollablauf CERT CA CERT CA PK CA PK CA CERT A, PK A CERT A BAN EXPIRATION PIN DESC DESC vorab durch Tradingprotokoll

6 Buyer vor Initiate Protokollelement (PDU) BAN H k hash = H k ( R B, BAN) R B Zufälliger Identifikator des Buyers (auch bei gleichem Pseudozufallsgenerator auf einer Chipkarte verschieden!) für den Seller zum Salzen der Nachrichten (gegen Replay) SALT B SALT B an den Verkäufer Initiate flow Käufer Verkäufer Vermittler, SALT B

7 Seller nach Initiate vor Invoice - Berechnung H(COMMON)=h 1 initiate SALT B hierdurch wird auch h1 gesalzen Hash H k H K, DESC) COMMON DESC initiate Hash H H(COMMON)=h 1 Sicht des Sellers auf die Transaktion mit Bezug zum Buyer Seller vor Invoice - Berechnung der Invoice-PDU Invoice-PDU Clear H(COMMON)=h 1 CERT A kann (als Service) hinzugefügt werden an den Buyer

8 Invoice flow Käufer Verkäufer Vermittler, SALT B Clear Initialisierung Buyer nach Invoice vor Payment - Berechnung H(COMMON)=h 2 Zuerst Überprüfung des Wertes SALT B DESC Hash H k H K, DESC) COMMON Hash H,... H(COMMON)=h 2

9 Buyer nach Invoice vor Payment - Vergleich der H(COMMON)-Werte H(COMMON)=h 2 H(COMMON)=h 1 H K, DESC) =? H K, DESC) insbesondere: DESC =? DESC =? Ergebnis: gleiche Sicht auf Transaktion Buyer nach Invoice vor Payment - Generierung des Einzahlungsscheins H(COMMON)=h 1 =h 2 verschlüsseln mit Public Key Acquirer PK A Payment-PDU BAN R B SLIP E A (.) EncSLIP PIN zum Schutz der PIN EXPIRATION schwache PIN-Authentisierung an den Seller

10 Payment flow Käufer Verkäufer Vermittler, SALT B Clear Initialisierung EncSLIP Zahlung Authorisation-Request flow Käufer Verkäufer Acquirer, SALT B Clear Initialisierung EncSLIP Zahlung Clear, H K, DESC), EncSLIP Authorisierung

11 Acquirer nach Authorisation-Request - ikp-pdu-daten Clear H K, DESC) SLIP H(COMMON)=h 1 =h 2 BAN R B H(COMMON)=h 1 PIN EXPIRATION Acquirer nach Authorisation-Request 1. Extrahierung der Werte, T,, aus Clear Überprüfung der Einzigartigkeit der Transaktion 2. Entschlüsselung des Wertes EncSLIP mit Hilfe des privaten Schlüssels SK A. Überprüfung, ob Entschlüsselung möglich. Secret Key Vermittler SK A EncSLIP DECRYPT SLIP Transaktion ungültig

12 Acquirer nach Authorisation-Request 3. Vergleich von h 1 und h 2 aus Clear H(COMMON)=h 1 =? falls gleich, dann haben Buyer und Seller gleiche Sicht auf Order Information H(COMMON)=h 2 aus EncSlip = Sicht des Buyers Acquirer nach Authorisation-Request 4. Neuformulierung von H(COMMON)= h 3 BAN H K, DESC) COMMON H k hash Hash H R B H(COMMON)=h 3

13 Acquirer nach Authorisation-Request H(COMMON)=h 1 H(COMMON)=h 3 H K, DESC) =? H K, DESC) falls gleich, dann wurde h 1 = h 2 aus Acquirersicht richtig gebildet Authorisation über Kreditkarteninstitut (out of ikp-scope) Käufer Verkäufer Acquirer, SALT B Clear Initialisierung EncSLIP Clear, H K, DESC), EncSLIP Zahlung Autorisierung BAN, EXPIRATION, PIN RESPCODE Kreditkarteninstitut

14 Acquirer vor Authorization Response signieren mit Secret Key Acquirer SK A Authorization Response-PDU RESPCODE S A (.) Sig A = S A (RESPCODE, H(COMMON)) Sig A H(COMMON)=h 3 RESPCODE an den Seller Autorisierung über Kreditkarteninstitut (out of ikp-scope) Käufer Verkäufer Acquirer, SALT B Clear Initialisierung EncSLIP Clear, H K, DESC), EncSLIP Zahlung Autorisierung BAN, EXPIRATION, PIN RESPCODE Kreditkarteninstitut RESPCODE, Sig A Autorisierungsbestätigung

15 Bestätigung vom Verkäufer an den Kunden: Confirmation flow Verkäufer überprüft die digitale Signatur Sig A des Vermittlers Sendet RESPCODE, Sig A an Kunden Autorisierung über Kreditkarteninstitut (out of ikp-scope) Käufer Verkäufer Acquirer, SALT B Clear Initialisierung EncSLIP Clear, H K, DESC), EncSLIP Zahlung Autorisierung BAN, EXPIRATION, PIN RESPCODE Kreditkarteninstitut RESPCODE, Sig A Autorisierungsbestätigung RESPCODE, Sig A Bestätigung an den Kunden

16 Sicherheitsbetrachtungen A1 (Autorisierung durch den Buyer): schwach nur durch PIN, Herausfischen gültige SLIP, dann Einsetzen verschiedener PINs in synthetische SLIP lässt keine Rückschlüsse auf PIN zu. Durch Überprüfung von DESC in H(COMMON) kann Lieferadresse nicht verbogen werden. Buyers SLIP kann nicht abgefangen und für anderen Einkauf verwendet werden, da Orderbeschreibung über H(COMMON) durch Acquirer überprüft wird. Replay von SLIP durch Seller wird über (, NONCE) entdeckt. S1b (Autorisierung durch Acquirer): durch Signatur und Einschluss von H(COMMON) in Authorisation Flows B1a (Unautorisierte Zahlungen) --> A1 B2b (Autorisierung durch Acquirer) --> S1b B5 (Pricvacy): teilweise durch gesalzene DESC