DE10237131A1

DE10237131A1 - Verfahren sowie Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten

Info

Publication number: DE10237131A1
Application number: DE10237131A
Authority: DE
Inventors: Andreas Schmidt; Markus Trauberg
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2002-08-13
Filing date: 2002-08-13
Publication date: 2004-02-26
Also published as: WO2004021663A1

Abstract

Zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten (PNU), die im Multimedia Messaging Service eines Kommunikationsnetzwerks (CN) von einem Push-Iniitiator (PI) über ein Push-Proxy-Gateway (PPG) an mindestens eine Kommunikationseinheit (UA) geschickt werden, wird im Push-Initiator (PI) und/oder im Push-Proxy-Gateway (PPG) ein Teil der oder die gesamten jeweiligen Push-Nutzdaten (PNU) mit Hilfe eines asymmetrischen Kryptographieverfahrens signiert.

Description

In Kommunikationsnetzwerken, insbesondere Funkkommunikationssystemen, kann es in der Praxis dazu kommen, dass auf das Teilnehmergerät eines Benutzers Nachrichten bzw. Daten in für den Benutzer unkontrollierbarer Weise von einer Komponente des Netzwerks heruntergeladen werden. Selbst wenn eine Hinweisnachricht beim Teilnehmergerät des jeweiligen Benutzers eintrifft, dass Daten bzw. Nachrichten netzwerkseitig zum Abruf bereitgehalten werden, bleibt es für den Benutzer zu undurchsichtig, wer der Absender dieser Benachrichtigung und der Bereitsteller dieser Daten tatsächlich ist. Dadurch sind Fehlentscheidungen beim Herunterladen von Daten durch den jeweiligen Benutzer möglich und auch die Gefahr des Missbrauchs solcher Hinweisnachrichten gegeben.
Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie für den jeweiligen Benutzer eines Teilnehmergeräts eines Kommunikationsnetzwerks sichergestellt werden kann, dass netzwerkseitig bereitgestellte Push-Daten bzw. Push-Nachrichten aus einer für den jeweiligen Benutzer vertrauenswürdigen Datenquelle stammen. Diese Aufgabe wird mit Hilfe folgendem erfindungsgemäßen Verfahren gelöst:
Verfahren zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten in einem Kommunikationsnetzwerk, die ausgehend von mindestens einem Push-Initiator über mindestens ein Push-Proxy-Gateway an mindestens einen Push-Client ohne dessen vorherige Aufforderung geschickt werden, indem im Push-Initiator oder im Push-Proxy-Gateway ein Teil der oder die gesamten Push-Nutzdaten mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur versehen werden.
Durch die datenquellenspezifische Kennzeichnung der jeweiligen Push-Nachricht mit Hilfe eines asymmetrischen Kryptographieverfahrens im Push-Initiator und/oder Push-Proxy-Gateway ist weitgehend sichergestellt, dass an die Kommunikationseinheit des jeweiligen Benutzers selektiv nur solche Daten bzw. Nachrichten vermittelt werden, die aus einer dem Benutzer vertrauenswürdigen, bekannten Datenquelle stammen.
Die Erfindung betrifft weiterhin ein Kommunikationsnetzwerk mit mindestens einer Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nachrichten nach dem erfindungsgemäßen Verfahren.
Die Erfindung und ihre Weiterbildungen werden nachfolgend anhand von Zeichnungen näher erläutert.
Es zeigen:
1 in schematischer Darstellung einen Pull-Modus bei der Übertragung von Daten zwischen einem Server und einem Client,
2 in schematischer Darstellung einen Push-Modus bei der Übertragung von Daten zwischen einem Server und einem Push–Client,
3 eine Push-Architektur gemäß WAP (Wireless Application Protocol), bei der Push-Nachrichten von einer Absendeeinheit (= Push Initiator PI) über ein Push-Proxy-Gateway) an eine Nachrichtenempfangseinheit (= Push-Client PC) übertragen werden,
4 in schematischer Darstellung die Funktionalität des Push-Proxy-Gateways nach 3 im Detail,
5 schematisch in vereinfachter Darstellung eine MMS-Architektur (MMS = Multimedia Messaging Service) nach 3GPP, die zur Durchführung des erfindungsgemäßen Verfahrens modifiziert ist,
6 eine beispielhafte Push-Nachricht "MMS Notification" in textueller Kodierung zur Benachrichtigung einer Kommunikationseinheit in einem Kommunikationsnetzwerk über das netzwerkseitige Vorliegen von abrufbaren Daten bzw. Nachrichten, insbesondere Multimediadaten, und
7, 8 verschiedene Beispiele für die Push-Nachricht "MMS Notification" in textueller Kodierung nach 6 mit einer digitalen Signatur zur erfindungsgemäßen datenquellenspezifischen Kennzeichnung.
Elemente mit gleicher Funktion und Wirkungsweise sind in den 1 mit 8 jeweils mit denselben Bezugszeichen versehen.
1 veranschaulicht schematisch die Übertragung von Daten DA zwischen einem Server SV und einem Client CL im sogenannten Pull-Modus, bei dem diese Empfangseinheit CL ein Anforderungssignals AF an den Server SV richtet. Erst aufgrund dieses Anforderungssignals AF hin werden die Daten bzw. Nachrichten vom Server SV an die Empfangseinheit CL heruntergezogen bzw. übermittelt (englisch pull = ziehen). Diese Pull-Funktion ist in der 1 mit PLM bezeichnet. Im Unterschied dazu werden die Daten bzw. Nachrichten DA im sogenannten Push-Modus vom Server SV ungefragt, d.h. ohne netzwerkseitiges Anforderungssignal, an die Empfangseinheit PC übermittelt, d.h. sozusagen direkt bzw. unvermittelt weitergeschoben (englisch push = schieben, stoßen). Dieser Push-Modus ist in der 2 mit PSM bezeichnet. Auf diese Weise gehen die Pull-Transaktionen immer vom jeweiligen Client aus, wäh rend die Push-Transaktionen von Daten immer vom jeweiligen Server initiiert werden. Das Browsen im World Wide Web ist ein typisches Beispiel für die Pull-Technologie. Dort entspricht die Eingabe einer URL (URL = Uniform Resource Locator, was der Adresse eines Speicherplatzes oder einem Hinweis darauf entspricht) in den Browser dem oben erwähnten Anforderungssignal. Derartige Server-/Client-Konstellationen sind in vorteilhafter Weise Bestandteil gängiger Kommunikationsnetzwerke, insbesondere Funkkommunikationssysteme.
In den Spezifikationen WAP-250, Push Architectural Overview, Version 03-Ju1y-2001, WAP-247, Push Access Protocol, Version 29-April-2001 sowie WAP-235, Push Over The Air Protocol, Version 25-April-2001 des WAP-Forums (WAP = Wireless Access Protocol) ist das Push-Verfahren für die Übertragung von Daten zwischen einem Server und einem Client definiert, der sich auf einem mobilen Endgerät, insbesondere Funkkommunikationsgerät, befindet. In der Terminologie des WAP-Forums wird der jeweilige Server, d.h. allgemein betrachtet diejenige Netzwerkkomponente, die zu übertragende Nutzdaten und eventuell zusätzliche Steuerbefehle (z.B. über die Art der Zustellung der Nutzdaten im Push-Modus) bereitstellt, als sogenannter Push-Initiator bezeichnet. Er schickt die Nutzdaten (gegebenenfalls inklusive der zusätzlichen Steuerbefehle) an mindestens ein Push-Proxy-Gateway, das die von ihm abgesandten Nutzdaten übertragungstechnisch an die unterschiedlichen Protokolle der tieferen Protokollschichten der jeweilig empfangenden Kommunikationseinheit anpasst. Mit anderen Worten heißt das, dass ein solches Gateway eine Schnittstellenfunktion für die Übertragungsverbindung zwischen dem jeweiligen Server und dessen zugeordneten, Push-Nachrichten empfangenden Empfangseinheiten übernimmt. Weiterhin wertet ein solches Push-Proxy-Gateway gegebenenfalls auch etwaig vorhandene Steuerbefehle für die Zustellung der Nutzdaten im Push-Modus aus und kontrolliert die korrekte Ausführung der Nutzdatenübertragung zwischen dem Push-Proxy-Gateway und dem jeweilig zugeordneten Push-Client, d.h. der jeweiligen Empfangseinheit der versandten Push-Nachrichten bzw. Push-Daten. Diese Push-Funktionalität eines Push-Proxy-Gateways kann zweckmäßigerweise in ein herkömmliches, "normales" WAP-Gateway integriert sein. Alternativ dazu ist es aber auch möglich, zwei getrennte Funktionseinheiten, nämlich WAP-Gateway und Push-Proxy-Gateway, mit einer klaren Aufgabenteilung im jeweiligen Kommunikationsnetzwerk vorzusehen.
3 veranschaulicht in schematischer Darstellung eine Push-Architektur in WAP zur Verteilung von Push-Nachrichten in einem Funkkommunikationsnetzwerk. Ein Push-Initiator PI schickt dabei Push-Nachrichten PNA, die neben Push-Nutzdaten PNU Steuerinformationen enthalten, über mindestens einen Übertragungspfad UP1 an ein zugeordnetes Push-Proxy-Gateway PPG, das die weitere Zustellung der Push-Nutzdaten PNU im Push-Modus über mindestens einen Übertragungspfad UP2 an einen Push-Client PC ausführt und überwacht. An das Push-Proxy-Gateway PPG können dabei eine Vielzahl von Push-Clients angeschlossen sein. Diese sind der zeichnerischen Einfachheit halber in der 3 weggelassen worden. Zwischen dem Push-Initiator PI und dem Push-Proxy-Gateway PPG wird bei der Übertragung der Push-Nachrichten PNA das sogenannte WAP PAP-Protokoll (PAP = Push Access Protocol) verwendet. Es setzt auf bekannte Standard-Internet-Protokolle wie beispielsweise HTTP (HTTP = Hypertext Transfer Protocol) auf. Ausführliche Angaben zum WAP PAP-Protokoll sind insbesondere in der Spezifikation WAP-247, Push Access Protocol, Version 29-April-2001 gemacht. Einzelheiten zum HTTP-Protokoll finden sich beispielsweise in der Spezifikation RFC 2616, Hypertext Transfer Protocol – HTTP/1.1; June 1999. Etwaig mit den Push-Nachrichten assoziierte zusätzliche Steuerbefehle werden vorzugsweise in der XML-Syntax (XML = Extensible Markup Language) ausgedrückt. Das Push-Proxy-Gateway PPG überträgt die Push-Nutzdaten PNU unter Berücksichtigung dieser Steuerbefehle des Push-Initiators PI an die Kommunikationseinheit bzw. den Client PC im Teilnehmergerät des jeweiligen Empfängers. Zwischen dem Push-Proxy-Gateway PPG und dem Push-Client-PC wird insbesondere das WAP-Push OTA Protocol (OTA = Over The Air) eingesetzt. Nähere Einzelheiten dazu sind in der Spezifikation WAP-235, Push Over The Air Protocol, Version 25-April-2001 angegeben.
In der 3 ist die Schnittstelle in der Übertragungsverbindung UPl zwischen dem Push-Initiator PI und dem Push-Proxy-Gateway PPG, die auf dem WAP PAP-Protokoll basiert, mit SB bezeichnet. Die Schnittstelle zur Übertragung der Push-Nutzdaten PNU zwischen dem Push-Proxy-Gateway PPG und dem Push-Client PC unter Zuhilfenahme des Push-OTA-Protokolls OTAP ist in der 3 mit dem Bezugszeichen SA angedeutet. In einem Funkkommunikationsnetzwerk wie z.B, nach dem UMTS-Standard umfasst die Schnittstelle SA insbesondere auch mindestens eine Luftschnittstelle zwischen einer Push-Nutzdaten absendenden Basisstation und ein oder mehreren Funkkommunikationsgeräten in deren Funkzelle.
4 veranschaulicht schematisch, wie Push-Nutzdaten PNU durch ein WAP-Gateway WRPG mit integrierter Push-Proxy-Gateway-Funktionalität an die tieferen Protokollschichten der beiden Schnittstellen SA sowie SB von 3, nämlich im einzelnen an das WAP OTA-Protokoll OTAP für die Schnittstelle SA und das WAP Push-Access-Protocol PAP für die Schnittstelle SB, zur Formatanpassung übergeben werden. In der 4 ist dabei der Push-Initiator PI als Absendekommunikationseinheit des Servers SV vorgesehen. Der Push-Client PC ist als empfangende Kommunikationseinheit vorzugsweise Bestandteil eines Funkkommunikationsgerätes, insbesondere eines mobilen Endgerätes UE wie z.B. Mobilfunktelefon. Der Push-Initiator PI des Servers SV macht die zu versendenden Push-Nachrichten PNA konform zum WAP PAP-Protokoll PAP, indem er diese an seine unteren Übertragungs-Protokollschichten LLB übergibt. Die über die Schnittstelle SB derart modifiziert übertragenen Push-Nachrichten PNA werden von den unteren Schichten LLB des WAP-PAP-Protokolls im WAP-Gateway WAPG ausgewertet und mit Hilfe des Gateways WRPG an die unteren Schichten LLA des WAP- OTA-Protokolls OTAP an dessen Format angepasst. Auf diese Weise kann der Push-Client PC im Teilnehmergerät UE mit Hilfe der unteren Protokollschichten LLA und seines WAP-OTA-Protokolls OTAP die empfangenen Push-Nutzdaten PNU einwandfrei empfangen und auswerten.
Für Mobilfunksysteme der nächsten Generationen (z.B. 2.5G und 3G), wie z.B. UMTS (UMTS = Universal Mobile Telecommunications System), wird zur Zeit eine multimediafähige Variante eines mobilen Nachrichtendienstes standardisiert, der sogenannte MMS-Service (MMS = Multimedia Messaging Service). Einzelheiten dazu sind detailliert in den Spezifikationen 3GPP T5 22.140 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Messaging Service (MMS); Service Aspects; Stage 1, sowie in 3GPP TS 23.140 version 5.3.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional Description; Stage 2 wiedergegeben. Nachrichten mit multimedialen Inhalten werden im Folgenden zur besseren Abgrenzung von den Textnachrichten des SMS (Short Message Service) nur noch kurz MMs (MM = Multimedia Message; MMs= Multimedia Messages (Plural)) genannt. Im Gegensatz zum SMS (SMS = Short Message Service) entfällt dabei die Beschränkung auf reine Textinhalte. Explizite Angaben zum SMS sind in der Spezifikation 3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical Realization of the Short Message Service (SMS) gemacht. Im Unterschied zum SMS ist es beim MMS in vorteilhafter Weise möglich, Texte entsprechend dem individuellen Geschmack des jeweiligen Benutzers zu formatieren, sowie Audio- und Videoinhalte in einer Nachricht einzubetten. Eine Multimedia Message (MM) kann demnach aus mehreren Multimedia-Elementen von unterschiedlichen Dateitypen (z.B. Audio- oder Standbild) und/oder Dateiformaten (bei Standbild z.8. GIF oder JPEG) zusammengesetzt sein.
In 5 ist die vereinfachte Netzwerkarchitektur nach 3GPP für den Multimedia Messaging Service schematisch dargestellt. Sie umfasst beispielhaft zwei Multimedia Messaging Service-Relay/Server RSA, RSB zweier verschiedener Multimedia Messaging Service Provider SPA, SPB. Der MMS-Relay/Server RSA übermittelt Push-Nutzdaten PNU an die Kommunikationseinheiten einer Vielzahl von Teilnehmergeräten, insbesondere Funkkommunikationsgeräten, des Kommunikationsnetzwerks CN, dessen übrige Komponenten in der 5 der Übersichtlichkeit halber weggelassen worden sind. In der 5 ist der zeichnerischen Einfachheit halber lediglich ein einzelnes Teilnehmergerät UA dieser Gruppe von Teilnehmergeräten eingezeichnet, das über eine Schnittstelle MM1 an den Relay/Server RSA angekoppelt ist. In entsprechender Weise sind ein oder mehrere Teilnehmergeräte UB, insbesondere Funkkommunikationsgeräte, dem zweiten MMS Relay/Server RSB des zweiten Providers bzw. Dienstanbieters SPB unter Zuhilfenahme der Schnittstelle MM1 zugeordnet. Die beiden Relay/Server RSA, RSB können über eine weitere Schnittstelle MM4 kommunizieren, wobei sie insbesondere im UMTS das sogenannte SMTP (Simple Mail Transfer Protocol) nutzen. Im jeweiligen Teilnehmergerät wie z.B. UA ist eine Kommunikationseinheit in Form eines sogenannten MMS User Agents implementiert, der die Push-Nutzdaten PNU vom MMS Relay/Server RSA empfangen und auswerten soll. Unter MMS User Agent wird dabei eine Ablaufprozedur verstanden, die den Multimedia Messaging Service realisiert. Dieser MMS User Agent kann dabei vorzugsweise auf einem Funkkommunikationsgerät, insbesondere Mobilfunkgerät, oder auf einem an ein Mobilfunkgerät angeschlossenen Zusatzgerät wie z.B. Laptop oder Ähnlichem vorgesehen sein. Ein MMS Relay/Server wie z.B. RSA ist ein Netzwerkelement, das im Zuständigkeitsbereich MMSE (MMSE = Multimedia Messaging Service Environment) des MMS Providers wie z.B. SPA den dortigen anwesenden MMS User Agents die MMS-Funktionalität zur Verfügung stellt.
Im Multimedia Messaging Service wird die Kommunikationseinheit bzw. der Push-Client des jeweiligen, Push-Nutzdaten PNU empfangenden Teilnehmergeräts wie z.B. UA in 5 zunächst vom zugeordneten MMS -Relay/Server wie z.B. RSA durch eine sogenannte Hinweis- oder Anfragenachricht "MMS Notification" über das Eintreffen einer neuen Multimedia Message auf dem MMS Relay/Server informiert, die dort zum Herunterladen (Download) bereit gehalten wird. Eine derartige "MMS Notification"-Nachricht enthält eine Referenz auf den Speicherplatz der Multimedia Message im Zuständigkeitsbereich des jeweiligen MMS Providers wie z.B. SPA, vorzugsweise in Form eines URI (URI = Uniform Resource Identifier). Mit Hilfe dieser Referenz kann die Multimedia Message daraufhin entweder sofort in Form eines sogenannten "immediate retrieval" oder auch zeitlich verzögert in Form eines sogenannten "deferred retrieval" auf das Endgerät wie z.B. UA in 5 heruntergeladen werden. In einer "MMS Notification"-Nachricht können viele ergänzende Informationen (wie z.B. Absender, Thema, usw.) zu einer Multimedia Message enthalten sein, die dem MMS User Agent des jeweiligen Empfängers als Entscheidungshilfe für den Download dienen können. Die Schnittstelle MM1 zwischen dem MMS Relay/Server RSA und dem MMS User Agent des Teilnehmergeräts UA in 5 wird insbesondere durch die WAP Spezifikationen WAP-205-MMS Architecture Overview; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-206-MMS Client Transaction; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 näher definiert.
Bei MMS-Teilnehmern mit mobilen Endgeräten werden die "MMS Notifications" dem jeweiligen Empfänger im Push-Modus nach dem WAP Push-Protokoll (vgl. Spezifikationen WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-Rpril-2001, WAP-235, Push Over The Air Protocol, Version 25-April-2001) zugestellt, d.h. zunächst werden die zu übertragenden Nutzdaten einer Hinweisnachricht "MMS Notification" vom jeweiligen MMS Relay/Server als Push-Initiator vorzugsweise kabelgebunden an das Push- Proxy-Gateway PPG übertragen. Dieses entscheidet nun seinerseits unter Berücksichtigung eventueller Vorgaben des MMS-Relay/Servers in Form der oben erwähnten Steuerbefehle über die Art der weiteren Zustellung der Hinweisnachricht "MMS Notification" über die Luftschnittstelle an den Push-Client auf dem mobilen Endgerät wie z.B. UA in 5. Die Schnittstelle MM1 in 5 entsprechend der 3GPP MMS Architektur beinhaltet dabei für die Push-Funktionalität die beiden Schnittstellen SA bzw. SB entsprechend den Push-Architekturen der 3, 4.
Eine einfache Möglichkeit, die Daten der jeweiligen Hinweisnachricht "MMS Notification" über das Vorliegen von Push-Nachrichten an die davon betroffenen Empfangs-Teilnehmergeräte zu übermitteln, besteht darin, dass die zu übermittelnden Daten der "MMS Notification"-Hinweisnachricht in einer Short Message oder mehreren Short Messages des Short Messaging Service (SMS) an das Endgerät des jeweiligen Empfängers gesendet werden. Mit anderen Worten heißt das: mindestens eine Short Message wird als Transportcontainer für die Zustellung einer "MMS Notification" verwendet. Eine nach WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 formatierte "MMS Notification"-Hinweisnachricht wird im Fall von MMS als Träger für die Push-Funktionalität mit UDH (User Data Headers)- und WSP (Wireless Session Protocol)- Kopf-Feldern versehen und in die jeweils 140 Bytes großen Transportcontainer des SMS (Skort Message Service) geschrieben. Eine Short Message (SM) ist insgesamt 160 Bytes lang, besitzt aber selbst einen Kopfteil von 20 Bytes, so dass pro Short Message nur 140 Bytes als "Payload", d.h. Laderaum für die im Push-Modus zu übertragenden Daten übrig bleiben.
Ohne Sicherheitsmaßnahmen wäre dadurch die Gefahr eines etwaigen Missbrauchs gegeben. Denn der jeweilige Empfänger einer mittels SMS empfangenen und korrekt formatierten "MMS Notification"-Hinweisnachricht kann nicht erkennen, ob es sich bei den empfangenen Daten tatsächlich um eine Benachrichtigung seines MMS- Providers über eine neu eingetroffene und zum Download bereitliegende Multimedia Message handelt. Die via SMS empfangenen Daten könnten aber auch lediglich ein korrekt formatierter Datensatz sein, mit dem eine "MMS Notification"-Hinweisnachricht vorgetäuscht werden soll, und der in Wirklichkeit von einem anderen Absender (Push-Initiator) als dem eigentlich erwarteten MMS -Relay/Server stammt. Dieser andere Absender könnte den URI (also die Referenz auf einen Speicherplatz, die eigentlich für den Download der Multimedia Message vorgesehen ist) in einer vorgetäuschten "MMS Notification"-Hinweisnachricht dazu benutzen, um den Download von unerwünschten Inhalten wie z.B. Werbung auf das mobile Endgerät des jeweiligen Kommunikationsnetzteilnehmers einzuleiten. Dieses sogenannte "Spamming" ist besonders im Fall von "immediate retrieval" im Multimedia Messaging Service (MMS) für den jeweiligen Empfänger ärgerlich, weil sein Endgerät in diesem Modus automatisch die Referenz in der "MMS Notification"-Hinweisnachricht auflöst und den Download-Prozess zum Herunterladen der Multimedia Message vom zugeordneten MMS -Relay/Server selbständig, d.h. ohne Benutzerabfrage einleitet.
Um nun für die jeweiligen Benutzer eines Teilnehmergerätes eines Kommunikationsnetzwerkes sicherzustellen, dass netzwerkseitig bereitgestellte Daten bzw. Nachrichten aus einer für den jeweiligen Benutzer vertrauenswürdigen Datenquelle stammen, wird eine datenquellenspezifische Kennzeichnung von Push-Nutzdatendadurch vorgenommen, dass diese Push-Nutzdatenim Multimedia Messaging -Relay/Server oder im Push-Proxy-Gateway teilweise oder ganz mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur versehen werden. Auf diese Weise werden bei jedem Versenden einer Push-Nachricht deren Push-Nutzdaten mit einer eindeutigen Kennung versehen, die eine Authentifizierung des versendenden Relay/Servers erlaubt. "MMS Notification"-Hinweisnachrichten auf bereitgestellte Inhalte anderer Provi der können somit bereits vorab im jeweiligen MMS User Agent erkannt und ignoriert werden, was einem Herausfiltern bzw. einer Aussortierung unerwünschter Daten entspricht. Ein Herunterladen unerwünschter Inhalte vom jeweiligen Server wird dadurch weitgehend vermieden.
Mit anderen Worten heißt das, dass die Überprüfung des Absenders einer Push-Nachricht durch Verifizierung einer digitalen Signatur vorgenommen wird. Dazu signiert der Multimedia Messaging -Relay/Server und/oder auch das nachgeschaltete Push-Proxy-Gateway mit einem privaten kryptographischen Schlüssel

