Die vorliegende Erfindung betrifft ein Verfahren, um elektronische Zertifikate in Mobilgeräten zu verifizieren und ein entsprechendes Identifizierungsmodul.

Es sind schon asymmetrische kryptographische Verfahren bekannt, die benutzt werden können, um Kommunikationspartner in einem Mobilfunknetz, beispielsweise in einem GSM-Netz, zu authen- tisieren. Solche Verfahren basieren beispielsweise auf dem RSA Algo- rithmus.

Die Figur 1 zeigt in schematischer Weise einen Authentisierungs- vorgang. Wenn die erste Entität 1 eine zweite Entität 2, beispielsweise einen Kommunikationspartner, authentisieren will, muss sie diese zweite Entität bitten, zu beweisen, dass sie einen privaten Schlüssel besitzt.

Obwohl der private Schlüssel nur der zweiten Entität bekannt ist, verfügt 1 über den öffentlichen Schlüssel von 2, mit welchem geprüft werden kann, dass 2 den privaten Schlüssel von 2 verwendet hat.

Um diesen Beweis zu erbringen kann beispielsweise die Entität 2 eine Zufallszahl 3 von 1 (Challenge) verschlüsseln, die beiden Parteien bekannt ist. Typischerweise wird die Zufallszahl von 1 erzeugt und nach 2 geschickt ; 1 erwartet von 2, dass 2 diese Zufallszahl mit ihrem privaten Schlüssel signiert und dass 2 mit dieser Signatur 4 antwortet. Die Signatur 4 kann dann von 1 mit dem öffentlichen Schlüssel von 2 verifiziert werden.

Das Challenge kann auch implizit beiden Parteien bekannt sein, so dass nur die zweite Meldung 4 geschickt werden muss. Wenn beide Enti- täten 1,2 über eine synchronisierte Uhr verfügen, kann man beispielsweise die Zeit als Challenge verwenden. Wichtig ist vor allem, dass ein Challenge 3 nie zweimal benutzt wird.

Die erste Entität 1 kann auch den öffentlichen Schlüssel von der zweiten Entität 2 verwenden, um Daten zu verschlüsseln, die nur mit dem privaten Schlüssel von 2 entschlüsselt werden können. Auf diese Weise können beispielsweise Session-Keys (oder Datenelemente, die dann erlauben, einen Session-Key abzuleiten) von 1 verschlüsselt werden und an 2 geschickt werden. Wenn 2 später diesen Session Key verwendet, um Daten mit einem symmetrischen Algorithmus zu verschlüsseln, beweist sie auch, dass sie den für die Entschlüsselung dieses Session Keys benötigten privaten Schlüssel tatsächlich besitzt ; sie wird damit auch authentifiziert.

Der Session Key kann beispielsweise während einer Session verwendet werden.

Selbstverständlich kann auch 2 mit diesem Mechanismus 1 und mit dem Schlüsselpaar von 1 authentifizieren.

Die erste Entität 1 muss sicher sein, dass der öffentliche Schlüssel, den sie benutzt, tatsächlich zur Entität 2 gehört. Um die Echtheit dieses Schlüssels überprüfbar zu machen, kann man Zertifikate benutzen, die von einer Zertifizierungsinstanz (CA-Certification Authority) herausgegeben werden.

Die Figur 2 zeigt ein Beispiel von einem solchen Schlüsseizertifikat 5. Das Zertifikat 5 ist ein elektronisches Dokument, welches ausser dem öffentlichen Schlüssel 51 des Benutzers üblicherweise auch seinen Name 50 und den Namen der Zertifizierungsinstanz 52 die das Zertifikat herausgegeben hat, umfasst. Mit einer Hashfunktion 6 wird der Hashwert 7 beispielsweise der Parameter 50,51,52 ermittelt ; dieser Wert 7 wird dann von der Zertifizierungsinstanz anhand eines asymmetrischen kryptographischen Algorithmus 9, beispielsweise RSA, mit dem privaten Schlüssel 8 der Zertifizierungsinstanz signiert und die Signatur 53 wird in das Zertifikat 5 kopiert.

