Fully Authentication Services Scheme for NFC Mobile Payment Systems

One commonly used wireless communication technology is Near-Field Communication (NFC). Smartphones that support this technology are used in contactless payment systems as identification devices to emulate credit cards. This technology has essentially focused on the quality of communication services and has somewhat disregarded security services. Communication messages between smartphones, the point of sale (POS), and service providers are susceptible to attack due to existing weaknesses, including that an adversary can access, block and modify the transmitted messages to achieve illegal goals. Therefore, there have been many research proposals in regards to authentication schemes for NFC communications in order to prevent various types of attacks. However, the proposed schemes remain inadequate to secure payment transactions in such systems. In this paper, we propose a fully authentication services scheme for NFC mobile payment systems in order to support a high security level. The proposed scheme has security services, such as a full authentication process, perfect forward secrecy, and simultaneous anonymity of the smartphone and POS. These security services have been validated using the BAN logic model and an automatic cryptographic protocol verifier (ProVerif) tool. A security analysis has clarified that the proposed scheme can prevent various types attacks. A comparison with recent authentication schemes demonstrates that the proposed scheme has an appropriate cost in different sides such as computation, communication and storage space. Therefore, the proposed scheme not only has appealing security features, but can also clearly be utilized in mobile payment systems.


Introduction
Near-Field Communication (NFC) is a wireless technology used to facilitate and speed up data transfer with a short range of within ten centimeters and 106-424 Kbps [1][2][3]. This technology has been developed based on radio frequency identification (RFID) technology [4][5][6][7]. One of the widely used systems developed based on NFC technology is the contactless payment system using a smartphone-called the mobile payment system [8][9][10][11][12][13]. Therefore, the world's largest smartphone and point of sale (POS) manufacturers have recently become supportive of NFC technology in all their productions, which are called NFC mobile and NFC POS, respectively.
In the mobile payment system, the process of payment can be summarized into the following steps [14][15][16][17][18]: the user places his/her NFC mobile within the range of the intended NFC POS in order to transmit the payment transaction request message; the NFC POS retransmits the transaction to the authentication center (AuC) of the payment serving provider (PSP); the AuC validates the POS NFC and NFC mobile; the AuC sends the transaction payment response message to the NFC POS; the NFC mobile is validated by the NFC POS; and the NFC mobile receives the transaction payment response message from the NFC POS. Upon receiving the response message, the NFC POS is then validated by the NFC mobile in order to complete the transaction.
NFC technology has essentially focused on the quality of communication services, and has somewhat disregarded security services. Additionally, all the messages from the transaction payment process between the NFC mobile, NFC POS, and AuC are susceptible to attack due to existing weaknesses [15,[19][20][21][22][23][24][25][26][27]]. An unauthorized party could access the transaction messages in order to collect secret data from the user's bank account. An unauthorized party could also block the transaction in order to prevent the delivery of payment services. In the same context, an unauthorized party could change the transaction messages in order to forward the incorrect payment transaction order.
Numerous types of attacks have recently been found that could exploit existing weaknesses, such as desynchronization, impersonation, stolen verifier table, replay, tracking, insider, spoofing, man-in-themiddle, and password guessing attacks [28][29][30][31]. Therefore, mobile payment systems require significant improvement in order to support appropriate security services, while at the same time being reasonable for use.
The authentication scheme is considered to be an optimal solution to improve such a system; researchers of mobile payment systems have recently proposed several authentication schemes. In 2012, Ceipidor et al. [32] proposed a scheme for a mutual authentication between NFC phones and NFC POS terminals for secure payment transactions. This protocol was based on the asymmetric method in order to conduct mutual authentication among NFC devices. Despite this, the protocol fulfilled security services such as confidentiality and mutual authentication, but it is susceptible to desynchronization attacks and cannot resist brute force attacks [14]. In 2015, Thammarat et al. [33] proposed a secure, lightweight protocol for NFC communications with mutual authentication, based on the limited-use of session keys. They claimed that their protocol could achieve some security aspects such as the forward/backward secrecy service, NFC mobile anonymity, and could defeat desynchronization attacks [14,15]. In 2017, Tung et al. [34] proposed a secure mutual authentication scheme for NFC mobile devices based on a set of hash functions. In this protocol, mutual authentication was partially satisfied, forward/backward secrecy was not achieved, it lacked anonymity in security services, and it could not defeat tracking attacks. In 2017, Nashwan [15] proposed the secure authentication protocol for NFC mobile payment systems. This protocol aimed to identify most of the security problems in Near-Field Communication (NFC) in order to achieve the highest levels of security. However, this protocol cannot fully support security services such as anonymity and the forward/backward secrecy services. In 2019, Abouhogail et al. [1] proposed an advanced authentication protocol for mobile applications using NFC technology in order to satisfy mutual authentication and to resist denial of services attacks. However, this protocol cannot support anonymity, forward/backward secrecy services or prevent desynchronization attacks. Therefore, in this paper, we proposed an authentication scheme for NFC mobile payment systems in order to resolve security problems that were observed above. The major contributions of this paper can be summarized as follows: the proposed authentication scheme for mobile payment systems is discussed; security verification using Burrows et al. [35] logic and an automatic cryptographic protocol verifier (ProVerif) tool [36][37][38] is used to verify the security services; comparative security analysis shows how the proposed scheme can fully support mutual authentication, full perfect forward security and full anonymity services and can resist all types of attacks; and a comparative performance analysis shows the proposed scheme's applicability. This paper prepared as follows. In Section 2, we present our proposed authentication scheme. Security validation using BAN logic model and a ProVerif tool to verify the security features is performed in Section 3A. Comparative security analysis with recent authentication schemes for NFC mobile payment system is discussed in Section 4A. Performance analysis is presented in Section 5. Finally, a conclusion is given in Section 6.

