Post on 19-Dec-2015
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
Electronic Payment Systems20-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
LOADINGTERMINAL
(ATM)
LOADING MANAGER
SAM
ISSUING BANK
SAM
AUTHORIZATIONSERVER
ACCOUNTDATABASE
3. AUTHORIZATION REQUEST4. AUTHORIZATION
5. AUTHORIZATION2. AUTHORIZATION REQUEST
6. UPDATE ACCOUNTS
7. SAM EXCHANGE
9. OFFLINE FILE TRANSFER
SAM = SECURITY APPLICATION MODULE
SOURCE: SHERIF
1. LOAD REQUEST + PIN
8. VALUE TRANSFER
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• Generate electronic receipts
• (Later) Merchant presents receipt to issuing bank to obtain credit to merchant account
• No purse-to-purse transactions
OFFLINE(NO THIRD PARTY)
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 SKC (known to card, not customer)
• No public-key encryption
• Merchant computes SKC from CID and his own secret key
SKM (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 SKC, CID and the value
M to be transferred, all encrypted with SKC
• Customer can decrypt this message with SKC and validate
merchant
• 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 AUTHENTICATIONID SEQUENCE # SEQUENCE # ACCOUNT # CODE
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
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 KZD
• 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
• Wireless potential
“Caroline” TrustedWallet Device
GeldKarte ReaderUSB or InfraredConnection to PC
CASHMOUSE
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
Other Electronic Purses
CYBERFLEX JAVA CARD
PRISMERA
QIANFLEX (CHINA)
PEOPLE’S BANK OF CHINA ePURSE
DANMØNT
AUSTRIAN QUICK
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
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 vendorsfor real money
• Assumptions– User-Broker relationship is long-term– Vendor-Broker relationship is long-term– User-Vendor relationship is short-term
WebWebServerServer
Scrip
BrokerBrokerServerServer
WebWebBrowserBrowser
User Vendor
Broker
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 WN
• Hash it N times to form W0
WN WN-1
WN-1 = H(WN )
WN-2
WN-2 = H(WN-1 )
W0
W0 = H(W1 )
• • • W1
W1 = H(W2 )
• Vendor receives W0 to start
• Each payword is worth one unit
• When vendor receives W53 he verifies it by hashing
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
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:
U, AU, PKU, TU, $U
• Broker issues a subscription card
CU = { B, U, AU, PKU, E, IU } SKB
• Vendor will deliver goods only to AU
USERNAME
USERADDRESS
USERPUBLIC KEY
USERCERTIFICATE
COORDINATES OF BANKACCOUNT OR CC
BROKERNAME
EXPIRATIONDATE
USER INFORMATION(CARD #, CREDIT LIMIT)
BROKERPRIVATE KEY
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
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)
– 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 }
• User “commits” this chain to a vendor, sends
M = { V, CU, W0, D, IM } SKUVENDOR
NAME
EXPIRATIONDATE OF
COMMITMENT
EXTRA INFORMATION(VALUE OF CHAIN)
USERPRIVATE KEY
“FIRST”PAYWORD
EXPENSIVE: REQUIRESDIGITAL SIGNATURE
CAN EASILY COMPUTE THIS WAY
DIFFICULT TO COMPUNTE THIS WAY
M IS VENDORSPECIFIC ANDUSER-SPECIFIC
(NO USE TOANYONE ELSE)
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
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.
ELECTRONIC PAYMENT SYSTEMS 20-763
SPRING 2004
COPYRIGHT © 2004 MICHAEL I. SHAMOS
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
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
QA&