EMV-Compatible Offline Mobile Payment Protocol with Mutual Authentication.

In 2014, Yang proposed a method to enhance the current EMV credit card protocol (EPMAR). However, the protocol ignores the exceeding of a credit quota caused by multiple offline transactions, with the result that the amount spent can exceed the risk control scope. In this paper, we proposed an EMV-compatible offline mobile payment protocol with mutual authentication (EOPMA) to enhance EPMAR. In EOPMA, we use the reverse hash chain technique to guarantee the payment, which solves the problem of credit quotas getting exceeded because of multiple offline payments. During a transaction, in addition to payment for merchandise, an offline authorization certificate for the transaction is sent to the merchant. The merchant can verify the correctness of the transaction in real time. Our protocol is compatible with the EMV standard, which is applicable to the retail environment of numerous merchants and effectively, making EMV transactions more secure and reliable. We use numerical analysis to examine the security and performance of the protocols. We formally check the correctness of EOPMA by using the Gong-Needham-Yahalom logic.

1. Introduction

Credit cards have become crucial transaction tools. In 2002, the standards for EMV chip credit cards were set by international organizations such as Europay, MasterCard, and Visa [1,2]. Chip credit cards contain a microprocessor for computing power and a tamper-proof space for storing encryption keys and personal information. Scholars have investigated potential methods of improving the security of EMV protocol. For example, Ruiter and Poll applied the EMV protocol to their standardized modules [3] and used a third-party verification tool to formally analyze and validate the EMV protocol. Chen et al. proposed an improvement to the EMV key generation mechanism [4]. Murdoch and Anderson mentioned that the EMV protocol may come under threat and thus proposed improvements for mitigating threats to the EMV protocol [5]. Moreover, Alhothaily proposed a user-controlled multiple-condition verification method for improving security [6], solving the problem of a simple card verification method.

Contactless chip credit cards that employ near-field communication (NFC) sensing technology have gradually become mainstream [7,8,9,10,11]. MasterCard and Visa have created contactless credit cards, namely PayPass [12] and payWave [13], respectively. Because of the increasing popularity of NFC smartphones, Steffens [14], Cheng [15], and Noh et al. [16] proposed the integration of credit cards into mobile phones. Google, Microsoft, and Apple Inc. have also implemented a mobile phone virtual credit card mechanism [17,18,19,20] to replace conventional chip credit cards. Users only need an NFC smartphone with a virtual credit card to make a purchase, not needing to carry a physical chip card.

Numerous scholars have suggested security enhancements, analyzed smartphone NFC-based credit cards [21,22,23,24,25,26,27,28,29], and attempted to implement EMV credit cards on NFC smartphones to achieve convenience and security. Pasquet et al. proposed a security framework for detecting security issues with NFC smartphone credit cards [20] (e.g., transactions may be blocked or forged, privacy protection of secure element’s SIM card owner, protection of essential transaction data, transaction application security, hardware tamper-proof protection mechanism, and protection of personal data), and verified the detection processes using detection tools. Furthermore, Paillès et al. [22] proposed that verification messages be separately sent to both merchant and issuer, with the merchant not told the identity of consumer, but the consumer’s identity is verified by the issuer. Mainetti et al. suggested a peer-to-peer message exchange method when exchanging messages between NFC smartphones and merchants’ points of sale (POSs) [23]. Moreover, Urien and Piramuthu proposed that the secure element in an NFC phone be replaced with a cloud-based security element that provides security services to properly implement the EMV credit card protocol [24].

In addition, scholars have stated that NFC faces the following security threats [30,31,32,33]: (1) NFC is a wireless transfer method in which an electromagnetic wave is received by NFC devices nearby when a message is sent; malicious users can thus eavesdrop and obtain the message. (2) A malicious user can attempt to modify the message content. (3) A malicious user can disturb the NFC-transmitted message and corrupt it, resulting in an inability of the NFC card reader to interpret the message and thus denial of service. Finally, (4) a malicious user can determine the location of a particular NFC device because the identification number of each NFC device is unique. When an EMV transaction is conducted offline (e.g., when on an airplane), the merchant is unable to confirm the validity of a virtual credit card with the issuer in a timely manner as is the case in an online transaction; malicious users can thus commit fraud [34]. The offline risk control mechanism described in the EMV protocol cannot prevent a malicious user from committing fraud if the transaction amount is below a threshold [35]. Some studies have attempted to increase the security of offline transactions; for instance, Blaze et al. proposed risk control mechanisms such as adding a limit to the consumption amount and usage time to users’ certificates obtained from the issuer to reduce the offline payment risk [36]. Rivest and Shamir suggested that users first apply for a certificate that has an expiration date and credit quota from the issuer before making any transactions. A PayWord that does not exceed the credit quota is generated when an offline purchase is made [37]. In research on PayWord [37,38,39,40,41], approaches have mainly been suggested that can only be used for single-merchant restrictions, but some have also been proposed for multiple merchant restrictions [42,43,44].

Yang proposed EMV-based Payment with Mutual Authentication and Risk management (EPMAR), which is suitable for both offline and online transactions [45]. EPMAR adds mutual authentication to the original EMV protocol in a compatible manner to solve the problem that anyone can use a POS to read a card [46,47]; in EPMAR, all messages are encrypted using a shared key so that a malicious user cannot determine the content even if they hack into the transaction message [48,49]. However, the disadvantage of EPMAR is that the transaction amount exceeds the risk control range allowed by the credit card after multiple offline transactions.

