WO2012004640A1

WO2012004640A1 - Transaction authentication

Info

Publication number: WO2012004640A1
Application number: PCT/IB2011/000517
Authority: WO
Inventors: Christiaan Johannes Petrus Brand; Albertus Stefanus Van Tonder
Original assignee: ENTERSECT TECHNOLOGIES Pty Ltd
Current assignee: ENTERSECT TECHNOLOGIES Pty Ltd
Priority date: 2010-07-08
Filing date: 2011-03-11
Publication date: 2012-01-12
Anticipated expiration: 2013-01-08

Abstract

A method and system (1) for authenticating a secure transaction between a secure transaction host (3) and a transacting user (13) is provided. The method includes receiving an authentication request from the secure transaction host (3) at an authentication server (7) and establishing a USSD session with the mobile phone (19) of the transacting user (13) via a network provider (9) upon receipt of the request. Details of the transaction is then passed to the user's mobile phone (19) by means of USSD messages and the user (13) is requested to confirm or deny, also by means of USSD, its intended performance of the secure transaction. Only if the user confirms the transaction is the transaction authenticated by the authentication service provider (7). The user may also be requested to enter a personal identification number and transmit it to the authentication service provider via USSD.

Description

TRANSACTION AUTHENTICATION

FIELD OF THE INVENTION The present invention relates to a method of authenticating secure transactions. In particular, but not exclusively, the invention relates to a method of authenticating transactions conducted by users in possession of a registered mobile cellular telephone or other GSM enabled device. BACKGROUND TO THE INVENTION

Passwords or pass keys are widely used to control authorised access to electronic media such as computer programs or Internet websites, for example Internet banking websites. Often, when a user wishes to gain authorised access to a program/website, the user must enter a login identifier (username) and a secret password. These are then checked against entries in a secure database by the program/website and access is only allowed if the login identifier and password correctly correlate with a database entry. The use of such a login identifier and password to control authorised access is known as one-factor authentication.

Password protected resources on computer networks like the Internet range from the simplest services, for example, managing your e-mail list subscriptions, to services requiring high-grade encryption and protection such as trading portfolios and banking services. With the evolution of technology and the proliferation of unscrupulous operators, particularly in the online arena, the protection of these sensitive resources with only a username and password has become insufficient and, in fact, more and more uncommon. The major disadvantage of a simple password is that knowledge of that single vital piece of information can give anyone, anywhere, at any time, unauthorized access to the sensitive data it is meant to protect. One-factor authentication therefore provides relatively weak protection as it relies on the user keeping his or her login identification and password secret. To make matters worse, so-called "key-logging" software has been developed that can be installed on computers as so-called "spyware" to record any key strokes made by a user on a computer keyboard. Such spyware, which is often secretly installed by criminals on computers in public places such as in Internet Cafes, allows third parties to secretly record a user's login identifier and password and use them at a later stage to gain unauthorised access to the user's secure information. This is therefore a relatively easy method of circumventing one-factor authentication.

To the applicant's knowledge, recent attempts at improving security have utilized users' mobile telephones because a one-to-one relationship is assumed to exist between a user and his or her mobile phone. For this technology to be used, it is assumed that the phone is always in the user's possession. Short Messages Service (SMS) messages are currently the preferred delivery mechanism for security messages and generally take the form of a text message sent by the service provider (for example a banking institution) to the user's mobile phone. The message normally includes a single, unique one-time-pin (OTP) which the user then has to manually enter into the secure environment it wishes to access or prior to conducting a secure transaction, in conjunction with his or her normal login details. While this technology adds an extra layer of security, it is still susceptible to abuse as it is possible to intercept SMS messages through, for example, techniques such as SIM-card cloning. It also still requires the user to enter an 8-digit (or longer) code from the cell phone onto the website or otherwise of the secure transaction it wishes to perform. Another disadvantage of this technology is the relatively high cost involved for the institution hosting the secure transaction, as it has to send an SMS message through a GSM network provider each time a user needs to be authenticated. Authentication may take place a number of times during any particular session and each such message will normally be billed for individually by the GSM network provider. An alternative transaction authentication system of which the applicant is aware requires an authentication software application to be installed on the transacting user's mobile phone. The software application is configured to communicate with an authentication service provider over a secure communications channel and to uniquely identify the user attempting to conduct a secure transaction if requested to do so, typically by means of a digital fingerprint which is generated by the software application and then registered with the authentication service provider. The software application is typically JAVA based and needs to be installed on the user's mobile phone before being operational. Apart from the obvious trouble of having to install the software application on user mobile phones, which will typically have to be motivated by the secure transaction host, the software applications are generally only executable on so-called "smart phones" or other, more advanced phones, which offer more, advanced computing capabilities and connectivity than their more basic counterparts. A substantial number of mobile phones that are not capable of executing complex software applications are still actively being used all around the world. Authentication systems that require the execution of complex mobile phone applications are therefore not available to users of these phones.

