WO2006016850A1

WO2006016850A1 - Authentication method and system

Info

Publication number: WO2006016850A1
Application number: PCT/SG2004/000239
Authority: WO
Inventors: C. Alfredo Fajardo
Original assignee: Veritas Mobile Solutions Pte. Ltd.
Priority date: 2004-08-07
Filing date: 2004-08-07
Publication date: 2006-02-16
Also published as: MY151711A; AR050000A1; TW200625906A

Abstract

There is disclosed a system and method for authenticating a transaction conducted by electronic messaging between a client device having an associated client device address and a host that provides messaging services for a plurality of clients, the method comprising a) sending a first message from the client device to the host; b) generating a public key in response to the first message; c) associating the public key with the client device address; d) sending a message from the host to the device address, the message containing the public key; e) sending a second message from the client device to the host, the message including the public key; f) comparing the public key and client device address of the second message with the public key and client device address of step c).

Description

AUTHENTICATION METHOD AND SYSTEM

The invention relates to the authentication of electronic messages in order to prevent spoofing. In particular, the invention has application in transactions involving wireless devices or email clients. The communications may be from wireless devices such as mobile phones, PDAs (Personal Digital Assistants), PPCs (portable personal computers) and the like. The invention may be particularly useful in the provision of financial transaction services using email or similar types of electronic messaging such as SMS (short messaging system).

The undertaking of financial transactions between two parties using electronic messaging such as with wireless devices and e-mail services has not been seriously pursued in the past due to security considerations, whereby the ability of an unauthorised party to spoof the identity of one party without the knowledge of the other party is relatively straight forward to parties having some knowledge of the protocol followed in the communication exchange between a payor and a payee.

In recent times, with the added security features provided by mobile phones operating under the GSM (Global System for Mobile Communications) network, the area has been further developed and a number of different types of payment system using wireless devices have come on to the market.

In one such payment system, facility is made for a user to call a prescribed telephone number of a financial service provided having a server set up to answer and process the telephone call. The user is initially prompted to enter a PIN (personal identification number) and is then advised to follow further prompts to make or request a payment instantly to or from another user/business/e-commerce business with a GSM phone number or a prescribed identification number of the financial service provider. When the user calls the financial service provider for the first time he/she is asked to record a personal greeting so that other users known to the user will easily identify him/her when making a payment between them. Accordingly, in a subsequent financial transaction occurring between the user and the other user using the system, the other user provides authentication of the user by way of sound recognition of the recorded greeting of the user, which is automatically played to the other user via their mobile phone on receiving a call from the server concerning the transaction, before the transaction is allowed to be undertaken.

Such an arrangement is relatively cumbersome and indeed is not practical to use when the parties are not familiar with each other. Furthermore, the implementation of such a system is more PC centric, involving the registration of users via a PC connected to the Internet, and thus is not able to be used with users having exclusive access to a wireless device and communicating solely by way of the instant messaging system provided therewith.

In the area of e-mail communications, due to its close affiliation with the Internet and browser based applications for accessing the same, using e-mail as a real time communication medium for performing financial transactions has never seriously been contemplated, given the superior real time characteristics of the Internet and the greater flexibility and power with operating security applications therein to avoid fraudulent and unauthorised transactions from occurring. However, there are still a significant number of persons who are confined to, or indeed prefer to, use e-mail as their principal communication medium in party-to-party communications. Thus, creating a financial transaction system and methodology that operates effectively with e-mail would still have widespread consumer appeal, notwithstanding the popularity of the Internet and accessing the same with browser based devices.

WO-A-03019445 discloses a financial transaction system and method, which will be described with reference to Figure 1.

A method and a system for performing financial transactions between parties having clients (15a, 15b) with an electronic messaging facility and a banking account facility with a financial institution. Each party has an electronic messaging address or Customer Identification Number (CIN) associated with the electronic messaging facility and a Customer Account Number (CAN) associated with the banking account facility (27) thereof.

A financial service provider service (13) is interfaced with the electronic messaging facility to handle communications between the clients (15a, 15b) of the parties and is also interfaced with the banking account facilities (27) of the parties to perform the financial transaction. The electronic messaging address (CIN) of each party is linked with the banking account facility therefor, and thus the banking account number(s) (CAN) thereof, within a database (45) associated with the server (13) to facilitate the financial transaction.