Proposed Authentication Scheme
The proposed scheme consists of three entities: the NFC mobile, NFC POS and AuC. This scheme uses a set of pseudonym identities, symmetric cryptography functions and hash functions to securely exchange the authentication messages. The main notation of the proposed scheme is listed in Tab. 1.

Phases of the Proposed Scheme
This section describes our proposed authentication scheme, which contains seven phases, namely, the NFC mobile registration phase, NFC POS registration phase, mobile log-in authentication phase, POS log-in authentication phase, authentication phase, user password change phase, and NFC POS password change phase.

NFC Mobile Registration Phase
Step 1: As shown in Fig. 1, the user of the NFC mobile device (Xi) inserts the credit identity number (IDi), selects password (PWi), and inputs the credit card code (Si) to the Xi according to the PSP specifications. Then, Xi generates ri, computes the Ci = h (ri ‖ PWi ‖ Si), and transmits a registration request message {M1: IDi and Ci} to AuC via a private channel. Step 3: Upon receiving {M1} from AuC, Xi stores [XIDi, XCi, Fi, and V] values with ri.

NFC POS Registration Phase
Step 1: As shown in Fig. 2, the owner of the NFC POS device (Yj) inserts its POS identity number (IDj), selects the password (PWj), and inputs the POS secret code (Sj) according to the PSP specifications, The Yi generates rj, computes Cj = h (rj ‖ PWj ‖ Sj), and transmits a registration request message {M1: IDj and Cj} to AuC through a private channel.
Step 2: In response to the Yj demand, the AuC node validates the presence of the (IDj) in the POS's table, which includes the data from all the POS deceives that have already been registered. If it exists, the AuC then refuses the registration request message {M1} and requests the Yi to re-enter a correct (IDj). Otherwise, the AuC generates three random numbers (r4, r5, and r6), then sets YCj = r4, YIDj = YIDj0 = r5, YIDj1 = ф. After that, the AuC computes Kj = h (IDj ‖ y ‖ r6), Fj = Kj È Cj and H = h (Kj ‖ Cj). Then, the AuC updates the POS's table to save [r6, YCj, IDj, YIDj0, YIDj1] authentication parameters and sends the registration response message {M2} to Yj, which includes [YIDj, YCj, Fj, and H].
Step 3: Upon receiving {M2} from AuC, Yj stores [YIDj, Cj, Fj, and H] values with rj. Fig. 3 illustrates the mobile log-in authentication phase. When a user wants to put his/her NFC mobile (Xi) near the NFC POS in order to send the payment transaction request message, Xi needs to authenticate the user. The process of authentication can be described between the user and his/her Xi device as follows. Step 1: The user inserts PWi and Si into the payment application. The Xi fetches ri, computes Ci = h (ri ‖ PWi ‖ Si), then finds Ki = Fi È Ci and V' = h (Ki ‖ Ci)).

