PT1500289E - Secure messaging via a mobile communications network - Google Patents

Abstract

A method of transmitting a message via a mobile telecommunications network from a sender's device to a user's terminal where the user is required to acknowledge message receipt in a predetermined way and authenticate himself by providing authentication data that is centrally authenticated, where an acknowledgement message is subsequently transmitted to the message sender and where at least a portion of the text message is encrypted by the sender's device before transmission and decrypted by the receiving terminal before display and where encryption data used for encryption and decryption of the message, is transmitted with the encrypted message. The message may be a text message, SMS, USSD, MMS and further security may be obtained by use of public/private key pairs wherein the public key is valid only for a certain number of text messages. The method may employ transaction reference counters in the devices to provide extra security and may also arrange for deletion of a received message after a set time.

Description

ΕΡ 1 500 289 / ΡΤ

DESCRIPTION " Safe messaging over a mobile communications network " The invention relates to a method of transmitting messages through a mobile communications network. More particularly, but not exclusively, the invention relates to methods of transmitting SMS text messages from the GSM system in a secure manner.

For mobile device users, SMS text messaging provides a fast and convenient method of sending and receiving messages. Messages are transmitted through a message exchange center. If messages can not be sent to the handset, they are stored in the message exchange center until they can be delivered. However, it may happen that the messages eventually reach " timeout " Without previous warning. SMS also provides a rarely used option of sending 'lightning messages', which appear immediately on the device, without requiring user interaction to read them. The SMS standard also supports E-mail (through X-400 protocols) and both binary and text-based data.

Conventional short messages such as the SMS service on GSM systems have the drawback that the service is unsuitable for many applications, such as e-commerce or other applications, where safe and controlled data delivery is required. The following are some of the reasons why the conventional short messaging service is not suitable for secure data delivery.

Firstly, the sender of a message is not normally informed if the message was delivered to the mobile receiving terminal and was received by the user. The GSM system also provides for the exchange of acknowledgment messages, where a acknowledgment is transmitted 2 ΕΡ 1 500 289 / ΡΤ to the sender of the message as soon as the message is delivered to the message exchange center. However, the sender can not know whether the message reached the handset, and more particularly whether the message actually reached the user to which the message was intended.

Secondly, the data transmitted through SMS can be decoded by third parties with a suitable digital receiver. In addition, messages are usually stored in the handset memory. Thus any third party gaining access to the terminal can read the messages.

Thirdly, the user of a mobile terminal can not, in many cases, necessarily be identified. In particular, by transmitting an SMS message over the Internet or other delivery mechanisms, the identity of the sender of the message may be hidden from the receiving user, or the recipient of the message may not be intended by the sender. It is an aspect of the present invention to obviate some or all of the disadvantages described above by providing systems according to the features of independent claims 1 and 2

Further aspects and advantages of the invention will be appreciated, by way of example only, from the following description and the accompanying drawings, in which: FIG. 1 is a schematic outline of a mobile telecommunications network according to the GSM standard, in which the present invention may be implemented; FIG. 2 is a schematic diagram illustrating the parts participating and the communications between these parts, in accordance with one embodiment of the present invention; FIG. 3A is a schematic diagram illustrating the format of a conventional SMS message, in accordance with the prior art and FIG. 3B is a schematic diagram which shows the format of an extensive SMS message in accordance with another embodiment of the present invention; FIG. 4 is a flowchart illustrating the process of transmitting a message, in accordance with a further embodiment of the present invention; FIG. 5 is a flowchart illustrating the software upgrade process, in accordance with another embodiment of the present invention; FIG. 6 is a flowchart illustrating the process of an e-commerce transaction using the extensive message exchange method according to yet another embodiment of the present invention, and FIGS. 7A and B are flow charts illustrating the process of transmitting a message, in accordance with yet a further embodiment of the present invention.

