DE29824106U1

DE29824106U1 - Sicheres Transaktionssystem

Info

Publication number: DE29824106U1
Application number: DE29824106U
Authority: DE
Original assignee: Barclays Bank PLC
Current assignee: Barclays Bank PLC
Priority date: 1998-06-10
Filing date: 1998-09-23
Publication date: 2000-07-13
Anticipated expiration: 2008-09-24
Also published as: GB9812520D0; WO1999064995A1; GB2338381A; AU9175798A; CA2299294A1; JP2002517869A; CN1266520A

Description

PCT/GB98/02868 - Barclays Bank PLC - J00040778DE - DEG*-37736 * * * "

Sicheres Transaktionssystem

Technisches Gebiet

Die vorliegende Erfindung bezieht sich auf ein sicheres Transaktionssystem, insbesondere zur Verwendung über ein öffentliches Netz.

Stand der Technik

Das üblichste und bekannteste öffentliche Datennetz ist das Internet, das der Öffentlichkeit Netzzugang bei geringen Kosten vermittelt. Viele Arten kommerzieller Transaktionen, die früher über Telefon, Brief oder private Netze abgewickelt wurden, lassen sich nun einfacher über das Internet durchführen. Internetprotokolle, etwa TCP/IP, wurden jedoch nicht für Sicherheit entwickelt, weshalb es notwendig ist, zusätzliche Protokolle für sichere Transaktionen über das Internet zu schaffen, zu denen Protokolle auf dem Transportniveau, etwa Secure Sockets Layer (SSL), und solche auf dem Anwendungsniveau, etwa Secure Hypertext Transfer Protocol (SHTTP), gehören. Diese Protokolle haben zum Ziel, das Abfangen, Entschlüsseln und Fälschen von Transaktionen zwischen Kunde und Server über das Internet zu verhindern; sie verifizieren aber nicht die Identität des Benutzers des Kunden-Endgerätes. So brauchen beispielsweise bei einer Kreditkartentransaktion nur Name und Adresse des Benutzers sowie Kartennummer und -Verfallsdatum angegeben zu werden, um Waren oder Dienstleistungen über das Internet zu bestellen. Es ist verhältnismäßig einfach, sich die erforderlichen Informationen zu verschaffen, um betrügerische Transaktionen über das Internet auszuführen. Zwar wird üblicherweise eine gewisse Verifizierung der Benutzeridentität auf dem Anwendungsniveau erreicht, etwa durch die Verwendung von Paßwörtern, doch können auch diese leicht beschafft oder erraten werden.

Dennoch sind verschiedene Protokolle vorgeschlagen worden, um sichere Transaktionen, insbesondere sichere Zahlung, über das Internet zu ermöglichen. Ein Beispiel dafür besteht in Secure Electronic Transaction (SET), einem Protokoll für Kreditkartentransaktionen über das Internet, von dem eine Variante in WO 97/41539 beschrieben ist. Typischerweise gehören zu derartigen Transaktionen drei Teilnehmer: ein Kunde, der Einzelheiten der Kreditkarte mitteilt, ein von einem Anbieter von Waren oder Dienstlei-

stungen betriebener Dienstprovider-Server und ein Autorisierserver, der die Einzelheiten der Kreditkarte prüft und den Dienstprovider-Server dahingehend informiert, ob Zahlung durch den Betreiber des Kreditkartensystems autorisiert ist.

Herkömmliche elektronische Transaktionssysteme unterstützen aber positive Anerkennung; anders gesagt, vermitteln sie nicht genügend Aussage, um zu bestätigen, daß eine bestimmte Transaktion autorisiert wurde.

Darüberhinaus binden herkömmliche elektronische Transaktionen einen bestimmten Anwender nicht an die Benutzung einer Autorisierkarte.
Ferner sind herkömmliche elektronische Transaktionssysteme in ihrem Anwendungsbereich begrenzt, da der Autorisierserver lediglich so ausgelegt ist, daß er eine autorisierende oder ablehnende Nachricht aufgrund der zugeführten Einzelheiten abgibt.

Darstellung der Erfindung

Gemäß einem Aspekt vermittelt die vorliegende Erfindung ein elektronisches Transaktionssystem, bei dem ein Endgerät für eine laufende Transaktion einmalige Transaktionsdaten mit für das betreffende Endgerät einmaligen Endgerätedaten zu einer Endgerät/Transaktions-Verbundinformation kombiniert, die an den Transaktionsserver gesendet wird. Der Transaktionsserver sendet die Transaktionsdaten an einen Autorisierserver, der eine die Transaktion an die Identität des Autorisierservers bindende Information zurückschickt. Der Transaktionsserver verfügt dann über eine Information, die die Transaktion, das Endgerät und den Autorisierserver in einer Form miteinander verbindet, die nicht in betrügerischer Absicht vom Transaktionsserver erzeugt werden kann und daher anerkannt werden muß.

Gemäß einem weiteren Aspekt vermittelt die Erfindung ein elektronisches Transaktionssystem, bei dem an den Benutzer eine Autorisiermarke ausgegeben wird. Informationen, die die Identität sowohl der Autorisiermarke als auch des Benutzers bestätigen, werden einer Authorisierstelle zugeführt, die die Gültigkeit dieser Informationen bestätigt und sie einem Autorisierserver zur Verfügung stellt. Die Autorisiermarke wird dann in einer elektronischen Transaktion mit einem Transaktionsserver verwendet, in dem Informationen zur Benutzeridentifikation und solche über die Autorisiermarke dem Transaktionsserver zugeführt und an den Autorisierserver

weitergegeben werden. Der Autorisierserver vergleicht die Benutzeridentitäts- und Autorisiermarken-Informationen mit Informationen, die vorher von der Authorisierstelle zur Verfügung gestellt wurden, und zeigt das Vergleichsergebnis dem Transaktionsserver an. Auf diese Weise kann, da die Übereinstimmung zwischen Benutzer und Marke vor der Transaktion verifiziert wurde, die Verwendung der Marke durch den Benutzer während der Transaktion bestätigt werden.

Gemäß einem weiteren Aspekt vermittelt die vorliegende Erfindung ein elektronisches Transaktionssystem, bei dem ein Benutzerendgerät Transaktions- und Identifikationsdaten an einen Transaktionsserver überträgt. Von dem Transaktionsserver werden die Transaktionsdaten an einen Autorisierserver weitergegeben, der die Identifikationsdaten mit auf autorisierte Benutzer des Systems bezogenen Identifikationsdaten vergleicht. Der Autorisierserver überträgt dann an den Transaktionsserver eine Autorisiernachricht, die angibt, wie die Identifikationsdaten mit den gespeicherten Identifikationsdaten übereinstimmen. Aufgrund der Autorisiernachricht und der Transaktionsdaten bestimmt der Transaktionsserver, ob die Transaktionsdaten angenommen werden sollen.

Kurzbeschreibung der Zeichnungen

Spezielle Ausführungsbeispiele der vorliegenden Erfindung werden nachstehend anhand der beigefügten Zeichnungen beschrieben; darin zeigt:

Figur 1 ein Diagramm der Dienstfunktionen eines Autorisiersystems in einem Ausführungsbeispiel der vorliegenden Erfindung,

Figur 2 ein Diagramm über den Aufbau des Systems,

Figur 3 ein Diagramm der Hardwarekomponenten eines Benutzerendgerätes,