In this paper, we propose EMV-based Offline Payment with Mutual Authentication (EOPMA), which is based on EPMAR and compatible with EMV mutual authentication in the NFC smartphone environment. In EOPMA, an offline transaction certificate and reverse hash chain are used to split and control transaction amounts for offline transactions, and the hash value obtained in each transaction clarifies the amount already spent. A counter installed in the NFC mobile device’s secure element is employed in the credit control method. The counter is forced to increase according to the amount spent in each transaction. Before an offline transaction is completed, the user must apply for an offline certificate that stipulates their credit quota and transaction authorization from the issuer; merchants can thus verify correctness of an EMV offline transaction.

Through a issuer’s endorsement value and the verification message given to each participating party (merchant and issuer), and the issuer can check the content of all transactions and verify the correctness of a message’s content (including the verification message sent by the user to the merchant), making transactions more secure by employing layers of checks.

EOPMA solves the exceeding of a credit quota caused by duplicate transactions in EPMAR that is beyond risk control to enhance the security of offline transactions. For the remainder of this paper, Section 2 introduces the EOPMA proposed in this study; Section 3 proves the security analysis of the protocol, and compares the performance with that proposed in other studies; Section 4 summarizes the methods proposed and the contributions.

2. EMV-Based Offline Payment with Mutual Authentication

An offline mutual authentication mobile payment protocol compatible with EMV is proposed in this study and is called EOPMA. EPMAR, the basis for EOPMA [45], increases the security of offline transactions and is applicable to NFC smartphones. The parties involved in EOPMA are the issuer, NFC mobile phone, acquirer, and merchant, as shown in Figure 1. Their roles are as follows:

Figure 1

EOPMA infrastructure.

Issuer: responsible for managing the application of credit cards and the issuance of offline transaction certificates. The issuer also communicates with the acquirer that deploys POS terminals through a secured financial network;

NFC mobile phone: used to store a virtual credit card in a secure element, and inductively transfers transaction data with the merchant’s POS. When a user wants to make an offline transaction, he must first apply for an offline transaction certificate from the issuer.

Merchant: deploys a POS to read the NFC mobile phone; transaction data received by the merchant are transmitted to the acquirer through a secure channel. Merchants can conduct online or offline transactions with the user.

Acquirer: receives the transaction data from the merchant and confirms the correctness of the transaction through the financial network. In offline transactions, the merchant cannot connect the acquirer to check if a credit card has been revoked.

The EOPMA process is divided into five phases: mutual authentication of the mobile phone, function selection, offline certificate application and split credit quota authorization, offline and online transactions, and payment request by merchant, as shown in Figure 2. The phases are explained as follows:

Figure 2

EOPMA flowchart.

In phase 1 Mutual authentication, mutual authentication of the EMV card and POS is performed, and the exchanged certificates of both user and merchant are authenticated. The EMV card and POS verifies each other’s identity. Otherwise, the EMV card returns a failed acknowledgement and aborts the transaction.

Phase 2 is the function selection phase in which the merchant checks whether the user already has an offline certificate. In phase 2, two functions can be selected: applying offline certificate (go to phase 3), or go transactions (phase 4). Phases 1 and 2 are similar to those in EPMAR and the details are thus not discussed in this paper.

In phase 3, the user requests an offline transaction certificate and the amount required for the transaction from the issuer. In addition to an offline certificate, a credit quota calculated by the issuer is obtained from the application to effectively control the offline transaction amount. Moreover, crucial messages are protected by a secure element.

In phase 4, the transaction process begins. The EMV chip specifications define two types of the card authentication: online transaction and offline transaction. The processing steps for an EMV contact chip transaction are defined in Figure 4 of [2]. If the NFC mobile phone requests to go online, then the merchant’s terminal builds an online request to the issuer via the financial bank network for online card authentication. Otherwise, an offline transaction is performed if the user has a certificate; in an offline transaction, the merchant verifies the transaction message transferred by the user; if the merchant supports online transactions, the transaction message received by the merchant is transferred to the acquirer for verification. In phase 4, the mobile phone uses the credit quota parameters obtained during the application to calculate the amount spent in the current transaction and to generate a unique verification message for sending to the merchant and issuer. The merchant immediately knows the correct transaction amount, whereas the issuer is informed of the correct credit quota and the identity of the transaction merchant.

Phase 5 is the phase in which the merchant requests payment from the issuer. In phase 5, after the offline transaction has been completed, the merchant requests payment from the issuer via the acquirer by using the transaction verification data provided by the user, and the issuer uses the verification message sent by the user to the merchant via the acquirer to confirm whether the transaction is legitimate.

2.1. Generation of Offline Transaction Certificates

The method proposed in this study is compatible with the EMV standards [1]. The amount available for offline transaction is represented as two usable hash values that clearly indicate the amount used and amount usage range. Both merchants and issuers can verify the availability of this credit quota. The user must first apply for an offline transaction certificate with the issuer before making an offline transaction. During the transaction, the user shows the certificate to the merchant so that the merchant can submit the certificate to the issuer via the acquirer to verify the validity of the offline transaction.

2.1.1. (a) Generation of Secret Factors

The secret factors and used in the credit hash chain are not randomly generated but obtained using the method employed by PayFair [25] and proposed by Yen et al. Before the issuer generates and , it first generates the random numbers and and corresponding sequence numbers and . It then stores and in a table, as illustrated in Table 1.

Table 1

Sequence numbers and random numbers of secret factors.

