An Optimistic Fair Exchange E-commerce Protocol for Complex

Transactions

C˘at˘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

cbirjoveanu@info.uaic.ro, mbirjoveanu@gmail.com

Keywords:

Electronic Commerce Security, Complex Transactions, Fair Exchange, Security Protocols.

Abstract:

In this paper, we deﬁne the concept of complex transaction as a combination i n any form of aggregate and

optional transactions. Even if there are many multi-party fair exchange protocols with applications in buying

digital goods, digital signature of contracts and certiﬁed e-mail , no one can be used to solve our problem:

complex transactions where a customer wants to buy several physical products from different merchants, pro-

viding fair exchange while preserving atomicity. In this paper, we propose the ﬁrst fair exchange e-commerce

protocol for complex transactions in that the customer wants to buy several different physical products from

different merchants. Our protocol uses as building block the fair exchange internet payment protocol (FEIPS)

for physical products that considers only one customer and one merchant. Also, our protocol provides effecti-

veness, timeliness, non-repudiation, integrity and conﬁdentiality of data exchanged between the parties.

1 INTRODUCTION

In order to assure security, e-commerce protocols

must satisfy some fundamental requirements: conﬁ-

dentiality, authentication and non -re pudiation. Now-

days, in the electronic commerce, it is usually that a

customer wishes to buy a pack of products/services

composed of several products (physical or digi-

tal)/services from different merchants. In this type of

e-commerce transactions, the customer is interested

in buying all products fr om the pack or no product

at all, namely aggregate/atomic transactions. For

ﬂexibility, in the optional transactions, the customer

wants to buy exactly one produ c t from many mer-

chants, and for this, he speciﬁes in his request more

possible products according to his preferences but

from this options only one will be committed. We

will refer to the combination in any form of ag gregate

and optional transactio ns as complex transactions.

In e-commerce protocols, fair exchange is anoth e r

essential property. For complex transactions, an e-

commerce protocol in that a customer wishes to buy

many products from different merchants assures fair

exchange if:

• for any optional tran saction from the complex

transaction, the customer obtains exactly one di-

gital receipt for the product’s payment, and

• for any aggregate transaction from the complex

transaction, the custo mer obtains the digital re-

ceipts for the pay ments of all pro ducts,

and each merchant obtains the corresponding pay-

ment for the prod uct, or non e of them obtains no-

thing. In a complex transaction , the issues that can

appear are when in a aggregate transaction so me pro-

ducts can be successfully acquired, but the others not,

or when in an optional transaction more than one pro-

duct is successfully acquired. In this cases, even if

each corresponding merchant gets the payment for his

product, fair exchange is not ensured.

To achieve fair exchang e, the proposed protocols

are based on a Trusted Third Party (TTP) that can be

inline, on line or ofﬂine. The protocols that are based

on inline TTP (that is used in every message) or on

online TTP (that is used in every protoco l instance)

are not efﬁcient because TTP becomes a bottleneck.

Using ofﬂine TTP (that is involved in a protocol in-

stance only when a n exception appea rs) removes the

disadvantage mentioned above. One goal of our pro -

tocol is to o btain the fair-exchange requirement in

complex transactions using an ofﬂine TTP.

In the literature there are many e -commerce pro-

tocols that consider only one customer an d one me r-

chant, mo st of them for buying digital products and

only few for buying physical products.

Even if there are many multi-party fair exchange

V. Bîrjoveanu C. and Bîrjoveanu M.

Optimistic

Fair

Exchange

E-commerce

Protocol

for

Complex

Transactions.

DOI:

10.5220/0006853501110122

Proceedings

the

15th

International

Joint

Conference

e-Business

and

Telecommunications

(SECRYPT

2018),

pages

111-122

ISBN:

978-989-758-319-3

111

protocols with applications in buying digital goods,

digital signature of contracts and certiﬁed e-mail, no

one can be used to solve our problem : complex tran-

sactions wh e re a customer wants to buy several physi-

cal products from different merchants, providin g fair

exchange.

Our Contribution. In this paper, we propo se the

ﬁrst fair exchang e e-commerce protocol for complex

transactions in that the customer wants to buy several

different physical products from different merchants.

Our protoc ol uses as building block the fair exchange

internet payment protocol (FEIPS) for physical pro-

ducts proposed in (Djuric and Gasevic, 2015). The

FEIPS protocol considers only one custo mer and one

merchan t. In our scenario, a complex transaction is

a combination in any f orm of aggregate and optional

transactions. Also, our protocol provid es effective-

ness, timeliness, non-repudiation, integrity and co nﬁ-

dentiality of data exchanged between the parties.

The paper is structured as follows: section 2 gives

application examples of our protocol, section 3 deﬁ-

nes secur ity requirements. Section 4 discusses related

work, section 5 brieﬂy presents the FEIPS protocol.

Our protoc ol is presented in section 6. Section 7 con-

tains the security analysis of the proposed protocol.

A comparative analysis is provid ed in section 8 and

section 9 contains the conclusion.

2 APPLICATIONS TO B2B/B2C

SCENARIOS

Our protocol has use cases in Business to Consumer

(B2C) and Business to Business (B2B) scenarios. For

a B2B scenario, the customer is the Electron c ompany

that manufactures electron ic board s for different pur-

poses, on request from his clients. To plan its busi-

ness, Electron uses an online catalog from where it

can buy several ele ctronic components from different

merchan ts denoted by M1, M2, M3, e. t.c. From the

online catalog, Electron can select products like: re-

sistors (R), capacitors (C), integrated circuits (IC), ca-

bles, conn e ctors, printed cir cuit boards (PCB) and so

on. Electron wants to start the production of a new

electronic board and therefore wants to prepare its or-

der in form of an e-commerce c omplex transaction as

follows: (100R of 10kΩ from M1 or 70R of 20kΩ

from M2) an d (5 0C of 100mF from M3 or 100C of

70mF from M4) and 70 connecto rs DB35 type from

M5 and 30PCB from the M6. The complex tran-

saction is composed from an aggregate transaction

and two optional transactions. For the ﬁrst optional

transaction if Electron can no t acquire 100R of 10kΩ

from M1 due to lack of stock or delay in delivery

time, then its second option is taken into considera-

tion to acquire 70R of 20kΩ from M2. To start the

production, Electron needs all types of componen ts

speciﬁed in its request, so a partial combination (e.g.

100R of 10kΩ, 100C of 70mF and 30PCB, but wit-

hout 70 connectors D B35 type) is not useful for him.

For an optional transaction, Electron must not acquire

