Anonymity and Fair-Exchange in e-Commerce Protocol for Physical

Products Delivery

C˘at˘alin V. Bˆırjoveanu

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

Keywords:

Electronic Commerce Security, Anonymity, Fair-Exchange, Security Protocols.

Abstract:

Fair exchange and customer’s and merchant’s anonymity are two important properties of e-commerce trans-

actions. There is to date a variety of proposed e-commerce protocols to achieve fair exchange and customer’s

anonymity for transactions involving digital products. For physical products delivery there is no e-commerce

protocol to provide fair exchange and customer’s and merchant’s anonymity. In this paper, we propose the

ﬁrst e-commerce protocol for physical products delivery that will provide fair exchange in all circumstances,

anonymity of customer and merchant for any collusion that can be formed, non-repudiation, integrity and

conﬁdentiality of data exchanged between the parties.

1 INTRODUCTION

The electronic commerce (e-commerce) has grown

rapidly and dynamically, becoming a part of everyday

life. It is difﬁcult for the customer and the merchant

to trust each other in the online environment. There

are many proposed solutions in which the customer

sends the payment ﬁrst, but in this case the customer

may have losses if the merchant behaves dishonest

and does not send the product to customer. Also, if the

merchant sends the product ﬁrst, then the customer

might not send the payment to merchant, and in this

way the merchant is prejudiced. Therefore, in order

to solve the situations like the ones mentioned above,

is necessary to design the fair-exchange e-commerce

protocols. The fair-exchange ensures that either the

customer gets the product and the merchant gets the

payment for product, or none do.

Fair-exchange protocols are used in different con-

texts to exchange payments and digital products (as

computer software, digital books, etc.) (Li et al.,

2006); payments and physical products (as laptops,

phones, etc.) (Alaraj, 2012),(Li et al., 2006),(Zhang

et al., 2006); email and receipt; and two digital signa-

tures on a document.

To achieve fair exchange, most of the proposed

protocols are based on a Trusted Third Party (TTP)

that acts like item validator or to solve the disputes.

Anonymity of customer and merchant is also a

key property that must be considered in a fair-

exchange e-commerce protocol. The customer may

want not to reveal sensitive data of his identity (as

credit card number, information about customer’s

bank, customer’s account number) so that this in-

formation can not be used by merchant in commer-

cial purpose to build spending habits of the cus-

tomer. An e-commerce protocol provides the cus-

tomer’s anonymity if no party and no coalition be-

tween parties can make a link between the true iden-

tity of the customer and actions taken by him. Also,

the merchant may want to remain anonymous in e-

commerce transactions. For example, a merchant who

has business in many areas may want that his cus-

tomers can not link transactions where the merchant

is involved in all these areas.

Among the protocols proposed to date for physi-

