Скачать презентацию Micropayments Revisited Ronald L Rivest Silvio Micali Скачать презентацию Micropayments Revisited Ronald L Rivest Silvio Micali

c342721706a96c6c0d86bfeabe46145b.ppt

  • Количество слайдов: 50

Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89 -957, 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 Outline u. What is a micropayment u. The need for micropayments u. Dimensions in micropayment approaches u. Previous work u. New methods: MR 1, MR 2, MR 3

What is a “micropayment”? u. A payment small enough that processing it is relatively 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 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: – 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 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 Authorization Deposit(s) Payment(s) User Merchant Payment Framework: Payment System Provider (PSP) - Bank Authorization Deposit(s) Payment(s) User Merchant

Dimensions to consider: u Level and form of aggregation (for transactions) u On-line PSP 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 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 Form of Aggregation u Deterministic aggregation: Accounting is exact. u Statistical aggregation: Accounting is statistical u In MR 2 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 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 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 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 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 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 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 Problem: u No aggregation: every check spent is returned to the PSP. u PSP must be on-line all the time.

Previous Work: Pay. Word u Rivest and Shamir ’ 96 u Emphasis on reducing Previous Work: Pay. Word 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 … xn u User signs x 0 and releases next xi for next payment. u Merchant can check every xi, i>0. How?

Example: u Assume after 70 transactions, merchant has x 70 u He checks hash(x 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 Hchin with Problem: u Session-level aggregation only. – Each User has established his own Hchin 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 - Micro. Mint – No Another Previous Work u Rivest and Shamir ’ 96 - Micro. Mint – 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 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 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 u u Merchant gives user hash value Yi=hash(yi+1) User writes Merchant Protocol example: u u u 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 of payment is 1¢. Bank sees only 1 out of every 1000 payments. 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 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” Goals for new works: u Non-interactive u Fair to user: user never “overcharged”

MR 1 u Like Lottery Tickets payments will be selected according to S. u MR 1 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 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=SIGu(T) Payments u. A user-U pays a merchant-M for T by sending M the check-C=SIGu(T) u C is payable if F(SIGm(C))

Properties u Payment phase is non-interactive u F(SIGm(C)) is unpredictable to U. next u Properties u Payment phase is non-interactive u F(SIGm(C)) is unpredictable to U. next u B can checks if SIGm(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 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/220

No cheating u. B and U can’t cheat M – SIGm(C) is unpredictable to No cheating u. B and U can’t cheat M – SIGm(C) is unpredictable to both of them. – Even if U, B saves history u. M and U can’t cheat B – SIGm(C) is deterministic. – Public key is chosen before transaction. – SIGu(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(SIGm(C))<S, OR Practical variant u. S could be a number, so C payable if F(SIGm(C))

MR 1 conclusions: Non-interactive scheme û No fair to user Possibility of user’s excessive MR 1 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 ü

MR 2 u. Goal: – fair to user MR 2 u. Goal: – fair to user

What’s new? u The risk of MR 1 scheme, shifted from User to the What’s new? u The risk of MR 1 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 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=SIGu(T) u User include time, serial number – SN in every Check. u C is payable if F(SIGm(C))

Selective deposit: u Let max. SN denote the maximum serial number of a payable Selective deposit: u Let max. SN 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 SNmax. SN, max. SN SN. User charged three cents

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

Cheaters catching u There is possibility to catch cheaters by two ways: – If 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 MR 1, M & B can’t cheat U. What about collusions ? u Like MR 1, M & B can’t cheat U. u Like MR 1, 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 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 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 MR 1 scheme.

Conclusions u Merchant is still paid 1/S for each winning payment, while user is 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.

MR 3 u On this scheme, Bank determines which checks are payable. u A MR 3 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=SIGu(T) u U includes every T a SN

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

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

Properties uk is arbitrary and up to the bank. u If there is more Properties uk 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 MR 2, 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 Conclusions u those micropayments schemes – Is highly scalable: bank can support billions of payments by processing only millions of transactions (1000 x reduction) – Provides global aggregation – Supports off-line payments – Provides for non-interactive payments – Protects user from statistical variations

(The End) (The End)