Jede Drittpartei kann dann mit dem öffentlichen Schlüssel 12 der Zertifizierungsinstanz prüfen, ob die digitale Signatur 53 wirklich von der Zertifizierungsinstanz 8 ausgegeben wurde (Figur 3). Zu diesem Zweck muss

der Hashwert 7 der Parameter 50 bis 52 ermittelt werden und mit dem Hashwert 10 verglichen werden, welcher aus der Signatur 53 mit dem öffentlichen Schlüssel 12 der Zertifizierungsinstanz ermittelt wird. Sind die beide Hashwerte gleich und vertraut man der Zertifizierungsinstanz, kann das Zertifikat 5 als echt betrachtet werden. Eine Drittpartei, die über den öffentlichen Schlüssel 12 der Zertifizierungsinstanz verfügt, kann auf diese Weise prüfen, ob der im Zertifikat 5 angegebene öffentliche Schlüssel 51 tatsächlich dem identifizierten Partner gehört.

So kommt man aber zurück zum ursprünglichen Problem : wie kann man sicher sein, dass der öffentliche Schlüssel 12 den man hat tatsächlich der Zertifizierungsinstanz gehört und nicht verfälscht wurde ? Zu diesem Zweck wird mindestens ein öffentlicher Schlüssel benötigt, dem man trauen kann und der zur Überprüfung aller anderen Zertifikate verwendet werden kann.

Ein solcher"Ursprungsschlüssel"kann beispielsweise in einem selbst signierten"Ursprungszertifikat"abgelegt werden. Der öffentliche Schlüssel, der im Ursprungszertifikat angegeben ist, kann verwendet werden, um dieses Ursprungszertifikat zu überprüfen.

Ein Ziel dieser Erfindung ist es, ein neues Verfahren vor- zuschlagen, um solche"Ursprungszertifikate"an Benutzer von Mobilgeräten, insbesondere von Mobilfunktelefonen, zu verteilen.

In der Computerbranche ist es schon bekannt, eine Liste von Ursprungszertifikaten verschiedener Zertifizierungsinstanzen in kommer- ziellen Browsern abzulegen. Ein Computerbenutzer der einen Browser in seinen Rechner installiert, kopiert damit automatisch diese Liste von Zertifikaten. Wurde jedoch der Browser aus einer nicht vertrauenswürdigen Quelle kopiert, beispielsweise über das Internet, kann nicht ausgeschlossen werden, dass diese Liste verfälscht wurde. Ausserdem können neue Ursprungszertifikate nach der Installation des Browsers nur mit viel Aufwand addiert werden.

Will eine Zertifizierungsinstanz durch dieses Verteilungsverfahren ihre Zertifikate schnell und breit bekannt machen, muss sie mit jedem Browserhersteller verhandeln, damit die Zertifikate in die neuen Versionen jedes Browsers kopiert werden. Es kann aber Monate oder gar Jahre dauern, bevor eine breite Basis von Benutzern eine Browserversion installiert haben.

Es wurde auch suggeriert, Ursprungszertifikate im Mobilgerät selbst abzulegen. Für eine Zertifizierungsinstanz ist es jedoch noch schwieriger, ein Zertifikat schnell in viele Mobilgeräte verschiedener Hersteller zu verteilen.

Elektronische Zertifikate wurden ausserdem in gespeicherte Speicherbereiche von SIM-Karten kopiert. Dadurch entsteht für eine Zertifizierungsinstanz eine Abhängigkeit gegenüber den SIM-Karten Herausgeber. Ausserdem sind Mobilteilnehmer nicht gerne bereit, ihre persönliche SIM-Karte, in welcher auch persönliche Daten wie Telefonnummerverzeichnisse gespeichert sind, zu ersetzen, nur um ihre Liste von Zertifikaten zu aktualisieren.

Ein Ziel der Erfindung ist es, ein neues Verteilungssystem anzubieten, das eine schnelle Verteilung von Zertifikaten erlaubt.

