A novel proxy deposit protocol for e-cash systems

Applied Mathematics and Computation 163 (2005) 869–877 www.elsevier.com/locate/amc

A novel proxy deposit protocol for e-cash systems Yu-Yi Chen a, Jinn-Ke Jan

b,*

, Chin-Ling Chen

c,*

a

Department of International Trade, Providence University, Taichung 433, Taiwan, ROC Institute of Computer Science, National Chung Hsing University, Taichung 402, Taiwan, ROC Institute of Applied Mathematics, National Chung Hsing University, Taichung 402, Taiwan, ROC

b c

Abstract In this paper, we propose a refined proxy deposit protocol based on the scheme proposed by Yu and Lei, A proxy deposit protocol for e-cash systems, in: ICCSA2001, 2001, p. 289 and implement two mathematic models (for ElGamal and RSA scheme) base on the scheme of Chen et al., refined proxy deposit protocol for e-cash systems, in: ICCSA2002, 2002, p. 141. And in consideration of the relationship in most typical e-cash scheme (various studies), a merchant must maintain an account at the issuer for depositing the received e-cash from customers. Since there will be a lot of issuers in the real world, each merchant must maintain an account at each issuer for depositing all kinds of e-cash. In order to reduce the onus of the merchants, the concept of depositdelegation protocol will be introduced in this paper such that a merchant only has to maintain an account at its trading bank (as an acquirer) and delegates all deposit business to it. Ó 2004 Elsevier Inc. All rights reserved. Keywords: E-cash; ElGamal; RSA; Digital signatures; Cryptography

1. Introduction As Fig. 1 described, a naive deposit delegation protocol is used between the merchant and the issuer. Anytime the merchant wants to deposit the received

*

Corresponding author. E-mail addresses: [email protected] (J.-K. Jan), [email protected] (C.-L. Chen).

0096-3003/$ - see front matter Ó 2004 Elsevier Inc. All rights reserved. doi:10.1016/j.amc.2004.04.015

870

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

Fig. 1. A naive delegation protocol.

cash, the cash is transmitted to the acquirer and then re-transmitted to the issuer. After verifying and double-spending checking, the issuer transfers the corresponding funds to the merchant’s account at the acquirer via the financial clearing system. In 2001, Yu and Lei [1] proposed a fair and secure deposit delegation protocol for the sake of diminishing the merchant’s onus. Next year, Chen et al., [2] proposed a refined proxy deposit protocol for e-cash systems. As we know, the most popular proposed e-cash systems (for example [3–16]) are almost developed based on solving discrete logarithm difficult problem (ElGamal scheme) or solving factorization difficult problem (RSA scheme). We now propose two refined proxy deposit schemes in this paper for using in most ElGamal or RSA based e-cash systems. In consideration of the practicability, a deposit delegation protocol should satisfy the following properties. 1. No damage from intruder: even if an intruder steals some information in the interaction, the merchant and the banks will not suffer any damage. 2. Non-repudiation: upon a successful completion of a protocol run, the merchant and the acquirer cannot deny delegation agreement. 3. Fairness: neither the merchant nor the delegated bank can take advantage of each other. This means that the merchant will not lose any money and the acquirer will not suffer any hazards during the delegation. 4. Economy: the interaction between the merchant and the banks should be as simple as possible to keep from high cost of the protocol. 5. Independence: the proposed protocol will not affect the alteration of the cash. It should be suitable for using in different e-cash system.

2. Our scheme In this section, we will present our deposit delegation protocol. The underlying assumption of this paper is that the issuer is trustworthy, and all deposits are only done after successful authentication.

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

871

2.1. Our ElGamal base deposit delegation scheme We will illustrate our ElGamal base deposit delegation scheme as Fig. 2 description. The notations used in our first scheme are defined as follows: k: concatenation r; a; k: three random numbers P: a large prime number CE1 ; CE2 ; CE3 : the ElGamal base cipher text cash: the existed e-cash IDX : the identity of X PKX : the public key of X

Fig. 2. Our ElGamal base deposit delegation scheme.

872

SKX : t; s:

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

