A new design of Mobile Payment system based on NFC Technology

A new design of Mobile Payment system based on

NFC Technology

Ahmed H. Ali

_{, Reham Abdellatif Abouhogail}

_,

Ibrahim F. Tarrad

_{and Mohamed I. Youssef}

1,2_{Electrical Quantities Metrology Dept., National Institute for Standards, Egypt}

1_{Ahmed.hussien@hotmail.com ,} 2_{rehlatif@yahoo.com} 3,4_{Electrical Engineering Department Al-Azhar University, Egypt}

4_{tarradif@gmail.com}

Abstract-- Mobile Payment researches has increased rapidly in recent years. A most recent researchers are focusing on contactless mobile payment systems that uses mobile phones wireless technologies to achieve payment system success factors like availability, simplicity, security, and privacy of payment transaction. Moreover, Mobile technologies has a number of security risks. This paper proposes a new secured design of mobile payment system using a Near Field Communication (NFC) technology. The proposed system uses the features of NFC system to achieve an efficient and complete payment cycle. Furthermore, a solution to the relay attack is proposed. Also the proposed design satisfies the three most important security measures, Confidentiality, integrity and availability.

Index Term--

Mobile

1.

As mobile devices have become one of the most trusted personal devices, also mobile payment is defined as interactions between parties in an electronic Payment (e-payment) system with specific data and certain payment capabilities, the concept of mobile payment (m-payments) includes any payment in which a mobile device is used in at least one step of payment process [1]. The m-payment services can be done through a none-bank party (as financial or credit institutions) that independent of pre-existing bank accounts [2].

Figure.1 shows m-payment basic process steps, m-payment system main steps are the registration and forwarding the authorized and validated payment transactions [3]. Payment system life-cycle starts with payment request creation then payment authorization, and ended by payment request completion [4].

Fig. 1. m-Payment Conceptual Schema

Moreover, the proposed m-payments contains four entities: consumer who subscribe to a service, merchants who provide product or service to consumers, payment service provider, which controls the payment process in additional to the financial organization (FO) who manage users financial accounts [5].

Fig. 2. Overview of the Proposed System

2.

The mobile payment systems are currently undergoing some exciting changes that can enrich the whole payment industry. A new technology like NFC can be used for enabling users to make payments with their mobile phone.

One of these systems was proposed by mFerio [6]. This system is a NFC Peer-To-Peer (P2P) mobile payment system. In this system a user will make a payment using two mobile devices, which are not connected to a payment backend server, this process based on the digital cash concept. The authors claim that this system is more secure and useable than the cash based payment system.

Another NFC Payment system was provided by Kadambi, Li, and Karp [7]. This system is based on the NFC-enabled mobile payment system that uses Europay, MasterCard, and Visa(EMV) payment standards. The system uses the mobile secure element (SE) to issue a payment authorization token for a merchant and sends it over to the bank server to start the payment. The aim of the system is to protect sensitive and confidential information from being sent over the communication channel that can be attacked. Also, a public key is being used in the system.

Also, Husni et al. [8] presented another NFC payment system that based on the capabilities of NFC-enabled phones to operate in many modes. A user can scan the tags of any products in order to buy them by using the NFC reader. Next, the user will send the payment total amount to the merchant to complete the transaction. Both the user phone and the merchant will generate similar key using secret information received from a third trusted party.

Also, one of the recent proposed system for payment using NFC is developed by Mohamad Badra [9], this proposed system uses Cryptography mechanism that used to protect sensitive payment information and users’ bank account. The physical credit card number is stored in mobile secure element (SE), in which the NFC-enabled mobile device emulates the card that stored into a Secure Element. Data stored into the SE

could be managed by third parties and multiple contactless applications can be stored and executed on the secure element [10].

3. BASIC SECURITY MECHANISM OF THE PROPOSED

SYSTEM

NFC payment system privacy and Security concerns is raised because of the security threats of NFC technology. One of NFC security advantage is the close range of communication, this makes it resistant to most wireless media attacks, As NFC is built over Radio Frequency Identifications (RIFD), this makes it vulnerable to the same attacks launched on RIFD [9]. A more concerning threat related to mobile payments is the ghost and leech attack, where attacker will relay the transferred information between NFC devices. Specifically, the attacker will use two NFC devices one of them called “host”, to relay information from POS to the second device which called “leech” using a communication wireless media. Then, the leech will relay that information to the POS device [6].