more then one product (e.g. for the ﬁrst optional tran-

saction he must not acquire both 100R of 10 kΩ and

70R of 20kΩ) because th en he will remain with un-

necessary pr oducts. For example, a pack of products

that solves the customer’s option s is: 100R of 10kΩ,

and 100C of 70mF, and 70 connectors DB35 type and

30PCB.

A similar scenario can be used in B2C applicati-

ons. In this case, the customer is a person that likes

electronics and wants to build an electronic hobby kit,

and for this he uses the onlin e catalog to order the nee-

ded components.

3 SECURITY REQUIREMENTS

In what follows, we will discuss the security requi-

rements we want to achieve in our optim istic fair ex-

change protocol for complex transactions: effective-

ness, fairness, timeliness, non-repudiation and conﬁ-

dentiality. These requir ements are stated and analy-

zed in (Ferrer-Gomila et al., 2010), (Liu et al. , 2011)

for certiﬁed electronic mail protocols, (Draper-Gil

et al., 2013) for contract signing protocols, and (Dju-

ric and Gasevic, 2015) f or electron ic payment proto-

cols for physical produc ts.

Effectiveness requires that if every party involved

in the complex transactions protocol behaves hone-

stly, does not want to prematurely terminate the pro-

tocol, and no communication error occurs, then the

customer receives his expected digital receipts from

merchan ts, and the merchants receive their payments

from the customer, witho ut any intervention of Trus-

ted Third Party (TTP). This is a requireme nt for op-

timistic protocols, where TTP intervenes only in case

of unexpected situations, such as a network com mu-

nication errors or dishonest behavior of one party.

Fairness for complex transactions requires:

• for any optional transaction from the comp lex

transaction, the customer obtains exactly one di-

gital receipt for the product’s payment, and

• for any aggregate transaction from the complex

transaction, the custo mer obtains the digital re-

ceipts for the pay ments of all pro ducts,

and each merchant obtains the corresponding pay-

ment for the pro duct, or none of them obtains nothing.

SECRYPT 2018 - International Conference on Security and Cryptography

112

This requirement corresponds to the strong fairn ess

requirement stated in (Asokan, 1998).

Timeliness requires that any party involved in the

complex transactions proto col ca n be sure that the

protocol execution will be ﬁnished at a certain ﬁnite

point of time, and that after the protocol ﬁnish point

the level o f fairne ss achieved cannot be degrade d.

Non-repudiation in the complex transaction pro-

tocol requires that neither the custome r nor any of

merchan ts can deny their involvement in the complex

transaction.

Conﬁdentiality in the complex transaction proto-

col re quires that the content of messages sent between

participating parties is accessible only to authorized

parties.

4 RELATED WORK

Until now there a re protocols proposed for the pa y-

ment for physical products, that provide fair exchange

and consider only one customer and one merchant

(Birjoveanu, 2 015),(Djuric and Gasevic, 2015),(Ala-

raj, 2012),(Li et al., 2006),(Zhang et al., 2006).

There are known many multi-party fair exchange

protocols proposed with applications in e-commerce

transactions for buying digital goods (Liu, 2009), di-

gital signature of contracts (Draper-Gil et al., 2013 ),

(Mukha medov and Ryan, 2008), ce rtiﬁed e-mail

(Zhou et al., 2005) and non-repudiation (Yanping and

Liaojun, 2009), (Onieva et al., 200 9). Despite great

variety of multi-party fair exchange protocols propo-

sed u ntil now, there is no solution to address our pro-

blem: com plex transactions where a customer wants

to buy several physical products from different mer-

chants, providin g fair exchange.

From a ll solutions for multi-party fair exchange,

we distinguish some of them (Liu, 2009), (Draper-

Gil et al., 2013), (Yanping and L ia ojun, 2009) that

solve related problems with our problem, but in other

scenarios.

The scenario most clo sest to our scenario is the

one proposed by (Liu, 2009), where in an aggregate

transaction a customer wants to buy several digital

products from different merchants. The solu tion from

(Liu, 2009) can not be applied to our problem because

in our problem we want to obtain fair exchange bet-

ween payments for physical products and digital re-

ceipts for physical pro ducts. Also, in (Liu, 2009) are

taken into consid eration only ag gregate transaction s,

but optional transactions are not considered, and ti-

meliness requirement is no t assured.

In (Draper-Gil et al., 2013), a multi-two party con-

tract signing protocol is proposed, where a consumer

and many providers want to sign a contract pairwise.

The solution from (Draper-Gil et al., 2013) assure s

weak fairn e ss and can not be applied to our problem

because it is applied in a contract signing scenario that

is different from our scenario. Weak fairness requires

that all parties receive the expected items, or all ho-

nest parties will have enough evidence to prove that

they have behaved correctly in front of an arbiter.

In (Yanping and Liaojun, 2009), an optimis-

tic multi-party non-repudiation p rotocol is proposed,

which allows the sender to exchange different messa-

ges with multiple recipients for non-repudiation evi-

dences. The solution from (Yanping and Liao jun,

2009) can not be ap plied to our problem because it

does not take into consideration atomicity an d is ap-

plied in a non-repudiation scenario, while our scena-

rio requires atomicity and fair exchange between pay-

ments for physical produ cts and digital receipts for

physical products.

As a result, from all known solutions for multi-

party fair exchange problems related with our pro-

blem, no one can be applied to solve o ur problem.

5 THE FEIPS PROTOCOL

Our protocol is based on the fair exchange internet

paymen t protocol (FEIPS) for the payment of physi-

cal products, pro posed in ( D juric and Gasevic, 2015),

that is why we br ie ﬂy descr ibe it. This protocol consi-

ders only one customer and one merchant. The FEIPS

protocol involves the customer (the payment Web seg-

ment), the merchant, the payment gateway and the

bank.

The payment Web segment is a soft digitally sig-

ned by payment gateway an d it is automatically down-

loaded b y customer from merchant before the proto-

col execution. The role of the p ayment Web segment

is to perform customer’s side protocol actions.

The FEIPS protoc ol consists of three sub-

protocols: the setup sub-protocol, the exchange sub-

protocol and the resolution sub-protocol. All me ssa-

ges transmitted in protocol are protected using hybrid

encryp tion. In the setup sub -protocol, the cu stomer

sends his session public key to the merchant, that re-

plies with an unique identiﬁer of the transaction. In

the exch ange sub-protocol, the customer sends to the

merchan t a payment message encrypted with the pay-

ment gateway’s public key and the purchase order. If

the merchant a grees with the order received from the

customer, then he sends the payment message to the

paymen t gateway. On reception of the payment mes-

sage, the payment gateway decrypts it, veriﬁes the