the secrete key of X the acquirer’s ElGamal base signature

Step 1: Initially, there is a large prime number P , a primitive number gðmod P Þ, each bank’s public key PKX and secret key SKX are generated as PKX ¼ gSKX ðmod P Þ; 1 < SKX < P  1. Step 2: Before the merchant delegates its received electronic cash to the acquirer, it randomly selects a blinding factor a and computes the following parameters. Mcash ¼ ðcashkIDMerchant Þ  a; CE1 ¼ gr ðmod P Þ; CE2 ¼ Mcash  ðPKAcquirer Þr ðmod P Þ; r

CE3 ¼ ðIDAcquirer kMcashkaÞ  ðPKIssuer Þ ðmod P Þ: The merchant sends ðCE1 ; CE2 ; CE3 Þ to the acquirer. Step 3: After the acquirer received the above message, the acquirer uses its secret key SKAcquirer to decrypt CE2 as follows: SK

1

r

CE2  ðCE1 Acquirer Þ ðmodP Þ ¼ Mcash  ðPKAcquirer Þ  ððgr Þ ¼ Mcash  ðg

SKAcquirer 1

Þ ðmodP Þ

r SKAcquirer 1

SKAcquirer r

Þ  ððg Þ

Þ ðmodP Þ

¼ McashðmodP Þ: Then the acquirer selects a random number k such that GCDðk; UðP ÞÞ ¼ 1 and uses its secret key SKAcquirer to sign Mcash as follows: t ¼ gk mod P ; s ¼ k 1  ðMcash  SKAcquirer  tÞ mod ðP  1Þ: The signature ðt; sÞ is sent back to the merchant as the non-repudiation proof. The other parameters ðCE1 ; CE3 Þ are forwarded to the issuer. Step 4: The issuer uses its secret key SKIssuer to decrypt ðCE1 ; CE3 Þ to get a, IDAcquirer , cash, and IDMerchant , as follows: SKIssuer 1 Þ ðmod P Þ CE3  ðCE1 SKIssuer 1

r

¼ ðIDAcquirer kMcashkaÞ  ðPKIssuer Þ  ððgr Þ SKIssuer r

Þ ðmod P Þ

r SKIssuer 1

¼ ðIDAcquirer kMcashkaÞ  ðg Þ  ððg Þ ¼ ðIDAcquirer kMcashkaÞ  ðmod P Þ ¼ ðIDAcquirer kMcashkaÞðmod P Þ Mcash  a ¼ ðcashkIDMerchant Þ  a  a ¼ ðcashkIDMerchant Þ:

Þ ðmod P Þ

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

873

Then the issuer verifies the cash is true or not, and records these parameters cash, IDAcquirer , and IDMerchant for the necessity of doubledeposit checking. Step 5: Finally, the issuer transfers the corresponding funds to the designated merchant’s account IDMerchant of the designated acquirer IDAcquirer . 2.2. Our RSA base deposit delegation scheme Besides, we will illustrate our RSA base deposit delegation scheme as Fig. 3 description. The different notations used in our second scheme are defined as follows: (pX ; qX ): a pair of large prime numbers NX : a large number, where NX ¼ pX  qX and /ðNX Þ ¼ ðpX  1Þ  ðqX  1Þ CR1 ; CR2 : the cipher text of RSA deposit delegation scheme SigAcquirer : the acquirer’s RSA base signature Step 1: Initially, each bank X chooses a pair of prime numbers ðpX ; qX Þ to compute the product. Then the public key PKX and the corresponding secret key SKX are generated as RSA encryption/decryption scheme such that PKX  SKX ¼ 1ðmod /ðNX ÞÞ. Step 2: Before the merchant delegates its received electronic cash to the acquirer, the merchant randomly selects a blinding factor a and computes the following parameters. Mcash ¼ ðcashkIDMerchant Þ  a; CR1 ¼ ðMcashÞPKAcquirer mod NAcquirer ; CR2 ¼ ðIDAcquirer kMcashkaÞPKIssuer mod NIssuer : The merchant sends ðCR1 ; CR2 Þ to the acquirer. Step 3: After the acquirer received the above message, the acquirer uses its secret key SKAcquirer to decrypt CR1 as follows: ðCR1 Þ

