Digicash implementation

Jens Bo Friis Cryptology University of Aarhus 4 June 2003 Project supervisor: Jesper Buus Nielsen

Abstract
This paper describes an e-cash system based on RSA. The c-cash system is believed to be provably secure, though a formal proof is not given. The purpose with this project is to implement the e-cash system and to determine whether the system is efficient or not.

RSA based e-cash system

04-06-2003

Jens Bo Friis

Introduction
A bank, handling withdraw and deposit transactions. A customer, using cash to pay with A shop, receiving cash for some service Bank

In cash systems there are normally three actors:

Customer

Shop

Normal hard cash cannot be easily copied. Paper quality, printing quality, water-markings are all factors put in place to prevent counterfeit. With digital money, an exact copy can easily be made. This challenges the way of detecting fraud and double-spending of digital copies. Hard cash are anonymous. They leave no trace behind of who had them, for what they have been used. Digital cash are withdrawn from the customers account. The coins will probably contain some ID identifying the uniqueness. A shop receives the coin and deposits the coin at the bank. This gives the bank a possibility of tracking the coin. So what we need is customer security: anonymity. No one must be able to trace the coin back to the customer. We need bank security. Double spending and double depositing must be detectable and even better, if the bank can find out who did the double spending. Shop security: The shop must be able to detect that its genuine cash and not fake. The original idea was invented by Chaum [3,4]. Accountability-after-the-fact or special soundness was proposed by Chaum, Fiat, Naor [5]. Wallets with observers. Briefly it is a combination of two devices, one observer and one wallet. The observer roughly prevents the user from double spending coins in the wallet. This has been discussed in [6] by Chaum, Pedersen and in [7] by Cramer, Pedersen. Proposals using RSA have so far shown to be inefficient compared to systems based on discretelogarithm. The purpose of this paper is to see how far we can go using RSA and using a new approach of detecting double spenders and cutnchooseing. I have implemented the cash system, to actually measure performance and efficiency. Protocols and security will be discussed, but this paper will not contain a formal proof of the security.

Overview of protocols and algorithms

In the following section I will briefly go through the main building blocks for building the Digicash system and protocols.

RSA based e-cash system

04-06-2003

Jens Bo Friis

2.1

RSA

Let N = pq , where p and q is to large primes, of length N / 2 , where N is the RSA bit length And let ( N ) = ( p 1)(q 1) . Chose e and calculate d so following applies:

d = e 1 (mod ( N )) ed = 1(mod ( N )) and 0 < e < ( N ) and gcd(e, ( N )) = 1 .

The public key is denoted ( N , e) and the private key ( N , d ) . Encryption: S = x d mod N , and decryption: x = S e mod N , where cipher text S Z N and plain text x Z N

2.2

RSA signature scheme

Let H be a cryptographic hash function. Signing: S = H ( x) d mod N , where the ( N , d ) is the private key, S is the signature on plain text x. Verifying: the signature is done by comparing the hash on the plain text to the decrypted signature: S e = H ( x) mod N . In short we define a signing function signing function sig sk ( x) = S and a verification function vervk ( S , x ) = 1 , where the verification key vk = ( N , e) and the signing key sk = ( N , d ) .

2.3

-protocols

We have a 3-move protocol that gives the verifier proof of knowledge of a witness w. The protocol we describe in the form (a, e, z ) where a is the initial commitment send from the prover to the verifier. The verifier sends a challenge e back and the prover sends a response z to the challenge to the verifier. The verifier can from this either reject or accept the proof. We define four functions ( A, E , Z , B) each calculating the steps in the -protocol

a = A( x, w; r ) , where w is the private input, x is the public input and r is some random bits.
e E , where E is the set of possible challenges.

z = Z ( x, w, r , e) , where z is the response to the challenge. b = B( x, a, e, z ) , where we say that if b = 1 then the proof of knowledge, or the conversation was
accepted. Completeness:

B( x, A( x, w; r ), e, Z ( x, w, r , e)) = 1 for all ( x, w) R and for all challenges e E and all

random bits r. Special hones verifier zero-knowledge: From a challenge e one can efficiently generate a conversation (a, e, z ) . With distribution equal to that of conversation between the honest prover and verifier where e occurs as challenge.

RSA based e-cash system

04-06-2003

Jens Bo Friis

Formally: There exists an efficient algorithm honest-verifier-simulator (hvs) which if given x and e computes hvs( x, e) = (a, z ) such that ( x, a, z , e) has the exact same distribution as if a and z were computed as a = A( x, w; r ) and z = Z ( x, w, r , e) . Special knowledge soundness: A prover that does not know a witness can answer only one of the possible challenges. Formally: From an instance x and (a, e' , z ' ) where e, e' E and e e' and B( x, a, e, z ) = B( x, a, e' , z ' ) = 1 one can compute w such that ( x, w) R

2.4

-protocol for proving the knowledge of the rth root

We have a modulus n , a large prime r , a relation x = w r mod n where x, w R Commit message: X = W r mod n , where W R, Z / Z n Challenge: e R, Z / Z r Response to challenge: z = w eW mod n Check: X , z Z / Z n and z r x e X mod n Correctness:

z r x e X mod n ( w eW ) r = ( w r ) e (W r ) mod n w erW r = ( w r ) e W r mod n w erW r = werW r mod n