Figur 4 ein Diagramm der Hardwarekomponenten einer SmartCard, Figur 5 ein Diagramm der Untersysteme innerhalb des Autorisierservers in dem Ausführungsbeispiel,

Figur 6 ein Diagramm der Zertifizier-Architektur des Systems,

Figur 7 ein Diagramm zur Erläuterung eines spezielleren Ausführungsbeispiels, bei dem das System zur Autorisierung eines elektronischen Formulars verwendet wird,

Figur 8 den Datenfluß in dem speziellen Ausführungsbeispiel,

Figur 9 die vom Benutzerendgerät angewendeten Verschlüsselungsvorgänge,

Figur 10 den von dem Server für das elektronische Formular angewendeten Vorgang zur Gültigkeitsprüfung der digitalen Unterschrift,

Figur 11 die Übertragung einer Autorisier-Anforderungsnachricht an den Autorisierserver,

Figur 12 den von dem Autorisierserver durchgeführten Autorisiervorgang, und

Figur 13 den Vorgang der Autorisier-Antwortnachricht vom Autori

sierserver an den Server für das elektronische Formular.

Ausführungsarten der Erfindung Autorisierdienst

Figur 1 zeigt die Dienstfunktionen, die in einem Ausführungsbeispiel der vorliegenden Erfindung die Erzeugung einer digitalen Unterschrift und einen Authorisierdienst vermitteln. Ein Digitalunterschrifts-Generator 10 erzeugt digitale Unterschriften in Form von Daten, die einen bestimmten Teilnehmer einmalig identifizieren und die unterschriebenen Daten an diesen Teilnehmer binden. Digitale Unterschriften bilden eine bekannte Technik zum Schutz von Daten gegen Änderung und zur Identifizierung des unterzeichnenden Teilnehmers. Der unterzeichnende Teilnehmer ist mit einem Paar aus einem privaten und einem öffentlichen Schlüssel ausgestattet, wobei dieses Schlüsselpaar dazu benutzt werden kann, digitale Unterschriften zu erzeugen und zu verifizieren. Bei dem "Teilnehmer" wird gewöhnlich davon ausgegangen, daß es der Benutzer ist, der denjenigen Computer bedient, in dem der private Schlüssel gespeichert ist und die digitale Unterschrift erzeugt wird. Im vorliegenden Ausführungsbeispiel ist der private Schlüssel jedoch auf einer SmartCard gespeichert, so daß die digitale Unterschrift die unterschriebenen Daten an die SmartCard bindet. Der "Teilnehmer" ist somit die SmartCard.

Bekanntlich lassen sich mit einem privaten Schlüssel verschlüsselte Daten mit dem entsprechenden öffentlichen Schlüssel entschlüsseln und umgekehrt. Zu geeigneten Verschlüsselungsalgorithmen gehören der RSA-Algorithmus, der beispielsweise in US 4,405,829 beschrieben ist. In einem typischen, mit digitaler Unterschrift arbeitenden Verfahren werden die zu "unterschreibenden" Daten einem Verwürfelungsalgorithmus, etwa dem

Secure Hash Algorithm (SHA), unterworfen. Das Ergebnis ist eine Art von Quersumme, die als "Hash" bezeichnet wird und sowohl von den Werten der die Daten bildenden Bits als auch von den Positionen dieser Bits abhängt. Daher ist es schwierig, die Daten so zu verändern, daß sie denselben Hash-Wert ergeben. Unter Verwendung des privaten Schlüssels wird der Hash-Wert zu einer digitalen Unterschrift verschlüsselt.

Eine digitale Unterschrift läßt sich dadurch verifizieren, daß an den empfangenen Daten derselbe Hash-Algorithmus angewendet wird, wie er zur Erzeugung des in der digitalen Unterschrift codierten Hash-Wertes verwendet wurde. Die digitale Unterschrift wird sodann unter Verwendung des öffentlichen Schlüssels entschlüsselt, und der entschlüsselte Hash-Wert wird mit dem berechneten Hash-Wert verglichen. Stimmen diese Werte überein, so ist die Unterschrift gültig.

Beispiele für Algorithmen bei digitaler Unterschrift sind die RSA Digital Signature, bei der der Hash-Wert zusammen mit einer Angabe über den Typ des mit RSA-Verschlüsselung verwendeten Hash-Algorithmus verschlüsselt wird, und der Digital Signature Algorithm (DSA), bei dem der Hash-Algorithmus der SHA ist und mittels einer Variante des Diffie-Helman-Algorithmus zusammen mit einer Zufallszahl verschlüsselt wird.

Der Digitalunterschrifts-Generator 10 tauscht eine Information IE mit einer Digitalunterschrifts-Annahmestelle 20 aus und sendet die "unterschriebene" Information SI an die Digitalunterschrifts-Annahmestelle 20, die eine unter Verwendung eines privaten Schlüssels erzeugte erste digitale Unterschrift und eine mit einem symmetrischen Schlüssel arbeitende zweite digitale Unterschrift einfügt, wobei diese beiden Schlüssel in dem Digitalunterschrifts-Generator 10 enthalten sind. Beim Empfang der unterschriebenen Information verifiziert die Digitalunterschrifts-Annahmestelle 20 die erste Unterschrift und sendet eine Autorisieranforderung AREQ an eine Digitalunterschrifts-Autorisierstelle 30. Die Autorisieranforderung AREQ enthält aus der unterschriebenen Information SI und der zweiten Unterschrift abgeleitete Informationen. Die Digitalunterschrifts-Autorisierstelle 30 prüft die aus der unterschriebenen Information SI und der zweiten Unterschrift abgeleiteten Informationen und sendet an die Digitalunterschrifts-Annahmestelle eine Autorisierantwort ARES, die angibt, ob die Unterschrift als echt zu akzeptieren ist. Die Autorisierantwort ARES ist mit einer digitalen Unterschrift unterschrieben, die von einem in der Digitalunterschrifts-Autorisier-

• ·

• !

-6-

stelle 30 enthaltenen privaten Schlüssel erzeugt wird. Je nach der Autorisierantwort wird die unterschriebene Information SI von der Digitalunterschrifts-Annahmestelle 20 angenommen oder zurückgewiesen.

Um das Vorliegen und die Annahme oder Zurückweisung der unterschriebenen Information zu belegen, kann die Digitalunterschrifts-Annahmestelle 20 ferner an eine Beglaubigungsstelle 40 für unterschriebene Nachrichten eine Beglaubigungsanforderung NREQ senden, die aus der unterschriebenen Information SI und der Autorisieranforderung ARES abgeleitete Informationen enthält. Als Antwort überträgt die Beglaubigungsstelle 40 an die Digitalunterschrifts-Annahmestelle 20 eine Beglaubigungsbestätigung NCF, die aus der Beglaubigungsanforderung NREQ abgeleitete und von der Beglaubigungsstelle 40 digital unterschriebene Informationen enthält. Die Digitalunterschrifts-Annahmestelle 20 überträgt in einem Archiv abgelegte Informationen ARDEP, die beispielsweise die unterschriebene Information SI, die Autorisierantwort ARES und die Beglaubigungsbestätigung NCF enthalten können, an ein Langzeitarchiv 50. Falls die unterschriebene Information SI nicht anerkannt wird, können diese Informationen später als Archiv-Abrufinformationen ARRET aus dem Langzeitarchiv 50 wiedergewonnen werden

