WO2004021663A1 - Method and device for the data source-specific marking of useful push data - Google Patents

Abstract

In order to mark in a data source-specific manner useful push data (PNU) which is sent from a push initiator (PI) to at least one communication unit (UA) via a push proxy gateway (PPG) in a multimedia messaging service of a communication network (CN), part or all of the respective useful push data (PNU) is signed in the push initiator (PI) and/or the push proxy gateway (PPG) by means of an asymmetric cryptographic method.

Description

description

Method and device for data source-specific identification of push user data

In practice, in communication networks, in particular radio communication systems, messages or data can be downloaded to a user's subscriber device from a component of the network in an uncontrollable manner for the user. Even if a notification message arrives at the subscriber device of the respective user that data or messages are held ready for retrieval on the network side, it remains too opaque for the user as to who the sender of this notification and the provider of this data actually is. This makes wrong decisions when downloading data by the respective user possible and there is also a risk of misuse of such notification messages.

The invention is based on the object of demonstrating a way in which it can be ensured for the respective user of a subscriber device of a communication network that push data or push messages provided on the network side come from a data source which is trustworthy for the respective user. This object is achieved with the aid of the following method according to the invention:

Method for data source-specific identification of push user data in a communication network, which is sent from at least one push initiator via at least one push proxy gateway to at least one push client without being requested to do so by using the push initiator or push Proxy gateway part or all of the push user data can be provided with at least one signature using an asymmetrical cryptography method. The data source-specific identification of the respective push message using an asymmetrical cryptography method in the push initiator and / or push proxy gateway largely ensures that only such data or messages are selectively conveyed to the communication unit of the respective user which come from a known, trusted data source.

The invention further relates to a communication network with at least one device for data source-specific identification of push messages according to the inventive method.

The invention and its developments are explained in more detail below with reference to drawings.

Show it:

1 shows a schematic representation of a pull mode in the transmission of data between a server and a client,

Figure 2 is a schematic representation of a push mode in the transmission of data between one

Server and a push client,

FIG. 3 shows a push architecture in accordance with WAP (Wireless Application Protocol), in which push messages are transmitted from a sending unit (= Push Initiator Pl) via a push proxy gateway) to a message receiving unit (= Push Client PC),

FIG. 4 shows a schematic representation of the functionality of the push proxy gateway according to FIG. 3 in detail, FIG. 5 schematically, in a simplified representation, an MMS architecture (MMS = Multimedia Messaging Service) according to 3GPP, which is modified to carry out the method according to the invention,

FIG. 6 shows an exemplary push message "MMS notification" in textual coding for notifying a communication unit in a communication network of the presence on the network of retrievable data or messages, in particular multimedia data, and

Figures 7, 8 different examples of the push message ^, MMS Notification "in textual coding according to Figure 6 with a digital signature for data source-specific identification according to the invention.

Elements with the same function and mode of operation are provided with the same reference numerals in FIGS. 1 with 8.

FIG. 1 schematically illustrates the transmission of data DA between a server SV and a client CL in the so-called pull mode, in which this receiving unit CL directs a request signal AF to the server SV. It is only on the basis of this request signal AF that the data or messages are pulled down or transmitted from the server SV to the receiving unit CL (English pull = pull). This pull function is designated in FIG. 1 by PLM. In contrast to this, the data or messages DA are transmitted without request from the server SV in the so-called push mode, that is to say without a network-side request signal, to the receiving unit PC, that is to say pushed directly or suddenly, so to speak (push = push, push). , This push mode is designated by PSM in FIG. 2. In this way, the ^• pull transactions always originate from the respective client, The push transactions of data are always initiated by the respective server. Browsing the World Wide Web is a typical example of pull technology. There, entering a URL (URL = Uniform Resource Locator, which corresponds to the address of a memory location or a reference to it) corresponds to the above-mentioned request signal in the browser. Such server / client constellations are advantageously part of common communication networks, in particular radio communication systems.

