LAYERED ARCHITECTURE FOR SECURE E-COMMERCE

APPLICATIONS

Amir Herzberg and Igal Yoffe

Computer Science Department,Bar Ilan University

Ramat-Gan, 59200, Israel

Keywords:

Secure e-commerce, secure payments, attested delivery, e-banking, cryptographic protocol, non-repudiation.

Abstract:

We present a layered architecture for secure e-commerce applications and protocols with fully automated

dispute-resolution process, robust to communication failures and malicious faults. Our design is modular, with

precise yet general-purpose interfaces and functionalities, and allows usage as an underlying secure service to

different e-commerce, e-banking and other distributed systems. The interfaces support diverse, ﬂexible and

extensible payment scenarios and instruments, including direct buyer-seller payments as well as (the more

common) indirect payments via payment service providers (e.g. banks). Our design is practical, efﬁcient, and

ensures reliability and security under realistic failure and delay conditions.

1 INTRODUCTION

Efﬁcient payments are crucial for efﬁcient markets

and commerce. Historically, improved payment in-

struments were critical to the development of com-

merce and economy. In particular, different secure,

unforgeable, authenticated payment tokens, made

trading easier: coins are easier to use than barter, pa-

per bills and checks easier than coins, credit-cards of-

ten easier than cash and checks.

To facilitate commerce between non-trusting peers

payment instruments used trusted third-parties. Of-

ten, these parties are trusted to hold the “real” values

(funds), and transfer them to the payee upon present-

ment of the appropriate payment authorization or to-

ken; this is the traditional role of a bank, or more gen-

erally a payment system provider (PSP). A separate

role for trusted third parties is to prevent or resolve

disputes between the parties, including disputes in-

volving bank, PSP, or other payment-related services.

Indeed, the ultimate control of payment instruments,

prevention of fraud and resolution of disputes, are of

the basic attributes of sovereignty. Banks (and some

other PSP) are usually subject to laws and government

regulation and supervision. One goal of these mech-

anisms is to prevent, or at least resolve, bank/PSP

fraud, e.g. a bank denying a deposit or removing

funds without authorization.

Traditionally, the main mechanism for dispute res-

olution is the use of (handwritten) signatures. Banks

provide customers with signed receipt for each de-

posit, and customers sign authorization for each pay-

ment (by check, credit card, or any other means).

There are laws and regulations on the necessary au-

thentication and record-keeping by ﬁnancial institu-

tions, and the system works well, at least for tradi-

tional, face-to-face transactions.

Currently, systems deployed with a PSP require

complete trust in the PSP, i.e. do not include mech-

anisms to prove PSP fraud; do not offer receipts

or dispute resolution. Moreover, unfortunately and

alarmingly, current deployed systems mostly rely

on credit card numbers, passwords and other weak-

authentication mechanisms, usually transmitted over

a connection protected by the SSL or TLS proto-

col. There were several proposals for deploying addi-

tional cryptographic authentication, most notably on

(anonymous) digital cash e.g. (Chaum, 1983) and mi-

cropayments e.g. (Herzberg, 2003; R. Rivest, 1996).

The most signiﬁcant effort was the iKP secure credit-

card payments protocol (Bellare et al., 2000), which

was adopted (with changes) into the SET (Secure

Electronic Transactions) system by Visa, MasterCard

and others, but not widely deployed. We should note

that both iKP and SET did not include a dispute reso-

lution process.

Several of these proposals, including iKP and SET,

authorized transactions using digital signatures by

118

Herzberg A. and Yoffe I. (2006).

LAYERED ARCHITECTURE FOR SECURE E-COMMERCE APPLICATIONS.

In Proceedings of the International Conference on Security and Cryptography, pages 118-125

DOI: 10.5220/0002099801180125

 SciTePress

buyers and sometimes also sellers. A possible ad-

vantage of signatures over many other authentication

mechanisms, is that signatures can be validated by

any party - not just the recipient - and at any time, not

only at real payment time. In this sense, a payment

system can use digital signatures, to allow third-party