a) einen Teil der Push-Nutzdaten (bei MMS z.B. die Referenz auf den Speicherplatz, wo die Daten der Push-Nutzdaten abgelegt sind) der jeweilig versandten oder der zu versendenden Push-Nachricht, oder
b) den gesamten Satz von Push-Nutzdaten (bei MMS z.B. die komplette "MMS Notification"-Hinweisnachricht) der jeweilig versandten oder der zu versendenden Push-Nachricht.

Die dabei erzeugte Signatur, insbesondere in Form eines sogenannten Hash-Wertes, wird dabei vom Relay/Server und/oder dem Push-Proxy-Gateway an das Endgerät des jeweiligen Empfängers im Push-Modus

a) entweder (z.B. in einem neuen Kopffeld) innerhalb der Push-Nutzdaten übertragen (z.B. innerhalb einer "MMS Notification"-Hinweisnachricht), oder
b) zusätzlich zu den signierten "Push-Nutzdaten" in einem neuen UDH- oder WSP-Kopffeld an das Endgerät des jeweiligen Empfängers im Push-Modus übertragen.

Im Endgerät wird selbst dann der öffentliche, kryptographische Schlüssel des asymmetrischen Kryptographieverfahrens des MMS – Providers zur Verifizierung der in oder mit den Push- Nutzdaten mitgelieferten Signatur benutzt. Auf diese Weise kann im Telekommunikationsendgerät eines Empfängers überprüft werden, ob die im Push-Modus empfangenen Daten tatsächlich von seinem eigenen MMS -Provider stammen, d.h. das Endgerät hat nunmehr praktisch eine verlässliche Herkunftsfilterfunktionalität. Somit wird besonders für den Fall des "immediate retrieval" des jeweiligen Teilnehmergeräts, insbesondere Funkkommunikationsgeräts, verhindert, dass unerwünschte Inhalte unter Benutzung nicht vertrauenswürdiger URLs automatisch (d.h. ohne Abfrage des Benutzers) auf das jeweilige Endgerät geladen werden.
Zur verlässlichen, empfangsseitigen Überprüfung von Push-Nutzdaten, insbesondere zur Überprüfung von im Push-Modus eintreffenden "MMS Notification"-Hinweisnachrichten, werden also die Mechanismen der asymmetrischen Kryptographie im Multimedia Messaging -Relay/Server und/oder Push-Proxy-Gateway eingesetzt, um die im Push-Modus zu übermittelnden Nutzdaten teilweise oder ganz zu signieren. Die Signatur der jeweiligen Push-Nutzdaten/Push-Nachricht wird dabei wahlweise im Push-Initiator des Multimedia Messaging Relay/Servers oder in dessen zugeordnetem Push-Proxy-Gateway mit einem privaten Schlüssel des Service Providers bzw. Netzwerkbetreibers durchgeführt, während die Verifizierung der Signatur im jeweiligen Telekommunikationsendgerät mit dem passenden öffentlichen Schlüssel des Service Providers bzw. Netzwerkbetreibers erfolgt. Dieser öffentliche Schlüssel kann entweder in einem internen Speicherbereich des jeweiligen Endgerätes oder in einer externen Speichereinheit abgelegt sein, die mit dem Endgerät über Kabel oder drahtlos verbunden werden kann.
In vorteilhafter Weise lässt sich das Speichern des öffentlichen kryptographischen Schlüssels auf einer intelligenten Speicherkarte, insbesondere einer sogenannten Smartcard wie z.B, einer SIM-Karte (SIM = Subscriber Identity Module) oder einer UICC (UICC = Universal Integrated Circuit Card) mit (U)SIM ((UMTS) subscriber identity module) als externer Spei chereinheit vornehmen, die in das mobile Endgerät eingelegt oder eingesteckt wird. Auf diesen Karten gibt es nämlich Speicherbereiche, die ausschließlich vom Netzwerkbetreiber beschrieben bzw, aktualisiert werden können, und solche, für die auch der Benutzer Schreib- und Leserechte hat. Die erstgenannten Speicherbereiche, die ausschließlich dem jeweiligen Netzbetreiber reserviert sind, eignen sich besonders gut für das Speichern und nachträgliche OTA-Aktualisieren (OTA = Over The Air) von öffentlichen kryptographischen Schlüsseln. Beispielsweise kann der Service Provider bzw. Netzbetreiber auf diese Weise die Schlüssellänge in einfacher Weise erhöhen, um neuen Sicherheitsanforderungen entsprechen zu können. Gemäß einer zweckmäßigen Ausführungsvariante wird eine bereits bestehende Applikation auf der SIM-Karte wie z.B. die SAT-Applikation (SAT = SIM Application Tool Kit) oder auf der UICC mit (U)SIM-Karte wie z.B. CAT (Card Application Tool Kit) bzw. (U)SAT-Applikation ((U)SAT = UMTS SIM Application Tool Kit) zur Verifizierung der Signatur der Push-Nutzdaten benutzt.
6 zeigt beispielhaft eine "MMS Notification"-Hinweisnachricht in textueller Kodierung im MMS. In der dazugehörigen binären Kodierung nach WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 erhält man einen Datenblock von etwa 100 Bytes. Wird diese "MMS Notification"-Hinweisnachricht als Push-Nutzdaten via SMS an einen Empfänger übermittelt, so werden diesem Datenblock noch einige WSP- und UDH-Kopf-Felder von insgesamt etwa 35 Bytes Länge vorangestellt. Die gesamte zu übertragende Datenmenge summiert sich somit in diesem Beispiel auf etwa 135 Bytes, was noch nicht zuviel Payload für eine einzelne Short Message wäre. Bei größeren Datenmengen, insbesondere von mehr als 140 Bytes, werden zweckmäßigerweise mehrere Short Messages entsprechend der Spezifikation 3GPP TS 23.040 version 5.2.0, Release 5; Third Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS) zur Übertragung der "MMS Notification"-Hinweisnachricht miteinander verkettet.
Die datenquellenspezifische Kennzeichnung der "MMS Notification"-Hinweisnachricht im MMS, die zum Herunterladen abholbereiter Push-Nachrichten vom MMS Relay/Server an ein oder mehrere adressierte Kommunikationseinheiten von Teilnehmergeräten geschickt wird, kann zweckmäßigerweise auf folgende vier verschiedene Möglichkeiten vorgenommen werden:
Ausführungsbeispiel 1:
Es wird nur ein Teil der "MMS Notification"-Hinweisnachricht mit Hilfe des asymmetrischen Kryptographieverfahrens signiert. Insbesondere wird die Referenzzeile auf den URI (URI = Uniform Resource Identifier), der die Verknüpfung zu dem Speicherplatz mit der bereitliegenden Multimedia Message bezeichnet, mit einer Signatur versehen. Dabei folgt die Signatur vorzugsweise im Push-Initiator desjenigen MMS Re-lay/Server, der Multimedia-Nachrichten (MMs=multimedia messages) zum Abruf durch eine Vielzahl zugeordneter MMS User Agents in Teilnehmergeräten des Kommunikationsnetzes bereithält. Dabei wird die Signatur als Erweiterung bzw. Extension an die URI-Referenz angehängt. Dies veranschaulicht beispielhaft die MMS Notification-Hinweisnachricht MN1* von 7, die gegenüber der MMS Notification-Hinweisnachricht MN1 dahingehend modifiziert worden ist, dass jetzt in der X-MMS-Content-Location-Zeile nach dem URL-Eintrag "http://siemens.de/sal/mms-id" eine Signatur in Form eines Hashwertes HW angehängt worden ist.
Möchte also ein MMS -Provider wie z.B. SPA von 5 die in 6 dargestellte "MMS Notification"-Hinweisnachricht an einen seiner Kunden übermitteln, so signiert er aus Sicherheitsgründen den Eintrag, d.h. den Feldwert des Kopffeldes "X-MMS-Content-Location" http://siemens.de/sal/mms-id mit seinem privaten kryptographischen Schlüssel. Das Ergebnis dieser Signatur ist beispielsweise ein Hashwert HW, der als Zusatz bzw. Extension an den bisherigen Feldwert (d.h. dem eigentlichen URL) des Kopffeldes X-MMS-Content-Location am Ende angeheftet wird. Im jeweiligen Empfangsterminal wird dann zunächst dieser Hashwert HW vom restlichen Feldwert (d.h. vom eigentlichen URI) des Kopffeldes X-MMS-Content-Location separiert. Anschließend wird die Signatur HW mit Hilfe des öffentlichen kryptographischen Schlüssels des MMS Providers im Endgerät selbst verifiziert. Der öffentliche kryptographische Schlüssel des MMS Providers kann dazu beispielsweise von einer externen Speichereinheit eingelesen werden.
Ausführungsbeispiel 2:
Auch in diesem Ausführungsbeispiel wird lediglich ein Teil der Push-Nutzdaten mit einer Signatur versehen. Insbesondere wird lediglich der URL der jeweiligen Push-Nachricht mit einem privaten Schlüssel im MMS-Relay/Server kodiert. Allerdings wird jetzt im Unterschied zum Ausführungsbeispiel 1 ein eigenes Kopffeld zur ursprünglichen MMS Notification-Hinweisnachricht MN1 wie z.B. MN1 von 6 hinzugefügt. Eine solche MMS Notification-Hinweisnachricht MN1, die zusätzlich ein eigenes Feld bzw. eine eigene Steuerzeile für die Signatur wie z.B. HW aufweist, ist in der 8 in textueller Kodierung gezeigt und mit MN1** bezeichnet. Sie geht aus der ursprünglichen MMS Notification-Hinweisnachricht MN1 von 6 dadurch hervor, dass im MMS Relay/Server in einer eigenen Steuerzeile X-MMS-Signature eine digitale Signatur in Form eines Hashwertes am Ende hinzugefügt worden ist. Analog zu dem im Ausführungsbeispiel 1 beschriebenen Vorgehen erzeugt also das Signieren des Feldwertes des Kopffeldes X-MMS-Content-Location einen Hashwert HW. Dieser wird nun allerdings nicht an den Feldwert des Kopfwertes X-MMS-Content-Location herangehängt, sondern in einem eigens dafür definierten Kopffeld X-MMS-Signature in die MMS Notification- Hinweisnachricht eingebunden. Bei der mit dem privaten Schlüssel versehenen MMS Notification-Hinweisnachricht MN1** von 8 ist das Kopffeld mit der Signatur am Ende der Nachricht hinzugefügt. Genauso kann es aber auch zweckmäßig sein, dieses Kopffeld mit der Signatur an anderer Stelle in die textuelle Kodierung der MMS Notification-Hinweisnachricht MN1 von 6 einzufügen.
Ausführungsbeispiel 3:
Weiterhin kann es zweckmäßig sein, die kompletten Push-Nutzdaten mit einer Signatur eines asymmetrischen Kryptographieverfahrens zu versehen. Handelte es sich bei den Push-Nutzdaten um eine "MMS Notification"-Hinweisnachricht im MMS, so wird also die gesamte "MMS Notification"-Hinweisnachricht mit dem privaten Schlüssel eines asymmetrischen Kryptographieverfahrens insgesamt versehen. Auch dabei erfolgt die Signatur zweckmäßigerweise im jeweiligen MMS Relay/Server. Zur Verschlüsselung der gesamten Push-Nutzdaten ist es zweckmäßig, für die Signatur mindestens ein Kopffeld vorzusehen, das den signierten Push-Nutzdaten vorangestellt wird. Die Push-Nutzdaten selbst bleiben dabei unverändert. Werden die jeweiligen Push-Nutzdaten insbesondere durch eine " MMS Notification"-Hinweisnachricht gebildet, so wird wie im ersten Ausführungsbeispiel ein Hashwert HW erzeugt. Dieser wird nun allerdings nicht an den Feldwert des Kopffeldes X-MMS-Content-Location wie im Ausführungsbeispiel 1 herangehängt, und auch nicht in einem Kopffeld innerhalb der Push-Nachricht wie im Ausführungsbeispiel 2 transportiert, sondern in eines der UDH- oder WSP-Kopffelder, die den eigentlichen Push-Nutzdaten, wie weiter vorstehend erläutert, vorangestellt. Gegebenenfalls kann es auch zweckmäßig sein, dazu extra neue UDH- oder WSP-Kopffelder zu definieren.
Ausführungsbeispiel 4:
Weiterhin kann es zweckmäßig sein, die jeweilige Push-Nachricht zusammen mit Steuerbefehlen vom Push-Initiator des jeweiligen MMS- Relay/Servers mittels des WAP PAP an das zugeordnete Push-Proxy-Gateway zur dortigen Signatur zu schicken, d.h. die Signatur der jeweiligen Push-Nutzdaten erfolgt erst im Push-Proxy-Gateway. Die Push-Nutzdaten selbst bleiben auf der Schnittstellenseite des PAP, d.h. im Bereich der Schnittstelle SB entsprechend der Architektur der 3, 4 unverändert. Es werden also die jeweiligen Push-Nutzdaten erst vom jeweiligen Push-Proxy-Gateway und nicht vom die Push-Nachricht absendenden MMS -Relay/Server signiert. Dazu werden zweckmäßigerweise zusätzliche Steuerbefehle für die Control Entity, das ist ein in XML-kodierter Datensatz, welcher den eigentlichen Push-Nutzdaten im WAP PAP vorangestellt werden, definiert.
Demgegenüber hat das Signierverfahren mit Hilfe eines asymmetrischen Kryptographieverfahrens im jeweiligen MMS-Relay/Server wie z.B. entsprechend den Ausführungsbeispielen 1 mit 3 den Vorteil, dass dort in der Regel über mehr Rechenleistung als in einem Gateway zur Verfügung steht und zudem die über die beiden Schnittstellen SA, SB von 4 transportierten Push-Nutzdaten lückenlos datenquellenspezifisch gekennzeichnet werden können. Dadurch sind Sicherheitslücken gegenüber dem Ausführungsbeispiel 4 besser vermieden. Denn die über beide Schnittstellen SA, SB geschickten Push-Nutzdaten sind für beide Schnittstellen mit einem privaten Schlüssel eines asymmetrischen Kryptographieverfahrens versehen, d.h. die Signatur bleibt unverändert.
Ggf. kann es auch zweckmäßig sein, sowohl im jeweiligen MMS-Relay/Server und im jeweilig nachgeschalteten Gateway eine asymmetrische Kryptographieverschlüsselung von Push-Nutzdaten vorzunehmen.
Durch die erfindungsgemäße datenquellenspezifische Kennzeichnung von Push-Nutzdaten mit Hilfe eines asymmetrischen Kryp tographieverfahrens wird somit erreicht, dass lediglich authentifizierte Push-Nutzdaten im Teilnehmergerät weiterverarbeitet werden, während Push-Nutzdaten unautorisierter Absender herausgefiltert und verworfen werden. Da lediglich für authentifizierte Push-Nutzdaten im Push-Modus z.B. im Fall eines Funkkommunikationsnetzes eine WSP (Wireless Session Protocol) oder HTTP-Verbindung (HTTP = Hypertext Transfer Protocol) aufgebaut wird, wird ein unerwünschtes (automatisches) Anfordern von Inhalten , die von unidentifizierbaren Dritten stammen, wirksam unterbunden. Der jeweilige Empfänger von Push-Nutzdaten kann somit stets sicher sein, dass nur Push-Nutzdaten aus einer ihm vertrauenswürdigen Datenquelle zum Anfordern der Inhalte herangezogen werden.
Gegenüber dem erfindungsgemäßen Verfahren wäre besonders folgende Übertragungsmöglichkeit von Nutzdaten im Push-Modus nachteilig: würde eine bestehende WSP- oder HTTP-Verbindung (WSP – Wireless Session Protocol) entsprechend der Spezifikation WAP-230-WSP Wireless Session Protocol Specification, approved version 5-July-2001, (HTTP = Hypertext Transfer Protocol, RFC 2616"Hypertext Transfer Protocol- HTTP/1.1"; June 1999) zwischen dem jeweiligen Telekommunikationsendgerät und dem zugeordneten MMS Relay/Server zur Übertragung von Daten im Push-Modua verwendet, so würde dazu das Push-Proxy-Gateway zunächst den Aufbau einer WSP- oder HTTP-Sitzung durch das Telekommunikationsendgerät veranlassen. Dies würde durch Übertragung eines SIR (SIR -Session Initiation Request) vom Push-Proxy-Gateway an den Push-Client auf dem Empfangsgerät wiederum mittels SMS durchgeführt werden. Nach Empfang des SIR könnte der Push-Client dann eine WSP oder HTTP-Verbindung zwischen dem Telekommunikationsendgerät und dem Push-Initiator aufbauen. Die WSP- und HTTP-Verbindungen würden zwar eine einigermaßen verlässliche Authentifizierung des Push-Initiators ebenfalls erlauben, hätten aber insbesondere den Nachteil, dass für jede Übertragung von Nutzdaten im Push-Modus (beispielsweise in Form einer MMS Notification) eigens eine WSP- oder HTTP-Verbindung aufgebaut werden müss te. Dies ist insbesondere im Roaming-Fall mit meist hohen zusätzlichen Kosten für den Empfänger verbunden und deshalb in der Praxis in der Regel nicht akzeptabel.
Das erfindungsgemäße Verfahren zur datenspezifischen Kennzeichnung von Push-Nutzdaten ermöglicht hingegen in vorteilhafter Weise, dass ohne SIR und anschließenden WSP- bzw. HTTP-Verbindungsaufbau die jeweilige "MMS-Notification"-Hinweisnachricht in mindestens einer Short Message zusammen mit der Signatur, insbesondere dem Hashwert, des asymmetrischen Kryptographieverfahrens untergebracht werden kann.

