Privacy-Preserving NFC-Based Authentication Protocol for Mobile Payment System

Abstract

One of the fastest-growing mobile services accessible today is mobile payments. For the safety of this service, the Near Field Communication (NFC) technology is used. However, NFC standard protocol has prioritized transmission rate over authentication feature due to the proximity of communicated devices. Unfortunately, an adversary can exploit this vulnerability with an antenna that can eavesdrop or alter the exchanged messages between NFC-enabled devices. Many researchers have proposed authentication methods for NFC connections to mitigate this challenge. However, the security and privacy of payment transactions remain insufficient. We offer a privacy-preserving, anonymity-based, safe, and efficient authentication protocol to protect users from tracking and replay attacks to guarantee secure transactions. To improve transaction security and, more importantly, to make our protocol lightweight while ensuring privacy, the proposed protocol employs a secure offline session key generation mechanism. Formal security verification is performed to assess the proposed protocol's security strength. When comparing the performance of current protocols, the suggested protocol outperforms the others.

1. Introduction

Many devices already include NFC, allowing for short-range communication and small data transfers. The usage of information and communication technology (ICT) is widespread worldwide [22]. However, NFC systems focus solely on communication speed, disregarding security aspects such as source and destination authentication [1–2] due to the minimal range of communications (about 10 cm). Due to this vulnerability in the NFC protocol, the authors in [3- 4] demonstrated that an adversary exploiting an NFC reader with a particular antenna might acquire confidential financial data from NFC bank cards or NFC-enabled devices within its (NFC reader) operational range. Many researchers [5-6] have discussed NFC's flaws, including authentication, protecting against replay, and man-in-the-middle attacks (MITM). Different methods have been suggested to provide party authentication in mobile payment systems using NFC technology [7–11].

El Madhoun et al. [7] devised a safe authentication system based on cloud infrastructure for NFC payment to solve security flaws revealed in the Europay, Mastercard, and Visa (EMV) protocols, which is the standard for securing contact and contactless NFC payment transactions. Asymmetric encryption is used in [7] to offer mutual authentication between an NFC-enabled device and an NFC-enabled point of sale (PoS) terminal. Also, symmetric encryption ensures bank data security during the authentication process. El Madhoun et al. [7] used the Scyther tool to confirm the security strength of the protocol. Unfortunately, there is a flaw in the protocol exchanged messages where users' IDs and transaction requests are sent in plaintext, allowing an eavesdropper to carry out a tracking attack and violate the parties' privacy.

Badra et al. [8] proposed detecting risks and weaknesses in the air interface between NFC-enabled smartphones and PoS terminals, as well as a method for securing NFC-based financial transactions using mobile devices. The suggested scheme is lightweight (due to the use of symmetric cryptosystem), simple, scalable, cost-effective, and has little computer processing overhead.

Sethia et al. [9] proposed a mutual authentication and verification system for the Internet of Things (IoT) access using NFC technology. The authors [9] deployed a cloud-based Trusted Certified Authority (TCA) to manage all cryptographic credentials and storage. In addition, the Automated Validation of Internet Security Protocols and Applications (AVISPA) tool verifies the suggested protocol.

Authentication protocol was proposed by Sethia et al. [10] for protecting mobile health cards. The suggested protocol prevented replay threats, impersonating, and other types of attacks. For confidentiality, this protocol uses both asymmetric and symmetric cryptography.

For the Europay, Mastercard, and Visa (EMV) protocol, Al-Haj et al. [11] presented an enhanced security mechanism. The suggested protocol's management and authentication server authenticate the financial transactions and mutual authentication between the NFC-enabled device and the PoS terminal. Mutual authentication, non-repudiation, data integrity, secrecy, and data privacy are all security aspects of the protocol.

In [12], Thammarat has provided an authentication protocol for mobile payment between the merchant and the buyer in the presence of an authentication server to carry out the authentication process between them, as well as a trusted third party for the dispute resolution process if the merchant or buyer does not accept the transaction. The protocol is composed of four stages. In the first two stages, symmetric keys are distributed among all the system users. Following that, an authentication process between the seller and the buyer used plaintext IDs, resulting in a tracking attack and a plaintext transaction requested, resulting in a breach of the parties' privacy.

For NFC-based proximity payments, the authors presented the security and privacy-preserving mobile commerce (SPPMC) framework [13]. They claimed that their protocol protects the user's privacy and anonymity; however, this isn't true because the participants' certificates contain all their information. Furthermore, these certificates were sent as plaintext between parties during the protocol phases.

A public key cryptography-based NFC mobile payment mechanism was presented by the authors of [21]. In [23], the authors proposed a Secure Protocol for Mobile Transaction (NSPMT) protocol based on NFC that included a Defense in Depth approach. Their Defense-in-depth approach consisted of three levels: defense at the hardware level, defense at the application level, and defense at the communication level.

