ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 10 Micropayments II

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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)

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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)

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Remote Micropayment Parties Users (buyers) Vendors (sellers) Brokers (intermediaries) –issue “scrip” (virtual money) to users –redeem scrip from vendors for real money Assumptions –User-Broker relationship is long-term –Vendor-Broker relationship is long-term –User-Vendor relationship is short-term WebServer Scrip BrokerServer WebBrowser User Vendor Broker

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 W N Hash it N times to form W 0 WNWN W N-1 W N-1 = H(W N ) W N-2 W N-2 = H(W N-1 ) W0W0 W 0 = H(W 1 ) W1W1 W 1 = H(W 2 ) Vendor receives W 0 to start Each payword is worth one unit When vendor receives W 53 he verifies it by hashing

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Buying Paywords User visits broker over secure channel (e.g. SSL), giving coordinates of bank account or credit card: U, A U, PK U, T U, $ U Broker issues a subscription card C U = { B, U, A U, PK U, E, I U } SK B Vendor will deliver goods only to A U USER NAME USER ADDRESS USER PUBLIC KEY USER CERTIFICATE COORDINATES OF BANK ACCOUNT OR CC BROKER NAME EXPIRATION DATE USER INFORMATION (CARD #, CREDIT LIMIT) BROKER PRIVATE KEY

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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) –W N = last payword, a random value chose by user User creates payword chain backwards by hashing W N W N-1 = H(W N ); W N-2 = H(W N-1 ) = H(H(W N )), etc., giving W = { W 0, W 1,... W N-1, W N } User “commits” this chain to a vendor, sends M = { V, C U, W 0, D, I M } SK U VENDOR NAME EXPIRATION DATE OF COMMITMENT EXTRA INFORMATION (VALUE OF CHAIN) USER PRIVATE KEY “FIRST” PAYWORD EXPENSIVE: REQUIRES DIGITAL SIGNATURE  CAN EASILY COMPUTE THIS WAY  DIFFICULT TO COMPUNTE THIS WAY M IS VENDOR SPECIFIC AND USER-SPECIFIC (NO USE TO ANYONE ELSE)

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Making Payment, cont. Vendor can use PK U and PK B to read the commitment to know that U is currently authorized to spend paywords. User “spends” paywords with the vendor in order W 1, W 2,..., W N. To spend payword W i, user sends the vendor the unsigned token P = { W i, i }. To verify that P is legitimate, vendor hashes it i times to obtain W 0. If this matches W 0 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 W i, when vendor receives W i+1, can hash it once and compare with W i.) P does not have to be signed because hash is one-way.

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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, W L (last payword received by vendor) Broker verifies each commitment using PK U and performs L hashes to go from W L to W 0 Broker pays V, aggregates commitments of U and bills U’s credit card or debits money from U’s bank account

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 CUSTOMER VENDOR SOURCE: SHERIF NEW COINS SPENDING OF COINS TRANSFER OF INFORMATION PURCHASE NEW COINS RETURN UNUSED COINS EXCHANGE COINS FOR OTHER FORMS OF VALUE

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 2 n/2 values of x to find a first collision Trying c 2 n/2 values of x yields about c 2 collisions Collisions become cheaper to generate after the first one is found

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Coins as k-way Collisions A k-way collision is a set { x 1, x 2,..., x k } with H(x 1 ) = H(x 2 ) =... = H(x k ) It takes about 2 n(k-1)/k values of x to find a k-way collision Trying c 2 n(k-1)/k values of x yields about c k collisions If k > 2, finding a first collision is slow, but subsequent collisions come fast If a k-way collision { x 1, x 2,..., x k } represents a coin, easily verified by computing H(x 1 ), H(x 2 ),..., H(x k ) A broker can easily generate 10 billion coins per month using one machine

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 { x 1, x 2,..., x k } to users for “real” money, records who bought each coin At end of month, users return unused coins for new ones

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Spending MicroMint Coins User sends vendor a coin { x 1, x 2,..., x k } Vendor verifies validity by checking that H(x 1 ) = H(x 2 ) =... = H(x k ). (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)

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Detecting MicroMint Forgery A forged coin is a k-way collision { x 1, x 2,..., x k } 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 BROKER USER VENDOR SOURCE: COMPAQ USER SPENDS VENDOR SCRIP FOR INFORMATION TRANSFER OF INFORMATION (CHANGE IN MESSAGE HEADER) USER BUYS BROKER SCRIP ($ WEEKLY) BROKERS PAY FOR VENDOR SCRIP ($$$ MONTHLY) (¢ DAILY) USER EXCHANGES BROKER SCRIP FOR VENDOR SCRIP (AS NEEDED)

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS 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 UserVendor VendorServer BrokerServer Wallet Broker Tokens $ $ New tokens Spent tokens

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS MilliCent System Architecture Broker Server Broker (tens?) HTTP Vendor Server Web Server Vendor (thousands) Price File Document Tree Site Map Price Configurator Browser Wallet User (millions of consumers) Browser Cache Wallet Contents HTTP

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS 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 WebServer Scrip BrokerServer WebBrowser Client Vendor Broker

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Secret wellsfargo.com / 0.005usd / / / {co=us/st=ca} 1d7f4a734b7c02282e48290f04c20 VendorValueID#Cust ID#PropsStampExpires MilliCent Scrip

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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 MilliCent processing: –Validates scrip and generates change –Sells subscriptions –Handles replays, cash-outs, and refunds VendorServer WebServer Vendor Site Price File Document Tree

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 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

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Q A &