A new design of Mobile Payment system based on …ijens.org/Vol_17_I_03/174703-5858-IJET-IJENS.pdfA new design of Mobile Payment system based on NFC Technology Ahmed H. Ali1, Reham

International Journal of Engineering amp Technology IJET-IJENS Vol17 No03 7

174703-5858-IJET-IJENS copy June 2017 IJENS I J E N S

A new design of Mobile Payment system based on

NFC Technology Ahmed H Ali1 Reham Abdellatif Abouhogail2

Ibrahim F Tarrad3 and Mohamed I Youssef4

12Electrical Quantities Metrology Dept National Institute for Standards Egypt

1Ahmedhussienhotmailcom 2rehlatifyahoocom

34Electrical Engineering Department Al-Azhar University Egypt

4tarradifgmailcom

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 Payment Privacy protection Secured

Payment System NFC Payment System

1 INTRODUCTION

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]

Figure1 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]

The proposed system simulates a payment transaction

process where an NFC mobile phone is used as a payment

terminal at a point of sale device (POS) Also the transaction

is made through NFC communication between the customer

NFC-phone and POS contactless reader which connected to a

computer The reader acts as a payment card terminal and an

application running on the Personal Computer (PC) acts as a

cash register system An overview of the proposed system is

shown in Figure 2



Fig 2 Overview of the Proposed System

2 BACKGROUND

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 usersrsquo 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 ldquohostrdquo to relay information from POS to the

second device which called ldquoleechrdquo 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

customers identity along with the merchantrsquos 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 (

119862119894119889 ) as in Equation (1)This Client Id used for identifying

each system subscribers and it will be generated when

customer registers to the system

119914119946119941 = 119924119946119950119942119946||119914119958119943119938119951 (1)

Where

119914119946119941 customer client Id

119924119946119950119942119946 mobile IMEI

119914119958119943119938119951 customer user financial account Number

The second step is to generate a secured payment message

(119875119898) using a new proposed security protocol as in Equation (2)

that constructed by encrypting transaction message (119931119950)and

119862119894119889in addition to the signature using symmetric encryption

119931119950 is the transaction message that hold the payment amount

and transaction information this transaction message was sent

by customer to POS and it will be described in details in the

following sections



119927119950 = 119916(119931119950 119914119946119941 119956119946119944119951) (2)

Where

119927119950 is the payment message that will be sent for each

payment request from the POS to the payment gateway

119931119950 is the transaction message that contains transaction

information

119956119946119944119951 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 customers 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

The proposed mobile payment system comprises four

main entities as previously mentioned each entity of them has

its own controller software in order to be involved in the

automated payment system the MPS Application the

Merchant installed software in additional to merchant website

Financial Organization Server application and finally

customer NFC enable mobile device that has installed java

mobile edition application based on NFC technology (JME) as

shown in Figure 5



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 paymentrsquos 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

2Merchant 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 POSrsquos 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

subscriberrsquos 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

b Get a notification of the status of the

process (success or failed)



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) 119878119896119890119910is the store key which generated randomly at the

initiation time by MPS for each POS as discussed in detail in

Subsection (44)

The application server will store all information in its

database Moreover the 119878119896119890119910will 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

61 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 userowner

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

62 Preparation Initialization Step

The proposed system contains four steps three steps

need to be followed to complete a transaction process in

additional to preparation step which should be done before

starting the payment process Also these steps will be started

after the completion of the preparation step which is the setup



process where an initial key was shared along with the

account number provided by MPS to the user

63 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

(119877119899) 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 (119878119896119890119910) will be created using

the logical exclusive-OR operation (XOR) with the

previously generated 119877119899 and the POS Reader ID (Reader ID

is the device serial number combined with manufacturer of

the device) 119877119868119863 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

119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key

119877119899 The random number which

generated by MPS for POS

119877119868119863 Reader Id

In the second step POS reader is an NFC-enabled

device that is able to write the generated 119878119896119890119910in the NFC tag

using NFC readWrite 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

64 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

65 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(119879119899) and transaction expiration time

(119879119890119905) 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 (119879119888119905) in format (yyyyMMdd) and auto

incremental number (119879119886119906119905119900) as per equation (4)

119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (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

generateRondomStoreKey()

validatePOS_APIKey()



Fig 9 New Transaction Initiation process

66 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

the119878119896119890119910stored 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 two 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 victimrsquos 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 itrsquos 119862119894119889in 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 119875119898 as in Equation (2) As it

was mentioned in Section (3) 119875119898 is the encryption of the

transaction message (119931119950) as in Equation (5) concatenated

with 119862119894119889 concatenated with merchantrsquos signature Finally the

POSrsquos application will send the encrypted payment message to

the MPS reader through the POSrsquos application

119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where

119931119950 ∶ Transaction message

119927119959 Payment amount

119826119844119838119858 POS store Key

119931119951 Transaction Number

119931119957119956 Transaction time stamp

sd Initiate New Request

Customer

POS MPS

[not Valid token]RequestInitiateFailure()

startPaymentProcess()

validateToken() boolean

RequestInitiateSuccess() TransactionId

login(IDPassword)

initateNewTransaction(Token)

[not Valid StoreKey]transactionStratFailure()

SuccessLogin() Token

ValidatePOSKey()

storeUserInfoAndToken()

startPaymentProcess(TokenTransactionIdPaymentInfo)

[incase of not valid (IdPassword)]loginFailure()checkUseCredential() boolean



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 customers 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

4) POS identification by asking all POS to request