As declared in Figure 3, the basic security mechanism of the proposed mobile payment systems, during any payment transaction. The system sends the transaction message and customer's identity along with the merchant’s digital signature over a communication network encrypted. In order to protect transaction messages from illegal party eavesdropping, both signature and encryption layers are used. In this basic security architecture, digital signature layer ensures that the message is sent from the intended client to the intended server. Hence, in the proposed system there are two steps: the first step is the concatenation of the International Mobile Equipment Identity (IMEI)which is used to uniquely identify a mobile device with the financial account number (UFAN) to form the Client Id ( 𝐶𝑖𝑑 ) as in Equation (1),This Client Id used for identifying

each system subscribers and it will be generated when customer registers to the system.

𝑪𝒊𝒅= 𝑴𝒊𝒎𝒆𝒊||𝑪𝒖𝒇𝒂𝒏 (1)

Where:

𝑪𝒊𝒅: customer client Id

𝑴𝒊𝒎𝒆𝒊: mobile IMEI

𝑪𝒖𝒇𝒂𝒏 : customer user financial account Number

The second step is to generate a secured payment message (𝑃𝑚) using a new proposed security protocol as in Equation (2)

that constructed by encrypting transaction message (𝑻𝒎)and

𝐶𝑖𝑑in addition to the signature using symmetric encryption,

𝑻𝒎: is the transaction message that hold the payment amount

𝑷𝒎= 𝑬(𝑻𝒎, 𝑪𝒊𝒅, 𝒔𝒊𝒈𝒏) (2)

Where

𝑷𝒎: is the payment message that will be sent for each

payment request from the POS to the payment gateway

𝑻𝒎: is the transaction message that contains transaction

information.

𝒔𝒊𝒈𝒏: the merchant signature.

Also, the proposed system was implemented using java technology, when Java applications are being compiled, class files are generated in machine language so, this process helps to prevent understanding the details of the used keys. Also, Java application programming interfaces (API) provides the ability to manipulate data between different applications and shares this data within an application, so that the access to the data is strictly prohibited.

Fig. 3. Security Mechanism of m-Payment

4. PROPOSED SYSTEM MODEL

The proposed payment system consists of four parties as shown in Figure 4 and as below:

 Customer: is the user who have NFC mobile device

that needs to buy a product or service.

 Merchant or point of sales (POS): is the entity

which offers the products and services to the customers and has a payment terminal, which allows the customer to make the payment.

 Mobile Payment Server (MPS): is the controller

entity which handles the payment process and all its activities. It acts as an interface between payment

terminals, it is the main entity of the proposed system.

 Financial Organization Server (FOS): is the

organization which manages the financial account of the Customers and merchants.

To describe the transaction process between the system parties, the customer's mobile device has NFC capabilities which allow the device to emulate contactless cards. With NFC, the customer taps the mobile device on the POS terminal (NFC Reader). This POS terminal acts as an interface between the card and mobile payment server (MPS). The card details and other transaction data are sent to MPS.

Fig. 4. Main parties of mobile payment model.

MPS authenticates the payment message data and transaction amount then sends payment details to financial organization server (FOS) after validating all payment request data to make money transfer between merchant and customer accounts, Then MPS response is sent back to the POS terminal, which provides the receipt to the customer. Figure 4 describes all parties of the proposed system.

5. Proposed System Software architecture

POS FOS

MPS

POS Tag NFC Mobile

Fig. 5. Proposed Mobile Payment System Entities and communication channels

1. MPS application: The MPS Application is a software

application that controls the payment process between the merchant and the customer with the FOS. The merchant can register payment requests with the MPS Application and can retrieve the payment’s status.

The MPS Application has a secure internet connection with merchant, the customer and FOS can connect. Also assumed that the MPS Application is secure and located in a location that is managed by the service provider.

2.Merchant Application: The Merchant application is an

interface which controls the payment requests and the NFC data exchange formats (NDEF) between the merchant and the MPS Application. All communication that happens between the merchant and the MPS Server Application has been secured, or otherwise it will be rejected.

The merchant has to register with the MPS Application and obtain an Application Programming Interface (API) Key before it is able to participate in the system as shown in Figure 6. With this API Key, the merchant generates session keys which are used to protect subsequent messages exchanged between the two entities.

