E ﬃ cient and Secure NFC Authentication for Mobile Payment Ensuring Fair Exchange Protocol

: The standard protocol of near ﬁeld communication (NFC) has concentrated primarily on the speed of communication while ignoring security properties. Message between an NFC-enabled smartphone and a point of sale are exchanged over the air (OTA), which is a message considered an authentication request for payment, billing, ticketing, loyalty services, identiﬁcation or access control. An attacker who has an antenna can intercept or manipulate the exchanged messages to take advantage of these. In order to solve this problem, many researchers have suggested authentication methods for NFC communications. However, these remain inadequate transaction security and fairness. In this paper, we will propose a technique that ensures mutual authentication, security properties, and strong fairness. Mutual authentication is a security property that prevents replay attacks and man-in-the-middle attacks. Both fair exchange and transaction security are also signiﬁcant issues in electronic transactions with regards to creating trust among the parties participating in the transaction. The suggested protocol deploys a secure o ﬄ ine session key generation technique to increase transaction security and, importantly, make our protocol lightweight while maintaining the fairness property. Our analysis suggests that our protocol is more e ﬀ ective than others regarding transaction security, fairness, and lightweight protocol. The proposed protocol checks robustness and soundness using Burrows, Abadi and Needham (BAN) logic, the Scyther tool, and automated validation of internet security protocols and applications (AVISPA) that provide formal proofs for security protocols. Furthermore, our protocol can resolve disputes in case one party misbehaves.


Introduction
Until recently, many smartphones have built-in near field communication (NFC) to allow short-range communication and small data transfers. Due to the severely short range of communications (short range is around 10 cm), NFC implementations concentrate only on the speed of communication, ignoring security properties, in particular, the authentication of the sender and the recipient [1][2][3][4]. Many techniques have been proposed to offer authentication of transactions through NFC [5][6][7][8][9].
El Madhoun et al. [5] proposed a secure authentication protocol for contactless-NFC payment based on a Cloud infrastructure to solve security vulnerabilities detected in the Europay Mastercard Visa (EMV) protocols. Asymmetric encryption is used to provide mutual authentication (with non-repudiation) between a near field communication (NFC) smartphone and an NFC point of sale terminal. Symmetric encryption is utilized the confidentiality of bank data in the authentication steps. This proposed protocol uses the Scyther tool to verify security protocols.
Badra et al. [6] suggested identifying threats and vulnerabilities of the air interface between NFC-enabled devices and the point of sale system, and a solution to secure NFC-based payment transactions with mobile phones. The proposed method gives lightweight (using symmetric cryptography), simple, scalable, cost-effective, and incurs minimal computational processing overheads.

Backgrounds
NFC [1,2] is a short-range wireless communication technology that is operating at 13.56 MHz. It can quickly send data rate links of 106, 212 and 424 Kbps inside a range of 10 cm. NFC equipment can execute a speedy pairing with various other devices, consumes little power and transmits small amounts of data. NFC is comprised of three operating modes. In the card emulation mode, NFC works as a radio frequency identification (RFID) tag installed in portable hardware. It can be operated as a contactless card according to ISO14443 and FeliCa. In the reader/writer mode, NFC can run as an NFC reader and writer. In the NFC-enabled peer-to-peer (P2P) mode, the system can communicate directly with each other, sharing data.
NFC is designed primarily on the speed of communication. Consequently, NFC lacks the encryption of data between two devices at the hardware level. Many researchers have discussed the weaknesses of NFC, which one of the essential security services is authentication, which protects against replay attack and man-in-the-middle attack (MITM).
Many security threats include [3,4] an eavesdropping type of attack, where communication between two NFC devices can be intercepted and read data by using the large antenna as NFC does not possess any countermeasures against eavesdropping. Data manipulation: an attacker intercepts and alters data throughout the communication, which can be separated into three different types: data alteration, data insertion, and data destruction. Relay attack: a relay attack is widely understood as man in the middle attack (MITM), which implementations focus on ISO 14443 and ISO18092 systems on network security. Data transmitted between two NFC devices can be intercepted by an attacker who both reads and records or manipulates the data before sending it to the receiving device.
To overcome the limitations of existing protocols [5][6][7][8][9], we will propose a new protocol that ensures mutual authentication, security properties, and fairness. In our proposed protocol, using a secure offline session key generation technique is to be employed. This can enhance transaction security and make the protocol lightweight while maintaining strong fairness. Our analysis demonstrates that our protocol is more efficient than others' regarding security, fairness and lightweight protocol.

