Secure Electronic Cash Scheme with Anonymity Revocation

In a popular electronic cash scheme, there are three participants: the bank, the customer, and the merchant. First, a customer opens an account in a bank.Then, he withdraws an e-cash from his account and pays it to a merchant. After checking the electronic cash’s validity, the merchant accepts it and deposits it to the bank. There are a number of requirements for an electronic cash scheme, such as, anonymity, unforgeability, unreusability, divisibility, transferability, and portability. Anonymity property of electronic cash schemes can ensure the privacy of payers. However, this anonymity property is easily abused by criminals. In 2011, Chen et al. proposed a novel electronic cash systemwith trustee-based anonymity revocation frompairing.Ondemand, the trustee can disclose the identity for e-cash. But, in this paper we point out that Chen et al.’s scheme is subjected to some drawbacks. To contribute secure electronic cash schemes, we propose a new offline electronic cash scheme with anonymity revocation. We also provide the formally security proofs of the unlinkability and unforgeability. Furthermore, the proposed scheme ensures the property of avoiding merchant frauds.


Introduction
Due to the fast progress of computer networks and Internet, information technology is used in electronic commerce.Many electronic commerce services can be found over the internet.So, an electronic payment mechanism is necessary for electronic commerce.And electronic payment is one of the key issues of electronic commerce development.To realize the digitalization of traditional cash and electronic payment, in 1983, Chaum suggested the first electronic cash scheme [1].Popularly, in an electronic cash scheme, there are three participants: the bank, the customer, and the merchant.First, a customer opens an account in a bank.Then, he withdraws an -cash from his account and pays it to a merchant.After checking the electronic cash's validity, the merchant accepts it and deposits it to the bank.For security and efficiency, there are a number of requirements for an electronic cash scheme, such as anonymity, unforgeability, unreusability, divisibility, transferability, and portability [2].Some of them are listed below.
Anonymity/Unlinkability. The customer of the cash must be anonymous.As long as the coin is spent legitimately, neither the merchant nor the bank can identify the customer of the coin.
Unforgeability.Only authorized banks can generate electronic cash.
Unreusability.The electronic cash cannot be reused.The scheme can detect the malicious customer, who spends the cash twice.
Electronic cash schemes can be divided into two categories: online and offline.In online schemes, as paying a coin to a merchant, the bank must attend to validate the coin and detect its reuse.But, in offline schemes, double spending can only be figured out when the merchant deposits the coin to the bank in the next phase.After Chaum's scheme, a lot of electronic cash schemes [3][4][5][6][7][8][9] have been proposed based on blind signatures and restrictive blind signatures.Afterward, many more complex schemes have been proposed [10][11][12][13].Recently, Eslami and Talebi proposed an untraceable electronic cash scheme [2] and claimed that their scheme satisfies all main security requirements, such as anonymity, unreusability, and date attachability.However, Baseri et al.
Mobile Information Systems [14] showed that Eslami and Talebi's scheme is subjected to some weaknesses in perceptibility of double spender, unforgeability, and date attachability.Baseri et al. also contributed a novel electronic cash scheme.
Untraceable electronic cash is an attractive payment tool for electronic commerce because its anonymity property can ensure the privacy of payers.However, this anonymity property is easily abused by criminals.In 2011, Chen et al. [15] proposed an electronic cash system with trustee-based anonymity revocation from pairing.On demand, the trustee can disclose the identity of the owner of an -cash.Chen et al. claimed that their scheme is the first attempt to incorporate mutual authentication and key agreement into -cash protocols and their scheme satisfies the security requirements of untraceability, verifiability, unforgeability, and anonymity revocation.But, in 2012, Chang [16] claimed that he finds some weaknesses of Chen et al. 's scheme.Then, Chen et al. [17] immediately provided a response to rebut Chang's attacks.By thoroughly investigating Chen et al. 's scheme, we find that, despite Chang's attacks being really wrong, Chen et al. 's scheme is surely insecure.Chen et al. 's scheme is subjected to some drawbacks.(1) The first flaw is the attack on the unforgeability by the dishonest customer.(2) The second flaw is the attack on double spending owner tracing.(3) The third flaw is the potential bank attack.
To contribute secure electronic cash schemes, we propose a new offline electronic cash scheme with anonymity revocation.Furthermore, the proposed scheme ensures the property of avoiding merchant frauds.
The remainder of this paper is organized as follows.Related concept of bilinear pairing and CDH problem are introduced in Section 2. In Section 3, we show some weaknesses of Chen et al. 's scheme.In Section 4 we propose a new electronic cash scheme with anonymity revocation.In Section 5 we show the verifiability of the proposed scheme.Double spender detection is covered in Section 6.In Section 7 we show that the proposed scheme satisfies uncheatability of merchants.Provable security of our scheme is covered in Section 8.In Section 9 we compare our scheme with the others.Finally conclusions are given in Section 10.