Special honest verifier zero-knowledge: Given an instance x Z / Z n and a challenge e R, Z / Z r , generate z R, Z / Z n and let X = z r x e mod n . Since the map z a z r mod n is a bijection it follows that X is uniformly random in Z / Z n Special soundness: Given two accepted conversations ( x, X , e, z , e' , z ' ) where X , z , z ' Z / Z n , z r = x e X mod n ,

z ' r = x e ' X mod n and e e'

Then we compute f = zz ' 1 . Note that f r = x ee ' . Since e e' < r it follows that gcd(e e' , r ) = 1 . Using Euclids extended algorithm, we compute , from (e e' ) + r = 1 Then we have ( f r ) = ( x e e ' ) = x1 r = x ( x ) r From x = w r mod n and x = ( x f ) r we get the witness w = x f mod n

2.5

RSA commitment scheme

Key setup: RSA modulus N , a prime r , x R, Z / Z N .

RSA based e-cash system

04-06-2003

Jens Bo Friis

Committing: c = commit ( N ,r , x ) (e, z ) = z r x e mod N , where message e Z / Z r and a random

z R, Z / Z N
Revealing: To open a commitment, reveal the message e and the randomness z and check

c = z r x e mod N
Now we build a 3-move -protocol (a, e, z ) that proves committed value: Commit message: send C = Z r x E mod N to verifier, where Z R, Z / Z N and E R, Z / Z r Challenge: send d R, Z / Z r to prover. Response to challenge: E ' = ed + E mod r and Z '= z d Zx h mod N , where h = ed + E div r . Send ( E ' , Z ' ) to verifier Verify: C Z / Z n , Z ' Z / Z n , E ' Z / Z r and Z ' r x E ' c d C mod N In short we define functions ( A, E , Z , B) each calculating the steps in the -protocol. Commit message: C = A(( N , r , x), Z , E ) , challenge d = E () , response to challenge

( E ' , Z ' ) = Z (( N , r , x, e, z ), ( E , Z ), d )
Check: B (( N , r , x, c), d , C , ( E ' , Z ' )) = 1 Special honest verifier zero-knowledge Since Z is uniformly random in Z / Z N , therefore Z ' = z d Zx h mod N is uniformly random in Z / Z N . Since E is uniformly random in Z / Z r , therefore E ' = ed + E mod r is uniformly random in Z / Z r . Given an instance c and a challenge d Z / Z r , we can simulate by picking Z ' R, Z / Z N and

E ' R, Z / Z r and compute C = Z r x E ' c d mod N .

Special soundness We assume that we have one commitment but two different challenge-response phases in the protocol we have (c, C , (d ' , E ' , Z ' ), (d ' ' , E ' ' , Z ' ' )) , where C Z / Z N , Z ' Z / Z N , E ' Z / Z r ,

Z ' ' Z / Z N , E ' ' Z / Z r , c d 'C Z 'r x E ' mod N , c d ''C Z ' 'r x E '' mod N and d ' d ' ' .
Then c d ' d '' = ( Z ' Z ' ' 1 ) r x E ' E ''

c ( d ' d '') = (( Z ' Z ' ' 1 ) ) r x ( E ' E '')

since gcd(d 'd ' ' , r ) = 1 , we can compute (d 'd ' ' ) + r = 1 we continue

c = (c ( Z ' Z ' ' 1 ) ) r x ( E ' E '')

If we substitute with z ' = c ( Z ' Z ' '1 ) and e' = ( E ' E ' ' ) we get

c = z ' r x e ' mod N = z r x e mod N

5

RSA based e-cash system

04-06-2003

Jens Bo Friis

Since we need to guarantee that e' Z / Z r , we therefore get the committed message e = e' mod r which is what we are looking for.

2.6

RSA blind signature scheme

The blind signature scheme makes it possible for a 3rd party to do the signing, without knowing what information is signed. This scheme is used obtaining a bank signature on some user generated coin in order to preserve anonymity. Key setup: Signers RSA public key or verification key ( N , e) and corresponding private key or signing key ( N , d ) . Blinding: x = H (m)r e mod N , where blinding factor r R, Z / Z N , a verification key

( N , e) and message m
Signer: y = x d mod N , where signing key ( N , d ) , y is the signed and blinded message m . Unblinding: S = yr 1 mod N , where S is the signature on message m . Verify: S H (m) d mod N In short we define a blinding function x = blind vk (m; r ) , where verification key vk and signing key sk and r is the randomness, the blinding factor. We define a signing function y = sig sk ( x) , an unblinding function S = unblind vk ( y, r ) and finally a verification function vervk (m, S ) = 1 if verified correctly. Rewritten we get vervk (m, (unblind vk ( sig sk (blind vk (m, r )), r ))) = 1 I will not go into details about the security of this scheme, but just assume that it is secure, if r is chosen uniformly random.

2.6.1

A variant, the CFN blind signature scheme

This scheme can sign sets of messages. It was developed by Chaum, Fiat and Naor. Key setup: The key is a RSA key (n, e, d ) , an integer l . The verification key is (n, e, l ) . Like in the blind signature scheme, we use a hash function H Blinding: Signature requester has l messages (m1 ,..., ml ) . For all i = 1,..., l compute

