Netcents Protocol for Inexpensive

Znternet Puyments

Tomi J. Poutanen

A thesis subrnitted in confonnity with the requirements for the degree of

Masrers of Applied Science

Graduate Deparnent of Electrical and Cornputer Engineering

University of Toronto

O Copyright by Tomi Poutanen, 1997

1

Nationai Library m*m ofCanada Bibliothèque nationale du Canada

Acquisitions and Acquisitions et Bibliographic Services services bibliographiques

395 Wellington Street 395. rue Wellington OüawaON KIAON4 Ottawa ON K I A ON4 Canada Canada

The author has ganted a non- L'auteur a accordé une licence non exclusive licence dowing the exclusive permettant à la National Library of Canada to Bibliothèque nationale du Canada de reproduce, loan, distri'bute or sell reproduire, prêter, distn'buer ou copies of this thesis in microform, vendre des copies de cette thèse sous paper or electronic formats. la forme de microfiche/nlm, de

reproduction sur papier ou sur format électronique.

The author retains ownership of the L'auteur conserve la propriété du copyright in this thesis. Neither the droit d'auteur qui protège cette thèse. thesis nor substantial extracts fiom it Ni la thèse ni des extraits substantiels may be printed or othenvise de celle-ci ne doivent être imprimés .

reproduced without the author's ou autrement reproduits sans son permission. autorisation.

NetCents Protocol for Inexpensive Internet Payments

Tomi J. Poutanen

Masters of Applied Science, 1997

Graduate Department of Elecmcal and Computer Engineering

University of Toronto

NetCents is a lightweight. flexible and secure protocol for electronic commerce over the internet.

It is designed to support purchases ranging in value from a fraction of a penny to several dollars,

with an emphasis on micropayments. It is based on decentralized verifkation of electronic

currency at a vendor's server with offline payment capture and policing. This is accomplished with

floating scrips, or signed containers of electronic currency, that are passed from vendor to vendor.

No custorner trust is required, but the system does place a certain amount of trust in vendors, for

exarnple, to guard against double spending, and therefore requires a probabilistic verification

scheme to limit vendor fraud to unprofitable levels. The protocol can be extended to support fully

anonymous payments. An online arbiter is implemented that will ensure proper delivery of

purchased goods and that can senle most customer/vendor disputes.

Acknowledgements

I offer my sincerest gratitude to Prof. Heather Hinton for her patience, support and vast expertise in

the field and to Prof. Michael Stumm for his inspiration and insight.

A lot of my early work was discussed with Anthony Cheng, who always provided me with valuable

feedback and motivation to punue the concept funher.

Caught In The Web, Inc. granted me access to their equipment in order to conducting my research

and develop the prototype system.

Lastly, to my wife, Susan. who's support and patience never wavered.

Thank you all.

Table of Contents

2.3 Cryptographie F ~ ~ ~ t i ~ n ~ ~ w . w w ~ ~ o ~ ~ w a w w o ~ ~ ~ ~ ~ ~ ~ - - ~ ~ ~ m - - ~ ~ ~ ~ a - ~ - ~ ~ - - ~ ~ w ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ l O

2.3.1 One-Way Funcuons ........... . .............. . .... ...... ............................. ........................... . ...................... 10 2.3.2 Hash Functions .......................................................................... -- ............................................... 1 1

2.3.3 Secret-Key Cryptography ............................................................................................... 1 1

2.3.4 hblicKeyCryptography ....................................................................................................... 12

2.3.5 Digital Signatures ............................................................................ - .......................... - .......... 12 2.3.6 Digital Certificates and Certification Authoritics ..................................................................... 13

2.4 Hybrid Payment Sy~t~m~~..~~~~~~~.~~~..~..~~.~~~~~,,~~~.~~~~~~.~~.~~~~..~---~.~.---~~~~~~~.l3 2.4.1 Account B a ~ d Payment Systems .................................................................................... 13

2-4.2 Encryptul Credit Card Protocois ............................. - . . . . . . . . . . . .......................................... 14

2 Current Electrooic Payment Systems,,,,,-------*~.-.*------15

2 . Online Payment Rotocols ...................................................................... . ................ 16

....................................................................................................................... 2.5.2 Offline Payment Protocols 2 1

2.5.3 MiIlicent ................................................................................................................................................... 27

2.6 Comparative Evaluation of Existing Payment Protocoh- ....w----w.-.,..w..-HII.mmH.. 3 .............................................................................................................................. 2.6.1 Evaluation Criteria 2 8

3 Netcents Protocol .....e................................................................................................................ 31

3.1 Motivation for the Netcents Protocol ..mo.-*.,-..*.mw....~wrn...*.rn.ww..ae..mw......o..w* ....w..a.m.no.w.aJ1

3.2 Overview ~ - . ~ - ~ ~ - - ~ ~ . W 1 ~ I I o ~ - n ~ ~ - ~ w w ~ ~ ~ ~ o w w m r ~ ~ ~ ~ ~ - ~ ~ ~ ~ w o - - ~ - ~ ~ ~ ~ ~ ~ ~ w ~ o m ~ ~ ~ m ~ ~ ~ w w ~ ~ ~ ~ ~ H ~ * ~ ~ ~ * * - H ~ ~ ~ - J l

3 3 Pr0to~01 ~ ~ ~ ~ O H W ~ ~ O ~ O ~ ~ O H ~ ~ ~ ~ W M ~ ~ ~ ~ ~ ~ ~ H H . H ~ ~ ~ ~ ~ O ~ ~ O . H ~ W ~ ~ ~ W ~ ~ H ~ ~ ~ H ~ O ~ H ~ ~ t . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ O ~ ~ ~ ~ ~

Participants ............................................................................................................................................... 33

.................................................................................................................................... Hierarchy of Trust 34

Cornrnon Data Structures ..................................................................................................................... 3 5

............................................................................................... Customer-Issuing Authori ty Transactions 3 6

............................................................................................................ Customer-Vendor Transactions 3 7

.................................................................................................................. Scrip Relocation Transactions 38

.............................................................................................................. Payment Against Multiple Scrip 40

Policy for Medium and Large Scale Transactions ....... ... .... ... ........ .. . 4 1

................................................................ Vendor-Acquirer-Issuing Authority Offline Batch Processing 41

..................................................................................................................... User to User Fund Transfers 42

.................................................................................................................................... Online Arbitration 42

...................................................................................................... ....................... Anonymous Scrip ... 43

........................................................................................................................................... Blinding Sites 44

........................................................................................................................................ Vendor Policing 45

Vendor Tamperproof Hardware ..................... ..., .................................................................................. 47

................................................................................................................................ Currency Conversion 48

5.3 Vendor ~erver...~.~.........~~~.~

8 Discussion .................................................................................................................................. 61

8.1 The NetCents Protocol As a Universal Internet Payment Scheme ... 61

8.3 Currency Conversion ...................................... -.62

9 Conclusion and Future Work .................................................................................................. 65

................................................................. 9.2 FufUm Work ....- 0.68

....................................................................................................................... 9.2.1 Online Shopping Behavior 68

........................................................................................................................................ 9.2.2 Wide sale tests 68

................................................................................................................................. 9.2.3 Distribution Policies 68

................................................................................................................................. 9.2.4 Scrip fund allotment 69

9.2.5 Explore Other Signature Schemes.. ............. .... ................................................................................ 69

.................................................................................... 9.2.6 Further support for arbitracion. certified delivery 70

9.2.7 Analysis of Tamperprwf Hardware ......................................................................................................... 70

9.2.8 Inregration with SET ........................................................................................................................... 7 1

Appendix B O RSA ............................................................................................................................ 83

List of Figures

Figure 1 : Flow of scnp and electronic payrnent orders in NetCents ................... .... ................. 32

...................... .....................................................-....... Figure 2: NetCents hierarchy of min .... 34

........... Figure 3: Electronic Payrnent Order processing .. .............................................................. 36

Figure 4: Basic Netcents Transaction ..................... .... ....................................................... 37

Figure 5 : Scnp Relocation Transactions .................... .. ................................................................ 38

............................................................. Figure 6: Failed Scnp Relocation Recovery ................... .. 39

Figure 7: Offline Payrnent Capture Transactions ....................................................................... 42

........................... ........................................................... Figure 8: Odine Arbiter Transactions .. 43

Figure 9: Purchase of Anonyrnous Cash ......................... .. ........................................................... 44

Figure 10: Average payment latency to the fiequency of requests for various hit rates ................ 59

vii

List of Tables

Table 1 : Comparative analysis of payment protocol properties

Table 2: Netcents vendor server performance

Table 3: Comparative analysis of payrnent protocol properties

viii

1 Introduction

I . I Motivation

With the rapid growth of the Internet, there has k e n great expectation of a new marketplace, with

systerns that would facilitate electronic commerce. However, the expectations have greatly

exceeded the reality - no standard electronic currency exists, and profitable Intemet ventures have

been far and between. The concept of physicai, hand carried cash does not lend itself well to the

electronic medium. Electronic currency has the potential to be easily duplicated, forged, or stolen.

Methods of tracing electronic currency infringe on the anonymity of the spender. the anonymity of

the spender, however, ensures the untracability of the currency.

In this work we present a novel protocol that is inexpensive, secure, scalable, and can handle the

societal issues associated with electronic commerce. This research originated from the need of a

universal electronic payment mechanism for the Intemet that meets the security properties of real

world currency as we have corne to expect, and yet remains low cost to dlow micropayments and

scalable to a world wide basis. No current payment scheme meets the above requirements,

typically trading security for cost or vice versa. The difficulty stems from the ease at which

electronic bit patterns can be duplicated. Unlike hard coins and bills, which are protected from

duplication by the cost of the metal and starnping machine or by elaborate watermarking and

holograms, electronic data can be copied and retransmitted readily. A central server is typically

required to validate each transaction and to guard against double spending. This raises the cost of

the protocol, introduces a central bottleneck and a single point of failure, and increases the latency

of a payment. The scalability at a low cost of such systems is questionable, due to the distributed

nature of the Internet,

The Internet presents a new mode1 for commerce that necessitates low per transaction costs.

Automated processes can serve customers with electronic goods and services at a fraction of the

cost of material goods or human services. This insignificant variable cost of sales, and the huge

potential market 0 together will drive individuai prices down to unprecedented levels.

miniscule communication cost, custornized information withdrawal and direct marketing

The

will

-- - - - -- - - - - - - -

Tomi Poutanen, NetCents Protocol for Inexpensive Intenter Payrnents

enable traditional news and entertainment media to be decomposed and sold by section or article.

Individual information requests can be charged for, as is the case for stock quotes. background

information, knowledge base searches, etc.

This research has resulted in a novel payrnent protocol, named NetCents, that is both secure and

low cost, and is scalable to a world-wide reach with multiple currencies, and issuing authorities (or

mints). NetCents is a payment protocol that hnctions offline, without the need to contact a central

server. Thus, the cost and payment latency are kept at check, and scalability is not hindered.

1.2 Electronic Commerce and the htemet

Electronic fund transfers have been around well before the advent of the World Wide Web

0. However, until recently al1 electronic monetary transfers have been of significant value,

and handled via dedicated private networks. At fint, financial institutions used private

communication channels to wire money orders between one another. This quickly expanded to

include large commercial trading partnea, enabling companies to transfer funds amongst

themselves with a bank as an intermediary, and the term electronic commerce was coined.

Electronic commerce was formalized into a set of clearly defined standards, named Electronic Data

