The Design of a Novel E-cash System with the Fairness Property and Its Implementation in Wireless Communications

The Design of a Novel E-cash System with the Fairness Property

and Its Implementation in Wireless Communications

Chih-Hung Wang* _{and Wei-Ming Chiang}

Department of Computer Science and Information Engineering National Chiayi University

Chiayi 600, Taiwan

[email protected]

Received 30 March 2007; Revised 23 April 2007 ; Accepted 29 May 2007

Abstract. With the popularization of the networking, the network payments have become a trend. Electronic cash (e-cash) is such kind of payment; however, although various types of the demands in e-cash implementa-tions have been conceived of, an e-cash scheme with fairness property has not yet been proposed. In this arti-cle, we present a novel electronic cash model, which uses a verifiable encryption and a restrictive blind signa-ture to construct an electronic cash system with fairness between customers and merchants. The proposed e-cash scheme properly combines the payment protocol with a fair exchange procedure, so that the customer and the merchant can fairly exchange their money and goods. Our scheme can maintain fairness with the aid of an off-line trusted third party (off-line TTP). That means in a normal case, the customer and the merchant can receive their desired items without TTP’s participation. However, only when a dispute occurs, the TTP can help both parties resolve the problem and ensure the fairness of the transaction. Moreover, this system can also protect customer’s privacy, and prevent some hostile deceptions such as double spending and steal-ing. The system has also been implemented in a PDA emulator for wireless communications to evaluate the efficiency of running the program on a low computing power device.

Keywords: electronic cash, fair exchange, verifiable encryption, electronic commerce, wireless communica-tions.

1 Introduction

Electronic cash systems have been widely discussed in past years in regards to many significant issues, such as anonymity, untraceability, unforgeability, unreuseability, non-repudiation and so on. Nevertheless, there still exist some problems between customers and merchants when an e-cash system is implemented on the Internet. For example, a customer who has paid electronic cash to a merchant cannot ensure that the merchant will send the goods which he has paid for. Similarly, a merchant who has sent goods to a customer also cannot ensure that the customer will send payment. To solve these problems, we integrate fair exchange with the payment protocol of our e-cash system.

There are two different types of electronic cash systems: on-line and off-line. In an on-line e-cash system, the issuing bank should participate in the payment protocol to verify the coin. This may be a straightforward way to make sure of the validity of payments, but it is inefficient for real-time transactions. An off-line system can en-hance performance in which the bank is not required to be present to verify the coin during the payment proce-dure; however, a double-spending detection mechanism must be properly designed.

Electronic cash was introduced by Chaum [14]. Chaum used a blind signature to provide “anonymity” and “untraceablility” for electronic cash. Afterwards, Brands in 1993 provides an untraceable electronic cash scheme in wallet with observers [6]. In his paper, he proposed that a coin can be traced only if double-spending occurs. Song and Korba [26] described how to construct an electronic cash scheme which has both features of “untrace-ability” and “non-repudiation”. This means it can be ensured that a legal user would never be traced; however, once a dispute happens, a user cannot deny that he had spent the electronic cash.

Many variants of e-cash scheme have been proposed for different applications. Okamoto [23] proposed a “di-visible” electronic cash scheme, which expresses the amount of money by a tree structure to divide the electronic cash into a minimum unit. In the divisible electronic cash scheme, any remainder money can be continually used [22]. Kim et al. proposed a “fair tracing” protocol to protect customers from suffering illegal tracing by a bank or other parties [19]. Camenish et al. proposed a scheme in which once a user spends one of coins in his wallet

twice, all coins in his wallet can be traced [9]. Hou and Tan eliminated the withdrawal phase of the electronic cash system. Fair traceability was also provided in their scheme in case of crimes taking place [18].

There are still more papers that consider efficiency. Chen et al. proposed a scheme that uses a proxy to reduce the burden of the merchant [10]. Chan et al. bounded each procedure in their divisible cash scheme by tens of exponentiations. [8]. Camenish et al. proposed a scheme with lower complexity of wallet size [9].

As we see, most of electronic cash schemes have not considered the “fairness” between customer and mer-chant. An on-line transaction is not a face-to-face service; for this reason, a dishonest buyer or seller may destroy the fairness of the transaction. An exchange is fair if at the end of exchange, each party receives the expected item or neither party receives any useful information about the other’s item. The last two decades of research have given us useful information on solutions to the fair exchange problem. Solutions to the fair exchange prob-lem reported in past literature fall into the following two categories: (1) Gradual exchange protocols: two parties gradually disclose the expected items by many steps [4][24]. (2) Trusted Third party protocols: two parties ex-change their expected items by the aid of on-line or off-line trusted third party [1][2][5][3].

