An Abuse Free Fair Contract Signing Protocol Based on the RSA Signature

ABSTRACT

               A fair contract signing protocol allows two potentially mistrusted parities to exchange their commitments (i.e., digital signatures) to an agreed contract over the Internet in a fair way, so that either each of them obtains the other’s signature, or neither party does. Based on the RSA signature scheme, a new digital contract signing protocol is proposed in this paper. Like the existing RSA-based solutions for the same problem, our protocol is not only fair, but also optimistic, since the third trusted party is involved only in the situations where one party is cheating or the communication channel is interrupted. Furthermore, the proposed protocol satisfies a new property, i.e., it is abuse-free. That is, if the protocol is executed unsuccessfully, none of the two parties can show the validity of intermediate results to others. Technical details are provided to analyze the security and performance of the proposed protocol. In summary, we present the first abuse-free fair contract signing protocol based on the RSA signature, and show that it is both secure and efficient.

EXISTING SYSTEM

              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 document that shows both of them have committed to the contract. If one party does not abide by the contract, the other party could provide the signed contract to a judge in court. As the electronic commerce is  becoming more and more important and popular in the world, it is desirable to need 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 simultaneity 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. This requirement is essentially captured by the concept of fairness.

PROPOSED SYSTEM

            

               In this Project we mainly focus on the problem of digital contract signing. Since a

party’s 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 parities. There is a rich history of contract signing (i.e., fair exchange of digital signatures) because this is a fundamental problem in electronic transactions. According to the involvement degree of a trusted third party (TTP), contract signin protocols can be divided into three types: (1) gradual exchanges without any TTP; (2) protocols with an on-line TTP; and (3) protocols with an off-line TTP. Early efforts mainly focused on the first type protocols to meet computational fairness: Both parties exchange their commitments/secrets “bit-by-bit”. If one party stops prematurely, both parties have about the same fraction of the peer’s secret, which means that they can complete the contract off-line by investing about the same amount of computing work. 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 several reasons. First of all, it is assumed that the two parties have equivalent 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 protocols are inefficient because the costs of computation and communication are extensive. In fair exchange protocols an on-line TTP is always involved in every exchange. In this scenario, a 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. Generally speaking, contract signing protocols with an on-line TTP could be designed more easily since the TTP facilitates each step of exchanging, but may be still expensive and inefficient because the TTP needs to be paid and must be part of every execution. In practice, the TTP is prone to become a bottleneck in the whole system, especially in the situation where many users rely on a single TTP.

ARCHITECTUTE

 

                           

THE PROPOSED PROTOCOL

                  We describe our new contract signing protocol based on the RSA signature. The basic idea is that Alice first splits her private key d into d1 and d2 so that d = d1 + d2 mod f(n). Then, only d2 is delivered to the TTP, while Alice keeps (d, d1, d2) as secrets. To exchange her signature s_A = h(m)^d mod n with Bob, Alice first sends partial signature s₁ = h(m)^d1 mod n to Bob, and proves that _1 is prepared correctly in an interactive zero-knowledge way by exploiting Gennaro et al.’s protocol . After that, Bob sends his signature s_B on message m to Alice, since he is convinced that even if Alice refuses to reveal the second partial signature s₂ = h(m)^d2 mod n, the TTP can do the same thing. As usual, we assume that the communication channel between Alice and Bob is unreliable, i.e., messages inserted into such a channel may be lost due to the failure of computer network or attacks from adversaries. However, the TTP is linked with Alice and Bob by reliable communication channels, i.e., messages inserted into such a channel will be delivered to the recipient after a finite delay.

