Transcript Micropayments I 2004 - Carnegie Mellon University
Electronic Payment Systems 20-763 Lecture 9: Micropayments I
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Micropayments
• Replacement of cash – Cheaper (cash very expensive to handle) – Electronic moves faster – Easier to count, audit, verify • Small transactions – Beverages – Phone calls – Tolls, transportation, parking – Copying – Internet content – Lotteries, gambling ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Micropayments
• Transactions have low value, e.g. less than $1.00
• Must process the transaction at low cost • Technological savings: – Don’t verify every transaction – Use symmetric encryption • Float-preserving methods – Prepayment – Grouping • Aggregate purchases (to amortize fixed costs) • Provide float to processor • Partial anonymity (individual purchases disguised) ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
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-to-face or Internet use) – In virtual form (computer file for Internet use) – The two forms are converging, e.g. wireless ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Electronic Purse Issues
• Loading (charging) the purse with money • Making a payment (removing money from the card) • Clearance (getting money into the seller’s account) ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte
• Issued by Zentraler Kreditausschuß (Germany) • Card contains counters representing money value – Max balance 200 EUR = USD252 • Card is loaded through a loading terminal – Debits customer’s bank account • Spending at merchant terminal or on Internet – Amount deducted from card, added to merchant terminal (card) – No real-time authorization • End-of-day: merchant uploads transactions • Money credited to merchant account • Bank fee: 0.3%, minimum USD 0.01
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Loading GeldKarte
1. LOAD REQUEST + PIN LOADING TERMINAL (ATM) 8. VALUE TRANSFER 2. AUTHORIZATION REQUEST 5. AUTHORIZATION 4. AUTHORIZATION
SAM LOADING MANAGER
7. SAM EXCHANGE 9. OFFLINE FILE TRANSFER 3. AUTHORIZATION REQUEST 6. UPDATE ACCOUNTS AUTHORIZATION SERVER ACCOUNT DATABASE
SAM ISSUING BANK
SAM = SECURITY APPLICATION MODULE SOURCE: SHERIF
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Payment
• Customer inserts GeldKarte in slot (at merchant terminal or PCMCIA card) • Merchant authenticates customer card • Customer authenticates merchant card • Transfer purchase amount
OFFLINE (NO THIRD PARTY)
• Generate electronic receipts • (Later) Merchant presents receipt to issuing bank to obtain credit to merchant account • No purse-to-purse transactions ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Card Authentication
• Merchant SAM generates a random number RAND (to prevent replay attack), sends to customer card with request for customer card ID (CID) • Card sends CID, a generated sequence number SNo, RAND, and H(CID) encrypted with a symmetric secret key SK
C
(known to card, not customer) • No public-key encryption • Merchant computes SK
C
key SK
M
from CID and his own secret (known to card, not merchant) • Merchant can now validate integrity of the card message by computing H(CID) ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Value Exchange
• Customer sends StartPayment message • Merchant sends MID, merchant’s transaction number TNo, SNo, a MAC encrypted with SK
C
, CID and the value M to be transferred, all encrypted with SK
C
• Customer can decrypt this message with SK
C
validate merchant and • Customer checks CID, M and SNo (prevent replay) • Customer card verifies at least M remaining, subtracts M, increments SNo, records payment data, generates proof of payment and sends to merchant card: { M, MID, SNo, TNo, ANo, MAC }
AMOUNT MERCHANT CUSTOMER MERCHANT CUSTOMER MESSAGE AUTHENTICATION ID SEQUENCE # SEQUENCE # ACCOUNT # CODE
COPYRIGHT © 2004 MICHAEL I. SHAMOS ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004
GeldKarte Value Exchange, cont.
• Merchant verifies payment: – compute actual payment amount M' from the proof of payment, compare with M – verify MID and TNo – increment TNo, increase balance by M – notify merchant of success – record transaction data with different secret key K
ZD
• Merchant requests payment from bank (later) – sends encrypted proofs of payment to bank – TNo prevents more than one credit per transaction ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Clearing
• Uses a “shadow account” (Börsenverechnungskonto) to track the contents of the card – When card is loaded, shadow account is credited – When money is spent, shadow account is debited • online transactions immediately • offline transactions later • If card is lost or damaged, money can be replaced • Problem: every transaction is recorded, no anonymity • Solution: “Weisse Karte.” Bought for cash, not connected to any bank account ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Security
• DES (customer), triple DES (merchant) (cipher block chaining or cipher feedback mode) • 128-bit hashes • Each card has unique ID, unique symmetric key, PIN stored in “secret zone” and in bank • Unique transaction numbers ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
GeldKarte Internet Payment
“Caroline” Trusted Wallet Device GeldKarte Reader USB or Infrared Connection to PC
• Wireless potential
CASHMOUSE
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Other Electronic Purses
QIANFLEX (CHINA) AUSTRIAN QUICK PEOPLE’S BANK OF CHINA ePURSE PRISMERA CYBERFLEX JAVA CARD
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004
DANM ØNT
COPYRIGHT © 2004 MICHAEL I. SHAMOS
Remote Micropayments
• Remote micropayments – Buyer is not physically in seller’s presence – 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
– Subscriptions, credit cards, checks, ACH (even PayPal) too expensive • Examples: web pages, stock quotes,news articles, weather report, directory lookup • Need instant service for large numbers of 1¢ transactions + reasonable profit to payment provider ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Remote Micropayment Parties
• Users (buyers) • Vendors (sellers) • Brokers (intermediaries) – issue “scrip” (virtual money) to users – redeem scrip from vendors for real money User
Web Browser
• Assumptions – User-Broker relationship is long-term – Vendor-Broker relationship is long-term – User-Vendor relationship is short-term
Scrip Broker Server
Broker Vendor
Web Server
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Micropayment Efficiency
• Providers need to process a peak load of at least 2500 transactions/second • 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 – Losing a micropayment – Keep micropayment fraud low ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Payword Concept
• Hash functions are one-way and easy to compute • Use them to secure scrip • Suppose we need N “coins” • Start with a random number W
N
• Hash it N times to form W
0
W
N W N-1 = H(W N )
W
N-1
W
W N-2 = H(W N-1 ) N-2
• • •
W 1 = H(W 2 )
W
1 W 0 = H(W 1 )
W
0
• Vendor receives W
0
to start • Each payword is worth one unit • When vendor receives W
53
he verifies it by hashing COPYRIGHT © 2004 MICHAEL I. SHAMOS ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004
Payword
• Based on “paywords,” strings that will be accepted by vendors for purchases • User authenticates himself to a broker with one signature verification, establishes means of 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 very cheap.) • User pays vendor by revealing paywords to vendor • Marginal cost of a payment: one hash computation ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
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 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Buying Paywords
• User visits broker over secure channel (e.g. SSL), giving coordinates of bank account or credit card:
USER NAME
U, A
U
, PK
U
, T
U
, $
U USER ADDRESS USER PUBLIC KEY USER CERTIFICATE
• Broker issues a subscription card C
U
= { B, U, A
U
, PK
U
, E, I
U
} SK
B COORDINATES OF BANK ACCOUNT OR CC BROKER NAME EXPIRATION DATE USER INFORMATION (CARD #, CREDIT LIMIT)
• Vendor will deliver goods only to A
U
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004
BROKER PRIVATE KEY
COPYRIGHT © 2004 MICHAEL I. SHAMOS
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) – W
N
= last payword, a random value chose by user • User creates payword chain backwards by hashing W
N
W
N-1
= H(W
N
); W
N-2
= H(W
N-1
) = H(H(W
N
)) , etc., giving W = { W
0
, W
1
, . . . W
N-1
, W
N
}
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, C
VENDOR NAME U
, W
“FIRST” PAYWORD 0
, D, I
EXPIRATION DATE OF COMMITMENT M
} SK
U EXPENSIVE: REQUIRES DIGITAL SIGNATURE EXTRA INFORMATION (VALUE OF CHAIN) USER PRIVATE KEY
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
Making Payment, cont.
• Vendor can use PK
U
and PK
B
to read the commitment to know that U is currently authorized to spend paywords.
• User “spends” paywords with the vendor in order W
1
, W
2
, . . . , W
N
. To spend payword W
i
, user sends the vendor the unsigned token P = { W
i
,
i
}.
• To verify that P is legitimate, vendor hashes it
i
times to obtain W
0
. If this matches W
0
payment is good.
in the commitment, the • If V stores the last payword value seen from U, only one hash is needed. (If last hash was W
i
, when vendor receives W
i+1
, can hash it once and compare with W
i
.) • P does not have to be signed because hash is one-way.
COPYRIGHT © 2004 MICHAEL I. SHAMOS ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004
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, W
L
(last payword received by vendor) • Broker verifies each commitment using PK
U
and performs L hashes to go from W
L
to W
0
• Broker pays V, aggregates commitments of U and bills U’s credit card or debits money from U’s bank account ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
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 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
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 ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS
ELECTRONIC PAYMENT SYSTEMS 20-763 SPRING 2004 COPYRIGHT © 2004 MICHAEL I. SHAMOS