GB2415574A

GB2415574A - Authenticating messages in a telecommunication system

Info

Publication number: GB2415574A
Application number: GB0413861A
Authority: GB
Inventors: Jagjeet Sondh
Original assignee: Vodafone Group PLC
Current assignee: Vodafone Group PLC
Priority date: 2004-06-21
Filing date: 2004-06-21
Publication date: 2005-12-28
Anticipated expiration: 2024-06-21
Also published as: GB2415574B; GB0413861D0

Abstract

A system for transmitting messages such as SMS messages and WAP push messages between devices registered with a telecommunication system is disclosed. The messages are authenticated. In order to send an authenticated message from a first device to a second device, the first device provides its key to the second device together with the MSISDN (or other public address) of the first device. This information is stored on the second device. The first device then generates a message. A hash value of the message is calculated using the first device's key. A secure message is generated which comprises the hash value and the message. The secure message is then transmitted to the second device. At the second device the key of the first device is retrieved from the store of the second device by using the MSISDN of the first device (included in the received message) as the identifier for the key. The hash value of the received message is calculated using the key of the first device stored on the second device. The two hash values are compared to determine whether the message is authenticated.

Description

1 2415574

AUTHENTICATING MESSAGES IN A

TELECOMMUNICATION SYSTEM

The invention relates to authenticating messages in a telecommunications -A 5 system and more particularly but not exclusively to authenticating messages such as short messages transmitted between devices registered with a mobile telecommunication network.

Embodiments of the invention to be described In more detail below, by way of example only, are for facilitating the sending and receiving of authenticated "short messages" or "SMS" messages in a telecommunication network such as a GSM network. Short messages are messages of a type defined in the GSM standard specifications and include text messages, binary data messages and other specified types of messages. However, it should be understood that the invention is not limited to the use of short messages in a GSM network, or to the sending of any particular type of message. It may be used, for example, for facilitating the sending and receiving of short messages, or their equivalents, in UMTS or 3G (Third Generation) telecommunications systems or in GPRS (General Packet Radio Systems). However, it can also be applied to the sending and receiving of messages of predetermined type in other types of networks.

US 20040030906 discloses a system for improving the security of configuration SMS messages (that is, messages for changing the functional parameters of a mobile terminal). A configuration SMS message for sending to a mobile terminal is encrypted using the intended recipient mobile terminal's IMEI as a key. For this purpose a central database of the IMEI of each mobile terminal is maintained by the management system of the mobile telecommunications network. The body of the SMS message has added to it a User Data Header (UDH). Presence of the UDH is identified by setting an indicator in the SMS header, namely the User Data Header Indicator (UDHI).

An unallocated Information Element (IE) is used to indicate the presence and length of the IMEI number of the mobile terminal. This IMEI number is prefixed to the actual text message in the message body. The IMEI number is bytes long, in accordance with the GSM standards. The message body of the SMS message is encrypted using the IMEI. When the encrypted SMS message is received at the wireless terminal it is determined whether the SMS message includes an IMEI used for encrypting the message. The decryption operation uses the IMEI that is pre-stored in a memory space of the mobile terminal. The decryption result is then parsed to extract the first 15 bytes (i.e. the IMEI of the encrypted SMS message), which are then compared to the IMEI pre-stored in the mobile terminal memory. If the IMEI's match, the mobile terminal allows the SMS message to be processed, and for the relevant functional parameters indicated in the message body of the SMS to be updated.

Further arrangements for secure or authenticated data communication are disclosed in US 2003-0236981, W02003096615, EP0898397 and WO 2003015343. i According to the invention, there is provided a method of enabling the transmission of secure messages between a plurality of devices registered with a telecommunications system, each having a public address by means of which messages are routed thereto and a key, the method including maintaining in one of said devices the database of public addresses and corresponding keys of the other ones of said devices; and retrieving from said database using the public address the corresponding key and calculating a hash value for a secure message using the retrieved key and a hash algorithm.

According to the invention, there is further provided a device for use in a telecommunications system having a public address by means of which messages are routed thereto by the telecommunications system and the key, the device including means for maintaining a database of public addresses and corresponding keys of other devices registered with the telecommunications system, and means for retrieving from said database using a public address the corresponding key and for calculating a hash value for a secure message using the retrieved key and the hash algorithm.

The invention also relates to a telecommunications system with which a plurality of such devices are registered.

