Für die symmetrische Verschlüsselung wird der DES-, für die asymmetrische der RSA-Algorithmus verwendet. Die Nutzung dieses Verfahrens ist
international allerdings eingeschränkt.
Aufgrund von U.S. Exportbestimmungen
kann der RSA-Algorithmus nur innerhalb der USA mit Schlüssellängen arbeiten, die
eine ausreichende Sicherheit bieten. International sind nur sehr kurze und damit
unsichere Schlüssellängen erlaubt. Dieses Poblem tritt bei SET nicht auf.
Zur Zeit exisiert eine erste Implementierung von SET der RSA Corp.. Deren
SET Toolkit wurde mit einer "U.S. Export Commodity Jurisdiction License"
ausgestattet, welches eine Ausfuhr der verwendeten kryptographischen Algorithmen
gestattet, und somit auch international eine sichere Schlüssellänge
gewährleistet.
Gibt die Bank ein Zertifikat heraus, muß sie überprüfen, ob die Person, die sich die Zugehörigkeit eines Schlüsselpaares zu einer Kontonummer zertifizieren läßt, hierzu auch berechtigt ist. SET sieht hier kein festes Verfahren vor. Es ist vorstellbar, daß die Bank bei der Zertifizierung Informationen vom Kartenbesitzer fordert, die nur er wissen kann. Ist die Bank sicher, daß der rechtmäßige Kontoinhaber die Registrierung wünscht, so stellt sie das Zertifikat aus und signiert dies mit Ihrem eigenen Signierschlüssel.
Zum Überprüfen, ob die Signatur der Bank gültig ist, muß dieser Schlüssel verifizierbar sein, d.h. auch die Bank benötigt ein Zertifikat, das von einer höheren Instanz ausgegeben wird. Es entsteht so ein Zertifizierungsbaum, an dessen Spitze eine Root-CA steht, deren Schlüssel nicht mehr zertifiziert ist. Dieser Schlüssel muß für jeden sichtbar von einer glaubwürdigen Instanz veröffentlich werden. Es ist vorstelbar, daß die Zertifikate der Banken von den Kreditkartengesellschaften ausgestellt werden, und diese wiederum ihre Zertifikate von einem Konsortium der Gesellschaften als Root-Instanz erhalten.
Neben Banken und Kunden erhalten auch die Händler Zertifikate, einerseits um sie als legitimierte SET-Nutzer erkennbar zu machen, andererseits um die öffentlichen Schlüssel für Verschlüsselung und Signatur bekanntgeben zu können.
Die duale Signatur entsteht auf folgende Weise:
Der Kartenbesitzer Bob erstellt eine Bestellung (Order Instruction, OI) und eine Zahlungsauthoriserung (Purchase Instraction, PI). Er bildet sowohl über der PI, als auch über der OI einen Hashwert (Hash(OI), Hash(PI). Die beiden Hashwerte werden verknüpft und über dem Ergebnis wird ein neuer Hashwert( = Dual Hash) gebildet. Diesen signiert der Kunde (signH (Dual Hash)) und die duale Signatur liegt vor.
Nun sendet er Alice zum einen die Bestellung (OI), den Hashwert der PI und
die duale Signatur. Alice kann den Hashwert über dem im Klartext übertragenen OI
erzeugen. Diesen konkateniert sie mit dem mitgeliefterten Hash(PI) und überprüft
mit dem durch Konkatentation entstandenen Hashwert die duale Signatur.
Zum
Weiterreichen an die Bank sendet er Alice eine - mit dem öffentlichen Schlüssel
der Bank verschlüsselte - Nachricht, die die PI und den Hashwert der OI
enthält.
Akzeptiert Alice die Bestellung, sendet sie diese verschüsselte
Nachricht und die duale Signatur an die Bank weiter. Diese erstellt nun den
Hashwert über der PI und überprüft mittels des mitgelieferten Hash (OI) die
duale Signatur. Es kann festgestellt werden, ob die PI auch wirklich von Bob
erstellt wurde, denn hätte Alice sie erstellt, wäre die duale Signatur falsch,
da Alice nicht über den nötigen privaten Signierschlüssel von Bob verfügt.
Da SET alle für die Kreditkarten-Transaktion nötigen Aktionen auf elektronischem Wege ermöglicht sind folgende Teilnehmer an einer SET-Transaktion beteiligt:
Bevor ein Kunde SET nutzen kann, muß er sich hierfür registrieren lassen, d. h. er erhält von einer Zertifizierungsinstanz ein Zertifikat für die von ihm verwendeten Schlüssel. In diesem Schritt muß die CA die hierfür vom Kunden erhaltenen Informationen bei der Bank des Kunden verifizieren. Dieser Schritt wird im Abschnitt Registrierung des Kunden näher beschrieben
Nun kann der Kunde im elektronischen Markt einkaufen gehen. Will er ein Produkt kaufen, tritt er mit dem Händler in Kontakt und sendet diesem die Bestellunterlagen zu. Um die Zahlung zu ermöglichen, sendet er dem Händler desweiteren die Informationen für die Zahlungsabwicklung zu. Wird der Kauf vom Händler akzeptiert, erhält er eine Bestätigung des Kaufs. Das Protokoll hierfür wird unter dem Punkt Einkauf erklärt.
Damit der Händler eine Zahlung akzeptiert, läßt er sich das Zahlungsversprechen des Kunden über das Payment Gateway verifizieren. Unter dem Punkt Zahlungsauthorisierung beschreibt die hierfür nötigen Schritte.
Als letzte Aktion beauftragt der Händler nach Auslieferung der Waren seine Bank diie Zahlung einzuziehen. Diese Aktion beschreibt der Abschnitt Zahlungsabwicklung.
Alle weiteren Aktionen zwischen den Banken finden über das schon vorhandene Bankennetz statt und werden daher von SET nicht betrachtet. Alle beschriebenen SET-Aktionen werden automatisch über entsprechende Softwarepakete bei den Teilnehmern erledigt.
Im Folgenden werden die einzelnen Protokolle vorgestellt. Zur Darstellung der versendeten Informationen wird folgendes Schema verwendet:
| signX(Data) | Die Informationen "Data" sind vom Teilnehmer X signiert |
| CryptKey(Data) | "Data" ist symmetrisch mit dem Schlüssel "Key" verschlüsselt |
| dualsignX(Data) | "Data" ist dual signiert |
| CryptPubX(Data) | "Data;" ist mit dem privaten Schlüssel des Teilnehmers X verschlüsselt |
| K | Steht für den Kunden als Index beim Signieren bzw. Verschlüsseln |
| H | Steht für den Händler |
| B | Steht für das Payment Gateway der Bank des Händlers |
| SignCertX | Zertifikat für den Schlüssel zum Signieren des Teilnehmers X |
| CryptCertX | Zertifikat für den Key-Exchange-Schlüssel des Teilnehmers X |
B A | Datenübertragung von A nach B |
In einem ersten Schritt sendet nun die Software des Kunden einen Request an die Zertifizierungsinstanz. Hierbei teilt sie mit, welchen Kreditkartentyp der Kunde verwendet, um ein entsprechendes Registrierungsformular zu erhalten. Diese Informationen werden in einen Init Request (Init Req) eingebettet. Hierfür sendet sie folgende Nachricht an die CA:
| CA Kunde | Cert Req |
Die CA wählt nun anhand des angegebenen Kreditkartentyps das entsprechende Registrierungsformular (RegForm). Um dem Kunden die Möglichkeit zu geben, die Richtigkeit des übertragenen Formulars und den Absender zu überprüfen, hängt die CA noch Ihr Zertifikat für den Signierschlüssel (SignCertCA) an und signiert beide. Damit der Kunde später das Formular vertraulich an die CA zurückschicken kann, fügt sie desweiteren das Zertifikat mit dem öffentlichen "Key-Exchange"-schlüssel hinzu.
| Kunde CA | signCA(RegForm, SignCertCA), CryptCertCA |
Der Kunde kann nun anhand des Zertifizierungsbaumes das Zertifikat der CA prüfen. Dies ist nur einmal nötig, wenn der Kunde den entsprechenden Schlüssel für spätere Benutzungen als gültig speichert. Mit diesem Schlüssel kann er nun die Signatur der CA prüfen und somit feststellen, ob das übertragene Formular unverändert bei ihm ankam und von der CA gesendet wurde.
Nun erzeugt die Software ein Schlüsselpaar zum Signieren von Nachrichten des Kunden, für das ein Zertifikat ausgestellt werden soll. Dieses benötigt er für alle späteren SET-Aktionen. Er erzeugt ein weiteres Schlüsselpaar zum Verschlüsseln von Nachrichten. Dies ist nötig, damit die CA ihm das Zertifikat vertraulich zusenden kann.
Nun füllt er das Formular aus und bettet dieses in einen Certification Request (Cert Req) ein. Er fügt diesem seinen öffentlichen Signierschlüssel (SignPubK) und den öffentlichen Verschlüsselungsschlüssel (CryptPubK) hinzu. Diese Informationen signiert er und verschlüsselt sie symmetrisch mittels eines zufälligen Schlüssels Key1. Diesen Schlüssel und seine Kontonummer AccNr (in den USA enthält dieser neben der Kontonummer auch einen Anteil, der die Bank repräsentiert) verschlüsselt er nun asymmetrisch mit dem Verschlüsselungsschlüssel der CA (CryptPubCA).
| CA Kunde | CryptKey1(signK(CertReq, SignPubK,CryptPubK), CryptPubCA(Key1, AccNr) |
Die CA entschlüsselt nun zunächst mit ihrem privaten Schlüssel Key1 und die Kontonummer des Kunden. Die Kontonummer wird vermutlich (Angaben hierüber liegen nicht vor) mitangegeben, um direkt die Information zu erhalten, zu welchem Konto die Informationen geprüft werden sollen, ohne erst im Formular den entsprechenden Eintrag zu suchen. Mit Key1 wird nun der Certification Request und die öffentlichen Schlüssel des Kunden entschlüsselt. Die CA verifiziert (z.B. mit Daten der Bank über den Kunden) die Angaben zum Konto und erstellt bei deren Richtigkeit das Zertifikat für den Signierschlüssel des Kunden, das sie mit Ihrer Signatur bestätigt. Das Zertifikat wird nun mit dem symmetrischen Schlüssel Key2 verschlüsselt und dieser wird asymmetrisch mit dem CryptPubKverschlüsselt. Hierdurch wird gesichert, daß das Zertifikat vertraulich übertragen wird.
| CA Kunde | CryptKey2( SignCertK), CryptPubK(Key2) |
Der Kunde kann nun mittels seines privaten Schlüssels Key2 entschlüsseln und hiermit sein Zertifikat entschlüsseln. Sein Zertifikat speichert er für die spätere Nutzung, den privaten Crypt-Schlüssel kann er wegwerfen, da er nicht mehr benötigt wird.
Nun ist der Kunde in der Lage einen Einkauf durchzuführen.
| Händler Kunde | InitReq |
Die Software des Händlers erzeugt für die bevorstehende Transaktion zunächst einen zufälligen Transaktions Identifier (TID), der in einen Init Response (InitResp) eingebettet wird. Dieser wird um die Integrität zu sichern, vom Händler verschlüsselt, der zur Überprüfung noch sein Signierzertifikat anfügt.
Damit die Kreditkarteninformationen des Kunden sicher über das Netz an die Bank übermittelt werden können, sendet der Händler dem Kunden das Verschlüsselungszertifikat des Payment Gateways zu, an das er sich später für die Authorisierung der Zahlung und den Zahlungseinzug wenden wird. Dieses Payment Gateway muß natürlich den entsprechenden Kreditkartentyp des Kunden bearbeiten können.
| Kunde Händler | signH( InitResp), SignCertH, CryptCertB |
Der Kunde überpüft nun zunächst die Signatur des Händlers. Ist diese gültig, erstellt er eine Bestellinformation (Order Instruction OI) für den Händler. Diese enthält die Angaben über das gewünschte Produkt und die TID. Desweiteren erstellt die Software eine Anweisung für das Payment Gateway, den Kaufbetrag für diese Transaktion (repräsentiert durch die TID) an den einreichenden Händler von seinem Kreditkartenkonto zu überweisen (Purchase Instruction PI).
Da für den Händler nur die OI und für die Bank nur die PI sichtbar sein soll, erstellt die Software nun zum Verbinden der beiden Anweisungen die duale Signatur. Hierfür erzeugt sie die Hashwerte für OI und PI jeweils mit eingefügtem Signierzertifikat des Kunden. Diese Hashwerte werden konkateniert und über dem Ergebnis wird ein weiterer Hashwert gebildet. Diesen Wert signiert der Kunde mit seinem privaten Signierschlüssel. Das Ergebnis stellt die duale Signatur dar.
Die so signierten PI wird n symmetrisch mit dem Schlüssel Key3 verschlüsselt. Diesen Schlüssel und die Kontonummer des Kunden (Acc.Nr) soll vertraulich an das Payment Gateway gesendet werden und wird deshalb asymmetrisch mit dem Puplic Encrytpion Key der Bank (den der Kunde aus dem Zertifkat der Bank entnehmen kann) verschlüsselt. Der dual signierten Order Instruction wird nun noch zum Prüfen der Signatur der Hashwert der - für den Händler nicht lesbaren - PI hinzugefügt.
| Händler Kunde | dualsignK( OI, SignCertK),hash(PI), CryptKey3(dualsignK(PI, SignCertK)), CryptPubB(Key3, Acc.Nr) |
Der Händler prüft nun zunächst die duale Signatur der für ihn bestimmten Order Instruction, in dem er aus der OI den Hashwert bildet, diesen mit dem mitgelieferten hash(PI) konkateniert und das Ergebnis erneut "hasht". Nun wendet er den öffentlichen Signierschlüssel des Kunden auf die duale Signatur an und vergleicht das Ergebnis mit dem erzeugten Haswert. Stimmen diese Hashwerte überein, so ist die Signatur geprüft.
Er sendet nun die verschlüsselte PI weiter an das Payment Gateway zur Authorisierung der Zahlung. Erhält er eine positive Antwort, sendet er dem Kunden eine signierte Kaufbestätigung (Purchase Response PurchResp) zu und kann nun die Ware ausliefern. Den Einzug des Kaufbetrag kann er dann später über das Payment Gateway abwickeln (siehe Zahlungseinzug )
| Kunde Händler | signH( Purch.Resp., SignCertH) |
Der Kunde erhält nun die Bestätigung, daß die Transaktion getätigt ist und kann auf den Eingang der Ware warten.
Hierzu sendet er nun zum einen die vom Kunden erhaltene PI an die Bank weiter. Desweiteren erzeugt er einen Authorisization Request (AuthReq), in den er den Kaufbetrag der Ware, die ID der Transaktion, den Hashwert der Order Instruction (für die Überprüfung der dualen Signatur bei der Bank) und weitere Informationen zur Transaktion einbettet. Zusätzlich fügt er seine beiden Zertifikate hinzu und signiert alles. Um diese Information vertraulich zur Bank zu senden, verschlüsselt er diese symmetrisch mit dem zufälligen Schlüssel Key4 und diesen dann asymmetrisch mit dem Bankschlüssel.
| Bank Händler | PI des Kunden:
CryptKey3(dualsignK(PI, signCertK)),
CryptPubB(Key3, Acc.Nr) CryptKey4(AuthReq, SignCertH, CryptCertH), CryptPubB(Key4) |
Die Bank entschlüsselt nun zunächst den Authorisation Request, und kann anhand der Signatur den absendenden Händler erkennen. Dann entschlüsselt sie die PI des Kunden und prüft die duale Signatur. Ist diese korrekt, und stimmen die vom Kunden angegebenen Informationen zu TID und Betrag mit denen des Händlers überein, so sendet sie über das Bankennetz die PI zur Prüfung der Angaben an die Bank des Kunden (die aus der übermittelten Kontonummer ersichtlich ist) weiter. Dies geschieht über das Bankennetz und ist somit nicht Gegenstand des SET Protokolls. Wird die Anfrage bestätigt, so ist gewährleistet, daß die Rechnung zu einem späteren Zeitpunkt beglichen werden kann.
Das Payment Gateway erzeugt nun eine Authorisation Response (AuthResp), die den Händler über die Verifizierung der PI unterrichtet. Diese wird vom Gateway signiert und dem Kunden verschlüsselt zugesandt (mit symmetrischen Key5). Um die spätere Abwicklung zu erleichtern, kann die Bank nun noch ein sogenanntes Capture Token (CapToken) mitsenden, das alle Angaben für einen späteren Zahlungseinzug beinhaltet. Dieses stellt den Anspruch des Händlers auf Einzug des Rechnungsbetrags vom Konto des Kunden dar. Da dieses wieder vom Händler an die Bank gesendet wird, verschlüsselt die Bank es so, daß nur sie es wieder lesen kann und verwendet hierfür den symmetrischen Schlüssel Key6.
| Bank Händler | CryptKey5(signB(AuthResp, SignCertB), CryptPubH(Key5); CryptKey6(CapToken), CryptPubB(Key6) |
Der Händler kann nun aus der Authorization Responce die Gültigkeit des Zahlungsversprechens des Kunden erkennen und speichert den Capture Token für den späteren Zahlungseinzug, der im nächsten Kapitel beschrieben wird.
| Bank Händler | CryptKey7(signH(CapReq, SignCertH,
CryptCertH),
CryptPubB(Key7) CryptKey6(CapToken), CryptPubB(Key6) |
Die Bank entschlüsselt Capture Request und Capture Token, prüft die Signaturen und leitet bei Übereinstimmung aller Werte die Überweisung des Rechnungsbetrags vom Konto des Kunden auf das Händlerkonto ein. Dies ist ein Vorgang der generell bei Kreditkartentransaktionen nötig ist, und ist somit nicht speziell für SET spezifiziert. Ist dies geschehen, unterrichtet er den Händler über den Zahlungseinzug mittels einer Capture Response (CapResp), die er verschlüsselt an den Händler sendet.
| Händler Bank | CryptKey8(signB(CapResp, SignCertB)), CryptPubH(Key8) |
Der Händler entschlüsselt die Nachricht und prüft die Signatur und speichert die Capture Response, bis der Betrag endgültig auf seinem Konto verbucht wird.