Mobile Log-in Authentication Phase
Step 2: The Xi verifies the authentication request by comparing the values of the computed (V') and the stored V. If they are not equivalent, Xi finishes the authentication. Otherwise, Xi approves that the user is legitimate. Fig. 4 illustrates the POS log-in authentication phase: when the seller wants to activate his/her NFC POS (Yj) to receive the user payment request message, the Yj needs to authenticate the seller. The process of authentication can be described between the seller and his/her Yj device as follows.

POS Log-in Authentication Phase
Step 1: The seller inserts PWj and Sj into the POS device (Yj). The Yj fetches rj, computes Cj = h (rj ‖ PWj ‖ Sj), and finds the Kj = Fj È Cj and H' = h(Kj ‖ Cj).  Step 2: The Yj verifies the authentication request by comparing the values of the computed (H') and the stored value H. If they are not equivalent, Yj finishes the authentication. Otherwise, Yj approves that the seller is legitimate.

Authentication Phase
Figs. 5a-5c illustrate the authentication phase. The NFC mobile (Xi) can execute the payment transaction through a specific NFC POS device (Yj) by achieving mutual authentication with the AuC and Yj. It should be noted that this phase is executed after both the log-in authentication phases of the Xi and Yj have been completed. Thus, the following steps summarize the authentication process. Step 1: When the Xi is placed near the Yj, the Xi generates a random number r7, then computes EKi = h (XIDi ‖ Ki ‖ XCi), CTi1 = EEKi (r7 ‖ Ti0), and V1 = h (r7 ‖ Ki ‖ XIDi ‖ XCi ‖ Ti0), where Ti0 is the timestamp from the user side. Finally, Xi transmits the authentication request message M1 = {Mi1: XIDi, CTi1, V1} to Yj through an NFC communication channel (public channel).
Step 3: As shown in Fig. 5b, after receiving the (M2), AuC first searches its user's table to find a pair of the (XIDi0 and XIDi1) according to the XIDi value that has been received through (M1), then operates as follows in order to authenticate the Xi.
If XIDi = XIDi0, it means that both identities have been updated by Xi and AuC in the prior authentication session. Then, AuC wants to validate whether the hash value of (XCi) is updated or not. Therefore, the AuC checks whether XIDi1 = ф.

End if
Step 4: According to Fig. 5c, as in the previous step, AuC determines Yj's identity. The AuC searches its POS's table to find a pair of (YIDj0 and YIDj1), according to the YIDj value, that has been received though (Mj1), and then executes the following steps to authenticate the Yj: If YIDj = YIDj0, it means that both the Yj's identities have been updated by Yj and AuC in the prior session. Then, AuC wants to validate whether the hash value of (YCj) is updated or not. Therefore, the AuC checks whether YIDj1 = ф.

End if
It should be noted that, after this step, both the NFC mobile and NFC POS are considered to be either legitimate parties or not for the AuC to complete the authentication process.

User Password Change Phase
Step 1: The user inserts PWi and Si to the NFC mobile (Xi). Then, Xi fetches the stored ri, computes Ci = h (ri ‖ PWi ‖ Si), finds the Ki = Fi È Ci, and V' = h (Ki ‖ Ci)), then verifies whether the computed (V') and the stored (V) are equivalent. If not, Xi cannot authenticate the user, and rejects the request of the password change. Otherwise, the user inserts an updated password PWi*.
Step 2: Xi computes Ci* = h (ri ‖ PWi* ‖ Si), Fi* = Ki È Ci È Ci* and V* = h (Ki ‖ Ci*) Step 3: Finally, Xi replaces computed Fi* and V* with Fi and V, respectively. Fig. 7 illustrates the NFC POS password change phase, where a seller of Yj needs to change the password. Therefore, he/she requires to execute the following steps:

Formal Security Verification
We can observe from the above description that the phases of the proposed scheme are either not used frequently or are executed through a secure communication channel, except for the authentication phase. Therefore, we will concentrate on the soundness of the authentication phase by verifying it based on the BAN logic model and a ProVerif tool in the following subsections.

Security Verification Using BAN Logic
In this section, we apply the BAN logic model [16,35] to examine the freshness and originality of the authentication messages exchanged between the NFC mobile, NFC POS and AuC in the authentication phase. To apply the BAN logic model, the basic notation and believing rules that we will used are listed in the Tabs. 2 and 3, respectively.
Therefore, the main goals of the authentication phase have been successfully proven and mutual authentication can be granted between the Xi, Yj and AuC throughout this phase.

Security Verification Using ProVerif Tool
In this section, we validate our authentication scheme in terms of achieving mutual authentication and secure authentication sessions using one of the common automated verifier tools, called the ProVerif tool [16,35]. This tool is used to verify the main security features of the cryptographic protocol, such as authentication, secrecy, anonymity by supporting numerous cryptographic techniques, including symmetric/asymmetric cryptography, hash functions, and digital signatures. Besides this, the ProVerif tool assumes that the adversary can modify, eavesdrop, and delete the communication messages that are exchanged between the authentication nodes. Thus, if the proof is true, as a result of the verification process, then all possible attacks are checked and the communication messages are in a safe state. Otherwise, traces of attacks are provided.
As to verify the security of our authentication scheme, we defined a set of premises for our verification code statements, as shown in Fig. 8. The publicchMM and publicchMP are public communication channels that are used by the NFC mobile. However, the publicchPP. publicchPM, and publicchPA are used by the NFC POS and AuC 2. Besides, we declared four data types: type key for symmetric encryption, type timestamp to set the timestamps, type coins to generate random numbers, and type host to define the participants of our authentication scheme as the NFCMobile, NFCPOS, and AuC. Then, four free names, namely, sec1, sec2, sec3 and sec4, were declared to analyze the secrecy of the session key. After that, we defined eight events in order to show the start and end of the authentication processes to review mutual authentication between principles. Finally, we defined a set of queries to check if the proposed scheme could achieve the authentication and secrecy of the session key. Fig. 9 illustrates the main functions that are defined to implement the authentication events. The h, xor, con1, con3, con4, and con5 represent the hash, exclusive-or, and concatenation functions. Besides this, the encrypt and isFresh symbols for encryption and freshness functions were used, wherein the isFresh function is used to check if the timestamp is a fresh value or not. Furthermore, we defined a set of data-type converter functions from line 44 to line 48.
The proposed authentication scheme is emulated as the concurrent execution of three separate processes in order to emulate the NFC mobile, NFC POS, and AuC. Fig. 10 illustrates the code of the NFC mobile, called the processNFCMobile process. The first part of the process represents the code of the NFC mobile log-in phase (lines 52 to 59). While the second part represents the code of the authentication phase in the NFC mobile side (line 60 to 78). The (StartPMparam) event of NFC POS is set at line 55 and the (endMPparam) event of the NFC mobile is set at line 78. In the last line, the analysis query code of the session key secrecy (Sk), through publicchMP, is set.    Fig. 12 shows the code of the AuC, called the processAuC process. This process represents the authentication phase in the NFC POS side (lines 118 to 147). The (StartPAparam) event of NFC POS is set at line 157, and the (endAPparam) event of the AuC is set at line 184. The analysis query code of the of session key secrecy of (EKi) through the publicch2 is set at line 185.
As we mentioned, our authentication scheme is emulated as the concurrent execution of the processNFCMobile, processNFCPOS, and processAuC. Fig. 13 shows the code of the main process used to execute the parallel processes. The code in the first part represents the registration phases for either the NFC POS or NFC mobile (lines 151 to 168), wherein all the relevant parameters used to emulate the registration phase are initiated, while the second part of the code is used to Launch an unbounded number of sessions between the processes. Illustrates the results of our verification code, wherein the first four results demonstrate that the attacker has not been traced as resetting the sec1, sec2, sec3, and sec4. Hence, the session key sk is secure against the various attacks that are emulated by the ProVerif tool, while the rest the four results show that the eight events have been executed in stable orders. Hence, mutual authentication is achieved between all the participants and our proposed scheme is secure according to the formal verification.

