Electronic Commerce: Payment Protocols and Fair Exchange Markus Jakobsson, RSA Labs DIMACS Tutorial on Applied Cryptography and.

Electronic Commerce: Payment Protocols and Fair Exchange

Markus Jakobsson, RSA Labs

www.markus-jakobsson.com

DIMACS Tutorial on Applied Cryptography and Network Security

Contents of this talk:

• Principles of some signature-based payment schemes.

• What is a fair exchange, and how can we obtain it?

• Some micro-payment schemes• A micro-payment scheme for routing

The typical credit-card transaction:

USER

SHOP

BANK

numbersum

ok/not ok

numbersum

crimes possible

no anonymity

online bottleneck

“Plain” signatures:

ISSUER

Contract/publickey

Contract/publickey

I

Consumerno anonymity

The typical E-money transaction:

SHOP

BANK

can avoid crimes

anonymity possible

off-line possible

USER

withdrawal

spending

deposit(possiblyoff-line)

Blind signatures (Chaum)

ISSUER

Ic/pk

c/pk I

Blind RSA Signatures• Normal signature on message m:

s=m1/3 modulo N• Blind signature generation:

Receiver: Signer:

m’=m r3 mod N s’=m’1/3 mod N

s=s’ / r mod N

ANONYMOUS E-Money:

SHOP

BANK

ok/not ok

(m,s)

s

m

(m,s)

s

m

We wantthis off-line

Bank

Eve

Dave

Cindy

Bob

Alice

Examples of this technique: Brands, Ferguson

Avoiding double-spending:

Two basic user-attacks that must be avoided:

$ $$

$$$

$$

$$

$ $

$

Forgery

$SHOP

SHOP

Overspending

(These are the minimal standard to prevent)

…..And three bank-attacks:

I McCarthy

TRACING

sooo…. you readMarxist material ?

BAD COP

INCRIMINATIONBANK

$

POF

EMBEZZLEMENT

….And four abuses of privacy:

$$

$

$

$

$

$

$

Pay tax? I have no income, sir!

TAX EVASIONMONEY LAUNDRY

$

$

$

SHOPFRONT

GrandCayman

BANK

SHOP

BLACKMAIL(user robbery)

Now please make a withdrawal

GULP!

BANK ROBBERY

$ $ $

GULP!

WE NEED

REVOKABILITY OF PRIVACY

Descriptionof

Offense

What is a bank robbery?

GULP!

Give me your secret key?

Or (more sophisticated) as a multiparty calculation with secret inputs (YAO [FOCS 86])

How do we avoid it?It must be impossible to obtain a blinded signature!

We need signatures that arenot publicly verifiable!(now the attacker can be given an invalid coin!)

YAO

Magic Ink SignaturesISSUER

Trace

ISSUER

MerchantConsumer

Trace

1. Issuing of credential

2. Use of credential

3. Deposit/report

Consumerrepresentative

access tokenspassports, group membershipgeneral certificationpayments, contract signing

What is a coin?

BANK

Bank &OMB.Man

coinserialNo.

coinserialNo.

Signing Ability

Good Withdrawals Good Withdrawals

coinserialNo.

with-drawalNo.

coinserialNo.

with-drawalNo.

Fair exchange

• Trusted third party

• Ripping

• Bit-by-bit

• Offline trusted third party (optimistic)

– FR97, ABSW98

Micropayments

Based on work by Micali and Rivest

The need for small payments

• “Pay-per-click” purchases on Web:– Streaming music and video– Information services

• Mobile commerce ($20G by 2005)– Geographically based info services– Gaming – Small “real world” purchases

• Infrastructure accounting:– Paying for bandwidth

Digital cash not for micropayments

• No aggregation: every coin spent is returned to the PSP/bank.

• This costs e.g. 25 cents per transaction just to process – very inefficient!

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.

• Processing cost is the key issue for micropayment schemes. (There are of course other issues common to all payment schemes…)

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 user/merchant session– Global aggregation: Payments can be

aggregated across users and merchants

PayWord (Rivest & Shamir)

• Emphasis on reducing public-key operations by using hash-chains instead (created starting from xn): x0 x1 x2 x3 … xn

• User digitally signs “root” x0 of hash chain and releases xi for i -th payment to merchant

• One hash-chain per user-merchant session: merchants returns last xi and signed root x0 -- receives i cents

Electronic Lottery Tickets as MicropaymentsRivest ’97, also see Wheeler ’96, Lipton and Ostrovsky ’98

• Merchant gives user hash value y = h(x)• User writes Merchant check: “This check is

worth $10 if three low-order digits of h-1(y) are 756.” (Signed by user, with certificate from PSP.)

• Merchant “wins” $10 with probability 1/1000. Expected value ofpayment is 1 cent.

• Bank sees only 1 out of every 1000 payments.

The “Peppercorn” Proposal

• Under English law, one peppercorn is the smallest amount that can be paid in consideration for value received.

• Peppercorn scheme is an improvement of basic lottery ticket scheme, making it:– Non-interactive– Fair to user: user never “overcharged”

Micali & Rivest

Peppercorn Scheme

999/1000

VOIDPEPPERCORN FAIRNESS:• User, merchant and bank cannot cheat• Fair to user always (never overcharged)• Fair to merchant and bank on average

Enable 1000 Transactions at Cost of 1

1/1000

$10

User Fairness: No “Overcharging”

• With basic scheme, unlucky user might have to pay $20 for his first 2 cents of probabilistic payments!

• We say payment schemeis user-fair if user neverneed pay more than he would if all payments werenon-probabilistic checksfor exactly expected value (e.g. 1 cent)