Other completely offline solutions also exist in which a pass key is randomly generated by a mobile digital device each time the user wishes to perform a secure transaction. The pass key is generally a meaningless hash number generated according to some predefined algorithm or private key that is stored on the device and which the secure environment is able to recognise as having originated from an authorized device. This solution involves an initial hardware cost for the issuing institution (in most cases banks) and the user is forced to carry an extra piece of hardware with him or her. In addition, this technology still requires the user to enter a, sometimes lengthy and complicated, pass key before being allowed to conduct the secure transaction. As mistakes in transcribing the pass key from the mobile digital device will result in the transaction being rejected, this normally adds a significant time delay to the transaction as the user is forced to transcribe the pass key with great care. This solution is, however, also subject to various security threats. The fact that it is completely offline makes it vulnerable to abuse without the user's knowledge. Also if the key (OTP) generating device is stolen, the thief will be in possession of a device that generates legitimate OTPs and all the thief needs is a legitimate username and password, which can easily be obtained by spyware or other means. Existing user authentication systems known to the applicant therefore make use of either one factor authentication (user name and password) or offline two-factor authentication (as described in the two previous paragraphs) to protect sensitive information. Two-factor authentication (T-FA) generally refers to a system wherein two different elements, or factors, are used to authenticate the identity of a person or information. The two factors normally include something the person to be authenticated has in his possession (for example the pass key generating hardware device or mobile phone in the examples above), and something he or she knows (for example a username and password). Using two factors as opposed to one delivers a higher level of authentication integrity. Any type of authentication in which more than one factor is used is generally referred to as strong authentication.

In the remainder of this specification the term "secure transaction" should be widely construed and may include any instance where user authentication is required before conducting a secure operation or before access is granted to a secure environment. Likewise, a "host of a secure transaction" or "client" should be widely construed to include any institution that offers secure services or transactions and that may require the authentication of its users in order to provide the services. In addition, the acronym USSD should be understood to mean Unstructured Supplementary Service Data, which is a messaging capability associated with all GSM phones. OBJECT OF THE INVENTION

It is an object of the invention to provide a secure transaction authentication system and method that will at least partially alleviate the abovementioned problems with existing authentication systems.

SUMMARY OF THE INVENTION

In accordance with this invention there is provided a method for authenticating a secure transaction to be conducted between a secure transaction host and a transacting user, the method to be carried out at an authentication server and comprising the steps of:

receiving an authentication request from the secure transaction host, the authentication request including at least a purported identity indicator of the transacting user and details of the secure transaction;

receiving a USSD session initiation message from a network provider, the USSD session initiation message including a user identifier verified by the network provider;

comparing the user identifier to the purported identity indicator;

transmitting a transaction confirmation request to a mobile communications device of the transacting user by means of a USSD message if the user identifier and purported identity indicator correspond, the transaction confirmation request including details of the secure transaction and requesting the user to confirm or deny its intended performance of the secure transaction;

receiving a confirmation or denial result from the mobile communications device of the transacting user by means of a USSD message; in response to a confirmation result, transmitting a positive authentication result to the secure transaction host; and

in response to a denial result, transmitting a negative authentication result to the secure transaction host.