Claims

Verfahren zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten (PNU) in einem Kommunikationsnetzwerk (CN), die ausgehend von mindestens einem Push-Initiator (PI) über mindestens ein Push-Proxy-Gateway (PPG) an mindestens einen Push-Client (PC) ohne dessen vorherige Aufforderung geschickt werden, indem im Push-Initiator (PI) oder im Push-Proxy-Gateway (PPG) ein Teil der oder die gesamten Push-Nutzdaten (PNU) mit Hilfe eines asymmetrischen Kryptographieverfahrens mit mindestens einer Signatur (HW) versehen werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Signatur (HW) innerhalb der Push-Nutzdaten (PNU) übertragen wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Signatur (HW) zusätzlich zu den Push-Nutzdaten (PNU) in mindestens einem eigenen Kopffeld übertragen wird, das den Push-Nutzdaten (PNU) vorausgestellt und/oder nachgeordnet wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Push-Nutzdaten (PNU) durch eine "MMS Notification"-Nachricht (MN1) (MMS = Multimedia Messaging Service) gebildet werden, durch die der Kommunikationseinheit (UA) angezeigt wird, dass eine Multimedianachricht zur Abholung netzwerkseitig bereitgehalten wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Kommunikationseinheit (UA), an die die jeweiligen Push-Nutzdaten (PNU) vom jeweilig zugeordneten Push- Initiator (PI) geschickt werden, in einem Teilnehmergerät eines Funkkommunikationsnetzwerks verwendet wird.
Kommunikationsnetzwerk (CN) mit mindestens einer Vorrichtung zur datenquellenspezifischen Kennzeichnung von Push-Nutzdaten (PNU) nach einem der vorhergehenden Ansprüche.