Simple and Efficient Contract Signing Protocol

Transcription

1 Simple and Efficient Cntract Signing Prtcl Abdullah M. Alaraj Infrmatin Technlgy Department Cllege f Cmputer, Qassim University Saudi Arabia Abstract In this paper, a new cntract signing is prpsed based n the RSA signature scheme. The will allw tw parties t sign the same cntract and then exchange their digital signatures. The ensures fairness in that it ffers parties greater security: either bth parties receive each ther's signatures r neither des. The is based n ffline Trusted Third Party (TTP) that will be brught int play nly if ne party fails t sign the cntract. Otherwise, the TTP remains inactive. The cnsists f nly three messages that are exchanged between the tw parties. Keywrds-cntract signing; fair exchange ; digital signature; s; security. I. INTRODUCTION Cntracts play an imprtant rle in many business transactins. Traditinally, paper-based cntracts are signed by the transacting parties wh need t be present at the same venue and at the same time. Each party signs a cpy f the cntract fr every cntracting party s that every party has a cpy f the signed cntract. If the parties, hwever, are nt able t meet t sign the paper-based cntract, then signing an electrnic cntract is an alternative. The prblem with signing electrnic cntracts, hwever, is exchanging the signatures f the parties, especially where there is a lack f trust between parties. One party may send the ther party their signature n the cntract but may nt receive the signature f the ther party in return. T slve the prblems f exchanging digital signatures, cntract signing s are used [3, 4, 5, 9, 10]. Cntract Signing Prtcls ensure that either cntracting parties receive each ther's signature r nne des. In this paper, a new, efficient cntract signing is prpsed. The prpsed is based n ffline trusted third party (TTP) that brught int play nly if ne party fails t send their signature n the cntract. In the nrmal executin f the, the tw parties will exchange their signatures directly. This paper is rganized as fllws. Related wrk is presented in sectin II. Sectin III presents the prpsed that cmprises the exchange and dispute reslutin. The analysis f the prpsed is discussed in sectin IV. The cmparisn f the prpsed with related s is presented in sectin V. II. RELATED WORK Early cntract signing s (as in [7, 16]) allw the parties t exchange their signatures directly withut any invlvement frm third party. That is, the parties gradually exchange their signatures in part until bth signatures are cmplete. If ne party fails t send an additinal part f the signature, the ther party wrks t search fr that remaining part. The gradual exchange s are based n the assumptin that the tw parties have the same cmputatinal pwer t ensure fairness. Hwever, in mst applicatins this assumptin is nt realistic [5]. The gradual exchange s require a large number f runds t cmplete the exchange f signatures. T vercme the prblems f gradual exchange f signatures, a trusted third party (TTP) is used in cntract signing s. The TTP helps the cntracting parties t exchange their signatures in a reliable and secure manner. The TTP can be used nline r ffline. In the nline-based third party cntract signing s [as in 6, 8,10] the TTP will be actively invlved in the exchange f the signatures between the parties. The parties will sign the cntract and send their signatures t the TTP wh will verify the signatures and if they are crrectly verified the TTP will frward the signatures t the parties. The main prblem with this apprach is that the TTP is invlved in every exchange and this may create a bttleneck. In additin t this, the fees f the third party make this a cstly apprach. In the ffline-based third party cntract signing s [as in 3, 4, 5, 11, 13 (als called ptimistic 11)], the parties will directly exchange each ther's signatures n a cntract. If ne party fails t submit their signature, the third party will be brught in t reslve any dispute. In the ffline-based third party cntract signing s, the TTP is rarely invlved which reduces the cst f running TTP. Als, the turnarund time is eliminated since the parties exchange their signatures directly. A categry f ffline TTP-based cntract signing s has been prpsed [3, 4, 5]. This categry vercmes the farness prblem by using verifiable and recverable encrypted signatures. This apprach will generally wrk as described belw. Let s say that tw cntracting parties, Alice and Bb, want t exchange their signatures n a cntract. 67 P a g e

