Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, CS...
-
Upload
breana-sammon -
Category
Documents
-
view
218 -
download
0
Transcript of Micropayments Revisited Ronald L. Rivest & Silvio Micali RSA Conference 2002 Seminar 89-957, CS...
Micropayments Revisited
Ronald L. Rivest & Silvio MicaliRSA 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
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
The need for small payments
“Pay-per-click” purchases on Web:– Streaming music and video– Information services
Mobile commerce – Geographically based info services– Gaming
Payment schemes
Dominant today:– Credit cards– Subscriptions
Other possibilities:– Electronic checks– Anonymous digital cash– Micropayments
FOR SALE
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.
Payment Framework:Payment System Provider (PSP) -
Bank
User MerchantPayment(s)
Authori-zation Deposit(s)
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
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
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.
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.
Interactive vs. Non-interactive
Interactive:Payment protocol is two-way dialogue
Non-interactive:Payment protocol is one-way
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.
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
Robustness against Fraud
Any party (user/merchant/PSP) may try to cheat another.
Any two parties may try tocheat the third.
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?
Problem:
No aggregation: every check spent is returned to the PSP.
PSP must be on-line all the time.
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 xi
for next payment. Merchant can check every xi, i>0.
How?
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).
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!
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
Previous Work: Lottery Tickets
“Electronic Lottery Tickets as Micropayments” – Rivest ’97Payments are probabilistic
First schemes to provideglobal aggregation: payments aggregated acrossall user/merchant pairs.
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.
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 themerchandise but …
it’s only cent
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 …")
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
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
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.
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
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
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
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.
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?
The risk of MR1 scheme, shifted from User to the Bank.
Advantage of this scheme is simplicity– Doesn’t prevent cheating – Punishes “cheating parties”
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)
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, maxSNSN.
User charged three cents for
Achievements
Non-interactive Fair to user: user never “overcharged”
– easy to prove! But what about cheating?
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
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.
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.
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.
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.
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
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.
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.
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.
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