Secure Electronic Transaction – Wikipedia

Secure Electronic Transaction (SET; deutsch Sichere elektronische Transaktion) ist ein Sicherheitsprotokoll für den elektronischen Zahlungsverkehr mit Kreditkarten, im Besonderen über das Internet.

SET wurde 1996 von VISA und Mastercard, unter Beteiligung von GTE, IBM, Microsoft und Netscape entwickelt.

Die Sicherheit von SET beruht auf der Verwendung von digitalen Signaturen und der Verschlüsselung der übertragenen Daten mit asymmetrischen und symmetrischen Verschlüsselungsalgorithmen. Eine Besonderheit des SET ist der Einsatz von Dualen Signaturen, um die Privatheit der Benutzer zu wahren bzw. den Datenschutz zu gewährleisten.

Aufgrund mangelnder Akzeptanz haben die Kreditkartenorganisationen in den letzten Jahren die Bemühungen zur Verbreitung von SET weitestgehend eingestellt und werben stattdessen für das 3-D-Secure-Verfahren.

In einem SET-Szenario gibt es verschiedene Teilnehmer: Kunden, die im Besitz von Kreditkarten sind, Banken und Kreditkarteninstitute der Kunden, Händler, die ihre Produkte zum Onlinekauf anbieten, die Banken der Händler sowie ein Payment Gateway, welches als Schnittstelle zwischen dem Händler und der Bank des Händlers dient. Wird nun ein Einkauf eines Kunden bei einem Händler mittels SET abgewickelt, so authentifizieren sich die Parteien untereinander mit Zertifikaten. Die Daten für den Einkauf (Bestellung, Bezahlung etc.) werden verschlüsselt übertragen, so dass nur der Teilnehmer die Information lesen kann, für den sie auch bestimmt ist (z. B. erhält die Bank des Kunden keine Information über die gekaufte Ware, nur deren Preis). Mit (dualen) Signaturen lässt sich die Echtheit und Integrität der Nachrichten nachweisen.

• PKIs und X.509-Zertifikate für Authentifikation und Schlüssel
• SHA-1 als Hashfunktion
• DES als symmetrische Verschlüsselungsfunktion
• RSA als asymmetrische Verschlüsselungsfunktion

Ziel der dualen Signatur ist wie bei der Standard-elektronischen Signatur, die Authentizität und die Integrität der Daten sicherzustellen. Bei der Dualen Signatur wird zusätzlich auf das Need-To-Know Prinzip geachtet, wenn die Nachricht für zwei (oder mehrere) Parteien gedacht ist. Hierzu werden die Nachrichtenteile so verschlüsselt, dass sie nur von der gewünschten Empfänger-Partei entschlüsselt werden kann. Damit die Signatur nun über den ganzen (Plain-)Text Gültigkeit hat, werden die angehängten Hashwerte der einzelnen Nachrichtenteile signiert. Um den Empfängern das Überprüfen der dualen Signatur zu ermöglichen, wird der Hashwert des unbekannten Nachrichtenteils seinem verschlüsselten Part hinzugefügt.

Formelmäßig:

Nachricht = Teil1 | Teil2 h1 = SHA-1(Teil1) h2 = SHA-1(Teil2) Duale_Signatur = SHA-1(h1 | h2) 

Empfänger 1 erhält: 

Msg1 = DES(Teil1 | h2) 

| steht für Konkatenation SHA-1 als Beispiel Hash-Funktion DES als Beispiel Verschlüsselung 

SET bietet, im Vergleich zu der im Internet normalerweise vorzufindenden Kreditkarten-basierten Bezahlung, viele Vorteile. Die Integrität und die Vertraulichkeit der Transaktionen werden mittels Signaturen und Verschlüsselung garantiert. Auch die Verbindlichkeit (Nicht-Abstreitbarkeit) der Transaktion ist durch die Zertifikate und Signaturen gegeben, sowie die Sicherheit, dass alle Teilnehmer authentisch sind. Ein weiterer datenschutzrechtlicher Vorteil ist die Einhaltung des Need-To-Know Prinzips mit Hilfe der dualen Signaturen.

Als problematisch darf allerdings die Festlegung der verwendeten Verschlüsselungsverfahren gesehen werden. DES gilt heute als nicht mehr ausreichend sicher und sollte nicht für die Verschlüsselung von vertraulichen Daten verwendet werden. Des Weiteren ist die Komplexität des Verfahrens sicherlich ein Hindernis bei dessen Umsetzung (der Standard umfasst über 900 Seiten). Außerdem ist fraglich, ob der notwendige Aufbau einer vollständigen Public-Key-Infrastruktur bei allen beteiligten Finanzintermediären (Banken und Kreditkartenfirmen), Händlern und Kunden Akzeptanz findet. Dies ist bis heute (Stand: 2017) nicht eingetreten.

• Ausführliche Erklärung (Memento vom 5. März 2016 im Internet Archive)
• Ausführliche Erklärung von IBM (Memento vom 4. März 2016 im Internet Archive) (PDF; 5,3 MB)