Preserving Anonymity in Fair Exchange Complex Transactions

E-Commerce Protocol for B2C/B2B Applications

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

Keywords:

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

Abstract:

In the electronic commerce context, it is common that a customer wishes to buy a pack of products/services

composed of several products/services from different merchants. The customer is interested in buying all

products from the pack or no product at all. On the other hand, sometimes the customer wants to buy exactly

one product from many merchants, and for this, he speciﬁes in his request more possible products according to

his preferences but from t hese options only one will be committed. The combination in any form of these two

types of e-commerce transactions will be named complex transaction. Despite the great variety of multi-party

fair exchange protocols proposed until now, there is no solution to address to physical products delivery in

complex transactions. In this paper, we propose t he ﬁrst e-commerce protocol for physical products delivery

in complex transactions that provides fair exchange and anonymity of the customer.

1 INTRODUCTION

In the electronic commerce, there are situations

in that a customer wishes to buy a pack of pro-

ducts/services composed of several prod ucts (physi-

cal o r digital)/services from different mercha nts. In

this type of e-commerce transactions, the customer is

interested in buying all produc ts from the pack or no

product at all, namely aggregate/atomic transactions.

For ﬂexibility, in the optional transactions, th e cus-

tomer wants to buy exactly one product from many

merchan ts, and for th is, he spe ciﬁes in his request

more possible products according to his preferences

but from these options only one will b e committed.

We will refer to the combination in any form of aggre-

gate and optional transactions as complex transacti-

ons.

In e-commerce protocols, fair exchange is an es-

sential property. For complex transactions, an e-

commerce protocol in that a customer wishes to buy

many products from different merchan ts assures fair

exchange if:

• for any optional transaction fr om th e complex

transaction, the customer obtains exactly o ne pro -

duct in order of his speciﬁed preferences, and

• for any aggregate transaction from the complex

transaction, the customer obtains all produ cts,

and each mercha nt obtains the payment for the cor-

respond ing product, or none of them obtains nothing.

In a complex transactio n, the issues that can a ppear

are when in a aggregate transaction some products

can be successfully acqu ired, but the others not, or

when in an optional transaction more than one pro-

duct is successfully acquired. In these cases, even if

each corresponding merchant gets the payment for his

product, fair exchange is not ensured.

To achieve fair exchange, most of the proposed

protocols are based on a Trusted Third Party (T TP)

that acts like item validator or to solve the disputes.

Anonymity of the customer is a key property that

must be considered in a fair exchange e-commerce

protocol. The customer may not want to reveal sen-

sitive data of h is iden tity (as credit card number, in-

formation abo ut customer’s bank, custom er’s account

number) so that this information can not be used by

merchan t in commer c ia l purpose to build spending

habits of the customer. An e-commerce protocol pro-

vides the customer’s anonymity if no par ty and no c o-

alition between parties can link the customer’s true

identity with his actions. To obtain customer’s anony-

mity in our protocol,th e challenge is to guarantee this

requirement both in pa yment and collection of physi-

cal products.

Until n ow there are protocols proposed for physi-

cal products delivery that provid e fair exchang e a nd

Bîrjoveanu, C. and Bîrjoveanu, M.

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications.

DOI: 10.5220/0006850800990110

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 1: DCNET, ICE-B, OPTICS, SIGMAP and WINSYS, pages 99-110

ISBN: 978-989-758-319-3

consider only one customer and o ne merchant (Birjo-

veanu, 2015; Dju ric and Gasevic, 2015; Alara j, 2012;

Li et al., 2006; Z hang et al., 2006) and from all this

solutions the one proposed in (Birjoveanu, 2015) pro-

vides also anonymity for both customer and merchant.

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 ( D raper-Gil et al., 2013;

Onieva et al., 2009), and certiﬁed e-mail (Onieva

et al., 2009). Despite g reat variety of multi-party fair

exchange protocols proposed until now, there is no

solution to address our problem: com plex transacti-

ons where a customer wants to buy several physical

products from different merchants, providing fair ex-

change and anonymity.

From all known solutions for multi-party fair ex-

change, no one can be applied to our problem. First,

all proposed solutions exchange digital items, while

our problem involves exchange between electronic

paymen t and ph ysical products delivery. Secondly,

some multi-par ty non-repudiation solutions exchange

different messages (Onieva et al., 2009) in a one-to-

many conﬁguration, withou t taken in to consideration

atomicity, while our problem involves one customer

that wants to buy several products while p reserving

atomicity. Thirdly, the scenario most closed to our

scenario is the one prop osed by (Liu, 2009), where

in an aggregate transaction, a customer wants to buy

from different merchants several digital prod ucts. The

solution from (L iu, 2009) can not be applied to our

problem because the protocol architecture for physi-

cal p roducts delive ry is more complex than for digital

products: delivery agents are needed for phy sical pro-

ducts delivery from merchants to customer. Also, in

(Liu, 2009) optional transactions and anonym ity are

not considere d.

Our contribution. I n this paper, we propose a new

anonymous fair exchange e-commerce p rotocol for

complex transactions in that the customer wants to

buy several different physical prod ucts from different

merchan ts. In our scenario, a complex transaction is

a combination in any form of aggregate and optio-

nal transactions. Our solution is the ﬁrst that addres-

ses to p hysical product delivery in complex transacti-

ons. Also, our protoco l pr ovides non-repudiation, in-

tegrity and conﬁdentiality of data exchanged between

the parties.

The paper is structured as follows: section 2 gives

an inform al description, section 3 presents the pro-

tocol, section 4 provides an analysis of the proposed

protocol and section 5 contains the conclusion.

2 INFORMAL DESCRIPTION

Our protocol has ap plications in Business to Consu-

mer (B2C) and Business to Business (B2B) scen arios.

For a B2B scenario, the cu sto mer is the Electron com-

pany that manufactures electronic boards for different

purposes, on req uest from his clients. To plan its bu-

siness, Electron uses an online catalog fr om where it

can buy several electronic compo nents from different

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

online catalog, Electron can select products like: r e-

sistors (R), capacitor s (C), integrated circuits (IC), ca-

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

on. Electron wants to star t the production of a new

electronic board and therefore wants to prepare its or-

der in form of an e-commerce complex transaction as

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