Purposes and contributions. We have constructed a fair electronic cash system that can protect a user’s privacy and maintain fairness during the transactions. Previous fair payment systems have been based on signature ex-change and will reveal a user’s identity. In our scheme, even when a dispute occurs, the buyer’s identity will not be revealed to the bank/TTP.

Organization. The rest of this article is organized as follows: In Section 2, we briefly introduce some techniques that are used to realize our protocol. In Section 3, we describe the basic model of our fair electronic cash scheme, and detailed procedures are proposed in Section 4. The security and fairness analysis is presented in Section 5. Then we demonstrate the implementation in wireless communications and discuss its efficiency in Section 6. Finally, the concluding remarks are given in Section 7.

2 Preliminaries

2.1 The Discrete Logarithm Assumption

The Discrete Logarithm Assumption (DLA) is an assumption that solving the discrete logarithm problem is be-lieved to be difficult. The discrete logarithm problem is defined as follows:

Given an element g in a group G of order q and another element y of G, find x where 0 < x < q-1 such that

x

y

=

g

. It is computationally hard to get x from y.

2.2 Double Exponentiation and Double Discrete Logarithm

Let , 'q q be two large primes where ' |q q − and 1 * q

f ∈ Ζ be an element of order 'q . It is computational diffi-cult to find a discrete logarithm to the base g and to the base f . Double exponentiation with base g and f is

de-fined as: ( ) ' : x f q G x g Ζ → a _.

By the double discrete logarithm of y∈G to the base g and f, when y=g(fx), there is an unique x ∈ Ζ if it q' exists.

2.3 Verifiable Encryption of Discrete Logarithm

In our scheme, a verifiable encryption is needed, so we briefly introduce one [27]. The encryption is identical to the ElGamal scheme, which is a variation of the Diffie-Hellman key-exchange protocol.

In the verifiable encryption method, each participant chooses a secrete key x ∈ Ζ , and publishes his public-_q'

key x(mod )

y= f q . The dealer randomly chooses α∈ Ζ to encrypt a message q' * q

m ∈ Ζ with his public-key y.

The encrypted message is a pair of 1

1 2

(C C, ) (fα,m y− α)(mod )q

= . The cipher-text(C C₁, ₂) can be decrypted as:

1 / 2 (mod ) x

Here is a protocol for verifying that a pair (C C ) is a ciphertext for the logarithm of a public element ₁, ₂ m

M =g . Since the equation_MC2 _gmC2 _g(y ) α

= = holds, one can perform the following protocol to prove to the verifier that the discrete logarithm of C to the base f is equal to the double discrete logarithm of _{1 M}C2 _{to the}

base g and y. The interactive proof proposed in [27] is shown in Fig. 1.

Stadler suggested a non-interactive proof for the verifiable encryption [27]. Let Hl:{0,1}*→{0,1}l be a hash function (l ≈100). The prover chooses e ∈ Ζ and computes i R q' i i

e f

t = f (mod ) and ( ei)(mod )

i

y g

q t =g q , for

1... .

i= l He then computes R=( ,...,j₁ j_l)=(e₁−β α₁ (mod '),...,q e_l−β α_l (mod '))q , whereβi is the i-th bit of 1 2 ( || || l H M C C β = 1 ||tf ||tg1|| ... ||tfl ||tgl).

The prover sends R and β to the verifier and then the verifier computes

2

1 ( )

1 (mod ) and ( ) for 1... ji

i i i i

i i

j C y

f g

t = f Cβ q t = g−βMβ i= l. The verifier accepts the proof as valid if he checks thatβ holds true.

3 The Basic Model of the System

In this section, we briefly describe our fair electronic cash scheme. There are four participants in this scheme: the Bank/TTP, the customer, the merchant, and the registration center, which can be written as B/T, C, M, RC re-spectively. The bank here also plays the role of resolving the dispute. Thus, the key pairs for the bank to sign the electronic cash and for the TTP to encrypt the goods are different. We assume that B/T should be trusted; i.e., B/T will not maliciously reveal the knowledge that he knows to other users. The customer can withdraw elec-tronic cash from B/T before he goes shopping on Internet. He wants to protect his privacy in the withdrawal, payment, and deposit protocols, and hopes to have a fair payment with the merchant. The merchant sells his soft goods on Internet. He must register all his goods to RC before he sells them. The registration center is responsi-ble for verifying whether the goods (e.g. a serial number) are valid or not, and generates a signature on the de-scription of goods as a certificate. Here we assume that the registration center is trusted enough that he will not reveal the information regarding the goods to any other party.

There are four phases in the proposed protocol (see Fig. 2):

