1
A Two-party Contract Signing Protocol
1
Nay Chi Htun, 2Khin Khat Khat Kyaw
1
Ph.D Student of UTYCC, Pyin Oo Lwin, Myanmar,[email protected]
2
Assistant Professor, IT Dept, UTYCC, Pyin Oo Lwin, Myanmar

software, music, information and so on) with an electronic
Abstract-- With the popularity of e-business issue, various
payment
forms of fair exchange protocols have been proposed by many
researchers. Contract signing protocol is one type of fair
exchange protocol. In this paper, a new contract signing
protocol is proposed. It is also important to formally analyze
the designed properties of the proposed protocol for belief of
 Digital contract signing protocols: exchanging digital
signatures on a given electronic document
 Non- repudiation protocols: exchanging an electronic item
customer on the protocol. Therefore the proposed protocol is
with evidences concerned with non-repudiation of origin and
formally analyzed with the standard verification tool, AVISPA.
non-repudiation of recipient.
Index Terms-- contract signing, two-party, offline TTP,
 Certified e-mail: exchanging an electronic message with a
fairness, formal verification, AVISPA
proof of receipt.
These protocols can be classified as fair exchange
I. INTRODUCTION
protocols in general. However, each type has its defined
Due to the significant improvement of global net, fair
exchange protocols are become more and more important
for e-commerce for all nations over the world. The basic
definition of fair exchange over the internet is that
exchanging electronic items between exchanged parties
fairly, properly and systematically. This process saves time
and money because travel expenses are not spent. However,
there are other problems about on-line exchanging systems.
problems and required properties.
Among fair exchange protocols, digital contract signing
protocols are protocols that exchange the digital signature
on an electronic documents. So it is another form of fair
exchange protocols. A digital contract signing protocol must
have at least the following three properties:
 Fairness: all signers must receive the signed documents
after performing the protocol.
One is fairness. Can on-line exchanging systems give actual
 Secrecy: no outsider must learn about the contract.
fairness between exchanged parties? If there is a problem in
 Non-repudiation: any signer must not confuse his signing