cal products delivery (Aimeur et al., 2006), (Alaraj,

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

of them provide fair exchange and customer’s and

merchant’s anonymity. In (Zhang et al., 2006), the

authors claims that the proposed e-commerce proto-

col for physical products delivery guarantees fair ex-

change and anonymity of both the client and the mer-

chant. There are several problems with the proto-

col proposed in (Zhang et al., 2006). First, in the

physical delivery of the product to cabinet is not take

into consideration a delivery agent. Thus, the pro-

tocol works only in certain particular scenarios in

which the merchant can directly access the cabinet

from which the client collects the product. This is

difﬁcult to achieve in an e-commerce environment

in which the customer and the merchant are not lo-

170

V. Bîrjoveanu C..

Anonymity and Fair-Exchange in e-Commerce Protocol for Physical Products Delivery.

DOI: 10.5220/0005508801700177

In Proceedings of the 12th International Conference on Security and Cryptography (SECRYPT-2015), pages 170-177

ISBN: 978-989-758-117-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

cated in the same geographical area. Secondly, it

does not provide anonymity of customer and mer-

chant. There are collisions between two parties (such

as customer and merchant’s bank) that destroy the

merchant’s anonymity and, also there are collisions

between three parties (such as merchant, merchant’s

bank and customer’sbank) that destroy the customer’s

anonymity. In (Aimeur et al., 2006) is proposed a pro-

tocol for physical product delivery that ensures the

customer’s anonymity, but does not discuss how to

make the payment and how it ensures fair-exchange.

In (Alaraj, 2012) and (Li et al., 2006) are proposed

e-commerce protocols that ensure fair-exchange for

physical product delivery, but they do not take into

consideration the anonymity issue.

In this paper, we propose the ﬁrst protocol for

physical products delivery that will provide fair ex-

change in all circumstances, anonymity of customer

and merchant for any collusion that can be formed,

non-repudiation, integrity and conﬁdentiality of data

exchanged between the parties.

The paper is structured as follows: section 2 gives

an informal description of our protocol, section 3

presents the protocol, section 4 provides an analysis

of the proposed protocol and section 5 contains the

conclusion.

2 INFORMAL DESCRIPTION

The goals of our protocol are to obtain the fair ex-

change of physical product and electronic payment

between a customer and a merchant and also to pro-

vide anonymity for both of them. The protocol uses

an online Trusted Third Party (TTP) that will vali-

date the coins of the customer and will provide fair

exchange of items if any party misbehaves or prema-

turely aborts.

Both customer and merchant may choose to re-

main anonymous during the protocol execution. To

ensure anonymity in the payment phase, our protocol

uses the electronic cash payment mechanism based on

group blind digital signatures on behalf of the banks

proposed in (Lysyanskaya and Ramzan, 1998). This

mechanism provides anonymity of the customer and

anonymity of the bank that issues the electronic cash.

Moreover, after the way it is used in our protocol, it

provides anonymity of the merchant in the payment

phase.

To ensure anonymity of the customer and the mer-

chant in the physical product delivery phase, our pro-

tocol is based on existence of a delivery agent whose

role is to take the product from a source cabinet and

provide it to a destination cabinet. Both source cab-

inet and destination cabinet provides access to the

physical products by passwords to conceal true iden-

tity of the customer and the merchant.

Informally, the protocol works as follows:

The customer decides the product he wants to buy

and in what follows the customer buys a digital coin

of appropriate value from his bank and validates this

coin to TTP. The customer sends to the merchant the

purchase order and the digital signature of TTP on the

encrypted coin. The merchant uses a delivery agent

to send the product to the customer. After the prod-

uct is posted to the destination cabinet, the customer

collects the product and he provides to the destina-

tion cabinet an evidence of the product collection and

sends to the merchant the decryption key of the coin

and his bank’s signature on the coin. The merchant

sends the coin to his bank for redemption. The mer-

chant’s bank veriﬁes the validity of the coin and then

transfers the coin value in the merchant’s account.

3 THE PROTOCOL

In the Table 1 are presented the notations used in the

description of the proposed protocol.

3.1 Assumptions

The following assumptions are made for our protocol:

(1) All parties use the same algorithms for encryp-

tion, hash, digital signature and the same group blind

digital signature protocol mentioned in the Table 1.

(2) Cryptographic algorithms are strong enough. (3)

TTP is the group manager, namely Central Bank, that

is known by all parties implied in protocol. TTP does

not misbehave or collude with any of parties to pro-

vide beneﬁts to another party. (4) C and M each have

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

and group manager share a commit-buffer in that the

transaction value is stored until the transaction is com-

pleted successfully or aborted. (6) All banks from

group and group manager maintain a global list of

coin’s serial already spent, validated but unspent, or

canceled, to allow any bank to check a digital coin for

double-spending or double-canceling. Each record in

the list includes besides the coin’s serial, a spent ﬂag.

The value of this ﬂag corresponds to the current state

of the coin. The spent ﬂag has three possible values:

spent = 0 means that the coin is validated by TTP

but not yet spent, spent = 1 means that the coin has

already been spent, spent = 2 means that the coin has

already been canceled. (7) A source cabinet SC ex-

ists, where the physical product is placed by M, and

DA can take the product from SC only by knowing

AnonymityandFair-Exchangeine-CommerceProtocolforPhysicalProductsDelivery

171

Table 1: Notations used in the protocol description.

Symbol Interpretation

C/C

′

, M/M

′

True identity/pseudo identity of the customer and the merchant

CB, MB, DA, TTP Customer’s Bank, Merchant’s Bank, Delivery Agent and Trusted Third Party

SC/DC The source/destination cabinet from which the product must be taken/posted by DA

addr

/DC

addr

The mailing address of SC/DC

acct

Customer’s/Merchant’s bank account with CB/MB

Pid The identiﬁer of the product that C wants to buy from M in the current transaction t

Pr, Quantity, Po Price, quantity, purchase order used to order the product with Pid identiﬁer

A → B : m A sends the message m to B

DC → DA → M

′

→ C

′

: m DC sends to DA the message m that is forwarded by DA to M

′

and by M

′

to C

′

pub

prv

Public/private key pair of A

′

ipub

′

iprv

One time public/private key pair of A used only in the transaction t

{m}

′

The message m encrypted with the key K

′

h(m) The digest of m obtained by applying of a hash function h, such as SHA-1

sig

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

prv

on h(m)

TTP

, L Timestamp generated by TTP, lifetime of encrypted digital coin’s validity

, n, K Nonce generated by A, digital coin generated by C, AES symmetric key that encrypts n

sig

(n) CB’s signature on n obtained by running the Group Blind Digital Signature Protocol

a password that is set by M when he puts the prod-

uct in. In the physical delivery of the product phase,

we use SC to replace the correspondence’s address of

M. So, the true identity of M remains hidden if it

wants. Also, a destination cabinet DC exists, where

the physical product is provided by DA, and C can

collect the product from DC only by knowing a pass-

word that is set by M. The purpose of using DC is

to hide the true identity of C if he wants. SC and DC

have the ability to digitally sign messages, verify dig-

ital signatures on messages and to check if the pass-

word entered by DA, respectively C corresponds to

the barcode set on product. After DA/C provides the

correct password, SC/DC opens a hatch where packed

product is available to DA/C. DC has a video camera

mounted that records the moment when C unwraps

the packed product and check if the product is the

ordered one. DC has a device that allows to C, by

pushing a button, to send the encrypted recording to

TTP. C uses this feature only in the case is not satis-

ﬁed with the product as an evidence of wrong product

reception. Otherwise, the recording is automatically

deleted. (8)Communication channels that are set be-

tween parties provides anonymity, except the cases in

that the parties choose to reveal their true identities.

3.2 Prelude

We assume that before the starting of the protocol, the

following system setup steps are executed: (1) TTP

generates a public/private key pair, (TTP

pub

,TTP

prv

)

and provides the public key TTP

pub

to C and M. (2)

When C and M create accounts to their banks, each of

them generates a public/private key pair, (C

pub

prv

)

and (M

pub

prv

), respectively. C provides his public

keyC

pub

to CB and M provides his public key M

pub

MB. The banks maintain databases with public keys

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

respectively M, generates a one time public/private

key pair, (C

′

ipub

′

iprv

), respectively (M

′

ipub

′

iprv

) that

each of them will use it only in the current transaction.

(4) The Setup and Join phases of the Group Blind

Digital Signature Protocol (GBDS Protocol) (Lysyan-

skaya and Ramzan, 1998) are executed. Brieﬂy, this

means that the group manager TTP generates a secret

key for group manager and the group’s public key. CB

and MB obtain from TTP the group membership cer-

tiﬁcate.

3.3 Protocol Description

In the following we describe our protocol, splitting

it in four phases. The messages exchanged in the

protocol are shown in the Figure 1.

Phase 1: Buying and Validating Digital Coins. Af-

ter C ﬁnds the physical product he wants to acquire

from M, he will contact his bank to buy a digital coin

with the value that he must pay to M. C generates a

new digital coin that is a number n of 256 bits consist-

ing of a unique coin serial number represented on the

ﬁrst 224 bits and the coin value represented in the last

SECRYPT2015-InternationalConferenceonSecurityandCryptography

172

3.6

3.7

3.4

3.5

3.9

3.8

3.1

3.2

4.1

3.7

2.2

2.1

TTP

1.2

1.1

3.3

3.7

4.3

4.2

GBDS

Figure 1: Messages exchanged in protocol.

32 bits. The protocol starts with running the GBDS

Protocol between C and CB on the digital coin n. The

coin’s value is sent byC to CB by signing it. CB trans-

fers the coin value from C

acct

to the commit-buffer,

and after running all steps of the protocol, C obtains

sig

(n)-the signature of his bank on the digital coin

n on behalf of the bank’s group. In this phase, CB

knows the identity of the customer and the value of

some digital coin purchased by him, but it doesn’t

know the serial number of the coin because his sig-

nature on the coin is blind.

Message 1.1: C

′

→ TTP :

′

ipub

,K}