Ein anderes Ziel ist es, ein neues Verfahren anzubieten, um von einer Zertifizierungsinstanz herausgegebene elektronische Zertifikate in einem Mobilgerät zu verifizieren.

Gemäss der vorliegenden Erfindung werden diese Ziele ins- besondere durch die Merkmale der unabhängigen Ansprüche erreicht.

Weitere vorteilhafte Ausführungsformen gehen ausserdem aus den ab- hängigen Ansprüchen und der Beschreibung hervor.

Insbesondere werden diese Ziele durch ein Verfahren erreicht, in welchem eine Referenz zum elektronischen Zertifikat der Zertifizierungs-

instanz ("Ursprungszertifikat") in einem zweiten Modul des Mobilgeräts gespeichert wird.

Das zweite Modul kann beispielsweise aus einer zweiten Chip- karte bestehen, die neben der ersten Chipkarte in einem zweiten Karten- Slot eines"Dual-Slots"Mobilgeräts eingeschoben werden kann.

Dies hat den Vorteil, dass elektronische Zertifikate schnell und einfach verteilt werden können, indem neue Module angeboten werden.

Mobilteilnehmer, die ein solches neues Zertifikat brauchen, beispielsweise um eine neue gesicherte Anwendung zu benutzen oder um mit einem neuen Partner zu kommunizieren, können es auf sehr einfache Weise installieren, indem sie nur ein neues Modul in ihr Mobilgerät einschieben.

Im Folgenden werden anhand der beigefügten Zeichnung bevor- zugte Ausführungsbeispiele der Erfindung näher beschrieben : Die oben beschriebene Figur 1 zeigt ein Authentisierungsschema basierend auf asymmetrischer Kryptographie.

Die oben beschriebene Figur 2 zeigt in schematischer Weise die Herstellung eines Schlüsseizertifikats.

Die oben beschriebene Figur 3 zeigt in schematischer Weise die Überprüfung eines Zertifikats.

Die Figur 4 zeigt ein"Dual-Slot"Mobilgerät.

Die Figur 5 zeigt das gleiche"Dual-Slot"Mobilgerät in schematischer Weise.

Die Figuren 6 bis 13 zeigen in schematischer Weise den Kommunikationsfluss zwischen dem Mobitgerät und den zwei Modulen in acht verschiedenen Ausführungsformen der Erfindung.

Obwohl diese Erfindung in mehreren Details den speziellen Fall der Ausführung in einem GSM-Mobilfunknetz beschreibt, wird der Fach- mann verstehen, dass dieses Verfahren auch mit anderen Typen von Funk- netzen, beispielsweise mit AMPS, TDMA, CDMA, TACS, PDC, HSCSD, GPRS, EDGE oder UMTS-Mobilfunknetzen eingesetzt werden kann, insbesondere mit WAP- (Wireless Application Protocol) fähigen Mobilfunknetzen. Diese Erfindung kann ausserdem in anderen Netzen, insbesondere im Internet, verwendet werden.

Die Figur 4 zeigt ein Mobilgerät 13, in diesem Beispiel ein Mobil- funktelefon, das für die Erfindung eingesetzt werden kann. Dieses Gerät weist Eingabemittel 19 (hier eine Tastatur), Wiedergabemittel 18 und 20 (hier eine LCD-Anzeige und einen Lautsprecher), ein Slot für ein konventionelles Identifizierungsmodul, beispielsweise eine SIM-Karte (Subscriber Identification Module), ein SIM-Modul oder eine SlM/WIM-Karte (WAP Identification Module) 16, sowie ein Slot für ein zweites Modul 14, beispielsweise in der Form einer Chipkarte, beispielsweise in Plug-In oder vorzugsweise im ISO-Format. Beide Module 16,14 können gleichzeitig in das Mobilgerät 13 eingeschoben werden und über eine Schnittstelle mit nicht dargestellten Datenverarbeitungsmitteln im Mobilgerät 13 kommunizieren.

