electronic payment systems 20-763 lecture 10 micropayments ii

20-763 ELECTRONIC PAYMENT SYSTEMS

FALL 2002

COPYRIGHT © 2002 MICHAEL I. SHAMOS

Electronic Payment Systems20-763

Lecture 10

Micropayments II


FALL 2002


Micropayments

• Replacement of cash– Cheaper (cash very expensive to handle)– Electronic moves faster– Easier to count, audit, verify

• Small transactions– Beverages– Phone calls– Tolls, transportation, parking– Copying– Internet content– Lotteries, gambling


FALL 2002


Micropayments

• Transactions have low value, e.g. less than $1.00• Must process the transaction at low cost• Technological savings:

– Don’t verify every transaction– Use symmetric encryption

• Float-preserving methods– Prepayment– Grouping

• Aggregate purchases (to amortize fixed costs)• Provide float to processor• Partial anonymity (individual purchases disguised)


FALL 2002


Micropayments

• Prepaid cards– Issued by non-banks– Represent call on future service– Not money since usable only with one seller

• Electronic purse– Issued by bank– Holds representation of real money– In form of a card (for face-to-face or Internet use)– In virtual form (computer file for Internet use)– The two forms are converging, e.g. wireless


FALL 2002


Electronic Purse Issues

• Loading (charging) the purse with money• Making a payment (removing money from the card)• Clearance (getting money into the seller’s account)


FALL 2002


Remote Micropayments

• Remote micropayments– Buyer is not physically in seller’s presence– Can’t insert card into vendor’s machine– No physical goods, only information goods

• if micropayment will work, goods must be cheap, e.g. $0.01

– Subscriptions, credit cards, checks, ACH (even PayPal) too expensive

• Examples: web pages, stock quotes,news articles, weather report, directory lookup

• Need instant service for large numbers of 1¢ transactions + reasonable profit to payment provider


FALL 2002


Remote Micropayment Parties

• Users (buyers)• Vendors (sellers)• Brokers (intermediaries)

– issue “scrip” (virtual money)to users

– redeem scrip from vendorsfor real money

• Assumptions– User-Broker relationship is long-term– Vendor-Broker relationship is long-term– User-Vendor relationship is short-term

WebWebServerServer

Scrip

BrokerBrokerServerServer

WebWebBrowserBrowser

User Vendor

Broker


FALL 2002


Micropayment Efficiency

• Providers need to process a peak load of at least 2500 transactions/second

• Public-key cryptography is expensive– 1 RSA signature verifications = 10 symmetric encryptions =

10,000 hashes

• Need to minimize Internet traffic– Servers must be up

– More servers required, longer queues, lost packet delay– Remove the provider from the process (user + vendor only)

• For small payment amounts, perfection is not needed– Losing a micropayment

– Keep micropayment fraud low


FALL 2002


Payword Concept• Hash functions are one-way and easy to compute• Use them to secure scrip• Suppose we need N “coins”

• Start with a random number WN

• Hash it N times to form W0

WN WN-1

WN-1 = H(WN )

WN-2

WN-2 = H(WN-1 )

W0

W0 = H(W1 )

• • • W1

W1 = H(W2 )

• Vendor receives W0 to start

• Each payword is worth one unit

• When vendor receives W53 he verifies it by hashing


FALL 2002


Payword

• Based on “paywords,” strings that will be accepted by vendors for purchases

• User authenticates himself to a broker with one signature verification, establishes means of paying “real” money for paywords

• User sets up with broker a linked chain of paywords to be used with a specific vendor. (Linking is used to make authentication of the paywords very cheap.)

• User pays vendor by revealing paywords to vendor• Marginal cost of a payment: one hash computation


FALL 2002


Payword

• User sets up Payword account with a broker (pays real money)

• Broker issues user a “virtual card” (certificate)– broker name, user name, user IP address, user public key

• Certificate authenticates user to vendor• User creates payword chains (typical length: 100

units) specific to a vendor


FALL 2002


Buying Paywords

• User visits broker over secure channel (e.g. SSL), giving coordinates of bank account or credit card:

U, AU, PKU, TU, $U

• Broker issues a subscription card

CU = { B, U, AU, PKU, E, IU } SKB

• Vendor will deliver goods only to AU

USERNAME

USERADDRESS

USERPUBLIC KEY