According to a further aspect of the invention, there is provided a method of sending secure messages between devices registered with a telecommunication system, each device having a public address by means of which messages are routed thereto, the method including providing a first device with a key; storing said key on the first device; transmitting said key to a second device; storing the received key and the associated public address of the first device in the store of the second device; composing a message using the first device for transmission to the second device; calculating hash value of said message using the key stored in the first device and generating a secure message comprising the hash value and said message; transmitting said secure message to the i second device; retrieving the key from the store of the second device using the public address of the first device as an identifier; and calculating a hash value of the received message using the retrieved key stored in the second device and comparing this to the first-mentioned hash value to authenticate the secure message.

For a better understanding of the invention, an embodiment will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 shows a block diagram of a known cellular telecommunications system including facilities for handhng short messages; and Figure 2 shows a flow chart indicating the steps taken when a message is received in accordance with the embodiment.

Figure I shows a conventional cellular telecommunications system with a network 10. The network 10 has mobiles lOA,lOB (and others not shown) registered with it. The mobiles communicate wirelessly with the network. The network 10 is a GSM network. Within the network 10, the details of the mobiles associated with (or "belonging" to) the network are stored in a home location register HER. The mobiles are authenticated with the network by a "challenge and response" process using an encryption algorithm and key stored on the smart card or SIM of each mobile. When a mobile (e.g. lOA) wishes to communicate with another mobile or fixed telephone, it will signal accordingly to the base station of the cell of the network where it is situated. The subscriber's details are obtained from the HER 16 and temporarily placed In a visitor location register (VLR) appropriate to that cell and are then used to enable the mobile to complete the connection with the called destination.

The procedure for transmission of "short messages" is different. The term "short messages" or "SMS messages" as used in relation to the embodiments means short messages as defined in the GSM standard specifications. Such messages arc commonly in the form of text messages of limited maximum length, but they can have other forms, such as in the form of binary data, or may contain configuration data for changing the functional parameters of a mobile. As will be explained below, however, the invention is not limited to the transmission of messages of this "short message" type.

Short messages may be sent to or from mobiles such as the mobiles lOA,lOB and the others belonging to the home network 10. However, in addition, short messages may be sent to or from "short message entities" (SMEs) such as shown at 20,20A,20B. These SMEs may be in the form of terminals of various sorts such as fixed terminals for sending short messages of various types to mobiles and for receiving short messages from mobiles. For example, the SMEs may be in the fonm of terminals associated with banking computers or computers of other types generating information (commercial information, for example) for transmission to mobiles and for receiving short messages in response from mobiles, but may be of many other types, such as application servers of various types.

The network 10 has a short message service centre (SMSC) 26 associated with it. The SMEs 20,20A,20B are connected to the SMSC 26 by fixed networks lO 30 of suitable type. When a mobile wishes to send a short message, it will do this via the SMSC 26 of its network 10. Thus, for example, if the mobile lOA wishes to send a short message to mobile 1 OB, the short message is automatically addressed by the mobile lOA to SMSC26, which then delivers the short message to mobile lOB (after registering the necessary details to enable a charge to be made to mobile lOA). Each short message therefore carries the address of the local SMSC (this address is automatically generated by the sender), together with the address of the intended destination of the short message. When the local SMSC receives the short message, it then reads the I address (the MSISDN or Mobile Station ISDN number or telephone number of the intended destination) and despatches the short message accordingly.

The arrangement described thus far in relation to Figure 1 is conventional. In such a conventional arrangement, short messages are transmitted to SMSC 26 in real time (that is, as these messages are generated either by mobiles lOA,lOB of network 10 or from SMEs 2O,20A, 20B via network 30).

Using SIM-Toolkit, now a part of GSM specifications, SMS can be used to send configuration data to perfonn over the air (OTA) activation of features.

By sending codes embedded in short messages from the server network operators can remotely provision the user's mobile terminal.

There is no arrangement currently in use to provide user authentication for Short Message Service (SMS), thus it is possible for attackers to spoof SMS messages (that is, to illegitimately send SMS messages appearing to be from an authorised source).

A short message is formally known as a Protocol Data Unit (PDU) and comprises two parts - the header information and the short message data or itself (known as the user data). As described above, a short message is sent to the SMSC that looks at the details on the header and tries to send the message to the recipient.