resolution of disputes, similarly to use of paper signa-

tures. This was deﬁnitely one of the goals of signing

in iKP.

Currently deployed systems do not have a secure

mechanism for fair dispute resolution. To protect con-

sumers, laws and regulations often force a default res-

olution in favor of the buyer. There are exceptions,

most notably, laws and regulations that accept the va-

lidity of records kept by a bank, when a client de-

nies having made a transaction. Clearly, such simple

dispute-resolution mechanisms provide an acceptable

solution to many existing payment scenarios, in spite

of their obvious potential unfairness to one party.

In this paper, for the ﬁrst time, we present a con-

struction which ensures efﬁcient, fault-tolerant and

fair dispute resolution to e-payment transactions. As

mentioned, many of the proposed payment protocols

use digital signatures, often with the hope of facili-

tating dispute resolution. However, few works (Her-

reweghen, 2000; J. Tang, 2004) including works on

non-repudiation (Zhou, 2001; Nenadic and Zhang,

2003) analyzed how the dispute resolution would

work in such protocols, and tried to deﬁne appropriate

process. The resulting processes were designed for a

human, and not fully automated. Furthermore, these

works did not consider the effects of communication

failures.

We considered both direct payments, between two

parties, and indirect payments, involving a trusted

third party such as a bank. Furthermore, we divide the

payments used in traditional and online commerce, to

three groups. The payments could be non-ﬁnal, ﬁ-

nal and conditional ﬁnal. With non-ﬁnal payments,

the payee need to validate the availability of the payer

funds, and take into account the payment might be

reversed. For example, paying a merchant with a per-

sonal check, may result in the merchant withholding

goods, until the check is cleared with the bank. An-

other example of non-ﬁnal payments, are credit card

MOTO (mail order, telephone order) payments, which

are unique in the absence of the credit card itself in the

transaction. Most laws allow non-ﬁnal MOTO pay-

ments to be easily reversed, by the customer stating

he never approved the order.

On the other hand, with ﬁnal payments, the ap-

proval and availability of payer funds is a function of

the payee local validation and actions only. A certi-

ﬁed check, for example, from a known bank assures

the merchant that he would receive payment if he de-

posits it within a time frame as deﬁned by banking

laws. Another category of payments, are conditional

Table 1: Payment instruments between two or more parties.

Payment Type Example

Direct (2P) Immediate cash, barter, tokens

Conditional betting, futures

Expirable

Indirect(>2P) Non-Final MOTO, personal checks,

(clearing) online credit cards usage

Final credit cards, certiﬁed

payment options and checks

Conditional lottery, escrow, conditional

Final certiﬁed payment options

Figure 1: Repetitive successful ﬂow of orders.

ﬁnal payments. One would receive payment against

a horse betting ticket, which is a certiﬁed conditional

payment option, only if the horse won the race, or in

case of e-mail, if one is signed on a message, it is, con-

ditionally, a payment, if the message is considered as

a SPAM (Herzberg, 2004). In Table 1 we summarize

the various payment instruments we had mentioned.

The design we present is ﬂexible, and supports sev-

eral types of payments, allowing its use as underly-

ing layer for many secure commerce protocols. Each

payment network principal employs four secure e-

commerce application layers, an application layer, a

payment layer, an order layer and an attestation layer,

as a bottom layer, as shown in Figure 2.

The most basic form of payment is a direct, im-

mediate payment order. Our design easily supports

such direct payments. See a simple example scenario

in Figure 1, where a payments client (client) opens a

payment channel (pay channel) to a payment server

(server), and then sends several payment requests, to

each of which the server sends back a response.

The design also supports conditional and expirable

payment orders. In this case, the server responds to

the order with a payment option. Furthermore, we use

the option mechanisms also to facilitate three-party

payments, both ﬁnal and conditional.

One aspect of the ﬂexibility of our layered con-

struction is the support for arbitrary condition func-

tion on payments, provided as a ‘black box’ function

to payment and e-commerce protocols. The condi-