Interchange (EDO, which defined typical business transactions such as purchase ordea, invoices,

account balances, etc. [GE97].

Consumers were introduced to the world of cash alternatives in the form of credit cards, and later

debit cards. More recently, prepaid smart car& have started to surface in restricted uses. Smart

cards offer the only low-cost payment solution that scales down to sub-dollar level payments. This

is due to its reliance on the tarnper resistance of the smart card, and thus, a central server need not

be contacted at every transaction. The ability to accommodate low value transactions is of great

importance since in the current US. marketplace, there are many more purchases of value below

$10 than there are transactions of greater value [GS97].

Tomi Poutanen, Netcents Profocof for Inexpensive Interner Payments

Payment mechanisms over the Intemet are at their infancy, and no clear protocol has emerged as

dominant. At stake is a cut in al1 online purchases, which are expected to reach US $6 billion by

the year 2000 [GS97]. Current schemes reflect those of debit card systems, where a cenual bank is

contacted to authonze the payment. Much hope is placed on the recently released Secure

Electronic Transfer (SET) protocol developed by Visa, MasterCard and a consortium of the most

powemil cornputer software and hardware vendon. It aims to enable secure credit card purchases

over the Internet [SET97]. Unfortunately. SET will suffer many of the same costs associated with

the real world use of credit cards; namely, the reliance on available central serves and the cost of

diable and secure communication channels. SET, like credit card payments, does not cover the

full range of payment amounts, and is not suitable for payments below five dollars. An Internet

micropayment system is required to handle payments below those handled by the online debit

based systems or SET. This dissertation deals with an electronic substitute for cash to handle small

to medium valued purchases of electronic content over the Intemet.

I .3 Electronic Payment Protocols Payment mechanisms face an enormous arnount of attention and scrutiny due to the intrinsic

associated value of the transactions. A new payment system will only be accepted if it can be

uusted. To be twted, it needs to be fully documented and open to public scrutiny, much like

current cryptographic protocols. Payment protocols need to be provably secure against attacks.

The security is usually built on top of a cryptographic primitive, and the security will hold as long

as the cryptographic function holds. Security by hidden, unpublicized means or "security by

obscurity" is not suficient and is vulnerable to the vast hacker community.

It is imperative that the protocol is formally specified since it is likely to be irnplemented by a

number of independent software developers. Proper interoperability between independently

developed payment systems is crucial in overall system security, and it is important to clearly

define the required operation in every case. The formal SET specification alone is over 1000 pages

long!

Torni Poutanen, Netcents Protocof for Inexpensive Inrenier Paymenrs

1.4 Micropayment Protocols A rnicropayment refen to a transaction of low monetary value, comparable to a payment with

pocket change. The value of micropayments is typically below one dollar, and ranges down to

fractions of pennies. At the onset of the Intemet, this class of payment protocols received most of

the publicity and research, and it was predicted to revolutionize traditional markets and kick-start

online econornies. The payment protocol that dominated the micro-levei transactions was expected

eventuaily to also dominate the larger valued transactions. It was widely believed that online

content would be sold at extremely low prices at a "per view" cost, such that anyone owning a

homepage could charge a penny for, Say, a poem, or an online magazine could charge per article

read instead of the entire publication. Unfominately, despite al1 the great promise, the field of

micropayments has ken the slowest to materialize, due io the technical dificulties involved in

supporting such a system.

The underiying dificulty in implementation is due to the ease of duplicating electronic bit patterns.

Real coins are protected from duplication by the cost of the metal and the cost of the machinery,

and bills contain hard to produce watermarks, holograrns, etc. However, an electronic coin cm

simply be copied, or retransmitted for future payments, in an assault called double spending. To

guard against double spending, every payment needs to be authorized by the institution that issued

the coin [Ch95, CTS95, BelCo951. This is called an online payment scheme since the issuing bank

is invoived in every transaction. This presents serious scalability, reliability and usability

shortcornings, by introducing a central bottleneck, a single point of failure, and increased payment

latency. It also raises the cost of the transaction, and imposes a minimum cost per transaction, as

the issuing bank is faced with the real cost of authorking each transaction.

Schemes that do not rely on a central semer to guard against double spending are called offline

payment protocols WSh96, HSW96, GaSi96, HeYo961. Typicaily, these protocols are credit

based, since there is no hard protection mechanism to prevent a user from double spending, and

spending more than the balance in their account. Double spending is detected at the time of the

clearing process, when the merchants tum in the received coins to their respective banks. Once

double spending is detected, the malicious user is penalized and expelled. Though offiine protocols

have received a lot of attention from researchers and cryptographers, no offline payment systems

Tomi Pou tanen, Net Cents Protocol for Inexpensive Intemet Payments

exist in the general public use. This is due to the inherent risk of introducing a payment system to

the Intemet where hackers are abundant and wide-scale malicious colluding is easy.

1.5 The Thesis In this thesis we perform an in-depth analysis of existing and proposed payment protocols,

including the much heralded SET standard. W e identify a list of desirable attributes for an online

payment system, and propose a novel payment protocol, dubbed NetCents, that fulfills the

requirements. The motivation for the research was to create a novel payment protocol that is

secure, low cost, distributed and scalable and that works well on the unreliable Internet

communication network. We also wanted it to be anonymous and interoperable across many

financial institutions and various currencies.

We provide a formai specification and a working implementation of the protocol, which correctly

verifies Our performance assumptions. The prototype implementation was also used to analyze the

security and robustness of the system by deliberately attempting to break it. This was

accomplished by attempting to subvert the protocol using compted or deleted messages.

NetCents provides the necessary requirements for an effective online economy: low cost,

scalability, and adequate security, privacy and non-repudiation. Security is based on standard

public key encryption algorithms. It provides the anonymity of cash, yet the buyer can dispute a

purchase effectively to an online arbiter.

The key innovation of NetCents is its use of floating scrips. A floating scrip is a signed container

of electronic cumncy passed from one vendor to another, such that it remains active at only one

vendor at a time. A scrip has a monetary value, or balance, associated with it, dong with a unique

public and private key. Initially the bank assigns a certain balance to the scrip, which is decreased

as the user makes online purchases at various vendors. A vendor accumulates signatures of the

scrip at declining balances, and collects the difference in balance from the bank, by presenting

signed pre-purchase and post-purchase balances of the scrip. For example, presenting a vendor

with two signatures of the scrip at balances of 30 cents and 25 cents constitutes a five cent

Tomi Poutanen, Netcents Protocoi for Inexpensive Intemet Payrnents 5

payment. The vendor locally verifies the signatures to prevent customer fraud, such as double

spending. Since a scnp is active at only one vendor at a time, catching double spending is trivial.

Steps are built into the NetCents protocol to detect vendor fraud, and measures are taken to limit

fraud to unprofitable levels. Vendor fraud control is built into the system and can be demonstrated

not to be profitable. The distributed operation of the protocol removes the bank as a central

bottleneck and single point of failure, and lowers the end-to-end transaction latency.

The NetCents protocol was designed to minimize the operational cost of the protocol. The bank is

only required for offline batch processing and customer services. The vendor overhead of

supporting the payment system is carefully minimized by offloading the majonty of the

computation load onto the purchaser. h the common case, payment verification is reduced to two

modular multiplications. Vendor communication costs are reduced by distributing the scnps in a

LRU fashion, in an attempt to exploit the users' tendency to shop repeatedly at the same locations.

I.6 Outline The next section presents a background to the field of electronic commerce. The section describes

desirable qudities of new payment systems, and formulates a method of evaluating and comparing

various systems. It also presents previously proposed payment protocols in detail, and shows how

these protocols have attempted to rneet the desired goals. Section 4 presents the new payment

protocol, NetCents. The section contains a natural language description of the protocol, complete

with illustrations. Appendix C has the formal specification of the protocol. Section 5 discusses the

secunty properties of the protocol. What sets this thesis apart from most payment protocol

specifications, is that a protocol impiementation was completed in order to test the performance

hypotheses. The developed system is described in section 6. and the performance results are

discussed in section 7. Section 8 discusses the scalability properties of the protocol and outlines a

possible worldwide implementation. Lastly, section 9 has general discussion about micropayments.

followed by the concluding remarks and an outline of future work in section 10.

Tomi Poutanen, NetCents Protocol for Inexpensive Intemet Paymenrs

2 Background and Prior Work

2.1 Fundamental Properties of Money

As researchers develop new electronic forms of money, it is important to keep fundamental

monetary properties in mind. The protocol that provides the most life-like payment mechanism

will have the greatest chance of being accepted by the Intemet population. Ideally, we would like a

system that is as painless to use as is cash in the form of coins and bills.

Coins and bills can be traded between any parties with in physicd contact, quickly and without the

need of expensive verification equiprnent. Coins and bills are divisible clown to the lowest

denomination, or one cent. Divisibility is redized through the use of change to a payrnent, with

different denominations, and is enabled by the ease of tradability of coins.

When cash is exchanged, there is typically limited anonymity. Merchants or observers may be able

to identify the buyer, or will at minimum be able to extract useful demographics such as gender,

race, age, time and location of purchase, etc. Disclosure to third parties is limited in practice by the

relative difficulty of physical (as opposed to data) surveillance. This independent and distributed

disclosure of limited identity with purchases is acceptable, since the transaction records are not

communicated to a central tracking server. A central tracking server would be detrimental to the

privacy requirements of shoppers, and their desire to not disclose their purchasing power.

However, there are a number of negative qualities of cash. Cash is an attractive target for theft

since it can be easily transferred and cannot be tracked in practice. Coins and bills are easily

misplaced and lost. There is the inconvenience of carrying cash, and the effort required to count

coins and bills to satisfy a payment. Interoperability between different currencies is cumbersome,

and requires detrimental exchange rates. Most significantly, there is the real cost of supporting

cash transactions. Not only does the consumer often pay to withdraw money from an automatic

teller, the merchani endures the cost of counting, auditing, storing and depositing the money, as

well as the cost and liability of miscounting money, and the possibility of robbery.

Tomi Poutanen, NetCenfs Protucol for Inexpensive Interner Payments

Alternative forms of money have been introduced to counter some of these deficiencies. These

payment systems include credit cards, debit cards, prepaid smart cards, and travelen' checks. Al1

systems charge the merchant a small fraction of the cost of the transaction. In retum, the merchant

can reduce the liabilities and costs associated with cash transactions, and they can extend their

target market by the easy accessibility to large amounts of money and the built in support for credit.

Unfortunately, credit and debit card transactions are intended for payments above five dollars only,

due to the high per transaction costs [GS97].

In the field of computerized transaction systems, a transaction should have four characteristics:

atomicity, consistency, isolation and durability [GR93]. These four properties are commonly

referred to as the ACID properties. The ACID properties have recently also k e n used evaluate

electronic payment systems [CST95, CHTY961.

Atomicity: A transaction either completes h l l y or not at dl. This is the most important

concept in electronic fund transfers, since Funds should be transferred as a

whole and should not be created or be destroyed.

Consistency: Al1 relevant parties must agree on al1 critical facts of the exchange.

Isolation: Transactions should not interfere with each other, and the result of a set of

overlapping transactions must be equivalent to some sequence of those

transactions executed in non-concurrent serial order.

Durability: Unexpected failures and computer shutdowns will not cormpt the data. The

system should be able to recover to the last consistent state.

J. D. Tygar further subdivided the definition of atomicity in the context of electronic commerce to

include the delivery of purchased goods as part of the evaluation of a payment transaction [Ty96].

This is especiaily relevant in the realm of Internet commerce, where communication channels are

not reliable. Certified delivery of electronic goods parallels the rise of a multi-billion dollar

industry in iracked, receipted couner delivery of documents and packages.

Tomi Poutanen, Netcents Protocol for Inexpensive Intemet Payments

Money atomicity:

Goods atomicity:

Cerüfkd delivery:

Transactions that feature atomic transfers of money are said to be

money atomic. The transaction either completes fully or not at dl. and

no money is created or destroyed.

Goods atomic transactions are money atomic and also ensure that the

consumer will receive goods if and only if the merchant is paid.

Goods atomic transactions provide an atomic swap of the electronic

goods and funds - sirnilar to the effect of the "cash on delivery"

parcels.

Protocols that are goods atomic and also allow the consumer and

merchant to prove exactly what was delivered satisfy certified delivery

requirements. If there is a dispute, this evidence can be shown to a

iudple to prove exactly what goods were delivered.

Using the above classification scheme and the desired monetary properties. we will compare

existing payment systems (section 3), and demonstrate the power of the proposed NetCents

protocol.

2.2 Government ReguIQfions on Payment Systems

Most countries have a long history of banking and credit agency laws that are set up to protect the

financial security of the consumer. Special rules are also defined to accommodate government

police and tax agencies, in order to detect embeulement, money laundering or tax evasion. The

laws have been defined for traditional payment mediums, such as electronic hinds transfers and

credit card transaction, and have not yet k e n modified to accommodate payments over the Intemet.

The following is a compendium of relevant American rules and regulations that apply when

designing an internet payment mechanism (Canadian laws are not as developed and restrictive as

the Amencan ones, but in order for a payment system to succeed acceptance by the Amencan

regulators is a must).

Tomi Poutanen, NetCents Protocol for Inexpensive Internet Paymenrs

Provide detailed transaction information at consumer's request (subpoena 12 USC

1829. Bank Secrecy Act) or to law enforcement (under subpoena 12 USC 3403.

Financial Privacy Act).

Store records of al1 transactions above $100 for a minimum of five years (12 USC

1829, Money Laundering Act).

Report d l transactions above $3000 to the govemment (12 USC 1829, Money

Laundenng Act).

Any currency system which is accessed by a card or similar device must protect the

consumer against fraud by assuming al1 losses over $50 resulting from the ioss of this

device (1 5 USC 1693, 12 USC 3403).

Regulation E is the rule goveming electronic fun& transfen, and is required by ail

credit issuing agencies, and it may well be enforced over the Intemet. It is intended as

a consumer protection rule to help guard against losing money €rom erron or fraud in

electronic fun& transfers. It requires written advance authorization for arrangements

to move money electronically. written receipts for every transfer, a written periodic

statement, giving the consumer the right to challenge any electronic funds transfer for a

period of 30 days from when they get the statement. Financial institutions have a duty

to investigate any challenges and respond within a short time (usually 10 days).

2.3 Cryptographie Functions We briefly outline some cryptographic primitives required for the understanding of current

payment protocols.

2.3.1 One-Way Functions One way functions form the basis of al1 cryptographic operations. and indicate a mathematical

operation that is easy to calculzts in one direction but hard to reverse. An example of a one way

function is the multiplication of two large primes. The product can easily be calculated but the

factors of the product are very hard to deduce. RSA public key encryption attains its secunty from

this specific one-way function [RSA79].

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Payments

2.3.2 Hash Functions

A hash function is a one way operation that maps a variable length bit string into a fixed-length

value called the message digest. Traditional examples of hash functions are the check sum and

CRC32 operations. A gwd one-way, cryptographie hash hinction, H, has the foilowing three

qualities:

Given message M. it is easy to computer the hash, h. where h = H(M).

Given h, it is hard to cornpute an M such that H(M) = h.

Given MT it is hard to find another message, MT, such that H(M') = H(M)

Hash functions work by repeatedly applying one-way functions over the input data Stream. A

message digest is a value generated for a message (or document) that is unique to that message. It

is used to verify that the message has not been aitered. A cryptographically secure hash function,

as described above, certifies that the message digest cm only be produced if and only if the entire

message is known. Thus, the knowledge of a secret cm be communicated as a message digest

without revealing the secret itself. Two prominent hash functions have emerged as

cryptographically secure: MD5 [Ri921 and SHA [SHS93], with output Iengths of 128 and 160 bits

respectively. As a rough guide, hash operations are in the order of 10,000 times faster than RSA

public key encryption operations [RiSh96].

2.3.3 Secret-Key Cryptography

Secret-key cryptography, also known as symmetric cryptography, uses the sarne key to encrypt and

decrypt the message. Therefore, the sender and the recipient of a message must share a secret,

namely the key. A well known secret-key cryptography algorithm is the Data Encryption Standard

(DES). Symmetnc key cryptography is significantly faster than public key encryption or

decryption [Shi96]. Thus, long messages are typically encrypted by a symmetric key, which, in

Nrn, is encrypted using a public key operation.

Tomi Poutanen, NerCents Protocol for Inexpensive Internet Payrnents

2.3 -4 Public Key Cryptography Public-key cryptography uses two keys: one key to encrypt the message and the other key to

decrypt the message. The two keys are mathematically related so that data encrypted with either

key can only be decrypted using the other. These two keys are referred to as the key-pair, and

comprise of a public key and a pn'vare key. The user distributes the public key and keeps the

private key secret. Because of the relationship between the two keys, a message encrypted with

either one of the key pairs can only be decrypted with the other key. The public key is used to

transmit a message to a user, with the assurance that only the owner of the private key (or the user)

cm decode the message. The private key is used to decode received messages and to sign message

digests to prove the authenticity and source of a message or data file. This assurance is only

maintained if the user ensures that the private key is not disclosed to anyone else. The best known

public-key cryptography algorithm is USA (narned after its inventors Rivest, Shamir, and Adleman)

[RSA79].

2.3.5 Digital Signatures When combined with message digests. encryption using the pnvate key allows users to digitally

sign messages. When the digest of a message is encrypted using the sender's pnvate key and

appended to the original message, the result is known as the digital signature of the message.

Recipient of the digital signature c m be sure that the message really came from the sender. in trust

of the security in the two one-way functions. And, because changing even one character in the

message changes the message digest in an unpredictable way, the recipient can be sure that the

message was not changed after the message digest was generated.

In many applications, a signature is created only once, but the signature is verified repeatedly.

Such applications include the signature on digital certificates, or on downloaded software

components such as ActiveX controls. In a payment scheme it is also desirable to distribute the

computational burden to the buyers in an effort to minirnize the server load. In an RSA encryption

environment, this cm be accomplished by using srnail values as the public key exponent, such as 3,

17, or 65537, which take only 2, 5 and 17 rnodular multiplications respectively to exponentiate in

Tomi Poutanen, Netcents Prorocol for Inexpertsive Internez Payments

order to verify the authenticity of a signature [Shi96]. As a rough guide, signaiure verifcation is

about 100 times faster than signature generation WSh961.

2.3 .6 Digital Certificates and Certification Authorities Key distribution and hierarchy of trust are integral issues faced with secure, distributed system

designers. In a scalable environment, new secure communication channels are constantly created,

and new relationships between entities are constantly initiated. It is infeasible to trust every

identity at al1 times. Mead, a hierarchy of trust is used where trusted parties, called certification

authonties, sign facts about memben, such as name, IP address, public key, etc., into one

unforgeable digital certiticate. The certification authority is expected to perfom sufficient due

diligence on its client before signing the certificate. The public key c m be used to initiate a secure

communication channel, and to authenticate a signature.

2.4 H y W Payment Systems Hybnd Intemet payment systems, are transaction schemes that rely on traditional payment means to

facilitate online purchases.

2.4.1 Account Based Payment Systems The fiat instance of electronic commerce and online purchases came in the means of account based

systems. In account based systems, the user registea with a site, such as an online journal like

Wall Street Journal Interactive (wsj.com), and pays for an account using traditional means, such as

a postal mailed cheque, or a telephone cal1 to provide a credit card number. The account can serve

as a subscnption to a web site with prepaid access, or as a debit account for future purchases.

Amenca Online (AOL) has k e n using account based purchasing schemes even before the advent

of the m. AOL would track user purchases within the AOL framework and bill the member as

part of the monthly online charges.

Tomi Poutanen, NetCents Protocof for Inexpensive Interner Payments

With account based systems, no credit card numben are passed over the Intemet, and the cost of a

transaction is aggregated into a number of smaller transactions. This mechanism. however, has

serious drawbacks. This system does not lend itself to spur-of-the-moment purchases at distributed

Intemet content providen, due to cost and time involved in seaing up a customer-vendor

relationship. Due to the cost of setting up an account and the cost of the credit card transaction,

single, sub-dollar level purchases are completely infeasible, unless the cost of the payment cm be

aggregated over several future purchases. Another limitation is the lack of trust and arbitration:

there is no formal policing of prornised service for each account based site. Once the customer

deposits money into an account, they will have a difficult time withdrawing their balance.

2.4.2 Encrypted Credit Card Protocols As the Intemet matured and the use of encryption became cornmonplace, a number of companies

began offering online credit card purchasing systems. The idea was to transfer the credit card

number to the vendor in an encrypted form. and build a mechanism for the vendor to contact the

acquirer for authorization, and later clearing. Enabling technologies included SSL encryption

[Shi971 between the customer and vendor. vendor storefront applications with shopping baskets,

such as Net.Commerce, Merchant Server, Open Market or VenFone, and a gateway to traditional

credit card clearing systems, such as vPOS (virtual Point Of Sale terminal from VeriFone).

Again, per transaction costs imposed by current credit card systems prevent low valued

transactions. The usability of the system is hindered by the cumbersome need to key in the credit

card number and expiry date. This also opened the possibility of Trojan sites [TW96] that spoof

customers into thinking they are at a legitimate site by mimicking the content and URL as close as

possible. The most detrimental aspect of this mechanisrn is the accumulation of credit card

numbers by vendors. This database of valid credit card numbers is easily stolen by anyone who

could crack into the server, a frighteningly common occurrence.

Tomi Poutanen, Netcents Protocol for Inexpensive Internet Payrnents

2.5 Current Electronic Payment Systems In this section we describe the previous work in electronic commerce protocols and micro-payment

based protocols. We highlight the significant systems and efforts to date and describe the relevant

issues and mechanisms used in payrnent protocol design and implementation.

Payment protocols that are exclusively designed for electronic payments in a normal consumer to

merchant transaction can be categorized as either online or offline protocols. In an online protocol

a central payrnent authority is contacted to authorize the transaction. In an offline protocol, the

merchant verifies the payrnent using cryptographie techniques, and commits the payment to the

payrnent authority at a later time, such as late at night, in a batch process.

In general, online systems, if designed and implemented properly, secure the merchant and the

bank against customer fraud, since every payment is approved by the customer's bank. Customen,

however, may counter theft or loss of their electronic money, and rnay be cheated by merchants via

misrepresentation of goods or failed delivery. Typical national banking laws protect the customer

from fraud, and the credit agency or the issuing banking authonty is responsible for the cost of the

fraud.

However, an online authorkation system is expensive due to the necessity of a highly available and

responsive clearing system at the issuing authority. Offline systems were designed to lower the

cost of a transaction by delaying the clearing to a batch process. Offline systerns, however, suffer

from the ease at which electronic currency can be duplicated and spent repeatedly, termed double

spending. Thus, offline protocols concentrate on detecting and lirniting fraud, and in catching the

fraudulent Party. As a result, offline payrnent protocols are generally suitable for low value

transactions where accountability d e r the fact is sufficient to deter abuse. Online payrnent,

however, remains necessary for transactions that require prior restraint against pesons spending

beyond their available funds.

Tomi Poutanen. NerCenrs Protocol for lnexpensive internet Payments

2.5.1 Online Payment Protocols

2.5.1.1 CyberCash

CyberCash (h~~lwww.cvbercash.com~ is the North American de facto standard for low-value

transaction electronic payments. CyberCash is also based on one of the most basic forms of

payment protocol: A payment is made by a client signing a iransfer request (of a fixed monetary

value) to the merchant. The rnerchant submits this signed request to the bank for authorization of

payment. Depending on the availability of fun& in the buyer's account, the bank will reply to the

merchant with a signed authorization or refusal.

The scalability of the CyberCash protocol is doubtful since it relies on the availability of a single

online bank, and only supports one currency per wallet. CyberCash, in its present fom, is not

goods atomic. It does not provide the mechanisms for dispute resolution by an independent online

arbiter. Furthermore, the protocol is not anonyrnous in nature, allowing the issuing bank to track

every purchase. Most significantly, however, CyberCash is not cheap. The systern restricts

payments to a minimum of 25 cents, for which arnount it charges the merchant an authorization fee

of 8 cents (or 32 percent). Although this fraction diminishes as the value of the transaction

increases, it still makes the cost of the protocol relatively expensive for sub-dollar payments.

Despite the numerous deficiencies and the high cost of the protocol, CyberCash has established

itself as the standard small-valued, online payment vehicle in North America by aggressive

marketing and the formation of strategic alliances. It is accepted in a number of high-volume, big-

ticket sites such as espn.com, wsj.com, and the Internet NewsStand. Despite its comparative

success, CyberCash reported less than $70,000 in revenue frorn its online payment scheme in Q1

1997. This bleak financial performance signifies the lack of acceptance of online electronic

payment protocols to date.

2.5.1.2 NetBill

Carnegie Mellon researchers Cox, Tygar and Sirbu defined a payrnent system. NetBill [ n S 9 5 ] ,

that fulfills the goods atomic payment requirements. NetBiil also adds signed pnce quotes and

sales agreements. which can later be used by an arbiter to resolve disputes. The protocol is based

- -

Tomi Poutanen, NetCents Protocol for Inexpensive intemet Payments

on Kerberos [SNS88] tickets to authenticate users and to provide credentials such as age or a

membership that may make her eligible for a discount. The key contribution of NetBill is its

certified gwds delivery mechanism. In the protocol, the goods are delivered to the buyer in

encrypted format as part of the payment negotiation format Only once the goods have been hilly

delivered will the client software sign and send the electronic payment order (EPO) to the

merchant. The merchant, in mm, forwards the EPO to the NetBill server. dong with the key to

unlock the encrypted goods. The NetBill server will authenticate the purchase against the buyer's

account. and reply with a confirmation to the merchant. As the final step in the protocol, the

merchant provides the buyer with the key to unlock the go&. Failing to do so, the buyer can

retrieve the key from the bank. By combining the payment clearing process with the delivery of the

purchased goods' decryption keys to the bank, the protocol ensures that the buyer will only be

charged if she can retrieve the keys to unlock the goods, regardless of communication failure with

the merchant. The delivery of goods is cerùfied as long as the buyer can communicate with either

the merchant or the bank.

The drawback of the certified delivery protocol is the addition of extra messages, and the

significant increase in the amount of encryption used. Although the protocol is useful for single

download applications, such as downloads of files or single news articles, it is not suitable for many

Intemet applications, such as access to the entire site, Iive feeds and interactive applications. and

downloads of time-sensitive information. Furthemore, encrypting the entire Web page and its

multimedia elements in one packet will strip the Web browser of its progressive rendering

capabilities.

In early 1997, CyberCash announced that it had licensed the NetBill certified delivery mechanism

to be incorporated into its CyberCarh and CyberCoin payment system.

2.5.13 DigiCash

Introduced in 1995 by Danish cryptographer and privacy advocate David Chaum, DigiCash was the

first functioning Intemet payment system [Ch95]. The major differentiator to DigiCash is its

completely anonymous nature, which is accomplished via the use of blind signatures [Ch821 (see

Appendix C). DigiCash lets the user create coins which the bank signs using the blinded signature

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Payments 17

algorithm. The bank must accept coins that it has signed, and its main online function is to guard

against double spending.

Although DigiCash is cryptographically sound, it lacks the sophistication required of a scaleable.

worldwide payment system. DigiCash requires a centralized server to validate payments, which

creates a central boaleneck. Fiaws in the DigiCash protocol have been shown io lead to an

inconsistent state violating the money atomic definition [CST95]. If transfer of DigiCash tokens

from customer to merchant is interrupted then it is possible that both or neither party may believe

that it has legitimate access to the tokens. The protocol is also not goods-atomic, nor do the

messages support non-repudiation to support an online arbiter.

The use of cryptographic coins also presents a problem. To validate a payment, a bank must

perform public key operations for every coin submitted. and must search through al1 previously

validated coins for double spending. For exarnple, a payment of 4 cents would arnount to 4 public

key operations and searches. Thus, the protocol is significantly more expensive to support than

CyberCash.

There is also the issue of possessing the correct change for a purchase. Only a bank can issue

change, and thus may need to be contacted by the custorner prior to a transaction. This further

complicates the protocol and introduces points of failure, latency and cost to a transaction.

The initial enthusiasm gmered by the system at its infancy has mostly tampered off, and the

system has not been able to attract big-ticket, high volume merchants. The fact that DigiCash is not

based in North America has, undoubtedly, played a significant part in its struggles to gain

acceptance. North Amencan users have complained about intolerably long transaction latency and

low reliability as the central semer is contacted to authorize the payment. On the other hand,

DigiCash seems to be surviving in Europe where it has announced strategic partnerships with a

number of European banks in order to locdize into different currencies.

Torni Poutanen. NerCents Prorocol for Inexpensive Internet Paymenrs

25.1.4 SET - Secure Eiectronic Transfer

The much-heralded protocol for enabling secure credit card transactions over the Intemet has at last

k e n finalized as the SET 1.0 standard [SET97], and is only now seeing wide scale field testing

before public rollout. It was devised by a large industry consortium and charnpioned by Visa and

Mastercard, who saw the need for a solid extension to the Intemet before an alternate payment

scheme becarne the de-facto standard. The protocol replaces the failed attempts of the STT

[SïT96] protocol defined by Visa and Microsoft. We will borrow much of the vocabulary used by

SET and credit card systems. The customer's credit card is issued by an issuing authoriîy, or

simply an issuer. Many different issuen can supply the same brand of credit card. The vendor

collects credit card numbers and signatures, and contacts his credit card payment agency, the

acquirer, for authorization of the payment. The acquirer, in tum, contact's the credit card holder's

issuing authority via a secure, private network, called an interchange network, to clear the payment

and to transfer funds.

What sets SET apart from other online payment schemes is its secunty, scalability and robust

design. The protocol is based on the RSA encryption protocol and utilizes 1024 bit public keys,

and a 2048 bit root key. The trust relationship is hierarchicai, al1 stemming from one root key.

This enables multiple certification authorities, issuing authorities, and acquiren (merchant payment

agencies), facilitating wide scalability.

Unlike the original STï specification and the many predating credit card payment protocols, the

SET protocol is completely removed from any association with credit card numbers. Instead it is

merely an extension to the card issuer's services, and functions much like other online protocols do.

Where it differs from the normal online message passing sequence, is that the merchant's acquirer

uses traditional pnvate networks to contact the buyer's issuing authority to authorize the payment.

Though proven through years of service in the existing credit card infrastructure, these interchange

networks add a real per transaction cost. Currently interchange network service companies charge

between 5 to 10 cents [GS97] for timely and secure message passing between acquirers and issuen,

whether it be a credit card or a debit card transaction.

Tomi Poutanen, NetCents Protocof for Inexpensive Interner Payments

SET introduces a new application of digital signatures, narnely the concept of dual signatures. A

dual signature is generated by creating the message digest of two messages, concatenating the

digests together, computing the message digest of the result and encrypting this digest with the

signer's private signature key. The signer must include the message digest of the other message in

order for the recipient to verify the dual signature. A recipient of either message cm check its

authenticity by generating the message digest on its copy of the message, concatenating it with the

message digest of the other message (as provided by the sender) and computing the message digest

of the result. If the newly generated digest matches the decrypted dual signature. the recipient can

trust the authenticity of the message.

Within SET, dual signatures are used to link an order message sent to the merchant with the

payment instructions containing account information sent to the acquirer. When the merchant

sen& an authorization request to the acquirer, it includes the payment instructions sent to it by the

cardholder and the message digest of the order information. The acquirer uses the message digest

from the merchant and cornputes the message digest of the payment instructions to check the dual

signature. The dual signature is used to blind the merchant from any account and payrnent

instructions sent as part of the payment.

SET is not a lightweight protocol. Cryptographie functions are readily used, in terms of setting up

a secure channel, verifying certificates and signing messages. In total, up to a dozen public key

operations can transpire to authorize one transaction. This adds payment latency and further drives

up the per transaction cost. Coupled with the interchange network charges and the risk based cost

of maintaining a credit account, then the cost of SET payments will make sub dollar valued

transactions unfeasible.

SET was obviously designed with emphasis on security, and it lacks many of the desirable features

of other, far simpler payment protocols. SET, like real world credit card payrnent systems, does not

provide for user anonymity against the issuer. SET does not provide non-repudiation [SET97], and

does not have certified delivery of purchased goods. It would seem that SET was designed with

traditionai purchases in rnind such as cataiog sales, where a couner Company certifies the delivery

of goods.

Tomi Poutanen. NerCenrs Protocol for Inexpensive hternet Payments

2.5 -2 Offline Payment Protocols

2.5.2.1 Mini-Pay

Though IBM is heavily involved with SET, it concedes that SET is not suitable for micro-

payments. Thus, they have proposed a low-cost, offline payment scheme narned Mini-Pay

[HeYo96]. A Mini-Pay user requests a daily signed certificate containing the user's issuing

authority, her public key, and her offline purchasing limit. The offline limit is the maximal amount

of purchases per day that the buyer c m do, before an online confirmation for the issuing authority

is required.

The buyer makes a purchase by signing a Mini-Pay payment order. If the total arnount of

purchases for the day is lower that the offline lirnit, then the purchase is fulfilled instantly.

Othenvise, the issuing authority is contacted to authonze the payment and issue a new offline limit.

At fixed periods, the seller would aggregate al1 the payment orders received frorn al1 buyers. and

would send thern as a single, signed deposit message to his online financial institution for clearing.

In al1 offline systems, this clearing period is typically set at low-load periods, such as laie at night,

in order to minirnize the communication cost and computational impact on the rest of the system.

An offline clearing process greatly reduces the costs of implementing and running a bank, since this

relaxes the high availability, and fast responsiveness requirements.

2.5.2-2 Agora

Independently developed from Mini-Pay, Agora is a closely sirnilar offline payment protocol

developed at the Bell Laboratones [GaSi96J. Agora extends the simple Mini-Pay system by adding

an enhanced fraud protection protocol, oniine arbitration and user ID revocation. Fraud control is

introduced by requesting online authorization from the buyer's issuing authority when the buyer

exceeds an offline credit limit (as in Mini-Pay) and at some low random probability. The random

probability mirron the purchasing rate of the consumer. The bank will revoke a customer ID when

the customer either exceeds her credit limit, or when the purchasing rate exceeds some preset rate.

This restriction is imposed due to the belief that a thief would go on an electronic shopping spree

Tomi Poutanen, Net Cents Protocol for Inexpensive Interner Payments 2 1

with a stolen wallet. Revocation is accomplished by a broadcast of the customer ID to dl of the

merchants in the system.

Online arbitration is necessary aven the current lack of stability within the Internet. If the buyer

fails to receive the purchased goods, then an online arbiter is contacted with a signed item price

with a hash, and the corresponding signed purchase order. The arbiter verifies the signatures and

contacts the merchant. The merchant is obliged to resend the item to the arbiter. Failing to do so

will cause the arbiter to repudiate the transaction by sending the bank a copy of the signed purchase

order. Unfominately, adding non-repudiation adds the extra computation overhead of two costly

public key operations for the merchant.

A clairn to fame for both Agora and Mini-Pay is the minimal cost when measured in terms of

communication overhead. When the online bank is not contacted for authorization, then the

protocols can be hilly piggybacked on typical HTTP-Get request and reply messages (four

messages in total). The authors of Agora, in particular, argue that the cost of a payment protocol

should be measured in the number of messages more than in computational complexity.

Although both protocols are certainly low-cost, they have major shortcomings based on the

customer's ability to double spend. Online issuing authorities will need to perform a rigid due

diligence of the users before signing them on, such as is done by credit card cornpanies or by

financial institutions. This need increases initialization costs and reduces competition in willing

issuing authorities, thus ultimately driving up the cost of the system. There is also the question of

who pays in case of fraud. In Mini-Pay, the merchant will not receive payment, in Agora it is not

specified. Either way, a high level of fraud will drive up the cost of the system. Furthermore, there

is also the real possibility of theft of the customer wallet. In case of credit card theft, the issuing

authority is required to pay for dl of the fraud according to law, a law that would likely be

extended to cover online purchases.

Tomi Poutanen, NetCenrs Protocol for Inexpensive Interner Payments

Neither protocol is fully anonymous, due to the after-the-fact policing requirements. Thus, the

bank is able to collect a complete purchasing profile of their customers - a highly undesirable

characteristic of online micro-payment level purchases.

Even when a customer is found to double spend, how do you stop hem? Mini-Pay requires a daily,

signed certificate from the issuing authority. Thus, the criminal is free to spend at their hearts

content for one fidl day. Agora atternpts to correct this problem by implementing a revocation

protocol. However, the revocation aigorithm has real scalability problems. In a worldwide

implementation with millions of online merchants, how do you broadcast revocation messages to

al1 of them in a timely fashion? The criminal may still attempt to make several additional

purchases before the revocation message is received from the bank. Furthermore, imposing a

probabilistic purchasing rate notification scheme is dangerous. By bad chance, a customer making

several purchases within a short penod of time may have al1 of her purchases relayed to the bank,

and will quickly exceed her allowed purchasing rate. This, in mm, would tngger the massive

revocation broadcast. The probabilistic purchasing rate notification scheme aside, a preset offline

credit limit makes it possible for a criminal to double spend up to the offline limit at each and every

merchant on the system.

The above faults in offline payment systems make them only suitable for low-cost, non-tangible

electronic content with no barter value. It is especially hard to implement online lottery or

garnbling sites, software downloads, or shipped goods delivery. Content such as pay news sites,

online stock quotes and games, however, are suitable. It cm be argued that an online pay site does

not lose any revenue from criminal use of the payrnent protocol. since the cost of providing the

service is negligible. Chances are that the criminal would not have paid for the service anyway.

However, if the fraudulent use is abundant, then there is a reai cost of the protocol above the per

transaction costs imposed by the payment system.

2.522 PayWord, micro-iKP and Mlprp

The lightest payment protocols are not based on public key cryptography due to its inherent

computational cost. Payrnent systems like PayWord [RiSh96], Micro Payment Transfer Protocol

(MPTP) [HalB95] and micro-LW mSW96] are al1 based on the repeated use of one way functions.

Tomi Poutanen, NetCents Protocol for Inexpensive Intemet Payments

Like Agora and MiniPay, these protocols do not protect against double spending at different

merchants. The merchants merely venfy the validity of the coins, and the issuing authonty will

detect double spending at the time of the offiine clearing.

The three protocols are built on the concept of chains of cryptographie hashes, similar to MD5

[Riv92]. A hash chah consists of a randorn seed, X, and a set of coins, where co = X, ci = hâsh(ci_

,). The buyer initiates a set of transactions with a merchant by presenting a signed tuple (v, n, c,),

where n is the number of coins the user agent expects to spend at the merchant, and v is the vendor.

The vendor identifier, v, is included in the purchase order, in order to prevent malicious framing by

a vendor by simply spending the sarne coin at more than one other vendor in a double spending

attack. The coins are presented in descending order. For example, a payment of three coins (or

three cents) is accomplished by simply presenting the merchant with c,3. The merchant verifies

that c, = ha~h(hash(hash(c,.~ ))), which is computationally simple. The process is repeated for

future payments until n is exhausted. This process arnortizes the cost of one public key signature

verification over multiple payments, and substitutes the comparatively inexpensive hash function

for repeated purchases. The secunty lies in the difficulty of reversing the one way hash function,

and only the buyer can determine the proper payrnent bit-strings.

The micro-iKP actually signs each individual payment with a "highly efficient but specialized

signature scheme", in order to provide non-repudiation of payments. Details of the specialized

signature scheme are not given, and a normal signature scheme would increase the cost of the

system to the level of other offline payment schemes. PayWord and MPTP do not support non-

repudiation, and none of the three protocols are fully anonymous.

MicroMint is an extension to PayWord [RiSh96] that completely eliminates public key

cryptography. It bas lower security but even higher speed. A coin in MicroMint is a bit-string

whose validity can be checked by anyone, but which is hard to produce. The coins are represented

by k-way hash-function collisions. a computationally difficult problem to solve, but once solved,

cm produce many subsequent coins repeatedly. Just as for a red mint, a

scale" allows him to produce large quantities of such coins at very low cost

scale forgery attempts cm only produce coins at a cost exceeding their vaiue.

broker's "economy of

per coin, while small-

However, MicroMint

Tomi Poutanen. Netcents Prorocol for Inexpensive Interner Payments

suffea from the lack of trust in new cryptographic primitives, and in the lack of non-repudiation.

The lack of non-repudiation is especially troublesome for an offline scheme, as it leaves open the

possibility of purely malicious framing. Stolen coins or coins received as payment can be reissued

repeatedly. Thus, a broker cannot legally prove who is guilty of duplicating coins and will not be

able to pursue a cheater in court, but can only drop a suspected cheater from its system. Whether

such a system can operate in practice remains to be seen, and would seem to be highly risky in

nature.

25.23 Anoaymous Oftliae Payment Schemes

DigiCash Internet payment system demonstrated a relatively simple anonymous online protocol

using blind signatures. However, it requires every spent coin to be authorized by the issuing

authority that guards against double spending of coins. OMine protocols require after-the-fact

detection of double spending, and thus must be able to identify double spenders in order to penalize

them accordingly. Chaum et al introduced a remarkable offline payment protocoi which is

anonymous, yet allows the bank to detect and trace a "repeat spender" [CFN88]. If a customer uses

a coin only once, then her privacy is protected unconditionally. But if she reuses a coin, the bank

c m trace it to her account and can prove that she has used it twice.

The mechanism is based on a concept called one-show blind signatures. The use of the protocol

ensures that a certified public key, which has been issued by the bank in a blinded way, can be

traced to the party that it has been issued to ifand only ifmore than one signature is computed with

respect to the key. The mechanism consists of letting the bank certify the public key of a user in

such a way that the user cm perfectly blind the public key and the certificate thereon, but not part

of the corresponding secret key. The signature scheme employed by the user must be such that one

signature does not reveal this part of the secret key, whereas two signatures do. The mathematics

of the protocol are extensive and, as such, beyond the scope of this dissertation.

So far, no anonymous, ofTline payment system has been introduced into the marketplace. This can

be attributed to the lack of trust in the new cryptographic primitives, and its added computational

cost and complexity. A coin is represented by a number of independent, signed tokens, and thus,

the storage, communication and verification costs d l increase significantly. The bank, in

Tomi Poutanen, Net Cents Protucol for Inexpensive Interner Payments 25

paiticular, will face a heavy burden in creating and verifying the coins, and will most likely need to

define a per-transaction or a percoin cost. Since the protocols are coin based they face many of

the sarne problems as DigiCash: lack of divisibility of coins; the need for exact change; the cost of

the iterative validation of al1 coins independently per transaction; and the lack of offline

transferability of coins.

There has k e n a lot of ment research into the field of anonymous offline protocols that propose

new schemes that attempt to overcome the above limitations [CP93, Fe93, EC94, SPC951. Tholigh

incremental improvements are king made, the solutions are still much more complex than online

or other offline protocols.

23.2.4 sinart car& Smart cards ofier a promising solution to the double spending problem faced by offline protocols.

Physical car& are tightly packaged devices comprising of a microcontroller, memory and an y 0

pon. The packaging is designed to ensure that the microcontroller and the memory cannot be

tarnpered with, without breaking the entire system. There are several protocols that have been

defined on the basis of tamper resistance of smart cards pr95], [ChPe92]. A number of smartcard

solutions are currently in trial, such as those of Mondex in Ontario, or the Visa-Chip cards, with the

hope that they can serve as replacement for cash for low valued purchases.

In the Intemet realm, the obvious drawback of the smart card scheme is the requirement of a smart

card reader on every cornputer. In section 4.3.1 1 we will outline the use of tamper resistant devices

as an extension to the NetCents protocol to guard against malevolent merchants. However, unlike

the offline use of smart cards, only the merchants need be equipped with tarnper resistant devices,

in order to ensure provable system security.

The existence of tmly tamper resistant devices is a hotly debated topic [GSTY96], with every

significant "tamper resistant" consumer device having been cracked, from pay-TV chips, to pre-

paid long distance smart cards, to the Clipper chip, and to the venerable Dallas DS5002FP Secure

Microcontroller [AnKu96]. The fear is that if a universdly accepted payment system is dependent

on the tamper resistance of a smart card, then it will have to withstand tremendous scrutiny and

Tomi Poutanen, NetCents Prorocol for Inexpensive Interner Payments

relentless intrusion attempts. If the security is bmken in such a way that false car& can be

reproduced or altered in an automated and rapid succession, then the system would collapse and, at

minimum, al1 existing cards would have to be replaced.

2.5.3 Millicent Digital Equipment's Millicent [DEC95, Man951 is close in nature to our proposed NetCents

protocol. Millicent, like NetCents, does not fa11 into either the online or the oMine category, but

rather is a distributed allocation of fun& to merchants, who locally authonze payments. In brief,

both are automated account based systems.

Millicent introduces a scrip, which is a digital money that is honored by a single vendor. In

Millicent's plan, a customer will have their electronic credit distributed at various site accounts on

the Intemel with a comrnon management interface - in effect, prepaying for access to a vendor, as

in an account based scheme. On the first visit to an online merchant, the customer needs to ask her

issuing authority for a signed scnp specific to the merchant. The scrip is transported to the

merchant, who will subsequently authorize payments from the customer against that scrip. A scrip

is analogous to a prepaid calling carci, or a debit card specific to one merchant.

Once the scrip is fully used, the customer asks the broker to transmit additional hnds in scrip to the

merchant. When the funds are required elsewhere, the balance of the scrip can be redeemed by the

broker on request by the customer. The protocol was designed on the assumption that online

consumers, as in the real world, tend to shop repeatedly at the same merchants. If this assumption

holds, then indeed the protocol is inexpensive to the issuing authority due to its limited and mainly

offline involvement.

However, if a customer does not tend to revisit online merchants (since physical location is of no

importance in Cybeapace), then this protocol becornes even more expensive than the online

protocols. The fun& are can only be redeemed by the broker, which must first request the scrip

and signed balance from the vendor, it must venfy the signature, and lady it needs to create and

Tomi Poutanen, NetCents Protocol for Inexpensive Internet Puymenrs

sign a new scrip. As with online payment protocols, this will result in longer payrnent latencies and

a single point of failure.

The movement of fun& is especially troublesome when a custorner balance nears zero, and the

number of scrips approaches one. At this point, fund transfers become common, requiring broker

involvement to redeem existing scrip and sign new ones.

Millicent does not use public key encryption, but uses shared keys with cryptographie hashes.

Though this operation is substantially faster than public key cryptography, it implies that non-

repudiation cannot be assured, and an online arbiter cannot be implemented. Shared keys also

introduce communication overhead between the issuing authority and the account holder when

creating and re-issuing scrips. Furthemore, the protocol is not fully anonymous. since the broker

handles the customer's account transfen and scrip creation.

2.6 Comparative Evaluation of Existing Payrn ent Prorocok

2.6.1 Evaluation Criteria The payment protocols are compared with respect to the following properties and attributes.

Large payments - support for payments in value above five dollars.

Small payments - support for small to medium valued payments ranging from 25 cents to

5 dollars.

Micro payments - support for micro-level payments of value below 25 cents including

fractions of a penny.

Fast vendor validation - fast validation of payment deposits at vendor, public key message

signing and decryption operations are not allowed due to their computational load. A

typical Pentium Pro semer should be able to validate at least 10 transactions per second.

No customer HW - payment system users do not need to invest in additional hardware.

No vendor HW - payment system does not require vendor side hardware.

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Payments

Money atomic - payment transaction either completes fully or not at d l .

Goods atomic - a purchase including goods delivery and money transfer either completes

fully or not at dl.

Certif~ed delivery - protocol is goods atomic and ais0 allows the consumer and merchant

to prove exactly what was delivered satisw certified delivery requirements.

Double spending protection - online protection against customer double spending.

Scaiable - the protocol can be extended to a world wide reach.

Distributed - the protocol does not reiy on a central semer for authentication.

Divisible - support for multiple denominations and a range of payment values.

Traderable - currency can be transferred frorn one user to another.

Interoperable - support for multiple currencies.

Partial anonymity - buyer identity is hidden frorn the vendor but not the bank.

Fuli anonymity - neither the vendor nor the bank can associate a purchase with a user.

Non-repudiation - steps in a transaction cm be proven to have taken place by

cryptographie

Tomi Poutanen, NetCenrs Prorucol for Inexpensive Interner Payments

2.6.2 Comparative Evaluation

1 Fast vendor validTn. 1 J 1

1 ~oocis atomic I I 1 Certified delivery 1 1

Double spending protection

1 Distributed 1 1 1 Divisible 14

Transferable

Interoperable

1 Partiai anonyrnity 1 J 1

Table 1: Comparative analysis of payrnent protocol properties

Torni Poutanen, NetCents Protocof for Inexpensive interner Payrnents

3 NetCents Protocol

3.1 Motivah-on for the NetCents Ptotocol This research orïginated from the need of a universal electronic payment mechanism for the

Internet that meets the security properties of real world currency as we have corne to expect, and

yet remains low cost and scalable to a world wide basis.

3.2 Oventiew The NetCents protocol bears a lot of similarities to Millicent. Like Millicent, money is transferred

to vendon in the fom of scnps, in aggregate amounts. Multiple payments can be charged against

the value of one scrip, until the fun& within the scrip are fully spent, or the hnds are no longer

required at the vendor. The difference between Millicent and NetCents lies in the allocation,

designation and distribution of scrip. In Millicent, scrips are vendor specific and scrip relocation

only occun from the broker to the vendor and back. In contrast, NetCents scnps are not vendor

specific and can be transferred from one vendor to another without the involvement of the broker.

Here the customer's funds are distributed at frequently visited merchants across the Intemet, and

can be transferred to a new vendor without the involvement of the broker. A scrip remains active at

only one vendor at a time, thus averting customer double spending.

The NetCents protocol is based on the assumption that online shoppen tend to frequent the sarne

vendor sites repeatedly on the Intemet. As such, the scrip relocation algorithm attempts to

minimize scnp movement by drawing from the user's expected hiture shopping behavior. The

distributed vendor scrip mode1 behaves much like a system cache - scnps are held at the sites

where recent purchases have k e n made. Like with cache lines, there is a fine balance between

how much value a scrip can hold to how many scnps there are. If a customer tends to spend al1 his

money at only a handhl of sites, then having only a small number of large vaiued scnps would

lend the most efficient solution. On the other hand, this could be disastrous for a customer making

many small payments at a broad range of vendors. The allocation can be fine-tuned over time by

the user agent based on the user's past shopping tendencies.

Torni Poutanen, NerCenrs Prorocol for Inexpensive Intemet Payments

.... - ...... .. Authority ----..____ ---.._..

Vendor 2 ---L

Customer Scrip

Vendor Scrip

........... --..-

Figure 1 : Flow of scrip and electronic payment orders in NetCents

From a bank's point of view, the system is very cheap to implernent and oversee, regardless of the

purchaser's shopping tendencies. The bank merely needs to sel1 NetCents to the customers, and to

send out scrïps when requested. The cost of sending out the scnp is amortized over the many small

payments that each scrip will render. The bank is later updated offline as the vendors cash in their

receipts. Also, there is minimal error correction and vendor policing overhead that needs to be

accounted for. The bank' s mission-critical workflo w is independent of the size of transactions

conducted by the vendon. Thus, it need not set a minimum transaction cost, and can sirnply

demand a percentage of al1 revenue.

The protocol executes a purchase with a signed electronic payment order (EPO). An EPO is a

signature of the snapshot of the scnp, i den t iwg the vendor location and balance, as well as the

fundamental elements of the transaction. EPOs are used by the vendors to collect the ciifference in

balance fiom the bank. An EPO comprises the components of a transaction and include the payer

(ScnpID), the payee (VendorID), purchased item identifier (ProductID), the balance remaining in

the scrip after the purchase, and the date of the transaction.

The signing algorithm can be any one of a number of public key signature algorithms. The key is

to choose an algorithm that minirnizes the verification cost performed by the vendor and the bank.

We have chosen RSA, the most popular public key encryption algorithm, for our initial protocol

implementation. For an RSA signature system where the public key, e, is kept short, for example 3,

Tomi Poutanen, NetConts Protucol for Inexpensive Infernet Pcryments 32

17,257 or 65537, verification is very fast [Sch96]. Consider a public key of 3, as is used in PEM

@ai93]: this would require only two multiplications and a modulo cdculation. On the other hand,

the private key, d (where d is the rnodular inverse of the public key, d: d = e-1 mod (p-l)(q-l), is

the same order of magnitude as the composite number, n (where n=p*q). Thus, the signing process

performed by the customer is a computationally expensive exponentiation, yet verification is

straightforward, greatly reducing the vendor computation overhead.

3.3 Protocol The formal protocol specification is defined in Appendix A, in parallel to this natural laquage

description.

3 -3.1 Participants

NetCents Root Certifcate Sewer - In order to accommodate multiple payment entities,

and dynamically created trust relationships, al1 memben have certificates that have been

signed by either the root server, or entities trusted by the root server. Specifically, the root

certificate server signs periodic certificates for issuing authorities and informs acquiren of

revoked certificates. It does not participate in any online transactions.

Issuing Authority - Online financial institutions that act as banks to customers by selling

scrip, providing detailed transaction records, and guarding against misuse and double

spending. In order to be tmsted by NetCents software, the issuing authority must possess a

valid certificate signed by the NetCents root key.

Acquirer - An acquirer is an online financial institution that serves as vendor's clearing

center. The typical flow of money is from the customer to his issuing authonty, and later,

when presented with an EPO for a scrip, from the issuing authority to a vendor's acquirer,

and finally to the vendor's bank account.

Tomi Poutanen, NetCents Protocof for Inexpensive Intemet Payments

Customer - Buyers of scrip fiom issuing authorities. Typically, customers create long term

relationships with issuing authonties for continuous tram fer of !%mis. The customer is

provided with a certificate signed by her issuhg authority. The certificate allows the

customer to handle secure online transactions and communication with the bank. The

customer interacts with the system via a customer agent, representing the software interface.

Vendor - A vendor is an online store that accepts NetCents scrip as a form of payment. A

vendor has a long term relationship with an acquirer, and holds a certificate signed by that

acquirer.

Arbiter - Arbiters are mutuaily tmted, independent observers to transactions. Their

Function is to guarantee delivery of purchased goods, and for dispute resolution.

Blinding Site - Since floating scrip travels f?om one vendor to another, there is a hint of

purchasing demographics that is revealed in the transfer of scrip. A blinding site is a void,

non-functional site that the customer agent can pass a scrip through in order to hide the

previous location of the scrip.

3.3.2 Hierarchy of Trust

Issuing Authority Acquirer

Customer Arbiter Blinding Site Vendor

Figure 2: NetCents hierarchy of trust

Tomi Poutanen, Net Cents Protocol for Inexpensive Internet Payrnents

3.3.3 Common Data Structures The acnial data structures used are specified in Appendix A. 1, in C notation. Digital Certificates

are issued to every member in the Netcents community. Al1 digital certificates have expiry dates,

an IP address where applicable and their RSA public key. The vendor certificate also includes a

liability amount to which the vendor is trusted, and is used in vendor fraud detection. The customer

certificate can optionaily include terms such as address, nationality, age or membenhips that can be

presented to vendors for proof of eligibility or discounts.

A scrip is divided into the vendor scrip and the secret customer scrip. Only the vendor scnp is

reveaied to vendors and is transported in the clear. Thus, it must be signed by the issuing authonty.

Scnps have public and pnvate RSA keys held in the vendor and customer scnp, respectively.

Associated with a scrip is the scnp snapshot balance. The balance is first set to the monetary value

of the scrip, as purchased by the customer, and the balance is decreased in accordance to payments

made against the scrip. A payment is made by presenting the vendor with a signature of the scrip at

the post-purchase balance. The concept of Electronic Payment Orden (EPO) are borrowed from

NetBill, and contain the scnp ID (ScnpID), vendor ID (VendorID), product ID (ProductID),

balance and date, al1 encrypted with the scrip pnvate key. Since the items in the EPO can be

represented in fewer than 512 bits, then a single RSA block can be used to encrypt the data.

Vendor validation involves the exponentiation to the small public exponent modulo the RSA

modulus, and a cornparison with the expected EPO values.

Tomi Poumen, NerCents Protocol for Inexpensive Interner Payments

EPO Ciphertext

5

Figure 3: Electronic Payment Order processing

Balance

0

3.3.4 Customer-Issuing Authority Transactions Customers m u t have an account with some online issuing authonty before a purchase can be

initiated. The issuing authority can be the electronic arm of a traditional bank, or simply a new

banking entity that sells NetCents scrip and performs the appropriate transaction tracking. The

purchase of NetCents currency is performed via a more mdtional and costly mechanism, such as

SET, a delivered cheque, or an electronic transfer directly fiom the buyer's bank. Connection

security will be provided with standard encryption protocols and reputed certificate authonties.

g cn 2 i, n Scrip Private Key

Date "

The customer purchases NetCents in bullc, the value of which is distributed among a number of

scrips. For example, on a $10 purchase of NetCents, IO scrips worth one dollar each can be

generated. The scrips need not be of equal value, and in the future, the distribution will be

determined by the user agent depending on the customer's pst shopping behavior. The bank-

generated scrip has a public and a pnvate part. The public part, calied vendor scrip, is evenhially

distributed to vendors where the customer has shopped; it contains a short public key. The

ProductID " E

Balance "

Tomi Poutanen, NerCenrs Protocoffor inexpensive lnfernet Payments 36

5 >

Date jL ProductID 32 a

VendorID ' 2 ScripID " BankïD "

VendorID 3L ScripID 64 B M D 3L

customer scrip, holds the private key, and is rehlmed to the customer through a secure charnel,

such as SSL.

3.3 -5 Customer-Vendor Transactions The following sequence of messages describes a transaction between a customer and a vendor in

the coune of a purchase. The transaction starts out with the user requesting a page or a quote for

an item on a Web site (MO). The vendor returns the VendorID, ProductID, price quote, date and

the vendor certificate, al1 unencrypted (Ml). The customer agent verifies the VendorID and vendor

IP address against vendor certificate. Once the certificate is venfied, the customer agent will

prompt the user to accept or decline the purchase to the vendor. If the customer has sufficient

arnount of rnoney in a scnp at the vendor, then she will generate a signed electronic payment order,

EPO. with the proper balance and transmit it to the vendor (M2). Foliowing sections defme the

process of transfemng the required scrip to the vendor. Upon receiving the EPO, the vendor

decrypts it and venfies its contents, ScripID, VendorID, Balance and Date. If the EPO decrypts as

expected the EPO will be stored for a later offline transaction with the bank, and the customer is

supplied the goods and an acknowledgement (M3). After a successful transaction, both the vendor

and the customer subtract the value of the purchase f?om the balance of the scrip.

MO: Request quotation

- MI Customer Vendor

M2

--

M3: Goods

Figure 4: Basic NetCents Transaction

If M3 is lost, then the customer agent will retransmit the EPO in M. NetCents requires that the

customer be able to repeatedly download purchased electronic content by presenting the EPO. This

is an important requirement in the unstable Internet communication environment. Html page and

file downloads are often lost and need to be restarted. If the vendor fails to deliver the goods, then

an online arbiter is involved as described in section 3.3.12. Can the customer resel or distribute the

Tomi Poutanen, NetCenfs Protocolfor Inexpensive lnternet Payments

EPO over the Intemet for anyone to use for downloading the electronic goods? Certainly.

However, they can equally well redistribute the downloaded electronic goods. However. the

merchant server and the online arbiter should incorporate logic to prevent repeated downloads fiom

varying IP addresses using the same EPO.

3.3.6 Scrip Relocation Transactions When a customer wishes to make a purchase at a vendor that does not have any, or not enough,

scrip, the customer agent instructs the vendor where to fetch the vendor scrip. At this time, an LRU

algorithm is used by the customer agent to determine the vendor or bank from which to request the

scrip, in an attempt to minimize scnp migration cost. However, friture work is required in better

optimizing the movement of scrips based on online shopping behavior.

The relocation of a scnp to Vendor, VendorID, V, fkom an old vendor, OldVendorID, OV. is

described as follows:

- ; M4 MS , Customer Vendor O Idvendor

4 - 4 M7 M6

Figure 5: Scrip Relocation Transactions

The process is started by the customer agent, who selects which scrip to fetch and f b m where. The

scrip can be located at the issuing authority, if it is still unused. An electronic payment order (EPO)

is calculated by the customer agent for the scnp and the new vendor identifier. The signed EPO

and the old vendor identifier are sent to the new vendor (M4), who checks the revocation list

against fraudtiient vendors. The vendor transmits the receipt to the old vendor (M5). Only the

holder of the private scrip can generate the proper signed EPO, and thus an imposter cannot initiate

false scrip transfer requests. Once the old vendor has venfied the receipt, the scnp is signed, dong

with the current balance, and transmitted to the new vendor (M6). The new vendor venfies the

scnp and the receipt and stores both the signed scnp and receipt. The signed scnp may be required

Tomi Poumen, Net Cents Protocol for Inexpensive Internet Paymenrs

for disputes between the vendors, and the receipt is used as the base receipt for fiiture transactions

with the customer. Lastly, the customer is notified that the scrip was transfened successfully and

that the payment transaction can commence (M7).

An inherent problem in distributing fùnds at Web servers lies in fkquent server downtime, which

may make the h d s inaccessible. In the Netcents relocation protocol, if the vendor holding the

least recently used scrip does not respond to a transfer request, then M7 will be a negative

acknowledgement. The protocol is restarted with the next LRU vendor until al1 other vendors are

exhausted. If al1 the remaining fimds are at an inaccessible vendor, then the protocol, as specified.

caxmot complete the purchase.

NetCents extends the protocol to accommodate purchases under holding vendor downtime. When

the customer receives the negative acknowledgement (M7) for the only remaining funds, it can

apply for credit fiom the issuing authority. The EPO is sent to the vendor (Mg), which forwards it

to the issuing authority (Mg). The issuing authority first verifies that the holding site is indeed

down (M10). The issuing author@ will also reference the scrip database records for the last

updated balance on the scrip, and veriQ that the claimed scrip balance is equai or lower. The

issuing authority can recreate and sign the scrip and pass it to the new vendor (Ml 1).

- 4 M7

M5 , Customer Vendor OldVendor

1 M8 MI 1 v

Issuuig Authonty

-

Figure 6: Failed Scrip Relocation Recovery

The decision to recreate the scrip depends on policies set by the issuing authority and vendor. If

the scrip used is not of anonyrnous type, then the customer can be caught for misuse in after-the-

fact double-spending detection. Thus, the issuing authority can grant a certain amount of "credit"

Tomi Poutanen, NerCenrs Protocof for InexpetsNe Internef Payments

to the customer, and reissue the scrip. The value of the trust placed on the customer can be clearly

determined by the issuing authority. Due to the lack of cost in servicing electronic content, the

selling vendor may want to accommodate untrusted customers. In this case, the vendor collects the

EPO in hope of later collecting the scrip from the holding vendor. Since the issuing authority is

notified with the EPOs of the purchase, a criminal can only double-spend the hinds once. The final

policy is to penalize the holding vendor for its downtime, and make it accountable for any double-

spending resulting from recreating the scrip.

The protocol does leave the system open for vendor fraud. Vendoa need to check against a vendor

revocation list in order to reject scrips from fraudulent vendon. Section 3.5 describes how to lirnit

vendor fraud to an unprofitable level.

3.3.7 Payment Against Multiple Scrip

We've dealt with purchases against and relocation of a single scnp. However, larger sized

transactions may require the debit against more than one scrip to finance a purchase. It is not

sufficient to simpiy repeat the payment (3.3.6) and relocation algorithm (3.3.7) until enough scrip

has k e n transferred to the merchant. This can break the money atomic properties of the protocol,

if some holding vendors are unavailable - a portion of the money has been sent without receipt of

any goods or even a guarantee that the remainder of the funds cm be supplied. The vendor,

acquirer, arbiter and issuing authority d l require that a payment is one unbreakable unit. Thus, the

protocol is altered slightly to fint transfer the required scrips over, and only afierwards send the

signed EPOs in one atomic transaction.

First repeat the relocation procedure for al1 required scnp. Then extend the EPO io include a 128

bit MD5 hash of al1 the ScripID's used to fulfill the transaction. This hash is the same on each

signed EPO in the transaction, and is easily reproducible by the bank. The individual signed EPOs

are only usehl if al1 can be presented to the bank or an arbiter, thus preserving money atomic

properties. This scheme is very similar to SET'S method of using dual signatures to link an order

message with the payment instructions.

-- --

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Puyments

3.3 -8 Policy for Medium and Large Scale Transactions It is important for the protocol to be able to handle payments of a wide range, and not be restricted

to only micro-level payments. In order to make a transaction of high value efficient without

sacrificing security, some minor policies need to be defined. Fint, to demonstrate a possible

drawback of the NetCents protocol, consider the following scenario: Nice buys $50 worth of

NetCents from her issuing authority and in retum receives 50 scrip worth one dollar each. After

visiting 30 separate Intemet vendon, she decides to make a large purchase from Software.com for

the remainder of her balance. If no measures are taken, then Software.com would have to first

fetch ail the scrip from the other vendors (up to 30) and to request the remaining 20 scrip from the

certificate authority. This is a costly transaction to complete requiring significant bandwidth and

processing power and introducing a large transaction latency.

The above problem can be overcome by some logic in the allocation of value and distribution of

scrip. It is advisable to limit the number of floating scrips for micropayments, and maintain a

portion at the issuing authority for larger valued transactions. The funds held at the issuing

authonty need not be distributed in many small valued scrip, but can be stored in one large valued

transaction. This large valued scrip can later be used to purchase srnaller valued scrip for

distribution arnong vendon. To continue the above scenario, the issuing authority, in conjunction

with the customer agent, may decide to onlyfloat 10 scrip worth nvo dollars each, and keep the

remaining fun& at the bank in one scrip worth $30. To Fulfill the payment to Softwase.com, only

1 1 scrips need to be fetched and venfied as the worst case. More likely, by retaining a portion of

the tùnds at the bank the vendor will likely be able to fulfill the payment in one cal1 to the bank.

Exact rules and policies are yet to be defined, and will depend on the observed usage of the system

once in hiIl scale field testing.

3.3 -9 Vendor-Acquirer-Issuing Authority Offline Batch Processing

In order for the vendors to collect the money from the issuing authority. they need to present two

signed EPOs at differing balances, as shown in figure 7. The EPOs are sent to the vendor's

acquirer (M13), which forwards them to the issuing authority (M14). The highest and the lowest

Torni Poutanen, NetCents Protocof for Inexpensive Intemet Payrnents

balance scrips are decrypted and verified. The highest and lowest balance scnps can encompass

many intermediary purchases. The verifkation process is inexpensive at four modular

multiplications. and two simple database operations - one to guard against double spending, the

second to store the new value of the scrip. Once venfied, the difference in balance represents the

amount owing to the vendor, and is returned in the acknowledgement (M15). The intermediary

EPOs can be stored for transaction tracking, if desired. The electronic h d s transfer between the

issuing authority and the acquirer is handled independently from the NetCents protocol over

existing banking networks.

Figure 7: Offline Payment Capture Transactions

3.3.1 0 User to User Fund Transfers Fund transfer between users is not a requirernent for the protocol to function as an internet payment

system, but it does enhance its functionality. Transfer of fun& between users is complicated by the

lack of t m t and the lack of fraud control placed on users. The transfer of scrip must pass through

an issuing authority in order to prevent double spending. The transfer is the same as purchasing

scrip at one issuing authority with someone else's scrip. The issuing authority need not be the same

as that of the original scrip's. The cost of involving a central server does impose a minimum per

transaction cost. On the other hand, transfer costs may be waived by the new issuhg authority in

lieu of the expected fiactionai income fkom customer purchases against the mferred h d s .

3.3.1 1 Online Arbitration In case of disputes, an online arbiter can use the signed EPOs in an audit. The product identifier

within the EPU can be used to insure delivery of a product to the buyer. The NetCents system

requires that the customer cm reload the purchased electronic goods by presenting the vendor with

Torni Poutanen, NetCents Prorocof for Inexpensive Internet Pcryments 42

the EPO. Consider a site selling Java applets. If M3 is lost, and the goods are not delivered

properly, then the custorner can reiniùate the download by presenting the EPO. If the site refuses

to transmit the Java applet, then an odine arbiter is contacted, and the EPO is presented (M17).

The arbiter verifies the EPO, and contacts the vendor with the same EPO (M2-a). If the vendor

supplies the arbiter with the requested item, then the arbiter delivers the goods to the customer

(M3). However, if the arbiter is denied the goods, and the vendor refuses to roll back the

transaction, then the issuing authority is notified (Mt 8), and the customer is notified (M19) that the

transaction will be voided. At the thne of offline batch processing with the vendor, the bank will

request a full EPO history for the scrip. If the vendor attempts to use the discredited receipt, then

the money is credited to the custorner and not the vendor.

MO: Re-te

1 +

Customer Vendor Issuing

A A Authority

A

Ml7 M2-a M3

M3 M 18

M I 9

Figure 8: Online Arbiter Transactions

3.3.12 Anonymous Scrip The above system is not fully anonymous since the issuing authonty can track the purchases

against a scrip bought by a certain client. Here we will present a method of delivering a scnp to the

issuing authority without the revealing the buyer of the scrip. This will provide for a Mly

anonymous payment mechanism. This is an optional component to the protocol, and may or may

not be supported by an issuing authority. It should be noted that some nations, such as the US., do

not allow anonyrnous electronic payments, since all transactions must be tracked and revealed to a

law enforcement agent when required.

Tom i Poutanen, Netcents Protocolfor Inexpensive Interner Payments

The key to the anonymous protocol is to use blind signatures (see Appendix C). The customer

creates the scrip, including the public and private keys and a random ScripID. The user calculates

the message digest, and blinds it with a random blinding factor. The remit is transferred to the

issuirig authority as part of the electronic huids transfer, using SET or a bank account withdrawal

(M20). The issuing authority signs the blinded message digests with private keys of defmed

monetary value to fulfill the value of the b d s txansfer. The signed blinded message digests are

retumed to the customer (M21), who removes the blinding factor, and appends the signature ont0

the scrip. When the customer initiates a purchase nom a vendor, the signed vendor scrip is

transferred (M22) k t ead of fetch relocation codes. The vendor passes the scnp onto the issuing

authority (M23), which verifies the signature. If the signature decrypts correctly, then the issuing

authority mut accept the scrip as legal, and will store the scrip into ifs database of active scrips.

Acknowledgement messages are retumed to the vendor (M24) and customer (MX). Thereafter

transactions can proceed as before with the ciifference that neither the vendor nor the issuing

authority know who the scrip belongs to.

M20 Customer Issuing

+

I - M2 1 - Authority

Figure 9: Purchase of Anonymous Cash

3.3.13 Blinding Sites

The method of moving scrip fiorn one vendor to another presents a privacy problem by potentially

revealing the customer's past shopping behavior. Consider, for example, a user that needs to fetch

scrip fkom a gambling site in order to make a donation at his church, under his name! By revealing

his name, his affiliation to the gambling site is revealed, regardless of whether he is using

anonymous scrip or not.

Tomi Poutanen, NefCents Protocolfor Inexpensive Internet Pqments

The NetCents payment mechanism allows the customers to create user profiles, such as '40e

Gambler" or "Joe Holy" for the given exarnple. When visiting a vendor for the fint time, the

customer can select which user profile to use, or create a new one. If the vendor requires scrip to

be fetched from another vendor, then only vendon are considered that received payment by the

same user typehame. If the only remaining scrip is on vendors of different buyer profile, then the

scrip is passed via a blinding site. The blinding site is a service of the issuing authority that serves

as a transport for the scrip. The customer agent will contact the blinding site, and request the scrip

to be fetched from its current site. Thereafter, the new vendor is contacted and instnicted to fetch

the scnp from the blinding site, without revealing any knowledge of its previous location.

3.3.14 Vendor Policing The concept of vendor trust is paramount in the distributed scrip verification scheme. Without

policing, a malicious vendor and a customer can together double spend the full value of the scnp at

every other vendor. This is accomplished by the custorner and vendor conspiring to dlow a single

scrip to be retrieved by multiple vendors.

One way to guard against this attack is to always pass the scnp through the issuing authority, which

checks for double spending. Unfominately, this will increase the communication costs and will

introduce a single point of failure, a service bottleneck and increased latency. Furthermore, the

issuing authority's costs are determined by the spending behavior of the customers, and the bank

will be tempted to impose minimum transaction amounts.

NetCents relaxes the policing requirements to take into effect the transaction size, and the vendor's

liability. The question to ask in guarding a crime is: "What does the criminal have to gain?' By

building a probability based verification system, a malicious vendor can be detected before they are

able to "profit*' from their crime. Consider charging a new vendor a $200 setup fee. The crime

will only be effective if the criminal is able to gain more than $200 for its crime. By extending the

mode1 to take into effect a vendor's accounts receivable (from the bank) and its expected future

income (as a product of its monthly cash flow and the number of months it has been in service) a

Tomi Poutanen, NetCents Protocol for Inexpensive Inzemer Payments

vendor liability arnount can be determined. It is only necessary to police a vendor to an extent

where a vendor is better off continuing honestly rather than trying to cheat.

However. a scrip cm travel via many vendors without any purchases and no chance of central

notification. before double spending is undertaken. Thus, a scrip is given an associated value,

Liabiliry, L, which signifies the liability of the l e s t trusted vendor that the scnp has passed

through. As the scrip moves from one vendor to another. L is set to the lower of Scnp.Liability and

VCert-Liability. where VCert is the certificate of the source vendor. This effectively sets the

liability of the least trusted vendor that the scrip has passed through. For some multiplier K. if

rund(O..l) < K*pnceRjability or KPL, where rand is a function retuming a random and evenly

distributed value between O and 1, then the issuing authority is notified with copies of the base EPO

and the current EPO. The issuing authority will detect double spending by checking against

overlapping balance ranges for the scnp.

The key is choosing K such that the probability of a vendor benefiting from the crime is less than

0.5. A vendor only benefits when he successfully double spends funds. However, the criminal

vendor is caught when the central server is notified more than once of the double spent funds in the

EPO. Using probability theory as the base the following inequality is created for detemng crime:

Depending on the prke, and the scrip liability, K must be chosen such that the nght-hand side of

the equation is always below 0.5. Unfortunately, to solve for K as an equality with 0.5, we are left

with a multivariate function that requires an iterative search to solve. We have arbitrarily chosen

the value 2 as K. since this yields a fast answer, and the formula equates to below 0.5 for the full

range of O 4 PZ. The risk is the highest at low P L (Le. small valued transactions against trusted

scnp), where the probability of breaking even is 0.461. For larger PL, the function is strictly

decreasing.

For example, consider a vendor that has requested a scrip from a site with a liability of $ 1 0 in

order to satisfy a 5 cent transaction. The certifying bank would be contacted at a probability of

Torni Poutanen, Netcents Protucol for Inexpensive Internet Payments 46

2*0.05 1 1000, or 0.0001. Since the probability of centrai authentication is so low for the scale of

transactions, the aggregate cost is negligible to the banks as well as the vendon. In order for a

criminal vendor to benefit in the crime, it would have to succeed in making ai l e s t 20.000 five cent

purchases without two separate vendon verifying the integrity of the scnp with the centrai

authority. Using basic probability theory, a malicious vendor, in this scenario, would have a less

than 40% chance of profiting from the crime (Le. the crime does not pay).

If an issuing authority notices vendor double spending, then the NetCents root server is presented

with the evidence. The root server verifies the evidence and possibly contacts the vendor or the

vendor's acquirer. If the evidence is found to be conclusive, then a full broadcast is made to al1

acquiren. The acquirea, in tum, inform al1 of their merchants of the malicious vendor. The

vendon will rehise scrip from the malicious vendor, unless it is passed via the scrip's issuing

authority. Any scnp already received from the vendor during the day is sent to the issuing

authority for venfication.

3.3.15 Vendor Tarnperproof Hardware The safest implementation would require tarnperproof hardware at the vendor sites. A vendor can

only double spend if he can circumvent the protective coating of a tamperproof hardware device.

The effort required to break into the device would make the crime not worth while, and definitely

not abundant. Furthermore. the crimind vendor would be caught by the end-of-day clearing

process at the latest.

Likely, the most favorable aspect of using hardware devices is that, if implemented properly, it

makes intrusion by a foreign hacker impossible. This is because the hardware device limits the

number of accepted calls to the bare minimum required to support the vendor. Thus there is

minimal risk for the vendor of a security breach by an Intemet intmder. In fact, hardware devices

need not be tamperproof - a cheaper device rnay only provide a hardware layer between the

Intemet server and the vendor protocol functionality, in order to protect against foreign intrusion.

Torni Poutanen, NetCents Protocol for Inexpensive intemet Pqments

The hardware device, however, must be powerful enough to be able to sign scnps rapidly, and it

must have suficient storage to guard against attempted double spending. A minimum

configuration would simply hold the vendor pnvate key, and a list of ScripIDs that has been signed

and sent in the course of the day (since the last communication with the bank), dong with a

timestarnp. The hardware device will refuse to resign the scrip unless the vendor can prove that the

scrip was retumed to the vendor as part of a pending transaction.

3.3.16 Currency Conversion NetCents, from its onset, was designed to support multiple currencies. A scnp has a specific

currency attached to it, and an online currency exchange mechanism is defined to handle cross-

currency transactions. Since a currency conversion will typicaily not translate to an even number,

it is important to be able to support fractions of cents. For example, an item listed at two U.S. cents

would translate to 3.52 German pfennings (@ 1.7664 markddollar). In order for a vendor to

convert between currencies, the acquirer provides a daily signed currency conversion table. The

desired currency is included in the MO quote request message, the vendor performs the conversion

on the fly and retums the quote in the customer's native currency. For the above example with

German marks, the customer will be asked to accept a payment of 3.52 pfennings (U.S. 2 cents).

1s there a danger for the acquirer to define an exchange rate when the actual payment clearing

process may not occur for several days later at possibly different real exchange rates? We argue

that the ability to perform currency conversion at the micro-level is in fact a positive financial

windfall for the financial institutions. Society is already used to suffering a sizable negative spread

in currency conversion, especially for smail arnounts. Thus, the acquirer can reap higher margins

by lowenng the foreign currency buy rate for its vendors. To offset the risk of currency

fluctuations, the bank cm buy currency futures in accordance to its vendors' daily foreign sales.

Tomi Poutanen, NetCents Protocol for Inexpensive Intemet Payments

4 Properties

4.1 Atomic Properties of Transactions The NetCents protocol c m be analyzed along the following transaction processing atomicity

requirements:

Money Atomic

By practicing careful design and transaction processing methods, a transaction can be

shown to be completely atomic. Money atornic properties are enforced by the vendor and

the customer agent. The vendor will ensure that no money is created, and the customer

agent will ensure that no money is Iost during a transaction. See section 4.3 on discussion

of lost messages for a further detail.

Goods Atomic

Goods atomic transfer of purchased items is guaranteed by available online arbiters. Online

vendors must be prepared to accept repeat download requests for the sarne electronic good

when presented with the sarne signed request by the arbiter. If the arbiter is declined the

goods, then the bank is told to invalidate the particular signed request.

Certified Delivery

The protocol cunently does not support Tygar's notion of certified delivery: that is, a goods

atornic transaction where al1 parties in a transaction cm prove exactly what was delivered.

This proof cm be used in a court of law, and is supported by the cryptographie strengths of

the protocol. This is due to NetCents' clear-text transfer of the item description, identifier,

and price to the buyer. However, the protocol specification can be extended to support

certified delivery. if desired. In order to facilitate certified delivery requirements, every

item on sale needs to be signed and have a message digest. This message digest will be

delivered to the customer, along with the item identifier, price, date, and a brief nahiral

language description, al1 signed by the vendor. The buyer includes this message digest in

the r e m signed receipt. Now, the buyer can prove the intended item of purchase and agree

to price, and the seller can prove the buyer's willingness to buy that item.

Tomi Poutanen, Netcents Protocoi for Inexpensive Intemet Poymenrs 49

Unfortunately, the process of creating a signature is computationally very expensive, and is

not suitable for a Iow-cost payment scheme. AIso, the likelihood of a criminal trial into

micropayment fraud is questionable.

4.2 Security Netcents is secure against an adveaary who can intercept, destroy, modify and replay messages.

The following outlines possible attacks by an adversary and how the system counters them.

Replay and DoubleSpending

Reusing an old EPO for a new purchase is ineffective since the signature includes the

balance within the scrip. The vendor will only accept an EPO that contains the proper new

balance. The EPO also has the vendor identifier coded in it, and thus, it is of no use for any

other vendors.

Double-Charging

Vendon cannot double charge customers since the EPO contains a scrip balance, not

payment amounts. The bank will catch al1 other attempts of over-charging.

Alterations

Vendors cannot alter the amount charged for the goods, since only the customer has the

private key to sign the EPO. which contains the scrip balance.

.-

Terni Poutanen, NetCents Protocol for Inexpensive h e m e t Payments

Man-in-theMiddle

A man-in-the-middle can efiectively raise the quote given by the vendor. If the customer

agrees to pay this amount, the signed receipt will be made out to the vendor, and is of no

use to the criminal. What makes this attack unlikely is the notification dialog sent to the

customer, requesting a buyer to manually accept the payment.

Denial of Service

Vendors and banks are pmtected from 'clogging' - bogus messages designed to cause them

excessive computations or other overhead, such as attempts to try to relocate scrip. In ail

but one case the maximum cost of a bogus message is the simply a signature verification.

The only vulnerability is a user's registration process with the issuing authority. The

registration process contains sensitive information, and must therefore p a s through a secure

SSL protected channel. After regisuation, a certificate is also created, signed and

transported to the user via the same secure channel. Initiating SSL encryption requires an

encryption step by the issuing authority. Thus, it is recommended that the registration

procedure is hosted on a separate server from the operational services of the issuing

authority. IP addresses should aiso be monitored to track repeat attacks. With carefixl

design, this weakness can be taken under control.

Scrip cm only be moved by legitimate ownen of the scrip, since the relocation process

requires a signed EPO encoding the balance and the destination vendor. Thus, malicious

users can be prevented from bbconfusing" the system by deliberately moving scrips around.

However. steps should be taken to prevent a legitimate owner of scrip from simply

relocating the scnp indefinitely without making any purchases. One possible measure

would be to pass the scrip through the issuing authority if there was no purchase against the

scrip. The issuing authority can keep track of the number of pointless scrip relocations, and

detain the scrip after a daily limit has k e n reached.

4.3 Lmt Messages The ability to gracefully recover from lost messages is especially important in the Intemet d m .

due to its low reliability. Here we outline al1 the points vulnerable to lost messages.

Tomi Poutanen, Netcents Protocol for Inexpensive Inremet Payments

Consumer-Vendor

As we have already discussed, the main danger of an online purchase is the possibility of

losing the purchased goods in transmission. We've dealt with the issue through an online

arbiter (section 3.3.1 1). During scrip relocation. the consumer may never receive the

transfer acknowledgement. and she may not know for certain if the scrip was transferred to

its destination. However, scrips are easy to locate since the customer can simply query and

follow the scrip migration path.

Consumer-Issuing Authority

There is a significant amount of tmst between the consumer and her issuing authority, as

people tmst the integrity of their bank. The customer buys scrip from the bank and trusts

the bank to deliver the customer scnp in private. if the message is lost then the customer

can request the issuing authority to resend the scrip once she has proven her identity with

her certificate. There's nothing to gain for the customer in receiving the sarne customer

scrip many times.

Consurner-Arbiter

The arbiter is contacted when the vendor fails in delivering the goods. But what happens if

the arbiter too fails to deliver the purchased items? The goods couid be one large archive,

and the consumer could be experiencing reliability problems with her ISP, causing the

transfer to fail repeatedly. The arbiter and the issuing authority must decide on a policy to

handle repeated failures. After a certain number of download attempts, it may be

worthwhile to forfeit the transfer and redeem the money. Of course, the user needs to be

flagged in order for them not to exploit this process repeatedly.

Vendor-Vendor

If a scrip is lost dunng relocation, then special steps must be taken to recover it. The

previous vendor will daim that it is no longer active, and thus will refuse to sign the scrip to

another vendor. Thus, the consumer agent recovers the scrip by requesting the same

transfer over again. The old vendor will reissue the exact sarne scrip to the new vendor,

which in turn will make it active.

Torni Poutanen, NetCents Protocol for Inexpensive Intemet Paymenrs

5 Imnlementation and Test Environment

A prototype implementation based on the NetCents protocol was built in order to test the system

secunty and performance. The prototype is built on Microsoft software technology designed to run

on Intel based computers. Off-the-shelf products were favored in order to ease development time,

and aiso, to make the system less proprietary.

5.1 Client Agent A client agent was written as a command line utility with timers and scripting support. The client

was designed for a Win32 platform (Windows 95 or NT) with Microsoft9s WinI.net Internet

extension. The WinInet extension is part of Microsoft's Intemet Explorer Web browser and is

included in the current distribution of the OS. The Winhet dynarnic linked libraries (DLLs) enable

Win32 applications to make Intemet calls, in the form of either synchronous or asynchronous

HïTP, FîP or Gopher requests and file transfen.

The Client Agent evolved from a simple iterative ping, to test round trip latency and server

throughput, to a scripted sequence of calls, and finally to a script based analysis tool chat gathered

detailed statistics at specified usage loads. The scripting capability allowed the development of a

set of predetermined calls to NetCents vendos, issuing authorities and acquirers, and facilitated the

modeling of a functioning NetCents payment environment. The need to precalculate the HlTP and

NetCents requests arises from the large computational cost of signing scrips - a client can only test

the server's performance if the client cm produce requests faster than the server can handle them.

Transaction systern practice has taught us that maximum server throughput alone is insufficient to

determine acceptable loads in lieu of latency [LZGS84]. Requests are unlikely to fail at a constant

frequency, and the system must be able to gracefully handle bunts of calls. The roundtrip latency

is thus caiculated as the average latency over a period of time, on requests that arrive at a specific

aggregate frequency. The arriva1 time itself is random but must average to the specified frequency

over the interval. As the worst case, ail requests arrive at the sarne time. The client agent

accomplishes this by randomly choosingpt points within a time interval. r, for a frequencyf. The

-- - -- - - - - - - -

Torni Poutanen, NerCenrs Prorocol for Inexpensive Internet Pqments 53

script commands are issued at the ordered distribution of times within the interval. For each cal1

within the script, a thread is spawned with the request and a wakeup time specified by the random

distribution of request times.

5.2 IssuingAuthority Server The NetCents issuing authority server is built on Windows NT technology, and depends heavily on

Microsoft server technology, including Windows NT Server 4.0, Intemet Information Server 2.0

(IIS), and Microsoft SQL Server 6.5. The issuing authority itself is designed as an ISAPI

extension. This is specific to IIS and diffea from a CG1 cd1 by the fact that an ISAPI extension is

loaded into the same address space as the server as a D U , whereas a CG1 program is a fully

separate process. Not only does this elirninate the overhead of spawning another pmcess, but even

load time is reduced by keeping the ISAPI DLL resident after its first use.

The issuing authority server handles requests for initializing a customer, issuing and signing scrip.

and transmitting scrip to vendors when requested. For the purposes of this prototype, ail NetCents

requests are conducted as extended URL calls, and replies are read as files. In the IIS environment

a URL cm be up to 4 KB, and easily accommodates the transmission of a request or a signed EPO.

Al1 binary data is converted to four-bit hexadecimal ASCII designation for transfer, and is

appended to the URL. Though not optimal, it was the easiest implementation, and sufficient for

Our experiments.

5.3 Vendor Server The vendor server was built on the sarne technology as the issuing authority. For the purposes of

Our performance and integrity tests. the vendor was given the functionality to respond to the

following requests: initialkation; scrip fetch process frorn another vendor or a bank; scrip release to

another vendor, and the payment request. Again, al1 requests are transmitted as extended H ï T P

ü F U requests.

Tomi Poutanen, NetCents Protocol for inexpensive Internet Payments

In a real implementation. the MS SQL relational database is overkill and presents a performance

bottleneck in the system. and increases the base system cost for the vendor. A much more efficient,

custom database design should be implemented for the final vendor configuration.

Torni Poutanen, NetCents Protocolfor Inexpensive Interner Paymenrs

6 Performance In this section, we pnsent experiments designed to evaluate the effectiveness and reliability of the

NetCents payment system. We employ the prototype system described in section 5, describe the

experimental setup, and proceed to present the results of various experiments.

6.1 ExperUnental Setup The prototype NetCents system was set up on a 10 Mbitsls Ethemet network mnning Windows NT

networking. One bank and two vendors were set up on three Intel Pentium Prol180 serves on

Windows NT 4.0 and servicing HTTP calls by Microsoft's Intemet Information Server. The

prototype system was controlled by requests from one client on a Pentium 166 also mnning NT 4.0.

Al1 computen were equipped with 3Com Fast EtherLink XL PCI 10/100Mb Adapter (3C905)

Ethemet cards.

Unfortunately, the 10 Mbius network was not quite fast enough to test high load server throughput.

The experiments, however, could not be initiated svaight from the vendor, without networking

overhead, since the client application was quite resource intensive and would have interfered with

the server performance.

6.2 Experimentar Results The first expriment is a simple test to measure round-trip latencies for various NetCents system

calls. Its purpose is to demonstrate the performance of the test environment. and to show the

effectiveness of Microsoft's ISAPI technology against CGI. Then, the individual NetCents services

are called to test the cost of various functions.

Fint, iterative HTTP requests were sent from the client to the vendor for a 256 byte HTML file.

We chose data block sizes of 256 bytes because that is close to the size of a scrip that is passed

from one vendor to another. The observed performance result cm be seen in Table 2.

Tomi Poutanen, NetCents Protocol for Inexpensive Interner Payments

The NetCents client makes calls to a vendor service, or a program. In order to enhance

performance, the NetCents vendors and banks were irnplemented as Microsoft ISAPI extensions.

ISAPI extensions are Windows dynarnically linked libraries that interface with Microsoft's Intemet

server. ISAPI extensions are faster than CG1 applications since ISAPI extensions are loaded once

into the same address space as the server. and kept resident for the lifetime of the server. CG1

applications, on the other hand, need to be spawned off into separate threads with their own

memory spaces, each time they are called. CG1 applications are hindered by the high initialization

time and high cost of the cross-address space communication with the Intemet server. To test

Microsoft's claims, calls were made to both a CG1 application and an ISAPI extension, both

designed to simply return 256 bytes of data As shown in Table 2, the ISAPI extensions were

significantly faster while requiring less processing power.

What would further make a CG1 application unusable, is the time required to establish an MS SQL

database connection (about 80 ms). The ISAPI extension is able to reuse the same database

connect-object for each request, thus significantly reducing query time.

H ï T P request of 256 byte file

CG1 request with 256 byte reply

Payment with scrip fetch 1 63.9 1 15.6 1 31%

ISAPI DLL cal1 with 256 byte reply

Payment against existing scrip

Scrip fetch from a bank/merchant

Table 2: NerCents vendor semer performance

Round-trip latency

(ms)

9.9

44.6

Raw EPO signing and verification costs were measured to be very efficient when running on a

stand-alone system. The RSA based signature scheme, with a 5 12 bit modulus and a public key of

3, yields a signature verification rate of 2930 per second on a Pentium Pro/l8O server. The most

expensive component of vendor operation is the task of signing outgoing scrips, which was

17.3

18.2

31.3

Tomi Poutanen, NerCenrs Protocol for Inexpensive Internet Payments 57

Throughput

requests/s

61.7

22.4

Server load

30%

84%

57.7

55.0

40.0

38%

34%

55%

measured at 34 rns on the same server. Assurning a 90% hit rate (percentage of payments that do

not require scnp transfer), a vendor, d g on the same system, can accommodate 270 payments

per second (not counting communication and database overhead). Customer performed receipt

signing is sufficiently fan at 0.18 s on a Pentium/75.

However, when put into practice in an ISAeI extension the overhead of the slow network, TCPllP

packet handling, the Intemet server, and SQL database calls greatly effect the round-trip latency.

Table 2 shows the observed latencies for a payment against an existing scrip (18.2 ms), a scrip

fetch fiom an issuing authority or another vendor (3 1.3 ms), and a payment which requires a scrip

to be fetched (63.9 ms). It should be noted that for a.ü operations, the server load is f a fiorn its

peak, and thus the maximum throughput is higher than shown in the second column.

Figure 10 depicts the observed average round-trip latency for purchases at vuying server Ioads, and

for difTerent hit rates. The hit rate was found to have a grave impact on the server throughput, since

a miss would result in a scnp fetch procedure involving three message exchanges: the k t to

inform the vendor fiom where to fetch the scrip; the second to actuaIly fetch the scrip; and the last

to pay against the traosferred scrip. Furthemore, a fourth message is sent at a random time to fetch

another scrip fiom the vendor, in order to keep the nurnber of scrips in equilibriurn, for the sake of

our analysis.

-- - - - - - -- -- -

Tomi Poutanen, Netcents P rotocolfor Inexpensive Internet Payments

10 20 30 40 50 60 70 Requests per second

Figure 10: Average payment Iatency cornpared to the frequency of requests for various hit rates.

The graph shows the importance of modeling expected purchasing behavior in scrip relocation

policies. When al1 payments are against scrip that reside on the vendor, then the vendor can

support up to 120 payments per second (with an average latency of 371 ms). For hit rates at 90%

the system can comfortably handle 65 requests per second (at 200 ms). The system handles 45 and

30 payments per second for hit rates of 75% and 50% respectively. If shoppers never shop at a

vendor more than once, then the vendor could only support 18 purchases per second.

Comparably, Millicent vendors can validate 1000 payments per second on existing scnp on a much

more powerful Alphastation 400 41233, and on an ATM network Wan951. 1s this type of

performance required? Hardy, considering that the above payment server would be able to single-

handedly support the daily load of netscape.com. Canada's most high-volume Intemet sites,

sympaticaca and canoe.ca typically do not exceed 10 hits per second (according to Sympatico,

1997), a rate easily handled by a single NetCent vendor server even at OYO hit rate. Considering

that Netcents is built on secure public key operaiions that provide non-repudiation and odine

arbitration, then the system performance is sufficient for typicd applications. If performance is

i n ~ ~ c i e n t , then the load cm be shared among mirrored Intemet servers.

Tomi Poutanen, Netcents Protocol for Inapensive Internet Payments

7 Scalability We expect the system to be truly scaiable to a global reach given its distributed nature, the low

vendor verification costs, and even Iower bank involvement in transactions- From the onset, the

system was designed with scaiability in mind The SET protocol was followed in creating a

trusted, interoperable network of issuing authorities and acquiren.

The only centrai server is the NetCents certificate server, which signs certificates for issuing

authorities and acquiren. This is not a time-sensitive task and short down time and high latency is

tolerable. If required, the root server with proper mirroring cm be duplicated to different

geographic locations, or Internet service providers. AI1 other members, including issuing

authorities, acquirers, arbiten and blinding sites, c m be arbitrarily added in response to market

forces.

In a payment transaction, the only possible single point of Mure cornes from issuing authority

downtime. Only the funds aiready distributed to vendors are accessible when the issuing authority

is down. Unlike Millicent, however, fun& can be moved between vendors to facilitate payments

even when the issuing authority is inaccessible. If issuing authority downtime persists and

customers are repeatedly denied access to their NetCents funds, then the issuing authority is likely

to lose customers to cornpetitors.

Online arbiters cm be added to the system as needed, and the system can continue to function even

with complete arbiter downtime, since a cornplaint is not time sensitive. Similarly blinding sites

can be added as needed. If al1 blinding sites are unavailable, then the scnp should be passed via the

bank in order to ensure customer privacy.

The NetCents parties are location independent. Thus, a purchase by a Gerrnan from a German

vendor will be validated entirely by online and offline communication messages within the country,

between German acquirers and issuing authonties, without slow and unreliable messages across

continents.

Tomi Poutanen. NetCenrs Prorocol for Inexpensive Interner Payments

Discussion

8.1 The Netcents Protocol As a Universal Intemet Payment Scheme NetCents payment protocol introduces a number of new concepts to Intemet payment systems. It

also borrows many strong qualities from existing protocols and integrates them into one flexible

and efficient system. NetCents meets al1 of the required properties defined in section 2.6, and with

its distributed and low cost nature and the built in support for multiple currencies, it is scalable to a

world-wide reach.

We have intrduced the notion of floating fun& that are passed from one vendor to another afier

the customer's shopping tendencies. This distributed movement of fun& removes the reliance of

central servers in the course of a payment, thus making the protocol both fast and cheap. We have

incorporated cryptographie functionality that makes the system secure against customer fraud, and

we include information in a transaction that conclusively shows proof of payment. This proof cm

be used by an online arbiter for minor dispute resolution and for ensuring proper delivery of

purchased goods. Lastly, we have included options for anonymous funds using blind signatures.

Since the protocol treats money in bulk, NetCents offers the fastest anonymous payment

mechanism, compared to individual signed coin based schemes.

NetCents is the only protocol that supports anonymous payments while guaranteeing goods

delivery. It is the only protocol that enables purchases at new vendon even when the bank is not

available, and ail while guarding against double spending. Lastly, it is the only protocol that can

handle the full range of payments, from fractions of a penny to hundreds of dollars.

8.2 Vendor Policing The Netcents protocol has been shown to be secure against customer fraud. However, trust is

placed on vendors, which can circumvent the system to enable double spending of hinds. To guard

against vendor fraud, two different policing schemes have been recommended. The first is a

probabilistic notification scheme that informs the scrip's issuing authority of the payment, in order

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Payments 61

to detect double spent funds before the criminal vendor profits more than the cost of his deposit.

The more trusted but costly mechanism is to enforce tamperproof hardware at vendos.

However, given the nature of micro-level purchases of electronic content, is the above level of

security really required? The cost of the crime to the seller is negligent - not much more than a

little bandwidth. As long as fraudulent use is not widespread, then the loss in sales resulting from

criminal behavior is negligent: the cnminal would probably not have paid for the good in the first

place. The fraudulent vendor will be detected at the end-of-day clearing. For the sake of electronic

content and goods, why would a vendor forfeit a $200 deposit, lose credibility with banks and face

a possible criminal suite?

The markets for lowcost Intemet content have yet to materialize, and thus, the criminal

oppominities are dificult to identify. Two dangers are present on the Internet: wide scale

collusion; and hacking of a vendor. If a probability based policing scheme is not implemented,

then a criminal vendor could sel1 44day-passes" for unlimited double-spending of anonymous scrip

for a day! The hacker community presents a more cumbenome problem. To crack a server is a

formidable task, and would require that the NetCents software modules be replaced. The intruder

would aiso have to retrieve the vendor private key off the system, and thus, we recommend that the

vendor server password encrypt the keys. It would be foolish, however, to assume that vendon are

not wlnerable to outside intmders. If targeted, a vendor could be liable for up to the value of fraud

until double spending is detected, and the vendor is eliminated. If the possibility of losing their

deposit is too risky to a vendor, then they should consider tamperproof hardware with a clearly

defined interface, which is not vulnerable to an outside hack.

8.3 Currency Conversion The ability of the system to handle fractions of pennies is of paramount importance in handling

multiple currencies. Smail payments with bank signed coin systems, such as DigiCash, do not lend

well to a multiturrency marketplace. The least valued signed coin must be significantly smaller

than the intended lowest valued transactions. Consider, for exarnple, the fine-grained currency

requirements when converting two U.S. cents to German Pfennings. Using proper currency

Tomi Poutanen, NetCents Protocolfor Inexpensive Internet Payments

conversion. this would translate into 3.53 pfennings (at Sept 18, 1997 conversion rate of 1.7664

markddollar). If the lowest German denomination is a coin worth one pfenning, then the German

mark account holder is charged either 3 or 4 pfennings - a pnce that differs by about 14% from the

price paid by U.S. dollar account holder. This discrepancy in purchase price is significant enough

to warrant concern: it is easily exploited and it is unfair. Consider the disadvantage of playing

poker with someone who's minimum bet is consistently 10% Iower than yous in real terms!

In a signed coin environment, the solution would be to either enforce one common currency. or to

lower the value of the smallest denomination. A common currency system will meet fierce

political and societal resistance. The latter solution will further increase the cost of electronic coin

based systems since more coins need to be stored, transmitted and verified. On the other hand, a

debit based system, such as NetCents, enables the vendor to charge the custorner to the fraction of a

penny, thus facilitaring currency conversions to the micropayment level.

8.4 Micropayrnents versus SET A more interesting discussion is on the viability of a micropayrnent protocol in light of the SET

credit card based payment system. This is a philosophical argument, not technical, and it questions

whether the concept of micro-level payments makes sense from a marketing point of view. The

argument against micropayments says that online content has a flat production cost, and to

maximize profit, the vendor should attempt to rnaximize downloads [Myh97]. Revenue is made

from advertisements and subscriptions to the site. An online journal thai decides to charge a few

cents per article would likely loose a significant portion of their readership. The Iost advertisement

revenue (typically 3 cents per page or less) would offset the increase in revenue per article read.

Also, if the online journal charged per article, then they would hurt their best customers - the

readen that want to read every article in the journal - who would most likely prefer a flat pncing

model.

The argument for SET, thus, says that most Internet content can be sold in a subscription or account

based model where the value of many micro-valued transactions is aggregated into one substantial

transaction, and where the cost of the more expensive SET transaction is shared.

Tomi Poutanen, NetCents Prorocol for Inexpensive Internet Payments

However, we argue that account based models do not drive business to the journal - the cost of a

full subscription will often be too expensive for a customer seeking only one article. On the other

hand charging a few pennies for an article will introduce the customer to the journal at a very Iow

cost in a piecemeal fashion. By tracking customer purchases via cwkies or a login process, the

journal c m introduce a monthly limit on billing, if they choose to.

Account based systems favor large content producers that cm afford to produce a full range of

attractive content. However, smdl producers will face difficulty in requesting accounts with al1 of

their customen. Using SET as an aggregated payment vehicle shares al1 of the problems discussed

in sections 2.4.1 - lack of arbitration, policing and anonyrnity, and it is unfriendly to spur-of-the-

moment purchases across the Intemet. Using a micropayment systern like Netcents addresses al1

of these concems.

Tomi Poutanen, NerCents Protocol for Inexpensive Interner Payments

9 Conclusion and Future Work

9.1 Conclusions

The NetCents micropayrnent protocol fulfills the three goals set upon reviewing pnor work done in

the field: it is Iow-cost, scalable and secure. It meets al1 the desired properties of payment schemes

as outlined in section 2.6, a feat that is not achieved by any other payment scheme. Traditiondly,

payment protocols have traded secunty for efficiency, introducing vulnerabilities such as the ability

to double spend, lack of non-repudiation, and lack of anonymity. The per transaction cost, high

latency, and single point of Mure in payrnent mechanisms are due to the need to contact a central

server in order to verify the validity and availability of funds for each payment.

NetCents' unique treatment of funds, in the form of floating scrips, enables distributed operation

and payments without the involvement of a third party. The use of floating scrips has many

benefits. Fint, the cost of handling a payment is limited to the computational load on part by the

vendor. Since the bank is not required in the course of a transaction, then it need not impose a

minimum per transaction cost to pay for the verificaiion service. This enables vendors to sel1 wares

at arbitrarily low costs ranging down to fractions of pennies. Second, by eliminating the bank from

the transaction, the payment round-trip latency is reduced, and a centrai bottleneck is removed.

Third. unlike offline payment protocols, NetCents is secure against customer fraud, and in

particular, prevents double spending of funds. A floating scrip is active at only one vendor at a

time, and the vendor handles the withdrawals from the scrip.

The NetCents payrnent mechanism is built on public key cryptography. In order to make a

purchase against a scnp, the buyer needs to present a signed electronic payrnent order to the vendor

and only the owner of the scrip private key can generate this signature. The system is

cryptographically safe against tampering and misuse. The use of cryptography also enables proof

of payment and non-repudiation. An online arbiter cm use this proof to police customer-vendor

disputes, and to certify elecîronic goocis delivery of purchased items. Cryptography also allows the

system to function in a fully anonyrnous format using blind scnp purchases.

Tomi Poutanen, NetCenrs Protocolfor Inexpensive Interner Payments

Even more important than the lowcost of a transaction is the scalability of the protocol. If a

protocol cannot scale to a woddwide reach, then its long-terrn survivability is dire. As such,

NetCents was designed with scalability in rnind, and is distributed in nature. The only single point

of failure for the entire system collapsing is the root NetCents certificate server. Fominately, these

certificates are only used to vaiidate new payment institutions, and thus. around-thetlock

availability is not required.

The NetCents protocol supports multiple issuing authorities, currencies, arbiters and blinding sites,

and al1 cm be arbitrarily added as needed. The NetCents parties are location independent. Thus, a

purchase by a Geman from a Geman vendor will be validated entirely by online and offline

communication messages within the country, between German acquirers and issuing authorities.

without slow and unreliable messages across continents.

The NetCents protocol is based on arbitranly sized debit payments against scrip. This provides for

a divisible paymtnt system that scaies well to the sub-penny range. This is especially important in

a cross-currency micropayment system, where a currency conversion in the scale of a few pennies

will result in a significant proporiion of the value of the transaction k ing determined in fractions of

a penny.

Tomi Poutanen, NetCents Protocol for Inexpensive Intemet Payments

9.2 Comparative Evaluation

Large-pay ments J

Small-payrnents J

Micro-payments

Fast vendor vdid'n. J

No customer HW J

Money atomic 1 -4

protection

Scdable

Distnbuted

Divisible J

Transferable

Interoperable

Table 3: Comparative analysis of payment protocol properties

- - - -

Tomi Poutanen. NetCents Protocol for Inexpensive Interner Payments

9.3 Futtire Work

The NetCents protocol definition is only at its infancy and there is roorn for substantial refinement,

analysis and testing of the protocol.

9.3.1 Online Shopping Behavior In designing the protocol, it was assumed that Intemet buyen tend to frequent the same sites or

vendors for online purchases, much like is observed in the real world by customer loyalty. brand

preference, and location convenience. Much of the efficiency in NetCents depends on this repeat-

shopping tendency. However, the intemet presents a new mode1 for the marketplace. and it is not

yet clear whether customers will shop at the sarne sites repeatedly, or if they will browse the

vastness of the Intemet for bargains. A better understanding of online shopping behavior is

required to better undentand how NetCents will perform in practice. Unfortunately, the Intemet as

a marketplace is at its infancy. there is only limited content for sale, and customers are scarce.

9.3.2 Wide scale tests In order to gain more confidence in the protocol, wide scale field-testing needs to be undertaken,

similar to DigiCash's six month mock marketplace. Coins were given away for free. and were used

to pay for sarnple electronic content and games. Digital Equipment is perforrning similar field tests

on their Millicent technology. The open field test will serve to iron out the last problems without

the risk of financial loss. Of particular interest is the movement of scrip between vendon. The

system must ensure that scrips are not permanently lost, or altered to circumvent the system, even

when operating in a highly hostile and unstable environment.

9.3 .3 Distribution Policies Currently, the only scnp relocation policy is LRU - the scrip that was least recently used to fulfill a

payment, is relocated to the new vendor. However, the consumer agent can gather extensive

statistics on shopping behavior, which can be used to make more educated guesses on future scnp

use. Fewer scrip relocations lead to lower vendor communication and computation overhead and

Tomi Poutanen, Netcents P rotocol for Inexpensive Internet Payntents 68

lower payment latency. The analysis of online shopping behavior and the field tests will provide

valuable feedback on which relocation policies can be designed.

9.3.4 Scrip fund allotment NetCents floating scrip functions much like a cornputer system memory cache. A cache makes a

careful tradeoff in detennining the number of cache lines versus cache line size. Similarly,

NetCents rnust balance the ailotment of fun& into either numerous scrips of small value. or few

scrips of more substantial value. The optimum mix will invariably depend on the customer,

depending on how many different vendon she tends to visit, and the value of her purchases.

Methods for accommodating a variety of user types need to be defined further, and the policies cm

be based on the consumers' past shopping tendencies.

There is also a balance between the cost of the cache and the cache size, and hit rate. Similarly. the

more money in a custorner's NetCents account, then the more scrip of higher value c m be

generated and distributed to vendon, thus reducing inter-vendor transfers. With this in mind, the

bank should enforce bulk purchases of scrip (say a minimum transfer of $10). The desired balance

of money in the account is to be determined in usage analysis.

9.3.5 Explore Other Signature Schemes The RSA public key signature algorithm was chosen as the basis for the NetCents protocol since it

is well known, source code is readily available, and the key pairs can be defined in such a way that

signature verification is extremely fast. However, there are a nurnber of other signature schemes

that yield better performance and may be better suited for the application. Signature schemes that

should be studied include Rabin signatures [Rab79], Shamir signatures [Sha95] and Elliptic Curve

Cryptosystem [S hi961 signatures.

A recent proposal by Shamir [Sha95] permits signatures to be validated extremely rapidly, although

at the cost of introducing a small risk that an invalid signature is accepted. Shamir describes a

variation of the Rabin [Rab791 signature scheme which permits signatures to be "screened" using a

test which will detect a fraudulent signature half the time and never reject a valid one. The çcheme

Torni Poutanen, Netcents Protocol for Inexpensive Interner Payments

rnay be applied repeatedly to provide the desired degree of assurance as to the authenticity of the

result.

The signature screening approach has a number of charactenstics that are particularly suitable for

micropayment schemes. The degree of assurance may be adjusted to refiect the level of risk.

Small payrnents might be accepted with only minimal checking and additional checks performed as

the risk increases. Another useful property is that the level of protection rnay be adjusted to reflect

the server load. This is especially important since it substantialiy reduces the excess server

capacity required to cope with peaks in demand and ailows unexpected increases in demand to be

dealt with in an orderly rnanner.

9.3.6 Further support for arbitration, certïfied delivery The protocol specification can be extended to support Tygar's notion of certified delivery; that is, a

goods atomic transaction where al1 parties in a transaction cm prove exactly what was delivered

[Ty96]. This proof can be used in a court of law. and supported by the cryptographie strengths of

the protocol. In order to facilitate certified delivery requirements, every item on sale needs to be

signed and have a message digest. This message digest will be delivered to the customer, dong

with the item identifier, price, date and a brief natural Ianguage description, al1 signed by the

vendor. The buyer includes this message digest in the return signed receipt. Now, the buyer c m

prove the intended item of purchase and agree to price, and the seller can prove the buyer's

willingness to buy that item.

Unfominately, the process of creating a signature is computationally very expensive, and is not

suitable for a low-cost payment scheme. Also, the likelihood of a criminal trial into rnicropayment

fraud is questionable.

9 -3.7 Analysis of Tamperproof Hardware A study into the minimum requirements for a tamperproof device to guard against vendor fraud

should be contacted. If the device c m be produced cheaply while at the same tirne providing

speedup in scrip signing, then there could be a real advantage of enforcing tamperproof hardware.

Tomi Poutanen, Netcents Protocol for Inexpensive Internet Payments 70

9.3.8 Integration with SET In designing NetCents, the SET secunty and banking hierarchy was followed in order to allow for

possible future SET interoperability. SET is an open protocol. and it can be built on top of the

NetCents protocol. SET suppom multiple brands, such as a VISA or Mastercard brands. NetCents

can be built as another brand extension. with differences in the underlying payment mechanism-

The two protocols could exist in unison, with NetCents handling al1 transaction of small monetary

value, and the credit car& covenng the higher end of the spectrum. The same public keys can be

shared and the account services can be combined into one-

Tomi Poutanen, NetCents Protocof for Inexpensive Infemet Puyments

Glossary

Acquirer

Anonymity

Bünd Signature

EDI

EPO

EC

Goods- Atomic

Hash

Issuing

authority

Micropayments

Money- Atomic

Non-

repudiation

Online

protocois

Online

A vendor submits the collected electronic moneys to his acquirer, which in mm

will return it as r d cash.

The inability of other parties to identify a member in a transaction.

The rnethod of requesting a signature by a third party without revealing the

contents of the message to be signed.

Electronic Data Interchange - method for large companies to handle electronic

commerce and electronic fund transfers via propriatery and secure pnvate

networks.

Electronic Payment Order - a term used by NetCents and NetBill to designate a

signed receipt by a buyer confirming purchase of the goods.

Electronic Commerce - designates al1 foms of purchases. money transfen.

bids, and barter conducted over an electronic medium such as email or the

Intemet,

A purchase of goods, where the customer is charged if and only if he actually

receives the purchased goods.

An arbitrarily long bit stream can be represented as one fixed length hash value

by iteratively running the stream through the hash hnctions (such as MDS).

A customer buys electronic currency from an issuing authority, which can be

thought of as the consumer's ontine bank.

The field payment mechanisms concemed with payments that are valued at a

few cents or less.

A monetary transfer, where the transaction is said to either complete fully or

not at d l . No money is created or lost.

The proof of integrity and origin of data - both in an unforgeable relationship

which can be verified by any Party.

Payment systems that do not require a central server in the course of a purchase

to guard against fraud.

Payment mechanisms that require authorization from a central server, or a

- .

Torni Poutanen, NetCenrs Protocol for Inexpensive Internet Payments

protocois

Pu blic-Key

Encryption

RSA

Scala biiity

Scrip

SET

Vendor

bank. for each purchase.

This form of encryption utilizes a key-pair, where the an encrypted message

generated using one of the keys can only be decoded with the complimentary

key.

The most popular public-key encryption algorithm used today.

The ability for a system to be expanded to a wide reach without bottleneck

issues,

A scnp holds a certain amount of fun& allocated by the issuing authority. A

floating scrip can be passed from one vendor to another without the need to

contact a central server.

Visa's and Mastercard's credit card payment protocol for the Internet.

An online merchant. shop or kiosk that sells online content and authorizes

payments-

Tomi Poutanen, NerCents Protocof for Inexpensive Interner Payrnents

Appendix A - Formal NetCents Protocol

A. 1 Cornmon Data Structures Netcents R o o t Public K e y

Date Expiry Date Int32 PublicExponent Int1024 RSA-Modulus

Issuing Authoiity and Acquirer Certificates fnt32 BankID Int32 IP Int32 RSA-Pub1 icExponent Int512 RSA-Modulus VarChar EFT-instructions Date ExpiryDate Int1024 RootSignature

/ / To be determined

Arbitar und Blipdipg Site Csrtificates Int32 SiteID Int3 2 BankID Int32 IP Int32 RSA-PublicExponent IntS12 RSA-Modulus Date ExpiryDate Int512 IASignature / / signature of issuing authority

Vendor Csrtificates Int64 Vendor ID Int32 BarikID VarChar Name Int32 IP Int32 Liabili ty Int3 2 RSA-PublicExponent Int512 RSA-Modulus Date ExpiryDate Int512 Asignature / / signature of acquirer

Custanrsc Certificates Int32 Cus tomerf D Int32 BankID VarChar Cus t ornerName VarChar Misc / / To be defined, and may include age, membership, etc. Int32 RSA-PublicExponent Int512 RSA-Modulus Date ExpiryDate Int512 IASignature / / signature of issuing authority

Torni Poutanen, NetCents Protocol for Inexpensive Internat Payments

Custoonsr Scrip Int64 ScripID Int32 BankID Int64 Vendor ID Int32 Value Int8 Currency Date ExpiryDate IntS12 RSA-PrivateExponent Int512 RSA-Modulus

Vendor Scrip 11x64 Int32 Int32 Int8 Int32 Int8 IntS12 IntS12

ScripID BankID Value Currency Liability RSA-PublicExponent RSA-Modulus Signature / / signature of issuing authority

E l e c t r d c P a y m a t Order Int64 Scripf D fnt64 Vendor ID Int64 Produc t ID Int32 Balance Date FurchaseDate Int128 MDS-Hash / / only used f o r paymencs againsc multiple scrip

A. 2 Cryptographie Notation

E{M, SKAB 1 The message M is encrypted with a s h e d key SK,

E{M, Cert.PrivateKey ) The message M is encrypted with the private key specified in

its certificate.

Sign(M, cert-private~ey) The message M is signed with a member's private key. In

practice this entails encrypting the message digest.

Hash (M) Calculates the hash (MD5 impiied) of a message

NONCE A unique, random number that is associated with a session.

A. 3 Customer-lssuing Authoriry Transactions

The fint steps in participating in the NetCents payment system is to register with an issuing

authority, B, and to buy scrip. The registration process is largely dependent on the issuing

- -

Tomi Poutanen, Netcents Protocol for Inexpensive Inremet Payments 75

authority and the type of questions they may a s k However, one task of the registration process is

to create and securely transmit a customer certificate to the customer, C:

1- C->B: (CMD-REQVEST-CERTIFICATE)

2. B->C: (BCert )

3. C->B: ((MD-REGISTER, E ( ( S h , NONCE) , BCert , PublicKey ) )

4. B->C: E( NONCE, SKca )

5. C->B: Fil1 necessary forms

6. B: Authorize client online, and generate a customer scrip, Ccert

7. B->C: E( (Ccert, NONCE), SK& 1

This completes the client registration with an issuing authonty. To purchase scrip, the client

deposits fùnds into her NetCents account using traditionai schemes such as credit card, electronic

fun& transfer from her bank, or a mailed check. A mailed check or a called in credit card would

result in her account king credited. She can also do the transfer online with, for example, SET:

1. C->B: ( CMD-SCRI P-PURCHASE )

2. B->C: (NONCE)

3. C->B: (Sign(NONCE, Ccert-PrivateKey),

Cus torner ID,

E( ( S h ) , BCert-PublicKey 1 ,

EI (Amounc, PO), S b 1 )

4. B: Authorize payment, PO (this could involve many steps)

5. B: Generate signed scrips worth a total of Amount.

6. B->C: E( (Scripl, Scrip2, -, Scrip,) , SGB 1 (customer scrip)

Note: Here PO stands for purchase order. and it contains the payment method, such as a credit card,

account number, SET transaction, etc.

If message 6 is lost, or if the fun& were transferred offiine via a postal check, a cailed in credit

card. or a traditional wire tramfer, then the owing hinds cm be collected by proving identity using

the customer certificate as follows:

Tomi Poutanen, NetCents Protocol for Inexpensive Internet Payments

2. B->C: E { (NONCE1 , NONCES ) , SKcB 1

3. C->B: ( Sign (NONCES, Ccert . PrivateKey) , EC (NONCE2 , AmountOwing) , S& 1

4. B: Certify that NONCE2 Fs signed by the right person-

S. B: Generate signed scrip worth a total of AmountOwing,

6. 3->Cr E{ (Scripz, Script, -, Scrip,) , SKcB 1 (customer scrip)

A.4 Cusmrner- Vendor Transactions

The following sequence of steps defines the transactions required to complete a purchase from a

vendor. The purchased product is identifimd by RoductID, and the vendor is identified by

VendorID. It is assumed that the vendor already has some scrip.

MO: Customer requests an item on the Web site.

Ml: (VendorID, ProductID, price, Date, V-Cert)

Check VendorID and IP in V-Cert, Popup purchase verification

dialog.

EPO = E{ (ScripID, VendorID, ProductID, Scrip-Value-price, Date),

Scrip-RSA-PrivateExponent )

Timer = 10 seconds

M2: (ScripID, EPO)

Veri £y EPO

i .e , cornpute EPO A Scrip.RSA,PublicExponent mod Scrip-RSA-Modulus

Scrip-Value = Scrip-Value - price (Vendor Scrip)

M3 : (Ac k, Goods )

Serip.value = Scrip-Value - price (Customer Scrip)

A.4. I Erroc Sequence intermpted afer step 5. but before step 7 completes

If the Timer in step 3 expires before a reply is received from the old vendor, then repeat 5. If no

response is heard within another 10 seconds, then contact an online arbiter to invalidate the

payment (see A.7).

--

Tomi Poutanen, Netcents Protucul for Inexpensive Interner Paymenrs

A S Scrip Relocation Transactions

The sequence of scrip relocation from a current holding vendor, OldVendorID or OV, to target

vendor, VendorID or V. The holding vendor can dso signify the issuing authority when if the scrip

is still unused. This same set of transactions is dso u;ed to transmit scnps to and from blinding

sites by the customer agent.

2, C->v:

3 - v: 4 , v->OV:

5 . ov: 6. OV->V:

7 , v:

EPO = E{ (ScripID, VendorID, -1, Scrip-Value, Date),

Scrip.RSA-PrivateExponerit 1

bFirstAttempt = TRUE

M4: (CMD-FETCH, EPO, OldVendorID, ScripID)

Check OldVendorID against revocation list, set Timer = 2 seconds.

M5: (CMD-REQOEST-SCRIP, EPO, VendorID, ScripID)

Check EPO, check VendorID against revocation list

M6: (Sign( Scrip, OV-PrivateKey), OV-Cert)

Remove Timer, Check OV-Cert, verify Scrip signature, store

signature, check EPO

M7: (Ack, ScripID)

AS. I Erroc Old Vendor Is Not Reachable

If the Timer in step 3 expires before a reply is received from the old vendor, then replace:

5, V: If bFirstAttempt Then

bFirstAttempt = FALSE

goto 3

6. V->C: M7: (ERROR-FETCH, OldVendorID)

7. C: Store ( ScripID, VendorID)

Decide on another old vendor

Goto 1

However, if the old vendor holds the only remaining scnp, then the transaction cannot complete.

The customer, however, can request for credit from her issuing authority, B, on a trust basis:

2 , C->V: M8: (CMD-FETCH-BAMC, EPO, BankID, OldVendorID, ScripID, Balance)

3 - V->B: Mg: (CMD-FETCH-BANK, ScripID, OldVendorID, VendorID, Balance, EPO)

4. B: Check that OldVendor is down (MIO), optionally blacklist OldVendor

Check Scrip owner identity, verify credit history

Tomi Poutanen, Net Cents Protocol for lnexpensive Inremet Payments

Check Scrip payment history and original balance against requested

balance

Check EPO with new VendorID.

If al1 OK, recreate a signed vendor scrip of specified balance.

5 - B->V: M11: Scrip

6 - V: Goto 5 in original sequerice

The protocol cm be extended such that the scnp is transferred via the issuing authority if the old

vendor is found to be dive. This would overcome a problem where the network is severed between

the two vendoa, but not the issuing authority and the vendors.

A.6 Purchase Against Multiple Scrip

1, C=>V: Customer requests an item on the Web site.

2, V->C: (VendorID, ProductID, price, Date, V-Cert)

3. C: Repeat A-3 until sufficient scrip at Vendor

4. C: MDS-Hash = Hash(VendorID, ProductID, Date, ScripID1, ScripID2, ..., ScripID,)

For each scrip calculate EPO as in A.3, but including MDS-Hash, and

certifying that Balance >= O

S. C->V: For each Scrip (ScripID, New balance, EPO)

6: V: For each Scrip, decrypt EPO, i - e . compute EPO A

Scrip-RSA-PublicExponent mod Scrip.RSA-Modulus

Calculate MDS-Hash, and validate al1 EPOs.

7: V->C: (Ack, Goods)

A. 7 User to User Fund Tran$ers

A transfer of funds from one user to another must be authonzed by a trusted issuing authority in

order to prevent double spending. The following sequence of steps defines the transfer of scrip

from one user, U 1, to another, U2, via the issuing authority, B.

1- UI, US: Agree on the amount to be transferred

2 - U2->B : (CMD,TRANSFER-SCRIP, E{ (SIC=, Amourit, Date) , B. RSA-PublicExponent)

3 B->U2 : E{ (ScripID1, ScripfD2, . . . , ScripID,) , SKBot)

4, US: ScripHash = MDS-Hash ( ScripIDz, ScripID2, . , . , ScripID,)

Tomi Poutanen, Net Cents Protocol for lnexpensive Intemet Payments

5. US->UT:

6. Ul:

( BankID, ScripHash, Date)

EPO = E{ (Scripf D, Bank1 D, O, Scrip -Value-Amount , Date, ScripHash) ,

Scrip-RSA-PrivateExponent )

(ScripfD, EPO)

E( (ScripID, EPO), SKeml

Verify EPO, fetch scrip(s) if necessary (refer to A-3, A.4)

E ( (CustornerS~rip~, Cust~merScrip~, . . . , CustomerScrip,) , S K B m )

A.8 Ofline Clearing; Vendor-Acquirer-lssuing Authoriry Transactions

The following process is the offline. late night batch process perfonned once every 24 hours. The

vendor transmits the gathered EPOs to his acquirer. A, which in tum requests payment from the

scrip's issuing authority, B.

M13: For each new EPO, (VendorScrip, VendorID, baseEPO, EPO)

M14: (CMD,CLEAR_EPO, VendorScrip, baseEPO, EPO, VendorCert,

AcquirerCert)

Verify baseEPO, EPO

Check against double spending

If OK, verify vendor and acquirer certificates, check vendor-

acquirer relationship.

Store Elec tronic Funds Trans f er (EFT) instructions for Acquirer

MIS: (Ack)

M16: (Ack, Balance)

baseEPO = EPO

In reality, the above sequence of steps can be fragmented in order to enhance throughput. A more

likely implementation is for the acquiring serves to gather al1 of their vendors' scrip before

cleaing the scrip with the issuing authonty. Al1 EPOs gathered by one acquirer can be transferred

and cleared in one large batch process with the issuing authority. Once the clearing procedure

completes, the vendor is contacted with a new balance. and any errors that may have occurred.

A. 9 Online Arbitration

Tomi Poutanen. NetCents Protocol for Inexpensive Interner Paymenrs

In order to facilitate guaranteed electronic goods delivery NetCents requires that customers must be

able to reload goods that have previously been paid for by retransrnitting the EPO. This is

especially important in the current htemet infrastructure where communication channels are not

dependable, and downloads are commonly interrupted. If the vendor fails to provide the customer

with the purchased goods, then an online arbiter, A, is used, which contacts the vendor, V, with the

same request. If the vendor fails to deliver the goods, then the arbiter will contact the scrip's

issuing authority, B, to cancel the possible transaction.

If Message 3 (see A.4.7) never arrives:

1. C->A: M17: (Vendorscrip, VendorID, VendorCert, ProductID, Balance, Date,

EPO )

2. A: Verify EPO, VendorCert

Timer = 10 seconds.

3. A->V: M2-a: (CMD-RESEND, ProductID, ScripID, Balance, Date, EPO)

If vendor CO-operates:

4 , V: Check EPO

5 - V->A: M3: (Ack, GOO~S)

6, A->C: M3 : ( Ack, Goods )

If Timer expires:

4 . A->B: M18: E ((CMD-REVOKE-EPO, ScripID, VendorID, ProductID, Balance,

Date, EPO) , SKm)

5. B->A: M19: E ( ( A c k , E P O ) , SKm )

6. A->C: M19: (Nack) (goods atomic negative acknowledgement of purchase)

A. 10 Anonymous Scrip Purchases and Initiation

The NetCents protocol can be extended to include support for hilly anonymous floating scrip.

Rabin's blind signature scheme is used. as explained in Appendix C. The details of a customer, C,

purchasing anonymous scnp from an issuing authonty, B. and initiating and transmitting it are as

follows:

1. C: Create multiple scrip, SI, Sz . . . Sn with random ScripIDs and RSA-PrivateKeys

Tomi Poutanen, NetCents Protocol for Inexpensive Inrernet Paymenrs

Select a blinding factor r

Calculate blinded scrips , BS = ( SI* rRSA-PUbL'd)LDdnenc (mod RSA-Modulus))

2. C->B: Transfer n dollars to the NetCents account (using traditional means)

3. C->B: M20: (BSL, BS1, . . ., BS,) 4 . B->C: M21: ( E{BSI, RSA-PrivateExponent) , E{BS2, RSA-PrivateExponent) , . , , ,

E {BSn, RSA-PrivateExponent ) )

5. C: SI = E{BS2, RSA-PrivateExponent) /r (mod n) - - .

At a Iater time. the customer contacts a merchant for a purchase and presents the vendor with the

signed but anonymous scrip, dong with an EPO:

Customer requests an item on the Web site.

(VendorID, ProductID, price, Date, V-Cert)

Check VendorID and IP in V-Cert- Popup purchase verification

dialog,

Choose an unused anonyrnous scrip

EPO = E{ (ScripID, VendorID, ProductID, Scrip-Value-price, Date),

Scrip-RSA-PrivateExponent )

Tirner = 10 seconds

M22: (Anonymous-VendorScrip, EPO)

Verify validity of EPO

M23: E{ SKvB , IssuingAuthority-RSA-PublicExponent 1 ,

E{ (Anonymous-VendorScrip, EPO, nonce), SKm)

Check validity of own scrip signature

If check passes, store the new scrip and guard against do

spending

M24: EC (Ack, ScripID, nonce), SKm)

M25: (Ack, ScripID)

The remainder of the transaction proceeds as normal. The difference k i n g that neither the vendor,

nor the issuing authonty can associate the scrip with the owner or original purchaser.

Torni Poutanen, NetCents Prorucol for Inexpensive Internet Payments

Appendix B - RSA Narned after its inventors, Rivest, Shamir, and

popular encryption system today. RSA gets

Adleman, the RSA encryption protocol is the most

its security from the diff~culty of factoring large

numben, and it is widely believed to be secure since it has withstood years of extensive

cryptoanai ysis.

To generate two keys, choose two random large prime numbers. p and q. Computer the product:

Then choose an encryption key, e, such that e and (p-l)(q-1) are relatively prime. The three most

cornmon choices for e are 3, 17, and 65537 (216+1), in order to achieve faster public key encryption

and signature venfication [Shi96]. Next, use the extended Euclidian algorithm to compute the

decryption key, d, as:

d = e-1 mod (@- l )(q- 1))

To encrypt a message, m, we take a modular exponentiation with one key to produce a cyphenext,

c, that cm only be reversed by the other key.

For a more cornplete discussion and analysis of RSA. refer to [Shi96].

- - - -

Tomi Poutanen, Netcents Protocol for Inexpensive Interner Pcryments

Appendix C - Blind Signatures The technique of blind signatures was invented by David Chaum [Ch82]. It enables the signature

of a message without revealing the contents of the message to the signer. The protocol has many

practical uses, such as date stamping a document by a tmsted third party without reveaiing the

document contents, and is used as the basis of many fully anonymous payment protocols. The

following simple steps illustrates the use of blind signatures:

1 .The customer chooses a blinding factor r (r < n) independently and uniformly at random, and she

presents the bank with x*rC (mod n), where x is the note number to be signed and where e and n are

the public, and modulus keys of the bank, respectively.

2.The bank signs i t with the private key d: (x*1-3~ = e x d (mod n).

3.The customer divides out the blinding factor: (r*xd)/r = xd (mod n).

4.And finally, the customer stores xd, the signed note that she will pay with later. Since r is random,

the bank cannot determine x, and thus cannot connect the signing with the subsequent payment.

DigiCash uses blind signatures to create and sign electronic coins. The bank must accept coins that

it has signed, and its main online function is to guard against double spending.

Blind signatures c m also be used to sign electronic checks. However, since a check c m have an

arbitrary dollar value associated with it, a cut-and-choose methodology is used to guard against

buyer theft. The protocol proceeds dong the following lines: the buyer prepares, Say, 100 checks

(presumably for the sarne amount), each blinded with a different blinding factor and sends them to

the bank. The bank asks the user to provide the blinding factor for al1 but one of them, and verifies

that al1 checks are indeed for the amount specified. In this case, the buyer has a one in a hundred

chance of being able to spoof the bank into signing a check of undetermined arnount. Presumably

the bank will make the penalty for cheating great enough to deter such an attempt.

Blinded electronic checks can be used to set up untraceable accounts for debit type payment

protocols, even whcn the initiai payment was performed with a traceable system such as SET.

- - - - - - - - -

Tomi Poutanen, NetCents Protocol for Inupensive Internet Payments

Bibliography

[AM34771 L. Adleman, K. Mandea, G. Miller, "On Taking Roots In Finite Fields", Proceedings of

the Nineteenth IEEE Symposium on Foundations of Compter Science", pg. 715-777, October,

1977.

[AnKu961 R. Anderson, M. Kuhn, "Tamper Resistance - a Cautionary Note", The Second

USENIX Workshop on Electronic Commerce. Oakland, CA, 1996.

[Bai931 D. Balenson, "Privacy Enhancement for Intemet Electronic Mail: Part III: Algorithms,

Modes, and Identifien," RFC 1423, February 1993.

melCo95] M. Bellare, J. Garay, R. Hauser, A. Herzberg, H. Krawczyk, M. Steiner, G. Tsudik, M.

Waidner, "iKP - A Family of Secure Electronic Payment Protocols", The F ia t USENIX Workshop

on Electronic Commerce, New York, NY, 1995.

[Berk70] E. R. Berklekamp, "Factoring Polynomials Over Large Fields", Journal of Computation,

Volume 24, Numkr 1 1 1, Pg 7 13-735, 1970.

Br931 S. Brands, "Untraceable Offline Cash in Wallet with Observers", Advances in Cryptology - CRYPTO '93, Springer-Verlag, pp. 302-3 1 8.

[Br951 S. Brands, "Proposal for an Intemet cash system", Proceedings of the Intemet Society;

Symposium on Network and Distributed System Security, San Diego, CA, 1995.

[CHTY96] J. Camp, M. Harkavy, J. D. Tygar, B. Yee, "Anonymous Atomic Transactions", The

Second USENIX Workshop on Electronic Commerce, Oakland, CA, 1996.

[CST95] J. Camp, M. Sirbu, J. D. Tygar, "Token and Notational Money in Electronic Commerce9*,

The First USENIX Workshop on Electronic Commerce, New York, NY, 1995.

Tomi Poutanen, NerCents Protocol for Inexpensive Internet Payments

[Ch95J D. Chaum, "An Introduction to ecash", DigiCash, http://www.digicash.com, 1995.

[Ch821 D. Chaum, "Blind signatures for untraceable payments", Advances in Cryptology: Crypto

'82 Proceedings. Plenum Press, 1983.

[CFN88] D. Chaum, A. Fiat, M. Naor, "Untraceable electronic cash", Advances in Cryptology:

Crypto '88, Lecture Notes in Cornputer Science, no. 403, Springer-Verlag, 1988.

[ChPe88] D. Chaum, T. Pedersen, "Wallet databases with observers," Advances in Cryptology - CRYPTO '92, Springer-Verlag, pp 89-105.

[CTS9q B. Cox, J. D. Tygar, M. Sirbu, "NetBill Security and Transaction Protocol", The Fint

USENIX Workshop on Electronic Commerce, New York, NY, 1995.

[CP93] R. J. F. Cramer, T. P. Pedersen, "hproved Privacy in Wallets with Observen", Advances

in Cryptology - EUROCRYET '93, Spnnger-Verlag, pp 329-3 17.

[DEC95] Millicent, http://www .Millicent.com

[E09q T. Eng, T. Okamoto, "Single-Terrn Divisible Electronic Coins", Advances in Cryptology -

EUROCRYPT '94, Springer-Verlag, pp 438-45 1.

Fe931 N. Ferguson, "Single Term Off-Line Coins", Proceedings of Eurocrypt '93, pp. 3 18-328.

[GaSi96] E. Gabber, A. Silberschatz, "Agora: A Minimal Distributed Protocol for Electronic

Commerce", The Second USENIX Workshop on Electronic Commerce, Oakland, CA, 1996.

[GE971 GE Information Systems, Online EDI Service: http://www.getradeweb.com. -

[GSTY96] H. Gobioff, S. Smith, J. D. Tygar, B. Yee, "Cmart Cards in Hostile Environments", The

Second USENIX Workshop on Electronic Commerce, Oakland, CA, 1996.

Tomi Poutanen, NetCents Prorocol for Inexpensive Internet Payments 86

[GSW Goldman Sachs, "Cyber Commerce - internet Tsunami". Goldman, Sachs & Co. - U.S.

Research, August 1 997.

[GR931 J. Gray, A. Reuter, 'Transaction Processing: Concepts and Techniques". Morgan

Kaufmann PubIishers, San Francisco, CA, 1993.

[HalB9a P. M. Hallman-Baker, "Micro Payment Transfer Protocol (MPTP) Version 0.1". W3C

Working Draft, November 22, 1995, http://www.w3.orglpub/W\KW~-mptp.

[HSW96] R. Hauser, M. Steiner, M. Waidner, "Micro-Payments based on iKP", August 1996,

http://www.zurich.ibm.com~iKPKPreferenceshl

[HeYo96] A. Herzberg, H. Yochai, "Mini-Pay: Charging per Click on the Web",

http://www.ibm.net.iVibm~i~int-lablmpay-

bZGS84J E. D. Lazowska, J. Zahorjan, G. S. Graham. K. C. Sevcik, "Quantitative System

Performance; Cornputer System Analysis Using Queueing Network Models". Prentice-Hall, New

Jersey, 1984.

m 9 4 1 J. K. MacKie-Mason, H. R. Varian, "Some FAQs about usage based pricing,"

University of Michigan, Sept 1994, URL:

fip://gopher.econ.lsaumich.edu/pub/Pape~~/~seFAQs.htm1.

[Man951 M. S. Manasse, "The Millicent protocol for electronic commerce," The First USENIX

Workshop on Electronic Commerce, New York, NY, 1995.

myh971 N. Myhrvold, "A Penny for Your Thoughts?" Slate, Feb 13, 1997. hm://www.slate.com.

[Sch96] Bruce Schneier, Applied Cryptography; Second Edïtion", John Wiley & Sons, USA, 1996.

Tomi Poutanen, Netcents Prorocol for Inexpensive Internet Payments 87

[Rab791 M. O. Rabin, "Digital Signatures and Public Key Functions as Intractable as

Factorization", MIT Laboratory of Computer Science Technical Report. MITlLCSlTR-212, Jan

1979.

wSh96] R. L. Rivest, A. Shamir, "PayWord and MicroMint: Two simple micropayment

schemes", 1996, http://theory.lcs.rnit.edu/-rivest/RivestShamir-mpay.ps.

[Rh921 R. L. Rivest, 'The MD5 message-digest algorithm", Intemet Request for Comments, Apnl

1992, RFC 1321.

[MA791 R. L. Rivest, A. Shamir, L.M. Adleman, "On Digital Signatures and Public Key

Cryptosystems", MIT Laboratory for Computer Science, Technical Report, MIT/LCSm-2 12, Jan

1979.

[SNS88] I. G. Steiner, B. C. Neuman, J. 1. Schiller, "Kerberos: An Authentication Service for Open

Network Systems," USENIX Winter Conference, pg. 19 1-202, February L 988.

[SET9V Mastercard, Visa, "SET 1 .O - Secure Electronic Transaction Specificatiod*, May 3 1,

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

[Sha95] A. Shamir, "Fast Signature Screening", CRYPTO '95 rump session taik; to appear in RSA

Laboratones* CryptoBytes.

[SHS93] National Institute of Standard and Technology (NIST). "FIPS Publication 1 80: Secure

Hash Standard (SHS)", May, 1993.

[SPC95] M. Stadler, JM. Piveteau, J. Camenisch, "Fair Blind Signatures", Advances in Cryptology

- EUROCRYPT '95, Springer-Verlag, pp 209-219.

[STT96] Microsoft, http://www.microsoft.com/windows/pr/spt27.

Torni Poutanen, NetCents Protocol for Inexpensive Interner Paymenrs

[Ty96] J. D. Tygar, "Atomicity in electronic commerce". Proceedings of the Fifteenth Annual

ACM Symposium on Principles of Distributed Computing. pages 8-26. May 1996.

[TW96] J. D. Tygar, A. Whitten, "WWW Electronic Commerce and Java Trojan Horses", The

Second USENIX Workshop on Electronic Commerce. Oakland, CA, 1996.

Tomi Poutanen, Netcents Protocol for Inexpensive Intemet Paymenrs

l MAGE NALUATION TEST TARGET (QA-3)

APPLIED IMAGE. lnc 1653 East Main Street - -. , , Rochester. NY 14609 USA -- --= Phone: 71 W48~-03OO -- -- - - Fa: 71 6/288-5989

O 1993. Wied Image. lm, W Righls Resenred