Dual-Slot Mobilfunketelefone 13 sind an sich schon bekannt. Die vorliegende Erfindung kann aber auch mit anderen Typen von Mobil- geräten, die über zwei Modul-Leser verfügen, eingesetzt werden.

Beispielsweise könnte diese Erfindung auch mit Rechnern, beispielsweise mit Laptop oder Palmtop, die über zwei Modul-Leser, beispielsweise zwei Chipkartenleser, verfügen, eingesetzt werden.

Das erste Modul 16 ist vorzugsweise als wegnehmbare Chipkarte realisiert, beispielsweise im Plug-In oder im ISO-Format und umfasst einen nicht dargestellten geschützten Speicherbereich, in welchem eine Benutzer- identifizierung abgelegt ist, beispielsweise eine IMSI-ldentifizierung (Inter- national Mobile Subscriber Identity) in einem GSM-Mobilfunknetz. Ein persönliches Zertifikat des Benutzers kann auch im EEPROM des ersten

Moduls 16 enthalten sein. Das erste Modul könnte auch in der Form eines anderen Datenträgers realisiert werden, beispielsweise eines optischen, magnetischen und/oder Halbleiter Datenträgers, beispielsweise als ROM oder EPROM-Modul. Das erste Modul könnte sogar als Software-Modul innerhalb eines geschützten Speicherbereich des Mobilgeräts 13 realisiert werden.

Das erfindungsgemässe zweite Modul 14 ist wegnehmbar und kann unabhängig vom Mobilgerät 13 und vom ersten Modul 16 vermarktet und verteilt werden, beispielsweise direkt durch die Zertifizierungsinstanz, beispielsweise ein Finanzinstitut, ein Telekommunikationsnetzbetreiber, usw.

Vorzugsweise wird das zweite Modul ebenfalls als Chipkarte realisiert, vorzugsweise im handlichen ISO-Format. In weiteren Aus- führungsformen könnte dieses Modul jedoch auch in der Form eines anderen Datenträgers realisiert werden, beispielsweise eines optischen, magnetischen und/oder Halbleiter Datenträgers, beispielsweise als ROM oder EPROM-Modul.

Das zweite Modul 14 umfasst einen geschützten Speicherbereich 15, in welchem mindestens ein Zertifikat oder eine Referenz zu einem Zertifikat abgelegt ist, vorzugsweise ein Ursprungszertifikat, mit welchem andere Zertifikate überprüft werden können. Dieses Zertifikat wird vor- zugsweise während der Herstellung des zweiten Moduls 14 abgelegt, beispielsweise in einem ROM-Bereich des Moduls 14 definiert. In einer Variante wird dieses Zertifikat bei der Personalisierung des zweiten Moduls durch die Zertifizierungsinstanz 14 abgelegt.

Im Speicherbereich 15 des zweiten Moduls kann beispielsweise ein komplettes Zertifikat 5 der Zertifizierungsinstanz abgelegt werden, wie es auf der Figuren 2 und 3 als Beispiel dargestellt wird. In einer Variante wird stattdessen nur eine Referenz zu einem solchen Zertifikat, beispiels- weise ein Hash des Zertifikats, eine Adresse, beispielsweise eine URL- Adresse eines anderswo gespeichertes Zertifikats, die Seriennummer der

Zertifizierungsinstanz, usw. In der Folge ist in der Beschreibung und in den Ansprüchen mit"Referenz zum Zertifikat"entweder das Zertifikat selbst gemeint, oder eine andere Datei, die erlaubt, dieses Zertifikat zu finden.

Es können ausserdem Listen von Zertifikaten oder von Ursprungszertifikaten im zweiten Modul 14 enthalten sein.

Das zweite Modul 14 kann auch andere Funktionen als die Prüfung von Zertifikaten erfüllen, beispielsweise Zahlungstransaktions- funktionen. In einer Variante kann das zweite Modul 14 beispielsweise auch als Geldkarte, beispielsweise als Kredit-, Debit-und/oder Prepaid- karte, eingesetzt werden. Wird das zweite Modul 14 von einem Kredit- karteninstitut oder von einem Finanzinstitut angeboten, kann beispiels- weise das Zertifikat oder eine Referenz zum Zertifikat dieses Instituts im Modul abgelegt werden.