3. POS TAG: it is an NFC tag used to store POS’s key as

each POS should renew its key daily and store it in this tag. POS TAG helps to prevent attacks as will be declared.

4. Customer Mobile Application: The customer mobile

application is a mobile application that provides a trustworthy interface between the MPS Application and the customer which developed by using mobile software development kit (SDK). With this application the customer can retrieve the payment request details and perform payments using his or her contactless credit card. The Mobile Application is not bound to the user.

4. Financial Organization application: It is software owned

and controlled by FOS which used to transfer money between

subscriber’s accounts, this software is out of this paper scope as it is already existed in the market and is used by electronic banking systems.

POS

MPS

POS Tag

NFC Mobile

Mobile Registration to MPS

POS Registration to MPS Write Pos Key to TAG

Fig. 6. The proposed system registration phase.

6. PROPOSED PAYMENT SYSTEM MAIN FLOW

The main follow of the proposed system is shown in Figure 7, the payment process in the new proposed system is divided into three steps as follows:

1- Registration Step

a. POS registrations

b. Customer registration to obtain user name and password

2- Preparation Step

a. POS renews its daily used key in order to ensure the security of that key.

b. Customer reads the POS Key in order to identify the POS that customer will buy one of its provided services or goods. c. Customer sends request to MPS to ask

for initializing the payment process 3- Payment Step

a. Start Payment Process

Fig. 7. Main Follow of the proposed architecture.

In the proposed system, we introduce a new entity to the architecture of the NFC-mobile payment system, which is NFC host card emulation storage to be used in payment process and to secure the sensitive data of subscribers. MPS application server is used to manage and to apply the encryption process and to store sensitive data securely at server side (MPS side). Figure 7 describes the main flow of the payment process for the proposed system.

The MPS will store information for each POS subscriber in its database; this information is represented as follows:

 UFAN: is the POS user financial account number that is given by FOS to each subscriber (account number is unique for each subscriber).

 𝑆𝑘𝑒𝑦:is the store key which generated randomly at the

initiation time by MPS for each POS as discussed in detail in Subsection (4.4).

The application server will store all information in its database. Moreover, the 𝑆𝑘𝑒𝑦will be updated every

configurable period at server, ( MPS) will update the key at their sides. The proposed cryptography approach is providing this feature in the encryption and decryption process. The update process will use the encrypted message to generate the new key. In the same way, the sign. Message is updated every day.

6.1 Merchant Registration to The Proposed System

Before a merchant is able to use the proposed system, it must first register with the Server Application and acquire an API Key, APK Key is a secret key issued to one entity. This key is only known to the key issuer and the key user/owner. The API Key is only known to the merchant(POS) and the MPS Application. Once registered, the merchant can start a payment process and cancel a payment request that belongs to his registered account.

A merchant can also retrieve the status of a payment request. In order to do this, the merchant only requires the payment request reference among with POS API. A merchant can have more than one API Key, but an API Key must belong to one merchant. This design decision provides flexibility and accountability as listed below.

1- A merchant can have more than one account in order to easily track sales based on categories, departments and more as merchant can assign API to each type of his category.

2- As merchant should have website in order to register to the proposed system, this allows web applications such as marketplaces uses hosting service providers to host their websites for smaller merchants that do not have their own website. The hosting service provider is registered as one merchant. Once registered the hosting service provider can create as many API Keys as required.

The MPS can also control applicable functions for each API Key by using MPS administrative parameters. The merchant registration and verification process is described as below:

a) The merchant initiates the registration process by accessing the registration web page hosted by the MPS Server Application.

b) The merchant is provided with limited access to the payment Server Application until the registration is completed and activated.

c) The MPS ensures that POS is managing and controlling the registered website in addition to that this website is using a secure hypertext transfer internet protocol (HTTPS)

d) As a final step of this process, the MPS Server Application generates a unique API Key and binds the merchant. This is an important step as the security of the system depends on this step. If this step fails, then the system trustworthiness is jeopardized.

6.2 Preparation / Initialization Step

process where an initial key was shared along with the account number provided by MPS to the user.

6.3 POS Key Generation