2 Alice will sign the cntract, encrypt the signature and then send the encrypted signature t Bb. Bb will then verify the encrypted signature and if it is crrectly verified, send his signature t Alice. If Alice finds that Bb's signature is crrect then she will send the decryptin key t Bb t decrypt her encrypted signature. If Alice fails t send the decryptin key, Bb will cntact the TTP t recver the decryptin key. Nenadic, Zhang and Bartn[3] prpsed a fair signature exchange. The is based n the verifiable and recverable encryptin f signatures n a cntract. Alice will send her partially encrypted signature t Bb wh will be able t verify it. If the encrypted signature is crrectly verified then Bb will send Alice his signature. On receiving Bb's signature, Alice will verify it and if it is crrectly verified then Alice will send the decryptin key t Bb t decrypt the encrypted signature. If Alice des nt send the decryptin key, Bb will cntact the TTP t recver Alice's signature. Ateniese [4] als prpsed a fair cntract signing. Ateniese's is based n the verifiable and recverable encryptin f a signature. If Alice and Bb want t exchange their signatures n a cntract then the will wrk as fllws. Alice will first sign the cntract, then encrypt the signed cntract with the public key f the trusted third party (TTP). Alice will then send Bb: (1) the encrypted signature, (2) evidence stating that Alice has crrectly encrypted her signature n the cntract. On receiving Alice's message, Bb will verify the evidence. If the evidence is valid then Bb will send his signature n the cntract t Alice. On receiving Bb's signature, Alice will verify it and if it is valid then Alice will send her signature n the cntract t Bb. If Alice des nt send her signature t Bb r Alice's signature is invalid then Bb can cntact the TTP t reslve the dispute. Wang [5] prpsed a fr signing cntracts nline. Their is based n the RSA signature. If Alice and Bb are planning t exchange their signatures n a cntract using Wang's [5] then Alice will first split her private key int tw parts d1 and d2. Only d2 will be sent t TTP. Alice will send Bb her partial signature that was signed using d1. On receiving Alice's partial signature, Bb will initiate an interactive zer-knwledge with Alice t check whether Alice's partial signature is crrect. If it is crrectly verified then Bb will send his signature t Alice. After Alice receives Bb's signature, Alice will verify it and if it is crrectly verified then Alice will send Bb the secnd part f her signature. If, hwever, Alice did nt send the secnd part f the signature, Bb can cntact the TTP t reslve the dispute. In this paper, we prpse a new apprach that uses verifiable and recverable encryptin f signatures that will allw the party wh receives the encrypted signature t verify it. If he / she crrectly verifies the encrypted signature, then it is safe fr this party t release his / her signature t the ther party because the TTP can be cntacted t recver the signature if the ther party fails t submit his / her signature. The prpsed des nt use the interactive zer-knwledge prfs fr verifying the encrypted signature as in [4 & 5]. Rather, the cntract certificate that is intrduced in this paper will allw the party wh receives the encrypted signature t verify it. III. THE PROPOSED CONTRACT SIGNING PROTOCOL A. Ntatins The fllwing represents the ntatins used in the prpsed : P a, P b, and P t : parties a, b, and TTP, respectively. C: The cntract t be signed by P a and P b C. at : the certificate fr the shared public key between P a and P t. C. at is issued by P t. A standard X.509 certificate [12] can be used t implement C. at Pk x = (e x, n x ): RSA Public Key [14] f the party x, where n x is a public RSA mdulus and e x is a public expnent Sk x = (d x, n x ): RSA Private Key [14] f the party x, where n x is a public RSA mdulus and d x is a private expnent h(m): a strng-cllisin-resistant ne-way hash functin enc.pk x (M): an RSA [14] encryptin f message M using the public key pk x (e x, n x ). The encryptin f M is cmputed as fllws: enc.pk x (M) = M ex md n x enc.sk x (Z): an RSA [14] decryptin f Z using the private key sk x (d x, n x ). The decryptin f Z is cmputed as fllws: enc.sk x (Z) = Z dx md n x Sig. x (M): the RSA digital signature [14] f the party x n M. The digital signature f party x n M is cmputed by encrypting the hash value f M using the private key sk x (d x, n x ). C-Cert: the cntract certificate. C-Cert is issued by CA. The cntents f C-Cert are: hesig: the hash value f the signature f P a n the cntract encrypted with pk at i.e. "h(enc.pk at (Sig. a (C)))" hc: hash value f the cntract CA's signature n C-Cert P x P y : M, means party x sends message M t party y X + Y: cncatenatin f X and Y B. Assumptins The fllwing represents the assumptins used in the prpsed : Channels between P a, P b and P t are resilient i.e. all sent messages will be received by their intended recipients Parties will use the same hashing, encryptin, decryptin algrithms. P t is trusted by all parties and will nt cllude with any ther party Parties P a and P b will agree n the cntract befre the starts 68 P a g e