from M2) and (50C of 100m F from M3 or 100C of

70mF from M4) and 70 connectors 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 not acquire 10 0R of 10kΩ

from M1 due to lack of sto ck or delay in d elivery

time, then its second option is taken into considera-

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

production, Electron ne eds all types of components

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

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

hout 70 connector s DB35 type) is not usef ul for him.

For an optional transaction, Electron must not acquire

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

saction h e must n ot acquire both 100R of 10kΩ and

70R of 20kΩ) be cause then he will remain with un-

necessary pr oducts. For example, a pack of products

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

and 100C of 70mF, and 70 connec tors 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 a nd wants to build an electronic hobb y kit,

and for this he uses the online catalog to order the nee-

ded components.

The protocol we propose uses an online TTP that

will validate the customer’s coins a nd will provid e

fair exchange if any party misbehaves or prematurely

aborts. The customer m ay choose to remain an ony-

mous during the protocol execution. Our pro tocol

uses the electronic cash payment mechanism based on

group blind digital signatu res on behalf of the banks

proposed in (Lysyanskaya and Ramzan, 1998) to pro-

vide anonym ity of the customer in th e payment phase.

To ensure anonymity of the customer in the physical

delivery phase, our p rotocol is based on a delivery

ICE-B 2018 - International Conference on e-Business

100

agent that takes the produc t from the merchant and

provide it to a destination cabine t, where the access to

the physical products is p rotected by passwords.

Next, we will in formally describe the protocol.

When the customer decides the products pack he

wants to buy and the options for each prod uct from

the pack, he clicks a “submit” button o n the online ca-

talog. In back-end, the protocol searches a sequen c e

of subtransactions to satisfy the c ustomer’s op tions in

order of preference s he supplies. A subtransaction is

a seque nce of proto col’s steps in which the c ustomer

buys a certain phy sical product from a certain mer-

chant.

Our protocol can run in multiple ro unds. One

protocol round consists of three sub-protocols: the

Agreement sub-protocol, the Delivery sub-proto col

and the Payment sub-protocol. In Agreement, a se-

quence of subtransactions is started as a possible solu -

tion for customer’s choices. For each subtransaction,

the customer buys a digital coin from h is bank and va-

lidates it to T T P. The customer sends to the merchant

the purchase order and th e digital signature of T T P

and the merchant replies to conﬁrm the agreement on

subtransaction’s terms. The Agreement will be com-

pleted either with all subtransactions successfully ﬁ-

nished or all aborted. If a ll subtransactions success-

fully ﬁnishe d Agreement, th e n Delivery simultane ous

realizes the physical delivery of products from these

subtransactions. After all products from the subtran-

sactions involved in Delivery are posted to the desti-

nation cabinet, the cu stomer collec ts the products and

provides it an evidence of the products collection. If

Delivery is successfully for all subtransactions, th e n

Payment simultaneously perf orms the payment for

these subtransactions.

In a pro tocol round some subtransactions can be

aborted without solving the customer’s options in that

round. If the customer’s options are no t completely

explored, new proto c ol r ounds will be executed to se-

arch a sequence of subtransactions that will satisfy his

choices. The protocol terminates after a rou nd that

solves the custome r’s options, or after a round where,

after Agreement, all subtransactions are aborted.

3 THE PROTOCOL

Our proposal uses as a building block our previous

work (Birjoveanu, 2015) that involves physical pro-

ducts delivery for only one customer and one me r-

chant and that provides fair exchange and anonymity.

The Table 1 presents the notations used in the descrip-

tion of our protocol.

3.1 Protocol Infrastructure

The following assumptions are made for our proto-

col: (1) All parties use the same algorithms for en-

cryption, hash, digital signature and the same group

blind digital signature p rotocol mentioned in Table 1.

(2) Cryptographic algorithms are strong enoug h. (3)

T T P is the grou p manager, namely Central Bank, that

is known by all parties implied in protocol. T T P does

not m isbehave or collude with any of parties to pro-

vide beneﬁts to another party. (4) There are n mer-

chants M

,...,M

. C can buy a pack of products from

these merchants, and each merchant can provide to

C only a certain type of product. C an d each M

have an account to their bank. (5) All banks from

group and group manager share a commit-buffer in

that each subtransaction’s value is stored until the sub-

transaction is completed successfully or aborted. (6)

All banks from group and group manager maintain a

global list of coin’s serial already sp ent, validated but

unspent, or canceled, to allow any bank to check a

coin for dou ble-spending or double-canceling. Each

record contains the unique identiﬁer of the subtran-

saction, the coin’s serial and a spent ﬂag. The value of

spent ﬂag corresponds to the cu rrent state of the coin:

spent = 0 mean s that the coin is validated by T T P

but not yet spent, spent = 1 the coin has alre a dy been

spent, spent = 2 the coin has alread y been canceled .

(7) For eac h substransaction s

, a destination cabinet

DC exists, where the physical products are provid ed

by DA

, and C can collect the produc t P

with the iden-

tiﬁer Pid

from DC only by knowing a password that

is set by M

. DC is used to hide the true ide ntity of C

if he wants. DC has the ability to digitally sign messa-

ges, verify sign atures and to check if the pa ssword en-

tered by C corre sponds to the barcode set on product.

After C provides the correct password, DC o pens a

hatch where packaged pr oduct is available to C. DC

has a video camera mounted that records when C un-

wraps each pack aged product and check if the product

is the ordered one. DC has a d evice that allows to C,

by push ing a button, to send the encry pted recording

to T T P. This feature allows on T TP side to store

in a buffer PidsAborted the product’s identiﬁers that

are not received acc ording to the agreement co nditi-

ons. C uses this feature only if is not satisﬁed with the

product, as an evidence of wrong product reception.

Otherwise, the recording is au tomatically deleted. (8)

Communica tion channels that are set between parties

provides anonymity, except the cases in that the par-

ties choose to reveal their tru e identities.

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications

101

Table 1: Notations used in the protocol description.

Symbol Interpretation

C/C

′

True identity/pseudo identity of the customer

,DA

The product with identiﬁer Pid

, the delivery agent i, where 1 ≤ i ≤ n

Identity of the merchant i that sells P

CB/M

The bank of customer/merchant M