Serial Number	Random Nonce
⋯	⋯
SN_w	R_w
⋯	⋯
SN_s	R_s

The issuer uses the uniquely owned key to encrypt and into the and of the hash chain to form and . During issuer verification of the merchant’s payment request phase, the issuer receives and to identify and and uses to calculate the and to obtain the correct and for starting the verification process.

2.1.2. (b) Credit Quota Calculation Method

Assuming the available credit limitation is n, the issuer calculates the entire hash chain by using the calculated :

2.1.3. (c) Issuance of Offline Certificates and Credit Quota Calculation Method

When applying for an offline transaction, the issuer gives the user an offline certificate and a credit quota . In the offline certificate, the user is informed of their upper credit limit n, and the amount of the secret value , of the endorsed , and for verification are placed in the credit quota content. The user employs the same calculation method as the issuer, , for and uses to calculate the entire series of hash chains . The user verifies through n depending on whether the calculation result of the hash function, , is the same to the endorsed by the issuer.

2.1.4. (d) Use of the Credit Quota

In each transaction, the amount spent is split from the credit quota to pay the merchant. The splitting method is to sequentially give the hash value from the hash chain from ; when it reaches , the maximum credit quota has been reached. To make further purchases, the user must reapply a new quota to the issuer.

The hash value generated by is used to represent the currently spent amount, and the interval between and is used to perform c calculations to obtain the amount used in the transaction. As illustrated in Figure 3, assuming that the offline credit quota applied is n and the amount spent in the first transaction is b, the user provides and . In the second transaction, the amount spent is c, and the user provides a continued amount of use of and . Finally, as shown in Figure 3, the credit quota is reached after multiple transactions when the user gives the merchant and , at which point the user must reapply for an offline transaction certificate to the issuer.

Figure 3

Simple offline transaction credit splitting diagram.

This protocol employs the characteristics of the reverse hash chain, with which the merchant obtains ; the merchant cannot calculate the previous hash value and thus cannot forge any amount unequal to that the user has authorized to the merchant. The protocol applies to a retail environment in which many merchants may be involved. When the user makes their first purchase, the merchant is given a quota between and , whereas, when the second purchase is made, the second merchant will be given the limit of and . This method is used to achieve an offline transaction mechanism that can be used for multiple merchants.

2.1.5. (e) Credit Quota Verification

As illustrated in Figure 3, the amount spent in the first transaction is b, and the merchant obtains and from the user. The merchant can judge the correctness of by calculating whether after b hash function calculations is equal to . The amount spent in the second purchase is c, and the merchant obtains the amount of and that the user continues to use; then, is used to calculate the hash function c times to determine whether it is equal to .

In a transaction, two transaction verification messages, and , are sent. is the verification message provided to the merchant with which the following verification is conducted:

and are used to calculate the correctness;

the issuer’s public key is employed to decrypt to obtain , and it is checked whether can be calculated back to to verify that the obtained hash value is correct;

the merchant checks that the forced addition to by the user is less than the applied amount n;

the merchant checks that is the merchant’s own ID.

The variable is a verification message provided to the issuer to perform symmetric encryption by using the shared key . The issuer verifies the contents of by:

the issuer verifies the merchant identity ;

the issuer checks whether is in the merchant list M;

the issuer obtains the serial number of the secret factor of the hash chains and and checks the corresponding hash value secret factors and ;

the issuer checks that the derived is the same offline certificate and credit quota that was supplied by the user.

2.2. Merchant’s Identity

When users purchase from multiple merchants, the merchants must be unable to deny the purchases. The identity of each merchant is calculated using each hash value in the hash chain, which is as follows:

is a hash function secret factor representing the identity of a merchant. In the first transaction, the mobile phone calculates to represent the merchant participating in the transaction. Similarly, in the second transaction, is calculated to represent the participating merchant. The secret factor of this hash chain is only shared between the issuer and mobile phone; the merchant is unaware which hash value it belongs to. Finally, the generated after the nth transaction (first item of the reverse hash chain) is stored in the phone’s secure element, and the user cannot modify the hash value of the representative merchant.

2.3. Compatibility with the EMV Protocol

The method proposed in this study is based on EPMAR, in which an unused field (EXTERNAL AUTHENTICATION command) of the EMV [1] command parameter is used to add new messages without changing the order of the original protocol. In addition, the unused option field (reserved for future use [RFU] of GENERATE AC) in the EMV message transfer is used to transfer the parameters and certificates required for authentication to improve security of offline transactions.

To distinguish parts of messages, blue font is used to indicate the newly added message and execution calculation by referring to EPMAR as the benchmark, and a green box indicates that the newly added message uses a field that is not used by EMV or has been reserved in order to be compatible with the EMV protocol.

Regarding the items held by mobile phones, merchants, and issuers during initialization, in addition to what is already employed in EPMAR (e.g., credit card data , credit card private key , communication key , merchant’s certificate , shared key , message authentication code , and merchant public key ), mobile phones and merchants hold a public key of the issuer, which can be used to decrypt an encrypted message after endorsement by the issuer. The issuer adds (1) the issuer’s own key, , which is used to generate a credit quota and the secret value of the merchant’s hash function; (2) the issuer’s private key, , which is employed to endorse the credit quota; and (3) the credit card’s public key, , which shares the essential parameters needed for the offline transaction stored in the secure element of the credit card.

2.4. Phase 3: Offline Certificate Application and Split Credit Quota Authorization

2.4.1. Phase 3 Process Diagram