The server (13) undertakes an authentication process within one and/or the other party using the electronic messaging facility requiring confirmation of a PIN also stored in the database (45). The authentication process is characterised by the server (13) providing the client (15a) of the one party instigating the financial transaction with a different electronic messaging address to "reply to" when requesting the PIN, from the original electronic messaging address of the server (13) used by that same party to initiate the financial transaction, to enhance the security of the transaction.

In the present application the term electronic messaging refers to those messages between two computing devices, including mobile communication devices and the like, where there is no real time contact between the parties. The devices do not handshake to provide a session connection, instead the devices intermittently connect only to receive or send a message, which is generally transferred via an intervening host server.

The term 'spooffing' is derived from internet security terminology and refers to a type of impersonation where a person intercepts communications between parties and 'pretends' to be a first one of the parties thereby gaining access to the computer of the second party. A spoof might involve hijacking a persons email address or impersonating a web site so as to receive communications intended for that web site. Spoofing is generally a blind attach on a system, allowing the person spoofing to issue commands or other communication to one party but without receiving any responses directly.

While it is true that messages received in your mobile phone or e-mail inbox can be spoofed, messages emanating from both cannot. One can receive "spoofed" messages from a mobile phone or email address. However, it is virtually impossible to spoof a message from a phone or email address that is intended for a specific session identifier.

It is an object of the present invention to provide improved authentication for messages sent via wireless media like SMS (Short Message Service) and wired media like e-mail. It is a further object of the present invention to overcome the problems associated with the 'spoofable' nature of SMS and e-mail. The invention provides a method of authenticating a transaction conducted by electronic messaging between a client device having an associated client device identifying code and a host that provides messaging services for a plurality of clients, the method comprising: a) sending a first message from the client device to the host; b) generating a public key in response to the first message; c) associating the public key with the client device identifying code; d) sending a message from the host to the device identifying code, the message containing the public key; e) sending a second message from the client device to the host, the message including the public key; f) comparing the public key and client device identifying code of the second message with the public key and client device identifying code of step c).

The host server may be in communication with a transaction server of a third party holding a plurality of client accounts and the client device identification code is associated with a particular client account. The client device identification code may be associated with a particular client account on the transaction server. The client device identification code may be associated with a particular client account on the host server.

The user of the client device may have a personal identification code (PESf) that is associated with the client device identification code on the host server. The PIN may be associated with the client device identification code in an initial registration procedure. The PIN may be provided to the host server in the message from the client device in step e) in order to authenticate the party using the client device.

The step b) preferably includes generating a transaction record including details associated with the client device identification code and associating those details with the public key, whereby the public key or public key and private combination acts as a transaction code which can be used to both authenticate the transaction and identify the transaction to be performed.

The invention also provides a system for authenticating a transaction conducted by electronic messaging between a client device having an associated client device identifying code and a host that provides messaging services for a plurality of clients, the host server being adapted to: a) receive a first message from the client device; b) generate a public key in response to the first message; c) associate the public key with the client device identifying code; d) send a message from the host to the device identifying code, the message containing the public key; e) receive a second message from the client device, the message including a key in the body of the message; f) comparing the key and client device identifying code of the second message with the public key and client device identifying code of c) above.

The user of the client device may have a personal identification code (PIN) that is associated with the client device identification code on the host server. The host server may be adapted to associate the PIN with the client device identification code in an initial registration procedure.

The host server is preferably adapted to generate a transaction record on receipt of the first message, the transaction record including details associated with the client device identification code, the host server associates those details with the public key, whereby the public key or the combination of the public key with the PIN, acts as a transaction code which can be used to both authenticate the transaction and identify the transaction to be performed.

The invention will now be described in more detail with reference to the accompanying drawings, in which;

Figure 1 is a schematic diagram of a transaction system in which an embodiment of the present invention can be used; Figure 2 is a block diagram showing the components of the transaction system of Figure 1;

Figure 3 is a schematic block diagram showing an example of a communication packet sent between a client and a server or vice versa;

Figure 4 is a flow diagram showing an authentication process according to an embodiment of the present invention.