paymen t info rmation and if the customer is autho ri-

An Optimistic Fair Exchange E-commerce Protocol for Complex Transactions

113

zed to use the card. If all checks are su ccessfully, the

paymen t gateway sends the payment message to the

bank. Depending on the customer’s account balance,

the bank makes or not the transfer a nd provides an

appropriate response to the payment gateway that for-

wards it to the mer c hant. Finally, the merchant sends

the response to the c ustomer. The response is digi-

tally signed by the payment gateway and it means the

digital receipt of the payment for the ord ered product.

The fair exchange in the FEIPS protoco l is deﬁned

w.r.t. exchange of electronic payment for a digital

receipt. The resolution sub-protocol is used to pro-

vide fair exchange for cases in that the customer pays,

but he does not receive the digital receipt because the

merchan t behaves dishonest or a network communi-

cation error appears. In the resolutio n sub-protocol,

the customer sends to the payment gateway (TTP) a

request for r esponse, and the payment gateway sends

him the response. (Djuric and Ga sevic, 2015) have

shown that the FEI PS protocol ensures fairness and

conﬁdentiality using the AVISPA tool (Vigano, 2006).

6 THE COMPLEX

TRANSACTIONS PROTOCOL

In the com plex transactions protocol (CTP), we con-

sider that one customer can buy prod ucts in complex

transactions fr om many merchants. CTP has the fol-

lowing participants: the customer (the payment Web

segment), the merchants, the payment gateway and

the bank.

Ta ble 1 presents the notations used in the de scrip-

tion of CTP. We use hybrid en c ryption with the same

meaning as in (Djuric and Gasevic, 2015). Hybrid

encryp tion {m}

PubKA

of the message m with the pu-

blic key PubkA means {m}

, {K}

PubKA

: the message

m is encrypted with an AES session symmetric key

K, wh ic h is in turn encrypted using PubKA. If two

parties use the session symmetric key K in a hybrid

encryp tion, th e n they will use K to hybrid encryption

of all the messages that will be transmitted between

them for the remainder of session. We make som e

considerations about the commun ic ation channels we

will use in CTP. (Ferrer-Gomila et al., 2010) consider

three types of communication channels: ope rational,

re silien t and u nreliable. Op erational communication

channels (messages are correctly received in a ﬁnite

amount of time) impose a not realistic assumption for

the cu rrent networks. In CTP, we consider resilient

communication channels ( messages can be delayed

but not lost) between PG and C, respectively between

PG and M, that is similarly with assumption from

(Djuric and G a sevic, 2015). The other communica-

tion channels are unreliable (messages can be lost).

6.1 The Preparation Phase

Before CTP execution, a preparation phase is needed .

The customer is browsing throug h the online catalog

where the products from merchants are posted. Af-

ter the customer decides the products pack he wants

to buy and the options/alternatives for each product

from the pack, he clicks a ”submit” button on the on-

line catalog and the download of the payment Web

segment is started. The payment Web segment has

the same role as in the FEIPS protocol, thus we use

the term customer and payment web segment inter-

changeable, the context indicating which of them we

refer to. The pa yment Web segment is a software di-

gitally signed by payment gateway that runs on the

customer’s computer. The p ayment Web segment re-

quires fr om custom e r the credit card inf ormation and

a challenge code that will be used to authenticate

and authorize the customer for using the credit card.

For eac h subtransaction involved in the complex tran-

saction (corresponding to the produc ts the c ustomer

wishes to buy), the payment Web segmen t generates a

RSA session public/pr ivate key pair for c ustomer. We

consider that the payment Web segment has the digi-

tal certiﬁcates for the public keys of each merchant

and payment gateway. Also, each merchant/p ayment

gateway has the digital certiﬁcate for the payment ga-

teway/each m erchant’s public key.

For an aggregate transactio n, we deﬁne the aggre-

gation operator, denoted by ∧, as follows: Pid

∧. . . ∧

Pid

meaning that C wishes to buy exactly k prod ucts

with product’s identiﬁers Pid

, . . . , Pid

. For an opti-

onal transaction, we deﬁn e the option operator, deno-

ted by ∨, as follows: Pid

∨ . . . ∨ Pid

meaning that C

wishes to buy a product that is exactly one of the pro-

ducts with product’s id entiﬁers Pid

, . . . , Pid

, where

the appar ition order o f 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 c hoices of C describing the sequence of

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

product identiﬁers selected by C using ∧ a nd ∨ opera-

tors. To repre sent the tree , we use the left-child, right-

sibling representation in that each internal node cor-

respond s 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 f ollowing ﬁelds: info for storing the useful