In the specifications WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001 and WAP-235, Push Over The Air Protocol, Version 25-April-2001 des WAP forums (WAP = Wireless Access Protocol) is the push procedure for the transmission of data between a server and a client, which is located on a mobile device, in particular a radio communication device. In the terminology of the WAP forum, the respective server, i.e. Generally speaking, the network component that provides the user data to be transmitted and possibly additional control commands (e.g. via the type of delivery of the user data in push mode) is referred to as the so-called push initiator. It sends the user data (possibly including the additional control commands) to a push proxy gateway, which sends the data it sends

In terms of transmission technology, adapts user data to the different protocols of the deeper protocol layers of the respective receiving communication unit. In other words, this means that such a gateway takes over an interface function for the transmission connection between the respective server and its associated receiving units receiving push messages. Furthermore, such a push proxy gateway also evaluates any existing control commands for the delivery of the user data in push mode and controls the correct execution of the user data transmission between the push proxy gateway and the respectively assigned push client, ie the respective receiving unit of the push messages or push data sent. This push functionality of a push proxy gateway can expediently be integrated into a conventional, "normal" WAP gateway. Alternatively, however, it is also possible to use two separate functional units, namely WAP gateway and push proxy gateway, to be provided with a clear division of tasks in the respective communication network.

FIG. 3 schematically illustrates a push architecture in WAP for the distribution of push messages in a radio communication network. A push initiator PI sends push messages PNA, which contain control information in addition to push user data PNU, via at least one transmission path UPI to an assigned push proxy gateway PPG, which further delivers the push user data PNU im

Executes and monitors push mode via at least one transmission path UP2 to a push client PC. A large number of push clients can be connected to the push proxy gateway PPG. These have been omitted from FIG. 3 for the sake of drawing simplicity. The so-called WAP PAP protocol (PAP = Push Access Protocol) is used between the push initiator PI and the push proxy gateway PPG when transmitting the push messages PNA. It is based on known standard Internet protocols such as HTTP (HTTP = Hypertext Transfer Protocol). Detailed information on the WAP PAP protocol is given in particular in the specification WAP-247, Push Access Protocol, version 29-April-2001. Details of the HTTP protocol can be found, for example, in the specification RFC 2616, Hypertext Transfer Protocol - HTTP / 1.1; June 1999. Any additional control commands associated with the push messages are preferably expressed in the XML syntax (XML = Extensible Markup Language). The push proxy gateway PPG transmits the push user data PNU, taking these control commands from the push initiator P1 into account, to the communication unit or the client PC in the subscriber device of the respective recipient. Between the push proxy gateway PPG and the push client PC the WAP-Push OTA Protocol (OTA = Over The Air) is used in particular. Further details are given in the specification WAP-235, Push Over The Air Protocol, version 25 April 2001.

In FIG. 3, the interface in the transmission connection UPI between the push initiator PI and the push proxy gateway PPG, which is based on the WAP PAP protocol, is designated by SB. The interface for the transmission of the push user data PNU between the push proxy gateway PPG and the push client PC with the aid of the push OTA protocol OTAP is indicated in FIG. 3 by the reference symbol SA. In a radio communication network such as According to the UMTS standard, the interface SA in particular also includes an air interface between a base station that sends push useful data and one or more radio communication devices in their radio cell.

FIG. 4 schematically illustrates how push user data PNU through a WAP gateway WAPG with an integrated push proxy

