A NOVEL PEER-TO-PEER PAYMENT SYSTEM

Despoina Palaka

Information Processing Laboratory, Electrical and Computer Engineering Department

Aristotle University of Thessaloniki, 540 06 Thessaloniki, Greece

Petros Daras, Kosmas Petridis and Michael G. Strintzis

Informatics and Telematics Institute

1st km Thermi-Panorama Road, GR-57001 Thermi, Thessaloniki, Greece

Keywords:

peer-to-peer, e-payment, anonymous payment.

Abstract:

In this paper a novel payment system for Peer-to-Peer (P2P) commerce transactions is presented. It imple-

ments electronic cash-based transactions, between buyers and merchants. In this system, ﬁnancial institutions

become partners in the e-commerce transaction, conducted by their customers over the Internet. The innova-

tion of the proposed system is the reduction of the involvement of the ﬁnancial institutions to ancillary support

services. Moreover, the proposed system can be characterized as distributed allocation of provinces to mer-

chants, who are responsible for locally authorizing payments. Finally, it is optimized for repeated payments

to the same merchants.

1 INTRODUCTION

With the turn of the century over 70 million

computers are connected to the Internet. Suc-

cessful electronic business sites like Ama-

zon.com (http://www.amazon.com/) or ebay

(http://www.ebay.com/) had foreseen the busi-

ness potential of the huge number of users and

offer world-wide services to consumers for buying

and selling goods using their web browsers. These

business sites provide a centralized trading platform,

which offers a certain degree of security to its

customers. The advantage of such a centralized

architecture is that rules can be enforced easily. How-

ever, this turns into a severe problem if we switch

the point of view: In any centralized architecture

the central entity is a single point of failure and a

bottleneck in terms of bandwidth and computing

recourses which limits scalability and in turn causes

high infrastructure requirements.

Nowadays these kinds of drawbacks have lit a ﬁre

under the peer-to-peer (P2P) movement. P2P comput-

ing, a term coined after the strong and delivering con-

tents using peer users’ computers, scheme, is increas-

ingly receiving attention as a new distributed comput-

ing paradigm for its potential to harness “edge” com-

puters, such as PCs and handheld devices, and make

their underutilized resources available to each other.

In P2P architecture inexpensive computation power,

bandwidth and storage are being exploit. Further,

computers that traditionally have been used solely as

clients communicate directly among themselves and

can act both as clients and servers, assuming what-

ever role is needed at each moment. The new P2P

networking paradigm offers new possibilities for elec-

tronic commerce. Customer peers interchange roles

with merchant peers in this new network economy.

In this paper a new electronic-payment system is

presented. The proposed electronic payment sys-

tem is based on the novel “peer-to-peer” protocol

(P. Daras, 2003). This system is considered able

to exploit the capabilities offered by P2P networks.

The new system provides a complete anonymous, se-

cure and practical framework in which each peer can

act both as a merchant and a customer. Further, the

proposed system provides a full and secure payment

mechanism where personal information (order infor-

mation) cannot be exposed to unauthorized third par-

ties.

The proposed peer-to-peer payment system uses

the basic feature of the Secure Electronic Transaction

(SET) protocol (Mastercard, 1997), the digital enve-

lope technique. In SET, message data is encrypted us-

ing a randomly generated key that is further encrypted

using the recipient’s public key. This is referred to as

the “digital envelope” of the message and is sent to the

recipient with the encrypted message. it can be used

for macro-payments as well as for micro-payments. It

245

Palaka D., Daras P., Petridis K. and G. Strintzis M. (2004).

A NOVEL PEER-TO-PEER PAYMENT SYSTEM.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 245-250

DOI: 10.5220/0001388802450250

 SciTePress

enables merchants to locally authorize payments and

it uses Millicent’s (S. Glassman, 1995) main concept,

scrip, which is electronic cash issued by the bank or

the merchant.

The rest of the paper is organized as follows. In the

following Section a short discussion about traditional

(client/server) payment systems and P2P ones, along

with some basic deﬁnitions and notation, is given. Se-

curity considerations regarding the SSL protocol are

presented in Section 3. In Section 4 the main transac-

tion steps of the novel peer-to-peer payment protocol

are drawn. A short description of the proposed pay-

ment system, is given in Section 5. Some security

threats and adversaries as well as the security require-

ments of each party, are described in Section 6. Fi-

nally, conclusions are drawn in Section 7.

2 P2P PAYMENT SYSTEMS

Combining the P2P characteristics with the electronic

commerce, many companies are promoting payment

services via the P2P infrastructure (Trymedia Sys-

tems, Lightshare, PinPost, Center-Span, First peer).

All these companies claim to support P2P com-

merce, by using e-mails or SSL (Secure Socket Layer)

(A.O. Freier, 1996) for the purchase transaction. But,

these systems enable payments through the legacy in-

frastructure (e.g., clearing and settlement systems) of

the ﬁnancial institutions. In these payments systems

there is not a direct communication (P2P communica-

tion) between payer (customer) and payee (merchant)

(Figure 1). Additionally, the luck of the acquirer gate-

way is essential, because the “single point failure”

problem is eliminated. On the other hand, in existing

non-P2P systems, like SET, which is considered to be

the most successful and secure payment system, the

problem introduced by the payment gateway is essen-

tial, but it would be naive to neglect that the acquirer

gateway’s role is essential for security and ﬁnancial

reasons and it cannot be omitted. In the proposed

system three parties are involved (Figures 2,3): the

customer (who makes the actual payment), the mer-

chant (who receives the payment) and the acquirer

gateway (who acts as an intermediary between the

electronic payment world and the existing payment

infrastructure and authorizes transactions by using the

latter). Hereafter, the acquirer gateway will be ad-

dressed as simply the broker. The broker, who is used

to “bless” the transactions and to enable a trust rela-

tionship between the parties, introduces the problem

of “single point failure”. However, in this payment

system the broker’s participation in the transactions

has been minimized in order to minimize the effect of

the problem that the broker introduces.

In the propsed payment system the broker’s role

Customer

Merchant

Financial Network

Customer's

Bank

Merchant's

Bank

Internet

Figure 1: Electronic Commerce models

is essential only in the ﬁrst two transaction steps

(P. Daras, 2003) till a trustworthy relationship be-

tween the customer and the merchant is established.

In the third step, which is the payment transaction, its

role is the one of a trusted observer that records the

details of the transaction, so that disputes can be han-

dled.

In the proposed payment system the merchant can

authorize payments. This is accomplished by the use

of the scrip. As described in (P. Daras, 2003) there

are two kind of scrips: BrokerScrip and VendorScrip.

The ﬁrst one can be produced and veriﬁed only by

the broker and it is used by customers in order to ob-

tain VendorScrip. VendorScrip can be produced and

veriﬁed by merchants and can be redeemed only to

its producer. The main reason for using this type of

electronic cash (scrip) is to relieve the banks front-

end (broker) from overload and to distribute it in the

other parties involved in a product’s purchase. Thus,

though the proposed system is based on a central en-

tity (broker), its major differentiating factor from tra-

ditional electronic commerce models is the reduction

of the competence of the ﬁnancial institutions.

3 SECURITY CONSIDERATIONS

OF SSL

While scalability and fault-tolerance come

implicitly with P2P infrastructures, as has

been proven by successful P2P systems like

Kazaa (http://www.kazaa.com/) or Gnutella

ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

246

Customer

Merchant

Internet

Financial Network

Customer's

Bank

Merchant's

Bank

Broker

Figure 2: P2P payment system

C Customer

M Merchant

B Broker

Figure 3: Parties

(http://gnutella.wego.com/), security guarantees

similar to centralized architectures are more difﬁcult

to be achieved in a distributed environment. More-

over, there is a widespread agreement that electronic

commerce means for secure electronic payments are

needed. Indeed, the appeal of electronic commerce

without electronic payment is limited. Further,

insecure electronic payments are more likely to

impede, than to promote, electronic commerce. Thus

the premise of security for electronic payments is of

the most importance. SSL is the de facto standard

for secure (i.e., encrypted and integrity-protected)

communication on the web and it is integrated in

almost all web browsers and servers. SSL uses asym-

metric encryption but typically only the merchants

have public-keys and the customers are anonymous.

Encrypting bank account data with SSL is certainly

better than sending them in the clear, but the gain in

payment security is very limited.

• Regarding the broker, the use of SSL is completely

transparent since no messages are signed, thus the

merchant does not gain any security.

• SSL does not hide bank account numbers or any

other information from the merchant. Thus, it can-

not be used in ID-based authorization.

• Unlike SET or peer-to-peer protocol (P. Daras,

2003), SSL does not mandate any speciﬁc public-

key infrastructure. Thus, there is no guarantee that

a customer can verify the merchant’s public-key.

• In SSL, merchants and brokers need additional

mechanisms (beyond SSL) to transmit bank ac-

count data and authorization information.

is a 192-bits long,

symmetric key.

is a 1024-bits long, private

(asymmetric) key.

is a 1024-bits long, public

(asymmetric) key.

Enc

(.)

Symmetric encryption

using the AES (Rijndael)

algorithm.

Sign

(.)

Digital signature that uses

the SHA1 algorithm for

hashing and the RSA

algorithm for encrypting.

SignOnly

(.)

Asymmetric encryption

(using the RSA algorithm)

of a message digest

produced by the SHA1

algorithm.

Enc

(SignOnly

(.))

Symmetric encryption

(using the Rijndael

algorithm) of the

cipher-text produced by

the SignOnly

(.)

function.

PKEnc

KPu

(.)

Asymmetric encryption

using the RSA algorithm.

X,Y X is concatenated with Y.

Figure 4: Cryptographic Primitives

A NOVEL PEER-TO-PEER PAYMENT SYSTEM

247

4 THE NOVEL PEER-TO-PEER

PROTOCOL

In Figure 4 the notation of cryptographic primitives

used in the protocol is presented, while in Figure 5

the notation of the basic message elements used in the

payment protocol is shown.

Label of the message

UID

Unique identifier of the peer user.

Value of the BrokerScrip , VendorScrip or product.

Random generated nonce.

Unique identifier of the customer's or merchant's

bank account.

BrokerScrip .

VendorScrip .

BrokerScrip's or VendorScrip's corresponding

CustomerSecret.

Authorization message. R="OK" or " NOK "

Order information consisting of the product's

name, price, quantity and a unique identifier.

Figure 5: Notation of some basic message elements

Customer Merchant

BrokerScrip request

, UID

Enc

(SignOnly

(ID

))

Enc

(Sign

)) , PKEnc

)

BrokerScrip response

,CS

, N

, UID

, Enc

(Sign

)) ,

PKEnc

)