Achieving User-Fairness

• Assume for the moment that all payments are for exactly one cent.

• Require user to sequence number his payments: 1, 2, …

• When merchant turns in winning payment with sequence number N PSP charges user N – (last N seen) cents

User charged three cents for

User-Fairness (continued)

• Note that merchant is still paid $10 for each winning payment, while user is charged by difference between sequence numbers seen by PSP.

• Users severely penalized for using duplicate sequence numbers. If user’s payments win too often, he is converted to basic probabilistic scheme. PSP can manage risk.

Peppercorn Benefits

• Processing costs reduced by 100x-1000x– Reduced bandwidth, storage, and computation

• Increased scalability and throughput• Bank off-line

– Remote locations, vending, parking meters

• Non-interactive payments– Payments via e-mail/SMS from buyer to seller

• User-Privacy (a lot of it, for free)

A Micro-Payment Scheme EncouragingCollaboration in Multi-Hop Cellular Networks

Markus Jakobsson1 Jean- Pierre Hubaux2 Levente Buttyán2

Multi-hop cellular

Advantages•reduced energy consumption•reduced interference•number of base stations can be reduced coverage of the network can be increased•ad hoc networking

Model

Asymmetric multi-hop cellular:– multi-hop up-stream– single-hop down-stream

Energy consumption of the mobiles is still reduced

Problem statement

While all mobile nodes stand to benefit from such a scheme, a cheater could benefit even more by being served without serving others (selfish behavior)

Approach

Introduce benefit for collaboration

… without strong security assumptions

… and without large overhead

Idea

Attach micropayments to packets

… allowing collaborators to get paid

… while avoiding and detecting various attacks

A New Twist

Traditional approach for (micro) payments:

“one transaction – one payee – one payment”

New approach:

“one transaction (packet) – several payees – several payments”

Note:– the payer (sender) does not always know who

the payees are (i.e., who is on the route)– … he may not even know the number of payees

(length of the route)

Contributions

1. Technique to determine how to route packets (may be based on size of reward, remaining battery life, how busy a node is, etc.)

2. Technique to allow base stations to verify payments, drop packets with invalid payments (nodes won’t have to do this – makes their life easier)

3. Technique for aggregation of payments (to minimize logs and requirements on storage and communication)

4. Auditing process to detect misbehavior

Related work (1)• (Buchegger, Le Boudec) Reputation-based collaboration

vulnerability due to “flattering collusions”• (Zhong et al) Sprite: Reputation w/o tamperproofness

not lightweight, only works for “dense” networks• (Nisan, Ronen) General treatment of collaboration• (Buttyan, Hubaux) Tamperproofness & micro-payments

strong assumptions, vulnerable to collusions

• (Marti et al.) Watchdog and path rater does not discourage misbehavior

Related work (2)

• (Rivest) Aggregation using probabilistic payments not applied to routing/collaboration

“This is a $256 payment iff the preimage to your hash value y ends in 00000000”

• (Micali, Rivest) Prob. payments with deterministic debits bank deals with variance, not for

routing/collaboration• payee obtains lottery tickets• payer pays per serial number (used consecutively)• bank watches for deposits with duplicate serial

numbers (this means cheating!)

The solution in a nutshell

attach payment token

check if the token is a winning ticket

if so, file claim

check token

if correct, deliver packet

submit reward claims

accountingandauditinginformation

debit/credit accounts

identifyirregularitieshonest

selfish

Potential attacks

• Selective acceptance (“winning tickets only, please”)• Packet dropping (“I’ll take this, oops”)• Ticket sniffing (“any winning tickets drifting by?”)• Crediting a friend (“you will win this one!”)• Greedy ticket collection (“let’s all pool tickets”)• Tampering with claims (“I’ll zap your reward claim”)• Reward level tampering (“promise big, keep small”)

Protocol (1)Setup

Connectivity graph

Shared

user key Ku

(Ui, di, Li)

user distance level id to BS required

Shared

user key Ku

Protocol (2)Packet origination

Packet transmission

p, L, Uo , packet

level originator’s MACKu(p, L)

id

forward requestwait for acksendDid I win?

to next user Ui with sufficient level Li (<L)

Protocol (3)Network processing

MAC correct?(otherwise drop)

Send towards destination

Collect auditing information(send in batches)

Reward claim

• U forwarded (L, p, Uo, )• checks if f (, Ku) = 1• if so, stores claim (U1, U2, , L)

• all such claims sent to base station when “convenient”

Well…did I win?

receivedfrom

sentto

What is f ?

“Safe” approach: a one-way function

“Quick & Dirty” approach: check Hamming distance between and Ku

(Note that claims leak key information - be careful!)

Accounting and Auditing

• Debit based on number of packets received by base stations

• Credit based on number of accepted claims

• Give credit both to claimant and his neighbors!– stimulates forwarding even for losing tickets– increases granularity

• Check for “irregularities” (punish offenders!)

Some footprints left by cheaters• Selective acceptance – higher frequency as claimant

then “sending neighbor” (of other’s claims)• Packet dropping – higher claimant frequency than

sending neighbors for packets the base stations never received

• Ticket sniffing – higher claimant frequency than sending and receiving neighbor frequencies

• Crediting a friend – impossible geography? Also: trust needed between cheaters (know the secret key of the other – can “call for free” then!)

• Greedy ticket collection – impossible geography, too long paths (too many claimants) unrealistic (statistical) transmission rate/time unit for offenders. If one cheater is nailed, consider his frequent neighbors!