The header contains the following parameters: SMSC Address The address of the SMSC to which the short message is to be sent. ; Destination Address The Destination Address field denotes the final recipient of the short message.

This parameter is usually specified by the sender as the MSISDN of the recipient. ! Originating Address The address of the sender of the short message. The address is usually the MSISDN of the sender and is usually automatically appended to the short message itself so that the recipient can identify the sender. Advantageously, the MSISDN of the sender is inserted into the SMS load by the SMSC.

Status Report Request This parameter allows the short message sender to request confirmation that the short message has been delivered to its intended recipient.

Service Center Timestamp In addition to the short message text itself and the Originating Address, the time and date that the SMSC received the short message are usually also automatically appended to outbound short messages from the SMSC.

Validity Period Each short message submitted to the SM3C is assigned a Validity Period, which sets the maximum time that the short message is retained in the SMSC. Failure to successfully deliver the short message within the short message lifetime causes it to be deleted, with no further delivery attempts made.

Date Coding Scheme The Data Coding Scheme (DCS) parameter is used for several purposes, including to: (l) Indicate the form in which the short message text (user data) is encoded - for example the GSM 7-bit default alphabet or 16-bit text or binary.

(2) Specify short message classes, which tell the mobile terminal how to deal with the short message. For example, the Data Coding Scheme flag is used to indicate whether to store the short message in the SIM or mobile terminal memory, send it directly to the mobile terminal display or to equipment attached to the mobile terminal.

(3) Allow a receiving Short Message Entity to display an icon associated with a short message, such as an email or voice mail icon.

(4) Indicate that a short message is compressed.

The Data Coding Scheme values are described in standard GSM 03.38.

Protocol Identifier The Protocol Identifier (PID) flag indicates how the short message should be handled by the receiving entity or the SMSC. Uses of the Protocol Identifier include: (1) Routing short messages to the correct outbound interface. This is useful when several interfaces share the same numbering plan (for example, PSTN, fax and voice). Use of the Protocol Identifier indicates to the SMSC where to send the short message to improve the likelihood that it Is successfully delivered to its intended Destination Address.

(2) Indicating that a mobile terminal receiving a short message should check to see if a short message of the same type is currently stored and if so replace it with the new one.

Reply Path The Reply Path allows a user to indicate to the receiver that a reply to the short message is requested. When the recipient chooses to reply to a short message, the SMSC Address from which the short message came is used instead of the | SMSC Address stored on the SIM. Additionally, the Originating Address from which the short message came is automatically used as the Destination Address.

Message Reference An identifier (1- 255) which is incremented with each short message sent.

Message Length Indicates the length of the short message.

Reject Duplicates The Reject Duplicates parameter allows a sender to indicate to the SMSC that a short message with the same Message Reference as one already stored in the SMSC for the same Destination Address should be discarded and replaced by the new one.

User Date Header Indicator The User Data Header Indicator allows a sender to indicate that the short message text itself (the user data) is in a special format of the types defined in standard GSM 03:40, such as SMS concatenation.

SMS Commands Some mobile terminals allow the sender to send specific instructions to the SMSC to carry out operations on previously submitted short messages. For example, different command types allow the user to inquire about the status of a short message or delete a short message that is waiting to be delivered.

Message Type Indicator j The Message T ype Indicator parameter indicates whether a short message is for sending, receiving, is a status report (confirmation of delivery), or a specific command to the SMSC such as an enquiry on a short message. A user does not normally have control over this parameter from the mobile terminal keypad.

Some of these parameters arc added by the mobile network entities and some are accessible by the originator of the short message. A default value for all of these parameters except the Destination Address is usually built into the application software, the SMSC and mobile terminal.

Different combinations of these Short Message Data Structure parameters are formed depending on what SMS-related action is being carried out. The presence and order of the parameters for different types of short message transactions are defined within standard GSM 03:40.

The embodiment now to be described is intended to be implemented on mobile terminals and PDA devices which support the J2ME environment to the

following minimum specification:

Connected Limited Device Configuration (CLDC) version 1.0 Mobile Information Device Profile (MIDP) version 2.0 Wireless Messaging API (WMA) version 1.1 The 'Bouncy Castle Crypto APIs' provided by 'The Legion of the Bouncy Castle' "http://www. bouncycastle.org" are used to provide the implementation of cryptographic algorithms.