Wahlweise werden, sofern eine unabhängige Zeitangabe benötigt wird, beispielsweise um die genaue Zeit einer Transaktion, etwa des Aussendens und Empfangs der unterschriebenen Information SI, zu bestätigen, von einer Standard-Zeitsignalquelle 60 Informationen für jede der oben beschriebenen Funktionen zur Verfugung gestellt und in jede digital unterschriebene Nachricht eingefügt.

Systemaufbau

In Figur 2 ist ein Systemaufbau des Digitalunterschrifts-Autorisierdienstes auf hohem Niveau dargestellt. In dieser Figur tragen gleiche Teile wie in Figur 1 die gleichen Bezugsziffern.

Ein Benutzer 12, der an dem Digitalunterschrifts-Dienst teilnehmen möchte, muß zunächst eine SmartCard 18 beantragen, von der digitale Unterschriften des Benutzers abgeleitet werden. Der Benutzer 12 hat einen Computer 14, der an das Internet 100 über ein Modem 16, beispielsweise unter Verwendung von bekannter Netzsurf-Software und TCP/IP-Protokollen, anschließbar ist.

Die Komponenten des Computers 14, bei dem es sich um einen IBM-kompatiblen "Personal Computer" oder einen Apple-Macintosh-Computer handeln mag, sind in Figur 3 gezeigt. Danach ist eine CPU 110 über einen Bus 120 mit einem Hauptspeicher 130, einer an einen Plattenspeicher 145 angeschlossenen Plattensteuerung 140, einer an eine Tastatur 152 angeschlossenen Benutzer-Interfacesteuerung 150 sowie weiteren Eingabegeräten, etwa einer Maus 154, einer an ein Sichtgerät 165 angeschlossenen Anzeigesteuerung 160 und einer Ein/Ausgabesteuerung 170, verbunden. Die Ein/Ausgabesteuerung 170 steuert das Modem 160 und einen Kartenleser 174, in den eine SmartCard eingelegt werden kann. Wahlweise ist an die Ein/Ausgabesteuerung 170 oder die Benutzer-Interfacesteuerung 150 ein Biometriegerät 180 angeschlossen, bei dem es sich um einen Fingerabdruck-Scanner, einen Iris-Scanner oder ein sonstiges Gerät handeln kann, das es gestattet, von dem Benutzer 12 einmalig abgeleitete Informationen in den Computer 14 einzugeben. Der Fingerabdruck-Scanner kann in die Tastatur 152 integriert sein.

Der Benutzer hat über das Internet 170 Zugriff zu einem Kundenserver 70 und beantragt Teilnahme am Digitalunterschrifts-Dienst. Dieser Antrag wird mittels einer geeigneten Form sicherer Nachrichtenübertragung an ein Kartenbüro 90 weitergegeben. Das Kartenbüro 90 sendet dem Benutzer 12 eine SmartCard 18 zu. Ein Beispiel der Komponenten innerhalb der SmartCard 18 ist in Figur 4 dargestellt.

Die SmartCard 18 enthält einen mit einem Speicher 210 und einem externen Stecker 220 verbundenen Prozessor 200. Die Karte 18 kann auch eine Energiequelle, etwa eine in der Karte 18 integrierte Zelle, enthalten; stattdessen kann Energie auch von dem Kartenleser 174 über den Stecker 220 zugeführt werden. Mindestens ein Teil des Speichers 210 bildete einen Festspeicher, um ein Betriebsprogramm und Daten zu speichern, wenn die Karte 18 aus dem Leser 174 entnommen ist.

In dem Festspeicher der Karte 18 werden bei der Herstellung ein Paar aus einem öffentlichen Schlüssel und einem privaten Schlüssel sowie ein Karten-Identifiziercode aufgezeichnet. Der private Schlüssel wird gegen Auslesen aus der Karte durch ein auf dem Prozessor 200 laufendes Betriebssystem und wahlweise durch Hardware-Schutzmaßnahmen geschützt, die verhindern, daß der Festspeicher zur Ermittlung seines Inhalts physisch untersucht wird.

• ·

·■*■■ >

* i

— 8 —

Wird von dem Kundenserver 70 ein Antrag empfangen, so wird der Name des Benutzers 12 auf die Karte 18 aufgedruckt, die dann dem Benutzer 12 zugesandt wird. Ferner wird an den Autorisierserver eine Statusnachricht gesandt, die angibt, daß die Karte 18 ausgegeben wurde, aber inaktiv ist.

Der Benutzer 12 bringt die Karte 18 sodann in das Geschäftslokal 80 einer den Digitalunterschrifts-Dienst unterstützenden Organisation, wo die Identität des Benutzers bezüglich der Identität desjenigen Benutzers überprüft wird, an den die Karte 18 ausgegeben wurde. Ist die Identität des Benutzers verifiziert, so wird von dem Geschäftslokal 80 eine Statusnachricht V an einen mit dem Autorisierserver 30 verbundenen Kartenverwaltungs-Server 38 geschickt, wobei diese Nachricht die Karte 18 und den Benutzer 12 identifiziert. An den Benutzer 12 werden ferner, soweit er nicht schon darüber verfügt, der Kartenleser 174 sowie Anwendungssoftware für den Digitalunterschrifts-Dienst ausgegeben.

Auf der Karte 18 wird entweder vor Ausgabe an den Benutzer oder durch den Benutzer bei der ersten Verwendung der Karte 18 in einer Transaktion eine PIN aufgezeichnet. Im ersten Fall erfährt der Benutzer die PIN nach Verifizierung seiner Identität.

Zur Verwendung des Digitalunterschrifts-Dienstes führt der Benutzer 12 die Karte 18 in den Kartenleser 114 ein. Die auf dem Computer 14 laufende Anwendungssoftware fordert dann den Benutzer 12 zur Eingabe einer PIN auf. Die von ihm eingegebene PIN wird mit der auf der Karte 18 gespeicherten PIN verglichen, wobei die Anwendungssoftware ein Ergebnis (VR) einer Kartengültigkeitsprüfung erzeugt, das anzeigt, ob eine PIN angefordert wurde und ob die eingegebene PIN mit der auf der Karte 18 gespeicherten übereinstimmt.

Zusätzlich oder alternativ erhält der Computer 14 von dem Biometriegerät 180, falls vorhanden, Biometriedaten. Wie in einem speziellen Ausführungsbeispiel nachstehend beschrieben wird, erzeugt die SmartCard 18 eine digitale Unterschrift für die von dem Computer 14 an den Dienstprovider 20 übertragene unterschriebene Information SI.

Bei dem Dienstprovider 20 kann es sich um einen Allzweckcomputer handeln, der mit Netzserver-Software arbeitet und an das Internet 100 angeschlossen ist. Auf dem Dienstprovider 20 läuft ferner Autorisier-Software zum Nachrichtenaustausch mit dem Autorisierserver 30.

Der Autorisierserver 30 umfaßt einen Allzweckrechner, der mit Autorisierserver-Software arbeitet und an das Internet 100 angeschlossen ist. Wie in Figur 2 und 5 gezeigt, ist der Autorisierserver 30 ferner, etwa über ein lokales oder privates Netz, an einen Server 32 für einen öffentlichen Schlüssel, einen Kartenbeglaubigungs-Server 34 und einen Kundenverifizier-Server 36 angeschlossen. Der Server 32 für den öffentlichen Schlüssel und der Kartenbeglaubigungs-Server 34 enthalten speziell zugeordnete Hardwaremodule einschließlich Verschlüsselungs/Entschlüsselungs-Beschleunigungshardware. In dem Kundenverifizier-Server 36 ist eine Datenbank abgespeichert, die die Einzelheiten der autorisierten Benutzer des Digitalunterschrifts-Dienstes enthält.