In FIG. 1 is a schematic outline of a mobile telecommunications network, in accordance with the GSM standard. A mobile switching center (MSC) is connected via communication junctions to a number of base station controllers (BSCs). The BSCs are geographically dispersed in areas served by the mobile switching center 2. Each BSC 4 controls one or several base transceiver stations (BTS) 6 located distant, and connected by additional communication junctions to the BSC 4. Each BTS 6 transmits radio signals to and receives signals from the mobile stations 8, which are in an area served by the BTS 6 The area is referred to as a " cell ". The GSM network is provided with a large number of such cells, which are ideally continuous, so as to provide continuous coverage throughout the network territory. The mobile switching center is provided with a home location register (HLR) 12, which is a database which stores the subscriber data. The SMS messages are sent through a short message service center (SM-SC) 14. The MSC 2 is connected to the SM-SC 14 via an SMS access port 16. Such access ports exist 4 ΕΡ 1 500 289 / ΡΤ for the short messages of mobile terminals and also for the short messages of mobile origin.

If it is a short message to be transmitted from a mobile terminal 8 to its final destination, the terminal 8 establishes a signaling connection to the MSC 2 and the message is subsequently transmitted through the SMS access port 16 to the SM-SC 14. From there, the message is then delivered to its final destination, which may, for example, be another mobile terminal or a mailbox. The GSM system provides an acknowledgment of delivery receipt, which indicates that the SM-SC received the message from a handset. However, the GSM system does not support an automatic acknowledgment to indicate whether the message has reached its final destination.

A short message which is addressed to a handset 8 is first routed to the SM-SC 16. The message may be transmitted to the SM-SC 16 by another mobile terminal, or other suitable means, such as the network a public switched telephone network PSTN 18 and a human operator, or via the Internet 20. The short message is subsequently transmitted to the SMS access port 16 and sent to the relevant MSC 2, which delivers it to the mobile station 8. Delivery on mobile station does not involve the user.

However, if the mobile station can not be reached then the message is held in the SM-SC 14 and delivered to the mobile terminal as quickly as possible. Usually, a process is started " alert " which notifies the SM-SC 14, when the terminal is connected to the mobile communications network.

All systems described above are commercially available products, which need not be described in more detail.

In the following the aspects of the different embodiments of the present invention will be summarized. It will be appreciated that these aspects can be implemented individually or in any combination. 5 ΕΡ 1 500 289 / ΡΤ extens The extensive message exchange method uses a conventional messaging structure through a mobile communications network, such as the SMS structure in GSM systems. However, the method provides additional features, which are implemented in the software. Applications are running on the participating servers or terminals, such as software applications. Thus, no modification of the hardware of the user terminal or of the underlying messaging protocol, such as the SMS messaging protocol, is required to implement the extensive messaging method.

In the method of extensive message exchange the receiving user has to confirm the reception of a transmitted message. When the message has reached the receiving terminal (RT), the receiving user (RU) needs to act and the sender of the message is subsequently informed if the RU has acted and therefore whether the message has actually reached the user. In one embodiment of the extensive message exchange method, the RU needs to act in order to be able to display the message after it has reached the RT. If the sender does not receive a reply, the message is automatically sent again. You can set the number of times the message is sent again.

In the extensive messaging method users communicate through a central authentication system (AS). Such AS may be implemented using a conventional server or computer and a system capable of communication over the mobile communications network. Each user must register with the AS before using the extensive messaging service. The extensive message exchange method automatically generates a formatted message or response, from the data and information that the user enters. Only a minimum of the input is required and the interface provided requires little or no user training. The system then brings the response data to the required format, so that a user can use all the desired options, which allow increased security in a simple and user-friendly manner. The text to be submitted, using the extensive message exchange method, is automatically encrypted. Again, a minimal user input is required and only a minimal number of messages is required, while at the same time a high security standard is achieved. Text can be encrypted using a specific public key for the transmission of a message (or a message response pair). According to the extensive message exchange method, the public key, which is used for encryption / decryption, is subsequently transmitted in an unencrypted manner, together with the encrypted text message in one and the same message. A private key, which complements this public key and is also specific to the transmission of this message, can be used at the sender's terminal to encrypt the message. This public-private key pair, which is specific to a communication, is referred to in the following as a pair of message keys or a message key. The RU maintains an additional private key in its terminal to decrypt the transmitted message and encrypt any possible response to that message. The private key stored in the UK terminal is not specific to the communication in progress.