The CDH Problem.
Let  be a cyclic additive group of prime order  and  a generator of .The computational Diffie-Hellman (CDH) problem is to compute  for given , ,  ∈ .

Effective Attacks on Chen et al.'s Scheme
In this section, we show the drawbacks of Chen et al. 's scheme [15].For the sake of brevity, we omit the review of Then, That is to say, the customer forges a valid -cash {,  ⋅ , ( ⋅ ,  ⋅ )}.
Of course, in payment protocol, when the merchant gets an -cash from customers, he also can similarly forge -cash.Further, these forged -cash make the scheme fail in double spending owner tracing, because it is impossible to find the customer identity from  ⋅ .
Note that (, ) is a signature on  and .Furthermore,  does not play distinction function to an -cash. is only a randomly selected number.Any customer can randomly choose any  for their -cash.If  has some function, it is only to certain customer.It is not strange that different customers may choose same  for their -cash.So, this attack is a successful forgery.

Attack by the Dishonest Merchant.
In practice, there are always many merchants from different shops.After receiving an -cash {, , (, )} from a customer, the merchant may spend {, , (, )} to another merchant.This attack is correct due to the fact that the verification equation is only related to , , , .And no extra information should be provided by customers in the verification process.Later, even if the bank finds double spending, the bank and the trustee cannot find real double spender, because the double spender may not be the customer himself.

Potential
Attack by the Bank.However, in payment protocol, the only verification to the -cash {, , (, )} is to examine whether the following equation holds:  (, ) =  ( 3 (CNO) ⋅   , ) ⋅  (LST ⋅   ,  pub ) .(5) But, when let  =  pub ( is a randomly selected number in  *  ) in the above equation, then So, the bank can randomly select  and .Then Let  =  pub ,  = (⋅ 3 () + ) ⋅   to generate an -cash {, , (, )}.This apparently violates the withdrawal protocol above the customer and the bank together performing a blind signature function to complete the -cash withdrawal.

Our Proposed Scheme
Based on an id-based signature scheme [21] proposed by Hess and an efficient id-based blind signature [22] proposed by Zhang and Kim, we propose an offline electronic cash scheme with anonymity revocation.In the proposed scheme there are four participants: Trustee , the bank , the customer , and the merchant .There are five protocols: license issuing, withdrawal, payment, deposit, and -cash owner tracing.Here any communication between any two entities should be encrypted, and this can be done by incorporating mutual authentication and key agreement protocols, likely in [15].Here, for brevity, we omit those encryptions in five protocols.

System Setup.
In this stage, the Key Generation Center (KGC) chooses a cyclic additive group  1 which is generated by  with prime order  and chooses a cyclic multiplicative group  2 of the same order and a bilinear map  :  1 ×  1 →  2 .KGC also chooses a random  ∈  *  as the master key and sets  pub =  public and chooses cryptographic hash functions When the customer  submits his identity, ID  to the KGC, the KGC computes the public key   =  1 (ID  ) and private key   =   for the customer .Similarly, the KGC generates the public/private key pairs (  ,   ), (  ,   ), and (  ,   ) for Trustee , the Bank , and the Merchant , respectively.

License-Issuing Protocol.
Before withdrawing -cash from the bank, customer  needs to ask trustee  to issue him a license.The following steps describe the protocol, which is also illustrated in Box 1.
(3) To sign on  −1 , trustee  selects a random number,  ∈  *  , and computes The trustee  also signs on After that, trustee  stores (, ) to the database and sends (, , , , ) to the customer .

Withdrawal Protocol.
To complete the -cash withdrawal, customer  and bank  together perform the following steps.This protocol is also illustrated in Box 2.
(2)  first computes and checks whether If so, the bank  selects a random number,  ∈  *  , computes  =   , and sends  to the customer .(3) The customer  selects two random numbers, ,  ∈  *  , computes and sends ℎ to the bank .
(5) Customer  computes and checks whether If so, the customer  obtains an -cash (,   ,   ).