acct

iacct

The bank account of the customer/merchant M

with CB/M

, Q

, Po

Price, quantity, purchase order used to order P

(Sid

′

,Pid

, fst)-the subtransaction in that C

′

buys P

from M

Sid

The unique identiﬁer of s

addr

The mailing address of the destination cabinet DC

A → B: m

A sends the message m to B

DC ⇒ C

′

: m

DC sends m to DA

that forwards it to M

and M

to C

′

pub

prv

(RSA) Public/private key pair of A

′

ipub

′

iprv

One time (RSA) public/private key pair of A used only in s

{m}

′

,h(m)

m encrypted with K

′

, m’s digest obtained by a hash function h (SHA-2)

sig

(m)

(RSA) Digital Signature with the A’s private key A

prv

on h(m)

iT TP

, N

Timestamp generated by T T P, nonce generated by A in s

Lifetime of encrypted digital coin’s validity in s

,sig

)

Coin generated by C, AES symmetric key used in s

, CB’s signature

on c

obtained by Group Blind Digital Signature (GBDS) protocol (Lysyanskaya and Ramzan, 1998)

3.2 Prelude

We assume that before the star ting of the protocol, the

following system setup steps are executed: (1) T T P

generates a public/private key pair, (T T P

pub

,T T P

prv

)

and provides T T P

pub

to C and each M

, where 1 ≤

i ≤ n. ( 2) When C and each M

create accounts to

their banks, each of them generates a public/private

key pa ir, (C

pub

prv

) and (M

ipub

iprv

), re spectively.

C provides C

pub

to CB and each M

provides M

ipub

B. The banks maintain databases with public keys

of their clients associated to their accounts. (3) C and

each M

generates a one time public/p rivate key pair

′

ipub

′

iprv

), respectively (M

′

ipub

′

iprv

) that each of

them will use it on ly in one subtransaction. (4) The

Setup and Join phases of the G BDS protocol ( Ly sy-

anskaya and Ramzan, 1998) a re executed. Brieﬂy, the

T T P generates a secret key for group manager and

the group’s public key. CB and each M

B obtain from

T T P the group membership certiﬁcate.

3.3 Protocol Description

For an aggregate transaction, we deﬁne the aggrega-

tion o perator, denoted by ∧, as follows: Pid

∧ .. . ∧

Pid

meaning that C wishes to buy exactly k products

with product’s identiﬁers Pid

,...,Pid

. For an opti-

onal transaction , we deﬁn e the option operato r, 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 identiﬁers Pid

,...,Pid

, wher e

the appar ition order of the product’s id entiﬁers is the

priority given by C. T his 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 selecte d by C using ∧ and ∨ ope-

rators. For efﬁciency, to represent the tre e, we use the

left-child, right-sibling representation in that each in-

ternal node cor responds to one of the above oper ators

or to a product identiﬁer, while each leaf n ode corre-

sponds to a product identiﬁer. Each node of th e tree

is represented by a structure with the following ﬁelds:

info for sto ring the useful in formation (product iden -

tiﬁer or one of the oper ators), left for pointing to th e

leftmost ch ild of no de, and right for pointing to the si-

bling of the node immediately to the right. The access

to tr ee is realized trough the root.

An example of tree derived from the complex tr an-

saction 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 connectors

DB35 type and Pid

to PCB. The root node has ∧ ope-

rator as info. The root does not have any right sibling

and its children ar e the two nodes having ∨ opera-

tor as info and the nodes with the info Pid

and Pid

A parent-child link is realized as follows: the parent

ICE-B 2018 - International Conference on e-Business

102

Pid1

Pid2

Pid4

Pid6

Pid5

Pid3

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

child, right-sibling representation.

node p oints only to its leftmost child, and the rest of

its children can be accessed starting with the lef tmost

child via sibling relationship. The ﬁrst node having as

info ∨ operator deﬁnes the product corresponding to

the optional subtransaction Pid

∨ Pid

Next, we will describe the phases of the protocol.

3.4 Agreement Sub-protocol

We u se s

.fst to denote the ﬂag of a subtransaction

= (Sid

′

,Pid

,fst). s

.fst can have values from

the set {1, 2, 3, abort}. s

.fst = 1 means that s

successfully completed Agreement, s

.fst = 2 means

that s

successfully completed Delivery, s

.fst = 3 me-

ans th a t s

successfully completed Payment, and s

.fst

= abort means that s

has not successfully comple-

ted Agreement or Delivery, or su ccessfully completed

Agreement but had to be later aborted because s

be-

longs to an aggregate transaction for which another

subtransaction was already aborted.

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

quence of subtransaction s s

...s

correspo nding to

the product deﬁned by p. For a node p, Ns(p) is cal-

culated depending on the p → info as follows:

• if p → info = Pid

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

is returned by the the SAgree(C

′

,Pid

) sub-

protocol that will be detailed below. So, if the

subtransaction in that C

′

buys from M

the pro-

duct w ith the ide ntiﬁer Pid

successfully ﬁnished

Agreement, then Ns(p) = (Sid

′

,Pid

,1), ot-

herwise Ns(p) = (Sid

′

,Pid

,abort).

The SAgree sub -protocol will be detailed below in

Table 3.

• if p → info = ∨, then

Ns(p) =











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

of p such tha t s.fst = 1,

for all s ∈ Ns(l)

Ns(r), otherwise

where r is the rightmost child of p.

The node p corre sponds to ∨ operator w.r.t. the

customer’s choices and these preferences are prio-

ritized by appearance in the ch ild nodes of p from

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

leftmost child of p, denoted Ns(l), for which all

subtransactions from Ns(l) have successfully pas-

sed Agreement. Otherwise, if all subtransactions

from node states of all childr e n of p are aborte d,

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 s.fst = 1, for any s from Ns(c

), for any 1 ≤

