Electronic Payment Systems
20-763
Lecture 10
Micropayments II
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Remote Micropayment Parties
• Users (buyers)
• Vendors (sellers)
• Brokers (intermediaries)
User
Vendor
Web
Browser
Web
Server
– issue “scrip” (virtual money)
to users
– redeem scrip from vendors
for real money
Scrip
Broker
Server
Broker
• Assumptions
– User-Broker relationship is long-term
– Vendor-Broker relationship is long-term
– User-Vendor relationship is short-term
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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 )
W1 = H(W2 )
W1
W0
W0 = H(W1 )
• Vendor receives W0 to start
• Each payword is worth one unit
• When vendor receives W53 he verifies it by hashing
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Buying Paywords
• User visits broker over secure channel (e.g. SSL),
giving coordinates of bank account or credit card:
U,
USER
NAME
AU,
PKU,
USER
ADDRESS
TU,
$U
USER
CERTIFICATE
USER
PUBLIC KEY
COORDINATES OF BANK
ACCOUNT OR CC
• Broker issues a subscription card
CU = { B, U, AU, PKU, E,
BROKER
NAME
EXPIRATION
DATE
IU } SKB
USER INFORMATION
(CARD #, CREDIT LIMIT)
BROKER
PRIVATE KEY
• Vendor will deliver goods only to AU
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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 }
 CAN EASILY COMPUTE THIS WAY
 DIFFICULT TO COMPUNTE THIS WAY
• User “commits” this chain to a vendor, sends
M IS VENDOR
SPECIFIC AND
USER-SPECIFIC
(NO USE TO
ANYONE ELSE)
M = { V, CU, W0, D, IM } SKU
VENDOR
NAME
“FIRST”
PAYWORD
20-763 ELECTRONIC PAYMENT SYSTEMS
EXPIRATION
DATE OF
COMMITMENT
FALL 2002
EXPENSIVE: REQUIRES
DIGITAL SIGNATURE
EXTRA INFORMATION
(VALUE OF CHAIN)
USER
PRIVATE KEY
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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.
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
PURCHASE NEW COINS
RETURN UNUSED COINS
EXCHANGE COINS FOR
OTHER FORMS OF VALUE
NEW COINS
SPENDING OF COINS
VENDOR
CUSTOMER
TRANSFER OF INFORMATION
SOURCE: SHERIF
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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 about
2n/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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Spending MicroMint Coins
• User sends vendor a coin { x1, x2, . . ., xk }
• Vendor verifies validity by checking that
H(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)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
USER EXCHANGES
BROKER SCRIP FOR
VENDOR SCRIP
(AS NEEDED)
BROKER
USER BUYS BROKER
SCRIP ($ WEEKLY)
BROKERS PAY
FOR VENDOR SCRIP
($$$ MONTHLY)
USER SPENDS VENDOR
SCRIP FOR INFORMATION
USER
VENDOR
(¢ DAILY)
TRANSFER OF INFORMATION
(CHANGE IN MESSAGE HEADER)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
SOURCE: COMPAQ
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
MilliCent Components
• Wallet
– integrated with browser
as a “proxy”
– User Interface
(content, usage)
Wallet
New
tokens
• Vendor software
– easy to integrate
as a web relay
– utility for price
management
• Broker software
$
Vendor
Server
Spent
tokens
User
– handles real money
20-763 ELECTRONIC PAYMENT SYSTEMS
Tokens
Vendor
Broker
Server
$
Broker
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
MilliCent System Architecture
Broker (tens?)
Vendor (thousands)
Broker
Server
Price
File
HTTP
User (millions
of consumers)
Browser
Document
Tree
Site Map
Wallet
HTTP
Browser
Cache
Price
Configurator
Vendor
Server
Web
Server
Wallet
Contents
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Millicent Scrip Verification
• Token attached to HTTP requests
• Scrip can not be:
Client
– Spent twice
Web
– Forged
Browser
– Stolen
• Scrip is validated:
– By each vendor, on the fly
– Low computational overhead
– No network connection
– No database look up
Broker
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
Vendor
Web
Server
Scrip
Broker
Server
COPYRIGHT © 2002 MICHAEL I. SHAMOS
MilliCent Scrip
Vendor Value ID# Cust ID# Expires Props
Stamp
Secret
wellsfargo.com / 0.005usd / 0081432 / 101861 / 19961218 {co=us/st=ca} 1d7f4a734b7c02282e48290f04c20
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Vendor Server
• Vendor server acts as a proxy
for the real Web server
• Vendor server handles all
requests:
– MilliCent
– relay to web-server
Vendor
Server
Web
Server
• MilliCent processing:
– Validates scrip and
Price
Document
generates change
File
Tree
– Sells subscriptions
– Handles replays, cash-outs, and refunds Vendor Site
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS
Q&A
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2002
COPYRIGHT © 2002 MICHAEL I. SHAMOS