LAYERED ARCHITECTURE FOR SECURE E-COMMERCE APPLICATIONS

119

tion function is deﬁned as part of a payment agree-

ment between the payment client and payment server.

In particular, we use the same basic two party pay-

ment, to enable also payments via a trusted third party

PSP, which has a long-term relationship with both

buyer and seller. The three party payment transac-

tion (buyer, PSP and merchant) is done by two in-

stances of the simple, two-party transactions, one be-

tween buyer and the PSP, and the other between the

seller and the PSP. Details and examples are presented

later on (speciﬁcally see Figure 3). Properly-designed

condition functions can support many other scenar-

ios, including betting, hedging and other structured

investment devices, and much more.

Related Work. Many payment models and

schemes have been developed over the years. Many

of these protocols focused on aspects of the payment

process, where the widely-used credit card system is

not satisfactory. The two main directions here are

micropayments (R. Rivest, 1996; Micali and Rivest,

2002; Herzberg, 2003) and digital (anonymous) cash

(Chaum, 1983). An important exception is iKP, the

i-Key-Protocol (Bellare et al., 2000), a family of pro-

tocols for secure credit-card payments, which was

adopted by MasterCard and Visa for the SET stan-

dard (which seems to have been abandoned). Another

important exception is the NetBill (Cox et al., 1995)

protocol, which is a distributed transactional payment

protocol featuring atomic delivery, where payment

proceeds only if the customer had received the goods.

Additional, notable layered architecture, though lack-

ing automated resolution process, is SEMPER (La-

coste et al., 2000), which aimed to create a global,

decentralized and secure marketplace. The literature

also includes vast research regarding non-repudiation

and fair exchange (Nenadic and Zhang, 2003; Pﬁtz-

mann et al., 2000; Ray and Ray, 2002) along with

dispute resolution (Kremer and Markowitch, 2003)

for different levels of a trusted third party involve-

ment (Zhou et al., 1999); for such a survey see (Kre-

mer et al., 2002). The mentioned works lack the

proofs to match between orders and issued goods,

or don’t handle failed submission of orders, pay-

ments or payment option deposits, which makes them

unsuitable as underlying infrastructure for secure e-

commerce services.

Contribution of this work. Our main contribution

may be in the presentment of new e-commerce lay-

ers as a well deﬁned, fully-automated services, un-

derlying secure e-commerce protocols and applica-

tions. We present an architecture, deﬁne e-commerce

layers with well deﬁned services and interfaces. An-

other key contribution is our validation constructions,

where every e-commerce layer deﬁnes its validation

functions for automated dispute resolution, which is

efﬁcient and fair to all parties.

Figure 2: Secure E-commerce layers vs. Internet layers.

Table 2: Attestation evidence structure.

Evidence Field Description

type Evidences of origin, delivery and

failed submission, EOO, EOD, EOFS,

respectively.

agr Attestation agreement.

msg The message sent.

ci Creation time interval.

σ Signature over evidence

ﬁelds.

2 ATTESTATION LAYER

The Attestation layer is the lowest secure e-commerce

layer. Attestation layer is based on top of a transport

layer, such as, for example, TCP/IP, TLS/SSL, work-

ing on top of socket or SSL API, respectively, and

provides additional certiﬁcation services. An attested

session is always between three parties: client, server,

and a notary (trusted third party), which acts as time-

stamping and certiﬁcation provider.

An attestation (Table 2) is a time-stamped and

signed statement, by an entity or a notary, on behalf of

the entity. An evidence of delivery (EOD), is an attes-

tation of message acceptance by an intended message

receiver. An evidence of origin (EOO), is an attesta-

tion of a message origin. An evidence of failure and

submission (EOFS) is an attestation that the message

was correctly sent, yet wasn’t acknowledged by the

intended receiver (as with EOD).

Generally, the EOD is a proof for the message

sender, that the intended message receiver had indeed

received the message. The EOO, intended for mes-

sage receiver, ensures that the message in question

had indeed originated from the claimed sender. The

EOFS allows the sender to prove he had sent the mes-

