Chapter 11 Micropayment Systems

11.1 Introduction 11.2 Overview of Micropayment System 11.3 Millicent 11.4 PayWord

Introduction
Online Credit card payment involves substantial minimal fee per transaction not applicable for charging smaller amounts Difficulties: - delay - user involvement - potential for disputes (refunds, chargeback) - handling cost

Micropayment charging amounts smaller or close to the minimal credit card transaction fee Low value per transaction small profit high processing rate payment verification inexpensively Successful micropayment system not involve computationally expensive cryptographic techniques

Overview of Micropayment System

Operated by one or more payment service provider (PSP) receiving aggregated payment from customers passing to the merchants Payment protocol - payment approval (customer agrees to pay) - payment authorization (PSP) Payment approval and payment authorization integrated or separated The single PSP solution is simple and efficient but expect more PSPs to emerge as the demand grows and market matures Unrealistic all customer and merchants have accounts with multiple PSPs Micropayment system support interoperability among multiple PSPs

Overview of Micropayment System

Micropayments via a single PSP

Overview of Micropayment System

Payments via the PSP

Overview of Micropayment System

Micropayments via two interoperating PSPs

Millicent
A decentralized micropayment scheme allow payments as low as $0.001 to be made Efficiently validated at a vendors site Without any additional communication, expensive public key encryption or offline processing allow it to scale effectively for repeated small payments Uses a form of electronic currency scrip Scrip vendor-specific fast and efficient to verify - it is not of great concern if loses a small piece of change Using fast symmetric encryption the protocol can be both lightweight and secure

Millicent
The Millicent Model

Millicent
i. Broker (Financial Institutions / Network Service Providers) Aggregating micropayments Not efficient customer buys vendor scrip from every vendor Customer will make enough micropayments in total at different vendors to cover the cost of a macropayment transaction Broker provides all the different vendor scrip needs of a customer in return for a single macropayment sell vendor scrip to customers The aggregation of different vendor scrips justifies a macropayment transaction to purchase these pieces of scrip

Millicent
i. Broker (Financial Institutions / Network Service Providers) Replacing subscription services Vendor maintains account information for customers who have paid to use the service for a set length of time Customers have to maintain account information for each different vendor Broker frees both the customer and vendor replacing a subscription service with a pay-per-access micropayment system

Millicent
i. Broker (Financial Institutions / Network Service Providers) Selling vendor scrip Brokers handle the real money in the Millicent system maintain accounts of customers and vendors. Have an agreement with each vendor whose scrip the broker sells Two ways in which a broker gets the vendor scrip: 1. Scrip warehouse (buy and store) 2. Licensed scrip production (generate) Efficient: - doesnt need to store a large number of scrip pieces - vendor does less computation doesnt have to generate - license smaller to transmit

Millicent
ii. Vendors Merchants selling low-value services or information Accept his or her own vendor scrip validate it locally prevent any double spending Sell scrip at discount or scrip-producing license profit for brokers

Millicent
iii. Customers Buy broker scrip with real money from their chosen broker Broker scrip has value at that broker only A macropayment scheme (SET or E-Cash) could be used to buy the broker scrip Using broker scrip - customer buys vendor scrip for specific vendors used to make purchases

Millicent
Purchasing with Millicent Buying broker scrip

Millicent
Purchasing with Millicent Purchasing from a vendor

Millicent
Purchasing with Millicent Further purchases from the same vendor

Millicent
Scrip Properties: Represents a prepaid value Represents any denomination of currency The security is based on the assumption Vendor-specific Can be spent only once Can be spent only by its owner Cannot be tampered with or its value changed Computationally expensive to counterfeit scrip Make no use of public key cryptography Cannot provide full anonymity

Millicent
Scrip Structure:

Millicent
Scrip Certification Generation

Millicent
Validating scrip at the time of purchase

10

Millicent
To prevent double spending - vendor checks the ID# has not already been spent Maintains bit vectors corresponding to the issued serial number (ID#s) to keep track of spent scrip Vendor discards the fully spent or expired vector keep valid scrip ID# speed up transactions Computation costs:
Recalculate certificate one hash function Prevent double spending one local ID# database lookup Making purchase across network one network connection

Different levels of efficiency, security and privacy sending scrip over a network

Millicent
Three main Millicent protocols:
1. Scrip in the clear 2. Encrypted network connection 3. Request signatures

1. Scrip in the clear Sending and receiving the purchase content and change in the clear No network security interception might be occurred

11

Millicent
2. Encrypted network connection Purchase using encrypted network connection

Millicent
2. Encrypted network connection Generating a customer_secret

12

Millicent
2. Encrypted network connection Buying vendor scrip

Millicent
3. Request signatures Generating a request signature

13

Millicent
3. Request signatures Purchase using a request signature

Millicent
3. Request signatures Vendor verifies the request signature

14

Millicent
Characteristics of the Three Millicent Protocols

Millicent
Application
1. 2. 3. 4. 5. 6. 7. 8.

Paying for information content Database searching Access to a service Authentication to distributed services Metering usage Usage-based charges Discount coupons Preventing subscription sharing

15

Millicent
Drawbacks
1.

Both broker and vendor must be trusted to issue the correct change no way to prove that change scrip is owned The user cannot independently verify the validity of a piece of scrip since the user cannot regenerate the scrip certificate

2.

PayWord
Credit-based micropayment scheme Reduce the number of public-key operation uses hash functions and symmetric key cryptography faster Uses chains of hash value to represent user credit Each hash value (PayWord) can be sent to a merchant as payment PayWord chain vendor-specific user digitally signs a commitment to honor payment for that chain Brokers maintain account for users and vendors not necessary for both a vendor and user to have an account at the same broker Need some assurance that users will honor their PayWord payment since PayWord is a credit-based scheme

16

PayWord
PayWord certificate authorizes a user to generate PayWord chains guarantees that a specific broker will redeem them Broker and vendors do not need PayWord certificates Users obtain a certificate when they initially setup an account with a broker Certificate have to be renewed every month limits fraud and ensuring that users who have overdrawn account will not be issued with a new certificate

PayWord
Obtaining a PayWord user certificate

17

PayWord
Since identified certificates with a user identifier and address are used no anonymity is provided Broker might maintain blacklists of certificates that have been revoked if secret key was lost or stolen avoid others to generate PayWord chains under their name Vendor has responsible to obtain any revoked certificate list from a broker

PayWord
PayWord Chains
Represent user credit at a specific vendor Is a chain of hash value Each PayWord (hash value) in the chain has the same value (1 cent)

18

PayWord
Generating a PayWord chain

PayWord
PayWord Chains
Vendor and broker need to know to whom the spent PayWords belong users account can be charged The user is authenticated by signing a commitment authorize the broker to redeem allows the vendor to be confident that he will be paid A commitment to a PayWord chain has the form: Comm = {V, CU, W0, E, ICOMM} SKU

19

PayWord
Paying a vendor with PayWords

PayWord
Verifying the first PayWord

20

PayWord
Verifying further payments

PayWord
Reclaiming PayWords with a broker

21

PayWord
Hash functions are computationally cheap Broker could perform certificate generation and PayWord redemption offline efficiency Payment verification requires only one hash computation vendor need only store the highest payment hash received PayWord is most efficient for repeated micropayments to a specific vendor Minimizes communication costs

broker does not have to be contacted for a new vendor payment need not change and return the unused vendor-specific scrip to the broker (unlike Millicent system)

Provides more opportunity for user fraud if a users secret key is compromised

22