j ≤ k, then Ns(p) = Ns(c

)...Ns(c

2. otherwise, let c

be, where 1 ≤ j ≤ k, the left-

most child of p with Ns(c

) = s

...s

such

that s

.fst = abort, for all 1 ≤ l ≤ m. In this

case, Ns(p) = Ns(c

)...Ns(c

). Even if the

subtransactions from Ns(c

) ,..., Ns(c

j−1

)

have successfully passed Agreement, the abor-

ted subtransactions f rom Ns(c

) lead to abor-

ting the entire aggregate transaction correspon-

ding to p. That is why all subtransactions from

Ns(c

),...,Ns(c

j−1

) will be aborted. Thus,

will set s.fst = abort, for any s ∈ Ns(c

), for

any 1 ≤ r ≤ j − 1 .

Because the nod e p correspon ds to ∧ operator,

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

ren. The sequence of node states of p’s children

is efﬁciently calculated until c

the leftmost child

of p for that Ns(c

) contains only abo rted subtran-

sactions.

Thus, Ns(p) is a sequence of subtransactions in

which either all subtransactions successfu lly passed

Agreement or all subtransactions are aborted. Exam-

ples of node states computation are presented in Ap-

pendix 5.

The Agreement sub-protocol, describ ed in Table

2, recursively calculates Ns(t) (t is the root of the tr ee

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.

Initially, bef ore the application the Agreement

sub-protocol in the ﬁrst round of the protocol,

Ns(p) = λ, for any no de p of the tree t (λ is empty

string). If the protocol does not terminate after the

ﬁrst round, then before starting a future round, the sta-

tes of the no des of tree are: some nodes q that corre-

sponds to the product identiﬁers have in Ns(q) a uni-

que aborted subtransaction ( because some substran -

sactions have been abor ted in previous rounds) and

all other nodes p have Ns(p) = λ. For efﬁciency, in

future r ounds, the protocol will not apply Agreement

to those nodes where their state is an aborted subtran-

saction (as we can see in the lines 1,6).

At the lines 2-3, if some conditions are met, the

protocol computes Ns(p) for a node p, depending on

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications

103

Table 2: Agreement sub-protocol.

Agreement(t)

1. if (t→left 6= NULL and s.fst 6= abort, for s ∈ Ns(t→left)) child[0] = Agreement(t→left);

2. if ((t→info = ∨ and s.fst = 1, for al l s from child[0]) or

3. (t→info = ∧ and s.fst = abort, for all s from child[0])) Ns(t) = child[0]; return Ns(t);

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

5. while (k 6= NULL)

6. if (s.fst 6= abort, for s from Ns(k)) child[j] = Agreement(k);

7. if (t→info = ∨ and s.fst = 1, for all s from child[j]) Ns(t) = child[j]; return Ns(t);

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

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

10. for (all s ∈ Ns(t) such that s.fst 6= abort) AggAbort(s); s.fst = abort; end for

11. return Ns(t);

12. k = k→right; j = j + 1; end while

13. if (t→info = Pid

) Ns( t) = SAgree(C

′

, M

, Pid

); return Ns(t);

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

15. while (k→right 6= NU LL) 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); end if

19. end if

the node state of the left most child of p. For a node

p with a least two children, the while loop (lines 5-

12) computes the nod e state of any child of p ex-

cept the left most one. The way in which node state

is computed is essential to obtain the fair exchange

and atomicity of a complex transaction ( lines 7-11):

if an aborted subtransaction/sequence of subtransacti-

ons leads to aborting the entire aggregate transaction,

but some subtransactions from the aggregate tra n-

saction successfully completed Agreement, then the

ones that are successfully must also be stored in the

node state corresponding to ∧ operator (line 9) and af-

terwards ab orted (line 10). In this case, for each sub-

transaction s that successfully comp le te d Agreement,

the AggAbort(s) procedure w ill be initiated by T T P

to cancel the coin involved in s in the same manner

with the messages 1.6

′

.i-1.7

′

i from Aborting proce-

dure (Table 3), and the ﬂag of s is set on abort.

For a node with a produ ct identiﬁer as info(line

13), the protoc ol a pplies the SAgree sub-protocol in

that the cu stomer establishes the agreement conditi-

ons with the merchant for buying th e produc t. Th e

node state fo r a node that c orresponds to ∨ operator,

for which all subtransactions from all its children are

aborted, is computed at the lines 14-16. The node

state for a node that corresponds to ∧ operator for that

all subtransactions from all its children successfully

completed Agreement, is computed at the lines 17- 18.

The subtransactions th at are initiated in a protoco l

round can bec ome aborte d in different ph ases of the

protocol without solving th e cu stomer’s o ptions. Bu t,

because the custom er can have many options w.r.t. the

products he wants to buy, new rounds of the proto-

col must be executed in which are not considered a ny

more the products that are information in the nodes

for that the node states have a substransaction already

aborted in a previous round.

Next, we will give details about

SAgree(C

′

,Pid

) sub-protocol presented in Table

3. In this sub- protoco l C buys a digital coin, validates

the coin to T TP, and establishes the agreement with

on the subtransactio n’s terms.

C g enerates a new digital coin that is a number c

of 256 bits consisting of a unique coin serial number

represented on the ﬁrst 224 bits and the coin value

in the last 32 bits. The p rotocol starts with running

the GBDS protocol between C and CB on the coin c

CB transfers the coin value from C

acct

to the co mmit-

buffer, and after running all steps of the GBDS proto-

col, C obtains sig

)-the signature of CB on c

behalf of the bank’s group. CB doesn’t know the se-

rial number of c

because h is signature on c

is blind,

and only knows the identity of the customer and the

value of some digital coin purchased by him.

After C gets the gr oup signature on c

, he va-

lidates at T T P an encrypted version of c

. C g e-

ICE-B 2018 - International Conference on e-Business

104

Table 3: SAgree sub-protocol.

SAgree(C

′

, M

, Pid

)

1.1.i. C

′

→T T P: Sid

, {Sid

, C

′

, M

, C

′

ipub

, K

}

T TP

pub

, {c

}

, sig

), sig

′

(sig

))

1.2.i. T T P→C

′

: Sid

, T

iT TP

, L

, N

iT TP

, S

iT TP

where S

iT TP

= sig

T TP

(Sid

, C

′

, M

, {c

}

, V

, T

iT TP

, L

, N

iT TP

)

1.3.i. C

′

→M

: Po

, sig

′

(Po

), {c

}

, V

, T

iT TP

, L

, N

iT TP

, S

iT TP

where Po

= Sid

, C

′

, M

, Pid

, Pr

, Q

, V

, DC

addr

