Fair Exchange E-Commerce Protocol for Multi-Chained Complex
Transactions
C
˘
at
˘
alin V. B
ˆ
ırjoveanu
1
and Mirela B
ˆ
ırjoveanu
2
1
Department of Computer Science, “Al.I.Cuza” University of Ias¸i, Ias¸i, Romania
2
Continental Automotive, Ias¸i, Romania
Keywords:
B2C/B2B, Multi-Party Electronic Commerce, Chained Transactions, Complex Transactions, Fair Exchange.
Abstract:
In this paper, we introduce the concept of chained transaction as a transaction in which the customer obtains
a physical product from a provider using one or more active intermediaries (brokers). Even if there are many
multi-party fair exchange protocols with applications in buying digital or physical goods, digital signature
of contracts and certified e-mail, no one can be used to solve our problem: complex transactions in which
a customer wants to buy several physical products, where each product is acquired in a chained transaction,
providing fair exchange. In this paper, we propose the first solution to the problem mentioned above. Our
protocol is optimistic and provides fairness, timeliness, non-repudiation and confidentiality.
1 INTRODUCTION
In e-commerce was taken into consideration a sig-
nificant type of transaction namely complex trans-
action. Complex transactions are very important as
they allow the customer a great flexibility regarding
the products he wants to buy. A complex transaction
is the combination in any form of aggregate and op-
tional transactions. An aggregate/atomic transaction
is a transaction in which the customer wants to buy
several products and he wants to obtain either all of
them, or none of them. An optional transaction is a
transaction in which the customer wants to buy ex-
actly one product from many options he expresses.
In the transaction model that considers complex
transactions, we introduce the concept of chained
transaction. A chained transaction is a transaction in
which the customer obtains a physical product from
a provider using one or more active intermediaries
(brokers). A broker is a party involved in the chained
transaction that receives from another broker (or cus-
tomer) a request to provide a certain physical product,
and to fulfill the request, he buys the product from
another broker (or a provider) an sells it to the re-
questing party. This type of transaction is relevant to
be considered being often used in practice, for exam-
ple when a broker makes available the products from
many others brokers/providers as a single interface to
the customer. A key business requirement is that after
execution of a chained transaction, each party knows
only the identities of the parties with whom he/she
communicates in the exchanges in which is involved.
The importance of this requirement derives from the
fact that if after the chained transaction’s execution a
broker from chain knows a provider, then in the trans-
actions that follow he could skip certain brokers in the
chain and contact the provider directly.
We define the Multi-Chained Complex Transac-
tions Protocol (MCCTP) as the protocol that consid-
ers complex transactions in which the customer ac-
quires each physical product in a chained transaction.
A standard security requirement in e-commerce
protocols is fair exchange. Generally speaking, an
e-commerce protocol ensures fair exchange if either
the customer/each broker receives the successful pay-
ment evidence and the corresponding broker/provider
receives the payment for product, or none of them ob-
tains nothing.
There are protocols for buying physical products
that provide fair exchange and consider only one cus-
tomer and one merchant (Djuric and Gasevic, 2015),
(Alaraj, 2012).
Many multi-party fair exchange protocols were
proposed with applications in e-commerce transac-
tions for buying physical goods (B
ˆ
ırjoveanu and
B
ˆ
ırjoveanu, 2019a), buying digital goods (B
ˆ
ırjoveanu
and B
ˆ
ırjoveanu, 2019b), (Liu, 2009), exchange of dig-
ital goods (Zhang et al., 2004), digital signature of
contracts (Draper-Gil et al., 2013a) and certified e-
mail (Zhou et al., 2005).
Bîrjoveanu, C. and Bîrjoveanu, M.
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions.
DOI: 10.5220/0009824000490060
In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - Volume 3: ICE-B, pages 49-60
ISBN: 978-989-758-447-3
Copyright
c
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
49
There are also multi-party fair exchange proto-
cols that considers intermediaries in different scenar-
ios: digital signature of contracts (Draper-Gil et al.,
2013b), non-repudiation (Onieva et al., 2004), and ex-
change of electronic items (Khill et al., 2001). From
the multi-party fair exchange protocols considering
intermediaries proposed until now, there is no one to
address our problem: complex transactions in which
a customer wants to buy several physical products,
where each product is acquired in a chained trans-
action using one or more brokers, providing fair ex-
change. (Khill et al., 2001) considers a ring architec-
ture that can not be applied to our problem because
in our model the customer and the provider are not
directly communicating. The proposal from (Onieva
et al., 2004) considers a customer, many providers,
but only one intermediary without considering com-
plex transactions. Thus, this solution is not suitable
for our problem because in our model we consider
a customer that buys physical products in a complex
transaction where each product is obtained using one
or more intermediaries (brokers). A solution for dig-
ital contracts signing between a customer and many
providers using intermediaries is proposed in (Draper-
Gil et al., 2013b). This solution considers a contracts
signing scenario that is different from our scenario,
so it can not be applied to our problem. Moreover,
the proposal from (Draper-Gil et al., 2013b) assures
weak fair exchange between digital signed contracts,
while our protocol assures strong fair exchange be-
tween successful payment evidences and payments
for physical products. Weak fairness requires that all
parties receive the expected items, or all honest par-
ties will have enough evidence to prove that they have
behaved correctly in front of an arbiter.
As a result, from all known solutions for multi-
party fair exchange considering intermediaries, no
one can be applied to solve our problem.
Our Contribution. In this paper, we propose the
first e-commerce protocol for complex transactions
in that the customer wants to buy several different
physical products, where each product is acquired
in a chained transaction using one or more brokers,
providing strong fair exchange. Our protocol pro-
vides also effectiveness, timeliness, non-repudiation
and confidentiality.
The paper is structured as follows: section 2
presents use cases of our protocol, section 3 defines
security requirements, section 4 describes our proto-
col. Section 5 presents the security analysis of our
protocol and section 6 contains the conclusion.
2 USE CASES IN B2C/B2B
Our protocol has use cases in Business to Consumer
(B2C) and Business to Business (B2B) scenarios. For
a B2C scenario, the customer is browsing through the
online catalog where there are a great variety of prod-
ucts for home decorations. In this catalog are prod-
ucts from HomeDept, BestHome, RusticHome, and
so on, that are home decorations hypermarkets which
collaborate with many other intermediaries (brokers)
to get the merchandise they sell. The customer wants
to redecorate a room. He would like primary a rustic
style, but if this is not possible (due to lack of stock or
delay in delivery time), also a modern style would fit.
Anyhow, in both options, he would like a white car-
pet and white curtains. So, he specifies his options as
a multi-chained complex transaction: ((rustic couch
and rustic table and rustic painting) or (2 modern arm-
chairs and steel table and abstract painting)) and white
carpet and white curtains. The multi-chained com-
plex transaction is an aggregate transaction in which
first component is an optional transaction, the sec-
ond and third components are individual products. In
the optional transaction, both preferences are aggre-
gate transactions. Each individual product is acquired
trough a chained transaction using one or more bro-
kers. The rustic couch (RC) and the rustic painting
(RP) are sold by the broker HomeDept, while the rus-
tic table (RT) is sold by the broker RusticHome. In
a chained transaction in which the customer acquires
RC, the customer initiates an exchange by contact-
ing the first broker HomeDept that is the receiver in
this exchange. HomeDept initiates the second ex-
change from chain by contacting the second broker
AllCouches that is the receiver in this exchange. All-
Couches goes in his turn to the next broker BestSleep-
Products that further goes to the provider that pro-
duces the couches. Similarly, in the chained trans-
action in that RT is acquired, RusticHome goes to the
second broker WoodenStuff that goes to the carpenter
that produces the table. Also, in the chained trans-
action in that RP is acquired, HomeDept collaborates
directly with a painter. In a similar manner, the white
table and curtains are acquired in chained transactions
using one or more brokers.
For example, a pack of products that solves the
customer’s options is: RC and RT and RP and white
carpet and white curtains. This means that each prod-
uct from the pack was successfully acquired in a
chained transaction: each party that initiates an ex-
change (the customer or a broker) receives a success-
ful payment evidence from the corresponding receiver
(a broker or the provider) and the corresponding re-
ceiver receives the payment for product from the cor-
ICE-B 2020 - 17th International Conference on e-Business
50
responding initiator.
A similar scenario can be used for B2B. In this
case, the customer is an interior design company that
redecorates a hotel.
3 SECURITY REQUIREMENTS
In what follows, we will discuss the security re-
quirements we want to achieve: effectiveness, fair-
ness, timeliness, non-repudiation, and confidentiality.
These requirements are also stated and analyzed in
(B
ˆ
ırjoveanu and B
ˆ
ırjoveanu, 2019a).
Effectiveness requires that if every party involved
in MCCTP behaves honestly, does not want to prema-
turely terminate the protocol, and no communication
error occurs, then the customer receives his success-
ful payment evidences (digital receipts) from brokers
and each corresponding broker receives the payment
for product, each broker that initiates an exchange
receives his successful payment evidence from the
corresponding broker/provider and each receiver bro-
ker/provider receives the payment for product, with-
out any intervention of Trusted Third Party (TTP).
This is a requirement for optimistic protocols, where
TTP intervenes only in case of unexpected situations,
such as a network communication errors or dishonest
behavior of one party.
Fairness in electronic payment protocols for phys-
ical products from (Djuric and Gasevic, 2015) is de-
fined only for one customer and one merchant. So, we
must adapt the fairness requirement to our scenario:
for chained transactions and also for multi-chained
complex transactions.
Fairness for a chained transaction requires:
either the chained transaction is successful: each
party that initiates an exchange in the chained
transaction (the customer or a broker) receives
a successful payment evidence from the corre-
sponding receiver (a broker or the provider) and
the receiver receives the payment for the product
from the corresponding initiator, or
the chained transaction is aborted: each party that
initiates an exchange (the customer or a broker) in
the chained transaction receives an aborted pay-
ment evidence from the corresponding receiver (a
broker or the provider) and the receiver doesn’t
receive the payment for the product.
Fairness in MCCTP (for a multi-chained complex
transaction) requires:
fairness for any chained transaction from the com-
plex transaction, and
for any optional transaction from the complex
transaction, either the chained transactions corre-
sponding to exactly one option are successful, or
all chained transactions are aborted, and
for any aggregate transaction from the complex
transaction, either all chained transactions belong-
ing to the aggregate transaction are successful, or
all are aborted.
This requirement corresponds to the strong fairness.
Timeliness requires that any party involved in MC-
CTP can be sure that the protocol’s execution will be
finished at a certain finite point of time, and after the
protocol’s finish point, the fairness level achieved can-
not be degraded.
Non-repudiation requires that neither the cus-
tomer, any of brokers, nor any of providers can deny
their involvement in MCCTP.
Confidentiality in MCCTP requires that the con-
tent of messages sent between participating parties
is accessible only to authorized parties. Also, after
any chained transaction’s execution, each party knows
only the identities of the parties with whom he/she
communicates in the exchanges in which participates.
The last requirement is important in chained transac-
tions: if after the chained transaction’s execution a
broker from chain knows a provider, then in the trans-
actions that follow he could skip certain brokers in the
chain and contact the provider directly.
4 MULTI-CHAINED COMPLEX
TRANSACTIONS PROTOCOL
In MCCTP, we consider that one customer can
buy products in complex transactions from many
providers using brokers.
4.1 Participants, Roles, Communication
Channels
MCTTP has the following participants: the customer,
the providers, the brokers, the payment gateway and
the bank. Table 1 presents the notations used in the
description of MCCTP.
In MCCTP the following roles are identified: ini-
tiator, receiver and payment processing. An initiator
is an agent that initiates an exchange with a receiver
by sending a request to the receiver to buy a product.
A receiver is an agent that responds to the initiators
request by sending to the initiator the corresponding
evidence of product’s buying. The payment process-
ing is an agent that performs payments between initia-
tors and receivers. These roles can be played by the
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions
51
Table 1: Notations used in the protocol description.
Notation Interpretation
C, PG, P
j
, B
i
Identity of Customer, Payment Gateway, Provider j, Broker i, where 1 j k, 1 i n
PkA, {m}
PkA
RSA public key of the party A, hybrid encryption of the message m with PkA
SigA(m) RSA digital signature of A on the digest h(m) of m, where h is a hash function
A B : m A sends the message m to B
participants as follows. C initiates a complex transac-
tion and can play only the initiator role. A provider
is an agent that provides a product to the agent that
initiates an exchange with him. So, any provider can
play only the receiver role. A broker is an interme-
diary agent in a chained transaction, communicating
with both initiators and receivers. In an exchange in
that the broker provides a product to an initiator, the
broker plays the receiver role. In an exchange in that
the broker buys a product from a receiver, the broker
plays the initiator role. The payment processing role
is played by PG that is a trusted party.
Hybrid encryption {m}
PkA
of the message m with
the public key PkA means {m}
K
, {K}
PkA
: the mes-
sage m is encrypted with an AES session symmetric
key K, which is in turn encrypted using PkA. If two
parties use the session symmetric key K in a hybrid
encryption, then they will use K to hybrid encrypt all
the messages that will be transmitted between them
for the remainder of session. We consider unreliable
communication channels (messages can be lost) be-
tween initiators and receivers, and resilient commu-
nication channels (messages can be delayed but not
lost) between PG and the other participants.
4.2 Setup
In what follows, we describe the setup phase which
is needed before MCCTP execution. The customer
is browsing through the online catalog where the
products from brokers are posted. After C decides
the products pack he wants to buy and the op-
tions/alternatives for each product from the pack, he
clicks a ”submit” button on the online catalog. We
consider that each initiator (customer or broker) has
a payment Web segment downloaded from PG. The
payment Web segment is a software digitally signed
by PG that runs on the initiator’s computer.
For each subtransaction from the complex transac-
tion (corresponding to the product the initiator wishes
to buy), the corresponding payment Web segment re-
quires from initiator the credit card information and a
challenge code that will be used to authenticate and
authorize the initiator for using the credit card. Also,
the payment Web segment generates a RSA session
public/private key pair for the initiator. We consider
that the payment Web segment has the digital certifi-
cates for the public keys of PG and of each receiver he
communicates with. Also, each receiver/PG has the
digital certificate for PG/each receiver’s public key.
MCCTP uses the Chained Transaction Protocol
(CTP). Next, we will describe CTP in which the cus-
tomer buys a certain physical product using one or
more brokers and a provider.
4.3 Chained Transaction Protocol
A subtransaction is an exchange in which an initia-
tor (customer or a broker) buys a physical product
from a receiver (a broker or a provider). A chained
transaction in which C buys a certain physical prod-
uct using the brokers B
1
,...,B
n
and the provider P is
a sequence of subtransactions s
0
s
1
...s
n
, where C is
the initiator in s
0
, B
i
is receiver in s
i1
and initiator
in s
i
, with 1 i n, and P is receiver in s
n
. In such
a chained transaction, C knows only the identity of
the broker he communicates with in the subtransac-
tion s
0
, because C participates only in s
0
. Also, B
i
knows only the identities of the agents from the sub-
transactions s
i1
and s
i
in which he participates, and
P knows only the identity of the broker B
n
.
C initiates CT P by sending to B
1
a purchase order
for buying a certain physical product. To fulfill Cs
request, B
1
initiates a new subtransaction by send-
ing a purchase order to B
2
. In the same manner, B
2
initiates a new subtransaction with B
3
, and so on un-
til B
n
initiates a new subtransaction with P. In this
step, n+1 subtransactions s
0
,s
1
,...,s
n
are started be-
longing to the chained transaction s
0
s
1
...s
n
. The suc-
cessful finish of the entire chained transaction starts
successfully finishing the subtransaction s
n
, s
n1
, un-
til successfully finishing s
0
. Successful finish of s
n
means that B
n
as initiator received from P the suc-
cessful payment evidence for product, and P received
the payment from B
n
. Only after successful finish of
s
n
, B
n
sends as receiver in s
n1
the payment request to
PG. Successful finish of s
n1
means that B
n
received
the payment from B
n1
, and B
n1
received from B
n
two successful evidences: the current payment evi-
dence of B
n1
and B
n
in s
n1
, and the past payment
evidence of B
n
in s
n
. In this manner, any subtransac-
tion s
i
from chain is successfully finished only after
the successful finish of s
i+1
,...,s
n
subtransactions.
CTP for a chained transaction s
0
s
1
...s
n
con-
sists of the Exchange sub-protocol for each chained
subtransaction s
i
, and two Resolution sub-protocols.
ICE-B 2020 - 17th International Conference on e-Business
52
Next, we will describe the CTPs sub-protocols.
4.3.1 Exchange Sub-protocol
In this section, we will describe the Exchange sub-
protocol for an arbitrary subtransaction s
i
, where 0
i n, that is presented in Table 3. The notations used
in CTP are provided in Table 2. In the subtransaction
s
i
, the payment Web segment of the initiator B
i
sends
to the receiver B
i+1
the purchase order PO
i,i+1
to buy
the product from the chained transaction. PO
i,i+1
contains a payment message PM
i
and the order in-
formation OI
i
both encrypted with PkB
i+1
. PM
i
is
build by B
i
s payment Web segment by encrypting
with PGs public key the payment information PI
i
of
B
i
and the signature of B
i
on PI
i
.
PI
i
contains the data provided by user as initiator:
card number CardN
i
and a challenge code CCode
i
is-
sued by bank. The challenge code is provided to user
by bank via SMS and it has a minimum length of four
characters. In each subtransaction s
i
from chained
transaction, the payment Web segment of B
i
gener-
ates a fresh random number N
i
. The identifier Id
i
of
s
i
is built by concatenating the identifier Id
i1
of s
i1
with N
i
. So, the identifier Id
i
of s
i
is the sequence
of numbers N
0
N
1
...N
i
generated in all subtransac-
tions of s
0
,s
1
,...,s
i
. This way of assigning identifiers
to subtransactions allows tracing the subtransactions
from the chained transaction. Thus, in case of a latter
dispute, the identification of the subtransactions from
chain is done in a simple manner. Also, PI
i
includes
the identifier Id
i
, the amount Am
i
, and PkB
i
.
OI
i
contains the identity of the initiator B
i
, of the
receiver B
i+1
, the product identifier Pid, the subtrans-
action identifier Id
i
, the amount Am
i
, and PkB
i
.
In each subtransaction s
i
, the receiver decrypts
PO
i,i+1
and checks the signature of the initiator on
OI
i
. If the receiver B
i+1
is not the provider P (i < n),
then he stores PO
i,i+1
and sends PO
i+1,i+2
to B
i+2
for
buying the product requested by B
i
.
At the line 2, if the receiver B
i+1
is the provider P
(i = n), then s
i
is the last subtransaction from chain.
So, B
i+1
stores PO
i,i+1
and sends the payment re-
quest PR
i,i+1
to PG to get payment from B
i
. PR
i,i+1
is
built from the payment message PM
i
and B
i+1
s sig-
nature on the subtransaction identifier Id
i
, the iden-
tity of the initiator B
i
, of the receiver B
i+1
, PkB
i
,
and Am
i
. Upon receiving PR
i,i+1
, PG decrypts it,
checks B
i
s signature on PI
i
and checks if B
i
is au-
thorized to use the card by checking if the combina-
tion of CardN
i
and CCode
i
is valid. If these checks
are successfully passed, then also B
i
proves as being
the owner of the public key PkB
i
. PG checks B
i+1
s
signature, and if checking is successful, then it has
the confirmation that both B
i
and B
i+1
agreed on Id
i
,
PkB
i
and Am
i
. If some check fails, then PG sends
to B
i+1
an aborted current payment evidence CE
i,i+1
(with Resp = ABORT ). If all checks are successful,
PG sends the payment message to the bank. The bank
checks B
i
s account balance, and if it is enough, then
the bank makes the transfer in B
i+1
s account pro-
viding a successful current payment evidence CE
i,i+1
(with Resp = Y ES) to PG that forwards it to B
i+1
at
the line 3. Otherwise, if checking B
i
s account bal-
ance fails, then also the transfer fails and the bank
provides an aborted current payment evidence CE
i,i+1
(with Resp = ABORT ) to PG that forwards it to B
i+1
as a proof of s
i
s abortion. We remark that the current
evidence CE
i,i+1
in s
i
includes the evidence E
i
that
will be latter send by B
i
to B
i1
to inform B
i1
if s
i
was successfully finished or aborted. Also, PG stores
PR
i,i+1
and CE
i,i+1
in its database. Upon receiving
{CE
i,i+1
}
PkB
i+1
, B
i+1
decrypts it and sends to B
i
(line
4) the current evidence CE
i,i+1
and the provider cer-
tificate Cert
P
both encrypted with PkB
i
. B
i
decrypts
the message received from B
i+1
, and checks the au-
thenticity of Cert
P
and CE
i,i+1
. If PGs signature from
CE
i,i+1
is successfully checked, then B
i
has the guar-
antee of CE
i,i+1
s authenticity and it corresponds to
the current subtransaction s
i
because of the presence
of the identifier Id
i
.
In each subtransaction s
i
that is not the last from
chain (i < n), in order to answer the request received
from the initiator B
i
, the receiver B
i+1
must ensure
that either all the subtransactions that follows s
i
in
chain have been successfully completed, or all the
subtransactions that follows s
i
in chain have been
aborted. An arbitrary subtransaction s
j
is success-
ful if the receiver B
j+1
received the payment and
B
j
received the successful current payment evidence
CE
j, j+1
and payment evidence E
j+1
. s
j
is aborted if
the receiver B
j+1
did not received the payment and B
j
received an aborted CE
j, j+1
.
So, at line 6, B
i+1
as initiator in s
i+1
waits to
receive from B
i+2
the current evidence CE
i+1,i+2
in
s
i+1
and the evidence E
i+2
in s
i+2
. If both ev-
idences CE
i+1,i+2
and E
i+2
received by B
i+1
are
successful (with Resp = Y ES) then this means that
s
i+1
,s
i+2
,...,s
n
are successfully finished. In this case,
B
i+1
sends PR
i,i+1
to PG in s
i
at line 8.
If B
i+1
receives from PG (line 9) a successful
CE
i,i+1
, then he sends CE
i,i+1
and E
i+1
to B
i
(line 11).
B
i
verifies evidence’s authenticity by checking PGs
signatures, checks the corresponding identifiers from
both evidences to ensure the freshness of evidences
and that these belong to successive subtransactions.
If both evidences are successful, then CE
i,i+1
ensures
B
i
that s
i
was successful and E
i+1
ensures B
i
that s
i+1
was successful. B
i
will use E
i
in s
i1
in the same man-
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions
53
Table 2: Notations used in CTP.
PO
i,i+1
= {PM
i
, OI
i
, SigB
i
(OI
i
)}
PkB
i+1
Purchase Order of B
i
to B
i+1
PM
i
= {PI
i
, SigB
i
(PI
i
)}
PkPG
and PI
i
= B
i
, CardN
i
, CCode
i
, Id
i
, Am
i
, PkB
i
, B
i+1
OI
i
= B
i
, B
i+1
, Pid, Id
i
, Am
i
, PkB
i
Id
i
= Id
i1
N
i
(If i = 0, then Id
i1
is the empty string)
PR
i,i+1
= {PM
i
, SigB
i+1
(Id
i
, B
i
, B
i+1
, PkB
i
, Am
i
)}
PkPG
Payment Request of B
i+1
to get payment from B
i
CE
i,i+1
= Resp, B
i
, B
i+1
, Id
i
, SigPG(Resp, B
i
, B
i+1
, Id
i
, Am
i
), E
i
Current Payment Evidence of B
i
and B
i+1
in s
i
E
i
= Resp, Id
i
, SigPG(Resp, Id
i
) Payment Evidence in s
i
that B
i
sends to B
i1
CE
i,i+1
.Resp/E
i
.Resp The response Resp in CE
i,i+1
/E
i
Table 3: Exchange sub-protocol for the subtransaction s
i
.
1. B
i
B
i+1
: PO
i,i+1
2. if (i = n) B
i+1
PG : PR
i,i+1
3. PG B
i+1
: {CE
i,i+1
}
PkB
i+1
4. B
i+1
B
i
: {CE
i,i+1
, Cert
P
}
PkB
i
5. else
6. if (B
i+2
B
i+1
: {CE
i+1,i+2
,E
i+2
}
PkB
i+1
in s
i+1
,
7. with CE
i+1,i+2
.Resp=YES and E
i+2
.Resp=YES)
8. B
i+1
PG : PR
i,i+1
9. PG B
i+1
: {CE
i,i+1
}
PkB
i+1
10. if (CE
i,i+1
.Resp=YES)
11. B
i+1
B
i
: {CE
i,i+1
,E
i+1
}
PkB
i
12. else Resolution 1
13. end if
14. else if (B
i+2
B
i+1
: {CE
i+1,i+2
,E
i+2
}
PkB
i+1
in s
i+1
,
15. with CE
i+1,i+2
.Resp=ABORT ) Resolution 1
16. else Resolution 2
17. end if
18. end if
19. end if
If i = 0, then B
i
denotes the customer C. If i = n, then
B
i+1
denotes P, and E
i+1
is replaced with Cert
P
.
ner as B
i+1
used E
i+1
. If B
i+1
receives from PG an
aborted CE
i,i+1
, then Resolution 1 sub-protocol is ap-
plied (line 12) to abort all subtransactions from chain.
The Resolution 1 sub-protocol will be detailed below
in section 4.3.2.
If B
i+1
receives from B
i+2
an aborted CE
i+1,i+2
,
then Resolution 1 sub-protocol is applied (line 15) to
abort all subtransactions from chain. Otherwise, if
B
i+1
receives from B
i+2
a successful CE
i+1,i+2
, but
E
i+2
is missing or aborted, then Resolution 2 sub-
protocol is applied (line 16) to obtain a successful
E
i+2
or to abort all subtransactions from chain. The
Resolution 2 sub-protocol will be detailed below in
section 4.3.3.
Therefore, CTP continues until either all subtrans-
actions initiated in chain transaction are successfully
finished, or all aborted. If all parties involved in CT P
behaves according to protocol’s steps and no commu-
nication errors appear, then in each subtransaction s
i
from chain the initiator B
i
obtains the successful cur-
rent payment evidence and the receiver B
i+1
obtains
the payment for the corresponding product.
4.3.2 Resolution 1 Sub-protocol
Let be s
i
, where 0 i n, the first subtransaction (in
reverse order: from s
n
to s
0
) from the chained trans-
action s
0
s
1
...s
n
in which B
i+1
receives from PG an
aborted CE
i,i+1
and forwards it to B
i
. If s
i
is not
the last subtransaction from chain (i < n), then fair-
ness in CTP is not ensured because the subtransac-
tions s
i+1
,...,s
n
are successful, and s
i
is aborted due
to aborted CE
i,i+1
. If s
i
is the last subtransaction from
chain (i = n), then s
n
is aborted, and also the sub-
transactions s
n1
,...,s
0
must be aborted. So, to ob-
tain fairness in CTP, Resolution 1 sub-protocol de-
scribed in Table 4 is applied to abort all subtransac-
tions s
i
from chain.
If s
i
is not the last subtransaction from chain, then
B
i+1
initiates Resolution 1 by sending to PG a request
to abort s
i+1
. The request contains the aborted CE
i,i+1
in s
i
and the successful CE
i+1,i+2
in s
i+1
. PG veri-
fies evidence’s authenticity by checking his signatures
and checks the corresponding identifiers from both
evidences to ensure that these belong to successive
subtransactions. If all checks are passed, PG aborts
the successful CE
i+1,i+2
. We denote by CE
i+1,i+2
, the
evidence generated by PG that aborts the successful
CE
i+1,i+2
. PG sends CE
i+1,i+2
to B
i+1
and B
i+2
as a
proof of aborting s
i+1
. The first for loop aborts in a
similar manner s
i+2
,...,s
n
, each iteration aborting a
new subtransaction from chain until aborting s
n
.
PG obtains CE
i+1,i+2
from the bank by sending to
it the request of B
i+1
. The bank aborts the success-
ful CE
i+1,i+2
by canceling the transfer from B
i+1
s
account into B
i+2
s account, and builds CE
i+1,i+2
as
follows:
1. E
i+1
= SigPG(ABORT, Id
i+1
, E
i+1
)
2. CE
i+1,i+2
= ABORT,B
i+1
,B
i+2
,Id
i+1
,SigPG(ABORT,
B
i+1
,B
i+2
,Id
i+1
,Am
i+1
,CE
i+1,i+2
),E
i+1
The second for loop aborts s
i1
,...,s
0
in this or-
der. In the first iteration, B
i
sends to PG a request to
abort s
i1
. The request contains the aborted CE
i,i+1
in s
i
and the content of PO
i1,i
received by B
i
in
s
i1
. PG verifies evidence’s authenticity by checking
his signature and PO
i1,i
s authenticity by checking
ICE-B 2020 - 17th International Conference on e-Business
54
Table 4: Resolution 1 sub-protocol.
if (i < n) B
i+1
PG : {CE
i,i+1
, CE
i+1,i+2
}
PkPG
PG B
i+1
: {CE
i+1,i+2
}
PkB
i+1
PG B
i+2
: {CE
i+1,i+2
}
PkB
i+2
end if
for ( j = i + 1; j n 1; j = j + 1)
B
j+1
PG : {CE
j, j+1
, CE
j+1, j+2
}
PkPG
PG B
j+1
: {CE
j+1, j+2
}
PkB
j+1
PG B
j+2
: {CE
j+1, j+2
}
PkB
j+2
end for
for ( j = i; j 1; j = j 1)
B
j
PG : {CE
j, j+1
,PM
j1
,OI
j1
,Sig
B
j1
(OI
j1
)}
PkPG
PG B
j
: {CE
j1, j
}
PkB
j
PG B
j1
: {CE
j1, j
}
PkB
j1
end for
the B
i1
s signatures. Also, PG verifies the corre-
sponding identifiers from CE
i,i+1
and PO
i1,i
to en-
sure that these belong to successive subtransactions.
If all checks are passed, PG generates an aborted ev-
idence CE
i1,i
and sends it to B
i
and B
i1
as a proof
of aborting s
i1
. Each iteration continues in a simi-
lar manner aborting a new subtransaction from chain
until aborting s
0
.
4.3.3 Resolution 2 Sub-protocol
Let be s
i
, where 0 i n, the first subtransaction (in
reverse order: from s
n
to s
0
) from the chained transac-
tion s
0
s
1
...s
n
in which B
i
sends PO
i,i+1
to B
i+1
, but
B
i
does not receive a payment evidence or receives
an invalid payment evidence from B
i+1
. It is obvious
that in this scenario, fairness in CTP is not ensured.
In this case, in any subtransaction s
i
from chain, a
timeout interval t (e.g. in the order of seconds or
minutes) is defined, in which B
i
waits a payment evi-
dence from B
i+1
. If t expires and B
i
does not receive a
payment evidence or receives an invalid payment ev-
idence from B
i+1
, then B
i
initiates Resolution 2 with
PG to receive a payment evidence w.r.t. s
i
and to ob-
tain fairness in CTP. B
i
sends to PG the content of
purchase order PO
i,i+1
and the invalid evidence R re-
ceived from B
i+1
, if a such an evidence is received.
B
i
PG : {PM
i
, OI
i
, R, SigB
i
(OI
i
, R)}
PkPG
PG decrypts the message, checks B
i
s signature
and checks the purchase order’s content and R.
If R does not contain the evidence CE
i,i+1
, then
PG checks if CE
i,i+1
has been generated for the entry
Id
i
, Am
i
and PkB
i
, as follows:
1. If PG finds in its database the successful CE
i,i+1
for the entry above, then PG requires E
i+1
from
B
i+1
. If B
i+1
responds to PG with a successful
E
i+1
, then PG sends it to B
i
and CTP continues
with s
i1
. Otherwise, if B
i+1
responds with an
aborted E
i+1
or does not respond, then PG gener-
ates the aborted
CE
i,i+1
and sends it to B
i
and B
i+1
as a proof of aborting s
i
. Now, Resolution 1 is ap-
plied to abort s
i+1
,...,s
n
if these are successful,
and also to abort s
i1
,...,s
0
.
2. If PG finds in its database the aborted CE
i,i+1
for
the entry above, then PG sends CE
i,i+1
to B
i
and
B
i+1
as a proof of aborting s
i
. Resolution 1 is ap-
plied as in item 1.
3. If PG does not find an evidence for the entry
above, then PG generates the aborted evidence
CE
i,i+1
and sends it to B
i
and B
i+1
as a proof of
aborting s
i
. Resolution 1 is applied as in item 1.
If R contains a successful CE
i,i+1
but a successful
E
i+1
is missing, then PG requires E
i+1
and CTP
continues as in item 1.
A chained transaction s
0
s
1
...s
n
successfully fin-
ished CTP if all subtransactions s
i
, where 0 i n,
are successfully finished (B
i
receives the successful
CE
i,i+1
and E
i
and B
i+1
receives the payment for
the corresponding product). A chained transaction
s
0
s
1
...s
n
is aborted if all subtransactions s
i
, where
0 i n, are aborted (B
i
receives an aborted CE
i,i+1
and B
i+1
does not receive the payment for product).
As we can see, after running CTP, either the chained
transaction successfully finished CTP, or is aborted.
Example. In Figure 1, we describe an instance of
CTP considering a customer C = B
0
, two brokers B
1
,
B
2
and a provider B
3
= P. In this example, C knows
only B
1
, B
1
knows only C and B
2
, B
2
knows only B
1
and P and P knows only B
2
. The chained transac-
tion is the sequence of the subtransactions s
0
s
1
s
2
. In
s
0
, C initiates CTP by sending P
0,1
to B
1
for buying
a certain physical product. To acquire the product
requested by C in s
0
, the broker B
1
initiates a new
subtransaction s
1
by sending PO
1,2
to B
2
. Also, to
acquire the product requested by B
1
, B
2
initiates s
2
by sending PO
2,3
to P. s
2
is the last subtransaction
from the chain because the receiver in s
2
is P. So, P
sends PR
2,3
to PG to get the payment for his prod-
uct from B
2
. After PG successfully verifies PR
2,3
,
he sends to P the successful CE
2,3
. To complete s
2
,
P sends to B
2
the successful CE
2,3
and Cert
P
. After
receiving message 6, B
2
is ensured that s
2
is success-
fully finished. In this step, B
2
continues s
1
(in which
he is the receiver) by sending in message 7, PR
1,2
to
PG that responds to him with a successful CE
1,2
. To
complete s
1
, B
2
sends to B
1
the successful CE
1,2
and
E
2
. The successful CE
1,2
ensures B
1
that s
1
success-
fully finished and the successful E
2
ensures B
1
that
s
2
successfully finished. In this step, B
1
continues s
1
by sending the message 10 to PG. After B
1
obtains
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions
55
C=B
0
1.PO
0,1
B
1
B
2
B
3
=P
2.PO
1,2
3.PO
2,3
12.{CE
0,1
,E
1
}
PkB0
PG
10.PR
0,1
11.{CE
0,1
}
PkB
1
9.{CE
1,2
,E
2
}
PkB1
PG
7.PR
1,2
8.{CE
1,2
}
PkB
2
6.{CE
2,3
,Cert
P
}
PkB2
PG
4.PR
2,3
5.{CE
2,3
}
PkB
3
subtransaction s
0
subtransaction s
1
subtransaction s
2
Figure 1: CTP message flow.
successful CE
0,1
, he sends CE
0,1
and E
1
to C. If C
obtains the successful CE
0,1
and E
1
, then the chained
transaction is successful. So, in each subtransaction
s
i
, the initiator B
i
obtains the successful current evi-
dence and the receiver B
i+1
obtains the payment.
On the other side, for example, if s
2
was success-
fully finished and in s
1
the broker B
2
receives in mes-
sage 8 an aborted CE
1,2
, then an unfair case appears
w.r.t. the entire chained transaction. In this case, B
2
initiates Resolution 1 sub-protocol with PG to abort
s
2
and s
0
. So, the chained transaction is aborted.
4.4 MCCTP Description
MCCTP is based on the same idea as the proposed
protocol in (B
ˆ
ırjoveanu and B
ˆ
ırjoveanu, 2019a).
For an aggregate transaction, the aggregation op-
erator, denoted by , is defined as follows: Pid
1
... Pid
k
meaning that C wishes to buy exactly k
products with product’s identifiers Pid
1
,...,Pid
k
. For
an optional transaction, the option operator, denoted
by , is defined as follows: Pid
1
. . . Pid
k
meaning
that C wishes to buy a product that is exactly one of
the products with product’s identifiers Pid
1
,...,Pid
k
,
where the apparition order of the product’s identifiers
is the priority given by C. This means that C wishes
first of all to buy the product Pid
1
, but if this is not
possible, his second option is Pid
2
, and so on.
From the choices of C describing the sequence of
products he wishes to buy, we build a tree over the
product identifiers selected by C using and opera-
tors. To represent the tree, we use the left-child, right-
sibling representation in that each internal node cor-
responds to one of the above operators or to an identi-
fier, while each leaf node corresponds to an identifier.
Each node of the tree is represented by a structure
with the following fields: info for storing the useful
information (identifier or one of the operators), left
for pointing to the leftmost child of node, and right
for pointing to the sibling of the node immediately
to the right. The access to tree is realized trough the
root. An example of tree derived from the complex
Figure 2: Tree describing the customer’s choices.
transaction from section 2, is shown in Figure 2.
Pid
1
corresponds to RC, Pid
2
to RT, Pid
3
to RP,
Pid
4
to modern armchairs, Pid
5
to steel table, Pid
6
to abstract painting, Pid
7
to white carpet and Pid
8
to
white curtains. The root node has operator as info.
The root does not have any right sibling and its chil-
dren are the node having operator as info and two
nodes with the info Pid
7
and Pid
8
.
In the multi-chained complex transactions proto-
col we proposed, a chained transaction ct, denoted
by CTP(C, B
i
,Pid
i
), is an instance of CTP in which
C buys the physical product with Pid
i
identifier from
the broker B
i
using many other brokers and a provider.
We define St(ct) the state of the chained transaction ct
as being the current evidence CE
0,i
that C will receive
in ct.
We define Ns(p) - the state of the node p as a se-
quence of chained transaction states St(ct
1
)...St(ct
m
)
corresponding to the product defined by p. For a node
p, Ns(p) is calculated similarly as in (B
ˆ
ırjoveanu and
B
ˆ
ırjoveanu, 2019a), depending on p info as fol-
lows:
if p info = Pid
i
, where 1 i n, then Ns(p) =
St(CTP(C,B
i
,Pid
i
)). For simplicity, we consider
that B
i
sells the product with Pid
i
identifier.
if p info = , then
Ns(p) =
Ns(l), if l, the leftmost child
of p such that St(ct).Resp =
Y ES, for all St(ct) Ns(l)
Ns(r), otherwise
where r is the rightmost child of p.
ICE-B 2020 - 17th International Conference on e-Business
56
if p info = , and c
1
,...,c
k
are all children of
p, then we have two cases:
1. if St(ct).Resp = Y ES, for any St(ct) from
Ns(c
j
), for any 1 j k, then Ns(p) =
Ns(c
1
)...Ns(c
k
).
2. otherwise, let be c
j
, where 1 j k,
the leftmost child of p with Ns(c
j
) =
St(ct
j1
)...St(ct
jm
) such that St.(ct
jl
).Resp =
ABORT , for all 1 l m. In this case, Ns(p) =
Ns(c
1
)...Ns(c
j
).
Thus, Ns(p) contains a sequence of chained trans-
action states in which either all chained transactions
successfully finished CTP or all chained transactions
are aborted.
MCCTP, described in Table 5, recursively calcu-
lates Ns(t) (t is the root of the tree derived from the
customer’s choices), traversing the tree in a similar
manner with depth-first search. For any node p of the
tree, we use a child array to store the node states of all
children of p.
At the lines 2-3, the protocol computes Ns(p) for
a node p, depending on the node state of the left most
child of p. For a node p with a least two children, the
while loop (the 5-12 lines) computes the node state of
any child of p except the left most one. If an aborted
chained transaction/sequence of chained transactions
leads to aborting the entire aggregate transaction, but
some chained transactions from the aggregate trans-
action successfully completed CTP, then the ones
that are successfully must also be stored in the node
state corresponding to operator (line 9) and af-
terwards aborted by applying AggregateChainsAbort
sub-protocol (line 10). We will describe Aggregate-
ChainsAbort sub-protocol in section 4.4.1.
At line 13, the protocol computes Ns(p) for a node
p with a product identifier as info.
4.4.1 AggregateChainsAbort Sub-protocol
In MCCTP, an unfair case for C may oc-
cur: the entire aggregate transaction is not
successful, but C has paid for certain prod-
ucts purchased in the successful chained transac-
tions. For example, for a node p that corre-
sponds to operator, MCCTP computes the node
state Ns(p) = St(ct
1
)...St(ct
k
)St(ct
k+1
)...St(ct
m
),
where St(ct
i
).Resp = Y ES for any 1 i k and
St(ct
j
).Resp = ABORT for any k + 1 j m.
To solve this unfair case, the customer’s payment
Web segment initiates AggregateChainsAbort(Ns(p))
sub-protocol by sending to PG a customer’s request
to abort any chained transaction from Ns(p) that suc-
cessfully finished CTP.
C PG : {Ns(p), SigC(Ns(p))}
PkPG
The customer request is build from Ns(p) and Cs
signature on Ns(p), both encrypted with PkPG.
PG decrypts the customer’s request, obtains the se-
quence of chained transaction states St(ct
1
)...St(ct
m
)
in Ns(p), and checks Cs signature on Ns(p). For
each St(ct
i
) Ns(p), PG searches into its database the
appropriate entry, and if it finds out then also checks
his signature.
If all checks are successfully passed, then
PG sends to the bank the customer’s request.
Each chained transaction ct
i
= CT P(C,B
i
,Pid
i
) =
s
0
s
1
...s
n
such that St(ct
i
) Ns(p) and St(ct
i
).Resp =
Y ES will be aborted as follows:
1. The bank cancels the transfer corresponding to s
0
,
from Cs account into B
i
s account, and generates
St(ct
i
) as in Resolution 1 sub-protocol.
2. After receiving St(ct
i
) from the bank, PG sends it
to C and B
i
as a proof of s
0
s abortion.
3. s
1
,..., s
n
, in this order, will be aborted by apply-
ing the same technique as in Resolution 1 sub-
protocol (B
i
requires and obtains from PG abor-
tion of s
1
, and so on, the last broker from chain
requires and obtains from PG abortion of s
n
).
5 SECURITY ANALYSIS
In this section, we will analyze the security require-
ments stated in section 3 for our MCCTP.
5.1 Effectiveness
If every party involved in MCCTP behaves accord-
ing to the protocol’s steps, does not want to prema-
turely terminate the protocol and there are no net-
work communication delays/errors, then each chained
transaction executed in MCCTP is successfully fin-
ished, without TTP involvement. Therefore, our pro-
tocol meets the effectiveness requirement.
5.2 Fairness
To show that MCCTP ensures fairness, three require-
ments must be satisfied. First requirement to obtain
fairness in MCCTP is to obtain fairness in CTP. So,
we will show that CTP ensure fairness by analyzing
all possible behaviors of each participant involved in
CTP: the customer, the brokers and the provider.
Customer. In CTP, each initiator (customer or bro-
ker) has a payment Web segment that performs initia-
tor’s side protocol actions and is a soft digitally signed
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions
57
Table 5: Multi-Chained complex transactions protocol.
MCCTP(t)
1. if (t left 6= NULL) child[0] = MCCTP(t left);
2. if ((t info = and St(ct).Resp = Y ES, for all St(ct) from child[0]) or
3. (t info = and St(ct).Resp = ABORT , for all St(ct) from child[0])) Ns(t) = child[0]; return Ns(t);
4. j = 1; k = t left right;
5. while (k 6= NULL)
6. child[j] = MCCTP(k);
7. if (t info = and St(ct).Resp = Y ES, for all St(ct) from child[j]) Ns(t) = child[j]; return Ns(t);
8. if (t info = and St(ct).Resp = ABORT , for all St(ct) from child[j])
9. for (c = 0; c j; c = c + 1) Ns(t) = Ns(t)child[c]; end for
10. AggregateChainsAbort(Ns(t)); return Ns(t);
11. k = k right; j = j + 1;
12. end while
13. if (t info = Pid
i
) Ns(t) = St(CTP(C,B
i
,Pid
i
)); return Ns(t);
14. else if (t info = ) k = t left;
15. while (k right 6= NULL) k = k right; end while
16. Ns(t) = Ns(k); return Ns(t);
17. else for (c = 0; c j - 1; c = c + 1) Ns(t) = Ns(t)child[c]; end for
18. return Ns(t);
19. end if
20. end if
by PG that is a trusted party. So, any corruption of
the payment Web segment by user is impossible. If
C initiates CTP with a broker B
i
, but a network com-
munication error appears and B
i
does not receive the
message from C, then C will not receive any payment
evidence from B
i
. If we consider only the current
chained transaction, then this is not an unfair case.
However, the state of this chained transaction is unde-
fined, and this scenario must be solved if this chained
transaction belongs to a multi-chained complex trans-
action. To ensure fairness in MCCTP, each chained
transaction must have a defined state (successful or
aborted). So, in this case, C waits for an evidence
from B
i
until the timeout interval t expires in which
case C initiates Resolution 2 sub-protocol to abort the
current chained transaction.
The only scenarios in which C can behave dishon-
est in CTP are when he wants to buy a product and
his account balance is insufficient, or when C pro-
vides incorrect data (card number, challenge code). In
both scenarios, the only case in CTP in that fairness
is not insured is when in a chained transaction ct =
CT P(C,B
i
,Pid
i
) = s
0
s
1
...s
n
, s
0
is the first aborted
subtransaction (in the reverse order: from s
n
to s
0
) in
which B
i
receives from PG an aborted CE
0,i
. In this
case, s
1
,...,s
n
are successful, and to obtain fairness
in CT P, B
i
initiates Resolution 1 sub-protocol. After
Resolution 1, all subtransactions from ct are aborted,
so fairness is ensured.
Broker. If s
i
is the first subtransaction from a
chained transaction s
0
s
1
...s
n
, in which B
i+1
does not
receive PO
i,i+1
from B
i
because of a network com-
munication error, then B
i
will not receive any pay-
ment evidence from B
i+1
. By the same reasoning as
in Cs case, B
i
waits for an evidence from B
i+1
until
the timeout interval t expires in which case B
i
initiates
Resolution 2 sub-protocol to abort the current chained
transaction.
We detail below all scenarios in which a broker B
i
can behave dishonest in CTP:
In s
i
, B
i
wants to buy from B
i+1
a product and
his account balance is insufficient, or B
i
provides
incorrect data (card number, challenge code). In
these scenarios, the only case in CTP in that fair-
ness is not insured is when s
i
is the first sub-
transaction (in the reverse order) from the chained
transaction s
0
s
1
...s
n
, in which B
i+1
receives from
PG an aborted CE
i,i+1
. To obtain fairness in CT P,
B
i+1
initiates Resolution 1 sub-protocol to abort
all subtransactions from the chained transaction.
s
i
is the first subtransaction from the chained
transaction in which B
i
does not send PO
i,i+1
to
B
i+1
and also any evidence to B
i1
. In this case,
B
i1
waits for an evidence from B
i
until the time-
out interval t expires in which case B
i1
initiates
Resolution 2 sub-protocol (case 3) to abort all sub-
transactions from the chained transaction.
s
i
is the first subtransaction from the chained
transaction in which B
i
as initiator does not send
PO
i,i+1
to B
i+1
, but continues as receiver in s
i1
sending PR
i1,i
to PG. In this scenario, the only
case in CTP in that fairness is not insured is when
B
i
receives in s
i1
a successful CE
i1,i
from PG.
ICE-B 2020 - 17th International Conference on e-Business
58
So, B
i
obtains the payment in s
i1
from B
i1
, but
B
i
did not bought in s
i
the product requested by
B
i1
. In this case, B
i
cannot respond in s
i1
to
B
i1
with a valid message (B
i
has a successful
CE
i1,i
, but cannot obtain a successful E
i
). Then,
B
i1
initiates Resolution 2 sub-protocol (case 1) to
abort all subtransactions from the chained transac-
tion.
s
i
is the first subtransaction from the chained
transaction in which B
i
sends PO
i,i+1
to B
i+1
, but
sends PR
i1,i
to PG in s
i1
without waiting for the
evidences from B
i+1
in s
i
. This case is solved as
in the item above.
s
i1
is the first subtransaction from the chained
transaction in which B
i
has received the evidence
CE
i1,i
, and also he has the evidences CE
i,i+1
,
E
i+1
from s
i
. However, B
i
does not send the evi-
dences or sends invalid evidences to B
i1
in s
i1
,
or a network communication error appears and
B
i1
does not receive the evidences from B
i
. In
this case, B
i1
waits for an evidence from B
i
until
the timeout interval t expires in which case B
i1
initiates Resolution 2 sub-protocol (case 1 or case
2) to ensure fairness in CTP.
Provider. In CTP, P can behave dishonest in the
following two scenarios. First, P receives PO
n,n+1
from B
n
, but P does not send PR
n,n+1
to PG. Second,
P receives the evidence from PG in s
n
, but P does not
send the evidence to B
n
or a network communication
error appears and B
n
does not receive the evidence
from P. In both cases, B
n
waits for an evidence from
P until the timeout interval t expires in which case B
n
initiates Resolution 2 sub-protocol to ensure fairness
in CTP.
As we can see, after analysis above considering all
possible scenarios in which the customer, the brokers
or the provider behave dishonest, fairness in CTP is
ensured.
The second requirement to obtain fairness in MC-
CTP is that for any optional transaction from the com-
plex transaction, the chained transactions correspond-
ing to exactly one option successfully finished CTP,
or all chained transactions are aborted. This require-
ment is satisfied in MCCTP from the way in which the
node state corresponding to operator is computed
(Table 5).
The third requirement to obtain fairness in MC-
CTP is that for any aggregate transaction from the
complex transaction, either all chained transactions
belonging to the aggregate transaction successfully
finished CTP, or all are aborted. When we con-
sider aggregate transactions in the complex transac-
tion, only a scenario in which fairness is not en-
sured can occur: the entire aggregate transaction is
not successful, but C has paid for certain products
purchased in the chained transactions that success-
fully finished CTP. To obtain fairness in this case,
the customer’s payment Web segment initiates Ag-
gregateChainsAbort sub-protocol from section 4.4.1
to abort any chained transaction that successfully fin-
ished CTP and that belongs to the unsuccessful aggre-
gate transaction. Thus, any chained transaction which
belongs to the aggregate transaction is aborted, solv-
ing this unfair case.
As a result, fairness exchange of payment for suc-
cessful payment evidence in multi-chained complex
transactions is preserved.
5.3 Timeliness
MCCTP uses CTP. Resolution 1 sub-protocol from
CTP is executed between initiators/receivers and
PG and the communication channels between initia-
tors/receivers and PG are resilient. Also, in CTP, we
have introduced a timeout interval t in which each
initiator waits the payment evidences from the cor-
responding receiver. If t expires and an initiator does
not receive the corresponding payment evidence, then
he initiates Resolution 2 sub-protocol with PG. Fur-
ther, in all cases, Resolution 2 will apply Resolution 1.
So, CTP execution will be finished at a certain finite
point of time. Moreover, if in MCCTP, the Aggregate-
ChainsAbort sub-protocol is executed, then the com-
munication channels used are resilient. As a result,
the execution of MCCTP will be finished at a certain
finite point of time. After the MCCTP finish point, C
received the successful payment evidences if and only
if each of involved chained transaction successfully
finished CTP. Also, after the finish point, C received
the aborted payment evidences if and only if each of
involved chained transaction is aborted. So, after the
MCCTP finish point, the level of fairness achieved
cannot be degraded.
5.4 Non-repudiation
In each chained transaction s
0
s
1
...s
n
executed in
MCCTP, in each subtransaction s
i
, PG stores in its
database the payment request PR
i,i+1
. In the compo-
nent PM
i
from PR
i,i+1
there is included the signature
of B
i
on PI
i
, which proves the involvement of B
i
as
initiator in s
i
. Also, PR
i,i+1
includes the signature of
B
i+1
on Id
i
, B
i
, B
i+1
, PkB
i
and Am
i
, which proves the
involvement of B
i+1
as receiver in s
i
. So, if any of ini-
tiators/receivers tries to deny its involving in MCCTP,
then PG has evidences to prove the contrary.
Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions
59
5.5 Confidentiality
In MCCTP, every message transmitted is hybrid en-
crypted with the public key of the receiver. So, only
the authorized receiver of a message can read the mes-
sage’s content. After execution of any chained trans-
action s
0
s
1
...s
n
, each party B
i
from chain knows in-
formation from s
i1
where B
i
participates as receiver
and from s
i
where B
i
participates as initiator. In ad-
dition to the known information from s
i1
and s
i
, B
i
receives only E
i+1
that ensures him that s
i+1
was suc-
cessful. We remark that from E
i+1
, B
i
obtains the re-
sponse Resp and the fresh random number generated
in s
i+1
, but these can not lead B
i
to determine the iden-
tity of the party that follows B
i+1
in chain. As a result,
MCCTP ensures confidentiality.
6 CONCLUSIONS
In this paper, we proposed an optimistic Fair Ex-
change E-Commerce Protocol for Multi-Chained
Complex Transactions.
Some of the future work on this proposal are dis-
cussed in what follows. First direction is to extend the
proposed protocol with a penalty mechanism applied
to the agents that behaves dishonest. This mechanism
will encourage the agents to behave honestly, other-
wise, their dishonest behavior will not bring benefits
above the impose penalties. As a result, the number
of aborted transactions caused by dishonest behavior
will be reduced. Second direction is to allow one
to many subtransactions between brokers. This will
lead to a more complex business model in which each
broker might perform aggregate, optional or chained
transaction. Third direction is to extend the proposed
protocol to provide anonymity of the customer. This
implies an elaborated infrastructure because an online
TTP is required.
REFERENCES
Alaraj, A. (2012). Fairness in physical products deliv-
ery protocol. International Journal of Computer Net-
works & Communications (IJCNC).
B
ˆ
ırjoveanu, C. V. and B
ˆ
ırjoveanu, M. (2019a). Auto-
mated verification of e-commerce protocols for com-
plex transactions. Communications in Computer and
Information Science.
B
ˆ
ırjoveanu, C. V. and B
ˆ
ırjoveanu, M. (2019b). Multi-
party e-commerce protocol for b2c/b2b applications.
In 16th International Joint Conference on e-Business
and Telecommunications. SCITEPRESS.
Djuric, Z. and Gasevic, D. (2015). Feips: A secure fair-
exchange payment system for internet transactions.
The Computer Journal.
Draper-Gil, G., Ferrer-Gomila, J. L., Hinarejos, M. F., and
Zhou, J. (2013a). An asynchronous optimistic proto-
col for atomic multi-two-party contract signing. The
Computer Journal.
Draper-Gil, G., Zhou, J., Ferrer-Gomila, J. L., and Hinare-
jos, M. F. (2013b). An optimistic fair exchange proto-
col with active intermediaries. International Journal
of Information Security.
Khill, I., Kim, J., Han, I., and Ryou, J. (2001). Multi-party
fair exchange protocol using ring architecture model.
Computers & Security.
Liu, Y. (2009). An optimistic fair protocol for aggregate
exchange. In 2nd International Conference on Future
Information Technology and Management Engineer-
ing. IEEE.
Onieva, J., Zhou, J., Lopez, J., and Carbonell, M. (2004).
Agent-mediated non-repudiation protocols. Elec-
tronic Commerce Research and Applications.
Zhang, N., Shi, Q., and Merabti, M. (2004). A unified ap-
proach to a fair document exchange system. Journal
of Systems and Software.
Zhou, J., Onieva, J. A., and Lopez, J. (2005). Optimised
multi-party certified email protocols. Information
Management & Computer Security Journal.
ICE-B 2020 - 17th International Conference on e-Business
60