The authentication process of the present invention can be used to authenticate in any transaction between an electronic mail client such as a mobile wireless device or an email client, and a host computer such as an email server or an SMS Centre (SMSC). A transaction system is described with reference to Figures 1 to 3, which is directed towards an electronic system comprising a client server computer system for performing financial transactions between a plurality of parties using electronic messaging. In the present embodiment, the parties each have a wireless device that constitutes a client of the system and each have account facilities with one or more banks or similar financial institutions. Accordingly, financial transactions are performed utilising electronic messaging in the form of SMS text messages. In alternative embodiments other message formats may be used such as email. Alternatively the system may allow the user to choose one of a number of messaging formats.

As shown in Figure 1 of the drawings, the system 11 generally comprises a financial service provider server, which functions as a host server 13; a plurality of clients 15, one client 15a being in the form of a PDA, and another client 15b being in the form of a mobile telephone, which clients 15a and 15b are respectively associated with parties A and B to a financial transaction; a GSM mobile telephone network 17 having instant messaging facilities of the SMS type, the network including GSM towers 19a and 19b to which the clients 15a and 15b are in communication range for effecting the financial transaction; an SMSC (SMS Centre) server 21 forming part of the GSM network 17 for controlling and managing the SMS communications within the GSM network; a communication link 23 interconnecting the host server 13 and the SMSC server 21 for allowing communications therebetween so that the GSM network in conjunction with the host server form a larger communication network; account facilities 25 for each party are housed in a particular bank of the party, one bank housing the facility 25a for party A, and another bank housing the facilitity 25b for party B, each facility comprising one or more different account types 27, which are accessible via banking servers 29a and 29b respectively associated with the banks; and further communication links 31 between the host server 13 and the banking servers 29, the further link 31a specifically connecting the host server to the banking server 29a associated with the bank of party A, and the further link 31b connecting the host server to the banking server 29b associated with the bank of party B.

The operation of GSM networks using SMS messaging and the transferring of instant messages between mobile clients and a host server via an SMSC of the type being the subject of the present embodiment has been described in International Patent Applications PCT/SGOO/00068, PCT/SGOO/00069, PCT/SGOO/00070, PCT/SGOO/00092, PCT/SGOO/00127 and Singapore Patent Application 200007381-7.

A salient feature of each of the wireless clients disclosed in the aforementioned applications and which is also adopted in the present embodiment is the use of the network identifying number, for uniquely identifying the wireless client to the wireless communication network - in this case the GSM telephone number of the client in the GSM mobile telephone network 17 - as the client identifying number (CIN) used by the host server 13 for identifying the client within its own database.

As also indicated in the aforementioned applications, the communication link 23 between the host server 13 and the SMSC server 21 may be a dedicated channel, such as a leased line, or a general-purpose channel, such as via the Internet.

With respect to the account facilities 25 associated with each client, in the present embodiment, the account types 27 comprise one or more personal accounts 33, such as a debit-credit savings account 33a and a debit-credit current or cash account 33b, and a host account 35 belong to the financial service provided that hosts the host server 13. The host account 35 is common to all of the parties that are customers of a particular bank, whereby each bank having a customer that is a party associated with a client of the system, also has a common host account. The reason for this will become apparent later. The personal accounts 33 of a party associated with each client 15 are identified by a client account number (CAN), which needs to be registered with the host server 13. Accordingly, the host server 13 uses the CAN to access the personal accounts 33 of a party when communicating with a corresponding banking server 29, via the appropriate further link 31.

In order to authenticate a client of a party desiring to access an account facility with the bank, it is customary for the party to have a PIN, which is secretly recorded with the bank, and supply this PIN together with the name of the party and the CAN, before access to the account will be allowed. In the present embodiment, a similar authentication procedure with clients of parties is also required by the host server 13 before it is able to access the account facility in response to a request by a client of a party in order to effect a financial transaction. Accordingly, each client of the host server is required to have a PIN registered by way of the client with the host server. In a similar manner to the bank, the host uses the PIN to correctly authenticate a client wishing to perform a transaction, before the transaction is allowed to be undertaken.

In order to provide for financial transactions between two clients, the host server 13 is specially configured to incorporate various processes for registering the clients and performing the transaction. As shown in Figure 2 of the drawings, these processes include a message handling means or message handler 37, a registering means or registrar 38, an authenticating means or authenticator 39, a transacting means or transactor 41 and a transaction abandoning means or abandonor 43. These processes variously communicate with a client database 45 that lists the CIN, PIN and CAN against each party having a client registered on the database so that the host server may perform a financial transaction therefor.