Alternatively, the AS generates a public and private message pair of keys prior to a communication or transmission requested by a user and sends the public message key to the user terminal. The AS stores as the private message key for future use. Upon receipt, the user's terminal stores the public key pair of message.

If the user wishes to send a secure message, the public message key is used to encrypt the message text, together with the user-specific private key, stored in the user's terminal. The message key is thus directly available, and does not need to be transmitted before sending a secure message, but after transmission of an extensive format message has been requested by the user. The public key of 7

The message may, for example, be transmitted in a first message (or reply message) from the AS to the user's terminal for use in a second message.

To improve security, the user may request that a reply be sent to the sender of the message before the message is actually displayed to the UK. If this reply message can not be delivered to the sender, the terminal will try again to send the reply message. If this response message can not be delivered after a predetermined number of retries, the original message is not displayed to the RU but is cleared from the RT. The user may also choose to store or delete any response to the transmitted message. If the response is not stored any memory that temporarily holds the reply message is deleted immediately after the reply message has been transmitted from the RT.

Referring now to FIG. 3, there is shown the format of a conventional SMS message and an extensive SMS message in accordance with an embodiment of the present invention. The SMS message format according to the prior art (FIG.3A) contains a header 201 and a body of text 202. The header includes a field 206, which identifies the type of SMS message, a parameter 207, which identifies the service provider, and parameters 208 and 209 that respectively identify the source and distribution address. The format typically allows the transmission of a text body of 140 or 160 bytes 202.

Referring now to FIG. 3B, the format of the extended message is described. The extended message also contains the header 201 and text body 202, and is therefore completely compatible with the conventional type. However, text body 202 includes an additional header 203, specific to the extended message format, which is incorporated into the body of conventional text 202. The remaining capacity of text body 202 is available as text body 204 of extensive format. The text body 204 of the extended format is therefore reduced in length 8 Ρ Ρ 1 500 289 / ΡΤ as compared to the text body 202 of the conventional type. The extensive format may be identified using field 206 that identifies the type of SMS message of conventional header 201. In the case of the extended format can not be identified in this manner, an additional header will be required to identify the message type for the terminals. FIG. 3B further illustrates the individual fields 211 to 218 of the additional header 203, in accordance with one embodiment. The first 8-bit field contains the type of message exchange service. The value in this field defines the method used to encode the text body 204. The 1 bit field 212 indicates that the RU is required to act before the message text is displayed. Field 213 determines the maximum number of retries, which can be used to deliver the message to the UK. The 2-bit field allows up to 4 retries to be required. In field 214 (1 bit) the user may request that the reply be transmitted to the sender of the message, before the message is displayed. If the reply message can not be delivered to the sender, after a predetermined number of retries, the terminal does not display the original message to the sender. Field 215 (1 bit) determines whether any possible response messages are stored in the RT in a " sent messages " folder.

If the response is not required to be stored, then the terminal will clear any memory that retains the response immediately after the reply message has been transmitted. Field 216 stores the information about the software version such that the software versions of the installed terminal software of the sender and the receiving user can be compared. 1 byte is reserved for this field. The 3-bit field 217 is reserved for future use. In field 218 the public key, specified for this transmission in progress, is transmitted in the message header 203 from the sender to the RU. This public key and a corresponding private message key was used for the encryption of the text body of the transmitted message. RT will extract the key and use it to decrypt the body of the text and can also use it for encrypting a response. There are 9 ΕΡ 1 500 289 / ΡΤ reserved 128 bits for field 218. However, fewer bits can be used for the transmission of the public key. The extensive message exchange method ensures that not only the terminals participating in a transaction or the transmission of the information, but also the user of the terminals are known or identified. A central AS checks the identity of each service user of the extensive messaging method before offering access to it. Any user who wishes to use the extensive messaging service needs to register with the AS. The AS is responsible for ensuring that the user is known to the AS and the AS verifies the identities of the users according to a predefined and published standard. The AS asks for the identification data of a user who registers and stores the user's data in a secure way. The identification data normally contains the name, address, IMSI and a personal password, or a personal identification number (PIN), chosen by the user or other appropriate safety data. The identification data may also contain relevant safety data about any previous user transactions through the AS.

