Date Attachable Offline Electronic Cash Scheme

Abstract

Electronic cash (e-cash) is definitely one of the most popular research topics in the e-commerce field. It is very important that e-cash be able to hold the anonymity and accuracy in order to preserve the privacy and rights of customers. There are two types of e-cash in general, which are online e-cash and offline e-cash. Both systems have their own pros and cons and they can be used to construct various applications. In this paper, we pioneer to propose a provably secure and efficient offline e-cash scheme with date attachability based on the blind signature technique, where expiration date and deposit date can be embedded in an e-cash simultaneously. With the help of expiration date, the bank can manage the huge database much more easily against unlimited growth, and the deposit date cannot be forged so that users are able to calculate the amount of interests they can receive in the future correctly. Furthermore, we offer security analysis and formal proofs for all essential properties of offline e-cash, which are anonymity control, unforgeability, conditional-traceability, and no-swindling.

(ProQuest: ... denotes non-US-ASCII text omitted.)

Academic Editor:T. Cao and Academic Editor:M. Ivanovic and Academic Editor:F. Yu

Department of Computer Science and Engineering, National Sun Yat-sen University, Kaohsiung 80424, Taiwan

Received 15 January 2014; Accepted 26 February 2014; 18 May 2014

This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

1. Introduction

Due to the rapid growth of the Internet and communication developments, electronic commerce has become much more popular and widely used than ever [1-8]. The mobile telecommunications have been developed from 2 G to 3.5 G. Furthermore, LTE Advanced, 4 G, and 5 G are being implemented to the market in recent years. With the convenience of mobile network, people can do shopping or electronic payments by using any devices with network capability instead of leaving home. As a result, electronic commerce has been emphasized nowadays. Electronic cash (e-cash) is definitely one of the most popular research topics among electronic commerce. E-cash and the traditional cash notes are very much alike except e-cash is digitized and used on Internet transactions; therefore, it is very important that e-cash be able to hold the accuracy, privacy, and all other security concerns.

A typical e-cash system usually consists of payers (customers), payees (shops), and a bank. There are two types of e-cash in general which are online e-cash [9-13] and offline e-cash [14-27]. Online e-cash system involves participation of the bank during transactions (the payment stage). Banks are able to check whether customers have double-spent the e-cash(s) or not, and if yes, banks can terminate the transactions at once. Thus, the bank has to be online during every transaction and it may lead to a bottleneck of the system. On the other hand, while banks do not participate in the payment stage of offline e-cash systems, double-spending check is only held during the deposit stage. Yet, the bank is set to be offline, but the system design is usually much more complicated than the online type and it may lead to a longer transaction time. Since both systems have their own pros and cons, they are used under different circumstances.

Extending online and offline e-cash systems, many e-cash schemes with other different features have been proposed over the years. For instance, e-cash can be stored compactly such that the space to store these e-cash is much reduced [15, 16], e-cash is generated by multiauthorities instead of one bank only [25], exact payments e-cash [13], recoverable e-cash which can be recovered when an e-cash is lost [26], and so on.

Based on the majority of the existing approaches, we summarize that a secure e-cash system should satisfy the following requirements.

(i) Anonymity : no one, except the judge, can obtain any information of the e-cash owner's identity from the contents of e-cash.

(ii) Unlinkability : no one, except the judge, can link any e-cash payment contents.

(iii): Unforgeability : no one, except the bank, can generate a legal e-cash.

(iv) Double-Spending Control : banks should have the ability to check if the e-cash is double-spent or not. No e-cash is allowed to be spent twice or more in an e-cash system.

(v) Conditional-Traceability : the system should be able to trace and revoke the anonymity of users who violate any of the security rules so that they will receive penalties.

(vi) No-swindling : no one, except the real owner, can spend a valid offline e-cash successfully.

In order to perform double-spending checks, banks have to store information of e-cash(s) in their database. Thus, the database of banks grows in direct proportion to the number of e-cash(s) withdrawn. Embedding an expiration date into each e-cash has been considered since it helps the banks to manage the database more easily. On the other hand, customers have to exchange their expired e-cash(s) with banks for new ones so as to keep the validity of the e-cash. Furthermore, customers will receive interest from banks after cash is deposited. In order to guarantee customers will receive the right amount of interest, it is necessary for customers to attach the deposit date to their e-cash(s) and the date cannot be modified by anyone else [11]. So far, there are a number of online e-cash schemes with an expiration date attachment [9, 11, 28]. However, there are very few offline approaches [21].

In this paper, we are going to propose an efficient date attachable offline e-cash scheme and provide formal proofs on essential properties to it in the random oracle model. Considering the practical needs, we pioneer to embed two kinds of date, which are expiration data and deposit date, to the offline e-cash. Moreover, we will offer an E-cash renewal protocol in our scheme (Section 3.2.5). Users can exchange their unused expired e-cash for a new one with another valid expiration date more efficiently. Compared with other similar works, our scheme is efficient from the aspect of considering computation cost.

The rest of this paper is organized as follows. In Section 2, we briefly review techniques employed throughout our scheme. Our proposed scheme is described in Section 3 in detail. Security proofs and analysis are covered in Section 4. Features and performance comparisons are made in Section 5, and the conclusion is given in Section 6.

2. Preliminaries

In this section, we briefly review techniques used in our date attachable offline e-cash scheme.

2.1. Chaum's Blind Signature Scheme

Blind signature was first introduced by Chaum [29]. It has been widely used in e-cash protocols since it has been proposed. A signer will not be able to view the content of the message while she/he is signing the message. Afterwards, a user can get a message with the signature of the signer by unblinding the signed message. The protocol is described as follows.

(1) Initialization:

: The signer randomly chooses two distinct large primes p and q , then computes n = p q and [varphi] ( n ) = ( p - 1 ) ( q - 1 ) . Afterwards, the signer selects two integers e and d at random such that e d ...1; 1 ( mod [varphi] ( n ) ) . Finally, the signer publishes the public parameters ( e , n ) and a one-way hash function H .

(2) User [arrow right] Signer: α

: The user chooses a message m and a random integer r in ^{Z n *} , then blinds the message by computing α = ^{r e} H ( m ) mod ... n and sends it to the signer.

(3) Signer [arrow right] User: t

: After receiving α , the signer signs it with her/his private key d and sends it back to the user. The signed message will be t = ^{α d} mod ... n .

(4) Unblinding:

: After receiving t from the signer, the user unblinds it by computing s = ^{r - 1} t mod ... n . The signature-message pair is ( s , m ) .

(5) Verification:

: The ( s , m ) can be verified by checking if ^{s e} ...1; H ( m ) ( mod ... n ) is true or not.

2.2. Chameleon Hashing Based on Discrete Logarithm

Chameleon hashing was proposed by Krawczyk and Rabin [30]. The chameleon hash function is associated with a one-time public-private key pair; it is a collision resistant function except for users who own a trapdoor for finding collision. Any user who knows the public key can compute the hashing, and for those who do not know the private key (trapdoor), it is impossible for them to find any two inputs which lead to the same hashing output. On the contrary, any user who knows the trapdoor can find the collision of given inputs. The construction of the chameleon hashing based on discrete logarithm is described as follows.

(1) Setup :

(i) p , q : two large primes such that p = k q + 1 ,

(ii) g : an element order q in ^{Z p *} ,

(iii): x : private key in ^{Z q *} ,

(iv) y : public key, where y = ^{g x} mod p .

(2) The function : a message m ∈ ^{Z q *} is given and a random integer r ∈ ^{Z q *} is chosen. The hash is defined as cham-hash _y ( m , r ) = ^{g m y r} mod p .

(3) Collision : for a user who knows x , she/he is able to find the collision of the hash for any given m , ^{m [variant prime]} such that cham-hash _y ( m , r ) = cham-hash _y ( ^{m [variant prime]} , ^{r [variant prime]} ) . The user derives ^{r [variant prime]} in the equation m + x r = ^{m [variant prime]} + x ^{r [variant prime]} (mod q ).

3. The Proposed Date Attachable Offline Electronic Cash Scheme

In this section, we will introduce a new date attachable offline e-cash scheme. Considering the issues mentioned in Section 1, we propose a secure offline e-cash scheme with two specific kinds of date attached to the e-cash, which are expiration date and deposit date.

3.1. Outline of the Proposed Scheme

Here we are going to briefly describe the procedures of our scheme. The proposed scheme contains four protocols, withdrawal protocol, payment protocol, deposit protocol, and e-cash renewal protocol. A user withdraws an e-cash with an expiration date attached to it from the bank. A trusted computing platform (i.e., judge device ) [31, 32], as stated in the proposed scheme, is installed in the bank to hold the identity information of all users and it will further help trace users when it is needed. It is impossible for anyone except the judge to obtain any information embedded in the device [33]. Nowadays, judge device can be implemented by the technique of Trusted Platform Module (TPM) [32, 34] in practice.

Before an e-cash is deposited, the depositor attaches the deposit date on the e-cash and sends it to the bank during the deposit stage. When the bank receives an e-cash, it will perform double-spending checking to verify whether the e-cash is doubly spent or not. The bank can derive secret parameters of the user who does double-spending and let the judge revoke the anonymity of the user. Besides, when an unused e-cash is expired, a user will be able to exchange it for a new one with a new expiration date. In our scheme, for the efficiency concerns, some of the unused parameters of users can remain unchanged while exchanging for a new valid e-cash. In the following sections, we will describe our scheme in detail.

3.2. The Proposed Scheme

Firstly, we define some notations as follows.

(1) _{H 1} , _{H 2} , _{H 3} : three one-way hash functions, _{H 1} , _{H 2} , _{H 3} : { 0,1 ^{} *} [arrow right] { 0,1 ^{} n} .