Das zweite Modul 14 kann sogar eine multifunktionnelle Chip- karte sein, beispielsweise eine JavaCard (Warenzeichen von Sun) oder eine OpenCard (Warenzeichen von IBM), die erlaubt mehrere Anwendungen als Applet oder als Programm zu unterstützen.

Das im zweiten Modul 14 abgelegte Zertifikat kann vom Mobil- gerät 13, beziehungsweise von Anwendungen in diesem Mobilgerät 13 und/oder im ersten Modul 16, verwendet werden, um digitale Signaturen zu prüfen. Beispielsweise kann dieses Zertifikat von Sicherheitsfunktionen des WTLS Protokolls in einem WAP-Browser (Wireless Application Protocol) verwendet werden, um die von einer Zertifizierungsinstanz herausge- gebenen Zertifikate von Partnern zu authentifizieren.

Die Figur 5 zeigt in schematischer Weise die möglichen Daten- flüsse A, B, C zwischen dem ersten Modul 16, dem zweiten Modul 14 und dem Mobilgerät 13 (ME-Mobile Equipment), das über ein Mobilfunknetz mit einem entfernten Partner 21, beispielsweise einem Dienstanbieter, kommuniziert. Das Mobilgerät 13, beziehungsweise eine Anwendung in diesem Mobilgerät oder im ersten Modul 16, will den entfernten Partner 21

authentifizieren, zum Beispiel indem das WTLS Protokoll eingesetzt wird.

Zu diesem Zweck muss diese Anwendung das Ursprungszertifikat im zweiten Modul 14 benutzen. Dies kann in zwei Modi passieren : In einer ersten Ausführungsform wird das zweite Modul rein als Speicher benutzt. In dieser Ausführungsform wird das Ursprungszertifikat 5 im benannten Speicherbereich des zweiten Moduls abgelegt und kann vom Mobilgerät 13 und/oder vom ersten Modul 16 abgeholt werden, um das Zertifikat des Partners 21 zu prüfen.

In einer zweiten Variante verfügt das zweite Modul über eigene Datenverarbeitungsmittel (Rechnerleistungen), mit welchen diese Über- prüfungen durchgeführt werden können. In dieser Variante gibt das Mobil- gerät 13 und/oder das erste Modul 16 das vom Partner 21 empfangene Zertifikat für Überprüfung an das zweite Modul weiter. Das zweite Modul überprüft das Partnerzertifikat und gibt eine Authentisierungsbestätigung, eine nicht-Authentisierungsbestätigung oder vorzugsweise feinere Meldungen als Ergebnis zurück.

Befindet sich der Apptikationsausführer, beispielsweise die An- wendung, die ein Zertifikat überprüfen will, im Mobilgerät 13, kann die Kommunikation mit dem zweiten Modul entweder direkt stattfinden (Pfeil C) oder durch das erste Modul 16 (Pfeile A und B) (vorausgesetzt, im Fall von einer Referenz zu einem Zertifikat, dass das Zertifikat abgeholt wird (nicht dargestellte Schritte)).

Vier verschiedene Meldungen können gebraucht werden, um das Zertifikat eines Partners 21 zu überprüfen : 1. ReadCACertRequest : Verlangt eine Kopie des Ursprungszertifikats (oder eine Referenz zu diesem Zertifikat).

2. Read_CA_Cert_Reply : Sendet das Ursprungszertifikat als Antwort (oder eine Referenz zu diesem Zertifikat).

3. Check_Partner_Cert_Request : Sendet das Partnerzertifikat (oder eine Referenz zu diesem Zertifikat).

4. Check_Partner_Cert_Reply : Sendet das Ergebnis der Über- prüfung des Zertifikats (Zertifikat authentifiziert/nicht authentifiziert).

Wir werden jetzt verschiedene Ausführungsformen des erfindungsgemässen Verfahrens anhand der Figuren 6 bis 13 näher beschreiben.