informa tion (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

SECRYPT 2018 - International Conference on Security and Cryptography

114

Table 1: Notations used in the protocol description.

Notation Interpretation

C, PG, Mi Identity of Customer, Payment Gateway, Merchant i, where 1 ≤ i ≤ n

PubKA, {m}

PubKA

RSA public key of the party A, hybrid encryption of the message m with PubKA

h(m)

The digest of t he message m obtained by applying of a hash function h (SHA-2)

SigA(m)

RSA digital signature of A on h(m)

A → B:m

A sends the message m to B

to the right. The access to tree is realized trough the

root. An example of tr e e derived from the complex

transaction from section 2, is shown in Figure 1.

Pid

correspo nds to R of 10kΩ, Pid

to R of 20k Ω,

Pid

to C of 100mF, Pid

to C of 70mF, Pid

to con-

nectors DB35 typ e and Pid

to PCB. The root node

has ∧ oper a tor as info. The root does not have any

right sibling and its children are two nodes having ∨

operator as info and the nodes w ith the info Pid

and

Pid

Next, we will describe the subtransaction protocol

(STP) in which the customer C buys a certain physical

product from a certain merc hant M.

Pid1

Pid2

Pid4

Pid6

Pid5

Pid3

Figure 1: Tree describing the customer’s choices in left-

child, right-sibling representation.

6.2 The Subtransaction Protocol

CTP uses STP. STP is based on FEIPS protocol, but

STP has a signiﬁcant difference from the FEIPS pro-

tocol, namely, STP consists of four su b-protocols:

the setup sub -protocol, the exchange sub-protocol and

two resolution sub-proto c ols.

Next, we will describe STP’s sub-protocols mes-

sages that are graphically represen te d in Figure 2.

6.2.1 Setup Sub-protocol

Message 1: C → M:{PubKC}

PubKM

In the ﬁrst message, the pa yment Web seg-

ment sends to M the customer’s session public key

PubKC ge nerated in the preparation phase. Th e mes-

sage is hybrid enc rypted with M’s public key PubKM.

Message 2: M → C:{Sid, SigM(Sid)}

PubKC

, or

M → C:{Resp, Sid, SigM(Resp, Sid)}

PubKC

, where

Resp = A BORT

Upon receiving the ﬁrst message, M generates a

fresh random num ber Sid that will be used as an uni-

que iden tiﬁer of the subtransaction. M sends to C, Sid

and his signature on S id, both encrypted with PubKC.

If upon receiving the ﬁrst message, for any reason,

M does not want to continue the setup sub-pr otocol,

then he will sen d to C a signed response Resp with

the value ABORT . Upon receiving the message 2, C

decryp ts it and authenticates M by chec king M’s sig-

nature.

6.2.2 Exchange Sub-protocol

Message 3: C → M:{PM, PO}

PubKM

If C receives a message 2 that does not contain a

response A BORT and he authenticates M, then in the

third message, the payment Web segment sends to M

a payment message PM and a purchase order message

PO, both encrypted with PubKM.

PM = {PI, SigC(PI)}

PubKPG

PM is build by payment Web segmen t by encryp-

ting with PG’s public key of the payment informatio n

PI and the customer’s signature on PI. The encryp-

tion of PI with PG’s public key assures that PI cannot

be found out by M.

PI = C ardN, CCode, S id, Amount, PubKC, NC, M

PI contains the d ata provided by the user: card

number CardN and a cha llenge code CCode issued

by bank. The challenge code is provided to user by

bank v ia SMS a n it has a minimum length of four cha -

racters. Also, PI contains S id, the amou nt Amount,

PubKC, a fresh nonce NC generated by C, and the

merchan t’s identity M.

PO = OI, SigC(OI)

PO is build from the or der information OI provi-

ded by C and the signature of C on OI. OI contains

the order descr iption for the product OrderDesc, Sid,

and Amount.

OI = OrderDesc, Sid, Amount

Upon rec eiving the message 3, M decrypts it and

checks the signature of C on OI. If M agrees with P O

received from C, then he stores PO as an evidence

of C’s orde r and sends the message 4 to PG. Other-

wise, M sends to C a me ssag e containing a response

ABORT for aborting the subtransaction.

Message 4: M → PG:

{PM, SigM(Sid, PubKC, Amount)}

PubKPG

In the message 4, M sends to P G the paym e nt

message PM and his signature on the subtransaction

identiﬁer, C’s public key and amount. Upon receiving

An Optimistic Fair Exchange E-commerce Protocol for Complex Transactions

115

the message 4, PG decrypts it, checks C’s signature

on PI and ch e cks if C is authorized to use the card

by checking if the combina tion of CardN and CCode

is valid. If these checks are successfully passed,

then a lso C proves as being the owner of the public

key PubKC. PG checks M’s sig nature, and if the

checking is successfully, then it has the conﬁrmation

that both C and M agreed on Sid, PubKC and

Amount. Also, PG checks the f reshness of PubKC ,

Sid and NC to avoid any r eplay attac k from dishonest

merchan ts. If some check fails, then PG sends to M

a response ABORT fo r aborting the subtransactio n.

If all checks are successfully, PG sends the payment

message to the ban k. The bank checks C’s account

balance, and if it is enough, then the ban k makes

the transfer in M’s acc ount providing an response

Y ES (Resp = Y ES) to PG that forwards it to M in

the message 5. Otherwise, if c hecking C’s account

balance fails, then also the transfer fails and the bank

provides an response ABORT (Resp = ABORT ) to

PG that forwards it to M in the mesage 5. Also, PG

stores the messages 4 an d 5 in its databases as an

evidence of the subtransactions d etails.

if t1 = false then 2.

if t2 = false then 6.

else 7.

endif

else 9.

10.

endif

Figure 2: STP mesage ﬂow.

Message 5: PG → M:

{Resp, Sid, SigPG(Resp, Sid, Amount, NC )}

PubKM

Upon rec eiving the message 5, M decryp ts it and

sends to C, in the message 6, the response and PG’s

signature on response both encrypted with PubKC.

Message 6: M → C:

{Resp, Sid, SigPG(Resp, Sid, Amount, NC )}

PubKC

C decrypts message 6 and checks PG’s sig-

nature. If checking is successfully, then C has

the guarantee of the response’s authenticity (it is

from PG) a nd it corresponds to the current subtran-

saction. The presence in r esponse of Sid, Amount

and NC proves the response’s freshness and it is

not replayed by a dishonest merchant. A response

with Resp = Y ES me ans that the subtransaction

successfully ﬁnished and the content of message 6

(Resp, Sid, SigPG(Resp, Sid, Amount, NC)) is a digi-

tal receipt for the payment of product. A resp onse

with Resp = ABORT means that the conte nt of mes-

sage 6 is a proof of the subtran saction’s abort.

6.2.3 Resolution 1 Sub-protocol

If C initiates STP, but he does n ot receive any mes-

sage from M or receives an invalid message 2 fr om

M, then the current subtr a nsaction’s state is undeﬁ-

ned. If we consider only the current su btransaction,

then STP does not give any beneﬁt to any party: the

paymen t is not sent to M and no digital receipt to

C as well. However, this case must be solved if we

reason that the current su btransaction belongs to an

aggregate transaction that contains subtransactions

that already successfully ﬁnished, as we will see in

CTP. In this case, a timeout interval t1 (e.g. in the

order of secon ds or minutes) is deﬁned, in which C

waits the message 2 from M. If t1 expires and C

does n ot receive the message 2 from M or receives

an invalid message, then C initiates the resolution

1 sub-pro tocol with PG (the messages 7 and 8) to

receive a response w.r.t. the current sub transaction.

Message 7: C → PG:{ PubKC)}

PubKPG

C sends to PG in the message 7 a response request

for the current subtransaction. Upon reception, PG

decryp ts the messag e, checks that no respon se has

been gene rated for PubKC, generates a subtran-

saction identiﬁer Sid and sends to C in message

8 a signed ABORT response. Also, PG sto res the

response in its databases.

Message 8: PG → C:

{Resp, Sid, SigPG(Resp, Sid)}

PubKC

, where

Resp = A BORT

Upon receiving the message 8, C decrypts it a nd

authenticates the response by checking PG’s signa-

ture.

6.2.4 Resolution 2 Sub-protocol

If C sends the pay ment in m essage 3, but he does not

receive message 6, or rec e ives an inva lid message

from M, then an un fair case appears: C send s the

paymen t and it was processed, but C did not receive

any response. In this case, a timeout interval t2 (e.g.

in the or der of seconds or minutes) is deﬁned, in