A further feature of the invention provides for the mobile communications device to be a mobile telephone.

Further features of the invention provide for the USSD session initiation message to include the USSD string; for the authentication request to include the USSD string; for the method to include the step of the authentication server marking a received authentication request as a waiting request until it receives a USSD session initiation message containing a USSD string corresponding to that included in the authentication request and of which the user identifier corresponds to the purported identity indicator; for all USSD messages between the transacting user and authentication server to go through the network provider; and for the user identifier and purported identity indicator to be mobile phone numbers. The invention further provides a system for authenticating a secure transaction conducted between a transacting user and a secure transaction host, the system comprising:

an authentication service provider including at least one authentication server; and

a network provider; wherein the authentication server is configured to: receive an authentication request from the secure transaction host, the request including at least a purported identity indicator of the transacting user and details of the secure transaction;

receive a USSD session initiation message from the network provider, the USSD session initiation message including a user identifier verified by the network provider;

compare the user identifier to the purported user identity indicator;

transmit a transaction confirmation request to a mobile communications device of the transacting user by means of a USSD message if the user identifier and purported identity indicator correspond, the transaction confirmation request including details of the secure transaction and requesting the user to confirm or deny its intended performance of the secure transaction;

receive a confirmation or denial result from the mobile communications device of the transacting user by means of a USSD message; and

in response to a confirmation result, transmit a positive authentication result to the secure transaction host; and

in response to a denial result, transmit a negative authentication result to the secure transaction host.

Further features of the invention provide for the mobile communications device to be a mobile phone; for the USSD session initiation message to include the USSD string; for the authentication request to include the USSD string; for the authentication server to be further configured to mark a received authentication request as a waiting request until it receives a USSD session initiation message containing a USSD string corresponding to that included in the authentication request and of which the user identifier corresponds to the purported identity indicator; for all USSD messages between the transacting user and authentication server to go through the network provider; and for the user identifier and purported identity indicator to be mobile phone numbers.

The invention also provides a system for authenticating a secure transaction comprising:

a secure transaction host operable to conduct a secure transaction with a transacting user;

an authentication service provider including at least one authentication server operable to authenticate the transaction between the secure transaction host and the transacting user; and

a network provider operable to receive a USSD session initiation from a mobile communications device of the transacting user, the USSD session initiation including at least a USSD string and an IMSI number associated with the SIM card used in the mobile communications device, to look up the identity of the transacting user by correlating the IMSI number to a database of subscribers, and to extract a user identifier from the database;

the system being characterized in that the secure transaction host is further operable to provide the transacting user with the USSD string and to transmit an authentication request to the authentication server, the authentication request including at least a purported identity indicator of the transacting user and details of the secure transaction;

the authentication server in turn being operable to:

receive the authentication request from the transaction host and mark it as a waiting request;

receive a USSD session initiation message from the network provider, the message including at least the user identifier and the

USSD string;

send a transaction confirmation request to the mobile communications device of the transacting user via USSD if the user identifier corresponds to the purported identity indicator of the waiting request, the transaction confirmation request including the details of the secure transaction and requesting the user to confirm or deny its intended performance of the secure transaction by means of a USSD message;

receive a confirmation or denial result from the mobile communications device of the transacting user;

in response to a denial result, transmit a negative authentication result to the secure transaction host. Further features of the invention provide for the mobile communications device to be a mobile phone; for the authentication request to include the USSD string; and for the user identifier and purported identity indicator to be mobile phone numbers.

The invention still further provides a method of authenticating a secure transaction conducted between a secure transaction host and a transacting user, the method to be carried out at an authentication server and comprising the steps of: receiving an authentication request from the secure transaction host, the authentication request including at least a purported identity indicator of the transacting user; initiating a USSD session with a mobile communications device associated with the purported identity indicator via a network provider, the association between the purported identity indicator and transacting user being verified by the network provider; transmitting a transaction confirmation request to the mobile communications device by means of a USSD message over the USSD session, the transaction confirmation request including details of the secure transaction and requesting the user to confirm or deny its intended performance of the secure transaction; receiving a confirmation or denial result from the mobile communications device of the transacting user by means of a USSD message; in response to a confirmation result, transmitting a positive authentication result to the secure transaction host; and in response to a denial result, transmitting a negative authentication result to the secure transaction host.