In general, the current proposed NFC-based authentication solutions do not provide adequate privacy and anonymity for users' identities, leading to tracking attacks. To protect the payment process based on NFC technology, this paper presented a secure authentication protocol for the user authentication step in the mobile payment system. The suggested authentication system depended on three parties' communications: the Client (C), Merchant (M), and Trusted Service Manager (TSM). The client and merchant must mutually authenticate each other as part of the protocol design. Existing payment protocols can be immediately applied to perform payment transactions at the payment transaction stage. As a result, the method of the payment transaction step isn't covered in this article.

In this paper, we introduce the following contribution:

• An NEC-based mobile payment system environment is designed and suggested for users with NFC-enabled devices to promote users' privacy and anonymity of their identity and security robustness and system performance.

• A secure Anonymous authentication mechanism is being developed to allow mobile payments based on an NFC-enabled device. The proposed authentication protocol creates and uses a unique session key for each communicating session—moreover, this session key is from an offline procedure to increase the protocol's security.

• A formal security verification is used to verify the security properties of our suggested protocol. The suggested protocol grants security, mutual authentication, forward and backward secrecy, and protection against five common attacks: tracking, passive eavesdropping, replay, man-in-the-middle (MITM), and impersonation.

• Performance comparison between current protocols shows that the suggested protocol is more efficient than the other solutions.

The remainder of the paper is arranged as follows. The system architecture presents in section 2. In section 3, our proposed authentication protocol is discussed. The formal security analysis for our solution is introduced in section 4. Section 5 gives the performance analysis of our protocol. Finally, section 6 concludes the paper.

2. System Architecture

The relationships between different parties throughout mobile payment transactions are illustrated in Fig. 1. The architecture proposed in [14] has given rise to our system.

Fig. 1. System Architecture.

Fig. 1 represents the suggested system design. The system architecture consists of three components: Client, Merchant, and Trusted Service Manager. The client and the merchant communicated via an insecure NFC channel. A secure Internet link connects the merchant to the Trusted Service Manager. In addition, the client uses a secure channel to communicate with the Trusted Service Manager.

One of the primary components of the suggested payment system is the client's NFC-enabled device. The client's device has a Secure Element (SE) that performs the cryptographic operation and stores confidential financial data. As shown in Fig. 1, the client will use NFC technology to connect to and communicate with the merchant.

The merchant uses an NFC-enabled Point-of-Sale (PoS) device. The merchant's PoS is connected to a secure Internet link to back-end processing services, such as the Trusted Service Manager.

The merchant's device interacts with the client's device to complete the payment transaction during the payment process. First, through the Trusted Service Manager, the merchant confirms the validity of the relevant client's machine. Then, the merchant will finish the payment transaction once the authenticity of the related client's device is verified.

The Trusted Service Manager (TSM) plays a vital role in data security by acting as a mediator. Multiple parties collaborate to coordinate technical and business exchanges, including Mobile Network Operators (MNOs), banks and other service providers, ticketing agencies, and other issuing authorities. These companies can communicate with one another according to the TSM. Users can also download apps and services to their mobile devices using it. The significant responsibility of a TSM is to deliver all of these services securely, using encryption and authentication. It also allows secure and validated data installation into the Secure Element (SE) without holding the mobile device.

3. The Proposed Protocol

In this part, we propose a mobile payment authentication protocol based on NFC technology to disentangle the issues and overcome current protocols' limitations such as anonymity and privacy preservation [10 – 13]. Client (C), Merchant (M), and Trusted Service Manager (TSM) are all involved in the proposed authentication protocol. Table 1 lists the notations used in this paper.

Table 1. Notations

The proposed protocol comprises three phases: enrollment, authentication, and offline key exchange.

3.1 Enrollment Phase

The client and the merchant should register their mobile phones with their respective banks before completing any transaction to activate the service through an application, as shown in [14]. In addition, each party device must install a financial assistance provider-specific application during this phase. Finally, when the application is installed on the party's device, the party registers with the TSM via a secure channel like transport layer security (TLS). The purpose of registration is to provide the party with his financial information and a long-term shared key with TSM. This sensitive information will be stored in the secure element of the entity device. At this point, both C and M shared with TSM 𝐾₁ and 𝐾₂, respectively. TSM held the shared long-term key with the hashed value of the party's unique ID to achieve anonymity for all the parties.

3.2 Authentication Phase

During this phase, the proposed protocol depends on the TSM to provide mutual authentication between C and M. The proposed authentication protocol's execution sequence is illustrated in Fig. 2 for all parties.

Fig. 2. The Protocol’s execution sequence

1. C → M: Msg₁

