02.06.2004 set - secure electronic transaction1 set – secure electronic transaction einführung...
TRANSCRIPT
02.06.2004 SET - Secure Electronic Transaction 1
SET – Secure Electronic Transaction
Einführung zum Protokoll und dessen Verifikation
Christian Mauro
02.06.2004 SET - Secure Electronic Transaction 2
Kreditkartenzahlung - Altes Modell
Karteninhaber Händler-Server
Hausbank KI Hausbank H
mit Glück SSLKreditkarteninfos
Bestellinfos
Gateway
02.06.2004 SET - Secure Electronic Transaction 3
Verwendete Verschlüsselungstechniken
Symmetrische Verschlüsselung in Form von DES (56 Bit)
Asymmetrische Verschlüsselung in Form von RSA (1024 Bit bzw. 2048 Bit für Root CA)
SHA-1 zur Prüfsummenbildung (160 Bit) Digitale Signatur Duale Signatur Zertifikate
02.06.2004 SET - Secure Electronic Transaction 4
Digitale Signatur
SHA-1 Privater
Signaturschlüssel
1:
1.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000
Sicherheit der Signatur
02.06.2004 SET - Secure Electronic Transaction 5
Zusammenspiel von Signatur, DES und RSA
SHA-1 Privater
Signaturschlüssel
} symmetrisch
verschlüsselt
RSA verschlüsselt mit dem
Public Key des Empfängers
Nachricht
(Digital Envelope)
02.06.2004 SET - Secure Electronic Transaction 6
Duale Signatur
SHA-1#1
#2SHA-1
SHA-1Privater
Signaturschlüssel
Empfänger 1: Nachricht 1 + Checksumme 2 + Duale Signatur
Empfänger 2: Nachricht 2 + Checksumme 1 + Duale Signatur
Alternativ: Weiterleitung über Empfänger 1
02.06.2004 SET - Secure Electronic Transaction 7
Zertifikat - Hierarchie
02.06.2004 SET - Secure Electronic Transaction 8
Typischer SET Ablauf
1. Cardholder Registration2. Merchant Registration3. Purchase Request4. Payment Authorization5. Payment Capture
02.06.2004 SET - Secure Electronic Transaction 9
Cardholder Registration
02.06.2004 SET - Secure Electronic Transaction 10
Merchant Registration
02.06.2004 SET - Secure Electronic Transaction 11
Purchase Request
02.06.2004 SET - Secure Electronic Transaction 12
Payment Authorization
02.06.2004 SET - Secure Electronic Transaction 13
Payment Capture
02.06.2004 SET - Secure Electronic Transaction 14
Verifikation der Purchase Request Phase
Mehrfach verschachtelte Verschlüsselungen und duplizierte Felder ergeben riesige Ausdrücke
Ständiges Generieren von zufälligen Nummern und Schlüsseln
Viele alternative Protokollpfade
Verifikation schwierig:
02.06.2004 SET - Secure Electronic Transaction 15
Verifikation der Purchase Request Phase
02.06.2004 SET - Secure Electronic Transaction 16
Verifikation der Purchase Request Phase
02.06.2004 SET - Secure Electronic Transaction 17
Verifikation – Theorem 1
02.06.2004 SET - Secure Electronic Transaction 18
Verifikation - Ergebnisse
Theorem 1:Ein Angreifer kann die PAN nur dann erhalten, wenn ein unseriöses Gateway involviert war.
Theorem 2:Wenn der Händler eine Authorization Response von einem seriösen Payment Gateway erhält, weiß er, dass diese vom Gateway signiert wurde; inklusive der Transaktionsnummer und des Kaufbetrags, was der Händler separat bestätigen kann.
Theorem 3:Wenn der Händler die duale Signatur von einem unmanipulierten Karteninhaber einsieht, kann er anhand der XID prüfen, dass diese für ihn bestimmt war und dass sie vom Karteninhaber erstellt wurde.
02.06.2004 SET - Secure Electronic Transaction 19
Verifikation - Ergebnisse
Theorem 4:Wenn das Payment Gateway die duale Signatur von einem unmanipulierten Karteninhaber und einem unmanipuliertem Händler einsieht, kann er prüfen, dass diese aus einer Transaktion vom gegebenen Karteninhaber und dem gegebenen Händler entstammt. Er kann zudem prüfen, dass der Händler ihn ausgewählt hat, die Transaktion zu bearbeiten.
Theorem 5:Wenn der Karteninhaber eine Purchase Response von einem unmanipulierten Händler empfängt, weiß er, dass auch wirklich der Händler diese geschickt hat. Zudem weiß er, dass der Händler eine signierte Nachricht von dem Payment Gateway erhalten hat, das der Händler zur Bearbeitung beauftragt hat.
02.06.2004 SET - Secure Electronic Transaction 20
Verifikation - Ergebnisse
Schwächen am Protokoll:a) Kein Feld, das auf Seite des Karteninhabers das Payment Gateway
spezifiziertb) Symmetrischer Schlüssel nicht Teil der PrüfsummeDies führt zu
Theorem 6:Wenn das Gateway eine dual signierte Authorisierungsanfrage erhält, weiß es,dass Karteninhaber und Händler eine Zahlungsanweisung (nicht unbedingtdie, die gerade vorliegt) für ein Gateway (nicht notwendigerweise es selbst)mit einem digitalen Briefumschlag (nicht zwingend der gerade geöffnete)zusammengestellt haben, in der sie in diversen Details übereingekommensind. Der Überweisungsbetrag kann nur vom Karteninhaber, nicht aber vomHändler eingesehen werden.Trotzdem bilden beide Parteien eine Prüfsummevon Bestellinfos und Gesamtbetrag, die das Gateway vergleichen kann.
02.06.2004 SET - Secure Electronic Transaction 21
Verifikation - Ergebnisse
• SET praktisch sicher• kleinere Schwächen, die nicht wirklich relevant sein sollten und sich zudem leicht beheben lassen• Größtes Problem: Umständliche Bedienung