Further features of the invention provide for the mobile communications device to be a mobile telephone and the network provider is a mobile phone network provider; for the authentication request to include details of the secure transaction; and for the transaction confirmation request to further include a message requesting the user to provide a personal identification number by means of a USSD message over the USSD session. The invention further provides a system for authenticating a secure transaction conducted between a transacting user and a secure transaction host, the system comprising: an authentication service provider including at least one authentication server; and a network provider, the system being characterised in that the authentication server is configured to: receive an authentication request from the secure transaction host, the request including at least a purported identity indicator of the transacting user and details of the secure transaction; initiate a USSD session with a mobile communications device associated with the purported identity indicator of the transacting user via the network provider, the association between the purported identity indicator and mobile communications device being verified by the network provider; transmit a transaction confirmation request to the mobile communications device of the transacting user by means of a USSD message, the transaction confirmation request including details of the secure transaction and requesting the user to confirm or deny its intended performance of the secure transaction; receive a confirmation or denial result from the mobile communications device of the transacting user by means of a USSD message; and in response to a confirmation result, transmit a positive authentication result to the secure transaction host; and in response to a denial result, transmit a negative authentication result to the secure transaction host.

Further features of the invention provide for the mobile communications device to be a mobile phone; and for the authentication server to be further configured to request a personal identification number from the transacting user and receive the personal identification number by means of a USSD message from the mobile communications device. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described, by way of example only with reference to the accompanying representation in which:

Figure 1 is a schematic illustration of an authentication system in accordance with the invention; and Figure 2 is a schematic illustration of a second embodiment of an authentication system in accordance with the invention.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS A system (1) for authenticating a secure transaction is shown in Figure 1. The system (1) includes a secure transaction host (3) at which is situated a web server (5) and an authentication server (7) maintained by an authentication service provider. The authentication server (7) is capable of communicating with a mobile phone network provider (9) via a GSM network (11).

When a user (13) attempts to conduct a secure online transaction with the secure transaction host (3) from, for example, a personal computer (15), the user (13) logs into a website operated by the transaction host (3) and typically enters a predefined username and password (17) which gains him or her access to a user account with the transaction host (3). The web server (5) receives the username and password and, if they are valid, identifies a user account which corresponds thereto. The web server (5) then retrieves a purported user identity indicator, in this case a mobile phone number, of the user associated with the identified account. It should be appreciated that at this stage of the process the identity of the user has not been verified and the identity therefore simply represents who the transacting user purports to be. If the web server (5) identifies the username and password as relating to a valid account, it displays an Unstructured Supplementary Service Data (USSD) string on the user's computer (15) as well as a message requesting the user to enter the USSD string on his or her mobile phone (19). The web server (5) also sends an authentication request (21) to the authentication server (7) which includes the purported identity indicator of the transacting user (13) as well as, optionally, the USSD string that was displayed to the user (13). The authentication server (7) then logs the authentication request and marks it as a waiting request. The authentication server (7) then waits for the user to initiate a USSD session from its mobile phone.

On request by the web server (5), the user enters the USSD string on its mobile phone (19) and initiates a USSD session, typically by pressing the dial button. A USSD message containing the USSD string is then sent to the network provider (9).

As a standard in GSM communication USSD messages (and any other GSM supported communication for that matter) include the International Mobile Subscriber Identity (IMSI) number of the SIM card being used in the applicable mobile phone. The IMSI number of the SIM card, along with its associated MSISDN number, which is a number uniquely identifying a subscription in a GSM or UMTS mobile network, typically the telephone number to the SIM card of a mobile/cellular phone, are in turn stored by the network provider (9) in a database (generally referred to as the Home Location Register (HLR)) which contains information of all the network provider's subscribers. It is generally assumed that a one to one relationship exists between an individual and the IMSI number of the SIM card used in its mobile phone.

