Module 9 Micropayment systems

Properties of micropayment systems

• Micropayments do not have a real-world cash equivalent – cash cannot be divided into units smaller than the lowest valued coin (penny, for example)

• A micropayment can be as small as a tenth or hundredth of a cent

• Typically, a subscription model is used to allow clients to prepay on an account, then use up the prepaid value over a period of time. Micropayment systems permit pay-per-use business models for electronic content.

• The overhead associated with processing micropayments must be miniscule

• For low overhead, asymmetric cryptography is out

Millicent

• Decentralized micropayment scheme• Involves brokers, customers, and vendors• Each vendor accepts vendor-specific scrip• Customers purchase broker scrip in bulk, then

exchange it with the broker for vendor-specific scrip as needed

• Brokers buy vendor-specific scrip in bulk, or are licensed by the vendor to produce the scrip.

• Vendors have low-value services or information. Vendors only accept their own type of scrip, and maintain a database of spent scrip ID numbers to prevent double spending.

Broker

Customer Vendor

1. Credit card # sent with macropayment protocol (e.g. SET)

2. Bulk amount of broker scrip using Millicent protocol

Broker obtains scrip from vendor

Broker

Customer Vendor

1. Credit card # sent with macropayment protocol (e.g. SET)

2. $5.00 of broker scrip using Millicent protocol

Buying broker scrip

Broker

Customer Vendor

1. $5.00 Broker scrip

2. $0.20 Vendor scrip $4.80 Broker scrip

New vendor

3. $0.20 Vendor scrip + request

4. $0.19 Vendor scrip change+ Purchased info/service

Broker

Customer Vendor

Use current change

1. $0.19 Vendor scrip + request

2. $0.15 Vendor scrip change+ article (cost $0.04)

Master scrip secret 5

Master scrip secret 7

Master scrip secret 6

Master scrip secret 6

“Certificate”

InfoVendor Value ID# Cust ID# Expiry

Used to determine which secret to

include

Hash algorithm (e.g., MD5)

To Customer

Vendor secret keysScrip certificate generation

Master scrip secret 5

Master scrip secret 7

Master scrip secret 6

Master scrip secret 6

“Certificate”

InfoVendor Value ID# Cust ID# Expiry

Used to determine which secret to

include

Hash algorithm

From Customer

“Certificate”Compare

Vendor secret keysScrip certificate validation at time of purchase

Sending scrip over a network

• In the clear– Scrip is sent in the clear from the customer to the vendor– The change and the content purchased is returned in the

clear– An attacker could intercept either message, and steal the

scrip or the change (the scrip is only valid at one vendor)

• Over an encrypted network connection– Uses symmetric encryption – requires that a secret be

shared using some other mechanism outside the scope of Millicent

– Vendor ID# and Customer ID# are sent in the clear, and the scrip and request are encrypted using the Customer Secret

– The Customer Secret is generated by hashing the Customer ID# concatenated with the master customer secret associated with that Customer ID#

Master customer secret 1

Master customersecret 3

Master customersecret 2

Master customer secret 2

Customer secret

InfoVendor Value ID# Cust ID# Expiry

Hash (e.g., MD5)

Vendor symmetric keysGenerating a Customer Secret

Cust ID#

Request Signatures

• To protect scrip from being stolen without incurring the overhead of encryption, privacy can be sacrificed while the scrip is still protected from thieves using request signatures.

• This scheme uses the same customer secret as the encryption scheme, but the customer secret is hashed with the scrip and request to produce a digest instead of encrypting the message

• The customer secret is a shared secret between the customer and the vendor, so only the customer can spend the scrip.

Customer secret

Request Signature

Hash (e.g., MD5)

scrip Request

Generating a request signature

Customer secret

Request Signature

Hash

scrip Request

Vendor verifies a request signature

Request Signature

Compare