The start payment steps are done by POS side. The workflow of this step has two actions generating the hashed Store Key at the POS reader and Writing the hashed message into the NFC tag. This function generates the random key (𝑅_𝑛) and it should be unique for each POS store. Increasing the length of generated key raises the trustiness in its uniqueness. Then, the Store Key (𝑆_𝑘𝑒𝑦) will be created using the logical exclusive-OR operation (XOR) with the previously generated 𝑅𝑛 and the POS Reader ID (Reader ID

is the device serial number combined with manufacturer of the device) 𝑅𝐼𝐷. The final result of that is delivered to a hash

function to generate the hashed message. The hash function as in Equation (3) is used to strength the generated message and makes it difficult to guess and also to prevent the generation of the same message.

𝑆𝑘𝑒𝑦= 𝐻(𝑅𝑛𝑅𝐼𝐷) (3)

Where

𝑆𝑘𝑒𝑦:POS shared key

𝑅𝑛: The random number which

generated by MPS for POS

𝑅𝐼𝐷: Reader Id

In the second step, POS reader is an NFC-enabled device that is able to write the generated 𝑆𝑘𝑒𝑦in the NFC tag

using NFC read/Write mode and store the same message inside its internal memory. The NFC tag can then be put closed to the POS reader. This stage is executed once every day by the POS reader, which will keep the randomness factor of the hashed message new and make it difficult to attached with. Figure 8 shows a details sequence of this step.

Fig. 8. Generating Store Key Sequence Flow

6.4 Customer Reads POS Store Key

The second stage depends on user interaction. As we previously mentioned the NFC phone can operate in three modes, and one of these modes is the reader mode where a NFC phone can read the content of an NFC tag in case of touch or be closest and process it. Therefore, this phase requires the user to put his phone in touch with the POS NFC in order to read the Store Key, and store it securely on the phone memory. The importance of this phase is to verify the closeness of the phone to the reader.

6.5 Initializing Payment Request

During this step, customer requests to initiate a new transaction by sending initial request to MPS as follows:

1- Customer starts login to MPS by sending his previously registration user Id and password

2- MPS replies with a failure message in case of invalid customer credentials

3- In case of valid user credentials, MPS generates a new transaction Number(𝑇_𝑛) and transaction expiration time (𝑇𝑒𝑡) which will be used during the payment process in

next steps. Transaction Number is unique and is generated as a concatenation of customer mobile IMEI and creation date (𝑇𝑐𝑡) in format (yyyyMMdd) and auto

incremental number (𝑇𝑎𝑢𝑡𝑜) as per equation (4) .

𝑻𝒏= 𝑯(𝑴𝒊𝒎𝒆𝒊 || 𝑻𝒄𝒕|| 𝑻𝒂𝒖𝒕𝒐) (4)

The sequence diagram shown in Figure 9 declares the start new transaction process for customer.

sd StoreKey of POS

POS MPS NFC Tag

[not Valid POS API]:StoreKeyRequestFailure() RequestStoreKey(API Key)

writeStoreKeyToTag(StoreKey) sendGeneratedStoreKeyToPOS(): StoreKey

Fig. 9. New Transaction Initiation process

6.6 Payment Steps

After the completion of the above two steps (registration and initialization steps), a customer needs to touch the phone with the POS reader to start payment process. This step is divided into three stages, which are as follows:

1- Authenticating process of customer phone and POS reader and the verification of the closeness of the phone with POS using store Key as mentioned. 2- Encrypting payment message and a hashed message

will be provided.

3- Authenticating the customer mobile phone and POS to MPS.

In this phase, the required application is selected by its predefined identification. This is called application identity (AID). After selecting the correct AID, a second APDU will be sent by the POS reader to the phone containing the𝑆_𝑘𝑒𝑦stored in the reader from the first phase. A phone will match both messages received from the POS reader and the scanned message from the NFC tag in step two. At this point we have three scenarios, which are based on the result of a message matching process.

 If the t wo messages matched, the phone will be sure that the POS reader has generated both messages. Moreover, matching the messages will ensure that the phone is in close range to the POS reader because the phone needs to get a copy of the message from the NFC tag (located next to the POS reader).

 If the two messages are not matched, in this case a phone will respond with a fail of execution response to the POS reader. As a result, the phone will reject any further commands and deactivate the service Host Card Emulation service (HCE). This scenario may occur if the stored value does not match with the received one; that might be another Store Key or an attacker tampered with the Store Key stored in the NFC-tag.

 A phone will reject further commands and deactivate the service, if the message does not exist at the phone side. Which means that the user did not scan the NFC tag, or the phone is not in proximity range of the POS reader. In the first case the cashier will ask the user to scan the tag first in order for the transaction to go through. Otherwise, it is the second case, where there is a suspicion of a relay attack being launched on the victim’s device. Either way, the phone has a mechanism as explained to prevent the transaction from being completed.

