Untraceable and Anonymous Mobile Payment Scheme Based on Near Field Communication

Abstract

With the developments of mobile communications, M-commerce has become increasingly popular in recent years. However, most M-commerce schemes ignore user anonymity during online transactions. As a result, user transactions may easily be traced by shops, banks or by Internet Service Providers (ISPs). To deal with this problem, we introduce a new anonymous mobile payment scheme in this paper. Our new scheme has the following features: (1) Password-based authentication: authentication of users is done by low-entropy password; (2) Convenience: the new scheme is designed based on near field communication (NFC)-enabled devices and is compatible with EuroPay, MasterCard and Visa (EMV-compatible); (3) Efficiency: users do not need to have their own public/private key pairs and confidentiality is achieved via symmetric-key cryptography; (4) Anonymity: users use virtual accounts in the online shopping processes, thereby preventing attackers from obtaining user information even if the transaction is eavesdropped; (5) Untraceablity: no one (even the bank, Trusted Service Manager (TSM), or the shop) can trace a transaction and link the real identity with the buyer of a transaction; (6) Confidentiality and authenticity: all the transaction is either encrypted or signed by the sender so our new scheme can provide confidentiality and authenticity. We also present the performance and the security comparison of our scheme with other schemes. The results show that our scheme is applicable and has the most remarkable features among the existing schemes.

1. Introduction

Mobile commerce (M-commerce) [1,2,3,4] has come into the limelight in recent years thanks to the universality of smartphones and the rapid developments of wireless and mobile communication technologies. By using M-commerce, a user can use an internet-enabled mobile device such as a smartphone or a tablet and then he/she can perform online activities. Possible online activities include online shopping, online auctions, online payments, etc.

M-commerce is convenient and attractive to both users and merchants. For users, M-commerce is convenient and simple compared to traditional transactions. Moreover, it brings possible customers from all over the world from a merchant’s viewpoint. Furthermore, merchants can collect customer behaviors via transactions and can make statistical analysis to speculate the consumption preferences of users. The analysis helps a merchant to send subsequent information that may be attractive to users in the future to push up sales.

1.1. Related Works

Due to the importance of M-commerce, many online payment schemes have been proposed [1,5,6,7,8,9,10]. Some of them are designed to increase the performance and some are designed to enhance the security or privacy of transactions. For example, Toorani et al. [11] proposed a secure short message service payment protocol. The scheme allows users to pay the bill by the short message service (SMS). However, some weaknesses have been found including replay-attack and SMS message forging attack. Molloy et al. [12] proposed a payment protocol using a virtual credit card instead of a real card. In addition, the virtual credit card can be generated as many times as a user wishes. On the other hands, to provide user anonymity and unlinkability, Martínez-Peláez et al. [13] proposed a micropayment protocol basing on the anonymous electronic cash. To increase the performance of online payment protocol, Kungpisdan et al. [9] proposed an account-based online payment protocol. The protocol adopted symmetric-key cryptography instead of public-key cryptography for achieving confidentiality. Compared to many schemes using public-key cryptographies, the scheme achieves low computation during tractions. Liao [14] proposed a cross-domain anonymous online payment scheme which allows users to consume in different merchants in mobile communication with user anonymity. On the other hand, near field communication (NFC) [15,16,17] has come into limelight in recent years and has become increasingly popular. For this reason, NFC-enabled mobile payment protocols are provided [18,19,20,21] in which credit card information is combined into NFC-enabled mobile devices. The NFC-chip embed into a smartphone will change itself to the card simulation mode to simulate a credit card when an online transaction is proceeded and the information inside the (simulated) card is requested. In this way the card information is transmitted securely via NFC standard protocol to the merchant or to the card issuer for authentication. In practice, Apple [22], Microsoft [23], and Google Inc. [24] have introduced their idea separately to replace the traditional credit card by a virtual credit card. In addition, the cards are stored in NFC-enabled smartphones. By using the smartphone, mobile payments, online transactions can be proceeded very efficiently and conveniently. For this reason, IT industries and many researches have continuously focusing on such a promising technology to continuously improve its security, performance and/or to add new features on it [25,26,27,28,29]. For example, Pasquet et al. [28] proposed an infrastructure to test the security of the simulated credit card in the NFC-enabled smartphone. Pailles et al. [27] focus on the protection of private data in user accounts. Mainetti et al. [26] proposed a protocol for message-exchange between the NFC-enabled smartphone and the Point of Sale (PoS) terminal using a peer to peer method. The advantage of the scheme in [26] is that the transaction confirmation message can be stored and customized by merchant. Finally, Urien and Piramuthu [29] assumes that a user’s NFC-enabled smartphone may be untrustworthy and, instead of using the built-in security element in NFC-enabled smartphones, they proposed the cloud security element to achieve the goal. Moreover, their scheme follows the EMV standard and can execute the EMV credit card protocol. Their concept is similar to the Host Card Emulation [25] technique.

1.2. Motivation

Anonymity is an important issue for mobile payment and online transactions from customers’ viewpoints. In general, speaking, the identity of a user is required to be presented to its counterparty who may be a card issuer, a merchant, or a Trusted Service Manager (TSM) during the process of an online payment. The identity presented here is used for authentication. However, this may leak the information on who the owner of the card holder is and/or by whom and where the goods or items have been bought, and from which merchant. Furthermore, with this information, an impersonation-attack may be launched to forge an invalid transaction. To deal with this problem, Luo et al. [30] in 2016 proposed an NFC-based mobile payment protocol with user anonymity. However, we found that their scheme has some security issues and may not be functional in practice. For example, they use the same private key for digital-signature signing and for ciphertext decryption. Unlinkability is also a problem. It is difficult to be achieved according to the definition of unlinkability. Furthermore, Lee et al. [31], also mentioned that Luo et al.’s idea suffers from the symmetric-key leakage problem. Although Lee et al. [31] introduced their remedy, the new scheme is designed for pre-paid system but not for credit card applications. In addition, the new scheme is not EMV-compatible.

1.3. Our Contributions