Gateway functionality to the deeper protocol layers of the two interfaces SA and SB of FIG. 3, namely specifically to the WAP OTA protocol OTAP for the interface SA and the WAP push access protocol PAP for the interface SB, for format adaptation. In FIG. 4, the push initiator P1 is provided as the sending communication unit of the server SV. As the receiving communication unit, the push client PC is preferably part of a radio communication device, in particular a mobile terminal device UE, such as a mobile radio telephone. The push initiator P1 of the server SV makes the push messages PNA to be sent conform to the WAP PAP protocol PAP by transferring them to its lower transmission protocol layers LLB. The push messages PNA transmitted in such a modified manner via the interface SB are evaluated by the lower layers LLB of the WAP-PAP protocol in the WAP gateway WAPG and, with the aid of the gateway WAPG, to the lower layers LLA of the WAP- OTA protocol OTAP adapted to its format. In this way, the push client PC in the user equipment UE can use the lower protocol layers LLA and its WAP-OTA protocol OTAP to correctly receive and evaluate the received push user data PNU.

For next generation mobile radio systems (eg 2.5G and 3G), such as UMTS (UMTS = Universal Mobile Telecommunication System), a multimedia-capable variant of a mobile messaging service is currently being standardized, the so-called MMS service (MMS = Multimedia Messaging) Service). Details on this are detailed in the specifications 3GPP TS 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, as well as 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 played. In the following, messages with multimedia content are only briefly called MMs (MM = Multimedia Message; MMs = Multimedia Messages (plural)) for better differentiation from the text messages of the SMS (Short Message Service). In contrast to SMS (SMS = Short Message Service), there is no restriction to pure text content. Explicit information on the SMS can be found in the specification 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) made. In contrast to SMS, with MMS it is advantageously possible to format texts according to the individual taste of the respective user and to embed audio and video content in a message. A multimedia message (MM) can accordingly be composed of several multimedia elements of different file types (for example audio or still picture) and / or file formats (for still picture for example GIF or JPEG). FIG. 5 shows the simplified network architecture according to 3GPP for the multimedia messaging service. It includes, for example, two multimedia messaging service relays / servers RSA, RSB of two different multimedia messaging service providers SPA, SPB. The MMS relay / server RSA transmits push user data PNU to the communication units of a multiplicity of subscriber devices, in particular radio communication devices, of the communication network CN, the remaining components of which have been omitted in FIG. 5 for the sake of clarity. For the sake of drawing simplicity, FIG. 5 shows only a single subscriber device UA of this group of subscriber devices, which is coupled to the relay / server RSA via an interface MM1. Correspondingly, one or more subscriber devices ÜB, in particular radio communication devices, are assigned to the second MMS relay / server RSB of the second provider or service provider SPB with the aid of the interface MM1. The two relay / servers RSA, RSB can communicate via an additional interface MM4, using the so-called SMTP (Simple Mail Transfer Protocol) in particular in UMTS. A communication unit in the form of a so-called MMS user agent is implemented in the respective subscriber device, such as UA, which is to receive and evaluate the push user data PNU from the MMS relay / server RSA. MMS user agent is understood to be a sequence procedure that implements the multimedia messaging service. This MMS user agent can preferably be provided on a radio communication device, in particular a mobile device, or on an additional device connected to a mobile device, such as a laptop or the like. An MMS relay / server such as RSA is a network element that provides the MMS functionality to the MMS user agents present in the area of responsibility MMSE (MMSE = Multimedia Messaging Service Environment) of the MMS provider such as SPA.

In the multimedia messaging service, the communication unit or the push client of the respective push user data PNU receiving subscriber devices such as UA in Figure 5 first of all from the assigned MMS relay / server such as RSA by means of a so-called notification or inquiry message 'MMS Notification' about the arrival of a new multimedia message on the MMS relay / server, which can be downloaded there

(Download) is kept ready. Such an 'MMS notification' message contains a reference to the storage space of the multimedia message in the area of responsibility of the respective MMS provider, such as SPA, preferably in the form of a URI (URI = Uniform Resource Identifier). With the aid of this reference, the multimedia message can then either can be downloaded immediately in the form of a so-called 'immediate retrieval' or a time delay in the form of a so-called 'deferred retrieval' to the terminal, such as UA in Figure 5. In an 'MMS notification' message, a lot of additional information (such as Sender, topic, etc.) for a multimedia message, which can be used by the MMS user agent of the recipient as a decision-making aid for the download. The interface MM1 between the MMS Relay / Server RSA and the MMS User Agent of the subscriber device UA in Figure 5 is particularly by the WAP specifications 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 defined in more detail.