Der Autorisierserver 30 empfängt von dem Dienstprovider die Autorisieranforderung AREQ, die einen Hash-Wert H der unterschriebenen Information SI, ein öffentliches Schlüsselzertifikat, eine auf die Karte 18 und den Benutzer bezogene Identifizierinformation und eine Kartenbeglaubigungsinformation enthält. Der Autorisierserver 30 sendet die Kartenbeglaubigungsinformation CCHK an den Kartenbeglaubigungs-Server 34, der die Echtheit der Karte 18 prüft und eine Antwort CRES zurückschickt, die angibt, ob die Karte echt ist oder nicht. Der Beglaubigungsserver 30 sendet die Benutzeridentitäts-Information ID an den Kundenverifizier-Server 36, der eine' Antwort IDRES zurückschickt, die anzeigt, ob oder wie weit die Einzelheiten der Kundenidentität richtig sind.

Der Autorisierserver 30 erzeugt aus den Antworten CRES und IDRES eine Autorisiernachricht AM, die an den Server 32 für den öffentlichen Schlüssel geschickt wird. Dieser unterschreibt die Autorisiernachricht AM und erzeugt eine Antwort ARES für unterschriebene Autorisierung, die an den Dienstprovider 20 übertragen wird.

Hierarchie der öffentlichen Schlüssel

Wie oben erläutert, werden die digitalen Unterschriften unter Verwendung einer Verschlüsselung mit öffentlichem Schlüssel erzeugt, verifiziert und autorisiert. Die öffentlichen Schlüssel werden mittels öffentlichen Schlüsselzertifikaten verteilt, so daß die Benutzer von öffentlichen Schlüsseln darauf vertrauen können, daß diese Teilnehmern gehören, mit denen sie in Verbindung treten möchten. Bekanntlich besteht ein öffentliches Schlüsselzertifikat aus einem Namen, der einen Teilnehmer identifiziert, der einen privaten Schlüssel hält (im vorliegenden Fall die Karte 18), dem ent-

• · *■*■

— 10 —

sprechenden öffentlichen Schlüssel und einer digitalen Unterschrift, die einen Hash-Wert des Namens und des öffentlichen Schlüssels enthält, wobei der Hash-Wert unter Verwendung des privaten Schlüssels einer Zertifizierstelle, der der Benutzer vertraut, verschlüsselt wurde. Verfügt der Benutzer nicht über den öffentlichen Schlüssel der Zertifizierstelle, so läßt sich dies von einem öffentlichen Schlüsselzertifikat der Zertifizierstelle erhalten, das von einer Stammzertifizierstelle unterschrieben ist. Auf diese Weise läßt sich eine Hierarchie von öffentlichen Schlüsselzertifikaten verwenden, die letzten Endes von einer Stammzertifizierstelle verwaltet wird, die immer Vertrauen genießt.

Ändert sich jedoch ein Paar aus einem öffentlichen Schlüssel und einem privaten Schlüssel, so gilt das öffentliche Schlüsselzertifikat nicht mehr. Das alte öffentliche Schlüsselzertifikat kann dadurch widerrufen werden, daß ein Code ausgegeben wird, der dieses Zertifikat auf einer Certificate Revocation List CRL identifiziert, die von Zeit zu Zeit an die Benutzer des öffentlichen Schlüssels herausgegeben wird. Ein öffentliches Schlüsselzertifikat kann somit vor seiner Benutzung anhand der CRL überprüft werden.

Figur 6 zeigt die Schlüsselhierarchie in dem vorliegenden Ausführungsbeispiel. Die SmartCard 18 führt unter Verwendung eines auf ihr gespeicherten privaten Schlüssels SCK einen Vorgang mit digitaler Unterschrift durch. Der entsprechende öffentliche Schlüssel ist in einem Smart-Card-Zertifikat SCC enthalten, das auf der Karte gespeichert und unter Verwendung eines privaten Kartenzertifizierschlüssels CCK einer Kartenzertifizierstelle 110 unterschrieben ist. Der entsprechende öffentliche Schlüssel ist in einem Zertifikat CCC der Kartenzertifizierstelle enthalten, das mit einem privaten Schlüssel RCK einer Stammzertifizierstelle 120 unterschrieben ist. Der private Schlüssel RCK der Stammzertifizierstelle dient auch zur Unterschrift des öffentlichen Schlüsselzertifikats ASC des Autorisierservers 30. Der entsprechende öffentliche Schlüssel ist in einem öffentlichen Schlüsselzertifikat RCC der Stammzertifizierstelle verteilt, das unter Verwendung des entsprechenden privaten Schlüssels RCK selbst-unterschrieben ist. Der private Schlüssel ASK des Autorisierservers dient zur Erzeugung einer digitalen Unterschrift auf der Autorisierantwort ARES.

• ·

— 11 —

Kartenbeglaubigung

Zusätzlich zu den oben beschriebenen Transaktionen mit öffentlichem Schlüssel führt die SmartCard 18 auch die Funktion einer Kartenbeglaubigung mit symmetrischem Schlüssel in Verbindung mit dem Autorisierserver 30 unter Verwendung eines auf der Karte 18 gespeicherten separaten privaten Schlüssels durch. Der Vorgang arbeitet mit einem Algorithmus des Zweischlüssel-Dreifachdaten-Verschlüsselungsstandards (DES, Verschlüsselung-Entschlüsselung-Verschlüsselung) im Cipher-Block-Chaining-Modus durch, um einen Acht-Bit-Nachrichtenbeglaubigungscode (MAC) zu erzeugen.

Die Beglaubigungsfunktion mit symmetrischem Schlüssel wird für sichere Übertragungen zwischen der SmartCard 18 und dem Beglaubigungsserver 30 verwendet, die den Dienstprovider 20 transparent passieren, ohne daß dieser sie entschlüsseln kann. Für jede Kartenbeglaubigungs-Transaktion wird der MAC aus einer Kombination folgender Größen berechnet: in der Karte intern gespeicherte Daten, zu denen ein Zählerwert ATC für variable Anwendungstransaktionen, der mit jeder Transaktion erhöht wird, und eine in dem öffentlichen Schlüsselzertifikat SCC enthaltene Kartenidentitätsnummer N gehören; von dem Dienstprovider 20 zugeführte Daten, zu denen Zeit, Datum und Identität des Dienstproviders gehören, um den MAC an die spezielle Transaktion zu binden; ein Hash-Wert H, der unterschriebenen Information SI, mit der der MAC an die zugeführten Daten und die digitale Unterschrift gebunden wird; und das Ergebnis VK der Gültigkeitsprüfung oder eine aus den Biometriedaten abgeleitete Information sowie die zweite nicht vorhersagbare Zahl UN2.

Ausführung mit elektronischen Formularen

Im folgenden wird anhand von Figur 7 bis 13 ein spezielleres Ausführungsbeispiel beschrieben, bei dem das System mit digitaler Unterschrift zur Beglaubigung eines vom Benutzer 12 an den Dienstprovider 20 elektromsch übermittelten ausgefüllten Formulars dient, wobei der Dienstprovider in diesem Fall von einer staatlichen Behörde betrieben wird. In Figur 7 bis 13 ist die räumliche Verbindung zwischen dem Computer 14 und dem Dienstprovider 20 sowie zwischen dem Dienstprovider 20 und dem Autorisierserver 30 in Form separater Netze dargestellt; in dem Beispiel verlaufen aber beide Verbindungen über das Internet.