sage in question, even if the message wasn’t received

due to communication faults or adversarial behavior.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

120

Table 3: Attestation agreement.

Agreement Field Description

∆

bound

Bound on attestation layer answer,

for message delivery.

, Id

, Notary The identities of the principals

participating in the agreement.

Principal’s identity is an (addr, v k)

tuple, of principal’s address and

public validation key, respectively.

Time-stamping. The attestation layer supplies, as

part of the evidences mentioned above, evidence that

a message had existed at speciﬁc time interval, and by

that time was also signed by the originating party’s

validation key. This allows cognoscibility of a mes-

sage even after message originator’s validation key

had expired, been compromised or revoked.

Conﬁdentiality. In our model we do not treat

conﬁdentiality issues, which could be solved by us-

ing transport communication layers below attestation

layer, for instance, TLS/SSL or IP-Sec layers.

Failed Delivery. We assume simple management

of non-delivered messages, where each message is

assigned only one type of evidence during lifetime.

The attestation layer doesn’t try to re-deliver a mes-

sage (reliability service could be provided by layers

below attestation, e.g., TCP), if it had been assigned

an EOFS.

Attestation Agreement. An attested communica-

tion channel is established using an attestation agree-

ment, speciﬁed in Table 3, and for which we assume

settings are valid for the whole period the channel re-

mains open. Parties signing the agreement specify

own identities and the notary that would be used for

attestation. The ∆

bound

, agreement ﬁeld, is the bound

required for the attestation service to return an evi-

dence, EOD or EOFS, for a sent message.

Validation. The validation functionality is not re-

lated to any particular instance of attestation module,

and could be invoked by any third party, which had

obtained the attested communication agreement and

would have to supply the evidence in question. The

Validate(e,type,id) efﬁcient predicate returns whether

the evidence e, Table 2, is valid. The id speciﬁes

the principal whose validation key is to be used from

the attestation agreement extracted from the evidence,

and type speciﬁes the validated evidence type.

Attestation interface. The interface between pay-

ment and attestation layers is described in Table 4, and

consists of initialization interface and an interface to

send and receive message along with their respective

evidences.

Initialization. Attestation initialization is two

phased, where in Init, the attestation layer generates

secret and validation key pair, keeps the secret key

and in InitResult returns the validation key, along with

the (communication) address of the attested instance.

These values, address and validation key, compose

principal’s identity, for the above layer, e.g., payment

or application layers, and would be used to sign evi-

dences, as speciﬁed in Table 2.

3 ORDER LAYER

The layer encapsulates operations (“orders”) related

to goods and services. The layer provides the service

for placing an order for goods or services by a client,

and validating that the server returned order result ad-

here to the order agreement signed between the prin-

cipals.

Order Agreement. We deﬁne an order agree-

ment between trading parties as speciﬁed in Table 5.

To sign an order agreement, the parties should agree

on an appropriate attestation agreement, and a trade

validation function, ValidateTrade(order,goods). The

function should have BadOrder, BadGoods, OrderOk,

GoodsOk return values. The BadOrder return value is

issued for an order which is invalid under the agree-

ment, regardless of the value of goods. The second,

BadGoods return value, is issued for goods which do

not match the order (which should also include the

payed amount), the OrderOk returned for valid order,

without goods; and the GoodsOk status is returned

when the corresponding goods match the order, in the

context of the agreement.

Table 5: Order agreement.

Agreement Field Description

ValidateTrade(order,goods) Trade validation function.

returns status; Validates that issued goods

match the order.

AttAgr Attestation agreement,

see Table 3.

Order interface. The interface between the appli-

cation and order layer, Table 6, deﬁnes the initializa-

tion, ordering goods or services, and validation of or-

der results. In the ﬁrst, Init phase, each order layer

machine establishes its own identity, as returned by

attestation layer. Using this information a principal

may establish order agreements with other network

principals.

When an order channel is established, order trans-

action are invoked with Order event, supplying client

speciﬁed order information which deﬁnes the de-

posited option or type of goods to acquire, the pay-