For MMS subscribers with mobile devices, the 'MMS notifications' are sent to the recipient in push mode according to the WAP push protocol (cf. specifications WAP-250, Push Architectural Overview, Version 03-July-2001, WAP-247, Push Access Protocol, Version 29-April-2001, WAP-235, Push Over The Air Protocol, Version 25-April-2001), ie the user data to be transmitted are first sent to a notification message 'MMS Notification' by the respective MMS relay / server as a push initiator, preferably wired to the push Transfer proxy gateway PPG. This in turn decides, taking into account any requirements of the MMS relay / server in the form of the control commands mentioned above, about the type of further delivery of the notification message 'MMS notification' via the air interface to the push client on the mobile terminal, such as UA in Figure 5. The interface MM1 in Figure 5 corresponding to the 3GPP MMS architecture contains the two interfaces SA and SB for the push functionality according to the push architectures of Figures 3, 4.

A simple way of transmitting the data of the respective “MMS Notification” notification message about the presence of push messages to the receiving subscriber devices affected by this is that the data to be transmitted of the “MMS Notification” notification message are in a short Message or several short messages of the Short Messaging Service (SMS) are sent to the end device of the respective recipient. In other words, at least a short message is used as a transport container for the

Delivery of an 'MMS Notification' is used. A 'MMS Notification' formatted according to WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0 is used in the case of MMS as a carrier for the push functionality with UDH (User Data Headers) - and WSP (Wellness Session Protocol) - header fields and written in the 140 byte transport container of the SMS (Short Message Service). A short message (SM) is 160 bytes long, but has a header of 20 bytes, so that only 140 bytes per short message

'Payload', i.e. space left for the data to be transferred in push mode.

Without security measures, there would be a risk of possible misuse. This is because the recipient of an SMS message received and correctly formatted via SMS cannot recognize whether it is the data received is actually a notification from its MMS provider about a newly arrived multimedia message that is available for download. The data received via SMS could, however, also simply be a correctly formatted data record with which an 'MMS notification' notification message is to be simulated, and which is actually from a sender (push initiator) other than the MMS relay / server actually expected This other sender could use the URI (ie the reference to a storage space which is actually intended for the download of the multimedia message) in a simulated 'MMS Notification' notification message to download unwanted content such as advertising to the mobile terminal of the respective communication network participant. This so-called 'spamming' is particularly annoying for the respective recipient in the case of 'immediate retrieval' in the multimedia messaging service (MMS), because in this mode his terminal automatically resolves the reference in the 'MMS notification' notification message and the download process to download the multimedia message from the assigned MMS relay / server independently, ie without user prompt.

In order to ensure for the respective users of a subscriber device of a communication network that data or messages provided on the network side originate from a data source that is trustworthy for the respective user, push-user data is identified in a data source-specific manner by the fact that these push-user data are stored in the multimedia messaging relay / server or be partially or completely provided with at least one signature in the push proxy gateway using an asymmetrical cryptography method. In this way, each time a push message is sent, its push payload data is provided with a unique identifier that allows authentication of the sending relay / server. 'MMS Notification' - Notification messages about content provided by other providers They can thus be recognized and ignored in advance in the respective MMS user agent, which corresponds to filtering out or sorting out unwanted data. This largely avoids downloading unwanted content from the respective server.

In other words, the sender of a push message is checked by verifying a digital signature. For this purpose, the multimedia messaging relay / server and / or the downstream push proxy gateway signs with a private cryptographic key

a) a part of the push user data (in the case of MMS, for example, the reference to the storage location where the data of the push user data 5 are stored) of the push message sent or to be sent, or

