WO2003030474A2 - Mmsc access control - Google Patents

Mmsc access control Download PDF

Info

Publication number
WO2003030474A2
WO2003030474A2 PCT/IE2002/000139 IE0200139W WO03030474A2 WO 2003030474 A2 WO2003030474 A2 WO 2003030474A2 IE 0200139 W IE0200139 W IE 0200139W WO 03030474 A2 WO03030474 A2 WO 03030474A2
Authority
WO
WIPO (PCT)
Prior art keywords
recipient
message
messaging system
content
code
Prior art date
Application number
PCT/IE2002/000139
Other languages
French (fr)
Other versions
WO2003030474A3 (en
Inventor
Frederick James Jones
Fergal O'sullivan
John Murtagh
Joseph Johnson
Louis Corrigan
Brendan Mcgee
Original Assignee
Markport Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Markport Limited filed Critical Markport Limited
Priority to AU2002343183A priority Critical patent/AU2002343183A1/en
Publication of WO2003030474A2 publication Critical patent/WO2003030474A2/en
Publication of WO2003030474A3 publication Critical patent/WO2003030474A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/224Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58Message adaptation for wireless communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • H04L61/301Name conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W68/00User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/69Identity-dependent
    • H04W12/72Subscriber identity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/14Flow control between communication endpoints using intermediate storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12Messaging; Mailboxes; Announcements

Definitions

  • the invention relates to communication of rich messages having content in a mobile network environment.
  • An example is routing of multi-media messages in which a multi-media service centre (MMSC) is used.
  • MMSC multi-media service centre
  • Another example is in WAP or I-Mode in which a notification is pushed to a subscriber and the subscriber then uses a browser to pull the notified content.
  • an MMSC receives a MIME encoded Multimedia Message or E-mail message as defined by the 3GPP, WAP Forum and IETF.
  • This message may contain multimedia elements (e.g. text, audio, video etc.).
  • This message is stored temporarily in an MMSC message store and a notification is sent to one or more mobile device(s) indicating the message characteristics (e.g. size etc.) and a unique message-locator, which can be used to retrieve the message.
  • the device/subscriber then retrieves the MMS message using the message-locator received in the notification.
  • the multimedia parts of the message may contain the actual multimedia content, or may contain a further part-locator which can be used to retrieve the multimedia content. This is typically used in applications where the multimedia content (voice / video) is too large to be stored on the device and is instead streamed from a server in the network.
  • United States Patent Specification No. US6246871B (Nokia) describes a method of messaging in which a notification includes a temporary access code for the stored message. Such a notification is sent to multiple recipients, who can then access the message using the temporary access code.
  • PCT Patent Specification No. W098/58332 (Ericsson) describes a messaging method in which a notification is sent to an intended recipient, the notification having a security key.
  • a method of communication of a rich message from a sender device to a recipient device comprising the steps of:-
  • the sender device transmitting the message to a messaging system
  • the messaging system storing content of the message, and transmitting a notification of the message to the recipient device, and
  • the recipient device requesting the content by accessing the messaging system and retrieving the content
  • the messaging system performs recipient authentication before allowing the recipient device to have access to the content.
  • the messaging system is an MMSC and the message is a multimedia message.
  • the messaging system includes in the notification an address of a substitute location for the content, said substitute location being different from a real location at which the content is stored, and the authentication step controls access to the real location.
  • the locations are URLs.
  • said notification includes a code generated by an encode function of the messaging system, and the authentication step is performed by a decode function.
  • the encode function generates the code using recipient data.
  • the decode function performs authentication by decoding the recipient data and comparing it with recipient data received in the content request.
  • the recipient data includes a recipient subscriber identifier.
  • the recipient subscriber identifier is an MSISDN.
  • the encode function uses the real location address to generate the code, and the decode function determines the real location address by decoding.
  • the code is included in a field of the substitute location address in the notification.
  • the encode function uses a secret key to generate the code, and the decode function uses said key to decode the code.
  • the secret key is randomly generated for each message.
  • the encode function uses a recipient's PKI public key to generate the code and the decode function requests the recipient device to decode the code using its private key and subsequently verifies the recipient device decoding.
  • the messaging system comprises the decode function.
  • the recipient device comprises the decode function.
  • the invention provides a communication device comprising means for performing recipient device steps of a method as defined above.
  • the recipient device may, for example, be a multimedia-enabled mobile device.
  • the invention provides a messaging system comprising means for performing messaging system steps of a method as defined above.
  • the messaging system may, for example, be an MMSC
  • a messaging system such as an MMSC transmitting a notification to a recipient, the notification indicating where message content can be retrieved
  • the recipient device typically a mobile device accessing the server storing the message content but importantly, only being allowed access to the content after authentication of the recipient.
  • the invention provides security at the level of the recipient.
  • control of access by recipients has been achieved by transmitting the notification only to the described reci ⁇ ient(s).
  • the notification is wrongly routed or finds its way to a wrong recipient, or if the message location is accessed by an unintended recipient, there is inadequate control over who accesses the content despite message or sender-level security being imposed.
  • the messaging system and the content server is an MMSC.
  • the MMSC contains a token-encode function for generation of a token using the following:
  • this secret key could be generated randomly for each message
  • the MMSC contains a token-decode function for extraction of the recipient subscriber identification and the actual message-locator or part-locator using the following:
  • token-encode and token-decode functions are such that it will not be feasible in practice for a 3 rd party to generate an alternative token such that the token-decode function will produce the original message-locator or message-part but with the recipient subscriber identification of the 3 rd party, rather than the intended recipient.
  • the MMSC receives the multimedia message from a content supplier indicating a need for token generation.
  • the message is stored in the MMSC server.
  • a token is generated using the token-encode function and is incorporated into a field used as a substitute message-locator.
  • the substitute message-locator addresses a placeholder location (URL), the content being stored in a different, "real" URL location.
  • the MMSC then notifies the recipient of the pending message using the substitute message-locator.
  • the user (“the requester", which should be the recipient), requests the message from the MMSC using the substitute message-locator.
  • the MMSC applies the token-decode function to extract the recipient subscription identification and the actual message-locator.
  • the MMSC then compares the recipient subs ⁇ iption identification with the subscription identification of the requester. If they match, and the message-locator identifies a valid message, the message is transmitted to the requester.
  • the decode function effectively performs recipient authentication for controlling access from the placeholder location to the real location.
  • a single message may be intended for several recipients.
  • separate tokens and message-identifiers are generated for each recipient and are validated individually. The important point is that the security is at the recipient level.
  • the MMSC receives the Multimedia Message from a content supplier indicating a need for token generation.
  • the message is stored in the MMSC server.
  • a token is generated using the token-encode function and is incorporated into the message as a substitute p ⁇ rt-loc ⁇ tor.
  • the user requests (e.g. from a streaming server) the content referenced by each p ⁇ rt-loc ⁇ tor.
  • the MMSC applies the token-decode function to extract the recipient subscription identification and each actual p ⁇ rt-loc ⁇ tor.
  • the MMSC compares the recipient subscription identification with the subscription identification of the requester. If they match, and the p ⁇ rt-loc ⁇ tor identifies a valid multimedia object, the multimedia content is transmitted (e.g. streamed) to the requester.
  • Further examples of implementation of the invention in which a number of alternative token-encode and token-decode mechanisms are described, are described below with reference to Figs. 1 to 3. For these examples, an implementation of the MMSC message store based on standard Web Server capabilities is assumed, i.e. message locators are implemented by URL's, and message content is downloaded using the HTTP protocol.
  • the MMSC receives a multimedia message from a content supplier indicating a need for token generation.
  • the message is stored in the MMSC server under a dynamically generated URL - url, say.
  • a token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - url s .
  • the MMSC then notifies the recipient of the pending message using the substitute message-locator, url s .
  • the token-encode function used in this implementation accesses a secure database to retrieve an access control token (ACT) that is uniquely associated with the recipient, e.g. this could be a secret PIN number or password assigned to or selected by the subscriber.
  • ACT access control token
  • the access control token is encoded, along with the actual message URL url herein using a secret key known only to the MMSC and incorporated into a field of the substitute URL url s .
  • the user requests the message from the MMSC by invoking a HTTP GET method on the substitute URL url s .
  • the MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL url s ..
  • the token-decode function extracts the access control token and the actual message URL url m using the secret key.
  • the MMSC responds to the request by generating a challenge to the requester to enter their access control token (ACT, e.g. PIN or password).
  • ACT access control token
  • the requester returns the requested information using a HTTP POST method. For added security, this exchange could use HTTPS to ensure the access control token was not exchanged in plain-text.
  • the token-decode function now compares the received access control token with the access control token that was decoded from the substitute URL url s . If the access control tokens match, the requester is authenticated and the message content stored under the actual URL url, cooperate, can be returned to the requestor.
  • the MMSC receives the multimedia message from a content supplier indicating a need for token generation.
  • the message is stored in the MMSC server under a dynamically generated URL - url m .
  • a token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - url s .
  • the MMSC then notifies the recipient of the pending message using the substitute message-locator, url s .
  • the token-encode function used in this implementation retrieves the recipient's network identity from the destination address of the message, e.g. this could be an MSISDN, MIN or similar identifier.
  • the subscriber identity is encoded, along with the actual message URL url structuring using a secret key known only to the MMSC and incorporated into a field of the substitute URL url s .
  • the user requests the message from the MMSC by invoking a HTTP GET method on the substitute URL url s .
  • the MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL url s ..
  • the token-decode function extracts the subscriber identifier and the actual message
  • the token-decode function now compares the subscriber identifier provided by the network with the subscriber identifier that was decoded from the substitute URL url s . If the subscriber identifiers match, the requester is authenticated and the message content stored under the actual URL url crulie can be returned to the requestor.
  • the MMSC receives the Multimedia Message from a content supplier indicating a need for token generation.
  • the message is stored in the MMSC server under a dynamically generated URL - url m .
  • a token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - url 5 .
  • the MMSC then notifies the recipient of the pending message using the substitute message-locator, url s .
  • the token-encode function first generates a unique access control token using a suitable random function. It then retrieves the recipient's PKI certificate and uses the recipient's public key to encode the access control token - act u .
  • the access control token is also encoded using a secret key known only to the MMSC - act m .
  • the actual message URL url m is also encoded using a secret key known only to the MMSC and all values are incorporated into a field of the substitute URL url s .
  • the user requests the message from the MMSC by invoking a HTTP GET method on the substitute URL url s .
  • the MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL url s ..
  • the token-decode function extracts act u . It also decodes act,,, and the actual message URL url m using the secret key.
  • the MMSC responds to the request by sending the act u to the requester and asking them to return the decrypted access control token.
  • the requester's mobile terminal decrypts the act u using the subscriber's private key (stored in a secure fashion on the mobile terminal).
  • the decrypted access control token is returned.
  • the token-decode function now compares the decrypted access control token received from the subscriber with the decrypted act,ippo. If the access control tokens match, the requester is authenticated and the message content stored under the actual URL url, cooperate, can be returned to the requestor.
  • the invention provides a very effective mechanism for sending messages with content to only intended recipients. This is very advantageous for ensuring privacy and confidentiality in a range of messaging scenarios, such as communication of sensitive business information.
  • the recipient may use a land-line telephone or other communication device to pull down the content. This may occur, for example, if the functionalities of mobile and fixed phones converge in later years.
  • the token-decode function might be contained in the recipient device.
  • the embodiments described use subscriber data (MSISDN or MIN) to encode the notification. Such data is associated specifically with the user and not necessarily the user's device.
  • the MSISDN may be stored in the user's SIM card.
  • the encode function may alternatively use a device identifier such as an IMEI or GSM network.

Abstract

An MMSC generates an encoded token based on a message-locator (or part-locator) and the recipient's subscription identification. The token is inserted in the message-locator (or part-locator) field of a notification sent to the recipient. When a MMS message request is received, the MMS decodes the message-locator (or part-locator) field to authenticate the subscriber and the locator. This authentication effectively allows access from a substitute URL location included in the notification to a real URL location for the content.

Description

"MMSC Access Control"
INTRODUCTION
Field of the Invention
The invention relates to communication of rich messages having content in a mobile network environment. An example is routing of multi-media messages in which a multi-media service centre (MMSC) is used. Another example is in WAP or I-Mode in which a notification is pushed to a subscriber and the subscriber then uses a browser to pull the notified content.
Prior Art Discussion
In normal operating mode, an MMSC receives a MIME encoded Multimedia Message or E-mail message as defined by the 3GPP, WAP Forum and IETF. This message may contain multimedia elements (e.g. text, audio, video etc.). This message is stored temporarily in an MMSC message store and a notification is sent to one or more mobile device(s) indicating the message characteristics (e.g. size etc.) and a unique message-locator, which can be used to retrieve the message. The device/subscriber then retrieves the MMS message using the message-locator received in the notification.
The multimedia parts of the message may contain the actual multimedia content, or may contain a further part-locator which can be used to retrieve the multimedia content. This is typically used in applications where the multimedia content (voice / video) is too large to be stored on the device and is instead streamed from a server in the network.
United States Patent Specification No. US6246871B (Nokia) describes a method of messaging in which a notification includes a temporary access code for the stored message. Such a notification is sent to multiple recipients, who can then access the message using the temporary access code. PCT Patent Specification No. W098/58332 (Ericsson) describes a messaging method in which a notification is sent to an intended recipient, the notification having a security key.
These messaging methods provide a degree of security for the recipient by verifying the identity of the sender and limiting access to message content. However, the security is at the level of the sender or message only, and there is little control or knowledge of who is accessing the message content. This is a problem in any situation where a user wishes to notify a recipient of the location of a message or other content, and ensure that only the intended recipient will be allowed to access the content. This situation arises particularly in the context of a multi-media message delivery by an MMSC.
SUMMARY OF THE INVENTION
According to the invention, there is provided a method of communication of a rich message from a sender device to a recipient device, the method comprising the steps of:-
the sender device transmitting the message to a messaging system;
the messaging system storing content of the message, and transmitting a notification of the message to the recipient device, and
the recipient device requesting the content by accessing the messaging system and retrieving the content,
characterised in that,
the messaging system performs recipient authentication before allowing the recipient device to have access to the content. In one embodiment, the messaging system is an MMSC and the message is a multimedia message.
In another embodiment, the messaging system includes in the notification an address of a substitute location for the content, said substitute location being different from a real location at which the content is stored, and the authentication step controls access to the real location.
In a further embodiment, the locations are URLs.
In one embodiment, said notification includes a code generated by an encode function of the messaging system, and the authentication step is performed by a decode function.
In another embodiment, the encode function generates the code using recipient data.
In a further embodiment, the decode function performs authentication by decoding the recipient data and comparing it with recipient data received in the content request.
In one embodiment, the recipient data includes a recipient subscriber identifier.
In another embodiment, the recipient subscriber identifier is an MSISDN.
In a further embodiment, the encode function uses the real location address to generate the code, and the decode function determines the real location address by decoding.
In one embodiment, the code is included in a field of the substitute location address in the notification. In another embodiment, the encode function uses a secret key to generate the code, and the decode function uses said key to decode the code.
In a further embodiment, the secret key is randomly generated for each message.
In one embodiment, the encode function uses a recipient's PKI public key to generate the code and the decode function requests the recipient device to decode the code using its private key and subsequently verifies the recipient device decoding.
In another embodiment, the messaging system comprises the decode function.
In a further embodiment, the recipient device comprises the decode function.
According to another aspect, the invention provides a communication device comprising means for performing recipient device steps of a method as defined above.
The recipient device may, for example, be a multimedia-enabled mobile device.
According to another aspect, the invention provides a messaging system comprising means for performing messaging system steps of a method as defined above.
The messaging system may, for example, be an MMSC
In this specification, it is an assumption that an authentication of the subscriber access is performed at initial access to the underlying wireless data network (e.g. GPRS, 2G etc.), and the resulting authenticated subscriber identity information (e.g. IMSI, MSisdn, MIN etc.) is made available to the MMSC. This information, if available, can be used as part of an access control function in an implementation of the invention, although alternative implementations may realise access control functions that do not rely on such information.
DETAILED DESCRIPTION OF THE INVENTION
Brief Description of the Drawings
The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which Figs. 1 to 3 are message flow diagrams of messaging methods of the invention.
Description of the Embodiments
In the invention a message is communicated by:
(a) a messaging system (such as an MMSC) transmitting a notification to a recipient, the notification indicating where message content can be retrieved, and
(b) the recipient device (typically a mobile device) accessing the server storing the message content but importantly, only being allowed access to the content after authentication of the recipient.
Thus, the invention provides security at the level of the recipient. Heretofore, control of access by recipients has been achieved by transmitting the notification only to the described reciρient(s). However if the notification is wrongly routed or finds its way to a wrong recipient, or if the message location is accessed by an unintended recipient, there is inadequate control over who accesses the content despite message or sender-level security being imposed. In one embodiment, the messaging system and the content server is an MMSC. The MMSC contains a token-encode function for generation of a token using the following:
• Recipient's subscription identification • Actual MMS C message-locator or part-locator
• Optionally, a secret key
• Optionally, this secret key could be generated randomly for each message
The MMSC contains a token-decode function for extraction of the recipient subscriber identification and the actual message-locator or part-locator using the following:
• The token
• Optionally, the requester's subscription identification
• If used in generation of the token, the secret key
The design of the token-encode and token-decode functions are such that it will not be feasible in practice for a 3rd party to generate an alternative token such that the token-decode function will produce the original message-locator or message-part but with the recipient subscriber identification of the 3rd party, rather than the intended recipient.
Token Handling for message-locator
The MMSC receives the multimedia message from a content supplier indicating a need for token generation. The message is stored in the MMSC server. A token is generated using the token-encode function and is incorporated into a field used as a substitute message-locator. The substitute message-locator addresses a placeholder location (URL), the content being stored in a different, "real" URL location. The MMSC then notifies the recipient of the pending message using the substitute message-locator. At some later time, the user ("the requester", which should be the recipient), requests the message from the MMSC using the substitute message-locator. The MMSC applies the token-decode function to extract the recipient subscription identification and the actual message-locator. The MMSC then compares the recipient subsαiption identification with the subscription identification of the requester. If they match, and the message-locator identifies a valid message, the message is transmitted to the requester. Thus, the decode function effectively performs recipient authentication for controlling access from the placeholder location to the real location.
A single message may be intended for several recipients. In this case separate tokens and message-identifiers are generated for each recipient and are validated individually. The important point is that the security is at the recipient level.
Token Handling for part-locator
The MMSC receives the Multimedia Message from a content supplier indicating a need for token generation. The message is stored in the MMSC server. For each multimedia part which contains a pαrt-locαtor rather than the actual multimedia content, a token is generated using the token-encode function and is incorporated into the message as a substitute pαrt-locαtor.
When the message has been received, the user ("the requester", which should be the recipient) requests (e.g. from a streaming server) the content referenced by each pαrt-locαtor. The MMSC applies the token-decode function to extract the recipient subscription identification and each actual pαrt-locαtor. The MMSC then compares the recipient subscription identification with the subscription identification of the requester. If they match, and the pαrt-locαtor identifies a valid multimedia object, the multimedia content is transmitted (e.g. streamed) to the requester. Further examples of implementation of the invention, in which a number of alternative token-encode and token-decode mechanisms are described, are described below with reference to Figs. 1 to 3. For these examples, an implementation of the MMSC message store based on standard Web Server capabilities is assumed, i.e. message locators are implemented by URL's, and message content is downloaded using the HTTP protocol.
Token Handling to invoke a Subscriber Challenge (Fig. 1)
The MMSC receives a multimedia message from a content supplier indicating a need for token generation. The message is stored in the MMSC server under a dynamically generated URL - url,„. A token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - urls. The MMSC then notifies the recipient of the pending message using the substitute message-locator, urls.
The token-encode function used in this implementation accesses a secure database to retrieve an access control token (ACT) that is uniquely associated with the recipient, e.g. this could be a secret PIN number or password assigned to or selected by the subscriber. The access control token is encoded, along with the actual message URL url„„ using a secret key known only to the MMSC and incorporated into a field of the substitute URL urls.
At some later time, the user ("the requester", which should be the recipient), requests the message from the MMSC by invoking a HTTP GET method on the substitute URL urls. The MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL urls..
The token-decode function extracts the access control token and the actual message URL urlm using the secret key. The MMSC responds to the request by generating a challenge to the requester to enter their access control token (ACT, e.g. PIN or password). The requester returns the requested information using a HTTP POST method. For added security, this exchange could use HTTPS to ensure the access control token was not exchanged in plain-text. The token-decode function now compares the received access control token with the access control token that was decoded from the substitute URL urls. If the access control tokens match, the requester is authenticated and the message content stored under the actual URL url,„, can be returned to the requestor.
Token Handling with Comparison to Subscriber's Network Identity (Fig. 2)
The MMSC receives the multimedia message from a content supplier indicating a need for token generation. The message is stored in the MMSC server under a dynamically generated URL - urlm. A token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - urls. The MMSC then notifies the recipient of the pending message using the substitute message-locator, urls.
The token-encode function used in this implementation retrieves the recipient's network identity from the destination address of the message, e.g. this could be an MSISDN, MIN or similar identifier. The subscriber identity is encoded, along with the actual message URL url„„ using a secret key known only to the MMSC and incorporated into a field of the substitute URL urls.
At some later time, the user ("the requester", which should be the recipient), requests the message from the MMSC by invoking a HTTP GET method on the substitute URL urls. The MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL urls..
The token-decode function extracts the subscriber identifier and the actual message
URL urlm using the secret key. The token-decode function now compares the subscriber identifier provided by the network with the subscriber identifier that was decoded from the substitute URL urls. If the subscriber identifiers match, the requester is authenticated and the message content stored under the actual URL url„„ can be returned to the requestor.
Token Handling with Public Key Cryptography (Fig. 3)
The MMSC receives the Multimedia Message from a content supplier indicating a need for token generation. The message is stored in the MMSC server under a dynamically generated URL - urlm. A token is generated using the token-encode function and is incorporated into a field of a substitute message-locator, i.e. a substitute URL - url5. The MMSC then notifies the recipient of the pending message using the substitute message-locator, urls.
The token-encode function first generates a unique access control token using a suitable random function. It then retrieves the recipient's PKI certificate and uses the recipient's public key to encode the access control token - actu. The access control token is also encoded using a secret key known only to the MMSC - actm. The actual message URL urlm is also encoded using a secret key known only to the MMSC and all values are incorporated into a field of the substitute URL urls.
At some later time, the user ("the requester", which should be the recipient), requests the message from the MMSC by invoking a HTTP GET method on the substitute URL urls. The MMSC applies the token-decode function, which may be invoked as a CGI script or Java servlet associated with the substitute URL urls..
The token-decode function extracts actu. It also decodes act,,, and the actual message URL urlm using the secret key. The MMSC responds to the request by sending the actu to the requester and asking them to return the decrypted access control token. The requester's mobile terminal decrypts the actu using the subscriber's private key (stored in a secure fashion on the mobile terminal). The decrypted access control token is returned. As the access control token is a randomly generated, single use token, it is not necessary to use HTTPS for the exchange. The token-decode function now compares the decrypted access control token received from the subscriber with the decrypted act,„. If the access control tokens match, the requester is authenticated and the message content stored under the actual URL url,„, can be returned to the requestor.
It will be appreciated that the invention provides a very effective mechanism for sending messages with content to only intended recipients. This is very advantageous for ensuring privacy and confidentiality in a range of messaging scenarios, such as communication of sensitive business information.
While the invention has been described in the context of mobile networks, it is envisaged that the recipient may use a land-line telephone or other communication device to pull down the content. This may occur, for example, if the functionalities of mobile and fixed phones converge in later years. In an alternative implementation of the invention, the token-decode function might be contained in the recipient device. Also, the embodiments described use subscriber data (MSISDN or MIN) to encode the notification. Such data is associated specifically with the user and not necessarily the user's device. For example, the MSISDN may be stored in the user's SIM card. The encode function may alternatively use a device identifier such as an IMEI or GSM network.
The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims

Claims
1. A method of communication of a rich message from a sender device to a recipient device, the method comprising the steps of:-
the sender device transmitting the message to a messaging system;
the messaging system storing content of the message, and transmitting a notification of the message to the recipient device, and
the recipient device ' requesting the content by accessing the messaging system and retrieving the content,
characterised in that,
the messaging system performs recipient authentication before allowing the recipient device to have access to the content.
2. A method as claimed in claim 1, wherein the messaging system is an MMSC and the message is a multimedia message.
3. A method as claimed in claims 1 or 2, wherein the messaging system includes in the notification an address of a substitute location for the content, said substitute location being different from a real location at which the content is stored, and the authentication step controls access to the real location.
A method as claimed in claim 3, wherein the locations are URLs.
5. A method as claimed in any preceding claim, wherein said notification includes a code generated by an encode function of the messaging system, and the authentication step is performed by a decode function.
6. A method as claimed in claim 5, wherein the encode function generates the code using recipient data.
7. A method as claimed in claim 6, wherein the decode function performs authentication by decoding the recipient data and comparing it with recipient data received in the content request.
8. A method as claimed in claim 7, wherein the recipient data includes a recipient subscriber identifier.
9. A method as claimed in claim 8, wherein the recipient subscriber identifier is an MSISDN.
10. A method as claimed in any of claims 5 to 9, when dependent on claims 3 or 4, wherein the encode function uses the real location address to generate the code, and the decode function determines the real location address by decoding.
11. A method as claimed in claim 10, wherein the code is included in a field of the substitute location address in the notification.
12. A method as claimed in any of claims 5 to 11, wherein the encode function uses a secret key to generate the code, and the decode function uses said key to decode the code.
13. A method as claimed in claim 12, wherein the secret key is randomly generated for each message.
14. A method as claimed in any of claims 5 to 13, wherein the encode function uses a recipient's PKI public key to generate the code and the decode function requests the recipient device to decode the code using its private key and subsequently verifies the recipient device decoding.
15. A method as claimed in any of claims 5 to 14, wherein the messaging system comprises the decode function.
16. A method as claimed in any of claims 5 to 14, wherein the recipient device comprises the decode function.
17. A messaging system comprising means for performing messaging system steps of a method as claimed in any preceding claim.
18. A messaging system as claimed in claim 17, wherein the messaging system is an MMSC.
19. A communication device comprising means for performing recipient device steps of a method as claimed in any preceding claim.
20. A communication device as claimed in claim 19, wherein the communication device is a multimedia-enabled mobile device.
PCT/IE2002/000139 2001-09-28 2002-09-30 Mmsc access control WO2003030474A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002343183A AU2002343183A1 (en) 2001-09-28 2002-09-30 Mmsc access control

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US32520401P 2001-09-28 2001-09-28
US60/325,204 2001-09-28
EP01650118.1 2001-10-08
EP01650118 2001-10-08

Publications (2)

Publication Number Publication Date
WO2003030474A2 true WO2003030474A2 (en) 2003-04-10
WO2003030474A3 WO2003030474A3 (en) 2003-12-11

Family

ID=27635774

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IE2002/000139 WO2003030474A2 (en) 2001-09-28 2002-09-30 Mmsc access control

Country Status (3)

Country Link
AU (1) AU2002343183A1 (en)
IE (2) IES82842B2 (en)
WO (1) WO2003030474A2 (en)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004112368A2 (en) * 2003-05-23 2004-12-23 Heyanita, Inc. Transmission of a data file by notification of a reference to the intended recipient and teleconference establishment using a unique reference
EP1523165A2 (en) * 2003-10-06 2005-04-13 Microsoft Corporation Internet-based event notification
DE102004003593A1 (en) * 2004-01-15 2005-08-04 Deutsche Telekom Ag Sending user-specific data based on WAP or HTML protocols involves determining characteristics of user/terminal sending URL information, analyzing for tokens, replacing with user/equipment-specific data for sending to service provider
EP1562342A1 (en) * 2004-02-05 2005-08-10 France Telecom Method for processing a multimedia message
WO2006021170A1 (en) * 2004-08-23 2006-03-02 Daybyday Media Gmbh Method and device for the secure transmission of emails
EP1643744A1 (en) * 2004-10-04 2006-04-05 Alcatel Method for transfering video data to several users in an MMS-network
CN100334896C (en) * 2004-03-13 2007-08-29 乐金电子(中国)研究开发中心有限公司 Multimedia note service information transmitting-receiving system and signal transmitting-receiving method
CN100372391C (en) * 2004-08-16 2008-02-27 华为技术有限公司 Multimedia message system and method for transmitting multimedia message
CN100456771C (en) * 2005-12-23 2009-01-28 华为技术有限公司 Communication device and its interactive method between modules
US7508132B2 (en) 2003-10-20 2009-03-24 Hewlett-Packard Development Company, L.P. Device having a getter structure and a photomask
US7603697B1 (en) * 2003-05-30 2009-10-13 Cellco Partnership Method and system for securely delivering authentication-related data
RU2465741C2 (en) * 2008-03-18 2012-10-27 Хуавэй Текнолоджиз Ко., Лтд. Method, system and device for implementing multimedia messaging service
WO2013028589A1 (en) * 2011-08-23 2013-02-28 Zixcorp Systems, Inc. Multi-factor authentication
US8396928B2 (en) 2007-09-21 2013-03-12 Smartbrief, Inc. Methods and systems for handling electronic message content for electronic communications devices
US8407296B2 (en) 2007-09-24 2013-03-26 Smartbrief, Inc. Multiple and multi-part message methods and systems for handling electronic message content for electronic communications devices
CN104378744A (en) * 2013-08-13 2015-02-25 中兴通讯股份有限公司 Service delivery method and device and service request method and device
WO2020205297A1 (en) * 2019-04-02 2020-10-08 Microsoft Technology Licensing, Llc Verification of caller location for use in assigning location-based numbers

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000042748A1 (en) * 1999-01-14 2000-07-20 Tumbleweed Communications Corp. Web-based delivery of secure e-mail messages
WO2001017165A2 (en) * 1999-08-31 2001-03-08 Tumbleweed Communications Corp. Solicited authentication of a specific user
US6246871B1 (en) * 1999-09-24 2001-06-12 Nokia Networks Oy Method and apparatus for providing access of messages to multiple recipients in cellular networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000042748A1 (en) * 1999-01-14 2000-07-20 Tumbleweed Communications Corp. Web-based delivery of secure e-mail messages
WO2001017165A2 (en) * 1999-08-31 2001-03-08 Tumbleweed Communications Corp. Solicited authentication of a specific user
US6246871B1 (en) * 1999-09-24 2001-06-12 Nokia Networks Oy Method and apparatus for providing access of messages to multiple recipients in cellular networks

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004112368A2 (en) * 2003-05-23 2004-12-23 Heyanita, Inc. Transmission of a data file by notification of a reference to the intended recipient and teleconference establishment using a unique reference
US8161116B2 (en) 2003-05-23 2012-04-17 Kirusa, Inc. Method and system for communicating a data file over a network
WO2004112368A3 (en) * 2003-05-23 2005-05-26 Heyanita Inc Transmission of a data file by notification of a reference to the intended recipient and teleconference establishment using a unique reference
US7483525B2 (en) 2003-05-23 2009-01-27 Navin Chaddha Method and system for selecting a communication channel with a recipient device over a communication network
US7277697B2 (en) 2003-05-23 2007-10-02 Adesh Desai Method and system for establishing a teleconference over a telephony network
US7603697B1 (en) * 2003-05-30 2009-10-13 Cellco Partnership Method and system for securely delivering authentication-related data
EP1523165A3 (en) * 2003-10-06 2006-10-18 Microsoft Corporation Internet-based event notification
EP1523165A2 (en) * 2003-10-06 2005-04-13 Microsoft Corporation Internet-based event notification
US7508132B2 (en) 2003-10-20 2009-03-24 Hewlett-Packard Development Company, L.P. Device having a getter structure and a photomask
DE102004003593B4 (en) * 2004-01-15 2016-05-12 Deutsche Telekom Ag Method for transmitting user-specific data based on the WAP or HTML protocol
DE102004003593A1 (en) * 2004-01-15 2005-08-04 Deutsche Telekom Ag Sending user-specific data based on WAP or HTML protocols involves determining characteristics of user/terminal sending URL information, analyzing for tokens, replacing with user/equipment-specific data for sending to service provider
EP1562342A1 (en) * 2004-02-05 2005-08-10 France Telecom Method for processing a multimedia message
CN100334896C (en) * 2004-03-13 2007-08-29 乐金电子(中国)研究开发中心有限公司 Multimedia note service information transmitting-receiving system and signal transmitting-receiving method
CN100372391C (en) * 2004-08-16 2008-02-27 华为技术有限公司 Multimedia message system and method for transmitting multimedia message
US8527007B2 (en) 2004-08-16 2013-09-03 Huawei Technologies Co., Ltd. Multimedia message system and method for sending multimedia message
US8559945B2 (en) 2004-08-16 2013-10-15 Huawei Technologies., Ltd. Routing function multimedia message service gateway
WO2006021170A1 (en) * 2004-08-23 2006-03-02 Daybyday Media Gmbh Method and device for the secure transmission of emails
EP1643744A1 (en) * 2004-10-04 2006-04-05 Alcatel Method for transfering video data to several users in an MMS-network
CN100456771C (en) * 2005-12-23 2009-01-28 华为技术有限公司 Communication device and its interactive method between modules
US8396928B2 (en) 2007-09-21 2013-03-12 Smartbrief, Inc. Methods and systems for handling electronic message content for electronic communications devices
US8407296B2 (en) 2007-09-24 2013-03-26 Smartbrief, Inc. Multiple and multi-part message methods and systems for handling electronic message content for electronic communications devices
RU2465741C2 (en) * 2008-03-18 2012-10-27 Хуавэй Текнолоджиз Ко., Лтд. Method, system and device for implementing multimedia messaging service
WO2013028589A1 (en) * 2011-08-23 2013-02-28 Zixcorp Systems, Inc. Multi-factor authentication
US8984605B2 (en) 2011-08-23 2015-03-17 Zixcorp Systems, Inc. Multi-factor authentication
US9509683B2 (en) 2011-08-23 2016-11-29 Zixcorp Systems, Inc. Multi-factor authentication
CN104378744A (en) * 2013-08-13 2015-02-25 中兴通讯股份有限公司 Service delivery method and device and service request method and device
EP3035717A4 (en) * 2013-08-13 2016-08-17 Zte Corp Method and device for service provision, and method and device for service request
WO2020205297A1 (en) * 2019-04-02 2020-10-08 Microsoft Technology Licensing, Llc Verification of caller location for use in assigning location-based numbers
US11350283B2 (en) 2019-04-02 2022-05-31 Microsoft Technology Licensing, Llc Verification of caller location for use in assigning location-based numbers

Also Published As

Publication number Publication date
IES20020779A2 (en) 2003-04-16
WO2003030474A3 (en) 2003-12-11
IE20020780A1 (en) 2003-04-16
IE83599B1 (en) 2004-09-22
IES82842B2 (en) 2003-04-30
AU2002343183A1 (en) 2003-04-14

Similar Documents

Publication Publication Date Title
EP3008935B1 (en) Mobile device authentication in heterogeneous communication networks scenario
US9768961B2 (en) Encrypted indentifiers in a wireless communication system
EP2062457B1 (en) Mobile application registration
JP4782139B2 (en) Method and system for transparently authenticating mobile users and accessing web services
US6944760B2 (en) Method and apparatus for protecting identities of mobile devices on a wireless network
US7721326B2 (en) Automatic authentication selection server
WO2003030474A2 (en) Mmsc access control
US20060262929A1 (en) Method and system for identifying the identity of a user
US8156340B1 (en) System and method for securing system content by automated device authentication
WO2010094331A1 (en) Authentication to an identity provider
EP1314278A2 (en) End-user authentication independent of network service provider
WO2011113314A1 (en) Service open method, system and service open server
FI116654B (en) A method for user authentication
CN103973543B (en) Instant communicating method and device
US10028141B2 (en) Method and system for determining that a SIM and a SIP client are co-located in the same mobile equipment
EP2096828B1 (en) Method and management unit for managing access to data on a personal network
EP3032448B1 (en) Method for authorizing access to information in a telecommunication system
KR100463751B1 (en) Method for generating packet-data in wireless-communication and method and apparatus for wireless-communication using that packet-data
US20100255811A1 (en) Transmission of messages
FI107865B (en) Method and arrangements for handling of messages in a telecommunication system
EP2399408A1 (en) Authentication to an identity provider
MXPA06005074A (en) Authentication and update of the generation of session keys between a service network node and at least one communications terminal with the aid of an identification card

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP