GB2464615A

GB2464615A - Authentication of mobile terminals

Info

Publication number: GB2464615A
Application number: GB0918557A
Authority: GB
Inventors: Veselin Rakocevic; Rajarajan Muttukrishnan; Dasun Weerasinghe
Original assignee: Univ City
Priority date: 2008-10-22
Filing date: 2009-10-22
Publication date: 2010-04-28
Also published as: GB0918557D0; GB0819370D0

Abstract

An embodiment of the invention relates to a communications method that comprises the steps of: operating a mobile terminal to generate an authentication message that includes an identifier for said terminal; transmitting said authentication message from said mobile terminal to a remote processing centre that is configured to extract said unique identifier from said authentication message and to determine from said extracted identifier whether said mobile terminal is an authorised user; and operating the remote processing centre, if said mobile terminal is determined to be authorised, to generate a token and a message incorporating that token. The identifier for said terminal may be configured to shield said mobile terminal's true identity (i.e. provide anonymous authentication) and the identifier may comprise a random number. The authentication message may include a revocation parameter that can be utilised to reveal the true identity of the mobile terminal. A random challenge received by the mobile terminal may be utilised to generate the revocation parameter. The revocation parameter may comprise a signed message containing the IMSI of the mobile terminal and the random challenge received from the remote processing centre. A temporary user ID may be generated by the remote processing centre upon successful authentication, which may also generate a revocation attribute. The method described may be used in authenticating terminals for online transactions and may involve a single-sign-on type arrangement.

Description

COMMUNICATIONS METHOD & SYSTEM

Field of the Invention

This invention relates to a communications method and system. Particularly preferred illustrative embodiments of the invention relate to a communications system that enables authenticated communication between parties. In one illustrative application, the communications system may be employed to provide a merchandising system for the purchase of goods or services by customers using their mobile terminals.

In another illustrative application, the teachings of the invention may be employed to provide a system for facilitating authenticated information exchange.

Particularly preferred embodiments of the present invention will be described hereafter with reference to an arrangement where mobile terminal users can obtain goods or services from a service provider, for example in a merchandising environment where mobile terminal users can purchase goods or services from a merchant by means of a mobile terminal (such as a radio telephone, portable digital assistant (PDA), laptop computer or any other computing device that is enabled for radio (e.g. cellular) communications).

Whilst the teachings of the present invention are particularly well suited for these applications, it will be immediately apparent to persons skilled in the art that the teachings of the present invention may be more widely applied. As a consequence of this, the following description should be considered as being merely illustrative of a preferred embodiment of the present invention. In other words, the scope of the present invention should not be interpreted as being limited only to the application of the teachings of the invention to the requisition of services or the procurement of goods from a provider, for example in a merchandising environment of the type hereafter described.

Background to the Invention

Electronic shopping or e-commerce has rapidly established itself as a popular alternative to traditional mechanisms by which customers can acquire goods or services from a business or person offering those goods or services for sale. E-commerce is popular with customers as they no longer need to actually visit stores to purchase goods or services but can instead browse and purchase the goods or services offered by a merchant from the comfort of their own homes. E-commerce is popular with merchants because they no longer need to invest large amounts of capital in physical business locations but can instead easily and inexpensively establish "virtual" shopping environments.

To participate in e-commerce, a customer needs a computing resource (such as a personal computer) and typically a landline communications connection (for example a broadband connection via the PSTN (public switched telephone network)) to the internet.

The merchant provides a computing resource, for example a web server, that is coupled to the internet via an internet gateway, and the user can open a web browser (such as FirefoxT) and navigate to the URL (unique resource locator) of the website maintained by the merchant from whom the customer wishes to purchase goods or services.

The customer is typically provided with the facility to browse through an online catalogue of goods or services provided by the merchant, and can often select items from the catalogue that they wish to purchase and temporarily store those items in a virtual shopping cart.

When the customer wishes to complete their purchase of the goods or services that they have placed in their shopping cart, the webserver and customer computing resource typically communicate and cooperate with one another to establish an encrypted communications channel (such as an SSL (secure socket layer) channel) by means of which sensitive customer related financial information may be transferred to the merchant to enable the merchant to take payment for the goods or services selected by the customer. By invoking a secure communications channel, transfer of sensitive information can be shielded from nefarious third parties who may be monitoring internet traffic to try to intercept sensitive financial information that they may then use for their own (often illegal) purposes.