Figur 8 zeigt die während einer Transaktion stattfindende Datenübertragung. Der Computer 14 hat bereits eine Internetverbindung mit dem Dienstprovider 20 hergestellt und arbeitet mit einer Netzsurf-Software. Als Antwort auf einen Antrag seitens des Benutzers 12 sendet der Dienstprovider 20 Daten D, zu denen ein Leerformular (etwa ein Formular zur Eintragung einer neuen Firma) darstellende HTML-Seiten gehören. Der Benutzer 12 füllt dieses Formular durch Einsetzen von Daten innerhalb der Surf-Software aus und beantragt die Übertragung des ausgefüllten Formulars an den Dienstprovider 20. Die Surf-Software unterstützt den Digitalunterschrifts-Dienst, beispielsweise mittels eines Einschubes, der Standard-Surfsoftware modifiziert, so daß der Benutzer 12 dann, wenn er die Übertragung des ausgefüllten Formulars beantragt, zur Eingabe einer PIN aufgefordert wird. Wurde die SmartCard 12 nicht in den Kartenleser 174 eingeführt, so fordert die Software den Benutzer 12 dazu auf.

In einer Datenverarbeitungsstufe DP erzeugt die SmartCard 18 aus den Formulardaten F des ausgefüllten Formulars und dem privaten Schlüssel SCK der SmartCard eine digitale Unterschrift. Die unterschriebenen Daten SD werden sodann an den Dienstprovider 20 geschickt, der die Unterschrift dadurch verifiziert, daß der öffentliche Schlüssel der Karte aus dem SmartCard-Zertifikat SCC unter Verwendung des aus dem Kartenbeglaubigungs-Autorisierzertifikat CCC wiedergewonnenen öffentlichen Schlüssels für Kartenzertifizierung wiedergewonnen, die Hash-Funktion für die Formulardaten berechnet und die berechnete Hash-Funktion mit derjenigen verglichen wird, die mit dem Kartenschlüssel SCK der SmartCard unterschrieben und in den unterschriebenen Daten SD enthalten ist. Von dem Dienstprovider 20 werden aus den unterschriebenen Daten SD abgeleitete Unterschrifts-Verifizierdaten SVD an den Autorisierserver 30 gesendet.

Kartenbeglaubigungsdaten CAD, zu denen der MAC und die zu dessen Erzeugung verwendeten Eingabedaten gehören, sowie die Benutzeridentitätsdaten ID werden an den Dienstprovider 20 übertragen und an den Beglaubigungsserver 30 weitergegeben. Zu den Benutzeridentitätsdaten ID gehören beispielsweise Name, Adresse und Geburtsdatum des Benutzers, die vom Benutzer 12 eingegeben und von der Surf-Software in einem von den unterschriebenen Daten SD separaten Feld übertragen. Wahlweise werden in die Benutzeridentitäts-Informationen Biometriedaten von dem Biometriegerät 180 eingefügt. Miteinander bilden die Unterschrifts-Verifi-

zierdaten SVD, die Kartenbeglaubigungsdaten CAD und die Benutzeridentitätsdaten ID die an den Autorisierserver 30 übertragene Autorisieranforderung AREQ.

Der Autorisierserver 30 prüft die Autorisieranforderung AREQ auf Fälschung oder überspielte Kryptogramme, prüft, ob das öffentliche Schlüsselzertifikat SCC der SmartCard mit der Kartenidentität übereinstimmt, und prüft die Benutzeridentitätsdaten ID anhand eines Eintrags von Einzelheiten bekannter Karteninhaber in einer Datenbank. Der Beglaubigungsserver verifiziert ferner den MAC anhand von zur Erzeugung des MAC verwendeten Eingabedaten unter Verwendung des geeigneten symmetrischen Schlüssels. Die Ergebnisse dieser Prüfungen werden unter Verwendung des privaten Schlüssels ASK des Autorisierservers digital unterschrieben und als Autorisierantwort ARES an den Dienstprovider 20 geschickt.

Einige der obigen Vorgänge werden nachstehend näher erläutert.

Benutzer an Dienstprovider

Figur 9 zeigt, wie die vom Computer 14 des Benutzers an den Dienstprovider 20 gesendeten Daten erzeugt werden. Zu den vom Dienstprovider 20 gesendeten Daten D gehörten zwei Zufalls- oder in sonstiger Weise nicht vorhersagbare 32-Bit-Zahlen UNl und UN2, Datum und Zeit der Transaktion sowie eine Serverkennung SID. Die erste nicht vorhersagbare Zahl ist in dem HTML-Formular als lesbare Seriennummer eingebettet und wird in den Formulardaten F zurückgesendet.

Die Anwendungssoftware berechnet einen Hash-Wert der Daten F für das ausgefüllte Formular unter Verwendung eines sicheren Hash-Algorithmus SHA und sendet den Hash-Wert zusammen mit der zweiten nicht vorhersagbaren Zahl UN2, dem Ergebnis VR der Gültigkeitsprüfung, Datum, Zeit und Serverkennung SID an die Karte 18 zur Verwendung in dem DES-Verschlüsselungsvorgang zur Erzeugung des MAC. Die Karte erzeugt einen Zählerwert ATC der Anwendungstransaktion, der ebenfalls in den DES-Vorgang eingegeben wird. Der Hash-Wert wird ferner als Eingang einem RSA-Verschlüsselungsvorgang mit öffentlichem Schlüssel zugeführt. Das öffentliche Schlüsselzertifikat SCC der Karte ist in der Karte 18 gespeichert und wird von der Anwendungssoftware zusammen mit dem MAC und Unterschriftsdaten SD zur Übertragung an den Dienstprovider 20 abgerufen.

• ·

Unterschrifts-Gültigkeitsprüfung

Der von dem Dienstprovider 20 durchgeführte Vorgang zur Gültigkeitsprüfung der Unterschrift der unterschriebenen Daten SD ist in Figur 10 dargestellt. Der Dienstprovider 20 empfängt die Formulardaten F und prüft (SlO), ob die Seriennummer UNl mit der des vorher übersandten Leerformulars übereinstimmt. Unter Anwendung des gleichen SHA, wie er von der Karte 18 durchgeführt wurde, wird aus den Formulardaten F ein Hash-Wert berechnet. Der öffentliche Schlüssel der Karte wird aus dem öffentlichen Schlüsselzertifikat SCC der Karte abgerufen und zum Entschlüsseln (S20) der Unterschriftsdaten SD verwendet, wobei der vom Computer 14 des Benutzers errechnete Hash-Wert extrahiert wird. Die beiden Hash-Werte werden verglichen (S30); bei Übereinstimmung wird die Unterschrift als gültig bestätigt. Dieser Vorgang weist jedoch nur nach, daß das Formular unter Verwendung der Karte 18 digital unterschrieben wurde. Wie im folgenden beschrieben, muß der Dienstprovider 20 außerdem prüfen, ob die Karte 18 gültig ist und von dem autorisierten Karteninhaber benutzt wird.

Autorisieranforderung