TTP

pub

,{n}

sig

(n),sig

′

(sig

(n))

After C gets the group signature on the digital

coin, he validates at TTP an encrypted version of the

digital coin. For this, C generates a symmetric key

K and sends to TTP a message that contains the fol-

lowing informations: C

′

, M

′

, the one time public key

′

ipub

that the customer will use only in the current

transaction t

, the key K, which are encrypted with

TTP’s public key to provide conﬁdentiality; the digi-

tal coin n encrypted with the key K; his bank’s signa-

ture on the digital coin - sig

(n); and his signature

on the sig

(n).

On reception of the message 1.1, TTP decrypts

ﬁrst encrypted component of the message and obtains

the one time public keyC

′

ipub

ofC and the key K. TTP

obtains the digital coin n by decrypting the ciphertext

{n}

with the key K and uses the C

′

ipub

to verify the

signature of the customer on the signed coin. TTP

checks the validity of the digital coin n by verifying

the signature sig

(n) using the group public key, and

checks whether this coin has already been spent, or

validated by TTP (in a previous request) but not yet

spent or canceled, by verifying the spent ﬂag of the

coin’s serial in the global list of coin’s serial. If all

checks out, TTP add the coin in the list setting the

coin’s spent ﬂag on the value 0, and sends to the cus-

