Network Security

Electronic Payment Systems II: E-cash,

Micro-payment
[Source: Various on-line slides and
documents]

Agenda

Electronic commerce concepts

Electronic payment systems overview
E-payment security
Payment security services
Material in this twin lecture is based on this
book: Security Fundamental for Electronic
Commerce by Vesna Hassler [Artech House and
Pedrick Moore, technical editor (2001) ]

Desirable Properties of Digital Money

Universality

Transferability (electronically)
Divisibility
Non-forgeability
Privacy

No one except involved parties know the amount

Anonymity

Accepted every where

No one can identify the payer, even the banks

Off-line

no on-line verification needed

Known system only satisfies some of these

Information Security by Van K Nguyen
Hanoi University of Technology

Electronic Cash

Primary advantage: small-medium

purchases

Payments of items less than $10

Credit card transaction fees make small
purchases unprofitable
Micropayments

Payments for items costing less than $1

Information Security by Van K Nguyen

Hanoi University of Technology

Basic protocol
Protocol basic steps:
1. C buys/withdraws e-cash from Bank
2. BC: e-coins

Merchant

While charging given amount + fee

3. CM: e-coins
4. M Bank: ask to check e-coin
validity
5. B M: verifies coin validity
Parties still to complete transaction
afterward merchant

Sep 2009

Present e-cash to issuing bank for deposit

once goods or services are delivered
Information Security by Van K Nguyen
Hanoi University of Technology

5
4
Bank

2
1

Customer
5

Electronic Cash Issues

E-coins must be spent only once

Users enjoy anonymity just like with real cash

Safeguards must be in place to prevent

counterfeiting

Divisibility and Convenience

Complex transaction (checking with Bank)

Sep 2009

Atomicity problem

Information Security by Van K Nguyen

Hanoi University of Technology

Two storage methods

On-line

Users do not have possession personally of ecoins

Trusted third party such as online bank holds
customers cash accounts

Off-line

Users can keep e-coins in smartcards or software

wallets
Fraud and double spending require tamper-proof
special techniques
Information Security by Van K Nguyen
Hanoi University of Technology

Advantages vs. Disadvantages

Advantages of e-cash

More efficient
Lower transaction costs
Available to anyone, unlike credit cards (which require
special authorization)

Disadvantages

Tax trail non-existent

Money laundering, black mailing
Susceptible to forgery

Information Security by Van K Nguyen

Hanoi University of Technology

Electronic Cash Security

Complex cryptographic algorithms prevent

double spending

Anonymity is absolute but double-spenders are

fully traceable

Serial numbers can allow tracing to prevent

money laundering

Does not prevent double spending, since the

merchant or consumer could be at fault

Information Security by Van K Nguyen

Hanoi University of Technology

Blind Signatures

Goal

to have the bank sign documents without knowing

what they are signing.

Anonymity with authentication

Information Security by Van K Nguyen

Hanoi University of Technology

10

How to sign with blind fold?

How?
Basic: Sign anything

1. You encrypt the message

2. Send it to the bank
3. The bank signs the message and
returns it
4. You decrypt the signed message
5. You spend it

Information Security by Van K Nguyen

Hanoi University of Technology

11

Cut and Choose

Problem
How to make the bank trust the validity of the stuff in sealed envelope?

Solution: the Cut-and-choose principle

1. Prepare n copies of the messages and

n different keys, and send them to the
bank
2. The bank requests the keys for and
opens n - 1 of them, and verifies them. It
then signs the remaining one.
3. The bank sends back the signed
message, which can then be
decrypted and spent
Information Security by Van K Nguyen
Hanoi University of Technology

12

Detecting Double Spending

Information Security by Van K Nguyen

Hanoi University of Technology

13

Existing E-cash Systems

E-cash not popular in U.S., but successful

in Europe and Japan

Reasons for lack of U.S. success not clear

Manner of implementation too complicated

Lack of standards and interoperable software that
will run easily on a variety of hardware and software
systems

Information Security by Van K Nguyen

Hanoi University of Technology

14

Existing E-cash Systems

Checkfree

Allows payment with online electronic checks

Clickshare

Designed for magazine and newspaper publishers

Miscast as a micropayment only system; only one
of its features
Purchases are billed to a users ISP, who in turn
bill the customer

Information Security by Van K Nguyen

Hanoi University of Technology

15

Existing E-cash Systems

CyberCash

Combines features from cash and checks

Offers credit card, micropayment, and check payment services
Connects merchants directly with credit card processors to provide
authorizations for transactions in real time

No delays in processing prevent insufficient e-cash to pay for the

transaction

CyberCoins

Stored in CyberCash wallet, a software storage mechanism located

on customers computer
Used to make purchases between .25c and $10
PayNow -- payments made directly from checking accounts