Upon receipt of the USSD message by the network provider (9), the network provider (9) retrieves a user identifier associated with the mobile phone (19) from where it originates, and transmits a USSD session initiation message to the authentication server (7), along with the user identifier of the user (13) from where it originates. As before, the user identifier in the embodiment described is a mobile phone number. It is also possible that communication between the network provider and the authentication server may be conducted through and intermediary such as, for example, a Wireless Application Services Provider (WASP).

It should be appreciated that one or more USSD strings may be exclusively allocated to an authentication server (7) of a particular transaction host (3). In this way the network provider (9) will always know to which transaction host the USSD session initiation relates.

Upon receipt of the USSD initiation message, the authentication server (7) checks its logs to determine if a request is waiting which has a purported identity indicator corresponding to the user identifier. If a waiting request is identified for the identified user, the authentication server (7) transmits a USSD message to the user (13), via the network provider (9) which contains the details of the transaction the user is attempting to conduct, and further request the user (13) to either confirm (accept) or deny (reject) the transaction by sending a USSD message to the authentication server containing its choice.

Upon receipt of the user's (13) choice, the authentication server (7) transmits a positive authentication result to the web server (5) of the transaction host (3) in response to a confirmation result from the user (13), and a negative authentication result in the case of a denial by the user (13). The transaction host (3) accordingly knows whether or not to allow the requested secure transaction.

It should be appreciated that the identification of the transacting user is done at two independent levels, firstly by the web server upon receipt of the user's username and password, and secondly by the network provider upon receipt of the USSD session initiation from the user using the IMSI number associated with the SIM card of the mobile phone. The authentication is therefore a good example of strong authentication. Only if the identity of the user determined at both stages corresponds, will it be possible to continue with the transaction at all. In addition, the user then still has the opportunity to accept or reject the transaction from his or her mobile phone.

USSD is generally associated with real-time or instant messaging type phone services. In addition, USSD messages do not generally get stored by the network providers before they are forwarded to their intended recipients, as is normally the case with standard SMS or MMS messages. In technical terms a Short Message Service Centre (SMSC) is therefore not present in the processing path. This can greatly accelerate response times and also adds an additional level of security as it is not possible to intercept USSD messages from a storage location. All these features make USSD particularly suited for use in an authentication system as proposed by the invention. In the embodiment of the invention described above, the USSD session is initiated from the user's side. In other words, the user has to take the first step by sending the USSD initiation from its mobile phone. The authentication server can only communicate with the transacting user via USSD if the user has initiated the USSD session. All communication is then conducted over the open USSD session until such time as it is terminated. International USSD standards, however, provide for a USSD session to be initiated from the network's side. This is generally referred to as a push operation. A push operation implies that, instead of the user having to take the first step by entering the USSD string on its mobile phone and accordingly initiated the USSD session, the authentication server may simply request the network provider to initiate the USSD session with the identified user or even be allowed by the network operator to initiate it directly. This allows the transaction details and acceptance/denial request to be sent to the user's mobile phone without the user first having to initiate the session. This would simplify the system even further, as well as alleviate the possibility of errors occurring while the user transcribes the USSD string onto his or her mobile phone.

A second embodiment of a system (1) for authenticating a secure transaction utilising a network initiated USSD session is shown in Figure 2. In the figure, the secure transaction host (23) is a telephone call centre at, for example, a banking institution which allows for telephone banking. The call centre has at least one call centre operator (25) and an authentication server (27) maintained by an authentication service provider. As before, the authentication server (27) is capable of communicating with a mobile phone network provider (29) via a GSM network (31).

When a user (33) phones the call centre (23) from his or her mobile phone (39), or any other phone for that matter, he or she is typically requested by the call centre operator (25) to answer a number of security questions such as, for example, his or her telephone number, bank account details, addresses, e-mail addresses and the like. If the user is unable to correctly answer all these questions he or she is not allowed to conduct the transaction telephonically.