The client database 45 is a relational database, which allows for the account facilities of the party to be selected, either by nominating the GSM mobile telephone number of the party, or alternatively the CAN or a personal banking account number of the party if this is known.

The message handler 37 is programmed to receive text messages from clients of the host server 13 in accordance with prescribed client protocols, compile and send text messages to particular clients in accordance with prescribed server protocols, and interact with the authenticator 39 and client database 45 to verify the identity of the parties to a particular transaction, all according to a prescribed message handler control algorithm. The message handler 37 is also programmed to interact with the registrar 38 to effect registration of parties having clients wishing to utilise the services provided by the host server 13 of the financial service provider to perform financial transactions between various parties.

The message handler 37 also includes a pseudo-random number generating means or pseudo-random number generator 46 for randomly generating a "reply to" address in accordance with a prescribed protocol. The randomly generated "reply to" address is then used by the message handler as the "reply to" address for the host server 13 in the compiling of text messages sent to clients in accordance with the prescribed server protocol.

The message handler 37 also includes a timing means or timer 48 to count down a prescribed time period. The message handler is programmed to invoke the timer 48 and wait for receipt of reply text messages from clients within this prescribed time period and verify PINs for specific clients provided therein.

The authenticator 39 is programmed to authenticate a particular transaction being undertaken at a particular point in time after the message handler 37 has verified the identity of the parties to the transaction to a prescribed level of security, in accordance with a prescribed authentication control algorithm. Thus the authenticator 39 functions in conjunction with the message handler 37 to determine when a particular transaction between two parties has been authenticated sufficiently to be transacted.

The transactor 41 is programmed to actually effect a transaction between the parties using the account facilities 25 established at the respective banks of the parties, in accordance with a prescribed transaction control algorithm. The transactor 41 is not invoked until the authenticator 39 has authenticated the transaction. On the transaction being authenticated, the transactor 41 communicates with the relevant bank server(s) 29 to effect internal transactions between the personal accounts 33 of the parties and the common host account 35 at the relevant bank(s) using the CAN of the appropriate parties and the CAN of the host account to complete the transaction.

The abandonor 43 is programmed to abandon the operation of the host server 13 in attending to a transaction being undertaken in accordance with a prescribed transaction abandoning control algorithm. The abandonor 43 operates in conjunction with the message handler 37 to determine if the prescribed time period counted down by the timer 48 elapses without a requisite response being received by either party at the requisite address during the authentication process, after a party has been prompted to provide such a response. It also operates in conjunction with the message handler 37 to determine whether a PIN supplied by a party is verified by the message handler to be correct. If either the prescribed time period elapses or a PIN is not verified the abandonor 43 abandons the transaction by instructing the message handler 37 to send appropriate text messages to the relevant parties notifying them of the abandonment of the transaction and terminating further operation of the transaction process being undertaken by the message handler.

The client 15, on the other hand, is configured to incorporate a messaging means or messager 47. The messager 47 is a standard text messager for compiling and sending an SMS message packet 49 to an intended recipient as shown in Figure 3 of the drawings that is transmitted to and handled by the SMSC server 21 for delivery to the recipient.

As shown in Figure 3 the message packet 49 includes a message portion 51, an intended recipient address portion 53, a sender's address portion 55 and an SMSC server address portion 57.

In the case of performing a financial transaction between two parties using the services of the financial service provider, the message packet 49 needs to be compiled by a client using the messager 47 according to different prescribed client protocols in order to communicate with the host server 13. Similarly, the message handler 37 also needs to be able to compile message packets in accordance with different prescribed server protocols to communicate with the clients 15 of the parties.

As the communication network involves communications between the SMSC server 21 and the host server 13, an access code is used in text messages sent by a client to the host server to signify to the SMSC server that the message needs to be sent to the host server for receipt and actioning, as opposed to being sent as an SMS message directly to a client of the GSM telephone network, without the involvement of the host server. This access code performs a dual function in that, in addition to signifying that the text message needs to be sent to the host server 13, it also indicates to the host server 13, the nature of the transaction being performed. In the case of the present embodiment, it signifies that not only a financial transaction is desired to be performed, but also the nature of the transaction, for example whether the transaction is an account balance query, or a payment to be made from the instigating party to an intended recipient party using the clients thereof, or a payment to be made to the instigating party from an intended recipient party. Thus different access codes recorded with the SMSC server 21 are used to signify different types of transactions to be performed.

