slide 1

Vitaly Shmatikov

CS 378

Digital Cash

slide 2

Digital Cash: Properties

Digital “payment message” with properties of cash

Unforgeable• Users cannot “mint” valid cash on their own

Anonymous and untraceable• Cannot link a payment to payer’s identity• Without this property, might as well use a credit

card, except for micropayments (more on this later)

Does not require online intermediaries• Accepting merchant does not have to interact with

the bank to verify that user’s payment is valid

slide 3

Overview of the System

user

bank

merchant

Withdrawdigital “coins”

Spend coins

Deposit coins

slide 4

Digital “Coins”

User creates the coin, bank signs it and debits the coin’s face amount to user’s account

user

bankCoin

m=(amount, serial number)

=sigbank(m)

Any merchant can verify bank’s

signature on the coin

No anonymity from the bank!

Bank can record all serial numbers.

When a coin is presented for payment by merchant, bank will

know who spent it.

slide 5

Blind Signatures

User creates a coin User puts his coin into a digital “envelope” Bank signs “through” the envelope

• Electronic equivalent of embossing an envelope: bank signs its contents without learning what they are

User receives the signed envelope and opens it, extracting bank’s signature on the coin

The coin is signed by the bank, but bank does not know its number and cannot trace it!

slide 6

RSA Signatures Redux

Public key is (n,e), private key is d• Main property: for any b, bed mod n b• Assume that everybody knows bank’s public key

To sign message m: s = md mod n• It’s infeasible to compute s on m if you don’t

know d

To verify signature s on message m: se mod n = (md)e mod n m

• Anyone who knows n and e (public key) can verify signatures produced with d (private key)

slide 7

Coins with Blind RSA Signatures [Chaum]

User creates the coin, blinds it, bank signs it, user removes blinding and obtains a valid coin

user

bankr=mbe,

“amount=$10”

=sigbank(r)=(mbe)d=md(bed)=mdb mod

n

User can cheat! For example, amount=$100 in m,

butamount=$10 in user’s message to

bank

Create m=(amount, serial num)

Public key=(n,e) b is a secret random

multiplier chosen by user

Bank does not see m, so

send amount separately

This is bank’s signature on the actual coin m

To extract it, user divides bank’s signature on r by his secret b. Bank has not learned m!

slide 8

“Cut-and-Choose” Verification

User creates and blinds K coins, bank asks to open K-1 of them (user doesn’t know in advance which ones)

user

bankr1=m1b1

e … rk=mkbke

“amount=$10”

Give me all b1 … bk

except bi

Create k coins mi=(amount, serial num)

Public key=(n,e)

Extract m1 … mi-1 mi+1 … mk

and verify that they contain

the right amount

b1 … bi-1 bi+1 … bk

Pick random i

=sigbank(ri)=midbi mod n

Coin mi will be used

Probability that user can cheat without being detected is only

1/k

slide 9

Double-Spending

Digital coins are easy to copy• A digital coin is simply a bitstring with certain

properties

Bank must keep track of spent coins to make sure user does not spend the same coin twice• Blinding is not a problem (why?)

Can’t prevent double-spending if bank is offline…• User pays with same coin at many merchants; when

they try to deposit the coin, bank refuses all but one– To prevent this, must involve bank in every transaction

… but can make sure that if a coin is double-spent, identity of cheater is revealed

slide 10

Preventing Double-Spending

Alice

bank

merchant #1Create N random numbers

r1, … rN for each coin

random b1…bN

1 or 0

For each bi, send ri if bi=0

“Alice”ri if bi=1

ri if bi=0“Alice”ri if bi=1

Cannot extract “Alice” from

this if coin is spent once

merchant #2

random b’1…b’N

ri if b’i=0“Alice”ri if b’i=1

Coin is double-spent

ri if b’i=0“Alice”ri if b’i=1

If bib’i for at least one i, bank

can compute (Aliceri) ri = “Alice”

and de-anonymize the cheater

Probability of this is 1-1/2n

slide 11

Micropayment Schemes

Credit cards are impractical for payments < $10• Newspaper articles, mobile downloads, etc.• Processing one credit-card payment costs about 25c

Many (unsuccessful) micropayment schemes• Millicent, PayWord, NetCard, iKP, PayTree, MicroMint

Key obstacle: implementation cost• Customer acquisition, disputes, overspending, fraud

Idea: aggregate small payments to reduce per-payment processing cost• Chaum’s digital coins are not good for aggregation

slide 12

Probabilistic Aggregation

User gives merchant a “lottery ticket” whose expected value is equal to the payment amount• Proposed independently by Rivest, Wheeler and others• For example, instead of a 1-cent payment, give “lottery

ticket” that wins $10 with probability 1/1000

After a large number of payments, merchant’s total winnings from lottery tickets will be statistically close to the total amount of payments• With 5000 tickets, merchant wins $50 on average

Only winning tickets need to be presented to bank• Few tickets win, so processing cost greatly reduced

slide 13

Peppercoin [Rivest and Micali]

user

bank

merchant

siguser(“This check is worth $10 if the three low-order digits of the hash of your digital signature on today’s date are 756”)

Winning checks

“You owe me 1 cent”

Probability of this isapproximately 1/1000

On average, only 1 transaction out of 1000

wins and must be presented for payment

slide 14

Problem: Statistical Variations

Unlucky user may pay $20 for his first two 1-cent transactions• If both tickets happen to win

Payment scheme is user-fair if user never has to pay more than he would pay if all his payments were non-probabilistic checks for the exact amount• I.e., as if user were writing 1-cent

checks instead of $10 lottery tickets

slide 15

Achieving User-Fairness

Assume that each payment is exactly 1 cent User sequentially numbers his payments: 1, 2,

… When merchant submits a winning payment

with sequence number N, bank charges the user the difference between this N and the previous sequence number that has been paid

• Severely punish users for reusing sequence numbers!

paid paidpaid

User is charged 3 cents