Electronic Payment Systems 20 763 Lecture 9 Micropayments

Electronic Payment Systems 20 -763 Lecture 9: Micropayments I

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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 (wallet) – 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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte • Issued by Zentraler Kreditausschuß (Germany) • Card contains counters representing money value – Max balance 200 EUR = USD 252 • Card is loaded through a loading terminal – Debits customer’s bank account • Spending at merchant terminal or on Internet – Amount deducted from card, added to merchant terminal (card) – No real-time authorization • End-of-day: merchant uploads transactions • Money credited to merchant account • Bank fee: 0. 3%, minimum USD 0. 01 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Loading Geld. Karte LOADING TERMINAL (ATM) 2. AUTHORIZATION REQUEST 1. LOAD REQUEST + PIN 8. VALUE TRANSFER 5. AUTHORIZATION 7. SAM EXCHANGE SAM ISSUING BANK LOADING MANAGER 4. AUTHORIZATION 3. AUTHORIZATION REQUEST AUTHORIZATION SERVER SAM 9. OFFLINE FILE TRANSFER 6. UPDATE ACCOUNTS SAM = SECURITY APPLICATION MODULE ACCOUNT DATABASE SOURCE: SHERIF ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Payment • Customer inserts Geld. Karte in slot (at merchant terminal or PCMCIA card) • Merchant authenticates customer card OFFLINE • Customer authenticates merchant card (NO THIRD PARTY) • Transfer purchase amount • Generate electronic receipts • (Later) Merchant presents receipt to issuing bank to obtain credit to merchant account • No purse-to-purse transactions ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Card Authentication • Merchant SAM generates a random number RAND (to prevent replay attack), sends to customer card with request for customer card ID (CID) • Card sends CID, a generated sequence number SNo, RAND, and H(CID) encrypted with a symmetric secret key SKC (known to card, not customer) • No public-key encryption • Merchant computes SKC from CID and his own secret key SKM (known to card, not merchant) • Merchant can now validate integrity of the card message by computing H(CID) ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Value Exchange • Customer sends Start. Payment message • Merchant sends MID, merchant’s transaction number TNo, SNo, a MAC encrypted with SKC, CID and the value M to be transferred, all encrypted with SKC • Customer can decrypt this message with SKC and validate merchant • Customer checks CID, M and SNo (prevent replay) • Customer card verifies at least M remaining, subtracts M, increments SNo, records payment data, generates proof of payment and sends to merchant card: { M, MID, SNo, TNo, ANo, MAC } AMOUNT MERCHANT ID CUSTOMER SEQUENCE # ELECTRONIC PAYMENT SYSTEMS 20 -763 MERCHANT SEQUENCE # SPRING 2004 CUSTOMER ACCOUNT # MESSAGE AUTHENTICATION CODE COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Value Exchange, cont. • Merchant verifies payment: – compute actual payment amount M' from the proof of payment, compare with M – verify MID and TNo – increment TNo, increase balance by M – notify merchant of success – record transaction data with different secret key KZD • Merchant requests payment from bank (later) – sends encrypted proofs of payment to bank – TNo prevents more than one credit per transaction ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Clearing • Uses a “shadow account” (Börsenverechnungskonto) to track the contents of the card – When card is loaded, shadow account is credited – When money is spent, shadow account is debited • online transactions immediately • offline transactions later • If card is lost or damaged, money can be replaced • Problem: every transaction is recorded, no anonymity • Solution: “Weisse Karte. ” Bought for cash, not connected to any bank account ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Security • DES (customer), triple DES (merchant) (cipher block chaining or cipher feedback mode) • 128 -bit hashes • Each card has unique ID, unique symmetric key, PIN stored in “secret zone” and in bank • Unique transaction numbers ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Geld. Karte Internet Payment “Caroline” Trusted Wallet Device Geld. Karte Reader USB or Infrared Connection to PC • Wireless potential ELECTRONIC PAYMENT SYSTEMS 20 -763 CASHMOUSE SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Other Electronic Purses QIANFLEX (CHINA) AUSTRIAN QUICK PRISMERA PEOPLE’S BANK OF CHINA e. PURSE CYBERFLEX JAVA CARD ELECTRONIC PAYMENT SYSTEMS 20 -763 DANMØNT SPRING 2004 COPYRIGHT © 2004 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 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 = 1000 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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 W 0 WN WN-1 = H(WN ) WN-2 = H(WN-1 ) • • • W 1 = H(W 2 ) W 0 = H(W 1 ) • 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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 20 -763 SPRING 2004 COPYRIGHT © 2004 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 EXPIRATION DATE OF COMMITMENT SPRING 2004 EXPENSIVE: REQUIRES DIGITAL SIGNATURE EXTRA INFORMATION (VALUE OF CHAIN) USER PRIVATE KEY COPYRIGHT © 2004 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. ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 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 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Major Ideas • Micropayment systems must be fast and cheap • They MUST lack features of higher-value payment systems • Use of hashing instead of cryptography • Micropayment parties: buyer, seller, broker • Payword user generates his own coins! • Fraud is not a serious problem with micropayments ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS

Q&A ELECTRONIC PAYMENT SYSTEMS 20 -763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS