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

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

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

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

Payment schemes u Dominant today: –Credit cards –Subscriptions u Other possibilities: –Electronic checks –Anonymous digital cash –Micropayments FOR SALE

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

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

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

Level of Aggregation u To reduce processing costs, many small micropayments should be aggregated into fewer macropayments. u 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

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

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

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

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

Ability to handle overspending u User may refuse to pay PSP for payments he has made. Solution: prepayment u User may spend more than he was authorized to spend. Solution: penalties/deterrence

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

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

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

Previous Work: PayWord u Rivest and Shamir ’96 u Emphasis on reducing public-key operations by using hash-chains instead: x 0 x 1 x 2 x 3 … x n u User signs x 0 and releases next x i for next payment. u Merchant can check every x i, i>0. How?

Example: u Assume after 70 transactions, merchant has x 70 u He checks hash(x 70 )= x 69 u Merchant sends x 70, x 0 to the bank (if he want to). u Bank checks if [hash 70 (x 70 )]= x 0. u If true, bank credits merchant by 70¢, charges the user by 70¢ (assume fees inside).

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

Another Previous Work u Rivest and Shamir ’96 - MicroMint –No aggregation: each coin is returned to PSP. u 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

Previous Work: Lottery Tickets u “Electronic Lottery Tickets as Micropayments” – Rivest ’97 Payments are probabilistic u First schemes to provide global aggregation: payments aggregated across all user/merchant pairs.

Lottery Tickets u 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.

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

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

Goals for new works: u Non-interactive u Fair to user: user never “overcharged”

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

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

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

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

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

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

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

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

MR2 u Goal: –fair to user

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

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

Selective deposit: u Let maxSN denote the maximum serial number of a payable C of U processed by B so far. u 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

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

Cheaters catching u 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

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

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

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

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

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

Selective deposit: u Let t’, t denote the time M’s last, current deposit. u M group all C into n list,L 1 ….L n. u V i =sum checks on L i, V=sum of V i u C i =commit (L i, V i ) u M sends to B: SIG m ( t, n, V, C 1, …,C n ) u B verifies last deposit time.

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

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

Conclusions u 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

(The End)