In this paper, we are going to introduce a new NFC-based mobile payment protocol. The new scheme has the following features:

• Password-based authentication: Password-based authentication does not require expensive infrastructure compared to digital-signature and biometrics-based authentications. In addition, it is convenient for users since users can use low-entropy and easy-to-remember password to establish a high-entropy session key. Consequently, in our protocol, we assume that a user of our scheme possesses no high-entropy secret key and no public/private key pair in advance. What the user has in advance is only a low-entropy password ($pw$) shared with a bank (card issuer). The $pw$ will then be used for user-authentication and for securing communication.
• Convenience: The new NFC-based anonymous mobile payment scheme is compatible with EMV standard [32,33,34] which is set up by the largest three credit card magnate corporations named Europay, MasterCard and Visa in 1993, and it also can be operated on any NFC function-enabled smartphones.
• Efficiency: Users of our scheme do not need to have their own public/private key pairs and confidentiality is achieved via symmetric-key cryptography.
• Anonymity: A user’s virtual account is all set up and registered via the bank. Except the bank, no one else will know the actual identity of the user even when eavesdropping is occurred during the transactions.
• Untraceablity: No one (even the bank, TSM or the shop) can trace a transaction and link the real identity with the buyer of a transaction.
• Confidentiality and Authenticity: Every communication for transactions is either encrypted by a session key from Diffie-Hellman key exchange [35] or by a pre-shared key between a bank and TSM.

1.4. Paper Organization

The paper is organized as follows: Section 2 presents some preliminaries required for our construction as well as Luo et al.’s scheme. The model and our new NFC-based anonymous mobile payment protocol is provided in Section 3. We provide the security of our protocol in Section 4 and the conclusion is given in Section 5.

2. Preliminaries and Luo et al.’s Scheme Revisited

This section reviews some cryptographic primitives and definitions required for our construction. We will also review Lou et al.’s work and discuss the security flaws of their scheme.

2.1. Security Assumptions

Definition 1.

Discrete Logarithm (DL) Problem:G is a cyclic group with prime order p. g is a primitive root of G. The DL problem to the base g means the following problem:

$$\mathrm{Given}g,h\in G,\mathrm{find}\mathrm{an}\mathrm{integer}x\mathrm{such}\mathrm{that}h=g^{x}modp.$$

The DL problem is believed to be difficult and to be the hard direction of a one-way function. Based on the DL problem, Computational Diffie-Hellman Assumption can be defined as follows:

Definition 2.

Computational Diffie-Hellman (CDH) Problem:G is a cyclic group of prime order p and g is a primitive root of G, the CDH assumption says that given $(g,g^a,g^b)$ for $a,b\in Z_p^{*}$ picked randomly, there exists no polynomial-time algorithm to find an element $C\in G$ such that $C=g^{ab}modp$ with non-negligible probability.

CDH problem is also believed to be difficult and based on the problem, any two entities can generate $C=g^{ab}modp$ as their session key which is called the Diffie-Hellman (key-exchange)-based key [35].

2.2. Luo et al.’s Scheme Revisited

We first review Luo et al.’s protocol (UAPS for short) in this subsection and discuss the security flaws of their scheme. There are four entities in UAPS: a secure element (SE) embedded in a smart phone, a user, a card issuer (i.e., the bank) and a virtual credit card issuer (i.e., the TSM). In addition, the protocol consists of four stages: registration stage, anonymous virtual bank account generation stage, anonymous transaction account generation and issuing of virtual credit card stages. Details are described as follows:

2.2.1. Registration Stage

In this phase, each entity must generate its own identity $ID$ and an asymmetric key pair $(P{K}_{ID},S{K}_{ID})$ with a certificate issued by a Certificate Authority (CA). At the beginning, a user with identity $I{D}_U$ must open a bank account and to register his NFC-enabled smartphone to the bank. The bank then generates a shared key $K_{B,U}$ between the bank and the user and returns it to the user.

2.2.2. Anonymous Virtual Bank Account Generation Stage

At this stage, the user with identity $I{D}_U$ requests the bank to establish a virtual account $AI{D}_i$ for him/her. The SE in the user’s NFC-enabled smartphone will generate a public/private key pair $(P{K}_{AI{D}_i},S{K}_{AI{D}_i})$, and then uses the private key $S{K}_{AI{D}_i}$ to sign the public key $P{K}_{AI{D}_i}$. Then it delivers the signature to the bank. After authenticating the identity of the user, the bank will issue the corresponding certification of $AI{D}_i$ to user. Figure 1 shows the communication flaws and the detailed descriptions are listed as follows:

• The user sends $I{D}_U\parallel E_{K_{B,U}}(I{D}_U\parallel N_1\parallel Sig{n}_{S{K}_U}(I{D}_U\parallel N_1))$ to the bank. Here $N_1$ is a nonce, $Sig{n}_{S{K}_U}\left(M\right)$ denotes the signature on message M signed by the signing key $S{K}_U$, and $E_K\left(M\right)$ denotes the ciphertext of message M encrypted by the key K.
• The bank decrypts the message with the share key and verifies the signature. If it passed, then the bank generates a virtual account $AI{D}_i$ and a nonce $N_2$. The bank then sends back $I{D}_B\parallel E_{K_{B,U}}(I{D}_U\parallel AI{D}_i\parallel N_2)$ back to the user.
• The user receives $AI{D}_i$ and stores $I{D}_U\parallel AI{D}_i\parallel N_2$ into the SE.
• The SE generates a key pair $(P{K}_{AI{D}_i},S{K}_{AI{D}_i})$ corresponding to $AI{D}_i$. $S{K}_{AI{D}_i}$ is stored in the SE and the SE returns $P{K}_{AI{D}_i}\parallel Si{g}_{S{K}_{AI{D}_i}}(I{D}_U\parallel AI{D}_i\parallel P{K}_{AI{D}_i}\parallel N_2)$ to the user.
• The user sends $I{D}_U\parallel E_{K_{B,U}}\left(Si{g}_{S{K}_U}\right(I{D}_U\parallel AI{D}_i\parallel N_2\parallel Si{g}_{S{K}_{AI{D}_i}}(I{D}_U\parallel AI{D}_i\parallel P{K}_{AI{D}_i}\parallel N_2)$ to the bank.
• The bank decrypts the message and gets $P{K}_{AI{D}_i}$. It will then create a certificate $CER{T}_{AI{D}_i}^B$ corresponding to $P{K}_{AI{D}_i}$. The bank then returns $I{D}_B\parallel E_{P{K}_{AI{D}_i}}(AI{D}_i\parallel AI{D}_i\_ExpTime\parallel AI{D}_i\_Limit\parallel CER{T}_{AI{D}_i}^B\parallel K_{AI{D}_i,B})\parallel E_{K_{AI{D}_i,B}}(AI{D}_i\parallel CER{T}_{AI{D}_i}^B\parallel K_{AI{D}_i,B})$ to user. Here $AI{D}_i\_ExpTime$ is the expiry time of $AI{D}_i$ and $AI{D}_i\_Limit$ is the credit limit of $AI{D}_i$.
• The user sends the ciphertext to the SE. SE retrieves the shared key $K_{AI{D}_i,B}$ and the certificate $CER{T}_{AI{D}_i}^B$.

2.2.3. Anonymous Transaction Account Generation Stage

After making registration to the bank, the user then needs to register its (virtual) identity to TSM to get the virtual credit card. The virtual credit card will be used in the actual transactions. The user will establish a pre-stored credit account in TSM and the credit limit for this account can be decided by the user itself. This account will be linked to the virtual account $AI{D}_i$ in the bank for consuming via mobile payment. On the other hand, for security of the payment, user generates $BINFO$ (i.e., payment information) which is composed of virtual account $AI{D}_i$, account expiry date $AI{D}_i\_ExpTime$, account limit $AI{D}_i\_Limit$, and the session key $K_{AI{D}_i,B}$. The message is signed by the signing key $S{K}_{AI{D}_i}$, and then be sent to the bank via TSM. Besides, user will encrypt the payment message by session key $K_{TI{D}_i,TSM}$, and then signed the cipher text by $S{K}_{TI{D}_i}$. The signature as well as $TSMINFO$ are then sent to TSM. TSM decrypts it and then encrypts the content by using the bank’s public key $P{K}_B$. TSM signs the cipher text to generate $TSMBINFO$. TSM transmits the $BINFO$ and $TSMBINFO$ to the bank. The bank can retrieve $BINFO$ and $TSMBINFO$. After comparing the information between the $BINFO$ and $TSMBINFO$, the bank authenticates the identities and returns the credit information of the virtual account to $TSM$. Figure 2 shows the communication flaws and the details are described as follows:

• The user generates virtual transaction account $TI{D}_i$ and a key pair $(P{K}_{TI{D}_i},S{K}_{TI{D}_i})$. He/she then signs $P{K}_{TI{D}_i}$ with $S{K}_{TI{D}_i}$ and encrypts it with $P{K}_{TSM}$. Then the user sends the ciphertext $E_{P{K}_{TSM}}\left(Sig{n}_{S{K}_{TI{D}_i}}(TI{D}_i\parallel P{K}_{TI{D}_i}\parallel Timestamp)\right)$ to TSM.
• After decrypts the message, TSM establishes a session key $K_{TI{D}_i,TSM}$ and returns $TI{D}_i\parallel E_{P{K}_{TI{D}_i}}(TI{D}_i\parallel K_{TI{D}_i,TSM})$ to the user.
• The user requests identifiers $SID,AI{D}_i,I{D}_B$ and nonce $N_1$ to the SE.
• The SE generates the payment message $BINFO$ and send it with $N_1$ to user. Here $BINFO=Sig{n}_{S{K}_{AI{D}_i}}\left(E_{K_{AI{D}_i,B}}(SID\parallel AI{D}_i\parallel I{D}_{TSM}\parallel I{D}_B\parallel AI{D}_i\_ExpTime\parallel AI{D}_i\_Limit\parallel N_2)\right)$.
• The user generates transaction message $TSMINFO=Sig{n}_{S{K}_{TI{D}_i}}\left(E_{K_{TI{D}_i,TSM}}(SID\parallel AI{D}_i\parallel I{D}_{TSM}\parallel I{D}_B\parallel N_2\parallel AI{D}_i\_ExpTime\parallel AI{D}_i\_Limit)\right)$ and encrypts $BINFO,TSMINFO$ and $N_1$ with $P{K}_{TI{D}_i}$. That is, user sends $Sig{n}_{S{K}_{TI{D}_i}}(TI{D}_i\parallel E_{P{K}_{TI{D}_i}}(TI{D}_i\parallel TSMINFO\parallel BINFO\parallel N_2)$ to TSM.
• After decrypted $TSMINFO$, TSM will generate the authentication message $TSMBINFO=Sig{n}_{S{K}_{TSM}}\left(E_{P{K}_B}(SID\parallel AI{D}_i\parallel N_2\parallel AI{D}_i\_ExpTime\parallel AI{D}_i\_Limit\parallel K_{TSM,B})\right)$ and sends $E_{P{K}_B}(I{D}_B\parallel AI{D}_i\parallel BINFO\parallel SID\parallel I{D}_{TSM}\parallel TSMBINFO)$ to the bank for confirmation.
• The bank uses its corresponding keys to decrypt the ciphertext. The bank then compares BINFO with TSMBINFO. The bank accepts the message if they are identical. In this case, the bank will send the credit information of $AI{D}_i$ to TSM.
• After receiving the returned message, TSM verifies that $TI{D}_i$ is authorized to access the service and TSM will send $TI{D}_i\parallel E_{K_{TI{D}_i,TSM}}(Status\parallel TI{D}_i\_ExpTime\parallel TI{D}_i\_Limit)$ to the user.

2.2.4. Issuing of Virtual Credit Card Stage

During this phase, user can apply to TSM for a virtual credit card. TSM will issue a virtual credit card with shorter expiry date and lower credit limit. Besides, the credit card is complied with be EMV standard and is stored in the SE. A user can repeat this stage to get new virtual credit card when the expiry date is coming or remained limit is exhausted. Figure 3 shows the communication flaws and detail steps are listed as below:

• The user sends a request to the SE with anonymous transaction identifier $TI{D}_i$.
• The SE generates a new public/private key pair $(P{K}_{TI{D}_i},S{K}_{TI{D}_i})$ corresponding to $TI{D}_i$ and sends $Sig{n}_{S{K}_{TD{I}_i}}(AI{D}_i\parallel TI{D}_i\parallel N_1\parallel N_2)\parallel N_1$ to user.
• The user sends the encrypted message $E_{K_{TI{D}_i,TSM}}(Sig{n}_{S{K}_{TD{I}_i}}(AI{D}_i\parallel TI{D}_i\parallel N_1\parallel N_2)\parallel N_1))$ by key $K_{TI{D}_i,TSM}$ to TSM.
• After receiving the request, TSM will issue a new virtual credit card $TI{D}_i-CreditINFO$ and generate a new certification $CER{T}_{TI{D}_i}^{TSM}$, and sends the encrypted message $E_{K_{TI{D}_i,TSM}}(TI{D}_i-CreditINFO\parallel CER{T}_{TI{D}_i}^{TSM})$ to the user.
• After receiving the message, user decrypts ciphertext and stores the corresponding certification and the new credit card information into the SE.
• The remaining process just follows the EMV standard.

2.3. Comments on Luo et al.’s Scheme

As mentioned at the beginning, this scheme focusses on the topic of user anonymity. However, it suffers from several problems. Lee et al. [31] pointed out that the scheme leaks the symmetric key shared between the SE and the bank. It means an adversary may attack the mobile device to find sensitive information in the SE. The adversary may also impersonate the mobile phone owner and do mobile payments on behalf of the real user.

Besides, in this protocol, it uses the same key pair for encryption/decryption and for (digital) signature signing/verification. This kind of mixing use of the same key is not recommended since it may cause some unexpected security flaws. For example, if using the same key for both RSA encryption scheme and for RSA digital-signature scheme, then an attacker may eavesdrop some ciphertexts sending from others to the user, then the attacker may cheat the sender to encrypt the ciphertexts (for any reason the user may believe). As a result, the attacker will get the plaintexts corresponding to the ciphertext. The reason this attack may happening is the same key pair used for signature and for encryption and this kind of mix-using should be avoided.

3. Proposed Scheme

In this section, we introduce a new untraceable NFC-based anonymous mobile payment protocol to overcome the security weaknesses of Luo et al.’s scheme. There are three types of entities in our new scheme: a user, a bank and a TSM.

• A user is a customer who applies for a virtual account and a virtual transaction account for privacy protection reason. With the accounts he/she can pay using his NFC-enabled smartphone via our mobile payment protocol in an anonymous and untraceable manner.
• A bank is a card issuer who generates a virtual account and issues the corresponding virtual card for users.
• TSM is a very important entity in NFC payment ecosystem. TSM is assumed to be the trusted third party who sets up technical connections and business agreements with mobile network operators, or other entities controlling the SE on smartphones.

In addition, our scheme consists of four stages, (1) Initialization; (2) Virtual Account Application; (3) Virtual Transaction Account Application and Virtual Credit Card Issuance; (4) Virtual Credit Card and/or Virtual Transaction Account Updating. The details are described as follows and

Table 1. Notations.

Notations	Description
$I{D}_a$	The identifier of entity a
$AI{D}_i$	Anonymous virtual account identifier for user i
$TI{D}_i$	Anonymous virtual transaction account identifier of i
$PW$	The shared password between user and the bank
$P{K}_a$, $S{K}_a$	Public and private key pair of entity a
$PS{K}_{B,TSM}$	A secure and pre-shared key between Bank and TSM
$VA-request$	Virtual account registration request
$VTA-request$	Virtual transaction account registration request
$Update-request$	Virtual credit card update request
$X\_ExTime$	Expiry time of x’s certificate
$X\_Limit$	Credit limit of account X
$Credit\_Info$	Corresponding information of a virtual credit card
$TSM\_Info$	Payment information for TSM
$N_j$	j-th random number equals to $N_{j-1}+1$
$Ticke{t}_{B,TSM}$	A ticket for accessing TSM generated by the bank
$H\left(\right)$	A cryptographic one-way hash function
$E_k\left(m\right)$	Encryption of message m with key k
$Si{g}_{S{K}_a}$	Signature of entity a on the message m
$x\parallel y$	Concatenation of messages x and y
$TS$	Time stamp

lists the notations we will use in our protocol. Figure 4 shows the communication flaws of our new scheme.

3.1. Initialization

This is the stage for initial setting. At first, assume every single entity (i.e., user U, TSM, Bank) has their own identifiers (i.e., $I{D}_U$, $I{D}_{TSM}$, $I{D}_B$) at the beginning.

• The user U is assumed to have a physical bank account and a password $pw$ shared with the bank (for authentication). The $pw$ is assumed to be low-entropy (i.e., not as secure as a high-entropy secret key) so it can be kept secretly very easily (e.g., store in the SE of a smart phone or just keep it in mind without memorizing it anywhere).

On the other hand, both TSM and the bank are the organizations possessing with high levels power of computation, it is reasonable to assume that they can have the public-key cryptosystem’s key pairs $(PK,SK)$. Furthermore, we assume that their keys are Discrete-Logarithm-based (DL-based) keys (ref. Definition 1). The public-key cryptosystems are mainly used for authentication and for Diffie-Hellman-based key-exchange (ref. Definition 2). There are many candidates of such (DL-based) public-key cryptosystems such as Digital-Signature Standard (DSS), Schnorr Signature and/or ElGamail signature. On the other hand, confidentiality is achieved via symmetric-key cryptography such as AES or RC4 et al.

• TSM has its own public/private key pair $(P{K}_{TSM},S{K}_{TSM})$. More precisely, $P{K}_{TSM}=(y_{TSM},g_{TSM},p_{TSM},q_{TSM})$ where $p_{TSM}$ is a large prime, $g_{TSM}$ is a generator of a multiplicative group $G=<g_{TSM}>$ of order $q_{TSM}$ and $y_{TSM}=g_{TSM}^{x_{TSM}}mod{p}_{TSM}$. $S{K}_{TSM}=x_{TSM}\in {\mathbb{Z}}_{q_{TSM}^{*}}$. In addition, TSM holds a high-entropy secret key $PS{K}_{B,TSM}$ shared with the bank.
• The same as TSM, the bank has its own public/private key pair $(P{K}_B,S{K}_B)$. More precisely, $P{K}_B=(y_B,g_B,p_B,q_B)$ where $p_B$ is a large prime, $g_B$ is a generator of a multiplicative group $G^{’}=<g_B>$ of order $q_B$ and $y_B=g_B^{x_B}mod{p}_B$. $S{K}_B=x_B\in {\mathbb{Z}}_{q_B^{*}}$. In addition, the bank holds a high-entropy secret key $PS{K}_{B,TSM}$ shared with TSM.

In short, at the end of the stage, a user with identity $I{D}_U$ has $pw$; TSM with identity $I{D}_{TSM}$ has a symmetric key $PS{K}_{B,TSM}$, a DL-based public/private key pair $(P{K}_{TSM},S{K}_{TSM})$; the bank with identity $I{D}_B$ has a symmetric key $PS{K}_{B,TSM}$, a DL-based public/private key pair $(P{K}_B,S{K}_B)$ and a $pw$ as the one shared with $I{D}_U$. All those keys are generated in advance before the starting of our protocol.

3.2. Virtual Account Application

This stage is to authenticate the user via $pw$. It then aims to create a virtual account identifier $AI{D}_U$ and make it registered to the bank. The bank will record that together with user identity $I{D}_U$. Some information for later communication between U and TSM such as a ticket $Ticke{t}_{B,TSM}$ will be sent back to the user side. Description in detail is listed as follows:

• $U\to Bank:(I{D}_U,VA-request,T,C)$
  This step is to apply for registration and to inform the bank about which TSM the user will communicate with in the next stage. The user computes and does the following steps:
  • Pick $x\leftarrow Z_{q_B}^{*}$, use $pw$ and bank’s public key $P{K}_B=(y_B,g_B,p_B,q_B)$ to compute $T=g_B^x{y}_B^{pw}mod{p}_B$.
  • Pick $r\leftarrow Z_{q_{TSM}}^{*}$, use TSM’s public key $P{K}_{TSM}=(y_{TSM},g_{TSM},p_{TSM},q_{TSM})$ and compute $R=g_{TSM}^{r}mod{p}_{TSM}$.
  • Create a virtual account identifier $AI{D}_U$, compute $k^{{}^{\prime }}=y_B^{x}mod{p}_B$, $k=H(I{D}_U\parallel I{D}_B\parallel k^{{}^{\prime }}\parallel T)$ and $h_{va}=H(VA-request\parallel I{D}_U\parallel I{D}_{TSM}\parallel AI{D}_U\parallel T\parallel R\parallel N_1\parallel T{S}_1)$ where $N_1$ is a nonce and $T{S}_1$ is a time stamp.
  • Compute $C=E_k(AI{D}_U\parallel I{D}_{TSM}\parallel R\parallel N_1\parallel T{S}_1\parallel h_{va})$.
  • Send $(I{D}_U,VA-request,T,C)$ to the bank as request for virtual account registration.
• $Bank\to U:(I{D}_B,C_B)$
  In this stage, the bank authenticates the user via $pw$, generates a virtual credit card and a ticket for $AI{D}_U$. The ticket is generated for later communication between the user and the TSM. Detail steps of banks are described as follows:
  • Check the identity $I{D}_U$ from its member-list and find the corresponding password $pw$. Reject and terminate if $I{D}_U$ is not in the list.
  • Use $pw$ to compute $k^{{}^{\prime }}={(T\times y_B^{-pw})}^{s{k}_B}mod{p}_B$ and $k=H(I{D}_U\parallel I{D}_B\parallel k^{{}^{\prime }}\parallel T)$.
  • Decrypt C by key k and recover $(AI{D}_U\parallel I{D}_{TSM}\parallel R\parallel N_1\parallel T{S}_1\parallel h_{va})\leftarrow D_k\left(C\right)$.
  • Compute $h_{va}^{{}^{\prime }}=H(VA-request\parallel I{D}_U\parallel I{D}_{TSM}\parallel AI{D}_U\parallel T\parallel R\parallel N_1\parallel T{S}_1)$ and check the time stamp $T{S}_1$. Accept the $VA-request$ if $h_{va}^{{}^{\prime }}=h_{va}$ and $T{S}_1$ is valid.
  • Records $(I{D}_U,AI{D}_U)$ in its database, determine the expiry time (i.e., $AI{D}_U\_ExTime$) and the credit limit (i.e., $AI{D}_U\_Limit)$ of the credit card going to be issued to $AI{D}_U$.
  • Use the symmetric key $K_{B,TSM}$ corresponding to $I{D}_{TSM}$ and generate $Ticke{t}_{B,TSM}=E_{K_{B,TSM}}(I{D}_B\parallel AI{D}_U\parallel AI{D}_U\_Extime\parallel AI{D}_U\_Limit\parallel R\parallel T{S}_2\parallel Lifetime\parallel Si{g}_{S{K}_B}(I{D}_B\parallel AI{D}_U\parallel AI{D}_U\_Extime\parallel AI{D}_U\_Limit\parallel R\parallel T{S}_2\parallel Lifetime))$. Here $Si{g}_{S{K}_B}\left(M\right)$ is the signature of the bank on the message M.
  • Generate a ciphertext by the session key k and get $C_B=E_K(I{D}_U\parallel AI{D}_U\parallel AI{D}_U\_Extime\parallel AI{D}_U\_Limit\parallel N_1+1\parallel Ticke{t}_{B,TSM}\parallel T{S}_1^{{}^{\prime }})$.
  • Return $I{D}_B$ and $C_B$ to the user.
• U: After receiving the returned information from the bank, the user U does the following computations:
  • Decrypt $C_B$, check the time stamp $T{S}_1^{{}^{\prime }}$ and the correctness of $N_1+1$.
  • Store $AI{D}_U,AI{D}_U\_Extime,AI{D}_U\_Limit$ and $Ticke{t}_{B,TSM}$ securely.

3.3. Virtual Transaction Account Application and Virtual Credit Card Issuance

This stage is to create a virtual transaction account $TI{D}_U$ of U and to make registration of $TI{D}_U$ to the TSM. Based on the account $TI{D}_U$, TSM will issue a virtual credit card for U without knowing the real identity of U (i.e., TSM only knows $AI{D}_U$ alternatively). For the virtual credit card, TSM will generate the corresponding expiry time and limit of the card for $TI{D}_U$, and then TSM will send the virtual credit card, the expiry time and account balance back to the user. Steps in detail are listed as follows:

• $I{D}_U\to I{D}_{TSM}:(I{D}_B,Ticke{t}_{B,TSM},C_{TSM})$
  The user does the following steps:
  • Compute the session key $k_{U,TSM}=H(I{D}_U\parallel I{D}_{TSM}\parallel k_{TSM}^{{}^{\prime }}\parallel R)$ where $k_{TSM}^{{}^{\prime }}=y_{TSM}^{r}mod{p}_{TSM}$ and $r\in Z_{q_{TSM}}^{*}$ is the random number picked at step $\left(1\right)$ of the previous stage.
  • Generate a virtual transaction account $TI{D}_U$ and compute $h_{vta}=H(VTA-request\parallel AI{D}_U\parallel TI{D}_U\parallel I{D}_B\parallel Ticke{t}_{B,TSM})$.
  • Use $k_{U,TSM}$ and generate the ciphertext $C_{TSM}=E_{k_{U,TSM}}(VTA-request\parallel AI{D}_U\parallel TI{D}_U\parallel h_{vta})$.
  • Sends $(I{D}_B,Ticke{t}_{B,TSM},C_{TSM})$ to TSM.
    Note: The VTA-request is the request of registering U’s virtual transaction account $TI{D}_U$ to TSM.
• $I{D}_{TSM}:(K_{U,TSM},I{D}_B,AI{D}_U,TI{D}_U)$
  TSM does the following steps after receiving the information from U.
  • Decrypt the $Ticke{t}_{B,TSM}$ using the symmetric key $K_{B,TSM}$ shared with the bank in advance. Accept the ticket $Ticke{t}_{B,TSM}$ if the signature from the bank is correct and the ticket is valid by checking the time stamp $T{S}_2$ and the lifetime. Do the following steps if $Ticke{t}_{B,TSM}$ is accepted.
  • Compute $k_{U,TSM}=H(I{D}_U\parallel I{D}_{TSM}\parallel k_{TSM}^{{}^{\prime }}\parallel R)$ where $k_{U.TSM}^{{}^{\prime }}=R^{S{K}_{TSM}}mod{p}_{TSM}$ and then decrypt $C_{TSM}$ by the key $k_{U,TSM}$.
  • Accept the $VTA-request$ if $AI{D}_U$ in $C_{TSM}$ is the same as that in $Ticke{t}_{B,TSM}$ and $h_{vta}$ is correct.
• $I{D}_{TSM}\to I{D}_U:(TSM\_Info)$
  TSM does the following steps:
  • Generate a virtual credit card and the corresponding information $Credit\_Info$ for $TI{D}_U$.
  • Determine the corresponding expiry time, $TI{D}_U\_Extime$, and credit balance, $TI{D}_U\_Limit$, where $TI{D}_U\_Extime\le AI{D}_U\_Extime$ and $TI{D}_U\_Limit\le AI{D}_U\_Limit$.
  • Generate the ciphertext $TSM\_Info=E_{K_{U,TSM}}(I{D}_{TSM}\parallel AI{D}_U\parallel TI{D}_U\parallel TI{D}_u\_Extime\parallel TI{D}_U\_Limit\parallel Credit\_Info\parallel T{S}_3\parallel Si{g}_{S{K}_{TSM}}\left(M\right))$ where M includes the whole message in the ciphertext $TSM\_Info$ excluding the signature.
  • Return the ciphertext $TSM\_Info$ to the user U.
• $I{D}_U\to SE:(TI{D}_U\_Extime,TI{D}_U\_Limit,Credit\_Info,k_{U,TSM})$.
  The user does the following steps:
  • Decrypt $TSM\_Info$ and verify the signature and the time stamp $T{S}_3$. Accept $TSM\_Info$ if it passed the verification.
  • Store the necessary security information including the expiry date of $TI{D}_U$, (i.e., $TI{D}_U\_Extime$), the credit balance of $TI{D}_U$ (i.e., $TI{D}_U\_Limit$), the information of the virtual credit card (i.e., $Credit\_Info$) and session key $k_{U,TSM}$ into the SE.

3.4. Virtual Credit Card and/or Virtual Transaction Account Updating

The goal of this stage is to allow a user to ask for a new virtual credit card from TSM. It will be launched when the date is closing to the expiry time or the remained limit is going to running out. Furthermore, user can change the virtual transaction account $TI{D}_U$ at this stage if necessary. Description in detail is listed as follows:

• $I{D}_U\to I{D}_{TSM}:(TI{D}_U,C_{req})$.
  The user $I{D}_U$ does the following steps:
  • Pick a new random number $r^{\prime }\in Z_{q_{TSM}}^{*}$ and compute $R^{{}^{\prime }}=g_{TSM}^{r^{\prime }}mod{p}_{TSM}$.
  • (Optional) Generate a new virtual transaction account $TI{D}_U^{{}^{\prime }}$ in case of applying for update the virtual transaction account.
  • Compute $h_{req}=H(update-request\parallel TI{D}_U\parallel \left(\mathrm{optional}\right)TI{D}_U^{{}^{\prime }}\parallel R^{{}^{\prime }}\parallel T{S}_{req})$ and the ciphertext $C_{req}=E_{k_{U,TSM}}(update-request\parallel TI{D}_U\parallel \left(\mathrm{optional}\right)TI{D}_U^{{}^{\prime }}\parallel R^{{}^{\prime }}\parallel T{S}_{req}\parallel h_{req})$ where $k_{U,TSM}$ is the session key generated at the previous stage and stored in the SE.
  • Send $(TI{D}_U,C_{req})$ to TSM
  Note: $TI{D}_U^{{}^{\prime }}$ is optional in this step.
• $I{D}_{TSM}\to I{D}_U:(I{D}_{TSM},C_{rpy})$
  TSM does the following steps after receiving the request.
  • Decrypt the ciphertext $C_{req}$ by the session key shared with $TI{D}_U$.
  • Accept the request if $h_{req}$ is valid. Continue the following step if accepted.
  • Create a new virtual credit card and the corresponding information $(Credit\_Inf{o}^{{}^{\prime }},TI{D}_U\_Extime,TI{D}_U\_Limit)$. Alternatively, if $TI{D}_U^{{}^{\prime }}$ presented (i.e., user has also requested to change a new virtual transaction account $TI{D}_U^{{}^{\prime }}$), change $(TI{D}_U\_Extime,TI{D}_U\_Limit)$ by $(TI{D}_U^{{}^{\prime }}\_Extime,TI{D}_U^{{}^{\prime }}\_Limit)$.
  • Compute the new session key $k_{U,TSM}^{{}^{\prime }}=R^{{}^{\prime }S{K}_{TSM}}mod{p}_{TSM}$.
  • Sign and encrypt $M_{rpy}$ where $M_{rpy}=I{D}_{TSM}\parallel TI{D}_U\parallel TI{D}_U^{{}^{\prime }}\parallel TI{D}_U^{{}^{\prime }}\_Extime,TI{D}_U^{{}^{\prime }}\_Limit\parallel Credit\_Inf{o}^{{}^{\prime }})$ if the virtual transaction account changed to $TI{D}_U^{{}^{\prime }}$. Otherwise, $M_{rpy}=I{D}_{TSM}\parallel TI{D}_U\parallel TI{D}_U\_Extime\parallel TI{D}_U\_Limit\parallel Credit\_Inf{o}^{{}^{\prime }}$. The resulted ciphertext is $C_{rpy}=E_{k_{U,TSM}^{{}^{\prime }}}(M_{rpy}\parallel Si{g}_{S{K}_{TSM}}\left(M_{rpy}\right))$.
  • Return $(I{D}_{TSM},C_{rpy})$ to the user.
• $I{D}_U\to SE:(Credi{t}^{{}^{\prime }}\_Info,k_{U,TSM}^{{}^{\prime }},TI{D}_U\_ExtimeTI{D}_U^{{}^{\prime }}\_Extime,TI{D}_U\_LimitTI{D}_U^{{}^{\prime }}\_Limit)$
  The user does the following steps:
  • Compute the new session key $k_{U,TSM}^{{}^{\prime }}=y_{TSM}^{r^{\prime }}mod{p}_{TSM}$ and use it to decrypt $C_{rpy}$.
  • Accept $C_{rpy}$ if the signature is valid.
  • Stores the necessary security parameters including new virtual credit card info, $Credit\_Inf{o}^{{}^{\prime }}$, new session key, $k_{U,TSM}^{{}^{\prime }}$, new expiry time, $TI{D}_U\_ExtimeTI{D}_U^{{}^{\prime }}\_Extime$, and new credit balance, $TI{D}_U\_LimitTI{D}_U^{{}^{\prime }}\_Limit$, to the SE.

Now, a new virtual credit card with lower credits, shorter expiry time and EMV-compatible has received by the user $I{D}_U$. It is stored in the SE and can be updated in accordance with the virtual credit card and/or virtual transaction account updating stage. The other rest transaction processes follow EMV standards, use an NFC smartphone with card emulation mode, and then transactions can be done in an efficient and secure way.

4. Security Analysis

We will analysis the confidentiality, anonymity and untraceability, integrity and unforgeability in this section. The security analysis is based on the assumption the bank and TSM are semi-trusted third parties (or called the honest-but-curious adversaries). A semi-trusted third party means a party that will act following the rules of the protocol but may also try to find sensitive data that should not be leaked to him/her if there is any security flaw in the protocol.

4.1. Confidentiality

Confidentiality is considered in three parts; the confidentiality between the user U and the bank during the virtual account application phase, the confidentiality between TSM and the user, and between TSM and the bank during the virtual transaction account application and virtual credit card issuance phase, and the confidentiality between the use and TSM during the account update phase.

Firstly, at the first stage, all the sensitive information sent between the user and the bank are encrypted by the Diffie-Hellman key $y_B^{x}mod{p}_B=k^{\prime }={(T\times y_B^{-pw})}^{s{k}_B}mod{p}_B$. Any passive attacker via eavesdropping is infeasible to compute the same key $k^{\prime }$ according to the CDH hardness problem (Definition 2). On the other hand, for any active attacker who attempts to impersonate the user with identifier $I{D}_U$ or the bank, he/she must have the knowledge of the user’s password $pw$ and/or the bank’s private key $s{k}_B$. The security of this part is protected by the technique of password-based authenticated key exchange protocol (PAKE). Our PAKE protocol is constructed following the concept of Abdalla and Pointcheval’s simple password-based encrypted key exchange protocol [36] and can be proved secure following their security proofs. Consequently, no sensitive information is leaked during the virtual account application stage.

During the second phase (i.e., virtual transaction account application and virtual credit card issuance stage), TSM communicates with the user $I{D}_U$ and the bank separately. All information sent between TSM and the bank are encrypted using the pre-shared key $K_{U,TSM}$. The information between user $I{D}_U$ and TSM are encrypted using the Diffie-Hellman key $k_{U.TSM}^{{}^{\prime }}=R^{S{K}_{TSM}}mod{p}_{TSM}=y_{TSM}^{r}mod{p}_{TSM}$. No one can compute the same key without $S{K}_{TSM}$ or r and r is chosen by the user $I{D}_U$. To avoid man-in-the-middle attack, $R=g_{TSM}^{r}mod{p}_{TSM}$ is firstly authenticated by the bank (i.e., the semi-honest third party) in the first stage. Then, R is encapsulated into the ticket $Ticke{t}_{B,TSM}$ so that only TSM can decrypt it and recover R. Consequently, the session keys in this stage are all secure and authenticated. The same security analysis is also applied to the key in the virtual credit card and/or virtual transaction account updating stage. Finally, all the sensitive information of the user is stored in the SE of the user’s smartphone. Therefore, we conclude that confidentiality is achieved in all stages of our protocol.

4.2. Anonymity and Untraceability

During the virtual account application stage, mutual authentications is achieved via password-based authentication. Only at this stage the user will reveal his real identity so only the bank knows a user’s real identity. After the stage, the bank issues a virtual bank account $AI{D}_i$ to the user. Furthermore, at the virtual transaction account application stage, the user uses the virtual bank account $AI{D}_i$ to communicate with the TSM. Therefore, TSM does not know a user’s real identity and TSM issues a temporary EMV-compatible virtual credit card to the virtual transaction account $TI{D}_i$ to the user. On the other hand, the communication between the user and TSM is encrypted using the Diffie-Hellman-based session key $k_{U,TSM}$ so even the bank has no ability to find the relationship between the virtual bank account $AI{D}_i$ and the virtual transaction account $TI{D}_i$. Finally, a merchant will only know the $TI{D}_i$ and will not know the real identity of the user. Consequently, the anonymity of a user is achieved at all stages.

In short, the bank will only know the real identity $I{D}_i$ and the virtual bank account $AI{D}_i$. On the other hand, TSM will only know $AI{D}_i$ and virtual transaction account $TI{D}_i$. Finally, a merchant only knows $TI{D}_i$ of the corresponding credit card. Therefore, we conclude that no one can trace a transaction and link the real identity with the buyer of a transaction. The untraceability is consequently achieved.

4.3. Integrity and Unforgeability

Firstly, we assume a user of our scheme has no high-entropy secret key and no public/private key pair in advance. All the communication to or from the user is encrypted based on the Diffie-Hellman-based session key, so unforgeability is achieved by the secrecy of the generated session key. We also assumed TSM and the bank are semi-honest, so they will be considered as passive attackers who will not forge new messages. In addition, the hash values (i.e., $h_{va},h_{req}$) provide information for the bank or TSM to verify the integrity of the received message. On the other hand, in our scheme, all transactions sent from the bank or from TSM are all signed by the sender and are recorded by the corresponding entities. Therefore, integrity and unforgeability can be achieved by the generated signatures from the viewpoints of the bank and TSM.

5. Performance and Comparison of Security Features

In this section, we show the performance of our proposed scheme from the viewpoint of communication costs. We consider only the cost that is required to be transmitted online during a transaction. That is, the transmission between user and bank, and the transmission between user and TSM. On the other hand, we will compare the features of our scheme with some other schemes.

To compute the online communication cost, we use the following assumptions.

• A request message (i.e., $\{VA,VTA,Update\}-request$) costs 20 bytes each.
• A DL-based signature is 40 bytes (using DSA [37], for example).
• A hash value is 32 bytes (using SHA-256, for example).
• A personal ID is about 20 bytes (using Unicode standard, a number or alphabet is 2 bytes. We assume an ID has 10 numbers or alphabets on average).
• A $Ticke{t}_{B,TSM}$ has 112 bytes (i.e., $20*4+4*4+16+40=112$).
• A $Credit\_Info$ has 83 bytes according to [4].
• The size of a ciphertext is the same as its corresponding plaintext.
• All other information not defined here such as $X_{L}imit,X_{E}xTime,TS$ cost 20 bytes each.

Table 2. Communication Cost of the Proposed Scheme.

Stage	Length in Byte
Virtual Account Application
$U\to Bank:(I{D}_U,VA-request,T,C)$	$20+20+128+256=424$
$Bank\to U:(I{D}_B,C_B)$	$20+132=152$
Virtual Transaction Account Application
$I{D}_U\to I{D}_{TSM}:(I{D}_B,Ticke{t}_{B,TSM},C_{TSM})$	$20+112+316=448$
$I{D}_{TSM}\to I{D}_U:(TSM\_Info)$	$20*5+83+20+40=243$
Virtual Credit Card and/or Updating
$I{D}_U\to I{D}_{TSM}:(TI{D}_U,C_{req})$	$20+464=484$
$I{D}_{TSM}\to I{D}_U:(I{D}_{TSM},C_{rpy})$	$20+223=243$

shows the communication cost of our scheme.

Next, we show the comparison of security features of our scheme with other schemes in

Table 3. Comparison of Features.

	$\mathit{pw}$-Based	Anonymity	Untraceability	EMV-Compatible
[2]	X	X	X	X
[5]	X	X	X	X
[6]	X	X	X	X
[30]	X	O	X	O
[13]	X	O	O	X
[20]	X	X	X	X
[29]	X	X	X	O
Proposed Scheme	O	O	O	O

.

6. Conclusions

In this paper, we investigate the scheme introduced by Luo et al. at Computers and Electrical Engineering in 2016. We found some security flaws and weakness of the scheme. In addition, we introduce a new EMV-compatible NFC-based anonymous payment scheme. The important feature of the new scheme is the user needs only a low-entropy password shared with a bank in advance instead of a high-entropy secret key or a cumbersome public/private key pair. The new scheme provides many privacy preserving properties such as anonymity, untraceability and is suitable for mobile payments of users.