Instead of asking all the security questions and relying on the user to answer all of them correctly, the call centre operator (25) simply asks the user to identify him or herself. The user may identify him or herself by, for example, verbally communicating a username and password (37) to the operator (25). The operator then enters the username and password at a computer terminal (26) which is connected to a user database (not shown) containing account details of all the users with accounts at the transaction host. If the user's proposed identity corresponds to one of the accounts on the database, the terminal retrieves a purported user identity indicator, again a mobile phone number, of the user associated with the identified account. It should be appreciated that at this stage of the process the identity of the user has not been verified and the identity therefore simply represents who the transacting user purports to be.

If the terminal identifies the purported user identity as relating to a valid account in the database it sends an authentication request (41) to the authentication server (27) which includes the purported identity indicator of the transacting user (33).

The authentication server (27) then initiates a USSD session (30) with the mobile phone (39) of the user (33) via the network provider (29). It should be appreciated that this may, in practice, be done by the authentication server (27) requesting the network provider (29) to initiate the session while providing to it, amongst others, the purported identity indicator, which in this case corresponds to the user's mobile phone number. Alternatively, the network provider (29) may provide the authentication server (27) with the capabilities of initiating the session directly, without having to request it first. As before, communication between the network provider and the authentication server may be conducted through and intermediary such as, for example, a Wireless Application Services Provider (WASP).

As explained in more detail above, the network provider (29) will then be able to look up the mobile phone number in the HLR and identify therefrom the IMSI number associated with the SIM card of the purported user's mobile phone. The network provider (29) will therefore initiate the USSD session (30) with the mobile phone recorded in its database as belonging to the purported user. On receipt of the USSD session initiation, the user's (33) mobile phone (39) displays a message (34) containing details of the transaction the user is attempting to conduct, and requests the user (33) to either confirm (accept) or deny (reject) the transaction by sending a USSD message (36) back to the authentication server (27) via the network provider (29) containing its choice.

The message (34) may also request the user (33) to enter a personal identification number (PIN) on the phone and transmit it back to the authentication server over the USSD session.

Upon receipt of the user's (33) choice, possibly in combination with a PIN, the authentication server (27) transmits a positive authentication result (42) to the computer terminal (26) of the relevant operator (25) at the transaction host (23) in response to a confirmation result from the user (33) and a correct PIN, and a negative authentication result in the case of a denial of the transaction by the user (33) and/or an incorrect PIN. The transaction host (23) accordingly knows whether or not to allow the requested secure transaction.

The transaction details in this example could simply include requesting the user whether he or she is attempting to conduct a telephone banking transaction. It should also be appreciated that numerous USSD authentication requests may be conducted during the course of a single telephone transaction, requesting the user to confirm or deny its next intended action.

It should also be appreciated that the authentication may be conducted while the user is communicating with the call centre operator over the same mobile phone on which the authentication is being conducted, as most mobile phones are generally capable of handling USSD and voice communications simultaneously. As before, only if the user confirms its intended execution of the secure transaction via the USSD session to the network operator, will the user be allowed to verbally transact with the transaction host. To do so, the user and its mobile phone generally have to be in the same physical location. If an imposter is trying to fraudulently transact with the call centre and is not in possession of the user's mobile phone, the real user still has the opportunity of rejecting the transaction from his or her mobile phone.

The system explained with reference to Figure 2 therefore alleviates the need for call centre operators to ask a series of security questions which could greatly reduce the time needed to conduct the telephonic transaction as well as reduce the nuisance factor typically posed by these questions. In additional, the additional layer of security provided by the user being requested to enter a PIN means that not only is the user in possession of the phone and, more importantly, the SIM card with the correct IMSI number, but it also has knowledge of the PIN. In addition to what is said above, USSD messages are generally cheaper than, for example SMS or MMS messages, thus making its use even more beneficial.

It should also be appreciated that the system could be employed with network initiated USSD in any number of transactions and that its use is definitely not limited to the embodiment described. Network initiated USSD offers substantial advantages over user initiated USSD in that the user does not have to take additional steps in order for the system to be implemented. The system could therefore be rolled out to any number of users on an existing platform without any further user interaction.