Figure 4 presents a flowchart of offline certificate application and split credit quota authorization processes. In steps 1 and 2, the merchant requests an offline certificate from the user’s mobile phone, and the mobile phone applies to the issuer if it does not have an offline certificate.

Figure 4

Offline certificate application and split credit line authorization processes.

Step 1: The merchant requests the user’s NFC phone to present its offline certificate.

Step 2: If the phone does not have an offline certificate,

(2a-1) the phone applies to the issuer for a certificate and the split credit quota authorization required for transactions.

(2a-2) the issuer generates the offline certificate, transaction authorization, and credit quota required to split the certificate. The certificate is stored in the secure element of the phone upon receipt.

If the phone has an offline certificate,

(2b) the phone sends a message containing the offline certificate to the merchant.

2.4.2. Phase 3 Protocol

To make the protocol concise, the commands that a merchant sends to the credit card to obtain data types are omitted. The transmitted message is indicated by a solid arrow above, and the action performed after receiving the message is denoted by the solid box. A communication key, , is used to encrypt and protect the transaction between the phone and merchant’s POS. Figure 5 presents the protocol for offline certificate application.

Figure 5

Offline certificate application and split credit line authorization protocol.

Message 1

When the user’s phone receives a GENERATE AC command [1] containing an offline certificate request cryptogram (OCRC) [45], the phone first decrypts to retrieve by using the communication key . The data transferred by the merchant, , serial number of the transaction, [1], and a random number obtained in mutual authentication, [45], are used to generate a message authentication code with the hash function by using the shared key, , with the issuer:

Message 2

The phone encrypts the , , and that were originally to be transmitted according to the protocol using and sends them back to the merchant to begin the offline certificate application phase.

Message 3

After receiving the message from the phone, the merchant decrypts , , and by using . Subsequently, in addition to sending the decrypted data and the generated in mutual authentication to the issuer, the merchant informs the issuer of the longest offline duration to be used, [45], so that the issuer can set the expiration time of the offline certificate according to the offline transaction environment.

Message 4

Once the issuer receives the request message for offline certificate application, it uses the shared key , , , and in the message to calculate and determine whether the code in the message sent by the merchant is correct. If the message is incorrect, the authorization response code () is set to fail. Otherwise, the is set to success, and the issuer starts to generate the parameters and transaction verification message required for issuance of the offline transaction certificate and credit control:

Randomly generated numbers and are used to create the corresponding serial numbers and , and and are stored in .

The of the issuer is employed to encrypt the random and serial numbers to generate secret factors representing the credit quota and offline transaction merchant :

The hash values of and are calculated and placed into the reverse hash chain set W and forward hash chain set S:

All authorized merchant identities are placed in the authorized merchant set M.

A is generated that enables the issuer to authenticate the transaction message.

A b is generated that represents the current user’s amount spent. Because the amount has not been used at the application phase, .

The issuer’s is used to perform asymmetric encryption on the last item of the credit quota hash chain for issuer endorsement. During the transaction, the merchant confirms the correctness of and calculates and verifies that the amount received is correct.

Asymmetric encryption is performed using the credit card’s public key , inserting the (a) shared key of the user and issuer; (b) secret factor of the limit hash chain; (c) serial number of ; (d) , which represents the secret factor of the merchant’s hash chain; (e) serial number of ; (f) amount to be spent b; (g) after has been endorsed by the issuer; and (h) apart from necessary amount data, a random number , which prevents the amount spent message from being resent:

According to EMV standards, the sent by the merchant, and the user’s credit assessment, the issuer generates , an X.509 certificate [50]. This certificate includes the issuer (), user’s credit card account (), offline certificate expiration time (), consumption upper limit (n), and all authorized merchant identities (M).

Finally, the issuer uses to generate a message authentication code ARC) by using the mutually exclusive results between and . Subsequently, this message authentication code, , the encrypted by the phone’s , and are sent to the merchant.

Message 5

If the merchant receives a reply from the issuer that the fails, the offline certificate application process is terminated. However, a successful indicates that the issuer agrees to send an offline certificate. The merchant uses the EXTERNAL AUTHENTICATION command marked in the unused parameter field [1] to transfer the offline certificate to the user’s mobile phone [45]. In addition, is placed in this unused parameter field.

Decryption and verification are performed after the phone has received ARCARC and :

Decryption is performed using , and the received, calculated at the beginning of the protocol, and are used to calculate the message authentication code ARC) to confirm that it is similar to the code received.

is employed to decrypt the offline certificate and inspect its source. The phone sets the inspection result to fail for a failed message authentication code and offline certificate verification.

If the message received is verified to match the correct , the certificate is placed in the list, making .

The of the credit card is used to decrypt the asymmetric encryption of Lim to obtain , , , , , b, , and and store them in the secure element for protection to prevent users from arbitrarily modifying the essential parameters and data of their offline transactions. Once the phone receives it, the Lim is sent directly to the secure element for decryption. The phone plays a mediating role between the merchant and secure element.

The issuer’s public key is employed to decrypt the asymmetric encrypted to obtain the generated by the issuer, and whether is equal to the obtained by decrypting after n hash function calculations is determined. If , the fails; otherwise, the is success, with . The forced added counter in the secure element adds up the amount of each purchase to the counter until the upper limit n is reached; reapplication is then required to continue making offline transactions.

Message 6

Finally, the phone returns the to the merchant. If the fails, the merchant must reapply for a certificate. Otherwise, the user’s phone saves the offline certificate, and the phone does not need to reapply for an offline certificate in the next transaction if the message received by the merchant contains , which indicates that offline transaction can commence immediately.