SKAcquirer

mod NAcquirer ¼ ððMcashÞ

PKAcquirer SKAcquirer

Þ

mod NAcquirer

¼ Mcash mod NAcquirer : Then the acquirer uses its secret key SKAcquirer to sign Mcash as follow: SigAcquirer ¼ ðMcashÞ

SKAcquirer

mod NAcquirer :

The signature SigAcquirer is sent back to the merchant as the nonrepudiation proof. The other parameter CR2 is forwarded to the issuer. Step 4: The issuer uses its secret key SKIssuer to decrypt the CR2 to get a, IDAcquire , cash, and IDMerchant as follows:

874

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

Fig. 3. Our RSA base deposit delegation scheme.

ðCR2 Þ

SKIssuer

ðmod NIssuer Þ

¼ ððIDAcquirer kMcashkaÞPKIssuer ÞSKIssuer mod NIssuer ¼ IDAcquirer kMcashka Mcash  a ¼ ðcashkIDMerchant Þ:

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

875

Then the issuer verifies the cash is true or not, and records these parameters cash, IDAcquirer , and IDMerchant for the necessity of doubledeposit checking. Step 5: Finally, the issuer transfers the corresponding funds to the designated merchant’s account IDMerchant of the designated acquirer IDAcquirer .

3. Analysis We have proposed two reliable deposit delegation protocols, now we want to examine whether the aforesaid properties are satisfied or not. 3.1. No damage from intrude issue In our both schemes, it is useless for the intruder to steal the delegated coin. (A) In our ElGamal base deposit delegation scheme: Mcash ¼ ðcashkIDMerchant Þ  a; CE1 ¼ gr ðmod P Þ; r

CE2 ¼ Mcash  ðPKAcquirer Þ ðmod P Þ; r

CE3 ¼ ðIDAcquirer kMcashjaÞ  ðPKIssuer Þ ðmod P Þ: Even anyone intercepts (CE1 ; CE2 ; CE3 ), it is impossible for the intruder to get the cash since it is blinded by a and encrypted into (CE1 ; CE2 ; CE3 ). Only the issuer can use its secret key SKIssuer to decrypt ðCE1 ; CE3 ) to get a and cash. SKIssuer 1 Þ ðmod P Þ ¼ ðIDAcquirer kMcashkaÞðmod P Þ CE3  ðCE1

Mcash  a ¼ ðcashkIDMerchant Þ: (B) In our RSA base deposit delegation scheme: Mcash ¼ ðcashkIDMerchant Þ  a; CR1 ¼ ðMcashÞPKAcquirer mod NAcquirer ; CR2 ¼ ðIDAcquirer kMcashkaÞ

PKIssuer

mod NIssuer :

It is also useless for the intruder to intercept (CR1 ; CR2 ) to get the cash. Only the issuer can use its secret key SKIssuer to decrypt CR2 to get a and cash. ðCR2 Þ

SKIssuer

ðmod NIssuer Þ ¼ IDAcquirer kMcashka Mcash  a ¼ ðcashkIDMerchant Þ:

876

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

3.2. Non-repudiation issue In our protocol, there is no excuse for the acquirer to repudiate any deposit delegation as the receipt signature is issued to the merchant. (A) In our ElGamal base deposit delegation scheme: The receipt ðt; sÞ can be verified as follow: ?

t

gMcash ¼ðPKAcquirer Þ  ts mod P : (B) In our RSA base deposit delegation scheme: Similarly, the receipt SigAcquirer can be verified as follow: ?

Mcash¼ðSigAcquirer Þ

PKAcquirer

mod NAcquirer :