for activation process that depends on the initial

registration process which is basically built on

top of the already registered data at MPS with no

chance of invalid data introduced into the new

mobile payment environment



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 119862119894119889 119905ℎ119890119899 stores

these data in its database as following and as summarized in

Table 1

1- Hashed password for customer

2- Generates 119862119894119889 as in Equation (1)

Table I

Experimental Customer Register parameters

Parameters Value Type

IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

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


Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated

MPS applies the steps mentioned in section 43 then

the registration record status will be changed to be active

Step 3 POS login to MPS systems and requests for getting

119930119948119942119962 using parameter shown in Table 3 as below

- 119930119948119942119962 is generated as per equation (3)

- MPS save 119930119948119942119962 database along with key generated

date 119930119957 and 119875119874119878119886119901119894

- MPS sends generated 119930119948119942119962 to POS

- POS writes the generated 119930119948119942119962 into POS TAG

Table III

Experimental POS 119878119896119890119910 generation Parameters


119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output

Step 4 Customer asks for initializing new transactions

number 119931119951 MPS generates a the transaction number as per

Equation (4) then stored into MPS database associated with

expiration time 119879119890119905 and customer identifications 119862119894119889 Table 4

lists the Experimental parameters for transaction initialization

process Table IV

Experimental Transaction Number Generation Parameters

Parameter Value Type

119914119946119941 3522720620364795284 Input

119931119951 164fa83d02baee69884669678afebebc Output

119931119942119957 24022017 1630 Output

Step 5 Customer scans POS TAG to get POS current 119878119896119890119910

Also Customer enters payment amount and ask for start

payment process to generate transaction message 119931119950 as per

equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG

Send Payment data to FOS

(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890

FOS Validates accounts and

balance

End

Send

Rejected

MSG

Fig 10 Payment Request Execution Flow Chart



Table V

Experimental 119879119898 Generation Parameters

Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216

164fa83d02baee69884669678afebebc 8596572aacc3588272ced5f342094dfb

Step 6 POS generates encrypted payment message 119927119950 as per

equation (2) and send it to MPS

Step 7 MPS decrypt 119927119950 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 customerrsquos 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 userrsquos 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

convenient for the cardholder quick and easy Compliant

with the existing needs for customer and payment systems)

Also we proposed a new payment system that is based on



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 ldquoComparative Review Of Existing Mobile Payment Systemsrdquo

International Journal of Applied Engineering Research 2015

[2] Ahmed H Ali Reham Abdellatif Abouhogail Ibrahim F Tarrad and

Mohamed I Youssef ldquoAssessment and Comparison of Commonly used

Wireless Technologies from Mobile Payment Systems Perspectiverdquo

International Journal of Software Engineering and Its Applications 2014

[3] Sunil K Timalsina Rabin Bhusal and Sangman Moh ldquoNFC and Its Application to Mobile Payment Overview and Comparisonrdquo Information

Science and Digital Content Technology (ICIDT) 2012

[4] S Britto R Kumar1 and S Albert Rabara2 ldquoAn Architectural Framework for the

Development of Secure Mobile Payment Systemrdquo Journal of Algorithms amp

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 amp Hong JmFerio

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 amp Karp A (2009) Near-field communication-based

secure mobile payment service In Proceedings of the 11th international

Conference on Electronic Commerce (pp 142ndash151) ACM2009 [8] E H Kuspriyanto K Basjaruddin N Purboyo T Purwantoro S amp

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 ldquoA lightweight security protocol for NFC-based mobile paymentsrdquo The 7th International Conference on Ambient Systems

Networks and Technologies 2016 [10] Tom Karygiannis Les Owens ldquoWireless Network Securityrdquo Special

Publication Computer Security Division Information Technology

LaboratoryNational Institute of Standards and Technology November 2002

[11] Fan Jia Yong Liu Li Zhang ldquoThreat Modeling for offline NFC Paymentsrdquo

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

Upper Austria2012



Fig 2 Overview of the Proposed System

2 BACKGROUND

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 usersrsquo 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 ldquohostrdquo to relay information from POS to the

second device which called ldquoleechrdquo 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

customers identity along with the merchantrsquos 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 (

119862119894119889 ) as in Equation (1)This Client Id used for identifying

each system subscribers and it will be generated when

customer registers to the system

119914119946119941 = 119924119946119950119942119946||119914119958119943119938119951 (1)

Where

119914119946119941 customer client Id

119924119946119950119942119946 mobile IMEI

119914119958119943119938119951 customer user financial account Number

The second step is to generate a secured payment message

