 Open Access
 Total Downloads : 329
 Authors : Rajasree R.S.
 Paper ID : IJERTV1IS8133
 Volume & Issue : Volume 01, Issue 08 (October 2012)
 Published (First Online): 29102012
 ISSN (Online) : 22780181
 Publisher Name : IJERT
 License: This work is licensed under a Creative Commons Attribution 4.0 International License
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 contractsigning 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: contractsigning protocols, certified email systems nonre pudiation protocols and epayment 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.

EXISTING SYSTEM
According to the involvement degree of a trusted third party (TTP), contractsigning protocols can be divided into three types: 1) gradual exchanges without any TTP; 2) pro tocols with an online 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 bitbybit.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 offline 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 realworld 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 online 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. Contractsigning protocols with an online 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.

PROPOSED SYSTEM
This paper shows the importance of abusefreeness 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 abusefree.

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.

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

AbuseFreeness
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.

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.

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 contractsigning protocol into existing software for electronic transactions.

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.

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:

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

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 RSABased Trapdoor Commitment Scheme
The following RSAbased efficient trapdoor commit ment scheme

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 160bit prime number u,such that GCD(u,(nB))=1, and selects a collisionresistant hash function p.Then, TCgen outputs the commitment public key pk and trapdoor td

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

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 butcurious 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(1ed 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.



TRAPDOORCOMMITMENT SCHEMES
A cryptographic primitive, called trapdoor commitment schemes has been used in order to achieve abusefreeness.
that the receiver can check if r=sp(r)tumodnB

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 .


REGISTRATION PROTOCOL

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=e1mod(n),
where (n)=(p1)(q1).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

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.

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)

SIGNATURE EXCHNAGE PROTOCOL

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.

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 zeroknowledge protocol with Alice to check whether Âµ1is indeed Alices valid par tial signature on contact m.
1

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

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.

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

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)


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.

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.


DISPUTE RESOLUTION PROTOCOL

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.

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.



SECURITY DISCUSSION

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

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 contractsigning protocol satis fies the property of fairness.


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 email with a light online trusted third party: Design and implementation, in Proc. 2002 Int.World Wide Web Conf. (WWW02), 2002, pp. 387395, ACM Press.
N. Asokan, V. Shoup, and M. Waidner, Optimistic fair exchange of digital signatures, in Proc. EUROCRYPT98, 1998, vol. 1403, LNCS, pp. 591606, SpringerVerlag.

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.

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