Rsa Based Solution For Fair Contract Signing

Rsa Based Solution For Fair Contract Signing

Rsa Based Solution For Fair Contract Signing

Rajasree R.S.

.

A fair contract signing protocol allows two potentially mistrusted parties to exchange their commitments to an agreed contract over the Internet in a fair way so that either each of them obtains the others signature or neither party does. Based on the RSA scheme a new digital contract signing is proposed. The proposed protocol satisfies new property abuse freeness. That is if the protocol is executed unsuccessfully, none of the two parties can show the validity of intermediate results to others. Here the first abuse free fair contract signing protocol based on the RSA signature is presented and it is showed that it is both secure and efficient.

Introduction

Contract signing plays a very important role in any busi- ness transaction, in particular in situations where the in- volved parties do not trust each other to some extent al- ready. Contract signing is truly simple due to the existence of simultaneity. That is, both parties generally sign two hard copies of the same contract at the same place and at the same time.

After that, each party keeps one copy as a legal docu- ment that shows both of them have committed to the con- tract. If one party does not abide by the contract, the other party could provide the signed contract to a judge in court. As electronic commerce is becoming more and more im- portant and popular in the world, it is desirable to have a mechanism that allows two parties to sign a digital contract via the Internet.However; the problem of contract signing becomes difficult in this setting, since there is no simul- taneity any more in the scenario of computer networks. In other words, the simultaneity has to be mimicked in order to design a digital contract-signing protocol. Information is exchanged in computer networks nonsimultaneously, so at least an unfair state must be passed through. From the view point of technique, the problem of digital contract signing belongs to a wider topic: fair exchange. Actually, fair ex-

change includes the following different but related issues: contract-signing protocols, certified e-mail systems nonre- pudiation protocols and e-payment schemes in electronic commerce .In this paper, the problem of digital contract signing between two parties is focused. Since a partys commitment to a digital contract is usually defined as his/her digital signature on the contract, digital contract signing is essentially implied by fair exchange of digital signatures between two potentially mistrusted parties. There is a rich history of contract signing (i.e., fair exchan- geof digital signatures) because this is a fundamental prob- lem in electronic transactions.

1. EXISTING SYSTEM

   According to the involvement degree of a trusted third party (TTP), contract-signing protocols can be divided into three types: 1) gradual exchanges without any TTP; 2) pro- tocols with an on-line TTP; and 3) protocols with an off- line TTP. Early efforts mainly focused on the first type of protocols to meet computational fairness: Both parties ex- change their commitments/secrets bit-by-bit.If one party stops prematurely, both parties have about the same frac- tion of the peers secret, which means that they can com- plete the contract off-line by investing about the same amount of computing work, e.g., exclusively searching the remaining bits of the secrets.

   The major advantage of this approach is that no TTP is involved. However, this approach is unrealistic for most real-world applications due to the following reasons. First of all, it is assumed that the two parties have equivalent or related computation resources. Otherwise, such a protocol

   is favorable to the party with stronger computing power, who may conditionally force the other party to commit the contract by its own interest. At the same time, such proto- cols are inefficient because the costs of computation and communication are extensive. In addition, this approach has the unsatisfactory property of uncertain termination. In the second type of fair exchange protocols an on-line TTP is always involved in every exchange. In this scenario TTP is essentially a mediator: a) Each party first sends his/her item to the TTP; b) then, the TTP checks the validity of those items; c) if all expected items are correctly received, the TTP finally forwards each item to the party who needs it. Contract-signing protocols with an on-line TTP could be designed more easily since the TTP facilitates the execu- tion of each exchange, but may be still expensive and inef- ficient because the TTP needs to be paid and must be part of every execution.

