Fair Exchange E-Commerce Protocol for Multi-Chained Complex

Transactions

alin V. B

ırjoveanu

and Mirela B

ırjoveanu

Department of Computer Science, “Al.I.Cuza” University of Ias¸i, Ias¸i, Romania

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 certiﬁed 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 ﬁrst solution to the problem mentioned above. Our

protocol is optimistic and provides fairness, timeliness, non-repudiation and conﬁdentiality.

1 INTRODUCTION

In e-commerce was taken into consideration a sig-

niﬁcant type of transaction namely complex trans-

action. Complex transactions are very important as

they allow the customer a great ﬂexibility 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 fulﬁll 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 deﬁne 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

ı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 certiﬁed 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

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

ﬁrst 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 conﬁdentiality.

The paper is structured as follows: section 2

presents use cases of our protocol, section 3 deﬁnes

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 ﬁt.

Anyhow, in both options, he would like a white car-

pet and white curtains. So, he speciﬁes 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

ﬁrst 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 ﬁrst 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

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 conﬁdentiality.

These requirements are also stated and analyzed in

ı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-

ﬁned 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

ﬁnished at a certain ﬁnite point of time, and after the

protocol’s ﬁnish 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.

Conﬁdentiality 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 identiﬁed: 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 initiator’s

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

Table 1: Notations used in the protocol description.

Notation Interpretation

C, PG, P

, B

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}

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 certiﬁ-

cates for the public keys of PG and of each receiver he

communicates with. Also, each receiver/PG has the

digital certiﬁcate 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

,...,B

and the provider P is

a sequence of subtransactions s

...s

, where C is

the initiator in s

, B

is receiver in s

i−1

and initiator

in s

, with 1 ≤ i ≤ n, and P is receiver in s

. In such

a chained transaction, C knows only the identity of

the broker he communicates with in the subtransac-

tion s

, because C participates only in s

. Also, B

knows only the identities of the agents from the sub-

transactions s

i−1

and s

in which he participates, and

P knows only the identity of the broker B

C initiates CT P by sending to B

a purchase order

for buying a certain physical product. To fulﬁll C’s

request, B

initiates a new subtransaction by send-

ing a purchase order to B

. In the same manner, B

initiates a new subtransaction with B

, and so on un-

til B

initiates a new subtransaction with P. In this

step, n+1 subtransactions s

,...,s

are started be-

longing to the chained transaction s

...s

. The suc-

cessful ﬁnish of the entire chained transaction starts

successfully ﬁnishing the subtransaction s

, s

n−1

, un-

til successfully ﬁnishing s

. Successful ﬁnish of s

means that B

as initiator received from P the suc-

cessful payment evidence for product, and P received

the payment from B

. Only after successful ﬁnish of

, B

sends as receiver in s

n−1

the payment request to

PG. Successful ﬁnish of s

n−1

means that B

received

the payment from B

n−1

, and B

n−1

received from B

two successful evidences: the current payment evi-

dence of B

n−1

and B

in s

n−1

, and the past payment

evidence of B

in s

. In this manner, any subtransac-

tion s

from chain is successfully ﬁnished only after

the successful ﬁnish of s

i+1

,...,s

subtransactions.

CTP for a chained transaction s

...s

con-

sists of the Exchange sub-protocol for each chained

subtransaction s

, and two Resolution sub-protocols.

ICE-B 2020 - 17th International Conference on e-Business

Next, we will describe the CTP’s sub-protocols.

4.3.1 Exchange Sub-protocol

In this section, we will describe the Exchange sub-

protocol for an arbitrary subtransaction s

, where 0 ≤

i ≤ n, that is presented in Table 3. The notations used

in CTP are provided in Table 2. In the subtransaction

, the payment Web segment of the initiator B

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

and the order in-

formation OI

both encrypted with PkB

i+1

. PM

build by B

’s payment Web segment by encrypting

with PG’s public key the payment information PI

and the signature of B

on PI

contains the data provided by user as initiator:

card number CardN

and a challenge code CCode

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

from chained

transaction, the payment Web segment of B

gener-

ates a fresh random number N

. The identiﬁer Id

is built by concatenating the identiﬁer Id

i−1

of s

i−1

with N

. So, the identiﬁer Id

of s

is the sequence

of numbers N

...N

generated in all subtransac-

tions of s

,...,s

. This way of assigning identiﬁers