The Bouncy Castle APT includes some classes which reside in packages that are the same as the standard Java API - for example java.security. SecureRandom. It is not possible to use these classes as is because a 'NoClassDeiPoundError' arises. To overcome this problem, the classes are passed through an obfuscator which changes the names of the classes and methods. A suitable obfuscator, the 'ProGuard' obfuscator, can be downloaded from http://proguard.sourceforge.net.

According to the embodiment, each device that wishes to send or receive SMS messages that can be authenticated is provided with a key or Message Authentication Code (MAC). One key is provided for each MSISDN. That is, each device that is to be able to send or receive authenticated SMS messages has a key associated with its telephone number. When a device wishes to send an authenticated SMS message to another device, the key of the sending device is used as a shared secret key. The key is known to both the devices.

Typically, a device will store the keys of various other devices with which it wishes to communicate by reception of authenticated SMS messages. The keys will be stored in a storage location on the terminal. For each key the MSISDN to which that key corresponds is stored with the key and is separated therefrom by a comma (or any other suitable separator). A key is retrieved from the store a, 5 by using the corresponding MSISDN to identify the storage location. i

The keys may be provided to mobile terminals by any suitable means. The mobile terminals may be provided with selected keys (and associated MSISDNs) before being distributed to users. For example, if a company that uses several mobile terminals registered with a network wishes to allow the users of those terminals to exchange authenticated SMS messages, each of those terminals could have its memory pre-configured to store the MSISDN and the associated key of each of the other terminals before these are supplied to the users. Alternatively, or additionally, each mobile terminal may be provided with the facility to forward its key and associated MSISDN to any other mobile terminal with which it wishes to be able to communicate by means of authenticated SMS message. The key may be forwarded by a binary SMS message. This will automatically include the sender's MSISDN in the header.

An SMS message is generated with a header and a message body generally in the conventional manner. The message body or payload of the SMS message is modified by an application provided on the sending mobile terminal that will sign the message using the sending mobile terminal's key and a hash algorithm, producing an HMAC. The HMAC is appended to the SMS message before it is sent to the recipient. As indicated above, the recipient is required to have the sender's key stored. This stored key is used to verify the HMAC.

In this embodiment the user can select a hash algorithm to be used to generate an authenticated SMS message. The following hash algorithms are available for selection in the embodiment, although others could be used: SHA1, SHA256 and MD5.

The HMAC is preferably generated using an application available from Bouncy Castle.

