1 / 50

Micropayments Revisited

Micropayments Revisited. Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, CS Dept., Bar Ilan University By Sharon Haroni. Outline . What is a micropayment The need for micropayments Dimensions in micropayment approaches Previous work New methods: MR1,MR2,MR3.

Download Presentation

Micropayments Revisited

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Outline • What is a micropayment • The need for micropayments • Dimensions in micropayment approaches • Previous work • New methods: MR1,MR2,MR3

  3. What is a “micropayment”? • A payment small enough that processing it is relatively costly. Note: processing one credit-card payment costs about 25¢ • A payment in the range 0.1¢ to $10

  4. The need for small payments • “Pay-per-click” purchases on Web: • Streaming music and video • Information services • Mobile commerce • Geographically based info services • Gaming

  5. Payment schemes • Dominant today: • Credit cards • Subscriptions • Other possibilities: • Electronic checks • Anonymous digital cash • Micropayments FOR SALE

  6. Why aren’t micropayments already here? • The market need is still nascent. • Rolling out a new payment system requires the coordination of many players. • Fundamentally: COST !Existing micropayment schemes are too costly to implement.

  7. Payment Framework: Payment System Provider (PSP) - Bank Authori-zation Deposit(s) Payment(s) Merchant User

  8. Dimensions to consider: • Level and form of aggregation (for transactions) • On-line PSP vs. off-line PSP • Interactive vs. non-interactive • Ability to handle disputes • Ability to handle overspending • Robustness against fraud

  9. Level of Aggregation • To reduce processing costs, many small micropayments should be aggregated into fewer macropayments. • Possible levels of aggregation: • No aggregation: PSP sees every payment • Session-level aggregation: aggregate all payments in one use session • Global aggregation: Payments can be aggregated across users

  10. Form of Aggregation • Deterministic aggregation:Accounting is exact. • Statistical aggregation:Accounting is statistical • In MR2 proposal makes aggregation look deterministic to user but statistical to bank.

  11. On-line PSP vs. Off-line PSP • On-line PSP:PSP authorizes each payment or each session. • Off-line PSP:User and merchant can initiate session and transact without participation of PSP. • Note: • PSP should be off-line if scheme has global aggregation. • If multiple PSP’s involved, off-line is better.

  12. Interactive vs. Non-interactive • Interactive:Payment protocol is two-way dialogue • Non-interactive:Payment protocol is one-way

  13. Ability to handle disputes • User claims he didn’t approve paymentSolution: use digital signatures • User claims goods are poor quality or were never sent.Solution: let user complain to merchant directly.

  14. Ability to handle overspending • User may refuse to payPSP for payments he has made.Solution: prepayment • User may spend morethan he was authorizedto spend.Solution: penalties/deterrence

  15. Robustness against Fraud • Any party (user/merchant/PSP) may try to cheat another. • Any two parties may try tocheat the third.

  16. Previous Work:Electronic Check • Simplest form of payment scheme. • User pays a merchant for transaction by digitally singing on piece of data which identifies transaction. • Merchant deposits by sending a Check to the Bank. • Bank credits a merchant and charges the user (after checking the sign). • So What is the problem?

  17. Problem: • No aggregation: every check spent is returned to the PSP. • PSP must be on-line all the time.

  18. Previous Work: PayWord • Rivest and Shamir ’96 • Emphasis on reducing public-key operations by using hash-chains instead: x0 x1 x2 x3 … xn • User signs x0 and releases next xifor next payment. • Merchant can check every xi, i>0. How?

  19. Example: • Assume after 70 transactions, merchant has x70 • He checks hash(x70)= x69 • Merchant sends x70, x0 to the bank (if he want to). • Bank checks if [hash70(x70)]= x0. • If true, bank credits merchant by 70¢, charges the user by 70¢ (assume fees inside).

  20. Problem: • Session-level aggregation only. • Each User has established his own H-chin with the merchant. • So… • if a user spend only 1¢, to deposit 1¢, the merchant or the bank would lose money!

  21. Another Previous Work • Rivest and Shamir ’96 - MicroMint • No aggregation: each coin is returned to PSP. • Manasse et al. ’95 – Millicent • User buys merchant-specific scrip from PSP for each session. • Requires PSP to be on-line for scrip purchase • Session-level aggregation only

  22. Previous Work: Lottery Tickets • “Electronic Lottery Tickets as Micropayments” – Rivest ’97Payments are probabilistic • First schemes to provideglobal aggregation: payments aggregated acrossall user/merchant pairs.

  23. Lottery Tickets • scheme: • Assume given S - selection rate between 0 to 1. • For each micropayment - interact according to a pre-determined protocol. • If micropayment selected, user pays 1/s times bigger than originally amount.

  24. Protocol example: • Merchant gives user hash value Yi=hash(yi+1) • User writes Merchant check: “This check is worth $10 if three low-order digits of h-1(Yi) are 756.” (Signed by user, with certificate from PSP.) • Merchant “wins” $10 with probability 1/1000. Expected value ofpayment is 1¢. • Bank sees only 1 out of every 1000 payments. • Merchant can, not provide the merchandise but … it’s only cent

  25. Problems: • Interaction: the user and the merchant must interact to select micropayments. • User risk: the scheme burdens the user with the risk that he may have to pay more than he should. • Y can be given by statistical approach (if merchant has enough “place” to store all “good y’s …")

  26. Goals for new works: • Non-interactive • Fair to user: user never “overcharged”

  27. MR1 • Like Lottery Tickets payments will be selected according to S. • No interaction between user to merchant. • Idea: • User sends Check – C, C will be payable if it worth some value. • Merchant can easily compute this value

  28. Basic scheme • Each U,M establish public key • Let T denote transaction • T contains: User, Merchant, Bank, merchandise, time, T value, … • Assume T value is const. • F(.) – public function, input string, output number between 0 to 1. • Example: • F(110)=0.110

  29. Payments • A user-U pays a merchant-M for T by sending M the check-C=SIGu(T) • C is payable if F(SIGm(C))<S • If C is payable M send to bank-B, C, SIGm(C) • If M’s, U’s signature are correct, B credits M’s count with 1/S and debits U’s account with 1/S.

  30. Properties • Payment phase is non-interactive • F(SIGm(C)) is unpredictable to U. next • B can checks if SIGm(C) is sign on C. • No cheating. Later • Note:All signature are deterministic

  31. U can’t guess F(.) • We use RSA signature. • L= length of SIG • c*Log(L) last bits of signature are indistinguishable • If L=1024 ,c=2 User can’t knew last 20 bits. (c is const grater than 1) • F(.) return 20 last bits of signature. • S could be till 1/220

  32. No cheating • B and U can’t cheat M • SIGm(C) is unpredictable to both of them. • Even if U, B saves history • M and U can’t cheat B • SIGm(C) is deterministic. • Public key is chosen before transaction. • SIGu(T) unpredictable to M,B • M and U can’t cheat B

  33. Practical variant • S could be a number, so C payable if F(SIGm(C))<S, OR the property that last X bits of C equal to F(SIGm(C)) • Using SIGm(Vi) for every day or time interval, minimizes M’s signatures. • Vi can be computed by hash(Vi+1) • M should delivers the Checks to the Bank after day/time interval, WHY? • Protecting against malicious user/bank.

  34. MR1 conclusions: • Non-interactive scheme • No fair to user Possibility of user’s excessive payments. • Very small Possibility that the user will be debited more than micropayments • Possibility decreases with number of micropayments increase

  35. MR2 • Goal: • fair to user

  36. What’s new? • The risk of MR1 scheme, shifted from User to the Bank. • Advantage of this scheme is simplicity • Doesn’t prevent cheating • Punishes “cheating parties”

  37. Basic scheme • Each U,M establish public key • All signature are deterministic • A user-U pays a merchant-M for T by sending M the check-C=SIGu(T) • User include time, serial number – SN in every Check. • C is payable if F(SIGm(C))<S • If C is payable M send to B, C, SIGm(C)

  38. Selective deposit: • Let maxSN denote the maximum serial number of a payable C of U processed by B so far. • If the new C is payable, B credits M’s count 1/S ¢, debits U’s count by SN-maxSN, maxSNSN. User charged three cents for

  39. Achievements • Non-interactive • Fair to user: user never “overcharged” – easy to prove! • But what about cheating?

  40. Cheaters catching • There is possibility to catch cheaters by two ways: • If a new SN of transaction is equal to SN before. • If SN and the time of transaction doesn’t suitable

  41. What about collusions ? • Like MR1, M & B can’t cheat U. • Like MR1, U & B can’t cheat M. • But malicious M ,U can cheat B!!! • How? • Cause check will be payable all the time, thus B credits M by 1/S, debits U by SN-SNmax.

  42. Example: • Let S=1/1000, that means for each micropayments there is possibility of 1/1000 to be chosen. • If micropayments equal to 1¢ M has to be paid 10$ for each winning. • if for every micropayments M wins, B should pays M 10$, debits U 1¢ • Bank lose 9.99$ each transaction.

  43. solution • Bank may keeps statistics and throw out of the system U/M whose payable checks cause exceptions. • Small probability that honest U/M looks like malicious. • Those honest U/M can be convinced that they caused losses to the bank, and may accept being under MR1 scheme.

  44. Conclusions • Merchant is still paid 1/S for each winning payment, while user is charged by difference between sequence numbers seen by Bank. • Users severely penalized for using duplicate sequence numbers. • If user’s payments win too often, he is converted to basic probabilistic scheme. • Bank can manage risk.

  45. MR3 • On this scheme, Bank determines which checks are payable. • A user-U pays a merchant-M for T by sending M the check-C=SIGu(T) • U includes every T a SN

  46. Selective deposit: • Let t’, t denote the time M’s last, current deposit. • M group all C into n list,L1….Ln . • Vi=sum checks on Li, V=sum of Vi • Ci=commit (Li, Vi) • M sends to B: SIGm( t, n, V, C1,… ,Cn ) • B verifies last deposit time.

  47. Selective deposit - continue • B selects k, and sends i1,…,ik to M. • M responses by de-committing Ci1…Cik • B credits M’s count with V¢ • B debits users whose checks belong to Li1…Lik according to SN like MR2. • If B feels something wrong (time, SN, sum, Li, Vi ), he throw M/U. • B also can throw M/U if they have any exceptions of statistical data, like MR2.

  48. Properties • k is arbitrary and up to the bank. • If there is more attempted fraud, a larger value of k may be used. • Recommended K>1 try to catch fakes checks. • M can chose t • Like MR2,M & U can cheat B, but B can identify them, and throw them out of system  to risky.

  49. Conclusions • those micropayments schemes • Is highly scalable: bank can support billions of payments by processing only millions of transactions (1000x reduction) • Provides global aggregation • Supports off-line payments • Provides for non-interactive payments • Protects user from statistical variations

  50. (The End)

More Related