e Commerce Technology 20 -763 Lecture 10 Micropayments

e. Commerce Technology 20 -763 Lecture 10 Micropayments II

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 Pay. Pal) 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 2001 COPYRIGHT © 2001 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Micropayment Efficiency • Providers need to process a peak load of at least 2500 transactions/second • Public-key cryptography is expensive – 1 hash = 10 symmetric encryptions = 10, 000 RSA signature verifications • 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 2001 COPYRIGHT © 2001 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 2001 COPYRIGHT © 2001 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 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 2001 COPYRIGHT © 2001 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 A U, USER ADDRESS PKU, USER PUBLIC KEY T U, $U USER CERTIFICATE 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 2001 COPYRIGHT © 2001 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 = { W 0, W 1, . . . 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, W 0, D, IM } SKU VENDOR NAME “FIRST” PAYWORD 20 -763 ELECTRONIC PAYMENT SYSTEMS EXPIRATION DATE OF COMMITMENT FALL 2001 EXPENSIVE: REQUIRES DIGITAL SIGNATURE EXTRA INFORMATION (VALUE OF CHAIN) USER PRIVATE KEY COPYRIGHT © 2001 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 W 1 , W 2 , . . . , 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 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 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 2001 COPYRIGHT © 2001 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 W 0 • 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 2001 COPYRIGHT © 2001 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 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Micro. Mint • Brokers produce “coins” having short lifetimes, sell coins to users • Users pay vendors with coins • Vendors exchange the coins with brokers for “real” money PURCHASE NEW COINS RETURN UNUSED COINS BROKER 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 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Minting Coins in Micro. Mint • Idea: make coins easy to verify, but difficult to create (so there is no advantage in counterfeiting) • In Micro. Mint, 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 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Coins as k-way Collisions • A k-way collision is a set { x 1, x 2, . . . , xk } with H(x 1) = H(x 2) =. . . = H(xk) • 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 ck collisions • If k > 2, finding a first collision is slow, but subsequent collisions come fast • If a k-way collision { x 1, x 2, . . . , xk } represents a coin, easily verified by computing H(x 1), H(x 2), . . . , H(xk) • A broker can easily generate 10 billion coins per month using one machine 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Selling Micro. Mint 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, . . . , 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 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Spending Micro. Mint Coins • User sends vendor a coin { x 1, x 2, . . . , xk } • Vendor verifies validity by checking that H(x 1) = H(x 2) =. . . = 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 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Detecting Micro. Mint Forgery • A forged coin is a k-way collision { x 1, x 2, . . . , 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 2001 COPYRIGHT © 2001 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 (¢ DAILY) TRANSFER OF INFORMATION (CHANGE IN MESSAGE HEADER) 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 VENDOR SOURCE: COMPAQ COPYRIGHT © 2001 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 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS

Q&A 20 -763 ELECTRONIC PAYMENT SYSTEMS FALL 2001 COPYRIGHT © 2001 MICHAEL I. SHAMOS