Wie in Figur 11 dargestellt, sendet der Dienstprovider 20 in der Autorisier-Anforderungsnachricht ARES die folgenden Informationen an den Autorisierserver 30: die Benutzeridentitätsdaten ID, zu denen gegebenenfalls Biometriedaten gehörten, die zweite nicht vorhersagbare Zahl UN2, den aus den abgerufenen Formulardaten F berechneten Hash-Wert H, das öffentliche Schlüsselzertifikat SCC der Karte, das Ergebnis VR der Gültigkeitsprüfung, den Zählwert ATC der Anwendungstransaktion und den Nachrichtenbeglaubigungscode MAC. Die Form der Autorisieranforderungsachricht ist im einzelnen in der folgenden Tabelle 1 gezeigt.

Tabelle 1 - Autorisieranforderungsnachricht

Feldname	Feldbeschreibung
Version	Version der Autorisieranf orderungsachricht
Service Provider Ref.	Vom Dienstprovider zugeführte Nachrichtenreferenz
Authorisation Service Ref.	Vom Dienstprovider zugeführte Autorisierdienst- Referenz
Contract Info	URL für einen Vertrag, der die Benutzung des Autori sierdienstes regelt

• ·

— 15 —

Feldname	Feldbeschreibung
Request Sent Time	Vom Systemtaktgeber des Dienstproviders abgegebene Zeit, zu der die Nachricht übertragen wurde
SCC	Öffentliches Schlüsselzertifikat der Karte 18
H	Hash-Wert der Formulardaten F
User Time	Zeit vom Benutzer des Computers 14, zu der die Autorisieranforderung von dem Computer 14 übertragen wurde
Server Provider Identity	Zur Erzeugung des MAC benutzte Dienstprovider- kennung
UN2	Zweite nicht vorhersagbare Zahl
Card Data	Von der Anwendungssoftware und der Karte 18 erzeugte und an den Autorisierserver weitergegebene Daten
User Surname	Nachname des Benutzers
User First Name	Vorname (n) des Benutzers
User Title	Titel des Benutzers
User DOB	Geburtsdatum des Benutzers
User Address	Erste Zeile der Benutzeradresse
User Postcode	Postleitzahl des Benutzers

Die in Tabelle 1 beschriebenen Kartendaten enthalten die in Tabelle 2 nachstehend gezeigten Felder:

Tabelle 2 - Struktur der Kartendaten

Feldname	Feldbeschreibung
Cryptogram Info Data	Bezeichnet die Art des Kryptogramms
Cryptogram Version Number	Versionsnummer des Krytogramms
Application Transaction Counter	In der Karte 18 gespeicherter Zählerwert, der nach jeder Transaktion aktualisiert wird
MAC	Von der Karte 18 erzeugtes Kryptogramm
VR	Ergebnis der Gültigkeitsprüfung
Derivation Key Index	Index, der dem Autorisierserver 30 den symmetrischen Schlüssel identifiziert

Vorgang der Autorisieranforderung

Der Autorisierserver 30 bestimmt die Autorisierantwort ARES gemäß Figur 12. Die Benutzeridentitätsinformation ID wird an den Kundenverifizier-Server 36 geschickt, der prüft, ob diese Information mit der gespeicherten, auf die Kartennummer bezogenen Benutzeridentitätsinformation über-

• ·

'S Φ

16 —

einstimmt und schickt eine Antwort IDRES zurück, die angibt, ob diese Einzelheiten richtig sind, und den Status der Karte enthält. Die Karten-Beglaubigungsdaten CAD werden an den Kartenbeglaubigungsserver 34 geschickt, wo die MAC unter Verwendung der aus dem öffentlichen Schlüsselzertifikat der Karte extrahierten Kartennummer N, der zweiten nicht vorhersagbaren Zahl UN2 sowie des Datums, der Zeit und der vom Dienstprovider 20 ursprünglich ausgegebenen Serveridentität verifiziert wird. Der Kartenbeglaubigungs-Server 34 prüft ferner das Ergebnis VR der Gültigkeitsprüfung und ermittelt, ob das Kryptogramm neu eingespielt wurde oder die Karte gefälscht ist und ob das öffentliche Schlüsselzertifikat SCC der Karte gültig ist und dem MAC entspricht.

Wahlweise weist der Kundenverifizierserver 36 eine Datenbank mit Biometrieinformationen für jeden autorisierten Benutzer auf, und die Antwort IDRES enthält Informationen zum Vertraulichkeitsniveau, anhand derer in der Benutzeridentitätsinformation ID enthaltene Biometriedaten auf Übereinstimmung mit dem für diesen Benutzer gespeicherten Profil geprüft werden.

Autorisierantwort

Der Autorisierserver 30 formatiert die Autorisier-Antwortnachricht ARES und überträgt sie an den Dienstprovider 20 mittels eines in Figur 13 gezeigten Vorgangs. Zunächst wird eine Autorisiernachricht AM erzeugt, die die folgenden Informationen enthält: den Hash-Wert H und die aus der Autorisieranforderung AREQ kopierte Benutzeridentitätsinformation ID sowie einen Antwort code, der die Serverantworten bezüglich Kartenbeglaubigung und Benutzerverifizierung angibt. Diese Nachricht AM wird an den öffentlichen Schlüssel-Server 32 geschickt, der unter Verwendung des privaten Schlüssels ASK des Autorisierservers eine digitale Unterschrift für die Nachricht erzeugt und diese Unterschrift AS zusammen mit dem öffentlichen Schlüsselzertifikat ASC des Autorisierservers zurückschickt. Der Autorisierserver sendet dann die Autorisiernachricht AM, die Unterschicht AS und das Autorisierserver-Zertifikat ASC an den Dienstprovider 20 zusammen mit einem Referenzcode, der den Vertrag angibt, aufgrund dessen die Autorisierung an den Dienstprovider 20 erfolgt.

Der Dateninhalt der Autorisiernachricht ist nachstehend in Tabelle 3 zusammengefaßt:

Tabelle 3 - Inhalt der Autorisiernachricht

Feldname	Feldbeschreibung
Service Provider Reference	Vom Dienstprovider zugeführte, aus der Autori- sieranforderungsnachricht kopierte Nachrichten referenznummer
Hash	Hash-Wert der Autorisier- Anforderungsnachricht
Request Received Time	Zeit vom Autorisierserver, zu der die Autorisier anforderung empfangen wurde
Authorisation Response	Autorisier-Antwortdaten
Response Sent Time	Zeit vom Autorisierserver, zu der die Antwort abgeschickt wurde

Die Autorisier-Antwortdaten sind gemäß Tabelle 4 in einzelnen Bits codiert:

Tabelle 4 - Bedeutung der Bits der Autorisier-Antwortdaten

Index	Bitnummer	Bedeutung
0	0	JCarte existiert nicht
	1	Karte nicht aktiviert
	2	Karte abgelaufen
	3	Karte als verloren gemeldet
	4	Karte als gestohlen gemeldet
	5	keine Verifizierung möglich
	6	Karte als Demonstrationskarte registriert
	7	Verifizierfehler - siehe folgende Bytes
1	0	Nicht spezifizierter Fehler in der Adressenüberein- stimmung
	1	Nachname stimmt nicht überein
	2	Vorname stimmt nicht überein
	3	Titel stimmt nicht überein
	4	Geburtsdatum stimmt nicht überein
	5	Erste Adressenzeile stimmt nicht überein
	6	Postleitzahl stimmt nicht überein
	7	(nicht genutzt)
2	0	Nicht spezifizierter Beglaubigungsfehler
	1	Kartenbeglaubigung nicht möglich
	2	Kryptogramm-Verifizierfehler
	3	Zählerwert der Anwendungstransaktion ungültig
	4	PIN-Verifizierung nicht durchgeführt
	5	PIN-Verifizierung negativ