3 Parties (P a, P b and P t ) already have their public keys and they are certified frm CA C. Registratin In the registratin phase, Pa needs t d the fllwing: P a will request frm P t t share an RSA public key with it. The shared public key is dented as pk at = (e at, n at ) and its crrespnding private key is dented as sk at = (d at, n at ). P t will certify the shared public key and issue the shared public key certificate C. at Pa will sign the cntract "C" using its private key sk a as Sig. a (C) and then send the fllwing t CA t certify the encrypted signature and issue C-Cert: Sig. a (C) + C + C. at On receiving P a 's request, CA will verify if the received signature is fr the cntract C included in P a 's message. If s, then CA will encrypt Sig. a (C) using the shared public key pk at that is included in C.at. That is, CA will cmpute: enc.pk at (Sig. a (C)) Then, CA will issue C-Cert that includes the items mentined in the "Ntatins" sectin. D. Exchange Prtcl The exchange represents the nrmal executin f the. It cnsists f the fllwing three steps (see Fig. 1): 1. [E-M1]: P a P b : C + C. at + C-Cert + enc.pk at (Sig. a (C)) 2. [E-M2]: P b P a : Sig. b (C) 3. [E-M3]: P a P b : Sig. a (C) verify "enc.pk at (Sig. a (C))". T verify the encrypted signature, P b will cmpute the hash value f "enc.pk at (Sig. a (C))" then cmpare it with "hesig" that is included in C-Cert. If they match, it means that P a encrypted the crrect signature. If all verificatins are crrect then P b will sign the cntract using their private key skb then will send the signed cntract "Sig. b (C)" t P a. Step [E-M3]: nce P a receives Sig.b (C), Pa will verify P b 's signature. That is, P a will decrypt the signature t get the hash value f the cntract then cmpare it with "hc" that is included in C-Cert. If P b 's signature is crrectly verified then P a will send their signature Sig.a(C) t P b Once P b receives Sig. a (C) then P b will verify it by decrypting the signature t get the hash value f the cntract and cmpare it with "hc" that is included in C-Cert. If the verificatin is crrect then the received signature is crrect. Nw, bth P a and P b have each ther's signatures n the cntract. Therefre, fairness is ensured. If P a did nt send E-M3 r sent incrrect E-M3 then P b can cntact P t using the dispute reslutin t reslve the dispute. E. Dispute Reslutin Prtcl Figure 1. Exchange Prtcl Step [E-M1]: P a encrypts the signed cntract with the shared public key pkat. Pa then sends the items C, C.at, C-Cert, enc.pkat(sig. a (C)) t P b. Step [E-M2]: nce P b receives E-M1 then they will d the fllwing verificatins: 1. P b will verify the crrectness f bth C. at and C-Cert by verifying the signatures n these certificates. 2. If the certificates are crrectly verified then P b will cmpute the hash value f the cntract and then cmpare it with "hc" that is included in C-Cert. 3. P b will als need t verify the crrectness f the encrypted signature f P a n the cntract i.e. P b will Figure 2. Dispute Reslutin Prtcl If P b did nt receive the step E-M3 r received an incrrect E-M3, P b can cntact P t t reslve the dispute. The dispute reslutin cnsists f the fllwing three steps (see Fig. 2): 1. [DR-M1]: P b P t : C + C. at + C-Cert + enc.pk at (Sig. a (C)) + Sig. b (C) 2. [DR-M2]: P t P a : Sig. b (C) 3. [DR-M3]: P t P b : Sig. a (C) Step [DR-M1]: if P b did nt receive the crrect signature r did nt receive the signature at all then P b will send message DR-M1 t P t t request a reslutin. Step [DR-M2]: nce P t receives DR-M1 then they will d the fllwing verificatins: P t will verify the crrectness f C. at and C-Cert by checking the signatures n these certificates. If the certificates are crrectly verified then P t will verify the crrectness f the encrypted signature f P a n the cntract i.e. enc.pk at (Sig. a (C)). T verify the encrypted signature, P t will either (i) cmpute the hash value f enc.pk at (Sig. a (C)) then cmpare it with 69 P a g e

