DE60206592T2

DE60206592T2 - Offset Sicherheitsverfahren zum Datenaustausch

Info

Publication number: DE60206592T2
Application number: DE60206592T
Authority: DE
Inventors: Nicolas Bouthors
Original assignee: Societe Francaise du Radiotelephone SFR SA
Current assignee: Societe Francaise du Radiotelephone SFR SA
Priority date: 2001-12-31
Filing date: 2002-12-06
Publication date: 2006-07-20
Anticipated expiration: 2022-12-07
Also published as: EP1324563B1; FR2834404A1; ATE306774T1; DE60206592D1; ES2254608T3; US20030135737A1; FR2834404B1; DK1324563T3; EP1324563A2; EP1324563A3

Description

Die Erfindung betrifft ein Verfahren zur abgesetzten Sicherung des Datenaustausches. Es ist für die Netzwerke bestimmt, in denen es möglich ist, mit Hilfe eines Terminals auf Daten unterschiedlicher Arten zuzugreifen, wobei bei diesem Zugriff vorausgesetzt wird, dass bei einem Internet-Provider ein Vertrag Abonnement abgeschlossen wird. Solche Netze sind beispielsweise das Internet für Privatpersonen oder die Mobilfunknetze. Um Zugriff auf Daten und auf diese Netze zu bekommen, muss der Benutzer eines Terminals, das den Anschluss an diese Netze ermöglicht, einen Vertrag abschließen. WO99/35801 beschreibt ein System, das den Zugriff gesendeter Mitteilungen kontrolliert, die von einer Vielzahl mobiler Vorrichtungen empfangen werden. Die gewählten mobilen Vorrichtungen verfügen über einen Sendungskodierschlüssel. Die gesendeten Mitteilungen werden vor ihrer Übertragung mit diesem Schlüssel so kodiert, dass die gewählten mobilen Vorrichtungen, die sie empfangen, und nur diejenigen, die über den Schlüssel verfügen, diese Mitteilungen entschlüsseln und ihrerseits weiterleiten können. Ein Ziel der Erfindung ist es, das Vertrauen der Benutzer in solche Netze zu stärken. Ein weiteres Ziel der Erfindung ist es, die Auswirkung der Sicherungsverfahren auf die Endbenutzer auf ein Mindestmaß zu beschränken.
Nach dem Stand der Technik sind Systeme bekannt, mit denen man auf einem Gerät, z.B. einem Personal Computer, so genannte aktive Inhalte oder Daten empfangen kann. Ein Inhalt gilt als aktiv, wenn zu seiner Auslegung mit Ausnahme der Anzeigekapazitäten Kapazitäten des auslegenden Gerätes verwendet werden. Die Kapazitäten mit Ausnahme der besagten Anzeigekapazitäten sind beispielsweise Kommunikations-, Speicher- und Bearbeitungskapazitäten.
Nach dem Stand der Technik und für die Personal Computer gibt es mindestens zwei Hauptsparten aktiver Inhalte. Es gibt aktive Inhalte, die defaultmäßig akzeptiert werden, z.B. Scripts, „Applets" vom Typ Jana und aktive Inhalte, die nur mit der Genehmigung des Benutzers des Gerätes für heruntergeladen und verwendet werden dürfen. Letztere aktive Inhalte sind als „Plug-ins" oder Erweiterung einer Navigationsanwendung bekannt. Beim Herunterladen einer solchen Erweiterung wird der Benutzer gefragt, ob er die besagte Erweiterung akzeptiert. Um ihm die Wahl zu erleichtern, kommt die besagte Erweiterung mit einem Zertifikat, das es ihm ermöglicht, die Stelle oder den Dienstleister zu identifizieren, von der oder dem die Erweiterung stammt. Mit einer solchen Erweiterung kann man die Kontrolle z.B. einer Navigations-Software auf einem für die Verwendung dieser Software verwendeten Gerätes verstärken.
Die beiden Arten der vorgenannten aktiven Inhalte kommen nach einer Anforderung seitens dieses Benutzers auf eines seiner Geräte. Das heißt, dass ein Benutzer eine Anfrage, z.B. nach dem HTTP-Protokoll, ausgesendet hat, um eine Webseite, also eine Datei im HTML-Format, zu empfangen. Diese Datei im HTML-Format enthält also diese aktiven Inhalte, die von der Navigations-Software ausgelegt werden.
Ein erstes Problem besteht bereits darin, dass die Handhabung der Zertifikate, die mit den Erweiterungen kommen, für einen Benutzer kein natürlicher Vorgang ist. So fragt die Navigations-Software, ob der Benutzer die Erweiterung, die von dieser oder jener Stelle gesendet wird, akzeptiert. Meist versteht der Benutzer den „Jargon", der mit dieser Frage einhergeht, nicht und versucht nicht, die Gültigkeit des Zertifikats zu prüfen. Folglich ist es für Leute mit böswilliger Absicht möglich, sich für eine Stelle mit gutwilliger Absicht auszugeben oder so zu tun, als seien sie guten Willens. Deshalb zieht es ein vorsichtiger Benutzer meist vor, die Erweiterungen abzulehnen anstatt das geringste Risiko einzugehen. Dadurch schränkt der Benutzer aus Gründen der Vorsicht die Dienstleistungen ein, auf die er zugreifen könnte, wenn es ein System gäbe, das ihm mehr Vertrauen in die Art und Weise der Versendung der besagten Erweiterungen schenken würde.
Dieses Problem gibt es auch in der Welt des Mobilfunks. Es sei daran erinnert, dass es in der Tat möglich ist, mit einem Mobiltelefon auf Internet und damit auf aktive Inhalte, so wie sie weiter oben beschrieben sind, zuzugreifen. Jedoch ist dieses Problem noch akuter, denn beim Mobilfunk gibt es einen so genannten Push-Modus. Das bedeutet, dass der Benutzer eines Mobilfunkgeräts aktive Inhalte empfangen kann, ohne sie angefordert zu haben. Der Grund für eine solche Funktionsweise ist, dass bei Mobilgeräten Energie gespart werden muss. Deshalb ist es kostspielig, mit einem Mobilgerät beispielsweise im Rahmen einer Messenger-Anwendung regelmäßig Server abfragen zu müssen. Es ist viel einfach, wenn der Messenger-Server eine Meldung an ein Mobilgerät sendet, wenn eine Mitteilung für ihn bestimmt ist.
Außerdem sind die Kontrollmöglichkeiten eines Gerätes vom Typ Mobilgerät durch mit diesem mobilen Terminal kompatiblen Scripts oder „Applets" viel größer als beim Personal Computer. Deshalb ist beim Umgang mit diesen aktiven Inhalten mit einem Mobilgerät größte Vorsicht geboten; ein kluger Benutzer lehnt sie übrigens systematisch ab.
Ein weiteres Problem mit den Mobilgeräten ist sowohl ihre geringe Speicherkapazität als auch in ihre schwache Rechenleistung. Damit kann erstens keine Zertifikat-Datenbank gespeichert und zweitens diese Zertifikat-Datenbank nicht zeitgleich genutzt werden. Eine ähnliche Lösung wie beim Personal Computer ist also nicht auf den Mobilfunk anwendbar. Außerdem wäre eine solche Lösung nicht ergonomisch, weil sie wie beim Personal Computer den Benutzer des Terminals beansprucht. Es ist also keine optimale Lösung.
Ein weiteres Problem stellt sich bezüglich des Dienstleisters. Es kann in der Tat vorkommen, dass der Dienstleister Gewährleistungen bezüglich der Gültigkeit einer Anfrage oder einer Antwort auf eine von einem Teilnehmer gesendete Anfrage verlangt. Nach dem Stand der Technik erfolgt dies durch die die Verwendung von Signaturen und Zertifikaten durch den Teilnehmer, so wie es der Dienstleister tut, um seine Daten zu gewährleisten. Der Teilnehmer muss also komplexe Zertifizierungstechnologien auf seinem Terminal verwenden und der Dienstleister muss sich die Mittel geben, um die von dem Teilnehmer vorgelegten Gewährleistungen zu prüfen. Wenn ein Dienstleister zahlreiche Anforderungen erhält, stellen die Vielzahl der Prüfvorgänge und ihre Komplexität ein Problem bezüglich der Reaktionszeit, die den Teilnehmer entmutigt und ihn davon abhält, sich erneut an den Dienstleister zu wenden.
Die Erfindung löst diese Probleme, indem sie den Arbeitsaufwand für eine minimale Prüfung für einen Teilnehmer und einen Dienstleister auf ein Mindestmaß beschränkt. Entsprechend prüft der Betreiber, der eine Mitteilung empfängt, die Übereinstimmung der Mitteilung mit den Regeln für sich selbst, den Sender sowie den Empfänger der Mitteilung. Wenn diese Regeln eingehalten werden, übermittelt der Betreiber die Mitteilung; ansonsten unterbricht er die Übermittlung der Mitteilung und meldet dem Sender eventuell, dass seine Mitteilung die Bedingungen für eine Weiterleitung nicht erfüllt. Somit führt der Betreiber die Prüfung von Signaturen, Zertifikat, Format und Mitteilungsinhalt durch. Wenn diese Prüfungen zufrieden stellend ausfallen, kennzeichnet der Betreiber die Mitteilung, bevor er sie weiterleitet. Wenn der Empfänger die Mitteilung bekommt, braucht er lediglich die vom Betreiber vorgenommene Markierung zu prüfen, um zu sehen, ob die von ihm empfangene Mitteilung die Bedingungen erfüllt, die der Empfänger dem Betreiber vorgeschrieben hat. Damit beschränkt sich für den Teilnehmer und den Dienstleister die Prüfung einer Mitteilung auf den Test einer von einem Betreiber vorgenommenen Markierung.
Ziel der Erfindung ist also ein Verfahren zur abgesetzten Sicherung des Datenaustausches zwischen einem Teilnehmer an einen Telekommunikationsbetreiber und einem Dienstleister, der in einem von dem Betreiber verwalteten Telekommunikationsnetz agiert, dadurch gekennzeichnet, dass der Betreiber die folgenden Schritte vornimmt:

– Empfang einer Mitteilung,
– Identifizierung des Senders der Mitteilung,
– Identifizierung des Empfängers der Mitteilung,
– Festlegung von auf die Mitteilung anzuwendenden Regeln,
– Anwendung von Regeln auf die Mitteilung, um festzulegen, ob die Mitteilung weitergeleitet werden soll,
– Kennzeichnung der Mitteilung,
– Weiterleitung der gekennzeichneten und den Regeln entsprechenden Mitteilung an den Empfänger.

Die Erfindung wird beim Lesen der folgenden Beschreibung und bei der Untersuchung der sie begleitenden Abbildungen besser verständlich. Diese werden orientierungshalber dargestellt und sind für die Erfindung nicht erschöpfend. Die Abbildungen zeigen im Einzelnen:
1: eine Darstellung von für die Durchführung des erfindungsgemäßen Verfahrens nützlichen Mitteln;
2: eine Darstellung einzelner Schritte des erfindungsgemäßen Verfahrens.
In der folgenden Beschreibung ist die Rede von Betreiber, Teilnehmer und Dienstleister. Alle agieren in einem oder mehreren Netzen. Der Teilnehmer verwendet ein Mobilfunkgerät, um mit von dem Betreiber verwalteten Geräten zu kommunizieren. Der Dienstleister besitzt einen Server, über den er mit Geräten des Betreibers kommunizieren kann. In der Beschreibung geht es um Aktionen des Terminals, des Teilnehmers, des Betreibers und des Dienstleisters. Es versteht sich von selbst, dass diese Aktionen von Geräten durchgeführt werden, die diesen einzelnen Beteiligten entsprechen. Somit wird eine von dem Teilnehmer durchgeführte Aktion von seinem Terminal und dem darin enthaltenen Mikroprozessor durchgeführt. Dieser Mikroprozessor wird durch Befehlscodes gesteuert, die in einem Speicher des Terminals abgelegt sind. Das Gleiche gilt für die Server der Betreiber und Dienstleister. Jeder Server beinhaltet einen Mikroprozessor und einen Programmspeicher mit Befehlscodes zur Steuerung dieser Mikroprozessoren.
1 zeigt ein über eine Funkverbindung 103 an ein Telekommunikationsnetz 102 angeschlossenes Terminal 101. Zum Zweck der Beschreibung und bei einer bevorzugten Vorgehensweise wird davon ausgegangen, dass es sich bei dem Netz 102 um ein Funktelefonnetz handelt und Terminal 101 demnach ein Mobiltelefon ist. Netz 102 wird von einem Mobilfunkbetreiber über an dieses Netz 102 angeschlossene Server verwaltet. 1 zeigt einen solchen Server 104.
Terminal 101 beinhaltet eine Kommunikationsschnittstelle, über die es die Verbindung 103 mit dem Netz 102 herstellen kann. Diese Kommunikationsschnittstelle besteht aus einer Antenne 105 und mehreren Funkschnittstellenstromkreisen 106, die für die Transkodierung zwischen an der Antenne 105 vorhandenen Analogsignalen und im Terminal 101 vorhandenen Digitalsignalen sorgen. Nach klassischer Art enthält Terminal 101 einen Mikroprozessor 107, einen Programmspeicher 108 sowie Ein-/Ausgangsmittel 109. Diese Mittel 109 sind u.a. eine Tastatur und ein Bildschirm.
Terminal 101 enthält auch einen Datenspeicher 110. In diesem Speicher werden die von Terminal 101 empfangenen Daten abgelegt. In einem Speicher 111 von Terminal 101 kann die Konfiguration dieses Terminals abgelegt und vor allem die Vorgaben abgespeichert werden, nach denen sich Server 104 in Abhängigkeit von den von ihm empfangen Mitteilungen verhalten soll, wobei diese Mitteilungen für den Benutzer von Terminal 101 bestimmt sind.
Speicher 108 beinhaltet mehrere Zonen. Insbesondere beinhaltet Speicher 108 eine Zone 108a mit Befehlscodes zur Steuerung von Mikroprozessor 107, wenn Terminal 101 mit dem Server 104, d.h. Telefon 101 mit dem Betreiber kommuniziert. Terminal 101 beinhaltet eine Zone 108b, die einer Aktualisierung der Konfiguration des Teilnehmers an Server 104 entspricht.
Für Terminal 101 wie für die übrigen Geräte, deren Beschreibung folgt, werden einige Speicher beschrieben. Bei einem bestimmten Geräten kann die Gesamtheit dieser Speicher sehr wohl nur mehrere Zonen des ein und demselben Speichers darstellen. Die Darstellung der einzelnen Elemente vereinfacht das Verständnis.
Die Elemente 106 bis 111 sind über einen Bus 112 verbunden. Das Netz 102 und damit Terminal 101 arbeiten nach einer beliebigen bereits vorhandenen oder künftigen Mobilfunknorm, z.B. GSM, PCS, DCS, GPRS oder UMTS.
Server 104 des Betreibers enthält Stromkreise 113, mit denen eine Schnittstelle zwischen dem Netz 102 und dem Server 104 hergestellt werden kann. Server 104 beinhaltet einen Mikroprozessor 114 sowie einen Programmspeicher 115. Speicher 115 ist in mehrere Zonen untergliedert, die Befehlscodes für die Steuerung von Mikroprozessor 114 je nach den jeweiligen Umständen enthalten. Eine Zone 115a ermöglicht es dem Server 104, mit Terminal 101 zu kommunizieren, und eine Zone 115b, mit einem Dienstleister zu kommunizieren, der im Netz 102 des Betreibers agieren will. Eine Zone 115c ermöglicht es dem Server 104, die für die von Server 104 empfangenen Mitteilungen relevanten Regeln festzulegen und anzuwenden. Eine Zone 115d ermöglicht es dem Server 104, eine Tabelle 116 von Teilnehmern des Betreibers zu aktualisieren. Eine Zone 115e ermöglicht es dem Server 104, eine Tabelle 117 von Dienstleistern zu aktualisieren, die im Netz des Betreibers agieren. Eine Zone 115f ermöglicht es dem Server 104, die Kennzeichnung der weitergeleiteten Mitteilungen vorzunehmen.
Server 104 enthält auch eine Tabelle 117 von Dienstleistern. Terminal 104 beinhaltet auch Schnittstellenstromkreise 118 zwischen Server 104 und einem Telekommunikationsnetz 119, z.B. Internet. Die Elemente 113 bis 118 sowie 128 sind an einen Bus 120 angeschlossen.
Tabelle 116 und 117 sind tabellenförmig angelegte Speicher. Jede Zeile entspricht einer Information und jede Spalte einem Speichervorgang, d.h. einem Teilnehmer für Tabelle 116 bzw. einem Dienstleister für Tabelle 117. In Tabelle 116 können also Informationen über Teilnehmer des Betreibers und in Tabelle 117 Informationen über Dienstleister abgespeichert werden, die im Netz des Betreibers, der Server 104 verwaltet, agieren wollen.
Tabelle 117 enthält eine Zeile 117a, die einem Identifier des Dienstleister entspricht. Eine Zeile 117b entspricht einer Liste von Regeln, auf die sich der Betreiber, der Server 104 verwaltet, und der in Zeile 117a angegebene Dienstleister geeinigt haben. Eine Zeile 117c entspricht einer Liste von Kennzeichnen, auf die sich der Betreiber, der Server 104 verwaltet, und der in Zeile 117a angegebene Dienstleister geeinigt haben, wobei jede Kennzeichnung eine Bedeutung haben kann, z.B. Mitteilung zufrieden stellend oder nicht zufrieden stellend.
Tabelle 116 enthält eine Zeile 116a, in der ein Identifier des Teilnehmers gespeichert werden kann. Bei einem Mobilfunknetz kann der Identifier von Zeile 116a beispielsweise eine Telefonnummer oder die Nummer einer SIM-Karte sein. Tabelle 116 enthält auch eine Zeile 116b, die einer Liste von Regeln entspricht, die die Merkmale der Mitteilungen definieren, die der in Zeile 116a angegebene Teilnehmer empfangen kann oder will. Eine Zeile 116c entspricht einer schwarzen Liste. Jeder Teilnehmer hat die Möglichkeit, Dienstleister oder Sender von Mitteilungen zu bestimmen, von denen er keine Mitteilungen mehr bekommen möchte. Diese Liste wird in Zeile 116c in der Spalte abgespeichert, die dem Identifier des Teilnehmers entspricht. Diese schwarze Liste enthält z.B. Identifier wie etwa in Zeile 117a.
Der Server 104 enthält auch einen Speicher 128 für die schwarze Liste des Betreibers. Diese schwarze Liste 128 ist die des Betreibers. Die schwarze Liste 128 enthält beispielsweise die Liste der Dienstleister, d.h. eine Liste von Identifiern, die nicht befugt sind, im Netz des Betreibers zu agieren.
1 zeigt auch einen Server 121, der einem Gerät eines Dienstleisters entspricht, der im Netz 102 des Betreibers, der Server 104 verwaltet, agieren möchte. Zum Zweck der Beschreibung wird davon ausgegangen, dass der Dienstleister oder Server 121 Daten übermitteln will, die in einem Speicher 122 in Terminal 101 abgelegt sind. Server 121 enthält einen Mikroprozessor 123, einen Programmspeicher 124 und Schnittstellenstromkreise 125 mit dem Netz 119. Server 121 enthält auch optional einen Konfigurationsspeicher 127 für die Ausgabe der Regeln, die dem Dienstleister entsprechen, der Server 121 verwendet. Die Elemente 122 bis 126 sind über einen Bus 127 verbunden. Speicher 124 enthält eine Zone 124a, um die Kommunikationsfunktionen mit Server 104 des Betreibers durchzuführen. Speicher 124 enthält eine Zone 124b, um die Aktualisierungsfunktionen der Tabelle 117 in Abhängigkeit vom Inhalt des Konfigurationsspeichers 126 von Server 121 durchzuführen.
Sämtliche für 1 beschriebenen Elemente kommen also im erfindungsgemäßen Verfahren zum Einsatz. Einige Etappen dieses Verfahrens werden in 2 dargestellt.
2 zeigt eine Etappe 201, Empfang einer Mitteilung durch den Betreiber.
Es wird zunächst davon ausgegangen, dass es sich bei dem Sender um einen Dienstleister handelt, der eine Mitteilung an einen Teilnehmer im Netz des Betreibers schicken will. Diese Mitteilung wurde also von Server 121 unter Verwendung des in Zone 124a von Speicher 124 integrierten Kommunikationsprotokolls gesendet. Server 104 empfängt diese Mitteilung über das in Zone 115b von Speicher 115 integrierte Protokoll. Die Protokolle von Zone 115b und 124a sind identisch. Dabei kann es sich beispielsweise um ein Standard-Kommunikationsprotokoll über Internet handeln.
Darauf folgt eine Etappe 202, Identifizierung des Senders. Sämtliche heutzutage in jedem beliebigen Netz ausgetauschten Mitteilungen enthalten ein Feld, in dem ein Identifier des Senders gespeichert werden kann. Wenn es sich bei dem Sender um einen Dienstleister handelt, geht man beispielsweise davon aus, dass dieses Feld eine Adresse vom Typ Internet ist. Die Identifizierung des Senders besteht also darin, die Internet-Adresse des Senders in der in Etappe 201 empfangenen Mitteilung zu lesen. Nach Erfassung dieser Adresse geht es weiter zur Etappe 203, Prüfung anhand der schwarzen Liste.
In Etappe 203 durchläuft Server 104 den Speicher 128 auf der Suche nach dem in Etappe 202 festgelegten identifier. Ist dieser in der schwarzen Liste 128 aufgeführt, so geht es weiter zu einer abschließenden Etappe 215; die Mitteilung wird nicht weiter als bis zum Betreiber geleitet. In diesem Fall unterbricht Server 104 die Übertragung der in Etappe 201 empfangenen Mitteilung.
Falls der in Etappe 202 festgelegte Identifier nicht in der schwarzen Liste 128 aufgeführt ist, geht es weiter zur Etappe 204, Identifizierung des Empfängers. Es wird davon ausgegangen, dass der Betreiber, der den Server 104 verwaltet, ein Mobilfunkbetreiber ist. In diesem Fall ist ein Identifier des Empfängers beispielsweise eine Telefonnummer. Wenn es sich bei dem Betreiber um einen Internet-Provider gehandelt hätte, so hätte der Identifier des Empfängers ebenfalls eine Adresse vom Typ Internet sein können. Die Identifizierung des Empfängers besteht also darin, das Empfängerfeld in der in Etappe 201 empfangenen Mitteilung zu lesen. Sobald der Identifier des Empfängers festgelegt ist, kann geprüft werden, ob die in Etappe 201 empfangene Mitteilung sämtliche Bedingungen erfüllt, um zu dem von dem durch in Etappe 203 festgelegten Identifier identifizierten Terminal weitergeleitet zu werden.
Anschließend geht es von Etappe 204 zu Etappe 205, Festlegung, ob eine Signatur vorhanden ist. Wenn die in Etappe 201 empfangene Mitteilung eine Signatur enthält, geht es weiter zur Etappe 206, Prüfung der Signatur; ansonsten geht es weiter zu Etappe 207, Festlegung, ob ein Zertifikat in der Mitteilung vorhanden ist.
Falls die Mitteilung eine Signatur beinhaltet, kann es sich beispielsweise um eine elektronische Signatur nach den französischen und europäischen Richtlinien handeln. Eine solche Signatur wird auf bekannte Weise erstellt und geprüft. Am bekanntesten ist der in den PKI-Technologien beschriebene Mechanismus (Public Key Infrastructure, d.h. öffentlicher Schlüssel für die Verschlüsselung einer Nachricht). In Etappe 206 kann jedoch jede beliebige andere Signatur-Technologie zur Anwendung kommen, auf die sich Sender und Betreiber einigen. Falls die Signatur gültig ist, geht es weiter zu Etappe 208, Löschen der Signatur; ansonsten geht es weiter zu Etappe 215.
Etappe 208 ist fakultativ. In dieser Etappe ändert der Betreiber die empfangene Mitteilung, um die vom Sender aufgebrachte Signatur zu löschen. Wenn diese Signatur bereits vom Betreiber geprüft wurde, braucht sie nicht mit weitergeleitet zu werden. Dadurch wird Bandbreite gespart. Jedoch kann es aus rechtlichen Gründen wünschenswert sein, die Signatur zu übermitteln. Von Etappe 208 geht es anschließend weiter zu Etappe 207. Weil Etappe 208 fakultativ ist, geht es von Etappe 206 weiter zu Etappe 207, wenn die Signatur korrekt ist.
Wenn in Etappe 207 die in Etappe 201 empfangene Mitteilung ein Zertifikat beinhaltet, geht es weiter zu Etappe 209, Prüfung des Zertifikats. In Etappe 209 liest der Betreiber das in Mitteilung 201 enthaltene Zertifikat und loggt sich in einen Server der Zertifikationsstelle ein, die das Zertifikat ausgestellt hat. Dabei handelt es sich um einen Zertifizierungsserver, auf den beispielsweise im Internet zugegriffen werden kann. Dieser Zertifizierungsserver teilt dem Betreiber mit, ob das Zertifikat abgelehnt wird oder nicht. Wird das Zertifikat nicht abgelehnt, d.h. wenn es gültig ist, geht es weiter zu Etappe 210, Löschen des Zertifikats. Ansonsten geht es weiter zu Etappe 215.
Wie Etappe 208 ist auch Etappe 210 fakultativ. Dadurch, dass das Zertifikat der in Etappe 201 empfangenen Mitteilung gelöscht wird, kann bei der Weiterleitung Bandbreite gespart werden, d.h. es werden weniger Informationen übermittelt und damit die Übermittlungszeit und der Speicherplatz für die Mitteilungen optimiert. Von Etappe 210 geht es weiter zu Etappe 211. Kommt Etappe 210 nicht zur Anwendung, und für den Fall, dass das Zertifikat gültig ist, geht es von Etappe 209 weiter zu Etappe 211. Falls das Zertifikat nicht gültig ist, geht es in allen Fällen von Etappe 209 weiter zu Etappe 215.
Der Betreiber kann feststellen, ob eine Mitteilung eine Signatur und/oder ein Zertifikat enthält, denn er hat sich im Vorfeld mit dem Dienstleister über das verwendete Kommunikationsprotokoll geeinigt. Ein Kommunikationsprotokoll definiert eine Struktur für die nach diesem Protokoll ausgetauschten Mitteilungen. Diese Struktur wiederum definiert Felder für die Signatur und die Zertifikate. Die Tatsache, dass diese Felder ausgefüllt sind oder nicht, weist also darauf hin, ob eine Signatur und/oder ein Zertifikat vorhanden ist oder nicht.
In Etappe 211 durchläuft der Betreiber den Speicher 117 der Dienstleister und insbesondere Zeile 117a, um den in Etappe 202 festgelegten Identifier zu finden. Dabei kann er eine erste Liste 117b mit den Regeln finden, die auf die in Etappe 201 empfangene Mitteilung anzuwenden sind.
Diese Regeln sind für jeden Dienstleister, der im Netz 102 des Betreibers agieren möchte, spezifisch. Sie betreffen beispielsweise die Art oder Größe der Mitteilung, die Anzahl von Mitteilungen, die ein Dienstleister während einer bestimmten Zeitspanne übermitteln kann usw. Die Größe der Mitteilung ist einfach festzulegen, ihre Art kann in einem Feld der in Etappe 201 empfangenen Mitteilung kodiert sein. Meist ermöglichen es die Mitteilungen, Dateien zu übermitteln. Es ist also einfach, die Art einer Datei festzulegen. Die bekanntesten Dateien sind beispielsweise die ausführbaren Dateien, die HTML-Dateien, die Textdateien usw.
Sämtliche Regeln in Zeile 117b werden zwischen dem Bediener und dem in Spalte 117a angegebenen Dienstleister ausgehandelt. Wenn die in Etappe 201 empfangene Mitteilung für den Sender sämtliche Regeln in Zeile 117b erfüllt, wechselt der Betreiber zu den Regeln des Empfängers der Mitteilung über.
Dazu sucht der Betreiber in Zeile 116a den in Etappe 204 festgelegten Identifier. Sobald er ihn gefunden hat, liest er die Zeile 116c, die diesem Identifier entspricht. Zeile 116c ist eine schwarze Liste des Betreibers. Die Funktionsweise ist die gleiche wie für den Speicher 128 in Etappe 203. Damit eine Mitteilung gültig ist, darf der in Etappe 202 festgelegte Identifier nicht in der schwarzen Liste des Teilnehmers aufgeführt sein, für den die Mitteilung bestimmt ist.
Die Regeln in Zeile 116b sind die gleichen wie die von einem Dienstleister definierten Regeln, außer, dass sie dem Teilnehmer eigen sind. Ein Teilnehmer kann den Wunsch äußern, dass keine Mitteilung ab einer bestimmten Größe oder keine Mitteilung, die eine ausführbare Datei enthält, gleich aus welcher Quelle sie stammt, an sein Terminal weitergeleitet wird. Die in Etappe 201 empfangene Mitteilung muss also mit den vom Teilnehmer definierten Regeln abgeglichen werden. Man bestimmt die Regeln der Zeile 116b, die auf die in Etappe 201 empfangenen Mitteilung anwendbar sind, auf die gleiche Weise wie für Zeile 116c, d.h. über den in Etappe 204 festgelegten Identifier, mit dem eine Spalte in Tabelle 116 identifiziert werden kann.
Die Anwendung dieser Regeln stellt die Etappe 212 dar. Wenn die in Etappe 201 empfangene Mitteilung die Prüfung anhand dieser Regeln nicht besteht, geht es weiter zu Etappe 215. Ansonsten geht es weiter zu Etappe 213, Weiterleitung der Mitteilung.
In Etappe 213 verwendet der Betreiber das in Zone 115a und 108a integrierte Protokoll, um die in Etappe 201 empfangene Mitteilung an ihren Empfänger, d.h. einen Teilnehmer in seinem Netz, weiterzuleiten. Meist sind die Protokolle, die für die Kommunikation zwischen Betreiber und Teilnehmer verwendet werden, nicht identisch. Deshalb konvertiert der Betreiber das Protokoll. Etappe 213 besteht also darin, den Inhalt der in Etappe 201 empfangenen Mitteilung ohne Anwendung von Etappe 208 und 210 zu übernehmen und diesen Inhalt in ein mit dem vom Betreiber für die Kommunikation mit dem Empfänger verwendeten Protokoll kompatiblen Raster abzulegen. So kann beispielsweise der Inhalt über Kurzmitteilungen (SMS) oder das WAP-Protokoll (Wireless Application Protocol oder drahtloses Anwendungsprotokoll) gesendet werden. In Etappe 213 ändert der Betreiber die Mitteilung, bevor er sie weiterleitet, indem er eine Kennzeichnung einfügt. Diese Kennzeichnung wird in ein spezifisches Feld der weitergeleiteten Mitteilung eingefügt. Danach geht es weiter zu Etappe 214, Empfang der Mitteilung durch den Empfänger.
In Etappe 214 empfängt der Teilnehmer, für den die Mitteilung bestimmt ist, eine Mitteilung. Als erstes sucht das Terminal 101 des Teilnehmers, sobald es die weitergeleitete Mitteilung empfängt, nach der Kennzeichnung des Betreibers. Ist diese Kennzeichnung vorhanden, weiß es, dass es dem Inhalt der Mitteilung blind vertrauen und sämtliche Aktionen im Zusammenhang mit Art und Inhalt der Mitteilung, die es soeben empfangen hat, durchführen kann. Beispielsweise enthält die Mitteilung einen aktiven Inhalt, deren Auslegung die Aktualisierung einer Termin-Datenbank von Terminal 101 verursacht. Da die Mitteilung gekennzeichnet ist, erfolgt diese Aktualisierung ohne Kontrolle seitens des Benutzers von Terminal 101. Ist die vom Teilnehmer empfangene Mitteilung nicht entsprechend gekennzeichnet, entscheidet dieser selbst, ob er die Mitteilung annimmt oder ablehnt. Das bedeutet, dass der Teilnehmer, der Terminal 101 benutzt, explizit und von Fall zu Fall selbst über die Behandlung solcher Mitteilungen entscheidet.
Als Variante der Erfindung verursacht das Scheitern in Etappe 206, 209 und 212 keine Unterbrechung der Übermittlung der in Etappe 201 empfangenen Mitteilung, sondern die Nichtkennzeichnung der Mitteilung oder die Anwendung einer Kennzeichnung, die bedeutet, dass die Mitteilung die Bedingungen für die Weiterleitung nicht erfüllt. In diesem Fall empfängt der Endempfänger die weitergeleitete Mitteilung, die entweder gar nicht gekennzeichnet ist oder deren Kennzeichnung besagt, dass die Mitteilung die Vorgaben der Regeln nicht erfüllt. Das Terminal – oder der Server – des Empfängers kann in diesem Fall der Mitteilung nicht trauen, nimmt seine eigenen Prüfungen vor und fordert eventuell die Mitwirkung des Teilnehmers oder Dienstleisters an, bevor der Inhalt der Mitteilung zur Durchführung gebracht oder gespeichert wird.
Mit den Befehlscodes in Zone 108b kann der Teilnehmer die ihn betreffende Spalte von Speicher 116 aktualisieren. Dazu verwendet er die Elemente 109, um den Inhalt des Konfigurationsspeichers 111 auszugeben. Nach der Ausgabe wird diese Konfiguration an den Betreiber weitergeleitet, um den Inhalt der den Teilnehmer entsprechenden Spalte von Speicher 116 zu ersetzen. Als Variante wird die Konfiguration des Teilnehmers auf Server 104 gespeichert. In diesem Fall muss der Teilnehmer vor der Ausgabe den Inhalt seiner Konfiguration des Servers 104 an den Speicher 111 weiterleiten und anschließend den Speicher 116 ausgeben und aktualisieren.
Die Aktualisierung der vom Betreiber und Dienstleister verwendeten Regeln und Kennzeichnungen erfolgt auf die gleiche Weise wie für den Teilnehmer, außer, dass der Konfigurationsspeicher der Speicher 127 von Server 121 ist. Im Falle eine Dienstleisters kann diese Aktualisierung auch per Post erfolgen. Das bedeutet, dass der Dienstleister dem Betreiber ein Schreiben sendet, in dem steht, welche Änderungen er an seinen Regeln vornehmen möchte, und dass der Betreiber seinen Server entsprechend aktualisiert.
Falls der Sender der Mitteilung ein Teilnehmer ist, z.B. beim Verkauf über einen Fernseh-Shop, erhält der Dienstleister eine vom Betreiber gekennzeichnete Meldung mit der Bestellung. Diese Kennzeichnung bedeutet, dass die vom Betreiber vorgenommenen Prüfungen entweder positiv oder negativ ausgefallen sind. Wenn sie positiv ausgefallen sind, weiß der Dienstleister, dass er die Bestellung unbesorgt annehmen kann, weil der Betreiber als Garant fungiert. Ansonsten kann er entweder die Bestellung ablehnen oder seine eigenen Prüfungen vornehmen, bevor er entscheidet, ob er die Bestellung annimmt. Der Prozess ist als symmetrisch, ganz gleich, ob die Mitteilung von einem Dienstleister an einen Teilnehmer oder von einem Teilnehmer an einen Dienstleister gesendet wird. Jedoch tendiert der Betreiber dazu, die Signatur bei einer von einem Teilnehmer an einen Dienstleister gesendeten Meldung nicht zu löschen, denn ein Dienstleister kann es vorziehen, die Signaturen aus rechtlichen Gründen für den Fall einer eventuellen Anfechtung des Teilnehmers bezüglich des Objekts seiner Mitteilung beizubehalten.
Wenn der Dienstleister der Sender oder Empfänger einer Mitteilung ist, kann es als Variante wünschenswert sein, die anwendbaren Regeln von Fall zu Fall unterschiedlich zu behandeln. So enthalten bei dieser Variante die Regeln in Zeile 117b jeweils ein zusätzliches Feld, das ihrer Relevanz bezüglich der Situation des Dienstleisters entspricht. Damit kann in Etappe 211, je nach dem, ob der Dienstleister der Sender oder Empfänger ist, entschieden werden, welche der dem Dienstleister entsprechenden Regeln anwendbar sind. Diese Bemerkung zu den Regeln gilt auch für die Regeln der Teilnehmer, die ebenfalls entweder der Sender oder Empfänger sein können.
Das beschriebene Verfahren kann in jedem Netz, in dem ein Betreiber, Teilnehmer und Dienstleister agiert, zur Anwendung kommen. Die Funktelefonnetze gehören ebenso zu diesen Netzen wie das Internet für Privatpersonen. In der Tat muss jeder, der sich in das Internet einloggen will, dies über einen Internet-Provider tun. Die Server des Internet-Providers können in diesem Falle das Verfahren nutzen. Damit kann die Konfiguration der von den Teilnehmern verwendeten Terminals vereinfacht werden, und dadurch kann es den Benutzer der Terminals auch erspart bleiben, sich Fragen über die Mitteilungen zu stellen, die auf den Terminals angezeigt werden, wenn der Betreiber nicht für die Sicherung der eingehenden Mitteilungen sorgt.
Aus Gründen der Übersichtlichkeit werden die Regeln in den beiden Tabellen 116 und 117 dargestellt. In der Praxis könnten sämtliche Regeln in der gleichen Tabelle aufgeführt werden, wobei in Etappe 211 die auf eine vom Betreiber empfangene Mitteilung anwendbaren Regeln extrahiert werden. Eine Regel besitzt also mindestens die folgenden Merkmale: Identifier des Senders, Identifier des Empfängers und eine Bedingung bezüglich einer Eigenschaft der Mitteilung. Die Eigenschaft einer Mitteilung kann ihre Größe, ihre Art bezüglich ihres Inhalts oder ein binäres Feld sein, in dem jedes Bit eine Bedeutung hat. Beim Empfang einer Mitteilung werden also ihre Eigenschaften durch Messung oder Lesen eines Feldes „Eigenschaft der Mitteilung" festgelegt. Es ist also einfach, die relevanten Regeln festzulegen und anzuwenden.
Die vom Betreiber verwendeten Kennzeichnungen für die weitergeleiteten Mitteilungen sind nur den am Verfahren Beteiligten bekannt. Eine Kennzeichnung ist vorzugsweise ein binäres Wort, das eine Bedeutung für den Empfänger hat. Über diese Bedeutung wird gemeinsam mit dem Betreiber entschieden. Der Test des Wertes einer Kennzeichnung gibt also Aufschluss über die Gültigkeit einer Mitteilung. Die verwendeten Kennzeichnungen können sich je nach Zeitpunkt nach festen Vorgaben oder auf Initiative eines der am Verfahren Beteiligten ändern.