The above arrangement allows a party of a client 15a compiling a text message for the purposes of undertaking a financial transaction to simply enter:

(a) the access code pertaining to the nature of the transaction desired to be performed and, if the transaction is to be a party-to-party transaction, the GSM telephone number of the other party to the transaction as the intended recipient's address 53; and

(b) the amount of the transaction, if the transaction is to be a party-to-party transaction, in the message portion 51.

Once the text message is compiled, it then simply needs to be sent, and thereafter the transaction proceeds under the control of the host server 13.

Thus a financial transaction is undertaken by the clients 15 and the host server 13 sequentially following alternate prescribed protocols, whereby resultant message packets 59 are sent from a client to the host server 15, then from the host server to a client, and so on, until the financial transaction is completed.

An authentication process in accordance with an embodiment of the present invention will now be described with reference to Figure 4. Figure 4, includes a registration process (steps 101 to 108) and also a transaction process (steps 109 to 114).

In a first step (101) an email or wireless client send registration information to a host server. The this embodiment the client device is a wireless telephone. The information may be sent by an SMS message. The registration information will typically include the user's details and any other information required to perform the particular transactions that the host server performs. For example the information may include the Bank account number (CAN) of the user.

In a second step (102) the information is stored in a temporary database on the host including the client device identifying number or code (CIN), e.g. the telephone number. In order to authenticate the registration process the host generates a public key at a third step (103). The host sends an SMS message to the client device, that is, to the client device identifying number (CIN), the SMS message including the public key in the body of the message. The client replies to the host with a message including the public key at a fourth step (104).

The host server receives the message and checks in a fifth step (105) to see whether the public key is matched to the correct client device identifying number. In the preceding step where the host sends a message including the public key, the message may also include a randomly generated reply address for greater security. If the registration is authenticated, then the host stores the users details in a permanent database and the user is registered with the host for use of the host's services. A user account is set up in the database including the user's details.

In a sixth step (106) the host prompts the user to provide his PIN, which is sent by the user from the client device in a further SMS in a seventh step (107).

The host receives the PIN in an eighth step (108) and stores the PIN with the users other details in the user's account in the database. The PIN can, therefore, be tagged to the user's client device identifying number. In an alternative embodiment the PIN is not permanently stored in the database but is requested each time the user requests a transaction to be performed by the host.

When the user wishes a transaction to be performed by the host, the user sends a message to the host with an appropriate request in a ninth step (109). The message may include an access code as discussed in relation to Figures 1 to 3 above.

In a tenth step (110) the host creates a transaction record, which may include a transaction number, which is linked to the user's account and the transaction requested. The transaction record allows access to the account details such as the user's PIN and the client device identifying number (CIN). The host generates a public key which is associated with the transaction request and send a message to the user's client device identifying number in an eleventh step (111). The message in (111) includes the public key in the body of the message and includes instructions to combine the public key with the private key. Again, the user may be instructed to reply to a different address, but in the present invention that is not necessary.

In the twelfth step (112) the user sends a message to the appropriate address including the combination of the PIN and the public key for the new transaction.

The host receives the message sent in step (112) and authenticates the request by comparing the combined PIN / public key provided by the user with the information available in the transaction record in a thirteenth step (113). Finally, in a fourteenth step (114) the host performs the required transaction assuming the authentication is successful, and sends a confirmation to the user.

In contrast to previous mobile authentication processes, which require a user to send his PIN to a dynamically suffixed shortcode message, which serves as the public key, the unified key authentication method of the present embodiment provides that a system-generated public key within the message sent by the host to the client address. The user then replies to the message with Ms PIN and the previously generated public key to authenticate the transaction. In a specific example of the process of the present invention, the following steps are performed:

1. System (host) prompts user to enter a PIN or password. User enters 6789. Please note that the private and public keys can be in numbers, characters, or alphanumeric.

2. System tags mobile number or e-mail address to the private key (PIN).

3. To authenticate a transaction, system generates a public key and transaction number. The host sends the following message to the client address, "To confirm this transaction please reply to this message with your PIN or password plus < DOG > Example: 1234dog."