4 "hesig" that is included in C-Cert. If they match it means that P a encrypted the crrect signature, r (ii) P t has the private key "sk at " crrespnding t the shared public key s it can decrypt the encrypted signature i.e. enc.pk at (Sig. a (C)) and then decrypt the signature with pk a and cmpare the decrypted hash with "hc" that is included in C-Cert. P t will als verify Sig. b (C) by decrypting the signature with pk b then cmparing the decrypted hash with "hc" that is included in C-Cert. If all verificatins are crrect then P t will send the message DR-M2 t P a and DR-M3 t P b. DR-M2 includes the signature f P b n the cntract. The signature f P b n the cntract is sent t P a t ensure fairness in the case where P b cntacted P t after receiving E-M1 i.e. P b may cheat by cntacting P t befre sending E-M2 t P a. Step [DR-M3]: P t will send Sig. a (C) t P b in DR-M3 Nw, bth P a and P b have each ther's signature n the cntract. Fairness is ensured either in the exchange r in the dispute reslutin if P a acts dishnestly. IV. ANALYSIS The fairness prperty in ur will be evaluated by studying the fllwing fur cases: (1) the first case where P a is hnest and P b is dishnest, (2) the secnd case where P a is dishnest and P b is hnest, (3) the third case where bth P a and P b are dishnest, and (4) the frth case where bth P a and P b are hnest. Case 1: If P a is hnest and P b is dishnest. P b acts dishnestly by sending an incrrect signature t P a r by cntacting P t befre sending his signature t P a. In the first scenari where P b sends an incrrect signature t P a, P a will check P b 's signature. Then if it is incrrect, P a will nt send his signature t P b in E-M3. In the secnd scenari where P b cntacted P t befre sending his signature t P a, P t will check P b 's request and if it is crrectly verified then P t will send the reslutin t bth P a and P b. Therefre, fairness is ensured Case 2: P a is dishnest and P b is hnest. P a can act dishnestly by sending the incrrect E-M1, sending the incrrect E-M3 r nt sending the E-M3 at all. In the scenari where P a sends incrrect E-M1, P b will verify E-M1 as described in sectin III. If P b finds that E-M1 is incrrect, they will nt send their signature t P a in E-M2. In this scenari n ne reveals their signature at this stage. In the scenaris where P a sends incrrect E-M3 t P b r P a des nt send E-M3, P b can cntact P t t recver P a 's signature. Case 3: bth P a and P b are dishnest. P a can act dishnestly by sending the incrrect E-M1, sending the E-M3 r nt sending the E-M3 at all. P b can act dishnestly by sending an incrrect signature t P a r by cntacting P t befre sending his signature t P a. The scenaris f case 3 are discussed in cases 1 and 2 abve. Case 4: bth P a and P b are hnest. If bth P a and P b act hnestly then fairness will be ensured in the exchange and there is n need t cntact P t at all. Therefre, the abve analysis f the fur cases shws that the fairness is ensured either in the exchange r in the dispute reslutin. It is wrth mentining that P t des nt need t receive any message frm P a in rder t reslve any dispute raised by P b. Rather, P t will receive the dispute request frm P b and then will decide if P b 's request is valid r nt. If the request is valid then P t will send the reslutin electrnically t bth P b and P a. The certificate C-Cert is unique fr each exchange. That is, every time P a and P b need t exchange their signatures n a cntract then a new certificate will be used. The shared public key certificate C. at, hwever, can be used fr signing an unlimited number f cntracts. P t is passive during the exchange i.e. in the nrmal executin f the P a and P b will nt need t cntact P t. In case P a misbehaves then P t will be cntacted by P b t reslve the dispute. V. COMPARISON WITH RELATED WORK The prpsed will be cmpared against cntract signing s that are based n verifiable and recverable encryptin f signatures, namely, Nenadic, Zhang and Bartn [3], Ateniese's [4] and Wang's [5]. Fr the cmparisn, we analyze the number f messages and the number f mdular expnentiatins in bth the exchange and dispute reslutin. The expnentiatin is the mst expensive cryptgraphic peratin in the finite field [5]. Bth the prpsed and Ateniese's Prtcl [4] have three messages in the exchange whereas Wang Prtcl [5] has seven messages. All s have three messages in the dispute reslutin. Regarding the mdular expnentiatins in the exchange, the prpsed has the lwest number f mdular expnentiatins, with nly six. Nenadic, Zhang and Bartn [3] has the lwest number f mdular expnentiatins in the dispute reslutin with nly five mdular expnentiatins. Our has seven mdular expnentiatins in the dispute reslutin. Ateniese's Prtcl [4] and Wang's [5] require interactive zer-knwledge prfs t allw ne party t verify the encrypted signature f the ther party. Our ffers greater efficiency in that it allws the receiving party t verify the encrypted signature using the cntract certificate (C-Cert). Frm Table 1, it is clear that the prpsed is mre efficient cmpared with the related s except fr the dispute reslutin as Nenadic, Zhang and Bartn [3] has the lwest number f mdular expnentiatins. 70 P a g e