tomer the following message:

Message 1.2: TTP → C

′

: T

TTP

,L,N

TTP

sig

TTP

′

,{n}

,Val,T

TTP

,L,N

TTP

)

The message 1.2 contains a timestamp T

TTP

, a

lifetime of encrypted coin’s validity L and a nonce

TTP

, all to avoid replay attacks. C checks if T

TTP

and L are recently enough, and then veriﬁes the

TTP’s signature that will be used by customer to

conﬁrm to the other party (the merchant) that {n}

represents the encryption of a valid coin n (that was

signed by a bank from the group, and its lifetime

has not expired), the coin is fresh and of the value

Val, but without exposing the digital coin n to the

merchant.

Phase 2: Agreement on the Transaction’s Terms.

The agreement phase is initiated by the customer that

sends a message to the merchant that represents his

intention to buy a product from him.

Message 2.1: C

′

→ M

′

Po,C

′

ipub

,sig

′

(Po,C

′

ipub

{n}

,Val,T

TTP

,L,N

TTP

sig

TTP

′

,{n}

,Val,T

TTP

,L,N

TTP

)

where

Po = C

′

,Pid,Pr,Quantity,Val,DC

addr

,h(N

)

Po contains h(N

) whose goal is to be used as a

barcode on the product and is set by M such that only

who knows the password N

can collect the product

from DC

addr

; N

is kept secret byC, while M receives

a digest of him.

When the message 2.1 is received, M checks the

terms of the transaction initiated by C. M veriﬁes

if T

TTP

and L are recently enough, the informations

from Po, the customer’s signature on Po and the sig-

nature of TTP. If M is not satisﬁed, he sends an abort

message to the customer and aborts the transaction. If

M is satisﬁed, the signature of TTP assures him that

{n}

represents the encryption of a valid digital coin

of value Val from Po. The new nonce N

TTP

ensures

the merchant about freshness of the digital coin. Even

if M does not know the digital coin and can’t redeem

it in this phase, he knows that could redeem it after it

will post the product with Pid identiﬁer to DC

addr

Message 2.2: M

′

→ C

′

: sig

′

(sig

′

(Po)),

′

ipub

}

′

ipub

If M is satisﬁed by the conditions of the message

it received, he sends to C a message to ensure C by

M’s agreement on the terms of transaction speciﬁed

in the message 2.1. After receiving message 2.2, if

C receives an abort message from M, then he aborts

the transaction. Otherwise, C obtains M’s public key

′

ipub

, by decrypting {M

′

ipub

}

′

ipub

with his one time

private key C

′

iprv

and checks the merchant’s signature.

Phase 3: Physical Delivery of the Product. If the

phase 2 is successful, M posts the product to SC from

AnonymityandFair-Exchangeine-CommerceProtocolforPhysicalProductsDelivery

173

where the product must be taken by DA.

Message 3.1: M

′

→ SC : product

The product has two barcodes set by M: h(N

) to

control the access of DA to SC, and h(N

) to control

the access of C to DC. We consider that the product

with both barcodes is placed by M on a shelf of SC

that is located at SC

