ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 9: Micropayments I

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 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 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 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 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 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte Issued by Zentraler Kreditausschuß (Germany) Card contains counters representing money value –Max balance 200 EUR = USD252 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 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Loading GeldKarte LOADING TERMINAL (ATM) LOADING MANAGER SAM ISSUING BANK SAM AUTHORIZATION SERVER ACCOUNT DATABASE 3. AUTHORIZATION REQUEST 4. AUTHORIZATION 5. AUTHORIZATION 2. AUTHORIZATION REQUEST 6. UPDATE ACCOUNTS 7. SAM EXCHANGE 9. OFFLINE FILE TRANSFER SAM = SECURITY APPLICATION MODULE SOURCE: SHERIF 1. LOAD REQUEST + PIN 8. VALUE TRANSFER

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

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte 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 SK C (known to card, not customer) No public-key encryption Merchant computes SK C from CID and his own secret key SK M (known to card, not merchant) Merchant can now validate integrity of the card message by computing H(CID)

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte Value Exchange Customer sends StartPayment message Merchant sends MID, merchant’s transaction number TNo, SNo, a MAC encrypted with SK C, CID and the value M to be transferred, all encrypted with SK C Customer can decrypt this message with SK C 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 CUSTOMER MERCHANT CUSTOMER MESSAGE AUTHENTICATION ID SEQUENCE # SEQUENCE # ACCOUNT # CODE

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte 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 K ZD Merchant requests payment from bank (later) –sends encrypted proofs of payment to bank –TNo prevents more than one credit per transaction

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte 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 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte 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 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS GeldKarte Internet Payment Wireless potential “Caroline” Trusted Wallet Device GeldKarte Reader USB or Infrared Connection to PC CASHMOUSE

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Other Electronic Purses CYBERFLEX JAVA CARD PRISMERA QIANFLEX (CHINA) PEOPLE’S BANK OF CHINA ePURSE DANMØNT AUSTRIAN QUICK

ELECTRONIC PAYMENT SYSTEMS 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 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 SPRING 2004 COPYRIGHT © 2004 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 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 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 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 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 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 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 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, 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 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) –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 SPRING 2004 COPYRIGHT © 2004 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 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, 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 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 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 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Q A &