In summary, this stage is very important to resist the relay attack. The reader was able to authenticate itself to the phone by sending the generated Store Key. The phone also was able to prevent the attack by matching the messages and acts based on the result of the matching process.

If the message matching result is successful, a third APDU will be sent after receiving the successful matching response from the phone. The third APDU is to get processing command, where the POS reader will ask the phone to send the transaction message and it’s 𝐶𝑖𝑑in order to complete the

transaction. Transaction message, Tm is as shown in Equation (4).

The POS server after receiving the command will generate the payment message, 𝑃_𝑚 as in Equation (2). As it was mentioned in Section (3), 𝑃𝑚 is the encryption of the

transaction message (𝑻_𝒎) as in Equation (5) concatenated with 𝐶𝑖𝑑 concatenated with merchant’s signature. Finally, the

POS’s application will send the encrypted payment message to the MPS reader through the POS’s application.

𝑻𝒎= (𝑷𝒗||𝐒key || 𝑻𝒏), 𝑯(𝑷𝒗||𝐒key||𝑻𝒏||𝑻𝒕𝒔) (5)

Where:

𝑻𝒎∶ Transaction message

𝑷𝒗 : Payment amount

𝐒𝐤𝐞𝐲 : POS store Key

𝑻𝒏 : Transaction Number

𝑻𝒕𝒔: Transaction time stamp

sd Initiate New Request

Customer

POS MPS

[not Valid token]:RequestInitiateFailure()

startPaymentProcess()

validateToken(): boolean

RequestInitiateSuccess(): TransactionId login(ID,Password)

initateNewTransaction(Token)

[not Valid StoreKey]:transactionStratFailure()

SuccessLogin(): Token

ValidatePOSKey()

storeUserInfoAndToken()

startPaymentProcess(Token,TransactionId,PaymentInfo)

Lastly, the POS reader will send the payment information to the MPS server. In this phase, the MPS server first needs to authenticate the POS from the received signature. Then the MPS compares the received Transaction Number with the registered one belongs to this phone. The result of the comparison has two scenarios, which are explained as follows:

 If the two numbers are matched, the MPS server will review the customer's UFAN. Then, MPS checks UFAN with the one stored in its database to verify the integrity of the encrypted message as follows:

 If the accounts are matched, the MPS server will send the payment request information to FOS and then approves the transaction and keeps a record of the transaction in its database. Therefore, a conformation message is sent to the POS reader and then to the phone to complete the transaction.

 If the accounts are not matched, the MPS server will reject the transaction and send a transaction denied message to the POS reader then to the phone.

 Going back, if the message transaction Number from the phone is not matched with the one stored in the MPS server database or it was expired, the transaction will be rejected and a message will be sent to the POS reader and the phone to inform them of the transaction rejection.

Moreover, HCE solutions are software based. Which means that the cost of those solutions is lower than a secure element based ones (hardware based solutions) in resources and technologies.

7. PROPOSED SYSTEM ACHIEVED SECURITY

OBJECTIVES

The new design of the mobile payment system achieves the following security objectives:

 Confidentiality: during the operation of the system,

sensitive information, such as the transaction information is not exchanged between entities as a plain text. Such information was protected by applying encryption mechanism. This prevents an active attacker from getting such information.

 Privacy: The proposed system uses NFC Host Card

Emulation (HCE) in mobile devices. By using HCE, the proposed system uses the host processor instead of the secure element. HCE technology introduces an advantages in the mobile payment, as it enables to implement payments solutions in the mobile without getting an agreement with mobile operators (MO) or mobile manufacturers which improve proposed system privacy.

Also, the payment message is routed in a way that the information only flows to the targeted entities and

never comes into contact with others that do not require it due to entities used identification which is unique for each subscribed one the system. In this way, not only the confidential information kept secret from attackers, but also from the entities that are legitimately participating in the process but who have no need to access to such information. During the operation of the protocol, payment information such as credit card details of the customer are kept secret from the merchant.

 Transaction Integrity: proposed system proves the

transaction integrity by applying encryption function to the payment message.

 Trustworthiness: the customer was provided with a