Initial Phase: The initial phase includes the following three subprocedures. (1) Key-pair Setup: setup user’s public / private key, bank’s public / private key, and TTP’s public / private key. (2) Account Establishment: the users’ (including customer and merchant) accounts in the bank are needed to be established before starting a transaction. (3) Goods Registration: all merchandise here can be regarded as digital data, for example, serial numbers, passwords, etc. They must be registered by the registration center.

Withdrawal Phase: The customer in this phase can acquire electronic cash from the bank by running the blind signature. The withdrawal phase is required to be designed to protect customer’s privacy.

Prover Verifier

Fig. 1.An iterative proof of the verifiable encryption

, f g t t

{0,1}

R

β

∈

(mod ') j= −e

βα

q

β

j

2 1 ( ) ( ) verify (mod ) if 0 if 1 j j j f y g C y g t f C q t g t M β β β = = = = = ' ( ) (mod ) e R q e f y g e t f q t g ∈ Ζ = = repeat k

Payment Phase: In this phase, customer and merchant aim to exchange their money and goods. We combine the payment procedure with the fair exchange protocol whereby both the customer and the merchant can get what they want or neither of them can receive useful information. When a dispute occurs, some steps may not execute normally in the payment phase. Thus, customer or merchant can ask for TTP’s help.

Deposit Phase: The merchant can change his coins received from the customer into real money via the bank. The detailed procedures are presented in next section.

4 The Proposed E-cash Scheme

The Initial Phase: Assume that q and 'q are defined as before. Let g g g, ₁, ₂∈G be three generators of G_q of order q. B/T has two key pairs. When he plays as a bank to sign the electronic cash for the customer, his private key isx'∈Z_q', and the corresponding public key is x'

h=g . When he plays as a TTP to encrypt or decrypt the electronic cash, his private key is x∈Zq' and the corresponding public key is mod

x

y= f q. C chooses a random number u1∈Zq and computes

1

1 u

I=g as his account information (note that 1

1 2 1 u

g g ≠ ), and then he sends I to B.

Next, B computes '

2

( )x

z= Ig and sends it to C.

M computes all imod

i

goods goods

PI =g p, for i=1,2,…,n, where the number of n denotes the amount of the goods. M then sends his ID=I_M, Public Information =PIgoods, goods, and the description to RC. RC then

veri-fies the goods and the description. If they are correct, RC signs them. The transmissions during this phase are running through a secure channel.

The Withdrawal Phase: This phase is similar to that of [6]. At the end of the protocol, C can get

, , ( ', ', ', '),

coin= A B z a b r where ( ', ', ', ')z a b r is the signature on (A, B). The additional steps are that C uses TTP’s public key to encrypt a part of the coin (i.e.

r

'

). The result is

'

coin =( , , ', ', ', (A B z a b C C1, 2) (f , 'r 1 y ))

α − α

= ⋅ , where y is TTP’s public key, and α is a random number se-lected by C.

The Payment Phase: There are four steps in the payment phase (see Fig. 3). In Step 1, C sends 1 2

' ( , , ' ', ', ( , ))

coin = A B z a b C C to M. IfA ≠1, M computes d=H0( , ,A B IM,date time desc/ , goodsi)and sends it to

C. Then C computes r₁=d u s( ₁ )+x₁(mod q), 2 2(mod ), ' ', ' ',

r r

r =ds+x q R =g A =A and sends r r R A1, ,2 ', ' to verifiable encrypted coin

Bank/TTP

Customer Merchant

Fig. 2. Fair e-cash scheme with off-line TTP (normal)

goods coin

verifiable encrypted goods

Registration Center

2.withdrawal 4.deposit

3.payment 1.account establishment

M. Here, M can make sure that C is the owner of this coin by verifying 1 2

1 2

r r d

g g =A B and the coin is correct by verifying R'=h ac' ' and 'A =z'c'b'.

Further notice that M does not know the value of r' in the coin. Thus, C must prove to M that he knows the correct value of r' and what he sends to M includes an encrypted r'. To reduce the computation costs, we apply a non-interactive proof proposed in [27] (see Fig. 4).

After M verifies the coin' successfully, M sends the certificate of pre_goods to C. Then M makes a non-interactive proof to C to convince C that the goodsi is encrypted by TTP. If the proof is valid, C is convinced that pre_goods can be decrypted to goodsi which he wants to buy.

In Step 3, C sends a real coin to M. After verifying the coin, M sends goodsi to C in Step 4. If C sends his

'

coin to M but does not receive the pre_goods after a period of time, he would query M. If the answer is “yes”, that means M had received coin'. Then C will wait for next time period. If C still does not receive the goods, he will run Cancel phase.

The Cancel Phase: This sub-protocol is for C to cancel the transaction. C sends ( , , ', ', ', '),A B z a b r

1, ,2 / , goodsi