ment amount, and possibly other relevant information

(e.g., original merchant offer). We then expect an

OrderResult event within ﬁnite time, as governed by

LAYERED ARCHITECTURE FOR SECURE E-COMMERCE APPLICATIONS

121

Table 4: Attestation layer interface.

Method Direction Description

Init(1

) in Initializes attestation layer, with a security parameter.

InitResult(vk,addr) out Returns generated validation key vk of the initializer, and the principal’s

address addr in the payment network.

OpenChannel(AttestationAgreement) in Establishes an attested channel between the source principal,

destination principal and a notary.

OpenChannelResult(success) out Notiﬁes the principal that an attested channel had been established.

CloseChannel() in Closes an attested communication channel.

Send(m) in Sends a a message m over established, attested, channel.

SendResult(e) out Returns an attestation evidence, Table 2, for the sent message.

Deliver(e) out Delivers an evidence of origin, Table 2, which also includes the message.

Table 6: Order layer interface.

Method Direction Description

Init(k) in Initializes the order layer, with security parameter k.

InitResult(vk,addr) out Returns initializer’s address addr, and validation key vk.

OpenChannel(OrderAgr) in Opens an order channel with the principal(s) speciﬁed by

OrderAgr agreement.

OpenChannelResult(status) out Notiﬁes the application of the order channel establishment success.

CloseChannel() in Closes an order channel.

Client

Order(order) in Instructs the order layer to issue an order, described by order,

over an established order channel.

OrderResult(status,result) out Returns the order status and result.

Server

VendRequest(order) out Instructs the application layer to issue goods, described by order,

and implicitly by the order agreement, in the order context.

VendRequestResult(orderresult) in Returns the vended goods, from the application.

Validation

Validate(OrderAgr,orderevidence) in Validation of order evidences according to the supplied OrderAgr.

returns result Where result is NoFraud, ServerFraud, ClientFraud.

the ∆

bound

, speciﬁed in the encapsulated attestation

agreement.

On the server side, we assume an application (or

upper) level functionality to issue goods or services,

using VendRequest interface. The goods and services

are issued in the context of the order agreement spec-

iﬁed for the open order channel, and are veriﬁable by

order agreement’s ValidateTrade.

The validation functionality, Validate(e), is com-

mon to all parties. That is, an automatic dispute res-

olution system, or an arbiter, upon dispute, would in-

stantiate the order layer, and supply the relevant order

agreement along with the the protocol-speciﬁc order

evidence e. Such order layer evidences include evi-

dence of purchase and evidence of failed order, for the

client, and evidence of sell, or of a bad client order, for

the server. The aforementioned evidences typically

composed of pairs of relevant attestation evidences.

4 PAYMENT LAYER

The payment layer encapsulates operations related to

funds, which includes payment transactions, ﬁnal and

conditional payment orders, and maintaining of ac-

counts for trading principals.

The payment layer interface is identical to order

layer interface, Table 6, with an additional meaning to

the Order interface method, for support of the afore-

mentioned payment instruments, e.g., ordering a pay-

ment option.

Payment layer agreement is speciﬁed in Table 7,

and includes trading principals initial mutual credit,

an encapsulated order agreement and a ValidateCon-

dition method for validating payment order deposits.

ValidateCondition. The ValidateCondi-

tion(option,condition), is an agreement between

parties, regarding evaluation of conditions of certiﬁed

options at deposit time. It compares option induced

condition, with the supplied one, at time of deposit, to

decide whether an option should be honored. Using a

horse-betting example, an option, for instance, could

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

122

Table 7: Pay agreement.

Agreement Field Description

ValidateCondition(option, Validation function for

condition) returns boolean; payment options’ conditions.

clientCredit Initial client’s credit.

serverCredit Initial server’s credit.

OrderAgr Order agreement, see Table 5.

specify odds, bet funds, race, the chosen horse, and

bookie’s signature required to approve the result. The

condition, supplied along with the option when it is

deposited, would be winner’s name and race, signed

by the bookie speciﬁed by the option.