2. PROPOSED SYSTEM

   This paper shows the importance of abuse-freeness and security in contract signing by proposing a new contract- signing protocol for two mutually distrusted parties. The protocol is based on an RSA multisignature, which is for- mally proved to be secure .This protocol is fair and opti- mistic. Furthermore, different from the above existing schemes,theprotocol is abuse-free.

   1. Fairness

      Our protocol guarantees the two parities involved to ob- tain or not obtain the others signature simultaneously.This property implies that even a dishonest party who tries to cheat cannot get an advantage over the other.

   2. Optimism

      The TTP is involved only in the situation where one par- ty is cheating or the communication channel is interrupted.

   3. Abuse-Freeness

      If the whole protocol is not finished successfully,any of the two parties cannot show the validity of the intermediate results generated by the other to an outsider,either during or after the procedure where those intermediate results are produced.

   4. Provable Security

      Under the standard assumption that the RSA problem is intractable, the protocol is provably secure in the random hash function model, where a hash function is treated as if it were a black box containing a random function.

      Timely Termination:

      The execution of a protocol instance will be terminated in a predetermined time. This property is implemented by adding a reasonable deadline in a contract. If one party does not send his/her signature to the other party after the deadline , both of them are free of liability to their partial commitments to the contract and do not need to wait any more.

      1. Compatibility:

         In our protocol, each partys commitment to a contract is a standard digital signature. This means that to use the protocol in existing systems, there is no need to modify the signature scheme or message forma at all. Thus, it will be very convenient to integrate the contract-signing protocol into existing software for electronic transactions.

      2. TTPs Statelessness:

         To settle potential disputes between users, the TTP is not required to maintain a database to searching or remember- ing the state information for each protocol instance, so the overhead on the side of the TTP is reduced greatly.

      3. High Performance:

         In a typical implementation, the protocol execution in a normal case requires only interaction of several rounds be- tween two parties, transmission of about one thousand bytes of data, and computation of a few modular exponentiations by each party.

         Existing System

         (n)

         Alice sets an RSA modulus n=pq whwre p and q are two safe k bit primes and sets her public key e R Z* , and calculates her private key

         d=e -1mod(n) (1)

         where mod(n) is Euers totient function. Then, she reg- isters her public key with a certification authority (CA) to get her certificate .After that, Alice randomly splits d into

         (n)

         d1 and d2 so that d=d1+d2, where e R Z* . To get a voucher VA from a TTP, Alice is required to send

         (CA,e 1,d 2)to the TTP, where

         1

         e1=d -1 mod(n) (2)

         The voucher is the TTPs signature that implicitly shows two facts:

         1. e1 can be used to verify a partial signature generated by using secret key d1, and

         2. the TTP knows a secret d2 matches with RSA key pairs (d1,e1)and (d,e) .When Alice and Bob want to ex- change their signatures on a message m, Alice first com- putes

      Strong RSA-Based Trapdoor Commitment Scheme

      The following RSA-based efficient trapdoor commit- ment scheme

      1. TCgen: The receiver Bob first generates two large primes Pb and qB ,, sets an RSA modulus nB= pb qB,, selects a random number s, picks a 160-bit prime number u,such that GCD(u,(nB))=1, and selects a collision-resistant hash function p.Then, TCgen outputs the commitment public key pk and trapdoor td

      2. TCcom : To commit to a string r with arbitrary length, the sender sends the receiver com r=sp(r)tumodnB

      3. TCver : To decommitr the sender reveals (r,t), so

         µ1=h(m)d1mod n (3)

         andsends (CA,VA,µ 1) to Bob, where h(.)is a secure hash function.Upon receiving , Bob checks the validity of CAand VA, and whether h(m)=µ1e1mod n. If all those veri- ficationsgo through, Bob returns his signature µ B to Alice, since he is convinced that the expected

         µ2=h(m)d2 mod n (4)

         can be revealed by Bob or the TTP. After receiving valid

         µB Alice reveals µ2=h(m)d2mod n to Bob. Finally, Bob ob- tains Alicesignature µ A for message by setting , µA= µ 1µ 2since we have

         A

         h(m)µ e=h(m)(d1+d2)e=h(m)demod n. (5)

         The security problem in Park sscheme is that an honest- but-curious TTP can easily derive Alices private key d.The reason is that with the knowledge of (n,e,e1,d2), the TTP knows that the integer e-(1-ed 2)e 1 is a nonzero multiple of(n). It is well known that knowing such a multiple of (n),Alices RSA modulus n can be easily factored. Con- sequently, the TTP can get Alices private key by the ex- tended Euclidean algorithm.