The Proposed Protocol
In this study, we suggest an authentication protocol for NFC communications in order to untangle the issues and to overcome restrictions such as authentication and the fairness of current protocols [5][6][7][8][9] by applying [10][11][12] model to complete the fairness protocol. In [12], the suggested mobile payment protocol based on an NFC communication. The protocol possesses comprehensive properties of both fair exchange and transaction security, such as confidentiality of transactions, integrity of transactions, authentication of transactions, Non-repudiation of transactions, and resistance to attacks like double-spending, man-in-the-middle, replay attacks. This protocol uses cryptography algorithms such as symmetric, asymmetric and hash function, and the technique of offline session key generation is used to enhance security of the protocol. Fairness property of this protocol can resolve any dispute in case one party misbehaves. Burrows, Abadi and Needham (BAN logic) and the Scyther tool are utilized to verify security of the protocol.
Our protocol is based on symmetric key encryption, using a secure session key distribution to improve the protocol [13]. Many session key generation techniques have been suggested [14,15]. One technique was suggested by [13], which is not only secured key compromise attacks but can also operate purely offline. The engaged parties perform their tasks that do not need to send session keys throughout the network. The technique was chosen to secure session key generation technique our protocol. There are four phases of the proposed protocol comprised of initiation phase, registration phase, authentication phase, and dispute resolution phase. Table 1, shown below, demonstrates the details of notations that are used in the proposed protocol.

Initiation Phase
In this phase, the goal is to exchange key distribution parameters between parties-P, S, TP and V. The details of the initiation phase are shown as follows: P and S exchange {K P-S , DK P-S , m P-S } through the secure channel such as transport layer security (TLS). Both P and S can create a set of session keys, SK P-Sj , where j = 1, . . . , m P-S , by using the session key creation technique described in [13]. P and trusted third party (TP) exchange {K P-TP , DK P-TP , m P-TP } through a secure channel such as TLS. Both P and TP can create a set of session keys SK P-TPj , where j = 1, . . . , m P-TP , by using the session key creation technique described in [13]. P and V exchange {K P-V , DK P-V , m P-V } through a secure channel such as TLS. Both P and V can create a set of session keys SK P-Vj , where j = 1, . . . , m P-V , by using the session key creation technique described in [13].
S and TP exchange {K S-TP , DK S-TP , m S-TP } through a secure channel such as TLS. Both S and TP can create a set of session keys, SK S-TPj , where j = 1, . . . , m S-TP , by using the session key creation technique described in [13].
S and V exchange {K S-V , DK S-V , m S-V } through a secure channel such as TLS. Both S and V can create a set of session keys, SK S-Vj , where j = 1, . . . , m S-V , by using the session key creation technique described in [13].
TP and V exchange {K TP-V , DK TP-V , m TP-V } through a secure channel such as TLS. Both TP and V can create a set of session keys, SK TP-Vj , where j = 1, . . . , m TP-V , by using the session key creation technique described in [13]. A trusted third party. TP by itself is not involved in the transaction but helps to keep a record of all transactions that have taken place for each engaged party for future verification. Note that TP is a semi-TP. Semi-TP may misbehave on its own. However, it will not collide with any of the participating parties.

V
The external party is a party that is not relevant to the particular transaction The key distribution parameters that are shared between the parties, where K A-B is a long-term key, DK A-B is a distributed key and m A-B is a random number. m A-B is used to specify the number of keys that will be generated. Request A message is considered a request message like payment, billing, ticketing, loyalty services, identification or access control, and so on.

Response
A message is considered a response message like payment, billing, ticketing, loyalty services, identification or access control, and so on.
The timestamp is given when authentication is requested.
The timestamp is given when a feedback message is provided.

Registration Phase
In this phase, each smartphone user needs to install an application dependent on the proposed protocol. At the point when the application has been completely installed, the user needs to perform registration through a secure channel such as TLS. The object of registration is to exchange {K N-S , DK N-S , m N-S }, {K N-P , DK N-P , m N-P }, {K N-TP , DK N-TP , m N-TP }, and {K N-V , DK N-V , m N-V } between the N and S, between N and P, between N and TP, and between N and V through the secure channel such as TLS. The details of the registration phase are shown as follows: Both N and S can create a set of session keys, SK N-Sj , where j = 1, . . . , m N-S , by using the session key creation technique described in [13].
Both N and P can create a set of session keys, SK N-Pj , where j = 1, . . . , m N-P , by using the session key creation technique described in [15]. Both N and TP can create a set of session keys, SK N-TPj , where j = 1, . . . , m N-TP , by using the session key creation technique described in [13].
Both N and V can create a set of session keys, SK N-Vj , where j = 1, . . . , m N-V , by using the session key creation technique described in [13].