b) the entire set of push useful data (for MMS, for example, the complete 'MMS notification' notification message) of the push message sent or to be sent.

The signature generated, in particular in the form of a so-called hash value, is sent from the relay / server and / or the push proxy gateway to the terminal of the respective receiver 5 in push mode

a) either (eg in a new header field) transmitted within the push user data (eg within an 'MMS notification' notification message), or 0 b) in addition to the signed 'push user data' in a new UDH or WSP header field transmitted to the end device of the respective recipient in push mode.

5 Even then, the public, cryptographic key of the asymmetrical cryptography procedure of the MMS provider is used in the terminal device to verify the Usage data supplied signature used. In this way it can be checked in the telecommunications terminal of a recipient whether the data received in push mode actually comes from his own MMS provider, ie the terminal now has practically reliable origin filter functionality. In this way, particularly in the case of the immediate retrieval of the respective subscriber device, in particular radio communication device, it is prevented that undesired content is automatically loaded onto the respective end device using non-trustworthy URLs (ie without the user having to query).

The mechanisms of asymmetric cryptography in the multimedia messaging relay / server and / or push proxy gateway are therefore used for reliable checking of push user data on the receiving end, in particular for checking 'MMS notification' messages arriving in push mode. to partially or completely sign the user data to be transmitted in the push mode. The signature of the respective push user data / push message is selected either in the push initiator of the multimedia messaging relay / server or in its assigned push proxy gateway with a private key of the service provider or network operator performed while the verification of the signature in the respective telecommunication terminal with the matching public key of the service provider or ^• network operator takes place This public key can be external either in an internal memory area of the respective terminal or in a. Speichereinhe it can be stored, which can be connected to the end device via cable or wirelessly.

The public cryptographic key can advantageously be stored on an intelligent memory card, in particular a so-called smart card such as a SIM card (SIM = Subscriber Identity Module) or a UICC (UICC = Universal Integrated Circuit Card) with (U) SIM ( (UMTS) subscriber identity module) as external storage Make unit that is inserted or inserted into the mobile device. There are memory areas on these cards that can only be written or updated by the network operator, and those for which the user also has write and read rights. The first-mentioned memory areas, which are reserved exclusively for the respective network operator, are particularly well suited for the storage and subsequent updating of OTA (OTA = Over The Air) of public cryptographic keys. For example, the service provider or network operator can easily increase the key length in this way in order to be able to meet new security requirements. According to an expedient version, an already existing application on the SIM card such as the SAT application (SAT = SIM Application Tool Kit) or on the UICC with (U) SIM card such as CAT (Card Application Tool Kit) or (U) SAT application ((U) SAT = UMTS SIM Application Tool Kit) used to verify the signature of the push user data.

FIG. 6 shows an example of an 'MMS Notification' message in textual coding in the MMS. In the associated binary coding according to WAP-209-MMS Encapsulation; WAP Multimedia Messaging Service (MMS) Specification Suite 2.0, a data block of approximately 100 bytes is obtained If this 'MMS Notification' message is sent to a recipient as SMS push data via SMS, this data block is preceded by a few WSP and UDH header fields with a total length of approximately 35 bytes. The total amount of data to be transferred thus adds up to around 135 bytes in this example, which would not be too much payload for a single short message. For larger amounts of data, in particular more than 140 bytes, it is advisable to use several short messages in accordance with the 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) for transmission of the 'MMS Notification' notification message chained together.

The data source-specific identification of the "MMS Notification" notification message in the MMS, which is sent to the downloadable push messages from the MMS relay / server for downloading to one or more addressed communication units of subscriber devices, can expediently be carried out in the following four different ways:

Example 1:

Only a part of the 'MMS Notification' notification message is signed with the aid of the asymmetrical cryptography method. In particular, the reference line on the URI (URI = Uniform Resource Identifier), which designates the link to the storage space with the available multimedia message, is also marked with The signature preferably follows in the push initiator of the MMS relay / server that holds multimedia messages (MMs = multimedia essays) ready for retrieval by a large number of assigned MMS user agents in subscriber devices of the communication network. The signature is appended to the URI reference as an extension, which is illustrated, for example, by the MMS notification message MNl * from FIG. 7, which has been modified compared to the MMS notification message MNl in such a way that now in the X -MMS- content location line after the URL entry 'http://siemens.de/sal/mms-id "a signature in the form of a Hash values HW has been added.

If an MMS provider, such as SPA from FIG. 5, would like to transmit the 'MMS notification' message shown in FIG. 6 to one of its customers, it signs the entry, ie the field value of the header field 'X-MMS content, for security reasons -Location 'http: // siemens .de / sal / mms-id with its private cryptographic key. The result this signature is, for example, a hash value HW, which is added as an addition or extension to the previous field value (ie the actual URL) of the header field X-MMS-Content-Location at the end. In the respective receiving terminal, this hash value HW is then separated from the rest of the field value (ie from the actual URI) of the X-MMS content location header field. The signature HW is then verified with the help of the public cryptographic key of the MMS provider in the terminal itself. For this purpose, the public cryptographic key of the MMS provider can be read in, for example, from an external storage unit.

Example 2:

In this exemplary embodiment too, only part of the push useful data is provided with a signature. In particular, only the URL of the respective push message is encoded with a private key in the MMS relay / server. However, in contrast to exemplary embodiment 1, a separate header field is now added to the original MMS notification message MNl, such as MNl from FIG. 6. Such an MMS notification message MN1, which additionally has its own field or control line for the signature, such as HW, is shown in textual coding in FIG. 8 and is designated MNl **. It emerges from the original MMS notification message MN1 from FIG. 6 in that a digital signature in the form of a hash value has been added to the MMS relay / server in a separate control line X-MMS signature. Analogous to the procedure described in exemplary embodiment 1, the signing of the field value of the header field X-MMS content location generates a hash value HW. However, this is now not appended to the field value of the header value X-MMS-Content-Location, but in a specially defined header field X-MMS-Signature in the MMS notification- Notice message included. In the MMS notification message MN1 ** provided with the private key from FIG. 8, the header field with the signature is added at the end of the message. Likewise, however, it can also be expedient to insert this header field with the signature elsewhere in the textual coding of the MMS notification message MN1 from FIG. 6.

Example 3:

Furthermore, it can be expedient to provide the complete push payload data with a signature of an asymmetrical cryptography method. If the push useful data was an 'MMS notification' notification message in the MMS, the entire 'MMS notification' notification message is thus provided with the private key of an asymmetrical cryptography method as a whole. Here, too, the signature is expediently carried out in the respective MMS relay / server. To encrypt the entire push user data, it is expedient to provide at least one header field for the signature, which is placed in front of the signed push user data. The push payload itself remains unchanged. If the respective push useful data is formed in particular by an 'MMS notification' notification message, a hash value HW is generated as in the first exemplary embodiment. However, this has not been appended to the field value of the header field X-MMS content location as in exemplary embodiment 1 , and also not transported in a header field within the push message as in exemplary embodiment 2, but in one of the UDH or WSP header fields, which precedes the actual push user data, as explained further above. to define extra new UDH or WSP header fields.

Example 4: Furthermore, it may be expedient to send the respective push message together with control commands from the push initiator of the respective MMS relay / server by means of the WAP PAP to the assigned push proxy gateway for the signature there, ie the signature of the respective one Push user data only takes place in the push proxy gateway. The push useful data itself remain unchanged on the interface side of the PAP, ie in the area of the interface SB in accordance with the architecture of FIGS. 3, 4. The respective push user data are therefore only from the respective push proxy gateway and not from the

MMS-Relay / Server sending push message signed. For this purpose, additional control commands for the control entity are expediently defined, that is, an XML-coded data record which precedes the actual push user data in the WAP PAP.