which C waits message 6 from M. If t2 expires and

C does not receive message 6 from M or receives

an invalid message, then C initiates the resolution

2 sub-protocol with PG (the m essages 9 and 10) to

SECRYPT 2018 - International Conference on Security and Cryptography

116

receive a response w.r.t. the current sub transaction.

Message 9: C→PG:{Sid, A m ount, NC, PubKC ,

SigC(Sid, A mount, NC, PubKC)}

PubKPG

Upon receiving the message 9, PG decrypts it and

checks if a response has bee n generated for the entry

Sid, Amount, NC and PubK C. If PG ﬁnds in its data-

base a response for the entry above, and checking the

signature of C using PubKC is successfully, then it

sends to C the response in message 10. Otherwise, if

PG d oes not ﬁnd a respo nse for the entry above, then

PG sends to C an ABOR T r esponse in message 10 and

stores it in its database. If PG receives the payme nt

in message 4 (sent by M afterward or replayed by M)

that contains the informa tion from the en try above,

then PG sends also an ABORT response to M.

Message 10: PG → C:

{Resp, Sid, SigPG(Resp, Sid, Amount, NC )}

PubKC

6.3 CTP Description

In the complex tra nsaction pro tocol we proposed, a

subtransaction s, denote d by STP(C, M

, Pid

), is an

instance of STP in which C buys the physical product

with Pid

identiﬁer from the merchant M

. We de-

ﬁne St(s) the state of the subtransactio n s as being th e

content of one of the messages 2, 6, 8 or 10 (identical

with the message 6) that the customer will receive in

s. More exactly, St(s) is:

• (Resp, Sid, SigM(Resp, Sid)), where

Resp = A BORT , or

• (Resp, Sid, SigPG(Resp, Sid, Amo unt, NC)),

where Resp ∈ {YES, ABORT }, or

• (Resp, Sid, SigPG(Resp, Sid)), where

Resp = A BORT .

For St(s) a state of the subtransaction s, we de note

by St(s).Resp the response (Resp) in St(s), and by

St(s).Sig the signature in St(s).

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

quence o f subtransaction states St(s

). . . St(s

) cor-

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

p, Ns(p) is calculated dependin g on the p → info as

follows:

• if p → info = Pid

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

St(STP(C, M

, Pid

)). For simplicity, we consider

that M

is the merchant that sells the pr oduct with

Pid

identiﬁer, where 1 ≤ i ≤ n.

• if p → info = ∨, then

Ns(p) =











Ns(l), if ∃ l, the leftmost child

of p such that St(s).Resp =

Y ES, for all St(s) ∈ Ns(l)

Ns(r), otherwise

where r is the rightmo st child of p.

The node p corresponds to ∨ operator w.r.t. the

customer’s choic es and this p references are prio-

ritized by appear ance in the child nodes of p f rom

left to the right. Ns(p) is the node state of th e left-

most child of p, denoted Ns(l), for which all sub-

transactions from Ns(l) have successfully ﬁnished

STP. Otherwise, if all subtransactions from no de

states of all children of p are aborted, then Ns(p)

is the node state of the rightmost child of p.

• if p → info = ∧, and c

, . . . , c

are all children of

p, then we have two cases:

1. if St(s).Resp = Y ES, for any St(s) 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(s

). . . St(s

) such that St.(s

).Resp =

ABORT , for all 1 ≤ l ≤ m. In this case,

Ns(p) = Ns(c

). . . Ns(c

). Even if the sub-

transactions states from Ns(c

), . . . , Ns(c

j−1

)

are Y ES (that means that the subtran sacti-

ons from Ns(c

), . . . , Ns(c

j−1

) have success-

fully ﬁnished STP), the aborted subtransacti-

ons s

, . . . , s

from Ns(c

) lea d to aborting

the entire aggregate transaction corresponding

to p. That is why all subtran sactions states from

Ns(c

), . . . , Ns(c

j−1

) will be aborted. Thus,

will set St(s).Resp = ABORT , for any St(s) ∈

Ns(c

), for any 1 ≤ r ≤ j − 1.

Because the node p corr esponds to ∧ operator,

Ns(p) is the sequence of node states of p’s child-

ren. For efﬁciency, the sequence of node states

of p’s children is calculated until c

the leftmost

child of p for that Ns(c

) contains only ab orted

subtransaction states.

Thus, Ns(p) contains a sequence of subtran-

saction states in which either all subtransactions

successfully ﬁnished STP or all subtra nsactions are

aborted.

CTP, described in Table 2, recursively calculates

Ns(t) (t is the root of the tree derived from the custo-

mer’s choices), traversing the tree in a similar ma nner

with depth-ﬁrst sear c h. For any node p of the tr ee, we

use a child array to store the node states of a ll children

of p.

At the lines 2-3, the protocol computes Ns(p) for

a node p, depending o n the node state of the le ft most

child of p. For a node p with a least two children, the

while loop (the 5-12 lines) computes the no de state

of any child of p except the left m ost o ne. We re-

mark th at way in which nod e state is computed is es-

sential to obtain the fair exchange and atomicity of

An Optimistic Fair Exchange E-commerce Protocol for Complex Transactions

117

Table 2: Complex transactions protocol.

CTP(t)

1. if (t → l eft 6= NULL) child[0] = CTP(t → left);

2. if ((t → info = ∨ and St(s).Resp = Y ES, for all St(s) from child[0]) or

3. (t → info = ∧ and St(s).Resp = ABORT , for all St(s) from child[0])) Ns(t) = child[0]; ret urn Ns(t);

4. j = 1; k = t → left → right;

5. while (k 6= NULL)

6. child[j] = CTP(k);

7. if (t → info = ∨ and St(s).Resp = Y ES, for all St(s) from child[j] ) Ns(t) = child[j]; ret urn Ns(t);

8. if (t → info = ∧ and St(s).Resp = ABORT , for all St(s) from child[j])

9. for (c = 0; c ≤ j; c = c + 1) Ns(t) = Ns(t)child[c]; end for

10. AggregateAbort(Ns(t)); return Ns(t);

11. k = k → right; j = j + 1;

12. end while

13. if (t → info = Pid

) Ns(t) = St(STP(C, M

, Pid

)); return Ns(t);

14. else if (t → info = ∨) k = t → left;

15. while (k → right 6= NULL) k = k → r ight; 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]; en d for

18. return Ns(t);

19. end if

20. end if

a co mplex transaction (lines 7-10) : if an aborted sub-

transaction/sequence of subtransactions leads to abor-

ting the entire aggregate transaction, but so me sub-

transactions from the aggregate transaction success-