In der mit der Figur 6 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im Mobilgerät 13 und die Kommunikation zwischen dem Mobilgerät 13 und dem zweiten Modul 14 findet direkt durch den Kanal C statt. Das zweite Modul 14 wird nur als Speicher benutzt.

In dieser Variante sendet zuerst das Mobilgerät 13 eine Read_CA_Cert_Request (Pfeil 61) an das zweite Modul 14, welches mit dem abgelegten Zertifikat, oder mit der abgelegten Referenz, durch eine Read_CA_Cert_Reply (Pfeil 62) antwortet. Dieses Zertifikat (oder die dazugehörige Referenz) kann dann von einer Anwendung im Mobilgerät verwendet werden, um das Zertifikat eines Partners 21 zu überprüfen.

In der mit der Figur 7 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im Mobilgerät 13 und die Kommunikation zwischen dem Mobilgerät 13 und dem zweiten Modul 14 findet direkt durch den Kanal C statt. Im Gegensatz zur Variante der Figur 6 verfügt jedoch das zweite Modul über Datenverarbeitungsmittel, mit welchen es ein Zertifikat selbst überprüfen kann.

In dieser Variante sendet zuerst das Mobilgerät 13 eine Check_Partner_Cert_Request (Pfeil 71) an das zweite Modul 14. Diese Anfrage enthält ein (gegebenenfalls im voraus abgeholtes) Partnerzertifikat. Das zweite Modul antwortet mit dem Ergebnis der

durchgeführten Überprüfung durch eine Check_Partner_Cert_Reply (Pfeil 72).

In der mit der Figur 8 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im Mobilgerät 13. Die Kommunikation mit dem zweiten Modul 14 findet jedoch durch das erste Modul (SIM oder WIM) 16 statt (Pfeile A und B auf der Figur 5). Das zweite Modul 14 wird nur als Speicher benutzt.

In dieser Variante sendet zuerst das Mobilgerät 13 eine Read_CA_Cert_Request (Pfeil 81) an das erste Modul 16, welches diese Anfrage an das zweite Modul 14 weiterleitet (Pfeil 82). Das zweite Modul 14 antwortet mit dem abgelegten Ursprungszertifikat oder mit der Referenz durch eine Read_CA_Cert_Reply Antwort (Pfeil 83) ; das erste Modul sendet das erhaltene Zertifikat oder die Referenz weiter an das Mobilgerät 13 (Pfeil 84), welches dieses Ursprungszertifikat verwenden kann, um das Zertifikat des Partners 21 zu überprüfen.

In der mit der Figur 9 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im Mobilgerät 13. Die Kommunikation mit dem zweiten Modul 14 findet auch durch das erste Modul (SIM oder WIM) 16 statt. Im Gegensatz zur Variante der Figur 8 verfügt jedoch das zweite Modul über Datenverarbeitungsmittel, mit welchen es ein Zertifikat selbst überprüfen kann.

In dieser Variante sendet zuerst das Mobilgerät 13 eine Check_Partner_Cert_Request (Pfeil 91) an das erste Modul 16. Diese An- frage enthält das (gegebenenfalls im voraus abgeholtes) Partnerzertifikat, oder eine Referenz zu einem Partnerzertifikat, mit welchem das zweite Modul das Zertifikat über das Endgerät 13 und eventuell über das erste Modul 16 abholen kann. Das erste Modul leitet dann diese Anfrage an das zweite Modul 14 weiter (Pfeil 92). Das zweite Modul 14 überprüft das erhaltene Zertifikat und sendet das Ergebnis der Überprüfung an das erste Modul 16 (Pfeil 93, CheckPartnerCertRep!y)zurück. Das erste Modul leitet das erhaltene Ergebnis an das Mobilgerät 13 weiter (Pfeil 94).

In der mit der Figur 10 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im ersten Modul 16. Die Kommunikation zwischen dem ersten und dem zweiten Modul 14 erfolgt durch das Mobilgerät 13 (Pfeile A und C auf der Figur 5). Das zweite Modul 14 wird nur als Speicher benutzt.