, h(N

), C

′

ipub

if (M

agreement) 1.4.i. M

→C

′

: Sid

, sig

(sig

′

(Po

)), {M

′

ipub

}

′

ipub

return (Sid

′

,Pid

,1)

else if (1.4

′

.i. M

→C

′

: Sid

, sig

(Po

, abort)) Aborting(s

) end if end if

where the Aborting(s

) procedure consist of:

1.5

′

.i. C

′

→T T P: Po

, sig

′

(Po

), {c

}

, V

, T

iT TP

, L

, N

iT TP

, S

iT TP

1.6

′

.i. T T P→C

′

: Sid

, cancel, sig

T TP

(Sid

, c

, sig

), cancel)

1.7

′

.i. C→CB: Sid

, cancel, {c

, sig

), C, C

acct

}

pub

, sig

T TP

(Sid

, c

, sig

), cancel)

return (Sid

′

,Pid

,abort)

nerates a non ce Sid

as subtransaction identiﬁer,

a symmetric key K

and sends to T T P the mes-

sage 1.1.i. T T P obtains C

′

ipub

, K

by decrypting

{Sid

′

ipub

}

TT P

pub

, obtains c

by decrypting

}

, and uses C

′

ipub

to verify the sign ature of the c u-

stomer o n the signed coin. T T P checks the validity of

by verifying sig

) using the group public key,

and checks whether c

has already been spent, or vali-

dated by T T P (in a previous request) but not yet spent

or canc e le d, by verifying the spent ﬂag of the c

’s se-

rial in the global list of coin’s serial. If all checks out,

T T P adds c

in the list setting the c

’s spent ﬂag on 0,

and sends to C th e message 1.2.i. The message 1.2.i

contains a timestam p T

iT TP

, a lif etime of encrypted

coin’s validity L

, a nonce N

iT T P

all to avoid replay

attacks, and S

iTT P

- the signature of T T P. On recep-

tion, C checks if T

iT TP

and L

are recently enough, and

then veriﬁes S

iTT P

C initiates the agreement by sending to M

the

message 1.3.i. Po

contains h(N

) whose goal is to

be u sed as a barcode on the pr oduct and is set by M

such that only who knows the password N

can col-

lect the product from DC

addr

; N

is kept secret by C,

while M

receives h(N

On reception of the message 1 .3.i, M

veriﬁes Po

if T

iT TP

and L

are recently eno ugh, the sig nature of C

on Po

, and S

iT TP

. If M

is satisﬁed (meaning that

the value of the boolean variable M

agreement is

1), S

iTT P

assures him that {c

}

represents the en-

cryption of a valid coin (that was signed by a bank

from the gr oup, an d its lifetime has not expir ed) of

value V

from Po

. Thus, M

sends to C the mes-

sage 1.4.i to e nsure C b y M

’s agreemen t. After re-

aching the agreement, s

= (Sid

′

,Pid

,1) is re-

turned as the state of the node w ith info Pid

. If M

is not satisﬁed, h e sends an abort message 1.4

′

.i to C

who applies Aborting(s

) procedure. In Aborting(s

C cancels c

in the messages 1.5

′

.i-1.7

′

.i and s

(Sid

′

,Pid

,abort) is returned a s the state of the

node with info Pid

. To cancel the coin, C sends 1.5

′

to T T P that checks it and sends b ack a cancellation

request in 1.6

′

.i. Further, C sends th is request to CB

who checks sig

), T T P’s signature and if c

has

not already been spent or canceled. If all checks are

satisﬁed, CB sets the spent ﬂag of c

to 2, transfers the

coin value from commit-buffer to C

acct

, and sends to

C a signed acknowledgment of suc cessfully cancella-

tion of c

. So, c

’s value is redeemed by C. If after M

receives 1.3.i, he doesn’t contin ue the sub-protocol, C

will apply Aborting(s

After Agreement is completed, Ns(t − root) is

stored in the variable Ps th at indicates the protocol

state. So, Ps is the sequence of th e subtransactions

for which all successfully completed Agreement or all

aborted.

3.5 Delivery Sub-protocol

If all subtransactions from Ps successfully completed

Agreement, then Delivery can be started to physically

deliver the products involved in any subtransaction

from Ps

In the Table 4 we give details about Delivery sub-

protocol for an arbitrary subtransaction s

. The pro-

duct P

has a barcode h(N

) set by M

to control the

access of C to DC. P

with this barcode is ta ken by

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications

105

Table 4: Delivery sub-protocol.

2.1.i. M

→ DA

: Sid

, Pid

, DC

addr

,{M

, M

′

ipub

}

ipub

, sig

(Sid

, M

, Pid

, DC

addr

)

2.2.i. M

→ DA

: Sid

, P

2.3.i. DA

→ M

: Sid

,sig

(Sid

, M

, Pid

, DA

, DC

addr

)

2.4.i. DA

→ DC: Sid

, P

2.5.i. DC → DA

→ M

→ C

′

: Sid

,sig

(Sid

, M

, Pid

, DA

, DC

addr

)

2.6.i. DC → C

′

: Sid

, P

2.7.i. C

′

→ DC: Sid

, sig

′

(Sid

, M

, Pid

, DC

addr

, C

′

, N

)

from M

to be delivered. M

sends to DA

a de-

livery request message 2.1.i. DA

obtains M

′

ipub

and

checks the signatu re of M

. In the message 2.2 .i, DA

collects the product P

from M

. To conﬁrm the co l-

lection of P

, DA

sends to M

an acknowledgment in

the message 2.3.i. In the message 2.4.i, DA

posts

to DC. Upon receiving P

from DA

, DC conﬁrms

him in the message 2.5.i by a signed a cknowledgment

which DA

forwards to M

, and M

to C. C collects P

from DC using N

and check s if the collected product

meets the speciﬁca tions from Po

. If C is satisﬁed, he

sends in the message 2.7.i a signed acknowledgment

to DC.

If all subtransactions from Ps successfully com-

pleted Delivery, then each subtransaction’s ﬂag from

Ps is set to 2.

3.6 Payment Sub-protocol

If C collects all products involved in any subtran-

saction from Ps and is satisﬁed, then he sends the

paymen t for each product to the suitable merchant.

Below, we present the Payment sub-protocol for an

arbitrary subtran saction s

from Ps.

3.1.i. C

′

→ M

: Sid

,{K

}

′

ipub

,sig

′

),sig

)

