WO2014174342A1

WO2014174342A1 - Mobile payment with strong authentication and non repudiation

Info

Publication number: WO2014174342A1
Application number: PCT/IB2013/053265
Authority: WO
Inventors: Mohamed ELHARRAS
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-04-25
Filing date: 2013-04-25
Publication date: 2014-10-30
Anticipated expiration: 2015-10-25

Abstract

This is the design of a mobile payment process based on authenticating the payer by two factor- authentication, something the payer owns (his mobile phone) and something he knows (pin). The process does not complete until a confirmation number representing payment ID is received on the payer's phone from the payment authority (payer's bank, etc.). The process starts by entering the payer's credentials at the sell point mobile device, that is : payer's PIN code then the payer's bank sends SMS to the payer pre-registered mobile number with transaction ID that he must enter into the sell point reader to get the required goods/service. Thus, we verified the payer physical presence at the sell point, prevented the sell point from making fake sell deals and monitored/approved in real-time all transactions. In the meantime, no individual private data was passed to the seller and both the seller and the payer cannot deny their actions in the selling transaction (repudiation). In real life implementation, the process is based on deploying these exchanged messages through real time mobile communications deploying USSD, SMS and physical data entry among the three parties: the payer, the seller and the payment authority.

Description

Mobile Payment with Strong Authentication of Payer

1. Introduction

This is the technical description of a mechanism to authenticate the user of a mobile computer device (Computer, cellular phone ...etc.) to ensure that the user is what s/he claims to be. This design has a wide range of implementations in mobile payment industry such as mobile banking and paying for goods and services using mobile phone or mobile computer.

The design resolves the problem of identifying a mobile phone/computer user rather than identifying the device itself (which is the case in most current mobile authentication mechanisms), to make it clearer, a mobile phone user can make phone calls once the phone is in his possession unless the mobile phone was protected by a pin code in such case we say that the mobile device is protected by two-factors authentication : something you know (pin) and something you have (the mobile itself). The problem becomes more complicated once this mechanism is required to do payment as a third party (payment recipient) is introduced into the equation. In such case we need to ensure that the mobile user (payer) is what he/she claims to be and also the payment recipient is authenticated to be the correct person/entity to receive the payment and both the payer and the recipient must be verified in real time in each payment process. We need also to ensure non-repudiation from payment process parties as once the payment is done, there should be no room to deny receiving the money by the recipient or authorizing the payment by the payer.

This product comes to ensure that payment was done from the payer himself to the recipient himself with the value indicated and with no room for any of them to deny their actions during this process, thus we ensure the secrecy of the process and the accountability of its participants by authenticating both parties involved in the payment process. In second part of this document I will present a real-life example of implementing this design that is paying for fuel in petrol station using mobile phones only. 2. The Design (abstract)

a. The mobile device user (applicant) presents his credential (PIN code) at the payment station (authenticator) b. The authenticator sends an encrypted message with the credentials it received to a verification authority (supplicant) which has access to all mobile users' credentials seeking verifications of this credential c. The supplicant sends a message to the applicant's pre-registered mobile device with a one-time password token to be presented to the authenticator d. Once the token is presented manually to the authenticator, payment is considered done as the authenticator will send another message to the supplicant with payment confirmation e. Optionally, the authenticator sends a message to the supplicant indicating the completion of goods delivery and the supplicant might then send a message to the applicant with his/her new balance after this transaction.

2.1 Detailed Design

2.1.1 The user registers with his payment authority (e.g. bank) and receives a PIN. This pin has segments indicating the bank code and the customer code. One of the registration fields is the customer's mobile phone number

2.1.2 At the sell point, the customer manually enters his pin code. At this point, the sell point opens a USSD session with the payment authority sending this customer's PIN and the value of the required good or service.

2.1.3 The payment authority performs the necessary checks on the entered PIN: its correctness, its balance,..etc. and any built-in check routine (including running the necessary Fraud Management System checks at this point) before proceeding. In case and error is encountered, the payment authority sends a push USSD message to the sell point refusing the payment process. The error message will be displayed to the customer at the sell point screen

2.1.4 If checks are success, the payment authority sends a SMS message to the customer mobile phone with the payment ID number. This message content has a configurable life time after which it becomes invalid to use.

2.1.5 If the customer enters this payment ID number at the sell point, the sell point sends USSD message to the payment authority with the payment ID

2.1.6 The payment authority updates customer balance and sends SMS to the customer with confirmation of transaction

2.1.7 Please see figure 2 of the attached document for the message flow during payment

2.2 The scientific basis of this design

This design is based on deploying the following security / anti-fraud techniques to produce the above process:

2.2.1 Pre-Shared Key: the customer has a pre shared pin with the bank that is his mobile number. Knowing this key by any third party does not unfold a secret as the intruder still has to put hand on the customer's mobile phone device itself however, keeping the customer mobile phone number is for privacy purposes only

2.2.2 One time password: the transaction ID that is sent from the customer's bank to the customer's mobile phone is simply a one-time password with expiration lifetime span after which it becomes invalid and the customer has to initiate a new transaction