addr

. We use SC

addr

to conceal the

true identity of the merchant and such to ensure his

anonymity.

Message 3.2: SC → M

′

: sig

′

,Pid,DA)

Upon receiving the product from the merchant, SC

conﬁrms to him by a signed acknowledgment.

Message 3.3: M

′

→ DA : Pid,SC

addr

,DC

addr

′

ipub

}

pub

sig

′

,Pid,SC

addr

,DC

addr

)

M sends to DA a delivery request message 3.3. N

has the same goal as N

, but in this case the password

is shared only between M and DA. DA recov-

ers the public key M

′

ipub

of M and N

by decrypting

′

ipub

}

pub

with his private key, and checks

the signature of M. If the signature is successfully

veriﬁed, DA is ensured by message’s authenticity.

Message 3.4: SC → DA : product

DA collects the product from SC by proving he

knows the password N

Message 3.5: DA → SC :

sig

′

,Pid,DA,SC

addr

,DC

addr

)

To conﬁrm the collection of the product, DA sends

to SC an acknowledgment in the message 3.5.

Message 3.6: DA → DC : product

Further, DA posts the product to DC as is speciﬁed

by merchant in the delivery request.

Message 3.7: DC → DA → M

′

→ C

′

sig

′

,Pid,DA,DC

addr

)

Upon receivingthe product from DA, DC conﬁrms

him by a signed acknowledgment which DA forwards

it to the merchant. Thus, the merchant has the proof

of posting the product to DC

addr

and thereafter he for-

wards the proof to the customer.

Message 3.8: DC → C

′

: product

The customer collects the product from DC using

the password N

Message 3.9: C

′

→ DC :

sig

′

,Pid,DC

addr

′

)

The customer checks if the collected product

meets the speciﬁcations from Po. If the customer

is satisﬁed with the product, he sends a signed

acknowledgment to DC.

Phase 4: Payment. If the customer collects the

product and is satisﬁed, then he sends to the mer-

chant the message 4.1. Message 4.1: C

′

→ M

′

{K}

′

ipub

,sig

′

(K),

sig

(n)

The merchant obtains the key K and veriﬁes the

customer’s signature on K, then he uses K to decrypt

the encrypted coin received in the message 2.1 from

the customer. M veriﬁes the validity of the sig

(n)

using the group public key. If the coin is valid, M

sends it to MB for redemption in the message 4.2.

Message 4.2: M → MB :

{n,sig

(n),sig

(n,sig

(n)),M,M

acct

}

pub

MB decrypts the received message, checks M’s

signature, checks that sig

(n) is a valid signature of

some bank from bank’s group, using the group public

key, without knowing who is the bank that signed the

coin. MB checks if the coin has already been spent or

canceled by checking the value of the spent ﬂag of the

coin, using the global list of the coins. If all checks

are satisﬁed, MB updates the global list by setting the

spent ﬂag of the coin n to the value 1, transfers the

coin value from commit-buffer to M

acct

, and sends to

M a signed acknowledgment of successfully redemp-

tion of the coin. Otherwise, if some check is not sat-

isﬁed, MB sends to M an suitable error message.

Message 4.3: MB → M : sig

(ack)

4 ANALYSIS OF THE PROTOCOL

4.1 Ensuring Fair-Exchange

In an e-commerce protocol the fair exchange assures

that two parties exchange items of value such that ei-

ther both parties obtain each other’s item or none do.

Our protocol assures fair exchange if either C gets the

physical product and M gets the payment for product,

or none do. If C and M behave honestly, the proposed

protocol assures fair exchange. We will consider all

possible scenarios in which M or C behave dishonest

or prematurely abort the protocol. To ensure fair ex-

change in all this scenarios, extensions of the basic

protocol are necessary as we will see below.

If M behaves dishonest, then the following scenar-

ios are possible:

1. M receives from C

′

a correct message 2.1, but

he doesn’t continue the protocol. Such behavior

brings no beneﬁt to M because he is in posses-

sion of an encrypted coin with a key that does not

know, so he can’t redeem the coin and get the pay-

ment. But C has bought a coin from his bank,

which can not be used by him. In this scenario, C

initiates the extended protocol providing to TTP

the message 2.1 he sent it to M. TTP checks the

information received from C and ask M for his

agreement on the terms of transaction. If M re-