4. User sends unified authentication code to system. User keys in 6789dog and sends message.

5. System cross-references unified code to transaction number, mobile # or e- mail.

6. Transaction is authenticated.

The public key can also act as a session ID - i.e., it tells the server exactly what you are trying to do. Its analogy in the suffixing world is that the suffix tells the server what you are trying to do. The PIN/ public key combination may serve as the transaction code.

Whilst an embodiment of the present invention has been described with reference to the drawings, variations will suggest themselves to those skilled in the art without departing from the scope of the invention as defined in the appended claims. For example, the use of SMS via GSM is preferred but not essential and the authentication process of the present invention can be used in other electronic messaging systems using standards other than SMS and networks other than GSM. In particular, the technique can be used with email messaging.

The PIN/ public key combination is preferred but not essential as the public key can be used to prevent spoofing without the use of the private key or PIN. However, the process of unifying the public and private keys provides another level of security as it not only authenticates the "conducting medium" (e.g. mobile phone number, e-mail account ...), but also authenticates the identity of the user. This takes the authentication a step further as opposed to current systems which only provide a public key to be entered by the user to confirm a transaction. The invention will also enable multiple users access (pre-registered) through a single conduit.

The present invention can be used in any transaction using electronic messaging and is not limited to financial transactions.

Claims

1. A method of authenticating a transaction conducted by electronic messaging between a client device having an associated client device identifying code and a host that provides messaging services for a plurality of clients, the method comprising: a) sending a first message from the client device to the host; b) generating a public key in response to the first message; c) associating the public key with the client device identifying code; d) sending a message from the host to the device identifying code, the message containing the public key; e) sending a second message from the client device to the host, the message including the public key; f) comparing the public key and client device identifying code of the second message with the public key and client device identifying code of step c).

2. A method as claimed in claim 1, wherein the host server is in communication with a transaction server of a third party holding a plurality of client accounts and the client device identification code is associated with a particular client account.

3. A method as claimed in claim 2, wherein the client device identification code is associated with a particular client account on the transaction server.

4. A method as claimed in claim 2 or 3, wherein the client device identification code is associated with a particular client account on the host server.

5. A method as claimed in any one preceding claim, wherein the user of the client device has a personal identification code (PIN) that is associated with the client device identification code on the host server.

6. A method as claimed in claim 5, wherein the PIN is associated with the client device identification code in an initial registration procedure.

7. A method as claimed in 5 or 6, wherein the PIN is provided to the host server in the message from the client device in step e) in order to authenticate the party using the client device.

8. A method as claimed in any one preceding claim wherein the step b) includes generating a transaction record including details associated with the client device identification code and associating those details with the public key, whereby the public key or public key and private combination acts as a transaction code which can be used to both authenticate the transaction and identify the transaction to be performed.

9. A System for authenticating a transaction conducted by electronic messaging between a client device having an associated client device identifying code and a host that provides messaging services for a plurality of clients, the host server being adapted to: a) receive a first message from the client device; b) generate a public key in response to the first message; c) associate the public key with the client device identifying code; d) send a message from the host to the device identifying code, the message containing the public key; e) receive a second message from the client device, the message including a key in the body of the message; f) comparing the key and client device identifying code of the second message with the public key and client device identifying code of c) above.

10. A system as claimed in claim 9, wherein the host server is in communication with a transaction server of a third party holding a plurality of client accounts and the client device identification code is associated with a particular client account.

11. A system as claimed in claim 10, wherein the client device identification code is associated with a particular client account on the transaction server.

12. A system as claimed in claim 10 or 11, wherein the client device identification code is associated with a particular client account on the host server.

13. A system as claimed in any one of claims 9 to 12, wherein the user of the client device has a personal identification code (PIN) that is associated with the client device identification code on the host server.

14. A system as claimed in claim 13, wherein host server is adapted to associate the PIN with the client device identification code in an initial registration procedure.

15. A system as claimed in any one of claims 9 to 14 wherein the host server is adapted to generate a transaction record on receipt of the first message, the transaction record including details associated with the client device identification code, the host server associates those details with the public key, whereby the public key or the combination of the public key with the PIN, acts as a transaction code which can be used to both authenticate the transaction and identify the transaction to be performed.