Figure 6: Obtain electronic cash from the bank

4.1 Obtain electronic cash from the

bank (BrokerScrip)

Initially the customer has neither BrokerScrip nor

electronic cash from the merchant (VendorScrip).

Through this transaction step (Figure 6), s/he estab-

lishes a connection to the broker and buys, using real-

money, the desirable BrokerScrip. Having received

the payment, the broker delivers the BrokerScrip to

the customer. The customer possesses only one Bro-

kerScrip and s/he can obtain a new one only if s/he

has spent it all. The BrokerScrip is used so as to ob-

tain electronic cash from a merchant.

Customer

Merchant

Initiate Purchase request

UID

Sign

)

Purchase request

, OI

, UID

, Enc

(Sign

)) ,

PKEnc

)

Purchase response

,OI

, UID

, Enc

(Sign

)),

PKEnc

)

Purchase request initiated

UID

, UID

Sign

)

Broker

Figure 7: Buy Item

ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

248

4.2 Obtain electronic cash from the

merchant

When a customer has electronic cash from the bank

and s/he wishes to purchase an item from a merchant,

s/he needs to obtain electronic cash from the speciﬁc

merchant (VendorScrip). If the value of the owned

BrokerScrip is bigger or equal to the one of the de-

sirable VendorScrip, this transaction step is initiated