fully completed STP, then the ones that are success-

fully must a lso be stored in the node state correspon-

ding to ∧ operator (line 9) and afterwards ab orted

by applying AggregateAbort sub-protocol (line 10).

We will describe AggregateAbort sub-protocol in the

section 6.3.1.

At line 13, the protocol comp utes Ns(p) for a node

p with a product identiﬁer as info.

The nod e state for a node that correspon ds to ∨

operator, for which all subtransactions states fr om all

its children are aborted, is c omputed at lines 14 − 16.

The node state for a node that cor responds to ∧ opera-

tor for th at all subtransactions states from all its child-

ren successfu lly completed STP, is computed at lines

17 − 18.

6.3.1 AggregateAbort Sub-protocol

As we discussed in the pr evious section, in

CTP, there may be cases in which an abor-

ted subtransaction/sequence of sub transactions le-

ads to abo rting the entire aggregate transaction,

but some subtransactions from the aggregate tran-

saction successfully completed STP. As a result,

an unfair case occurs for C: the entire aggre-

gate transaction is not successful, but C has paid

for ce rtain produc ts. For example, for a node p

that corresponds to ∧ operator, CTP computes the

node state Ns(p) = St(s

). . . St(s

)St(s

k+1

). . . St(s

where St(s

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

St(s

).Resp = ABORT for any k + 1 ≤ j ≤ m. The

entire complex transaction corre sponding to the node

p is not completed successfully because the compo-

nent subtransactions s

k+1

, . . . , s

are aborted, but in

the same complex transaction C paid for the pro-

ducts involved in the subtransactio ns s

, . . . , s

. So,

the fairness will be obtained by applying Aggrega-

teAbort(Ns(p)) sub -protocol in that entire aggregate

transaction will be aborted. Next, we will describe

AggregateAbort(Ns(p)) sub-protocol.

To solve the unfair case mentioned above, the

paymen t Web segment initiates the AggregateA-

bort(Ns(p)) sub-protocol by sending to PG in th e

message 11 a customer req uest to abort Ns(p). The

message 11 is build from Ns(p) and the customer’s

signature on Ns(p), both encrypted w ith PubKPG.

Message 11: C → PG:

{Ns(p), SigC(Ns(p))}

PubKPG

SECRYPT 2018 - International Conference on Security and Cryptography

118

Upon receiving the message 11, PG decrypts

it, ob tains the sequence of subtransaction states

St(s

). . . St(s

) in Ns(p), and c hecks the signature of

C on Ns(p ) to be sure that this request comes from

C. PG checks the signatures involved in all subtran-

saction states from Ns(p) as follows:

• PG checks M’s signature, for any St(s) ∈

Ns(p), such that St(s) = (Resp, Sid, SigM(Resp,

Sid)) with Resp = AB O RT ;

• PG searches into its databa se the appropri-

ate entry for St(s) and checks his signature,

for any St(s) ∈ Ns(p), such that St(s) =

(Resp, Sid, S igPG(Resp, Sid, Amo unt, NC))

with Resp ∈ {YES, ABORT }, or St(s) =

(Resp, Sid, S igPG(Resp, Sid)) with Resp =

ABORT .

If all checks are succe ssfully passed, then PG

sends to the bank the customer’s request. The

bank aborts any sub transaction’s state St(s) =

(Resp, Sid, S igPG(Resp, Sid, Amo unt, NC)) ∈ Ns(p),

such that St(s).Resp = Y ES by canceling the transfer

correspo nding to St(s) from customer’s a c count into

merchan t’s accoun t, and updating St(s) by:

1. OldSt(s) = St(s),

2. St(s).Resp = ABORT and

3. St(s).Sig = SigPG(St(s).Resp, Sid, Amount, NC,

OldSt(s)).

By updating St(s) as above, St(s) becomes abor-

ted, and PG’s signatu re is updated including the old

subtransaction state. In this way, any party (C, M

or PG) can check a fterward PG’s signature from

the update d St(s) to ensure that th e subtransaction s

that successfully completed STP has been a uthorized

aborted. Thus, we remark that no party can have 2 dif-

ferent independent subtransaction states for th e same

subtransaction.

The bank sends the new Ns(p ) computed above

(in th a t any subtransaction state is aborted) to PG that

forwards it to C in message 12.

Message 12: PG → C:{ Ns(p), SigPG(Ns(p))}

PubKC

PG stores message 12 in its da ta base for tran-

saction’s evidence.

Also, in message 13, PG sends simultaneously the

subtransaction state St(s) ∈ Ns(p) just aborted by the

above procedure, to each merchant M involved in the

subtransaction s.

Message 13: PG → M:{St(s)}

PubKM

7 SECURITY ANALYSIS

In this section, we will analyze the security require-

ments stated in section 3 for our CTP.

7.1 Effectiveness

If every party involved in the complex transaction pro-

tocol from Table 2 behaves according to the proto-

col’s steps, does no t want to prematurely terminate

the protocol and there are n o network communication

delays/erro rs, then our protocol assures that the cu-

stomer receives the digital rece ipts from merchants,

and eac h merchant receives his corresp onding pay-

ment from the c ustomer without TTP involvement.

Therefore, our protocol meets the effectiveness requi-

rement.

7.2 Fairness

In our CTP, the fairness may not be insured only for

C. There are some arguments for this. The payment

Web segment performs cu stomer’s side protocol ac ti-

ons and is a soft digitally signed by PG that is a trus-

ted p a rty. So, any corruption of the payment We b seg-

ment by user o r M is im possible. Moreover, C recei-

ves the digital receipt for payment only after C sends

the pa yment to M. We remark that C can not chea t

M by sending an inappropriate payment message PM

directly to PG, bec ause PM is sent ﬁrst by C to M in

message 3, and after M agr ees with PO, then M sends

PM to PG in messag e 4. As we saw in section 6.2.2,

if all checks of PG w.r.t message 4 are su c cessfully,

then it has the conﬁrmation that bo th C and M agreed

on the subtransaction data (Sid, PubKC and Amount).

From these arguments, M is in a more advantageo us

position than C in the exchange of the payment for the

digital receipt and C is the only party that could have

losses.

CTP uses STP. To obtain fairness in CTP, a neces-

sary but not sufﬁcient condition is to obtain fairness in

STP.

STP is based on the FE IPS protocol, with the ma-

jor difference that STP has the sub-protocol resolu-

tion 1 in addition to th e FEIPS protocol. (Djuric and

Gasevic, 2015) have shown that the FEIPS protocol

ensures fairness u sin g AVISPA tool for a utomated va-

lidation o f large-scale Internet security protoco ls that

provides four back-ends th at impleme nts different ve-

riﬁcation techniques (Vigan o, 2006). More exactly,

in (Djuric and Gasevic, 2015 ), the authors used for

FEIPS’s veriﬁcation two back-ends from the AVISPA

tool: Cl-Atse (Constrain t-Logic-based Attack Sear-

cher) - a model ch ecker that uses constraint solving

An Optimistic Fair Exchange E-commerce Protocol for Complex Transactions

119

techniques (Turuani, 2006), and OFMC (On-the-Fly

Model-Checker) - a model checker that uses symbo-

lic techniqu e s (Basin et al., 2005). In AVISPA, the fair

exchange requirement between payment and digital

receipt for the FEIPS protocol, is ensured b y proving

the authentication goals PG authen ticates C on P I and

C authenticates PG on dig ital rec eipt, or by ﬁnding

attacks for both authentication goals. The fairness ve-

riﬁcation results obtained in AVISPA for the FEIPS

protocol showed that there is no attack (Djuric and

Gasevic, 2015).

However, the only case in S TP in that the fairness

for C is not insured is when C sends the payment in

message 3, the paym ent is successfully processed, but

he does not rece ive the digital receipt for payment in

message 6, or receives an invalid message from M.

This case may arise in the following scenarios: M

sends the payment to PG in the message 4, but M

does not receive message 5 from PG, or M receives

message 5 but does not send the message 6 to C, or

M receives the message 5 but sends an invalid mes-

sage to C. The scenarios above c an appear because M

behaves dishonest or a network co mmunication error

occurs. In this c a se, C waits for the message 6 from

M until the timeout interval t2 expires in which case

C initiates the resolution 2 sub-protocol with PG to

receive the digital receipt. Afte r PG receives the mes-

sage 9, he sends to C in message 10 the digital r eceipt

for payment because the payment has been success-

fully processed and PG ﬁnds the digital receipt in its

databases. We remark that if C initiates the resolu-

tion 2 sub-protocol a nd M sends the message 4 to PG

afterward, the fairness is preserved because PG will

send to both C and M an ABORT response as is men-

tioned in section 6. 2.4. Thus, the unfair case is sol-

ved: M receives the payment and C the digital receipt,

or M does not receives the payment and C receives

an AB ORT response. The resolution 1 sub-protocol

from section 6.2.3 is necessary only when we take

into consideration the complex transactions (in which

is mandatory to have a deﬁned state for each perfor-

med subtransaction), to solve the case in tha t in a sub-

transaction C initiates STP, but he does not receive

any message from M or rece ives an invalid message 2

from M. This case can appear because M behaves dis-

honest or because of a network communication er ror.

In this case, C waits for message 2 from M until the ti-

meout interval t1 expires in which case C initiates the

resolution 1 sub-pr otocol with PG, and PG sends to

C an ABORT response for the current subtransaction.

We also note that in the FEIPS protocol was not ne-

cessary to consid er a resolution 1 sub-protocol as in

section 6.2.3, because th e FEIPS protocol take into

consideration only one customer and one merchant.

As a result of the discussion ab ove, from the fact that

the FEIPS protocol ensures fairness, we obtain that

STP ensures fairness.

The fairness obtained in all subtransations from

a complex transaction does not directly implies that

fairness is ensured in entire complex transaction. So,

in addition to fairness in STP, to obtain fairness in

CTP, two requirements must be also ensured. First,

for a ny optional transaction from th e complex tran-

saction, C obtains exactly one digital receipt for the

paymen t of o nly one product, and corresponding mer-

chant obtains the payment for the pr oduct, or none of

them obtains nothing. The product is either an in-

dividual product, or an aggregate product that corre-

sponds to a ∧ operator. Also, the digital receipt is

either an in dividual rece ipt corresponding to an in-

dividual product, or is a seq uence of receipts corre-

sponding to an aggregate pr oduct. As we have seen

in Table 2, CTP ensures this re quirement: the n ode

state corresponding to ∨ ope rator is the node state of

its leftmost child for which all subtr ansactions have

successfully ﬁnished STP. Otherwise, if all subtran-

sactions from node states of all children of the node

∨ are aborted , then its n ode state is the node state

of the rightmost child of ∨. Secondly, for any ag-

gregate transaction from the complex transaction, C

obtains the digital rece ipts for the p ayments of all pro-

ducts, and each mer chant obtains the corresponding

paymen t fo r th e product, or none of them obtains no-

thing. In CTP, the node state for a node corre sponding

to the ∧ operator is computed as fo llows: if all sub-

transactions from all node states of all child ren o f th e

node ∧ have successfully ﬁnished STP, then the node

state of ∧ is the sequence of node states of its child-

ren. Otherwise, the node state of ∧ is the sequence of

node states of its children until to the leftmost child

that contains only aborted subtransaction states in its

node state. But, in this last case, an unfair case occurs

for C: the entire aggregate transaction is not success-

ful, but C has paid for certa in products and he recei-

ved the digital receipt for these. We note that this is

the only case in that the fairness for C can b e violated

in CTP. In this case, as we h ave seen in CTP, the Ag-

gregateAbort sub-protocol is applied. More exactly,

C (payment Web segment) initiates the AggregateA-

bort sub-protocol from section 6.3.1 to abort any sub-

transaction th at successfully ﬁnished STP and that be-

longs to the unsuccessful a ggregate transaction , by

sending to PG (message 11) the node state corre-

sponding to ∧ operator. After checking the signatu-

res from all received subtransaction ’s states, PG sends

the custome r’s request to the bank that aborts all sub-

transactions that successfully ﬁnish e d STP (including

the canceling the corresponding tra nsfer) and that be-

SECRYPT 2018 - International Conference on Security and Cryptography

120

longs to the unsuccessful aggregate transaction. The

bank sends to PG the new n ode state coresponding to

∧ operator where all subtransaction’s states are abo r-

ted. Also, C and each merchant involved in these

aborted subtransactions receive fr om PG (messages

12 and 13) the new subtransaction’s states abor te d.

Thus, the unfair ca se for C is solved: the entire aggre-

gate transaction is aborted, mea ning that any subtran-

saction which belongs to the ag gregate transaction is

aborted.

As a result, fairness exchange of payment for digi-

tal receipt in complex transactions a nd complex tra n-

sactions atomicity are preserved.

7.3 Timeliness

Any party can be sure that CTP execution will be ﬁ-

nished at a certain ﬁnite point of time, for two rea-

sons. First, we have introduced two timeout intervals

in STP when C waits the message 2 from M, respecti-

vely, whe n C waits the message 6 from M. If these

timeout intervals expires, then C initiates the resolu-

tion 1 sub-protoc ol with P G , respectively, C initiates

the reso lution 2 sub-protocol with PG. Secondly, if

in CTP, a complex transaction contains subtransacti-

ons that successfully ﬁnished STP and also contains

an aborted subtransaction, then the AggregateAbort

sub-protocol is executed betwee n C and PG, to abort

any subtransaction from the complex transaction. The

communication channel between C and PG is resi-

lient, and as a result, CTP execution will be ﬁnished

at a certain ﬁnite point of time. After the CTP ﬁnish

point, the level of fairness ac hieved cannot be degra-

ded. If after the ﬁnish point, C has the digital receipts

of payments for produc ts, then each merchant obtains

also the corresponding payment for his product. On

the other side , if each merchant involved obtains the

paymen t f or his product, then, after th e protoco l ﬁ-

nish point, C gets the corresponding digital receipts

from the messages 6, or messages 10. Moreover, if

after th e ﬁnish point, C has not received the digital

receipts, then also the corresponding merchant does

not get the payment; if each m erchant involved has

not get the payment, then C also does not receive the

digital receipts.

7.4 Non-repudiation

In a ny subtransaction from CTP, C cannot deny

its participation in subtransaction because he canno t

deny its signature on the payment information PI. If

C tries to deny its participation in a subtransaction,

PG has in its database the evidence of C’s signature

on PI. Also, no merchant can deny its participatio n in

a subtransaction be c ause he cannot deny its signature

which he includes in the message 4. If a merchan t

tries to deny its participation in a subtransaction, PG

has the evidence of the merchant’s signature on th e

subtransaction identiﬁer Sid, C’s public key PubKC

and the subtransaction’s amount Amount.

7.5 Conﬁdentiality

Every message transmitted between parties involved

in any subtransaction from CTP is hybrid encrypted

with the public key of the receiver: every message is

encryp ted by sender with a symmetric key, and this

symmetric key is encrypted with the receiver’s public

key. So, only the authorized receiver of a message

can read the message’s content. In particular, in any

subtransaction from CTP, the conﬁd e ntiality of the

card number CardN between C and PG is o btained

because C sends (in message 3) CardN hybrid encryp-

ted with PG’s public key. Also, in any subtra nsaction

from CTP, the con ﬁdentiality of the order description

OrderDesc between C and M is obtained because C

sends OrderDesc hybrid encrypted with M’s public

key. As a result, CTP ensures the conﬁdentiality re-

quirement. This requireme nt is also satisﬁed for the

FEIPS protocol only taken into consideration one cu-

stomer and one merchant.

8 COMPARATIVE ANALYSIS

Ta ble 3 provides a comparative analysis between the

security requirements obtained by our protocol and

the security requirements obtained by the most related

solutions to our propo sal.

9 CONCLUSIONS

In this pap e r, we proposed an optimistic fair-exchange

e-commerce protocol for complex transactions. Our

protocol is based on FEIPS protocol (that consid ers

only one customer and o ne merchant) for which was

formally proved fairness and conﬁdentiality require-

ments using AV ISPA. The main streng ths of our pro-

tocol are: ensures strong fair-exchang e and a tomicity

for complex transactions, uses payment gateway as

ofﬂine TTP, provides timeliness, no n-repudiation, in-

tegrity and conﬁdentiality.

An Optimistic Fair Exchange E-commerce Protocol for Complex Transactions

121

Table 3: Multi-party fair-exchange e-commerce protocols: a comparative analysis.

Our protoc ol Liu Draper-Gil Yanping

Scenario Payment for Payment for Contract signing Non-repudiation

physical products in digital products in

complex transactions aggregate transactions

Atomicity Y Y Y N

Effectiveness Y Y Y Y

Fairness Strong Weak Weak Strong

Timeliness Y N Y Y

Non-repudiation Y Y Y Y

Conﬁdentiality Y N Y Y

Y=YES, N=NO

REFERENCES

Alaraj, A. (2012). Fairness in physical products delivery

protocol. International Journal of Computer Net-

works & Communications (IJCN C).

Asokan, N. (1998). Fairness in electronic commerce. PhD

Thesis, University of Waterloo, Canada.

Basin, D., Modersheim, S., and Vigano, L. (2005). Ofmc:

A symbolic model-checker for security protocols. In-

ternational Journal of Information Security.

Birjoveanu, C. V. (2015). Anonymity and fair-exchange

in e-commerce protocol for physical products deli-

very. I n 12th International Conference on Security

and Cryptography. 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. (2013). An asynchronous optimistic proto-

col for atomic multi-two-party contract signing. The

Computer Journal.

Ferrer-Gomila, J. L., Onieva, J. A ., Payeras, M., and Lopez,

J. (2010). Certiﬁed electronic mail: properties revisi-

ted. Computers & Security.

Li, H., Kou, W., and Du, X. (2006). Fair e-commerce pro-

tocols without a third party. In 11th IEEE Symposium

on Computers and Communications. IEEE.

Liu, Y. (2009). An optimistic fair protocol for aggregate

exchange. In 2nd International Conference on Future

Information Technology and Management Engineer-

ing. IEEE.

Liu, Z., Pang, J., and Zhang, C. (2011). Veriﬁcation of a key

chain based ttp transparent cem protocol. Electronic

Notes in Theoretical Computer Science.

Mukhamedov, A. and Ryan, M. D. (2008). Fair multi-party

contract signing using private contract signatures. In-

formation and Computation.

Onieva, J. A., Lopez, J., and Zhou, J. (2009). Secure Multi-

Party Non-Repudiation Protocols and Applications.

Springer.

Turuani, M. (2006). The cl-atse protocol analyser. In

17th International Conference on Rewriting Techni-

ques and Applications. Springer.

Vigano, L. (2006). Automated security protocol analysis

with the avispa tool. Electronic Notes in Theoretical

Computer Science.

Yanping, L. and Liaojun, P. (2009). Multi-party non-

repudiation protocol with different message exchan-

ged. In 5th International Conference on Information

Assurance and Security. IEEE.

Zhang, Q., Markantonakis, K., and Mayes, K. (2006).

A practical fair exchange e-payment protocol for

anonymous purchase and physical delivery. In 4th

ACS/IEEE International Conference on Computer Sy-

stems and Applications. IEEE.

Zhou, J., Onieva, J. A., and Lopez, J. (2005). Optimi sed

multi-party certiﬁed email protocols. Information Ma-

nagement & Computer Security Journal.

SECRYPT 2018 - International Conference on Security and Cryptography

122