[go: up one dir, main page]

DE602005003221T2 - Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen - Google Patents

Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen Download PDF

Info

Publication number
DE602005003221T2
DE602005003221T2 DE602005003221T DE602005003221T DE602005003221T2 DE 602005003221 T2 DE602005003221 T2 DE 602005003221T2 DE 602005003221 T DE602005003221 T DE 602005003221T DE 602005003221 T DE602005003221 T DE 602005003221T DE 602005003221 T2 DE602005003221 T2 DE 602005003221T2
Authority
DE
Germany
Prior art keywords
message
address
digital signature
separator
key
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.)
Expired - Lifetime
Application number
DE602005003221T
Other languages
English (en)
Other versions
DE602005003221D1 (de
Inventor
Michael K Kitchener Brown
Michael G. Waterloo Kirkup
Michael S 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 DE602005003221D1 publication Critical patent/DE602005003221D1/de
Application granted granted Critical
Publication of DE602005003221T2 publication Critical patent/DE602005003221T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)
  • Debugging And Monitoring (AREA)

Description

  • Ein Teil der Offenbarung dieses Patentdokuments enthält urheberrechtlich geschütztes Material. Der Inhaber des Urheberrechts erhebt keinerlei Einwände gegen die Faksimile-Reproduktion durch das Patentdokument oder die Patentoffenbarung, wie sie in der Patentakte oder den Patentunterlagen des Patent- und Warenzeichenamts vorkommen, behält sich aber alle sonstigen Urheberrechte vor.
  • Die Ausführungsformen der Erfindung beziehen sich im Allgemeinen auf die Verarbeitung von Nachrichten (z. B. E-Mail-Nachrichten) und insbesondere auf die Verarbeitung von digital signierten Nachrichten, die von Benutzern von Computergeräten (z. B. Mobilgeräten) empfangen werden.
  • Elektronische Postnachrichten (E-Mail-Nachrichten) können allgemein mit einem von mehreren bekannten Protokollen codiert werden, um die sichere Nachrichtenkommunikation zu ermöglichen. Das Protokoll Secure Multiple Internet Mail Extensions ("S/MIME") basiert z. B. 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, welche die Authentifizierung und Autorisierung ermöglichen. Die mit einem privaten Schlüssel eines Paars aus privatem und öffentlichem Schlüssel verschlüsselten Daten können nur unter Verwendung des entsprechenden öffentlichen Schlüssels des Paars entschlüsselt werden, und die mit einem öffentlichen Schlüssel eines Paar aus privatem und öffentlichem Schlüssel verschlüsselten Daten können nur unter Verwendung des entsprechenden privaten Schlüssels des Paars entschlüsselt werden. Zur Gewährleistung der sicheren Nachrichtenkommunikation können auch andere bekannte Standards und Protokolle eingesetzt werden, wozu beispielsweise Pretty Good PrivacyTM (PGP) und Varianten von PGP wie OpenPGP gehören. PGP-basierte Systeme nutzen ebenfalls öffentliche und private Verschlüsselungsschlüssel, um die Vertraulichkeit und Integrität zu gewährleisten, obwohl die Authentizität der zur Codierung von PGP-Nachrichten verwendeten öffentlichen Schlüssel auf andere Weise überprüft wird als bei S/MIME-Systemen. In Standards und Protokollen zur sicheren Nachrichtenkommunikation können Konstrukte ähnlich einem "Zertifikat" (wie beispielsweise in S/MIME verwendet) bereitgestellt werden, die einen öffentlichen Schlüssel und Informationen zum Schlüsselinhaber enthalten. Ein Beispiel für ein solches Konstrukt ist in PGP-basierten Systemen als "PGP-Schlüssel" bekannt.
  • Eine codierte Nachricht kann verschlüsselt, digital signiert ("signiert") oder beides sein. Stellen wir uns eine signierte Nachricht vor, die von einem Benutzer an einem Computergerät (z. B. einem Mobilgerät) empfangen wird. Die Nachricht umfasst typischerweise eine digitale Signatur, die mithilfe des privaten Schlüssels des Signatars generiert wurde, obwohl einige Protokolle auch die Signierung mehrerer individueller Abschnitte einer Nachricht erlauben können. Wenn mehrere Abschnitte einer Nachricht signiert sind, kann die Nachricht mehrere digitale Signaturen umfassen. Wenn der Benutzer den öffentlichen Schlüssel besitzt, mit dem eine gegebene digitale Signatur erfolgreich decodiert werden kann, die mit dem privaten Schlüssel des Signatars generiert wurde, dann ist der Benutzer in der Lage, den Signatar zu authentifizieren und die Integrität der signierten Daten zu verifizieren. Ein öffentlicher Schlüssel kann in einigen Fällen die empfangene Nachricht begleiten.
  • Trotz des Schutzes, der durch die Verwendung von digitalen Signaturen erreicht wird, gibt es jedoch Fälle, in denen die Sicherheit noch immer kompromittiert werden kann. Beispielsweise kann ein privater Schlüssel einer Person verwendet werden, um eine Nachricht zu signieren. Ein Benutzer empfängt die Nachricht, und ein öffentlicher Schlüssel, der die Nachricht begleitet, decodiert die digitale Signatur in der Nachricht erfolgreich. Die erfolgreiche Verifizierung der digitalen Signatur würde nahelegen, dass die Person die Nachricht signiert hat und dass die Nachricht beim Transport nicht modifiziert wurde. Nehmen wir jedoch an, dass der private Schlüssel, der zum Codieren der digitalen Signatur verwendet wurde, gar nicht zum Absender der Nachricht gehört, der im Header der Nachricht identifiziert ist, ohne dass der Benutzer davon Kenntnis hat. In diesem Beispiel kann der Benutzer fälschlicherweise dazu gebracht werden anzunehmen, dass der identifizierte Absender die Nachricht signiert hat, obwohl der identifizierte Absender tatsächlich gar nicht die Person ist, welche die Nachricht signiert.
  • Allgemeines
  • In einem umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei das Verfahren die folgenden Schritte umfasst: das Empfangen einer Nachricht, umfassend: einen Header, der mindestens eine Absenderadresse für die Nachricht identifiziert, mindestens einen Abschnitt aus signierten Daten, eine digitale Signatur entsprechend jedem Abschnitt aus signierten Daten und mindestens ein Nachrichtentrennzeichen; das Ermitteln, ob ein erstes Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt; wenn das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, das Durchführen von mindestens einer vorbestimmten Aktion für jede digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt; und wenn das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt, das Verifizieren, dass die Absenderadresse mit einer Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der einen digitalen Signatur verwendet wurde, die nach dem ersten Nachrichtentrennzeichen vorkommt und die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, und das Durchführen von mindestens einer vorbestimmten Aktion für jede andere digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt.
  • Kurze Beschreibung der Zeichnungen
  • Um ein besseres Verständnis der Ausführungsformen der hier beschriebenen Systeme und Verfahren zu ermöglichen, und um deutlicher zeigen zu können, wie diese in die Praxis umgesetzt werden können, wird anhand von Beispielen Bezug auf die beiliegenden Zeichnungen genommen, welche folgende Bedeutung haben:
  • 1 ist ein Blockdiagramm eines Mobilgeräts in einer exemplarischen Implementierung;
  • 2 ist ein Blockdiagramm einer Kommunikations-Subsystemkomponente des Mobilgeräts aus 1;
  • 3 ist ein Blockdiagramm eines Knotens eines Drahtlosnetzes;
  • 4 ist ein Blockdiagramm zur Darstellung der Komponenten eines Host-Systems in einer exemplarischen Konfiguration;
  • 5 ist ein Blockdiagramm zur Darstellung der Komponenten eines Beispiels für eine codierte Nachricht;
  • 6A bis 6E sind Beispiele für Nachrichten;
  • 7A ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer Ausführungsform; und
  • 7B ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer anderen Ausführungsform; und
  • 7C ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer anderen Ausführungsform.
  • Beschreibung bevorzugter Ausführungsformen
  • Wie im obigen Beispiel gezeigt wurde, kann ein Benutzer, der eine signierte Nachricht auf einem Computergerät empfängt, dazu gebracht werden fälschlicherweise anzunehmen, dass der im Header der Nachricht identifizierte Absender die Nachricht signiert hat, selbst wenn das nicht der Fall ist, obwohl eine digitale Signatur in der Nachricht erfolgreich decodiert wurde.
  • Um dieses Problem zu beheben, kann ein Computergerät eingesetzt werden, das zur Verifizierung von Adressenübereinstimmungen für eine signierte Nachricht eingerichtet ist. Insbesondere kann das Gerät so eingerichtet sein, dass es verifiziert, dass die Adresse (z. B. die E-Mail-Adresse), die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, mit der Adresse übereinstimmt, die mit dem im Header der Nachricht identifizierten Absender assoziiert ist. Wenn eine Adressen-Nichtübereinstimmung festgestellt wird (d. h. wenn diese Adressen nicht übereinstimmen), dann kann der Benutzer über die Adressen-Nichtübereinstimmung benachrichtigt werden, und zwar mittels einer Warnung oder Fehlermeldung, die dem Benutzer z. B. angezeigt wird. Dementsprechend kann der Benutzer durch die Verarbeitung signierter Nachrichten, in denen Adressen-Nichtübereinstimmungsfehler erkannt werden, gewarnt werden, wenn der Signatar einer Nachricht (oder eines Abschnitts davon) nicht dieselbe Person ist wie der identifizierte Absender der Nachricht.
  • Aus der Patentanmeldung US2005/0039017 ist es bekannt, eine ankommende E-Mail-Nachricht nach dem ersten Vorkommen einer digitalen Signatur zu durchsuchen, um zu verifizieren, dass der zur Erstellung dieser Signatur verwendete Schlüssel zum Absender gehört.
  • Wie oben erwähnt wurde, können einige Nachrichten in Abhängigkeit vom eingesetzten sicheren Nachrichtenkommunikationsprotokoll mehrere digitale Signaturen enthalten, die durch denselben privaten Schlüssel generiert wurden. Beispielsweise kann eine Person eine Anzahl von unterschiedlichen Abschnitten derselben Nachricht mit einem privaten PGP-Schlüssel signieren. Daher kann eine Nachricht mehrere digitale Signaturen enthalten, die mithilfe des privaten PGP-Schlüssels dieser Person generiert wurden. Wenn die Nachricht von einem Benutzer empfangen wird, kann in einer Implementierung des oben erwähnten Geräts für jede der digitalen Signaturen eine Verifizierung durchgeführt werden, dass die Adresse, die mit dem privaten PGP-Schlüssel der Person assoziiert ist, der die jeweilige Signatur generiert hat, mit der Adresse des Absenders übereinstimmt, der im Header der Nachricht identifiziert ist.
  • Allerdings können einige andere Nachrichten mehrere digitale Signaturen enthalten, jedoch im Gegensatz zum obigen Beispiel kann derselbe private Schlüssel nicht alle digitalen Signaturen von einer dieser Nachrichten signiert haben.
  • Während beispielsweise einige Geräte, die zum Verarbeiten codierter Nachrichten eingerichtet sind, die digitalen Signaturen von einer älteren Nachricht eliminieren, bevor eine neue durch einen Benutzer verfasste Nachricht, welche die ältere Nachricht einbezieht, übertragen wird, werden die digitalen Signaturen durch andere Geräte nicht auf diese Weise eliminiert. Eine neue Nachricht, welche die ältere Nachricht einbezieht, kann z. B. eine Antwortnachricht sein, die zum Absender der älteren Nachricht zurückgesendet wird, oder eine weitergeleitete Nachricht, die zu einem anderen Empfänger gesendet wird. In diesem Zusammenhang wird verständlich sein, dass die meisten bekannten Systeme dem Benutzer gestatten, Text der "Ursprungsnachricht" (d. h. der älteren Nachricht) als Text in die neue Antwort- oder Weiterleitungsnachricht einzubeziehen. Wenn ein Gerät nicht dazu eingerichtet ist, die digitalen Signaturen von einer älteren Nachricht zu eliminieren, bevor eine neue Nachricht, welche die ältere Nachricht enthält, übertragen wird, dann können, wenn eine Nachricht einen Konversationsverlauf (einen so genannten Thread) zwischen zwei oder mehreren Personen enthält, mehrere digitale Signaturen, die potenziell mithilfe verschiedener privater Schlüssel generiert wurden, in der Nachricht enthalten sein.
  • Wenn ein Computergerät, das zur Verifizierung von Adressenübereinstimmungen eingerichtet ist, eine Nachricht empfängt, die eine oder mehrere digitale Signaturen enthält, dann kann es möglicherweise nicht wissen, dass einige der digitalen Signaturen eventuell aus älteren signierten Nachrichten stammen, beispielsweise als Teil von weitergeleitetem Text oder von Text, auf den geantwortet wird, der ordnungsgemäß in die Nachricht einbezogen wurde. Tatsächlich kann selbst dann, wenn es nur eine einzige digitale Signatur in einer Nachricht gibt, diese digitale Signatur nicht durch den Absender der empfangenen Nachricht generiert worden sein, wenn die digitale Signatur aus einer älteren Nachricht stammt.
  • Wenn das Computergerät annimmt, dass jede empfangene Nachricht, die eine oder mehrere digitale Signaturen enthält, durch den Absender der empfangenen Nachricht generiert sein müsste, und dann versucht, für jede der digitalen Signaturen eine Verifizierung durchzuführen, dass die Adresse, die mit dem Schlüssel assoziiert ist, mit dem die jeweilige Signatur generiert wurde, mit der im Header der empfangenen Nachricht identifizierten Absenderadresse übereinstimmt, dann ist es wahrscheinlich, dass zumindest eine Adressen-Nichtübereinstimmung erkannt wird, und der Benutzer kann über jede Adressen-Nichtübereinstimmung benachrichtigt werden. Allerdings wird in diesen Fällen eine Adressen-Nichtübereinstimmung erkannt, obwohl kein Angreifer von dritter Seite in böswilliger Absicht versucht hat, sich für den Absender auszugeben.
  • Das Melden von Adressen-Nichtübereinstimmungsfehlern, selbst wenn eine Nachricht einen Konversations-Thread enthält oder in anderer Weise ordnungsgemäß Daten einbezieht, die nicht durch den Absender signiert wurden, kann die Gebrauchsfähigkeit des Computergeräts beeinträchtigen.
  • Die hier beschriebenen Ausführungsformen beziehen sich allgemein auf eine Vorrichtung und auf Verfahren, mit denen die Anzahl der einem Benutzer gemeldeten Adressen-Nichtübereinstimmungsfehlern minimiert werden kann, insbesondere bei Nachrichten, die ordnungsgemäß Nachrichtenteile einbeziehen, welche durch eine andere Person als den Absender signiert wurden, wie es der Fall sein kann, wenn die Nachricht einen Konversations-Thread enthält. Damit kann die Gebrauchsfähigkeit eines Computergeräts erhöht werden, und es kann besonders vorteilhaft sein, wenn es sich bei dem Computergerät um ein Mobilgerät handelt.
  • In einem umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei das Verfahren die folgenden Schritte umfasst: das Empfangen einer Nachricht, umfassend: einen Header, der mindestens eine Absenderadresse für die Nachricht identifiziert, mindestens einen Abschnitt aus signierten Daten, eine digitale Signatur entsprechend jedem Abschnitt aus signierten Daten und mindestens ein Nachrichtentrennzeichen; das Ermitteln, ob ein erstes Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt; wenn das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, das Durchführen von mindestens einer vorbestimmten Aktion für jede digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt; und wenn das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt, das Verifizieren, dass die Absenderadresse mit einer Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der einen digitalen Signatur verwendet wurde, die nach dem ersten Nachrichtentrennzeichen vorkommt und die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, und das Durchführen von mindestens einer vorbestimmten Aktion für jede andere digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt.
  • In einem anderen umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, das Umgehen der Verifizierung umfasst, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  • In einem anderen umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, umfasst: das Verifizieren, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde; und das Unterdrücken des Benachrichtigens eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  • In einem anderen umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, umfasst: das Ermitteln einer abschnittsspezifischen Adresse, die mit dem Abschnitt aus signierten Daten assoziiert ist, dem die digitale Signatur entspricht; das Verifizieren dass die abschnittsspezifische Adresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde; und das Benachrichtigen eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die abschnittsspezifische Adresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  • In einem anderen umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei das Ermitteln einer abschnittsspezifischen Adresse das Extrahieren einer Adresse für einen vorherigen Absender aus dem Text in der Nachricht umfasst, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und dem Abschnitt vorkommt.
  • In einem anderen umfassenden Aspekt wird ein Verfahren für die Verarbeitung digital signierter Nachrichten bereitgestellt, die in einem Computergerät empfangen wurden, wobei das Ermitteln einer abschnittsspezifischen Adresse umfasst: das Extrahieren eines Namens für einen vorherigen Absender aus dem Text in der Nachricht, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und dem Abschnitt vorkommt; und das Abrufen einer Adresse für den mit dem Namen assoziierten vorherigen Absender aus einem Adressbuch.
  • Diese und weitere Aspekte und Merkmale von verschiedenen Ausführungsformen werden im Folgenden detailliert beschrieben.
  • Einige Ausführungsformen der hier beschriebenen Systeme und Verfahren beziehen sich auf ein Mobilgerät. Ein Mobilgerät ist ein Zweiwege-Kommunikationsgerät mit erweiterten Datenkommunikationsfunktionen, das über die Fähigkeit zur Kommunikation mit anderen Computersystemen verfügt. Ein Mobilgerät kann auch die Fähigkeit zur Sprachkommunikation einschließen. In Abhängigkeit von 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 Netz 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 exemplarischen 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-Subsystem 104 ausgeführt. Das Kommunikations-Subsystem 104 empfängt Nachrichten von und sendet Nachrichten zu einem Drahtlosnetz 200. In dieser exemplarischen Implementierung des Mobilgeräts 100 ist das Kommunikations-Subsystem 104 gemäß den Standards Global System for Mobile Communication (GSM) und General Packet Radio Services (GPRS) konfiguriert. Das GSM/GPRS-Drahtlosnetz 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 Netzverhalten 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-Subsystem 104 mit dem Netz 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 Netzprotokollen 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 exemplarischen Implementierung des Mobilgeräts 100 zugeordnete Drahtlosnetz ein GSM/GPRS-Drahtlosnetz ist, können in abweichenden Implementierungen auch andere Drahtlosnetze dem Mobilgerät 100 zugeordnet sein. Zu anderen Typen von Drahtlosnetzen, die verwendet werden können, zählen beispielsweise datenzentrische Drahtlosnetze, sprachzentrische Drahtlosnetze und Dualmodusnetze, die über dieselben physischen Basisstationen sowohl Sprachkommunikation als auch Datenkommunikation unterstützen können. Zu den kombinierten Dualmodusnetzen gehören unter anderem Code Division Multiple Access (CDMA) oder CDMA2000-Netze, GSM/GPRS-Netze (wie oben erwähnt), und zukünftige Netze der dritten Generation (3G) wie EDGE und UMTS. Zu einigen älteren Beispielen für datenzentrische Netze gehören das MobitexTM-Funknetz und das DataTACTM-Funknetz. Zu einigen älteren Beispielen für sprachzentrische Netze gehören Personal Communications Systems (PCS) Netze wie GSM und Time Division Multiple Access (TDMA) Systeme.
  • Der Mikroprozessor 102 interagiert auch mit zusätzlichen Subsystemen wie dem Random Access Memory (RAM) 106, dem Flash-Speicher 108, dem Display 110, dem zusätzlichen Eingabe-/Ausgabe-Subsystem (E/A) 112, dem seriellen Port 114, der Tastatur 116, dem Lautsprecher 118, dem Mikrofon 120, einem Nahbereichskommunikations-Subsystem 122 und sonstigen Geräten 124.
  • Einige der Subsysteme des Mobilgeräts 100 führen kommunikationsbezogene Funktionen aus, während andere Subsysteme 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 Netz 200 als auch für geräteresidente Funktionen wie ein Taschenrechner 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 Netzregistrierungs- oder -aktivierungsprozeduren Kommunikationssignale über das Netz 200 senden und empfangen. Der Netzzugriff 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 Netz 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 Netz 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 könnte, 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 Drahtlosnetz 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 Drahtlosnetz 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 Netz 200, das zusätzliche E/A-Subsystem 112, den seriellen Port 114, das Nahbereichskommunikations-Subsystem 122 oder jedes andere geeignete Subsystem 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 Port 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 Kommunikationsnetz 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-Subsystem 122 ermöglicht die Kommunikation zwischen dem Mobilgerät 100 und verschiedenen Systemen oder Geräten, ohne dazu das Netz 200 zu verwenden. Beispielsweise kann das Subsystem 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-Subsystem 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-Subsystem 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-Subsystem 112 verwendet wird. Das zusätzliche E/A-Subsystem 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-Subsystem 104 über das Netz 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-Subsysteme, 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 der Kommunikations-Subsystemkomponente 104 aus 1 gezeigt. Das Kommunikations-Subsystem 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-Subsystems 104 hängt vom Netz 200 ab, in dem das Mobilgerät 100 arbeiten soll, daher sollte es einleuchten, dass der in 2 gezeigte Aufbau nur als Beispiel dient. Die von der Antenne 154 über das Netz 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 Netz 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 Netz 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 Netz 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 Netz 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 Drahtlosnetzes als 202 gezeigt. In der Praxis umfasst das Netz 200 einen oder mehrere Knoten 202. Das Mobilgerät 100 kommuniziert mit einem Knoten 202 innerhalb des Drahtlosnetzes 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-Netzes gemeint, sondern vielmehr als eine Liste der Komponenten, die im Allgemeinen in der Kommunikation über das Netz 200 verwendet werden.
  • In einem GSM-Netz ist MSC 210 mit BSC 204 und mit einem ortsfesten Netz 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 Netz (Internet) 224 (hier auch allgemein als eine gemeinsam verwendete Netzinfrastruktur bezeichnet) bildet den Datenpfad für GPRS-taugliche Mobilgeräte. In einem um GPRS-Funktionen erweiterten GSM-Netz 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 Netzabdeckung für ein bestimmtes Abdeckungsgebiet, das im Allgemeinen als eine "Zelle" bezeichnet wird. Die feststehende Sende-Empfangsausrüstung überträgt Kommunikationssignale zu den und empfängt Kommunikationssignale von den Mobilgeräten innerhalb dieser Zelle über die Station 206. Die feststehende Sende-Empfangsausrüstung führt normalerweise solche Funktionen durch 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 Netzes 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 Netze 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 MSC210 haben innerhalb des Drahtlosnetzes 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 Netz 200 durch. GGSN 218 stellt Verbindungen für den netzüberschreitenden Betrieb mit externen paketvermittelten Netzen bereit und stellt die Verbindung zu einem oder mehreren SGSNs 216 über ein Internet Protocol (IP) Backbone-Netz her, das innerhalb des Netzes 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 Netze 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-kompatible Dienste oder auf Privatnetzverbindungen zugreifen kann. Der APN repräsentiert auch einen Sicherheitsmechanismus für das Netz 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 over 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 nur eine begrenzten Anzahl im Netz 200 verfügbar. Um die Verwendung von PDP-Kontexten zu maximieren, führt das Netz 200 einen Idle-Timer für jeden PDP-Kontext aus, um zu ermitteln, ob es ein Fehlen von Aktivität gibt. 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 exemplarischen Konfiguration 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 das Desktop-Computergerät ("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 S/MIME-Zertifikate oder PGP-Schlüssel gehören, die beim Austauschen von Nachrichten verwendet werden. Der Prozess des Herunterladens von Informationen vom Desktopcomputer 262a eines Benutzers zum Mobilgerät 100 des Benutzers kann auch als Synchronisierung bezeichnet 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 Dienstanbieternetz 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 der IT-Richtlinie (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 nach 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.
  • Während Simple Mail Transfer Protocol (SMTP), RFC822-Header 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-Authentifizierung 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 Standards und Protokolle können eingesetzt werden, um eine sichere Nachrichtenkommunikation zu ermöglichen, zum Beispiel Pretty Good PrivacyTM (PGP) und Varianten von PGP wie OpenPGP. Es sollte verständlich sein, dass bei hier vorkommenden allgemeinen Verweisen auf "PGP" mit diesem Begriff auch jede aus einer Vielzahl von abweichenden Implementierungen eingeschlossen sein soll, die auf dem allgemeineren PGP-Schema basiert.
  • Sichere Nachrichtenprotokolle wie S/MIME und PGP-basierte Protokolle basieren auf öffentlichen und privaten Verschlüsselungsschlüsseln, um die Vertraulichkeit und Integrität zu gewährleisten. 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 decodiert werden, wenn der entsprechende öffentliche Schlüssel des Paares verwendet wird, und Daten, die unter Verwendung eines öffentlichen Schlüssels aus einem Paar aus privatem Schlüssel und öffentlichem Schlüssel verschlüsselt wurden, können nur decodiert werden, wenn der entsprechende private Schlüssel des Paares verwendet wird. Es ist vorgesehen, die Informationen des privaten Schlüssels niemals öffentlich zu machen, 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 Nachrichten-Header 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 Verifizierung 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 Verifizierung einer digitalen Signatur in dieser Weise die Authentifizierung des Absenders und die Nachrichtenintegrität gewahrt werden.
  • Eine codierte Nachricht kann verschlüsselt, signiert oder sowohl verschlüsselt als auch signiert werden. In S/MIME wird die Authentizität der bei diesen Operationen verwendeten öffentlichen Schlüssel mithilfe von Zertifikaten validiert. Ein Zertifikat ist ein digitales Dokument, das von einer Zertifikatstelle (Certificate Authority – CA) ausgestellt wird. Zertifikate werden zur Authentifizierung der Zuordnung zwischen Benutzern und ihren privaten Schlüsseln verwendet und ermöglichen im Wesentlichen einen Level of Trust (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. Die Zertifikate werden typischerweise durch die Zertifikatstelle digital signiert.
  • In PGP-basierten Systemen wird ein PGP-Schlüssel verwendet, der insofern einem S/MIME-Zertifikat ähnelt, als dass er öffentliche Informationen enthält, wozu ein öffentlicher Schlüssel und Informationen zum Inhaber oder Eigentümer des Schlüssels gehören. Im Unterschied zu S/MIME-Zertifikaten werden PGP-Schlüssel jedoch im Allgemeinen nicht durch eine Zertifikatstelle ausgestellt, und der Level of Trust in die Authentizität eines PGP-Schlüssels erfordert typischerweise eine Verifizierung, dass eine vertrauenswürdige Person für die Authentizität eines gegebenen PGP-Schlüssels bürgt.
  • Standard-E-Mail-Sicherheitsprotokolle ermöglichen typischerweise die sichere Nachrichtenübertragung zwischen nicht-mobilen Computergeräten (z. B. Computer 262a, 262b aus 4; Remote-Desktopgeräte). Damit von Absendern empfangene signierte Nachrichten auf dem Mobilgerät 100 gelesen werden können und verschlüsselte Nachrichten vom Mobilgerät 100 aus gesendet werden können, ist das Mobilgerät 100 eingerichtet zum Speichern von öffentlichen Schlüsseln (z. B. in Form von S/MIME-Zertifikaten, PGP-Schlüsseln) von anderen Personen. Die auf dem Computer 262a eines Benutzers gespeicherten Schlüssel werden typischerweise vom Computer 262a z. B. über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen.
  • Das Mobilgerät 100 kann auch eingerichtet sein zum Speichern des privaten Schlüssels aus dem Paar aus öffentlichem und privatem Schlüssel, das mit dem Benutzer assoziiert ist, so dass der Benutzer des Mobilgeräts 100 abgehende Nachrichten, die auf dem Mobilgerät 100 verfasst wurden, signieren kann und zum Benutzer gesendete Nachrichten entschlüsseln kann, die mit dem öffentlichen Schlüssel des Benutzers verschlüsselt wurden. Der private Schlüssel kann vom Computer 262a des Benutzers beispielsweise über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen werden. Der private Schlüssel wird vorzugsweise zwischen dem Computer 262a und dem Mobilgerät 100 ausgetauscht, so dass der Benutzer eine Identität und ein Verfahren zum Zugriff auf Nachrichten gemeinsam verwenden kann.
  • Die Benutzercomputer 262a, 262b können S/MIME-Zertifikate und PGP-Schlüssel aus einer Reihe von Quellen beziehen, um sie auf den Computern 262a, 262b und/oder auf Mobilgeräten (z. B. dem Mobilgerät 100) beispielsweise in einem Schlüsselspeicher zu speichern. Die Quellen dieser Zertifikate und Schlüssel können privat (z. B. nur für die Verwendung innerhalb einer Organisation bestimmt) oder öffentlich sein, können lokal und entfernt angeordnet sein und der Zugriff auf sie kann beispielsweise aus dem Privatnetz einer Organisation heraus oder über das Internet erfolgen. In dem in 4 gezeigten Beispiel befinden sich mehrere mit der Organisation assoziierte PKI-Server (Public Key Infrastructure) 280 im LAN 250. Die PKI-Server 280 schließen beispielsweise einen CA-Server 282, der zum Ausstellen von S/MIME-Zertifikaten verwendet werden kann, einen LDAP-Server (Lightweight Directory Access Protocol) 284, der zum Suchen nach und zum Herunterladen von S/MIME-Zertifikaten und/oder PGP-Schlüsseln verwendet werden kann, sowie einen OCSP-Server (Online Certificate Status Protocol) 286 ein, der zur Verifizierung des Widerrufstatus von S/MIME-Zertifikaten verwendet werden kann.
  • Zertifikate und/oder PGP-Schlüssel können vom LDAP-Server 284 beispielsweise durch einen Benutzercomputer 262a abgerufen werden, um über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen zu werden. Allerdings kann in einer abweichenden Implementierung der Zugriff auf den LDAP-Server 284 auch direkt (d. h. in diesem Kontext "über die Luft") durch das Mobilgerät 100 erfolgen, und das Mobilgerät 100 kann über einen mobilen Datenserver 288 nach individuellen Zertifikaten und PGP-Schlüsseln suchen und diese abrufen. In gleicher Weise kann der mobile Datenserver 288 eingerichtet sein, um dem Mobilgerät 100 das direkte Abfragen des OCSP-Servers 286 zur Verifizierung des Widerrufstatus von S/MIME-Zertifikaten zu gestatten.
  • In abweichenden Implementierungen können nur ausgewählte PKI-Server 280 für Mobilgeräte zugänglich gemacht sein (dass z. B. Zertifikate nur von einem Benutzercomputer 262a, 262b heruntergeladen werden dürfen, während die Überprüfung des Widerrufstatus auch vom Mobilgerät 100 aus zugelassen wird).
  • In abweichenden Implementierungen können bestimmte PKI-Server 280 nur für Mobilgeräte zugänglich gemacht sein, die für bestimmte Benutzer registriert sind, was beispielsweise durch einen IT-Administrator und möglicherweise entsprechend einer IT-Richtlinie festgelegt wird.
  • Zu anderen [nicht dargestellten] Quellen für S/MIME-Zertifikate und PGP-Schlüssel können beispielsweise ein Windows-Zertifikat- oder -Schlüsselspeicher, ein anderer sicherer Zertifikat- oder Schlüsselspeicher im oder außerhalb des LAN 250 sowie Smartcards gehören.
  • In mindestens einer Systemausführungsform befindet sich im LAN 250 eine Policy Engine 290. Die Policy Engine 290 kann beispielsweise durch einen von der PGP Corporation entwickelten PGP Universal Server bereitgestellt werden. Das ist jedoch nur ein Beispiel. In abweichenden Implementierungen kann die Policy Engine in einem anderen Gerät oder einem anderen Konstrukt als einem PGP Universal Server implementiert sein, und sie kann im Kontext von anderen Protokollen als PGP (z. B. in einer S/MIME Policy Engine) angewendet werden.
  • Unter Bezug auf das oben genannte Beispiel ist der PGP Universal Server 290 eingerichtet, um mit dem Desktopcomputer eines Benutzers (z. B. 262a) und dem Mobilgerät des Benutzers (z. B. 100 über den Nachrichtenverwaltungsserver 272) zu kommunizieren, und er kann des Weiteren eingerichtet sein, um Nachrichten zu verschlüsseln und um die Einhaltung von Sicherheitsanforderungen im Hinblick auf die durch den Benutzer gesendeten Nachrichten durchzusetzen, was beispielsweise auf der Grundlage von Richtlinien erfolgen kann, die durch einen Administrator festgelegt wurden. Die Platzierung des PGP Universal Servers 290 im LAN 250 wie in 4 gezeigt erfolgt nur als ein Beispiel, und es sind andere Platzierungen und Konfigurationen möglich. In Abhängigkeit von der Platzierung des PGP Universal Servers 290 und der konkreten Konfiguration des LAN 250, in welcher der PGP Universal Server 290 möglicherweise eingesetzt wird, kann das Ausmaß der Steuerung über die verarbeiteten Nachrichten, die Gegenstand der Sicherheitscodierung sind, und insbesondere über die durch einen Benutzer gesendeten Nachrichten variieren.
  • Der PGP Universal Server 290 kann beispielsweise eingerichtet sein, um direkt alle ausgehenden Nachrichten zu verarbeiten (d. h. Nachrichten, die durch den Benutzer vom Desktopcomputer, vom Mobilgerät oder von einem anderen Computergerät des Benutzers an einen oder mehrere Empfänger gesendet werden), wobei er die Entscheidungen darüber, welche Nachrichten zu verschlüsseln und/oder zu signieren sind, wenn dies überhaupt der Fall ist, in Übereinstimmung mit Richtlinien trifft, die auf dem PGP Universal Server 290 entsprechend der Konfiguration durch den Administrator definiert sind. Wenn eine Richtlinie vorschreibt, dass eine Nachricht, die durch den Benutzer an eine bestimmte Domain gesendet werden soll oder die zu einem bestimmten Thema bzw. einem bestimmten Betreff gehört, beispielsweise verschlüsselt und mit PGP signiert werden soll, dann kann der PGP Universal Server 290 selbst die Nachricht vor der Übertragung verschlüsseln und signieren.
  • Alternativ kann der Benutzer – beispielsweise über eine PGP-fähige Messaging-Anwendung auf dem Computergerät des Benutzers, die mit dem PGP Universal Server 290 kommuniziert – Sicherheitsrichtliniendaten von dem PGP Universal Server 290 auf das Computergerät des Benutzers herunterladen. Der Benutzer der Anwendung kann dann auf der Grundlage der erhaltenen Sicherheitsrichtliniendaten beispielsweise angewiesen werden, die Nachricht zu verschlüsseln und zu signieren, bevor sie übertragen werden.
  • Dementsprechend wird mit dem PGP Universal Server 290 die Möglichkeit bereitgestellt, eine zentralisierte Richtlinie auf der Basis von Domains und anderen Mechanismen durchzusetzen.
  • Der PGP Universal Server 290 kann auch eingerichtet sein, um PGP-Schlüssel zu speichern, zu prüfen und anderweitig zu verwalten, und um PGP-Schlüssel von entfernten Schlüsselspeichern abzurufen, wenn die Schlüssel zum Codieren (z. B. Verschlüsseln und/oder Signieren) von Nachrichten benötigt werden. Wenn das durch einen Benutzer oder durch eine Anwendung angefordert wird, kann der PGP Universal Server 290 auch bei Bedarf gespeicherte oder abgerufene PGP-Schlüssel dem Benutzer bereitstellen.
  • Durch Übernahme des Einsatzes einer Policy Engine, wie sie zum Beispiel im hier beschriebenen Beispiel durch einen PGP Universal Server 290 implementiert ist, kann ein Großteil der Belastung, die mit dem Verarbeiten von sicheren Nachrichten (z. B. E-Mails), und insbesondere mit der fallspezifischen Entscheidung, welche Nachrichten sicher gesendet werden sollen und welche Sicherheitscodierung angewendet werden soll, auf die Policy Engine übertragen werden.
  • Nunmehr mit Bezug auf 5 ist ein Blockdiagramm zur Darstellung der Komponenten eines Beispiels für eine codierte Nachricht gezeigt, wie sie durch einen Nachrichtenserver (z. B. den Nachrichtenserver 268 aus 4) empfangen und an einen Benutzer (z. B. den des Mobilgeräts 100) weitergeleitet werden kann, die allgemein mit 350 bezeichnet ist. Die codierte Nachricht 350 enthält typischerweise ein oder mehrere der folgenden Bestandteile: einen Header 352, einen Hauptteil bzw. einen Datenabschnitt 354, optional einen oder mehrere codierte Anhänge 356, einen oder mehrere verschlüsselte Sitzungsschlüssel 358 (wenn die Nachricht verschlüsselt ist) und eine digitale Signatur sowie signaturbezogene Informationen 360.
  • Zum Beispiel enthält der Header-Abschnitt 352 der Nachricht 350 typischerweise Adresseninformationen, beispielsweise "An" (To), "Von" (From), und "Cc" Nachrichtenadressen, und kann auch beispielsweise Nachrichtenlängenindikatoren und Verschlüsselungs- und Signaturschemen-Identifikatoren enthalten. Der eigentliche Nachrichteninhalt ist normalerweise im Hauptteil bzw. Datenabschnitt 354 und möglicherweise in einem oder mehreren Anhängen 356 enthalten, die eventuell durch den Absender mit einem Sitzungsschlüssel verschlüsselt wurden. Wenn ein Sitzungsschlüssel verwendet werden soll, wird dieser 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 eingeschlossen.
  • Wenn die Nachricht signiert ist, sind auch eine digitale Signatur und signaturbezogene Informationen 360 enthalten. Dazu können beispielsweise das Zertifikat des Senders gehören, wenn Protokolle wie S/MIME verwendet werden. Ein weiteres Beispiel: Wenn die Signatur eine PGP-Signatur ist, dann enthält die PGP-Signatur einen PGP-Schlüsselidentifikator, der zur Identifizierung des PGP-Schlüssels verwendet werden kann, der die Nachricht signiert hat. Der PGP-Schlüssel würde typischerweise nicht in die Nachricht eingeschlossen sein. Im Allgemeinen können Personen, die eine sichere Kommunikation miteinander beabsichtigen, im Vorfeld einer solchen Kommunikation PGP-Schlüssel austauschen. Der PGP-Schlüssel enthält typischerweise auch Informationen, die mit dem Schlüsselinhaber assoziiert sind, beispielsweise eine Adresse (z. B. eine E-Mail-Adresse), die mit dem Schlüsselinhaber assoziiert ist.
  • Die signierten Nachrichten müssen nicht auf Nachrichten mit einer einzelnen digitalen Signatur 360 beschränkt sein, die an das Ende der Nachricht angehängt ist. Beispielsweise können einige Protokolle das Signieren mehrerer, individueller Abschnitte von Daten in einem Nachrichtenhauptteil 354 gestatten, und die resultierende Nachricht kann mehrere digitale Signaturen umfassen, die in der Nachricht enthalten sind, möglicherweise eingebettet in den Nachrichtenhauptteil 354 selbst.
  • Das Format einer codierten Nachricht, wie es in 5 gezeigt wird, ist hier lediglich als Beispiel dargestellt, und dem Fachmann auf dem Gebiet der Technik wird verständlich sein, dass codierte Nachrichten auch in anderen Formaten existieren können. In Abhängigkeit vom jeweils speziell eingesetzten sicheren Nachrichtenstandard oder -protokoll können Komponenten einer codierten Nachricht in einer anderen Reihenfolge auftreten als in 5 gezeigt, und eine codierte Nachricht kann weniger, mehr oder andere Komponenten enthalten, was davon abhängen kann, ob die codierte Nachricht verschlüsselt, signiert oder beides ist. Beispielsweise können in vielen bekannten Implementierungen die Sitzungsschlüssel 358 nach dem Header 352 und vor dem Nachrichtenhauptteil 354 bereitgestellt werden.
  • Um ein besseres Verständnis einer Reihe von Merkmalen der hier beschriebenen Ausführungsformen zu vermitteln, sind in 6A bis 6E mehrere Beispiele für Nachrichten gezeigt, die lediglich der Veranschaulichung dienen sollen. Es sollte einleuchten, dass das allgemeine Format und der Inhalt der Nachrichten sich zwischen verschiedenen Implementierungen unterscheiden können.
  • Es dürfte auch verständlich sein, dass obwohl die meisten der in diesen Beispielen gezeigten Nachrichten Daten enthalten, die mit einem PGP-basierten Protokoll signiert wurden, die Merkmale der hier beschriebenen Ausführungsformen auch auf Nachrichten anwendbar sind, die Daten enthalten, welche unter Verwendung anderer Nachrichtenprotokolle signiert wurden.
  • Aus Gründen der Kürze werden die eigentlichen PGP-Signaturen, die in den Nachrichten erscheinen würden, in den Abbildungen nicht explizit gezeigt, sondern stattdessen wird jede Signatur der Einfachheit halber in diesen Beispielen allgemein als "<...signature appears hexe...>" (Signatur erscheint hier) identifiziert.
  • Unter Bezug auf 6A ist die exemplarische E-Mail-Nachricht 400 dargestellt, die wie im Header 402 der Nachricht 400 ersichtlich von John Smith an die Adresse janedoe@xyz.com gesendet wird und einen Nachrichtenbeginn-Header 404, einen signierten Datenabschnitt 406 sowie eine digitale PGP-Signatur 408 enthält, die dem signierten Datenabschnitt 406 entspricht und durch einen Signaturbeginn-Header 409 identifiziert wird. Die digitale Signatur 408 kann in bekannter Weise verwendet werden, um zu verifizieren, dass der signierte Datenabschnitt 406 tatsächlich mit dem Schlüssel signiert wurde, der durch die Schlüssel- ID innerhalb der digitalen Signatur 408 identifiziert wird, und dass er während der Übertragung nicht modifiziert wurde.
  • Außerdem kann in einer Systemausführungsform die Adresse, die mit dem zum Generieren der digitalen Signatur 408 verwendeten Schlüssel assoziiert ist, ermittelt werden, indem mit dem Schlüssel assoziierte Informationen zum Schlüsselinhaber aus einem Schlüssel-/Zertifikatspeicher abgerufen werden. Beispielsweise kann die Empfängerin janedoe@xyz.com der Nachricht 400 bereits zuvor PGP-Schlüssel mit John Smith ausgetauscht und den PGP-Schlüssel von John Smith in einem Schlüsselspeicher ihres Computergeräts (z. B. des Mobilgeräts 100 aus 4) gespeichert haben. Angenommen, die Nachricht wurde tatsächlich von John Smith gesendet, dann würde der Schlüssel, der durch die Schlüssel-ID innerhalb der digitalen Signatur 408 identifiziert wird, mit einem Schlüssel für John Smith übereinstimmen, der in diesem Schlüsselspeicher gespeichert ist. Dann kann zur Erhöhung der Sicherheit verifiziert werden, dass die mit diesem Schlüssel assoziierte Adresse mit der im Header 402 identifizierten Adresse übereinstimmt. Wenn die Adressen nicht übereinstimmen, kann der Empfänger der Nachricht 400 dann gewarnt werden, dass eine Adressen-Nichtübereinstimmung erkannt wurde, und zwar unabhängig davon, ob sich die digitale Signatur 408 anderweitig selbst richtig verifiziert oder nicht.
  • Nunmehr unter Bezug auf 6B ist das Beispiel einer E-Mail-Nachricht 410 dargestellt, die wie im Header 412 der Nachricht 410 ersichtlich eine Antwort von Jane Doe, der Empfängerin der Nachricht 400 (6A) unter janedoe@xyz.com, an John Smith ist. Der Text der Nachricht 400 wurde unter einem Nachrichtentrennzeichen 414 in die Nachricht 410 einbezogen und kann als Repräsentation eines Konversations-Threads zwischen John Smith und Jane Doe angesehen werden.
  • In diesem Beispiel ist das Nachrichtentrennzeichen 414 ein Ursprungsnachricht-Trennzeichen in der Form "-----Original Message-----" (Ursprungsnachricht). Eine Vielzahl von Nachrichtentrennzeichen sind beim Stand der Technik bekannt, die üblicherweise zum Trennen der Daten einer Nachricht, auf die geantwortet wird, von den Daten in einer aktuellen Nachricht verwendet werden, wozu beispielsweise ein Zeilentrennzeichen (z. B. eine Linie oder eine Reihe von Bindestrichen, die die Daten einer Antwort, auf die geantwortet wird, von den Daten in der aktuellen Nachricht trennen), ein Ursprungsautor-Trennzeichen (z. B. eine Angabe dazu, wer die Nachricht geschrieben hat, auf die geantwortet wird, was in der Nachricht 410 z. B. "John Smith schrieb:" oder "<johnsmith@abc.com> schrieb:" sein kann) sowie andere vordefinierte Trennzeichen für diesen Zweck gehören. In gleicher Weise können ein Weitergeleitete-Nachricht-Trennzeichen (z. B. "-----Forwarded Message-----" (Weitergeleitete Nachricht), ein Ursprungsautor-Trennzeichen und andere vordefinierte Trennzeichen verwendet werden, um die Daten einer Nachricht, die weitergeleitet wurde, von den Daten in einer aktuellen Nachricht zu trennen.
  • In der Beispielnachricht 410 hat Jane Doe keinen Abschnitt ihrer Antwort an John Smith digital signiert. Allerdings enthält die Nachricht 410 Text der älteren Nachricht 400, auf die geantwortet wurde. Durch die Einbeziehung des Textes einer älteren Nachricht enthält die Nachricht 410 jetzt einen Abschnitt aus signierten Daten 406 und die entsprechende digitale Signatur 408. Ein Gerät, das zur Erkennung von Adressen-Nichtübereinstimmungen eingerichtet ist, könnte annehmen, dass die Adresse, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur 408 verwendet wurde, mit der Adresse der Absenderin Jane Doe übereinstimmen müsste, die im Header 412 der Nachricht 410 genannt ist. In diesem Fall würde eine Adressen-Nichtübereinstimmung erkannt werden, weil der Schlüssel, der zum Generieren der digitalen Signatur 408 verwendet wurde, zu John Smith gehört. Allerdings wäre es irreführend, den Empfänger über diese Adressen-Nichtübereinstimmung zu benachrichtigen, weil der Fehler das Ergebnis der ordnungsgemäßen Einbeziehung einer älteren Nachricht 400 in die aktuelle Nachricht 410 ist und nicht dadurch entstanden ist, dass beispielsweise eine dritte Seite in böswilliger Absicht versucht hat, sich für Jane Doe auszugeben.
  • Dementsprechend kann gemäß einem umfassenden Aspekt, der im Folgenden vor dem Hintergrund einer Reihe von Ausführungsformen und unter Bezug auf 7A bis ZC detailliert beschrieben werden soll, mindestens eine vorbestimmte Aktion für jede digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt, durchgeführt werden, die den Zweck hat, eine Irreführung des Benutzers unter den oben angeführten Umständen zu verhindern. Beispielsweise könnte im Beispiel von 6B das Computergerät von John Smith so eingerichtet sein, dass es alle digitalen Signaturen (z. B. 408) ignoriert, die im Text der Nachricht 410 nach dem Nachrichtentrennzeichen 414 vorkommen, wodurch die Verifizierung umgangen wird, dass die Absenderadresse im Header 412 mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert. ist, der zum Generieren der digitalen Signatur 408 verwendet wurde. Als weiteres Beispiel könnte das Computergerät von John Smith so eingerichtet sein, dass es zwar verifiziert, dass die Absenderadresse im Header 412 mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur 408 verwendet wurde, jedoch die Benachrichtigung des Benutzers über die erkannte Adressen-Nichtübereinstimmung unterdrückt. Andere Beispiele für vordefinierte Aktionen in abweichenden Ausführungsformen werden im Folgenden ebenfalls beschrieben.
  • Nunmehr unter Bezug auf 6C wird die exemplarische E-Mail-Nachricht 410b dargestellt, die ein anderes Beispiel einer Antwort von Jane Doe im Gegensatz zur in 6B gezeigten Antwort ist.
  • Die Nachricht 410b ähnelt der Nachricht 410. Der Text der Nachricht 400 wurde ebenfalls unter einem Nachrichtentrennzeichen 414 in die Nachricht 410b einbezogen. Allerdings hat Jane Doe in der Beispielnachricht 410b den gesamten Inhalt ihrer Antwortnachricht an John Smith mithilfe ihres eigenen PGP-Schlüssels digital signiert. Die durch Jane Does Schlüssel signierten Daten sind in 6C mit 416 ausgewiesen, und die digitale PGP-Signatur, die den signierten Daten 416 entspricht, ist als 418 ausgewiesen.
  • Die signierten Daten 416 beziehen auch einen Abschnitt aus signierten Daten 406 und die entsprechende digitale Signatur 408 aus der Nachricht 400 ein, auf die geantwortet wurde.
  • Für die beiden digitalen Signaturen 408 und 418, die in der Nachricht 410b vorkommen, wäre es in diesem Beispiel für das Computergerät von John Smith angebracht zu erkennen, ob es eine Adressen-Nichtübereinstimmung zwischen der letzten digitalen Signatur 418 und dem Absender der Nachricht 410b (d. h. Jane Doe) laut Identifizierung im Header 412 gibt. Für die verbleibende digitale Signatur 408 kann jedoch die mindestens eine vorbestimmte Aktion durchgeführt werden, wie das unter Bezug auf 6B beschrieben wurde.
  • 6D und 6E sind weitere Beispiele für Nachrichten 420, 420b, die einen längeren Konversations-Thread zwischen John Smith und Jane Doe enthalten. Es werden zwei alternative Antworten von John Smith an Jane Doe gezeigt, wie aus dem Header 422 ersichtlich ist. Die Nachrichten, auf die geantwortet wird, wurden nach dem Nachrichtentrennzeichen 424 in die Nachrichten 420, 420b einbezogen.
  • In 6D wurde der neue Text, der als Antwort von John Smith bereitgestellt wird, signiert, und die signierten Daten und die entsprechende digitale Signatur sind als 426 bzw. 428 dargestellt. In der Nachricht 420 erscheint das Nachrichtentrennzeichen 424 nicht innerhalb der signierten Daten 426.
  • In 6E wurde sowohl der neue Text, der als Antwort bereitgestellt wird, als auch die Nachricht, auf die John Smith antwortet, signiert, und die signierten Daten und die entsprechende digitale Signatur sind als 426 bzw. 428 dargestellt. In der Nachricht 420b erscheint das Nachrichtentrennzeichen 424 innerhalb der signierten Daten 426.
  • In beiden Beispielen wäre es angebracht zu erkennen, ob es eine Adressen-Nichtübereinstimmung zwischen der digitalen Signatur 428 und dem Absender der Nachricht 420 laut Identifizierung im Header 422 gibt. Allerdings kann mindestens eine vorbestimmte Aktion im Hinblick auf die anderen digitalen Signaturen durchgeführt werden, die in den Nachrichten 426, 428 vorkommen. Diese Merkmale werden durch mindestens eine der unten beschriebenen Ausführungsformen bereitgestellt.
  • Wie bereits zuvor in dieser Beschreibung erwähnt wurde, beziehen sich die hier beschriebenen Ausführungsformen allgemein auf eine Vorrichtung und auf Verfahren, mit denen die Anzahl der einem Benutzer gemeldeten Adressen-Nichtübereinstimmungsfehlern minimiert werden kann, insbesondere bei Nachrichten, die ordnungsgemäß Nachrichtenteile einbeziehen, welche durch eine andere Person als den Absender signiert wurden, wie das der Fall sein kann, wenn die Nachricht einen Konversations-Thread enthält. Damit kann die Gebrauchsfähigkeit eines Computergeräts erhöht werden, und es kann besonders nützlich sein, wenn es sich bei dem Computergerät um ein Mobilgerät handelt.
  • Zuerst Bezug nehmend auf 7A ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer exemplarischen Ausführungsform dargestellt, das allgemein mit 500 bezeichnet ist. Weitere Details im Hinblick auf verschiedene Schritte des Verfahrens 500 (und der Verfahren 500b und 500c) und im Hinblick auf Merkmale, die in abweichenden Ausführungsformen eingesetzt werden können, wurden bereits in der bisherigen Beschreibung erläutert.
  • Mindestens einige der Schritte des Verfahrens 500 (und des Verfahrens 500b und 500c) werden durch eine Anwendung durchgeführt, die im Computerprogramm ausgeführt wird und sich dort befindet. Die Anwendung kann eine E-Mail- oder eine andere Messaging-Anwendung sein, eine andere Anwendung, die mit der E-Mail- oder anderen Messaging-Anwendung gekoppelt oder anderweitig in diese integriert ist (z. B. als Addon-Komponente, die für die benötigte Funktionalität sorgt), oder eine andere Anwendung, die zur Durchführung solcher Schritte programmiert wurde.
  • Das Computergerät kann ein Desktopcomputer (was beispielsweise einen Laptopcomputer oder ein anderes Computergerät einschließen kann, mit dem ein Mobilgerät synchronisiert werden kann), ein Mobilgerät oder ein anderes Computergerät sein. Das Computergerät kann mit einer Policy Engine (z. B. in einem PGP Universal Server 290 aus 4 implementiert) sein.
  • In Schritt 510 wird eine Nachricht (z. B. eine E-Mail-Nachricht) im Computergerät (z. B. dem Mobilgerät 100 aus 4) durch eine Anwendung empfangen, die auf dem Computergerät ausgeführt wird (z. B. eine E-Mail-Anwendung). Die empfangene Nachricht umfasst einen Header, der typischerweise eine Absenderadresse (d. h. von wo aus die Nachricht gesendet wurde), die Empfängeradresse bzw. -adressen, das Datum und die Uhrzeit beim Senden oder Empfangen der Nachricht, das Thema bzw. den Betreff der Nachricht und potenziell andere Informationen einschließt, wie das oben unter Bezug auf das Beispiel von 5 erläutert wurde.
  • Die in Schritt 510 empfangene und entsprechend dem Verfahren 500 zu verarbeitende Nachricht ist auch eine Nachricht, die mindestens einen Abschnitt aus signierten Daten sowie eine digitale Signatur entsprechend jedem Abschnitt aus signierten Daten enthält. Ein Abschnitt aus signierten Daten kann einen ganzen Nachrichtenhauptteil umfassen.
  • Gemäß mindestens einer Ausführungsform kann jeder des mindestens einen Abschnitts aus signierten Daten unter Verwendung eines PGP-Schlüssels signiert worden sein. Jeder des mindestens einen Abschnitts aus signierten Daten kann durch einen PGP-Nachrichtenbeginn-Header (z. B. "-----BEGIN PGP MESSAGE-----" oder "-----BEGIN PGP SIGNED MESSAGE-----") an seinem Anfang und einen entsprechenden PGP-Signaturbeginn-Header (z. B. "-----BEGIN PGP SIGNATURE-----") an seinem Ende definiert sein, wobei die signierten Daten zwischen den beiden Headern erscheinen.
  • Ein Abschnitt aus signierten Daten und die entsprechende digitale Signatur können auch als Bestandteil einer älteren Nachricht enthalten sein (z. B. einer Nachricht, auf die geantwortet wird bzw. wurde, oder einer Nachricht, die weitergeleitet wird bzw. wurde), die in die in Schritt 510 empfangene Nachricht einbezogen wurde. In einigen Fällen können diese signierten Daten und die entsprechende digitale Signatur weiter signiert sein und damit innerhalb eines anderen Abschnitts aus signierten Daten in der in Schritt 510 empfangenen Nachricht verschachtelt sein (siehe z. B. 6E).
  • Die in Schritt 510 empfangene und entsprechend dem Verfahren 500 zu verarbeitende Nachricht umfasst auch mindestens ein Nachrichtentrennzeichen, welches anzeigt, dass mindestens eine ältere Nachricht in diese empfangene Nachricht einbezogen wurde. Ein Nachrichtentrennzeichen kann beispielsweise ein Ursprungsnachricht-Trennzeichen (z. B. "-----Original Message-----" (Ursprungsnachricht)), ein Zeilentrennzeichen (z. B. "-----" oder eine horizontale Linie oder Leiste), ein Ursprungsautor-Trennzeichen (z. B. "<der absender> schrieb:"), ein Weitergeleitete-Nachricht-Trennzeichen (z. B. "-----Forwarded Message-----" (Weitergeleitete Nachricht)) oder ein anderes Nachrichtentrennzeichen sein, das möglicherweise vordefiniert ist und für dessen Erkennung die Anwendung eingerichtet ist. Da die Nachrichtentrennzeichen bei den bekannten Systemen stark voneinander abweichen können, kann eine Anwendung so eingerichtet werden, dass sie die üblichen Varianten erkennen kann.
  • In einer abweichenden Ausführungsform kann die Anwendung auch so eingerichtet sein, dass sie innerhalb eines Abschnitts aus signierten Daten, der an seinem Beginn durch einen ersten Nachrichtenbeginn-Header definiert ist, einen nachfolgenden Nachrichtebeginn-Header als ein Nachrichtentrennzeichen erkennt. Wenn beispielsweise ein erster Header des Typs "-----BEGIN PGP MESSAGE-----" vorkommt, der anzeigt, dass signierte Daten folgen, und dann nach diesem ersten Header jedoch vor einem Header des Typs "-----BEGIN PGP SIGNATURE-----" ein Header des Typs "-----BEGIN PGP MESSAGE-----" vorkommt, dann kann der nachfolgende Header als ein Nachrichtentrennzeichen behandelt werden.
  • In Schritt 520 wird das erste Nachrichtentrennzeichen in der in Schritt 510 empfangenen Nachricht aufgesucht. Das Vorkommen des ersten Nachrichtentrennzeichens in der empfangenen Nachricht legt typischerweise nahe, dass alle Daten in der Nachricht, die vor dem ersten Nachrichtentrennzeichen stehen, vom Absender der in Schritt 510 empfangenen Nachricht stammen, während die Daten, die nach dem ersten Nachrichtentrennzeichen folgen, von einer anderen Person als dem Absender stammen. Die Daten, die nach dem ersten Nachrichtentrennzeichen folgen, gehören zu einer älteren Nachricht, die der Absender der in Schritt 510 empfangenen Nachricht beispielsweise beantwortet oder weitergeleitet hat.
  • Die Nachricht kann – muss aber nicht – einen oder mehrere Abschnitte aus signierten Daten und die entsprechenden digitalen Signaturen umfassen, wobei beides vor dem ersten Nachrichtentrennzeichen vorkommt. Solche Abschnitte aus signierten Daten stammen mit großer Wahrscheinlichkeit vom Absender der in Schritt 510 empfangenen Nachricht. Jede digitale Signatur, die signierten Daten entspricht, welche vor dem ersten Nachrichtentrennzeichen vorkommen, kann in bekannter Weise verifiziert werden [Schritt nicht dargestellt].
  • Außerdem ist die Anwendung in einer Ausführungsform so eingerichtet, dass für jede digitale Signatur, die signierten Daten entspricht, welche vor dem ersten Nachrichtentrennzeichen vorkommen, die folgenden Schritte durchgeführt werden: (1) das Verifizieren, dass die im Header der in Schritt 510 empfangenen Nachricht identifizierte Absenderadresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde, die den signierten Daten entspricht, welche vor dem ersten Nachrichtentrennzeichen vorkommen; und (2) das Benachrichtigen eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der jeweiligen digitalen Signatur verwendet wurde, wie das in Schritt 530 gezeigt ist.
  • Um die Adresse zu ermitteln, die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, kann es erforderlich sein, die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber abzurufen, die in einem Schlüsselspeicher gespeichert sind (z. B. in einem Schlüsselspeicher auf dem Computergerät oder aus einem entfernten Schlüsselspeicher) und aus denen die Adresse extrahiert werden kann [Schritt nicht dargestellt]. Sobald die Adresse ermittelt wurde, die mit dem Schlüssel assoziiert ist, kann die Anwendung eine Verifizierung durchführen, dass die ermittelte Adresse mit der Absenderadresse übereinstimmt.
  • In einer abweichenden Ausführungsform kann die Benachrichtigung des Benutzers in Schritt 530 nur dann durchgeführt werden, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt. Beispielsweise kann eine IT-Richtlinieneinstellung festlegen, unter welchen Umständen ein Benutzer des Computergeräts benachrichtigt werden soll, wenn eine Adressen-Nichtübereinstimmung erkannt wird.
  • In Schritt 540 wird ermittelt, ob das erste Nachrichtentrennzeichen, das in Schritt 520 aufgesucht wurde, innerhalb eines Abschnitts aus signierten Daten der in Schritt 510 empfangenen Nachricht vorkommt. Wenn beispielsweise in der Nachricht ein Trennzeichen des Typs "-----Original Message-----" nach einem Header des Typs "-----BEGIN PGP MESSAGE-----" oder "-----BEGIN PGP SIGNED MESSAGE-----" vorkommt, allerdings bevor ein "-----BEGIN PGP SIGNATURE-----" vorkommt, dann würde dies nahelegen, dass das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt.
  • Wenn ermittelt wird, dass das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, dann legt dies typischerweise nahe, dass die Daten, die mit älteren Nachrichten assoziiert sind, welche in die in Schritt 510 empfangene Nachricht einbezogen wurden, nicht durch den Absender der empfangenen Nachricht signiert wurden. Wenn ermittelt wird, dass das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, dann kann mindestens eine vorbestimmte Aktion für jede der digitalen Signaturen in der Nachricht durchgeführt werden, die nach dem ersten Nachrichtentrennzeichen vorkommen, was die Anzahl der irreführenden Adressen-Nichtübereinstimmungsfehler minimieren würde, über die der Benutzer des Computergeräts ansonsten benachrichtigt würde.
  • Beispielsweise umfasst in dieser Ausführungsform wie in Schritt 550 gezeigt die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, das Umgehen der Verifizierung, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde. Anders ausgedrückt: Die Anwendung ist für den Zweck der Erkennung von Adressen-Nichtübereinstimmungen so eingerichtet, dass alle digitalen Signaturen ignoriert werden, die nach dem ersten Nachrichtentrennzeichen vorkommen.
  • Es wird verständlich sein, dass die Anwendung die digitalen Signaturen selbst verifizieren kann (d. h. dass die digitalen Signaturen decodiert werden, um den Signatar der entsprechenden signierten Daten zu authentifizieren und die Nachrichtenintegrität zu bestätigen) [Schritt nicht dargestellt].
  • Durch das Ignorieren der digitalen Signaturen, die nach dem ersten Nachrichtentrennzeichen vorkommen, für den Zweck der Erkennung von Adressen-Nichtübereinstimmungen, kann die Wahrscheinlichkeit eliminiert werden, dass der Benutzer über irreführende Adressen-Nichtübereinstimmungsfehler im Zusammenhang mit älteren Nachrichten benachrichtigt wird, solange das erste Nachrichtentrennzeichen in der Nachricht ordnungsgemäß identifiziert wird. Damit kann die Gebrauchsfähigkeit des Computergeräts erhöht werden, und es kann besonders nützlich sein, wenn es sich bei dem Computergerät um ein Mobilgerät handelt. Beispielsweise kann es für einen Benutzer umständlicher sein, eine große Anzahl an irreführenden Adressen-Nichtübereinstimmungsfehlern auf einem Mobilgerät zu verwalten.
  • Wenn – wiederum unter Bezug auf Schritt 540 – stattdessen ermittelt wird, dass das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt, dann legt dies typischerweise nahe, dass die Daten, die mit mindestens einer älteren Nachricht assoziiert sind, in die in Schritt 510 empfangene Nachricht einbezogen wurden und durch den Absender der empfangenen Nachricht signiert wurden. Eine digitale Signatur entsprechend dem Abschnitt aus signierten Daten, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, sollte existieren, aber erst nach dem ersten Nachrichtentrennzeichen. Dementsprechend wird in Schritt 560 durch die Anwendung eine Verifizierung durchgeführt, dass die im Header der in Schritt 510 empfangenen Nachricht identifizierte Absenderadresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde. In Schritt 570 wird der Benutzer des Computergeräts über eine Adressen-Nichtübereinstimmung benachrichtigt, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zu Generieren der digitalen Signatur verwendet wurde.
  • In Fällen, wo die gesamten Hauptteile der Nachrichten in einer Konversation zwischen zwei oder mehreren Personen routinemäßig signiert werden, wird die digitale Signatur, die der aktuellen Nachricht entspricht, die in jedem konkreten Fall empfangen wird, typischerweise an das Ende der Nachricht angehängt. Dementsprechend wird in diesen Fällen, wenn ein erstes Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt, die digitale Signatur, welche dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, typischerweise die letzte digitale Signatur in der Nachricht sein (siehe 5E).
  • Es ist jedoch ganz allgemein möglich, dass die digitale Signatur, welche dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, nicht die letzte digitale Signatur in der Nachricht ist. Es kann erforderlich sein, die richtige entsprechende digitale Signatur zu ermitteln [Schritt nicht explizit dargestellt], indem beispielsweise ermittelt wird, welche digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, im Hinblick auf den konkreten Abschnitt aus signierten Daten erfolgreich verifiziert wird.
  • Wie oben erwähnt wurde, kann es zur Ermittlung der Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, erforderlich sein, die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber abzurufen, die in einem Schlüsselspeicher gespeichert sind (z. B. in einem Schlüsselspeicher auf dem Computergerät oder aus einem entfernten Schlüsselspeicher) und aus denen die Adresse extrahiert werden kann [Schritt nicht dargestellt]. Sobald die Adresse ermittelt wurde, die mit dem Schlüssel assoziiert ist, kann die Anwendung eine Verifizierung durchführen, dass diese mit der Absenderadresse übereinstimmt.
  • In einer abweichenden Ausführungsform kann die Benachrichtigung des Benutzers in Schritt 570 nur dann durchgeführt werden, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt. Beispielsweise kann eine IT-Richtlinieneinstellung festlegen, unter welchen Umständen ein Benutzer des Computergeräts benachrichtigt werden soll, wenn eine Adressen-Nichtübereinstimmung erkannt wird.
  • In Schritt 580 wird mindestens eine vorbestimmte Aktion für jede der digitalen Signaturen in der Nachricht durchgeführt, die nach dem ersten Nachrichtentrennzeichen vorkommen, aber nicht für die digitale Signatur, für die in Schritt 560 eine Adressenübereinstimmung verifiziert wurde, was die Anzahl der irreführenden Adressen-Nichtübereinstimmungsfehler minimieren würde, über die der Benutzer des Computergeräts ansonsten benachrichtigt würde.
  • In dieser Ausführungsform umfasst die mindestens eine vorbestimmte Aktion für jede digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, aber nicht für die digitale Signatur, für die in Schritt 560 eine Adressenübereinstimmung verifiziert wurde, das Umgehen der Verifizierung, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde. Anders ausgedrückt: Die Anwendung ist für den Zweck der Erkennung von Adressen-Nichtübereinstimmungen so eingerichtet, dass alle digitalen Signaturen ignoriert werden, die nach dem ersten Nachrichtentrennzeichen vorkommen, mit Ausnahme der digitalen Signatur, welche den signierten Daten entspricht, innerhalb derer das erste Nachrichtentrennzeichen vorkommt.
  • Wie bei Schritt 550 wird verständlich sein, dass die Anwendung die digitalen Signaturen selbst verifizieren kann (d. h. dass die digitalen Signaturen decodiert werden, um den Signatar der entsprechenden signierten Daten zu authentifizieren und die Nachrichtenintegrität zu bestätigen) [Schritt nicht dargestellt].
  • Außerdem kann – wie schon unter Bezug auf Schritt 550 erwähnt – durch das Ignorieren der anderen digitalen Signaturen, die nach dem ersten Nachrichtentrennzeichen vorkommen, für den Zweck der Erkennung von Adressen-Nichtübereinstimmungen, die Wahrscheinlichkeit eliminiert werden, dass der Benutzer über irreführende Adressen-Nichtübereinstimmungsfehler im Zusammenhang mit älteren Nachrichten benachrichtigt wird, solange das erste Nachrichtentrennzeichen in der Nachricht ordnungsgemäß identifiziert wird. Damit kann die Gebrauchsfähigkeit des Computergeräts erhöht werden, und es kann besonders nützlich sein, wenn es sich bei dem Computergerät um ein Mobilgerät handelt. Beispielsweise kann es für einen Benutzer umständlicher sein, eine große Anzahl an irreführenden Adressen-Nichtübereinstimmungsfehlern auf einem Mobilgerät zu verwalten.
  • Unter Bezug auf 7B ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer anderen exemplarischen Ausführungsform dargestellt, das allgemein mit 500b bezeichnet ist.
  • Das Verfahren 500b gleicht dem Verfahren 500, mit der Ausnahme, dass die mindestens eine vorbestimmte Aktion, die für eine digitale Signatur durchgeführt wird, die nach dem ersten Nachrichtentrennzeichen vorkommt (d. h. für jede digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, wenn das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, und ansonsten für jede digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, und die nicht diejenige ist, die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt) das Verifizieren umfasst, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde, aber auch das Unterdrücken des Benachrichtigens eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde. Dies ist in den Schritten 550b und 580b dargestellt. Die anderen Schritte des Verfahrens 500b wurden bereits zuvor unter Bezug auf das Verfahren 500 aus 7A beschrieben.
  • In einer abweichenden Ausführungsform kann die Unterdrückung der Benachrichtigung des Benutzers in Schritt 550b und/oder Schritt 580b nur dann durchgeführt werden, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt. Beispielsweise kann eine IT-Richtlinieneinstellung festlegen, unter welchen Umständen ein Benutzer des Computergeräts benachrichtigt werden soll, wenn eine Adressen-Nichtübereinstimmung erkannt wird.
  • Wie ebenfalls unter Bezug auf 7A erwähnt wurde, kann es zur Ermittlung der Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, erforderlich sein, die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber abzurufen, die in einem Schlüsselspeicher gespeichert sind (z. B. in einem Schlüsselspeicher auf dem Computergerät oder aus einem entfernten Schlüsselspeicher) und aus denen die Adresse extrahiert werden kann [Schritt nicht dargestellt]. Sobald die Adresse ermittelt wurde, die mit dem Schlüssel assoziiert ist, kann die Anwendung eine Verifizierung durchführen, dass diese mit der Absenderadresse übereinstimmt.
  • Es wird auch verständlich sein, dass die Anwendung die digitalen Signaturen selbst verifizieren kann (d. h. dass die digitale Signatur decodiert wird, um den Signatar der entsprechenden signierten Daten zu authentifizieren und die Nachrichtenintegrität zu bestätigen) [Schritt nicht dargestellt].
  • Nunmehr unter Bezug auf 7C ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren für die Verarbeitung signierter Nachrichten in einer anderen exemplarischen Ausführungsform dargestellt, das allgemein mit 500c bezeichnet ist.
  • Das Verfahren 500c gleicht dem Verfahren 500, mit der Ausnahme, dass ein Versuch unternommen wird, einen Kontext für digitale Signaturen bereitzustellen, die nach dem ersten Nachrichtentrennzeichen vorkommen, so dass eine ordnungsgemäße Verifizierung von Adressenübereinstimmungen durchgeführt werden kann. Das bringt dem Benutzer potenziell zusätzliche Sicherheit. Stellen wir und beispielsweise vor, der Benutzer nimmt an, dass der Absender eines Abschnitts einer älteren Nachricht, die in eine empfangene Nachricht einbezogen wurde, diesen Abschnitt signiert hat, wie das im Text eines Konversations-Threads angegeben ist. Allerdings ist es möglich, dass der Absender oder die Absenderadresse, wie sie in der "Von:"-Zeile in einer älteren Nachricht eines Konversations-Threads angegeben ist, verändert wurde, um es so aussehen zu lassen, als wäre eine ältere Nachricht durch eine andere Person als den tatsächlichen Absender gesendet und signiert worden.
  • Die im Hinblick auf das Verfahren 500c beschriebene Ausführungsform versucht, diese Arten von Problemen zu lösen, indem eine Adresse ermittelt wird, die mit jedem spezifischen Abschnitt aus signierten Daten assoziiert ist, der mit einer älteren Nachricht assoziiert ist, welche in die in Schritt 510 empfangene Nachricht einbezogen wurde.
  • Konkreter ausgedrückt wird nicht angenommen, dass eine Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer digitalen Signatur verwendet wurde, welche in einer empfangenen Nachricht vorkommt, mit der Absenderadresse übereinstimmen müsste, sondern es kann für jeden Abschnitt aus signierten Daten in der Nachricht ein Versuch unternommen werden, eine abschnittsspezifische Adresse zu ermitteln, so dass bei der Erkennung von Adressen-Nichtübereinstimmungen die richtigen Adressen miteinander verglichen werden können.
  • Insbesondere umfasst in einer Ausführungsform die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt (d. h. für jede digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, wenn das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, und ansonsten für jede digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, und die nicht diejenige ist, die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt): (1) das Ermitteln einer abschnittsspezifischen Adresse, die mit dem Abschnitt aus signierten Daten assoziiert ist, dem die digitale Signatur entspricht, wie das in den Schritten 550c und 580c gezeigt ist; (2) das Verifizieren, dass die in den Schritten 550c und 580c ermittelte abschnittsspezifische Adresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde, wie das in den Schritten 552c bzw. 582c gezeigt ist; und (3) das Benachrichtigen eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die abschnittsspezifische Adresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde, wie das in den Schritten 554c bzw. 584c gezeigt ist. Die anderen Schritte des Verfahrens 500c wurden bereits zuvor unter Bezug auf das Verfahren 500 aus 7A beschrieben.
  • In einer Ausführungsform umfasst der Schritt des Ermittelns einer abschnittsspezifischen Adresse, die mit dem Abschnitt aus signierten Daten assoziiert ist, dem die digitale Signatur entspricht, (z. B. die Schritte 550c und 580c) wenn möglich das Extrahieren einer Adresse für einen vorherigen Absender aus dem Text in der Nachricht, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und diesem Abschnitt aus signierten Daten vorkommt. Allgemein besteht das Ziel darin, zuerst zu ermitteln, wo die ältere Nachricht beginnt, die in eine empfangene Nachricht einbezogen wurde und die den Abschnitt aus signierten Daten enthält, was typischerweise durch das Nachrichtentrennzeichen angezeigt wird, das am nächsten den signierten Daten voransteht. Dementsprechend wird es zumindest in einigen Fällen typischerweise möglich sein, eine abschnittsspezifische Adresse des Absenders dieser älteren Nachricht aus dem Header zu ermitteln, der nach dem Nachrichtentrennzeichen vorkommt, wo ein solcher Header in dem einbezogenen Text bereitgestellt ist.
  • Wenden wir uns beispielsweise dem Beispiel aus 6D zu. Die signierten Daten 416 sind Bestandteil der ursprünglichen Nachricht von Jane Doe, was im Header 412 angezeigt wird, auf die in der Nachricht 420 geantwortet wurde. Um die richtigen Adressen miteinander zu vergleichen, kann die Adresse des Absenders, die im Header 412 erscheint (d. h. janedoe@xyz.com), der den signierten Daten 416 voransteht, als eine abschnittsspezifische Adresse extrahiert werden, die speziell mit den signierten Daten 416 und der entsprechenden digitalen Signatur 418 assoziiert ist. Dann kann die Verifizierung durchgeführt werden, dass die mit der entsprechenden digitalen Signatur 418 assoziierte Adresse mit der abschnittsspezifischen Adresse des Absenders übereinstimmt, der im Header 412 erscheint, und der Benutzer kann benachrichtigt werden, wenn ein Adressen-Nichtübereinstimmungsfehler erkannt wird. In gleicher Weise kann im Hinblick auf die digitale Signatur 408 die Adresse des Absenders, der im Header 402 erscheint, welcher den signierten Daten 406 voransteht, als eine abschnittsspezifische Adresse extrahiert werden, die speziell mit den signierten Daten 406 und der entsprechenden digitalen Signatur 408 assoziiert ist. Dann kann die Verifizierung durchgeführt werden, dass die mit der entsprechenden digitalen Signatur 408 assoziierte Adresse mit der abschnittsspezifischen Adresse des Absenders übereinstimmt, der im Header 402 vorkommt, und der Benutzer kann benachrichtigt werden, wenn ein Adressen-Nichtübereinstimmungsfehler erkannt wird.
  • Auf diese Weise können Adressen-Nichtübereinstimmungsfehler selbst dann richtig erkannt werden, wenn die signierten Daten und die entsprechenden digitalen Signaturen Bestandteil älterer Nachrichten sind, die in eine im Computergerät empfangene Nachricht einbezogen wurden.
  • Wie ebenfalls unter Bezug auf 7A erwähnt wurde, kann es zur Ermittlung der Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, erforderlich sein, die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber abzurufen, die in einem Schlüsselspeicher gespeichert sind (z. B. in einem Schlüsselspeicher auf dem Computergerät oder aus einem entfernten Schlüsselspeicher) und aus denen die Adresse extrahiert werden kann [Schritt nicht dargestellt]. Sobald die Adresse ermittelt wurde, die mit dem Schlüssel assoziiert ist, kann die Anwendung eine Verifizierung durchführen, dass die ermittelte Adresse mit der abschnittsspezifischen Absenderadresse übereinstimmt.
  • Es wird auch wird verständlich sein, dass die Anwendung die digitalen Signaturen selbst verifizieren kann (d. h. dass die digitale Signature decodiert wird, um den Signatar der entsprechenden signierten Daten zu authentifizieren und die Nachrichtenintegrität zu bestätigen) [Schritt nicht dargestellt].
  • Bei einigen Nachrichten wird die Adresse des Absenders einer empfangenen Nachricht oder von vorherigen Absendern für ältere Nachrichten, die in die empfangene Nachricht einbezogen wurden, möglicherweise in der empfangenen Nachricht nicht explizit gezeigt. Das kann beispielsweise auftreten, wenn eine Anwendung so eingerichtet ist, dass sie Nachrichten so verarbeitet, dass der Absender innerhalb des Headers einer gegebenen Nachricht nur durch einen Namen identifiziert wird (z. B. durch einen für einen Benutzer leicht erkennbaren Namen).
  • Dementsprechend umfasst in einer abweichenden Ausführungsform der Schritt des Ermittelns einer abschnittsspezifischen Adresse, die mit dem Abschnitt aus signierten Daten assoziiert ist, dem die digitale Signatur entspricht (z. B. die Schritte 550c, 580c): (1) wenn möglich das Extrahieren eines Namens für einen vorherigen Absender aus dem Text in der Nachricht, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und dem Abschnitt vorkommt; und (2) wenn ein Name extrahiert wurde, das Abrufen einer Adresse für den mit dem extrahierten Namen assoziierten vorherigen Absender aus einem Adressbuch als die abschnittsspezifische Adresse. Allgemein besteht das Ziel darin, zuerst zu ermitteln, wo die ältere Nachricht beginnt, die in eine empfangene Nachricht einbezogen wurde und die den Abschnitt aus signierten Daten enthält, was typischerweise durch das Nachrichtentrennzeichen angezeigt wird, das am nächsten den signierten Daten voransteht. Dementsprechend wird es zumindest in einigen Fällen typischerweise möglich sein, den Namen des Absenders dieser älteren Nachricht aus dem Header zu ermitteln, der nach dem Nachrichtentrennzeichen vorkommt, wo ein solcher Header in dem einbezogenen Text bereitgestellt ist. Ausgehend von diesem Namen kann dann ein Versuch unternommen werden, beispielsweise aus den Daten in einem Adressbuch des Benutzers eine abschnittsspezifische Adresse zu ermitteln, die mit diesem Namen assoziiert ist.
  • Wenden wir uns beispielsweise dem Beispiel aus 6E zu. Die signierten Daten 416 sind Bestandteil der ursprünglichen Nachricht von Jane Doe, was im Header 412 angezeigt wird, auf die in der Nachricht 420 geantwortet wurde. Um die richtigen Adressen miteinander zu vergleichen, kann der Name des Absenders, der im Header 412 erscheint (d. h. Jane Doe), welcher den signierten Daten 416 voransteht, extrahiert werden. Aus dem Adressbuch des Benutzers kann anschließend eine Adresse für Jane Doe als die abschnittsspezifische Adresse abgerufen werden, die speziell mit den signierten Daten 416 und der entsprechenden digitalen Signatur 418 assoziiert ist. Dann kann die Verifizierung durchgeführt werden, dass die mit der entsprechenden digitalen Signatur 418 assoziierte Adresse mit der abschnittsspezifischen Adresse des Absenders übereinstimmt, der mit dem Namen assoziiert ist, der im Header 412 erscheint, und der Benutzer kann benachrichtigt werden, wenn ein Adressen-Nichtübereinstimmungsfehler erkannt wird.
  • Als ein Adressbuch kann jedes Verzeichnis, jede Liste oder jede andere Datenstruktur verstanden werden, mit dem bzw. der Namen und die damit assoziierten Adressen bereitgestellt werden können. Die Daten des Adressbuchs können sich im Computergerät oder beispielsweise in einem Speicher auf einem entfernten Computergerät befinden.
  • In dieser abweichenden Ausführungsform kann die Adresse für einen vorherigen Absender nur in solchen Fällen aus einem Adressbuch abgerufen werden, wo die Adresse des vorherigen Absenders im entsprechenden Header nicht explizit bereitgestellt wird. Wenn eine Adresse explizit bereitgestellt wird, kann die extrahierte Adresse verwendet werden, um wie oben beschrieben die Verifizierung der Adresse durchzuführen.
  • Wie ebenfalls unter Bezug auf 7A erwähnt wurde, kann es zur Ermittlung der Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer gegebenen digitalen Signatur verwendet wurde, erforderlich sein, die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber abzurufen, die in einem Schlüsselspeicher gespeichert sind (z. B. in einem Schlüsselspeicher auf dem Computergerät oder aus einem entfernten Schlüsselspeicher) und aus denen die Adresse extrahiert werden kann [Schritt nicht dargestellt]. Sobald die Adresse ermittelt wurde, die mit dem Schlüssel assoziiert ist, kann die Anwendung eine Verifizierung durchführen, dass diese mit einer abschnittsspezifischen Adresse übereinstimmt.
  • Es wird auch verständlich sein, dass die Anwendung die digitalen Signaturen selbst verifizieren kann (d. h. dass die digitale Signatur decodiert wird, um den Signatur der entsprechenden signierten Daten zu authentifizieren und die Nachrichtenintegrität zu bestätigen) [Schritt nicht dargestellt].
  • Die Ausführungsformen der unter Bezug auf 7A bis 7C beschriebenen Verfahren werden lediglich als Beispiele bereitgestellt, und in abweichenden Ausführungsformen können auch andere Techniken verwendet werden, um die Anzahl von irreführenden oder anderweitig unrichtigen Benachrichtigungen zu Adressen-Nichtübereinstimmungsfehlern zu minimieren, die potenziell durch ein Computergerät erzeugt würden, das zum Erkennen von Adressen-Nichtübereinstimmungsfehlern eingerichtet ist. Insbesondere kann eine andere Heuristik angewendet werden, um die Ermittlung zu unterstützen, wann die Benutzerbenachrichtigung über eine Adressen-Nichtübereinstimmung angesichts der konkreten Struktur einer Nachricht wahrscheinlich unangemessen ist.
  • Außerdem ist in einer abweichenden Ausführungsform, wo eine Verifizierung durchgeführt wird, dass die Absenderadresse oder eine abschnittsspezifische Adresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren einer bestimmten digitalen Signatur verwendet wurde, für eine digitale Signatur, die entweder vor oder nach dem ersten Nachrichtentrennzeichen vorkommt, für den Fall, dass eine Adressen-Nichtübereinstimmung erkannt wird, das Computergerät des Weiteren eingerichtet zum Unterdrücken des Anzeigens der Nachricht selbst oder von einem oder mehreren Teilen der Nachricht für den Benutzer. Das Unterdrücken des Anzeigens von mindestens einem Teil von jeder Nachricht kann nur dann durchgeführt werden, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt. Beispielsweise kann eine IT-Richtlinieneinstellung festlegen, unter welchen Umständen eine Nachricht (oder Teile davon) für einen Benutzer angezeigt werden sollen, wenn eine Adressen-Nichtübereinstimmung erkannt wird. Wenn das Anzeigen von mindestens einem Teil einer Nachricht unterdrückt wird, dann wird der Benutzer typischerweise darüber benachrichtigt, dass der Grund für die Unterdrückung des Anzeigens der Nachricht darin besteht, dass ein Adressen-Nichtübereinstimmungsfehler erkannt wurde.
  • Es wird auch verständlich sein, dass in einer gegebenen Implementierung eine Kombination der Merkmale von verschiedenen hier beschriebenen Ausführungsformen eingesetzt werden kann. Beispielsweise kann für bestimmte Abschnitte aus signierten Daten in einer Nachricht der Versuch unternommen werden, eine abschnittsspezifische Adresse zu ermitteln, um eine Verifizierung der Adressenübereinstimmung durchzuführen, während andere Abschnitte von Daten in einer Nachricht einfach umgangen und ignoriert werden können. Ob für eine spezifische ältere Nachricht, die in eine empfangene Nachricht einbezogen wurde, eine Verifizierung einer Adressenübereinstimmung durchgeführt wird, kann beispielsweise davon abhängen, wie alt die spezifische ältere Nachricht in einem gegebenen Konversations-Thread ist. Die Technik, die auf einen gegebenen Abschnitt aus signierten Daten und die entsprechende digitale Signatur einer älteren Nachricht, die in eine empfangene Nachricht einbezogen wurde, angewendet werden soll, kann beispielsweise durch eine Sicherheitsrichtlinie vorgegeben werden (z. B. durch Festlegen einer IT-Richtlinieneinstellung), welche die Verwendung des Computergeräts bestimmt.
  • Die Schritte der hier beschriebenen Verfahren können in Form von ausführbaren Softwareanweisungen bereitgestellt werden, die auf einem computerlesbaren Medium gespeichert sind, was auch übertragbare Medien einschließen kann.
  • Die Beschreibung der 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 vom Umfang der Erfindung abzuweichen, der in den hier beigefügten Ansprüchen definiert ist.

Claims (26)

  1. Verfahren für die Verarbeitung digital signierter Nachrichten, die in einem Computergerät empfangen wurden, das Verfahren umfassend die folgenden Schritte: das Empfangen (510) einer Nachricht, umfassend: einen Header, der mindestens eine Absenderadresse identifiziert, mindestens einen Abschnitt aus signierten Daten, eine digitale Signatur entsprechend jedem Abschnitt aus signierten Daten und mindestens ein Nachrichtentrennzeichen; das Ermitteln (540), ob ein erstes Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt; wenn das erste Nachrichtentrennzeichen nicht innerhalb eines Abschnitts aus signierten Daten vorkommt, das Durchführen von mindestens einer vorbestimmten Aktion für jede digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt; und wenn das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt, das Verifizieren (560), dass die Absenderadresse mit einer Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren einer digitalen Signatur verwendet wurde, die nach dem ersten Nachrichtentrennzeichen vorkommt und die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, und das Durchführen von mindestens einer vorbestimmten Aktion für jede andere digitale Signatur in der Nachricht, die nach dem ersten Nachrichtentrennzeichen vorkommt.
  2. Verfahren gemäß Anspruch 1, des Weiteren umfassend den Schritt des Benachrichtigens (570) eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der einen digitalen Signatur verwendet wurde, die nach dem ersten Nachrichtentrennzeichen vorkommt und die dem Abschnitt aus signierten Daten entspricht, innerhalb dessen das erste Nachrichtentrennzeichen vorkommt, wenn das erste Nachrichtentrennzeichen innerhalb eines Abschnitts aus signierten Daten vorkommt.
  3. Verfahren gemäß Anspruch 2, wobei der Schritt des Benachrichtigens (570) nur dann durchgeführt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  4. Verfahren gemäß jedem der Ansprüche 1 bis 3, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, das Umgehen (550, 580) der Verifizierung umfasst, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  5. Verfahren gemäß jedem der Ansprüche 1 bis 3, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, umfasst: das Verifizieren (550b, 580b), dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde; und das Unterdrücken (550b, 580b) des Benachrichtigens eines Benutzers des Computergeräts über eine Adressen- Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  6. Verfahren gemäß Anspruch 5, wobei das Benachrichtigen des Benutzers über eine Adressen-Nichtübereinstimmung nur dann unterdrückt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  7. Verfahren gemäß jedem der Ansprüche 1 bis 3, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, umfasst: das Verifizieren, dass die Absenderadresse mit der Adresse übereinstimmt, die mit einem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde; und das Unterdrücken des Anzeigens von mindestens einem Teil der Nachricht für einen Benutzer des Computergeräts, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  8. Verfahren gemäß Anspruch 7, wobei das Anzeigen von mindestens einem Teil der Nachricht für den Benutzer nur dann unterdrückt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  9. Verfahren gemäß jedem der Ansprüche 1 bis 3, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, umfasst: das Ermitteln (550c, 580c) einer abschnittsspezifischen Adresse, die mit dem Abschnitt aus signierten Daten assoziiert ist, dem die digitale Signatur entspricht; das Verifizieren (552c, 582c), dass die abschnittsspezifische Adresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde; und das Benachrichtigen (554c, 584c) eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die abschnittsspezifische Adresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  10. Verfahren gemäß Anspruch 9, wobei das Benachrichtigen des Benutzers über eine Adressen-Nichtübereinstimmung nur dann durchgeführt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  11. Verfahren gemäß Anspruch 9, wobei die mindestens eine vorbestimmte Aktion für eine digitale Signatur, die nach dem ersten Nachrichtentrennzeichen vorkommt, des Weiteren das Unterdrücken des Anzeigens von mindestens einem Teil der Nachricht für einen Benutzer des Computergeräts umfasst, wenn die abschnittsspezifische Adresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  12. Verfahren gemäß Anspruch 11, wobei das Anzeigen von mindestens einem Teil der Nachricht für den Benutzer nur dann unterdrückt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  13. Verfahren gemäß jedem der Ansprüche 9 bis 12, wobei das Ermitteln einer abschnittsspezifischen Adresse das Extrahieren einer Adresse für einen vorherigen Absender aus dem Text in der Nachricht umfasst, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und dem Abschnitt vorkommt.
  14. Verfahren gemäß jedem der Ansprüche 9 bis 12, wobei das Ermitteln einer abschnittsspezifischen Adresse umfasst: das Extrahieren eines Namens für einen vorherigen Absender aus dem Text in der Nachricht, der zwischen dem Nachrichtentrennzeichen, das am nächsten dem Abschnitt aus signierten Daten voransteht, dem die digitale Signatur entspricht, und dem Abschnitt vorkommt; und das Abrufen einer Adresse für den mit dem Namen assoziierten vorherigen Absender aus einem Adressbuch.
  15. Verfahren gemäß jedem der Ansprüche 1 bis 14, des Weiteren umfassend für jede digitale Signatur in der Nachricht, die vor dem ersten Nachrichtentrennzeichen vorkommt, die folgenden Schritte: das Verifizieren (530), dass die Absenderadresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der jeweiligen digitalen Signatur verwendet wurde; und das Benachrichtigen (530) eines Benutzers des Computergeräts über eine Adressen-Nichtübereinstimmung, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der jeweiligen digitalen Signatur verwendet wurde.
  16. Verfahren gemäß Anspruch 15, wobei der Schritt des Benachrichtigens (530) nur dann durchgeführt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  17. Verfahren gemäß jedem der Ansprüche 1 bis 14, des Weiteren umfassend für jede digitale Signatur in der Nachricht, die vor dem ersten Nachrichtentrennzeichen vorkommt, die folgenden Schritte: das Verifizieren, dass die Absenderadresse mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der jeweiligen digitalen Signatur verwendet wurde; und das Unterdrücken des Anzeigens von mindestens einem Teil der Nachricht für einen Benutzer des Computergeräts, wenn die Absenderadresse nicht mit der Adresse übereinstimmt, die mit dem Schlüssel assoziiert ist, der zum Generieren der digitalen Signatur verwendet wurde.
  18. Verfahren gemäß Anspruch 17, wobei das Anzeigen von mindestens einem Teil der Nachricht für den Benutzer nur dann unterdrückt wird, wenn das durch eine Sicherheitsrichtlinie gestattet ist, welche die Verwendung des Computergeräts bestimmt.
  19. Verfahren gemäß jedem der vorherigen Ansprüche, des Weiteren umfassend den Schritt des Ermittelns der Adresse, die mit einem Schlüssel assoziiert ist, der zum Generieren einer digitalen Signatur verwendet wurde, indem die mit dem Schlüssel assoziierten Informationen zum Schlüsselinhaber aus einem Schlüsselspeicher abgerufen werden.
  20. Verfahren gemäß jedem der vorherigen Ansprüche, wobei das mindestens eine Nachrichtentrennzeichen aus einem oder mehreren der folgenden Nachrichtentrennzeichen besteht, die aus der folgenden Gruppe ausgewählt werden: ein Zeilentrennzeichen, ein Ursprungsnachricht-Trennzeichen, ein Weitergeleitete-Nachricht-Trennzeichen, ein Ursprungsautor-Trennzeichen, ein nachfolgender Nachrichtenbeginn-Header innerhalb eines Abschnitts aus signierten Daten, der zum Teil durch einen ersten Nachrichtenbeginn-Header definiert ist, und ein vordefiniertes Trennzeichen.
  21. Verfahren gemäß jedem der Ansprüche 1 bis 20, wobei jeder des mindestens einen Abschnitts aus signierten Daten unter Verwendung eines PGP-Schlüssels signiert wurde, und wobei jeder des mindestens einen Abschnitts aus signierten Daten durch einen PGP-Nachrichtenbeginn-Header und einen entsprechenden PGP-Signaturbeginn-Header in der Nachricht definiert ist.
  22. Verfahren gemäß jedem der Ansprüche 1 bis 20, wobei jeder des mindestens einen Abschnitts aus signierten Daten unter Verwendung von S/MIME signiert wurde.
  23. Verfahren gemäß jedem der vorherigen Ansprüche, wobei das Computergerät ein Mobilgerät ist.
  24. Computerlesbares Medium, auf dem eine Vielzahl von Anweisungen gespeichert sind, wobei diese Anweisungen die Durchführung der Schritte des Verfahrens gemäß jedem der vorherigen Ansprüche bewirken.
  25. Vorrichtung, die angepasst ist zum Durchführen der Schritte des Verfahrens gemäß jedem der Ansprüche 1 bis 23.
  26. Vorrichtung gemäß Anspruch 25, wobei die Vorrichtung ein Mobilgerät ist.
DE602005003221T 2005-07-29 2005-07-29 Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen Expired - Lifetime DE602005003221T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP05107025A EP1748614B1 (de) 2005-07-29 2005-07-29 Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen

Publications (2)

Publication Number Publication Date
DE602005003221D1 DE602005003221D1 (de) 2007-12-20
DE602005003221T2 true DE602005003221T2 (de) 2008-08-28

Family

ID=35079179

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005003221T Expired - Lifetime DE602005003221T2 (de) 2005-07-29 2005-07-29 Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen

Country Status (6)

Country Link
EP (1) EP1748614B1 (de)
CN (1) CN1905449B (de)
AT (1) ATE377900T1 (de)
CA (1) CA2549585C (de)
DE (1) DE602005003221T2 (de)
SG (1) SG129350A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
LU102626B1 (de) * 2021-03-01 2022-09-01 Wenzl Ehm Alexander Verfahren zur Übertragung von verschlüsselten Nachrichten

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7653696B2 (en) 2005-07-29 2010-01-26 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
CN101340653B (zh) * 2008-08-07 2011-09-14 四川长城天讯数码技术有限公司 用于便携终端下载数据的版权保护方法及系统
EP2458812B1 (de) * 2010-11-29 2016-09-14 BlackBerry Limited Server und Verfahren zum Signieren einer Mitteilung

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7127741B2 (en) * 1998-11-03 2006-10-24 Tumbleweed Communications Corp. Method and system for e-mail message transmission
US7240199B2 (en) * 2000-12-06 2007-07-03 Rpost International Limited System and method for verifying delivery and integrity of electronic messages
US20030050981A1 (en) * 2001-09-13 2003-03-13 International Business Machines Corporation Method, apparatus, and program to forward and verify multiple digital signatures in electronic mail
US20040092310A1 (en) * 2002-11-07 2004-05-13 Igt Identifying message senders
US6986049B2 (en) * 2003-08-26 2006-01-10 Yahoo! Inc. Method and system for authenticating a message sender using domain keys

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
LU102626B1 (de) * 2021-03-01 2022-09-01 Wenzl Ehm Alexander Verfahren zur Übertragung von verschlüsselten Nachrichten
WO2022184717A1 (de) * 2021-03-01 2022-09-09 Wenzl Ehm Alexander Verfahren zur übertragung von verschlüsselten nachrichten

Also Published As

Publication number Publication date
CN1905449A (zh) 2007-01-31
ATE377900T1 (de) 2007-11-15
DE602005003221D1 (de) 2007-12-20
SG129350A1 (en) 2007-02-26
CN1905449B (zh) 2011-04-06
EP1748614A1 (de) 2007-01-31
CA2549585C (en) 2011-05-03
EP1748614B1 (de) 2007-11-07
CA2549585A1 (en) 2007-01-29

Similar Documents

Publication Publication Date Title
DE60219222T2 (de) Mehrstufiges System und Verfahren zur Verarbeitung von kodierten Nachrichten
DE602004003503T2 (de) System und Verfahren zur Verifikation von digitalen Unterschriften von Zertifikaten
DE60315434T2 (de) Zertifikatinformationsspeichersystem und verfahren
DE60318825T2 (de) Vorrichtung und verfahren zur unterstützung von mehreren zertifizierungstatusanbietern auf einem mobilen kommunikationsgerät
DE60302148T2 (de) System und verfahren zur auswahl der nachrichteneinstellungen
US8301878B2 (en) System and method for enabling bulk retrieval of certificates
US8090786B2 (en) Method and apparatus for processing digitally signed messages to determine address mismatches
DE602006000817T2 (de) System und Methode für steuernde Datenkommunikation zwischen einem Server und einer Client-Vorrichtung
US20130282848A1 (en) Systems and methods for protecting header fields in a message
US8542824B2 (en) System and method for processing messages with encryptable message parts
DE60309446T2 (de) System und verfahren für die anzeige eines signatur- und vertrauenswürdigkeitsstatuses einer gesicherten nachricht
US8463863B2 (en) Systems and methods for protecting header fields in a message
EP2224655B1 (de) Systeme und Verfahren zum Schützen von Überschriftenfeldern in einer Mitteilung
DE602004013000T2 (de) System und Methode zum Suchen und Abrufen von Zertifikaten
DE602005003221T2 (de) Verfahren und Vorrichtung für die Verarbeitung der digital unterzeichneten Anzeigen, um Adressen-Fehlanpassungen festzustellen
DE602005001155T2 (de) Vorrichtung und Verfahren zum Versenden verschlüsselter Nachrichten an Verteilerlisten
DE602005003220T2 (de) Vorausladung von Sicherheitsrelevanten Daten in einem Mobilnetzwerk
DE602005002648T2 (de) Benachrichtigung von wartenden Aufgaben mittels eines mobilen Geräts
DE60315991T2 (de) System und verfahren zur mimischen auswahl der nachrichteneinstellungen
EP1632871A1 (de) System und Verfahren zum Abfragen von verwandten Zertifikaten
EP2150027B1 (de) Systeme und Verfahren zum Aufbewahren von auditierbaren Aufnahmen auf einer elektronischen Vorrichtung
EP2224656B1 (de) Systeme und Verfahren zum Schützen von Überschriftenfeldern in einer Mitteilung
WO2020187622A1 (de) Verfahren zum authentifizieren eines computersystems
EP3669507B1 (de) Geschützte mobile nachrichtenübertragung
EP1852802B1 (de) System und Verfahren zur Verarbeitung von Nachrichten mit verschlüsselbaren Nachrichtenteilen

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