sponds to the TTP’s request by sending to C the

SECRYPT2015-InternationalConferenceonSecurityandCryptography

174

message 2.2, then the basic protocol can continue

with the phase 3. If M doesn’t respond, then TTP

sends to C a cancellation request of the coin in the

ﬁrst message below that furtherC sends encrypted

together with his account information to CB.

TTP → C

′

: n,sig

(n),sig

TTP

(sig

(n))

C → CB :

{n,sig

(n),sig

TTP

(n,sig

(n)),C,C

acct

}

pub

CB checks if sig

(n) is a valid signature, TTP’s

signature, if the coin n has not already been spent

or canceled by checking the global list of coin’s

serial. If all checks are satisﬁed, CB sets the spent

ﬂag of the coin n to the value 2, transfers the coin

value from commit-buffer to C

acct

, and sends to C

a signed acknowledgment of successfully cancel-

lation of the coin n. In this way the coin’s value is

redeemed by C. Otherwise, if some check is not

satisﬁed, CB sends to C an suitable error message.

2. M receives from C

′

a correct message 2.1 and

sends the message 2.2 to C

′

, but he doesn’t posts

the product or posts a product that doesn’t com-

ply with the speciﬁcations from Po. Similarly to

the scenario 1, M does not have any beneﬁt from

this behavior. If C is not satisﬁed with the col-

lected product, he pushes the button of the DC’s

device that allows sending to TTP the recording

of the moment when C unwraps the packed prod-

uct, proving to TTP that the received product is

wrong. Also, C sends to TTP all the messages

received/sent from/to M. TTP checks the infor-

mation received from C and send to M all evi-

dence received from C and ask M to post the cor-

rect product. If M responds to TTP by sending

such a proof, then C can continue the basic pro-

tocol with collecting the product from DC. If M

doesn’t respond to the TTP, then similarly to the

scenario 1, TTP will cancel the customer’s coin

used in the current transaction.

3. M sends to CB many times the same message 4.2

for multiple redemption of the same coin. This

scenario is solved in the basic protocol, because

MB checks if the coin received in the message 4.2

has already been spent by checking the value of

the spent ﬂag of the coin.

If C behaves dishonest, then the following scenar-

ios are possible:

1. C collects the product in the message 3.8, but does

not send to M

′

the decryption key of the encrypted

coin or sends to M

′

in the message 4.1 a wrong

decryption key. In this scenario, M initiates the

extended protocol providing to TTP all the mes-

sages received/sent from/to C. TTP checks the

current transaction’s messages and ask C for digi-

tal coin decryption key. According to the response

of C, there are three possible scenarios:

(a) If C responds to the TTP’s request by send-

ing to M

′

the digital coin decryption key K in

a message 4.1, then M

′

can continue the basic

protocol with coin redemption.

(b) If C doesn’t respond to TTP, then TTP sends

to M

′

the digital coin decryption key K that is

in possession of TTP from phase 1:

TTP → M

′

: {K}

′

ipub

,sig

TTP

(K),sig

(n).

M can decrypt the digital coin using the key

K received from TTP, checks the validity of

sig

(n) and can continue the basic protocol

with the message 4.2 for coin redemption.

decryption key because M

′

didn’t posted the

product or M

′

posted another product than the

ordered one. To claim this, C must submit to

TTP the proof of wrong product reception: the

recording of the moment when C unwraps the

packed product. This proof is sent on a secure

channel from DC’s device to TTP, so TTP can

not be fooled. Further, this scenario is solved

similarly with the previous (b) scenario.

2. C sends the same digital coin to TTP (in the mes-

sage 1.1) in two different sessions of validating

encrypted digital coins, to initiate two different

buying transactions with two distinct merchants.

This scenario is solved in the basic protocol be-

cause all banks and TTP maintain a global list of

coin’s serial already spent, validated but unspent,

or canceled. On reception from C of the ﬁrst re-

quest for validating the coin, TTP adds the coin

to the global list of coins, and therefore any new

validation request of the same coin from C is de-

tected by TTP. Thus, TTP detects double spend-

ing from C and aborts the second transaction.

3. C sends to M

′

in the message 2.1, an encrypted

coin already spent. This scenario is solved in the

basic protocol. If the coin wasn’t used to buy from

′

, then M

′

detects this by verifying the TTP’s

signature that validated the encrypted coin. Oth-

