Micropayments Revisited

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)