xi = H (mi )ri mod n , where r R, Z / Z n . Send ( x1 ,..., xl ) to the signer.

e

Signing: Compute S = (

l i =1

xi ) d mod n and send S to requester.

l i =1 i

Unblinding: Compute s = S ( Verify: s e (

r ) 1 mod n

l i =1

H (mi )) mod n

In short we define a blinding function ( x1 ,..., xl ) = blind vk ((m1 ,..., ml ); (r1 ,..., rl )) , where verification key vk and signing key sk and (r1 ,..., rl ) is the randomness, the blinding factor. We define a signing function S = sig sk ( x1 ,..., xl ) , an unblinding function

RSA based e-cash system

04-06-2003

Jens Bo Friis

s = unblind vk ( S , (r1 ,..., rl )) and finally a verification function vervk ((m1 ,..., ml ), s ) = 1 if
verified correctly. Rewritten we get:

vervk ((m1 ,..., ml ), (unblind vk ( sig sk (blind vk (m1 ,..., ml , (r1 ,..., rl )), (r1 ,..., rl )))) = 1

The Digicash system

This section describes the Digicash protocols, for the different phases; withdraw, buy and deposit. The withdraw phase, where the user talks to the bank, identifying, generating pre-coins, bank signing some of the pre-coins and final process of making pre-coins into actual coins. The pay phase, where the user buys some item online and pays on-the-fly using one or more coins. The deposit phase, where the shop deposits the coins received from the payment phase and the bank verifies the deposit, detecting double deposit and double spending. All three protocols involve sessions, ex. to combine two or more payments into one buy, since not all things costs the same. We define a cryptographic hash-function H to be one-way and secure. In this implementation we use SHA1. The basics of this system are: Withdrawal: The user generates a set of part-coins, coins that not yet have been verified. These coins are prepared at customers location, partly offline. The generation phase itself, can be offline, preparing lots of coins. When part-coins have been prepared; generated, committed and blinded, the part coins are sent to the bank for verification The bank asks the customer to unblind some of the part coins, selecting a random sub-set. This is the cutnchoose protocol as know from the literature. The sub-set could be say half of the generated part-coins. The customer unblinds the chosen part-coins and sends them to the bank. The bank then verifies the customer signature, part-coin integrity and if everything is found ok, the bank then regroups the part-coins into a set of final coins and signs them using the blind signature scheme. Doing a batch withdrawal of coins optimizes the performance of the protocol compared to the amount of signings needed. Why is described later. Finally the bank withdraws the total amount (for all coins) from the customers bank account. The customer then unblinds the coins and saves them in a secure wallet. The customer then wants to buy some item at a shop and he requests a shop id and payment id. Using this challenge, the final stages of the commitment scheme, the -protocol, are completed. Now the coin has been spent. The customer keeps paying until the complete amount has been paid 7

Payment:

RSA based e-cash system

04-06-2003

Jens Bo Friis

The shop then lets the customer download the item. The shop needs to deposit the spend coins. This is done by sending them to the bank. The bank verifies the coins signature and integrity, just like the shop did. The bank then looks up the coin in their already-deposited-coins-database to see if the coin already exists. If it does, two things could have happened: 1) the coin could have been double spent. In this case, the bank can reveal the customers identity, using the special soundness of the commitment scheme. The bank then probably closes the customers account, and sends a letter to him. 2) The shop has double deposited the coin. In this case the bank could simple ignore this or perhaps stop accepting deposits from that shop. Finally the bank deposits the coin value at the shops account.

Deposit:

The difficult part of the above is to get around the performance bottleneck with the cutnchoose technique in the withdrawal process.

3.1

Key setup

The parties in the protocols are the bank B , the withdrawer W and a shop. There might be several withdrawers and shops. The withdrawer has a private key Wsk and a public key Wvk . The bank has a public key ( Bvk , BK ) , where Bvk is the verification key of the blind signature scheme and

BK is the key of the perfect hiding commitment scheme.

The bank public key must be known by all parties of the system. Further the bank must hold a proof that Bvk belongs to W . This is done during identification, as described later. Note that the moduli from the Bvk and from BK should be generated independently. All private keys could be stored on a secure device, like a smartcard, running signature schemes. This would greatly improve the security around the private keys.

3.2

Part-coins

The structure of the public part-coin will be (c, a, aux, V , sigV ) and the private part-coin will be (cid b , cid w , s, r , u , E , Z ) . A signature on the public part-coin will be ( sig c , sig a , sig aux ) . We first define some coin constants, that is used in the protocols

m = total number of part-coins in one withdraw

l = number of part-coins left after part-coin reveal

o = number of part-coins to be opened by bank during reveal p = part-coins in each coin, after reveal and sign Cw = number of coins per withdraw.

Private part-coin information:

RSA based e-cash system

04-06-2003

Jens Bo Friis

cid b is the bank part of the coin id. All part coins in one withdrawal contains the same
bank coin id. This gives the bank a way of binding a coin to a user. This gives the bank a possibility to link the coin id to the user. This is needed to detect double spending. The bank part coin id 64 bits long and is selected randomly.

cid w is the withdrawer part of the coin id. This is unique for each part coin generated.
Together with cid b , a unique part coin is generated in the system. The withdrawer keeps