Authentication Phase
In this phase, the proposed protocol provides authentication between N and P, between N and S through P, and between P and S. Note that P communicates with an NFC reader through a

Registration Phase
In this phase, each smartphone user needs to install an application dependent on the proposed protocol. At the point when the application has been completely installed, the user needs to perform registration through a secure channel such as TLS. The object of registration is to exchange {KN-S, DKN-S, mN-S}, {KN-P, DKN-P, mN-P}, {KN-TP, DKN-TP, mN-TP}, and {KN-V, DKN-V, mN-V} between the N and S, between N and P, between N and TP, and between N and V through the secure channel such as TLS. The details of the registration phase are shown as follows: Both N and S can create a set of session keys, SKN-Sj, where j = 1, …, mN-S, by using the session key creation technique described in [13].
Both N and P can create a set of session keys, SKN-Pj, where j = 1, …, mN-P, by using the session key creation technique described in [15]. Both N and TP can create a set of session keys, SKN-TPj, where j = 1, …, mN-TP, by using the session key creation technique described in [13].
Both N and V can create a set of session keys, SKN-Vj, where j = 1, …, mN-V, by using the session key creation technique described in [13].

Authentication Phase
In this phase, the proposed protocol provides authentication between N and P, between N and S through P, and between P and S. Note that P communicates with an NFC reader through a secure channel. From Figure 1 displays the transaction flow of authentication protocol of all parties, including N, P, S and TP.  N sends an authentication request message M1 to P which contains the following: h(ID N , T 1 , Request, SK N-Sj ): the hash value is considered as a message authentication code (MAC), which is an authentication token between N and S, which will be transmitted to S through P, and ensures the integrity of the message. This message P cannot generate since P does not know the session key SK N-Sj . Hence, only N constructs this message. h(ID N , T 1 , Request, h(ID N , T 1 , Request, SK N-Sj ), {h N-TP } SKN-TPj , SK N-Pj ): the hash value is considered as a MAC, which is an authentication token between N and P, and ensures the integrity of the message. Moreover, this message P uses to verify the authenticity of N. N cannot deny that it did not originate this message as the possession of both SK N-Sj and SK N-Pj . {h N-TP } SKN-TPj : the message encrypted with the session key SK N-TPj shared between N and TP, which will be transmitted to TP through S. This message P cannot generate because P does not know the session key SK N-TPj . Therefore, N is original of this message. Note that T 1 is generated by N to prevent replay attack.
On receiving message M1 from N, P will verify the authentication request message h(IDN, T1, request, h(ID N , T 1 , request, SK N-Sj ), {h N-TP } SKN-TPj , SK N-Pj ) of N, if the message is invalid, P rejects N's request. If not, P forwards N's authentication request to S in the message M2. P sends message M2 to S. It contains the following: h(ID P , h(ID N , T 1 , request, SK N-Sj ), SK P-Sj ): the hash value is considered as a MAC, which is an authentication token between P and S, and ensures the integrity of the message. Besides, this message S uses to verify the authenticity of P. {h P-TP } SKP-TPj : the message encrypted with the session key SK P-TPj shared between P and TP which will be transmitted to TP through S. This message S cannot generate because S does not know the session key SK P-TPj . Therefore, P is original of this message.
On receiving the message M2 from P, S will check the correctness of the authentication request message h(ID P , h(ID N , T 1 , request, SK N-Sj ), SK P-Sj ) of P, if the message is invalid, S rejects P's request. If not, S will check the correctness of authentication request message h(ID N , T 1 , request, SK N-Sj ) of N.
If the message is successful, S sends response message back to N and P. Otherwise, S rejects P's request. Then, S sends the message M3 to TP.
On receiving message M3 from S, TP will process three things: TP decrypts the message {h N-TP } SKN-TPj using SK N-TPj keeps the hash value, decrypts the message {h P-TP } SKP-Sj using SK P-TPj , keeps the hash value, decrypts the message {h S-TP } SKS-TPj using SK S-TPj keeps the hash value. Next, TP encrypts three hash values, encrypts the hash value of h N-TP , h P-TP , h S-TP using SK N-TPj+1 . Encrypts the hash value of h N-TP , h P-TP , h S-TP using SK P-TPj+1 . Encrypts the hash value of h N-TP , h P-TP , h S-TP using SK S-TPj+1 . Then, TP sends messages M4 to S.
On receiving the message M4 from TP, S decrypts the message {h(h N-TP , h P-TP , h S-TP )} SKS-TPj+1 with SK S-TPj+1 and keeps the hash value as proof if a dispute arises. Then, S sends messages M5 to P. The message M5 contains the following: h(T 1 , T 2 , response, SK N-Sj+1 ): the hash value is considered as a message as MAC, which is an authentication token between N and S which will be transmitted to N through P, and ensures the integrity of the message. This message P will not generate since P does not know the session key SK N-Sj+1 . Hence, only S constructs this message. h(h(T 1 , T 2 , response, SK N-Sj+1 ), SK P-Sj+1 ): the hash value is considered as MAC, which is an authentication token between P and S, and ensures the integrity of the message. Moreover, the message P uses to verify the authenticity of S. S cannot deny that it did not originate this message as the possession of both SK N-Sj+1 and SK P-Sj+1 . {h(h N-TP , h P-TP , h S-TP )} SKN-TPj+1 : this message will forward to N via P. {h(h N-TP , h P-TP , hS -TP )} SKP-TPj+1 : this message will send to P.
On receiving the message M5 from S, P will verify the authentication response message h(h(T 1 , T 2 , response, SK N-Sj+1 ), SK P-Sj+1 ) of S, if the message is invalid, P rejects S's response. Unless, P decrypts the message {h(h N-TP , h P-TP , h S-TP )} SKP-TPj+1 and keeps the hash value as proof if a dispute arises. Then, P sends the message M6 to N.
On receiving the message M6 from P, N will verify the authentication result message h(h(T 1 , T 2 , response, SK N-Sj+1 ), {h(h N-TP , h P-TP , h S-TP )} SKN-TPj+1 , SK N-Pj+1 ) of P, if the message is invalid, N rejects P's response. Unless, N will verify the authentication result message h(T 1 , T 2 , Yes/No, SK N-Sj+1 ) of S, if the message is invalid, N rejects P's response. If not, N decrypts the message {h(h N-TP , h P-TP , h S-TP )} SKN-TPj+1 with SK N-TPj+1 and keeps the hash as proof if a dispute arises. Note that T 2 is generated by S to prevent a replay attack.
It can be seen that N with S via P can provide mutual authentication for all engaged parties. Each message in this protocol can be used to identify the sender and the recipient of the message. Thus, our protocol ensures mutual authentication for N, P, and S. This protocol contains only symmetric cryptographic operations, MAC and a hash function, which leads to lightweight operations. Therefore, it is appropriate for NFC communications. Additionally, using a secure offline session key generation technique will enhance the security of the protocol.