3. TRAPDOORCOMMITMENT SCHEMES

   A cryptographic primitive, called trapdoor commitment schemes has been used in order to achieve abuse-freeness.

   that the receiver can check if r=sp(r)tumodnB

   1. TCSim: Given an answer (r,t)to a commitment com=r¯,by using the trapdoor µ Breceiver Bob can de- commit r¯ w.r.t. any string r1 .

4. REGISTRATION PROTOCOL

   1. Alice first sets an RSA modulus n=pq, where p and q are two -bit safe primes, i.e., there exist two primes p and q such that p=2p +1and q=2q +1. Then, Alice selects her random public key e, and calculatesher private key

      d=e-1mod(n),

      where (n)=(p-1)(q-1).Finally, Alice registers her pub- lic key with a CA to get her certificate CA, which binds her identity and the corresponding pubic key (n,e)together.

      1

   2. Alice randomly splits d into d1and d2 such that d= d1+ d2 mod(n) and computes e1 = d -1mod(n).Then, Alice sends (CA,w,µ w,d 2 )to the TTP but keeps (d,d1,d2,e) secret.

   3. The TTP first checks that Alices certificate CA is va- lid.After that, the TTP checks that the triple (w,µw,d2) is prepared correctly. If everything is in order, the TTP stores d2 securely, and creates a voucher VAby computing

   VA =SignTTP(CA,w,µw) (6)

   1. SIGNATURE EXCHNAGE PROTOCOL

      1. First, the initiator Alice computes her partial signature

         µ1=h(m)d1and then sends the triple (CA,VA,µ1) to the res- ponder Bob. Here,h(.) is a cryptographically secure hash function.

      2. Upon receiving (CA,VA,µ1) Bob first verifies thatC is Alices certificate issued by a CA, and that VA is Alices voucher created by the TTP. Then, Bob checks if the identi- tiesof Alice, Bob, and the TTP are correctly specified as part of the contract m. If all those validations hold, Bob initiates the following interactive zero-knowledge protocol with Alice to check whether µ1is indeed Alices valid par- tial signature on contact m.

         1

         1. Bob picks two numbers i,j at random,and sends a challenge c to Alice by computing c=µ 2iµwj mod n.

         2. After getting the challenge c, Alice calculates the res- pondence r=ce1 mod n, and then returns her commitment r=TCcom(r,t) to Bob by selecting a random number t, where TCcom is the commitment algorithm of a secure trapdoor commitment scheme which depends on Bobs public key.

         3. When the commitment r is received, Bob sends Alice the pair(i,j) to show that he prepared the challenge c properly.

            1 w

         4. Alice checks whether the challenge c is indeed pre- pared correctly, i.e., c=µ 2iµ j mod n.. If the answer is pos- itive, Alice decommits the commitment r by revealing the respondence (r,t) to Bob.With the knowledge of (r,t), Bob accepts µ1 as valid if and only if

            r=h(m)2i wj mod n and r=TCcom(r,t). (7)

      3. Only if µ1 is Alices valid partial signature and the deadline t specified in contract is sufficient for applying dispute resolution from the TTP, Bob sends his signature

         µB on contract m to Alice, since he is convinced that anoth- er partial signature µB can be released by the TTP, in case Alice refuses to do so.

      4. Upon receiving µB, Alice checks whether it is Bobs valid signature on message m. If this is correct, she sends

         Bob the partial signature µB, by computing µ2=h(m)d2 mod

         n. When Bob gets µ2 , he sets µA= µ1 µ2 mod n , and ac- cepts as µ2 valid .In this case, Bob can recover Alices standard RSA signature µ2 on message m from µA. If Bob does not receive the value of µ 2or only receives an invalid

         µ2 from Alice timely, he applies help from the TTP via the dispute resolution protocol before the deadline t expires.

   2. DISPUTE RESOLUTION PROTOCOL

      1. The TTP first verifies whether CA , VA , and µB are Alices valid certificate, voucher, and Bobs signature on contract m respectively. After that, the TTP checks wheth- er the deadline t embedded in m expires, and whether Alice, Bob,and itself are the correct parties specified in m. If any validation fails, the TTP sends an error message to Bob. Otherwise,continue.

      2. Then, the TTP computes µ2=h(m)d2mod n and checks whether h(m)2=(µ1 µ2)2e. If this equality holds,the TTP sends (m,µ2 )to Bob and forwards (m ,µB ) to Alice.