cid w secret. This is a random 128 bits value.

s Z / Z r* is the combination of the coin ids, s = (cid b , cid w ) . The resulting s is 192
bits long. The size of this is critical to the speed of the withdraw protocol. I will describe this later. The smaller s , the faster coin withdraws. But the larger s the more coins can be generated.

* r R, Z / Z n is the random input, used in the RSA commitment scheme.

* u R, Z / Z n is the blinding factor, used in RSA blind signature scheme.

E R , Z / Z r* is the random input of the commit message of the RSA commitment

scheme, proof of knowledge using -protocol.
* Z R , Z / Z n , is the random input of the commit message of the RSA commitment

scheme, proof of knowledge using -protocol. Public part-coin information:

c is the commitment to the message s , using RSA commitment scheme. This perfect
hiding commitment under the key.

a is the initial commit message of the RSA commitment scheme, proof of knowledge
using -protocol. Building this commitment into the final coin makes the double spending detection possible.

aux is an auxiliary value. In this system, we represent the value of the coin by this
property. Format is not important as long as bank and withdrawer agrees upon. In this implementation, aux is an integer representing the value of the coin. Note that this value does not contain any information about the identity of the withdrawer.

V = H (cid w ) , a secure one-way hash of the user chosen cid w sig v is a signature on (V1 ,..., Vm ) , m is the number of part-coins. The signature can be
verified using the verification key of the user.

Part-coin signatures:

sig a is a signature on initial commit messages (a1 ,..., a p ) , as in the CFN blind signature
scheme

sig aux is a signature on coin values (aux1 ,..., aux p ) sig c is a signature on commitments (c1 ,..., c p )

RSA based e-cash system

04-06-2003

Jens Bo Friis

All signatures are validated as in the CFN blind signature scheme. This proves that signed messages has not been modified after bank signature has been applied.

3.3

Identification

The withdraw phase first requires provable identification. This is handled using the RSA signature scheme on some random text x . The signature S = sigWsk (x) is send to bank. The bank verifies the signature by checking verWvk ( x, S ) = 1 . The bank also verifies public key belonging to the user and verifies the validity of the public key. If all this holds, the bank holds a proof that the signing key Wsk belongs to the user.

3.4

Withdraw

The withdraw phase consists of several steps: 1) Withdrawer input is withdrawers private key Wsk and aux , the coin value. 2) The withdrawer gets cid b from the bank. This is the initial input of the withdrawal process together with withdrawers private key Wsk and banks public key ( Bvk , BK ) 3) For all part-coins needed to be created (1..m) a. The withdrawer generates coin id cid w and computes s = (cid b , cid w ) . Save s in the private part-coin. Notice that s computation is reversible. One can always get bank and withdrawers coin ids from s . b. The withdrawer computes a hash of the V = H (cid w ) . Save V in the public partcoin c. The withdrawer computes random bits r as input for the commitment. Save r in the private part-coin. d. The withdrawer computes commitment c = commit BK ( s; r ) . Save c in the public part-coin e. The withdrawer computes random input E and Z and computes commitment message of the commitment message a = A( E , Z , BK ) . Save a to the public part-coin. Save ( E , Z ) to the private part-coin 4) The withdrawer signs hashed coin ids sig V = sigW (V1 ,...,Vm ) using withdrawers private key Wsk . Using this technique, only one signature on all part-coins generated is computed, saving a lot of computing power, since cryptographic hash functions are much faster to compute than RSA signature scheme. The receiver, the bank, now has a proof that the user generated the part-coins. 5) The withdrawer blinds public part-coins using RSA blind signature scheme. This is done for each public part-coin generated (1..m) . Blinding key is the banks public key Bvk .

10

RSA based e-cash system

04-06-2003

Jens Bo Friis

a. Compute a random blinding factor u , used in the RSA blind signature scheme. Save u to private part-coin. b. Compute blinding on commitment c and on commitment message a . Note that aux and V is left unblinded. 6) The withdrawer now sends the blinded public part-coins C = (C1 ,..., C m ) to the bank 7) The bank responds with a random set of part-coins to be signed R = (i1 ,..., io ) where R C , the rest R * is to be revealed. The bank saves C and R and sends R to the withdrawer 8) The withdrawer copies the private part-coin and removes all R instances, leaving all R * . The revealed private part coin is send to the bank. 9) The bank uses the private part-coin to verify information send in the saved public partcoin. First the bank verifies that verW ( sigV , (V1 ,...,Vm )) = 1 . 10) The bank verifies that all coin values aux are the same in all public part-coins. 11) For all R * instances in C do: a. Verify that all cid b are the same in the revealed private part-coin. b. Verify that cid w from the private part-coin and V from the public part-coin computes V = H (cid w ) . 12) The bank verifies general integrity of the private and public part-coins, like revealed challenge actually matches revealed private part-coins. 13) The bank now regroups the public part-coins not revealed R = ( R1 ,.., Rl ) into sets of coins (1..Cw) and within each coin R = ( R1 ,.., R p ) . We need to regroup part-coins, in order to be able to sign each coin, so each coin can be used independently. 14) The bank first prepares a set of coins (1..Cw) and corresponding signed coins information. The bank then signs each coin (1..Cw) . a. Compute sig a = sig Bsk (a1 ,..., a p ) . Save sig a in signed coin b. Compute sig aux = sig Bsk (aux1 ,..., aux p ) . Save sig aux in signed coin c. Compute sig c = sig Bsk (c1 ,..., c p ) . Save sig c in signed coin 15) The bank finally saves the withdrawer identity together with cid b . The will allow the bank to lookup withdrawers identity, if some coin in this withdrawal is double spend and the coin is opened. 16) The bank withdraws the coins value amount = aux * Cw and sends the coin signature to the withdrawer. Some errors could occur during the last steps of the withdrawal process, so that withdrawer ends up with useless coins and money withdrawn from his account. One could think that withdrawal from the his account, could wait until coins are deposited (spend), but that would break the anonymity, since coins then would require