For example, the HMAC may be generated by receiving input text ("text") of any length and producing an L-bit output (L = 128 for MD5 and L = 164 SHA1). Text is the data to which the hash function is to be applied and corresponds to the message body or payload of the SMS. K is the key that is shared between the two devices. H is the hash function. Two fixed but different 64 byte strings "if" and "opad" are defined as follows: Had = the byte 0x36 repeated 64 times opad = the byte 0x5C repeated 64 times i The function HMAC takes the key K and Text, and produces HMACK (Text) H(K opad, H (K (E) mad, Text).

In other words the HMAC is generated as follows: ( 1) Append zeros to the end of K to create a 64 byte string (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (l) with ipad (3) Append the data stream Text to the 64 byte string resulting from step (2) (4) Apply H to the stream generated in step (3) (5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad (6) Append the H result from step (4) to the 64 byte string resulting from -> 5 step (5) (7) Apply H to the stream generated in step (6) and output the result.

The HMAC can be generated using different hash algorithms H without requiring any modification to the algorithm for generating the HMAC.

Therefore, as new or improved hash algorithms are generated, the HMAC can use these hash algorithms without requiring any modification.

When the HMAC for an SMS message has been calculated, an authenticated SMS message is generated. The authenticated SMS messages in the WMA binary message class. The secure SMS message is generated by a MIDlet (i. e. an application that conforms to the MIDP standard) on the sending mobile j terminal. The message body or payload of each authenticated SMS message is j as follows: )

Byte Length Description

The version of the Secure SMS MlDlet. This is used to check that the receiver has the same version as the sender. If the sender has a newer version the receiver will be notified that they need to upgrade. If the sender has an older version the receiver will handle the message appropriately.

Size in bytes of the text part of the message (say x).

2 The options for the message: Bits O to 2 indicate the hash algorithm used in the HMAC Bit 3 indicates the presence of a "nonce" in the message.

Bit 4 indicates the presence of a date or timestamp.

x The text of the message.

The HMAC, the length depends on the type of the hash algorithm used to compute the HMAC.

The 4 byte "nonce" if present.

4 The date in seconds since l January i 1970.

As indicated in the above Table, when a secure SMS message is sent a "nonce" and a timestamp is advantageously appended to the message. The "nonce" is a value that varies with time - for example, a random number. The time stamp in this embodiment is the time in seconds since 1 January 1970, and is generated by the clock of the sending device.

The mobile terminals are provided with a Key Manager MIDlet, which has the following functionality: 1. Personal Key Management - the personal key is the key that is used in generating the HMAC appended to messages that the user sends.

2. Friend Key Management - friend keys are keys that are used when validating the HMAC of a message received from a third party.

3. Nonce Database Management - Each message received may have a nonce and a timestamp appended. This timestamp is stored for each message and is used in prevention of replay attacks when subsequent messages are received.

The Personal Key Management function enables the user to delete their personal key, create a personal key or transmit their key to a third party.

The personal key is a 128 bit DES key (in fact 112 bits are used for the actual keying material, other bits are for parity checking) generated using the Bouncy Castle DESedeKeyGenerator class. It is stored as the one and only record in a RecordStore on the mobile terminal called 'personalkey'. The key can be transmitted by binary SMS or other suitable means to a third party for inclusion in their friends' key record store thus enabling the third party to verify messages sent by the user. On selecting the transmit option the user is prompted for the telephone number (MSISDN) of the third party. Having entered the phone number and chosen to send the key an SMS containing the key will be sent to the third party on port 1001 (sms:lltelno:1001) the Key Manager MIDlet registers with the push registry to listen on sms://:1001 and so will be invoked when an SMS is received on that port.

Upon receipt of an SMS the KeyManager MIDlet of the receiving mobile terminal displays the sender of the incoming key. The user can opt to discard the key or save it into the Friend Keys record store. The friend keys are stored in a record store named 'friendkeys'. The address (MSISDN) of the sender and the key data is stored.

The Friends' Key Management function enables the user to list the senders of all keys in their friend record store or delete all of their friends' keys. The latter option means that validation of secure SMSs received will not be possible until the friend retransmits their key and it is again accepted into the 'friendkeys' record store.

Selecting a 'List' option displays a list of the friends' address (sms:lltelno) of all keys in the friends' keys record store. The user is given the option of deleting the individual friend keys by selecting them from the list and choosing the delete option.

The Noncc Database Management function is arranged to store the "nonce" and timestamp appended to each received message. When a message is received, the nonce and timestamp are stored into a record store created for the sender.

For example if a secure SMS is received from 5550001 then the nonce and date from the SMS is entered as a record into a record store called nonce_sms://5550001'. This record store is used in the detection of replay! attacks. It is necessary to manage this record store as it will grow larger as more and more SMSs are received. The user is given the option of deleting all the nonce record stores, deleting the record store for a selected friend or l cleaning' the record store for a selected friend. Cleaning means removing all entries that have been deemed to be expired (e.g. over 3 days) as determined by the date on the device and the date in the record. This is described in more detail below.

The mobile terminals are also provided with a Secure SMS MIDlet. The Secure SMS MIDlet allows a user to send and receive secure SMS messages When sending a secure SMS message using this MIDlet, the user enters the telephone number (MSISDN) of the recipient and the message and chooses the type of digest (hashing algorithm) used in computation of the HMAC.

If the user selects the Send option the following actions occur: ; 1. The text message is converted to a binary representation.

2. A four byte nonce is generated - this is just a random number 3. The date (according to the sending device) is generated and converted to a time in seconds since 1 January 1970 (4 bytes).

4. The message/nonce/time data is converted to an HMAC in the manner described above using the selected digest and the user's personal key from the 'personalkey' record store.

5. The message is formatted as shown in the above table and sent to port 1000 i.e. sms://teluo:1000.

A report screen showing the time taken to perform the message compilation may be shown.

The user can view the hex representation of the message if desired.

The Secure SMS MIDlet registers with the push registry to be notified of all incoming messages on port 1000.

The flow chart of Figure 2 shows the process for receiving a secure SMS message. i When a message is received by a receiving mobile terminal (step A) the friendkeys' record store is searched for the sender of the message (step B). If the sender's address is present in the record store then the user is shown the sender's address and the fact that the key is available for that address. The user then has the option to decode the message. If sender's address is not found in the friend key record store then the decode option is not available - the message cannot be validated and so is discarded.) If the user chooses the decode option the following operations occur: Step C: The HMAC for the message/nonce/date is computed using the digest as indicated by the 'options' in the message and the friend's key read from the 'friendkeys' record store. i

Step D: The computed HMAC is compared to the HMAC in the received message and if it differs (in size or content) then an appropriate error message is given.

If the HMACs agree the message may then be displayed to the user.

Alternatively, and as shown in the flow chart of Figure 2, further authentication takes place if it is then determined if a message store exists (step E). If it does the message store is opened (step F). Then the nonce and date data (time stamp) in the received message is compared toeach record in a nonce_address' record store (step G) storing the nonces and time stamps of previously received messages. If the nonce/date combination matches any stored combination then an error indicating a possible replay attack is displayed (step H). If there is no match, it is then determined whether the date of the message is earlier than the earnest date of all records in the store (step I).

If the message data is satisfactory the message is stored in the record store together with the local receiving device time at which the message was received (step J).

The message is then displayed to the user.

As mentioned above, the MSISDN of the sender is inserted into the SMS message automatically by the SMSC when the SMS message is transmitted from the sending terminal to the SMSC. This advantageously reduces the likelihood that a sending terminal can "spoof' the identity of (or masquerade as) another device in order to illegitimately send authenticated messages as if they wore from an authoriscd sender. Even if the sending terminal were able to cause the MSISDN of an authorised sender to be inserted into the SMS message (whether by the SMSC or by another mechanism), the message would still not be authenticated unless the sender had also obtained the authorised sender's DES key.

An example device may have the following key record stores: Personal Key l Friends Keys

MSISDN KEY

50003234 128 DES Key 50003264 128 DES Key 50002142 128 DES Key 50002579 128 DES Key l and the following message record store: i Message Record Store MSISDN Message Nonce Transmitting Receiving Device Device Timestamp/D ate Timestamp/D ate 50003234 Hello 565422 1230000 1232000 50003264 See u later 111466 1231254 1232665 50002142 5DAD 126654 1123265 1132545 l 50002579 XYZ 756669 1456566 1446565 As indicated above, to allow detection of replay attacks, where an intermediary intercepts a message and resends it at a later date, all received messages from a third party are stored in a record store. There is one record store for each sender, it is named "messages_TelephoneNumber" where TelephoneNumber is the number of the sender.

To try to avoid excessive storage requirements the message stores may be cleaned. Cleaning is the removal of all messages that are older than a given length of time (currently set at 3 days). When an entry is added to a message database it is stored along with a timestamp derived from local device clock. It is this timestamp that is used when cleaning the record stores, i.e. all records where the difference between the timestamp derived from the receiving device clock stored with message in the record and the current local time are deleted.

Note that cleaning will always leave one record (the latest received) in the store to allow for continued replay attack detection.

The time after which messages are deleted is set at 3 days as SMS messages have a finite period for which they can reside on the SMSC without being delivered. So theoretically it is not possible to receive a message that is older than 3 days since the message would have timed out on the SMSC.

Using a timestamp derived from the sender's clock for detection of replay attack has inherent problems since the clock may be changed.

If a third party who has previously sent a message changes the device clock backwards then there is a slight possibility that a message will be received with the same timestamp and text as a previous message. This message would be discarded as a potential replay attack. If the clock is changed far enough backwards then a message could be discarded because its timestamp is before the earliest record's timestamp.

If the clock Is changed on the local device then it will affect the cleaning of the message database but this should not cause any erroneous replay attack notification.

The Key ManagerMIDlet allows a user to manually clean the databases. An option can be set so that this operation occurs each time a valid message is received. This will incur a small overhead when processing a new message but it will b.e more efficient since message store size will be minimised.

In the embodiment described above if a first device wishes to send a secure message to the second device, it must previously provide that second device with its key and corresponding MSISDN. The second device then stores this key and MSISDN. When the second device receives a message from the first device, the second device uses the MSISDN transmitted as part of the secure message to search through stored MSISDNs. When a match to the received MSISDN is found, the corresponding key is retrieved and is used to authenticate the HMAC received in the secure message. In an alternative arrangement, it may be the second device (that is, the device that wishes to receive the secure message) that transmits its key together with the corresponding MSISDN to the first device. The first device may store this key and MSISDN. Other devices that wish to receive messages from the first device will also send their keys and MSISDNs to the first device. These keys are stored in the first device using the MSISDN as their identifier. When the I first device wishes to send a message it uses the MSISDN of the desired recipient (the second device in this example) to search through the stored MSISDNs. When a match is found the corresponding key for the second device is retrieved. This key is used to generate the HMAC that forms part of the secure message. The secure message is then sent from the first device to the second device. When the second device receives the secure message it calculates the HMAC using its own key. If the HMACs match, the message is authenticated.

Although the embodiment described above concerns the sending of authenticated or secure SMS messages, the invention is also applicable to the sending of other types of messages. Such messages might be sent between two mobile (wireless) telecommunications devices, one mobile telecommunications device and one fixed (wired) telecommunications device, or between two fixed (wired) telecommunications devices.

As well as SMS messages, the invention can be applied to performing WAP push. WAP push allows services to send information proactively to devices, thus complementing the already widely deployed browsing services offered by WAP gateways. This information is transmitted via a WAP push proxy gateway. A user or a network operator may provide an information provider with the user's MSISDN and corresponding key. This will allow the information provider to send secure or authenticated messages to the user via the WAP push proxy gateway. The user's receiving device will only accept the message if it is authenticated. Both SMS and WAP push can be used to transmit MMS messages, and this is also within the scope of the present invention.

Claims

N CLAIMS

1. A method of enabling the transmission of secure messages between a plurality of devices registered with a telecommunications system, each having a public address by means of which messages are routed thereto and a key, the method including maintaining in one of said devices the database of public addresses and corresponding keys of the other ones of said devices; and retrieving from said database using the public address the corresponding key and calculating a hash value for a secure message using the retrieved key and a hash algorithm.

2. The method of claim 1, wherein said retrieving step is performed in response to reception of a secure message from one of said other devices that includes a hash value calculated using a key identical to said key and a hash algorithm identical to said hash algorithm.

3. The method of claim 2, including comparing the hash value of the received secure message and the hash value calculated by the said one of said devices to authenticate the secure message.

4. The method of claim 1, wherein said retrieving step is performed prior to sending the secure message from the said one of said devices to one of said other devices, the calculated hash value being included in the secure message.

5. The method of any one of claims I to 4, wherein said other ones of the devices transmit their keys to said one of said devices, whereby said database is compiled.

6. The method of claim 5, wherein said keys are transmitted in a message which includes the sending device's public address.

7. The method of claim 6, wherein the message comprises an SMS message.

8. The method of any one of claims I to 7, wherein said secure message -A 5 includes a value that varies with time.

9. The method of any one of claims 1 to 8, including storing messages on the receiving device.

10. The method of any one of claims I to 9, including, when a secure message is received, comparing elements of the received message to corresponding elements of stored messages.

11. The method of any one of claims 1 to 10, wherein the secure message comprises an SMS message.

12. The method of any one of claims 1 to 11, wherein the message comprises a WAP push message.

13. The method of any one of claims 1 to 12, wherein the message comprises an MMS message.

14. The method of any one of claims 1 to 13, wherein the telecommunications system comprises a mobile or cellular telecommunications system.

15. The method of claim 14, wherein at least one of said devices comprises a mobile or cellular telecommunications terminal for wirelessly communicating with the telecommunications system. '

16. The method of claim 14 or 15, wherein the telecommunications system comprises a GSM or UMTS (3G) mobile telecommunications system.

17. The method of any one of claims 1 to 16, wherein each of said keys -> 5 comprises a respective DES Keys.

18. The method of any one of claims l to 17, wherein the step of calculating the hash value of the message generates an HMAC.

19. The method of any one of claims 1 to 18, wherein the public address of each of said devices comprises the MSISDN of the device.

20. The method of any one of claims 1 to 19, wherein the telecommunications system is arranged such that, when said secure messages i, are transmitted between respective devices, the public address is automatically transmitted as part of the message.

21. A device for use in a telecommunications system having a public address by means of which messages are routed thereto by the telecommunications system and the key, the device including means for maintaining a database of public addresses and corresponding keys of other devices registered with the telecommunications system, and means for retrieving from said database using a public address the corresponding key and for calculating a hash value for a secure message using the retrieved key and the hash algorithm.

22. The device of claim 21, operable to receive a secure message from another device registered with the telecommunications network that includes a hash value calculated using a key identical to said key and a hash algorithm identical to said hash algorithm, and in response thereto extracting the public address from the received secure message and providing this to said retrieving means for retrieving the corresponding key and calculating a hash value for the received secure message using the retrieved key and said hash algorithm.

23. The device of claim 22, including means for comparing the hash value of the received secure message and the hash value calculated by the retrieving means for authenticating the received secure message.

24. The device of claim 21, operable to send a secure message to another device that is addressed using the public address of that other device by providing said public address to the retrieving means for retrieving from said database the corresponding key and calculating the hash value for inclusion in the secure message.

25. The device of any one of claims 21 to 24, including means for receiving keys from other devices registered with a telecommunications system, whereby said database is compiled.

26. The device of any one of claims 21 to 25, including a store for storing secure messages received.

27. The method of claim 26, including means for comparing elements of a received secure message with corresponding elements of stored messages.

28. The device of any one of claims 21 to 27, wherein the secure message comprises an SMS message, a WAP push message or an MMS message.

29. The device of any one of claims 21 to 28, wherein the keys comprise respective DES Keys.

30. The device of any one of claims 21 to 29, wherein the hash value comprises an HMAC.

31. The device of any one of claims 21 to 30, wherein the device is for use in a mobile of cellular telecommunications system.

32. The device of claim 31, wherein the device communicates wirelessly with the telecommunications system.

33. A telecommunications system having registered therewith a plurality of devices according to any one of claims 21 to 32.

34. The telecommunications system of claim 33, operable to transmit secure messages between respective devices registered therewith by means of the public address comprising an element of each of said messages.

35. The telecommunications system of claim 33 or 34, comprising a mobile or cellular telecommunication system.

36. The telecommunications system of claim 33,34 or 35, wherein the telecommunications system comprises a GSM or UMTS (3G) mobile telecommunications system.

37. The telecommunications system of claim 33,34,35 or 36, wherein the public address of each of the devices comprises the MSlSDN of the device.

38. A method of sending secure messages between devices registered with a telecommunication system, each device having a public address by means of which messages are routed thereto, the method including providing a first device with a hey; storing said key on the first device; transmitting said key to a second device; storing the received key and the associated public address of the first device in the store of the second device; composing a message using the first device for transmission to the second device; calculating hash value of said message using the key stored in the first device and generating a secure message comprising the hash value and said message; transmitting said secure message to the second device; retrieving the key from the store of the second device using the public address of the first device as an identifier; and calculating a hash value of the received message using the retrieved key stored in the second device and comparing this to the first-mentioned hash value to authenticate the secure message.

39. The method of claim 38, wherein the second device receives keys from a plurality of said devices and stores each of those keys in a location addressable by the public address corresponding to each of those devices.

40. The method of claim 38 or 39, wherein the message comprises an SMS message.

41. The method of claim 38 or 39, wherein the message comprises a WAP push message.

42. The method of claim 38 or 39, wherein the message comprises an MMS.

43. The method of any one of claims 38 to 42, wherein the telecommunication system comprises a mobile or cellular telecommunication system.

44. The method of claim 43, wherein at least one of said devices comprises a mobile or cellular telecommunications terminal for wordlessly communicating with the telecommunication system.

45. The method of claim 43 or 44, wherein the telecommunication system comprises a GSM or UMTS (3G) mobile telecommunication system.

46. The method of any one of claims 38 to 45, wherein the or each key comprises a DES Key.

47. The method of any one of claims 38 to 46, wherein the step of calculating the hash value of the message generates an HMAC.

48. The method of any one of claim 38 to 47, wherein the public address of each of said devices comprises the MSISDN of the device.

49. The method of any one of claims 38 to 48, wherein the telecommunication system is arranged such that when said messages of a predetermined type are transmitted between respective devices the public address is automatically transmitted as part of the message.

50. The method or telecommunications system of any one of the preceding claims wherein the public address of a device sending a said message is automatically Inserted into said message by the SMSC of the telecommunications system.

51. A method substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.

52. A device substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.

53. A telecommunications system substantially as hereinbefore described with reference to and/or substantially as illustrated in any one of or any combination of the accompanying drawings.