Payment evidences and Validation. Payment

layer evidences include balance statements, along-

side with evidences of client or third-party’s deposits

of payment orders, issued to the pay client. We re-

mark that for simplicity of management the state-

ments could be incremental, and enclosed within

each payment transactions. Validation of payment

layer evidences is straightforward, provided undis-

puted (signed) server balance statement, for the previ-

ous payment transaction, and comparing amount and

validity of current transaction evidences which in-

cludes server supplied evidences of payment options

deposits, to the balance statement of the current (dis-

puted) transaction.

Multi-party payments. Payments which involve

multiple PSPs could be facilitated by additional,

multi-party, e-commerce layer. The layer would

maintain an open, decentralized payment network,

which is to provide interoperability among many

PSPs without requiring global trust in each PSP, by

means of payment routing tables (PRTs) and agree-

ments, that would allow automatic dispute resolution,

involving multiple PSPs along a payment path. For

further details see (Herzberg, 2003).

5 BREAKDOWN AND USE-CASES

We present few concise use-cases, which together

with the presented attestation and payment layer

APIs, would clarify how one should implement

payment-layer machines (client and server) and com-

mon validation functionality, for a payment protocol.

We plan to publish full implementation of our order

and pay layer protocol, including Validate predicates

in a separate paper.

1. Ordering goods or services. We begin with a

trivial ﬂow of a set of successful orders, as shown in

Figure 1. Two trading principals, client and server,

use a signed pay agreement to establish a payment

channel. Over the payment channel they progress

with a set of request and response pairs, where each

such pair, is a successfully completed order. The or-

der request may be requests for goods or services,

such as, request for a payment option, and the re-

sponse contains either a refuse, or the requested

goods. The returning goods and services could be

validated to match the order and the payed amount,

by the client, or any party, e.g., an arbiter, using the

pay agreement between the server and the client.

2. Ordering and depositing an option. An option

acquisition and deposit, is between two trading par-

ties, namely, server and client. The process begins

with ordering an option, where the server removes

funds from client’s account to pending, and issues the

option. The option response arrives to the client, in a

form of EOO. When the client deposits such option,

as EOO, server validates that it’s an EOO issued by

itself, validates the option condition, and if the condi-

tion is upheld, and option didn’t expire, commits the

funds transfer from pending to self. Then, a receipt

and the goods speciﬁed by the option, are sent, in a

response message, to the client.

3. Notarized failure of ordering goods or ser-

vices. We show failed ﬂow of orders, and describe

the recovery within the next order, in Figure 5. We

begin with the simpler case; in case A, shown in the

ﬁgure, an order response has failed, with notarization,

for server. When the next order arrives, the server in-

cludes with the response, the EOFS, for the previous

(failed) response, and includes an updated balance

statement. The client, which was aware of only one

successfully processed order, receives the response

and the enclosed EOFS, for the failed response, vali-

dates the EOFS, and concludes that both orders were

processed, and update its account and balances ac-

cordingly.

The next case, described as ﬁgure’s case B, as op-

posed to case A, a client’s request fails, possibly, be-

cause server unavailability, and thus client is issued

an EOFS. This EOFS

is enclosed with the next, third

order, order

request. The server, would process all

previous failed orders, enclosed with the request. For

instance, if the failed order was a deposit of an option,

it needs still to be deposited, and the deposit time to be

taken from the EOFS. As for failed orders, pay agree-

ment may specify special fees or ﬁnes for server’s un-

availability.

Also, notice the incremental nature of EOFSes,

where, for each failing request or response, the next,

request or response, respectively, will include all the

previous EOFS-es.

4. Communication failures. For beneﬁt of hon-

est parties we supply means of recovery from non-

notarized communication failures. Consider the case

in Figure 4; a client (or similarly a server) issuing an

order request, receives in return a communication fail-

ure (instead of an EOD). The client could not possibly

know whether the channel had failed, before the re-

LAYERED ARCHITECTURE FOR SECURE E-COMMERCE APPLICATIONS

123

Figure 3: Trade and payments with PSP intermedi-