11

RSA based e-cash system

04-06-2003

Jens Bo Friis

some information on whos account money would have to be withdrawn from. I will not investigate this further. 17) The withdrawer now does the same coin regrouping as the bank did in step 13. This is needed to get the bank generated coin signatures straight. 18) The withdrawer unblinds the coin signatures ( sig c , sig a , sig aux ) , using the blinding factor u as described in the RSA blind signature scheme. 19) Finally the user has Cw coins of value aux , signed by the bank. A coin now consists of public coin (a1 ,..., a p ; c1 ,..., c p ; aux1 ,..., aux p ) , coin signature ( sig a , sig c , sig aux ) and private coin ( s1 ,..., s p ; r1 ,..., rp ) . All information is stored securely in the withdrawers wallet.

3.5

Wallet

This paper does not describe in detail, how coins can be stored in a secure way. There are numerous ways of doing this. Some could involve the use of smartcards, others encrypted files on the hard drive. We assume for now that the wallet is secure. The design of withdraw, pay and deposit protocols makes it possible for the bank to identify double spenders, i.e. users that has tampered with their wallets or withdraw or pay software. Wallet security has to do with user security, securing coins that a user has withdrawn so that no one else can steal or spend them. Just like hard cash in a leather wallet. In this implementation, I am using a simple password protection of both the private-part and the public part of the coin. Protecting this makes it hard to spend coins, without knowing the password. The wallet itself could be running on a smartcard but because of the huge amount of commitments required during withdraw, running withdraw programs on a low-CPU power device, would not be practicable. The wallet could be a physical file on a hard drive, using smart cards with encryption keys to access the content of the wallet.

3.6

Pay

The pay process is basically completing the -protocol started in the withdraw phase. During withdraw; the withdrawer computed a commitment message a = A(...) . The pay process completes the -protocol by computing the last steps E , Z , B . 1) We now assume that the payer has selected some item, he wants to buy. The payer receives a pay session id, which is unique within each shopping session. This pay session id is send to the shop for each payment within each shopping session. This allows for multiple payments, if the payer does not have a coin that matches the price of the selected item. The pay process is cycled for each coin payments. The pay session is updated with the price of the item. The item price is send to the payer. 2) The payer finds a set of suitable coins, starting with the largest coin in wallet that matches the item price and so on. The payer ends up with a set of coins which value gives the price of the item. If no suitable coins can be found, the wallet has run empty for a

12

RSA based e-cash system

04-06-2003

Jens Bo Friis

specific coin type. Break out and report the error to the payer that the wallet needs to be updated. 3) The shop sends a challenge ( sid , pid ) , where sid is a unique shop id and pid is a unique payment id, within the shop. Notice that this challenge e = E ( sid , pid ) where e Z / Z r* . Since r is 196 bits, this limits the message space of ( sid , pid ) . In this implementation sid is the shops unique company number, the CVR number, ensuring shop uniqueness. Since this is default 7 digits, this can be represented by 32 bits, leaving room for extensions. The pid consists of two parts. One part is some incremental number representing transactions within the shop. The other part is random. In this implementation, the incremental part has 64 bits reserved. This should be enough per shop. The remaining bits are random. 4) For each part-coin in the coin compute response to challenge z = Z ( E , Z , BK , ( s, r ), e) , where the random bits from the RSA commitment scheme is ( E , Z ) , BK is the commitment key of the bank, s is the committed message containing coin ids, r is the random bits of the RSA commitment scheme, z = ( E ' , Z ' ) and e is the shop challenge. The payer sends the public coin (a1 ,..., a p ; c1 ,..., c p ; aux1 ,..., aux p , E '1 ,..., E ' p , Z '1 ,..., Z ' p , e) and the coin signature

( sig a , sig c , sig aux )

5) The shop verifies the coin signature verBvk (( sig a , sig c , sig aux ), (a, c, aux)) = 1 6) The shop verifies that challenge e is correct 7) The shop verifies that B ( BK , c, e, E ' , Z ' , a ) = 1 . This is the last and final step of the protocol. Now the coin has been spend and the response-to-challenge step of the protocol now binds the coin, so double spending can be detected. If double spending is ever done, a new set of ( E*, Z *) will be computed and this is what the bank needs to compute coin ids using special soundness of the -protocol. Note that coin ids are stored together with the withdrawers identity at the bank. 8) The shop computes the remaining amount to be paid by the payer and sends that value to the payer. If no more is to be paid, send the value of zero. The shop updated remaining amount on the pay session id 9) The coin now consists of (a1 ,..., a p ; c1 ,..., c p ; aux1 ,..., aux p , E '1 ,..., E ' p , Z '1 ,..., Z ' p , e) and the coin signature ( sig a , sig c , sig aux ) . The shop stores this coin the shop wallet, for later deposit at the bank. 10) The payer repeats the pay process as long as the remaining amount is not zero, by continuing from step 3. 11) The payer sends a message pay finished to the shop 12) The shop validates that the pay session ids remaining amount is zero, and if true process the order.