Dispute Resolution Phase
There are two sub-phases: N requests dispute, and P requests dispute. After the transaction is complete, if N or P is not satisfied with the transaction, N or P can request a dispute resolution to V, the dispute resolution protocol. Consider the protocols below: N sends the hash value h(hN-TP, hP-TP, hS-TP) of the transaction to V. Upon receiving the hash value of N, V sends the requested hash value of the TP. After receiving the hash value from the TP, V compares the hash value of N with the hash value from the TP. If the hash values do not match, V rejects N's request; if not, V sends a notification of dispute resolution to P and S. From Figure 2 shows transaction flow of N request dispute protocol of all parties including N, P, S, V and TP. The details of this protocol are outlined below.

Message Confidentiality
Our protocol satisfies the confidentiality problem by using symmetric key encryption to messages in each step of protocol to assure that only intended receiver can decrypt message sent to them.

Message Confidentiality
Our protocol satisfies the confidentiality problem by using symmetric key encryption to messages in each step of protocol to assure that only intended receiver can decrypt message sent to them.

Message Integrity
It can be seen that, in the proposed protocol, each message contains MAC. It is ensured by applying MAC that an attacker will not be able to alter or modify the message without being detected by the receiver.

Mutual Authentication
Each message in the protocol can be used to identify the sender and the receiver of the message, therefore ensuring authentication to N, P, and S. Our protocol be composed of symmetric cryptographic method, hash function, and Message Authentication Code (MAC) only. Moreover, with using the technique of offline session key generation and distribution. Only the sender and the receiver who share the same key will be able to encrypt and decrypt messages. It can be seen that, in the message M1, although N and P share the session key SK N-Pj , P cannot generate this message h(ID N , T 1 , request, SK N-Sj ) by itself. This is because P cannot generate h(ID N , T 1 , request, SK N-Sj ) as the session key SK N-Sj is shared between N and S. Only N knows both SK N-Sj and SK N-Pj . Hence this guarantees that N generated this message h(ID N , T 1 , request, h(ID N , T 1 , request, SK N-Sj ), {h N-TP } SKN-TPj , SK N-Pj ).

