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 …")

Goals for new works:

Non-interactive Fair to user: user never

“overcharged”

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

MR2

Goal:– fair to user

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

(The End)