(119875119898) using a new proposed security protocol as in Equation (2)

that constructed by encrypting transaction message (119931119950)and

119862119894119889in addition to the signature using symmetric encryption

119931119950 is the transaction message that hold the payment amount

and transaction information this transaction message was sent

by customer to POS and it will be described in details in the

following sections



119927119950 = 119916(119931119950 119914119946119941 119956119946119944119951) (2)

Where




information
























system




























shown in Figure 5



POS

FOS

MPS

POS Tag

NFC Mobile


channels
































bound to the user





banking systems

POS

MPS

POS Tag

NFC Mobile










a POS registrations


name and password

2- Preparation Step








3- Payment Step

















follows





Subsection (44)








day



















his category



























jeopardized



























119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key



119877119868119863 Reader Id


































119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (4)



sd StoreKey of POS

POS MPS NFC Tag










66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012



119927119950 = 119916(119931119950 119914119946119941 119956119946119944119951) (2)

Where




information
























system




























shown in Figure 5



POS

FOS

MPS

POS Tag

NFC Mobile


channels
































bound to the user





banking systems

POS

MPS

POS Tag

NFC Mobile










a POS registrations


name and password

2- Preparation Step








3- Payment Step

















follows





Subsection (44)








day



















his category



























jeopardized



























119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key



119877119868119863 Reader Id


































119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (4)



sd StoreKey of POS

POS MPS NFC Tag










66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012



POS

FOS

MPS

POS Tag

NFC Mobile


channels
































bound to the user





banking systems

POS

MPS

POS Tag

NFC Mobile










a POS registrations


name and password

2- Preparation Step








3- Payment Step

















follows





Subsection (44)








day



















his category



























jeopardized



























119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key



119877119868119863 Reader Id


































119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (4)



sd StoreKey of POS

POS MPS NFC Tag










66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012














follows





Subsection (44)








day



















his category



























jeopardized



























119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key



119877119868119863 Reader Id


































119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (4)



sd StoreKey of POS

POS MPS NFC Tag










66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012





















119878119896119890119910 = 119867(119877119899119877119868119863) (3)

Where

119878119896119890119910POS shared key



119877119868119863 Reader Id


































119931119951 = 119919(119924119946119950119942119946 || 119931119940119957|| 119931119938119958119957119952) (4)



sd StoreKey of POS

POS MPS NFC Tag










66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012




66 Payment Steps





follows





will be provided


to MPS













































(4)








119931119950 = (119927119959||119826key || 119931119951) 119919(119927119959||119826key||119931119951||119931119957119956) (5)

Where



119826119844119838119858 POS store Key




Customer

POS MPS





login(IDPassword)




ValidatePOSKey()





































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012


































and technologies


OBJECTIVES

















privacy












merchant



the payment message























reason














time





















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012















Table 1



Table I



IMEI 352272062036479 Input

UFAN 5284 Input

119914119946119941

3522720620364795284 Output






Table II



Website https127001

7001pos

Input

UFAN 5285 Input

119927119926119930119938119953119946

586 Generated







date 119930119957 and 119875119874119878119886119901119894



Table III



119927119926119930119938119953119946 586 Input

119930119948119942119962 0f826c1589b41fe4e85edeab59f8

5216

Output

119930119957 24022017 021500 am Output






process Table IV



119914119946119941 3522720620364795284 Input


119931119942119957 24022017 1630 Output




equation (4)



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012



NO

YES

NO

YES

YES

NO

YES

YES

NO

NO

Start

Decrypt 119927119950

Extract 119862119894119889 119931119950 119878119894119892119899

119862119894119889 119894119904 119881119886119897119894119889 Send Rejected

MSG

119894119904 119881119886119897119894119889 119875119874119878 119930119946119944119951

Parse 119931119950

119878119896119890119910 119931119951 119931119957119956

119931119951119864119909119901119894119903119890119889

119878119896119890119910 119864119909119901119894119903119890119889

End

Send Completed MSG


(POS UFAN CUSTOMER

UFAN Payment value)

119865119874119878 119875119886119910119898119890119899119905

119889119900119899119890


balance

End

Send

Rejected

MSG




Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012



Table V


Parameter Value

119927119959 20 ($)

119931119957119956 20170224151213 (date format

yyyyMMddHHmmss)

119931119950 20

0f826c1589b41fe4e85edeab59f85216








































to the relay attack

























Table VI


System

Feature

Not

Depends

on SE

Prevent

Relay

Attack

Ensure

User

Location

Uses

Encryption

for

transaction


Kadambi

Li [7]

NO NO NO NO


Mohamad

Badra [9]

NO NO NO YES

Proposed

System

YES YES YES YES

10 CONCLUSION































participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012


























participants



and replay attacks










mechanism


































Applied Sciences

Upper Austria2012

Documents

A new design of Mobile Payment system based on …ijens.org/Vol_17_I_03/174703-5858-IJET-IJENS.pdfA new design of Mobile Payment system based on NFC Technology Ahmed H. Ali1, Reham