(2) _{H 4} , _{H 5} : two one-way hash functions, _{H 4} , _{H 5} : { 0,1 ^{} *} [arrow right] { 0,1 ^{} q} .

(3) _{E ~ x} , _{D ~ x} : a secure symmetric cryptosystem. Plaintext is both encrypted and decrypted with a symmetric key x .

(4) _{E ^ p k} , _{D ^ s k} : a secure asymmetric cryptosystem. Plaintext is encrypted with a public key p k and decrypted with the corresponding private key s k .

(5) ( p _{k j} , s _{k j} ) : the public-private key pair of the judge.

(6) ( _{e b} , _{d b} ) : the public-private key pair of bank.

(7) D a t e : expiration date. It represents an effective spending date of a withdrawn e-cash. Any e-cash withdrawn in the same period will have the same expiration date, and vice versa.

(8) I _{D c} : the identity of user C .

(9) _{l k} , _{l r} : the security parameters.

(10) A judge device : a tamper-resistant device which is issued by the judge. It is installed into the system of the bank. It is impossible to intercept or modify any information stored in the device.

3.2.1. Initialization

Initially, the bank randomly chooses two distinct large primes ( _{p b} , _{q b} ) and computes RSA parameters _{n b} = _{p b q b} . It selects an integer _{e b} at random such that GCD ( [varphi] ( _{n b} ) , _{e b} ) = 1 , where [varphi] ( _{n b} ) = ( _{p b} - 1 ) ( _{q b} - 1 ) and 1 < _{e b} < [varphi] ( _{n b} ) . Then, it finds a _{d b} such that _{e b d b} ...1; 1 ( mod [varphi] ( _{n b} ) ) . Secondly, it also chooses two other large primes p and q and two generators _{g 1} and _{g 2} of order q in ^{Z p *} . Then, the bank publishes ( _{n b} , _{e b} , p , q , _{g 1} , _{g 2} , p _{k j} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} , E ~ , D ~ , E ^ , D ^ ) . Meanwhile, the judge embeds ( _{n b} , _{e b} , p , q , _{g 1} , _{g 2} , p _{k j} , s _{k j} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} , E ~ , D ~ , E ^ , D ^ ) into a judge device and issues it to the bank.

3.2.2. Withdrawal Protocol

Users run the withdrawal protocol with banks to get an e-cash, as shown in Figure 1, yet banks have to obtain information of users' identity, such as I _{D c} or account numbers, before the withdrawal protocol is proceeded. Therefore, users should perform an authentication with banks beforehand. Users can execute the withdrawal protocol by any devices that have the ability to compute and connect to the network. For instance, users can use mobile phones or computers to perform the withdrawal protocol and store the withdrawn e-cash. The detailed steps of the protocol are as follows.

(1) Bank [arrow right] User: D

: Firstly, the user prepares parameters for withdrawing an e-cash. The user chooses integers a , _{x 1} , _{x 2} , _{r 1} , _{r 2} , and _{r 3} in random, where a _{∈ R} ^{Z _{n b} *} and _{x 1} , _{x 2} , _{r 1} , _{r 2} , _{r 3 ∈ R} { 0,1 , ... , q - 1 } and selects a string k _{∈ R} { 0,1 ^{} _{l k}} randomly. The user then computes ( _{y 1} , _{w 1} , _{y 2} , _{w 2} ) , where _{y i} = ^{g i _{x i}} mod ... p and _{w i} = ^{g i _{r i}} mod ... p for i = { 1,2 } . Secondly, the bank computes parameters for expiration date. It randomly chooses a r in ^{Z n *} , prepares D = Date || r for some expiration date D a t e . The bank will send D to the user when she/he requests to withdraw an e-cash.

(2) User [arrow right] Bank: ( α , ... )

: After receiving D , the user prepares ... = _{E ^ p k j} ( k || _{ID c} ) and [figure omitted; refer to PDF]

: where m = ( _{y 1} || _{w 1} || _{y 2} || _{w 2} || _{r 3} ) . Finally, the user sends ( α , ... ) to the bank.

(3) Bank [arrow right] Judge device: ( ... , μ , D )

: The bank sets μ = I _{D c} , where I _{D c} is the identity of user C , and inputs it together with ... and D to the judge device.

(4) Judge device [arrow right] Bank: ( β , _{E ~ k} ( b , σ , _{r j} ) )

: The judge device decrypts ... and checks if μ = I _{D c} . If not, it returns "ID error" to the bank; or else, it picks a random integer _{b ∈ R} ^{Z _{n b} *} and a string _{r j ∈ R} { 0,1 ^{} _{l r j}} randomly. Then it computes σ = _{E ^ p k j} ( μ || _{r j} ) and [figure omitted; refer to PDF]

: Finally, it encrypts ( b , σ , _{r j} ) by using the symmetric key k and outputs it together with β to the bank.

(5) Bank [arrow right] User: ( t , _{E ~ k} ( b , σ , _{r j} ) )

: After receiving ( β , _{E ~ k} ( b , σ , _{r j} ) ) from the judge device, it computes [figure omitted; refer to PDF]

: and sends ( t , _{E ~ k} ( b , σ , _{r j} ) ) to the user.

(6) Verifications

: After receiving ( t , _{E ~ k} ( b , σ , _{r j} ) ) , the user firstly decrypts the ciphertext by using the symmetric key k in order to obtain ( b , σ , _{r j} ) . Secondly, she/he checks if his/her ID is embedded correctly by computing if σ = _{E ^ p k j} ( I _{D c} || _{r j} ) is true or not. Thirdly, she/he computes [figure omitted; refer to PDF]

: and verifies s by checking if [figure omitted; refer to PDF]

: is true or not. Finally, when all verifications are done, the user gets the e-cash tuples ( s , m , σ , D ) and stores ( _{x 1} , _{x 2} , _{r 1} , _{r 2} ) for further payment usages.

Figure 1: Withdrawal protocol.

[figure omitted; refer to PDF]

3.2.3. Payment Protocol

When a user has to spend the e-cash, she/he performs the protocol as shown in Figure 2. The steps of the protocol are described as follows.

(1) User [arrow right] Shop: ( s , m , σ , D , _{x 2} , _{r 2} )

: The user sends ( s , m , σ , D , _{x 2} , _{r 2} ) to the shop, where D contains the expiration date of the e-cash.

(2) Shop [arrow right] User: _{r s}

: The shop first checks D to verify if the e-cash is still within the expiration date or not. If not, it terminates the transaction. Otherwise, it continues to verify ^{s _{e b} H 1 2} ( m || D ) _{H 3} ( σ || D ) = _{H 2} ( D ) ( mod ... _{n b} ) . If it is not valid, the protocol is aborted; or else, it selects a string ^{r s [variant prime]} _{∈ R} { 0,1 ^{} _{l r j}} and sets a challenge _{r s} = ( I _{D s} || ^{r s [variant prime]} ) , where I _{D s} is the identity of the shop. Finally, it sends _{r s} to the user.

(3) User [arrow right] Shop: ( ^{s [variant prime]} , _{r u} )

: After receiving _{r s} from the shop, the user randomly selects a _{r u ∈ R} ^{Z q *} and computes a response to the challenge [figure omitted; refer to PDF]

: where u = _{H 4} ( _{r u} || _{r s} ) . Then, the user sends ( ^{s [variant prime]} , _{r u} ) to the shop.

(4) Verifications

: After receiving ( ^{s [variant prime]} , _{r u} ) from the user, the shop verifies if _{w 1} = ^{y 1 _{H 4} ( _{r u} || _{r s} ) g s [variant prime]} ( mod ... p ) is true or not. If it is true, the shop will accept the e-cash. On the other hand, if it is not, the shop will reject it. Since it is an offline e-cash, the shop does not have to deposit it to the bank immediately. It can store the e-cash and deposit it later together with other received e-cash(s).

Figure 2: Payment protocol.

[figure omitted; refer to PDF]

3.2.4. Deposit Protocol

As Figure 3 shows, shops attach the deposit date to their e-cash(s) and deposit them to banks in this protocol. Banks perform double-spending checks when they receive these e-cash(s). If any e-cash is double-spent, the bank will revoke the anonymity of the e-cash owner with the help of the judge. The steps are described in detail as follows.

(1) Shop [arrow right] Bank: ( s , m , σ , D , d , _{r 4} , ^{s [variant prime]} , _{r u} , _{r s} )

: The shop computes _{r 4} = _{r 2} - _{x 2 H 5} ( d ) , where d is the deposit date, and sends ( s , m , σ , D , d , _{r 4} , ^{s [variant prime]} , _{r u} , _{r s} ) to the bank.

(2) Verifications

: Firstly, the bank checks the correctness of expiration date D and deposit date d , respectively, and also checks if [figure omitted; refer to PDF]

: are true or not. Secondly, the bank verifies if ^{s _{e b} H 1 2} ( m || D ) _{H 3} ( σ || D ) = _{H 2} ( D ) ( mod ... _{n b} ) and checks the uniqueness of ( s , m , σ , D ) . Finally, if all of the above facts are verified successfully, the bank will accept and store the e-cash in its database and record _{H 1} ( m || D ) in exchange list . Otherwise, it will reject this transaction and trace the owner of the e-cash.

Figure 3: Deposit protocol.

[figure omitted; refer to PDF]

3.2.5. E-Cash Renewal Protocol

In order to reduce the unlimited growth database problem of the bank, we have expiration date and renewal protocol in our scheme to achieve it, as shown in Figure 4. When an unused e-cash is expired, the user has to exchange it for another e-cash with a new expiration date from the bank.

(1) User [arrow right] Bank: ( s , ρ , σ , D )

: The user recalls m = ( _{y 1} , _{w 1} , _{y 2} , _{w 2} , _{x 2} , _{r 3} ) and prepares [figure omitted; refer to PDF]