Information Security by Van K Nguyen

Hanoi University of Technology

16

Existing E-cash Systems

DigiCash

Trailblazer in e-cash
Allowed customers to purchase goods and services using
anonymous electronic cash

Coin.Net

Electronic tokens stored on a customers computer is used to make

purchases
Works by installing special plug-in to a customers web browser
Merchants do not need special software to accept eCoins.
eCoin server prevents double-spending and traces transactions, but
consumer is anonymous to merchant

17

Micropayments

Replacement of e-cash

Cheaper

inexpensive to handle

Recycling faster
Easier to count, audit, verify

Low transactions value,

Low cost for transaction
process

e.g. less than $1

Best suit to small

transactions

Beverages
Phone calls
Tolls, transportation,
parking
Copying
Internet content
Lotteries, gambling

Information Security by Van K Nguyen

Hanoi University of Technology

Micropayments

Prepaid cards

Issued by non-banks
Represent call on future
service
Not money since usable only
with one seller

Electronic purse (wallet)

Issued by bank
Holds representation of real
money
In form of a card (for face-toface or Internet use)

Loading (charging) with money

Payment:removing money from the
card)
Clearance: money sellers
account

Saving in choosing
technologies

Selectively verifying (e.g. not

all every transaction)
Light-weight cryptographic
tools

Float-preserving methods

Prepayment
Grouping

Aggregate purchases
(amortizing)
Provide float to processor
Partial anonymity (individual
purchases disguised)

Information Security by Van K Nguyen

Hanoi University of Technology

Remote Micropayments

Remote micropayments

Buyer is remote from sellers

Traditional payment is too expensive

Subscriptions, credit cards, checks, ACH or even PayPal

Examples such as payment for view of

Cant insert card into vendors machine

No physical goods, only information goods
if micropayment will work, goods must be cheap, e.g. $0.01

web pages, stock quotes, news articles, weather report,

directory lookup

Just required features are

instant service
transactions as cheap as 1 but in large number
reasonable profit to payment provider
Information Security by Van K Nguyen
Hanoi University of Technology

Remote Micropayment Parties

Users (buyers)
Vendors (sellers)
Brokers (intermediaries)

User

Vendor

Web
Browser

Web
Server

issue scrip (virtual money)

to users
redeem scrip from vendors
for real money

Scrip

Broker
Server

Broker

Assumptions

User-Broker relationship is long-term

Vendor-Broker relationship is long-term
User-Vendor relationship is short-term
Information Security by Van K Nguyen
Hanoi University of Technology

Micropayment Efficiency

Providers need to process a peak load of at least 2500

transactions/second

Using light-weight crypto tools

Public-key cryptography is expensive: 1 RSA signature verifications = 1000

symmetric encryptions = 10,000 hashes

Need to minimize Internet traffic

Servers must be up
More servers required, longer queues, lost packet delay
Remove the provider from the process (user + vendor only)

For small payment amounts, perfection is not needed

Not a big matter if losing a micropayment

All we need is to keep micropayment fraud low

Information Security by Van K Nguyen

Hanoi University of Technology

Payword Concept

Secure payment scripts by using hash functions

As a light-weight crypto tool, hash functions are easy to

compute but their one-way property has enough to protect
against stealing small values

Suppose we need N coins

WN

Start with a random number WN

Hash it N times to form W0
WN-1

WN-1 = H(WN )

WN-2

WN-2 = H(WN-1 )

W1 = H(W2 )

W1

W0
W0 = H(W1 )

These N numbers will be used as coins, or paywords,each

of which is worth one unit
Vendor receives W0 to start
Information Security by Van K Nguyen
Hanoi University of Technology

Payword

Based on these paywords strings that will

be accepted by vendors for purchases

First, user authenticates his/her to a broker with

one signature verification, paying real money for
paywords
User sets up with broker a linked chain of
paywords to be used with a specific vendor

Linking is used to make authentication of the paywords can be

aggregated, so the cost very cheap

User pays vendor by revealing paywords to vendor

Marginal cost of a payment: one hash computation

Information Security by Van K Nguyen

Hanoi University of Technology

Payword

User sets up Payword account with a broker (pays

real money)

Broker issues user a virtual card (certificate)

broker name, user name, user IP address, user public key

Certificate authenticates user to vendor

User creates payword chains (typical length: 100 units)
specific to a vendor

Information Security by Van K Nguyen

Hanoi University of Technology

Buying Paywords

User visits broker over secure channel (e.g. SSL),

giving coordinates of bank account or credit card:
U,
USER
NAME

AU,
USER
ADDRESS

PKU,
USER
PUBLIC KEY

TU,

USER
CERTIFICATE

COORDINATES OF BANK
ACCOUNT OR CC