obtains K

, veriﬁes sig

′

), and recovers c

by decryptin g with K

the encrypted coin received in

the message 1.3 .i. M

veriﬁes the validity of sig

)

and, if c

is valid, he sends it to M

B in the message

3.2.i for redemption.

3.2.i : M

→ M

B : Sid

,{co

,sig

(co

sig

(co

,sig

(co

)),M

iacct

}

pub

B checks M

’s signature, checks sig

) and

uses the global list of the coins to check if c

has

already been spent or canceled. If all checks are

satisﬁed, M

B updates the global list by setting the

spent ﬂag of c

on 1, transfer s the c

’s value from

commit-buffer to M

iacct

, and sends to M

a signed

acknowledgment of suc c essfully redemption of c

;

otherwise, M

B sends to M

an error message.

3.3.i. M

B → M

: sig

(ack)

If all subtransactions from Ps successfully com-

pleted Payment, then ea c h subtransaction’s ﬂag fr om

Ps is set to 3.

If in a subtransaction s

from Ps, C does no t

send to M

the decryption key K

of the encryp-

ted coin or sends to M

in 3.1.i a wrong decryp-

tion key, then M

sends to T T P all the messages re-

ceived/sent from/to C in s

. TT P checks the mes-

sages of s

and if all c hecks are successfully, then

sends K

to M

, the key that is in possession of

T T P from the Agreement sub-protocol: T T P → M

Sid

,{K

}

′

ipub

,sig

T TP

),sig

). M

decryp ts c

using K

, checks the validity of sig

) and conti-

nues the sub-protocol with 3.2.i.

3.7 The Complex Transaction Protocol

Next, we describe the protocol for c omplex transacti-

ons, presented in Table 5, that relies on the three pha-

ses discu ssed above. t is the root of the tree der ived

from the choices of C. Initially, Empty(Ns(t)) sets

Ns(p) = λ, for any node p of the tree t. A while ite-

ration executes a round of the protocol, that executes

the three phases of the protocol. At the line 3, Ps vari-

able retains the sequence of subtra nsactions that have

run Agreement corresponding to options p rovided by

C. If all subtransactions from Ps successfully comple-

ted Agreement, then Delivery ma y take place to phy-

sically deliver the products involved in any subtran-

saction fr om Ps. At the line 5, Ps retains the sequence

of subtransactions that h ave run Delivery. Further,

if all su btransactions from Ps successfully completed

Delivery, then Payment takes place and the seq uence

of subtransactions that solves the options of C is re-

turned.

If after Agreement took place, Ps is a sequence of

subtransactions that are all aborted, then the options

of C can not be successfully solved. In this case, at the

line 10, the subtr ansactions sequence will be returned

ICE-B 2018 - International Conference on e-Business

106

Table 5: The Complex Transaction Protocol.

1. Empty(Ns(t));

2. while (1)

3. Ps = Agreement(t);

4. if (s.fst = 1, for all s from Ps)

5. Ps = Delivery(Ps);

6. if (s.fst = 2, for al l s from Ps)

7. Ps = Payment(Ps); return Ps;

8. else Aborting(s), for all s from Ps;

9. Update(t); end if

10. else return Ps; end if end while

as an evidence of the protocol’s failure.

The c a se in that after Agreement took place, all

subtransactions s

...s

from Ps successfully comple-

ted Agreement, but so me of these subtransactions did

not successfully completed Delivery of physical pro-

ducts (e.g. some me rchant doesn’t p ost the product

or posts a wrong p roduct), is treated at th e line 8. In

this case, the Aborting(s

) procedure is applied for all

1 ≤ i ≤ k, to abort all the substransactions from Ps

that successfully completed Agreement. Acc ording to

assumption 7 from the section 3.1, DC has a device

that allows C to send to T T P the encrypted recording

of the moment when C receives products that are not

in conformity with the agreement established. The

identiﬁers of these products are stored in the buffer

PidsAborted used at the line 9 to update the tree with

the root t. Update(t) updates Ns(p), for any node p

of the tree, as follows:

• if p → info = Pid

, with 1 ≤ i ≤ n, then

we have the following cases: if Ns(p) has

the ﬂag on abort, then Ns(p) remains unchan -

ged; if p → info ∈ PidsAborted, then Ns(p) =

(Sid

′

,Pid

,abort); in all other cases Ns(p)

= λ.

• if p → info 6= Pid

, with 1 ≤ i ≤ n, then Ns(p) = λ.

By Update(t), the states of the nodes corresponding

to pro ducts from aborted subtransactions in the cur-

rent pr otocol’s round are mentaine d in the tree with

the root t, so that these products are not taken into

consideration in a new protocol’s round.

In a new round (while itera tion), the protocol se-

arches a new sequence of subtransactions that will

successfully ﬁnish all three sub-protocols, and in this

way satisfying the options of C. The protocol termi-

nates when encounters a roun d in which the proto-

col state Ps computed after that round contains a se-

quence of sub transactions that solves C’s options, or

when encounters a round in that Ps computed after

Agreement has all subtransactions aborted. In the last

case, the protocol can not solve the optio ns of C.

4 SECURITY ANALYSIS

4.1 Fair-exchange

For a tree t that describes th e choices of C, we deﬁne

solve(t) - the sequence of produc ts obtained by C after

the proto col execution and that solves the choices of

C. solve(t) is deﬁned depending on the protoco l state

Ps calculated after the protocol execution.

If after a protocol’s round Ps = s

...s

such

that s

.fst = 3 for any 1 ≤ i ≤ m, then solve(t) =

Pid

...Pid

meaning the products from all subtran-

sactions that successfully term inates all three sub-

protocols. Otherwise, if in a protocol’s round after

Agreement sub-pr otocol, Ps is a sequence of a borted

subtransactions, then solve(t) = abort meaning that

the protocol can not solve the optio ns of C.

Our protocol assures fair exchange if after the pro-

tocol execution, either C gets the sequence of physi-

cal products solve(t) = Pid

...Pid

and eac h M

gets

the payment for th e pr oduct Pid