: and sends it together with the unused ( s , σ , D ) to the bank.

(2) Verifications

: Firstly, the bank checks the correctness of expiration date D and makes sure ρ does not exist in the exchange list . Secondly, the bank verifies if s e b H 1 ( ρ ) H 3 ( σ || D ) ...1; H 2 ( D ) ( mod ... n b ) . Finally, if all of the above facts are verified successfully, the bank will accept to exchange the e-cash. It will send a new expiration date D [variant prime] and store ρ in the exchange list . Otherwise, it will reject the exchange request.

(3) User [arrow right] Bank: ( α ^ , ... )

: The user computes [figure omitted; refer to PDF]

: where ^{m [variant prime]} = ( _{y 1} , _{w 1} , _{y 2} , _{w 2} , _{x 2} , ^{r 3 [variant prime]} ) , ^{r 3 [variant prime]} is a random, and ^{D [variant prime]} is the new expiration date issued by the bank. The user sends ( α ^ , ... , I _{D c} ) to the bank. Then the bank repeats the withdrawal protocol in Section 3.2.2 from Step 2 with the user.

Figure 4: E-Cash renewal protocol.

[figure omitted; refer to PDF]

3.2.6. Double-Spending Checking and Anonymity Control

In our scheme, the identity of the users is anonymous in general except when the users violate any security rules and, therefore, their identities will be revealed.

(1) Double-Spending Checking

: When an e-cash is being doubly spent, there must be two e-cash(s) with the same record prefixed by ( s , _{y 1} , _{w 1} , _{y 2} , _{w 2} , _{r 3} , σ , D ) stored in the database of the bank. Therefore, the bank is able to detect any double-spent e-cash easily by checking the above parameters. For instance, the bank has received two e-cash(s), [figure omitted; refer to PDF]

: Thus, the bank can obtain two equations as follows: [figure omitted; refer to PDF]

: The bank can derive ( _{x 1} , _{r 1} ) from the above equations and send ( s , _{y 1} , _{w 1} , _{y 2} , _{w 2} , _{x 2} , _{r 3} , σ , D ) and ( _{x 1} , _{r 1} ) to the judge to trace the owner of the e-cash.

(2) Revocation

: The judge can trace any user who doubly spends e-cash(s) or violates any transaction regulations. When the judge receives ( s , _{y 1} , _{w 1} , _{y 2} , _{w 2} , _{x 2} , _{r 3} , σ , D ) and ( _{x 1} , _{r 1} ) from the bank, it checks the following equations: [figure omitted; refer to PDF]

: If all of the above equalities are true, the judge will decrypt σ and return the extracted I _{D c} to the bank.

4. Security Proofs

In this section, we provide security definitions and formal proofs of the following security features: unlinkability, unforgeability, traceability, and no-swindling for our proposed date attachable offline electronic cash scheme ( D A O E C S ).

4.1. E-Cash Unlinkability

Based on the definition of unlinkability introduced by Abe and Okamoto [35] and Juels et al. [36], we formally define the unlinkability property of D A O E C S .

Definition 1 (The Linkage Game).

Let _{U 0} , _{U 1} , and J be two honest users and the judge that follows D A O E C S , respectively. Let B be the bank that participates the following game with _{U 0} , _{U 1} , and J . The game environment is shown in Figure 5.

Figure 5: The game environment of linkage game.

[figure omitted; refer to PDF]

Step 1.

According to D A O E C S , B generates the bank's public key ( _{e b} , _{n b} ) , the bank's private key ( _{d b} , _{p b} , _{q b} ) , system parameters ( p , q , _{g 1} , _{g 2} ) , the expiration date D , and the five public one-way hash functions _{H 1} , _{H 2} , _{H 3} , _{H 4} , and _{H 5} . J generates the judge's public-private key pair ( p _{k j} , s _{k j} ) .

Step 2.

B generates _{x 1 i} , _{x 2 i} , _{r 1 i} , _{r 2 i} , _{r 3 i} in random, where _{x 1} , _{x 2} , _{r 1} , _{r 2} , _{r 3 ∈ R} { 0,1 , ... , q - 1 } , and computes ( _{y k i} , _{w k i} ) for k = { 1,2 } and i = { 0,1 } , where _{y k i} = ^{g k _{x k}} mod ... p and _{w k i} = ^{g k _{r k}} mod ... p .

Step 3.

We choose a bit b ^ ∈ { 0,1 } randomly and place ( _{y 1 b ^} , _{w 1 b ^} , _{y 2 b ^} , _{w 2 b ^} ) and ( _{y 1 1 - b ^} , _{w 1 1 - b ^} , _{y 2 1 - b ^} , _{w 2 1 - b ^} ) on the private input tapes of _{U 0} and _{U 1} , respectively, where b ^ is not disclosed to B .

Step 4.

B performs the withdrawal protocol of D A O E C S with _{U 0} and _{U 1} , respectively.

Step 5.

If _{U 0} and _{U 1} output two e-cash(s) ( _{s b ^} , _{m b ^} , _{σ b ^} , _{D b ^} ) and ( _{s 1 - b ^} , _{m 1 - b ^} , _{σ 1 - b ^} , _{D 1 - b ^} ) , where _{m i} = ( _{y 1 i} , _{w 1 i} , _{y 2 i} , _{w 2 i} , _{r 3 i} ) , on their private tapes, respectively, we give the two e-cash(s) in a random order to B ; otherwise, [perpendicular] is given to B .

Step 6.

B outputs ^{b ^ [variant prime]} ∈ { 0,1 } as the guess of b ^ . The bank B wins the game if ^{b ^ [variant prime]} = b ^ and J has not revoked the anonymity of ( _{s b ^} , _{m b ^} , _{σ b ^} , _{D b ^} ) and ( _{s 1 - b ^} , _{m 1 - b ^} , _{σ 1 - b ^} , _{D 1 - b ^} ) to B . We define the advantage of B as [figure omitted; refer to PDF] where Pr [ ^{b ^ [variant prime]} = b ^ ] denotes the probability of ^{b ^ [variant prime]} = b ^ .

Definition 2 (Unlinkability).

A D A O E C S satisfies the unlinkability property if and only if the advantage Ad ^{v D A O E C S Linkability} ( B ) defined in Definition 1 is negligible.

Theorem 3.

A D A O E C S satisfies the unlinkability property of Definition 2 if the adopted cryptosystems are semantically secure.

Proof.

If B is given [perpendicular] in the Step 5 of the game, it will determine b ^ with probability 1 / 2 , which is exactly the same as a random guess of b ^ .

Here, we assume that B gets two e-cash ( _{s 0} , _{m 0} , _{σ 0} , _{D 0} ) and ( _{s 1} , _{m 1} , _{σ 1} , _{D 1} ) . Let ( _{α i} , _{β i} , _{t i} , _{... i} , _{E ~ k i} ( _{b i} , _{σ i} , _{r j i} ) ) , i ∈ { 0,1 } , be the view of data exchanged between _{U i} and B in the withdrawal protocol (Section 3.2.2) and let ( _{x 2 i} , _{r 2 i} , _{r 4 i} , _{r u i} , _{r s i} , ^{s i [variant prime]} , _{d i} ) be the view of data exchanged when B performs the payment protocol (Section 3.2.3) and the deposit protocol (Section 3.2.4) by using ( _{s i} , _{m i} , _{σ i} , _{D i} ) , where i ∈ { 0,1 } .

For ( s , m , σ , D , _{x 2} , _{r 2} , _{r 4} , _{r u} , _{r s} , ^{s [variant prime]} , d ) ∈ [figure omitted; refer to PDF] and ( _{α i} , _{β i} , _{t i} , _{... i} , _{E ~ k i} ( _{b i} , _{σ i} , _{r j i} ) ) , i ∈ { 0,1 } , there always exists a pair ( ^{a i [variant prime]} , ^{b i [variant prime]} ) such that [figure omitted; refer to PDF] And from (3), _{t i} ...1; ( _{α i β i H 2} ( D ) ^{) _{d b}} ( mod ... _{n b} ) , (4) always holds as [figure omitted; refer to PDF] Besides, _{E ^ p k j} and _{E ~ k i} are semantically secure encryption functions. B cannot learn any information from _{... i} and _{E ~ k i} ( _{b i} , _{σ i} , _{r j i} ) .

From the above, given any ( s , m , σ , D ) ∈ { ( _{s 0} , _{m 0} , _{σ 0} , _{D 0} ) , ( _{s 1} , _{m 1} , _{σ 1} , _{D 1} ) } and ( _{α i} , _{β i} , _{t i} ) , where i ∈ { 0,1 } , there always exists a corresponding pair ( ^{a i [variant prime]} , ^{b i [variant prime]} ) such that (1), (2), (3), and (4) are satisfied.

Thus, go back to Step 6 of the game, the bank B succeeds in determining b ^ with probability ( 1 / 2 ) + [straight epsilon] , where [straight epsilon] is negligible since E ^ and E ~ are semantically secure. Therefore, we have Ad ^{v D A O E C S Linkability} ( B ) = 2 [straight epsilon] , which is negligible, so that D A O E C S satisfies the unlinkability property.

4.2. E-Cash Unforgeability

In this section, we will formally prove that the proposed date attachable offline electronic cash scheme ( D A O E C S ) is secure against forgery attack. The forgery attack can be roughly divided into two types, one is the typical one-more forgery type (i.e., ( l , l + 1 ) -forgery) [37] and the other is the forgery on some specific expiration date of an e-cash after sufficient communications with the signing oracle (i.e., bank). The details of definitions and our formal proofs will be described as follows.

Definition 4 (Forgery Game 1 in D A O E C S (FG-1)).