Informal Security Verification Analysis
In this section, we discuss the security of the proposed authentication scheme through the achievement of security services. Besides this, the informal analysis is demonstrated to show how our proposed authentication scheme can prevent the related attacks types. Finally, the security features comparison of our proposed authentication scheme with other related schemes is presented.

Security Services Achievements
The Proposed Scheme Supports Full Mutual Authentication.
Proof. Our authentication scheme can fully achieve mutual authentication among NFC mobile (Xi), NFC POS (Yj) and AuC during the authentication phase through the following authentication messages.
The computed value of (H1') by the AuC matches the received value of (H1) from Yj via (M2). Besides this, the computed value of (H2') by the Yj matches the received value of (H2) from AuC via (M3). In addition, the transmitted value of (H3) by Yj via (M6) matches the computed value of (H3') by AuC. Thus, mutual authentication can be supported among Yj and AuC by the exchanging M2, M3 and M6 messages.  When the computed value of (V1') by the AuC matches the received value of (V1) from Xi via (M1). Besides this, the computed value of (V2') by the Xi matches the received value of (V2) from AuC via (M4). Furthermore, the transmitted value of (V3) by Xi via (M6) matches the computed value of (V3') by AuC. Thus, mutual authentication can be supported among Xi and AuC by exchanging M2, M4 and M6 messages.
On the other side, the value of (XIDi') that was decrypted by the Xi matches the value of (XIDi) that was encrypted by Yj using the shared (Sk) within received M4. Besides this, the value of (YIDj') that was decrypted by the Yj matches with the value of (YIDj) that was encrypted by Xi using the same shared (Sk) within the received M5. Thus, mutual authentication can be achieved between Xi and Yj via the exchange of M4 and M5 messages. Therefore, the proposed authentication scheme is able to support full mutual authentication services among all the communication entities.
The Proposed Scheme Supports a Full NFC Devices Anonymity.
Proof. To protect NFC mobile and NFC POS identities, the proposed scheme employs pseudonym identities (XIDi and YIDj) as transmitted messages instead of the NFC device's real identities. The pseudonym identities are generated in random manner and updated after finishing each authentication session. Thus, the pseudonym identities are distinct for both NFC mobile and NFC POS devices in every authentication session. Furthermore, it is unattainable for an adversary to obtain the NFC mobile and NFC POS real identities from the messages that have been transferred between the communication entities.
Therefore, the proposed authentication scheme is able to achieve full anonymity and the untraceability of services.

The Proposed Scheme Supports a Full Perfect Forward Secrecy.
Proof. According to our proposed authentication scheme, assume that the adversary has gained the longterm keys of the NFC devices, which are (Ki, XCi) and (Kj, YCj) of the NFC mobile and NFC POS, respectively. Then, the adversary still cannot obtain the session key (Sk) that has been generated by the AuC. This is because, after each succeeded authentication session, the keys XCi and YCj will be changed by one-way hash functions, as XCi' = h(XCi) and YCj' = h(YCj) in both the NFC mobile and NFC POS, respectively. The reason for this is that the used hash functions are one-way functions, and so the adversary cannot obtain the XCi and YCj from XCi' and YCj'. Therefore, our proposed authentication scheme is able to support a perfect forward secrecy service during the authentication stage.

Resistance to Related Attacks
The Proposed Scheme Resists De-Synchronization Attack.
Proof. Since our authentication scheme uses XIDi, YIDj and has a group of one-way hash functions in order to support full anonymity for NFC devices and perfect forward secrecy features. Therefore, it also wants a method to preserve the synchronization of the hash values of the NFC mobile, NFC POS, and the AuC.
In our authentication scheme, the consistency of the (XIDi) and hash chain value of h(XCi) will be guaranteed by exploiting two pseudonym identities (XIDi0) and (XIDi1) for the connection between the Xi and AuC. Similarly, for the connection between the Yj and AuC, our authentication scheme uses two pseudonym identities, (YIDj0) and (YIDj1), to ensure the consistency of YIDj and the hash chain value h (YCj). Since the hash functions that have been considered in our scheme are one-way hash functions, even if the adversary can block the authentication messages, the Xi, Yj and AuC can re-synchronize the hash values between them. With a view to make our discussion more precise, Fig. 15 illustrates different desynchronization attack scenarios.
Scenario (S1): Assume the adversary has blocked (M1) message, clearly will not affect the synchronization between Xi, Yj and AuC, wherein the authentication entities have not started updating the value of XIDi nor the hash chain value of h(XCi). Therefore, this scenario will not be taken into account.