, where 1 ≤ i ≤ m,

or none do. From the construc tion of our protocol,

after its execution, C can obtain either a sequence of

products that solves his choices, or nothing. Further-

more, after the protocol execution, C can ’t obtain a

sequence of prod ucts Pid

...Pid

6= solve(t).

If C an d each M

, where 1 ≤ i ≤ n, behave hone-

stly, the proposed protocol assures fair excha nge. In

what follows, we will consider all possible scenarios

in which any M

or C behave dishonest or prematurely

abort the protocol.

If C behaves dishonest, th en the following scena-

rios are possible:

1. After Delivery sub-protocol took p la c e in some

protocol’s round, Ps = s

...s

is a sequence of

subtransactions that successfully completed De-

livery sub-protocol. So, C collected all products

involved in any subtransaction from Ps and he is

satisﬁed. However, Payment sub-protocol, for a

subtransaction s

from Ps, where 1 ≤ i ≤ k, C does

not send to M

the decryption key of the encrypted

coin or sends to M

a wrong decryption key. This

scenario is solved as mentioned in Payment sub-

protocol, T T P providing to M

the correct key.

2. C sends the same coin to T T P (in 1.1.i) in two

different sessions of Agreement sub-protocol, to

initiate two different subtransactions s

, s

with

two distinct merchants, in the same round or in

different rounds of the protocol. This scenario

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications

107

is solved because all banks an d T T P maintain a

global list of coin’s serial already spent, valida-

ted but unspent, or cance le d. On rec e ption from C

of the ﬁrst request for coin validation, T T P adds

the coin to the list, an d a ny new validation request

of the same coin fr om C is detected by T T P that

aborts s

by s

.fst = abort.

3. In a subtransaction s

from Agreement sub-

protocol, C sends to M

in 1.3.i, an encrypted coin

already spent, or already canceled or of insufﬁ-

cient value. If the coin is already spent but wasn’t

used to buy from M

, then M

detects this by ve-

rifying S

iT TP

. Otherwise, if the c oin was already

used to buy from M

, then M

can check this by

verifying Sid

and N

iT TP

. If the coin was a lready

canceled, then M

detects this becau se T

iT TP

and

are not recently enough. If the coin is of in-

sufﬁcient value, M

detects this by checkin g if the

value from Po

is equal with the encrypted coin’s

value validated by T T P. So, M

detects double

spending/double cancelling/insufﬁcient coin’s va-

lue from C, and aborts s

by s

.fst = abort.

4. In Agreement sub-protoc ol, C sends to CB 1.7

′

many times for multiple redemp tion of the same

canceled coin . This scenario is solved because

CB c hecks if the coin received in a cancellation

request has already been ca nceled.

If M

behaves dishonest, then the following scenarios

are possible:

1. In a subtransaction s

from Agreement sub-

protocol, M

receives from C

′

a correct message

1.3.i, but he sends to C

′

an abort message 1.4

′

or doesn ’t continue the sub-protocol. Suc h beha-

vior brings no beneﬁt to M

because he is in pos-

session of an encrypted coin with a key that does

not know, so he can’t get the payment. But C has

bought a coin which can not be used by him. In

both scenarios, C applies Aborting(s

) to cancel

and to redeem the coin, and to abort s

. If the

aborted s

is a component of an aggregate tran-

saction, then all other su btransactions from the

aggregate that successfully completed Agreement

sub-protocol will be aborted by AggAbort proce-

dure and by setting their ﬂags on abort.

2. After Agreement sub-protocol took p la ce, Ps =

...s

is a sequence o f subtransactions that

successfully completed Agreement sub-protocol.

In s

from Ps, M

sent 1.4.i to C

′

, but in Delivery

sub-protocol he doesn’t post the product o r posts

a product that doesn’t com ply w ith the speciﬁca-

tions from Po

. M

does not have any beneﬁt from

this behavior, but can prejudic e the other honest

merchan ts involved in s

...s

. In s

, C pushes the

button o f the DC’s device tha t allows sending to

T T P the recording o f the mome nt when C un-

wraps the packed pr oduct, proving to T TP that

the product is wrong. Becau se the product from s

is not complying with the spec iﬁca tions from Po

the rest of the products involved in the sequence

...s

can’t lead to solve(t). So, C sends to

T T P all the messages received/sent from/to each

, where 1 ≤ j ≤ k. T T P checks the informa-

tion received from C, applies Aborting(s

), where

1 ≤ j ≤ k and triggers an off-line procedure sen-

ding to M

the proof of his dishonest behavior.

Also, T T P requests from M

the payment for the

transportation services of pro ducts provided by

the honest merchants to DC and ba ck. After T T P

receives the payment, he returns the transportation

costs to each honest merchant from s

...s

3. I n Payment sub-protoc ol, M

sends many times the

same 3.2.i fo r multiple redemption of the same

coin. This scenario is solved by M

B checking if

the coin received in 3.2.i has already been spe nt.

Each party involved in the proto col must keep a

record of every message sent or received in protoc ol

including signed acknowledgments of DC and DA

where 1 ≤ i ≤ n. DC and DA

, wh ere 1 ≤ i ≤ n, h ave

no interest not to follow the protocol steps, be cause

their interest is to get proﬁt f rom fees for such servi-

ces provided in e-commerce transactions. However, if

one of the parties mentioned above behaves dishonest,

the other parties send the recor ds to T T P to trigger

off-line mechanisms to ensure fairness.

4.2 Anonymity

Our protocol ensures the cu sto mer’s anonymity if no

party and no coalition between parties can make a link

between the true identity of the customer, C, and the

pseudo identity of the customer, C

′

, which he uses in

protocol.

In our protocol, we use an electronic cash payment

based on group blind digital signatures on beh alf of

the banks. The only steps fr om our pro tocol in that

the custom er uses his true identity are the GBDS pro-

tocol’s steps and in the message 1.7

′

.i in that the cus-

tomer cancel his coin, because CB must know C

acct

charge it with the coin’s value or to redeem the coin’s

value. In the GBDS protocol, CB k nows only that

C bought a coin with a certain value, but it doesn’t

know the ser ia l of the coin. Following, CB can’t as-

sociate C with the coin bought by him, mainta ining