Let _{l k} ∈ N be a security parameter and A be an adversary in D A O E C S . _{O S} is an oracle which plays the role of the bank in D A O E C S to be responsible for issuing e-cash(s) (i.e., ( s , m , σ , D ) , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ) according to the queries from A . A is allowed to query _{O S} for l times; consider the experiment ^{Exp A FG- 1} ( _{l k} ) shown in Algorithm 1. A wins the forgery game FG-1 if the probability Pr [ Ex ^{p A FG- 1} ( _{l k} ) = 1 ] of A is nonnegligible.

Algorithm 1: Experiment FG-1.

Experiment ^{E x p A FG- 1} ( _{l k} )

( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) [arrow left] Setup ( _{l k} )

{ ( _{s 1} , _{m 1} , _{σ 1} , _{D 1} ) , ... , ( _{s l + 1} , _{m l + 1} , _{σ l + 1} , _{D l + 1} ) } [arrow left] ^{A _{O S}} ( p _{k j} , _{g 1} , _{g 2} , _{e b} , _{n b} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} )

if the following checks are true, return 1;

(i) ^{s i _{e b} H 1 2} ( _{m i} ) _{H 3} ( _{σ i} || _{D i} ) ...1; _{H 2} ( _{D i} ) (mod _{n b} ), ∀ i ∈ { 1 , ... , l + 1 } ;

(ii) _{m 1} , ... , _{m l + 1} are all distinct

else return 0;

Definition 5 (Forgery Game 2 in D A O E C S (FG-2)).

Let _{l k} ∈ N be a security parameter and A be an adversary in D A O E C S . _{O S} is an oracle which plays the role of the bank in D A O E C S to take charge of the following two events:

(i) issue e-cash(s) (i.e., ( s , m , σ , D ) , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ) according to the queries from A ,

(ii) record the total number _{l D i} of each distinct expiration date _{D i} .

A is allowed to query _{O S} for l times; consider the experiment ^{Exp A FG- 2} ( _{l k} ) shown in Algorithm 2. A wins the forgery game FG-2 if the probability Pr [ Ex ^{p A FG- 2} ( k ) = 1 ] of A is nonnegligible.

Algorithm 2: Experiment FG-2.

Experiment ^{E x p A FG- 2} ( _{l k} )

( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) [arrow left] Setup ( _{l k} )

{ ( _{s i} , _{m i} , _{σ i} , ^{D *} ) , 1 ...4; i ...4; _{l ^{D *}} + 1 } [arrow left] ^{A _{O S}} ( p _{k j} , _{g 1} , _{g 2} , _{e b} , _{n b} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} )

if the following checks are true, return 1;

(i) ^{s i _{e b} H 1 2} ( _{m i} ) _{H 3} ( _{σ i} || ^{D *} ) ...1; _{H 2} ( ^{D *} ) (mod _{n b} ), ∀ i ∈ { 1 , ... , _{l ^{D *}} + 1 } ;

(ii) _{m 1} , ... , _{m l ^{D *} + 1} are all distinct;

else return 0;

Here we introduce the hard problems used in our proof models.

Definition 6 (Alternative Formulation of RSA Chosen-Target Inversion Problem (RSA-ACTI)).

Let k ∈ N be a security parameter and A be an adversary who is allowed to access the RSA-inversion oracle _{O inv} and the target oracle _{O t} . A is allowed to query _{O t} and _{O inv} for m and _{q h} times, respectively. Consider Algorithm 3.

We say A breaks the RSA-ACTI problem if the probability Pr [ Ex ^{p A RSA-ACTI} ( k ) = 1 ] of A is nonnegligible.

Algorithm 3

Experiment ^{E x p A RSA-ACTI} ( k )

( N , e , d ) [arrow left] R K e y G e n ( k ) .

( _{y 1} , ... , _{y m} ) [arrow left] _{O t} ( N , e , k )

{ π , ( _{x 1} , _{y 1} ) , ... , ( _{x n} , _{y n} ) } [arrow left] ^{A _{O inv} , _{O t}} ( N , e , k )

if the following checks are true, return 1;

(i) π : { 1 , ... , n } [arrow right] { 1 , ... , m } is injective

(ii) ^{x i e} ...1; _{y i} (mod N ), ∀ i ∈ { 1 , . . . , n }

(iii) n > _{q h}

else return 0;

Definition 7 (The RSA Inversion Problem).

Given ( e , n ) , where n is the product of two distinct large primes p and q with roughly the same length and e is a positive integer relatively-prime to ( p - 1 ) ( q - 1 ) , and a randomly-chosen positive integer y less than n , find an integer x such that ^{x e} ...1; y ( mod ... n ) .

Definition 8 (E-Cash Unforgeability).

If there exists no probabilistic polynomial-time adversary who can win FG-1 or FG-2, then D A O E C S is secure against forgery attacks.

Theorem 9.

For a polynomial-time adversary A who can win FG-1 or FG-2 with nonnegligible probability, there exists another adversary S who can break the RSA-ACTI problem or RSA inversion problem with nonnegligible probability.

Proof.

S simulates the environment and controls three hash oracles, _{O H 1} , _{O H 2} , _{O H 3} and an e-cash producing oracle _{O S} of D A O E C S scheme to respond to different queries from A in the random oracle model and takes advantage of A to solve RSA-ACTI problem or RSA inversion problem, simultaneously. Then, for consistency, S maintains three lists _{L H 1} , _{L H 2} , and _{L H 3} to record every response of _{O H 1} , _{O H 2} , and _{O H 3} , respectively.

Here we will start to do the simulation for the two games (i.e., FG-1 and FG-2) to prove D A O E C S is secure against forgery attacks. The details of simulation are set below and illustrated in Figures 6 and 7, respectively.

Simulation in FG-1 . In this proof model, S is allowed to query the oracles _{O inv} (i.e., ( · ^{) d} ) and _{O t} of RSA-ACTI problem defined in Definition 6 for helping S to produce e-cash(s) and the corresponding verifying key is ( e , n ) .

(i) _{H 1} Query of _{O H 1}

: Initially, every blank record in _{L H 1} can be represented as ( [perpendicular] , [perpendicular] , [perpendicular] ) . When A sends m for querying the hash value _{H 1} ( m ) , S will check the list _{L H 1} :

(a) if m = _{m i} for some i , then S retrieves the corresponding _{H 1} ( _{m i} ) and returns it to A ;

(b) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) ...0; [perpendicular] for some i , then S retrieves the corresponding ^{H 1 2} ( _{m i} ) and returns it to A ;

(c) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) = [perpendicular] for some i , then S queries _{O t} to get an instance y and returns it to A , then fills the record ( _{m i} , _{H 1} ( _{m i} ) , [perpendicular] ) as ( _{m i} , _{H 1} ( _{m i} ) , y ) in _{L H 1} ;

(d) otherwise, S selects a random ρ ∈ _{Z n} , records ( m , ρ , [perpendicular] ) in _{L H 1} , and returns ρ to A .

(ii) _{H 2} Query of _{O H 2}

: When A asks for _{H 2} query by sending D to S , S will look up the list _{L H 2} :

(a) if D = _{D i} for some i , the corresponding τ will be retrieved and S will send ( ^{τ e} mod ... n ) back to A ;

(b) otherwise, S will select a random τ ∈ _{Z n} , record ( D , τ ) in _{L H 2} , and return ( ^{τ e} mod ... n ) back to A .

(iii): _{H 3} Query of _{O H 3}

: While A sends ( σ , D ) to S for _{H 3} ( σ || D ) , S will look up the list _{L H 3} :

(a) if ( σ , D ) = ( _{σ i} , _{D i} ) for some i , the corresponding η will be retrieved and ( ^{η e} mod ... n ) will be returned to A ;

(b) otherwise, S will select a random η ∈ _{Z n} , record ( ( σ , D ) , η ) in _{L H 3} , and return ( ^{η e} mod ... n ) back to A .

(iv) E-Cash Producing Query of _{O S}

: When A sends ( α , ... , D ) to S , S will do the following steps:

(1) decrypt ... , obtain ( k , ID ) ;

(2) randomly select _{r j} and prepare σ = _{E ^ p k j} ( ID || _{r j} ) ;

(3) choose η _{∈ R Z n} , set _{H 3} ( σ || D ) = ( ^{η e} mod n ) , and store ( ( σ , D ) , η ) in _{L H 3} ;

(4) select b _{∈ R} ^{Z n *} and compute β = ( ^{b e η e ) - 1} mod n ;

(5) retrieve or assign τ such that _{H 2} ( D ) = ( ^{τ e} ) as the _{O H 2} query described above;

(6) send ( α β ^{τ e} ) to oracle _{O inv} to get t = ( α β ^{τ e ) d} mod ... n ;

(7) return ( t , _{E ~ k} ( b , σ , _{r j} ) ) back to A .

Eventually, assume that A can successfully output l + 1 e-cash tuples [figure omitted; refer to PDF] where _{m i} are all distinct, ∀ i , 1 ...4; i ...4; l + 1 , such that ^{s i e H 1 2} ( m ) _{H 3} ( _{σ i} || _{D i} ) = _{H 2} ( _{D i} ) ( mod ... n ) after l times to query _{O S} with nonnegligible probability _{... A} .

According to _{L H 1} , _{L H 2} , and _{L H 3} , S can compute and retrieve RSA-inversion instances ( ∀ i , 1 ...4; i ...4; l + 1 ) [figure omitted; refer to PDF] Via A querying the signing oracle _{O S} for l times (i.e., query _{O inv} for l times by S ), S can output l + 1 RSA-inversion instances [figure omitted; refer to PDF] and break the RSA-ACTI problem with nonnegligible probability at least _{... A} .

Simulation in FG-2 . Initially, S is given an instance ( y , e , n ) of RSA inversion problem defined in Definition 7 and simulates the environment as follows.

(i) _{H 1} Query of _{O H 1}