If necessary, the merchant should release the right a to prove ðcashkIDMerchant Þ  a equal to Mcash. Clearly, the receipt can be claimed as evidence for declaring the delegation of the cash. 3.3. Fairness issue First, the merchant will not lose his right by reason of holding the receipt signature. As we just state, even if the acquirer terminates the delegation maliciously after holding of Mcash and related cipher text, the merchant will also not lose anything because of the acquirer has no issuer’s secret key SKIssuer and random number a to unblind Mcash to get the cash. As we know, both identity of the merchant IDMerchant and the acquirer IDAcquirer is designated in Mcash such that it is useless to be transmitted to another one. Second, the acquirer will not suffer any hazards. No one can forge or tamper the corresponding signature. That means no one can make a fake receipt for framing the acquirer. 3.4. Economy issue In our both schemes, to speak of any participant parties, it is economical and efficient since there is at most one run during the relative communication session. 3.5. Independence issue Our protocol does not invoke trusted third party, hardware, and any alteration of the cash. As we know, the most popular proposed e-cash systems are almost developed based on solving discrete logarithm difficult problem (ElGamal scheme) or solving factorization difficult problem (RSA scheme). Based on this reason, our two schemes should be suitable for using in most e-cash systems.

Y.-Y. Chen et al. / Appl. Math. Comput. 163 (2005) 869–877

877

4. Conclusion We have proposed two realistic schemes that are simple and secure. Our scheme meets all of the requirements that we identified in the above section by incorporating cryptographic mathematic model that make our system firm against anyone’s fraud. Up to date, there are many electronic cash systems have been proposed, and a typical clearing system is necessary urgently. Our proposal contributes an efficient and practical proxy deposit protocol to integrate most different e-cash systems in the real life.

References [1] P.L. Yu, C.L. Lei, A proxy deposit protocol for e-cash systems, in: ICCSA2001, 2001, pp. 289– 295. [2] Y.Y. Chen, J.K. Jan, C.F. Kuo, A refined proxy deposit protocol for e-cash systems, in: ICCSA2002, 2002, pp. 141–146. [3] C. Boyd, E. Foo, Off-line fair payment protocols using convertible signatures, in: Proceedings of ASIACRYPT’98, 1998, pp. 271–285. [4] D. Chaum, A. Fiat, M. Naor, Untraceable electronic cash, in: Advances in Cryptology–– Proceedings of Crypto’88, 1989, pp. 319–327. [5] G. Di Crescenzo, A non-interactive electronic cash system, in: Proceedings of Italian Conference on Algorithms and Complexity, CIAC’94, 1994, pp. 109–124. [6] S. D’Amiano, G. Di Crescenzo, Methodology for digital money based on general cryptographic tools, in: Advances in Cryptology––EUROCRYPT’94 Proceedings, 1995, pp. 156–170. [7] M. Jakobsson, mini-cash: a minimalistic approach to e-commerce, in: Public Key Cryptography PKC’99, Lecture Notes in Computer Science, vol. 1560, 1999, pp. 122–135. [8] Mao, Wenbo, Lightweight micro-cash for the Internet, in: ESORICS’96, (LNCS1146), 1996, pp. 15–32. [9] G. Medvinsky, B.C. Neuman, ‘‘Netcash: a design for practical electronic currency on the Internet, in: Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 102–106. [10] T. Okamoto, An efficient divisible electronic cash scheme, in: Advances in Cryptology–– EUROCRYPT’95 Proceedings, 1996, pp. 433–451. [11] T. Okamoto, K. Ohta, Disposable zero-knowledge authentication and their applications to untraceable electronic cash, in: Advances in Cryptology––CRYPTO’89 Proceedings, 1990, pp. 481–496. [12] T. Okamoto, K. Ohta, Universal electronic cash, in: Advances in Cryptology––CRYPTO’91 Proceedings, 1992, pp. 324–337. [13] P. Panurach, Money in electronic commerce: digital cash, electronic fund transfer, and ecash, Communications of the ACM (1996) 45–50. [14] T. Poutanen, H. Hinton, M. Stumm, Netcents––a lightweight protocol for secure micropayments, USENIX, 1998. [15] M. Sirbu, J.D. Tygar, NetBill: An internet commerce system optimized for network delivered services, IEEE Personal Communications 2 (4) (1995) 34–39. [16] Y. Yacobi, efficient electronic money, in: Advances in Cryptology––ASIACRYPT’94 Proceedings, 1996, pp. 153–163.