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
 Accepted every where
 Transferability (electronically)
 Divisibility
 Non-forgeability
 Privacy
 No one except involved parties know the amount
 Anonymity
 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 3
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 4
Basic protocol
 Protocol basic steps: Merchant

1. C buys/withdraws e-cash from Bank

2. BC: e-coins 5
While charging given amount + fee
4
3. CM: e-coins
4. M  Bank: ask to check e-coin Bank 3
validity
5. B M: verifies coin validity 2
 Parties still to complete transaction
1
afterward merchant
 Present e-cash to issuing bank for deposit
once goods or services are delivered
Customer
Information Security by Van K Nguyen
Sep 2009 Hanoi University of Technology 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)
 Atomicity problem

Information Security by Van K Nguyen

Sep 2009 Hanoi University of Technology 6
Two storage methods

 On-line
 Users do not have possession personally of e-
coins
 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 7
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 8
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 9
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 user’s 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 customer’s 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 customer’s computer is used to make
purchases
 Works by installing special plug-in to a customer’s 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  Best suit to small
inexpensive to handle

transactions
 Recycling faster  Beverages
 Easier to count, audit,  Phone calls
verify
 Tolls, transportation,
 Low transactions value, parking
Low cost for transaction  Copying
process  Internet content
 e.g. less than $1  Lotteries, gambling

Information Security by Van K Nguyen

Hanoi University of Technology
 Micropayments
 Prepaid cards  Saving in choosing
 Issued by non-banks technologies
 Represent call on future  Selectively verifying (e.g. not
service all every transaction)
 Not money since usable only  Light-weight cryptographic
with one seller tools
 Electronic purse (wallet)  Float-preserving methods
 Issued by bank  Prepayment
 Holds representation of real  Grouping
money  Aggregate purchases
 In form of a card (for face-to- (amortizing)
face or Internet use)  Provide float to processor
 Loading (charging) with money  Partial anonymity (individual
 Payment:removing money from the purchases disguised)
card)
 Clearance: money  seller’s
account

Information Security by Van K Nguyen

Hanoi University of Technology
Remote Micropayments
 Remote micropayments
 Buyer is remote from seller’s
 Can’t insert card into vendor’s machine
 No physical goods, only information goods
 if micropayment will work, goods must be cheap, e.g. $0.01
 Traditional payment is too expensive
 Subscriptions, credit cards, checks, ACH or even PayPal
 Examples such as payment for view of
 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) User Vendor
 Vendors (sellers) Web Web
Browser Server
 Brokers (intermediaries)
 issue “scrip” (virtual money) Scrip
to users
 redeem scrip from vendors Broker
for real money 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
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
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”
 Start with a random number WN
 Hash it N times to form W0

WN WN-1 WN-2 • • • W1 W0
WN-1 = H(WN ) WN-2 = H(WN-1 ) W1 = H(W2 ) 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, A U, PKU, T U, $U
USER USER USER USER COORDINATES OF BANK
NAME ADDRESS PUBLIC KEY CERTIFICATE ACCOUNT OR CC

 Broker issues a subscription card