13

RSA based e-cash system

04-06-2003

Jens Bo Friis

3.7

Deposit

The party in the deposit protocol is the depositor and the bank. The depositing is quite simple since its simply sending spent coins to the bank and depositing the value of the coins to the depositors bank account. 1) The depositor sends the spend coin

(a1 ,..., a p ; c1 ,..., c p ; aux1 ,..., aux p , E '1 ,..., E ' p , Z '1 ,..., Z ' p , e) and the coin
signature ( sig a , sig c , sig aux ) to the bank. 2) The bank verifies the coin signature 3) The bank uses the coin signature as a unique key for lookup in the spent-coin-database. If the coin has already been deposited, the two coins C and C * are different, the bank compute the special soundness, revealing the coin ids. The bank then knows the withdrawers identity and the bank would probably send a letter to the withdrawer: we know about your double spending habit. If the coins are equal, the coins are not double spend, but double deposited from the shop. The bank could either ignore this or send a letter to the shop. 4) The bank the deposits the coin and save in the spend-coin-database, using coin signature as the key. 5) The bank finally deposits the coin value at the depositors account.

3.8

Part-coin security and the security of the system

Coins are generated by the withdrawer. The coin ids that link the users identity to the coin are hidden using perfect hiding commitment scheme. This way the coin itself does not carry any identity information, besides the bank during withdrawal of cause knows the users identity. This is handled by blinding the coins using a blind signature scheme. This way the bank cannot register all the generated coins. Generated coins are now anonymous and the spending process must keep that anonymity. Since the -protocol does not reveal any information on the coins internals, but only proves the knowledge of, spending coins does not leak information. However if a withdrawer tries to double spend the coin, special soundness of the -protocol reveals the committed message, the coin id. The bank can then lookup the coin id and find the user. The coin therefore contains no information about the users identity and is therefore anonymous. The used -protocol is only honest verifier zero-knowledge and we cannot assume that the shop is honest. But since this does not seem to be a problem in practice, this is not fixed to keep simplicity. The bank cannot generate fake coins, since the pre-part-coin is signed using the withdrawers private key. The withdrawer cannot generate fake coins, since the final coins are signed using the banks private key. The shop therefore cant generate fake coins either. The shop can easily ensure coin integrity, by verifying the signature on the coin generated by the bank. No one else but the withdrawer can spend the coin, since only the withdrawer has the privatepart-coin, containing the committed message and the randomness of the commitment scheme.

14

RSA based e-cash system

04-06-2003

Jens Bo Friis

The bank security is covered by cutnchooseing the part-coins making it unlikely that the withdrawer has cheated, using fake coin ids.

4
4.1

Design considerations
Minimizing the amount of signatures

Generating a RSA signature requires exponentiation using the large exponent of the private key or signing key, which requires a large amount of multiplications. The verification exponent is however small and therefore verification is much faster than signing. This makes signing slow, especially when signing many part-coins. One design criteria was therefore to minimize the amount of signatures required, without loosing proof of private key ownership. In the withdrawal protocol, RSA signature schemes are computed in two situations: 1) At the withdrawer, signing all generated part-coins using CFN signature scheme. 2) At the bank, signing all verified, regrouped coins, using CFN blind signature scheme This gives a total of 1 + Cw signings required. The initial design was to sign all part-coins at withdrawers using withdrawers private key, requiring a total of m + Cw signings required. This optimization saved m 1 signings.

4.2

Generating more coins at a time, probability of cheating with coins

Generating large amount of coins optimizes the amount of signatures needed per final spend able coin. But we also want to minimize the probability that part-coins are bad. For simplicity we choose m = 2l . We have: m is the number of generated part-coins, l is the number of part-coins after reveal. Assume that there are a total of b bad part-coins. Since we open o = l part-coins there is a probability for each of the bad coins that it is amongst those opened. Therefore there is a probability b that none of the bad coins are opened. We set the probability of accepting bad coins to P = 2 70 = 8,4 * 10 22 . Then we get at most 70 coins of the remaining part coins are bad. If we send m = 1400 and open o = l = 700 , then at most

1 of the remaining are bad. Using c = 25 , the number of part-coins in a single coin, we 10 1 have a probability ( ) 25 < 2 70 that the generated coin does not contain bad coins. 10

Using the measured performance, as described later, we can withdraw 10 part-coins per sec. This gives us 140 secs to withdraw the above 28 coins. This is a time-coin ratio of 5:1

15

RSA based e-cash system

04-06-2003

Jens Bo Friis

Another setting is m=4416, l=2208, c=16, Cw=138 gives us security (

70 16 ) 10 24 . The 2208

