Presentation on theme: "Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, CS Dept., Bar Ilan University By Sharon Haroni."— Presentation transcript:
Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, 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))
"name": "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))
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))
"name": "Practical variant u S could be a number, so C payable if F(SIG m (C))
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
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))
"name": "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.",
"description": "u C is payable if F(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