At registration, the AS then generates a personal and public key pair for each user. It stores the public key in conjunction with the user's data in the secure data store and communicates the private key to the user. The private key may, for example, be communicated using the software update process, as will be described below, with reference to FIG. 5.

Referring now to FIG. 4, the process of transmitting an extensive message from a source user (OU), through an AS to an RU, will be described.

At step 302 the OU contacts the AS and requests an extensive message, for example, by sending a conventional SMS message from the originating terminal (OT). The request is transmitted to the AS in step 304. The AS then checks whether the 10 ΕΡ 1 500 289 / ΡΤ OU is a registered user and verifies the identity of the user (step 306).

At step 308 the AS extracts the identity data stored for the OU, such as the PIN and a private key specific to the OU. AS generates a public key, specified for data transmission, for the extensive message requested in step 309, and transmits the public key through a conventional SMS to the OU (step 310). The TO then automatically generates a message according to the default long message format (step 311). The definitions of fields 211 to 217 may be predefined by the user or may be entered by the user specifically for the extensive message to be transmitted. The OT requests the text to be transmitted and the UK IMSI number, as in a conventional SMS message. In addition, the OT requests a PIN for authorization of the OT user (step 312). The OR enters the requested data at step 314 and the TO encrypts the body of the message text and PIN using the public key received at step 310 and a private key received at registration. The message generated does not include a public key, so field 218 is empty. At step 318 the OT transmits the extended message to the AS. AS extracts the PIN and text body of the received extensive message and decrypts the data (step 320), using its private key extracted in step 308 and the public key, which was generated by the AS in step 309 and transmitted to the OU in step 310. At step 322, the AS compares the received and decrypted PIN in steps 318 and 320 with the PIN extracted from the secure user database at step 308.

If the PINs do not match at step 322, the AS may send a new message to the OU requesting a PIN for authorization. The user can enter the PIN a second time, the TO encrypts the PIN and steps 318 to 322 are repeated. The process can be repeated until the PIN is entered, but the possible retry numbers are predetermined by the AS. If the maximum number of retries is reached, the process is aborted (step 324). 11 ΕΡ 1 500 289 / ΡΤ

If the ΡΙΝ matches at step 322, the process proceeds to step 326. The AS extracts the IMSI number from the RU from the message received at step 318 and verifies that the RU is a registered user and verifies the identity of the RU in step 326. The AS extracts the related data from the database UK at step 328. This data includes a public key specific to the RU and further includes a PIN provided by the RU at registration. The data may also include the preferred definitions, as defined by the UK.

At step 330 AS generates a public and private key pair for the ongoing communication with the RU. At step 332 the AS then encrypts the body of the message text received from the OU at step 318 using the user-specified public key extracted at step 328 and the specific transaction private key generated at step 330. At step 334 the AS then generates a message in the extensive message format, as described above, and transmits the message to the UK handset.

The extensive SMS message data fields 211 to 217 are set according to the predefined settings in the user data store or can be specified by the OU specifically for the message to be transmitted and according to the information-specific security requirements to be transmitted. The terminal receives the SMS message and identifies from the header 201 that the received message is a message of the extensive format. The RT extracts and interprets the additional header 203 and extracts the public transaction key transmitted in step 336. If the additional header field 212 is set, then the RT requests a PIN number for the user identification before the message is displayed to the user (step 340). After the RU enters its PIN number at step 342, the RT encrypts the PIN at step 344 using the transmitted public key and its private key and transmits the PIN in an SMS message to the AS (step 346).