2.5. Phase 4: Offline and Online Transactions

Figure 6 presents a flowchart of offline transactions. In steps 3 and 4, the merchant provides relevant data to the user regarding purchased merchandise, and the user provides their certificate, payment, and verification information to the merchant upon confirmation.

Figure 6

Offline transaction process.

In step 3, the user selects the merchandise to be purchased, and the phone displays the merchandise information and price for the user to confirm. In step 4, after the user has given their confirmation, the phone makes the payment and provides the merchant with the offline certificate and credit quota.

In phase 4, the merchant transfers an offline/online transaction request () and a GERNATE AC command (information required for transactions in the EMV protocol), encrypted by , to the mobile phone, as illustrated in Figure 7. If , an online transaction is performed between the merchant and mobile phone; if , an offline transaction is performed.

Figure 7

Offline/online transaction protocol.

Message 7

Once the phone receives the GENERATE AC command with parameter , is used to decrypt the transaction data to obtain , and the user confirms that the transaction amount in is correct. The phone then executes the following three steps in accordance with the EMV payment requirements:

A message authentication code is generated from the , , and using the issuer’s . .

,, , the of , , and the for generating are calculated.

Encryption is performed using the EMV credit card’s to generate the signed dynamic application data (SDAD) from , , , and the hash function generated in the previous step.

The data stored in the secure element during the application phase are retrieved for verification and calculation, and transaction verification and payment messages are generated:

The sent by the merchant must be present in the authorized merchant list M of ; if it is not, the transaction is canceled immediately.

The amount spent b is employed to calculate the used hash value . Moreover, the transaction amount c is used to calculate the paid hash value . The amount spent is a reverse hash chain, and the hash is a one-way irreversible function; thus, the actual method for calculating the hash value is as follows:

The merchant code is calculated. In the first purchase, and . Each transaction generates a hash value representing the merchant, and the shared key is used for encryption so that the merchant is unaware of ; nonetheless, it does represent the merchant participating in the transaction.

The amount c is spent in the transaction; thus, the amount spent becomes .

The current purchase amount c is added to , such that .

A verification message is generated for the issuer, and the offline transaction authentication key , which was obtained by the secure element during the application is used to represent the merchant’s identity hash value , serial number of , serial number of , and placed in during the application phase; these are symmetrically encrypted to become .

A verification message is generated for the merchant, and the of the credit card is employed to asymmetrically encrypt the issuer verification message , amount after issuer endorsement , hash value of the amount spent , hash value of the payment amount , current amount spent c, offline transaction amount counter, and merchant’s identity into .

Message 8

The mobile phone encrypts , , , , and , which are returned to the merchant through the use of . The newly added message content is placed in the RFU of GENERATE AC for transfer to achieve an EMV-compatible protocol.

The merchant receives the returned message from the mobile phone and performs two decryption and six verification actions:

is used to decrypt and extract , , , , and .

is employed to decrypt and obtain , and ’, and the issuer’s public key is used to decrypt to obtain :

The is decrypted using , and the hash function is verified.

’ in is equal to .

Whether current time meets the limited by the is checked.

Whether the counter limit has not exceeded the offline transaction amount n set in the offline certificate is checked.

The correctness of is calculated. Using , where , it is determined whether and are in the same hash chain. Whether is equal to after c hash function calculations is determined, and the calculation method is .

The transaction is terminated immediately if any verification fails. Finally, receipt of indicates that the transaction is an offline transaction, and the merchant requests payment from the issuer to complete the transaction. However, if is received, the merchant transfers data to the issuer to begin an online transaction. The transfer content of the online transaction begins from Message 3.

2.6. Phase 5: Payment Request by the Merchant

Figure 8 presents the merchant payment request diagram. In steps 5 and 6, the merchant transfers the payment information and verification message to the issuer to verify the correctness of the transaction. If the information is correct, the issuer sends the amount corresponding to the user’s purchase to the merchant.

Figure 8

Process of merchant payment request.

Step 5: the merchant sends the self-verified message, issuer-verified message, and payment information to the issuer to request verification of the transaction’s correctness.

Step 6: if the transaction is verified, the merchant can request payment from the issuer.

Once the offline transaction is complete, the merchant sends the payment message received to the issuer. As illustrated in Figure 9, in addition to the transaction message of a payment request, an additional verification required by the issuer (in the method proposed in this study) is added.

Figure 9

Merchant payment request protocol.

The merchant sends the verification messages and to the issuer. The issuer decrypts the messages using and , respectively, to obtain and .

Whether and ′ in exist in is checked. If they do, sequence numbers and are used to obtain the random numbers and from the table. Subsequently, , , and the issuer’s are employed to perform encryption for calculating and to obtain the and applied by the user. After obtaining and , the issuer makes checks and verifications to determine whether the transaction amount should be issued to the merchant:

It is verified that and are in the W hash value set generated during the application phase and the merchant representative hash value is in the S hash value set.

Whether in is present in the list of authorized merchants of the offline certificate is determined.

The preposition , where , is considered to determine whether and are in the same hash chain and thus confirm their correctness. Whether equals after c hash function operations is determined, and its calculation method is .

Whether exceeds the limit n is checked.

It is confirmed that the in is equal to the placed in during the application phase.

If the aforementioned verification fails and the comparison result does not conform to the issuer, the transaction is rejected and reviewed. If the verification is successful, the issuer pays the amount to the merchant.

3. Security Analysis and Performance Evaluation