trustworthy display, ensuring that the shown payment details are as entered. In other words, the customer assured that the correct payment will go to the selected merchant and not somewhere else biased by an attacker and this is applied also using the hashed information which attached with the payment request.

 Payment Authorization by customer: the customer

authorizes the payment requests and involves his credentials as happened at a POS terminal using his PIN code and predefined key.

 Entity Authentication: The mobile user is

authenticated by using signature function that depends on mobile IMEI. The merchant is authenticated by POS identification and daily generated store key. So the proposed system contains mutual authentication between all participants.

 Auditing: The new system provides audit trails by

recording every step during the process in MPS database to help the customer to retrieve all information about his payment process at any time whatever the completion of the process of the failure due to any reason.

 General Security objective: the proposed system

verifies the following security concerns before starting of any payment process.

1) By using only, the certified POS using the registration process of each POS which supports the required level of security.

2) By using IMEI for each mobile which is unique for each mobile device as a part of the process message to ensure the uniqueness and to prevent non-repudiation.

3) Using one-time used transaction number to avoid any duplication attempt, also each initiated transaction number request has its own expiration time.

8. SIMULATION AND RESULTS

The proposed system was implemented using java and android platform. MPS web application was developed using java enterprise platform and for data storage oracle database was used. A new mobile applications were developed using android software development kit (SDK) that was be installed in both customer mobile and POS NFC reader. A detailed description of experimental simulation steps is listed below:

Step 1. A customer with NFC enabled mobile phone registers

to MPS application by providing a user name, password, UFAN and mobile phone IMEI, MPS generate 𝐶𝑖𝑑 𝑡ℎ𝑒𝑛 stores

these data in its database as following and as summarized in Table 1:

1- Hashed password for customer. 2- Generates 𝐶_𝑖𝑑 as in Equation (1).

Table I

Experimental Customer Register parameters

Parameters Value Type

IMEI 352272062036479 Input

UFAN 5284 Input

𝑪𝒊𝒅 3522720620364795284 Output

Step 2: POS registers to MPS system by providing (secured

website, UFAN and POS name), then MPS generates POS

API and the registration record now is inactive till POS requests for activating the registered account, Table 2 displays experimental parameter for POS registration process.

Table II

Experimental POS Register parameters

Parameters Value Type

Website https://127.0.0.1:

7001/pos

Input

UFAN 5285 Input

𝑷𝑶𝑺𝒂𝒑𝒊 586 Generated

MPS applies the steps mentioned in section 4.3, then the registration record status will be changed to be active.

Step 3: POS login to MPS systems and requests for getting

𝑺𝒌𝒆𝒚 using parameter shown in Table 3 as below:

- 𝑺_𝒌𝒆𝒚 is generated as per equation (3).

- MPS save 𝑺𝒌𝒆𝒚 database along with key generated

date 𝑺_𝒕 and 𝑃𝑂𝑆_𝑎𝑝𝑖.

- MPS sends generated 𝑺𝒌𝒆𝒚 to POS.

- POS writes the generated 𝑺_𝒌𝒆𝒚 into POS TAG.

Table III

Experimental POS 𝑆𝑘𝑒𝑦 generation Parameters

Parameters Value Type

𝑷𝑶𝑺𝒂𝒑𝒊 586 Input

𝑺𝒌𝒆𝒚 0f826c1589b41fe4e85edeab59f8

5216

Output

𝑺𝒕 24/02/2017 02:15:00 am Output

Step 4: Customer asks for initializing new transactions

number 𝑻𝒏 , MPS generates a the transaction number as per

Equation (4) then stored into MPS database associated with expiration time 𝑇𝑒𝑡 and customer identifications 𝐶𝑖𝑑, Table 4

lists the Experimental parameters for transaction initialization process.

Table IV

Experimental Transaction Number Generation Parameters

Parameter Value Type

𝑪𝒊𝒅 3522720620364795284 Input

𝑻𝒏 164fa83d02baee69884669678afebebc Output

𝑻𝒆𝒕 24/02/2017 16:30 Output

Step 5: Customer scans POS TAG to get POS current 𝑆_𝑘𝑒𝑦,

Also Customer enters payment amount and ask for start payment process to generate transaction message 𝑻𝒎 as per

NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt

𝑷

Extract

𝐶

, 𝑻

, 𝑆𝑖𝑔𝑛