2.2.3 Out-of Band: the exchanged keys and messages among the customer, the sell point and the bank goes through two different mediums: electronic (through mobile network) and physical (through keying-in data at the sell point key pad). Thus an intruder will have to access the exchanged messages and be present when the customer keys -in any data. This will make it difficult for any intruder and achieve high level of secrecy of the exchanged keys/messages

2.2.4 Deploying strong authentication technique: that is something the customer has (mobile phone device) and something customer knows (customer PIN). The two-factor authentication technique is known for its secrecy

2.2.5 This is a practical implementation of what is known in mathematics as "A2-Code" authentication theory with addition of the above secrecy techniques in 2.2.1 to 2.2.4 that will make it extremely infeasible to for an intruder to hack the exchanged messages between the customer, the seller and the payment authority

3. Possible variations of the above design implementation a. The user password (pin) might be switched to another form of passwords such as zero knowledge passwords where the user is asked for parts of a known secret (e.g. enter the first, third and last character of a known password). Switching to more complicated forms must be proportionate to the value of good/service the user asks access to. b. Generating the one time password might take many forms. From random number to advanced random passwords could be used, again based on the value of the goods / service the user seeks access for. As such the system becomes a flexible payment tool covering payment for restaurant meals to payment for house down payments. c. The above process is also valid when using a mobile computer (not phone) and messages can be exchanged using the Internet instead of the cellular mobile networks. The following part will introduce a real life case study: paying for fuel at petrol station.

4. Description of Drawings

The applied authentication model

4.1 "Authentication Model" is the four tier authentication model of this design

"The Payment Process" represents the message flow diagram exchanged during payment process as per the proposed invention design (also enclosed in the file "Flow Diagram BW.PDF"

Industrial Applicability

Case Study: Paying for fuel at petrol station

Due to recent fuel distribution bottlenecks in Egypt, the Egyptian government is seeking solutions to control fuel distribution, prevent fuel smuggling yet keeping control over the dispensed amounts of subsidized fuel.

This is the design of a payment process to be used in petrol stations to pay for fuel through mobile phone based on the above model. For this case study purposes, I will assume the name "Tawasul" for the above mentioned process and it will be carried by a dedicated system (software+ hardware) linked to the mobile operators' networks. In this case:

6.1 The user registers with the authentication authority (the government) who keeps any authentication credentials (name, mobile phone number, national ID number, car plate number ...etc). For the registration purpose, an internet application is designed and the customer has to enter data from both his car licenses and his national id card then a mobile phone is required. As a result of registration, the customer receives a SMS on his mobile with his 8 digits customer number

6.2 The user proceeds to the dispensing point in the petrol station (the sell point) presenting his credentials (in this case customer number). Note that this is strong two factors authentication (mobile phone device + customer number)

6.3 The reader at the petrol station is just a normal mobile phone, could be rugged device to sustain the hard operational environment 6.4 The reader at the fuel dispensing point opens USSD session (Unstructured Supplementary Service Data) sending this presented data plus the requested amount of fuel (e.g. 20 liters of fuel) to Tawasul platform which is a server hosting the software that does the authentication process and operates as centralized authenticator point for all mobile networks operators. Toii/osu/ then contacts the supplicant system (government, user bank ...etc) seeking verification of the presented credentials (in this case customer number)

6.5 Upon receiving confirmation of correctness, the Tawasul platform also receives the latest registered mobile number of this customer then Tawasul sends message through SMS to the customer phone with one time token (e.g. process ID in the form of 8-digits number). The SMS content has expiration time after which it becomes invalid

6.6 The customer physically presents this token at the dispensing point mobile reader which sends it through another USSD session to Tawasul and gets a confirmation mode. The customer then gets the 20 liters of fuel

6.7 Optionally Tawasul might send SMS to the customer with his new balance

Claims

1- Doing payment by this proposed invention will prevent repudiation by either payment parties: the payer or the payment receiver

2- Unless the payer hands his mobile phone and his PIN code to someone else, the above payment process will assure the physical existence of payer at payment point

3- Trying to intrude or hack to the above authentication process will only succeed if and only if the hacker has access to the payer and the sell point computing devices and the PIN code of the payer , thus minimizing the risk of doing fraudulent payment transactions

4- Unlike payment by credit cards equipped with chip (pin and chip) , this method does not

proceed with the payment unless a confirmation is sent to the payer's mobile , thus preventing the seller's fraud possibility ( fake sell)

5- This payment mechanism can replace paying by credit cards with higher level of authentication / secrecy and anti-fraud measures plus it costs less as it saves the cost of printing and maintaining the credit card itself

6- This proposed payment process will be easier to implement in new markets where there is no or little banking service penetration

7- the above design will keep all customer's information privacy as there is no data is passed to the seller that he might use later to pin-point the identity of a specific customer

8- no need to equip the mobile phone with any other technology (e.g. Near Field Communication) , thus producing the least expensive solution