to subtransactions allows tracing the subtransactions

from the chained transaction. Thus, in case of a latter

dispute, the identiﬁcation of the subtransactions from

chain is done in a simple manner. Also, PI

includes

the identiﬁer Id

, the amount Am

, and PkB

contains the identity of the initiator B

, of the

receiver B

i+1

, the product identiﬁer Pid, the subtrans-

action identiﬁer Id

, the amount Am

, and PkB

In each subtransaction s

, the receiver decrypts

i,i+1

and checks the signature of the initiator on

. 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

At the line 2, if the receiver B

i+1

is the provider P

(i = n), then s

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

. PR

i,i+1

built from the payment message PM

and B

i+1

’s sig-

nature on the subtransaction identiﬁer Id

, the iden-

tity of the initiator B

, of the receiver B

i+1

, PkB

and Am

. Upon receiving PR

i,i+1

, PG decrypts it,

checks B

’s signature on PI

and checks if B

is au-

thorized to use the card by checking if the combina-

tion of CardN

and CCode

is valid. If these checks

are successfully passed, then also B

proves as being

the owner of the public key PkB

. PG checks B

i+1

’s

signature, and if checking is successful, then it has

the conﬁrmation that both B

and B

i+1

agreed on Id

PkB

and Am

. 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

’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

the line 3. Otherwise, if checking B

’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

’s abortion. We remark that the current

evidence CE

i,i+1

in s

includes the evidence E

that

will be latter send by B

to B

i−1

to inform B

i−1

if s

was successfully ﬁnished or aborted. Also, PG stores

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

(line

4) the current evidence CE

i,i+1

and the provider cer-

tiﬁcate Cert

both encrypted with PkB

. B

decrypts

the message received from B

i+1

, and checks the au-

thenticity of Cert

and CE

i,i+1

. If PG’s signature from

i,i+1

is successfully checked, then B

has the guar-

antee of CE

i,i+1

’s authenticity and it corresponds to

the current subtransaction s

because of the presence

of the identiﬁer Id

In each subtransaction s

that is not the last from

chain (i < n), in order to answer the request received

from the initiator B

, the receiver B

i+1

must ensure

that either all the subtransactions that follows s

chain have been successfully completed, or all the

subtransactions that follows s

in chain have been

aborted. An arbitrary subtransaction s

is success-

ful if the receiver B

j+1

received the payment and

received the successful current payment evidence

j, j+1

and payment evidence E

j+1

. s

is aborted if

the receiver B

j+1

did not received the payment and B

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

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

i+1

i+2

,...,s

are successfully ﬁnished. In this case,

i+1

sends PR

i,i+1

to PG in s

at line 8.

If B

i+1

receives from PG (line 9) a successful

i,i+1

, then he sends CE

i,i+1

and E

i+1

to B

(line 11).

veriﬁes evidence’s authenticity by checking PG’s

signatures, checks the corresponding identiﬁers 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

that s

was successful and E

i+1

ensures B

that s

i+1

was successful. B

will use E

in s

i−1

in the same man-

Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions

Table 2: Notations used in CTP.

i,i+1

= {PM

, OI

, SigB

(OI

)}

PkB

i+1

Purchase Order of B

to B

i+1

= {PI

, SigB

(PI

)}

PkPG

and PI

= B

, CardN

, CCode

, Id

, Am

, PkB

, B

i+1

= B

, B

i+1

, Pid, Id

, Am

, PkB

= Id

i−1

(If i = 0, then Id

i−1

is the empty string)

i,i+1

= {PM

, SigB

i+1

(Id

, B

i+1

, PkB

, Am

)}

PkPG

Payment Request of B

i+1

to get payment from B

i,i+1

= Resp, B

, B

i+1

, Id

, SigPG(Resp, B

, B

i+1

, Id

, Am

), E

Current Payment Evidence of B

and B

i+1

in s

= Resp, Id

, SigPG(Resp, Id

) Payment Evidence in s

that B

sends to B

i−1

i,i+1

.Resp/E

.Resp The response Resp in CE

i,i+1

Table 3: Exchange sub-protocol for the subtransaction s

1. B

→ 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

: {CE

i,i+1

, Cert

}

PkB

5. else