: Initially, every blank record in _{L H 1} can be represented as ( [perpendicular] , [perpendicular] , [perpendicular] ) . When A sends m for querying the hash value _{H 1} ( m ) , S will check the list _{L H 1} :

(a) if m = _{m i} for some i , then S retrieves the corresponding _{ρ i} and returns it to A ;

(b) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) ...0; [perpendicular] for some i , then S retrieves the corresponding [varsigma] and returns ( ^{[varsigma] e} mod ... n ) to A ;

(c) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) = [perpendicular] for some i , then S selects a random [varsigma] ∈ _{Z n} , returns ( ^{[varsigma] e} mod ... n ) to A , and then fills the record ( _{m i} , _{H 1} ( _{m i} ) , [perpendicular] ) as ( _{m i} , _{H 1} ( _{m i} ) , [varsigma] ) in _{L H 1} ;

(d) otherwise, S selects a random ρ ∈ _{Z n} , records ( m , ρ , [perpendicular] ) in _{L H 1} , and returns ρ to A .

(ii) _{H 2} Query of _{O H 2}

: When A asks for _{H 2} query by sending D to S , S will look up the list _{L H 2} :

(a) if D = _{D i} for some i , the corresponding τ will be retrieved and S will send ( ^{τ e} mod ... n ) back to A ;

(b) otherwise, S will select a random τ ∈ _{Z n} , record ( D , τ ) in _{L H 2} , and return ( ^{τ e} mod ... n ) back to A .

(iii): _{H 3} Query of _{O H 3}

: While A sends ( σ , D ) to S for _{H 3} ( σ || D ) , S will look up the list _{L H 3} :

(a) if ( σ , D ) = ( _{σ i} , _{D i} ) for some i , the corresponding _{H 3} ( _{σ i} || _{D i} ) will be retrieved and returned to A ;

(b) otherwise, S will select a random η ∈ _{Z n} , set _{H 3} ( σ || D ) = ( ^{η e} y mod n ), record ( ( σ , D ) , η , _{H 3} ( σ || D ) ) in _{L H 3} , and return _{H 3} ( σ || D ) back to A .

(iv) E-Cash Producing Query of _{O S}

: Let _{l D i} be a counter to record the number of queries on each expiration date _{D i} , which is initialized by 0. When A sends ( α , ... , D ) to S , S will do the following steps:

(1) decrypt ... , obtain ( k , ID ) ;

(2) randomly select _{r j} and prepare σ = _{E ^ p k j} ( ID || _{r j} ) ;

(3) choose η _{∈ R Z n} , set _{H 3} ( σ || D ) = ( α ^{η e} mod ... n ) , and store ( ( σ , D ) , [perpendicular] , ( α ^{η e} mod ... n ) ) and ( σ , D ) in _{L H 3} and _{L x} , respectively;

(4) select b _{∈ R} ^{Z n *} and compute β = ( ^{b e} α ^{η e ) - 1} mod ... n ;

(5) retrieve or assign τ such that _{H 2} ( D ) = ( ^{τ e} ) as the _{O H 2} query described above;

(6) compute t ...1; ( α β ^{τ e ) d} ...1; ( ( b η ^{) - 1} τ ) ( mod ... n );

(7) set _{l D} = _{l D} + 1 and return ( t , _{E ~ k} ( b , σ , _{r j} ) ) back to A .

Eventually, assume that A can successfully output _{l ^{D [variant prime]}} + 1 e-cash tuples for some expiration date ^{D [variant prime]} [figure omitted; refer to PDF] such that ^{s i e H 1 2} ( _{m i} ) _{H 3} ( _{σ i} || ^{D [variant prime]} ) = _{H 2} ( ^{D [variant prime]} ) ( mod ... n ), ∀ i , 1 ...4; i ...4; _{l ^{D [variant prime]}} + 1 , after _{l ^{D [variant prime]}} times to query _{O S} on ^{D [variant prime]} , with nonnegligible probability _{... A} .

Assume some ( _{σ i} , ^{D [variant prime]} ) , 1 ...4; i ...4; _{l ^{D [variant prime]}} + 1 , is not recorded in _{L x} ; then by the _{L H 1} , _{L H 2} , and _{L H 3} , S can compute and retrieve [figure omitted; refer to PDF] and solve the RSA inversion problem with nonnegligible probability at least _{... A} .

Figure 6: The proof model of FG-1.

[figure omitted; refer to PDF]

Figure 7: The proof model of FG-2.

[figure omitted; refer to PDF]

4.3. E-Cash Conditional-Traceability

In this section, we will prove that the ID information embedded in e-cash(s) cannot be replaced or moved out by any user against being traced after some misbehavior or criminals. The details of our proof model are illustrated in Figure 8.

Figure 8: The proof model of TG.

[figure omitted; refer to PDF]

Definition 10 (Tampering Game (TG)).

Let _{l k} ∈ N be a security parameter and A be an adversary in D A O E C S . _{O S} is an oracle which plays the role of bank in D A O E C S to record parameters from the queries of A and issue e-cash(s) (i.e., ( s , m , σ , D ) , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ) accordingly. A is allowed to query _{O S} for l times; consider Algorithm 4.

A wins the game if the probability Pr [ Ex ^{p A TG} ( k ) = 1 ] of A is nonnegligible.

Algorithm 4

Experiment ^{E x p A TG} ( _{l k} )

( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) [arrow left] Setup ( _{l k} )

( ^{s [variant prime]} , ^{m [variant prime]} , ^{σ [variant prime]} , ^{D [variant prime]} ) [arrow left] ^{A _{O S}} ( p _{k T A} , _{e R} , _{n R} , _{H 1} , _{H 2} )

{ _{σ 1} , ... , _{σ l} } [arrow left] _{O S}

if the following two checks are true, return 1;

(i) ^{σ [variant prime]} ∉ { _{σ 1} , ... , _{σ l} }

(ii) ^{s [variant prime] e H 1 2} ( ^{m [variant prime]} ) _{H 3} ( ^{σ [variant prime]} || ^{D [variant prime]} ) = _{H 2} ( ^{D [variant prime]} ) mod n

else return 0;

Definition 11 (E-Cash Traceability).

If there exists no probabilistic polynomial-time adversary who can win the tracing game TG, then D A O E C S satisfies the E-Cash Traceability.

Definition 12 (Alternative Formulation of RSA Known-Target Inversion Problem (RSA-AKTI)).

Let k ∈ N be a security parameter and A be an adversary who is allowed to access the RSA-inversion oracle _{O inv} and the target oracle _{O t} . A is allowed to query _{O t} and _{O inv} for _{q t} and _{q h} times ( _{q h} < _{q t} ), respectively. Consider Algorithm 5.

We say A breaks the RSA-AKTI problem if the probability Pr [ Ex ^{p A RSA-AKTI} ( k ) = 1 ] of A is nonnegligible.

Algorithm 5

Experiment ^{E x p A RSA-AKTI} ( k )

( N , e , d ) [arrow left] R K e y G e n ( k ) .

( _{y 1} , ... , _{y q t} ) [arrow left] _{O t} ( N , e , k )

{ ( _{x 1} , _{y 1} ) , ... , ( _{x q t} , _{y q t} ) } [arrow left] ^{A _{O inv} , _{O t}} ( N , e , k )

if ^{x i e} ...1; _{y i} (mod N ), ∀ i ∈ { 1 , ... , _{q t} } , return 1;

else return 0;

Theorem 13.

For a polynomial-time adversary A who can win the tracing game TG with nonnegligible probability, there exists another adversary S who can break the RSA-AKTI problem with nonnegligible probability.

Proof.

S simulates the environment of D A O E C S by controlling three hash oracles, _{O H 1} , _{O H 2} , _{O H 3} , to respond hash queries and an e-cash producing oracle _{O S} of D A O E C S to respond e-cash producing queries from A , respectively, in the random oracle model. Eventually, S will take advantage of A 's capability to solve RSA-AKTI problem. Then, for consistency, S maintains three lists _{L H 1} , _{L H 2} , and _{L H 3} to record every response of _{O H 1} , _{O H 2} , and _{O H 3} , respectively.

Besides, in the proof model, S is allowed to query the oracles _{O inv} (i.e., ( · ^{) d} ) and _{O t} of the RSA-AKTI problem defined in Definition 12 for helping S produce valid e-cash(s) and the corresponding verifying key is ( e , n ) .

Here we will do the simulation for game TG to prove that D A O E C S satisfies the e-cash traceability. Details are described as follows.

(i) _{H 1} Query of _{O H 1}

: Initially, every blank record in _{L H 1} can be represented as ( [perpendicular] , [perpendicular] , [perpendicular] ) . When A sends m for querying the hash value _{H 1} ( m ) , S will check the list _{L H 1} :

(a) if m = _{m i} for some i , then S retrieves the corresponding _{H 1} ( _{m i} ) and return it to A ;

(b) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) ...0; [perpendicular] for some i , then S retrieves the corresponding _{[varsigma] i} and returns ( ^{[varsigma] i e} mod ... n ) to A ;

(c) else if m = _{H 1} ( _{m i} ) and ^{H 1 2} ( _{m i} ) = [perpendicular] for some i , then S chooses [varsigma] _{∈ R Z n} , sets ^{H 1 2} ( _{m i} ) = ( ^{[varsigma] e} mod ... n ), and returns ^{H 1 2} ( _{m i} ) to A then fills the original record ( _{m i} , _{H 1} ( _{m i} ) , [perpendicular] ) as ( _{m i} , _{H 1} ( _{m i} ) , [varsigma] ) in _{L H 1} ;

(d) otherwise, S selects a random ρ ∈ _{Z n} , sets _{H 1} ( _{m i} ) = ρ , records ( m , _{H 1} ( _{m i} ) , [perpendicular] ) in _{L H 1} , and returns ρ to A .

