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.

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 and , then computes and . Afterwards, the signer selects two integers and at random such that mod . Finally, the signer publishes the public parameters and a one-way hash function .(2)User Signer:  The user chooses a message and a random integer in , then blinds the message by computing and sends it to the signer.(3)Signer User:  After receiving , the signer signs it with her/his private key and sends it back to the user. The signed message will be .(4)Unblinding: After receiving from the signer, the user unblinds it by computing . The signature-message pair is .(5)Verification: The can be verified by checking if () 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), : two large primes such that ,(ii): an element order in ,(iii): private key in ,(iv): public key, where mod .(2) The function: a message is given and a random integer is chosen. The hash is defined as CHAM-HASH_y mod .(3) Collision: for a user who knows , she/he is able to find the collision of the hash for any given , such that CHAM-HASH_y CHAM-HASH_y. The user derives in the equation (mod ).

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): three one-way hash functions, .(2): two one-way hash functions,  : .(3), : a secure symmetric cryptosystem. Plaintext is both encrypted and decrypted with a symmetric key .(4): a secure asymmetric cryptosystem. Plaintext is encrypted with a public key and decrypted with the corresponding private key .(5): the public-private key pair of the judge.(6): the public-private key pair of bank.(7): 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): the identity of user .(9), : 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 and computes RSA parameters . It selects an integer at random such that GCD, where and . Then, it finds a such that mod . Secondly, it also chooses two other large primes and and two generators and of order in . Then, the bank publishes . Meanwhile, the judge embeds 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 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 User:  Firstly, the user prepares parameters for withdrawing an e-cash. The user chooses integers , , , , , and in random, where and , , , , and selects a string randomly. The user then computes , where and for . Secondly, the bank computes parameters for expiration date. It randomly chooses a in , prepares for some expiration date . The bank will send to the user when she/he requests to withdraw an e-cash.(2)User Bank:  After receiving , the user prepares and  where . Finally, the user sends to the bank.(3)Bank Judge device:  The bank sets , where is the identity of user , and inputs it together with and to the judge device.(4)Judge device Bank:  The judge device decrypts and checks if . If not, it returns “ID error” to the bank; or else, it picks a random integer and a string randomly. Then it computes and  Finally, it encrypts by using the symmetric key and outputs it together with to the bank.(5)Bank User:  After receiving from the judge device, it computes  and sends to the user.(6)Verifications After receiving , the user firstly decrypts the ciphertext by using the symmetric key in order to obtain . Secondly, she/he checks if his/her ID is embedded correctly by computing if is true or not. Thirdly, she/he computes   and verifies by checking if  is true or not. Finally, when all verifications are done, the user gets the e-cash tuples and stores for further payment usages.

Figure 1 

Withdrawal protocol.

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 Shop:  The user sends to the shop, where contains the expiration date of the e-cash.(2)Shop User:  The shop first checks 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 . If it is not valid, the protocol is aborted; or else, it selects a string and sets a challenge , where is the identity of the shop. Finally, it sends to the user.(3)User Shop:  After receiving from the shop, the user randomly selects a and computes a response to the challenge  where . Then, the user sends to the shop.(4)Verifications After receiving from the user, the shop verifies if 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.

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 Bank:  The shop computes , where is the deposit date, and sends to the bank.(2)Verifications Firstly, the bank checks the correctness of expiration date and deposit date , respectively, and also checks if  are true or not. Secondly, the bank verifies if and checks the uniqueness of . Finally, if all of the above facts are verified successfully, the bank will accept and store the e-cash in its database and record in exchange list. Otherwise, it will reject this transaction and trace the owner of the e-cash.

Figure 3 

Deposit protocol.

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 Bank:  The user recalls and prepares  and sends it together with the unused to the bank.(2)Verifications Firstly, the bank checks the correctness of expiration date and makes sure does not exist in the exchange list. Secondly, the bank verifies if . 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 and store in the exchange list. Otherwise, it will reject the exchange request.(3)User Bank:  The user computes  where , is a random, and is the new expiration date issued by the bank. The user sends 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.

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 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),  Thus, the bank can obtain two equations as follows:  The bank can derive from the above equations and send and 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 and from the bank, it checks the following equations:  If all of the above equalities are true, the judge will decrypt and return the extracted 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 ().

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 .

Definition 1 (The Linkage Game). Let , , and be two honest users and the judge that follows , respectively. Let be the bank that participates the following game with , , and . The game environment is shown in Figure 5.

Figure 5 

The game environment of linkage game.

Step 1. According to , generates the bank’s public key , the bank’s private key , system parameters , the expiration date , and the five public one-way hash functions , ,  , , and . generates the judge’s public-private key pair .

Step 2. generates , , , , in random, where , , , , , and computes for and , where and .

Step 3. We choose a bit randomly and place and on the private input tapes of and , respectively, where is not disclosed to .

Step 4. performs the withdrawal protocol of with and , respectively.

Step 5. If and output two e-cash(s) and , where , on their private tapes, respectively, we give the two e-cash(s) in a random order to ; otherwise, is given to .

Step 6. outputs as the guess of . The bank wins the game if and has not revoked the anonymity of and to . We define the advantage of as where denotes the probability of .

Definition 2 (Unlinkability). A satisfies the unlinkability property if and only if the advantage defined in Definition 1 is negligible.

Theorem 3. A satisfies the unlinkability property of Definition 2 if the adopted cryptosystems are semantically secure.

Proof. If is given in the Step 5 of the game, it will determine with probability , which is exactly the same as a random guess of .
Here, we assume that gets two e-cash and . Let , , be the view of data exchanged between and in the withdrawal protocol (Section 3.2.2) and let be the view of data exchanged when performs the payment protocol (Section 3.2.3) and the deposit protocol (Section 3.2.4) by using , where .
For and , , there always exists a pair such that And from (3), , (4) always holds as Besides, and are semantically secure encryption functions. cannot learn any information from and .
From the above, given any and , where , there always exists a corresponding pair such that (1), (2), (3), and (4) are satisfied.
Thus, go back to Step 6 of the game, the bank succeeds in determining with probability , where is negligible since and are semantically secure. Therefore, we have , which is negligible, so that 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 () 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., -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 (FG-1)). Let be a security parameter and be an adversary in . is an oracle which plays the role of the bank in to be responsible for issuing e-cash(s) (i.e., , where ) according to the queries from . is allowed to query for times; consider the experiment shown in Algorithm 1.   wins the forgery game FG-1 if the probability Pr of is nonnegligible.

Definition 5 (Forgery Game 2 in (FG-2)). Let be a security parameter and be an adversary in . is an oracle which plays the role of the bank in to take charge of the following two events:(i)issue e-cash(s) (i.e., , where ) according to the queries from ,(ii)record the total number of each distinct expiration date .
is allowed to query for times; consider the experiment shown in Algorithm 2. wins the forgery game FG-2 if the probability Pr of is nonnegligible.

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

Definition 6 (Alternative Formulation of RSA Chosen-Target Inversion Problem (RSA-ACTI)). Let be a security parameter and be an adversary who is allowed to access the RSA-inversion oracle and the target oracle . is allowed to query and for and times, respectively. Consider Algorithm 3.
We say breaks the RSA-ACTI problem if the probability Pr of is nonnegligible.