DE10258769C5

DE10258769C5 - Kommunikation zwischen einem Bediengerät, einem Anbietermodul und einem Kundenmodul

Info

Publication number: DE10258769C5
Application number: DE10258769.8A
Authority: DE
Inventors: Daniel Ciesinger
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2002-12-16
Filing date: 2002-12-16
Publication date: 2017-08-17
Anticipated expiration: 2022-12-17
Also published as: DE10258769A1; AU2003296651A1; WO2004055744A1; DE10258769B4

Abstract

Verfahren zur Kommunikation zwischen einem Bediengerät (10), einem Anbietermodul (12) und einem als tragbarer Datenträger ausgestalteten Kundenmodul (14) über ein Netzwerk (16), mit den Schritten in der Reihenfolge: – Übertragen (30) einer Anforderung von dem Bediengerät (10) zu dem Anbietermodul (12), – Authentisierung (32, 34) des Anbietermoduls (12) gegenüber dem Kundenmodul (14), indem das Anbietermodul (12) eine gesicherte SSL-Verbindung mit dem Kundenmodul (14) aufweist, – Weiterleiten (36) der Anforderung von dem Anbietermodul (12) an das Kundenmodul (14), – Übertragen (40) einer Antwort auf die Anforderung von dem Kundenmodul (14) zu dem Anbietermodul (12), und – Weiterleiten (42) der Antwort von dem Anbietermodul (12) an das Bediengerät (10).

Description

