DE602004003503T2 - System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten - Google Patents

System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten Download PDF

Info

Publication number
DE602004003503T2
DE602004003503T2 DE602004003503T DE602004003503T DE602004003503T2 DE 602004003503 T2 DE602004003503 T2 DE 602004003503T2 DE 602004003503 T DE602004003503 T DE 602004003503T DE 602004003503 T DE602004003503 T DE 602004003503T DE 602004003503 T2 DE602004003503 T2 DE 602004003503T2
Authority
DE
Germany
Prior art keywords
certificate
public key
digital signature
mobile device
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602004003503T
Other languages
English (en)
Other versions
DE602004003503D1 (de
Inventor
Michael K. N2M 2Z2 Kitchener Brown
Michael S. N2K 4B1 Waterloo Brown
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Publication of DE602004003503D1 publication Critical patent/DE602004003503D1/de
Application granted granted Critical
Publication of DE602004003503T2 publication Critical patent/DE602004003503T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Description

  • Die vorliegende Erfindung bezieht sich allgemein auf die Verarbeitung von Nachrichten, wie beispielsweise E-Mail-Nachrichten, und insbesondere auf ein System und ein Verfahren zur Gültigkeitsprüfung von Zertifikaten, die bei der Verarbeitung codierter Nachrichten verwendet werden.
  • Per elektronischer Post übertragene Nachrichten („E-Mails") können mit einem von mehreren bekannten Protokollen codiert werden. Einige dieser Protokolle, wie z. B. das Protokoll Secure Multiple Internet Mail Extensions („S/MIME") basieren auf öffentlichen und privaten Verschlüsselungsschlüsseln, um die Vertraulichkeit und die Integrität zu gewährleisten, und auf einer Public Key Infrastructure (PKI), um Informationen zu kommunizieren, die für die Authentifizierung und Autorisierung sorgen. Die mit einem privaten Schlüssel oder mit einem Paar aus privatem und öffentlichem Schlüssel verschlüsselten Daten können nur unter Verwendung des entsprechenden öffentlichen Schlüssels des Paars und umgekehrt entschlüsselt werden. Die Authentizität der zur Codierung von Nachrichten verwendeten öffentlichen Schlüssel wird mithilfe von Zertifikaten geprüft. Konkret heißt das: Wenn ein Benutzer eines Computergeräts eine Nachricht verschlüsseln möchte, bevor die Nachricht an eine bestimmte Person gesendet wird, benötigt der Benutzer ein Zertifikat für diese Person. Das Zertifikat enthält typischerweise den öffentlichen Schlüssel der Person sowie weitere im Zusammenhang mit der Identifikation stehende Informationen.
  • Zertifikate sind digitale Dokumente, die typischerweise durch Zertifizierungsstellen ausgestellt werden. Um einem bestimmten öffentlichen Schlüssel vertrauen zu können, muss der öffentliche Schlüssel typischerweise durch eine Zertifizierungsstelle ausgestellt sein, die ebenfalls vertrauenswürdig ist, oder durch eine Instanz, die mit der vertrauenswürdigen Zertifizierungsstelle verbunden ist. Die Beziehung zwischen einer vertrauenswürdigen Zertifizierungsstelle und einem ausgestellten öffentlichen Schlüssel kann durch eine Reihe von miteinander verbundenen Zertifikaten repräsentiert werden, die auch als Zertifikatkette bezeichnet wird. Die Zertifikatkette kann verfolgt werden, um die Gültigkeit eines Zertifikats zu ermitteln.
  • Typischerweise signiert eine Zertifizierungsstelle jedes von ihr ausgestellte Zertifikat digital, um zu bestätigen, dass ein bestimmter öffentlicher Schlüssel zum vorgeblichen Eigentümer gehört, wie das im jeweiligen Zertifikat angegeben ist. Beim Erstellen von Zertifikatketten müssen die digitalen Signaturen der Zertifikate aus der Kette oft verifiziert werden. Die Verifikation einer digitalen Signatur von einem Zertifikat ist ein Prozess, für den der öffentliche Schlüssel der Zertifizierungsstelle benötigt wird, die das Zertifikat ausgestellt hat.
  • Eine Veröffentlichung von W. Stallings mit dem Titel „Cryptography and network security: principles and practice – 2nd", 1998, Seiten 163 bis 205, offenbart ein Verfahren zur Verifikation einer digitalen Signatur unter Verwendung eines öffentlichen Schlüssels.
  • Eine Veröffentlichung von W. Pugh et al mit dem Titel „Incremental computation via function caching", Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages, ACM, NY, USA, 11. Januar 1989, Seiten 315 bis 328, offenbart ein Verfahren zum Caching von Informationen. Dieses Verfahren schließt die Verwendung von Funktions-Caching ein, das heißt, das Erinnern der Ergebnisse von vorherigen Funktionsaufrufen und das Vermeiden von deren erneuter Berechnung, um die Ergebnisse vorheriger inkrementeller Berechnungen erneut zu verwenden oder zu aktualisieren.
  • Allgemein
  • Der Verifikationsprozess kann zeitaufwändig und kostspielig sein (z. B. hinsichtlich der Verwendung von Computerressourcen), insbesondere wenn die Verifikationen auf kleineren Geräten durchgeführt werden, beispielsweise auf mobilen Geräten. Wenn mehrere Zertifikate auf dem Computergerät eines Benutzers verarbeitet werden, kann dieselbe digitale Signatur mehreren Verifikationen unterzogen werden. Die Ausführungsformen der Erfindung beziehen sich allgemein auf ein System und ein Verfahren, das eine effizientere Verifikation von digitalen Signaturen von Zertifikaten ermöglicht, indem bestimmte Informationen, die zur Verifikation der Signaturen verwendet werden, zur erneuten Verwendung gespeichert werden.
  • In einem allgemeinen Aspekt der Erfindung wird ein Verfahren zur Verifikation einer digitalen Signatur von einem Zertifikat in einem Computergerät bereit gestellt, wobei das Verfahren die folgenden Schritte umfasst: Durchführen einer ersten Signaturverifikationsoperation an der digitalen Signatur unter Verwendung eines ersten öffentlichen Schlüssels, der einem Aussteller des Zertifikats zugeordnet ist; Ermitteln, ob die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wurde; Speichern des ersten öffentlichen Schlüssels in einem Speicherbereich; Empfangen einer Anforderung zum Durchführen einer zweiten Signaturverifikationsoperation an der digitalen Signatur unter Verwendung eines zweiten öffentlichen Schlüssels, der einem Aussteller des Zertifikats zugeordnet ist; Vergleichen des zweiten öffentlichen Schlüssels mit dem im Speicherbereich gespeicherten ersten öffentlichen Schlüssel, um zu ermitteln, ob der erste öffentliche Schlüssel und der zweite öffentliche Schlüssel übereinstimmen; und Anzeigen der erfolgreichen Verifikation der digitalen Signatur als Reaktion auf die Anforderung, wenn die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wurde und wenn im Vergleichsschritt eine Übereinstimmung ermittelt wurde, wodurch die zweite Signaturverifikationsoperation nicht durchgeführt werden muss.
  • Kurze Beschreibung der Zeichnungen
  • Zur Erleichterung des Verständnisses der Ausführungsformen der Erfindung, und um deutlicher zeigen zu können, wie sie in die Realität umgesetzt werden kann, wird nun anhand von Beispielen auf die beiliegenden Zeichnungen Bezug genommen, welche folgende Bedeutung haben:
  • 1 ist ein Blockdiagramm eines Mobilgeräts in einer beispielhaften Implementierung;
  • 2 ist ein Blockdiagramm einer Kommunikations-Teilsystemkomponente des Mobilgeräts aus 1;
  • 3 ist ein Blockdiagramm eines Knotens eines Drahtlosnetzwerks;
  • 4 ist ein Blockdiagramm zur Darstellung der Komponenten eines Host-Systems in einer Beispielkonfiguration;
  • 5 ist ein Blockdiagramm zur Darstellung eines Beispiels einer Zertifikatkette;
  • 6 ist ein Blockdiagramm zur Darstellung der Komponenten eines Beispiels einer codierten Nachricht;
  • 7A ist ein Blockdiagramm zur Darstellung von zwei beispielhaften Zertifikatketten;
  • 7B ist ein Blockdiagramm zur Darstellung der Kreuzzertifikate zur Verknüpfung der Zertifikatketten aus 7A;
  • 8A ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zur Verifikation einer digitalen Signatur von einem Zertifikat in einer Ausführungsform der Erfindung; und
  • 8B ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zur Verifikation einer digitalen Signatur von einem Zertifikat in einer anderen Ausführungsform der Erfindung.
  • Beschreibung von bevorzugten Ausführungsformen
  • Einige Ausführungsformen der Erfindung verwenden eine Mobilstation. Bei einer Mobilstation handelt es sich um ein Zweiwege-Kommunikationsgerät mit erweiterten Datenkommunikationsfunktionen, das über die Fähigkeit zur Kommunikation mit anderen Computersystemen verfügt, und es wird hier auch allgemein als Mobilgerät bezeichnet. Ein Mobilgerät kann auch die Fähigkeit zur Sprachkommunikation einschließen. In Abhängigkeit der von einem Mobilgerät bereitgestellten Funktionalität kann es als Daten- und Nachrichtenübertragungsgerät, als Zweiwege-Pager, als Mobiltelefon mit Möglichkeit zur Daten- und Nachrichtenübertragung, als drahtloses Internet-Gerät oder als Datenkommunikationsgerät (mit und ohne Telefoniefunktion) bezeichnet werden. Ein Mobilgerät kommuniziert mit anderen Geräten über ein Netzwerk aus Sender-Empfänger-Stationen.
  • Um dem Leser das Verständnis des Aufbaus eines Mobilgeräts und seiner Kommunikation mit anderen Geräten zu erleichtern, wird Bezug auf 1 bis 3 genommen.
  • Zunächst Bezug nehmend auf 1 ist ein Blockdiagramm eines Mobilgeräts in einer beispielhaften Implementierung gezeigt, das allgemein mit 100 bezeichnet ist. Das Mobilgerät 100 umfasst eine Reihe von Komponenten, wobei der Mikroprozessor 102 die steuernde Komponente ist. Der Mikroprozessor 102 steuert den Gesamtbetrieb des Mobilgeräts 100. Die Kommunikationsfunktionen, einschließlich der Daten- und Sprachkommunikation, werden durch das Kommunikations-Teilsystem 104 ausgeführt. Das Kommunikations-Teilsystem 104 empfängt Nachrichten von und sendet Nachrichten zu einem Drahtlosnetzwerk 200. In dieser beispielhaften Implementierung des Mobilgeräts 100 ist das Kommunikations-Teilsystem 104 gemäß den Standards Global System for Mobile Communication (GSM) und General Packet Radio Services (GPRS) konfiguriert. Das GSM/GPRS-Drahtlosnetzwerk wird weltweit verwendet, und es wird erwartet, dass diese Standards letztendlich durch die Standards Enhanced Data GSM Environment (EDGE) und Universal Mobile Telecommunications Service (UMTS) abgelöst werden. Es werden noch immer neue Standards definiert, es wird jedoch erwartet, dass diese Ähnlichkeiten zum hier beschriebenen Netzwerkverhalten aufweisen werden, und dem Fachmann auf dem Gebiet der Technik wird auch einleuchten, dass die Erfindung zur Verwendung aller anderen geeigneten Standards vorgesehen ist, die in Zukunft entwickelt werden. Die Drahtlosverbindung, die das Kommunikations-Teilsystem 104 mit dem Netzwerk 200 verbindet, wird durch einen oder mehrere verschiedene Hochfrequenzkanäle (HF) repräsentiert, die entsprechend definierten Protokollen arbeiten, die für die GSM/GPRS-Kommunikation spezifiziert sind. Bei neueren Netzwerkprotokollen sind diese Kanäle in der Lage, sowohl leitungsvermittelte Sprachkommunikation als auch paketvermittelte Datenkommunikation zu unterstützen.
  • Obwohl das dem Mobilgerät 100 in einer beispielhaften Implementierung des Mobilgeräts 100 zugeordnete Drahtlosnetzwerk ein GSM/GPRS-Drahtlosnetzwerk ist, können in abweichenden Implementierungen auch andere Drahtlosnetzwerke dem Mobilgerät 100 zugeordnet sein. Zu anderen Typen von Drahtlosnetzwerken, die verwendet werden können, zählen beispielsweise datenzentrische Drahtlosnetzwerke, sprachzentrische Drahtlosnetzwerke und Doppelmodusnetzwerke, die über dieselben physischen Basisstationen sowohl Sprachkommunikation als auch Datenkommunikation unterstützen können. Zu den kombinierten Doppelmodusnetzwerken gehören unter anderem Code Division Multiple Access (CDMA) oder CDMA2000-Netzwerke, GSM/GPRS-Netzwerke (wie oben erwähnt), und zukünftige Netzwerke der dritten Generation (3G) wie EDGE und UMTS. Zu einigen älteren Beispielen für datenzentrische Netzwerke gehören das MobitexTM-Funknetzwerk und das DataTACTM-Funknetzwerk. Zu einigen älteren Beispielen für sprachzentrische Netzwerke gehören Personal Communications Systems (PCS) Netzwerke wie GSM und Time Division Multiple Access (TDMA) Systeme.
  • Der Mikroprozessor 102 interagiert auch mit zusätzlichen Teilsystemen wie dem Random Access Memory (RAM) 106, dem Flash-Speicher 108, dem Display 110, dem zusätzlichen Eingabe-/Ausgabe-Teilsystem (E/A) 112, dem seriellen Anschluss 114, der Tastatur 116, dem Lautsprecher 118, dem Mikrofon 120, einem Nahbereichskommunikations-Teilsystem 122 und anderen Geräten 124.
  • Einige der Teilsysteme des Mobilgeräts 100 führen kommunikationsbezogene Funktionen aus, während andere Teilsysteme für „residente" oder gerätespezifische Funktionen verantwortlich sind. Beispielsweise können das Display 110 und die Tastatur 116 sowohl für kommunikationsbezogene Funktionen wie das Eingeben einer Textnachricht zur Übertragung über das Netzwerk 200 als auch für geräteresidente Funktionen wie ein Rechengerät oder eine Aufgabenliste verwendet werden. Die vom Mikroprozessor 102 verwendete Betriebssystemsoftware ist typischerweise in einem Dauerspeicher wie einem Flash-Speicher 108 gespeichert, bei dem es sich alternativ auch um einen Festwertspeicher (Read-Only Memory, ROM) oder um ein ähnliches Speicherelement (nicht dargestellt) handeln kann. Dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass das Betriebssystem, spezifische Geräteanwendungen oder Teile davon temporär in einen flüchtigen Speicher wie den RAM 106 geladen werden können.
  • Das Mobilgerät 100 kann nach Abschluss der erforderlichen Netzwerkregistrierungs- oder -aktivierungsprozeduren Kommunikationssignale über das Netzwerk 200 senden und empfangen. Der Netzwerkzugriff wird einem Teilnehmer oder Benutzer eines Mobilgeräts 100 zugeordnet. Um einen Teilnehmer zu identifizieren, benötigt das Mobilgerät 100 ein Teilnehmeridentitätsmodul (Subscriber Identity Module) oder eine „SIM"-Karte 126, die in eine SIM-Schnittstelle 128 eingelegt wird, damit die Kommunikation mit einem Netzwerk erfolgen kann. Die SIM-Karte 126 entspricht vom Typ her einer konventionellen „SmartCard", die – unter anderem – zur Identifizierung eines Teilnehmers des Mobilgeräts 100 und zur Personalisierung des Mobilgeräts 100 verwendet wird. Ohne die SIM-Karte 126 ist das Mobilgerät 100 nicht voll funktionsfähig für die Kommunikation mit dem Netzwerk 200. Durch Einlegen der SIM-Karte 126 in die SIM-Schnittstelle 128 erhält ein Teilnehmer Zugriff auf alle abonnierten Dienste. Zu diesen Diensten könnten zählen: Webbrowsing und Nachrichtenübertragung wie z. B. per E-Mail, Sprachnachrichten, Short Message Service (SMS) und Multimedia Messaging Services (MMS). Zu weiterentwickelten Diensten können gehören: Point of Sale-, Außendienst- und Sales Force-Automatisierung. Die SIM-Karte 126 enthält einen Prozessor und einen Speicher zum Speichern von Informationen. Sobald die SIM-Karte 126 in die SIM-Schnittstelle 128 eingelegt wird, ist sie mit dem Mikroprozessor 102 gekoppelt. Um den Teilnehmer zu identifizieren, enthält die SIM-Karte 126 einige Benutzerparameter wie z. B. eine International Mobile Subscriber Identity (IMSI). Ein Vorteil in der Verwendung der SIM-Karte 126 besteht darin, dass ein Teilnehmer nicht notwendigerweise an ein einziges physisches Mobilgerät gebunden ist. Die SIM-Karte 126 kann auch zusätzliche Informationen für ein Mobilgerät speichern, beispielsweise Informationen zu Terminen (Kalenderdaten) oder Informationen zu den zuletzt erfolgten Anrufen.
  • Das Mobilgerät 100 ist ein batteriebetriebenes Gerät und enthält eine Batterieschnittstelle 132 zur Aufnahme von einer oder mehreren wiederaufladbaren Batterien 130. Die Batterieschnittstelle 132 ist an einen Regler (nicht dargestellt) gekoppelt, der die Batterie 130 bei der Bereitstellung des Stroms V+ an das Mobilgerät 100 unterstützt. Obwohl derzeitige Technologien eine Batterie verwenden, können auch zukünftige Technologien wie Mikrobrennstoffzellen den Strom für das Mobilgerät 100 liefern.
  • Der Mikroprozessor 102 ermöglicht zusätzlich zu seinen Betriebssystemfunktionen die Ausführung von Softwareanwendungen auf dem Mobilgerät 100. Eine Reihe von Anwendungen zur Steuerung der grundlegenden Gerätefunktionen, einschließlich Anwendungen zur Daten- und Sprachkommunikation, sind normalerweise bereits herstellerseitig auf dem Mobilgerät 100 installiert. Eine weitere Anwendung, die auf das Mobilgerät 100 geladen werden kann, ist ein Personal Information Manager (PIM), Ein PIM verfügt über Funktionen zum Organisieren und Verwalten von Datenobjekten, die für einen Teilnehmer von Interesse sind, was beispielsweise unter anderem E-Mails, Kalenderereignisse, Sprachnachrichten, Termine und Aufgabenobjekte sein können. Eine PIM-Anwendung verfügt über die Fähigkeit zum Senden und Empfangen von Datenobjekten über das Drahtlosnetzwerk 200. Die PIM-Datenobjekte können mit den entsprechenden Datenobjekten des Mobilgerätteilnehmers, die auf einem Host-Computersystem gespeichert und/oder zugeordnet sind, über das Drahtlosnetzwerk 200 nahtlos integriert, synchronisiert und aktualisiert werden. Diese Funktionalität erstellt hinsichtlich dieser Objekte ein gespiegeltes Abbild des Host-Computers auf dem Mobilgerät 100. Das kann insbesondere vorteilhaft sein, wenn es sich beim Host-Computersystem um das Bürocomputersystem des Mobilgerätteilnehmers handelt.
  • Weitere Anwendungen können auch über das Netzwerk 200, das zusätzliche E/A-Teilsystem 112, den seriellen Anschluss 114, das Nahbereichskommunikations-Teilsystem 122 oder jedes andere geeignete Teilsystem 124 auf das Mobilgerät 100 geladen werden. Diese Flexibilität bei der Anwendungsinstallation erhöht die Funktionalität des Mobilgeräts 100 und kann erweiterte gerätespezifische Funktionen, kommunikationsbezogene Funktionen oder beides ermöglichen. Beispielsweise können über sichere Kommunikationsanwendungen E-Commerce-Funktionen und andere derartige Finanztransaktionen mit dem Mobilgerät 100 ermöglicht werden.
  • Der serielle Anschluss 114 ermöglicht es einem Teilnehmer, über ein externes Gerät oder eine Softwareanwendung Voreinstellungen festzulegen, und erweitert die Fähigkeiten des Mobilgeräts 100 durch das Bereitstellen von Informationen oder Softwaredownloads zum Mobilgerät 100, die nicht über ein drahtloses Kommunikationsnetzwerk erfolgen. Der alternative Downloadpfad kann beispielsweise verwendet werden, um über eine direkte und damit vertrauenswürdige Verbindung einen Verschlüsselungsschlüssel auf das Mobilgerät 100 zu laden, um eine sichere Gerätekommunikation zu ermöglichen.
  • Das Nahbereichskommunikations-Teilsystem 122 ermöglicht die Kommunikation zwischen dem Mobilgerät 100 und verschiedenen Systemen oder Geräten, ohne dazu das Netzwerk 200 zu verwenden. Beispielsweise kann das Teilsystem 122 ein Infrarotgerät sowie die zugehörigen Schaltungen und Komponenten für die Nahbereichskommunikation enthalten. Beispiele für die Nahbereichskommunikation sind die von der Infrared Data Association (IrDA) entwickelten Standards, Bluetooth sowie die Gruppe der von der IEEE entwickelten 802.11-Standards.
  • Bei der Verwendung wird ein empfangenes Signal wie z. B. eine Textnachricht, eine E-Mail-Nachricht oder ein Webseitendownload durch das Kommunikations-Teilsystem 104 verarbeitet und in den Mikroprozessor 102 eingespeist. Der Mikroprozessor 102 verarbeitet dann das empfangene Signal zur Ausgabe an das Display 110 oder alternativ an das zusätzlichen E/A-Teilsystem 112. Ein Teilnehmer kann auch Datenobjekte wie beispielsweise E-Mail-Nachrichten erstellen, wozu die Tastatur 116 in Verbindung mit dem Display 110 und möglicherweise das zusätzliche E/A-Teilsystem 112 verwendet wird. Das zusätzliche Teilsystem 112 kann Geräte wie die folgenden enthalten: einen Touchscreen, eine Maus, einen Trackball, einen Infrarot-Fingerabdruckleser oder ein Drehrad mit dynamischer Tastendruckfunktion. Bei der Tastatur 116 handelt es sich um eine alphanumerische Tastatur und/oder um ein für Telefone typisches Ziffernfeld. Ein erstelltes Objekt kann durch das Kommunikations-Teilsystem 104 über das Netzwerk 200 übertragen werden.
  • Für die Sprachkommunikation ist der allgemeine Betrieb des Mobilgeräts 100 im Wesentlichen gleich, außer dass die empfangenen Signale zum Lautsprecher 118 ausgegeben würden, und die Signale für die Übertragung würden durch das Mikrofon 120 erzeugt werden. Alternative Sprach- oder Audio-E/A-Teilsysteme, wie z. B. ein Aufzeichnungssystem für Sprachnachrichten, können auch auf dem Mobilgerät 100 implementiert sein. Obwohl die Sprach- oder Audiosignalausgabe in erster Linie durch den Lautsprecher 118 erreicht wird, kann auch das Display 110 verwendet werden, um zusätzliche Informationen wie z. B. die Identität des Anrufers, die Dauer eines Sprachanrufs oder andere auf Sprachanrufe bezogene Informationen bereitzustellen.
  • Nunmehr Bezug nehmend auf 2 wird ein Blockdiagramm einer Kommunikations-Teilsystemkomponente 104 aus 1 gezeigt. Das Kommunikations-Teilsystem 104 umfasst einen Empfänger 150, einen Sender 152, einen oder mehrere eingebettete oder interne Antennenelemente 154, 156, Lokaloszillatoren (LOs) 158 und ein Verarbeitungsmodul wie beispielsweise einen digitalen Signalprozessor (DSP) 160.
  • Der konkrete Aufbau des Kommunikations-Teilsystems 104 hängt vom Netzwerk 200 ab, in dem das Mobilgerät 200 arbeiten soll, daher sollte es einleuchten, dass der in 2 gezeigte Aufbau nur als Beispiel dient. Die von der Antenne 154 über das Netzwerk 200 empfangenen Signale werden in den Empfänger 150 eingespeist, der solche üblichen Empfängerfunktionen wie die Signalverstärkung, die Frequenzabwärtsmischung, die Filterung, die Kanalauswahl und die Analog-Digital-(A/D)-Umwandlung durchführen kann. Die A/D-Umwandlung eines empfangenen Signals ermöglicht die Durchführung komplexerer Kommunikationsfunktionen wie Demodulation und Decodierung im DSP 160. In einer ähnlichen Weise werden die zu übertragenden Signale durch den DSP 160 verarbeitet, einschließlich Modulation und Codierung. Diese vom DSP verarbeiteten Signale werden in den Sender 152 eingespeist, wo die Digital-Analog-(D/A)-Wandlung, die Frequenzaufwärtsmischung, die Filterung, die Verstärkung und die Übertragung über das Netzwerk 200 mit der Antenne 156 erfolgt. Der DSP 160 verarbeitet nicht nur die Kommunikationssignale, sondern übernimmt auch die Empfänger- und Sendersteuerung. Beispielsweise können die im Empfänger 150 und im Sender 152 auf die Kommunikationssignale angewendeten Verstärkungsgrade adaptiv durch automatische Verstärkungsregelungsalgorithmen gesteuert werden, die im DSP 160 implementiert sind.
  • Die drahtlose Verbindung zwischen dem Mobilgerät 100 und einem Netzwerk 200 kann einen oder mehrere unterschiedliche Kanäle einschließen, typischerweise unterschiedliche HF-Kanäle sowie die zugehörigen Protokolle, die zwischen dem Mobilgerät 100 und dem Netzwerk 200 verwendet werden. Ein HF-Kanal ist eine beschränkte Ressource, mit der sparsam umgegangen werden muss, was sich typischerweise aus den Einschränkungen in der Gesamtbandbreite und aus der beschränkten Batterieleistung des Mobilgeräts 100 ergibt.
  • Wenn das Mobilgerät 100 sich im vollen Betrieb befindet, wird der Sender 152 typischerweise nur dann getastet oder eingeschaltet, wenn er an das Netzwerk 200 sendet und ist ansonsten abgeschaltet, um sparsam mit Ressourcen umzugehen. In gleicher Weise wird der Empfänger 150 periodisch abgeschaltet, um Strom zu sparen, bis er benötigt wird, um Signale oder Informationen (wenn überhaupt) während ausgewiesener Zeitabschnitte zu empfangen.
  • Nunmehr Bezug nehmend auf 3 wird ein Blockdiagramm eines Knotens eines Drahtlosnetzwerks als 202 gezeigt. In der Praxis umfasst das Netzwerk 200 einen oder mehrere Knoten 202. Das Mobilgerät 100 kommuniziert mit einem Knoten 202 innerhalb des Drahtlosnetzwerks 200. In der Beispielimplementierung von 3 ist der Knoten 202 gemäß den Technologien General Packet Radio Service (GPRS) und Global Systems for Mobile (GSM) konfiguriert. Der Knoten 202 enthält eine Basisstationssteuereinheit (Base Station Controller – BSC) 204 mit einer zugehörigen Turmstation 206, eine Paketsteuerungseinheit (Packet Control Unit – PCU) 208, die zur GPRS-Unterstützung in GSM hinzugefügt wurde, ein mobile Vermittlungsstelle (Mobile Switching Center – MSC) 210, ein Heimatregister (Home Location Register – HLR) 212, ein Besucherregister (Visitor Location Register – VLR) 214, ein Serving GPRS Support Node (SGSN) 216, ein Gateway GPRS Support Node (GGSN) 218 und ein Dynamic Host Configuration Protocol (DHCP) 220. Die Liste der Komponenten ist nicht als erschöpfende Liste jedes Knotens 202 innerhalb eines GSM/GPRS-Netzwerks gemeint, sondern vielmehr als eine Liste der Komponenten, die im Allgemeinen in der Kommunikation über das Netzwerk 200 verwendet werden.
  • In einem GSM-Netzwerk ist MSC 210 mit BSC 204 und mit einem ortsfesten Netzwerk wie einem Public Switched Telephone Network (PSTN) 222 gekoppelt, um die Anforderungen der Leitungsvermittlung zu erfüllen. Die Verbindung über PCU 208, SGSN 216 und GGSN 218 zum öffentlichen oder privaten Netzwerk (Internet) 224 (hier auch allgemein als eine gemeinsam verwendete Netzwerkinfrastruktur bezeichnet) bildet den Datenpfad für GPRS-taugliche Mobilgeräte. In einem um GPRS-Funktionen erweiterten GSM-Netzwerk enthält BSC 204 auch eine Packet Control Unit (PCU) 208, die eine Verbindung zu SGSN 216 hat, um die Segmentierung und die Funkkanalzuweisung zu steuern und um den Paketvermittlungsanforderungen gerecht zu werden. Um die Mobilgerätposition und die Verfügbarkeit für sowohl leitungsvermittelte als auch paketvermittelte Verwaltung zu verfolgen, wird HLR 212 gemeinsam von MSC 210 und SGSN 216 verwendet. Der Zugriff auf VLR 214 wird durch MSC 210 gesteuert.
  • Station 206 ist eine feststehende Sende-Empfangsstation. Station 206 und BSC 204 bilden gemeinsam die feststehende Sende-Empfangsausrüstung. Die feststehende Sende-Empfangsausrüstung sorgt für die drahtlose Netzwerkabdeckung für ein bestimmtes Abdeckungsgebiet, das im Allgemeinen als eine „Zelle" bezeichnet wird. Die feststehende Sende-Empfangsausrüstung überträgt Kommunikationssignale zu und empfängt Kommunikationssignale von den Mobilgeräten innerhalb dieser Zelle über die Station 206. Die feststehende Sende-Empfangsausrüstung führt normalerweise Funktionen aus wie die Modulation und möglicherweise die Codierung und/oder Verschlüsselung von Signalen, die zum Mobilgerät übertragen werden sollen, und zwar entsprechend bestimmten, üblicherweise vorbestimmten Kommunikationsprotokollen und -parametern, unter der Steuerung ihrer Steuerungseinheit. Die feststehende Sende-Empfangsausrüstung übernimmt in gleicher Weise die Demodulation und möglicherweise Decodierung und Entschlüsselung, falls erforderlich, aller Kommunikationssignale, die innerhalb seiner Zelle vom Mobilgerät 100 empfangen werden. Die Kommunikationsprotokolle und -parameter können zwischen unterschiedlichen Knoten voneinander abweichen. Zum Beispiel kann ein Knoten ein abweichendes Modulationsschema verwenden und mit anderen Frequenzen arbeiten als andere Knoten.
  • Für alle innerhalb eines bestimmten Netzwerks registrierten Mobilgeräte 100 sind permanente Konfigurationsdaten wie z. B. ein Benutzerprofil im HLR 212 gespeichert. HLR 212 enthält auch Positionsinformationen für jedes registrierte Mobilgerät und kann abgefragt werden, um die aktuelle Position eines Mobilgeräts zu ermitteln. MSC 210 ist verantwortlich für eine Gruppe von Positionsbereichen und speichert die Daten der Mobilgeräte, die sich aktuell in seinem Verantwortlichkeitsbereich befinden, im VLR 214. Des Weiteren enthält VLR 214 auch Informationen zu den Mobilgeräten, die andere Netzwerke besuchen. Die Informationen im VLR 214 schließen für einen schnelleren Zugriff einen Teil der permanenten Mobilgerätedaten ein, die vom HLR 212 zum VLR 214 übertragen wurden. Durch die Verschiebung zusätzlicher Informationen von einem entfernten HLR-Knoten 212 zum VLR 214 kann das Ausmaß an Verkehr zwischen diesen Knoten reduziert werden, sodass Sprach- und Datendienste mit kürzeren Reaktionszeiten bereitgestellt werden können und gleichzeitig weniger Computerressourcen verwendet werden müssen.
  • SGSN 216 und GGSN 218 sind Elemente, die innerhalb von GSM zur GPRS-Unterstützung hinzugefügt wurden, nämlich für die Unterstützung paketvermittelter Daten. SGSN 216 und MSC 210 haben innerhalb des Drahtlosnetzwerks 200 ähnliche Verantwortlichkeiten, indem sie die Position jedes Mobilgeräts 100 verfolgen. SGSN 216 führt außerdem Sicherheitsfunktionen und die Zugriffssteuerung für den Datenverkehr auf Netzwerk 200 durch. GGSN 218 stellt Verbindungen für den netzüberschreitenden Betrieb mit externen paketvermittelten Netzwerken bereit und stellt die Verbindung zu einem oder mehreren SGSNs 216 über ein Internet Protocol (IP) Backbone-Netzwerk her, das innerhalb des Netzwerks 200 betrieben wird. Während des normalen Betriebs muss ein bestimmtes Mobilgerät 100 einen „GPRS-Attach" durchführen, um eine IP-Adresse zu erhalten und um auf Datendienste zuzugreifen. Diese Anforderung ist in leitungsvermittelten Sprachkanälen nicht vorhanden, da ISDN-Adressen (Integrated Services Digital Network) für die Leitweglenkung eingehender und ausgehender Anrufe verwendet werden. Gegenwärtig verwenden alle GPRS-fähigen Netzwerke private, dynamisch zugewiesene IP-Adressen, wodurch ein an das GGSN 218 angeschlossener DHCP-Server 220 erforderlich ist. Es gibt viele Mechanismen zur dynamischen IP-Zuweisung, einschließlich der Verwendung einer Kombination aus einem RADIUS-Server (Remote Authentication Dial-In User Service) und einem DHCP-Server. Sobald der GPRS-Attach abgeschlossen ist, wird eine logische Verbindung von einem Mobilgerät 100, über PCU 208 und SGSN 216 zu einem Access Point Node (APN) innerhalb von GGSN 218 eingerichtet. Der APN repräsentiert ein logisches Ende eines IP-Tunnels, der entweder auf direkte Internet-kompatile Dienste oder auf Privatnetzwerkverbindungen zugreifen kann. Der APN repräsentiert auch einen Sicherheitsmechanismus für das Netzwerk 200, insofern als dass jedes Mobilgerät 100 einem oder mehreren APNs zugewiesen sein muss und das Mobilgerät 100 keine Daten austauschen kann, ohne zuerst einen GPRS-Attach zu einem APN durchzuführen, für dessen Benutzung es autorisiert wurde. Für den APN kann angenommen werden, dass er einem Internet-Domänennamen wie „meineverbindung.drahtlos.com" ähnelt.
  • Sobald der GPRS-Attach abgeschlossen ist, wird ein Tunnel erstellt, und der gesamte Verkehr wird innerhalb standardmäßiger IP-Pakete ausgetauscht, wozu jedes Protokoll verwendet wird, das in IP-Paketen unterstützt werden kann. Dazu zählen Tunnelungsverfahren wie IP über IP, wie das bei einigen IPSec-Verbindungen (IPSecurity) der Fall ist, die mit VPNs (Virtual Private Networks) verwendet werden. Diese Tunnel werden auch als PDP-Kontexte (Packet Data Protocol) bezeichnet, und von diesen ist eine begrenzten Anzahl im Netzwerk 200 verfügbar. Um die Verwendung von PDP-Kontexten zu maximieren, führt das Netzwerk 200 einen Idle-Timer für jeden PDP-Kontext aus, um mangelnde Aktivität zu ermitteln. Wenn ein Mobilgerät 100 nicht seinen PDP-Kontext verwendet, kann die Zuordnung des PDP-Kontexts aufgehoben und die IP-Adresse wieder dem IP-Adressenpool zugeführt werden, der durch den DHCP-Server 220 verwaltet wird.
  • Nunmehr Bezug nehmend auf 4 ist ein Blockdiagramm zur Darstellung der Komponenten eines Host-Systems in einer Beispielkonfiguration gezeigt. Das Host-System 250 wird typischerweise ein Unternehmensbüronetzwerk oder ein anderes LAN (Local Area Network) sein, kann aber stattdessen ein privater Bürocomputer oder in abweichenden Implementierungen beispielsweise ein anderes privates System sein. In diesem in 4 gezeigten Beispiel ist das Host-System 250 als ein LAN einer Organisation dargestellt, zu der ein Benutzer des Mobilgeräts 100 gehört.
  • Das LAN 250 umfasst eine Anzahl von Netzwerkkomponenten, die durch LAN-Verbindungen 260 miteinander verbunden sind. Beispielsweise befindet sich der Desktopcomputer 262a eines Benutzers mit einer zugehörigen Dockingstation 264 für das Mobilgerät 100 des Benutzers im LAN 250. Die Dockingstation 264 für das Mobilgerät 100 kann mit dem Computer 262a verbunden sein, beispielsweise über eine serielle oder über eine USB-Verbindung (Universal Serial Bus). Andere Benutzercomputer 262b befinden sich auch im LAN 250, und jeder kann mit einer zugehörigen Dockingstation 264 für ein Mobilgerät ausgestattet sein oder auch nicht. Die Dockingstation 264 ermöglicht das Laden von Informationen (z. B. PIM-Daten, private symmetrische Verschlüsselungsschlüssel zum Ermöglichen einer sicheren Kommunikation zwischen dem Mobilgerät 100 und dem LAN 250) vom Benutzercomputer 262a zum Mobilgerät 100 und kann insbesondere nützlich für das massenhafte Aktualisieren von Informationen sein, das häufig bei der Initialisierung des Mobilgeräts 100 für dessen Verwendung durchgeführt wird. Zu den zum Mobilgerät 100 heruntergeladenen Informationen können Zertifikate gehören, die beim Austauschen von Nachrichten verwendet werden. Dem Fachmann auf dem Gebiet der Technik wird verständlich sein, dass die Benutzercomputer 262a, 262b typischerweise auch mit anderen Peripheriegeräten verbunden sind, die in 4 nicht explizit dargestellt sind.
  • Darüber hinaus wird in 4 zur vereinfachten Darstellung nur eine Teilgruppe von Netzwerkkomponenten des LAN 250 gezeigt, und dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass das LAN 250 für diese Beispielkonfiguration weitere Komponenten umfasst, die in 4 nicht explizit dargestellt sind. Noch allgemeiner kann das LAN 250 einen kleineren Teil eines größeren Netzwerks [nicht dargestellt] der Organisation repräsentieren und kann andere Komponenten umfassen und/oder in anderen Topologien angeordnet sein, die im Beispiel von 4 nicht gezeigt werden.
  • In diesem Beispiel kommuniziert das Mobilgerät 100 mit dem LAN 250 über einen Knoten 202 des Drahtlosnetzwerks 200 und eine gemeinsam verwendete Infrastruktur 224 wie beispielsweise ein Dienstanbieternetzwerk oder das öffentliche Internet. Der Zugriff auf das LAN 250 kann durch einen oder mehrere Router [nicht dargestellt] ermöglicht werden, und die Computergeräte des LAN 250 können hinter einer Firewall oder einem Proxyserver 266 operieren.
  • In einer abweichenden Implementierung umfasst das LAN 250 einen drahtlosen VPN-Router [nicht dargestellt], um den Datenaustausch zwischen dem LAN 250 und dem Mobilgerät 100 zu ermöglichen. Das Konzept eines drahtlosen VPN-Routers ist in der Drahtlosindustrie noch neu, und es impliziert, dass eine VPN-Verbindung direkt über ein spezielles drahtloses Netzwerk zum Mobilgerät 100 eingerichtet werden kann. Die Möglichkeit zur Verwendung eines drahtlosen VPN-Routers steht erst seit kurzem zur Verfügung und könnte verwendet werden, wenn die neue Version 6 des Internetprotokolls (IPV6) in IP-basierte Drahtlosnetzwerke eingeführt wird. Dieses neue Protokoll wird ausreichend IP-Adressen bereitstellen, um jedem Mobilgerät eine IP-Adresse zuzuordnen, wodurch es möglich wird, jederzeit Informationen zu einem Mobilgerät zu pushen. Ein Vorteil der Verwendung eines drahtlosen VPN-Routers besteht darin, dass es sich dabei um eine Standard-VPN-Komponente handeln kann, für deren Verwendung kein separates drahtloses Gateway und keine separate drahtlose Infrastruktur erforderlich ist. Eine VPN-Verbindung wäre vorzugsweise eine Transmission Control Protocol (TCP)/IP- oder User Datagram Protocol (UDP)/IP-Verbindung, um die Nachrichten in dieser abweichenden Implementierung direkt an das Mobilgerät 100 zu liefern.
  • Die für einen Benutzer des Mobilgeräts 100 bestimmten Nachrichten werden anfänglich von einem Nachrichtenserver 268 des LAN 250 empfangen. Solche Nachrichten können von jeder aus einer Reihe von Quellen stammen. Beispielsweise kann eine Nachricht durch einen Absender von einem Computer 262b innerhalb des LAN 250, von einem anderen Mobilgerät [nicht dargestellt], das mit dem Drahtlosnetzwerk 200 oder mit einem anderen Drahtlosnetzwerk verbunden ist, oder von einem anderen Computergerät oder einem anderen Gerät, das zum Senden von Nachrichten in der Lage ist, über die gemeinsam verwendete Netzwerkinfrastruktur 224 und möglicherweise z. B. über einen Anwendungsdienstanbieter (Application Service Provider – ASP) oder Internet-Dienstanbieter (Internet Service Provider – ISP) gesendet worden sein.
  • Der Nachrichtenserver 268 agiert typischerweise als die primäre Schnittstelle für den Austausch von Nachrichten, insbesondere von E-Mail-Nachrichten, innerhalb der Organisation und über die gemeinsam verwendete Netzwerkinfrastruktur 224. Jedem Benutzer in der Organisation, der zum Senden und Empfangen von Nachrichten eingerichtet ist, ist typischerweise ein Benutzerkonto zugeordnet, das durch den Nachrichtenserver 268 verwaltet wird. Ein Beispiel eines Nachrichtenservers 268 ist ein Microsoft ExchangeTM-Server. In einigen Implementierungen kann das LAN 250 mehrere Nachrichtenserver 268 umfassen. Der Nachrichtenserver 268 kann auch so angepasst sein, dass er über die Nachrichtenverwaltung hinaus zusätzliche Funktionen bereitstellt, wozu die Verwaltung von Daten zählt, die beispielsweise Kalendern und Aufgabenlisten zugeordnet sind.
  • Wenn die Nachrichten vom Nachrichtenserver 268 empfangen werden, werden sie typischerweise in einem Nachrichtenspeicher [nicht explizit dargestellt] gespeichert, von dem die Nachrichten nachfolgend abgerufen und an die Benutzer geliefert werden können. Beispielsweise kann eine auf einem Benutzercomputer 262a ausgeführte E-Mail-Clientanwendung die auf dem Nachrichtenserver 268 gespeicherten E-Mail-Nachrichten abrufen, die dem Konto dieses Benutzers zugeordnet sind. Diese Nachrichten würden dann typischerweise vom Nachrichtenserver 268 abgerufen und lokal auf dem Computer 262a gespeichert werden.
  • Beim Betrieb des Mobilgeräts 100 kann der Benutzer wünschen, dass E-Mail-Nachrichten abgerufen und auf das Handgerät geliefert werden. Eine auf dem Mobilgerät 100 ausgeführte E-Mail-Clientanwendung kann auch die dem Konto des Benutzers zugeordneten Nachrichten von Nachrichtenserver 268 anfordern. Der E-Mail-Client kann so konfiguriert sein (entweder durch den Benutzer oder durch einen Administrator, möglicherweise in Übereinstimmung mit den IT-Richtlinien (Information Technology) einer Organisation), um diese Anforderung auf Anweisung des Benutzers, in einem vorbestimmten Zeitintervall oder beim Auftreten eines vordefinierten Ereignisses durchzuführen. In einigen Implementierungen ist dem Mobilgerät 100 seine eigene E-Mail-Adresse zugeordnet, und die speziell an das Mobilgerät 100 adressierten Nachrichten werden automatisch zum Mobilgerät 100 weitergeleitet, wenn sie durch den Nachrichtenserver 268 empfangen werden.
  • Um die drahtlose Kommunikation von Nachrichten und nachrichtenbezogenen Daten zwischen dem Mobilgerät 100 und den Komponenten des LAN 250 zu ermöglichen, können eine Anzahl von Drahtloskommunikations-Unterstützungskomponenten 270 vorhanden sein. In dieser Beispielimplementierung umfassen die Drahtloskommunikations-Unterstützungskomponenten 270 beispielsweise einen Nachrichtenverwaltungsserver 272. Der Nachrichtenverwaltungsserver 272 wird verwendet, um speziell die Unterstützung für die Verwaltung von Nachrichten wie E-Mail-Nachrichten bereitzustellen, die durch Mobilgeräte gehandhabt werden sollen. Im Allgemeinen kann der Nachrichtenverwaltungsserver 272 verwendet werden, um zu steuern, wann, ob und wie Nachrichten zum Mobilgerät 100 gesendet werden, obwohl die Nachrichten weiterhin wie vor auf dem Nachrichtenserver 268 gespeichert werden. Der Nachrichtenverwaltungsserver 272 ermöglicht auch die Handhabung der auf dem Mobilgerät 100 erstellten Nachrichten, die zum Nachrichtenserver 268 gesendet werden, um anschließend ausgeliefert zu werden.
  • Beispielsweise kann der Nachrichtenverwaltungsserver 272: die „Mailbox" (z. B. den Nachrichtenspeicher, der dem Benutzerkonto auf dem Nachrichtenserver 268 zugeordnet ist) des Benutzers überwachen; vom Benutzer definierbare Filter auf neue Nachrichten anwenden, um zu ermitteln, ob und wie die Nachrichten an das Mobilgerät 100 des Benutzers weitergeleitet werden sollen; neue Nachrichten komprimieren und verschlüsseln (z. B. unter Verwendung einer Verschlüsselungstechnik wie Data Encryption Standard (DES) oder Triple DES) und sie über die gemeinsam verwendete Netzwerkinfrastruktur 224 und das Drahtlosnetzwerk 200 zum Mobilgerät 100 pushen; und auf dem Mobilgerät 100 erstellte Nachrichten (die z. B. mit Triple DES verschlüsselt wurden) empfangen, die erstellten Nachrichten entschlüsseln und dekomprimieren, die erstellten Nachrichten auf Wunsch umformatieren, sodass sie so erscheinen, als würden sie vom Computer 262a des Benutzers stammen, und die erstellten Nachrichten zum Nachrichtenserver 268 weiterleiten, um sie auszuliefern.
  • Bestimmte Eigenschaften oder Einschränkungen, die den Nachrichten zugeordnet sind, welche vom Mobilgerät 100 gesendet und/oder empfangen werden sollen, können durch den Nachrichtenverwaltungsserver 272 definiert (z. B. durch einen Administrator in Übereinstimmung mit einer IT-Richtlinie) und durchgesetzt werden. Dazu kann beispielsweise gehören, ob das Mobilgerät 100 verschlüsselte und/oder signierte Nachrichten empfangen kann, welche Mindestgröße die Verschlüsselungsschlüssel haben, ob ausgehende Nachrichten verschlüsselt und/oder signiert werden müssen und ob Kopien von allen sicheren Nachrichten, die vom Mobilgerät 100 gesendet wurden, zu einer vordefinierten Kopieradresse gesendet werden sollen.
  • Der Nachrichtenverwaltungsserver 272 kann auch so angepasst sein, dass er andere Steuerungsfunktionen bereitstellt, zum Beispiel nur das Pushing bestimmter Nachrichteninformationen oder vordefinierter Abschnitte (z. B. „Blöcke") einer auf dem Nachrichtenserver 268 gespeicherten Nachricht zum Mobilgerät 100. Wenn beispielsweise eine Nachricht anfänglich durch das Mobilgerät 100 vom Nachrichtenserver 268 abgerufen wird, ist der Nachrichtenverwaltungsserver 272 so angepasst, dass er nur den ersten Teil einer Nachricht zum Mobilgerät 100 pusht, wobei der Teil eine vordefinierte Größe (z. B. 2 KB) hat. Der Benutzer kann dann weitere Teile der Nachricht anfordern, die in gleichgroßen Blöcken durch den Nachrichtenverwaltungsserver 272 zum Mobilgerät 100 geliefert werden, möglicherweise bis zu einer maximalen vordefinierten Nachrichtengröße.
  • Demnach ermöglicht der Nachrichtenverwaltungsserver 272 eine bessere Steuerung des Datentyps und der Datenmenge, die zum Mobilgerät 100 kommuniziert werden sollen, und kann dazu beitragen, potenzielle Verschwendung von Bandbreite und anderen Ressourcen zu minimieren.
  • Dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass der Nachrichtenverwaltungsserver 272 nicht als ein separater physischer Server im LAN 250 oder einem anderen Netzwerk implementiert sein muss. Beispielsweise können einige oder alle Funktionen, die dem Nachrichtenverwaltungsserver 272 zugeordnet sind, auch in den Nachrichtenserver 268 oder in irgendeinen anderen Server im LAN 250 integriert sein. Darüber hinaus kann das LAN 250 mehrere Nachrichtenverwaltungsserver 272 umfassen, insbesondere in abweichenden Implementierungen, bei denen eine große Anzahl von Mobilgeräten unterstützt werden muss.
  • Die Ausführungsformen der vorliegenden Erfindung beziehen sich allgemein auf die Zertifikate, die bei der Verarbeitung von codierten Nachrichten verwendet werden, zum Beispiel bei E-Mail-Nachrichten, die verschlüsselt und/oder signiert sind. Während Simple Mail Transfer Protocol (SMTP), der RFC822-Kopf und Teile des Bestandteile des Hauptkörpers von Multipurpose Internet Mail Extensions (MIME) verwendet werden können, um das Format einer typischen E-Mail-Nachricht zu definieren, die keine Codierung erfordert, kann Secure/MIME (S/MIME), eine Version des MIME-Protokolls, bei der Kommunikation von codierten Nachrichten verwendet werden (z. B. in sicheren Nachrichtenanwendungen). S/MIME ermöglicht End-to-End-Authentifikation und -Vertraulichkeit und schützt die Datenintegrität und -sicherheit von dem Zeitpunkt, zu dem ein Erzeuger einer Nachricht eine Nachricht sendet, bis zum Decodieren und Lesen der Nachricht durch den Nachrichtenempfänger. Andere bekannte Standards und Protokolle können eingesetzt werden, um eine sichere Nachrichtenkommunikation zu ermöglichen, zum Beispiel Pretty Good PrivacyTM (PGP), OpenPGP und andere aus dem Stand der Technik bekannte.
  • Sichere Nachrichtenprotokolle wie S/MIME basieren auf öffentlichen und privaten Schlüsseln, um die Vertraulichkeit und Integrität zu gewährleisten, sowie auf einer Public Key Infrastructure (PKI) zum Kommunizieren von Informationen, die für die Authentifikation und Autorisierung sorgen. Daten, die unter Verwendung eines privaten Schlüssels aus einem Paar aus privatem Schlüssel und öffentlichem Schlüssel verschlüsselt wurden, können nur entschlüsselt werden, wenn der entsprechende öffentliche Schlüssel des Paares verwendet wird und umgekehrt. Die Informationen des privaten Schlüssels werden niemals öffentlich gemacht, wogegen die Informationen des öffentlichen Schlüssels weitergegeben werden.
  • Wenn zum Beispiel ein Absender eine Nachricht in verschlüsselter Form an einen Empfänger senden möchte, wird der öffentliche Schlüssel des Empfängers zum Verschlüsseln einer Nachricht verwendet, die dann nur mithilfe des privaten Schlüssels des Empfängers entschlüsselt werden kann. Alternativ wird in einigen Codierungstechniken ein Sitzungsschlüssel zur einmaligen Verwendung erzeugt und zum Verschlüsseln des Nachrichtenhauptteils verwendet, was typischerweise mit einer symmetrischen Verschlüsselungstechnik (z. B. Triple DES) erfolgt. Der Sitzungsschlüssel wird dann mithilfe des öffentlichen Schlüssels des Empfängers (z. B. mit einem Algorithmus zur Verschlüsselung mit öffentlichen Schlüsseln wie RSA) verschlüsselt, der dann nur mithilfe des privaten Schlüssels des Empfängers wieder entschlüsselt werden kann. Der entschlüsselte Sitzungsschlüssel kann dann zum Entschlüsseln des Nachrichtenhauptteils verwendet werden. Der Nachrichtenkopf kann verwendet werden, um das spezielle Verschlüsselungsschema zu spezifizieren, das zum Entschlüsseln der Nachricht verwendet werden muss. In abweichenden Implementierungen können andere auf der Kryptografie mit öffentlichen Schlüsseln basierende Verschlüsselungstechniken verwendet werden. Allerdings kann in jedem dieser Fälle nur der private Schlüssel des Empfängers verwendet werden, um die Entschlüsselung der Nachricht zu ermöglichen, und auf diese Weise kann die Vertraulichkeit der Nachrichten gewahrt werden.
  • Als ein weiteres Beispiel kann ein Absender eine Nachricht unter Verwendung einer digitalen Signatur signieren. Eine digitale Signatur ist eine unter Verwendung des privaten Schlüssels des Absenders codierte Zusammenfassung der Nachricht (z. B. ein Hash der Nachricht), die dann an die ausgehende Nachricht angehängt werden kann. Um die digitale Signatur der Nachricht beim Empfang zu verifizieren, verwendet der Empfänger dieselbe Technik wie der Absender (z. B. denselben standardmäßigen Hash-Algorithmus), um eine Zusammenfassung der empfangenen Nachricht zu erhalten. Der Empfänger verwendet auch den öffentlichen Schlüssel des Absenders, um die digitale Signatur zu decodieren, um das zu erhalten, was eine übereinstimmende Zusammenfassung der empfangenen Nachricht sein sollte. Wenn die Zusammenfassungen der empfangenen Nachricht nicht übereinstimmen, lässt das darauf schließen, dass entweder der Nachrichteninhalt während des Transports geändert wurde und/oder dass die Nachricht nicht von dem Absender stammt, dessen öffentlicher Schlüssel zur Verifikation verwendet wurde. Digitale Signaturalgorithmen sind so konstruiert, dass nur jemand, der Kenntnis vom privaten Schlüssel des Absenders hat, in der Lage sein sollte, eine Signatur zu codieren, die der Empfänger mithilfe des öffentlichen Schlüssels des Absenders korrekt decodiert. Deshalb kann durch die Verifikation einer digitalen Signatur in dieser Weise die Authentifikation des Absenders und die Nachrichtenintegrität gewahrt werden.
  • Eine codierte Nachricht kann verschlüsselt, signiert oder sowohl verschlüsselt als auch signiert werden. Die Authentizität der bei diesen Operationen verwendeten öffentlichen Schlüssel wird mithilfe von Zertifikaten auf Gültigkeit geprüft. Ein Zertifikat ist ein digitales Dokument, das von einer Zertifikatstelle (Certificate Authority – CA) ausgestellt wird. Zertifikate werden zur Authentifikation des Zusammenhangs zwischen Benutzern und ihren privaten Schlüsseln verwendet und ermöglichen im Wesentlichen einen Grad an Vertrauen in die Authentizität der öffentlichen Schlüssel der Benutzer. Zertifikate enthalten Informationen über den Zertifikatinhaber, wobei die Zertifikatinhalte typischerweise entsprechend einem akzeptierten Standard (z. B. X.509) formatiert sind.
  • In 5 ist ein Beispiel einer Zertifikatkette 300 dargestellt. Das für „John Smith" ausgestellte Zertifikat 310 ist ein Beispiel für ein Zertifikat, das für eine Person ausgestellt wurde, und kann als ein End-Entity-Zertifikat bezeichnet werden. Das End-Entity-Zertifikat 310 identifiziert typischerweise den Zertifikatinhaber 312 (d. h. in diesem Beispiel John Smith) und den Aussteller des Zertifikats 314 und enthält eine digitale Signatur des Ausstellers 316 sowie den öffentlichen Schlüssel 318 des Zertifikatinhabers. Das Zertifikat 310 enthält typischerweise auch andere Informationen und Attribute, die den Zertifikatinhaber identifizieren (z. B. E-Mail-Adresse, Name der Organisation, Name der Organisationseinheit, Standort usw.). Wenn die Person eine Nachricht erstellt, die an einen Empfänger gesendet werden soll, ist es üblich, das Zertifikat 310 der Person in die Nachricht einzuschließen.
  • Damit ein öffentlicher Schlüssel als vertrauenswürdig gelten kann, muss dessen ausstellende Organisation vertrauenswürdig sein. Die Beziehung zwischen einer vertrauenswürdigen CA und dem öffentlichen Schlüssel eines Benutzers kann durch eine Reihe von miteinander verbundenen Zertifikaten repräsentiert werden, die auch als Zertifikatkette bezeichnet wird. Die Zertifikatkette kann verfolgt werden, um die Gültigkeit eines Zertifikats zu ermitteln.
  • Bei der in 5 dargestellten Beispielzertifikatkette 300 kann beispielsweise der Empfänger einer Nachricht, die vorgeblich von John Smith gesendet wurde, eine Verifikation des Vertrauenswürdigkeitsstatus des an die empfangene Nachricht angehängten Zertifikats 310 wünschen. Um beispielsweise den Vertrauenswürdigkeitsstatus des Zertifikats 310 auf dem Computergerät eines Empfängers (z. B. dem Computer 262a aus 4) zu verifizieren, wird das Zertifikat 320 des Ausstellers ABC herangezogen und verwendet, um zu verifizieren, dass das Zertifikat 310 tatsächlich durch den Aussteller ABC signiert wurde. Das Zertifikat 320 kann bereits in einem Zertifikatspeicher auf dem Computergerät gespeichert sein, oder es muss eventuell erst von einer Zertifikatquelle (z. B. LDAP-Server 284 aus 4 oder einem anderen öffentlichen oder privaten LDAP-Server) abgerufen werden. Wenn das Zertifikat 320 bereits auf dem Computergerät des Empfängers gespeichert ist und das Zertifikat bereits durch den Empfänger als vertrauenswürdig ausgewiesen wurde, wird auch das Zertifikat 310 als vertrauenswürdig betrachtet, da es mit einem gespeicherten vertrauenswürdigen Zertifikat verkettet ist.
  • Allerdings muss im in 5 gezeigten Beispiel das Zertifikat 330 auch den Vertrauenswürdigkeitsstatus von Zertifikat 310 verifizieren. Das Zertifikat 330 ist selbstsigniert und wird als ein „Stammzertifikat" betrachtet. Dementsprechend kann das Zertifikat 320 als ein „Zwischenzertifikat" innerhalb der Zertifikatkette 300 betrachtet werden; jedes Zertifikat ist mit einem Stammzertifikat verkettet, wobei davon ausgegangen wird, dass eine Kette zum Stammzertifikat für ein bestimmtes End-Entity-Zertifikat ermittelt werden kann, die null, ein oder mehrere Zwischenzertifikate enthalten kann. Wenn Zertifikat 330 ein Stammzertifikat ist, das von einer vertrauenswürdigen Quelle ausgestellt wurde (zum Beispiel von einer großen Zertifikatstelle wie Verisign oder Entrust), dann kann das Zertifikat 310 als vertrauenswürdig betrachtet werden, weil es mit einem vertrauenswürdigen Zertifikat verkettet ist. Die Folge davon ist, dass sowohl der Sender als auch der Empfänger der Nachricht der Quelle des Stammzertifikats 330 vertrauen. Wenn ein Zertifikat nicht mit einem vertrauenswürdigen Zertifikat verkettet werden kann, kann das Zertifikat als „nicht vertrauenswürdig" angesehen werden.
  • Zertifikatserver speichern Informationen über die Zertifikate und Listen zur Identifizierung der Zertifikate, die bereits widerrufenen wurden. Auf diese Zertifikatserver kann zugegriffen werden, um Zertifikate zu erhalten und um die Zertifikatauthentizität und den Widerrufstatus zu verifizieren. Beispielsweise kann ein LDAP-Server (Lightweight Directory Access Protocol) verwendet werden, um Zertifikate zu erhalten, und ein OCSP-Server (Online Certificate Status Protocol) kann verwendet werden, um den Zertifikatwiderrufstatus zu verifizieren.
  • Standardmäßige E-Mail-Sicherheitsprotokolle ermöglichen typischerweise eine sichere Nachrichtenübertragung zwischen nichtmobilen Computergeräten (z. B. den Computern 262a, 262b aus 4; entfernten Desktopgeräten). Nunmehr wiederum Bezug nehmend auf 4 ist das Mobilgerät 100 angepasst, um Zertifikate und die zugehörigen öffentlichen Schlüssel von anderen Personen zu speichern, damit von Absendern empfangene signierte Nachrichten vom Mobilgerät 100 gelesen und verschlüsselte Nachrichten an diese Absender gesendet werden können. Die auf einem Benutzercomputer 262a gespeicherten Zertifikate werden z. B. typischerweise vom Computer 262a über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen.
  • Die auf dem Computer 262a gespeicherten und zum Mobilgerät 100 heruntergeladenen Zertifikate sind nicht auf Zertifikate beschränkt, die mit Personen verbunden sind, sondern können auch Zertifikate einschließen, die beispielsweise für CAs ausgestellt wurden. Bestimmte auf dem Computer 262a und/oder auf dem Mobilgerät 100 gespeicherte Zertifikate können durch den Benutzer auch explizit als „vertrauenswürdig" ausgewiesen werden. Entsprechend kann, wenn ein Zertifikat durch einen Benutzer auf dem Mobilgerät 100 empfangen wird, dieses auf dem Mobilgerät 100 verifiziert werden, indem eine Übereinstimmung des Zertifikats mit einem auf dem Mobilgerät 100 gespeicherten festgestellt wird und es als vertrauenswürdig ausgewiesen wird oder ansonsten als mit einem vertrauenswürdigen Zertifikat verkettet ermittelt wird.
  • Das Mobilgerät 100 kann auch so angepasst sein, dass es den privaten Schlüssel des dem Benutzer zugeordneten Paars aus öffentlichem und privatem Schlüssel speichert, sodass der Benutzer des Mobilgeräts 100 die auf dem Mobilgerät 100 erstellten ausgehenden Nachrichten signieren und mit dem öffentlichen Schlüssel des Benutzers verschlüsselte Nachrichten entschlüsseln kann, die zum Benutzer gesendet wurden. Der private Schlüssel kann beispielsweise über die Dockingstation 264 vom Computer 262a des Benutzers auf das Mobilgerät 100 heruntergeladen werden. Der private Schlüssel wird vorzugsweise zwischen dem Computer 262a und dem Mobilgerät 100 ausgetauscht, sodass der Benutzer eine Identität und ein Verfahren zum Zugriff auf Nachrichten auf beiden Geräten verwenden kann.
  • Die Benutzercomputer 262a, 262b können Zertifikate von einer Anzahl von Quellen erhalten, um sie auf den Computern 262a, 262b und/oder auf Mobilgeräten (z. B. Mobilgerät 100) zu speichern. Diese Zertifikatquellen können privat (z. B. speziell zur Verwendung in einer Organisation vorgesehen) oder öffentlich sein, können lokal oder entfernt gespeichert sein und können beispielsweise aus dem privaten Netzwerk einer Organisation heraus oder über das Internet zugänglich sein. Im in 4 gezeigten Beispiel befinden sich im LAN 250 mehrere PKI-Server 280, die der Organisation zugeordnet sind. Die PKI-Server 280 schließen einen CA-Server 282 zum Ausstellen von Zertifikaten, einen LDAP-Server 284 zum Suchen und Herunterladen von Zertifikaten (z. B. für Personen innerhalb der Organisation) und einen OCSP-Server 286 zum Verifizieren des Widerrufstatus von Zertifikaten ein.
  • Zertifikate können vom LDAP-Server 284 zum Beispiel durch einen Benutzercomputer 262a abgerufen werden, um sie über die Dockingstation 264 auf das Mobilgerät 100 herunterzuladen. Allerdings kann in einer abweichenden Implementierung der Zugriff auf den LDAP-Server 284 durch das Mobilgerät 100 direkt (d. h. in diesem Kontext „durch die Luft") erfolgen, und das Mobilgerät 100 kann durch einen mobilen Datenserver 288 nach individuellen Zertifikaten suchen und diese abrufen. In gleicher Weise kann der mobile Datenserver 288 so angepasst sein, dass dem Mobilgerät 100 die direkte Abfrage des OCSP-Servers 286 ermöglicht wird, um den Widerrufstatus von Zertifikaten zu verifizieren.
  • In abweichenden Implementierungen können nur ausgewählte PKI-Server 280 für Mobilgeräte zugänglich gemacht werden (wodurch z. B. das Herunterladen von Zertifikaten nur von einem Benutzercomputer 262a, 262b ermöglicht wird, während der Widerrufstatus von Zertifikaten vom Mobilgerät 100 aus überprüft werden kann).
  • In abweichenden Implementierungen können bestimmte PKI-Server 280 nur für Mobilgeräte zugänglich gemacht worden sein, die für bestimmte Benutzer registriert sind, wie das durch einen IT-Administrator spezifiziert wurde, möglicherweise z. B. in Übereinstimmung mit einer IT-Richtlinie.
  • Andere Quellen von Zertifikaten [nicht dargestellt] können z. B. einen Windows-Zertifikatspeicher, einen anderen sicheren Zertifikatspeicher im oder außerhalb des LAN 250 und SmartCards einschließen.
  • Nunmehr Bezug nehmend auf 6 ist ein Blockdiagramm zur Darstellung der Komponenten eines Beispiels einer codierten Nachricht, wie sie von einem Nachrichtenserver (z. B. Nachrichtenserver 268 aus 4) empfangen werden kann, allgemein als 350 bezeichnet. Die codierte Nachricht 350 schließt typischerweise eine oder mehrere der folgenden Komponenten ein: einen Kopfabschnitt 352, einen codierten Hauptteilabschnitt 354, optional einen oder mehrere codierte Anhänge 356, einen oder mehrere verschlüsselte Sitzungsschlüssel 358 sowie eine Signatur und signaturbezogene Informationen 360. Beispielsweise schließt der Kopfabschnitt 352 typischerweise Adressierungsinformationen wie „An"-, „Von"- und „CC"-Adressen ein und kann auch beispielsweise Angaben zur Nachrichtenlänge und Kennungen der Absenderverschlüsselung und des Signaturschemas enthalten. Der eigentliche Nachrichteninhalt schließt normalerweise einen Nachrichtenhauptteil oder den Datenabschnitt 354 und möglicherweise einen oder mehrere Anhänge 356 ein und kann durch den Absender unter Verwendung eines Sitzungsschlüssels verschlüsselt worden sein. Wenn ein Sitzungsschlüssel verwendet wurde, wurde er typischerweise für jeden vorgesehenen Empfänger mithilfe des jeweiligen öffentlichen Schlüssels für jeden Empfänger verschlüsselt und in 358 in die Nachricht einbezogen. Wenn die Nachricht signiert war, werden auch eine Signatur und signaturbezogene Informationen 360 einbezogen. Das kann beispielsweise das Zertifikat des Absenders einschließen.
  • Das Format für eine codierte Nachricht wird in 6 lediglich anhand eines Beispiels gezeigt, und dem Fachmann auf dem Gebiet der Technik wird verständlich sein, dass codierte Nachrichten auch in anderen Formaten existieren können. Beispielsweise können je nach verwendetem speziellen Nachrichtenschema die Komponenten einer codierten Nachricht in einer anderen Reihenfolge auftreten als in 6 gezeigt, und eine codierte Nachricht kann weniger, zusätzliche oder unterschiedliche Komponenten einschließen, was sich danach richten kann, ob die codierte Nachricht verschlüsselt, signiert oder beides ist.
  • Die Ausführungsformen der vorliegenden Erfindung beziehen sich allgemein auf ein System und ein Verfahren, das eine effizientere Verifikation von digitalen Signaturen von Zertifikaten ermöglicht, indem bestimmte Informationen, die zur Verifikation der Signaturen verwendet werden, zur erneuten Verwendung gespeichert werden. Durch das Erstellen von Zertifikatketten (wie das im Beispiel von 5 erläutert wurde), müssen die digitalen Signaturen der Zertifikate oft verifiziert werden. Wenn mehrere Zertifikate auf dem Computergerät eines Benutzers verarbeitet werden, kann dieselbe digitale Signatur oft mehreren Verifikationen unterzogen werden. Das kann insbesondere vorherrschend sein, wo Zertifikatketten gebildet werden, die Kreuzzertifikate enthalten. Kreuzzertifikate werden weiter unten im Zusammenhang mit 7B besprochen.
  • Zunächst Bezug nehmend auf 7A wird ein Blockdiagramm zur Darstellung von zwei beispielhaften Zertifikatketten gezeigt. Die beiden Beispielzertifikatketten werden allgemein als 400a und 400b bezeichnet. Dem Fachmann auf dem Gebiet der Technik wird verständlich sein, dass die Zertifikatketten 400a und 400b als Beispiele vorgesehen sind. Insbesondere kann eine Zertifikatkette eine geringere oder größere Anzahl von Zertifikaten als in den gezeigten Beispielen abgebildet enthalten.
  • Viele Organisationen richten ihre eigenen CAs ein, die Zertifikate speziell für Personen innerhalb ihrer Organisationen ausstellen. End-Entity-Zertifikate, die für Personen innerhalb einer bestimmten Organisation ausgestellt werden, müssen nicht durch eine einzelne CA ausgestellt werden, die der Organisation zugeordnet ist. Ein End-Entity-Zertifikat wird oft durch eine aus einer Anzahl von untergeordneten oder zwischengeordneten CAs innerhalb einer CA-Hierarchie ausgestellt, die durch eine Stamm-CA für die Organisation angeführt wird. Diese Stamm-CA kann ein selbstsigniertes Stammzertifikat bereitstellen, das als ein „Vertrauensanker" verwendet wird – als ein Startpunkt für die Gültigkeitsprüfung von Zertifikaten, die innerhalb der Organisation ausgestellt werden.
  • Die Zertifikatkette 400a zeigt eine beispielhafte Zertifikatkette, die gebildet wird, um die Gültigkeit eines für „Benutzer1" ausgestellten Zertifikats 402a zu prüfen, bei dem es sich um eine Person innerhalb der Organisation „ABC" handelt. Das Zertifikat 402a ist über ein Zwischenzertifikat 406a, das von der Stamm-CA an eine Zwischen-CA der Organisation ausgestellt wurde, mit einem selbstsignierten Stammzertifikat 404a verkettet, das durch eine Stamm-CA der Organisation ausgestellt wurde und das von Benutzer1 für vertrauenswürdig gehalten wird. Die innerhalb der Organisation ABC ausgestellten Zertifikate können durchsucht und von einem LDAP-Server abgerufen werden, der beispielsweise durch die Organisation unterhalten wird (z. B. LDAP-Server 284 aus 4).
  • In gleicher Weise zeigt die Zertifikatkette 400b eine beispielhafte Zertifikatkette, die gebildet wird, um die Gültigkeit eines für „Benutzer2" ausgestellten Zertifikats 402b zu prüfen, bei dem es sich um eine Person innerhalb einer anderen Organisation „XYZ" handelt. Das Zertifikat 402b ist über ein Zwischenzertifikat 406b mit einem selbstsignierten Stammzertifikat 404b verkettet, das durch eine Stamm-CA der Organisation XYZ ausgestellt wurde und das von Benutzer2 für vertrauenswürdig gehalten wird. Die innerhalb der Organisation XYZ ausgestellten Zertifikate können durchsucht und von einem LDAP-Server abgerufen werden, der beispielsweise durch die Organisation XYZ unterhalten wird.
  • Es wird nun von einer Beispielsituation ausgegangen, in der Benutzer1 von Organisation ABC eine codierte Nachricht von Benutzer2 der Organisation XYZ empfängt. Selbst wenn Benutzer2 sein Zertifikat 402b an die Nachricht angehängt hat, ist Benutzer1 nicht in der Lage, den Vertrauenswürdigkeitsstatus des Zertifikats 402b von Benutzer2 allein mit diesem Zertifikat zu verifizieren (wenn davon ausgegangen wird, dass Benutzer1 nicht bereits das Zertifikat 402b von Benutzer2 gespeichert und als vertrauenswürdig markiert hat). Wenn Benutzer1 Zertifikaten von der Organisation XYZ nicht vertraut, dann kann die Gültigkeit des Zertifikats 402b von Benutzer2 nicht geprüft werden, da es nicht mit einem vertrauenswürdigen Zertifikat verkettet ist.
  • Um die sichere Kommunikation zwischen Benutzern unterschiedlicher Organisationen zu ermöglichen, kann es erwünscht sein, dass Zertifikate zwischen den Organisationen verwendet werden und als vertrauenswürdig gelten können. Zwischen zwei Organisationen kann ein Authentifikationsverfahren durchgeführt werden, das als Kreuzzertifizierung bekannt ist, wobei eine CA einer Organisation eine CA der anderen Organisation zertifiziert.
  • Der Begriff Kreuzzertifizierung kann verwendet werden, um allgemein zwei Operationen zu bezeichnen. Die erste Operation, die typischerweise relativ selten durchgeführt wird, bezieht sich auf die Einrichtung einer Vertrauensbeziehung zwischen zwei CAs (z. B. organisationsübergreifend oder innerhalb derselben Organisation) durch das Signieren des öffentlichen Schlüssels von einer CA durch eine andere CA in einem Zertifikat, das als ein Kreuzzertifikat bezeichnet wird. Die zweite Operation, die typischerweise relativ häufig durchgeführt wird, beinhaltet das Verifizieren des Zertifikats eines Benutzers durch die Bildung einer Zertifikatkette, die mindestens ein solches Kreuzzertifikat enthält.
  • Nunmehr Bezug nehmend auf 7B ist ein Blockdiagramm zur Darstellung von Beispielen für Kreuzzertifikate zur Verknüpfung von zwei Beispielzertifikatketten gezeigt. In diesem Beispiel wird ein Kreuzzertifikat 410 gezeigt, das durch die Stamm-CA von Organisation XYZ für die Stamm-CA von Organisation ABC ausgestellt wurde. In gleicher Weise wird ein Kreuzzertifikat 412 gezeigt, dass von der Stamm-CA von Organisation ABC für die Stamm-CA von Organisation XYZ ausgestellt wurde.
  • Das Beispiel von 7B veranschaulicht die gegenseitige Kreuzzertifizierung zwischen zwei Stamm-CAs. Allerdings sind in abweichenden Implementierungen auch andere Kreuzzertifizierungsverfahren möglich. Beispielsweise können Kreuzzertifikate durch eine untergeordnete CA in einer Organisation für die Stamm-CA einer anderen Organisation ausgestellt werden. Als ein weiteres Beispiel kann eine CA einer ersten Organisation ein Kreuzzertifikat für die CA einer zweiten Organisation ausstellen, selbst wenn von der zweiten Organisation im Gegenzug kein Kreuzzertifikat für die erste Organisation ausgestellt wird.
  • Darüber hinaus kann die organisationsübergreifende Verwendung von Zertifikaten eingeschränkt sein, wenn das beispielsweise durch die IT-Richtlinie einer Organisation vorgegeben wird. Beispielsweise kann die IT-Richtlinie einer Organisation vorgeben, dass Zertifikate von anderen Organisationen ausschließlich zum Zweck der Verarbeitung codierter E-Mail-Nachrichten als vertrauenswürdig gelten dürfen. Kreuzzertifikate können auch durch eine ausstellende CA einer Organisation widerrufen werden, um die Vertrauensbeziehung mit anderen Organisationen zu beenden. So kann eine effizientere Steuerung der sicheren E-Mail-Kommunikation zwischen Personen ermöglicht werden, die zu unterschiedlichen Organisationen gehören.
  • Kreuzzertifikate ermöglichen die sichere Kommunikation zwischen Personen von Organisationen, die eine Vertrauensbeziehung eingerichtet haben. Es wird wiederum die Situation angenommen, dass Benutzer1 von Organisation ABC eine codierte Nachricht von Benutzer2 von Organisation XYZ empfängt. Benutzer1 ist in der Lage, den Vertrauenswürdigkeitsstatus des Zertifikats 402b von Benutzer2 zu verifizieren, indem die Zertifikate in einer Kette des Zertifikats 402b von Benutzer1 abgerufen werden, bis zum Stammzertifikat 404a, das durch eine Stamm-CA der Organisation von Benutzer1 ausgestellt wurde und das von Benutzer1 als vertrauenswürdig eingestuft wird. Insbesondere enthält die Kette entsprechend der Beispieldarstellung in 7B das Stammzertifikat 404a von ABC, das Kreuzzertifikat 412, das Stammzertifikat 404b von XYZ, das Zwischenzertifikat 406b und das Zertifikat 402b von Benutzer1.
  • Damit Benutzer1 den Vertrauenswürdigkeitsstatus des Zertifikats 402b von Benutzer1 verifizieren kann, muss Benutzer1 das Zertifikat 402b erhalten. Dieses begleitet üblicherweise die Nachricht von Benutzer1 an Benutzer1; wenn jedoch das Zertifikat 402b nicht bereitgestellt wird oder nicht anderweitig auf dem Computergerät von Benutzer1 gespeichert ist, muss es abgerufen werden, beispielsweise von einem durch die Organisation XYZ unterhaltenen LDAP-Server oder einem anderen Zertifikatserver. Darüber hinaus muss jedes der verbleibenden Zertifikate in der Kette ebenfalls abgerufen werden, um den Vertrauenswürdigkeitsstatus von Zertifikat 402b zu verifizieren. Die anderen Zertifikate in der Kette, die in diesem Beispiel ein Stammzertifikat und ein Kreuzzertifikat einschließen, müssten vom LDAP-Server von ABC, vom LDAP-Server von XYZ oder von einem anderen LDAP-Server abgerufen werden, der für Benutzer1 zugänglich ist.
  • Wie unter Bezugnahme auf 5 und 7A und 7B erwähnt wurde, müssen die digitalen Signaturen von ausstellenden CAs von Zertifikaten oft verifiziert werden, wenn Zertifikatketten erstellt werden. Bei der Gültigkeitsprüfung von Zertifikaten können auch andere Aufgaben durchgeführt werden, beispielsweise die Überprüfung der Gültigkeit des Datums eines Zertifikats oder die Überprüfung anderer Gültigkeitskriterien, die möglicherweise durch eine Organisation beispielsweise in Übereinstimmung mit einer IT-Richtlinie aufgestellt wurden.
  • Die Verifikation einer digitalen Signatur von einem Zertifikat ist ein Prozess, der den öffentlichen Schlüssel der ausstellenden CA erfordert. Wenn eine CA ein Zertifikat digital signiert, werden typischerweise Zertifikatinformationen, beispielsweise einschließlich des Namens und des öffentlichen Schlüssels des Zertifikatinhabers, oder ein Hash dieser Informationen, der durch Anwendung eines Hashing-Algorithmus erstellt wurde, unter Verwendung des privaten Schlüssels der CA codiert. Der Algorithmus, der von der ausstellenden CA zum Signieren eines Zertifikats verwendet wird, ist typischerweise in dem Zertifikat identifiziert. Anschließend kann die digitale Signatur der CA von einem Zertifikat in einer ähnlichen Weise, wie sie zur Verifikation der digitalen Signatur einer von einem Benutzer signierten Nachricht verwendet wird, verifiziert werden, indem die codierten Informationen oder der Hash mithilfe des öffentlichen Schlüssels der CA decodiert werden und das Ergebnis mit den erwarteten Zertifikatinformationen bzw. mit deren Hash verglichen wird. Eine erfolgreiche Übereinstimmung zeigt an, dass durch die CA verifiziert wurde, dass der öffentliche Schlüssel des Zertifikatinhabers in gültiger Weise an den Zertifikatinhaber gebunden werden kann, und lässt darauf schließen, dass der öffentliche Schlüssel des Zertifikatinhabers als vertrauenswürdig gelten kann, wenn die CA vertrauenswürdig ist.
  • Die Verifikation von Zertifikatsignaturen kann ein sowohl zeitaufwändiger als auch kostspieliger Prozess sein (z. B. in Bezug auf die Verwendung von Computerressourcen), insbesondere wenn die Verifikationen auf kleinen Geräten durchgeführt werden wie beispielsweise Mobilgeräten. Die Ausführungsformen der vorliegenden Erfindung beziehen sich allgemein auf ein System und ein Verfahren, das eine effizientere Verifikation von digitalen Signaturen von Zertifikaten ermöglicht, indem bestimmte Informationen gespeichert werden, die für Signaturverifikationsoperationen verwendet werden, um sie erneut verwenden zu können.
  • In mindestens einer Ausführungsform sind ein oder mehrere öffentliche Schlüssel einer CA, die ein bestimmtes Zertifikat ausgestellt hat, diesem Zertifikat zugeordnet und werden im Cache zwischengespeichert oder gespeichert. Wie oben angedeutet wurde, ist der öffentliche Schlüssel der CA erforderlich, wenn versucht wird, eine digitale Signatur von einem Zertifikat zu verifizieren, das durch eine CA signiert wurde. Allerdings können mehrere Zertifikate existieren (denen jeweils ein öffentlicher Schlüssel angehängt ist), die scheinbar zur selben CA gehören. Diese Situation könnte beispielsweise auftreten, wenn mehrere Zertifikate dieselben oder ähnliche Subjektdaten haben (d. h. die Zertifikatdaten, die den Zertifikatinhaber identifizieren) oder wenn der CA mehrere öffentliche Schlüssel ausgestellt wurden (von denen einige nicht mehr gültig sein können). Dementsprechend kann es von Vorteil sein zu verfolgen, welcher bestimmte öffentliche Schlüssel bereits verwendet wurde, um ein bestimmtes Zertifikat erfolgreich zu verifizieren.
  • Bezug nehmend auf 8 wird ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zur Verifikation von digitalen Signaturen von Zertifikaten in einer Ausführungsform der Erfindung allgemein als 420 gezeigt.
  • In einer Ausführungsform der Erfindung werden zumindest einige der Schritte des Verfahrens durch eine Anwendung zur Zertifikatgültigkeitsprüfung durchgeführt, die sich auf einem Mobilgerät befindet und dort ausgeführt wird. In abweichenden Ausführungsformen kann sich die Anwendung zur Zertifikatgültigkeitsprüfung auf einem anderen Computergerät als dem Mobilgerät befinden und auf diesem anderen Gerät ausgeführt werden. Darüber hinaus muss die Anwendung zur Zertifikatgültigkeitsprüfung keine eigenständige Anwendung sein, und die Funktionalität der Anwendung zur Zertifikatgültigkeitsprüfung kann in eine oder mehrere Anwendungen implementiert sein, die sich auf dem Mobilgerät oder auf einem anderen Computergerät befinden und dort ausgeführt werden.
  • Allgemein wird beim Verfahren 420, wenn ein bestimmter öffentlicher Schlüssel zur erfolgreichen Verifikation der digitalen Signatur von einem Zertifikat verwendet wurde, eine Kopie dieses öffentlichen Schlüssels im Cache zwischengespeichert oder auf andere Weise in einem Speicherbereich gespeichert. Beispielsweise kann der öffentliche Schlüssel gemeinsam mit den Zertifikatdaten gespeichert werden, die dem Zertifikat zugeordnet sind, oder in einem separaten Speicherbereich (z. B. in einer Referenztabelle), der zum Speichern der zur erfolgreichen Signaturverifikation verwendeten öffentlichen Schlüssel angepasst ist. Wenn ein nachfolgender Versuch zur Verifikation der digitalen Signatur für dasselbe Zertifikat unternommen wird, wird nicht sofort eine aufwändige Signaturverifikationsoperation durchgeführt, für die mindestens das Decodieren einiger Daten mithilfe eines öffentlichen Schlüssels erforderlich wäre, sondern stattdessen wird der öffentliche Schlüssel, der zur erneuten Verifikation der digitalen Signatur verwendet worden wäre, zuerst mit dem gespeicherten öffentlichen Schlüssel verglichen. Wenn diese öffentlichen Schlüssel übereinstimmen, gilt die Verifikation als erfolgreich, weil der zu verwendende öffentliche Schlüssel mit einem Schlüssel übereinstimmt, der zuvor erfolgreich in einer Signaturverifikationsoperation verwendet wurde. Es wird als unnötig angesehen, für dieselbe digitale Signatur erneut die eigentliche Signaturverifikationsoperation durchzuführen. Dementsprechend können zumindest einige nachfolgende Signaturverifikationsoperationen durch effizientere Vergleichsoperationen (z. B. Byte-Array) ersetzt werden. Es folgt eine detaillierte Beschreibung der Schritte des Verfahrens 420.
  • In Schritt 430 wird eine Verifikation einer digitalen Signatur von einem Zertifikat initiiert (z. B. durch die Anwendung zur Zertifikatgültigkeitsprüfung). Verifikationen von digitalen Signaturen von Zertifikaten können beispielsweise durchgeführt werden, wenn Zertifikatketten erstellt werden, um die Gültigkeit bestimmter von einem Benutzer empfangenen Zertifikate zu prüfen (um z. B. den Vertrauenswürdigkeitstatus eines Zertifikats zu verifizieren, das an eine empfangene Nachricht angehängt ist, wie das unter Bezug auf 5 erläutert wurde). In dieser Ausführungsform handelt es sich bei den zu verifizierenden digitalen Signaturen von Zertifikaten um die der Zertifizierungsstellen, von denen die jeweiligen Zertifikate ausgestellt wurden. Wie bereits oben erwähnt wurde, wird für eine Signaturverifikationsoperation ein öffentlicher Schlüssel der Zertifizierungsstelle, die das Zertifikat ausgestellt hat, benötigt. In diesem Schritt ist eventuell das Abrufen eines Zertifikats oder von Zertifikaten und eines öffentlichen Schlüssels oder von öffentlichen Schlüsseln (z. B. von einem LDAP-Server) erforderlich, wenn diese noch nicht in einem Zertifikatspeicher auf dem Mobilgerät oder einem anderen Computergerät gespeichert sind.
  • Für einen gegebenen öffentlichen Schlüssel wird in Schritt 440, vor der Durchführung der Signaturverifikationsoperation mithilfe dieses öffentlichen Schlüssels, ermittelt, ob die digitale Signatur von dem betreffenden Zertifikat bereits zuvor erfolgreich mithilfe dieses öffentlichen Schlüssels verifiziert wurde. Wie oben angedeutet wurde, kann das erfolgen, indem ein gespeicherter öffentlicher Schlüssel für die Zertifikatausgabestelle, der zuvor zur erfolgreichen Verifikation der digitalen Signatur vom betreffenden Zertifikat verwendet wurde (sofern ein solcher existiert und in Schritt 470 im Cache oder einem anderen Speicherbereich gespeichert wurde), mit dem öffentlichen Schlüssel verglichen wird, der zur Verifikation der digitalen Signatur verwendet werden soll, und dann ermittelt wird, ob es eine Übereinstimmung gibt. Da in dieser Ausführungsform ausschließlich öffentliche Schlüssel im Cache oder in einem anderen Speicherbereich gespeichert werden, die bereits für erfolgreiche Verifikationsversuche verwendet wurden, würde die Ermittlung einer Übereinstimmung nahe legen, dass die digitale Signatur vom betreffenden Zertifikat zuvor bereits erfolgreich verifiziert wurde.
  • Wenn die digitale Signatur vom betreffenden Zertifikat zuvor nicht erfolgreich mit dem öffentlichen Schlüssel verifiziert wurde, wird anschließend in Schritt 450 die digitale Signatur unter Verwendung des öffentlichen Schlüssels in bekannter Art und Weise verifiziert. Wenn die Signatur mithilfe dieses öffentlichen Schlüssels erfolgreich verifiziert wurde, was in Schritt 460 ermittelt wird, wird der öffentliche Schlüssel, der für diese erfolgreiche Verifikation verwendet wurde, in Schritt 470 entsprechend dieser Ausführungsform im Cache oder in einem anderen Speicherbereich gespeichert, um ihn später erneut verwenden zu können. Beispielsweise kann der in Schritt 470 gespeicherte öffentliche Schlüssel zusammen mit den Daten gespeichert werden, die dem betreffenden Zertifikat zugeordnet sind, oder in einem zentralen Speicherbereich für öffentliche Schlüssel (z. B. in einer Referenztabelle) mit Indizierung nach Zertifikat (z. B. durch Speichern des Ausstellernamens und der Seriennummer des Zertifikats zusammen mit dem öffentlichen Schlüssel).
  • Wenn dagegen die digitale Signatur vom betreffenden Zertifikat bereits zuvor mithilfe des gegebenen privaten Schlüssels erfolgreich verifiziert wurde, was in Schritt 440 ermittelt wird, dann wird in Schritt 480 eine Anzeige bereitgestellt, dass die Verifikation erfolgreich ist. Dies erfolgt anstelle der Durchführung einer tatsächlichen Signaturverifikationsoperation, für die mindestens die Decodierung einiger Daten mithilfe des öffentlichen Schlüssels erforderlich wäre, wodurch der Signaturverifikationsprozess effizienter gemacht wird. Dies kann zur Einsparung von Batterieleistung beitragen und den Gesamtnutzen für den Benutzer steigern, was insbesondere für kleine Geräte wie Mobilgeräte gilt.
  • Die Schritte des Verfahrens 420 können für zusätzliche öffentliche Schlüssel wiederholt werden.
  • Nunmehr Bezug nehmend auf 8B ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zur Verifikation von digitalen Signaturen von Zertifikaten in einer anderen Ausführungsform der Erfindung allgemein als 420b gezeigt.
  • Das Verfahren 420b gleicht dem Verfahren 420, außer dass im Gegensatz zum Verfahren 420, bei dem ausschließlich die öffentlichen Schlüssel im Cache oder in einem anderen Speicherbereich gespeichert werden, die bereits für erfolgreiche Signaturverifikationen verwendet wurden, beim Verfahren 420b die öffentlichen Schlüssel, die für jegliche Signaturverifikationsversuche (ob nun erfolgreich oder erfolglos) verwendet wurden, zusammen mit dem Ergebnis des Verifikationsversuchs im Cache oder in einem anderen Speicherbereich gespeichert werden.
  • Allgemein wird im Verfahren 420b, wenn ein bestimmter Schlüssel zur Verifikation der digitalen Signatur von einem Zertifikat verwendet wird, eine Kopie dieses öffentlichen Schlüssels im Cache oder anderweitig in einem Speicherbereich gespeichert, und zwar zusammen mit dem Ergebnis der Operation. Beispielsweise können der öffentliche Schlüssel und das zugehörige Ergebnis zusammen mit den Zertifikatdaten gespeichert werden, die dem Zertifikat zugeordnet sind, oder sie können in einem separaten Speicherbereich (z. B. in einer Referenztabelle) gespeichert werden. Wenn ein nachfolgender Versuch zur Verifikation der digitalen Signatur vom selben Zertifikat unter Verwendung des gegebenen öffentlichen Schlüssels unternommen wird, dann wird keine aufwändige Signaturverifikationsoperation durchgeführt, bei der mindestens die Decodierung einiger Daten mithilfe des öffentlichen Schlüssels erforderlich ist, sondern stattdessen wird der öffentliche Schlüssel, der zur erneuten Verifikation der digitalen Signatur verwendet worden wäre, zuerst mit dem gespeicherten öffentlichen Schlüssel bzw. den gespeicherten öffentlichen Schlüsseln verglichen. Wenn der gegebene öffentliche Schlüssel mit einem gespeicherten öffentlichen Schlüssel übereinstimmt, gilt der aktuelle Verifikationsversuch als erfolgreich oder als nicht erfolgreich, was sich danach richtet, welches Ergebnis zusammen mit dem gespeicherten öffentlichen Schlüssel gespeichert ist. Wenn das gespeicherte Ergebnis anzeigt, dass der vorherige Verifikationsversuch mit diesem gespeicherten öffentlichen Schlüssel erfolgreich war, dann gilt auch der aktuelle Verifikationsversuch als erfolgreich. Wenn dagegen das gespeicherte Ergebnis anzeigt, dass der vorherige Verifikationsversuch mit diesem gespeicherten öffentlichen Schlüssel nicht erfolgreich war, dann gilt der aktuelle Verifikationsversuch als fehlgeschlagen. Dementsprechend können nachfolgende Signaturverifikationsoperationen, für die ansonsten die Decodierung von einigen Daten mithilfe des öffentlichen Schlüssels erforderlich wäre, durch effizientere Vergleichsoperationen (z. B. Byte-Array) ersetzt werden.
  • In Schritt 430a wird eine Verifikation einer digitalen Signatur von einem Zertifikat initiiert (z. B. durch die Anwendung zur Zertifikatgültigkeitsprüfung), wie das im Zusammenhang mit dem Verfahren 420 beschrieben wurde.
  • Für einen gegebenen Schlüssel wird in Schritt 440b, vor der Durchführung der Signaturverifikationsoperation mithilfe dieses öffentlichen Schlüssels, ermittelt, ob die digitale Signatur von dem betreffenden Zertifikat bereits zuvor mithilfe dieses öffentlichen Schlüssels verifiziert wurde. Wie oben angedeutet wurde, kann das erfolgen, indem ein öffentlicher Schlüssel für die Zertifikatausgabestelle, der zuvor zur Verifikation der digitalen Signatur vom betreffenden Zertifikat verwendet wurde (sofern ein solcher existiert und in Schritt 470 im Cache oder einem anderen Speicherbereich gespeichert wurde), mit dem öffentlichen Schlüssel verglichen wird, der zur Verifikation der digitalen Signatur verwendet werden soll, und dann ermittelt wird, ob es eine Übereinstimmung gibt. Wenn eine Übereinstimmung festgestellt würde, würde dies nahe legen, dass zuvor bereits ein Versuch zur Verifikation der digitalen Signatur vom betreffenden Zertifikat erfolgt ist.
  • Wenn zuvor kein Versuch erfolgt ist, die digitale Signatur vom betreffenden Zertifikat zu verifizieren, wird anschließend in Schritt 450 eine Signaturverifikationsoperation in bekannter Art und Weise durchgeführt, wie das auch im Zusammenhang mit dem Verfahren 420 beschrieben wurde. Gemäß dieser Ausführungsform wird sowohl der öffentliche Schlüssel, der für die Verifikation verwendet wird, als auch das Ergebnis des Verifikationsversuchs (d. h. eine Anzeige, ob die digitale Signatur erfolgreich oder erfolglos verifiziert wurde) in Schritt 470b im Cache oder in einem anderen Speicherbereich gespeichert, um ihn später erneut verwenden zu können. Beispielsweise kann der in Schritt 470b gespeicherte öffentliche Schlüssel zusammen mit den Daten gespeichert werden, die dem betreffenden Zertifikat zugeordnet sind, oder in einem zentralen Speicherbereich für öffentliche Schlüssel (z. B. in einer Referenztabelle) mit Indizierung nach Zertifikat (z. B. durch Speichern der Seriennummer des Zertifikats zusammen mit dem öffentlichen Schlüssel).
  • Wenn die digitale Signatur vom betreffenden Zertifikat bereits zuvor mit dem gegebenen öffentlichen Schlüssel verifiziert wurde, was in Schritt 440b ermittelt wird, dann wird in Schritt 472 das Ergebnis des vorherigen Verifikationsversuchs mit diesem Schlüssel aus dem Cache oder dem anderen Speicherbereich abgerufen, und es wird ermittelt, ob das gespeicherte Ergebnis anzeigt, dass der vorherige Verifikationsversuch mit diesem Schlüssel erfolgreich war, oder ob es anzeigt, dass er nicht erfolgreich war. Wenn es anzeigt, dass der vorherige Versuch erfolgreich war, wird in Schritt 480 eine Anzeige bereitgestellt, dass die aktuelle Verifikation erfolgreich ist; wenn dagegen angezeigt wird, dass der vorherige Versuch nicht erfolgreich war, wird in Schritt 490 eine Anzeige bereitgestellt, dass die aktuelle Verifikation nicht erfolgreich ist.
  • Die Schritte des Verfahrens 420b können für zusätzliche öffentliche Schlüssel wiederholt werden.
  • Anstelle der Durchführung einer Signaturverifikationsoperation, die zumindest die Decodierung von einigen Daten mithilfe eines gegebenen öffentlichen Schlüssels erfordern würde, werden die Ergebnisse vorheriger Verifikationsversuche verwendet, um zu ermitteln, ob eine Verifikation unter Verwendung dieses öffent lichen Schlüssels fehlschlagen soll, wodurch der Signaturverifikationsprozess effizienter gemacht wird. Insbesondere wenn ein Benutzer mehrfach die Verifikation der digitalen Signatur von einem Zertifikat unter Verwendung desselben ungültigen öffentlichen Schlüssels anfordert, muss eine tatsächliche aufwändige Signaturverifikationsoperation, für die mindestens die Decodierung einiger Daten mithilfe des öffentlichen Schlüssels erforderlich ist, nur einmal durchgeführt werden, und die nachfolgenden Versuche werden sofort fehlschlagen, nachdem eine vergleichsweise effiziente Vergleichsoperation (z. B. Byte-Array) durchgeführt wurde. Dies kann zur weiteren Einsparung von Batterieleistung beitragen und den Gesamtnutzen für den Benutzer steigern, was insbesondere für kleine Geräte wie Mobilgeräte gilt.
  • Dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass in abweichenden Ausführungsformen zusätzlich zu den öffentlichen Schlüsseln und den oben beschriebenen Ergebnissen der Verifikationsversuche falls erwünscht auch andere Informationen im Cache oder im anderen Speicherbereich gespeichert werden können.
  • In einer abweichenden Ausführungsform der vorliegenden Erfindung dürfen die im Cache oder im anderen Speicherbereich gespeicherten öffentlichen Schlüssel und andere Informationen (z. B. Ergebnisse von Verifikationsversuchen) nur für eine eingeschränkte Zeitdauer für Vergleiche öffentlicher Schlüssel verwendet werden, und nach dieser Zeitdauer gelten sie als veraltet und können aus dem Cache oder aus dem anderen Speicherbereich gelöscht werden. Das kann aus Sicherheitsgründen erfolgen, sodass eine tatsächliche Signaturverifikationsoperation, für die mindestens die Decodierung einiger Daten mithilfe des öffentlichen Schlüssels erforderlich ist, von Zeit zu Zeit erneut durchgeführt werden muss. Diese Zeitdauer kann beispielsweise entsprechend der IT-Richtlinie festgelegt werden. In gleicher Weise können in einer anderen abweichenden Ausführungsform der vorliegenden Erfindung einige oder alle der im Cache oder im anderen Speicherbereich gespeicherten öffentlichen Schlüssel und anderen Informationen beispielsweise auf manuelle Anweisung eines Benutzers oder Administrators als veraltet markiert und gelöscht werden, sodass die Signaturverifikationsoperation erneut durchgeführt werden muss. Zur weiteren Erhöhung der Sicherheit können auch Operationen zur Gültigkeitsprüfung durchgeführt werden, um sicherzustellen, dass beispielsweise die öffentlichen Schlüssel (z. B. die öffentlichen Schlüssel, mit denen zuvor erfolgreich eine Zertifikatsignatur verifiziert wurde) nach dem Speichern nicht ungültig geworden sind.
  • Die Schritte eines Verfahrens zur Verifikation digitaler Signaturen von Zertifikaten in den Ausführungsformen der vorliegenden Erfindung können als ausführbare Softwareanweisungen bereitgestellt werden, die auf computerlesbaren Medien gespeichert sind, wozu beispielsweise übertragbare Medientypen gehören können.
  • Die Beschreibung der vorliegenden Erfindung erfolgte im Hinblick auf eine Reihe von Ausführungsformen. Dem Fachmann auf dem Gebiet der Technik wird jedoch verständlich sein, dass andere Varianten und Modifikationen ausgeführt werden können, ohne den Umfang der Erfindung zu verlassen, der durch die beigefügten Patentansprüche definiert wird.

Claims (7)

  1. Ein Verfahren zur Verifikation einer digitalen Signatur von einem Zertifikat zur Verwendung in einem Computergerät (100, 262a, 288), wobei das Verfahren die folgenden Schritte umfasst: Durchführen einer ersten Signaturverifikationsoperation an der digitalen Signatur unter Verwendung eines ersten öffentlichen Schlüssels, der einem Aussteller des Zertifikats zugeordnet ist; Ermitteln, ob die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wurde; Speichern des ersten öffentlichen Schlüssels in einem Speicherbereich; Empfangen einer Anforderung zum Durchführen einer zweiten Signaturverifikationsoperation an der digitalen Signatur unter Verwendung eines zweiten öffentlichen Schlüssels, der einem Aussteller des Zertifikats zugeordnet ist; Vergleichen des zweiten öffentlichen Schlüssels mit dem im Speicherbereich gespeicherten ersten öffentlichen Schlüssel, um zu ermitteln, ob der erste öffentliche Schlüssel und der zweite öffentliche Schlüssel übereinstimmen; und Anzeigen der erfolgreichen Verifikation der digitalen Signatur als Reaktion auf die Anforderung, wenn die digitale Signatur in der ersten Signaturwerifikationsoperation erfolgreich verifiziert wurde und wenn im Vergleichsschritt eine Übereinstimmung ermittelt wurde, wodurch die zweite Signaturverifikationsoperation nicht durchgeführt werden muss.
  2. Das Verfahren gemäß Anspruch 1, wobei der erste öffentliche Schlüssel nur dann im Speicherschritt im Speicherbereich gespeichert wird, wenn die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wird.
  3. Das Verfahren gemäß Anspruch 1, wobei der Speicherschritt des Weiteren das Speichern eines Ergebnisses umfasst, das anzeigt, ob die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wurde oder nicht, und wobei das Ergebnis im Anzeigeschritt verwendet wird, um zu ermitteln, ob die digitale Signatur in der ersten Signaturverifikationsoperation erfolgreich verifiziert wurde oder nicht.
  4. Das Verfahren gemäß Anspruch 3, des Weiteren umfassend den Schritt des Anzeigens der erfolglosen Verifikation der digitalen Signatur als Reaktion auf die Anforderung, wenn im Anzeigeschritt ermittelt wird, dass die digitale Signatur in der ersten Signaturverifikationsoperation nicht erfolgreich verifiziert wurde, und wenn im Vergleichsschritt eine Übereinstimmung festgestellt wird.
  5. Das Verfahren gemäß jedem der Ansprüche 1 bis 4, wobei das Computergerät ein Mobilgerät (100) ist.
  6. Ein computerlesbares Medium, das Programmcode-Mittel zur Ausführung auf einem Computergerät (100) umfasst, wobei die Programmcode-Mittel bei ihrer Ausführung bewirken, dass das Computergerät (100, 262a, 288) alle Schritte aus dem Verfahren gemäß jedem der Ansprüche 1 bis 5 ausführt.
  7. Ein System (100, 200, 250) zur Verifikation einer digitalen Signatur von einem Zertifikat, umfassend mindestens ein Computergerät (100, 262a, 288), wobei das Computergerät so angepasst ist, dass es die Programmcode-Mittel ausführt, um zu bewirken, dass das Computergerät alle Schritte aus dem Verfahren gemäß jedem der Ansprüche 1 bis 5 ausführt.
DE602004003503T 2004-10-29 2004-10-29 System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten Active DE602004003503T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP04105424A EP1653655B1 (de) 2004-10-29 2004-10-29 System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten

Publications (2)

Publication Number Publication Date
DE602004003503D1 DE602004003503D1 (de) 2007-01-11
DE602004003503T2 true DE602004003503T2 (de) 2007-05-03

Family

ID=34929791

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004003503T Active DE602004003503T2 (de) 2004-10-29 2004-10-29 System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten

Country Status (12)

Country Link
EP (1) EP1653655B1 (de)
JP (1) JP4491402B2 (de)
KR (1) KR100740521B1 (de)
CN (1) CN100536395C (de)
AT (1) ATE347206T1 (de)
AU (1) AU2005225093B2 (de)
BR (1) BRPI0505083B1 (de)
CA (1) CA2526863C (de)
DE (1) DE602004003503T2 (de)
HK (1) HK1089589A1 (de)
SG (1) SG122015A1 (de)
TW (1) TWI324871B (de)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716139B2 (en) 2004-10-29 2010-05-11 Research In Motion Limited System and method for verifying digital signatures on certificates
US7756932B2 (en) 2005-07-29 2010-07-13 Research In Motion Limited System and method for processing messages being composed by a user
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US7797545B2 (en) 2005-09-29 2010-09-14 Research In Motion Limited System and method for registering entities for code signing services
EP1853028B1 (de) * 2006-05-05 2013-02-27 Research In Motion Limited Verfahren und System zur sicheren Übertragung von Nachrichten
EP1898567B1 (de) * 2006-08-24 2008-11-26 Research In Motion Limited System zur Feststellung des Erreichens der maximalen Anzahl hergestellter IP-Verbindungen und ein dazugehöriges Verfahren
US8315162B2 (en) 2006-08-24 2012-11-20 Research In Motion Limited System and method for determining that a maximum number of IP sessions have been established
JP4629075B2 (ja) * 2006-08-24 2011-02-09 リサーチ イン モーション リミテッド Ｉｐセッションの最大数が確立されていることを決定するシステムおよび方法
US8687586B2 (en) 2006-10-13 2014-04-01 Blackberry Limited System and method for managing IP sessions based on how many IP sessions are supported
DE102006062177A1 (de) 2006-12-22 2008-06-26 Bundesdruckerei Gmbh Datenverarbeitungssystem zur Durchführung von Zertifikatskettenprüfungen
US8611946B2 (en) 2007-01-25 2013-12-17 Blackberry Limited Methods and systems for configuring multi-mode mobile stations
CN101364869B (zh) * 2007-08-09 2012-03-28 鸿富锦精密工业（深圳）有限公司 电子文档加密系统及方法
WO2009087545A1 (en) * 2008-01-04 2009-07-16 Nokia Corporation System and method for binding notification types to applications for a notification framework
US8555054B2 (en) 2009-10-12 2013-10-08 Palo Alto Research Center Incorporated Apparatus and methods for protecting network resources
JP5459845B2 (ja) * 2010-02-17 2014-04-02 株式会社東芝 携帯可能電子装置、携帯可能電子装置の制御方法及びｉｃカード
US8924715B2 (en) * 2010-10-28 2014-12-30 Stephan V. Schell Methods and apparatus for storage and execution of access control clients
WO2014127373A1 (en) * 2013-02-18 2014-08-21 Aetherpal Inc. Multiple-persona on mobile devices
US11127001B2 (en) * 2013-05-09 2021-09-21 Wayne Fueling Systems Llc Systems and methods for secure communication
EP3326096B1 (de) * 2015-07-20 2022-02-16 Notarize, Inc. System und verfahren zur validierung der urheberschaft einer elektronischen signatursitzung
AU2017302345B2 (en) * 2016-07-29 2021-11-11 Magic Leap, Inc. Secure exchange of cryptographically signed records
CN109863494A (zh) * 2016-08-22 2019-06-07 Keyp股份有限公司 数据防护系统
EP3287919A1 (de) * 2016-08-22 2018-02-28 Keyp GmbH Datenschutzsystem
ES2764128T3 (es) * 2016-12-21 2020-06-02 Merck Patent Gmbh Dispositivo de lectura para leer una marca compuesta que comprende una función física no clonable para la lucha contra la falsificación
US10623188B2 (en) * 2017-04-26 2020-04-14 Fresenius Medical Care Holdings, Inc. Securely distributing medical prescriptions
CN110943840A (zh) * 2018-09-25 2020-03-31 杭州字符串科技有限公司 一种签名验证方法及系统
KR102619137B1 (ko) 2023-07-19 2023-12-29 주식회사 블로코엑스와이지 오픈배지 발급 및 검증을 위한 시스템, 및 방법

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6085320A (en) * 1996-05-15 2000-07-04 Rsa Security Inc. Client/server protocol for proving authenticity
JP2948814B1 (ja) 1998-09-08 1999-09-13 株式会社高度移動通信セキュリティ技術研究所 べき乗剰余演算軽減方法
JP4581200B2 (ja) * 2000-08-31 2010-11-17 ソニー株式会社 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
US7107248B1 (en) * 2000-09-11 2006-09-12 Nokia Corporation System and method of bootstrapping a temporary public-key infrastructure from a cellular telecommunication authentication and billing infrastructure
JP3971890B2 (ja) 2000-11-01 2007-09-05 日本電信電話株式会社 署名検証支援装置、署名検証支援方法、及び電子署名検証方法
US6889209B1 (en) * 2000-11-03 2005-05-03 Shieldip, Inc. Method and apparatus for protecting information and privacy
US20030204741A1 (en) * 2002-04-26 2003-10-30 Isadore Schoen Secure PKI proxy and method for instant messaging clients

Also Published As

Publication number Publication date
CN1767438A (zh) 2006-05-03
BRPI0505083A (pt) 2006-07-04
SG122015A1 (en) 2006-05-26
JP4491402B2 (ja) 2010-06-30
CN100536395C (zh) 2009-09-02
CA2526863C (en) 2011-02-08
EP1653655B1 (de) 2006-11-29
KR100740521B1 (ko) 2007-07-20
TWI324871B (en) 2010-05-11
KR20060052279A (ko) 2006-05-19
TW200629846A (en) 2006-08-16
CA2526863A1 (en) 2006-04-29
BRPI0505083B1 (pt) 2021-01-26
EP1653655A1 (de) 2006-05-03
ATE347206T1 (de) 2006-12-15
HK1089589A1 (en) 2006-12-01
JP2006129490A (ja) 2006-05-18
DE602004003503D1 (de) 2007-01-11
AU2005225093A1 (en) 2006-05-18
AU2005225093B2 (en) 2008-09-25

Similar Documents

Publication Publication Date Title
DE602004003503T2 (de) System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten
DE602006000817T2 (de) System und Methode für steuernde Datenkommunikation zwischen einem Server und einer Client-Vorrichtung
DE60219222T2 (de) Mehrstufiges System und Verfahren zur Verarbeitung von kodierten Nachrichten
DE60315434T2 (de) Zertifikatinformationsspeichersystem und verfahren
DE60318825T2 (de) Vorrichtung und verfahren zur unterstützung von mehreren zertifizierungstatusanbietern auf einem mobilen kommunikationsgerät
US8099593B2 (en) System and method for retrieving related certificates
US8301878B2 (en) System and method for enabling bulk retrieval of certificates
DE60029217T2 (de) Verfahren und vorrichtung zum initialisieren von sicheren verbindungen zwischen und nur zwischen zueinandergehörenden schnurlosen einrichtungen
EP3121795B1 (de) Aufbau einer kommunikationsverbindung mit einer benutzervorrichtung über eine zugangskontrollvorrichtung
DE60205289T2 (de) System und Verfahren zur gesicherte Funkübertragung von Konfigurationsdaten
US8725643B2 (en) System and method for verifying digital signatures on certificates
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
DE60309446T2 (de) System und verfahren für die anzeige eines signatur- und vertrauenswürdigkeitsstatuses einer gesicherten nachricht
US20060036849A1 (en) System and method for certificate searching and retrieval
DE602005001155T2 (de) Vorrichtung und Verfahren zum Versenden verschlüsselter Nachrichten an Verteilerlisten
CA2516754C (en) System and method for retrieving related certificates
DE602005003221T2 (de) Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen
DE602004013000T2 (de) System und Methode zum Suchen und Abrufen von Zertifikaten
DE602005002648T2 (de) Benachrichtigung von wartenden Aufgaben mittels eines mobilen Geräts
DE602004005706T2 (de) System und Verfahren zum Erzeugen eines Sicherheitszustandsindikators auf einer Anzeigevorrichtung
DE602005003220T2 (de) Vorausladung von Sicherheitsrelevanten Daten in einem Mobilnetzwerk
DE60315991T2 (de) System und verfahren zur mimischen auswahl der nachrichteneinstellungen
WO2020187622A1 (de) Verfahren zum authentifizieren eines computersystems
DE602004005582T2 (de) Paketbasiertes Kommunikationssystem und Verfahren
CA2477026C (en) System and method for enabling bulk retrieval of certificates

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: MERH-IP, 80336 MUENCHEN