erwise, if the coin was already used to buy from

′

, then M

′

can check this by verifying N

TTP

. So,

M detects double spending from C and aborts the

transaction.

4. C sends to M

′

in the message 2.1, an encrypted

coin of insufﬁcient value. This scenario is solved

in the basic protocol, because M checks if the

value from Po corresponds with the encrypted

coin’s value validated by TTP. If these values are

not equal, then M aborts the transaction.

AnonymityandFair-Exchangeine-CommerceProtocolforPhysicalProductsDelivery

175

5. C sends to M

′

in the message 2.1, an encrypted

coin that has already been canceled. C’s intention

is to buy a product without paying for it. This sce-

nario is solved in the basic protocol, because M

checks if T

TTP

and L are recently enough. In this

scenario, these values are not recently enough,

and M aborts the transaction.

6. C sends to his bank many times the cancellation

requests of the same coin for multiple redemption

of the same canceled coin. This scenario is solved

in the extended protocol, becauseCB checks if the

coin received in a cancellation request has already

been canceled.

DA, SC, and DC send signed acknowledgments of

product collection in the phase 3 of the basic proto-

col. Moreover, these three entities have no interest

not to follow the protocol steps, because their interest

is to get proﬁt from fees for such services provided in

e-commerce transactions. Each party involved in the

protocol must keep a record of every message sent

or received in protocol including signed acknowledg-

ments of DA, SC, and DC. If one of the parties men-

tioned above (DA, SC, or DC) behaves dishonest, the

other parties send the records to TTP to trigger an

off-line mechanisms to ensure fairness.

4.2 Analysis of Anonymity

One of the main objectives of our protocol is to en-

sure the anonymity of the customer and the merchant.

In what follows, we show that the protocol proposed

ensures anonymity of the customer and the merchant

in any possible collusion scenario.

An e-commerce protocol provides customer’s

anonymity if no party and no coalition between par-

ties can make a link between the true identity of the

customer and actions taken by him in the e-commerce

transaction. More exactly, our protocol ensures the

customer’s anonymity if the true identity of the cus-

tomer, C, can’t be linked with the pseudo identity of

the customer, C

′

, which he uses in the e-commerce

transaction.

Ensuring the customer’s anonymity rises two

problems that must be solved in this regard: guar-

anteeing the customer’s anonymity in the payment’s

phase, and guaranteeing the customer’s anonymity

when the customer collects the physical product. To

provide the anonymity of the customer in the pay-

ment phase, we use an electronic cash payment that

is based on group blind digital signatures on behalf of

the banks. The only steps from our protocol in that

the customer uses his true identity are the GBDS Pro-

tocol’s steps, because CB must know C

acct

to charge

it with the coin’s value. CB knows only that C bought

Table 2: Informations that each party knows after protocol

execution.

Entity

Info C M CB MB DA SC DC

C y n y n n n n

M n y n y n n n

CB y n y n n n n

MB n y n y n n n

DA n y n n y y y

SC n y n n y y n

DC y y n n y y y

′

y y n n n n y

pub

y n y n n n n

′

ipub

y y n n n n y

n y y n y n n n

C&t

y n n n n n n

′

y y n n n n y

′

y y n n y y y

pub

n y n y n n n

′

ipub

y y n n y n n

M&t

n y n n n n n

′

y y n n y y y

a coin with a certain value, but it doesn’t know the

serial of the coin. Following, CB can’t associate C

with the coin bought by him, maintaining thus the

anonymity of the customer. Another essential fea-

ture of the GBDS Protocol is the customer bank’s

anonymity: any party can check if sig

(n) is valid,

but without knowing who is the bank that signed the

coin. CB is not known by any other party (except

C), so, CB can’t participate in no coalition with any

other party to obtain sensitive information to destroy

the customer’s anonymity.

To ensure the customer’s anonymity when C col-

lects the physical product, our protocol doesn’t use

the customer’s correspondence address but uses a des-

tination cabinet where the product is placed.

We show in the Table 2, the information 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 column

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

identity of the customer; n under the column M, MB,

DA, SC and DC means that the true identity of the

customer is not known to M, MB, DA, SC and DC.

C&t

means that C performs the transaction t

. The

meaning is extended for C

′

, M&t

, M

′

From Table 2 we observe that no party alone has

sufﬁcient information to link the true identity of the