Payment Protocol.
When the customer  wants to spend his cash at the shop, the customer  and the merchant  do the following steps.This protocol is also illustrated in Box 3.
(2) The merchant  checks whether If so, he selects a random number  ∈  *  and computes Then he sends (, ) to the customer .
(3) The customer  computes and checks whether If so, he computes Then he sends ( 1 , If so, the merchant accepts the payment.

Deposit Protocol.
When the merchant  wants to deposit the received -cash into his account in the bank , the following steps are done between the bank  and the merchant .This protocol is also illustrated in Box 4.
(2) The bank  first checks whether the coin exists in its deposit.If the coin exists, it runs the double spender detection procedure.Else, the bank computes and checks whether If the above four equations hold, the bank accepts the coin, stores it in the deposit table, and transfers money to the merchant .

Revoking the Anonymity.
In the case that an -cash (,   ,   ) is abused by a criminal, whether the cash is spent twice or not, the trustee can revoke the anonymity of the cash by the  provided by the bank.As soon as the trustee  receives the request of revoking anonymity,  checks his database to find record (, ) and computes the identity information ID  =   () ⊕  by using his secret key .

Verifiability of the Proposed Scheme
Firstly, we show that the blind license  −1  can be verified by equation Since Secondly, we show that the -cash can be verified by equation  (  , ) =  (  +  2 (LST ‖   )   ,  pub ) . (29) In fact, Thirdly, we show that the signature (, ) on (LST,   ,   ) by merchant can be verified by equation Since Fourthly, we show that the information ( 1 ,  2 ) can be verified by the equations Finally, we show that the signature (, ) on  1 +  2 +  3 +  4 by trustee can be verified by the equation Since (36)

Double Spender Detection
In the case that the customer spends an -cash twice or more, the bank  can compute Then, the bank  checks its databases in the withdrawal protocol to find the record {ID  , ( −1 LST, , )} and knows the identity information ID  of the malicious customer .
Here ( 1 ,  2 ) and (  1 ,   2 ) are information the customer  sends to the merchant  in payment phase in twice consumption, respectively.In fact, So, Hence, the bank  can compute  −1  and obtain the identity information ID  of the malicious customer .

Uncheatability of Merchants
When the customer sends -cash (,   ,   ) to the merchant, the merchant computes signature (, ) on (,   ,   ).When the merchant sends (, ) to the customer, the customer first verifies it using the public key   of the merchant .When (, ) satisfies the verification equation, the customer sends ( 1 ,  2 ,  1 ,  2 ,  3 ,  4 , , ) to the merchant.If later the merchant uses -cash (,   ,   ) and ( 1 ,  2 ,  1 ,  2 ,  3 ,  4 , , ) to spend to other merchants and cheats the customer, the customer can show the merchant's signature to some arbitration agency.So, the scheme can effectively resist merchants cheat attack.

Provable Security
In this section, we show that the proposed scheme satisfies the property of unlinkability and unforgeability.
Definition 1 (the linkability game).Let  be a security parameter and let  1 and  2 be two customers. 1 ,  2 , and the bank  are involved in the following game.
Step 1.The bank  outputs two Licenses  0 and  1 .
Step 2. We randomly choose a bit   ∈ {0, 1} and place (   ,    ) and ( 1−  ,  1−  ) on the private input tapes of  1 and  2 , respectively.The bit   will not be disclosed to the bank .
Step 3. The bank  and two customers  1 ,  2 perform the withdrawal protocol of the proposed scheme.
Step 4. If  1 and  2 output two -cash (   ,     ,     ) and ( 1−  ,   1−  ,   1−  ) on their private tapes, respectively, we give the two 3 tuples in a random order to the bank; otherwise, ⊥ is given to .
Step 5.The bank  outputs   * ∈ {0, 1} as the guess of   . wins the game if   * =   .We define the advantage of  as Proof of Theorem 3. We consider the condition in Definition 1.Let (,   ,   ) be one of the two -cash given to the bank and let (, ℎ, ) be the view of the bank in one of the withdrawal protocols.It is sufficient to show that there exist two random factors (, ) that map (, ℎ, ) to (,   ,   ).We know Mobile Information Systems So, by equation   = , there is a unique .Then, by equation ℎ =  −1  2 ( ‖   ) + , there is a unique .Furthermore, when  and   are correctly computed, the following equation holds: So, it holds when   = +  .It is to say that (, ) always exists regardless of the values (,   ,   ) and (, ℎ, ).Therefore, even an infinitely powerful bank outputs a correct value   with probability of exactly 1/2.So, the proposed scheme satisfies the unlinkability property.
Definition 4 (the forgeability game).The adversary F and the challenger A play the following game.
Step 1.The challenger A takes a security parameter and generates the public parameters params and sends params to the adversary F.
Step 2. The adversary F can perform polynomially bounded number of hash queries, extract queries, and -cash queries.These three kinds of queries answer the hash function, private key, and -cash query by the adversary F, respectively.
(2) The adversary F has never requested the private key of the bank .
Definition 5 (unforgeability).An adversary F is said to be an (, ,   ,   ,   )-forger if it has advantage at least  in the above game, runs in time at most , and makes at most   ,   , and   extract, -cash, and hashing queries, respectively.A scheme is said to be (, ,   ,   ,   )-secure against A in the sense of unforgeable against -cash existential forgery attack if no (, ,   ,   ,   )-forger exists.
Theorem 6.If the CDH problem is hard, then the proposed scheme is secure against -cash existential forgery attack.
Proof of Theorem 6. Suppose that F is a forger who can forge -cash in the proposed scheme.A CDH instance (, , ) is given for ,  ∈   *  , By using the forgery algorithm F, we will construct an algorithm A which outputs the CDH solution  in .Algorithm A performs the following simulation by interacting with the forger F.
Setup.Algorithm A sets  pub =  and starts by giving F the system parameters including (,  pub ).At any time, F can query the random oracle  1 ,  2 and extract and cash queries.To answer these queries, A does the following.
1 -Queries.At any time F can query the random oracle  1 .To respond to these queries, A maintains a list  1 -list of tuples (ID, , , ) as explained below.When an identity ID is submitted to the  1 oracle, A responds as follows: If the query ID already appears on the  1 -list in a tuple (ID, , , ), A responds with  1 (ID) = .Otherwise, A generates a random coin  ∈ {0, 1}.If  = 0 then A computes  = () for a random  ∈  *  ; If  = 1 then A computes  = .A adds the tuple (ID, , , ) to  1 -list and responds to F with  1 (ID) = . 2 -Queries.To respond to  2 -Queries, A maintains a list referred to as  2 -list of tuples ( ‖   , ).When F queries the  2 oracle at ( ‖   ), A responds as follows: If the query ( ‖   ) already appears on the  2 -list in a tuple ( ‖   , ), then A responds with  2 ( ‖   ) =  ∈   .Otherwise, A generates a random  ∈   and adds the tuples ( ‖   , ) to  2 -list and responds to F with  2 ( ‖   ) = .
Extract Queries.When F queries the private key corresponding to ID, A first finds the corresponding (ID, , , ) from the  1 -list.If  = 0, then A fails and halts.Otherwise, A computes the private key  ID =  ⋅  pub = () by using the tuple (ID, , , ) in the  1 -list and responds to F with  ID .Cash Queries.If F requests an -cash on  under ID, A responds to this query as follows: A first finds the corresponding tuple (ID, , , ) from  1 -list and chooses one random number ,  ∈  *  and computes   =  − .If ( ‖   , ) already appears on the  2 -list, A chooses another ,  ∈  *  and tries again.Otherwise, A computes   =  ⋅  pub and stores ( ‖   , ) on the  2 -list.Then A responds to F with (  ,   ).Indeed, the output is valid -cash on  for ID.In fact, Output.If A does not abort as a result of F's extract query, then F's view is identical to its view in the real attack.By Forking Lemma, after replying F with the same random tape, A obtains two valid -cash: (,   ,   ) , (,   ,   * ) .(45) So, by the security proof of [22], A obtains () =   = (ℎ − ℎ * ) −1 ( −  * ).This completes the proof.

Comparisons
In this section, we compare our scheme with [15,[18][19][20] in some features, communication efficiency, and computation cost.The features are anonymity/unlinkability, unforgeability, verification, double-spending owner tracing, anonymity revocation, and uncheatability of merchant.Our scheme satisfies all of above features, but the others do not.We show the comparison result in Table 1.In Table 2, we compare the communication efficiency of our scheme with other schemes.Fan et al. 's scheme [18] and Zhang et al. 's scheme [20] are not trustee based, and therefore they do not have license-issuing protocol and owner tracing protocol.Juang's scheme [19] also does not have license-issuing protocol and owner tracing protocol but has the initializing phase and recovering phase.
For comparison, the numbers of rounds of initializing phase and recovering phase in Juang's scheme are computed to license-issuing protocol and owner tracing protocol, respectively.By Table 2, the proposed scheme demonstrates better communication efficiency under enhanced security.Our scheme and schemes [15,20] are all id-based scheme using bilinear pairings.So, in Table 3, we compare the computation cost of our scheme with schemes [15,20].It is necessary to illustrate that Zhang et al. 's scheme [20] has no license-issuing protocol and owner tracing protocol and for fair comparison, we have not computed the computation cost of encryption and its related computation cost in Chen et al. 's scheme.Compared with Chen et al. 's scheme, there are eleven more pairings computations in the proposed scheme.These eleven pairings computations are in payment protocol and deposit protocol and useful to prevent the merchant from cheat.
In practice, we can use elliptic curves to reduce the computation cost of bilinear pairings.

Conclusion
In this paper, we show that Chen et al. 's electronic cash scheme is suffering from some weaknesses in unforgeability and merchant frauds.To contribute a secure scheme, we propose a new offline electronic cash scheme with anonymity revocation.We also provide the formally security proofs of the unlinkability and unforgeability.Furthermore, the proposed scheme ensures the property of avoiding merchant frauds.

Table 1 :
Comparison of features of our scheme with recent schemes.

Table 2 :
Required number of rounds for each protocol in compared schemes.

Table 3 :
Comparison of computation costs.