The above description is by way of example only and it should be appreciated that numerous changes may be made to the embodiments described without departing from the scope of the invention. In particular, it should be appreciated that the authentication system is not limited in its application to secure online (Internet) transactions. It could also be utilized in other secure transactions such as, for example, access to a secure client domain, online financial transactions, offline financial transactions, online purchases, offline purchases, access to databases, access to information, physical access to buildings or other premises, access to computer networks, subscriber websites, network portals, ATM transactions and the like. In cases where the transactions are not conducted online, it will be appreciated that the server at the transaction host does not have to be a web-server, but could be any server capable of communicating with the authentication server.

The system may also be used as a pre-authorisation mode in which case the user may initiation a USSD session with the authentication server by entering a known USSD string on his or her mobile phone. The authentication server may then, by means of a series of menu options, allow the user to pre- authorise a secure transaction at any number of pre-authorized transaction hosts. The pre-authorised transaction will then be stored at the authentication server and if the user later attempts to conduct the transaction the authorisation will already be in place and can simply be retrieved by the transaction host and the transaction authorised without delay. This could, for example, be used if a user wishes to withdraw money from an ATM but does not wish to present his or her mobile phone while waiting at the ATM.

Numerous changes may also be made to the physical lay-out of the system, in particular to the network topography of the system, without departing from the scope of the invention. In particular, it is foreseeable that numerous authentication and host servers may be connected in a network configuration and that authentication may be handled by an authentication server which could process the authentication in the shortest amount of time. It is also foreseeable that the authentication server may be physically remote from the transaction host, in which case the authentication may be conducted over a suitable communications network.

It is also foreseeable that the user identifier and purported identity indicator may be any one of a number of things including, but not limited to, personal information, personal identification numbers, specially assigned identifiers and the like.

It should be appreciated that the invention is still capable of functioning despite the user losing his or her mobile phone. If a user's mobile phone is lost or broken it is generally easy to put the SIM card of the old phone into a new one, in which case the system will continue functioning as usual. In the case of a lost or stolen phone the user simply has to deactivate his or her old SIM card and apply for a new one, after receipt of which his or her personal records will have been updated accordingly with a new IMSI number associated with the new SIM card. The user's mobile phone number will, however, generally remain unchanged.

Finally, it should be appreciated that secure transaction hosts may obtain fixed, unique USSD strings which can be associated with all transactions conducted through them. In this case it would not be necessary for the transaction host to repeatedly display the USSD string to the transacting user and the user may simply store the USSD string associated with the transaction host in his or her mobile phone phonebook and initiate USSD sessions with the appropriate transaction host as and when required, without having to transcribe a USSD string in order to do so.

Claims

A method of authenticating a secure transaction to be conducted between a secure transaction host (3) and a transacting user (13), the method to be carried out at an authentication server (7) and comprising the steps of:

receiving an authentication request (21) from the secure transaction host, the authentication request including at least a purported identity indicator of the transacting user (13);

receiving a USSD session initiation message from a network provider (9), the USSD session initiation message resulting from a USSD session initiated by the user (13) and including a user identifier verified by the network provider (9);

comparing the user identifier to the purported identity indicator; transmitting a transaction confirmation request to a mobile communications device (19) of the transacting user by means of a USSD message if the user identifier and purported identity indicator correspond, the transaction confirmation request including details of the secure transaction and requesting the user (13) to confirm or deny its intended performance of the secure transaction;

receiving a confirmation or denial result from the mobile communications device (19) of the transacting user (13) by means of a USSD message;

in response to a confirmation result, transmitting a positive authentication result to the secure transaction host (3); and

in response to a denial result, transmitting a negative authentication result to the secure transaction host (3).

A method as claimed in claim 1 in which the authentication request includes details of the secure transaction.

3. A method as claimed in any one of the preceding claims in which the USSD session initiation message includes a USSD string.

A method as claimed in any one of the preceding claims in which the authentication request includes the USSD string.

A method as claimed in claim 4 which includes the step of the authentication server (7) marking a received authentication request as a waiting request until it receives a USSD session initiation message containing a USSD string corresponding to that included in the authentication request and of which the user identifier corresponds to the purported identity indicator.