Msg₁ = 𝐻₁(ID_𝐶), 𝐸_𝐾1{ID_𝐶, Request_𝐶, 𝑁₁, TS₁}

2. M → TSM: Msg₁, Msg₂

Msg₂ = 𝐻₁(ID_𝑀), 𝐸_𝐾2{ID_𝑀, Request_𝑀, 𝑁₂, TS₂}

3. TSM → M: Msg₃

Msg₃ = 𝐸_𝐾2{Response, PK_𝐶, 𝐻₂((Request_𝑀, Response), 𝐾₂), 𝐻₁(ID_𝐶), 𝑁₂, TS₃}

3. TSM → C: Msg₄

Msg₄ = 𝐸_𝐾1{Response, PK_𝑀, 𝐻₂((Request_𝐶, Response), 𝐾₁), 𝐻₁(ID_𝑀), 𝑁₁, TS₃}

C sends an authentication request Msg₁ to M, which contains the client’s concealed identity 𝐻₁(ID_𝐶) to avoid tracking attacks and provide anonymity. The second part of the message 𝐻₁(ID_𝐶), 𝐸_𝐾1{ID_𝐶, Request_𝐶, 𝑁₁, TS₁} is encrypted by a shared key between C and TSM to ensure authenticity and confidentiality. C can't dispute that he didn't send this message because of the possession of 𝐾₁.

When M received a message Msg₁ from C, he passed it to TSM along with his authentication message Msg₂, which has the same security features as Msg₁ for M.

On receiving messages M1 and M2 from M, TSM will process the following:

1- From hashed ID for each party, pick up the corresponding long-term shared key.

2- Decrypt each authenticated request and check its correctness.

3- If it accepts the request, it sends the authenticated response 𝐻₂((Request_𝐶, Response), 𝐾₁), ensuring the integrity of the response and the non-repudiation of the transaction. Besides the distribution of parties’ public keys in a session key calculation.

All the nonce and timestamps in the protocol are used to prevent replay attacks.

3.3 Session Key Exchange

At this point, both customer C and merchant M can compute offline, Diffie-Helman key 𝐾_DH. For customer C:

𝐾_DH = 𝑓₁(SK_𝐶, PK_𝑀)

For merchant M:

𝐾_DH = 𝑓₁(SK_𝑀, PK_𝐶)

Then, both compute session key 𝐾_𝑆

𝐾_𝑆 = 𝑓₂(𝐾_DH, 𝑁₁, 𝑁₂, 𝐻{ID_𝐶}, 𝐻{ID_𝑀})

Finally, C and M can execute mutual authentication using a trusted third-party TSM. This proposed authentication protocol uses only symmetric cryptographic operations, MAC, and a hash function, resulting in lightweight processes. As a result, it is suitable for NFC-enabled devices. Furthermore, using a secure offline session key generation approach will improve the protocol's security.

4. Security Analysis

This section explores the proposed authentication protocol for a mobile payment system using NFC technology in terms of security. First, the proposed protocol's security is evaluated in its ability to defend against replay attacks, eavesdropping, man-in-the-middle attacks, and tracking attacks. Then we utilized the Scyther tool to check the proposed protocol's security.

4.1 Security Characteristics

A few potential attacks are presented here to assess the security of the proposed protocol.

4.1.1 Replay Attack

A replay attack occurs when an adversary obtains a copy of an authenticated message and then resends it to the receiving party. A session key based on nonce values is generated in the proposed protocol for communication between client C and merchant M. The nonce value changes with each session, so the session key generation mechanism eliminates replay attacks.

4.1.2 Eavesdropping

An adversary utilizes an appropriate antenna and gets close enough to obtain or modify payment information, such as credit card numbers. Establishing a secure channel between two NFC devices can prevent eavesdropping; our suggested protocol can prevent eavesdropping by using symmetric cryptography and incorporating the hash function of messages in each step.

4.1.3 Main-In-The-Middle Attack

Our proposed protocol can mitigate a MITM attack by combining symmetric-key cryptographic procedures and the hash function. As a result, there is no exposure of confidential information, the reuse of authentication information is limited, and our protocol provides mutual authentication to identify both the transmitter and the receiver.

4.1.4 User Anonymity

As a result of the wireless transmission in NFC-based applications, an adversary can control the communication channel between users. Consider the possibility that an opponent intercepts the transmitted messages Msg₁, Msg₂ between client C and Merchant M. The hash values 𝐻₁(ID_C)and 𝐻₁(ID_M) represent the identities of C and M, respectively because a hash value represents the user identity. Even if the adversary obtains the masked user identity, it is useless because the identity-hashed value does not expose the user's true identity. As a result, no attacker can deduce the true identities of the client and merchant from the intercepted messages. In that case, the suggested protocol guarantees user anonymity and avoids the tracking attack.