Non-Repudiation of Transactions
The proposed protocol uses symmetric encryption to encrypt message. It can satisfy the non-repudiation property by keeping evidence from each message that each party performed in each transaction. To show that our protocol satisfies the non-repudiation of transactions. In the message M1, it can be seen that N and P share the session key SK N-Pj , but P cannot generate this message h(ID N , T 1 , Request, SK N-Sj ) by itself because the session key SK N-Sj is shared between N and S. Only N knows both SK N-Sj and SK N-PSj , hence N cannot refuse that it did not originate this message as the possession of SK N-Pj demonstrates clearly that only N can generate this message h(ID N , T 1 , request, h(ID N , T 1 , request, SK N-Sj ), {h N-TP } SKN-TPj, SK N-Pj ).

Brute Force Attack Prevention
The suggested protocol changes session keys every time at the completion of the transaction. It is hard to discover the correct session key. In addition, the technique of offline key generation and distribution is utilized in our protocol to resistance to brute force attacks.

Replay Attack Prevention
A replay attack is one in which an attacker obtains a copy of an authenticated message and later transmits it to the intended destination. Our proposed protocol use timestamps and limited-use session keys preventing replay attacks as the session keys used in this protocol are used only once.

MITM Attack
A MITM attack can be prevented with the combination of symmetric-key cryptographic operations including hash function. No confidential information is exposed, the reuse of authentication information is limited, and our protocol provides mutual authentication that can identify both its sender and recipient.

Eavesdropping
An attacker uses a suitable antenna and close enough in order to receive transferred information, such as credit card numbers, or manipulate payment information. Eavesdropping can be avoided by establishing a secure channel between two NFC devices, our proposed protocol can avoid eavesdropping by applying symmetric cryptography, including the hash function of messages in each step.

Data Manipulation
An attacker intercepts and alters data throughout the communication. This attack cannot occur successfully because the proposed protocol uses symmetric cryptography, including the hash function in all steps.