In contrast, the signing process with the help of an asymmetrical cryptography process in the respective MMS relay / server, e.g. in accordance with the exemplary embodiments 1 to 3, the advantage that there is generally more computing power available than in a gateway and that the push useful data transported via the two interfaces SA, SB of FIG. 4 can also be identified in a data-specific manner without gaps. As a result, security gaps are better avoided compared to embodiment 4. This is because the push user data sent via both interfaces SA, SB are provided with a private key of an asymmetrical cryptography method for both interfaces, i.e. the signature remains unchanged.

Possibly. it can also be expedient to carry out asymmetrical cryptography encryption of push user data both in the respective MMS relay / server and in the respective downstream gateway.

Due to the data source-specific identification of push user data according to the invention with the aid of an asymmetrical cryptographic This ensures that only authenticated push user data are further processed in the subscriber device, while push user data are filtered out and rejected by unauthorized senders. Since a WSP (Wireless Session Protocol) or HTTP connection (HTTP = Hypertext Transfer Protocol) is only set up for authenticated push user data in push mode, for example in the case of a radio communication network, there is an undesirable (automatic) request for content that is unidentifiable Come from third parties, effectively prevented. The respective recipient of push payload data can thus always be sure that only push payload data from a data source that is trustworthy can be used to request the content.

Compared to the method according to the invention, the following transmission option of user data in push mode would be disadvantageous: an existing WSP or HTTP connection (WSP - Wireless Session Protocol) would conform to the specification 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) between the respective telecommunication terminal and the assigned MMS relay / server for the transmission of data in push mode, so the push proxy gateway first initiates the establishment of a WSP or HTTP session by the telecommunication terminal, which would be done by transmitting a SIR (SIR session initiation request) from the push proxy gateway to the push client on the Receiving device in turn can be carried out by SMS .. After receiving the SIR, the push client could then use a WSP or HTTP connection between the tel Set up the device and the push initiator. Although the WSP and HTTP connections would also allow a somewhat reliable authentication of the push initiator, they would have the disadvantage, in particular, that a WSP or HTTP is specifically for each transmission of user data in push mode (for example in the form of an MMS notification) -Connection must be established- te. Particularly in the case of roaming, this is usually associated with high additional costs for the recipient and is therefore generally not acceptable in practice.

The method according to the invention for data-specific identification of push useful data, on the other hand, advantageously enables the respective 'MMS notification' notification message in at least one short message together with the signature, in particular the hash value, without SIR and subsequent WSP or HTTP connection establishment , the asymmetrical cryptography process can be accommodated.

Claims

claims 1. Method for the data source-specific identification of push useful data (PNU) in a communication network (CN), starting from at least one push initiator (Pl) can be sent via at least one push proxy gateway (PPG) to at least one push client (PC) without prior request by a part in the push initiator (Pl) or in the push proxy gateway (PPG) the or all of the push useful data (PNU) are provided with at least one signature (HW) using an asymmetric cryptography method. 2. The method according to claim 1, characterized in that the signature (HW) is transmitted within the push useful data (PNU). 3. The method according to claim 1, characterized in that the signature (HW) is transmitted in addition to the push user data (PNU) in at least one separate header field, which is prepended and / or subordinate to the push user data (PNU). 4. The method according to any one of the preceding claims, characterized in that the push useful data (PNU) are formed by an 'MMS notification' message (MNl) (MMS = Multimedia Messaging Service), by which the communication unit (UA) is displayed that a multimedia message is ready for collection on the network side. 5. The method according to any one of the preceding claims, characterized in that the communication unit (UA) to which the respective push useful data (PNU) from the respectively assigned push Initiator (Pl) are sent, is used in a subscriber device of a radio communication network. 6. Communication network (CN) with at least one device for data source-specific identification of push useful data (PNU) according to one of the preceding claims.