Broker issues a subscription card

CU = { B, U, AU, PKU, E,
BROKER
NAME

$U

EXPIRATION
DATE

IU } SKB

USER INFORMATION
(CARD #, CREDIT LIMIT)

Vendor will deliver goods only to AU

Information Security by Van K Nguyen
Hanoi University of Technology

BROKER
PRIVATE KEY

Making Payment

Commitment to a payword chain = promise by user to

pay vendor for all paywords given out by user before E

N = value in jetons needed for purchases (1 payword = 1 jeton)

WN = last payword, a random value chose by user

User creates payword chain backwards by hashing WN

WN-1 = H(WN); WN-2 = H(WN-1) = H(H(WN)) , etc., giving
W = { W0, W1, . . . WN-1, WN }

CAN EASILY COMPUTE THIS WAY

DIFFICULT TO COMPUNTE THIS WAY

User commits this chain to a vendor, sends

M IS VENDOR
SPECIFIC AND
USER-SPECIFIC
(NO USE TO
ANYONE ELSE)

M = { V, CU, W0, D, IM } SKU

VENDOR
NAME

FIRST
PAYWORD

EXPIRATION
DATE OF
COMMITMENT

EXPENSIVE: REQUIRES
DIGITAL SIGNATURE

EXTRA INFORMATION
(VALUE OF CHAIN)

Information Security by Van K Nguyen

Hanoi University of Technology

USER
PRIVATE KEY

Making Payment, cont.

Vendor can use PKU and PKB to read the commitment to

know that U is currently authorized to spend paywords.
User spends paywords with the vendor in order
W1 , W2 , . . . , WN . To spend payword Wi, user sends
the vendor the unsigned token P = { Wi, i }.
To verify that P is legitimate, vendor hashes it i times to
obtain W0 . If this matches W0 in the commitment, the
payment is good.
If V stores the last payword value seen from U, only one
hash is needed. (If last hash was Wi, when vendor
receives Wi+1, can hash it once and compare with Wi .)
P does not have to be signed because hash is one-way.
Information Security by Van K Nguyen
Hanoi University of Technology

Settlement with Payword

Even if vendor has no relationship with broker B, can still

verify user paywords (only need brokers public key)
For vendor to get money from B requires relationship
Vendor sends broker B a reimbursement request for
each user that sent paywords with M, WL (last payword
received by vendor)
Broker verifies each commitment using PKU and
performs L hashes to go from WL to W0
Broker pays V, aggregates commitments of U and bills
Us credit card or debits money from Us bank account

Information Security by Van K Nguyen

Hanoi University of Technology

Payword Payment Properties

Payment and verification by vendor are offline (no use of

a trusted authority).
Payment token P does not reveal the goods
Fraud by user (issuing paywords without paying for
them) will be detected by the broker; loss should be
small
Vendor keeps record of unexpired paywords to guard
against replay

Information Security by Van K Nguyen

Hanoi University of Technology

Major Ideas

Micropayment systems must be fast and cheap

They MUST lack features of higher-value payment
systems
Use of hashing instead of cryptography
Micropayment parties: buyer, seller, broker
Payword user generates his own coins!
Fraud is not a serious problem with micropayments

Information Security by Van K Nguyen

Hanoi University of Technology

MicroMint

Brokers produce coins having short lifetimes, sell

coins to users
Users pay vendors with coins
Vendors exchange the coins with brokers for real
money
PURCHASE NEW COINS
RETURN UNUSED COINS

BROKER

EXCHANGE COINS FOR

OTHER FORMS OF VALUE

NEW COINS

SPENDING OF COINS

VENDOR

CUSTOMER
TRANSFER OF INFORMATION

SOURCE: SHERIF
Information Security by Van K Nguyen
Hanoi University of Technology

Minting Coins in MicroMint

Idea: make coins easy to verify, but difficult to create

(so there is no advantage in counterfeiting)
In MicroMint, coins are represented by hash-function
collisions, values x, y for which H(x) = H(y)
If H() results in an n-bit hash, we have to try about
2n/2 values of x to find a first collision
Trying c2n/2 values of x yields about c2 collisions
Collisions become cheaper to generate after the first
one is found

Information Security by Van K Nguyen

Hanoi University of Technology

Coins as k-way Collisions

A k-way collision is a set { x1, x2, . . ., xk } with

H(x1) = H(x2) = . . . = H(xk)
It takes about 2n(k-1)/k values of x to find a k-way
collision
Trying c 2n(k-1)/k values of x yields about ck collisions
If k > 2, finding a first collision is slow, but subsequent
collisions come fast
If a k-way collision { x1, x2, . . ., xk } represents a coin,
easily verified by computing H(x1), H(x2), . . ., H(xk)
A broker can easily generate 10 billion coins per
month using one machine

Information Security by Van K Nguyen

Hanoi University of Technology

Selling MicroMint Coins

Broker generates 10 billion coins and stores (x, H(x))

for each coin, having a validity period of one month
The function H changes at the start of each month
Broker sells coins { x1, x2, . . ., xk } to users for real
money, records who bought each coin
At end of month, users return unused coins for new
ones

Information Security by Van K Nguyen

Hanoi University of Technology

Spending MicroMint Coins

User sends vendor a coin { x1, x2, . . ., xk }

Vendor verifies validity by checking that
H(x1) = H(x2) = . . . = H(xk). (k hash computations)
Valid but double-spent coins (previously used with a
different vendor) cannot be detected at this point
At end of day, vendor sends coins to broker
Broker verifies coins, checks validity, checks for
double spending, pays vendor
(Need to deal with double spending at this point)

Information Security by Van K Nguyen

Hanoi University of Technology

Detecting MicroMint Forgery

A forged coin is a k-way collision { x1, x2, . . ., xk }

under H() that was not minted by broker
Vendor cannot determine this in real-time
Small-scale forgery is impractical
Forged coins become invalid after one month
New forgery cant begin before new hash is announced
Broker can issue recall before the month ends
Broker can stay many months ahead of forgers

Information Security by Van K Nguyen

Hanoi University of Technology

Millicent

Vendors produce vendor-specific scrip, sell to brokers

for real money at discount
Brokers sell scrip from many vendors to many users
Scrip is prepaid: promise of future service from vendor
Users spend scrip with vendors, receive change
USER EXCHANGES
BROKER SCRIP FOR
VENDOR SCRIP
(AS NEEDED)

BROKER
USER BUYS BROKER
SCRIP ($ WEEKLY)

BROKERS PAY
FOR VENDOR SCRIP
($$$ MONTHLY)

USER SPENDS VENDOR

SCRIP FOR INFORMATION

USER

( DAILY)
TRANSFER OF INFORMATION
(CHANGE IN MESSAGE HEADER)

Information Security by Van K Nguyen

Hanoi University of Technology

VENDOR
SOURCE: COMPAQ

Millicent

Broker

User

issues broker scrip to user

exchanges broker scrip for vendor scrip
interfaces to banking system
collects funds from users
pays vendors (less commission)
buys broker scrip from brokers
spends by obtaining vendor-specific scrip from broker

Vendor

sells scrip to brokers

accepts vendor scrip from users
gives change to users in vendor scrip

Information Security by Van K Nguyen

Hanoi University of Technology

MilliCent Components

Wallet

easy to integrate
as a web relay
utility for price
management

Broker software

Tokens

Wallet

New
tokens

Vendor software

integrated with browser

as a proxy
User Interface
(content, usage)

Spent
tokens

User

handles real money

Vendor

Broker
Server

Broker

Information Security by Van K Nguyen

Hanoi University of Technology

Vendor
Server

MilliCent System Architecture

Broker (tens?)
Vendor (thousands)

Broker
Server

Price
File

HTTP

User (millions
of consumers)

Browser

Document
Tree
Site Map

Wallet
HTTP

Browser
Cache

Price
Configurator

Vendor
Server

Wallet
Contents

Information Security by Van K Nguyen

Hanoi University of Technology

Web
Server

Millicent Scrip Verification

Token attached to HTTP requests
Scrip can not be:
Client
Spent twice
Web
Forged
Browser
Stolen
Scrip is validated:
By each vendor, on the fly
Low computational overhead
No network connection
No database look up
Broker

Information Security by Van K Nguyen

Hanoi University of Technology

Vendor
Web
Server

Scrip
Broker
Server

MilliCent Scrip

Vendor Value ID# Cust ID# Expires

Props

Stamp

Secret

wellsfargo.com / 0.005usd / 0081432 / 101861 / 19961218 {co=us/st=ca} 1d7f4a734b7c02282e48290f04c20

Information Security by Van K Nguyen

Hanoi University of Technology

Vendor Server

Vendor server acts as a proxy

for the real Web server
Vendor server handles all
requests:

Millicent
relay to web-server

Vendor
Server

Web
Server

Millicent processing:

Validates scrip and

generates
Price
Document
change
File
Tree
Sells subscriptions
Handles replays, cash-outs, and refunds
Vendor Site

Information Security by Van K Nguyen

Hanoi University of Technology

Major Ideas

Micropayment systems must be fast and cheap

They MUST lack features of higher-value payment
systems
Use of hashing instead of cryptography
Micropayment parties: buyer, seller, broker
Micromint models minting coins

High overhead to prevent counterfeiting

Fraud is not a serious problem with micropayments

Information Security by Van K Nguyen

Hanoi University of Technology