In dieser Variante sendet zuerst das erste Modul 16 eine ReadCACertRequest an das Mobilgerät 13 (Pfeil 101), welches diese Anfrage an das zweite Modul 14 weiterleitet (Pfeil 102). Das zweite Modul antwortet mit dem abgelegten Ursprungszertifikat oder mit einer Referenz zum Ursprungszertifikat durch eine Read_CA_Cert_Reply (Pfeil 103), die an das erste Modul weitergeleitet wird (Pfeil 104). Die Überprüfung des Partnerzertifikats mit dem Ursprungszertifikat erfolgt im ersten Modul 16.

In der mit der Figur 11 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im ersten Modul 16. Die Kommunikation zwischen dem ersten und dem zweiten Modul 14 erfolgt durch das Mobilgerät 13 (Pfeile A und C auf der Figur 5). Im Gegensatz zur Variante der Figur 10 verfügt jedoch das zweite Modul 14 über Daten- verarbeitungsmittel, mit welchen es ein Zertifikat selbst überprüfen kann.

In dieser Variante sendet zuerst das erste Modul 16 eine Check_Partner_Cert_Request an das Mobilgerät 13 (Pfeil 111). Diese Anfrage enthält ein (gegebenenfalls im voraus abgeholtes) Partnerzertifikat. Das Mobilgerät leitet diese Anfrage an das zweite Modul 14 weiter (Pfeil 112). Das zweite Modul überprüft das erhaltene Partnerzertifikat und sendet durch eine Check_Partner_Cert_Reply (Pfeil 113) das Ergebnis zurück. Dieses Ergebnis wird vom Mobilgerät an das erste Modul weitergeleitet (Pfeil 114).

In der mit der Figur 12 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im ersten Modul 16. Die Kommunikation zwischen dem ersten und dem zweiten Modul 14 kann direkt stattfinden (Pfeil B auf der Figur 5). Das zweite Modul 14 wird nur als Speicher benutzt.

In dieser Variante sendet zuerst das erste Modul 16 eine Read_CA_Cert_Request (Pfeil 121) an das zweite Modul 14, welches mit dem abgelegten Zertifikat oder mit der Referenz durch eine Read_CA_Cert_Reply (Pfeil 122) antwortet.

In der mit der Figur 13 dargestellten Variante befindet sich der Applikationsausführer, z. B. eine WTLS-Applikation, im ersten Modul 16. Die Kommunikation zwischen dem ersten und dem zweiten Modul 14 kann direkt stattfinden (Pfeil B auf der Figur 5). Im Gegensatz zur Variante der Figur 12 verfügt jedoch das zweite Modul über Datenverarbeitungsmittel, mit welchen es ein Zertifikat selbst überprüfen kann.

In dieser Variante sendet zuerst das erste Modul 16 eine Check_Partner_Cert_Request (Pfeil 131) an das zweite Modul 14. Diese Anfrage enthält ein (gegebenenfalls im voraus abgeholtes) Partnerzertifikat, oder eine Referenz zu einem Partnerzertifikat, mit welchem das zweite Modul das Zertifikat über das Endgerät 13 und eventuell über das erste Modul 16 abholen kann. Das zweite Module antwortet mit dem Ergebnis der durchgeführten Überprüfung durch eine Check_Partner_Cert_Reply (Pfeil 132).

Der Fachmann wird verstehen, dass andere Datenflusse innerhalb der Erfindung möglich sind. Beispielsweise kann das im zweiten Modul 14 abgelegte Ursprungszertifikat auch verwendet werden, um andere Zertifi- kate im ersten Modul 16 (beispielsweise das Mobilteilnehmerzertifikat), im Mobilgerät 13, und/oder in über eine kontaktlose Schnittstelle im Nahbereich (beispielsweise gemäss Bluetooth, HomeRF und/oder IrdA) mit dem Mobilgerät 13 verbundenen externen Geräten, beispielsweise POS (Point-of-Sales), zu authentizieren.