customer, C, with the pseudo identity C

′

. Only C can

SECRYPT2015-InternationalConferenceonSecurityandCryptography

176

disclose this information if he wants.

2-party Collusion. The 2-party collisions where M

can occur are M and MB, M and DA, M and SC, M and

DC. From this collisions, M doesn’t get more knowl-

edge than he already had, and the other parties get

the knowledge of M. By colluding between DA and

SC, DA doesn’t get more knowledge than he already

had. The coalitions between DA and DC, DC and SC

get only information that C

′

performs the transaction

. All other 2-party collisions that could form are be-

tween CB and M, CB and MB, CB and DA, CB and

SC, CB and DC, MB and DA, MB and SC, MB and

DC, but they are not possible because the parties in-

volved do not know each other.

3-party Collusion. From the analysis above, we

observe that M can be involved in the following 3-

party collisions: M, MB, DA; M, MB, SC; M, MB,

DC; M, DA, SC; M, DA, DC and M, SC, DC. These

coalitions are reduced to 2-party collisions in which

M is involved because from these 3-party collisions

M doesn’t get more knowledge than he already had.

One more 3-party collusion can be formed between

DA, SC and DC, but it does not get more information

about customer as against the 2-party collisions DA

and DC, or DC and SC.

4-party Collusion. The only 4-party collisions (M,

MB, DA, SC; M, MB, DA, DC; M, MB, SC, DC; M,

DA, SC, DC) are reduced to 3-party collisions because

M already knows all information known to the other

parties from this collisions.

5-party Collusion. The only possible 5-party col-

lusion M, MB, DA, SC and DC, is reduced to 3-party

collisions by same arguments as above.

Regarding merchant’s anonymity, he uses his true

identity only in communication with MB in the coin

redemption phase. MB knows personal information

about M (such as M

acct

), but it doesn’ t know infor-

mation about the pseudo identity M

′

. Moreover, MB

is not known to any other party (except M), and can’t

participate in coalitions with any other party to de-

stroy the merchant’s anonymity. Our protocol doesn’t

use the merchant’s correspondence address, but uses

a source cabinet where the product is placed by M.

Is easy to see from Table 2 that no party alone has

sufﬁcient information to link the true identity of the

merchant, M, with the pseudo identity M

′

2-party Collusion. The 2-party collisions where

C can occur are C and CB, C and DC. From collu-

sion between C and CB, C doesn’t get more knowl-

edge than he already had, and CB gets the knowledge

of C. From collusion between C and DC, C gets as

new information the identity of DA, and DC gets the

knowledge of C. By colluding DA and SC, DA and

DC, SC and DC are obtained only information about

′

, no information about M. No other 2-party col-

lusion is possible because there is no other party to

know another party.

3-party Collusion. The 3-party collisions that can

be formed areC, CB, DC; C, DA, DC; C, SC, DC; DA,

SC, DC, and these get only the information that M

′

performs the transaction t

, without any information

about M.

4-party Collusion. The only 4-party collisions C,

CB, DC, DA; C, CB, DC, SC and C, SC, DC, DA, are

reduced to 3-party collisions.

5-party Collusion. The only 5-party collusion C,

CB, DA, SC and DC, is reduced to 3-party collusion

C, DA, and DC.

5 CONCLUSIONS

By integrating an electronic cash payment mechanism

and using a suitable mechanism for physical products

delivery, the proposed protocol is the ﬁrst to provide

fair exchange between physical products and pay-

ments in all circumstances, and customer and mer-

chant’s anonymity in any collusion scenario. All of

these makes the proposed protocol a candidate to be

used effectively in practice for electronic transactions

that implies buying physical products.

Future work will include formal proving of the

correctness of the proposed protocol using strand

spaces framework or formal veriﬁcation using auto-

mated model checking tools (e.g. AVISPA).

REFERENCES

Aimeur, E., Brassard, G., and Mani Onana, F. (2006). Se-

cure anonymous physical delivery. IADIS Interna-

tional Journal on WWW/Internet.

Alaraj, A. (2012). Fairness in physical products deliv-

ery protocol. International Journal of Computer Net-

works & Communications (IJCNC).

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.

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

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

nancial Cryptography. 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

Systems and Applications. IEEE.

AnonymityandFair-Exchangeine-CommerceProtocolforPhysicalProductsDelivery

177