Date Attachable Offline Electronic Cash Scheme

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.


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][2][3][4][5][6][7][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][10][11][12][13] and offline e-cash [14][15][16][17][18][19][20][21][22][23][24][25][26][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 ecash(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.

2
The Scientific World Journal (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.

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

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.
(2) User → Signer: The user chooses a message and a random integer in Z * , then blinds the message by computing = ( ) mod 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 = mod .

Chameleon Hashing Based on Discrete Logarithm.
Chameleon hashing was proposed by Krawczyk and Rabin [30]. The chameleon hash function is associated with a onetime 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.
(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 ( , ) = cham-hash ( , ). The user derives in the equation The Scientific World Journal 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.

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 ecash 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 ecash. In the following sections, we will describe our scheme in detail.

The Proposed
Scheme. Firstly, we define some notations as follows.
: 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.  (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.

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 ID 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.
(3) Bank → Judge device: ( , , ) The bank sets = ID , where ID is the identity of user , and inputs it together with and to the judge device.
If yes: continue; ID c Verify ? =Ê pk (ID c ‖ r j ) The judge device decrypts and checks if = ID . If not, it returns "ID error" to the bank; or else, it picks a random integer ∈ Z * and a string ∈ {0, 1} randomly. Then it computes =̂( ‖ ) and Finally, it encrypts ( , , ) by using the symmetric key and outputs it together with to the bank. 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 =̂(ID ‖ ) is true or not. Thirdly, she/he computes = mod (4) and verifies by checking if is true or not. Finally, when all verifications are done, the user gets the e-cash tuples ( , , , ) and stores ( 1 , 2 , 1 , 2 ) for further payment usages.

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. (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 ∈ {0, 1} and sets a challenge = (ID ‖ ), where ID is the identity of the shop. Finally, it sends to the user.
After receiving from the shop, the user randomly selects a ∈ Z * and computes a response to the challenge where = 4 ( ‖ ). Then, the user sends ( , ) to the shop.

(4) Verifications
After receiving ( , ) from the user, the shop verifies 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 ecash, 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 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.
(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 2 1 ( ‖ ) 3 ( ‖ ) = 2 ( )(mod ) 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 1 ( ‖ ) in exchange list. Otherwise, it will reject this transaction and trace the owner of the e-cash.

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.
(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 computeŝ where 3 is a random, and is the new expiration date issued by the bank. The user sends (̂, , ID ) to the bank. Then the bank repeats the withdrawal protocol in Section 3.

from
Step 2 with the user.

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 bank. Therefore, the bank is able to detect any doublespent 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 ( 1 , 1 ) from the above equations and send ( , 1 , 1 , 2 , 2 , 2 , 3 , , ) and ( 1 , 1 ) to the judge to trace the owner of the e-cash.
The judge can trace any user who doubly spends ecash(s) or violates any transaction regulations. When the judge receives ( , 1 , 1 , 2 , 2 , 2 , 3 , , ) and ( 1 , 1 ) from the bank, it checks the following equations: If all of the above equalities are true, the judge will decrypt and return the extracted ID to the bank.

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 (DAOECS).

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 DAOECS.
Definition 1 (The Linkage Game). Let 0 , 1 , and J be two honest users and the judge that follows DAOECS, respectively. Let B be the bank that participates the following game with 0 , 1 , and J. The game environment is shown in Figure 5.
Step 4. B performs the withdrawal protocol of DAOECS with 0 and 1 , respectively.
Step 5. If 0 and 1 output two e-cash(s) (̂,̂,̂,̂) and , on their private tapes, respectively, we give the two e-cash(s) in a random order to B; otherwise, ⊥ is given to B.

8
The Scientific World Journal if the following checks are true, return 1; (i) where Pr[̂=̂] denotes the probability of̂=̂. Proof. If B is given ⊥ in the Step 5 of the game, it will determinêwith probability 1/2, which is exactly the same as a random guess of̂.

E-Cash Unforgeability.
In this section, we will formally prove that the proposed date attachable offline electronic cash scheme (DAOECS) 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., (ℓ, ℓ + 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.

FG-2 if the probability Pr[Exp FG-2
Here we introduce the hard problems used in our proof models.
Definition 6 (Alternative Formulation of RSA Chosen-Target Inversion Problem (RSA-ACTI)). Let ∈ 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 . A is allowed to query O and O inv for and ℎ times, respectively. Consider Algorithm 3.
We say A breaks the RSA-ACTI problem if the probability Pr[Exp RSA-ACTI A ( ) = 1] of A is nonnegligible.

Definition 7 (The RSA Inversion Problem). Given ( , ),
where is the product of two distinct large primes and with roughly the same length and is a positive integer relatively-prime to ( − 1)( − 1), and a randomly-chosen positive integer less than , find an integer such that ≡ (mod ). 3 , respectively. Here we will start to do the simulation for the two games (i.e., FG-1 and FG-2) to prove DAOECS is secure against forgery attacks. The details of simulation are set below and illustrated in Figures 6 and 7, respectively.

Definition 8 (E-Cash Unforgeability
Simulation in FG-1. In this proof model, S is allowed to query the oracles O inv (i.e., (⋅) ) and O of RSA-ACTI problem defined in Definition 6 for helping S to produce e-cash(s) and the corresponding verifying key is ( , ). (a) if = for some , the corresponding will be retrieved and S will send ( mod ) back to A; (b) otherwise, S will select a random ∈ Z , record ( , ) in L 2 , and return ( mod ) back to A.
)) ≡ d Figure 6: The proof model of FG-1. (a) if ( , ) = ( , ) for some , the corresponding will be retrieved and ( mod ) will be returned to A; (b) otherwise, S will select a random ∈ Z , record (( , ), ) in L 3 , and return ( mod ) back to A.
According to L 1 , L 2 , and L 3 , S can compute and retrieve RSA-inversion instances (∀ , 1 ≤ ≤ ℓ + 1) Via A querying the signing oracle O for ℓ times (i.e., query O inv for ℓ times by S), S can output ℓ + 1 RSA-inversion instances and break the RSA-ACTI problem with nonnegligible probability at least A .
Simulation in FG-2. Initially, S is given an instance ( , , ) of RSA inversion problem defined in Definition 7 and simulates the environment as follows.
Initially, every blank record in L 1 can be represented as (⊥, ⊥, ⊥). When A sends for querying the hash value 1 ( ), S will check the list L 1 : (a) if = for some , then S retrieves the corresponding and returns it to A; (b) else if = 1 ( ) and 2 1 ( ) ̸ = ⊥ for some , then S retrieves the corresponding and returns ( mod ) to A; (c) else if = 1 ( ) and 2 1 ( ) = ⊥ for some , then S selects a random ∈ Z , returns ( mod ) to A, and then fills the record ( , 1 ( ), ⊥) as ( , 1 ( ), ) in L 1 ; (d) otherwise, S selects a random ∈ Z , records ( , , ⊥) in L 1 , and returns to A.
When A asks for 2 query by sending to S, S will look up the list L 2 : (a) if = for some , the corresponding will be retrieved and S will send ( mod ) back to A; (b) otherwise, S will select a random ∈ Z , record ( , ) in L 2 , and return ( mod ) back to A. (a) if ( , ) = ( , ) for some , the corresponding 3 ( ‖ ) will be retrieved and returned to A; (b) otherwise, S will select a random ∈ Z , set 3 ( ‖ ) = ( mod ), record (( , ), , 3 ( ‖ )) in L 3 , and return 3 ( ‖ ) back to A.
Assume some ( , ), 1 ≤ ≤ ℓ + 1, is not recorded in L ; then by the L 1 , L 2 , and L 3 , S can compute and retrieve and solve the RSA inversion problem with nonnegligible probability at least A .

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.
A wins the game if the probability Pr[Exp TG Definition 11 (E-Cash Traceability). If there exists no probabilistic polynomial-time adversary who can win the tracing game TG, then DAOECS satisfies the E-Cash Traceability.

Definition 12 (Alternative Formulation of RSA Known-Target Inversion
Problem (RSA-AKTI)). Let ∈ 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 . A is allowed to query O and O inv for and ℎ times ( ℎ < ), respectively. Consider Algorithm 5.
We Proof. S simulates the environment of DAOECS by controlling three hash oracles, O 1 , O 2 , O 3 , to respond hash queries and an e-cash producing oracle O of DAOECS 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 1 , L 2 , and L 3 to record every response of O 1 , O 2 , and O 3 , respectively.
Besides, in the proof model, S is allowed to query the oracles O inv (i.e., (⋅) ) and O of the RSA-AKTI problem defined in Definition 12 for helping S produce valid e-cash(s) and the corresponding verifying key is ( , ).
Here we will do the simulation for game TG to prove that DAOECS satisfies the e-cash traceability. Details are described as follows. When A asks for 2 query by sending to S, S will look up the list L 2 : (a) if = for some , the corresponding will be retrieved and S will send ( mod ) back to A; (b) otherwise, S will select a random ∈ Z , record ( , ) in L 2 , and return ( mod ) back to A.
While A sends ( , ) to S for 3 ( ), S will look up the list L 3 : (a) if ( , ) = ( , ) for some , the corresponding will be retrieved and returned to A; (b) otherwise, S will query O to get an instance ; record and (( , ), ) in L and L 3 , respectively; (c) return back to A.

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 ecash 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.

Experiment Exp
if the following checks are true, return 1;  Figure 9 and each oracle is constructed as follows.
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 DAOECS satisfies no-swindling property.

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.

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.   According to [41], ≈ , ≈ inv ≈ 240 . : a modular exponentiation; : a modular multiplication; : a hash operation; zkp: a zero-knowledge proof. : a modular addition; inv: a modular inversion.

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

⬦
The communication cost of each transaction at user side in bytes.

18
The Scientific World Journal

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 , , 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.

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.