𝐶

𝑖𝑠 𝑉𝑎𝑙𝑖𝑑?

Send Rejected

MSG

𝑖𝑠 𝑉𝑎𝑙𝑖𝑑 𝑃𝑂𝑆 𝑺𝒊𝒈𝒏?

Parse

𝑻

𝑆

_𝑘𝑒𝑦

,

𝑻

, 𝑻

𝑻

𝐸𝑥𝑝𝑖𝑟𝑒𝑑 ?

𝑆

_𝑘𝑒𝑦

𝐸𝑥𝑝𝑖𝑟𝑒𝑑?

End

Send Completed MSG

Send Payment data to FOS

(POS UFAN, CUSTOMER

UFAN, Payment value)

𝐹𝑂𝑆 𝑃𝑎𝑦𝑚𝑒𝑛𝑡

𝑑𝑜𝑛𝑒

?

FOS Validates accounts and

balance

End

Send

Rejected

MSG

Table V

Experimental 𝑇𝑚Generation Parameters

Parameter Value

𝑷𝒗 20 ($)

𝑻𝒕𝒔 20170224151213 (date format

yyyyMMddHHmmss)

𝑻𝒎 20,

0f826c1589b41fe4e85edeab59f85216, 164fa83d02baee69884669678afebebc, 8596572aacc3588272ced5f342094dfb

Step 6: POS generates encrypted payment message 𝑷_𝒎as per

equation (2) and send it to MPS.

Step 7: MPS decrypt 𝑷_𝒎 and apply steps as shown in flow

chart shown in Figure 10 then the process ended by either success of failure of transaction payment.

9. COMPARISON BETWEEN THE PROPOSED SYSTEM AND OTHER NFC PAYMENT SYSTEMS

As Discussed in Section 2, The proposed NFC payment system mFerio [6] relies on two aspects, the physical security aspect and the user security aspect. First, the physical security aspect is defined as using an embedded secure element storage that is used to store data needed for a transaction which affects customer’s privacy, because the mobile operator can know all the transactions of the customer without contributing in the process. The authors did not specify any authentication mechanisms to be used. Second, the user security aspect relies on the user’s awareness of any attack being launched.

Also, the system does not provide a solution for the relay attack since using the secure element will make a system vulnerable to the relay attack. Moreover, this system is not reliable because of the complexity that is being added through the number of steps needed to complete a transaction. And regarding system Kadambi, Li, and Karp [7], The authors assume their system provides end-to-end secured transaction with the use of payment authorization to protect confidential sensitive data over public networks.

However, the authors did not provide a solution for the relay attack, and the use of the secure element will make the protocol vulnerable to this type of attack [12].

Also, for the system proposed by Husni et al. [8], according to the authors the use of a symmetric encryption mechanism will prevent a number of attacks. However as mentioned before, the application-level cryptography will not prevent the relay attack since it is only used to send data from the POS to the phone without altering it [11]. And regarding payment system which proposed by Mohamad Badra [9], the system also depends on SE that makes the system vulnerable to the relay attack.

In the proposed system, the system does not depend on secure element to avoid attacks vulnerability as it uses HCE instead which has its encryption mechanism, also this leads to enhance system privacy due to excluding mobile operator from payment process actors, also the system provides an authentication mechanism for both customer and merchant in additional to authorization methodology for transaction and identification mechanism.

Also the proposed system provides a security protocol for all payment system actors starting by buyer and ending by payment gateway (MPS), Another feature, introduced by this mechanism is insuring the location of a customer phone to a POS reader in order to make a payment with a simple and secured way that uses NFC reader mode. This process proved that the system is resistant to relay attacks. Moreover, we offer the use of an encryption mechanism to encrypt the financial information in order to protect the information from being sent over a public network in a plain text.

In the proposed system, the mobile phone makes only hash operation, which is considered a very simple one and less computation overhead than in [9] which makes encryption operation. So this is considered very useful in minimizing

power consumption. Table I summarizes the

comparison of the four mentioned systems.

Table VI

Comparison between different payment systems

System / Feature

Not Depends

on SE

Prevent Relay Attack

Ensure User Location

Uses Encryption

for transaction

mFerio [6] NO NO NO NO

Kadambi, Li [7]

NO NO NO NO

Husni [8] NO NO NO YES

Mohamad Badra [9]

NO NO NO YES

Proposed System

