electronic payment systems 20-763 spring 2004 copyright © 2004 michael i. shamos electronic payment...

ELECTRONIC PAYMENT SYSTEMS 20-763

SPRING 2004

COPYRIGHT © 2004 MICHAEL I. SHAMOS

Electronic Payment Systems20-763

Lecture 9: Micropayments I


SPRING 2004


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


SPRING 2004


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)


SPRING 2004


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


SPRING 2004


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)


SPRING 2004


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


SPRING 2004


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


SPRING 2004


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)


SPRING 2004


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)


SPRING 2004


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


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 KZD

• Merchant requests payment from bank (later)– sends encrypted proofs of payment to bank

– TNo prevents more than one credit per transaction


SPRING 2004


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


SPRING 2004


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


SPRING 2004


GeldKarte Internet Payment

• Wireless potential

“Caroline” TrustedWallet Device

GeldKarte ReaderUSB or InfraredConnection to PC

CASHMOUSE


SPRING 2004


Other Electronic Purses

CYBERFLEX JAVA CARD

PRISMERA

QIANFLEX (CHINA)

PEOPLE’S BANK OF CHINA ePURSE

DANMØNT

AUSTRIAN QUICK


SPRING 2004


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


SPRING 2004


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


SPRING 2004


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


SPRING 2004


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


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


SPRING 2004


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


SPRING 2004


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


SPRING 2004


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)


SPRING 2004


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.


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, 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


SPRING 2004


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


SPRING 2004


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


SPRING 2004


QA&

electronic payment systems 20-763 spring 2004 copyright © 2004 michael i. shamos electronic payment...

Documents

merchant terminal card

electronic moves

shamos electronic purse

pcmcia card merchant

usd252 card

card clearance

gambling slide

party slide