ate.

Figure 4: Non-notarized communication failure for

orders.

quest had been delivered (and server had obtained an

EOO), or afterward, and the failure had prevented him

from receiving an EOD (or EOFS). Thus, the state of

the order would be unknown, until the next order suc-

cessfully completes. As could be seen in the ﬁgure,

if the order was indeed received by a honest server,

the client would see the order’s EOO included in the

next response, and update order’s status, and account

balances, accordingly.

5. Dispute resolution. Consider disputes regard-

ing amount of funds in the accounts, after a series of

orders. Since account balances could be validated in-

crementally, adhering to the concept of retaining last

evidences, the client would turn to an arbiter with two

subsequent sever response evidences, as a payment

evidence. The arbiter would instantiate the payment,

order and attestation layers, given the pay agreement,

and would invoke the corresponding Validate rou-

tine. Possible implementation of the routine, which

is shared by all protocol parties, would be taking the

balance statement from the (last) non-disputed server

response, and comparing all the reported order-results

and deposit balance changes, to the balance reported

in the current response, in addition to checking de-

posits validity with ValidateCondition.

Additional scenarios, e.g., server just ignoring an

order, for which the client had obtained an EOD,

could be addressed by introducing additional order

layer evidences and order layer trusted party, which

could, similarly to attestation, issue an evidence of

failed (or ignored) order for the client.

6. Payments with PSP intermediate. With indi-

rect ﬁnal payments, the payee (merchant) receives a

pre-authorized payment option from the payer (cus-

tomer). The payee is able to locally validate the pay-

ment, unlike payments which require clearance to en-

sure availability of payer funds. When the option is

deposited to the PSP, its condition is evaluated, and

if the evaluation succeeds the PSP makes the transfer

Figure 5: Failed order ﬂows.

between payer an payee accounts, otherwise the pay-

ment option is discarded. In Figure 3 we show our

schematic settings for such indirect payments. The

conditional payments ﬂow between the payer and the

payee progress as two separate interactions, as fol-

lows: a PSP receives an order for an option from the

payer, moves the funds speciﬁed by the order to pend-

ing, and returns a payment option. The payer, in a

process of trade with the payee, handles the payment

option to the payee. In his own pay interaction against

the PSP, the payee deposits the option. At deposit,

the PSP checks for expiration and option condition,

and then two receipts are generated, one indicating

the end of PSP’s transaction against the payer and the

other indicating the end of PSP’s transaction against

the payee.

The trade itself between the payer and the payee,

shown as a dotted line, could be performed by any e-

commerce protocol. Although the merchant and the

customer do not maintain long-term relationship as

required in our settings (such long-term relationship

renders introduction of a PSP intermediate as arti-

ﬁcial), the option itself could be used as a material

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

124

for signing ad-hoc pay agreement (see Section 4) be-

tween the parties. Then, multiple trade transactions

could occur between payer and payee, until the credit

speciﬁed by the option is exhausted.

In addition, using conditional certiﬁed payment op-

tions provides extra ﬂexibility. Consider, for exam-

ple, the case of assuring goods delivery, as with Net-

Bill (Cox et al., 1995). The PSP conditions the payee

presenting a delivery receipt signed by a customer, or

notarized delivery services (N. Asokan, 2000). Such

receipt would be checked by the ValidateCondition

pay agreement predicate, upon option deposit, assur-

ing option deposit is successful only when goods had

been delivered.

6 CONCLUSION

Following our construction we are implementing a

payment protocol with automated dispute resolution,

it would be published in a separate paper. We also

consider applying our constructions and protocol for

the SICS (Herzberg, 2004), SPAM-prevention sys-

tem. We believe SICS could be easily adapted for

the presented architecture, in collecting and resolving

SPAM-related payments.

In conclusion, we have introduced a novel,

agreement-based, mechanism, and have shown how

to use it to construct ﬁnal and conditional ﬁnal pay-

ments, between two parties which maintain a long

term relationship, or how to conduct trade when a