(Figure 8).

Note, that the requested VendorScrip can be used

for payments only to this speciﬁc merchant. The bro-

ker beyond the veriﬁcation of the scrip, serves as an

observer of the transaction who records the details of

it.

4.3 Buy Item

If the customer wishes to purchase an item from a spe-

ciﬁc merchant and has the appropriate VendorScrip,

this scrip can be sent to the merchant (Figure 7). The

merchant checks and validates the VendorScrip, s/he

reduces its value and sends a new VendorScrip (the

change) to the customer. This interaction means that

the customer has paid the merchant. In this transac-

tion step both the customer and the merchant inform

the broker that a transaction is about to take place or

has taken place, respectively.

5 DESCRIPTION OF THE

PROPOSED PAYMENT SYSTEM

The proposed payment system is as an on-line sys-

tem; the central authority (broker) must be contacted

during the “Obtain BrokerScrip” and “Obtain Ven-

dorScrip” transaction steps, in order to “bless” value

transfers and in the “Buy item” transaction step in or-

der to record the transaction details. Even though the

online systems are more demanding in terms of com-

munication complexity, than the ofﬂine systems, they

are considered more secure than the last ones. Addi-

tionally, the proposed system can be characterized as

direct-payment system, because it requires an interac-

tion between payer and payee.

This system is proper for micro-payments as well

as for macro-payments. The desirable usage sce-

nario which fully exploits the beneﬁts of the pro-

posed system is the one where the customer obtains,

using macro-payment, BrokerScrip and VendorScrip

and then pays for the items using micro-payments. In

this scenario the interaction with the broker is min-

imized and even more his/her role is reduced to the

one of an external observer (less computation power

is needed, because s/he has just to verify the digital

signatures of the messages sent by the customer and

the merchant, and then record to a ﬁle the details of

the transaction).

Implemented on the JXTA (the term “JXTA” is

short for juxtapose, as in side by side. It is recogni-

tion that P2P is juxtaposed to client-server or Web-

based computing, which is today’s traditional dis-

tributed computing model) platform, the proposed

system does not require any special hardware and it

can be implemented in any platform.

Further, it offers some kind of divisibility by allow-

ing users to pay small valued products using high val-