(ii) _{H 2} Query of _{O H 2}

: When A asks for _{H 2} query by sending D to S , S will look up the list _{L H 2} :

(a) if D = _{D i} for some i , the corresponding τ will be retrieved and S will send ( ^{τ e} mod ... n ) back to A ;

(b) otherwise, S will select a random τ ∈ _{Z n} , record ( D , τ ) in _{L H 2} , and return ( ^{τ e} mod ... n ) back to A .

(iii): _{H 3} Query of _{O H 3}

: While A sends ( σ , D ) to S for _{H 3} ( σ ) , S will look up the list _{L H 3} :

(a) if ( σ , D ) = ( _{σ i} , _{D i} ) for some i , the corresponding _{y i} will be retrieved and returned to A ;

(b) otherwise, S will query _{O t} to get an instance y ; record y and ( ( σ , D ) , y ) in _{L T} and _{L H 3} , respectively;

(c) return y back to A .

(iv) E-Cash Producing Query of _{O S}

: While A sends ( α , ... , D ) to S , S will do the following steps:

(1) decrypt ... , obtain ( k , ID ) ;

(2) randomly select _{r j} and prepare σ = _{E ^ p k j} ( ID || _{r j} ) ;

(3) choose η _{∈ R Z n} , set _{H 3} ( σ || D ) = ( α ^{η e} mod ... n ) , and store ( ( σ , D ) , _{H 3} ( σ || D ) ) in _{L H 3} ;

(4) select b _{∈ R} ^{Z n *} and compute β = ( ^{b e} α ^{η e ) - 1} mod ... n ;

(5) retrieve or assign τ such that _{H 2} ( D ) = ( ^{τ e} ) as the _{O H 2} query described above;

(6) compute t ...1; ( α β ^{τ e ) d} ...1; ( ( b η ^{) - 1} τ ) ( mod ... n );

(7) return ( t , _{E ~ k} ( b , σ , _{r j} ) ) back to A .

Assume that A can successfully output an e-cash tuples ( ^{s [variant prime]} , ^{m [variant prime]} , ^{σ [variant prime]} , ^{D [variant prime]} ) , where ^{σ [variant prime]} never appeals as a part for some _{O S} query such that ^{s [variant prime] e H 1 2} ( ^{m [variant prime]} ) _{H 3} ( ^{σ [variant prime]} || ^{D [variant prime]} ) ...1; _{H 2} ( ^{D [variant prime]} ) ( mod ... n ); then by _{L H 1} , _{L H 2} , and _{L H 3} , S can derive [figure omitted; refer to PDF] Let | _{L T} | = _{q t} and _{L T} = { _{y 1} , ... , _{y q t} } . S sends _{y i} ∈ ( _{L T} - { ^{y [variant prime]} } ) , 1 ...4; i ...4; ( _{q t} - 1 ) , to _{O inv} and obtains _{q t} - 1 _{x i} such that _{x i} = ^{y i d} mod ... n .

Eventually S can output _{q t} RSA-inversion instances [figure omitted; refer to PDF] after querying _{O inv} for _{q h} times, where _{q h} = _{q t} - 1 < _{q t} and thus, it breaks the RSA-AKTI problem with nonnegligible probability at least _{... A} .

4.4. E-Cash No-Swindling

In typical online e-cash transactions, when an e-cash has been spent in previous transactions, another spending will be detected immediately owing to the double-spending check procedure. However, in an offline e-cash model, the merchant may accept a transaction involving a double-spent e-cash first and then do the double-spending check later. In this case, the original owner of the e-cash may suffer from loss. Therefore, a secure offline e-cash scheme should guarantee the following two events.

(i) No one, except the real owner, can spend a fresh and valid offline e-cash successfully.

(ii) No one can double spend an e-cash successfully.

Roughly, it can be referred to as e-cash no-swindling property. In this section, we will define the no-swindling property and formally prove that our scheme is secure against swindling attacks.

Definition 14 (Swindling Game in D A O E C S ).

Let _{l k} ∈ N be a security parameter and A be an adversary in D A O E C S . _{O B} is an oracle issuing generic e-cash(s) (i.e., ( s , _{y 1} , _{w 1} , _{x 2} , _{r 2} , _{r 3} , σ , D ) ) of D A O E C S to A . _{O off ...} is an oracle to show the expanding form ( s , _{y 1} , _{w 1} , _{x 2} , _{r 2} , _{r 3} , σ , D , _{r s} , ^{s [variant prime]} ) for the payment according to the input ( s , m , σ , D ) . Consider the two experiments SWG-1 and SWG-2 shown in Algorithms 6 and 7, respectively.

A wins the game if the probability Pr [ Ex ^{p A SWG- 1} ( _{l k} ) = 1 ] or Pr [ Ex ^{p A SWG- 2} ( _{l k} ) = 1 ] of A is nonnegligible.

Algorithm 6: Experiment SWG-1.

Experiment ^{E x p A SWG- 1} ( _{l k} )

( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , p , q , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) [arrow left] Setup ( _{l k} )

{ ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) } [arrow left] ^{A _{O B} , _{O off ...}} ( p _{k j} , _{g 1} , _{g 2} , _{e b} , _{n b} , p , q , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} )

if the following checks are true, return 1;

(i) ^{s _{e b} H 1 2} ( ^{y _{H 4} ( _{r u} || _{r s} ) g s [variant prime]} mod ... p || _{y 1} || _{w 2} || _{y 2} || D || _{r 3} ) _{H 3} ( σ || D ) = _{H 2} ( D ) mod _{n b} ;

(ii) ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D ) never be a query to _{O off ...}

else return 0;

Algorithm 7: Experiment SWG-2.

Experiment ^{E x p A SWG- 2} ( _{l k} )

( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , p , q , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) [arrow left] Setup ( _{l k} )

{ ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) } [arrow left] ^{A _{O B} , _{O off ...}} ( p _{k j} , _{g 1} , _{g 2} , _{e b} , _{n b} , p , q , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} )

if the following checks are true, return 1;

(i) ^{s _{e b} H 1 2} ( ^{y _{H 4} ( _{r u} || _{r s} ) g s [variant prime]} mod ... p || _{y 1} || _{w 2} || _{y 2} || D || _{r 3} ) _{H 3} ( σ || D ) = _{H 2} ( D ) mod _{n b} ;

(ii) ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D ) is allowed to be queried to _{O off ...} for once;

(iii) ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r s} , ^{s [variant prime]} ) is not obtained from _{O off ...}

else return 0;

Definition 15 (E-Cash No-Swindling).

If there exists no probabilistic polynomial-time adversary who can win the swindling game defined in Definition 14, then D A O E C S satisfies e-cash no-swindling.

Theorem 16.

For a polynomial-time adversary A who can win the swindling game SWG with nonnegligible probability, there exists another adversary S who can solve the discrete logarithm problem with nonnegligible probability.

Proof.

Consider the swindling game defined in Definition 14. S simulates the environment by controlling the hash oracles, _{O H 4} , to respond hash queries on _{H 4} of D A O E C S in the random oracle model. Eventually, S will take advantage of A 's capability to solve the discrete logarithm problem. Then, for consistency, S maintains a list _{L H 4} to record every response of _{O H 4} . S is given all parameters ( p _{k j} , s _{k j} , _{g 1} , _{g 2} , _{e b} , _{d b} , _{p b} , _{q b} , _{n b} , p , q , _{H 1} , _{H 2} , _{H 3} , _{H 4} , _{H 5} ) of D A O E C S and an instance ^{y *} of discrete logarithm problem (i.e., ^{y *} = ^{g x *} mod ... p ). Here we will describe the simulations for the two experiments ^{Exp A SWG- 1} and ^{Exp A SWG- 2} , individually.

The simulation for ^{Exp A SWG- 1} is illustrated in Figure 9 and each oracle is constructed as follows.

(i) Oracle _{O B}

: Initially, S guesses that the generic e-cash produced from ν th query will be the attack target. When A sends i th query to _{O B} for an e-cash, _{O B} will do the following:

(a) select _{r 1} , _{x 1} , _{r 3 ∈ R Z q} and _{y 2} , _{w 2 ∈ R Z p} ;

(b) if i = ν ,

(1) compute ( _{w 1} = ( ^{y * ) _{r 1}} mod ... p ) and ( _{y 1} = ^{g _{x 1}} mod ... p );

(c) if i ...0; ν ,

(1) compute ( _{w 1} = ^{g _{r 1}} mod ... p ) and ( _{y 1} = ^{g _{x 1}} mod ... p );

(d) prepare s = ( ( ^{H 1 2} ( m ) _{H 3} ( σ || D ) ^{) - 1} _{H 2} ( D ) ^{) _{d b}} mod ... _{n b} , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ;

(e) record ( i , ( s , m , σ , D ) , ( _{r 1} , _{x 1} ) ) ) in list _{L B} and return ( s , m , σ , D ) to A .

(ii) Oracle _{O off ...}

: When A sends a valid e-cash tuple ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r s} ) to _{O off ...} , it will look up the list _{L B} :

(a) if ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D ) exists with prefix index ν , then abort;

(b) otherwise, _{O off ...} will retrieve the corresponding ( _{r 1} , _{x 1} ) ; choose a random _{r u} , compute u = _{H 4} ( _{r u} || _{r s} ) and ( ^{s [variant prime]} = _{r 1} - u _{x 1} mod ... q ), and send ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) back to A .