At step 348 AS decrypts the transmitted PIN, using the public transaction key and its extracted private key at step 328. At step 350, the AS checks the inserted pin 12 ΕΡ 1 500 289 /,, comparing it with the specific PIN of the stored in the user's secure data store to verify that the data matches. If the data does not match, the AS may send a message to the RT requesting the correct PIN. The AS determines the number of retries possible before the process is aborted. If the PIN is successfully verified, the AS sends a confirmation message to the RT in step 352. The RT then extracts its private key and decrypts the text body 204 using the transmitted public transaction key and its private key in step 353.

Upon receiving this RT confirmation message then displays the decrypted text message at step 354. The user can then read the text body of the message and may wish to reply to the message. For the response, the user needs to enter the response data in step 356 and press a " submit " the terminal. The RT then automatically generates a message according to the extensive message exchange method. The RT encrypts the response using its private key and the public transaction key transmitted in step 334. Fields 211 to 217 are automatically set according to predefined values or the same values are used as in the SMS message of step 334. RT transmits the reply message to the AS in step 358. Upon receipt of the encrypted response of the user, the AS decrypts the body of the response text using its private key and the public key of the RU in step 360. Subsequently, AS transmits the response to the OU, similar to steps 328 to 354. It is described in the following additional process steps, which will be executed if field 214 of additional header 203 is set. The RT requests, encrypts and transmits the PIN as described above in steps 338 to 346. The AS decrypts and verifies the PIN and decrypts the received message, as described with reference to steps 348 to 353. However, AS then generates message to the OU to further confirm the origin of the message. This response message transmitted from the AS to the OU requests an acknowledgment from the OT. 13 Ε 1 500 289 / ΡΤ

If the AS can not deliver the reply message or does not receive a acknowledgment message, which confirms receipt of the reply message by the OT, then the AS tries again after a predetermined time interval to deliver the reply message a predetermined number of times, or until the AS receives an acknowledgment message from the OT. If the receiver does not finally receive a acknowledgment message, then the AS sends a message to the RT, which notifies the RT of the negative result of the response message. In this case, the RT does not display the message to the RU, but properly notifies the user.

If the AS receives an acknowledgment message from the TO, the AS notifies the RT of the acknowledgment reply message in conjunction with the message of step 352 and subsequently decrypts and displays the message to the RU as described above, with reference to steps 303 and 354.

An additional layer of security can be added if the PIN number itself is part of the encryption algorithm. In this case, the AS extracts the UK PIN number in step 308 and encrypts the text data to be sent to the UK, using the PIN, the transaction public key, and the AS private key. The message can only be decrypted and displayed after the user enters the correct PIN number.

Turning now to FIG. 7, the process of transmitting an extensive message from a source user to an AS will be described, according to another embodiment of the present invention. The process begins with an initiation process (steps 370 to 376), which is executed only once, before any extensive messages are transmitted between the user and the AS. At step 370, AS creates a public and private key pair, which must be used for encrypting a message or a message response pair. The AS stores the private key in the AS database (step 372) and sends the public key to the TO (step 374). In step 376 the OT receives 14 ΕΡ 1 500 289 / ΡΤ the public key and stores the same for future use. The public key is stored in a secure way, for example, inside an electronic purse of the device.

If the OU wants to send a secure message, the user requests an extensive message (step 378) by pressing a preset key or a key combination. The TO then automatically generates a message according to the predefined extensive message format and provides the OU with a screen for inserting the OU message (step 380). At step 381, the user enters the text of the message. The OT then requests the PIN and the destination of the message (step 382) and the OR inserts the requested data in step 383. At step 384 the OT encrypts the message, using the stored private key and the public message key, received from the AS in step 374 of the initiation process. The OT sends the extended format message to the AS at step 386. Upon receipt of the message, the AS decodes the message at step 388 and further processes the message, for example by sending the message text as an additional format message (see steps 326 to 360 of Figure 4B). For further communication with the TO, the AS subsequently discards the pair of message keys and generates a new pair of message keys at step 390. If a response is to be transmitted from the AS to the TO, the AS encrypts the response (step 392) using the public key specified for the TO and the private message key generated in step 390. The AS sends the public message key together with the encrypted response to the TO (step 394). At step 396, the OT decodes the response message, using the private key, specifies for the OT, and stored therein. The public message key, transmitted from the AS to the TO in step 394, is stored in the apparatus for future use, as in the initiation step 376. If the OU now wishes to send a secure message of the extensive message format, the user may request directly to send such a message as described above with reference to step 378. The initiation steps 372 to 376 do not have to be performed since the message key pair has already been generated in the AS (at step 390) and transmitted to the OT (at step 394), during the processing of the last extensive message. 15

