WO2010140876A1

WO2010140876A1 - Method, system and secure server for multi-factor transaction authentication

Info

Publication number: WO2010140876A1
Application number: PCT/MY2010/000088
Authority: WO
Inventors: Ching Wee Ho
Original assignee: Bemobile Sdn. Bhd.
Priority date: 2009-06-01
Filing date: 2010-05-26
Publication date: 2010-12-09
Also published as: WO2010140876A8

Abstract

A method of providing multi-factor payment authentication system in which a customer transaction by a first communication channel is authenticated by a unique confirmation through a second communication channel of differing protocol to the first channel. In one embodiment, the second channel is an SMS or USSD channel and the unique confirmation is sent by the customer in response to an SMS message or USSD session received on his mobile device. The method can be adopted as a security enhancement to 3-D Secure^TM or similar authentication protocols.

Description

METHOD, SYSTEM AND SECURE SERVER FOR MULTI-FACTOR TRANSACTION AUTHENTICATION

TECHNICAL FIELD

The invention generally relates to the technical field of security in authentication of financial transactions such as an online purchase or order for goods or services. More particularly the invention relates to multi-factor authentication of a known payer authentication and receipt signing protocol.

BACKGROUND ART

Methods of providing authentication in financial transactions range from the single PIN number to methods in which a PIN number is used in combination with a code generated by a security dongle, or a lookup code on a card. These methods work adequately in a face-to-face situation.

Particular problems arise where the customer interacts with a merchant without face-to-face contact, for instance in an internet or mail order transaction. This situation is known in the art as card-not-present (CNP). In many cases, the merchant carries out a transaction with no surety that the customer is the person actually holding the card to which the transaction will be charged. Often the numeric Card Security Code (CSC) or Credit Card ID or Card Verification Value (CW) is required as proof that the customer has the card. In particular the CW2 code is used since this does not appear in the magnetic stripe on the card.

In order to enhance security, two-factor authentication has been introduced. Generally, two-factor authentication requires a combination of something the cardholder has and something the cardholder knows. One example is the need for a cardholder to enter a pin number into a POS terminal in addition to just presenting the card.