Scenario (S2):
Assume the adversary has blocked (M2) message, obviously will not affect synchronization between Xi, Yj and AuC, wherein the authentication entities have not even started updating the YIDj nor the hash chain value h (YCj). Therefore, this scenario is the same as (S1) and will not be taken into account.
Scenario (S3): Assume the adversary has blocked (M3) message, the asynchronous pseudonym identities of the NFC POS will be considered between the Yj and AuC. In this case, since the hash chain values the Yi and AuC are not updated, then the synchronization of these identities only needs to be considered. The value of YIDj0 in the AuC has been renewed, while the value of YIDj in the Yj does not update. Fortunately, the previous pseudonym identity is saved in YIDj1 in the AuC, which is YIDj1 = YIDj. Thus, when the next authentication session is started by the Xi by unchanged XIDi, then the Yj will use the unchanged Yj, the AuC is still able to distinguish the Yj and completes the authentication.
Similarly, the asynchronous pseudonym identities of the NFC mobile will be considered between the Xi and AuC. Since both the hash chain values the Xi and AuC are not updated, then the synchronization of these identities only needs to be considered. The value of XIDi0 in the AuC is a fresh pseudonym identity, while XIDi value in the Xi does not update. Fortunately, the previous pseudonym identity is saved in XIDi1 in the AuC, which is XIDi1 = XIDi. Thus, when the next authentication session is started by the Xi by unchanged XIDi, the AuC is still able to distinguish the Xi and completes the authentication. In general, this scenario will cause asynchronous pseudonym identities between the <Yj and AuC> and <Xi and AuC>, but it will not have any effect on the next sessions.
Scenario (S4): Assume the adversary has blocked (M4) message, clearly this attack will not affect the synchronization of pseudonym identities of the NFC devices and AuC. Therefore, this scenario is the same as (S3) and will be ignored.
Scenario (S5): Assume the adversary has blocked (M5) message, it is like scenario (S3). However, the pseudonym identities values in the Xi and AuC have updated, and this means XIDi = XIDi0, and so we only want to consider the synchronization of two hash chain values in Xi and AuC. In this scenario, the hash chain value in the Xi is updated, while the value hash chain in the AuC is unchanged. When Xi uses a changed hash chain value, it initiates a new session, and the AuC will update its hash chain value through checking whether it is the value of XIDi1 = ф or not. Therefore, even if this scenario will cause asynchronous hash chain value between the Xi and the AuC, the two pseudonym identities will synchronize the hash chain values again.

