Module 9 Micropayment systems Properties of micropayment

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 obtains scrip from vendor Broker 1. Credit card # sent with macropayment protocol (e. g. SET) Customer 2. Bulk amount of broker scrip using Millicent protocol Vendor

Buying broker scrip Broker 1. Credit card # sent with macropayment protocol (e. g. SET) Customer 2. $5. 00 of broker scrip using Millicent protocol Vendor

New vendor Broker 1. $5. 00 Broker scrip 2. $0. 20 Vendor scrip $4. 80 Broker scrip Customer 3. $0. 20 Vendor scrip + request 4. $0. 19 Vendor scrip change + Purchased info/service Vendor

Use current change Broker Customer 1. $0. 19 Vendor scrip + request 2. $0. 15 Vendor scrip change + article (cost $0. 04) Vendor

Scrip certificate generation Vendor secret keys Master scrip secret 5 Master scrip secret 6 Master scrip secret 7 Used to determine which secret to include Vendor Value ID# Cust ID# Expiry Info Hash algorithm (e. g. , MD 5) “Certificate” To Customer Master scrip secret 6

Scrip certificate validation at time of purchase Used to determine which secret to include Vendor secret keys Master scrip secret 5 Master scrip secret 6 Master scrip secret 7 Value ID# Cust ID# Expiry Info Master scrip secret 6 Hash algorithm “Certificate” From Customer Compare “Certificate”

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#

Generating a Customer Secret Vendor symmetric keys Master customer secret 1 Master customer secret 2 Master customer secret 3 Value ID# Cust ID# Expiry Info Cust ID# Customer secret Hash (e. g. , MD 5) Master customer secret 2

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.

Generating a request signature scrip Customer secret Hash (e. g. , MD 5) Request Signature Request

Vendor verifies a request signature Customer secret scrip Request Signature Compare Hash Request Signature