Whilst this arrangement provides protection against unauthorised interception of internet traffic, the communications system employed to enable customers to communicate with merchants is only really as secure as the customer terminals and webservers themselves. Thus, whilst communications links may be encrypted and protected, an SSL communications channel would not, in itself, protect against the installation of rogue software (such as keylogging software for example) at the customer terminal or indeed from hacking of the webserver, and to avoid against such attacks it is now commonplace for both customers and merchants to take steps to protect against unauthorised attempts to covertly access any of their computing resources that are connected to the internet.

The adoption of such measures has meant that for the vast majority of customers, e-commerce has become a relatively secure and enjoyable way of easily acquiring goods and services from merchants.

That said, one immediately apparent drawback with such an e-commerce solution (from the customer's point of view at least) is that it does require the customer to have access to a landline communications network (for example the PSTN). Some customers may not wish or be able to pay for installation and maintenance of a landline, and other customers may not want to be restricted to shopping only from their home or office computer. For example, a potential customer travelling on public transport may see an advertisement for a product and want to immediately purchase that product using their mobile terminal.

To enable users to shop using their mobile telephones (an activity generally known as "m-commerce") most modern mobile terminals provide the user with the option of connecting to an internet, such as the World Wide Web. To access such functionality it is usually necessary for the customer to include, as part of the customer's subscription to the wireless network provider that they have chosen, the option of establishing internet data connections via the mobile telecommunications network.

If a given customer has paid for the ability to make internet data communications via a mobile telecommunications network, then that customer can invoke -via the wireless air interface between the mobile terminal and the mobile network -a communications channel by launching a web browser on their mobile terminal. Once the communications channel between the mobile terminal and the gateway has been established, the user is then free to surf the web from their mobile terminal much in the same way as they would if they were surfing the web from a computer connected to an internet via the PSTN.

In particular, that customer would be able to navigate to a website provided by a merchant and select goods or services offered by the merchant for purchase. When the user opts to pay for the goods or services they have selected, then it might be possible for a secure SSL communication exchange to be invoked so that the customer can transfer financial information to the merchant to effect payment. However, one problem is that most mobile WAP browsers do not support SSL communications, and for those that do invoking an SSL authentication process consumes bandwidth and causes delay.

An alternative way that customers might communicate with a merchant or other provider is via SMS (short messaging system) messages. SMS messages are short messages (typically up to 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters) sent via the control channels (as opposed to traffic channels) of a mobile network air interface. Whilst SMS messages have the advantage that they are usually not routed via an internet and hence are less open to abuse by third parties monitoring internet traffic, it remains the case that as SMS messages are not encrypted they are liable to intercept and misuse by nefarious third parties who are monitoring the air interface. It is of course the case that SMS messages could be encrypted, but this would greatly increase the amount of data to be transferred and hence the cost of sending messages. For these reasons, SMS messaging is not a viable means for securely transferring sensitive information from customers to merchants.

Another drawback associated with existing arrangements is that they necessarily require the customer to identify themselves to the merchant. More overtly, for delivery of goods to occur the customer will typically have to provide the merchant with names and addresses, and whilst this is typically not a problem for most purchases there are circumstances where a customer may prefer to be as anonymous as he or she would have been if they were to have bought the goods or services in question by means of an anonymous cash transaction.

It is an aim of the present invention to address these problems.

Summary of the Invention

In pursuit of this aim, a presently preferred embodiment of the present invention provides a communications method comprising any novel combination of features herein described. Another embodiment relates to a mobile terminal that is configured to provide an execution environment in which one or more software modules may be executed to provide one or more steps of the method herein described.

In an illustrative embodiment, there is provided a communications method that comprises the steps of: operating a mobile terminal to generate an authentication message that includes an identifier for said terminal; transmitting said authentication message from said mobile terminal to a remote processing centre that is configured to extract said unique identifier from said authentication message and to determine from said extracted identifier whether said mobile terminal is an authorised user; and operating the remote processing centre, if said mobile terminal is determined to be authorised, to generate a token and a message incorporating that token.

Preferably, said identifier is configured to shield said mobile terminal's true identity. The identifier may comprise a random number that is utilised as a identifier for said mobile terminal.

The authentication message may include a revocation parameter that can be utilised to reveal the true identity of said mobile terminal.

In one arrangement, the mobile terminal is configured to receive a random challenge, and to utilise said random challenge when generating said revocation parameter. The random challenge may be received from said remote processing centre.

The random challenge may be generated from a random number (RAND).

The revocation parameter may comprise a signed message that contains the IMSI of the mobile terminal and the random challenge from said remote processing centre. The message may be signed with a private key for a selected service provider.

The message may be encrypted with a symmetric session key.

In one arrangement, the remote processing centre is configured to decrypt said authentication message and reveal a decrypted authentication message, and to authenticate said mobile terminal.

Authentication of said mobile terminal may include: generating an authentication message and comparing said generated authentication message with said decrypted authentication message.

In one envisaged embodiment, said generated authentication message is compared with said decrypted authentication message to determine whether the authentication message from said mobile terminal was generated using the same RAND as that used by the remote processing centre to generate said authentication message.

The remote processing centre may be further configured to extract an IMSI for said mobile terminal from said decrypted authentication message.

The remote processing centre may be configured to determine whether said extracted IMSI is included in a database of authorised IMSI numbers.

Preferably, the remote processing centre is configured to generate a user security token if said extracted IMSI is included in said database. The user security token may include a temporary user ID. The user security token may be sent to said mobile terminal.

In one embodiment the remote processing centre is configured, responsive to successful authentication of said mobile terminal, to generate a revocation attribute (RA) for forwarding to a service provider.

The RA may be created by adding said revocation parameter to a message that includes the mobile terminal IMSI, and the RAND utilised by said mobile to generate said authentication message.

Another aspect of the present invention relates to an authentication module that is configured to implement one or more steps of the method herein described. The authentication module may be embodied, at least in part, as software executable by a mobile terminal. Another aspect of the invention relates to a mobile terminal comprising an authentication module, the terminal being configured to provide an execution environment in which said authentication module may be executed.

Yet another embodiment relates to a system for authenticated communications, the system comprising: a mobile terminal that comprises an authentication module, said authentication module being configured to generate an authentication message that includes an identifier for said terminal; and a remote processing centre configured to: receive an authentication message transmitted from said mobile terminal, to extract said unique identifier from said authentication message, to determine from said extracted identifier whether said mobile terminal is an authorised user; and if said mobile terminal is determined to be authorised, to generate a token and a message incorporating that token.

Other features, advantages and aspects of the invention will be apparent from the following detailed description of preferred embodiments.

Brief Description of the Drawings

Various aspects of the teachings of the present invention, and arrangements embodying those teachings, will hereafter be described by way of illustrative example with reference to the accompanying drawings, in which: Fig. 1 is a schematic representation of a mobile terminal; Fig. 2 is a schematic representation of the components of the terminal illustrated in Fig. 1; Fig. 3 is a schematic representation of a communications system that incorporates preferred embodiments of the present invention; Fig. 4 is a flow chart depicting the steps of a method of generating a token and authenticating a mobile terminal with a single sign-on server; Fig. 5 is a schematic representation of the steps of a method for authenticating a mobile terminal and generating a token; and Fig. 6 is a flow chart depicting the steps of a mechanism for identifying the user.

Detailed Description of Preferred Embodiments

Referring now to Figs. 1 and 2 of the accompanying drawings, there is shown an illustrative example of a mobile terminal, in this case a mobile telephone 1. As will be appreciated by persons skilled in the art, any computing resource (such as a laptop or PDA) that is provided with radio communications functionality (for example, cellular functionality via a GSM, UMTS or any other network) may be employed in the method and system of the present invention. As a result of this, the following description should not be interpreted as being limited only to mobile telephones, but should more broadly be construed to encompass any radio communications enabled computing device.

The following description will also refer to "service providers", and in the context of this application this term should be broadly construed to refer to any individual or organisation that offers services to another party. For example, a merchant offering merchandising services (for example, a selection of goods for purchase) is a "service provider" in the context of this application, as is an organisation offering legal services.

In this illustrative example, the terminal 1 comprises a display 3, an aerial 5 and a plurality of keys 9 arranged in a keypad. The keys, as is known in the art, can be arranged as so-called hard keys with one predetermined function or alternatively they can be arranged as soft-keys which have a plurality of functions depending on the particular operating mode of the terminal. The terminal 1 is provided with a microphone 11 and a loudspeaker 13 for input of user speech and generation of audio signals for relaying to a user.

In this illustrative example, an infra red input/output port 12 is also provided to permit infrared optical data signals to be received from and/or transmitted to other mobile terminals which are also equipped with an appropriate port.

Figure 2 is a schematic representation of key components of the terminal shown in Figure 1. As shown the terminal 1 includes a central control unit or processor 15 that, at least in general terms, is operable to control operation of the terminal. Coupled to the processor 15 is a radio unit 17 and timing control circuitry 19 that together are operable to control the transmission and reception of telecommunications signals to and from other telecommunications terminals or from telecommunications networks to which the terminal can connect via the aerial 5. The processor 15 and/or the associated memory store the IMEI (International Mobile Equipment Identity) number, a fifteen digit serial number which uniquely identifies the mobile terminal to the wireless network and is transmitted to the network whenever the terminal is used.

A removable data storage device or subscriber identity module (SIM) 5 is provided for data and program storage. The data stored comprises the IMSI (International Mobile Subscriber Identity) which uniquely identifies the subscriber to the wireless network, and other information such as a set of telephone numbers stored on the phone by the user. Software programs may also be stored on the SIM as part of the so-called SIM toolkit (or SIM application toolkit as it is otherwise known).

Coupled to the processor 15 is the display 3, and signals can be sent from the processor 15 to the display in order to convey messages, instructions, and other information to a user of the terminal. The processor is also coupled to the keypad 9 for data input by a user to the terminal.

Sound (for example user speech) picked up by the microphone 11 is 15 processed by a speech processor 21 (for example to remove non-transmittable frequencies), and a coder/decoder (CODEC) 23 that is operable to convert analogue signals generated by the microphone 11 into digital data for subsequent processing. The speech processor 21 and CODEC 23 are also operable to process received digital data and convert it into appropriate audio 20 signals for relaying to a user by means of the loudspeaker 13.

Also coupled to the processor 15 is a ring generator 25 which is operable to generate one of a variety of different alerts which are used to alert a user of the terminal as to when a call, a message or other information is received at the terminal 1. In this particular case the ring generator is operable to generate appropriate signals to drive a vibrating device 27, to illuminate an LED 28 (or bank of illumination devices) or to generate a ring signal for relay to the user via the loudspeaker 13. Typically, a user of the terminal is able to select which of these alert options are most preferable for their current ambient environment. For example, a user who is at work and does not want to disturb his or her colleagues with an audible ring tone might choose the vibrating buzzer as an alternative means to alert them to an arriving call at the terminal.

The mobile terminal 1 includes an authentication module (AM) 30 which, in the preferred embodiment, comprises software that may be executed by the processor to invoke part of an authenticated communications system with other parties and other software components. The AM 30 of the preferred embodiment comprises software, but it will be immediately apparent to persons skilled in the art that the functionality provided by this software may equally be provided by hardware, for example by an application specific integrated circuit (ASIC) or indeed by a combination of software and hardware.

Referring now to Fig. 3, there is depicted a schematic representation of a system 32 embodying the teachings of the present invention. As shown, the system 32 comprises a server 34 to which a mobile terminal 1 (for example a terminal of the type depicted in Figs. 1 and 2) can send messages via a wireless network 36 (such as a GSM cellular network).

The wireless network can communicate with an internet 38, such as the World Wide Web, via an appropriate gateway (not shown), and in particular with individual service providers (in this instance, A and B). The service providers can in turn communicate with the mobile terminal (via the wireless network 36) and the server 34.

The server 34, in the preferred embodiment, comprises a single sign-on server (SSO), and by this we mean that once the mobile terminal 1 has been authenticated with the server, the user will be deemed to have been authenticated by any of the service providers 40 -at least until that authentication expires. In one envisaged arrangement the SSO 34 may be operated by the wireless network provider, and that provider may derive revenue from each transaction completed with service providers (SP) 40.

The AM 30 of the mobile terminal functions in concert with SSO software modules and software modules of the SP to provide, as will now be described, a secure authenticated mechanism for communicating with an SP, for example for the purpose of acquiring goods or services from the SP. In this illustrative arrangement, each of the SP have pre-registered with the SSO, and the SF and SSO have shared their public key certificates.

To commence communications with service providers, the user of the mobile terminal 1 (in this instance, a customer) first operates the mobile terminal 1, as shown in Fig. 4, to select the desired SF and execute the AM software application 30 resident on the mobile terminal 1. Selection of the AM software application 30 causes the processor to execute the AM software application 30 in step 42. The processor 15 then attempts to contact the SSO 34 in step 42 to request sign-on to the SSO.

If contact cannot be effected, the processor 15 displays a message, in step 51, advising the user that the SSO has not responded to the sign-on request sent by the processor 15 and suggests that the user should try contacting the SSO at a later time.

If contact with the SSO is achieved, the mobile terminal (MT) generates a security token, which consists of two parts: a mobile subscriber unique ID (which in this embodiment is a random number that is used as an identifier for the MT), and a Revocation Parameter (RP) which can be used to reveal the MT identity to a trusted authority, if needed. The security token (ST) is generated as follows (steps 44-46 in Fig.4): The MT uses a random challenge (the like of which is known in the art) that is generated in this illustrative arrangement by the Network Operator (the Network Operator (NO) being co-located with the SSO in this illustrative embodiment) and the long term secret key stored in the SIM card to compute a secret session key. In a preferred embodiment, the standard SIM based encryption algorithms used in GSM networks can be used to generate this key.

The processor of the MT then generates the distinct signature key pair for each service provider (SP), where the SP's public key acts as the MS ID and the private key is bound to the true identity of the MT, and will be different for every SP.

The MT then generates the Revocation Parameter (RP) by signing a short message containing the MS IMSI and the random challenge obtained from the network operator. Signing is effected with the private key for the particular SP concerned, following which the signed message is symmetrically encrypted with the session key.

Finally, the MT creates the security token -which token includes, as aforementioned, the following attributes: (a) an MT ID, which will be the public key used only with a particular SP, and (b) a revocation parameter.

As will later be described in connection with Fig. 5, the SSO receives the authentication message from the mobile terminal and performs an authentication check.

The SSO then generates an encrypted message which is sent back to the mobile terminal. The message is then inspected by the processor 15 to determine whether the authentication has been successful. If the authentication has been successful, the MT can start using or otherwise communicate with the SP in step 48. If authentication is not successfully completed, the user of the terminal is advised -in step 50 -by way of a displayed message, that authentication has failed and the application then terminates.

Referring now to Fig. 5, the SSO 34 is initially in a dormant state waiting to receive sign-on requests from mobile terminals. When the SSO 34 receives a sign-on request, the SSO acknowledges receipt of the request by sending a random challenge message, a copy of which is stored by the SSO. The SSO then awaits receipt of an authentication token from the mobile terminal. In the preferred arrangement a timer is started once the sign-on request has been acknowledged and the SSO 34 times out and stops the authentication process if no authentication message is received within a predetermined period of time thereafter.

Once an authentication message has been received the SSO 34 decrypts the message in step 66, and performs the authentication check in step 54 as follows.

The SSO uses the secret key associated with the MT and the random challenge that was sent to the MT to generate an authentication message, and to generate the secret session key.

The SSO then decrypts the revocation parameter RP from the security token using the session key. Next, the signature on the received message is verified using the public key of the SP (obtained from the token).

The SSO will then compare the two values of the authentication message (the one that has been generated and the one recovered from the RP). If these two messages are equal, this confirms that the MT has used the same random number (RAND) used to generate the random challenge that the SSO sent.

The SSO 34 then can compare the extracted IMSI with a database of pre-registered IMSI numbers to determine whether the received IMSI is associated with a mobile terminal (and hence a mobile terminal user) that has previously been registered with the service.

If the IMSI extracted from the decrypted authentication message is not listed in the database, the SSO 34 can determine that the IMSI is not valid and can notify the terminal that authentication has failed. If the IMSI extracted from the decrypted authentication message is listed in the database, the SSO 34 can determine the IMSI is valid and generate a token.

The SSO acknowledges authentication by creating a User Security Token. The token contains a temporary user ID and is encrypted using, for example, symmetric encryption.

If the authentication check is successful, the SSO creates a Revocation Attribute (RA) by adding the RP to a message (which comprises the MS IMSI and RAND) and encrypts the new message (which will consist of the MS IMSI, RAND, and RP), for example with the SSO public key.

Once the RA is created it is forwarded to the appropriate service provider using the service provider public key generated by the MT previously as the MS ID. Attached to this message will be the RA.

As the user had been authenticated using the SSO system, the service provider will now be able to deliver the service requested by the user.

Referring to Fig. 6, if it should be necessary to reveal the identity of a user, for example if a user is suspected of illegal activities, the MT identity can be revealed to the service provider by means of the following arrangement.

In step 68, the SP forwards the public key for the SP (the public key that has been generated by the MS to act as the MS ID) to the SSO The SSO uses its private key to decrypt the RA and thereby reveal the message, and then uses the secret key associated with the MS IMSI and the random challenge contained in the message to re-generate the session key.

The SSO then decrypts the RP using the session key and checks the integrity of the message using the public key for the SP generated by the MS. Successful completion of this check indicates that owner of the public key is the same as the owner of the secret key linked to the IMSI number, and hence the user identity can be revealed.

In the preferred embodiment all messages to and from any component of the system are embodied as SOAP messages. It will, however, be appreciated that this preferred arrangement need not be an essential feature of the invention.

It will also be appreciated that the scope of the present invention is not limited to the particular embodiments described above in detail but instead includes all modifications and alterations that fall within the scope of the accompanying claims.

Lastly, it should also be noted that the scope of the present invention extends to any combination of features herein described, irrespective of whether or not that particular combination has been explicitly enumerated herein.

Claims

CLAIMS1. A communications method that comprises the steps of: operating a mobile terminal to generate an authentication message that includes an identifier for said terminal; transmitting said authentication message from said mobile terminal to a remote processing centre that is configured to extract said unique identifier from said authentication message and to determine from said extracted identifier whether said mobile terminal is an authorised user; and operating the remote processing centre, if said mobile terminal is determined to be authorised, to generate a token and a message incorporating that token.
2. A method according to Claim 1, wherein said identifier is configured to shield said mobile terminal's true identity.3. A method according to Claim 2, wherein said identifier comprises a random number that is utilised as a identifier for said mobile terminal.
3. A method according to Claim 2 or 3, wherein said authentication message includes a revocation parameter that can be utilised to reveal the true identity of said mobile terminal.
4. A method according to any preceding claim, wherein said mobile terminal is configured to receive a random challenge, and to utiUse said random challenge when generating said revocation parameter.
5. A method according to Claim 4, wherein said random challenge is received from said remote processing centre.
6. A method according to Claim 5, wherein said random challenge is generated from a random number (RAND).
7. A method according to Claim 5 or 6, wherein said revocation parameter comprises a signed message that contains the lMSI of the mobile terminal and the random challenge from said remote processing centre.
8. A method according to Claim 7, wherein said message is signed with a private key for a selected service provider.
9. A method according to Claim 7 and 8 wherein said message is encrypted with a symmetric session key.
10. A method according to any preceding claim, wherein said remote processing centre is configured to decrypt said authentication message and reveal a decrypted authentication message, and to authenticate said mobile terminal.
11. A method according to Claim 10, wherein authentication of said mobile terminal includes: generating an authentication message and comparing said generated authentication message with said decrypted authentication message.
12. A method according to Claim 11, wherein said generated authentication message is compared with said decrypted authentication message to determine whether the authentication message from said mobile terminal was generated using the same RAND as that used by the remote processing centre to generate said authentication message.
13. A method according to Claim 12, wherein the remote processing centre is further configured to extract an IMSI for said mobile terminal from said decrypted authentication message.
14. A method according to Claim 13, wherein the remote processing centre is configured to determine whether said extracted IMSI is included in a database of authorised IMSI numbers.
15. A method according to Claim 14, wherein the remote processing centre is configured to generate a user security token if said extracted IMSI is included in said database.
16. A method according to Claim 15, wherein said user security token includes a temporary user ID.
17. A method according to Claim 15 or 16, wherein said user security token is sent to said mobile terminal.
18. A method according to any of Claims 14 to 17, wherein said remote processing centre is configured, responsive to successful authentication of said mobile terminal, to generate a revocation attribute (RA) for forwarding to a service provider.
19. A method according to Claim 18, wherein said RA is created by adding said revocation parameter to a message that includes the mobile terminal IMSI, and the RAND utilised by said mobile to generate said authentication message.
20. An authentication module configured to implement one or more steps of the method of any preceding claim.
21. An authentication module according to Claim 20 embodied, at least in part, as software executable by a mobile terminal.
22. A mobile terminal comprising an authentication module according to Claim 21, the terminal being configured to provide an execution environment in which said authentication module may be executed.23. A system for authenticated communications, the system comprising: a mobile terminal that comprises an authentication module, said authentication module being configured to generate an authentication message that includes an identifier for said terminal; and a remote processing centre configured to: receive an authentication message transmitted from said mobile terminal, to extract said unique identifier from said authentication message, to determine from said extracted identifier whether said mobile terminal is an authorised user; and if said mobile terminal is determined to be authorised, to generate a token and a message incorporating that token.22. A method substantially as hereinbefore described with reference to the accompanying drawings.
23. A system or mobile terminal substantially as hereinbefore described with reference to the accompanying drawings.