ΕΡ 1 500 289 / PT

If the message sent in step 386 of the TO to the AS does not require a response, the AS transmits a message, which includes the message public key, but without a text message, at step 394. The TO then stores the public key of message as described with reference to step 398 above.

By the use of an extensive message, as described above with reference to FIG. 7, the user may directly send a secure encrypted message with a public and private key pair specific to a message or a pair of message-response messages, without contacting the AS pair for sending the message (as described with reference to Figure 4A).

Turning now to FIG. 5, the process of updating the software applications for the extensive message exchange method is described.

As described above, field 216 of header 203 includes information about the software version used to generate the message. When the RT interprets the data from the 203 header, the RT compares the software version stored in the RT with the version indicated in field 216. If the information does not match, the RT contacts the AS for a software update. The RT can process the transmitted message, although a mismatch has been detected if the software versions are compatible. In case they are not compatible, RT will reject the message. The AS will then delay the retransmission of the message until the updated software has been supplied to the RT.

For updating the software, the user contacts the AS via a predefined path at step 402, for example using a conventional SMS message. At step 404, the AS checks the details of the user. Subsequently, the AS sends the software update via an SMS message to the RT (step 406). The software version and also the service type are specified in the message. At step 408 the RT checks whether the software actually originated from the AS. This can be done, for example, by comparing the IMSI number 16 ΕΡ 1 500 289 / ΡΤ of the RT, contacted at step 402, with the IMSI number, from which the software update originated. If the source of the software update can not be verified, the user is alerted immediately and the process is stopped. However, if the sender is successfully verified, the RT subsequently decompresses the software (step 410). At step 412 the RT displays a notification about the software update to the user and requests the user's conventional PIN for access to the handset if the PIN identification is implemented. The RT checks to see if a valid PIN has been entered (step 414). If the PIN was not entered or is incorrect, the RT allows a predetermined number of retries. Upon successful verification of the PIN, the RT sends a message to the AS acknowledging receipt of the software update (step 416). The RT then stores the software in its memory and automatically updates the application software at step 418. The RT notifies the user at step 420 that the software update is complete. The extensive message exchange method is also advantageous for other applications in which a reliable and reliable transmission of data is required.

In another embodiment the security of the extensive message exchange system is enhanced by the inclusion of a transaction reference counter. The transaction reference counter is installed on both the AS and the user's terminal. The AS has a transaction reference counter, specific for each registered user terminal. Whenever a message is successfully received, the transaction reference counter is incremented in the AS and in the user's terminal. The transaction reference is included in each message transmitted from the user to the AS, either as part of the encrypted message body or in the message header. The transaction reference counter of the user terminal and the AS (specific to the particular user) must always be synchronized so that the message is 17

ΕΡ 1 500 289 / PT. The AS compares the transaction reference of its counter to the given user terminal, with the transaction reference, received from the user's terminal. The AS will only respond correctly if the OT message contains a transaction reference that matches the transaction reference counter for the given user terminal.

If the transaction references do not match, the AS disables the extended messaging service until the mismatch is resolved. The transaction reference at a user terminal is defined in a startup procedure, when the software is downloaded from the AS to the terminal. The transaction reference is only transmitted in the extensive messages from the user terminal to the AS, but not from the AS to the user's terminal (except in the initialization procedure during software download). Instead, both transaction reference counters (on the user and AS terminal) maintain their own internal counters. This provides additional safety.