5. SECURITY DISCUSSION

   1. CASE 1:ALICE IS HONEST, BUT BOB IS CHEATING.

      If Bob cheats in any possible way, he cannot learn other information except µ 1is valid Upon receiving the valid value of µ 1, Bob has to make a choice whether he should send his signature µ B on contract m to Alice. If Bob does, honest nitiator Alice returns back her second partial signa- ture µ2=h(m)d2 as Bob expects. In such a situation, Bob gets Alices signature on contract m by setting µA= µ1 µ2 mod n while Alice also obtains Bobs signature µB simultaneously. If Bob does not send µB or only sends an incorrect µB to Alice, he cannot get the value of µ2 from ice. Furthermore, in this setting, Bob also cannot get the value of µ2 from the TTP so that Alice does not obtain his signature µB. Once those values are submitted, Bob indeed gets µ2 from the TTP but Alice receives (m, µB) from the TTP, too. There- fore, once again, Bob and Alice get the others signature on contract m at the same time

   2. CASE 2: BOB IS HONEST, BUT ALICE IS CHEATING.

      In our signature exchange protocol, Alice may cheat in any or some of the following steps: step (1), step (2), and step (4). First of all, according to the specification of our signature exchange protocol, to get the signaure on con- tract from the honest responder Bob, the initiator Alice has to convince Bob accepting as a valid partial signature in step (2). Step (2) is confirmation protocol for RSA undeni- able signatures,and that their protocol satisfies the property of soundness. The soundness means that the possible cheat- ing Alice (prover), even computationally unbounded, can- not convince

      Bob (verifier) to accept an invalid as valid with nonneg- ligible probability. Therefore, we conclude that to get from Bob, Alice has to send valid µ1 (with valid CAandVA ) instep (1) and perform honestly in step (2). Alice is not so silly by preparing and sending µ1 to Bob. Bob can drive her private key (and then compute signature µB. Therefore, to get signature µB from Bob, Alice has to compute

      µ1=h(m)d1 and send it to Bob. In this situation, Bob receives valid µ1=h(m)d1 from Alice before Alice gets valid µB from Bob. After that, step (4) is the only one possible cheating chance for Alice, i.e., she may refuse to reveal µ2 or just send an incorrect µ2 to Bob. However, this cheating behavior does not harm Bob essentially, since he can get the value of µ2 from the TTP via our dispute resolution pro- tocol. The reason is that Bob has received valid µ1before he sends µB to Alice. After getting the value of from the TTP, Bob can recover Alices signature according to the recovery algorithm specified in . Therefore, in case (b) where Bob is honest but Alice is dishonest, Alice cannot get Bobs signature such that Bob does not obtain her sig- nature. Based on the above analysis, we conclude that the proposed protocol is not advantageous to any dishonest party. In other words, our contract-signing protocol satis- fies the property of fairness.

6. CONCLUSION

This protocol can be adapted to fair payments in e- commerce .In this setting, one customer purchases digital goods from a merchant via the Internet by paying with a digital check or cash. The extended scheme could imple-

ment such an electronic transaction between two parties fairly. That is, it is guaranteed that the customer gets the digital goods from the merchant if and only if the merchant gets the money from the customer.

Finally, using the technique of threshold RSA signature the proposed protocol could be extended for the scenarios where the trust on a single TTP needs to be distributed into multiple TTPs, or a contract is required to be signed only by a given quota of members cooperatively

. References

[[1] Abadi, N. Glew, B. Horne, and B. Pinkas, Certified e-mail with a light on-line trusted third party: Design and implementation, in Proc. 2002 Int.World Wide Web Conf. (WWW02), 2002, pp. 387395, ACM Press.

1. N. Asokan, V. Shoup, and M. Waidner, Optimistic fair exchange of digital signatures, in Proc. EUROCRYPT98, 1998, vol. 1403, LNCS, pp. 591606, Springer-Verlag.

2. N. Asokan, V. Shoup, and M. Waidner, Optimistic fair exchange of digital signatures, IEEE J. Sel. Areas Commun., vol. 18, no. 4, pp. 591606, Apr. 2000.

3. G. Ateniese, Efficient verifiable encryption (and fair exchange) of digital signature, in Proc. ACMConf. Computer and Communications Security