Die Erfindung betrifft allgemein das Gebiet der elektronischen Kommunikation und insbesondere das Gebiet des gesicherten Umgangs mit Daten bei Transaktionen zwischen einem Anbieter und einem Kunden. Ferner betrifft die Erfindung den Einsatz mindestens eines tragbaren Datenträgers, z. B. einer Chipkarte (smart card), in diesem Zusammenhang.
In der internationalen Offenlegungsschrift WO 97/02548 A1 ist ein Bezahlsystem offenbart, das auch unter der Marke Mondex bekanntgeworden ist. Bei diesem System kommunizieren ein Kundenmodul und ein in einem Bediengerät befindliches Anbietermodul über ein proprietäres Protokoll miteinander, um eine virtuelle Zahlung vom Kundenmodul zum Anbietermodul zu übermitteln. Dieses System erfordert jedoch spezielle Hard- und Software und ist auf das Gebiet des bargeldlosen Zahlungsverkehrs beschränkt.
Aus den Offenlegungsschriften US 2001/0007129 A1 sowie WO 00/79411 A2 sind Verfahren bekannt, welche die Kommunikation zwischen einem Bediengerät, einem Anbietermodul und einem Kundenmodul erlauben. Die genannten Verfahren und Systeme lassen eine Kommunikation zwischen Bediengerät, Anbietermodul und Kundenmodul über gängige Netzwerke zu. Ein proprietäres Protokoll wird nicht benötigt.
In dem Bericht ”Webcard: A Java Card Web Server” von Jim Rees und Peter Honeyman, herausgegeben vom Center for Information Technology Integration, University of Michigan, Ann Arbor, USA, CITI Technical Report 99-3, ist eine Chipkarte beschrieben, die als Webserver programmiert ist und die wesentliche Funktionen der Internet-Protokolle TCP/IP und HTTP auszuführen vermag. Eine konkrete Anwendung dieser Technik ist nicht offenbart.
Der Artikel ”Aus der Chipkarte wird eine Patientenakte mit allen relevanten Angaben” in der Zeitschrift Forum – Arzt in Nordbaden –, herausgegeben von der Kassenärztlichen Vereinigung Nordbaden, Ausgabe 1/2002, Seite 25, beschreibt Pläne zur Einführung elektronischer Rezepte. Die Verordnungen des Arztes werden auf einer Chipkarte des Patienten gespeichert und in der Apotheke ausgelesen. Bei einer solchen Nutzung von Chipkarten ist es erforderlich, die persönlichen Daten des Patienten – insbesondere alle Informationen, die den Gesundheitszustand des Patienten betreffen – höchst vertraulich zu behandeln. So soll beispielsweise sichergestellt werden, daß die auf der Chipkarte gespeicherten Verordnungen nur von autorisierten Personen gelesen werden können.
Die Erfindung hat die Aufgabe, eine Technik zur Kommunikation zwischen einem Bediengerät, einem Anbietermodul und einem Kundenmodul bereitzustellen, die einerseits eine hohe Flexibilität für eine Vielzahl möglicher Anwendungen und andererseits eine gute Absicherung gegen unbefugte Benutzung bietet. In bevorzugten Ausgestaltungen soll die Erfindung ferner kostengünstig realisierbar sein.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren mit den Merkmalen von Anspruch 1, ein Anbietermodul, ein Kundenmodul und ein Computerprogrammprodukt.
Die Erfindung geht von der Grundidee aus, das Anbietermodul einerseits zur Vermittlung eines Datenaustauschs zwischen dem Bediengerät und dem Kundenmodul und andererseits zur Authentisierung gegenüber dem Kundenmodul einzusetzen. Durch diese Maßnahme wird ein System geschaffen, bei dem das Kundenmodul vor der Ausgabe vertraulicher Informationen erst die Berechtigung der abfragenden Stelle überprüfen kann. Ferner ermöglicht es die erfindungsgemäße Systemstruktur, Kunden- und Anbietermodule einzusetzen, die von einem Client-Server-Kommunikationsmodell mit Anforderungen (requests) und Antworten (responses) ausgehen. Solche Module sind in vielfältigen Ausgestaltungen verfügbar.
Die im vorliegenden Dokument verwendete Wortwahl ”Anbietermodul” und ”Kundenmodul” bezeichnet die Rolle der Nutzer dieser Module in typischen Anwendungen. In der Regel ist das Anbietermodul einem Anbieter von Gütern, Dienstleistungen oder immateriellen Leistungen zugeordnet, beispielsweise einem Händler, einem Apotheker, einem Arzt, einer Ausgabestelle für Bonuspunkte und so weiter. Das Kundenmodul ist dagegen im Besitz des Nachfragenden. Diese typischen Rollen sind jedoch nur als Beispiele und nicht als Einschränkung des Schutzbereichs zu verstehen. Es sollen vielmehr vorzugsweise alle Module, die eine Authentisierung anfordern können, als Kundenmodule im Sinne der vorliegenden Erfindung angesehen werden, und alle Module, die sich zu authentisieren vermögen, als Anbietermodule.
Die Erfindung ist besonders flexibel, weil sie das sicherheitskritische Authentisierungsverfahren von der eigentlichen Anwendung – z. B. der Rezeptabgabe oder der Verwaltung von Bonuspunkten – trennt. Dadurch kann die Anwendung mit deutlich geringerem Aufwand und mit deutlich größeren Freiheiten als bei bisher bekannten Systemen entwickelt werden. Ferner ermöglicht es die Erfindung, die Interaktion zwischen dem Anbietermodul, z. B. einer Händlerkarte, und dem Kundenmodul über ein lokales oder globales Netzwerk, z. B. das Internet, ohne Medienbruch zu realisieren. Neben den bereits geschilderten Anwendungsmöglichkeiten kann das erfindungsgemäße System prinzipiell auch als System zum bargeldlosen Bezahlen oder als Geldbörsensystem – ähnlich wie das bereits genannte Mondex-System oder die in Deutschland bekannte GeldKarte – eingesetzt werden.
Erfindungsgemäß ist das Kundenmodul als tragbarer Datenträger ausgestaltet, und auch das Anbietermodul kann in bevorzugten Ausführungsformen ein tragbarer Datenträger sein. Beispiele für tragbare Datenträger sind insbesondere Chipkarten mit eigener Intelligenz (smart cards), die in Kreditkartengröße oder in kompakten Bauformen, wie z. B. Mobiltelefon-SIMs, ausgestaltet sein können. Der tragbare Datenträger kann jedoch auch eine nicht-kartenförmige Baugruppe, wie z. B. ein USB-Dongle, sein. In weiteren Ausführungsvarianten ist das Anbietermodul ein auf einem sicheren Server ausgeführtes Programm, das die Funktion eines physischen Anbietermoduls simuliert und daher als ”virtuelles Anbietermodul” bezeichnet wird.
In bevorzugten Ausgestaltungen erfolgt die Kommunikation zwischen dem Bediengerät und dem Anbietermodul und/oder zwischen dem Anbietermodul und dem Kundenmodul über mindestens ein Internet-Protokoll. Beispiele für solche Internet-Protokolle sind TCP/IP (Transmission Control Protocol/Internet Protocol), UDP/IP (User Datagram Protocol/Internet Protocol), IPSec (IP Security Protocol), TLS (Transport Layer Security), SSL (Secure Sockets Layer), HTTP (Hypertext Transfer Protocol) und S-HTTP (Secure HTTP). Die Authentisierung des Anbietermoduls gegenüber dem Kundenmodul kann in manchen Ausführungsformen der Erfindung mittels HTTP Digest Authentication oder mittels SSL Client Authentication erfolgen. Die genannten Protokolle sind an sich gut bekannt und in den entsprechenden RFC-Normen bzw. anderen Dokumenten im Detail beschrieben. Die Protokolle als solche sind nicht Gegenstand der vorliegenden Erfindung.
Vorzugsweise ist neben der Authentisierung des Anbietermoduls gegenüber dem Kundenmodul auch eine Authentisierung des Kundenmoduls gegenüber dem Anbietermodul vorgesehen. In weiteren bevorzugten Ausgestaltungen erfolgt die Datenübertragung zwischen dem Anbietermodul und dem Kundenmodul in gesicherter, z. B. verschlüsselter, Form. Insbesondere kann ein einmal aufgebauter gesicherter Datenübertragungsweg ohne nochmalige Authentisierung für eine Mehrzahl von Kommunikationsvorgängen zwischen dem Anbietermodul und dem Kundenmodul verwendet werden. Auch bei der Kommunikation zwischen dem Bediengerät und dem Anbietermodul kann in manchen Ausgestaltungen der Erfindung eine Authentisierung eines oder beider Kommunikationspartner und/oder eine Verschlüsselung der übertragenen Nachrichten erfolgen.
Das erfindungsgemäße Computerprogrammprodukt weist Programmbefehle auf, um das erfindungsgemäße Verfahren in einem Datenträger zu implementieren bzw. auszuführen. Ein derartiges Computerprogrammprodukt kann ein körperliches Medium sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das ComputerproComputerprogrammprodukt ein Datenträger-Betriebssystem oder ein Teil davon oder ein zur Ausführung durch den Datenträger vorgesehenes Programm sein.
Das Anbietermodul, das Kundenmodul und das Computerprogrammprodukt weisen in bevorzugten Weiterbildungen Merkmale auf, die den oben erwähnten und/oder den in den abhängigen Verfahrensansprüchen genannten Merkmalen entsprechen.
Weitere Merkmale, Aufgaben und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung eines Ausführungsbeispiels der Erfindung und mehrerer Ausführungsalternativen. Es wird auf die schematischen Zeichnungen verwiesen, in denen zeigen:
1 ein Blockdiagramm mit Komponenten eines Ausführungsbeispiels der Erfindung, und
2 ein beispielhaftes Ablaufdiagramm eines Kommunikationsvorgangs.
In 1 sind ein Bediengerät 10, ein Anbietermodul 12 und ein Kundenmodul 14 gezeigt, die an ein Netzwerk 16 angeschlossen sind. Das Bediengerät 10 ist in dem gezeigten Ausführungsbeispiel ein persönlicher Computer (PC) mit Eingabemitteln, wie z. B. einer Tastatur und einer Maus, und Ausgabemitteln, wie z. B. einem Bildschirm. Das Bediengerät 10 führt einen Internet-Browser, wie z. B. den unter der Marke Internet Explorer bekannten Browser, aus. In 1 ist dieser Browser symbolisch durch ein auf dem Bildschirm des Bediengeräts 10 angezeigtes Browserfenster 18 dargestellt. In Ausführungsalternativen kann das Bediengerät 10 auch anders ausgestaltet sein, z. B. als kompaktes Gerät mit einer Anzeige und einem Tastenfeld.
Das Anbietermodul 12 und das Kundenmodul 14 sind als je ein tragbarer Datenträger ausgebildet. Im vorliegenden Ausführungsbeispiel ist jeder dieser Datenträger eine Chipkarte, die in an sich bekannter Weise einen Halbleiterchip mit einem Prozessorkern, mehreren in unterschiedlichen Technologien ausgestalteten Speicherfeldern und einer Schnittstelle zur drahtgebundenen oder drahtlosen Kommunikation aufweist. Die Datenträger sind über je ein Schnittstellengerät 20, 22 an das Netzwerk 16 angeschlossen. In 1 sind die Schnittstellengeräte 20, 22 als externe Geräte gezeigt. In Ausführungsalternativen ist dagegen vorgesehen, das Schnittstellengerät 20 und/oder das Schnittstellengerät 22 in das Bediengerät 10 zu integrieren. Das Anbietermodul 12 kann fest oder herausnehmbar in das Bediengerät 10 eingebaut sein, während das Kundenmodul 14 in der Regel leicht in das Schnittstellengerät 22 eingeführt und wieder entnommen werden kann.
Im vorliegenden Ausführungsbeispiel ist sowohl das Anbietermodul 12 als auch das Kundenmodul 14 als Internet-Smartcard ausgebildet, also als Chipkarte, in welcher ein Internet-Protokollstapel implementiert ist. Der Internet-Protokollstapel umfaßt beispielsweise die Internet-Protokolle TCP/IP für die Transport- und Netzwerkschicht und HTTP für die Anwendungsschicht, wobei auf die Transportschicht eine Sicherungsschicht, die SSL verwendet, aufgesetzt ist. Es können jedoch auch andere oder zusätzliche Protokolle, insbesondere für Sicherungs- und Authentisierungszwecke, eingesetzt werden.
Das Netzwerk 16 ist ein lokales TCP/IP-Netzwerk, das entweder von der Außenwelt getrennt oder – über geeignete Schutzvorrichtungen – mit dem Internet verbunden sein kann. Insbesondere in Ausgestaltungen, bei denen eines oder beide Schnittstellengeräte 20, 22 in das Bediengerät 10 integriert ist bzw. sind, kann das Netzwerk 16 lediglich eine oder zwei Punkt-zu-Punkt-Verbindungen zwischen dem Bediengerät 10 und dem Anbietermodul 12 und/oder zwischen dem Anbietermodul 12 und dem Kundenmodul 14 aufweisen.
Der Browser kann beispielsweise durch Eingabe der IP-Adresse in der Adressenliste des Browsers direkt auf das Anbietermodul 12 zugreifen. Das Anbietermodul 12 präsentiert dann eine Webseite, die die Auswahl verschiedener Transaktionen und die Eingabe der Netzwerkparameter des Kundenmoduls gestatten. In einem ersten, ggf. einmaligen Schritt werden die Netzwerkparameter der Kundenmoduls 14 eingestellt, dann wird eine Transaktion ausgewählt, woraufhin das Anbietermodul 12 eine Netzwerkverbindung zum Kundenmodul 14 herstellt, sich authentisiert und den für die Transaktion erforderlichen Anweisungen samt Parametern in das Kundenmodul übermittelt. Daraufhin übermittelt das Kundenmodul 14 die angeforderten Daten an das Anbietermodul 12, welches die erhaltenen Daten verarbeitet und eine geeignete Erfolgsmeldung an den Browser übermittelt.
Alternativ wird zum Betrieb der auf dem Bediengerät 10 laufende Browser so konfiguriert, daß er das Anbietermodul 12 als Proxy für die Kommunikation mit dem Kundenmodul 14 verwendet. Dazu wird eine Adresse des Anbietermoduls 12 in ein zur Einrichtung von Proxies vorgesehenes Konfigurationsfeld des Browsers eingetragen. Namenskonflikte können bei einem lokalen Netzwerk 16 nicht auftreten. Der Browser leitet dann alle eigentlich an das Kundenmodul 14 gerichteten Anforderungen an das Anbietermodul 12. Auch das Anbietermodul 12 wird so konfiguriert, daß es über das lokale Netzwerk 16 auf das Kundenmodul 14 zuzugreifen vermag und als Proxy gegenüber dem Kundenmodul 14 arbeitet.
Um das Kundenmodul 14 anzusprechen, wird die Adresse des Kundenmoduls 14 (z. B. http://kunde.local) in die Adressleiste des auf dem Bediengerät 10 laufenden Browsers eingegeben. Der Browser sendet daraufhin eine Anforderung (request) an das als Proxy dienende Anbietermodul 12. Wenn die Anforderung keinen Zugriff auf besonders geschützte Daten beinhaltet, kann sie ohne weiteres vom Anbietermodul 12 an das Kundenmodul 14 weitergeleitet werden.
Das Kundenmodul 14 arbeitet als Internet-Server und reagiert auf die eingehende HTTP-Anforderung mit einer geeigneten HTTP-Antwort (response). Beispielsweise kann die Antwort ein HTML-Dokument enthalten, das Auswahlfelder für mehrere von dem Kundenmodul 14 angebotene Operationen definiert. Die Antwort wird über das Anbietermodul 12 an das Bediengerät 10 geleitet. Dort zeigt der Browser das vom Kundenmodul 14 stammende HTML-Dokument am Bildschirm an. In dem in 1 dargestellten Browserfenster 18 ist ein Ausschnitt des HTML-Dokuments sichtbar, der als einziges Auswahlfeld die vom Kundenmodul 14 angebotene Operation ”Rezept ausgeben” enthält.
In Reaktion auf jede Auswahl einer Operation – z. B. durch Anklicken des entsprechenden Auswahlfeldes im Browserfenster 18 – generiert der Browser eine neue Anforderung, die das Bediengerät 10 an das Anbietermodul 12 sendet. 2 zeigt einen beispielhaften Ablauf, der ausgeführt wird, wenn diese Anforderung vertrauliche Daten betrifft. Dies ist beispielsweise bei der Operation ”Rezept ausgeben” einer Patientenkarte der Fall, weil das gespeicherte Rezept nur berechtigten Personen – z. B. Apothekern – zugänglich gemacht werden soll. Die bei Auswahl der Operation ”Rezept ausgeben” erzeugte Anforderung ist als sicherheitskritisch gekennzeichnet, z. B. dadurch, daß in ihr als Protokoll nicht ”http:”, sondern ”https:” angegeben ist. Schritt 30 in 2 betrifft das Übertragen dieser Anforderung vom Bediengerät 10 an das Anbietermodul 12.
Das Anbietermodul 12 analysiert die eingehende Anforderung und stellt fest, daß eine Authentisierung beim Kundenmodul 14 erforderlich ist, weil sonst das Kundenmodul 14 die Anforderung nicht beantworten würde. Das Anbietermodul 12 führt daraufhin die Authentisierung durch. Dies geschieht im vorliegenden Ausführungsbeispiel in den in 2 nur schematisch gezeigten Kommunikationsschritten 32 und 34, indem das Anbietermodul 12 eine gesicherte SSL-Verbindung mit dem Kundenmodul 14 aufbaut. Das Anbietermodul 12 bildet dabei den Client, und das Kundenmodul 14 bildet den Server.
Im Zusammenhang mit dem Aufbau der SSL-Verbindung wird – neben einer Authentisierung des Servers beim Client und neben der Vereinbarung eines Sitzungsschlüssels für die weitere, verschlüsselt ablaufende Kommunikation – auch eine Authentisierung des Client beim Server durchgeführt, die als SSL Client Authentication bekannt ist. Für diese Authentisierung kann z. B. ein an sich bekanntes Challenge-Response-Verfahren eingesetzt werden. Hierbei erhält der Client vom Server Daten – den sogenannten Challenge – die der Client in einer kryptographischen Operation unter Verwendung eines privaten Schlüssels des Client verarbeitet. Das Ergebnis sendet der Client an den Server, der daraufhin unter Verwendung des komplementären, öffentlichen Schlüssels des Client überprüft, ob der Client tatsächlich in Besitz des korrekten privaten Schlüssels ist.
Die bei der SSL-Authentisierung verwendeten Schlüssel der Anbietermodule 12 werden von vertrauenswürdigen Organisationen – sogenannten Trustcentern – ausgestellt. Die Trustcenter sind auch im Kundenmodul 14 als vertrauenswürdig eingetragen. Eine solche unter der Bezeichnung Public Key Infrastructure (PKI) bekannte Schlüsselverwaltung ist insbesondere dann erforderlich, wenn einer Gruppe von Händlern oder Dienstleistungsanbietern Zugriff auf Kundenmodule 14 ermöglicht werden soll.
In Ausführungsalternativen sind andere Authentisierungsverfahren vorgesehen, z. B. die an sich bekannte HTTP Digest Authentication. Allgemein sollen diese Verfahren sicherstellen, daß keine unberechtigte Person ein funktionierendes Anbietermodul 12 herstellen kann. Eine Authentisierung des Servers beim Client und der Aufbau eines verschlüsselten Kommunikationsweges sind nur für manche Anwendungen erforderlich, so daß in Ausführungsalternativen auf eines dieser Merkmale oder auf beide verzichtet werden kann.
Nachdem die Authentisierung erfolgreich abgeschlossen ist, leitet das Anbietermodul 12 in Schritt 36 die Anfrage an das Kundenmodul 14 weiter. Das Kundenmodul 14 bearbeitet die Anfrage und erzeugt in Schritt 38 die gewünschte Antwort. Dies kann z. B. eine HTTP-Antwort mit dem im Kundenmodul 14 gespeicherten Rezept in Form eines HTML-Dokuments sein. Die Antwort wird in Schritt 40 vom Kundenmodul 14 an das Anbietermodul 12 übertragen und in Schritt 42 vom Anbietermodul 12 an das Bediengerät 10 weitergeleitet. Dort wird das in der Antwort enthaltene HTML-Dokument in Schritt 44 vom Browser im Browserfenster 18 angezeigt.
Es können sich nun weitere Kommunikationsschritte anschließen, die jeweils eine vom Bediengerät 10 über das Anbietermodul 12 zum Kundenmodul 14 geleitete Anforderung und eine vom Kundenmodul 14 über das Anbietermodul 12 zum Bediengerät 10 geleitete Antwort aufweisen. Eine nochmalige Authentisierung ist in der Regel nicht erforderlich, insbesondere dann nicht, wenn – wie im vorliegenden Ausführungsbeispiel – im Zuge der ersten Authentisierung ein gesicherter Datenübertragungsweg zwischen dem Anbietermodul 12 und dem Kundenmodul 14 aufgebaut wurde. Es sind jedoch auch Ausführungsalternativen vorgesehen, bei denen das in 2 gezeigte Verfahren einschließlich der Authentisierung für jedes Anforderungs-Antwort-Paar wiederholt wird.
Im hier beschriebenen Ausführungsbeispiel ist das Anbietermodul 12 dazu eingerichtet, die vom Bediengerät 10 eingehenden Anforderungen zu überwachen und vor dem Weiterleiten der ersten sicherheitskritischen Anforderung die Authentisierung in den Schritten 32 und 34 anzustoßen. Es sind auch Ausführungsalternativen vorgesehen, in denen das Anbietermodul 12 zunächst alle eingehenden Anforderungen an das Kundenmodul 14 weiterleitet und den Authentisierungsvorgang erst in Reaktion auf eine Fehlermeldung oder eine sonstige Authentisierungsaufforderung des Kundenmoduls 14 beginnt. Ferner sind Ausführungsvarianten denkbar, in denen das Anbietermodul 12 sich stets beim Kundenmodul 14 authentisiert – gegebenenfalls in Zusammenhang mit dem Aufbau eines gesicherten Datenübertragungskanals –, bevor es seine Tätigkeit als Proxy für die Vermittlung von Nachrichten zwischen dem Bediengerät 10 und dem Kundenmodul 14 beginnt.
Ebenso sind insbesondere für Online-Händler Ausführungen sinnvoll, bei denen mittels Browser auf das Kundenmodul 14 zugegriffen wird und dieses daraufhin eine Kommunikation mit dem Anbietermodul 12 initiiert.
In einer alternativen Ausgestaltung des in 1 gezeigten Systems ist das Anbietermodul 12 als virtuelles Anbietermodul ausgestaltet. Dies heißt, daß die Funktionen des Anbietermoduls 12 von einem Programm simuliert werden, das von einem gesicherten, in den Figuren nicht gezeigten Server ausgeführt wird. Der gesicherte Server ist über das Netzwerk 16 – entweder lokal oder über ein virtuell-privates Netz (VPN) oder über einen gesicherten Datenübertragungskanal im Internet – erreichbar. Das virtuelle Anbietermodul, das von dem gesicherten Server bereitgestellt wird, kommuniziert dann ebenso wie in dem in 2 gezeigten Ablauf mit dem Bediengerät 10 und dem Kundenmodul 14 und führt die erforderliche Authentisierung gegenüber dem Kundenmodul 14 durch. Es kann insbesondere vorgesehen sein, daß der gesicherte Server eine Mehrzahl von virtuellen Anbietermodulen – für einen einzigen oder für mehrere Anbieter – bereitstellt.

Claims

Verfahren zur Kommunikation zwischen einem Bediengerät (10), einem Anbietermodul (12) und einem als tragbarer Datenträger ausgestalteten Kundenmodul (14) über ein Netzwerk (16), mit den Schritten in der Reihenfolge: – Übertragen (30) einer Anforderung von dem Bediengerät (10) zu dem Anbietermodul (12), – Authentisierung (32, 34) des Anbietermoduls (12) gegenüber dem Kundenmodul (14), indem das Anbietermodul (12) eine gesicherte SSL-Verbindung mit dem Kundenmodul (14) aufweist, – Weiterleiten (36) der Anforderung von dem Anbietermodul (12) an das Kundenmodul (14), – Übertragen (40) einer Antwort auf die Anforderung von dem Kundenmodul (14) zu dem Anbietermodul (12), und – Weiterleiten (42) der Antwort von dem Anbietermodul (12) an das Bediengerät (10).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Anbietermodul (12) weitere von dem Bediengerät (10) stammende Anfragen an das Kundenmodul (14) weiterleitet und weitere von dem Kundenmodul (14) stammende Antworten an das Bediengerät (10) weiterleitet.
Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß neben der Authentisierung (32, 34) des Anbietermoduls (12) gegenüber dem Kundenmodul (14) auch eine Authentisierung des Kundenmoduls (14) gegenüber dem Anbietermodul (12) und/oder der Aufbau eines gesicherten Datenübertragungsweges zwischen dem Anbietermodul (12) und dem Kundenmodul (14) erfolgt.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Anbietermodul (12) und das Kundenmodul (14) über ein Internet-Protokoll, insbesondere mindestens eines der Protokolle TCP/IP, UDP/IP, IPSec, TLS, SSL, HTTP und S-HTTP, miteinander kommunizieren.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die Authentisierung (32, 34) des Anbietermoduls (12) gegenüber dem Kundenmodul (14) mittels HTTP Digest Authentication oder mittels SSL Client Authentication erfolgt.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß das Bediengerät (10) und das Anbietermodul (12) über ein Internet-Protokoll, insbesondere mindestens eines der Protokolle TCP/IP, UDP/IP, IPSec, TLS, SSL, HTTP und S-HTTP, miteinander kommunizieren.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das Anbietermodul (12) als tragbarer Datenträger oder als virtuelles Anbietermodul ausgestaltet ist.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß zunächst das Bediengerät (10) eine Anforderung an das Kundenmodul (14) schickt und diese daraufhin die Kommunikation mit dem Anbietermodul (12) beginnt.
Anbietermodul (12), insbesondere in Form eines tragbaren Datenträgers, das dazu eingerichtet ist, mit einem externen Bediengerät (10) und einem externen Kundenmodul (14) über ein Netzwerk (16) zu kommunizieren, wobei das Anbietermodul (12) einen Datenaustausch zwischen dem Bediengerät (10) und dem Kundenmodul (14) vermittelt und zusätzlich dazu eingerichtet ist, sich gegenüber dem Kundenmodul (14) zu authentisieren, dadurch gekennzeichnet, daß das Anbietermodul (12) ausgestaltet zum Einsatz in einem Verfahren nach einem der Ansprüche 1 bis 7 ist.
Kundenmodul (14), das in Form eines tragbaren Datenträgers ausgestaltet ist und ausgestaltet zum Einsatz in einem Verfahren nach einem der Ansprüche 1 bis 8 ist.
Computerprogrammprodukt, das Programmbefehle aufweist, um einen tragbaren Datenträger als Anbietermodul (12) gemäß Anspruch 9 oder als Kundenmodul (14) gemäß Anspruch 10 zu konfigurieren.