USERCERTIFICATE

COORDINATES OF BANKACCOUNT OR CC

BROKERNAME

EXPIRATIONDATE

USER INFORMATION(CARD #, CREDIT LIMIT)

BROKERPRIVATE KEY


FALL 2002


Making Payment

• Commitment to a payword chain = promise by user to pay vendor for all paywords given out by user before E– N = value in jetons needed for purchases (1 payword = 1 jeton)

– WN = last payword, a random value chose by user

• User creates payword chain backwards by hashing WN

WN-1 = H(WN); WN-2 = H(WN-1) = H(H(WN)) , etc., giving

W = { W0, W1, . . . WN-1, WN }

• User “commits” this chain to a vendor, sends

M = { V, CU, W0, D, IM } SKUVENDOR

NAME

EXPIRATIONDATE OF

COMMITMENT

EXTRA INFORMATION(VALUE OF CHAIN)

USERPRIVATE KEY

“FIRST”PAYWORD

EXPENSIVE: REQUIRESDIGITAL SIGNATURE

CAN EASILY COMPUTE THIS WAY

DIFFICULT TO COMPUNTE THIS WAY

M IS VENDORSPECIFIC ANDUSER-SPECIFIC

(NO USE TOANYONE ELSE)


FALL 2002


Making Payment, cont.• Vendor can use PKU and PKB to read the commitment to know

that U is currently authorized to spend paywords.• User “spends” paywords with the vendor in order

W1 , W2 , . . . , WN . To spend payword Wi, user sends the

vendor the unsigned token P = { Wi, i }.

• To verify that P is legitimate, vendor hashes it i times to obtain W0 . If this matches W0 in the commitment, the payment is good.

• If V stores the last payword value seen from U, only one hash is needed. (If last hash was Wi, when vendor receives Wi+1, can

hash it once and compare with Wi .)

• P does not have to be signed because hash is one-way.


FALL 2002


Settlement with Payword

• Even if vendor has no relationship with broker B, can still verify user paywords (only need broker’s public key)

• For vendor to get money from B requires relationship• Vendor sends broker B a reimbursement request for

each user that sent paywords with M, WL (last payword

received by vendor)

• Broker verifies each commitment using PKU and

performs L hashes to go from WL to W0

• Broker pays V, aggregates commitments of U and bills U’s credit card or debits money from U’s bank account


FALL 2002


Payword Payment Properties

• Payment and verification by vendor are offline (no use of a trusted authority).

• Payment token P does not reveal the goods• Fraud by user (issuing paywords without paying for

them) will be detected by the broker; loss should be small

• Vendor keeps record of unexpired paywords to guard against replay


FALL 2002


MicroMint

• Brokers produce “coins” having short lifetimes, sell coins to users

• Users pay vendors with coins• Vendors exchange the coins with brokers for “real”

money

BROKER

CUSTOMER VENDOR

SOURCE: SHERIF

NEW COINS

SPENDING OF COINS

TRANSFER OF INFORMATION

PURCHASE NEW COINSRETURN UNUSED COINS

EXCHANGE COINS FOROTHER FORMS OF VALUE


FALL 2002


Minting Coins in MicroMint

• Idea: make coins easy to verify, but difficult to create (so there is no advantage in counterfeiting)

• In MicroMint, coins are represented by hash-function collisions, values x, y for which H(x) = H(y)

• If H(•) results in an n-bit hash, we have to try about2n/2 values of x to find a first collision

• Trying c•2n/2 values of x yields about c2 collisions• Collisions become cheaper to generate after the first

one is found


FALL 2002


Coins as k-way Collisions

• A k-way collision is a set { x1, x2, . . ., xk } with

H(x1) = H(x2) = . . . = H(xk)

• It takes about 2n(k-1)/k values of x to find a k-way collision

• Trying c• 2n(k-1)/k values of x yields about ck collisions

• If k > 2, finding a first collision is slow, but subsequent collisions come fast

• If a k-way collision { x1, x2, . . ., xk } represents a coin,

easily verified by computing H(x1), H(x2), . . ., H(xk)

• A broker can easily generate 10 billion coins per month using one machine


FALL 2002


Selling MicroMint Coins

• Broker generates 10 billion coins and stores (x, H(x)) for each coin, having a validity period of one month

• The function H changes at the start of each month

• Broker sells coins { x1, x2, . . ., xk } to users for “real”

money, records who bought each coin• At end of month, users return unused coins for new

ones


FALL 2002


Spending MicroMint Coins

• User sends vendor a coin { x1, x2, . . ., xk }

• Vendor verifies validity by checking thatH(x1) = H(x2) = . . . = H(xk). (k hash computations)

• Valid but double-spent coins (previously used with a different vendor) cannot be detected at this point

• At end of day, vendor sends coins to broker• Broker verifies coins, checks validity, checks for

double spending, pays vendor• (Need to deal with double spending at this point)


FALL 2002


Detecting MicroMint Forgery

• A forged coin is a k-way collision { x1, x2, . . ., xk }

under H(•) that was not minted by broker• Vendor cannot determine this in real-time• Small-scale forgery is impractical• Forged coins become invalid after one month• New forgery can’t begin before new hash is announced• Broker can issue recall before the month ends• Broker can stay many months ahead of forgers


FALL 2002


Millicent• Vendors produce vendor-specific “scrip”, sell to brokers

for “real” money at discount• Brokers sell scrip from many vendors to many users• Scrip is prepaid: promise of future service from vendor• Users “spend” scrip with vendors, receive change

BROKER

USER VENDOR

SOURCE: COMPAQ

USER SPENDS VENDORSCRIP FOR INFORMATION

TRANSFER OF INFORMATION(CHANGE IN MESSAGE HEADER)

USER BUYS BROKERSCRIP ($ WEEKLY)

BROKERS PAYFOR VENDOR SCRIP ($$$ MONTHLY)

(¢ DAILY)

USER EXCHANGESBROKER SCRIP FOR

VENDOR SCRIP(AS NEEDED)


FALL 2002


Millicent

• Broker– issues broker scrip to user– exchanges broker scrip for vendor scrip– interfaces to banking system– collects funds from users– pays vendors (less commission)

• User– buys broker scrip from brokers– spends by obtaining vendor-specific scrip from broker

• Vendor– sells scrip to brokers– accepts vendor scrip from users– gives change to users in vendor scrip


FALL 2002


MilliCent Components

• Wallet– integrated with browser

as a “proxy”– User Interface

(content, usage)

• Vendor software– easy to integrate

as a web relay– utility for price

management

• Broker software – handles real money

User Vendor

VendorVendorServerServer


WalletWallet

Broker

Tokens

$ $

Newtokens

Spenttokens


FALL 2002


MilliCent System Architecture

BrokerServer

Broker (tens?)

HTTP

VendorServer

Web Server

Vendor (thousands)

Price File

DocumentTree

Site Map

PriceConfigurator

Browser Wallet

User (millionsof consumers)

BrowserCache

WalletContents

HTTP


FALL 2002


Millicent Scrip Verification

• Token attached to HTTP requests• Scrip can not be:

– Spent twice– Forged– Stolen

• Scrip is validated:– By each vendor, on the fly– Low computational overhead– No network connection– No database look up

WebWebServerServer

ScripScrip


WebWebBrowserBrowser

Client Vendor

Broker


FALL 2002


Secret

wellsfargo.com / 0.005usd / 0081432 / 101861 / 19961218 {co=us/st=ca} 1d7f4a734b7c02282e48290f04c20

Vendor Value ID# Cust ID# Props StampExpires

MilliCent Scrip


FALL 2002


Vendor Server

• Vendor server acts as a proxy for the real Web server

• Vendor server handles all requests:– MilliCent – relay to web-server

• MilliCent processing:– Validates scrip and

generates change– Sells subscriptions– Handles replays, cash-outs, and refunds

VendorVendorServerServer

Web Web ServerServer

Vendor Site

Price File

DocumentTree


FALL 2002


Major Ideas

• Micropayment systems must be very fast and inexpensive

• Are brokers necessary?• Must give up some level of security or authentication• Low losses because each transaction (and item of

scrip) is very small• Micropayments are integrated into browsers and

wallets• Best application: Internet content


FALL 2002


QA&

electronic payment systems 20-763 lecture 10 micropayments ii

Documents

real moneybroker issues

unitwhen vendor

termuservendor relationship

specific vendor

termvendorbroker relationship

user ip address

user public keycertifi

virtual card certificatebroker