6. if (B

i+2

→ B

i+1

: {CE

i+1,i+2

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

: {CE

i,i+1

i+1

}

PkB

12. else Resolution 1

13. end if

14. else if (B

i+2

→ B

i+1

: {CE

i+1,i+2

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

denotes the customer C. If i = n, then

i+1

denotes P, and E

i+1

is replaced with Cert

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

i+1

receives from B

i+2

a successful CE

i+1,i+2

, but

i+2

is missing or aborted, then Resolution 2 sub-

protocol is applied (line 16) to obtain a successful

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

ﬁnished, 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

from chain the initiator B

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

, where 0 ≤ i ≤ n, the ﬁrst subtransaction (in

reverse order: from s

to s

) from the chained trans-

action s

...s

in which B

i+1

receives from PG an

aborted CE

i,i+1

and forwards it to B

. If s

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

are successful, and s

is aborted due

to aborted CE

i,i+1

. If s

is the last subtransaction from

chain (i = n), then s

is aborted, and also the sub-

transactions s

n−1

,...,s

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

from chain.

If s

is not the last subtransaction from chain, then

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

and the successful CE

i+1,i+2

in s

i+1

. PG veri-

ﬁes evidence’s authenticity by checking his signatures

and checks the corresponding identiﬁers 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

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 ﬁrst for loop aborts in a

similar manner s

i+2

,...,s

, each iteration aborting a

new subtransaction from chain until aborting s

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

follows:

1. E

i+1

= SigPG(ABORT, Id

i+1

, E

i+1

)

2. CE

i+1,i+2

= ABORT,B

i+1

i+2

,Id

i+1

,SigPG(ABORT,

i+1

i+2

,Id

i+1

,Am

i+1

,CE

i+1,i+2

),E

i+1

The second for loop aborts s

i−1

,...,s

in this or-

der. In the ﬁrst iteration, B

sends to PG a request to

abort s

i−1

. The request contains the aborted CE

i,i+1

in s

and the content of PO

i−1,i

received by B

i−1

. PG veriﬁes evidence’s authenticity by checking

his signature and PO

i−1,i

’s authenticity by checking

ICE-B 2020 - 17th International Conference on e-Business

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)

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)

→ PG : {CE

j, j+1

,PM

j−1

,OI

j−1

,Sig

j−1

(OI

j−1

)}

PkPG

PG → B

: {CE

j−1, j

}

PkB

PG → B

j−1

: {CE

j−1, j

}

PkB

j−1

end for

the B

i−1

’s signatures. Also, PG veriﬁes the corre-

sponding identiﬁers from CE

i,i+1

and PO

i−1,i

to en-

sure that these belong to successive subtransactions.

If all checks are passed, PG generates an aborted ev-

idence CE

i−1,i

and sends it to B

and B

i−1

as a proof

of aborting s

i−1

. Each iteration continues in a simi-

lar manner aborting a new subtransaction from chain

until aborting s

4.3.3 Resolution 2 Sub-protocol

Let be s

, where 0 ≤ i ≤ n, the ﬁrst subtransaction (in

reverse order: from s

to s

) from the chained transac-

tion s

...s

in which B

sends PO

i,i+1

to B

i+1

, but

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

from chain, a

timeout interval t (e.g. in the order of seconds or

minutes) is deﬁned, in which B

waits a payment evi-

dence from B

i+1

. If t expires and B

does not receive a

payment evidence or receives an invalid payment ev-

idence from B

i+1

, then B

initiates Resolution 2 with

PG to receive a payment evidence w.r.t. s

and to ob-

tain fairness in CTP. B

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.

→ PG : {PM

, OI

, R, SigB

(OI

, R)}

PkPG

PG decrypts the message, checks B

’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

, Am

and PkB

, as follows:

1. If PG ﬁnds in its database the successful CE

i,i+1

for the entry above, then PG requires E

i+1

from

i+1

. If B

i+1

responds to PG with a successful

i+1

, then PG sends it to B

and CTP continues

with s

i−1

. Otherwise, if B

i+1

responds with an

aborted E

i+1

or does not respond, then PG gener-

ates the aborted

i,i+1

and sends it to B

and B

i+1

as a proof of aborting s

. Now, Resolution 1 is ap-

plied to abort s

i+1

,...,s

if these are successful,

and also to abort s

i−1

,...,s

2. If PG ﬁnds in its database the aborted CE

i,i+1

for

the entry above, then PG sends CE

i,i+1

to B

and

i+1

as a proof of aborting s

. Resolution 1 is ap-

plied as in item 1.

3. If PG does not ﬁnd an evidence for the entry

above, then PG generates the aborted evidence

i,i+1

and sends it to B

and B

i+1

as a proof of

aborting s

. Resolution 1 is applied as in item 1.

If R contains a successful CE

i,i+1

but a successful

i+1

is missing, then PG requires E

i+1

and CTP

continues as in item 1.

A chained transaction s

...s

successfully ﬁn-

ished CTP if all subtransactions s

, where 0 ≤ i ≤ n,

are successfully ﬁnished (B

receives the successful

i,i+1

and E

and B

i+1

receives the payment for

the corresponding product). A chained transaction

...s

is aborted if all subtransactions s

, where

0 ≤ i ≤ n, are aborted (B

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 ﬁnished CTP, or is aborted.

Example. In Figure 1, we describe an instance of

CTP considering a customer C = B

, two brokers B

and a provider B

= P. In this example, C knows

only B

, B

knows only C and B

, B

knows only B

and P and P knows only B

. The chained transac-

tion is the sequence of the subtransactions s

. In

, C initiates CTP by sending P

0,1

to B

for buying

a certain physical product. To acquire the product

requested by C in s

, the broker B

initiates a new

subtransaction s

by sending PO

1,2

to B

. Also, to

acquire the product requested by B

, B

initiates s

by sending PO

2,3

to P. s

is the last subtransaction

from the chain because the receiver in s

is P. So, P

sends PR

2,3

to PG to get the payment for his prod-

uct from B

. After PG successfully veriﬁes PR

2,3

he sends to P the successful CE

2,3

. To complete s

P sends to B

the successful CE

2,3

and Cert

. After

receiving message 6, B

is ensured that s

is success-

fully ﬁnished. In this step, B

continues s

(in which

he is the receiver) by sending in message 7, PR

1,2

PG that responds to him with a successful CE

1,2

. To

complete s

, B

sends to B

the successful CE

1,2

and

. The successful CE

1,2

ensures B

that s

success-

fully ﬁnished and the successful E

ensures B

that

successfully ﬁnished. In this step, B

continues s

by sending the message 10 to PG. After B

obtains

Fair Exchange E-Commerce Protocol for Multi-Chained Complex Transactions

C=B

1.PO

0,1

2.PO

1,2

3.PO

2,3

12.{CE

0,1

}

PkB0

10.PR

0,1

11.{CE

0,1

}

PkB

9.{CE

1,2

}

PkB1

7.PR

1,2

8.{CE

1,2

}

PkB

6.{CE

2,3

,Cert

}

PkB2

4.PR

2,3

5.{CE

2,3

}

PkB

subtransaction s

Figure 1: CTP message ﬂow.

successful CE

0,1

, he sends CE

0,1

and E

to C. If C

obtains the successful CE

0,1

and E

, then the chained

transaction is successful. So, in each subtransaction

, the initiator B

obtains the successful current evi-

dence and the receiver B

i+1

obtains the payment.

On the other side, for example, if s

was success-

fully ﬁnished and in s

the broker B

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

initiates Resolution 1 sub-protocol with PG to abort

and s

. 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 deﬁned as follows: Pid

∧

... ∧ Pid

meaning that C wishes to buy exactly k

products with product’s identiﬁers Pid

,...,Pid

. For

an optional transaction, the option operator, denoted

by ∨, is deﬁned as follows: Pid

∨ . . . ∨ Pid

meaning

that C wishes to buy a product that is exactly one of

the products with product’s identiﬁers Pid

,...,Pid

where the apparition order of the product’s identiﬁers

is the priority given by C. This means that C wishes

ﬁrst of all to buy the product Pid

, but if this is not

possible, his second option is Pid

, and so on.

From the choices of C describing the sequence of

products he wishes to buy, we build a tree over the

product identiﬁers 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-

ﬁer, while each leaf node corresponds to an identiﬁer.

Each node of the tree is represented by a structure

with the following ﬁelds: info for storing the useful

information (identiﬁer 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

corresponds to RC, Pid

to RT, Pid

to RP,

Pid

to modern armchairs, Pid

to steel table, Pid

to abstract painting, Pid

to white carpet and Pid

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

and Pid

In the multi-chained complex transactions proto-

col we proposed, a chained transaction ct, denoted

by CTP(C, B

,Pid

), is an instance of CTP in which

C buys the physical product with Pid

identiﬁer from

the broker B

using many other brokers and a provider.

We deﬁne St(ct) the state of the chained transaction ct

as being the current evidence CE

0,i

that C will receive

in ct.

We deﬁne Ns(p) - the state of the node p as a se-

quence of chained transaction states St(ct

)...St(ct

)

corresponding to the product deﬁned by p. For a node

p, Ns(p) is calculated similarly as in (B

ırjoveanu and

ırjoveanu, 2019a), depending on p → info as fol-

lows:

• if p → info = Pid

, where 1 ≤ i ≤ n, then Ns(p) =

St(CTP(C,B

,Pid

)). For simplicity, we consider

that B

sells the product with Pid

identiﬁer.

• 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

• if p → info = ∧, and c

,...,c

are all children of

p, then we have two cases:

1. if St(ct).Resp = Y ES, for any St(ct) from

Ns(c

), for any 1 ≤ j ≤ k, then Ns(p) =

Ns(c

)...Ns(c

2. otherwise, let be c

, where 1 ≤ j ≤ k,

the leftmost child of p with Ns(c

) =

St(ct

)...St(ct

) such that St.(ct

).Resp =

ABORT , for all 1 ≤ l ≤ m. In this case, Ns(p) =

Ns(c

)...Ns(c

Thus, Ns(p) contains a sequence of chained trans-

action states in which either all chained transactions

successfully ﬁnished 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-ﬁrst 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 identiﬁer 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

)...St(ct

)St(ct

k+1

)...St(ct

where St(ct

).Resp = Y ES for any 1 ≤ i ≤ k and

St(ct

).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 ﬁnished CTP.

C → PG : {Ns(p), SigC(Ns(p))}

PkPG

The customer request is build from Ns(p) and C’s

signature on Ns(p), both encrypted with PkPG.

PG decrypts the customer’s request, obtains the se-

quence of chained transaction states St(ct

)...St(ct

)

in Ns(p), and checks C’s signature on Ns(p). For

each St(ct

) ∈ Ns(p), PG searches into its database the

appropriate entry, and if it ﬁnds 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

= CT P(C,B

,Pid

) =

...s

such that St(ct

) ∈ Ns(p) and St(ct

).Resp =

Y ES will be aborted as follows:

1. The bank cancels the transfer corresponding to s

from C’s account into B

’s account, and generates

St(ct

) as in Resolution 1 sub-protocol.

2. After receiving St(ct

) from the bank, PG sends it

to C and B

as a proof of s

’s abortion.

3. s

,..., s

, in this order, will be aborted by apply-

ing the same technique as in Resolution 1 sub-

protocol (B

requires and obtains from PG abor-

tion of s

, and so on, the last broker from chain

requires and obtains from PG abortion of s

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 ﬁn-

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 satisﬁed. 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

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

) Ns(t) = St(CTP(C,B

,Pid

)); 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

, but a network com-

munication error appears and B

does not receive the

message from C, then C will not receive any payment

evidence from B

. If we consider only the current

chained transaction, then this is not an unfair case.

However, the state of this chained transaction is unde-

ﬁned, 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 deﬁned state (successful or

aborted). So, in this case, C waits for an evidence

from B

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 insufﬁcient, 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

,Pid

) = s

...s

, s

is the ﬁrst aborted

subtransaction (in the reverse order: from s

to s

) in

which B

receives from PG an aborted CE

0,i

. In this

case, s

,...,s

are successful, and to obtain fairness

in CT P, B

initiates Resolution 1 sub-protocol. After

Resolution 1, all subtransactions from ct are aborted,

so fairness is ensured.

Broker. If s

is the ﬁrst subtransaction from a

chained transaction s

...s

, in which B

i+1

does not

receive PO

i,i+1

from B

because of a network com-

munication error, then B

will not receive any pay-

ment evidence from B

i+1

. By the same reasoning as

in C’s case, B

waits for an evidence from B

i+1

until

the timeout interval t expires in which case B

initiates

Resolution 2 sub-protocol to abort the current chained

transaction.

We detail below all scenarios in which a broker B

can behave dishonest in CTP:

• In s

, B

wants to buy from B

i+1

a product and

his account balance is insufﬁcient, or B

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

is the ﬁrst sub-

transaction (in the reverse order) from the chained

transaction s

...s

, in which B

i+1

receives from

PG an aborted CE

i,i+1

. To obtain fairness in CT P,

i+1

initiates Resolution 1 sub-protocol to abort

all subtransactions from the chained transaction.

• s

is the ﬁrst subtransaction from the chained

transaction in which B

does not send PO

i,i+1

i+1

and also any evidence to B

i−1

. In this case,

i−1

waits for an evidence from B

until the time-

out interval t expires in which case B

i−1

initiates

Resolution 2 sub-protocol (case 3) to abort all sub-

transactions from the chained transaction.

• s

is the ﬁrst subtransaction from the chained

transaction in which B

as initiator does not send

i,i+1

to B

i+1

, but continues as receiver in s

i−1

sending PR

i−1,i

to PG. In this scenario, the only

case in CTP in that fairness is not insured is when

receives in s

i−1

a successful CE

i−1,i

from PG.

ICE-B 2020 - 17th International Conference on e-Business

So, B

obtains the payment in s

i−1

from B

i−1

, but

did not bought in s

the product requested by

i−1

. In this case, B

cannot respond in s

i−1

with a valid message (B

has a successful

i−1,i

, but cannot obtain a successful E

). Then,

i−1

initiates Resolution 2 sub-protocol (case 1) to

abort all subtransactions from the chained transac-

tion.

• s

is the ﬁrst subtransaction from the chained

transaction in which B

sends PO

i,i+1

to B

i+1

, but

sends PR

i−1,i

to PG in s

i−1

without waiting for the

evidences from B

i+1

in s

. This case is solved as

in the item above.

• s

i−1

is the ﬁrst subtransaction from the chained

transaction in which B

has received the evidence

i−1,i

, and also he has the evidences CE

i,i+1

i+1

from s

. However, B

does not send the evi-

dences or sends invalid evidences to B

i−1

in s

i−1

or a network communication error appears and

i−1

does not receive the evidences from B

. In

this case, B

i−1

waits for an evidence from B

until

the timeout interval t expires in which case B

i−1

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

, but P does not send PR

n,n+1

to PG. Second,

P receives the evidence from PG in s

, but P does not

send the evidence to B

or a network communication

error appears and B

does not receive the evidence

from P. In both cases, B

waits for an evidence from

P until the timeout interval t expires in which case B

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 ﬁnished CTP,

or all chained transactions are aborted. This require-

ment is satisﬁed 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

ﬁnished 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 ﬁnished 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 ﬁn-

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 ﬁnished at a certain ﬁnite

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 ﬁnished at a certain

ﬁnite point of time. After the MCCTP ﬁnish point, C

received the successful payment evidences if and only

if each of involved chained transaction successfully

ﬁnished CTP. Also, after the ﬁnish point, C received

the aborted payment evidences if and only if each of

involved chained transaction is aborted. So, after the

MCCTP ﬁnish point, the level of fairness achieved

cannot be degraded.

5.4 Non-repudiation

In each chained transaction s

...s

executed in

MCCTP, in each subtransaction s

, PG stores in its

database the payment request PR

i,i+1

. In the compo-

nent PM

from PR

i,i+1

there is included the signature

of B

on PI

, which proves the involvement of B

initiator in s

. Also, PR

i,i+1

includes the signature of

i+1

on Id

, B

i+1

, PkB

and Am

, which proves the

involvement of B

i+1

as receiver in s

. 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

5.5 Conﬁdentiality

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

...s

, each party B

from chain knows in-

formation from s

i−1

where B

participates as receiver

and from s

where B

participates as initiator. In ad-

dition to the known information from s

i−1

and s

, B

receives only E

i+1

that ensures him that s

i+1

was suc-

cessful. We remark that from E

i+1

, B

obtains the re-

sponse Resp and the fresh random number generated

in s

i+1

, but these can not lead B

to determine the iden-

tity of the party that follows B

i+1

in chain. As a result,

MCCTP ensures conﬁdentiality.

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 beneﬁts

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

ırjoveanu, C. V. and B

ırjoveanu, M. (2019a). Auto-

mated veriﬁcation of e-commerce protocols for com-

plex transactions. Communications in Computer and

Information Science.

ı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 uniﬁed 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 certiﬁed email protocols. Information

Management & Computer Security Journal.

ICE-B 2020 - 17th International Conference on e-Business