time-coin ratio is 441sec/138 => 3.2:1 which is better than above, but is completed in 440 secs Another setting is m=704, l=352, c=32, Cw=11 gives us security ( coin ratio is 6.4:1 but is completed in 70 secs. Its clear that withdrawal cannot be done on-the-fly. Now, if we accept the probability of 2 30 10 9 that a bad coin ever occurs, we can at most generate 2 70 / 2 30 = 2 40 = 1012 coins total and still have the probability of 2 30 that anyone is bad. This is acceptable for a critical real-life application. Generating 1000 coins a sec, the system will run dry in 400 years. Another issue is about the probability of accepting bad coins. Lets say that B is the number of times a bad part-coin is sent to the bank. If there is one bad coin sent we will detect it with the probability of , seeing it half the times. Let A be the number of accounts that is ever open in the system. Lets say we close an account every time some user is caught sending bad coins. The number of closed accounts we call B . Since we cannot close more accounts than we open we have: 2 B A . Lets say that we give 50 accounts to all living persons. Then we have A 2 39 B 2 38 . So, at most 2 38 requests are ever made and with probability 2 70 2 38 = 2 32 that one of them is accepted. This is a risk we are willing to accept.

70 32 ) 3.5 *10 23 . Time352

4.3

Minimizing the exponentiation factors

The commitment computation requires two exponentiations, where one exponent, a prime r and the other exponent e Z / Z r which is the message to commit. A design goal is therefore to minimize the prime number r , minimizing the number of multiplications required to do the exponentiation. The message e , which is the coin ids, should still be large enough to hold the total amount of coin id generations. In the first version of the protocol, the withdrawer committed his identity into the coins. This required a large prime number r = 1024 bits. But a design change, committing coin ids instead, resulted in prime number r = 196 bits, since the only requirement was to be large enough to contain a coin id large enough to contain all coins generated at all times. This gives us a theoretical coin space of 2192 = 6,3 *10 57 coins. If we generate 1000 coins per sec, this gives us

2192 / 60 / 60 / 24 / 365 = 2 *10 50 years before no more coins can be generated.

The performance of Digicash

Test platform: Pentium 3, 1GHz Programming language: Java. Coin parameters: m=1400 (total amount of part-coins), o=700 (total amount of opened/revealed coins), p=25 (number of part-coins per coin) and Cw = 28 (total coins withdrawn).

16

RSA based e-cash system

04-06-2003

Jens Bo Friis

5.1

Withdrawal

It takes 2.5 minutes to withdraw 28 coins, all included (part-coin generation, blinding, revealing, verification, integrity checking, signing, unblinding). That is one coin per 5 secs. An empty wallet will withdraw 10, 20, 50 and 100 value coins, 28 of each. Total time was 4x2.5 = 10 minutes withdrawing worth 5040 credits. Performance can be quite acceptable under certain circumstances. If the system implements an intelligent wallet, which is capable of withdrawing coins offline and using spare time. This is in fact what I have partly done. The withdrawal application, examines the wallet content, withdrawing coins that the wallet is running low on. This means that the wallet only withdraws what is needed. Let say the customer buys a lot of online newspapers pages, spending much coins of one type. The withdrawal application will then withdraw only coins of that type. This speeds up withdrawal, to be acceptable but reloading an empty wallet, takes some time. How much time depends on how many coins of each type that is withdrawn. This should be compared to withdrawing coins of only one type, triggering many payments or withdrawing coins on-the-fly which introduces the waiting time of the withdrawal. Further, the above figures are from an only slightly optimized system. There is no math optimizations, no RSA signing optimizations (using Chinese remainder Theorem and multi prime keys), no debug information has been removed which will slow the system, and no extra integrity validation has been removed. This extra integrity validation is only to ensure correct calculations and should of cause no be present in a final system. My guess is that withdrawal could be optimized to run 10%-30% faster, without redesign. Rethinking the withdrawal and wallet strategies, could make the system run smoother, without the customers interaction and as a background process.

5.2

Payment

Payment is quite fast. Most of the time is being used in initializing the runtime, initializing the graphical user interface. The core payment process is fast, much faster than the surrounding environment. Note that this is based on a single coin payment. Paying with multiple coins, introduces some overhead; network communication, payment book-keeping etc. Using a two coin payment, payment takes approx. 1-2 sec. Performance of the payment protocol is probably the most user important thing in the system, since this would be the every day, multiple times per day event. The success of Digicash depends entirely on payment performance. If payment is too slow, no one will use it.

5.3

Deposit

Deposit is even faster, since no ping-pong protocols are being used. Deposit is again much faster than the surrounding environment.

5.4

Coin size and network transmission

During withdraw where many part-coins are generated and send to the bank, a large amount of information is transmitted to and from the bank.

17

RSA based e-cash system

04-06-2003

Jens Bo Friis