PSP is a trusted party. Our constructions are practi-

cal, layered, with promise of automatic dispute reso-

lution based on precise agreements and relatively sim-

ple cryptographic constructions assumed.

REFERENCES

Bellare, M., Garay, J., Hauser, R., Herzberg, A., Krawczyk,

H., Steiner, M., Herrenweghen, E. V., and Waidner, M.

(2000). Design, Implementation and Deployment of

the iKP Secure Electronic Payment System. In Jour-

nal on Selected Areas in Communication, special is-

sue on Network Security, volume 18, pages 611–627.

Chaum, D. (1983). Blind Signatures for Untraceable Pay-

ments. In Advances in Cryptology - Proceedings

of CRYPTO ’82, pages 199–203. D. Chaum, R. L.

Rivest, and A. T. Sherman, Eds., Plenum, NY.

Cox, B., Tygar, J. D., and Sirbu, M. (1995). NetBill secu-

rity and Transaction Protocol. In The First USENIX

Workshop on Electronic Commerce, pages 77–88.

Herreweghen, E. V. (2000). Non-repudiation in SET: Open

Issues. In Proceedings of the 4th Conference on Fi-

nancial Cryptography.

Herzberg, A. (2003). Payment technologies for E-

commerce, Chapter 13, Micropayments. Springer-

Verlag.

Herzberg, A. (2004). Controlling Spam by Secure Inter-

net Content Selection. In Proceedings of Secure Com-

munication Networks (SCN), volume 3352 of LNCS,

pages 337–350. Springer-Verlag.

J. Tang, A. Fu, J. V. (2004). Supporting Dispute Handling

in E-commerce Transactions, a Framework and Re-

lated Methodologies. In Electronic Commerce Re-

search Journal, volume 4, pages 393–413. Kluwer

Academic.

Kremer, S. and Markowitch, O. (2003). Fair Multi-Party

Non-Repudiation Protocols. International Journal on

Information Security, 1(4):223–235.

Kremer, S., Markowitch, O., and Zhou, J. (2002). An Inten-

sive Survey of Non-repudiation Protocols. Computer

Communications, 25(17):1606–1621.

Lacoste, G., Pﬁtzmann, B., Steiner, M., and Waidner, M.,

editors (2000). SEMPER - Secure Electronic Market-

place for Europe, volume 1854 of Lecture Notes in

Computer Science. Springer-Verlag.

Micali, S. and Rivest, R. (2002). Micropayments revis-

ited. In Progress in Cryptology — CT-RSA 2002, vol-

ume 2271 of LNCS. In Bart Preneel, editor, Springer-

Verlag.

N. Asokan, V. Shoup, M. W. (2000). Optimistic fair ex-

change of digital signatures. IEEEJournal on Selected

Areas in Communications, 18:593–610.

Nenadic, A. and Zhang, N. (2003). Non-repudiation and

Fairness in Electronic Data Exchange. In Proceed-

ings of 5th International Conference on Enterprise

Information Systems (ICEIS), pages 55–62, Angers,

France.

Pﬁtzmann, B., Schunter, M., and Waidner, M. (2000). Prov-

ably Secure Certiﬁed Mail. In IBM Research Report

RZ 3207 (#93253), IBM Research Division, Zurich.

R. Rivest, A. S. (1996). PayWord and MicroMint: Two

Simple Micropayment Schemes. In Proceedings of

the International Workshop on Security Protocols,

pages 69–87.

Ray, I. and Ray, I. (2002). Fair exchange in E-commerce.

SIGecom Exch., 3(2):9–17.

Zhou, J. (2001). Non-repudiation in electronic commerce.

Computer Security Series. Artech House.

Zhou, J., Deng, R. H., and Bao, F. (1999). Evolution of Fair

Non-repudiation with TTP. In ACISP ’99: Proceed-

ings of the 4th Australasian Conference on Informa-

tion Security and Privacy, pages 258–269, London,

UK. Springer-Verlag.

LAYERED ARCHITECTURE FOR SECURE E-COMMERCE APPLICATIONS

125