exchanging, who resolved this case? How he resolved this
case?
Can
outsider
compromise
the
e-item?
Do
communication channels save for the participants? What
types of attacks can occur on the on-line exchanging system?
To solve these many questions, many secure and fair
exchange protocols are proposed by many researchers.
There are various types of fair exchange protocols. Most
common types of fair exchange protocols are:
 E-payment protocols : purchasing digital product (such as
on the given document.
 Authentication: only registered signer must receive the
signed document.
Digital contract signing protocols are proposed for two
parties such as [1,2] as well as multi parties such as [3,4].
The paper is organized as follow. A new contract signing
protocol is proposed in section 2. The proposed protocol is
formally analyzed with AVISPA in section3. In section 4,
the paper is concluded.
2
II. A TWO-PARTY CONTRACT SIGNING
PROTOCOL
generated from the contract by Bpk and certB
includes
encrypted hash value of cB by Apk .
In this section, an two-party contract signing protocol is
In turn, Alice verifies whether H(cB)=Decrpt (certB) by
briefly described. The notations are described as follows:
Ask. Then Alice encrypts contract plus her nounce with Ask
T
and sends to Bob.
: the digital contract to be signed
cA
: encrypted the digital contract concatenated with
Alice’s nounce by Alice’s public key
Bob decrypts the message with Apkand generates nounce
from the decrypted message. Then Bob concatenates the
certA : encrypted hash value of cA with Bob’s public key
generated nounce with the receive message from Alice. Next
cB
: encrypted the digital contract concatenated with
all information is encrypted with Bsk and forwards it to Alice
Bob’s nounce by Bob’s public key
by Bob.
certB : encrypted hash value of cB with Alice’s public key
SA(X): encrypted X by Alice’s private key and used as
Finally, Alice can decrypt the message of Bob by B pk and
get the same signature.
Alice’s signature
SB(X): encrypted X by Bob’s private key and used as Bob’s
signature
B. Recovery Protocol
In the dispute resolution protocol of the proposed
H: homomorphic one way function
protocol, Bob not need to run the recovery protocol because
There are some assumptions about the proposed contract
signing protocol. Alice, Bob and TTP must agree the public
TTP also sends him the required signature whenever Alice
calls recovery procedure.
key encryption that is intended to use in the process. TTP
On the other hand, after sending her signature, Alice waits
must know the private keys of Alice and Bob to create the
for Bob’s signature. When she does not receive Bob’s
signature when some unnatural behaviors occur. Or TTP can
signature, she performs the following steps to call the
sign the digital contract with its own private key and other
recovery protocol.
out organization must satisfy with his signature. Besides,
 Alice
TTP: cA , certA, cB, certB
TTP must know that Alice is the initiator of the signing
 TTP
Alice: SA
process.
 TTP
Bob : SB
To run dispute resolution protocol, Alice forwards Bob’s
A. MAIN PROTOCOL
commitment as well as her commitment to TTP. TTP then
 Alice
Bob: cA , certA
verifies the two commitments until they are validated. Then
 Bob
Alice: cB, certB
TTP sends SA to Alice and SB to Bob.
 Alice
Bob : SA(t, NA)
 Bob
Alice : SB(t,NA,NB)
In the modified contract signing protocol, Bob does not
need to run the recovery protocol because he sends his
signature to Alice after receiving Alice’s signature. So,
In the main protocol, Alice sends cA and certA to Bob,
where cA includes encrypted contract plus Alice’s nounce
generated from the contract by Apk and certA
includes
encrypted hash value of cA by Bpk .
After validating
the commitment by verifying H(cA
)=Decrypt(certA ) by Bsk , Bob sends cB and certB to Alice,
where cB includes encrypted contract plus Bob’s nounce
compatible to this condition, fairness is strong on Bob.
However, such a condition may be exist between Alice and
Bob during the exchange process. Assume that Alice is
dishonest and she directly runs the recovery protocol with
two commitments after first round without sending her
signature to Bob. Then, TTP also sends SB to Bob as well as
he sends
3
SA to Alice and fairness is maintained in the way in the
intermediate format (IF) on which AVISPA tool verifies the
modified two-party contract signing protocol.
protocols with various back ends. AVISPA supports four
C. Analysis of the Protocol
back ends currently to validate security properties. They are
The proposed contract signing protocol can also gives
On-the-Fly Model-Checker (OFMC), SAT-based ModelChecking
fairness.
(SATMC),
Constraint-Logic-
based
Attack
Proposition 1: Alice is honest and Bob is dishonest.
Searcher (CL-AtSe) and Tree Automata based on Automatic
After exchanging the respective commitments, Alice
Approximations for the Analysis of Security Protocols
sends her signature to Bob. On the other hand, Bob does not
(TA4SP). This becomes the special trade mark of AVISPA
send his signature to Alice. So Alice calls the recovery
tool and the user can select the preferred back end for the
protocol with two commitments and TTP sends the required
protocol verification.
signature to Alice. So Fairness is strong between Alice and
Bob even Bob is a dishonest party in performing according
to the modified protocol.
Proposition 2: Alice is dishonest and Bob is honest.
After exchanging the commitments, Alice does not send
her signature to Bob. Instead she directly runs dispute
resolution protocol with two commitments. For this case,
TTP sends the required signature to Alice and similarly, he
also forwards the signature to Bob. Therefore fairness is still
B. Modeling the proposed protocol in HLPSL
In modeling security protocol in HLPSL specification,
Basic role, Transition and Composed role must be defined.
role alice(A,B,T:agent,
Ka, Kb: public_key,
SND, RCV: channel (dy))
played_by A def=
local State: nat, Certa,Certb,Na,Nb:text, Contract: message
init State :=0
transition
…
end role
strong for both party even Alice is dishonest.
Figure 1. The basic role of Alice
III. FORMAL ANALYSIS OF THE PROPOSED
PROTOCOL
In this section, the proposed protocol is formally analyzed
with the standard verification tool, AVISPA.
In basic role, three basic roles are specified for three
parties: Alice, Bob and TTP. For example, the basic role of
Alice for the proposed protocol is specified in figure 1.
In transition section of the proposed protocol, the goal
features such as witness, request and secret must also be
A. AVISPA
AVISPA is a push-button tool for the automated
specified on the contract and signatures of the signed parties
in order to validate the designed fairness and secrecy
validation of Internet security-sensitive protocols and
properties.
Witness and request are non-repudiation
applications [5]. Some protocols are formally analyzed as
evidences for authentication goal that indirectly corresponds
examples in tutorials published by AVISPA team [6]. It
to fairness between signed participants. Secret feature give
provides a modular and expressive formal language for
privacy so that outsider of exchanged process cannot
specifying protocols and their security properties, and
compromise the exchanged signed contract. For
integrates different back-ends that implement a variety of
the goal facts of Alice are shown in figure 2. The witness on
state-of-the-art automatic analysis techniques.
Na and Contract defined by Alice means that she really
instance,
Before validating the security properties of the protocols
sends the predetermined contract and her nounce to Bob.
with AVISPA tool, the protocol must be modeled with high
The request on Nb specified by Alice means that she really
level protocol specification language (HLPSL) accepted by
receives the nounce from Bob. Secret on
this tool. Then HLPSL2IF translator interprets HLPSL to
Na, Nb and
4
Contract made by Alice means that she keeps her sent and
received items secret.
In this section, the security goals for the proposed
protocol are identified.
At first, to guarantee the fairness of the protocol, Alice
Witness(A,B,na,Na)/\witness(A,B,contract,Contract)
Secret(Na,na,{A,B,T})/\secret(Contract,contract,{A,B,T})
request(A,B,nb,Nb) /\secret(Nb,nb,{A,B,T})
Figure 2. The goal facts of Alice
In composed role part , basic roles of Alice and Bob are
glued together in order to execute in parallel. For composed
role, TTP is not needed to take into the considerations.
Therefore, only two basic roles are composed in one session.
In the session role, the channels under which each basic
role work are declared .The session role of the both protocol
is defined in HLPSL as follows:
role session(A,B,T:agent,
Ka,Kb: public_key)
def=
local SA,Sb,ST,RARB,RT:channel(dy)
composition
alice(A,B,T,Ka, Kb,SA,RA)/\
bob(A,B,T,Ka,Kb,SB,RB)/\
end role
and Bob must have non-repudiation evidences: Nonrepudiation of origin (NNO) and Non-repudiation of
role environment()
def=
const contract,na,nb:protocol_id,
ka,kb,ki:public_key,
a,b,t,i:agent,
timeout,abort:text
intruder_knowledge={a,b,t, ki,inv(ki)}
composition
session(a,b,t,ka,kb) /\session(i,b,t,ki,kb) /\session(a,i,t,ka,ki)
end role
goal
…
environment ()
Figure 4. The environment role of old contract signing
protocol
recipient (NNR) with respect to the contract and their
respective nounces.
 NNO and NNR on the contract itself between Alice
and Bob
Defined goal: authentication_on contract
Figure 3. The session role of two contract signing
protocols
Eventually, role environment, the top-level role of HLPSL
is defined. In this role, protocol ids corresponding to the
exchange items are identified. It also contains global
constants .In fact, role environment is the composition of
one or more role sessions. The intruder knowledge for the
protocols is also defined in this role. In the proposed
contract signing protocol, intruder knows the ID of signed
parties, his own ID , his own public key and private key.
Public keys of Alice and Bob are not known to the Intruder.
According to the nature of contract signing protocols,
private key encryption is used as the signature and
knowledge of public keys is given to the two signed
participants.
 NNO and NNR on Alice’s Nounce(Na) between Alice
and Bob
Defined goal: authentication_on na
 NNO and NNR on Bob’s Nounce(Nb) between Alice
and Bob
Defined goal: authentication_ on nb
Secondly, to guarantee the secrecy of the protocol, the
contract itself and exchanged nounces must be secure.
 Secrecy of contract between Alice and Bob
Defined goal: secrecy_of contract
 Secrecy of Alice’s Nounce(Na) between Alice and Bob
Defined goal: secrecy_of na
 Secrecy of Bob’s Nounce (Nb) between Alice and Bob
Defined goal: secrecy_of nb
The environment role under determined
intruder model for the proposed contract signing protocol is
defined as in figure 4.
D. Analyzing Security Goals of the Proposed Protocol
In this section, the proposed contract signing protocol is
C. Specifying Security Goals for the Proposed Protocol
formally analyzed with the Avispa tool to see if it is as
5
efficient contract signing protocol that can fit in the real
Committee on Security and Privacy, IEEE Computer
world. Here OFMC back end is used to verify the security
Society Press.
properties. When the signing protocol is analyzed with
[2] Juan A. Garay, Markus Jakobsson, and Philip D.
AVISPA tool, it can be seen that the proposed protocol is
MacKenzie. Abuse-free optimistic contract signing. In
safe for its promised properties. The verification result is
Advances in Cryptology—Crypto 1999, volume 1666 of
shown in figure 5.
Lecture Notes in Computer Science, pages 449–466.
Springer-Verlag, 1999.
[3] Birgit Baum-Waidner and Michael Waidner. Roundoptimal and abuse free optimistic multi-party contract
signing. In Ugo Montanari, Jos´e D. P. Rolim, and Emo
Welzl, editors, Automata, Languages and Programming
— ICALP 2000, volume 1853 of Lecture Notes in
Computer
Science,
pages
524–535,
Geneva,
Switzerland,July 2000. Springer-Verlag.
[4] Juan A. Garay, Markus Jakobsson, and Philip D.
MacKenzie. Abuse-free optimistic contract signing. In
Advances in Cryptology—Crypto 1999, volume 1666 of
Lecture Notes in Computer Science, pages 449–466.
Figure 5. The Analyzed result of the proposed contract
signing protocol
Fair exchange protocols such as contract signing
are
essential
for
improving
[5] The AVISPA team, “AVISPA v1.1 User Manual”, June
2006.
IV. CONCLUSION
protocols
Springer-Verlag, 1999.
e-business
applications. In this paper, an efficient contract signing
protocol is introduced to utilize in the e-commerce issue.
The proposed protocol is able to give the required properties
of a good-quality contract signing protocol such as fairness,
secrecy and non- repudiation. In order to prove this fact, the
proposed contract signing protocol is formally analyzed with
the standard verification tool, AVISPA. As can be clearly
shown in the figure 6, the protocol is safe for the promised
properties. Therefore the proposed contact signing protocol
is a useful help to the e-commerce world.
V. REFERENCES
[1] N. Asokan, Victor Shoup, and Michael Waidner.
Asynchronous protocols for optimistic fair exchange. In
IEEE Symposium on Research in Security and Privacy,
pages 86–99, Oakland, CA, May 1998. Technical
[6] The AVISPA team, “HLPSL Tutorial”, June 2006.