The largest transmit of data is the generated and blinded part-coins that is sent to the bank for verification. Since this part-coin bundle contains m part-coins, this message sent from the customer to the bank, is quite large. From above example where m=1400, this message takes up about 400KB of bandwidth. This is 3.5KB per part-coin. This is could in fact be a serious issue as of now, since many users still is connected to the internet using low bandwidth modems. But as time goes, more and more users are using high bandwidth internet connections, and then this is perhaps not that serious. Customers using 128Kb/sec upload, would have to wait 33 sec for a coin message to be transmitted. This must be added to the 2.5 minutes generating and verifying the coins. This totals to less than 3 minutes per 28 coins or one coin per 6 secs. One could easily imagine using the intelligent wallet and using an always-online internet connection, this would not be a problem at all. The second largest message sent in the system is a coin payment. A coin including signature takes up 11KB of bandwidth. This is still high, for low bandwidth users, but not near a problem for users using 128Kb/sec upload where network transmit time would be approx 1 sec. The remaining messages are small <3KB, and therefore not significant.

How the system is build

The Digicash demonstration is build of two applets, a bank website and a shopping website. Both applets are capable of running in the browser, making the visual experience seamless to the web page view.

Withdraw applet Customers browser Pay applet

Bank website

Withdrawing Depositing

Wallet Shops website Catalog Confirm buy Shopping Download

Wallet

18

RSA based e-cash system

04-06-2003

Jens Bo Friis

The shop must implement code to support the buy protocol. This code could be shared between all shops. The customer is surfing the shops website. The site functionality is just like any other shopping site, except when payment is needed. A pay java applet is then downloaded to the customers browser. The applet is initialized and shows a view where the customer selects a wallet and enters the unlock password for that wallet

Notice the cheat button. This is for double spending. The above example the user has apparently selected some item, costing 50 credits. His wallet currently contains 3220 credits. The user interface is shown every time the user selects some items to view or download. Of cause we implement this other ways, ex. using a hidden payment applet, doing the payment behind the scenes. Withdrawing credits from the bank is done by the customer identifying himself by selecting a personal X.509 certificate and unlocking the private key with a password.

The update button will examine the selected wallet, and withdraw the needed coins from the bank. The withdrawn coins are stored in the wallet, encrypted with a password. In this example the wallet will always contain credits of value 10, 20, 50 and 100. Again this could be implemented other ways ex. as a hidden background process, always keeping the wallet up to date.

19

RSA based e-cash system

04-06-2003

Jens Bo Friis

Conclusion

The primary goal of this project was to get the system up and running and to measure performance. As a result performance bottlenecks have been identified. Some I have already fixed. I came up with an example where the Digicash anonymity could be used, without need for the customer to enter shipping address or other identification. In this case the shop is an online mp3 music shop, where a customer can buy mp3 music by selecting and accepting payment. The music is the downloaded to the customers computer. But this is of cause not limited to only mp3 music. Pay-per-click like applications could also use this protocol, enabling micro-payments in an anonymous and secure way. So did it perform well enough? I think the performance of the system is surprisingly good. From the start I was very sceptical about the performance, especially the cutnchoose in the withdrawal phase. But I think it ended up quite effective. The multiple coin withdrawal and the one-time-signing of all part-coins instead of signing each part-coin speeded up withdrawal process more than 50 times. Withdrawal times are now in the acceptable range, where smart wallets, can make the withdrawal even more smooth. A goal with this project was to see, by starting from scratch; how far a RSA based implementation would get me. I am surprised that is took me all the way ending up with an online demo, being able to buy mp3 music using a browser over the internet anonymous and secure. Several minor implementation details remain to be solved. As of now, the bank public key cannot be easily changed, since a copy does not reside in each coin. Therefore the shop must know the public validation key beforehand. Another issue is about the shopping session. I have not solved the problem with roll-back of spend coins. Errors can happen during payment and if it happens after the customer have spent some coins, the shop now has valid deposit able coins but user has got no merchandise. An already known situation, but difference here is anonymity. The shop does not know the payer. Spend coins does not carry any identification, not even the coin id can be looked up, since this is really the key to the withdrawers identity. Therefore the shop cannot pay back the coin. The payer must rely on an honest shop which simply deletes the coins received from an unfinished payment transaction. If the shop never deposits the coins, the coins can be used again. This way the transactions can be rolled back. Maybe all users could have coin receiver status, like the shop? This would enable users to give coins to each other. Notice that no spent coin can/must be allowed to be given to others, since double spenders identity is the original withdrawers identity. Another extension to the system would be wallet security. In this example, the wallet is a simple password encrypted file, allowing anyone with access to the file and correct password to spend coins stored in the wallet. The wallet could run as an applet stored on a smart card. Since coins takes up 11KB, not many coins can be stored in a typical smart card. But the smartcard could secure some file on the hard drive.

20

RSA based e-cash system

04-06-2003

Jens Bo Friis

8
[1] 2002 [2] [3]

References
On Electronic Payment Systems, Roland Cramer and Ivan Damgrd, CPT 2001, apr. Anonym og sikker e-cash protocol (in Danish), Jens Bo Friis, 2003 Blind signatures for untraceable payments, Davis Chaum, Proc. CRYPTO 82

[4] Security without identification: transaction systems to make Big Brother obsolete David Chaum. 1985 [5] [6] Untraceable electronic cash, David Chaum, Amos Fiat, Moni Naor, CRYPTO 88 Wallet databases with observers. David Chaum, Torben Pedersen, CRYPTO 92

[7] Improved privacy in wallets with observers, Ronald Cramer, Torben Pedersen, EUROCRYPT 93

21