t«

— 18 —

Wahlweise kann zu den Autorisier-Antwortdaten eine Angabe des Vertraulichkeitsniveaus gehören, mit dem die in der Kundenidentitätsinformation enthaltenen Biometriedaten mit denen in dem Kundenverifizier-Server 36 gespeicherten Daten übereinstimmen; beispielsweise geben bei Iris- und Fingerabdruck-Abtastungen verwendete Musterübereinstimmungsalgorithmen einen geeigneten Wert zurück, der auf der Korrelation zwischen einer Eingabe und einem Referenzmuster beruht.

Aufgrund der Autorisierantwort ARES und des Ergebnisses des Unterschrifts-Verifiziervorgangs bestimmt der Dienstprovider 20, wie die Formulardaten F zu verarbeiten sind. Ist beispielsweise die Unterschrift verifiziert und die Transaktion von dem Autorisierserver autorisiert, so kann der Dienstprovider eine dem Benutzer 12 entsprechende Aufzeichnung unter Hinzufügen der in den Formulardaten F enthaltenen Information aktualisieren. Ist entweder die Unterschrift nicht verifiziert oder die Transaktion nicht autorisiert, so können die Formulardaten F verworfen oder an den Computer des Benutzers eine Nachricht übertragen werden, die angibt, daß das Formular nicht angenommen wurde.

Da die Autorisierantwort ARES detaillierte Informationen über die Ergebnisse der verschiedenen Autorisierprüfungen enthält, kann der Dienstprovider die Durchführung gewisser Arten von Transaktionen gestatten, falls die Autorisierprüfungen als erfolglos angegeben werden. Stimmt beispielsweise der Titel nicht überein, so beurteilt der Dienstprovider dies als nicht signifikant, da der Benutzer durch andere Daten eindeutig identifiziert ist, und die Transaktion wird vom Dienstprovider 20 als akzeptierbar verarbeitet.

Bei der Wahlmöglichkeit, bei der die Autorisierantwort ARES eine Angabe über das Vertraulichkeitsniveau enthält, mit dem die zugeführte Benutzeridentitätsinformation ID auf Übereinstimmung mit der gespeicherten Benutzeridentitätsinformation übereinstimmt, setzt der Dienstprovider 20 für die laufende Transaktion ein minimales Vertraulichkeitsniveau fest und gestattet die Durchführung der Transaktion, falls dieses Vertraulichkeitsniveau überschritten wird. Vorzugsweise wird dieses minimale Vertraulichkeitsniveau entsprechend dem Geldwert der Transaktion oder, falls die Transaktion keinen Geldwert spezifiziert, entsprechend den Folgen eines Betrugs in der Transaktion bestimmt.

Im Betrugsfalle dient die Autorisierantwort ARES vorzugsweise zur Bestimmung der Haftung zwischen dem Betreiber des Dienstproviders 20 und dem Betreiber des Autorisierservers 30. Sind beispielsweise Bits mit dem Index 0 gesetzt, so wird der Betreiber des Autorisierservers keine Haftung übernehmen, falls der Dienstprovider die Transaktion annimmt, während dann, wenn nur eines der Bits mit dem Index 1 gesetzt ist, der Betreiber des Autorisierservers Haftung nur bis zu einem vorher vereinbarten Limit übernehmen wird; ist keines der Bits gesetzt, so wird der Betreiber des Autorisierservers Haftung bis zu dem für den Benutzer 12 vorher vereinbarten maximalen Wert übernehmen.

Die vorliegende Erfindung beschränkt sich nicht auf die Verwendung des Internet, sondern ist auch auf Transaktionen über sonstige Netze anwendbar, die an sich nicht sicher sind. Das den Computer 14 des Benutzers mit dem Dienstprovider 20 verbindende Netz kann von dem den Dienstprovider 20 mit dem Autorisierserver 30 verbindenden Netz getrennt sein.

Das obige Ausführungsbeispiel wurde zwar anhand eines bestimmten Benutzers beschrieben; es versteht sich aber, daß ähnliche Vorgänge für verschiedene Benutzer durchgeführt werden können, so daß das System Transaktionen vornehmen kann, die von irgendeinem aus einer großen Anzahl von Benutzern eingeleitet werden.

Die vorliegende Erfindung beschränkt sich nicht auf einen bestimmten Transaktionstyp, etwa die Beglaubigung von Formularen oder die Autorisierung von Zahlungen.

In einem alternativen Ausführungsbeispiel kann die SmartCard 18 die Formulardaten unter Verwendung des symmetrischen Verschlüsselungs-Schlüssels nach dem DES-Verfahren unterschreiben und den RSA-Verschlüsselungsvorgang übergehen. Der Dienstprovider 20 ist dann nicht in der Lage, die Unterschrift zu verifizieren, sondern wird stattdessen den Hash-Wert neu berechnen und ihn zur Verifizierung an den Autorisierserver 30 senden.

In einem alternativen Ausführungsbeispiel benutzt die SmartCard 18 den öffentlichen Schlüssel SCK sowohl zum Erzeugen des MAC als auch zum Unterschreiben der Formulardaten F, ohne daß irgendein symmetrischer Verschlüsselungs-Schlüssel verwendet wird. In diesem Fall prüft der Dienstprovider 20 die Kartenanwendungsdaten CAD unter Verwendung des in dem Schlüsselzertifikat SCC der SmartCard enthaltenen öffentlichen

Schlüssels, um sicherzustellen, daß der MAC unter Verwendung des privaten Schlüssels SCK aus den Eingabedaten erzeugt wurde. Der Dienstprovider 20 ist jedoch nicht in der Lage zu prüfen, ob die kartenspezifischen Daten, etwa der Zählerwert ATC der Anwendungstransaktion und die Kartennummer N, richtig sind und einer gültigen Karte entsprechen, so daß diese kartenspezifischen Daten noch an den Autorisierserver 30 gesendet werden, der die Übereinstimmung der kartenspezifischen Daten und der Gültigkeit der Karte 18 prüft. In ähnlicher Weise werden die Benutzeridentitätsdaten ID noch an den Autorisierserver 30 zum Vergleich mit dem Autorisierserver zugänglichen Einzelheiten des Karteninhabers gesendet.

Die obigen Ausführungen sind als Beispiele beschrieben und nicht im Sinne einer Beschränkung des Schutzumfangs der Erfindung auszulegen. Vielmehr erstreckt sich die Erfindung auf sämtliche Varianten, die in den Schutzumfang der nachstehenden Ansprüche fallen.

Claims

1. Vorrichtung zum Verarbeiten einer Datentransaktion zwischen einem Endgerät (14) und einem ersten Server (20) über ein öffentliches Netz (100) sowie zwischen dem ersten Server (20) und einem zweiten Server (30), wobei
das Endgerät (14) die Transaktions-Nachrichtendaten (F) und Identifikationsdaten (ID) an den ersten Server (20) überträgt,
der ersten Server (20) die Identifikationsdaten (ID) an den zweiten Server (30) überträgt,
der zweite Server (30) die empfangenen Identifikationsdaten (ID) mit vorher gespeicherten Identifikationsdaten vergleicht, eine Autorisiernachricht (ARES) erzeugt, die das Maß der Übereinstimmung zwischen den empfangenen Identifikationsdaten (ID) und den vorher gespeicherten Identifikationsdaten angibt, und die Autorisiernachricht (ARES) an den ersten Server (20) überträgt, und
der erste Server (20) die Transaktions-Nachrichtendaten (17) je nach der empfangenen Autorisiernachricht (ARES) verarbeitet.