ued scrip and returning the change as new scrip.

Regarding the role inversion the proposed system

has interchangeable roles; it allows users to assume

different roles (a user can act both as a merchant and

a customer), when convenient. However, it does not

allow users to become the bank.

In terms of security, the proposed system ensures

user’s privacy by allowing anonymous purchases, se-

curing transfers and protecting critical information.

Furthermore, it provides the means to detect unautho-

rized data modiﬁcation using an auditing mechanism

so that errors or misuse can be detected.

6 SECURITY REQUIREMENTS

AND SECURITY ANALYSIS OF

THE SYSTEM

Internet is a heterogeneous network, without single

ownership of the network resources and functions.

In particular, one cannot exclude the possibility that

messages between the legitimate parties would pass

through a maliciously controlled computer. Further,

the routing mechanisms in Internet are not designed

to protect against malicious attacks. Therefore nei-

ther conﬁdentiality nor authentication for messages

sent over the Internet can be assumed, unless proper

cryptographic mechanisms are employed.

Additionally, one must be concerned about the

trustworthiness of the merchants providing Internet

service. The kind of business that is expected in the

Internet includes the so-called cottage industry-small

merchants. It is very easy for an adversary to set up

a shop and put up a fake electronic storefront in order

to get customers’ secrets (e.g. (Wallich, 1999)). This

implies that the customers’ bank account numbers or

PINs should travel from customer to broker without

being revealed to the merchant.

Finally, in a payment system based on electronic

cash, customers should be considered trustworthy.

Customers’ attacks on the proposed system are lim-

ited to scrip attacks. These attacks are: double-

spending, faulty scrip attack and scrip forgery. Dou-

ble spending involves spending scrip more than once,

A NOVEL PEER-TO-PEER PAYMENT SYSTEM

249

faulty scrip attack involves creation of scrip without

the correct structure and scrip forgery attack involves

forging the scrip’s data.

1. Double spending: scrip is concatenated with

two secrets the MasterScripSecret and the Master-

CustomerSecret (P. Daras, 2003). These secrets are

known only to the producer of the scrip. Each time

a scrip is used, its secrets are deleted from the pro-

ducer’s look up tables, ensuring that the scrip can-

not be re-spent.

2. Faulty scrip: each user of the payment proto-

col can act both as merchant and customer and s/he

is able to produce scrip, but this scrip can only be

used to authorize payments with its producer (the

scrip carries the Producer’s ID).

3. Scrip forgery: scrip consists of the scrip body,

which contains the information of the scrip and a

certiﬁcate, which is the signature of the scrip. Any

alteration of the information contained in the scrip

body can be detected by verifying the scrip’s cer-

tiﬁcate.

7 CONCLUSIONS

In this paper a new payment system is presented. This

system is designed to be used in P2P networks. In

this system the broker’s participation is reduced in or-

der to reduce the “single point of failure” problem.

Further, the new system is compliant to all parties’ re-

quirements involved in a transaction and offers conﬁ-

dentiality and full anonymity to the customers. More-

over, it establishes a framework for enabling secure

payment transactions.

REFERENCES

A.O. Freier, P. Kariton, P. K. (1996). The ssl protocol: Ver-

sion 3.0.

Mastercard, V. (1997). Set 1.0 - se-

cure electronic transaction speciﬁcation.

http://www.mastercard.com/set.html.

P. Daras, D. Palaka, V. G. D. B. K. P. M. S. (2003). A novel

peer-to-peer payment protocol. In Eurocon 2003, The

International Conference on Computer as a tool. Eu-

rocon 2003.

S. Glassman, M. Manasse, M. A. P. G. P. S. (1995). The mil-

licent protocol for inexpensive electronic commerce.

In Proceeding of the 4th International World Wide

Conference.

Wallich, P. (1999). Cyber view: How to steal millions in

champ change. In Sci. Amer., pp. 32-33. Sci. Amer.

Customer Merchant

Initiate VendorScrip request

UID

, UID

, Enc

(SignOnly

(ID

)) , Enc

(Sign

)) , PKEnc

)

VendorScrip request

Br0

, UID

, Enc

(SignOnly

(ID

)),

Enc

(Sign

)) , PKEnc

) ,

Enc

(Sign

)) , PKEnc

)

Authorization request

, UID

, Enc

(SignOnly

(ID

)),

Enc

(Sign

)) , PKEnc

) ,

Enc

(SignOnly

(ID

)) , Enc

(Sign

)) ,

PKEnc

)

Change BrokerScrip

Br1

, UID

, Enc

(Sign

)) , PKEnc

)

Authorization response

, UID

, Sign

)

VendorScrip response

UID

Enc

(Sign

)) ,

PKEnc

)

Broker

Figure 8: Obtain electronic cash from the merchant

ICETE 2004 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

250