YES YES YES YES

10. CONCLUSION

In this work, we concluded that NFC mobile payment has a very good perspective (Easy to use, secure, More

NFC-enabled mobile payment. The system uses a phone application that emulates a contactless card to make payments. In the proposed system a phone will authenticate a POS reader using a new location detection mechanism that uses a hashed key (Store ID) generated by the MPS and sent to POS reader. This message is stored in an NFC tag as well as in the Database of the MPS to be used in the authentication process.

Another feature, introduced by this mechanism is insuring the proximity of a phone to a POS reader in order to make a payment. This process proved that the system is resistant to relay attacks. Moreover, we offer the use of an encryption mechanism to encrypt the financial information in order to protect the information from being sent over a public network in a plain text.

Also one of the achieved security objective of the proposed system is the protection against fraud (Transaction denial, Transaction forgery and Protection of the SIM holder privacy). Also Conforming to these objectives, the security target of the proposed system was focused on the following security achievement:

 Protection of the payment sensitive data.

 Mutual authentication between the different participants.

 Secure operation of the payment application.

 Immunity against known types of attacks like relay and replay attacks.

 Secure operation of the software platform.

 Hardware tamper resistance.

The security comparison of the proposed system with others systems show that the proposed system is better than others form privacy prospective as the system involves only the required participants (customer, MPS, POS) but other system involves mobile operator, also the proposed system provides a security mechanism for identifying all participants in additional to new transaction handling mechanism.

The proposed system was implemented using android development tool and jdeveloper tool for developing MPS and POS websites. In additional to oracle database which were used for storing system information at MPS side.

11. REFERENCES

[1] Rushabh Patela, Akhil Kunchea, Nihar Mishraa, Zakwan Bhaiyata, Rahul Joshib “Comparative Review Of Existing Mobile Payment Systems”, International Journal of Applied Engineering Research 2015

[2] Ahmed H. Ali, Reham Abdellatif Abouhogail, Ibrahim F. Tarrad and Mohamed I. Youssef, “Assessment and Comparison of Commonly used Wireless Technologies from Mobile Payment Systems Perspective”, International Journal of Software Engineering and Its Applications, 2014 [3] Sunil K. Timalsina, Rabin Bhusal, and Sangman Moh, “NFC and Its

Application to Mobile Payment: Overview and Comparison”, Information Science and Digital Content Technology (ICIDT), 2012

[4] S. Britto, R. Kumar1, and S. Albert Rabara2 “An Architectural Framework for the

Development of Secure Mobile Payment System”, Journal of Algorithms & Computational Technology Vol. 4 No. 4, 2009

[5] Au and Kauffman, the economics of mobile payments: Understanding stakeholder issues for an emerging financial technology application, Electronic Commerce Research and Applications, 2007.

[6] Balan, R., Ramasubbu, N., Prakobphol, K., Christin, N., & Hong, J.mFerio: the design and evaluation of a peer-to-peer mobile payment system. MobiSys 2009 (pp. 291-304). New York: ACM, 2009.

[7] Kadambi, K., Li, J., & Karp, A. (2009). Near-field communication-based secure mobile payment service. In Proceedings of the 11th international Conference on Electronic Commerce (pp. 142–151). ACM,2009

[8] E., H., Kuspriyanto, K., Basjaruddin, N., Purboyo, T., Purwantoro, S., & Ubaya, H. Efficient tag-to-tag near field communication (NFC) protocol for secure mobile payment. Instrumentation, Communications, Information Technology, and Biomedical Engineering (ICICI-BME), 2011 2nd International Conference (pp. 97-101). IEEE, 2011.

[9] Mohamad Badra “A lightweight security protocol for NFC-based mobile payments” The 7th International Conference on Ambient Systems, Networks and Technologies, 2016

[10] Tom Karygiannis, Les Owens “Wireless Network Security”, Special Publication, Computer Security Division Information Technology Laboratory,National Institute of Standards and Technology, November 2002.

[11] Fan Jia, Yong Liu, Li Zhang “Threat Modeling for offline NFC Payments”, Journal of Convergence Information Technology(JCIT) Volume8, Number4, Feb 2013.

[12] Roland, M. (2012). Applying recent secure element relay attack scenarios to the real world: Google Wallet Relay Attack. University of Applied Sciences Upper Austria, NFC Research Lab Hagenberg . University of Applied Sciences