Registration Protocol

                   To use our protocol for exchanging digital signatures, only the initiator Alice needs to register with the TTP. That is, Alice is required to get a voucher VA from the TTP besides obtaining a certificate CA from a certification authority (CA). To this end, the following procedures are executed.

                 (1) Alice first sets an RSA modulus n = pq, where p and q are two k-bit safe primes, i.e., there exist two primes p0 and q0 such that p = 2p0 +1 and q = 2q0 +1. Then, Alice selects her random public key e ÎR Z^*_f(n), and calculates her private key d = e−1 mod f(n), where f(n) = (p − 1)(q − 1). Finally, Alice registers her public key with a CA to get her certificate CA, which binds her identity and the corresponding pubic key (n, e) together.

                 (2) Alice randomly splits d into d1 and d2 such that d = d1 +d2 mod f(n) by choosing d1 ÎR Z^*_f(n), and computes e1 = d−1 1 mod f(n). At the same time, she generates a sample message-signature pair (w, s_w), where wÎ Z^* n \ {1,−1}, ord(w)≥ p0q0, and sw = wd1 mod n. Then, Alice sends (CA,w, s_w, d2) to the TTP but keeps (d, d1, d2, e1) secret.

                 (3) The TTP first checks Alice’s certificate CA is valid. After that, the TTP checks that the triple (w, s_w, d2) is prepared correctly. If everything is in order, the TTP stores d2 securely, and creates a voucher VA by computing VA = SignTTP (CA,w,s_w). That is, VA is the TTP’s signature on message (CA,w,s_w), which guarantees that the TTP can issue a valid partial signature on behalf of Alice by using the secret d2.

                 We give some notes on the above registration protocol. To get her certificate from a CA, Alice has to prove that modulus n is the product of two safe primes. This technical issue is addressed in. Of course, step (1) can be omitted if Alice has obtained such a certificate before she registers with the TTP. To validate the correctness of the triple (w, s_w, d2), the TTP needs to do the followings. Firstly, the TTP validates that w is an element of order at least of p0q0 by checking that w Î Z^* n \ {1,−1}, and that both gcd(w−1, n) and gcd(w+1, n) are not prime factors of n . Then, Alice is required to show that she knows the discrete logarithm of sw to the base w via a zero-knowledge protocol interactively or non-interactively. Finally, the TTP checks whether wº ,s_w ,d2)e mod n. If  all those validations pass, the TTP accepts (w, s_w, d2) as a valid triple and creates the voucher VA for Alice.

                 Though the above registration protocol is a little complicated, we remark that this stage needs to be executed only once for a sufficiently long period, for example, one year. In this period, Alice can fairly sign any number of contracts with all potential parties. Furthermore, it seems reasonable in the real world to require users to first register with the TTP before they are served. The reason is that the TTP is usually unlikely to provide free service for settling disputes between users. Moreover, for enhancing efficiency, the sample message w can be fixed as a constant, e.g., w = 2, as pointed out by Gennaro et al.. Compared with schemes based on verifiably encrypted signatures, one disadvantage of our registration protocol is that the TTP needs to keep a distinct secret d2 for each registered user. However, this shortcoming can be eliminated by some simple techniques. For example, the TTP can encrypt each concatenation of d2 and the corresponding user’s unique identifier by exploiting a secure symmetric-key encryption algorithm, and then stores the results into its database. To extract a user’s d2 later, the TTP only needs to decrypt the corresponding record using the unique symmetric key.

Signature Exchange Protocol

                 

                  We assume that a contract m has been agreed between Alice and Bob before they begin to sign it. In addition, it is supposed that the contract explicitly contains the following information: a predetermined but reasonable deadline t, the identities of Alice, Bob, and the TTP. Our signature exchange protocol is briefly illuminated in Figure 1, and further described in detail as follows.

       (1) Firstly, the initiator Alice computes her partial signature s₁ = h(m)^d1 mod n, and then sends the triple (CA, VA, s₁)  to the responder Bob. Here, h(·) is a cryptographically secure hash function.

        (2) Upon receiving (CA, VA, s₁), Bob first verifies that CA is Alice’s certificate issued by a CA, and that VA is Alice’s voucher created by the TTP. Then, Bob checks if the identities of Alice, Bob, and the TTP are correctly specified in the contract m. If all those validations hold, Bob initiates the following interactive protocol with Alice to check whether s1 is Alice’s valid partial signature on contact m.

        (2a) Bob picks two numbers i, j ÎR [1, n] at random, and sends a challenge c to Alice by computing c = s₁²ⁱ sw ^j  mod n.

        (2b) After getting the challenge c, Alice calculates the respondence  r = c^e1 mod n, and then returns her commitment ¯r = commit(r) to Bob, where commit(·) is a secure commitment scheme.      

       (2c) When the commitment ¯r is received, Bob sends the pair (i, j) to Alice.

       (2d) Alice checks whether the challenge c is prepared properly, i.e., c ºs₁²ⁱ s_w^j

mod n. If the answer is positive, Alice reveals the respondence r to Bob. With the knowledge of r, Bob accepts _1 as valid if and only if r s h(m)^2iwj mod n and ¯rº commit(r).

       (3) Only if s₁ is Alice’s valid partial signature and the deadline t specified in contract m is sufficient for applying dispute resolution from the TTP, Bob sends his signature sB on contract m to Alice, since he is convinced that another partial signature s₂ can be released by the TTP, in case Alice refuses to do so.

      (4) Upon receiving s_B, Alice checks whether it is Bob’s valid signature on message m. If this is correct, she sends Bob the partial signature s₂ by computing s₂ = h(m)^d2 mod n. When Bob gets s2, he sets ¯s_A = s₁s₂ mod n, and accepts s₂ as valid if and only if h(m)2 = ¯s₂A mod n. In this case, Bob can recover Alice’s standard RSA signature s_A on message m from ¯s_A (more details are provided later). If Bob does not receive the value of s₂ or only receives an invalid s₂ from Alice timely, he applies help from the TTP via the dispute resolution protocol before the deadline t expires.

                    The following is further explanation of our signature exchange protocol. Firstly, the interactive protocol exploited in step (2) is exactly the confirmation protocol for RSA undeniable signatures by Gennaro et al. With respect to the private key (d1, e1) and the public key (n,w, s_w). Note that similar approaches are used to construct e-payment protocol and certified e-mail system.  it is proved that a successful execution of this zero-knowledge protocol guarantees that s₁ = βh(m)^d1 mod n, where s₂ {1,−1, a1,a2} and a_i’s (i = 1, 2) denote the two non-trivial elements of order 2. In this case, Bob accepts _1 as valid and sends his signature s_B on contract m to Alice in step (3), since he is convinced that another partial signature s₂ can be revealed by either Alice or the TTP. After that, if Alice does not reveal the value of s₂ or only sends invalid _2 to Bob before the deadline t, Bob resorts to the TTP to get the correct value of s₂. If Alice honestly reveals s₂= h(m)^d2  mod n to Bob in step (4), we have h(m)º ¯s_A^2e mod n, i.e.,¯ s_A= s₁s₂mod n is valid. In such condition, Bob can recover the correct value of s_A from ¯s_A by using the following recovery algorithm:

(a) set s_A = ¯s_A, if h(m) = ¯s ^e_A mod n;

(b) set s_A = −¯s_A mod n, if h(m) = −¯s ^e_A mod n;

(c) get s_A by factoring n, else, i.e., h(m) 6= ±¯_s ^e_Amod n.

          We describe how Bob can factor n and then get the value of ¯s_A in case (c), i.e., h(m)2 = ¯s_A^2e mod n but h(m) 6= ±¯s_A^2e mod n. Note that the equality h(m)2 = ¯s_A^2e mod n implies that ¯s_A^2e = _h(m)d mod n, where s₂ {1,−1, _1, _2}.When β = ±1, corresponding to cases (a) and (b), Bob can easily find the value of _A. So we conclude that case (c) means ¯s_A = a_ih(m)d mod n, i = 1 or 2. Recall that ord(a_i) = 2 and e is an odd number (due to e Î Z^* _f(n) and f(n) = 4p0q0), so we have ¯s_A^e = (a_ih(m)^d)e mod n = a_i h(m) mod n. Therefore, Bob can get the value of ai by

computing a_i = ¯s_A^e h(m)−1 mod n. It is well known that with the knowledge of such a non-trivial element of order 2, Alice’s RSA modulus n can be easily factored, i.e., (a_i − 1) and (a_i + 1) are the two prime factors of n. Consequently, Bob can get Alice’s private key d by using extended Euclidean algorithm, and then obtain the value s_A by computing s_A = h(m)^d mod n. Based on the above discussion, we conclude that case (c) does not happen in the real world unless Alice wants to reveal her private key. That is, if Alice reveals s₁= a_i h(m)^d1 mod n and s₂= h(m)^d2 mod n, Bob will not only always recover her signature s_A on contract m, but also could derive her private key d (and then forge signatures). So we ignore case (c) in the discussions hereafter under an implicit assumption that any user does not want to compromise his/her own private key.

Dispute Resolution Protocol

  

                If Bob has sent his signature _B to Alice but does not receive the value of s₂ or only receives an invalid s₂ from Alice before the deadline t, then he sends the TTP (CA, VA,m, s₁, s_B) to apply dispute resolution. Upon receiving Bob’s application, the TTP performs as follows:

               (1) The TTP first verifies whether CA, VA, and _B are Alice’s valid certificate, voucher, and Bob’s signature on contract m, respectively. After that, the TTP checks whether 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 s₂ = h(m)^d2 mod n, and checks whether h(m)² º (s₁s₂)^2e mod n. If this equality holds, the TTP sends (m, s₂) to Bob and forwards (m, s_B) to Alice. Otherwise, i.e., h(m)² ¹ (s₁s₂)^2emod n, the TTP sends an error message to Bob.

               In the following, we explain why our dispute resolution protocol works. Since the TTP sets s₂= h(m)^d2mod n, we conclude that h(m) ² º (s₁s₂) ^2e mod n if and only if s₁ºβh(m)^d1 mod n, where βÎ{1,−1, s₁, s₂}. That is, the TTP can determine whether Bob has sent a valid s₁to apply dispute resolution by checking h(m)² º(s₁s₂) ^2e mod n. If this equality holds, the TTP reveals the correct value of s₂to Bob and forwards Bob’s signature s_B on contract m to Alice. After getting the correct s₂, Bob can recover Alice’s signature s_A on contract m by employing the recovery algorithm given in previous section. In the case of h(m)² ¹ (s₁s₂) ^2e mod n, the TTP knows that Bob is a cheater, and so only sends an error message to him. Note that if the s₁sent to the TTP is prepared as s₁= a_ih(m)^d1 mod n, the TTP can also get Alice’s private key d as Bob does.

Hardware Requirements:

•         System                 : Pentium IV 2.4 GHz.

•         Hard Disk               : 40 GB.

•         Floppy Drive       : 1.44 Mb.

•         Monitor                 : 15 VGA Colour.

•         Mouse                  : Logitech.

•         Ram                        : 512 Mb.

Software Requirements:-

             Language:  Java / Dot Net

            OS: Windows XP