Assume that A can successfully output a valid offline e-cash expansion tuple ( ^{s *} , ^{w 1 *} , ^{y 1 *} , ^{w 2 *} , ^{y 2 *} , ^{r 3 *} , ^{σ *} , ^{D *} , ^{r u *} , ^{r s *} , ^{s [variant prime] *} ) , where ( ^{s *} , ^{w 1 *} , ^{y 1 *} , ^{w 2 *} , ^{y 2 *} , ^{r 3 *} , ^{σ *} , ^{D *} ) is prefixed with ν and postfixed with ( ^{r 1 *} , ^{x 1 *} ) in _{L B} . Then, since ^{w 1 *} = ^{y 1 * _{H 4} ( r u * || r s * ) g s [variant prime] *} mod ... p and ^{w 1 *} = ( ^{y * ) r 1 *} , S can derive [figure omitted; refer to PDF] and solve the discrete logarithm problem with nonnegligible probability at least ( 1 / _{q O B} ) _{... A} , where _{q O B} is the total number of _{O B} query.

The simulation for ^{Exp A SWG- 2} is illustrated in Figure 10 and each oracle is constructed as follows.

(i) Oracle _{O B}

: Initially, S guesses that the generic e-cash produced from ν th query will be the attack target. When A sends i th query to _{O B} for an e-cash, _{O B} will do the followings.

(a) if i = ν :

(1) select ^{s [variant prime]} , u , _{x 1} , _{r 3 ∈ R Z q} and _{y 2} , _{w 2 ∈ R Z p} ;

(2) compute ( _{y 1} = ( ^{y * ) _{x 1}} mod ... p ) and ( _{w 1} = ^{y 1 u g s [variant prime]} mod ... p );

(3) prepare s = ( ( ^{H 1 2} ( m ) _{H 3} ( σ || D ) ^{) - 1} _{H 2} ( D ) ^{) _{d b}} mod ... _{n b} , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ;

(4) record ( i , ( s , m , σ , D ) , ( u , ^{s [variant prime]} ) ) ) in list _{L B} ;

(b) if i ...0; ν :

(1) select _{r 1} , _{x 1} , _{r 3 ∈ R Z q} and _{y 2} , _{w 2 ∈ R Z p} ;

(2) compute ( _{w 1} = ^{g _{r 1}} mod ... p ) and ( _{y 1} = ^{g _{x 1}} mod ... p );

(3) prepare s = ( ( ^{H 1 2} ( m ) _{H 3} ( σ || D ) ^{) - 1} _{H 2} ( D ) ^{) _{d b}} mod ... _{n b} , where m = ( _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , D ) ;

(4) record ( i , ( s , m , σ , D ) , ( _{r 1} , _{x 1} ) ) ) in list _{L B} ;

(c) return ( s , m , σ , D ) to A .

(ii) Oracle _{O off ...}

: A status parameter sta is initialized by 0. When A sends a valid e-cash tuple ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r s} ) to _{O off ...} , it will look up the list _{L B} :

(a) if ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D ) exists with prefix index ν and sta = 0 , _{O off ...} will perform the following procedures:

(1) set sta = 1

(2) retrieve the corresponding ( u , ^{s [variant prime]} ) from _{L B} and choose a random _{r u} ;

(3) set _{H 4} ( _{r u} || _{r s} ) = u and record ( ( _{r u} || _{r s} ) , u ) in _{L H} ;

(4) record ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) in list _{L off ...} ;

(5) send ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) back to A ;

(b) if ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D ) exists with prefix index ...0; ν , _{O off ...} will retrieve the corresponding ( _{r 1} , _{x 1} ) , choose random _{r u} and u , set _{H 4} ( _{r u} || _{r s} ) = u , record ( ( _{r u} || _{r s} ) , u ) in _{L H} , compute ( ^{s [variant prime]} = _{r 1} - u _{x 1} mod ... q ), and send ( s , _{w 1} , _{y 1} , _{w 2} , _{y 2} , _{r 3} , σ , D , _{r u} , _{r s} , ^{s [variant prime]} ) back to A .

(c) Otherwise, abort.

(iii): Oracle _{O H 4}

: While A sends ( _{r u} || _{r s} ) to query for _{H 4} ( _{r u} || _{r s} ) , _{O H 4} will check the list _{L H} :

(a) if ( _{r u} || _{r s} ) exists as the prefix of some record, _{O H 4} will retrieve the corresponding u and return it to A ;

(b) otherwise, _{O H 4} will choose a random u , record ( ( _{r u} || _{r s} ) , u ) in _{L H} , and return u to A .

Assume that A can successfully output a valid offline e-cash expansion tuple ( ^{s *} , ^{w 1 *} , ^{y 1 *} , ^{w 2 *} , ^{y 2 *} , ^{r 3 *} , ^{σ *} , ^{D *} , ^{r u *} , ^{r s *} , ^{s [variant prime] *} ) , where ( ^{s *} , ^{w 1 *} , ^{y 1 *} , ^{w 2 *} , ^{y 2 *} , ^{r 3 *} , ^{σ *} , ^{D *} ) is prefixed with ν and postfixed with ( u , ^{s [variant prime]} ) in _{L B} and _{H 4} ( ^{r u *} || ^{r s *} ) ...0; u .

Then, via _{L H} , since [figure omitted; refer to PDF]

S can derive [figure omitted; refer to PDF] and solve the discrete logarithm problem with nonnegligible probability at least ( 1 / _{q O B} ) _{... A} , where _{q O B} is the total number of _{O B} query.

Figure 9: The proof model of SWG-1.

[figure omitted; refer to PDF]

Figure 10: The proof model of SWG-2.

[figure omitted; refer to PDF]

Summarize the proof models for the two experiments shown above, if there exists a polynomial-time adversary who can win the swindling game with nonnegligible probability, then there exists another one who can solve the discrete logarithm problem with nonnegligible probability. It implies that there exists no p.p.t. adversary who can win the swindling game, and our proposed offline e-cash scheme D A O E C S satisfies no-swindling property.

5. E-Cash Advanced Features and Performance Comparisons

In this section, we compare the e-cash features and performance of our proposed scheme with other schemes given in [9, 13-15, 21, 22, 27, 38-40]. We analyze the features and performance of the aforementioned schemes and form a table (Table 1) for the summary.

Table 1: Advanced features and performance comparisons.

	Ours	[38]	[14]	[15]	[9]	[21]	[22]	[39]	[40]	[13]	[27]
Advanced features
On/off-line	Off	Off	Off	Off	On	Off	Off	Off	Off	On	Off
Conditional-traceability	Yes	Yes	No	Yes	No	Yes	Yes	Yes	Yes	Yes	No
Date attachability	Yes	No	No	No	Yes	Yes	No	No	No	No	Yes
No-swindling	Yes	No	No	No	--	No	Yes	No	No	--	No
Renewal protocol	Yes	--	Yes	--	No	Yes	Yes	--	--	--	Yes
Formal proof	Yes	Yes	No	Yes	No	No	Yes	Yes	Yes	Yes	No
Performance
Transaction cost *	5 E + 7 M + 7 H + 1 inv + 1 A [approximate] 1454 M	14 E + 14 M + 1 H + 5 A [approximate] 3375 M	6 E + 8 M [approximate] 1448 M	23 E + 14 M + 1 A [approximate] 5534 M	2 E + 2 M + 2 H [approximate] 966 M	5 E + 9 M + 1 H + 1 inv + 2 A [approximate] 1450 M	2 E [approximate] 480 M	18 E + 15 M + 2 H + 8 A [approximate] 4337 M	31 E + 22 M + 6 H + 10 A [approximate] 7468 M	22 E + 11 M + 4 A [approximate] 5291 M	6 E + 8 M + 1 H [approximate] 1449 M
Communication cost [open diamond]	1092	576	1288	939	769	644	300	828	968	1536	728

According to [41], H [approximate] M , E [approximate] inv [approximate] 240 M .

E : a modular exponentiation; M : a modular multiplication; H : a hash operation; zkp: a zero-knowledge proof.

A : a modular addition; inv : a modular inversion.

^* The computation cost of withdrawal and payment protocols at user side.

^{[open diamond]} The communication cost of each transaction at user side in bytes.

5.1. Features Comparisons

All the schemes mentioned above fulfill the basic security requirements stated in Section 1, which are anonymity, unlinkability, unforgeability, and no double-spending. Besides these features, there can be other advanced features on an e-cash system discussed in the literatures. We focus on three other advanced features, which are traceability, date attachability, and no-swindling, and we compare the proposed scheme with the aforementioned schemes.

We also propose an e-cash renewal protocol for users to exchange a new valid e-cash with their unused but expired e-cash(s); therefore, users do not have to deposit the e-cash before it expires and withdraw a new e-cash again. Our proposed e-cash renewal protocol reduces the computation cost by 49.5% as compared to withdrawal and deposit protocols, which is almost half of the effort of getting a new e-cash, at the user side. It does a great help to the users since their devices usually have a weaker computation capability, such as smart phones.

5.2. Performance Comparisons

According to [41], we can summarize and induce the computation cost of all operations as follows. The computation cost of a modular exponentiation computation is about 240 times of the computation cost of a modular multiplication computation, while the computation cost of a modular inversion almost equals to that of a modular exponentiation. Also, the computation cost of a hash operation almost equals to that of a modular multiplication.

With the above assumptions, the total computation cost of users during withdrawal and payment phases of our proposed scheme can be induced as 1452 times of a modular multiplication computation, while other works [9, 13-15, 21, 22, 27, 38-40] need 3375, 1448, 5534, 966, 1450, 480, 4337, 7468, 5291, and 1449 times of a modular multiplication computation to finish withdrawal and payment phases at the user ends.

According to [15], we assume the RSA parameters n , p , q are 1024, 512, and 512 bits, respectively. We adopt AES and SHA-1 as the symmetric cryotsystem and one-way hash function used in all protocols, respectively; therefore, the signed message and hash massage are in 128 and 160 bits, respectively. We assume the expiration date is in 32 bits.