CU = { B, U, AU, PKU, E, IU } SKB
BROKER EXPIRATION USER INFORMATION BROKER
NAME DATE (CARD #, CREDIT LIMIT) PRIVATE KEY

 Vendor will deliver goods only to AU

Information Security by Van K Nguyen
Hanoi University of Technology
 Making Payment
 Commitment to a payword chain = promise by user to
pay vendor for all paywords given out by user before the
date in D (expiration date)
 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
 CAN EASILY COMPUTE THIS WAY

W = { W0, W1, . . . WN-1, WN }  DIFFICULT TO COMPUNTE THIS WAY

 User “commits” this chain to a vendor, sends

M IS VENDOR EXPENSIVE: REQUIRES
SPECIFIC AND
USER-SPECIFIC M = { V, CU, W0, D, IM } SKU DIGITAL SIGNATURE

(NO USE TO EXPIRATION

VENDOR “FIRST” EXTRA INFORMATION USER
ANYONE ELSE) DATE OF
NAME PAYWORD (VALUE OF CHAIN) PRIVATE KEY
COMMITMENT

Information Security by Van K Nguyen

Hanoi University of Technology
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 broker’s 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
U’s credit card or debits money from U’s 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

BROKER EXCHANGE COINS FOR
RETURN UNUSED COINS OTHER FORMS OF VALUE

NEW COINS

SPENDING OF COINS
CUSTOMER VENDOR
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 c•2n/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 can’t 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 BROKERS PAY

BROKER SCRIP FOR FOR VENDOR SCRIP
VENDOR SCRIP ($$$ MONTHLY)
(AS NEEDED) USER BUYS BROKER
SCRIP ($ WEEKLY)

USER SPENDS VENDOR

SCRIP FOR INFORMATION
USER (¢ DAILY) VENDOR
TRANSFER OF INFORMATION
(CHANGE IN MESSAGE HEADER) SOURCE: COMPAQ

Information Security by Van K Nguyen

Hanoi University of Technology
Millicent
 Broker
 issues broker scrip to user
 exchanges broker scrip for vendor scrip
 interfaces to banking system
 collects funds from users
 pays vendors (less commission)
 User
 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
 integrated with browser
as a “proxy” Tokens Vendor
Wallet Server
 User Interface
(content, usage)
New Spent
 Vendor software tokens tokens
 easy to integrate User Vendor
as a web relay
 utility for price
management
$ Broker $
 Broker software Server
 handles real money
Broker

Information Security by Van K Nguyen

Hanoi University of Technology
MilliCent System Architecture
Broker (tens?)

Broker Vendor (thousands)

Server
Price
File Price
Configurator
HTTP Document
User (millions Tree
of consumers) Site Map

Browser Wallet Vendor Web

Server Server
HTTP
Browser Wallet
Cache Contents

Information Security by Van K Nguyen

Hanoi University of Technology
 Millicent Scrip Verification
• Token attached to HTTP requests
• Scrip can not be:
Client Vendor
– Spent twice
Web Web
– Forged Browser Server
– Stolen
• Scrip is validated:
– By each vendor, on the fly Scrip
– Low computational overhead
– No network connection
– No database look up Broker
Broker Server

Information Security by Van K Nguyen

Hanoi University of Technology
 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: Vendor Web
 Millicent Server Server
 relay to web-server
 Millicent processing:
 Validates scrip and generates
change Price Document
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
Yêu cầu Bài tập lớn
 Yêu cầu của đề cương BTL (cuối tuần 10):
 Tên đề tài
 Viết abstract (1 paragraph) mô tả tóm tắt về
nội dung báo cáo.
 Kế hoach- Nội dung chi tiết
 Cấu trúc phần/mục
 Nêu title của mỗi phần
 Nhiệm vụ của thành viên trong mỗi phần
 Các từ khóa (keyword) trong phần này
 1 paragraph mô tả tóm tắt (abtract) của phần này.
Network Security by Van K Nguyen
Sep 2010 Hanoi University of Technology 47
 Báo cáo (nộp tuần 13, trình bày tuần 14 và 15)
 Sử dụng đúng cấu trúc phần/mục đã nêu trong đề cương
 Các thành viên thực hiện đúng theo phân công
 Tài liệu tự viết, không được sao chép nguyên đoạn/câu mà không nêu rõ tài
liệu trích dẫn.
 Các báo cáo cùng chủ đề sẽ bị đánh giá chặt chẽ hơn, theo tiêu chí riêng;
giống nhau sẽ bị cho điểm thấp; Nếu báo cáo 2 nhóm giống nhau quá nhiều
sẽ bị chia điểm ( ví dụ: cùng 3= 6/2)
 Nội dung báo cáo nên đầu tư vào các phần có tự phân tích, đánh giá (nhận
định, so sánh) của riêng mình; sao chép kiến thức (kể cả dịch) là rất ít giá
trị. Để có báo cáo sâu sắc cần biết thể hiện tư duy độc lập, khả năng tổng
hợp và phân tích.
 Cách viết: học tập các bài báo khoa học được đăng tải ở các tạp chí/hội
nghị chuyên môn
 Báo cáo không cần dài, không quá 20 trang
 Chuẩn bị slides thuyết trình không quá 30 slides (có thể trình bày từ 15-25
phút)
Network Security by Van K Nguyen
Sep 2010 Hanoi University of Technology 48