Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Published by Modified over 9 years ago

Similar presentations

Presentation on theme: "ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 9: Micropayments II."— Presentation transcript:

1

2 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 9: Micropayments II

3 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

4 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

5 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

6 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

7 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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)

8 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

9 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Statistical Schemes During World War II, Cola-Cola raised the price of a bottle from 5 cents ($0.05) to 6 cents ($0.06) It was expensive to change the coin mechanism Coca-Cola randomly removed 1/5 of the bottles from its machines but kept the 5-cent mechanism 4/5 of the time a customer would receive a bottle for 5 cents 1/5 of the time a customer would pay 5 cents and get NOTHING The AVERAGE price of a bottle was 6 cents Rarely, a user might pay a lot for a bottle (1 in 625 bottles cost 20 cents)

10 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Statistical Payment 999/1000 VOID FAIRNESS: User, merchant and bank cannot cheat Not always fair to user (might be overcharged) Fair to merchant and bank on average Enable 1000 Transactions at Cost of 1 1/1000 $10 User needs to pay Mapquest $0.01

11 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS MR1 (Micali, Rivest) Three parties: user U, merchant M, bank B For simplicity, assume every transaction is worth $0.01 but we only want to process transactions with probability 1/1000 U and M have public-private key pairs Let F be a publicly available function (everyone can obtain the code) that returns a number between 0 and 1 uniformly. (The values of F are uniformly distributed between 0 and 1.) A transaction string T = User ID || Merchant ID ||Bank ID ||timestamp SOURCE: RON RIVEST

12 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS MR1, continued When User U wants to pay Merchant M, he sends M his digital signature C for transaction string T C = Sig U (T) (hash of T encrypted with U’s private key) Merchant M now signs C D = Sig M (C) (hash of C encrypted with M’s private key) Merchant M computes F(D) –If F(D) <.001, then C is worth $10; otherwise C is worth $0 –This occurs 1/1000 of the time If C has value, M sends to bank C & D = Sig M (C) Bank verifies signatures and F(D), charges U $10 and credits M with $10 No risk to bank; U may pay a lot more than the transaction value SOURCE: RON RIVEST

13 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Properties of MR1 Payment is off-line –U and M do not have to be in contact during transaction –U can send C by email –M does not have to contact Bank during transaction Bank only sees 0.1% of transactions No risk to bank Because of signatures, neither U nor M can cheat (if protocol is implemented properly) U may pay a lot more than the transaction value Want a protocol in which U never pays more than the transaction value SOURCE: RON RIVEST

14 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS MR2 (Micali, Rivest) Goal: make sure U never pays more than transaction value he uses Shift risk from User to Bank. This is OK because Bank processes large number of transactions U includes a serial number S as part of the transaction string Let MaxS be the highest serial number the Bank has processed for user U so far (starts at 0) When Bank processes a payable transaction: –credits M with $10 –debits U by S – MaxS –MaxS  S

15 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Why Does MR2 Work? User NEVER pays more than the number of transactions he creates After n transactions, serial number S = n. Suppose he has to pay m times Total payment = User can cheat (by not incrementing S), but Bank will catch him Bank on average receives as much as it pay out

16 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Properties of MR1 and MR2 Highly scalable: billions of transactions handled with only millions of payments Inexpensive Payments are offline Global aggregation (can handle payments to many merchants from many customers) SOURCE: RON RIVEST

17 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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)

18 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

19 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

20 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

21 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

22 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Secret wellsfargo.com / 0.005usd / 0081432 / 101861 / 19961218 {co=us/st=ca} 1d7f4a734b7c02282e48290f04c20 VendorValueID#Cust ID#PropsStampExpires MilliCent Scrip

23 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 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

24 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 Micromint models minting coins –High overhead to prevent counterfeiting Fraud is not a serious problem with micropayments

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

Download ppt "ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 9: Micropayments II."

Similar presentations

E-Commerce Payment Systems

E-Commerce Payment Systems
Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, CS Dept., Bar Ilan University By Sharon Haroni.

Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar , CS Dept., Bar Ilan University By Sharon Haroni.
Cryptography and Network Security

Cryptography and Network Security
SECURITY IN E-COMMERCE VARNA FREE UNIVERSITY Prof. Teodora Bakardjieva.

SECURITY IN E-COMMERCE VARNA FREE UNIVERSITY Prof. Teodora Bakardjieva.
PAYWORD, MICROMINT -TWO MICROPAYMENT SCHEMES PROJECT OF CS 265 SPRING, 2004 WRITTEN BY JIAN DAI.

PAYWORD, MICROMINT -TWO MICROPAYMENT SCHEMES PROJECT OF CS 265 SPRING, 2004 WRITTEN BY JIAN DAI.
Computer Science Dr. Peng NingCSC 774 Advanced Network Security1 Topic 3.2: Micro Payments.

Computer Science Dr. Peng NingCSC 774 Advanced Network Security1 Topic 3.2: Micro Payments.
1 Supplement III: Security Controls What security services should network systems provide? Confidentiality Access Control Integrity Non-repudiation Authentication.

1 Supplement III: Security Controls What security services should network systems provide? Confidentiality Access Control Integrity Non-repudiation Authentication.
Digital Cash Present By Kevin, Hiren, Amit, Kai. What is Digital Cash?  A payment message bearing a digital signature which functions as a medium of.

Digital Cash Present By Kevin, Hiren, Amit, Kai. What is Digital Cash?  A payment message bearing a digital signature which functions as a medium of.
Copyright 1996 RSA Data Security, Inc. All rights reserved.Revised 1/1/96 PayWord and MicroMint: Two Simple MicroPayment Schemes Ronald L. Rivest (MIT)

Copyright 1996 RSA Data Security, Inc. All rights reserved.Revised 1/1/96 PayWord and MicroMint: Two Simple MicroPayment Schemes Ronald L. Rivest (MIT)
20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 11 Electronic Cash.

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 11 Electronic Cash.
Slide 1 Vitaly Shmatikov CS 378 Digital Cash. slide 2 Digital Cash: Properties uDigital “payment message” with properties of cash uUnforgeable Users cannot.

Slide 1 Vitaly Shmatikov CS 378 Digital Cash. slide 2 Digital Cash: Properties uDigital “payment message” with properties of cash uUnforgeable Users cannot.
Payment Systems 1. Electronic Payment Schemes Schemes for electronic payment are multi-party protocols Payment instrument modeled by electronic coin that.

Payment Systems 1. Electronic Payment Schemes Schemes for electronic payment are multi-party protocols Payment instrument modeled by electronic coin that.
Department of Information Engineering1 Major Concerns in Electronic Commerce Authentication –there must be proof of identity of the parties in an electronic.

Department of Information Engineering1 Major Concerns in Electronic Commerce Authentication –there must be proof of identity of the parties in an electronic.
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 9: Micropayments I.

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 9: Micropayments I.
Micro-Payment Protocols and Systems Speaker: Jerry Gao Ph.D. San Jose State University URL:

Micro-Payment Protocols and Systems Speaker: Jerry Gao Ph.D. San Jose State University URL:
20-763 ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 10 Micropayments II.

ELECTRONIC PAYMENT SYSTEMS FALL 2002COPYRIGHT © 2002 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 10 Micropayments II.
1 Formal Specification and Verification of a Micropayment Protocol Alex X. Liu The University of Texas at Austin, U.S.A. October 13, 2004 Co-author: Mohamed.

1 Formal Specification and Verification of a Micropayment Protocol Alex X. Liu The University of Texas at Austin, U.S.A. October 13, 2004 Co-author: Mohamed.
20-763 ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS eCommerce Technology 20-763 Lecture 10 Micropayments I.

ELECTRONIC PAYMENT SYSTEMSFALL 2001COPYRIGHT © 2001 MICHAEL I. SHAMOS eCommerce Technology Lecture 10 Micropayments I.
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems 20-763 Lecture 11 Electronic Cash.

ELECTRONIC PAYMENT SYSTEMS SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS Electronic Payment Systems Lecture 11 Electronic Cash.
Apr 22, 2003Mårten Trolin1 Agenda Course high-lights – Symmetric and asymmetric cryptography – Digital signatures and MACs – Certificates – Protocols Interactive.

Apr 22, 2003Mårten Trolin1 Agenda Course high-lights – Symmetric and asymmetric cryptography – Digital signatures and MACs – Certificates – Protocols Interactive.

Similar presentations

Ads by Google