r r date time desc to B/T. After verifying these messages, the bank stores them in the Database_C. A coin which stored in Database_C is not allowed to be deposited by M in the future.

The Resolve_M Phase: After M sends pre_goods to C, he can run this protocol if he did not receive the coin from C. M sends A B z a b, , ', ', ', (C C1, 2) (g1 ,r 1 y ), ', ', , ,R A r r date time1 2 /

α − α

= ⋅ , , _

i

goods i

desc pre goods to B/T, B/T will check whether they are in the Database_C. If not, TTP decrypts coin' and sends the real coin to M and the goods to C.

The Resolve_C Phase: If C sends the coin to M but does not receive the deserved goods, he can sendA B z a b r, , ( ', ', ' '), , ,r r date time desc1 2 / , goodsi,pre goods_ i to B/T. B/T then verifies

' ' ' r c g =h a , Ar'=z'c'b' and 1 2 1 2 r r d

g g =A B to confirm the correctness and the ownership of the coin. If the above verifications pass, B/T decrypts pre goods_ i and verifies

i i

goods goods

PI =g . B/T then sends the goods to C and the real coin to M.

1. (

coin desc

',

_goods

)

2.

,

(

,

,

),

(

)

_

i i i

goods RC M goods goods TTP i

PI

Sig

I

PI

desc

E

goods

=

pre

goods

3.

coin

= , , ', ', ', '

A B z a b r

4.

goods

=

Serial Number

Customer Merchant

Fig. 3. Four steps in payment phase

_

verify pre goods

' verify coin

verify goods

The Deposit Phase: If M finishes the payment protocol in the normal case or successfully runs the Resolve_M, he will obtain the coin=A B z a b r, , ( ', ', ', '). Now he can perform this protocol for deposit.

5 Security and Fairness Analysis

5.1 Security Analysis

Security of e-cash is defined in terms of six requirements: Unreusability, Untraceablity, Unforgeablility, Unex-pandability, Unlinkability and Unstealability [17][21]:

Unreuseability: If a coin has been deposited in the bank twice, the bank would be assumed to receive two messages( , , ) and ( ', ',d r r_{1 2} d r r_{1 2}') which are produced during the payment phase. Thus, the bank can reveal

1 1 2 2

( ') /( ')

1 1

r r r r

u g − −

= and compute the customer’s identity 1

1 u

I=g . This situation shows that once the user uses the coin twice, his account information will be traced by the bank.

Untraceability: This property can be proven under the security assumption of used blind signature which has been shown in [6]. The bank cannot link the identity of the customer and the payment coins, since c' and r' are unknown to the bank in the withdrawal phase. Another security assumption is based on a representation problem in group of prime order. That is, given a generator tuple (g₁,...,gk) and h∈Gp, to find a representation of h with respect to (g₁,...,gk) is hard. In this scheme, a customer’s identity is defined as 11

u

I=g , a coin is repre-sented as A B z a b r, , ( ', ', ', ') where 1

2 1 2

( )s ( u )s

A= Ig = g g . Anyone who wants to trace the customer’s identity must know a presentation of A with respect to g₁ and g₂. If the representation problem is hard to solve, it can be said that the customer’s identity is untraceable.

Unforgeability: A legal coin should include the bank’s signature, namely ( ', ', ', ')z a b r , which can be verified by r' H A B z a b( , , ', ', ') '

g =h a . The value r' is computed by the equations of r'=ru+v(mod )q and

' (mod )

r=cx+w q where x' is bank’s private key. Anyone who has no bank’s private key cannot compute such a signature, and hence cannot forge a valid coin.

1 1 2 , , ', ', ', ( , ) ( , ' ) A B z a b C C fα r− yα = ⋅ d 1 1 1 2 2 ( ) mod mod r d u s x q r ds x q = + = + ' ' 1

, , '

2

, '

r r

r r

R

=

g

A

=

A

1 2 1 2

r r d

verify

g g

=

A B

' '

'

'

'

'

'

c c

R

h a

A

z

b

=

=

' ( ) for 1,..., (mod ) i i ei i i R q e f y g i l e Z t f q t g = ∈ = =

,

, , for

1,...,

i i f g

t

t

β

R

i

=

l

1 1 1 2 1 1 1 ( ' || || || || || ... || || ) ( ,..., ) ( (mod '),..., (mod ')) l l l f g f g l l l H R C C t t t t R j j e q e q

β

β α

β α

= = = − − :{0,1}* {0,1}l l H → 2 2 1 1 1 ( ) 1 ( ) for 1,..., (mod ) ( ' ) ( ' ) i i i ji i i i ji i i i j f C y g C y g verify i l t g C q t g R t g A β β β β β − − = = = = Customer Merchant

Fig. 4. The first step of the payment phase (verification of the pre_coin)

0 if 1,

( , , _M, / , _goodsi) A

d H A B I date time desc ≠

Unexpandability: Assume that there are only N coins which are made by N withdrawal protocols. If the prop-erty of unforgeability is established, it is infeasible to generate a different coin from the original N coins. When N+1 deposit protocols occur, there are two kinds of situation. One situation is that a customer spent his coin twice, and his identity was revealed by double spending checking (g=( / ') /( /r r_{1 1} r₂ r₂')). The other situation occurs when the merchant deposits the same coin twice. This kind of behavior can be easily detected by the bank to check whether there are the same r, r', date time/ and goods_i in his database.

Unlinkability: Assume that two coins: coin₁=(A B₁, ₁, ( ',z₁ a b r₁', ₁', '))₁ and coin =2 (A B2, 2,(z2',a2',b2',r2')) were withdrawn by the same customer, where 1

1 ( 2) s A = Ig , 11 21 1 1 2 x x B =g g and 2 2 ( 2) s A = Ig , 12 22 2 1 2 x x B =g g . Be-cause of the representation problem of the prime order, no one can determine the link between A₁ and A₂ with-out knowing the secret s x1, 11,x21 and s x2, 12,x22 those being kept by the owner.

Unstealability: During the payment protocol, the customer must prove to the merchant that he is the owner of the coin. Upon receiving d=H0 =( , ,A B IM,date time/ ), the customer sends r r1, 2 to the merchant, where

1 ( 1 ) 1 (mod ')

r =d u s +x q and r2 =ds+x2. Here u s x x1, , ,1 2 should be kept secret by the customer. Even if some-one can steal a coin, he cannot spend this coin without proving that he is the owner of this coin.

5.2 Fairness Analysis

There are three cases in discussing the fairness of our protocol.

Case 1 (Both C and M behave properly): It is easy to see that in this case C obtains the goods and M obtains the coin.

Case 2 (M behaves improperly): There are four ways that M may behave improperly.

(1) M does not send pre_goods to C after he receives the coin' from C: After waiting for a response from M for a short time (assume t ms), C will query M again. If there still no answer, C will run the Cancel protocol to stop the transaction. The fairness can be maintained even if M performs the Resolve_M sub-protocol before C runs the Cancel sub-sub-protocol, since B/T still needs to send the goods to C in the last step. (2) M sends an invalid pre_goods to C: In the second step of the payment phase, M need to sends the following

information to C: , ( , , ), ( ) _

i i i

goods TA M goods goods TTP i i

PI Sig I PI desc E goods = pre goods . C first checks the

signa-ture ( , , )

i i

TTP M goods goods

Sig I PI desc with

i

goods

desc . If

i

goods

desc is satisfied, C can use the public information

i

goods

PI in the signature to verify the proof of the verifiable encryption made by M (i.e. check the equation

mod

i i

goods goods

PI =g p). C can verify the pre_goods (i.e. E_TTP(goods_i)) so that M cannot successfully make a proof for this invalid pre_goods to convince C.

(3) M receives the coin from C but refuse to send the goods to C: In this case, C already received a valid pre_goods and then he can ask B/T to decrypt the pre_goods (see Resolve_C). After doing Resolve_C sub-protocol, C can obtain the goods he desired.

(4) M receives the coin at Step3 in the payment protocol but sends invalid goods to C: The incorrect goods will not pass the verification of imod

i

goods goods

PI =g p. C can ask B/T to resolve the dispute, and obtain the valid goods by running Resolve_C sub-protoocl.

Case 3 (C behaves improperly): There are also four ways that C may behave improperly. (1) C sends an invalid coin' or wrong

si

good

desc to M: First, M checks whether

si

good

desc belongs to him or not. If yes, M checks the correctness of coin' by verifying the zero-knowledge proof of verifiable encryption from C. If not, M reject the transaction. In our scheme, coin'=( , , ', , , (A B z a b C C1, 2)) where (C C1, 2) is ci-pher of r'. C must send '

' r

R =g and '

' r

A = A to M. Since g and A is public to M, if C sends wrong R'

or A' to M, the verification of the following two equations will not be satisfied: ' '

' c ', ' 'c ' R =h a A =z b . Moreover, if C sends an invalid coin'(i.e. (C C1, 2)) to M, he cannot prove that he knows the element r'. An invalid coin'cannot pass the verification and thus the fairness can still be maintained because the both two parties obtain nothing.

(2) After receiving pre_goods from M, C performs Cancel: There are two possibilities in this case. In the first case, C does not run Resolve_C then the both sides obtain nothing. The other case occurs when C runs Re-solve_C then both sides obtain their desire information.

(3) After receiving pre_goods from M, C refuses to send coin to M: In this case, C has pre_goods and M has

'

items. If not, neither of them obtains useful information. In light of the fact that C can perform Resolve_C and M can perform Resolve_M, let us then consider what happens if both C and M perform their resolve sub-protocol. In this situation, C will receive two goods_i’s from B/T and M will receive two coin’s from B/T. Two goodsi’s have the same serial number that can be copied by a user easily. How to prevent a user from copyinggoods_i and using it arbitrarily is not important here. The point is that M has two copies of

coin, and can he deposit both of them? The answer is no. Because M cannot create another pair of r r1, 2, called r r₁', ₂', since he does not know u x x₁, ₁, ₂. If he uses the same r r₁, ₂ to deposit the coin twice, the B/T can easily ascertain that it is a double deposit by M. So, even if each side performs a resolve sub-protocol and receives two copies, the fairness between C and M still holds.

(4) C sends invalid coin after he receives correct pre_gooods from M: If C sends incorrect coin or r' to M in Step 3 of the payment phase, the following verification equations will not pass: ' ' ' '

', ' '

r c r c

g =h a A =z b . If the verification is abortive, M can run Resolve_M to obtain his coin.

6 Implementations and Efficiency

6.1 Implementation Environment

To observe the efficiency and practicability of our scheme, we implemented it and evaluated its computing time. We first realize our scheme on PC. The experimental platform is the IntelTM Pentium 3.2 GHz PC, with 1536 MD DDR RAM and Java 2 SDK 1.4.x. Subsequently, we implemented our scheme on a personal digital assistant (PDA) to evaluate the efficiency of running on a low computing power device. We choose Nokia 9210c as our experimental platform because it can offer us many useful tools such as Nokia Symbian 6.0 SDK and EPOC Emulator.

The hardware resources of a PDA such as computing power and memory size are not as ample as that of a PC. Moreover, there are still several details that we should take care; for example, the useable memory size on a PDA device is limited to 8 MB, and classes that we can use on the PDA with Pjava are only supported before Java 1.1.

PJEE (Personal Java Emulation Environment) is a JRE (Java run time environment) developed on smaller de-vices like PDAs. After we install PJEE on our digital product (i.e. Nokia 9210c), we can run our programs writ-ten in Java language on it with only minor modifications. If we write the program with JDK whose version is over 1.1, we must compile the program with a proper vision and a proper class path. For example, the command can be written as:

C:\...>javac –classpath D:/pjee1.1\lib\classes.zip –target 1.1 Main.java In addition, we packed our program into a .jar file which can be directly executed on the PDA.

6.2 System Implementation Architecture

Fig. 5 indicates the system implementation architecture. By using the library of java language, we can easily write some cryptographic functions, like big prime integer generation, primality testing, discrete logarithm, blind signa-ture, message authentication code, etc.

Fig. 5.The system implementation architecture

6.3 System Simulation on the Server Side

First, we use a double discrete logarithm program to produce the environmental parameters. The program pro-duces a big prime number with length of 512 bits and 1024 bits called 'q , and then finds qand psuch that

2 ' 1

q= q + and p=2q+ . If the program cannot find such 1 q and p, it repicks a big prime number 'q , until the above conditions are satisfied. The program then finds out the generators f ,g g, 1, and g2. This is a time-consuming procedure (usually running more than 10 hours), and the speed depends on the probability. After we find out p and q, we store them for repeated usage.

The public keys and private keys for all participants (including customers and merchants) can be computed by using the parameters p and q which we figured out before. The following shows the equations:

User’s key pair: ( 1

1, 1 u

u I=g ) Bank’s key pair: ( '

', x

x h=g ) TTP’s key pair: ( , x

x y= f )

Fig. 6 shows the produced process of the above-mentioned key and the corresponding account information. Before the merchant starts to sell his goods, he must register the goods with the registration center.

6.4 System Simulation on the Client Side

In the withdrawal phase, the customer needs to withdraw electronic cash from the bank. With a blind signature technique, we need to compute c=c u'/ mod q, where c'=H A B z a b( , , ', ', '). It may be worth to pointing out that Pjava did not support the library of the message authentication code (MAC). Hence, we need to create a class for it to run on the client side. We designed the MAC as a 160-bit output hash function just like SHA-1, which also can be used directly on the server side.

In payment phase, the customer needs to make a transaction with the merchant under the wireless network environment. Some parameters need to be produced in advance. Subsequently, the customer sends his pre_coin to the merchant and proves its correctness by a zero-knowledge proof. After this, the merchant sends his pre_goods to the customer and also proves its correctness. We implemented both iterative and non-iterative veri-fications. In the case of non-iteration verification, we can reduce the executing time for about (2l− +1 1)t_t ms, where tt denotes the time of a network transmission and l denotes the number of repetitions in the iterative verification procedure. Assume that t =_t 30 and l =100, the non-iterative way will reduce (2*100)*30 ms = 6 second. The process of the iterative verification is shown in Fig. 7.

Fig. 6.The process of key generalization and account establishment

Fig. 7. The process of the iterative verification

For the non-iterative verification, we need to compute n_t different values of ', , i i f g e t t and compute 1 1 1 2 ( ' || || || || || ... || || ) l l l f g f g H R C C t t t t

β = and R=(e1− β α1 (mod '),...,q e −l β αl (mod '))q , where R is a bit stream with l bits. Fig. 8 shows the result of the verification and the parameter R in the non-iterative verifica-tion.

6.5 Efficiency Analysis

To estimate the efficiency of this system, we first figure out the execution time of the initial phase, withdrawal phase and deposit phase. The result shows that each of them does not take more than one second. The most time-consuming procedure is placed in the payment phase, i.e. the zero-knowledge proof. In the client (customer) side, performing the proof of verifiable encryption for 100 rounds (security level 2−100) with a 512-bits 'q needs 9.8 seconds. Notably, the following experimental results of the client side are based on running the programs on an emulator instead of a real PDA device. Since a real PDA has more limitations on memory resources, the per-formance should be lower than what we list below.

Table 1 shows the time needed in the verification for the client side based on the different values of l. Small land size of 'q can be more suitable for wireless environment but will have less security. Time needed in the verification for the server side is shown in Table 2. From Table 2, we can see that the computing time greatly increases because of large number of rounds in the proof procedure. Even in the server side, we need about 4 seconds to perform the proof for 100 rounds.

Total Time of Client Side with q’ of 1024 bits

Total Time of Client Side with q’ of 512 bits l =160 l =100 l =50 l =10

1.2

≅

(sec)

Table 1.Time complexity in the client side (on Nokia 9210c EPOC emulator)

l: number of rounds

9.5

≅

5.2 ≅ 29.2 ≅

15.4

≅

9.8

≅

91.5

≅

57.1

≅

Total Time of Server Side with q’ of 1024 bits

Total Time of Server Side with q’ of 512 bits l =160 l =100 l =50 l =10

0.4537

≅

(sec)

Table 2.Time complexity in the server side (on PC)

l: number of rounds

4.6528

≅

2.2316 ≅ 17.8562 ≅

7.0925

≅

4.4365

≅

49.5427

≅

32.4126

≅

7 Conclusion and Future Works

In this article, we realize a fair electronic cash system by using a verifiable encryption in the payment phase. The customer can keep his privacy, and his identity will not be traced by anyone if he does not spend his coins twice. By using a non-interactive proof and three sub-protocols of fair exchange, the customer and the merchant can fairly exchange their coins and goods. Nobody can gain an advantage in the exchange.

But we have to say with regret that our scheme has high computational costs; we are investigating how to reduce the computation complexity in the future.

Acknowledgments

This work was supported in part by TWISC@NCKU, National Science Council under the Grants NSC 94-3114-P-006-001-Y.

References

[1] N. Asokan, M. Schunter and M. Waidner, “Optimistic protocols for fair exchange,” Proceed-ings of 4th ACM Confer-ence on Computer and Communications Security, pp.6-17, 1997.

[2] N. Asokan, V. Shoup and M. Waidner, “Asynchronous protocol for optimistic fair exchange,” Proceedings of 1998 IEEE Symposium on Security and Privacy, pp.86-99, 1998.

[3] N. Asokan, V. Shoup and M. Waidner, “Optimistic fair exchange of digital signatures,” Proceedings of IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, pp. 593 -610, 2000.

[4] E. F. Brickell, D. Chaum, I. B. Damgard and J. van de Graaf, “Gradual and verifiable release of a secret,” Advances in Cryptology – Proceedings of Crypto ’87, pp.156-166, 1987.

[5] F. Bao, R. H. Deng and W. Mao, ”Efficient and practical fair exchange protocols with off-line TTP,” Proceedings of 1998 IEEE Symposium on Security and Privacy, pp.77-85, 1998.

[6] S. Brands, “Untraceable off-line cash in wallets with observers,” In Advances in Cryptology – Proceedings of Crypto'93, Lecture Notes in Computer Science, pp. 302-318, Springer-Verlag, 1994.

[7] D.Chaum, A. Fiat and M. Naor. “Untraceable electronic cash,” In Advances in Cryptology- Crypto’88, Lecture Notes in Computer Science, pp. 319-327, Springer-Verlag, 1990.

[8] A. Chan, Y. Frankel and Y. Tsiounis, “East come-easy go divisible cash,” In Advances in Cryp-tology – Proceedings of Eurocrypt ’98, Lecture Notes in Computer Science, pp.561-575, Springer-Verlag, 1998.

[9] J. Camenisch, S. Hohenberger and A. Lysyanskaya, “Compact e-cash,” In Advances in Cryp-tology – Proceedings of Eurocrypt ’05, Lecture Notes in computer Science, pp. 302-321, Springer-Verlag, 2005.

[10] Y. Y. Chen, J. K. Jan and C. L. Chen, “A novel proxy deposit protocol for e-cash systems,” Proceedings of ELSEVIER Applied mathematics and Computation, Vol.163, No.2, pp. 869-877, 2005.

[11] T. J. Ca, D. D. Lin, and R. Xue, “A randomized RSA-based partially blind signature scheme for electronic cash,” Com-puter & Security, Vol.24, No.1, pp. 44-49, 2005.

[12] D. Chaum, R. L. Rivest, and A. T. Sherman, “Blind signatures for untraceable payments” In Advances in Cryptology – Proceedings of. Crypto’82, pp. 199-203. 1982.

[13] I. B. Damgard. “Payment systems and credential mechanisms with provable security against abuse by individuals,” In Advances in Cryptology - Proceedings of Crypto ’88, Lecture Notes in Computer Science, pp. 328-225, Springer-Verlag, 1988.

[14] D. Chaum, “Blind signature systems,” In Advances in Cryptology - Proceedings of Crypto ’83, pp.153-156, 1983. [15] N. Ferguson, “Single term off-line coins,” In Advances in Cryptolog - Proceedings of Eurocrypto ’93, pp. 318-328,

1993.

[16] M. K. Franklin and M. K. Reiter, “Fair exchange with a semi-trusted third party,” Proceedings of The Fourth ACM Conference on Computer and Communications Security, pp. 1-6, 1997.

[17] M. Franklin and M. Yung, “Secure and efficient off-line digital money,” Proceedings of the twentieth International Colloquium on Automata, Languages and Programming (ICALP 1993), Lecture Notes in Computer Science 700, pp. 265-276, Springer-Verlag, 1993.

[18] X. S. Hou and C. W. Tan, “A new electronic cash model,” Conference on Information Tech-nology: Coding and Com-puting (ITCC04), Vol.1, pp.374-379, 2004.

[19] B. G. Kim, S. J. Min and K. J. Kim, “Fair tracing based on VSS and blind signature without Trustees,” International research center of Information Security (IRIS) Computer Security Symposium, 2003.

[20] S. J. Kim and H. K. Oh, “Efficient anonymous cash using the hash chain,” IEICE Transactions on Communications, Vol.E86-B, No.3, pp. 1140-1143, 2003.

[21] T. Nakanishi and Y. Sugiyama, “An efficient on-line electronic cash with unlikable exact payments,” Proceedings of International Conference on Information Security (ISC2004), Vol.3225, pp. 367-378, 2004.

[22] T. Okamoto, “An efficient divisible electronic cash Scheme,” In Advances in Cryptology – Proceedings of Crypto’95, Lecture Notes in Computer Science 963, pp. 438-451, Springer-Verlag, 1995.

[23] T. Okamoto and K. Ohta, “Universal electronic cash,” In Advances in Cryptology – Proceedings of Crytpo’91, pp. 324-337, 1998.

[24] T. Okamoto and K. Ohta, “How to simultaneously exchange secrets by general assumption,” Proceedings of 2nd ACM Conference on Computer and Communications Security, pp. 184-192, 1994.

[25] B. Schoenmakers, “Basic Security of the ecashTM payment system,” Proceedings of Computer Security and Industrial Cryptography: State of the Art and Evolution, East Course. Leunen Beligium, 1997.

[26] R. Song and L. Korba, “How to make e-cash with non-repudiation and anonymity,” Conference on information Tech-nology: Coding and Computing (ITCC’04), NRC: 46549, 2004.

[27] M. Stadler, “Publicly verifiable secret sharing,” In Advances in Cryptology – Proceedings of Eurocrypt’96, Lecture Notes in Computer Science, pp. 190-199, Springer-Verlag, 1996.

[28] Y. Tsiounis, Efficient electronic cash: new notations and techniques, Ph.D. Dissertation, College of Computer Science, Northeastern University, Boston, USA, pp.50-51, 1997.

[29] C. H. Wang, “Untraceable fair network payment protocols with off-Line TTP,” In Advances in Cryptology – Proceeings of Asiacrypt’03, Lecture Notes in Computer Science 2894, pp.173–187, Springer-Verlag, 2003.

[30] H. Wang and Y. Zhang, “Untraceable off-line electronic cash flow,” Proceedings of Austral-Asian E-Commerce Com-puter Science Conference (ACSC’01), Vol.23, No.1, pp. 191-198, 2001.