2. Vorrichtung nach Anspruch 1, wobei der erste Server (20) die Transaktionsdaten (F) auch entsprechend ihrem Inhalt verarbeitet.

3. Vorrichtung nach Anspruch 2, wobei der erste Server (20)
aus der Autorisiernachricht (ARES) Annahmekriterien bestimmt,
aus den Transaktions-Nachrichtendaten (17) ein oder mehrere Annahmeparameter bestimmt, und
die Transaktions-Nachrichtendaten (17) als gültig verarbeitet, wenn ein oder mehrere Annahmeparameter die Annahmekriterien erfüllen.

4. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der erste Server (20) die Identifikationsdaten (ID) zusammen mit für die laufende Transaktion spezifischen Transaktions-Identifikationsinformationen (ATC, UN2, H) an den zweiten Server schickt, wobei die Autorisierantwort (ARES) auch angibt, ob die Transaktions-Identifikationsinformationen (ATC, UN2, H) verifiziert worden sind.

5. Vorrichtung nach Anspruch 4, wobei der erste Server (20) die Transaktions-Identifikationsinformationen (ATC, UN2, H) von dem Endgerät (14) zusammen mit einer ebenfalls an den zweiten Server (30) gesendeten digitalen Unterschrift (MAC) erzeugt und der zweite Server (30) die digitale Unterschrift (MAC) anhand der Transaktions-Identifikationsinformationen (ATC, UN2, H) verifiziert.

6. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei der zweite Server (30) die Autorisiernachricht (ARES) unterschreibt und der erste Server (20) die unterschriebene Autorisiernachricht (ARES) verifiziert, und wobei die Verarbeitung der Transaktions-Nachrichtendaten (17) von der Verifizierung durch den ersten Server (20) abhängt.

7. Vorrichtung zum Verarbeiten einer Datentransaktion zwischen einem Endgerät (14) und einem ersten Server (20) über ein öffentliches Netz (100) sowie zwischen dem ersten Server (20) und dem zweiten Server (30), wobei
das Endgerät (14)
Transaktions-Nachrichtendaten (17) erzeugt,
variable Endgeräte-Kenninformationen (MAC) erzeugt, die das Endgerät (14) identifizieren und für jede Datentransaktion variieren,
die Transaktions-Nachrichtendaten (17) digital unterschreibt,
und
die unterschriebenen Transaktions-Nachrichtendaten (SD) und die Endgeräte-Kenninformationen (MAC) über das öffentliche Netz (100) an den ersten Server (20) überträgt,
der erste Server (20)
die Transaktions-Nachrichtendaten (17) verifiziert und
die Endgeräte-Kenninformationen (MAC) an den zweiten Server (30) überträgt, und
der zweite Server (30)
die Endgeräte-Kenninformationen (MAC) verifiziert und in Abhängigkeit vom Ergebnis eine Transaktions-Autorisiernachricht (ARES) erzeugt,
die Transaktions-Autorisiernachricht (ARES) digital unterschreibt, und
die unterschriebene Transaktions-Autorisiernachricht (ARES) an den ersten Server (20) überträgt.

8. Vorrichtung nach Anspruch 7, wobei der erste Server (20) auch die Vereinbarkeit der Transaktions-Nachrichtendaten (17) verifiziert.

9. Vorrichtung nach Anspruch 7 oder 8, wobei der erste Server (20) die digitale Unterschrift der Transaktions-Nachrichtendaten (F) verifiziert.

10. Vorrichtung nach Anspruch 7 oder 8, wobei das Endgerät (14) die unterschriebenen Transaktions-Nachrichtendaten (SD) auch an den zweiten Server (30) überträgt und dieser die digitale Unterschrift der Transaktions- Nachrichtendaten (17) verifiziert.

11. Vorrichtung nach einem der Ansprüche 7 bis 10, wobei das Endgerät (14) die Endgeräte-Kenninformationen (MAC) digital unterschreibt.

12. Vorrichtung nach Anspruch 11, wobei der zweite Server (30) auch die digitale Unterschrift der Endgeräte-Kenninformationen (MAC) verifiziert.

13. Vorrichtung nach Anspruch 11, wobei der erste Server (20) auch die digitale Unterschrift der Endgeräte-Kenninformationen (MAC) verifiziert.

14. Vorrichtung nach Anspruch 12 oder 13, wobei das Unterschreiben und Verifizieren der Endgeräte-Kenninformationen (MAC) unter Verwendung eines symmetrischen Schlüsselpaares erfolgen.

15. Vorrichtung nach einem der Ansprüche 7 bis 14, wobei
das Endgerät (13) von einem Benutzer (12) eingegebene Benutzer- Identitätsinformationen (ID) an den ersten Server (20) und dieser sie an den zweiten Server (30) überträgt, und
der zweite Server (30) die empfangenen Benutzer-Identitätsinformationen (ID) mit vorher gespeicherten Benutzer-Identitätsinformationen vergleicht, wobei der Inhalt der Autorisiernachricht (ARES) vom Vergleich der Benutzer-Identitätsinformationen (ID) abhängt.

16. Vorrichtung nach einem der Ansprüche 7 bis 15, wobei der erste Server (20) aus der Autorisiernachricht (ARES) und den Transaktions-Identifikationsinformationen (SI) abgeleitete Informationen (ARDEP) einer Datenspeichereinrichtung (50) zuführt.

17. Vorrichtung nach einem der Ansprüche 7 bis 16, wobei das Endgerät (14) eine herausnehmbare Beglaubigungsmarke (18) zum Ableiten der sie identifizierenden Endgeräte-Kenninformationen (MAC) aufweist.

18. Vorrichtung nach einem der Ansprüche 7 bis 16, wobei das Endgerät (14) eine herausnehmbare Beglaubigungsmarke (18) zum Ableiten der digitalen Unterschrift der Transaktions-Nachrichtendaten (17) aufweist.

19. Vorrichtung nach Anspruch 17 oder 18, soweit auf Anspruch 15 rückbezogen, wobei
das Endgerät (14) die Identität des Benutzers (12) und der Marke (18) verifiziert und eine Verifiziernachricht (V) an den zweiten Server (30) überträgt, und
der zweite Server (30) die Autorisiernachricht (ARES) bestimmende Statusinformationen in Abhängigkeit von der Verifiziernachricht (V) speichert.

20. Vorrichtung nach einem der Ansprüche 7 bis 19, wobei der erste Server (20) die Transaktions-Nachrichtendaten (F) je nach der empfangenen Autorisiernachricht (ARES) verarbeitet.

21. Vorrichtung Anspruch 20, wobei der erste Server (20)
aus der Autorisiernachricht (ARES) Annahmekriterien bestimmt,
aus den Transaktions-Nachrichtendaten (17) ein oder mehrere Annahmeparameter bestimmt, und
die Transaktions-Nachrichtendaten (UT) als gültig verarbeitet, wenn ein oder mehrere Annahmeparameter die Annahmekriterien erfüllen.

22. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Übertragungen zwischen dem ersten Server (20) und dem zweiten Server (30) über das öffentliche Netz (100) erfolgen.

23. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei das öffentliche Netz (100) ein Paketübertragungsnetz ist.