Scenario (S6):
Assume the adversary has blocked (M6) message, this scenario is similar to (S5) regarding to the value of YIDj0, if the pseudonym identities values in the Yj and AuC have updated, it means that YIDj0 = YIDj, and so we only need to consider synchronization of two hash chain values in Yj and AuC. The hash chain value in the Yj is updated, while the value hash chain in the AuC is unchanged. When Yj, using changed hash chain values, initiates a new session, the AuC will update its hash chain value through checking whether it is the value of YIDj1 = ф or not. Therefore, even if this scenario will cause asynchronous hash chain value between the Yj and the AuC, the two pseudonym identities will synchronize the hash chain values synchronize again.
Therefore, according to the analysis of the above-mentioned de-synchronization attack scenarios, the proposed authentication scheme can resist de-synchronization attacks.
The Proposed Scheme Resists Stolen Password Table Attack. Proof. In the proposed authentication scheme, no password table of the NFC mobile or a NFC POS is stored in the AuC. Therefore, the proposed authentication scheme will not be subjected stolen verifier table attacks and can prevent such attacks.
The Proposed Scheme Resists Impersonation Attack.
Proof. In the proposed authentication scheme, the adversary cannot forge the NFC mobile or NFC POS devices. The adversary should be able to generate a valid value of {Ti0, XIDi, CTi1, and V1} in order to forge the Xi. It is impracticable where the adversary does not identify the secret keys XCi and Ki. Similarly, the adversary should be able to generate a valid value of {Tj0, YIDj, YCj, and H1} in order to forge the Xi. it is impracticable where the adversary does not identify the secret keys Kj and YCj. Therefore, our authentication scheme can prevent both NFC mobile and NFC POS impersonation attacks.
The Proposed Scheme Resists Spoofing Attack.
Proof. The adversary cannot forge the legitimate authentication messages of the NFC mobile or NFC POS without the pair of secret keys (Ki and XCi) or (Kj and YCj), respectively. Therefore, the NFC mobile or NFC POS device cannot spoof any other NFC mobile or NFC POS devices in in our authentication scheme.
The results in Tab. 7 illustrate that the proposed authentication scheme can achieve all the listed security features. Where the authentication schemes in [1,15,34] did not support the security features such as full mutual authentication, full NFC devices anonymity and untraceability, and full perfect forward secrecy. Furthermore, the only scheme that supported the NFC mobile login function, NFC POS Login function, NFC mobile password change function, and NFC POS password change function was the proposed authentication scheme. That means that our scheme offers more security features than the other related authentication schemes.

Performance Analysis
This section compares the storage space, communication, and communication costs of our authentication scheme with recent related schemes [1,15,34]. We will only focus on comparing the authentication phase where the other phases are not used frequently.
As pointed out in [39,40], the size of all the parameters to 128 bits, and the input and output block sizes of symmetric cryptography functions are multiples of 128 bits; the output of the hash functions is equal to 160 bits, the running time of AES cryptographic function is (T E/D ≅0.0056 s), and the running time of the one-way hash function are SHA-1, MAC and HMAC is (T mac ≈ T hmac ≈ T h ≅0.00032 s).

Storage Space Costs Analysis
Tab. 8 illustrates the storage space costs of the NFC devices of the proposed authentication scheme and other authentication schemes [1,15,34]. In the proposed authentication scheme, storage space costs for the NFC mobile {XIDi, XCi, Fi, and V} are required (128 + 128 + 128 + 160) = 544 bits, the NFC POS {YIDj, Cj, Fj, and H} are required (128 + 128 + 128 + 160) = 544 bits, while for the AuC, it requires 1024 bits. We note that our authentication scheme has the highest cost. The reason for this is that the NFC devices of our authentication scheme store a set of pseudonym identities in order to preserve the anonymity service. Yes Prevent the Wrong password login/update attack n/a n/a n/a Yes Prevent the Password table attack n/a n/a n/a Yes

Computation Costs Analysis
Tab. 10 shows the computation costs of our authentication scheme in comparison to the other recent authentication schemes [1,15,34]. The computation costs are computed based on the total execution time of the encryption, decryption, MAC, and hash functions that are executed during the authentication phase. We note that the proposed authentication scheme has the highest cost. The reason for this is that our authentication scheme executes both encryption/decryption functions in all authentication messages to preserve security services, but the total computation costs are still in the applicable range.

Conclusion
We proposed a new authentication scheme for the NFC mobile payment system in order to overcome current security deficiencies and to make such a system more secure. The proposed authentication scheme has significant security services, such as full mutual authentication between all communication entities, full anonymity for NFC devices, and full perfect forward secrecy services. The ProVerif tool was used to  verify the mutual authentication and the shared key secrecy. The BAN logic model was performed to confirm the mutual authentication between the communication entities. According to the several attack scenarios that were discussed, the highest security features of our authentication scheme were illustrated. Therefore, it can not only achieve full security features, but can also prevent numerus attacks such as password table, smartcard loss, replay, wrong login information, man-in-the-middle, insider, impersonation, and desynchronization attacks. Furthermore, a performance analysis showed that the proposed authentication scheme has an applicable cost range in the storage space, computation, and communication. Finally, our proposed authentication scheme is applicable in NFC mobile payment systems in order to execute payment transactions in a safe manner.