With the above assumptions, we compute the communication cost of each offline transaction, withdrawal, and payment, at the user side. Our scheme needs 2048 bits for withdrawing an e-cash and 6688 bits for spending an e-cash, which is 1092 bytes for each transaction.

The details of the comparisons are summarized in Table 1.

6. Conclusion

In this paper, we have presented earlier a provably secure offline electronic cash scheme with an expiration date and a deposit date attached to it. Besides, we have also designed an e-cash renewal protocol, where users can exchange their unused and expired e-cash(s) for new ones more efficiently. Compared with other similar works, our scheme is efficient from the aspect of considering computation cost of the user side and satisfying all security properties, simultaneously. Except for anonymity, unlinkability, unforgeability, and no double-spending, we also formally prove that our scheme achieves conditional-traceability and no-swindling. Not only does our scheme help the bank to manage their huge databases against unlimited growth, but also it strengthens the preservation of users' privacy and rights as well.

Acknowledgments

This work was partially supported by the National Science Council of Taiwan under Grants NSC 102-2219-E-110-002, NSYSU-KMU Joint Research Project (NSYSUKMU 2013-I001), and Aim for the Top University Plan of the National Sun Yat-sen University and Ministry of Education, Taiwan.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

References

[1] H. Chen, P. P. Y. Lam, H. C. B. Chan, T. S. Dillon, J. Cao, R. S. T. Lee, "Business-to-consumer mobile agent-based internet commerce system (MAGICS)," IEEE Transactions on Systems, Man and Cybernetics C: Applications and Reviews , vol. 37, no. 6, pp. 1174-1189, 2007.

[2] S. C. Fan, Y. L. Lai, "A study on e-commerce applying in Taiwan's restaurant franchise," in Proceedings of the IET International Conference on Frontier Computing. Theory, Technologies and Applications, pp. 324-329, August 2010.

[3] D. R. W. Holton, I. Nafea, M. Younas, I. Awan, "A class-based scheme for E-commerce web servers: formal specification and performance evaluation," Journal of Network and Computer Applications , vol. 32, no. 2, pp. 455-460, 2009.

[4] Z. Jie, X. Hong, "E-commerce security policy analysis," in Proceedings of the International Conference on Electrical and Control Engineering (ICECE '10), pp. 2764-2766, June 2010.

[5] D. R. Liuy, T. F. Hwang, "An agent-based approach to flexible commerce in intermediary-Centric electronic markets," Journal of Network and Computer Applications , vol. 27, no. 1, pp. 33-48, 2004.

[6] S. J. Lin, D. C. Liu, "An incentive-based electronic payment scheme for digital content transactions over the Internet," Journal of Network and Computer Applications , vol. 32, no. 3, pp. 589-598, 2009.

[7] H. Wang, Y. Zhang, J. Cao, V. Varadharajan, "Achieving Secure and Flexible M-Services through Tickets," IEEE Transactions on Systems, Man, and Cybernetics A:Systems and Humans , vol. 33, no. 6, pp. 697-708, 2003.

[8] C. Yue, H. Wang, "Profit-aware overload protection in E-commerce Web sites," Journal of Network and Computer Applications , vol. 32, no. 2, pp. 347-356, 2009.

[9] C. C. Chang, Y. P. Lai, "A flexible date-attachment scheme on e-cash," Computers and Security , vol. 22, no. 2, pp. 160-166, 2003.

[10] C. L. Chen, J. J. Liao, "A fair online payment system for digital content via subliminal channel," Electronic Commerce Research and Applications , vol. 10, no. 3, pp. 279-287, 2011.

[11] C. I. Fan, W. K. Chen, Y. S. Yeh, "Date attachable electronic cash," Computer Communications , vol. 23, no. 4, pp. 425-428, 2000.

[12] C. I. Fan, W. Z. Sun, "Efficient encoding scheme for date attachable electronic cash," in Proceedings of the 24th Workshop on Combinatorial Mathematics and Computation Theory, pp. 405-410, 2007.

[13] T. Nakanishi, M. Shiota, Y. Sugiyama, "An efficient online electronic cash with unlinkable exact payments," Information Security , vol. 3225, of Lecture Notes in Computer Science, pp. 367-378, 2004.

[14] Y. Baseri, B. Takhtaei, J. Mohajeri, "Secure untraceable off-line electronic cash system," Scientia Iranica , vol. 20, pp. 637-646, 2012.

[15] J. Camenisch, S. Hohenberger, A. Lysyanskaya, "Compact e-cash," in Proceedings of the 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques: Advances in Cryptology (EUROCRYPT '05), pp. 302-321, May 2005.

[16] J. Camenisch, S. Hohenberger, A. Lysyanskaya, "Balancing accountability and privacy using E-cash," Security and Cryptography for Networks , vol. 4116, of Lecture Notes in Computer Science, pp. 141-155, 2006.

[17] J. Camenisch, A. Lysyanskaya, M. Meyerovich, "Endorsed e-cash," in Proceedings of the IEEE Symposium on Security and Privacy, pp. 101-115, May 2007.

[18] S. Canard, A. Gouget, J. Traoré, "Improvement of efficiency in (unconditional) anonymous transferable E-cash," Financial Cryptography and Data Security , vol. 5143, of Lecture Notes in Computer Science, pp. 202-214, 2008.

[19] D. Chaum, A. Fiat, M. Naor, "Untraceable electronic cash," Advances in Cryptology-CRYPTO '88 , vol. 403, of Lecture Notes in Computer Science, pp. 319-327, Springer, Berlin, Germany, 1990.

[20] G. Davida, Y. Frankel, Y. Tsiounis, M. Yung, "Anonymity control in E-cash systems," in Proceedings of the First International Conference on Financial Cryptography, pp. 1-16, 1997.

[21] Z. Eslami, M. Talebi, "A new untraceable off-line electronic cash system," Electronic Commerce Research and Applications , vol. 10, no. 1, pp. 59-66, 2011.

[22] C. I. Fan, V. S. M. Huang, Y. C. Yu, "User efficient recoverable off-line e-cash scheme with fast anonymity revoking," Mathematical and Computer Modelling , vol. 58, pp. 227-237, 2013.

[23] X. Hou, C. H. Tan, "Fair traceable off-line electronic cash in wallets with observers," in Proceedings of the 6th International Conference on Advanced Communication Technology, pp. 595-599, February 2004.

[24] X. Hou, C. H. Tan, "A new electronic cash model," in Proceedings of the International Conference on Information Technology: Coding and Computing, pp. 374-379, April 2005.

[25] W. S. Juang, "A practical anonymous off-line multi-authority payment scheme," Electronic Commerce Research and Applications , vol. 4, no. 3, pp. 240-249, 2005.

[26] J. K. Liu, V. K. Wei, S. H. Wong, "Recoverable and untraceable e-cash," in International Conference on Trends in Communications (EUROCON '01), vol. 1, pp. 132-135, 2001.

[27] C. Wang, H. Sun, H. Zhang, Z. Jin, "An improved off-line electronic cash scheme," in Proceedings of the 5th International Conference on Computational and Information Sciences (ICCIS '13), pp. 438-441, 2013.

[28] W. S. Juang, "D-cash: a flexible pre-paid e-cash scheme for date-attachment," Electronic Commerce Research and Applications , vol. 6, no. 1, pp. 74-80, 2007.

[29] D. Chaum, "Blind signatures for untraceable payments," Advances in Cryptology-CRYPTO '82 , of Lecture Notes in Computer Science, pp. 199-203, Springer, Berlin, Germany, 1983.

[30] H. Krawczyk, T. Rabin, "Chameleon signatures," in Proceedings of the Network and Distributed System Security Symposium (NDSS '00), pp. 143-154, 2000.

[31] S. Pearson Trusted Computing Platforms: TCPA Technology in Context , Prentice Hall, New York, NY, USA, 2002.

[32] S. Pearson, "Trusted computing platforms: the next security solution,", no. HPL-2002-221, Hewllet-Packard Laboratorie, 2002.

[33] C. I. Fan, V. S. M. Huang, "Provably secure integrated on/off-line electronic cash for flexible and efficient payment," IEEE Transactions on Systems, Man and Cybernetics C: Applications and Reviews , vol. 40, no. 5, pp. 567-579, 2010.

[34] S. Bajikar Trusted platform module (TPM) based security on notebook pcs--white paper, Mobile Platform Group, Intel Corporation, 2002

[35] M. Abe, T. Okamoto, "Provably secure partially blind signatures," in Proceedings of the 20th Annual International Cryptology Conference on Advances in Cryptology (CRYPTO '00), pp. 271-286, Springer, 2000.

[36] A. Juels, M. Luby, R. Ostrovsky, "Security of blind digital signatures," in Proceedings of the 17th Annual International Cryptology Conference on Advances in Cryptology (CRYPTO '97), pp. 150-164, Springer, 1997.

[37] M. Bellare, C. Namprempre, D. Pointcheval, M. Semanko, "The one-more-RSA-inversion problems and the security of chaum's blind signature scheme," Journal of Cryptology , vol. 16, no. 3, pp. 185-215, 2003.

[38] S. Brands, "Untraceable off-line cash in wallets with observers (extended abstract)," CRYPTO , pp. 302-318, 1993.

[39] Y. Hanatani, Y. Komano, K. Ohta, N. Kunihiro, "Provably secure electronic cash based on blind multisignature schemes," Financial Cryptography , vol. 4107, of Lecture Notes in Computer Science, pp. 236-250, 2006.

[40] C. Popescu, "An off-line electronic cash system with revokable anonymity," in Proceedings of the 12th IEEE Mediterranean Electrotechnical Conference, pp. 763-767, May 2004.

[41] A. Menezes, P. van Oorschot, S. Vanstone Handbook of Applied Cryptography , CRC Press, New York, NY, USA, 1997.