thus the anonymity of the custo mer. Also, in the mes-

sage 1.7

′

.i, the customer reveals his true identity only

to CB, but this do es not destroy the customer’s ano ny-

mity because the coin will be canc e le d and not used

ICE-B 2018 - International Conference on e-Business

108

Table 6: Informations that each party knows after protocol

execution.

Entity

Info C M

CB M

B DA

C y n y n n n

y y n y y n

CB y n y n n n

B n y n y n n

n y n n y y

DC y y n n y y

′

y y n n n y

y y n y n n

C&s

y n n n n n

′

y y n n n y

anymore. Another feature of the GBDS p rotocol is

the anonymity of CB: any party can check if sig

)

is valid, without knowing who is the bank that signed

the coin c

. CB is not known by any other party (ex-

cept C), so, CB ca n’t participate in no coalition with

any othe r party to destroy the customer’s anonymity.

To ensure the customer’s anonym ity when C co llec ts

the ph ysical products, our protocol doesn’t use the cu-

stomer’s correspondence address but uses a de stin a -

tion cabinet where the product is placed.

We show in Ta ble 6, the inform ation that each

party in the protocol knows after protocol execution.

The information have the following meaning. For ex-

ample, we consider the ﬁrst row: y under the c olumn

C and CB means that C and CB know C - the true iden-

tity of the customer; n un der the co lumn M

, M

B, DA

and DC means that the true identity of the custo mer is

not known to M

, M

B, DA

and DC. C&s

means that

C p erforms the subtransaction s

. The meaning is ex-

tended for C

′

From the Table 6, we observe that no party alone

has sufﬁcient in formation to link the true identity of

the customer, C, with the pseudo iden tity C

′

. Only C

can disclose this information if he wants.

We analyze the coalition of the maximum size

that can be formed b y parties involved in protoc ol to

try to destroy the customer’s anonymity. The coali-

tion of the maximum size consists of the following

parts: M

,...,M

B,... , M

B,DA

,...,DA

, and

DC. For any 1 ≤ i ≤ n, DA

has info rmation only

about entities M

, and DC, and no inf ormation a bout

C. For any 1 ≤ i ≤ n, M

B have no information about

C. DC has the information C

′

,...,C

′

, but no

informa tion about C. For any 1 ≤ i ≤ n, M

has the in-

formation C

′

. So, th e only information related to

customer obtained b y the coalition of the maximum

size is C

′

,...,C

′

, but no information about the

customer’s true id e ntity. Thus, the customer’s anony-

mity is preserved.

5 CONCLUSIONS

Fair exchange in complex tran sactions is much har-

der to o btain compare to fair exchange in a subtran-

saction, b ecause fair exchange obtained in all su btran-

sactions from a complex transaction does not directly

implies fair exchang e in entire complex transaction.

The complexity of our protocol is higher for complex

transactions containing both aggregate and optional

transactions then for complex transactions containing

only aggregate transactions. The requirement fo r op-

tional transactio ns impose the protocol execution in

multiple rounds to solve the customer’s o ptions. We

remark that obtaining the customer’s anonymity in

complex transactions is not simple. To obtain the ano-

nymity of the customer, the challen ge in our protocol

was to guarantee this requirement both in payment

and collection of physical products.

We proposed an e-c ommerce protocol taking into

consideration severa l requirements that are not con-

sidered so far together in literature: physical pro-

ducts delivery, aggregate transaction, optional tran-

saction, fair exchange and anonymity. If some of the

requirements mentioned ab ove are not needed in an

e-commerce application, then we will use simpliﬁed

versions of the proposed protocol. Thus, if optio-

nal transactions are not required in a complex tran-

saction e-commerce protocol, then only one round of

the protocol is necessary and Agreement sub-protocol

is replaced with customer initiating simultaneously all

subtransactions for agreement on terms. If the c usto-

mer’s anonymity is not required, then a simpler pay-

ment method that replaces GBDS protocol is used.

Also, in th is case, the destination cabinet and all mes-

sages involvin g him are elim inated.

Future work will include formal veriﬁcation of the

proposed protocol and extending the protocol by ta-

ken into consider ation of active intermediary agents

(that are not delivery agents) between customer and

merchan ts.

REFERENCES

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

protocol. International Journal of Computer Net-

works & Communications (IJCNC).

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

in e-commerce protocol for physical products deli-

Preserving Anonymity in Fair Exchange Complex Transactions E-Commerce Protocol for B2C/B2B Applications

109

very. In 12th International Conference on Security

and Cryptography. SCIT EPRESS.

Djuric, Z. and Gasevic, D. (2015). F eips: A secure fair-

exchange payment system f or 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,.

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.

Lysyanskaya, A. and Ramzan, Z. (1998). Group blind sig-

nature: a scalable solution to electronic cash. In Fi-

nancial Cryptography. Springer.

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

Party Non-Repudiation Protocols and Applications.

Springer.

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.

APPENDIX

For some nodes of th e tree from Figure 1, we will

give computation example of node states:

• If p is the node with p → info = Pid

then Ns(p) = (Sid

′

,Pid

,1) if

the subtransaction with identiﬁer Sid

successfully ﬁnished Agreement; otherwise

Ns(p) = (Sid

′

,Pid

,abort).

• If q is the ﬁrst node with q → info = ∨ then:

Ns(q) = s

, whe re s

= (Sid

′

,Pid

,1),

if the subtransaction s

successfully ﬁnished

Agreement; otherwise, Ns(q) = s

, where s

(Sid

′

,Pid

,fst) and s

.fst ∈ {1,abort}.

• If t the root node, c

the ﬁrst node (from left) with

→ info = ∨, c

the second n ode with c

→ info

= ∨, c

the node with c

→ info = Pid

and c

the

node w ith c

→ info = Pid

, then:

– if Ns(c

) = s

, Ns(c

) = s

, Ns(c

) = s

and

Ns(c

) = s

, where s

= (Sid

′

,Pid

,1)

with i ∈ {1,4,5,6} , then Ns(t) = s

– if Ns(c

) = s

, Ns(c

) = s

above, but Ns(c

) = s

with s

(Sid

′

,Pid

,abort), then Ns(t) = s

and s

, s

will be aborted.

ICE-B 2018 - International Conference on e-Business

110