Modelling and Verification of Multi-Party
Contract Signing Protocol
Yadana Htun#1, Win Zaw*2
#
Faculty of Information and Communication Technology, University of Technology(Yatanarpon Cyber City)
Pyin Oo Lwin, Myanmar.
[email protected]
*
Technological University (Thanlyin)
Yangon, Myanmar.
[email protected]
Abstract— E-contracting ,i.e., establishing and enacting
electronic contracts, has become important because of
technological advances (e.g., the availability of web services) and
more open markets. However, the establishment of an e-contract
is complicated and error prone. There are multiple negotiation
styles ranging from two-party to multi-party contract signing
protocol. A number of two-party contract signing protocols have
been proposed with various features. Nevertheless, in some
applications, a contract may need to be signed by multiple
parties. Multi-Party Contract Signing Protocol have been
proposed with fairness , abuse-freeness and timeliness properties.
This research is carried out to improve the advance features like
verifiability property in the Multi-Party Contract Signing
Protocol . In this paper, the current main analysis techniques
using Colored Petri Nets (CP-nets) for modelling and verification
of multi-party contract signing protocol are introduced.
Index Terms— E-contracting, Multi-Party Contract Signing
Protocol, fairness, abuse-freeness and timeliness.
I. INTRODUCTION
Contracts are documents that states the mutual obligations
and authorizations that reflect the agreements between two
trading partners[1]. An e-contract is a contract modeled,
specified and enacted by a software system. Contract signing
is a fundamental service for business transactions, and has
been well practiced in the traditional paper-based business
model[2]. Nowadays, it is necessary to find appropriate
mechanisms for contract signing in the digital world. Fair
exchange is a problem of exchanging data in a way that
guarantees either all participants obtain what they want, or
none does. From a designing point of view, contract signing is
a particular form of fair exchange, in which the parties
exchange commitments to a contract. If several signers are
involved, then it is a multi-party contract signing (MPCS)
protocol.
There is some two-party contract signing protocols in the
literature. Nevertheless, less research has been done on multiparty contract signing [2]. The paper proposes multi-party
contract signing protocol with verifiability feature. The
possible dishonest behaviours of the Trusted Third Party(TTP)
are identified that the TTP simply does not reply to
participants’ requests, or replies with invalid messages and the
TTP resolves the protocol but does not publish the contract.
The paper will try to analyse these dishonest behaviours of the
Trusted Third Party(TTP) for achieving the verifiability
feature and to produce a contract signing protocol that can be
signed by multiple parties.
The rest of this paper is organized as follows. In Section2,
review the previous work related to contract signing, outline
the properties to be satisfied when designing an optimistic
contract signing protocol, and give explicit definitions for
some terms used along the descriptions of these protocols. In
Section3, describe an optimal multi-party contract signing
protocol. After that, the proposed security property design is
described in Section4, and concludes the paper in Section5.
II. RELATED WORK
As contract signing is a particular case of fair exchange,
any fair exchange protocol found in the literature in which
digital signatures are exchanged can be considered as the
related work[2]. In all practical schemes, contract signing
involves an additional player, called trusted third party (TTP).
This party is (at least to some extent) trusted to be have
correctly, thus playing the role of a notary in paper-based
contract signing and somehow sharing the legal duties the
former one shave. In fact, designing and implementing a
contract signing protocol using a non-line TTP should not be a
complicated task. In this case, if Alice and Bob wish to enter
into a contract, they each sign a copy of the contract and send
it to the TTP through a secure channel. The TTP will forward
the signed contracts only when it has received valid signatures
from both Alice and Bob.
Nevertheless, in our continuous search for speeding up our
daily life activities, it is desirable not using a TTP in a
contract signing protocol [2]. Additionally, if the TTP is not
involved, the notary fee could be avoided. Some protocols
appear in the literature trying to eliminate the TTP's
involvement using gradual exchange of signatures. But these
solutions are not deterministic, thus may not be accepted by
signatories. Our objective is to focus on contract signing
protocols that necessarily use a TTP only in those cases in
which an exception occurs (i.e., a network communication
failure or a dishonest party's misbehaviour). Otherwise (allhonest-case), the TTP will not be contacted, and parties will
bring the protocol to its end by themselves. In the literature,
these protocols are called optimistic contract signing protocols.
Some properties extracted from the different previous work
on optimistic contract signing are summarized as follows [2].
Effectiveness - if each party behaves correctly, the TTP will
not be involved in the protocol.
Fairness
- no party will be in an advantageous situation at
the end of the protocol.
Timeliness - any party can decide when to finish a protocol
run without losing fairness.
Non-repudiation - no party can deny its action.
Transparency of TTP - if the TTP is contacted to resolve the
protocol, the resulting contract will be similar to the one
obtained in case the TTP is not involved.
Abuse-Freeness - it is not possible for an attacker (either a
legitimate participant or an outsider) to show a third party that
the contract final state is under its control.
Verifiability of TTP - if the TTP misbehaves, all harmed
parties will be able to prove it. An easy way to comply with
the conference paper formatting requirements is to use this
document as a template and simply type your text into it.
This section reviews related work on other formal methods
for analysing Contract Signing Protocols. In [3], Chadha,
Kanovich, and Scedrov proposed an inductive proof method
to analyse a variant of contract signing protocol proposed by
Garay, Jakobsson and MacKenzie. Their method aims to
prove fairness and abuse-free properties of the protocol, rather
than to find attacks. In addition, their method is manual. In [4],
Shamatikov and Mitchell applied a model checking system
called Murϕ to analyse two contract signing protocols.
A protocol is modelled as automata by using a
programming language. This method is automatic and some
new attacks on the protocols are discovered. In [5], Gurgens
and Rudolph analysed a number of fair exchange nonrepudiation protocols using asynchronous product automata
(APA) and the simple homomorphism verification tool
(SHVT). Similar to Murϕ, a protocol is modelled as automata
but by using a text-based description on states and state
transitions. Their method is automatic and it found new
attacks. Both Murϕ and SHVT offer an analysis of multiple
sessions, but they can detect only a single attack trace.
In summary, the multi-party contract signing is proposed
with various features and analysed with various simulation
tools over those formal methods discussed previously in that it
provides a simpler and more intuitive way to model a
protocol .
III. AN OPTIMAL MULTI-PARTY CONTRACT SIGNING
PROTOCOL
There are n signing parties P1,…, Pn . Protocol proceeds at
least (n+1) rounds [2]. The following simple solution uses
verifiable encryption of signatures based on ring architecture
for achieving transparency of the TTP. Assume that the
channel between any participant and the TTP is functional and
not disrupted. The following notation is used in the protocol
description.
- C =[M,P,id,t]: a contract text M to be signed by each party
Pi ε P (i = 1,…,n), a unique identifier id for the protocol run,
and a deadline t agreed by all parties to contact the TTP.
- eP (X): encryption of message X with P's public key.
- SP (X): P's digital signature on X.
- Certi : a certificate with which anyone can verify that
the cipher text is the correct signature of the plaintext, and can
be decrypted by the TTP (see CEMBS-Certificate of an
Encrypted Message Being a Signature in[9]).
An optimal synchronous protocol for multi-party contract
signing is outlined as follows [2]:
1.
P1 → P2
: m1[= C, eTTP (SP1 (C)), Cert1]
2.
P2 → P3
: m1,m2[= C, eTTP (SP2 (C)), Cert2]
n-1. Pn-1→Pn : m1,..,mn-1[= C, eTTP (SPn-1 (C)), Certn-1]
n.
Pn → Pn-1 : mn[= C, eTTP (SPn(C)), Certn], SPn(C)
n +1. Pn-1→Pn-2 : mn-1, mn, SPn-1 (C), SPn(C)
2(n-1).P2 →P1 : m2,m3,…, mn, SP2 (C), SP3 (C),…, SPn(C)
2n – 1.P1 → P2 : SP1 (C)
2n.
P2 → P3 : SP1 (C), SP2 (C)
3(n - 1).Pn-1 → Pn : SP1 (C), SP2 (C),…, SPn-1 (C)
The protocol has two clearly differentiated phases:
exchange of commitments and exchange of digital signatures
[2]. The parties first exchange their commitments in an “inand-out" manner. Note that P1 can choose deadline (t) in the
first message (and others can halt if they do not agree). Only
after the first phase is finished at step n, the final signatures
are exchanged. Following this simple approach, only 3(n - 1)
steps are needed.
If there is no exception (e.g., network failure or
misbehaving party), the protocol will not need the TTP's help
[2]. Otherwise, the following resolve sub-protocol helps to
drive the contract signing process to it send. Pi can contact the
TTP before the deadline t.
1. Pi → TTP : resolvePi = C , m1,…,mn, SPi (C, m1,…,mn)
2. TTP
: IF resolvePi is received before t THEN
decrypts m1…mn
publishes SP1 (C),…, SPn(C)
If the main protocol is not completed successfully, some
parties may not hold all the commitments (m1,…, mn). Then,
the parties just wait until the deadline t and check with the
TTP whether the contract has been resolved by other parties.
If not, the contract is cancelled. Otherwise, the parties get the
valid contract (SP1 (C),…, SPn(C)) from the TTP.
If a party has all the commitments when the main protocol
is terminated abnormally, it could initiate the above subprotocol [2]. Then the TTP will help to resolve the contract if
the request is received before the deadline t and the contract
will be available to all the participants (even after the deadline
t). After the deadline, the TTP will not accept such requests
anymore. In other words, the status of the contract will be
determined the latest by the deadline t. This optimal version
permits overlapping the dispatch of promises with real
signatures without losing fairness.
(STTPi + messagei ) Annocementi
Message
IV. PROPOSED SECURITY PROPERTY DESIGN
The Optimal Multi-Party Contract Signing Protocol
presented in the previous section improved the lower bound of
steps and achieved the property of fairness. However, as the
paper pointed out in the security analysis that it does not
satisfy the property of verifiability. Here, this paper improves
the Multi-Party Contract Signing protocol to address this
property.
A. Achieving Verifiability Feature
The paper identify the possible dishonest behaviours of the
TTP that are the TTP simply does not reply to participants'
requests , or replies with invalid messages and the TTP
resolves the protocol but does not publish the contract.
In the first case, some parties could be beneficiated if the
parties got the contract from the main protocol while others
did not. A possible solution is using multiple TTPs and secure
media storage. TTPs have only the write privilege over the
media storage but do not control it while participants in the
contract signing protocol have only the read privilege over the
media storage. A participant can multi-cast his request to the
TTPs before the deadline t. As long as one of the TTPs does
not misbehave, the correct response will be available from the
secure media storage.
In the second case, the TTP could collude with some parties
and resolve the contract for them but does not publish the
contract for other parties. That means some parties not holding
all the commitments will not get the valid contract. To detect
the TTP's cheating, the TTP is required to sign the contract
when it is resolved, but this overrides the TTP's transparency.
It is difficult to reach a trade-off between transparency and
verifiability.
The proposed security property will use the first case to
achieve the verifiability property. The design of proposed
security system is shown as follows in Fig.1. With the concept
of design, this paper modifies the previous optimal multi-party
contract signing protocol to eliminate the illustrative
information. The main protocol remains the same, but Certi is
not included in mi. Instead, the evidence of annocement
Annocementi is generated:
Annocementi = STTPi (h(C)), messagei
where h(C) is the hash value of contract C to be used to
establish a unique link between Annocementi and C.
Signature of
TTP
Secure Media
Stroage
m1
P1
m2
P2
-----mn
Pn
mi [= C, eTTP(SPi(C)), Annocementi ]
Fig.1. The Proposed Security Property Design
1. P1 → P2 : m1 [= C, eTTP(SP1(C)), Annocement1 ]
2. P2 → P3 : m1, m2 [= C, eTTP(SP2(C)), Annocement2 ]
n-1. Pn-1→Pn : m1,.., mn-1 [= C, eTTP(SPn-1(C)), Annocementn-1 ]
n. Pn → Pn-1: mn [= C, eTTP(SPn(C)), Annocementn ], SPn(C)
n+1. Pn-1 → Pn- : mn-1,mn, SPn-1(C), SPn(C)
2(n-1).P2 → P1: m2, m3,…, mn, SP2(C), SP3(C),…,SPn(C)
2n-1. P1 → P2 : SP1(C)
2n. P2 → P3 : SP1(C), SP2(C)
3(n-1).Pn-1 → Pn : SP1(C), SP2(C),…, SPn-1(C)
Each party needs to check whether all the annocement it
has received are valid before releasing its real signature of the
contract. If they are all correct, the TTP will publish SP1 (C),..,
SPn(C). Therefore, TTPs have only the write privilege over the
media storage but do not control it while participants in the
contract signing protocol have only the read privilege over the
media storage. A participant can multi-cast his request to the
TTPs before the deadline t. As long as one of the TTPs does
not misbehave, the correct response will be available from the
secure media storage.
B. Colored Peri Nets(CPN Tools)
CPN is a formal method based on graph theory to analyse
distributed systems and communication protocols [6]. In fact,
CPN is a model checking technique where a system is first
modelled by a kind of graphs, called a net and then a state
space of all possible executions of the system is generated and
analysed to search for errors in the system. However, only a
single error trace can be detected by the built-in mechanism in
CPN.
CPN extends Petri nets with programming abilities. The
programming language provided in CPN is a functional
programming language called CPN-ML, and it is based on
standard ML. A graph model in CPN contains four main
components: places, transitions, arcs and tokens. Places,
represented by circles, and transitions, represented by
rectangles, are used to describe states and actions of the
system, respectively. Arcs represented by arrows are used to
link between place and transition. Tokens mean data and they
are just a rich set of data types in standard ML. Arc
expressions which are CPN-ML programs attached to arcs
describe how a transition produces output tokens from input
tokens. A transition can occur, called enabled, only when
there are sufficient tokens that match the arc expressions on its
input places. When an enabled transition is executed, called
occurred, tokens from input places are removed and new
tokens are added into output places according to
corresponding arc expressions. Thus, the main programming
functionality in CPN is to perform token processing at
transitions. Furthermore, CPN provides a software tool called
CPN Tools which facilitates the creation, the modification and
the analysis of nets.
The original Petri nets, called place/transition nets, are
considered as low-level nets. It is widely known that low-level
nets are not practical to deal with real-world applications due
to their unmanageable size of the net specification. Thus,
many
high-level
nets,
for
example
CPN
and
predicate/transition nets, have been developed to solve this
problem. In fact, CPN is very much similar to
predicate/transition nets and they are considered as two
different dialects.
There are other kinds of high-level nets, for example
algebraic Petri nets, CPN with algebraic specifications, etc.
Most of them are similar to CPN, but the difference is on the
inscription language which is the language for arc expressions
and tokens. While the inscription language in CPN is based on
functional programming, the inscription language in algebraic
Petri nets and CPN with algebraic specifications is based on
algebraic specifications. Further discussion on the difference
between CPN and other high-level nets can be found.
C. Verification Of Multi-Party Contract Signing Protocol
The simulation design by using Colored Petri Nets is
divided into three sections. They are sender, network and
receiver The basic idea is that the Sender sends messages
which the Network broadcasts to the Receiver.
Analogously, the Receiver send acknowledgments which
the Network transmits to the Sender.
V. CONCLUSIONS
Contract signing is a fundamental service for business
transactions. Previous work mainly focused on two-party
contract signing. In some applications, however, a contract
may need to be signed by multiple parties. In this paper, the
multi-party contract signing protocol with the additional
feature like verifiability property is improved by modifying
the previous optimal multi-party contract signing protocol. As
a future work, the other properties of multi-party contract
signing protocol can analyze and simulate with various tools.
There are many models and tools to verify security protocols,
including, Finite State Machines (FMS), Colored Petri Nets
(CP-Nets), Cryptographic Protocol Analysis Language
Evaluation System (CPAL-ES), BAN Logics, Morphi,etc and
includes the formal security analysis of optimal multi-party
contract signing protocol.
REFERENCES
[1]
[2]
[3]
[4]
[5]
Bacarin, E., van der Aalst, W., Madeira, E., & Medeiros, C. (2007).
Towards modelling and simulating a multi-party negotiation protocol
with coloured Petri nets. Proceedings of the 8th Workshop and Tutorial
on Practical Use of Coloured Petri Nets and the CPN Tools (pp. 29-48).
Aarhus, Denmark: University of Aarhus.
Jianying Zhou ,Jose A.Onieva ,and Javier Lopez. A Synchronous
Multi-Party Contract Signing Protocol Improving Lower Bound of
Steps. Security and Privacy in Dynamic Environments, Proceedings of
the IFIP TC-11, 21st International Information Security
Conference(SEC 2006), 22-24 May 2006, Karlstad, Sweden; 01/2006.
Chadha, R., Konovich, M., and Scedrov, A. 2001. Inductive Methods
and Contract-Signing Protocols. In: Proceedings of 8th ACM
Conference on Computer and Communications Security. 6-8
November 2001. Pennsylvania, USA. ACM Press. p. 176-185.
Shmatikov, V., and Mitchell J.C. 2002. Finite-State Analysis of Two
Contract Signing Protocols. Theoretical Computer Science 283: 419450.
Gürgens, S., and Rudolph, C. 2005. Security Analysis of Efficient (Un-)
Fair Non-Repudiation Protocols. Formal Aspect of Computing 17(3):
260-276.