The security of the method proposed in this study and the performance are analyzed in this chapter.

Verifiability:

In phase 4, the merchant can immediately verify the verification message of the offline transaction.

In phase 5, the issuer obtains transaction verification messages (for the merchant and issuer) from the merchant and verifies all the information obtained to ensure the correctness of the transaction.

Counterfeiting prevention:

In phase 3 (2a-2), the issuer provides the user and merchant with the encrypted hash value of the final item of the user’s credit quota chain so that they can verify the amount of the hash value (as shown in Figure 4). Attackers cannot encrypt the cipher text without the issuer’s private key.

In message 7 of phase 4, the amount spent b information given to the merchant is protecvalue by the user is asymmetrically encrypted using the credit card private key : , and the merchant requests payment from the issuer after confirmation. Incorrect amount information generated by the user is immediately detected by the merchant. Similarly, the merchant cannot falsify the information given by the user to request a higher amount from the issuer.

Tampering prevention:

In the application phase, the offline transaction certificate and credit quota limit information are encrypted using the virtual credit card’s public key and the key shared between the user and issuer, enabling the issuer to protect the message content. In addition to the credit quota hash chain’s secret factor , the credit quota message contains cipher text encrypted using the issuer’s private key.

If the secret factor is not calculated by the original issuer, different hash values obtained during the verification will cause failure of the verification.

The verification message given to the merchant in message 8 of phase 4 is encrypted using the virtual credit card’s private key , which is stored in the secure element. Even if malicious software is installed on the user’s mobile phone, the content encrypted by the secure element is not easily modified.

Replay attack prevention:

In the application phase, the issuer places a random number in the credit quota message and passes it to the user. The user places the random number in the issuer verification message (as shown in Figure 9 and passes it to the merchant during a transaction. The merchant sends this message to the issuer during their payment request. The issuer then checks whether the random number is the same as that given by the issuer to the user during application and whether the corresponding amount is the amount originally given as the hash value.

Nonrepudiation:

In phase 4, in addition to having a transaction message, the user has a verification message (to be given to the merchant) that is encrypted using the virtual credit card’s private key to generate the signed dynamic application data (SDAD) from , , , which ensure that the message is sent by the user. The user cannot deny that they have created this message.

The issuer verification message also contains two corresponding hash values ( and ) for the transaction that the merchant is not informed of, indicating that the credit quota is for the use of a certain merchant. If the merchant subsequently denies the transaction, the issuer can identify the corresponding merchant during verification.

Duplicate payment prevention:

The user cannot cheat the merchant because a is stored in the secure element of the mobile phone and is forced to increase upon every transaction. The value of must be smaller than the transaction usage amount requested by the user. If the user repeatedly uses the amount of the hash value, the counter is still forcibly added to; thus, the amount spent must be lower than the applied amount (e.g., a failed transaction may waste the usable amount because the counter has already been forcibly added to when the user sends out a credit quota limit hash value), and the amount does not expand because of a duplicate payment. If the merchant want to duplicate the payment (as shown in Figure 8), it sends and to the issuer. The issuer will decrypt the message and detect double-spending by using the and are in the W hash value set generated during the application phase.

3.1. Security Analysis

Table 2 shows the security comparison between our protocol EOPMA, EPMAR [45], and the original EMV standards [1]. We also compare our protocol with Al-Tamimi [28] and Madhoun [29] works. EOPMA, EPMAR and Modhoun’s scheme perform mutual authentication with the merchant. Both of them can detect a malicious phone and a malicious merchant. The original EMV standards (CDA, DDA and SDA) only authenticate with the phone, which causes an MITM attack to possibly occur. In addition, in an EMV transaction, the data between a reader and a card are transmitted in plaintext.

Table 2

Security comparison chart.

	EOPMA	EPMAR	Al-Tamimi	Modhoun	EMV-CDA	EMV-DDA	EMV-SDA
Exceeding of a credit quota	O	X	X	X	X	X	X
Malicous phone	O	O	O	O	O	O	O
Malicous merchant	O	O	O	O	X	X	X
Confidentiality	O	O	O	O	X	X	X
Replay attacks	O	O	O	O	X	X	X
Data privacy	O	O	O	O	X	X	X
Integrity	O	O	O	O	O	O	O
Non-repudiation	O	O	O	O	O	X	X
MITM attacks	O	O	X	O	O	X	X
Clone attacks	O	O	O	O	X	X	X
Fully EMV-Compatiable	O	O	X	O	O	O	O

In Al-Tamimi’s scheme, it adds a Mobile Network Operator (MNO) layer as a trust third party to perform mutual authentication between the NFC phone and the merchant. However, it requires extra communication channel, which is not fully EMV-compatible.

3.2. GNY Logic Proof

In this section, we use the Gong–Needham–Yahalom (GNY) logic [51] to prove the security of our proposed protocol. The GNY logic is used for the analysis of cryptographic protocols in a formal way, which can be easily applied and gives a quick insight in the working of a protocol. Our analysis includes four parts: the notation of the GNY proof (Table 3), initial assumptions (Table 4), goals of proposed protocol (Table 5), and the proving process (Table 6).

Table 3

Notations of the GNY proof.

I	Issuer
M	Merchant
P	User’s NFC phone
{X}_K,{X}K−1	Uses the symmetric key K to encrypt/decrypt the message X.
{X}_+K,{X}_−K	Uses the asymmetric key K to encrypt/decrypt the message X.
H(X)	Message X is protected by the one way hash function H(X).
P◃X	P is told message X.
P∈X	P possesses message X.
∗X	X is generated by others; P◃∗X means P is told for X which he did not convey previously.
P∣≡#(X)	P believes X is fresh. X has not been used at any time in the prior protocol, or sent by an attacker.
	For example, a random number or a counter.
P∣≡⌀(X)	P believes X is recognizable.
P∣≡PSQ	P believes S is shared by P and Q.
P∣≡P+KQ	P believes Q owns the private key −K correspondent to the public key +K.
P∣≡Q∣∼X	P believes Q sent X.

Table 4

Initial assumptions.

Phone
P∈−K_emv,+K_emv,Kenc_emv,TK	The phone keeps a virtual credit card’s public key, private key,
P∣≡PKenc_emvI	and the shared encryption key.
P∣≡PTKM	The phone generates a session key TK with a merchant during a transaction.
P∣≡→+K_issI	The phone holds the issuer’s public key.
P∣≡⌀(ID_M_g)	The phone knows the merchant’s ID.
Merchant
M∈ID_M_g,TK	The merchant owns his identity,
M∣≡MTKP	the shared session key TK with the phone,
M∣≡M+K_emvP	credit card’s public key,
M∣≡M+K_issP	and the issuer’s public key.
Issuer
I∈−K_iss,+K_iss,Kenc_emv,K_β	The issuer has its own private key and public key,
I∣≡IKenc_emvP	the shared key with the phone,
I∣≡→+Kenc_emvP	the transaction key.
I∣≡⌀(ID_M_g)	The issuer knows the merchant’s identity,
I∣≡#(R_lim)	and uses a random number for verification.

Table 5

Goals of proposed protocol.

Phase 3, offline certificate application and split credit quota authorization
P∣≡I∣∼#(R_lim)	The phone believes R_lim and Cert_off is generated by the issuer,
P∣≡I∣≡⌀#(R_lim)	gets the shared key K_β.
P∣≡I∼#(K_β,w_n,SN_w,s_o,b,φ,R_lim)	Finally both of them believes all the messages are fresh
P∣≡⌀(K_β,w_n,SN_w,s_o,b,φ,R_lim)	and are recognizable.
P∣≡PK_βI
P∣≡I∣∼Cert_off
P∣≡I∣⌀Cert_off
Phase 4, offline and online transactions
M∣≡P∣⌀Cert_off	The merchant believes the phone has the offline certificate Cert_off,
M∣≡P∣∼(μ)	and he believes μ is generated by the phone.
M∣≡P∣⌀(μ)	Finally the two parties believe the μ is fresh
M∣≡P∣∼#(β,φ,w_b,w_b+c,c,counter,ID_M_g)	and is recognizable.
M∣≡⌀(β,φ,w_b,w_b+c,c,counter,ID_M_g)
Phase 5, payment request by merchant
I∣≡M∣∼⌀(μ)	Both the issuer and the merchant believe μ is recognizable,
I∣≡M∣⌀(β,φ,w_b,w_b+c,c,counter,ID_M_g)	and the issuer believes β is recognizable.
I∣≡⌀(β)
I∣≡⌀(s_v,SN_w,SN_s,R_lim)

Table 6

Proving process.

Phase 3
Message	M◃∗R_lim,∗{Cert_off}_Kenc_emv	The merchant and the issuer has built an secure channel
1.1	M∣≡I∣∼R_lim,∗{Cert_off}_Kenc_emv /* IA */	all the messages between them can be trusted.
	M∣≡#(R_lim,{Cert_off}_Kenc_emv) /* IA */
	M∣≡⌀(R_lim,{Cert_off}_Kenc_emv) /* IA */
Message	P◃∗{R_lim}_TK,∗{Cert_off}_Kenc_emv	The phone believes TK is fresh.
1.2	P◃{R_lim}_TK,{Cert_off}_Kenc_emv /*T1*/	believes μ is generated by the phone.
	P◃R_lim,Cert_off /* T3 */	Finally both of them believes the μ is fresh
	P∈R_lim,Cert_off /* P1 */	and is recognizable.
	P∣≡#(R_lim) /* F3 */
	P∣⌀#(R_lim) /* R4 */
	P∣≡#(Cert_off) /* F3 */
	P∣⌀#(Cert_off) /* R4 */
	P◃K_β,w_n,SN_w,s_0,b,φ,R_lim /* T3 */
	P∈K_β,w_n,SN_w,s_0,b,φ,R_lim /* P1 */
	P∣≡⌀(K_β,w_n,SN_w,s_0,b,φ,R_lim)
	P∣≡PK_βI /* J1 */
Phase 4
Message	P◃∗Req,∗{Data_emv}_TK	The phone believes TK is fresh,
2.1	P◃Req,{Data_emv}_TK /* T1 */	and Data_cdol1 is recognizable.
	P◃Data_cdol1 /* T3 */	Therefore, Data_cdol1 is not forged or replayed.
	P∈Data_cdol1 /* P1 */
	P∣≡⌀Data_cdol1 /* R2 */
Message	M◃∗{μ}_TK	The merchant believes TK is fresh, and μ is not forged.
2.2	M◃{μ}_TK /* T1 */	The merchant gets the public key +K_emv of the credit card.
	M◃μ /* T3 */	Therefore, the merchant can vertify the message μ by φ.
	M∈μ /* P1 */
	M∣≡#(μ) /* F4 */
	M◃β,φ,w_b,w_b+c,c,counter,ID_M_g /* T6 */
	M∈β,φ,w_b,w_b+c,c,counter,ID_M_g /* P1 */
	M∣≡⌀(β,φ,w_b,w_b+c,c,counter,ID_M_g
	M∣≡⌀(φ) /* R3*/
	M◃w_0 /* T6 */
	M∈w_0/* T6 */
	M∣≡w_0 /* P1 */
Message	I◃∗μ	The issuer and the merchant has established a secure channel,
3	I◃μ /* IA, T1*/	all the messages exchanged between them can be trusted.
	I∣≡M∣∼μ/∗IA∗/	The issuer gets phone’s public key +K_emv, and the shared
	I∈μ/∗P1∗/	key K_β.
	I∣≡#(μ) /* IA, F4 */	Therefore, the issuer can verify the message μ and β.
	I∣≡⌀(μ). /* IA, R3 */
	I◃β,φ,w_b,w_b+c,c,counter,ID_M_g /* T6 */
	I∈β,φ,w_b,w_b+c,c,counter,ID_M_g /* P1*/
	I∈≡⌀(w_b,w_b+c,c,counter,ID_M_g
	I∣≡#(β) /* F2 */
	I∣≡⌀(β) /* R2 */
	I∣≡⌀(φ) /* R3*/
	I◃s_v,SN_w,SN_s,R_lim /* T3 */
	I◃s_v,SN_w,SN_s,R_lim /* T3 */
	I∈s_v,SN_w,SN_s,R_lim /* T3 */
	I∈⌀(s_v,SN_w,SN_s,R_lim)

3.3. Performance Analysis

In the current EMV standard, the asymmetric encryption uses RSA 1024 bits, we also add RSA 2048 bits as the object of analysis. In symmetric encryption, we chose AES-128 as the benchmark for our symmetric encryption. In order to compare with the original EMV standards, we chose the same experimental environment as EPMAR; use two E975 LG Optimus G mobile phones at Taiwan to negotiate the consumer side and the merchant side, and use the Android API level 16 library to implement EOPMA. The transmission rate between the phone and the reader is 858 kbit/s, according to ISO 14443 standard. Table 7 lists the operation time of cryptography functions of the LG mobile phone. Due to the restriction of EMV standards, an EMV transaction should take less than 500 ms, we choose RSA-1024 in our protocol evaluation.

Table 7

The operation time of cryptography functions (ms).

Operations	Time
AES-128 (T_A)	0.15
HMAC-128 (T_H)	0.16
HMAC-256 (T_H_256	0.25
Random number generation	0.01
RSA encrypt (T_RSA_E)	0.59
RSA decrypt (T_RSA_D)	5.67

Next, we compare the extra computational loads with EPMAR. We assume the computation capabilities of the issuer are better than the mobile phone and the merchant’s POS. Table 8 shows the extra operation time of EOPMA, comparing to EPMAR. We use the symbol , , , , as HMAC, AES, RSA encryption, RSA decryption and random number generation, respectively. In phase 1 and phase 2, the EOPMA operations are the same as EPMAR. In phase 3, the issuer requires extra six random numbers’ generation, plus two hash chains (W and S) calculations. The W hash chain is for the credit quota generation and the S hash chain is used to represent the count of merchants. The phone needs an AES decryption and n HMAC-128 to calculate the hash chain ().

Table 8

The extra operations of EOPMA, comparing to EPMAR.

Operations	Phone	Merchant	Issuer
Phase 1	0	0	0
Phase 2	0	0	0
Phase 3	T_A+n∗T_H+T_RSA_D	T_A+T_RSA_E+T_RSA_D+T_H	6∗T_r+n∗T_H+T_RSA_E+T_RSA_D
Phase 4	T_A+T_RSA_E	(c−b)∗T_H+T_A+T_RSA_D	0
Phase 5	0	0	T_A+T_RSA_D+(c−b)∗T_H

In phase 4, the phone only needs one AES encryption and one RSA encryption. The merchant requires one AES decryption, one RSA decryption and up to (c-b) hash operations. In phase 5, the merchant only forwards the payment information to the issuer; all the verifications are done in the issuer.

In the experiment, we choose , for the maximum of 100 offline transactions, and the maximum offline transactions per merchant, . The result is shown in Figure 10. The extra spent time of the phone is less than 23 ms. The issuer requires 29.74 ms for 100 transactions. However, the computing power of a server far exceeds that of a mobile phone. The issuer’s calculation time will be smaller than the experiment.

Figure 10

Extra computation time.

4. Conclusions

In this paper, we proposed an offline mobile payment protocol named EOPMA that is compatible with EMV, provides mutual authentication, and can solve the problems of credit quota exceeding in EPMAR and duplicate payments in PayWord. In EOPMA, an offline transaction is halted when the offline credit quota reaches the amount specified by the user, and the user must then reapply to the issuer to make further purchases. Through the proposed offline certificate and credit control, both the issuer and merchant can clearly verify the content of transaction information and the credit quota given by users, protecting them from losses incurred. Using EOPMA, the amount spent will never exceed the credit quota imposed by the issuer to ensure credit control and solve the double-spending problem.

We implemented EOPMA on an NFC phone and compared the performance with other schemes. EOPMA implemented EMV’s unused and reserved commands to add a new method that is compatible with the existing EMV protocol. Our protocol resists the security threats in the EMV standards, such as man-in-the-middle attacks, replay attacks, and clone attacks. The cryptographic protocol analysis logic of Gong, Needham and Yahalom (GNY) is used to prove the correctness of EPMAR.