A method as claimed in any one of the preceding claims in which all USSD messages between the transacting user (13) and authentication server are routed through the network provider (9).

A method as claimed in any one of the preceding claims in which the user identifier and purported identity indicator are mobile telephone phone numbers.

A method of authenticating a secure transaction conducted between a secure transaction host (23) and a transacting user (33), the method to be carried out at an authentication server (27) and comprising the steps of:

receiving an authentication request (41) from the secure transaction host, the authentication request including at least a purported identity indicator associated with the transacting user (33); initiating a USSD session (30) with a mobile communications device (39) associated with the purported identity indicator through a network provider (29), the association between the purported identity indicator and mobile communications device (39) being verified by the network provider;

transmitting a transaction confirmation request (34) to the mobile communications device (39) by means of a USSD message over the USSD session, the transaction confirmation request (34) including details of the secure transaction and requesting the user (33) to confirm or deny its intended performance of the secure transaction; receiving a confirmation or denial result (36) from the mobile communications device (39) of the transacting user (33) by means of a USSD message;

in response to a confirmation result, transmitting a positive authentication result to the secure transaction host (23); and

in response to a denial result, transmitting a negative authentication result to the secure transaction host (23).

9. A method as claimed in claim 8 in which the transaction confirmation request (34) further includes a message requesting the user (33) to provide a personal identification number by means of a USSD message over the USSD session.

10. A system (1 ) for authenticating a secure transaction conducted between a transacting user (13, 33) and a secure transaction host (3, 23), the system comprising:

an authentication service provider including at least one authentication server (7, 27); and

a network provider (9, 29), the system being characterised in that the authentication server (7, 27) is configured to:

receive an authentication request (21 , 41 ) from the secure transaction host (3, 23), the request including at least a purported identity indicator of the transacting user (13, 33) and details of the secure transaction;

establish a USSD session with a mobile communications device (19, 39) associated with the transacting user (13, 33) through the network provider (9, 29);

transmit a transaction confirmation request to the mobile communications device (19, 39) of the transacting user (13, 33) by means of a USSD message over the USSD session, the transaction confirmation request including details of the secure transaction and requesting the user (13, 33) to confirm or deny its intended performance of the secure transaction;

receive a confirmation or denial result from the mobile communications device (19, 39) of the transacting user (13, 33) by means of a USSD message; and

A system as claimed in claim 10 in which the USSD session between the mobile communications device (19) and the authentication server (7) is initiated by the transacting user (13) from the mobile communications device ( 9).

A system as claimed in claim 11 in which the authentication server (7) is further configured to receive a USSD session initiation message from the network provider (9), the USSD session initiation message including a user identifier verified by the network provider (9), to compare the user identifier to the purported user identity indicator and to transmit the transaction confirmation request only if the user identifier and purported identity indicator correspond.

A system as claimed in any one of claims 10 to 12 in which the authentication server (7) is further configured to mark a received authentication request as a waiting request until it receives a USSD session initiation message containing a USSD string corresponding to a second USSD string included in the authentication request and of which the user identifier corresponds to the purported identity indicator.

14. A system as claimed in any one of claims 10 to 13 in which the network provider (9) is operable to receive a USSD session initiation from the mobile communications device (19) of the transacting user

(13), the USSD session initiation including at least a USSD string and an IMSI number associated with a SIM card used in the mobile communications device (19), to look up an identity of the transacting user (13) by correlating the IMSI number to a database of subscribers, and to extract the user identifier from the database.

15. A system as claimed in claim 10 in which the authentication server (27) is further configured to initiate the USSD session with the mobile communications device (39).

16. A system as claimed in claim 15 in which the network provider (29) is configured to verify an association between the purported identity indicator and the mobile communications device (39) of the transacting user (33).

17. A system as claimed in any one of claims 10 to 16 in which the authentication server (7, 27) is further configured to request a personal identification number from the transacting user (13, 33) and receive the personal identification number by means of a USSD message over the USSD session from the mobile communications device (19, 39).