In the following, an electronic commerce transaction, which uses the extensive message exchange method with reference to FIG. 2. In such a scenario, a merchant or service provider has a server 101 with an Internet connection 103, through which it offers goods or services. A user accesses the merchant's server via the Internet 103 through a computer, or a mobile terminal, or other suitable device, and selects and requests goods or services. The communications, for making the payment and for sending the confirmations, are performed through the central AS 107. The merchant communicates with the AS through a secure channel and the AS communicates with the user using the extensive message exchange method through of the mobile communications network using terminals 105. 18 ΕΡ 1 500 289 / ΡΤ

In FIG. 6 the individual process steps are illustrated. After the user has selected and ordered the required goods or services, the merchant contacts the AS through a predetermined secure channel and makes an authentication request at step 502. The trader also communicates the details of the purchase to the AS. The AS then verifies the identity of the merchant in step 504. The AS extracts the name or IMSI of the consumer from the data reported by the merchant and verifies the identity of the consumer in step 506. If the AS can not identify either the identity of the merchant or the the process is aborted.

If both identities have been verified, the AS then generates a message (step 508) based on the information reported in step 502. The message may, for example, contain details about the selected goods or services and / or details about the payment of the goods or services. The message is then generated, transmitted to the user and verified as described above, with reference to FIG. 4B in steps 326-354. The user may then enter the response data to the secured message in step 512, such as payment and / or confirmation details regarding the method of payment.

Again, an extensive message is generated in the RT and transmitted to the AS (step 514). The AS decrypts the message at step 516. To further enhance security, the AS must send a commit response to the merchant (step 518 and 522) over a predetermined secure communications channel. The merchant is then prompted to respond to this confirmation message (step 524). This ensures that the transaction can only be performed if both legitimate parties have agreed to the transaction, ie after the merchant confirms receipt of the confirmation message. The AS then pays the purchase at step 526. The extensive message exchange method can also be used in voting systems over a mobile communications network. A PIN is provided to pre-registered users, or a regional or national selection of registered users, which is randomly generated 19 ΕΡ 1 500 289 / ΡΤ in AS. These numbers are subsequently sent to the users as an extensive message message, which requests a receive acknowledgment response as described above. After the AS receives the acknowledgment message, it activates the PINs.

On election day, an additional extensive message exchange method is sent to registered users. This message contains a choice of candidates and asks for the PIN as previously transmitted. The user may then respond, using an extensive message response, as described above, in a secure manner. Exactly such a message is sent per user and the PIN prevents unauthorized voting.

Other possible applications for the extensive message exchange method include a secure method of access, for example, to a computer system or building. The user requests an access code from the AS through the mobile communications network. The AS subsequently verifies the identity of the requesting user and transmits an access code in a secure message. An alternate PIN may be entered by the user to indicate that he is being coerced or is in danger, thereby alerting the relevant authorities without compromising user safety.

While in the embodiments described above SMS messages are described in accordance with the GSM standard, it should be appreciated that other methods of exchanging messages over mobile communications networks, such as MMS multimedia messaging) and USSD (unstructured supplementary service data).

While the above described embodiments are implemented in the method of extensive message exchange in software applications running on the terminals of the mobile communication system, it should be appreciated that the method may alternatively be implemented as a " SIM Toolkit ". The " SIM Toolkit " or " SIM Application Toolkit " prolongs the role of the SIM card and allows the SIM card to be programmed to perform new functions. 20

ΕΡ 1 500 289 / PT

It is to be understood that the embodiments described above are only preferred embodiments. Namely, various features may be omitted, altered or substituted by equivalents, without departing from the scope of the present invention, which is defined in the appended claims.

Lisbon, 2009-12-09

Claims (24)