Other methods have been developed to attempt to provide more security for the merchant and card user where the user is remote from the merchant. One of these is an XML-based protocol implemented variously as 3-D Secure™, J/Secure™ or SecureCode™ and extending over the issuer domain (the bank authority which issued the card to a user), the acquirer domain (the merchant and the merchant's banking authority) and the inter-operability domain (the protocols, communication and hardware required to implement the XML protocol). Under this scheme the cardholder is authenticated with an Access Control Server (ACS) which may be used to verify that the cardholder can pass an authentication check with the ACS. In use, the cardholder browses the merchant site, adding items to a shopping cart before finalising the purchase. At this point the merchant server sends the applicable user information to a Directory Server for the cardholder's card which in turn seeks an Access Control Server. The ACS determines whether the card has authentication established with it, and if it has prompts the merchant web interface to require the customer's browser to send an authentication request to the ACS. The ACS authenticates the customer (using a password, smart chip, PIN₁ etc.) and prompts the customer browser to send an ACS signed payer authentication response to the issuing bank. The issuing bank receives this response, validates the signature (whether locally or remotely) and then proceeds with an authorised transaction to transfer the required funds. Methods using such multiple authentication measures provide additional security over methods using single mode authentication measures. The 3-D Secure™ and equivalent specifications include provision to carry out the purchase and authentication via voice or message if necessary, but do not propose the use of more than a single communication channel at any one time. Methods using a different communication channel (factor) than that being used to carry out the transaction to obtain a second form of authentication are much preferable to single channel methods. Multi-factor authentication allowing interaction with the customer by two forms of communication provides some surety to a transaction because the customer must respond to the transaction over the two differing communication channels, substantially reducing the likelihood of interference or interception of the whole communicated data by some external person. However, introducing a second channel communication method into the 3- D Secure™ or similar protocol method is not permissible since the protocol is essentially fixed.

The present invention thus aims to provide a solution to the above and/or other problems which offers advantages over the prior art, in context of the above- described three-domain authentication system. SUMMARY OF THE INVENTION

In one exemplification, the invention consists in a method of providing a multi-factor payment authentication system in which a customer transaction by a first communication channel is authenticated by a unique confirmation through a second communication channel of differing protocol to the first channel, the second channel being a cellular wireless channel and the unique confirmation being sent by the customer through the second channel from his mobile device. Thus, in this embodiment, an SMS message, USSD session, or similar assists in authentication.

In another aspect the invention provides a multi-factor payment authentication system in which a customer transaction being carried out with a transaction authority over a first communication channel and requiring authentication of the customer by a challenge and response from an authentication server to the customer via the transaction authority is authenticated by a request for authentication from the transaction authority to a security server and the issuance to the customer through a second communication channel of differing protocol to the first channel of a request for confirmation of transaction and a returned unique confirmation from the customer through the second channel to the security server, to generate an authentication response to the authentication server when correct, wherein the unique confirmation is generated by the customer at the second communication channel destination on receipt of the request for confirmation.

In one embodiment, the second communication channel is a cellular wireless channel (e.g. SMS or USSD) and the request is received by a mobile device of the customer. The unique confirmation is generated by a one-time password generator retained by the customer, the unique confirmation being entered by the customer as a return SMS or reply to a network-initiated (push-mode) USSD session.

In another embodiment, the first communication channel is an internet protocol channel and the second communication channel is an SMS or USSD channel and the SMS request/USSD session is received by a mobile device of the customer. The unique confirmation is generated by an application program provided on the mobile device of the customer and returned as an SMS message/USSD reply by customer action.

In a further embodiment, the request received on the mobile device of the customer includes a response option through the wireless channel indicating that the transaction is fraudulent. A response indicating a fraudulent transaction may be routed to the customer bank in addition to the transaction authority. Where no response to the request for confirmation is received within a predetermined period of time, the transaction may be halted.

In a further aspect, the invention provides a multi-factor transaction authentication system having: an interaction means to interact with a customer over a first communication channel of a first protocol during a transaction; an authentication server to respond to a request from the customer by requesting authentication of the customer over the first communication channel; characterised in a security server to act upon the request for authentication from the authentication server and to request verification of a transaction from the customer by a second communication channel of a different protocol; a generation means to generate a verification confirmation in the form of a unique confirmation generated at the customer location; and a customer response issuer issuing a response including the unique confirmation via the second communication channel to the security server; the security server returning an authentication confirmation to the authentication server on receipt of a correct verification.

In an embodiment, the first communication channel uses an internet protocol.

In another embodiment, the response issued via the second communication channel may include an indicator that the transaction is fraudulent.

The indication that the transaction is fraudulent may be returned, preferably in real- time, to the customer bank authority in addition to the transaction authority.

A failure to issue a verification over the second communication channel may result in failure of the transaction.

The second communication channel may use voice (for example, voice recognition, IVR and the like), SMS or USSD, in each case either through mobile or fixed line telephone network.

In another aspect, the invention relates to a method of providing multi-factor payment authentication system in which a customer transaction by a first communication channel is authenticated by a unique confirmation through a second communication channel of differing protocol to the first channel, the second channel being an SMS or USSD channel and the unique confirmation being generated at the SMS or USSD destination. This method can use 3-D Secure™ or similar authentication protocols over the first communication channel. In a further aspect, the invention provides a security server for use in the above method and system.

These and other features of as well as advantages which characterise the present invention will be apparent upon reading of the following detailed description and review of the associated drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a general diagram of a transaction environment.

FIG. 2 is a flow chart of the process of verifying a transaction taking place.

DETAILED DESCRIPTION AND BEST MODE The 3-D Secure™ protocol, or variants of it, to which this invention relates is not a payment protocol, but a payer authentication and receipt signing protocol whose objectives are to verify the account ownership of the payer during a transaction, and to provide the merchant with the equivalent of a signed receipt. The 3-D Secure™ protocol was initiated by Visa (registered trademark) and implemented for other card issuing authorities by a committee. There are four participating parties in the protocol: merchants, issuers, cardholders, and the card issuing authority itself.

Participating merchants are required to integrate a plug-in (Merchant Plug-In - MPI) component into their Web storefronts and need to use a Validation Server to prove the authenticity of the digital signature on the transactions. Participating issuers are required to install two servers - the Enrolment Server that is used to register cardholders to the service, and the Access Control Server (ACS) that is used to authenticate the cardholders during the transactions. In addition, the issuers are required to register at the card issuing authority, to pass the relevant information (participating number ranges and ACS URLs) to the card issuing authority and to receive a private key that will be used to sign receipts.

Participating cardholders need to register against their issuing bank and to choose an appropriate password that will be used to authenticate them before signing their receipts.

The card issuing authority operates a central Directory Server (DS) that serves as a repository for the participating card number ranges and their associated ACS URLs. The 3-D Secure™ protocol itself Is based on two sets of request/response messages sent from the merchant's MPI to the issuer's ACS - the Verify Enrolment Request/Response (VEReq/VERes) and the Payer Authentication Request/Response (PAReq/PARes). The first request is used to check whether a specific card is enrolled in the service, and the second request is used to ask the issuer to authenticate the payer identity.

There are several components in the 3-D Secure™ or similar environment that are distributed between the issuer, the merchant, and the card issuing authority:

At the card issuing authority 1. A wide area network is operated by the card issuing authority and is responsible for switching credit card transactions from acquirers to issuers and to handle settlement of those transactions. Some local or domestic transactions will be routed through local networks that are operated by national bodies, by third party processors or by the acquirers themselves. 2. The Directory Server (DS) is responsible for managing the list of participating card ranges and their appropriate ACS servers. This component acts as a central directory of all participating issuers, to allow the MPI to reach the proper ACS when needed.

At the Issuer 3. The Access Control Server (ACS) is responsible for two tasks: (1) the first task being to provide the merchant with information on whether or not a card is enrolled in the 3-D Secure™ service, and (2) the second being to present to the card holder the transaction receipt for the cardholder to approve, to authenticate his identity and to sign the receipt on his behalf. 4. The Enrolment Server is responsible for enrolling cardholders to the issuer's 3-D Secure™ service. This includes receiving cardholder enrolment requests (usually via the Web), receiving from the cardholder authenticating information, allowing the cardholder to select his password, and registering the cardholder in the account holder's file. 5. The Authorization Server receives authorization requests from the card issuing authority wide area network, checks whether the cardholder has enough funds and/or credit and that the transaction is not susceptible to fraud. It then responds with an approve/decline authorization reply.

6. The Account Holder's File holds the cardholder information needed to operate the 3-D Secure™ or similar service. This information will usually be accessed through the cardholder PAN. This information includes the status of the cardholder enrolment, the information needed to authenticate the cardholder during the enrolment process and information used to authenticate the holder during the transaction process.

7. The Receipt File (optional) holds all the receipts that were signed during the 3-D Secure™ or similar service payer authentication process. It may be used to facilitate more efficient Request for Copy processing.

8. The Transaction Log File (optional) holds the entire log of all 3-D Secure™ or similar service transactions, including those that did not pass authentication. This includes logs of the merchants' requests for authentication, the cardholder input during the process and the ACS response.

At the Merchant

9. The Storefront is responsible for all the merchant's interaction with the customer— from presenting the merchandise to them, to enabling them to search and browse the catalogue, to managing their shopping cart, to accepting checkout payment and shipping instructions from the customer and finally to presenting them with the receipt and getting their approval.

10. The Merchant Plug In (MPI) has three tasks: (1) The first task is to interact with the merchant's storefront (and possibly with the user account and transaction files) to receive the relevant transaction details at the proper time (usually at the receipt approval time) and to initiate the 3-D Secure™ or similar process; (2) The second task is to check whether the card is enrolled in the 3-D Secure™ or similar service, and to find which ACS is handling this card; and (3) The third task is to redirect the transaction details to the appropriate ACS, and to get the signed receipt in response for authentication of the card holder. 11. The Validation Server is responsible for checking whether the receipts the merchant gets from the ACS are signed properly. This component can run either as part of the MPI ("Thick client MPI") or as another server ("Thin client MPI"). 12. The Receipt File is responsible for storing the signed receipts and later retrieving them in order to satisfy "Request for Copy" requirements at a time of dispute.

13. The Point of Sale (POS) is responsible to connect the merchant with his 5 acquirer, to perform credit card transactions - from receiving authorizations, to capture the transactions for settlement and to making various adjustments, if needed.

At the Cardholder

14. To receive from the ACS the transaction receipt for the cardholder to approve, 10 to authenticate the cardholder identity, and to return an authenticating response to the ACS.

Referring now to FIG. 1, a typical transaction using a secure authentication process such as 3-D Secure™ or similar will first be described. In FIG.1, there is shown a user 100 who interacts with a financial system to carry out a transaction through a

15 computer 101, typically as a purchase at a web site, although it may be any other type of purchase or transaction. The user's computer 101 communicates, typically via the internet 102, with a merchant storefront 106 and web payment system 103. The web payment system 103 collects the required customer details as part of the Merchant Plug In (MPI) and verifies that the data relates to a known card by

20 querying card directory server (DS) 104. The card directory server will also query the access control server (ACS) 107 and return an indication of whether the card has enrolled in the security verification service. If the card is enrolled, the merchant payment server 103 initiates a verification process 105 between the user and the directory server 104 via the network. During this process the user receives content

25 which the user knows to be stored only as a verification of the card with the card issuer's access control server and the user provides some sort of authorisation, normally a static password, for the user to be authenticated and the transaction to be authorised to proceed. The access control server 107 then returns a signed transaction authorisation through the user's computer 101 and the merchant server

30 106 to the payment server 103. The transaction is now signed as authorised and can be processed through the transaction processor 103 which initiates the transfer ~ of the required funds between appropriate servers. Session process 105 proceeds through the same network and internet protocols as the remainder of the web ordering and transaction processes and is therefore subject to attack by phishing pages, man in the middle attack or keylogging of the authorisation information. The use of a static password in the existing 3-D Secure™ 5 process is also disadvantageous from a security viewpoint. The invention proposes to obviate this vulnerability by providing a server 109 which communicates over a different communication channel with the user to confirm the authorisation.

In addition to the features already described, FIG. 1 shows, in accordance with an embodiment of the invention, communication via an SMS message as an addition

10 or substitute in the process 105 for the phase in which the user receives the card authorisation request with identification from the access control server and is requested to confirm the transaction. The Mobile Security server 109 stores the card identification against the user's mobile number, and intercepts or diverts the access control server 107 authorisation request to the SMS server 110 and the

15 user's mobile device 108. The user responds via SMS with an item of secure information as a form of a challenge/response, returning possibly a password, and indicating that the transaction is accepted. This response is verified by the mobile security server 109 and the confirmation passed back to the access control server 107 which generates the signed transaction authorisation for the transaction server

20 103.

The secure information provided at the mobile device 108 may be a unique code or password generated either by an application within the device which is invoked by the incoming SMS message content or origin. Alternatively, a password may be entered by the user from a one-time code generator carried by the user. Such

25 generators typically take the form of a small gadget with display. The display shows a random code which changes with time or a lookup function which can provide an authentication code when seeded with an initial code. Such devices are now issued by banks for use in secure online banking login. So, there is the possibility that the user may use an existing such gadget, for example where the card to which a

30 transaction is to be charged is issued by the same bank. The mobile secure server 109 can calculate the code which should be shown and confirm that this is a match for the reported code before issuing a confirmation to access control server 107. In an alternative embodiment, authentication of the customer through the SMS channel makes use of mobile signature based on a certificate issued by a Certificate Authority, such as MyTRUST™ in Malaysia, and stored on the customer's SIM card. The customer authentication/signing will then be routed to the Certificate Authority for the digital signing over the encrypted SIM card. The advantages of such an arrangement include convenience (the customer does not need to remember any password), and a legally-binding and highly secure authentication.

Mobile secure server 109 may also accept an indication from the user of the mobile device of an indication that the request is an attempted fraud. The server will advise the access control server 107 that the transaction should be refused, but may also communicate with the issuer's bank at 111 so that the bank may query the user.

This provides a powerful and effectively real-time, automated process of reporting fraud at the time it is being attempted. Therefore, in accordance with one particularly advantageous embodiment, the authentication request sent to the customer over the second communication channel includes a response option that is returned over the same channel to report a fraudulent transaction attempt.

Preferably, the second communication channel is SMS, and the fraud reporting option is included in the SMS request. Such a facility is clearly much faster than for example the user having to contact his bank or card issuer's call centre, authenticate himself and verbally report the matter. The card account can be immediately suspended pending further investigation of the reported fraud.

FIG. 2 shows the path followed by the transaction confirmation flow in which at 201 the transaction between the customer and merchant is begun by verifying the card details with the card directory server at 202. If the card is shown in the directory server as not having been registered for authorisation verification the merchant has the option of continuing with an unverified transaction, or opting out of the transaction at 204.

Where the card user has registered the card, the access control server is checked at 205 to see if contact information allowing contact via a second communication channel is held. If the card user has not registered the card for a second channel verification the standard procedure is followed in which a verification check is initiated at 206 through only the same first channel as that over which the user is interacting with the merchant. If a verification is received at 207, it is passed to the access control server and checked at 209 for validity before either confirming the transaction at 210 or voiding it at 211.

If the card user has registered the card with the second channel server, shown in FIG. 1 as an SMS server, is prompted at 212 to contact the customer by means of an SMS message with details of the transaction (for example, the card issuing authority name and transaction amount) and a request for authorisation. If no response is received at 213 the transaction is voided at 211.

Where a response from the customer is received a check is made at 215 as to whether the response is to be interpreted as a fraud indication (for instance a response of "3" from a menu choice of 1: Proceed, 2: Declined, 3: Report Fraud). If so the fraud response is reported automatically at 214 to the merchant and also to the issuing bank for the card, so that the bank has the choice of stopping all transactions from the card until the customer is contacted. Where there is no indication of fraud, the response is checked at 217 as to whether it is the correct code for authorising the transaction. This will depend on what type of confirmation the customer is using - whether the response is a code from a onetime password creator or security dongle, whether an application in the mobile device has generated a one-time password on receipt of the prompt from the device number of the Mobile Secure server, or whether the response is some other form of secure answer such as a mobile signature. If the response is incorrect, the transaction is again voided at 216.

If the response from the customer is correct a verification response for the access control server is generated at 218 and supplied to the access control server at 209. Once determined as valid, the transaction is confirmed at 210.

The security server 109 may operate on the basis of rules relating to individual cards, or according to the Merchant Category Code (MCC) assigned by the card company. For instance, the use of a card may invoke processing to determine if the transaction amount is less than a predetermined amount such as $100, or the transaction is with a merchant for which second channel processing is set as not required. If so, the authentication response is returned directly rather than accessing the customer via SMS message or other out-of-band channel for secondary verification.

As an alternative to an SMS channel, the same system of authentication can make use of a network-initiated (push-mode) USSD session on the user's mobile device. The user must respond via his mobile device by replying within the USSD session before it times out.

The USSD message will include details of the transaction to be confirmed and reply options such as Send 1 to Confirm, 2 to Decline or 3 to Report fraud. An advantage of USSD is that it can be used when the user is overseas and roaming with his mobile device, without incurring roaming SMS charges.

It is to be understood that even though numerous characteristics and advantages of the various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and functioning of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail so long as the functioning of the invention is not adversely affected. For example the particular elements of the transaction system shown may vary dependent on the particular application for which it is used without departure from the scope of the present invention.

As used herein, the term "mobile device" refers to a mobile telephone, smart phone, PDA or other device capable of communication with a cellular telephone network. In addition, although the preferred embodiments described herein are directed to a transaction system using SMS messages or USSD sessions to authorise transactions, it will be appreciated by those skilled in the art that the teachings of the present invention can be applied to other systems such as voice controlled systems, without departing from the scope of the present invention. Thus, the second channel secure server may, for example, be set up to communicate using voice messages via fixed or mobile line. In this case, the user may be prompted to respond by dial tones (Interactive Voice Response - IVR) or by voice with voice recognition at the server of the code read by the user. However, the use of mobile communication is preferred over fixed line communication. This is because mobile devices are personal and less often shared, as well as being carried on the person and therefore more likely to be readily to hand when the authentication response is requested. INDUSTRIAL APPLICATION

The method, system and server of the invention are used in the secure confirmation over communication networks of financial transactions to allow the exchange of funds between parties to a transaction. The present invention is therefore industrially applicable.

Claims

1. A method of providing a multi-factor payment authentication system in which a customer transaction being carried out with a transaction authority over a first communication channel and requiring authentication of the customer by a challenge and response from an authentication server to the customer via the transaction authority is authenticated by a request for authentication from the transaction authority to a security server and the issuance to the customer through a second communication channel of differing protocol to the first channel of a request for confirmation of transaction and a returned unique confirmation from the customer through the second channel to the security server, to generate an authentication response to the authentication server when correct, wherein the unique confirmation is generated by the customer at the second communication channel destination on receipt of the request for confirmation.

2. A method as claimed in claim 1, wherein the second communication channel is a cellular wireless channel and said request is a message received by a mobile device of the customer.

3. A method as claimed in claim 2, wherein the. unique confirmation is generated by a one-time password generator retained by the customer, the unique confirmation being entered in said mobile device as a return message by the customer.

4. A method as claimed in claim 2, wherein the unique confirmation is generated by an application program provided on said mobile device of the customer and returned as a message by customer action.

5. A method as claimed in claim 2 or claim 4, wherein the unique confirmation makes use of a digital certificate stored on a SIM card of said mobile device.

6. A method as claimed in any one of claims 2 to 5, wherein the said message includes a response option for the customer to report through the cellular wireless channel that the transaction is fraudulent.

7. A method as claimed in claim 6, wherein a response indicating a fraudulent transaction is routed automatically to the issuing bank in addition to the transaction authority.

8. A method as claimed in any one of claims 2 to 7, wherein said cellular wireless channel uses SMS.

9. A method as claimed in any one of claims 2 to 7, wherein said cellular wireless channel uses USSD.

10. A method as claimed in any one of the preceding claims, wherein if no response is received, or received within a predetermined time, to the request for confirmation, the transaction is halted.

11. A method as claimed in any one of the preceding claims, wherein the process involving the second communication channel is selectively invoked based on one or more predetermined criteria such as the transaction amount or the merchant category.

12. A method as claimed in any one of the preceding claims, wherein the first channel is an internet protocol channel.

13. A multi-factor transaction authentication system in which a customer interacts over a first communication channel of a first protocol during a transaction, the system having: an authentication server to respond to a request from the customer by requesting authentication of the customer over the first communication channel; and a security server adapted to act upon the request for authentication from the authentication server; to issue a request for verification of a transaction from the customer through a second communication channel of a different protocol; and to receive, via the second communication channel, a verification confirmation in the form of a unique confirmation generated at the customer location; wherein the security server is adapted to return an authentication confirmation to the authentication server on receipt of a correct verification.

14. A transaction authorisation system as claimed in claim 13, wherein the first communication channel uses an internet protocol.

15. A transaction authorisation system as claimed in claim 13 or 14, wherein the second communication channel is an SMS or USSD channel and said verification request is an SMS message or USSD session received by a mobile device of the customer.

16. A transaction authorisation system as claimed in any one of claims 13 to 15, wherein said request includes a response option over the second communication channel for the customer to report that the transaction is fraudulent.

17. A transaction authorisation system as claimed in claim 16, wherein a response indicating that the transaction is fraudulent may be returned to the issuing bank in addition to the transaction authority.

18. A transaction authorisation system as claimed in any one of claims 13 to 17, wherein if no response is received, or received within a predetermined time, to the request for confirmation, the transaction is halted.

19. A transaction authorisation system as claimed in any one of claims 13 to 18, wherein the security server selectively invokes the process involving the second communication channel based on one or more predetermined criteria such as the transaction amount or the merchant category.

20. A transaction security server adapted for use in the method or system of any one of the preceding claims, wherein in use the security server acts upon the request for authentication from said authentication server, issues a request for verification of a transaction from the customer for transmission over said second communication channel of a different protocol, receives, over the second communication channel, a verification confirmation in the form of a unique confirmation generated at the customer location, and returns an authentication confirmation to the authentication server on receipt of a correct verification.

21. A transaction security server according to claim 20, wherein said second communication channel is an SMS or USSD channel and said verification request is an SMS message or USSD session received by a mobile device of the customer.

22. A transaction security server according to claim 20 or claim 21, wherein in use the security server generates a verification request that includes a response option over the second communication channel for the customer to report that the transaction is fraudulent.