4.2 Formal Security Verification Using Scyther

In this section, our proposed mobile payment protocol is verified using a formal approach that proves the security properties and ensures that the protocol is free of various forms of attacks and vulnerabilities. Scyther [15] is a tool for analyzing security protocols using the perfect cryptography assumption, which assumes that all cryptographic functions are perfect. For example, the adversary can learn nothing from an encrypted communication unless he has the decryption key. Scyther employs an unbounded verification and validation technique, which seeks to show that a protocol is sound for all potential behaviors, including an opponent's existence [15]. It's a security protocol analysis tool that utilizes the security protocol description language (SPDL) as its basis [15, 16]. Several academics have now used the Scyther tool to verify security protocols; see [17, 18].

As a result, we constructed the suggested protocol in SPDL to validate authentication (with non-repudiation) and confidentiality of Scyther claims [15]. Our proposed protocol targeted five types of goals non-injective synchronization, non-injective agreement, weak agreement, secrecy, and the aliveness of all the participants. The Scyther tool's "verification claim" approach is used to verify our protocol.

As shown in Fig. 2, 3, and 4, the protocol successfully guarantees all Scyther claims for C, M, and TSM, respectively, and no attacks are detected. Alive, Weakagree, Niagree, and Nisynch are authentication claims used to detect replay, relay, and man-in-the-middle attacks. Confidentiality claim Secret. [15] and [16] provide formal definitions for all Scyther claims. Six algorithms make up our suggested scheme. In this section, we will present the design of the scheme in detail.

Fig. 2. Scyther results for the Client

Fig. 3. Scyther results for the Merchant

Fig. 4. Scyther results for the TSM

The proposed protocol achieves all of the defined objectives. As a result, each side has met the requirements for secure mutual authentication.

5. Performance Analysis

The proposed and existing authentication protocols for the mobile payment system are compared regarding security characteristics and performance in this section. In addition, the proposed authentication protocol is compared to several current authentication protocols [11, 12, 13, 21, 23].

Table 2 compares the proposed authentication protocol to current protocols in several security aspects. As a result, as shown in Table 2:

Table 2. Comparison of Security Characteristics

• Ahamad et al. protocol [13] and our suggested protocol hide the user's identity. In [13], the identity of the user is not used. Instead, the certificate of the user is used in cipher form. Despite this, the recipient of an encrypted message in a symmetric system without sending the user's identity faces a hurdle in selecting the appropriate decryption key, which requires time-consuming searching to find the correct key. Instead, we use the hashed ID to protect user privacy and detect the corresponding key more quickly to overcome this challenge.

• In comparison to the other authentication protocols, Thammarat's protocol [12] and our proposed protocol enable backward/forward secrecy of the session key.

• Our protocol is the only protocol to mitigate the tracking attack due to the hashed identity in the exchanged message.

Table 3 lists the symbols and abbreviations that can be used to compare our procedure's performance to those of other protocols [11–13, 21, 23].

Table 3. Notations used for Performance Analysis

Next, the execution time and energy consumption for various cryptographic processes [19, 20] are shown in Table 4.

Table 4. The energy and time consumption of some cryptographic operations based on [19, 20]

Finally, Table 5 compares the performance of the proposed authentication protocol to existing approaches [11, 12, 13, 21, 23]. In addition, Table 5 shows the mathematical symbols that reflect the individual time and energy usage during various computing operations.

Table 5. Protocol comparisons of cryptographic operations cost, energy consumption, and execution time.

Based on Table 5, our protocol depends only on two cryptographic operations hash function and symmetric cryptosystems, leading to less time than existing protocols [11-13, 21]. The hash function process has been used in our proposed protocol to include novel security features like Party's Identity Cloaking and tracking attack mitigation as well as to satisfy the security criteria of the payment system described in [14]. However, the authors in [23] missed to meet the security standards for payment systems in favor of protocol effectiveness, in addition to their protocol's inability to protect user privacy.

According to the results, the proposed protocol consumes fewer resources. In addition, as compared to protocols in [11-13, 21, 23], the suggested protocol provides privacy preservation and mitigates tracking attacks.

6. Conclusions

This paper proposes a secure, lightweight authentication technique for mobile payment systems that use NFC-enabled devices. Compared to the corresponding current protocols, our proposed protocol has a lower computation time and less energy. It also enhances security and privacy throughout the mobile payment transaction procedure. Furthermore, the proposed protocol protects against well-known attacks, including passive eavesdropping, replay, tracking attack, and man-in-the-middle. In addition, the proposed protocol provides mutual authentication and session key backward/forward secrecy. Additionally, the proposed protocol's security and validity are ensured by using the Scyther tool to verify the security protocol.

We plan to improve this proposed solution in the future, create a prototype, and demonstrate its effectiveness in a real-world setting.