Claims

Verfahren zur abgesetzten Sicherung des Datenaustausches zwischen einem Teilnehmer an einen Telekommunikationsbetreiber und einem Dienstleister, der in einem von dem Betreiber verwalteten Telekommunikationsnetz agiert, dadurch gekennzeichnet, dass der Betreiber die folgenden Schritte vornimmt: – Empfang (201) einer Mitteilung, – Identifizierung (202) des Senders der Mitteilung, – Identifizierung (204) des Empfängers der Mitteilung, – Festlegung (211) von auf die Mitteilung anzuwendenden Regeln, – Anwendung (212) von Regeln auf die Mitteilung, um festzulegen, ob die Mitteilung weitergeleitet werden soll, – Kennzeichnung (213) der Mitteilung, – Weiterleitung (213) der gekennzeichneten und den Regeln entsprechenden Mitteilung an den Empfänger, – Prüfung (214) der Mitteilung durch den Empfänger, um die Mitteilung zu akzeptieren oder abzulehnen, durch einfache Prüfung des Vorhandenseins und der Gültigkeit der Kennzeichnung.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Mitteilung von ihrem Sender signiert wird, wobei die Gültigkeit der Signatur als zusätzliche Bedingung für ihre Weiterleitung vom Betreiber geprüft wird (206).
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Mitteilung von einem Zertifikat begleitet wird und der Betreiber die Gültigkeit des Zertifikats als zusätzliche Bedingung für ihre Weiterleitung prüft (209).
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Anwendung der Regeln die Gültigkeit des Nichterscheinens von Identifiern von Sendern auf einer vom Empfänger definierten schwarzen Liste beinhaltet (203).
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die schwarze Liste von dem Betreiber gespeichert wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Anwendung der Regeln die Prüfung der Größe der Mitteilung beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Anwendung der Regeln eine Prüfung der Art der Mitteilung beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Anwendung der Regeln die Kontrolle der Häufigkeit der Mitteilungen für einen Empfänger oder Sender beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Betreiber bei einer vom Sender signierten Mitteilung die Signatur des Senders der Mitteilung löscht (208).
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Betreiber bei einer Mitteilung mit Zertifikat das besagte Zertifikat löscht (210).