5 # messages in exchange # messages in dispute reslutin # mdular expnentiatins in exchange # mdular expnentiatins in dispute reslutin TABLE I. Nenadic [3] PROTOCOLS COMPARISONS Ateniese Prtcl [4] Wang Prtcl [5] (taken 5 (taken VI. 22 (taken 20 (taken CONCLUSION 10.5 (taken frm [5]) Nt mentined Our A new ffline TTP-based fair cntract signing is prpsed in this paper. The prpsed ensures the exchange f signatures f tw parties n a cntract. At the end f the executin f the, bth parties get each ther's signatures r neither des. The prpsed cmprises f nly three messages in the exchange as well as nly three messages in the dispute reslutin. If ne party evades during the executin f the, the prvides an nline reslutin fr the disputes where the TTP will be invlved. The prpsed is efficient as it has the lwest number f mdular expnentiatins in the exchange. In a future study, we plan t investigate hw t make the an abuse-free as Wang did in [5]. We als intend t implement and integrate the prpsed with e- cmmerce applicatins fr the exchange f digital signatures between tw parties. REFERENCES [1] A. Alaraj, "Optimizing One Fair Dcument Exchange Prtcl" Internatinal Jurnal f Netwrk Security & Its Applicatins (IJNSA), Vl.4, N.1, pp. 1-12, January 2012 [2] A. Alaraj and M. Munr, An e-cmmerce Fair Exchange Prtcl that Enfrces the Custmert be Hnest. Internatinal Jurnal f Prduct Lifecycle Management, IJPLM, Vl.3, Ns.2/3, pp , 2008 [3] A. Nenadic, N. Zhang, and S. K. Bartn, "A Secure and Fair DSA-based Signature Exchange Prtcl ", the 9th IEEE Sympsium n Cmputers and Cmmunicatins (ISCC'2004), Alexandria, Egypt June 29-July 1, 2004, pp [4] G. Ateniese, Efficient verifiable encryptin (and fair exchange) f digital signature, in Prc. ACMCnf. Cmputer and Cmmunicatins Security (CCS 99), 1999, pp , ACM Press [5] G. Wang"An Abuse-Free Fair Cntract-Signing Prtcl Based n the RSA Signature" by G. Wang, IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 5, NO. 1, pp , MARCH 2010 [6] H. Burk and A. Pfitzmann, "Value Exchange Systems Enabling Security and Unbservability", Cmputers & Security 9, pp , 1990 [7] I. Damgard, "Practical and prvably secure release f a secret and exchange f signatures". In: Prceedings f advances in cryptlgy EUROCRYE T 93, vl Berlin, Germany: LNCS, Springer-Verlag; pp [8] J. Zhu and D. Gllmann, A fair nn-repudiatin, in Prc. IEEE Symp. Security Privacy, 1996, pp , IEEE Cmputer Press [9] L. Harn and C. Lin "Cntract signature in e-cmmerce" Cmputers and Electrical Engineering37 (2011), pp , 2011 [10] M. Ben-Or, O. Gldreich, S. Micali, and R. Rivest, A Fair Prtcl fr Signing Cntracts,IEEE Transactins n Infrmatin Thery, vl. 36, n. 1, pp , Jan [11] N. Askan, M. Schunter, and M. Waidner, Optimistic Prtcls fr Fair Exchange, Prc.Furth ACM Cnf. Cmputer and Cmmunicatin Security, pp. 8-17, Zurich, Switzerland,April 1997 [12] Public-Key Infrastructure (X.509), The PKIX wrking grup, available athttp://datatracker.ietf.rg/wg/pkix/charter/ accessed n [13] Q. Shi, N. Zhang, M. Merabtia: Fair exchange f valuable infrmatin: A generalised framewrk. Jurnal f Cmputer and System Sciences 77 (2011),pp [14] R. Rivest, A. Shamir, L. Adleman A methd fr btaining digital signatures and public-keycryptsystems, Cmmun ACM 1978; pp , 1978 [15] S. Micali, Simple and fast ptimistic s fr fair electrnic exchange, in Prc. PODC 03, 2003, pp , ACM Press. [16] T. Okamt and K. Ohta. "Hw t simultaneusly exchange secrets by general assumptins". In: Prceedings f ACM cnference n cmputer and cmmunicatin security, pp [17] X. Liang, Z Ca, R. Lu, and L Qin "Efficient and secure in fair dcument exchange", Cmputer Standards & Interfaces, Vl. 30 (2008), pp , 2008 [18] Z. Sha "Security analysis f tw RSA-Based fair dcument exchange ". In: Prceedings f the Secnd Internatinal Wrkshp n Cmputer Science and Engineering, Qingda, China, pp , 2009 AUTHOR PROFILE Abdullah Alaraj is presently a faculty member in the department f Infrmatin Technlgy, Cllege f Cmputer, Qassim University, Saudi Arabia. He received his BSc in Cmputer Science frm King Saud University (Saudi Arabia), his MSc in Internet and Distributed Systems frm Durham University(UK), and his PhD frm Durham University (UK). His areas f research interests include: e-cmmerce security, fair exchange s, fraud, trust, infrmatin security 71 P a g e