Practicality of the Proposed Protocol
In this segment, we will compare the proposed protocol with previous protocols in [5][6][7][8][9] regarding performance, including fairness, security properties, cryptographic operations cost, energy consumption, time consumption, communication cost, and storage cost. Table 2 displays a comparison of the fairness of NFC authentication protocols. We proposed a comparison between the NFC authentication protocols in [5][6][7][8][9] and our protocol. Regarding the model outlined in [10][11][12], the protocols proposed in [5,[7][8][9] have no fairness because the trusted third party is not involved. In addition, the protocols proposed in [5,[7][8][9] cannot resolve disputes in case one party misbehave because they do not contain the resolve disputes phase. The proposed protocol in [6] is weak in terms of fairness according to the model delineated in [10][11][12] as [6] cannot resolve conflicts in case one party misbehave because they do not contain the resolve dispute phase. It can be seen that the proposed protocol satisfies strong fairness according to the model suggested in [10][11][12].  Table 3 exhibits a comparison of the security properties of the protocols found in [5][6][7][8][9] with our protocol. It is clear that our protocol and [8] satisfy the necessary security properties and resistance to attacks, which are message confidentiality, message integrity, mutual authentication, non-repudiation of transactions, brute force attack prevention, replay attack prevention, MITM attacks, eavesdropping, and data manipulation.

Performance Analysis
From Table 4, Figures 4-6 demonstrate comparisons of cryptographic operations, energy consumption and time consumption between our protocol and the other protocols in [5][6][7][8][9]. The proposed protocol in [5,6,8,9] uses more energy consumption than our protocol. Our protocol uses more energy consumption than the protocol in [7]. Nevertheless, the protocol in [7] still lacks security property and strong fairness. The offered protocol in [5,8,9] takes more time consumption than our protocol. Our protocol takes more time consumption than the protocols in [6,7]. However, the protocol in [6,7] still lacks security properties and strong fairness. Note that time consumption is derived from [16], which is proposed in [10,12]. Energy consumption is derived from [17], which is recommended in [18,19]. Table 5 demonstrates symbols, abbreviations and with their sizes in order to calculate communication cost, and storage cost of our protocol with previous protocols in [5][6][7][8][9]. In communication cost, Table 6 and Figure 7 show comparisons of communication cost between the previous protocols in [5][6][7][8][9] and the proposed protocol. It can be seen that the proposed protocol has a lower communication cost than the existing protocols in [5,9]. Nonetheless, the proposed protocol has a higher communication cost than the protocols in [6-8] but these protocols not satisfied security properties and strong fairness. In storage cost, Table 7 and Figure 8 represent comparisons of storage cost between the proposed protocol and the previous protocols in [5][6][7][8][9]. It is clear that the existing protocols in [5,8,9] have a higher storage cost than our proposed protocol. However, the existing protocols in [6,7] have a lower communication cost than the proposed protocols, but protocols in [6,7] cannot provide security properties and strong fairness. Table 3. Comparison of security properties.

Using Scyther
The Scyther tool is a formal proof for security protocols. It is an automated security protocol analysis tool based on the security protocol description language (SPDL) [20,21]. Many researchers have now utilized the Scyther tool to validate security protocols; see [22,23]. Our protocol is verified using the "verification claim" scheme in the Scyther tool. It can be seen that status (OK) for all the claims are utilized to verify the security properties and no attacks are discovered within bounds. It shown in Figure 9.

Using AVISPA
The automated validation of internet security protocols and applications (AVISPA) tool is a formal verification tool for network security protocols. AVISPA is developed by [24] and can be found in [25,26] used for verifying network security protocols. We simulate and check the proposed protocol under both, on-the-fly model-checker (OFMC) and constraint logic-based attack searcher (CL-ATSE) back-ends. It can be seen that simulation reports of OFMC and CL-ATSE reports of our protocol in AVISPA is safe, as shown in Figure 10.

Using Scyther
The Scyther tool is a formal proof for security protocols. It is an automated security protocol analysis tool based on the security protocol description language (SPDL) [20,21]. Many researchers have now utilized the Scyther tool to validate security protocols; see [22,23]. Our protocol is verified using the "verification claim" scheme in the Scyther tool. It can be seen that status (OK) for all the claims are utilized to verify the security properties and no attacks are discovered within bounds. It shown in Figure 9.

Using AVISPA
The automated validation of internet security protocols and applications (AVISPA) tool is a formal verification tool for network security protocols. AVISPA is developed by [24] and can be found in [25,26] used for verifying network security protocols. We simulate and check the proposed protocol under both, on-the-fly model-checker (OFMC) and constraint logic-based attack searcher (CL-ATSE) back-ends. It can be seen that simulation reports of OFMC and CL-ATSE reports of our protocol in AVISPA is safe, as shown in Figure 10.

Using BAN
In this fragment, The BAN logic [27] is a well-known formal model, which is used to examine the security of mutual authentication using the widely-accepted works [28,29]. The notations used in BAN logic [27] are defined in Table 8.

Using BAN
In this fragment, The BAN logic [27] is a well-known formal model, which is used to examine the security of mutual authentication using the widely-accepted works [28,29]. The notations used in BAN logic [27] are defined in Table 8.

Symbol Definitions
X, Y Statement P, Q Parties P|≡X P believes in X P X P sees X P|~X P once said X P|⇒X P has the jurisdiction over X #(X) The formula X is fresh P X ↔Q P and Q may use the shared key K to communicate P X

⇔Q
The formula Y is a secret known only to P and Q {X} K The formula X is encrypted under the key K (X) K The hash value of X using K as a key Moreover, the proposed protocols use six rules of BAN logic to prove a security protocol: We analyze mutual authentication using BAN logic to show that our protocol guarantee a secure mutual authentication of all parties. All established goals are successfully proven in the proposed protocol. Thus, it can be concluded that every party has satisfied a secure mutual authentication.

Conclusions
In this paper, we introduced a protocol that ensures mutual authentication for NFC mobile payment to all engaged parties using lightweight cryptographic operations for running on mobile devices. The proposed protocol satisfies the necessary transaction security and strong fairness for NFC communications, which are significant issues in mobile payment transactions regarding creating trust among the parties participating in the transaction. We have demonstrated that our proposed protocol is more effective compared to existing protocols regarding transaction security, fairness, and lightweight protocol. In case that one party misbehaves, the proposed protocol can resolve disputes. Furthermore, the robustness and soundness of the proposed protocol is ensured through use of BAN logic, the Scyther tool, and AVISPA to verify the security protocol.