An authentication system for transmitting information, wherein said authentication system stores identification information of a plurality of provider users and a plurality of receiving users and is adapted to: receive information from at least one of said supplier users; authenticating said at least one provider user (326), and transmitting a message, including said information through a mobile communications network to a mobile terminal of the receiving user; which is further adapted to: extract a public key, specifies to said receiving user, said stored identification information and use said user specific public key for encrypting said at least part of said message; providing a public and private key pair of communication-specific keys, valid only for a single communication between the authentication system and said receiving user (330), wherein said communication comprises a message and a response thereto (334, 358) ; encrypting at least part of the message to be transmitted using said communications specific key and sending said communications specific public key to said receiving user as part of said message. ΕΡ 1 500 289 / ΡΤ 2/5 An authentication system for transmitting information, wherein said authentication system stores the identification information of a plurality of provider users and a plurality of receiving users and is adapted to: receive information from at least one of the supplier users; authenticating said at least one provider user (326), and transmitting a message, including said information through a mobile communications network to a mobile terminal of the receiving user; which is further adapted to: extract a public key, specifies to said receiving user, said stored identification information and use the user-specific public key for encrypting said at least part of said message; providing a specific public and private key for communication keys, valid only for a single communication between the authentication system and said receiving user (330); wherein said communication comprises a message and a reply thereto (334, 358); sending said communication-specific public key to said receiving user terminal prior to said communication and storing said communication-specific public key in said mobile terminal; and encrypting at least part of the message to be transmitted, using said communication-specific private key. ΕΡ 1 500 289 / ΡΤ 3/5 Authentication system according to claim 1 or claim 2, which is further adapted to authenticate a receiving user as the recipient of said information. An authentication system according to any preceding claim, wherein a response thereto comprises a receive acknowledgment message and / or a reply message from said receiving user. Authentication system according to any preceding claim, which is further adapted to decrypt at least part of said response, using said public and private key pair of communication specific keys. Authentication system according to claim 5, which is further adapted to transmit a confirmation message to said a provider user, based on said acknowledgment or reply confirmation message. The authentication system according to claim 6, wherein said confirmation message requests a confirmation acknowledgment message from said a user provider and said authentication system is further adapted to send a confirmation message to said user terminal portion of the receiving user, which notifies the terminal to decrypt and display the decrypted portion of said message. Authentication system according to any one of claims 3 to 7, wherein said receiving user is requested to authenticate, providing the authentication data. Authentication system according to any one of claims 3 to 8, wherein said receiving user's terminal automatically generates said receive acknowledgment message, upon delivery of said authentication data and / or response data. ΕΡ 1 500 289 / ΡΤ 4/5 Authentication system according to any one of claims 3 to 9, wherein a central authentication system verifies the authentication of the receiving user. The authentication system according to any one of claims 3 to 10, wherein said message or a portion thereof is only displayed to the receiving user, if the receiving user provides a valid authentication. An authentication system according to any preceding claim, wherein said message is an SMS message in accordance with the GSM standard. Authentication system according to any one of claims 1 to 11, wherein said message conforms to the MMS standards. Authentication system according to any one of claims 1 to 11, wherein said message conforms to the USSD standards. An authentication system according to any preceding claim, wherein in said authentication system and at said receiving user terminal a transaction reference counter is implemented and wherein each of said transaction reference counters is incremented if received successfully a message. The authentication system of claim 15, wherein a transaction reference is included in each message transmitted from the receiving user to the authentication system. The authentication system of claim 16, wherein said sender compares the transaction reference received with its transaction reference counter and the sender only responds if the received transaction reference matches the transaction reference counter of the transaction system. authentication. ΕΡ 1 500 289 / ΡΤ 5/5 An authentication system according to any preceding claim, wherein said information received from the provider users is encrypted and wherein said authentication system may be operated to decrypt said information before sending said information to said user terminal user. The authentication system according to claim 18, wherein said information is encrypted using a public and private key pair valid only for a single transaction between said user provider and said authentication system. The authentication system of claim 19, wherein said public key is transmitted to the terminal of said provider provider before said information is received by said authentication system. The authentication system of claim 20, wherein said public key is transmitted to said provider user in response to a request received by said authentication system. The authentication system of claim 20, wherein said public key is transmitted to said provider user in a prior communication. An electronic commerce system, incorporating an authentication system according to any one of the preceding claims. Electronic voting system comprising the authentication system according to any one of claims 1 to 22.