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.


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

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:

1.
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; 2.
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. 3.
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. 4.
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.  Figure 1. EOPMA infrastructure.
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: 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.

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.

(a) Generation of Secret Factors
The secret factors w 0 and s n 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 w 0 and s n , it first generates the random numbers R w and R s and corresponding sequence numbers SN w and SN s . It then stores {SN w , R w } and {SN s , R s } 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 K iss to encrypt {SN w , R w } and {SN s , R s } into the w n and s 0 of the hash chain to form w n = E K iss (SN w , R w ) and s 0 = E K iss (SN s , R s ). During issuer verification of the merchant's payment request phase, the issuer receives SN w and SN s to identify R w and R s and uses K iss to calculate the w n = E K iss (SN w , R w ) and s 0 = E K iss (SN s , R s ) to obtain the correct w n and s 0 for starting the verification process.

(b) Credit Quota Calculation Method
Assuming the available credit limitation is n, the issuer calculates the entire hash chain w 0 , w 1 , · · · , w n by using the calculated w n : (1)

(c) Issuance of Offline Certificates and Credit Quota Calculation Method
When applying for an offline transaction, the issuer gives the user an offline certificate Cert o f f and a credit quota Lim. In the offline certificate, the user is informed of their upper credit limit n, and the amount of the secret value w n , w 0 of the endorsed ϕ = E SK iss (w 0 ), and SN w for verification are placed in the credit quota content. The user employs the same calculation method as the issuer, w i = h(w i+1 , for i = n − 1, n − 2, · · · , 0 and uses w n to calculate the entire series of hash chains w 0 , w 1 , · · · , w n . The user verifies w n through n depending on whether the calculation result of the hash function, w 0 , is the same to the w 0 endorsed by the issuer.

(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 w 0 , · · · , w b , · · · , w b+c , · · · , w n ; when it reaches w n , 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 w i = h(w i+1 ) is used to represent the currently spent amount, and the interval between w b and w b+c 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 w 0 and w b . In the second transaction, the amount spent is c, and the user provides a continued amount of use of w b and w b+c . Finally, as shown in Figure 3, the credit quota is reached after multiple transactions when the user gives the merchant w k and w n , at which point the user must reapply for an offline transaction certificate to the issuer.  This protocol employs the characteristics of the reverse hash chain, with which the merchant obtains w i = h(w i+1 ); the merchant cannot calculate the previous hash value w i+1 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 w b and w b , whereas, when the second purchase is made, the second merchant will be given the limit of w b and w b+c . This method is used to achieve an offline transaction mechanism that can be used for multiple merchants.
s 0 is a hash function secret factor representing the identity of a merchant. In the first transaction, the mobile phone calculates s 1 to represent the merchant participating in the transaction. Similarly, in the second transaction, s 2 is calculated to represent the participating merchant. The secret factor of this hash chain s 0 is only shared between the issuer and mobile phone; the merchant is unaware which hash value it belongs to. Finally, the s n 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.

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 Data emv , credit card private key SK emv , communication key TK, merchant's certificate Cert acq m , shared key K enc emv , message authentication code K mac emv , and merchant public key PK m ), mobile phones and merchants hold a public key PK iss 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, K iss , which is used to generate a credit quota and the secret value of the merchant's hash function; (2) the issuer's private key, SK iss , which is employed to endorse the credit quota; and (3) the credit card's public key, PK emv , which shares the essential parameters needed for the offline transaction stored in the secure element of the credit card.  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.

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, TK, is used to encrypt and protect the transaction between the phone and merchant's POS. Figure 5 presents the protocol for offline certificate application. •

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 E(Data cdol1 ) to retrieve Data cdol1 by using the communication key TK. The data transferred by the merchant, E(Data cdol1 ), serial number of the transaction, ATC [1], and a random number obtained in mutual authentication, R m [45], are used to generate a message authentication code with the hash function by using the shared key, K mac emv , with the issuer: •

Message 2
The phone encrypts the OCRC, ATC, and AC that were originally to be transmitted according to the protocol using TK and sends them back to the merchant to begin the offline certificate application phase. •

Message 3
After receiving the message E TK (OCRC, ATC, AC) from the phone, the merchant decrypts OCRC, ATC, and AC by using TK. Subsequently, in addition to sending the decrypted data Data cdol1 and the R m generated in mutual authentication to the issuer, the merchant informs the issuer of the longest offline duration to be used, end_time [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 OCRC request message for offline certificate application, it uses the shared key K mac emv , Data cdol1 , ATC, and R m in the message to calculate MAC Kmac emv (Data cdol1 , ATC, R m ) and determine whether the AC code in the message sent by the merchant is correct. If the message is incorrect, the authorization response code (ARC) is set to fail. Otherwise, the ARC 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:   Figure 5. Offline certificate application and split credit line authorization protocol.

1.
Randomly generated numbers R w and R s are used to create the corresponding serial numbers SN w and SN s , and {SN w , R w } and {SN s , R s } are stored in STable.

2.
The K iss of the issuer is employed to encrypt the random and serial numbers to generate secret factors representing the credit quota w n and offline transaction merchant s 0 : 3.
The hash values of w n and s 0 are calculated and placed into the reverse hash chain set W and forward hash chain set S: 4. All authorized merchant identities ID M i are placed in the authorized merchant set M.

5.
A K β is generated that enables the issuer to authenticate the transaction message. 6.
A b is generated that represents the current user's amount spent. Because the amount has not been used at the application phase, b = 0. 7.
The issuer's SK iss is used to perform asymmetric encryption ϕ = E SK iss (w 0 ) on the last item w 0 of the credit quota hash chain for issuer endorsement. During the transaction, the merchant confirms the correctness of w 0 and calculates and verifies that the amount received is correct. 8.
Asymmetric encryption is performed using the credit card's public key PK emv , inserting the (a) shared key K β of the user and issuer; (b) secret factor w n of the limit hash chain; (c) serial number SN w of w n ; (d) s 0 , which represents the secret factor of the merchant's hash chain; (e) serial number SN s of s 0 ; (f) amount to be spent b; (g) ϕ after w 0 has been endorsed by the issuer; and (h) apart from necessary amount data, a random number R lim , which prevents the amount spent message from being resent: 9.
According to EMV standards, the end_time sent by the merchant, and the user's credit assessment, the issuer generates Cert o f f , an X.509 certificate [50]. This certificate includes the issuer (Issuer), user's credit card account (PAN), offline certificate expiration time (ET), consumption upper limit (n), and all authorized merchant identities (M).
Finally, the issuer uses K mac emv to generate a message authentication code MAC Kmac (AC⊕ARC) by using the mutually exclusive results between ARC and AC. Subsequently, this message authentication code, ARC, the E(K enc emv (Cert o f f ) encrypted by the phone's K enc emv , and Lim are sent to the merchant. •

Message 5
If the merchant receives a reply from the issuer that the ARC fails, the offline certificate application process is terminated. However, a successful ARC 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, Lim is placed in this unused parameter field. Decryption and verification are performed after the phone has received E TK (MAC Kmac emv (AC⊕ARC),ARC, Lim) and E(K enc emv (Cert o f f ):

1.
Decryption is performed using TK, and the ARC received, AC calculated at the beginning of the protocol, and K mac emv are used to calculate the message authentication code MAC Kmac emv (AC⊕ARC) to confirm that it is similar to the code received.

2.
K enc emv is employed to decrypt the offline certificate Cert o f f and inspect its source. The phone sets the inspection result ARC to fail for a failed message authentication code and offline certificate verification.

3.
If the message received is verified to match the correct Cert o f f , the certificate is placed in the Data emv list, making Data emv = Data emv ∪ Cert o f f .

4.
The SK emv of the credit card is used to decrypt the asymmetric encryption of Lim to obtain K β , w n , SN w , s 0 , SN s , b, ϕ, and R lim 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.

5.
The issuer's public key is employed to decrypt the asymmetric encrypted ϕ to obtain the w 0 generated by the issuer, and whether w 0 is equal to the w n obtained by decrypting Lim after n hash function calculations is determined. If w 0 = h n (w n ), the ARC fails; otherwise, the ARC is success, with counter = 0. 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 ARC to the merchant. If the ARC 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 Data emv , which indicates that offline transaction can commence immediately.  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.

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

Message 7
Once the phone receives the GENERATE AC command with parameter Req, TK is used to decrypt the transaction data to obtain Data cdol1 , and the user confirms that the transaction amount in Data cdol1 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 Data cdol1 , ATC, and r m using the issuer's K mac emv . AC1 = MAC Kmac emv (Data cdol1 , ATC, R m ). -R p ,Data cdol1 , ATC, the Req of AC1, AC1, and the r m for generating AC1 are calculated.
-Encryption is performed using the EMV credit card's SK emv to generate the signed dynamic application data (SDAD) from R p , Req, AC1, and the hash function h(R p , Req, AC1, R m , Data cdol1 , ATC) 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: 1.
The ID M g sent by the merchant must be present in the authorized merchant list M of Cert o f f ; if it is not, the transaction is canceled immediately. 2.
The amount spent b is employed to calculate the used hash value w b = h n−b (w n ). Moreover, the transaction amount c is used to calculate the paid hash value w b+c = h −c (w b ). 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: 3. The merchant code s v = h(s u ) is calculated. In the first purchase, u = 0 and v = 1. Each transaction generates a hash value s i representing the merchant, and the shared key is used for encryption so that the merchant is unaware of s i ; nonetheless, it does represent the merchant participating in the transaction.

4.
The amount c is spent in the transaction; thus, the amount spent becomes b = b + c.

5.
The current purchase amount c is added to counter, such that counter = counter + c.

6.
A verification message β is generated for the issuer, and the offline transaction authentication key K β , which was obtained by the secure element during the application is used to represent the merchant's identity hash value s v , serial number SN w of w n , serial number SN s of s 0 , and R l im placed in Lim during the application phase; these are symmetrically encrypted to become β = E K β (s v , SN w , SN s , R lim ).

7.
A verification message µ is generated for the merchant, and the SK emv of the credit card is employed to asymmetrically encrypt the issuer verification message β, amount after issuer endorsement ϕ, hash value of the amount spent w b , hash value of the payment amount w b+c , current amount spent c, offline transaction amount counter, and merchant's identity ID M g into µ = E SK emv (β, ϕ, w b , w b+c , c, counter, ID M g ). •

Message 8
The mobile phone encrypts Req, ATC, SDAD, µ, and β, which are returned to the merchant through the use of TK. 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 E TK (Req, ATC, SDAD, µ, β) from the mobile phone and performs two decryption and six verification actions: -TK is used to decrypt E TK (Req, ATC, SDAD, µ, β) and extract Req, ATC, SDAD, µ, and β. -PK emv is employed to decrypt µ and obtain β , ϕ , w b , w b+c , c , counter , and ID M g ', and the issuer's public key is used to decrypt ϕ to obtain w 0 : 1.
The SDAD is decrypted using PK emv , and the hash function h(R p , Req, AC1, R m , Data cdol1 , ATC) is verified.

2.
ID M g ' in µ is equal to ID M g .

3.
Whether current time meets the ET limited by the Cert o f f is checked.

4.
Whether the counter limit has not exceeded the offline transaction amount n set in the offline certificate is checked. 5.
The correctness of w b is calculated. Using w b = h −i (w 0 "), where 0 ≤ i ≤ n, it is determined whether w b and w 0 " are in the same hash chain. Whether w b+c is equal to w b after c hash function calculations is determined, and the calculation method is h c (w b+c ) = w b .  Figure 7. Offline/online transaction protocol.

Phone
The transaction is terminated immediately if any verification fails. Finally, receipt of Req = TC indicates that the transaction is an offline transaction, and the merchant requests payment from the issuer to complete the transaction. However, if Req = ARQC 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. 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.

•
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.
Whether SN w and SN s ' in β exist in STable is checked. If they do, sequence numbers SN w and SN s are used to obtain the random numbers R w and R s from the table. Subsequently, {SN w , R w }, {SN s , R s }, and the issuer's K iss are employed to perform encryption for calculating w n = E K iss (SN w , R w ) and s 0 = E K iss (SN s , R s ) to obtain the w n and s 0 applied by the user. After obtaining w n and s 0 , the issuer makes checks and verifications to determine whether the transaction amount should be issued to the merchant:

1.
It is verified that w b and w b+c are in the W hash value set generated during the application phase and the merchant representative hash value s v is in the S hash value set. 2.
Whether ID M g in µ is present in the list of authorized merchants of the offline certificate Cert o f f is determined. 3.
The preposition w b = h −i (w 0 ), where 0 ≤ i ≤ n, is considered to determine whether w b and w 0 are in the same hash chain and thus confirm their correctness. Whether w b+c equals w b after c hash function operations is determined, and its calculation method is h c (w b+c ) = w b . 4.
Whether counter exceeds the limit n is checked.

5.
It is confirmed that the R lim in β is equal to the R lim placed in Lim 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.

Security Analysis and Performance Evaluation
The security of the method proposed in this study and the performance are analyzed in this chapter.

1.
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.

2.
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 w n 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 w b = h n−b (w n ) by the user is asymmetrically encrypted using the credit card private key SK emv : µ = E SK emv (β, ϕ, w b , w b+c , c, counter, ID M g ), 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.

3.
Tampering prevention: • In the application phase, the offline transaction certificate and credit quota limit information Lim = E PK emv (K β , w n , SN w , s 0 , SN s , b, ϕ, R lim ) are encrypted using the virtual credit card's public key PK emv and the key K β 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 s 0 , the credit quota message contains cipher text encrypted using the issuer's private key.

•
If the secret factor s 0 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 SDAD in message 8 of phase 4 is encrypted using the virtual credit card's private key SK emv , 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.

4.
Replay attack prevention: • In the application phase, the issuer places a random number w n = E K iss (SN w , R w ) 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.

5.
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 SK emv to generate the signed dynamic application data (SDAD) from R p , Req, AC1, which ensure that the message is sent by the user. The user cannot deny that they have created this message.

•
The issuer verification message µ = E SK emv (β, ϕ, w b , w b+c , c, counter, ID M g ) also contains two corresponding hash values (w b and w b+c ) 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.

6.
Duplicate payment prevention: • The user cannot cheat the merchant because a counter is stored in the secure element of the mobile phone and is forced to increase upon every transaction. The value of counter 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 w b and w b+c are in the W hash value set generated during the application phase. 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.

EOPMA EPMAR Al-Tamimi Modhoun EMV-CDA EMV-DDA EMV-SDA
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.

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). {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 |≡ P S ← → Q P believes S is shared by P and Q. P |≡ P +K ← − → Q P believes Q owns the private key −K correspondent to the public key +K. P |≡ Q |∼ X P believes Q sent X. Phone P ∈ −K emv , +K emv , Kenc emv , TK The phone keeps a virtual credit card's public key, private key, The issuer knows the merchant's identity, and uses a random number for verification.  and he believes µ is generated by the phone.
Finally the two parties believe the µ is fresh M |≡ P |∼ #(β, ϕ, w b , w b+c , c, counter, ID Mg ) and is recognizable. M |≡ ∅(β, ϕ, w b , w b+c , c, counter, ID Mg ) Phase 5, payment request by merchant Both the issuer and the merchant believe µ is recognizable, I |≡ M | ∅(β, ϕ, w b , w b+c , c, counter, ID Mg ) and the issuer believes β is recognizable.
The phone believes TK is fresh.
{Cert o f f } Kencemv /*T1*/ believes µ is generated by the phone. P R lim , Cert o f f /* T3 */ Finally both of them believes the µ is fresh P ∈ R lim , Cert o f f /* P1 */ and is recognizable.

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. 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 T H , T A , T RSA E , T RSA D , T − r 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 w n (n * 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.

Phone Merchant Issuer
In the experiment, we choose n = 1..100, for the maximum of 100 offline transactions, and the maximum offline transactions per merchant, (c − b) = 10. 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.

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.

Notations Symbols Definitions
Cert publisher target Publisher signs the certificate issued to the target, and the certificate contains a public key corresponding to the target's private key. Cert o f f Required certificate for offline transactions.

PK target
Target's public key.

SK target
Target's private key.

Kenc emv
A symmetric encryption key shared between the credit card and issuer.

Kmac emv
A symmetric key shared between the credit card and issuer for calculating the message authentication code.
K β A symmetric key shared between the credit card and issuer for encrypting the offline transaction certificate message provided to the issuer. TK A communication key for the mobile phone and merchant.

K iss
A key owned by the issuer for encryption of specific serial numbers and random numbers to generate secret values for the hash function chain. E key (M) Encryption of message M by using a symmetric or asymmetric key. D key (M) Decryption of message M by using a symmetric or asymmetric key.

MAC Kmacemv (M)
In the EMV protocol, a symmetric authentication function and a key Kmac emv are used to calculate the message authentication code function of message M.

h(M)
The hash function and key are employed to calculate the message authentication code function of message M.
n The maximum credit quota during an offline transaction, which also represents the number of hash functions that can be calculated by the hash function chain of the credit quota. t Maximum number of offline transactions. m Number of merchants authorized for offline transactions.
w n The first item of the hash function chain, which can perform nth hash function calculations for the limit of offline transactions. w 0 The last item in the hash function chain for the credit quota for offline transactions.
s 0 The first item of the hash function chain, which is used to represent the secret factor of the merchant participating in the offline transaction.

s n
The nth item of the hash function chain, which is used to represent the merchant participating in the offline transaction, indicating the merchant corresponding to the nth offline transaction. i , i The plaintext i obtained after decryption using the key.

STable
The table in which the issuer places the w n and s 0 elements.

SN i
The serial number corresponding to i.

R i
The random number used for i.

R lim
The random number attached to the credit quota issuance.

Lim
The required content for offline transaction amount management and restrictions. W A set of hash values for all amounts. S A set of hash values for all corresponding merchants. M A set of all merchants authorized to complete offline transactions.

ID M
The identification name of merchant i. counter Offline transaction amount counter. ϕ The credit quota issued by the issuer. l The number of calculations of the hash function corresponding to this consumption amount. end t ime The longest offline transaction duration notified by merchants.

PAN
Primary account number, which is the user's credit card account number.

ET
Expiry time, which is the effective time taken to complete the offline transaction.