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 CustomerVendor 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 CustomerVendor 1. Credit card # sent with macropayment protocol (e.g. SET) 2. $5.00 of broker scrip using Millicent protocol Buying broker scrip

Broker CustomerVendor 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 CustomerVendor 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 “Certificate” InfoVendorValueID#Cust ID#Expiry Used to determine which secret to include Hash algorithm (e.g., MD5) To Customer Vendor secret keys Scrip certificate generation

Master scrip secret 5 Master scrip secret 7 Master scrip secret 6 “Certificate” InfoVendorValueID#Cust ID#Expiry Used to determine which secret to include Hash algorithm From Customer “Certificate” Compare Vendor secret keys Scrip 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 customer secret 3 Master customer secret 2 Master customer secret 2 Customer secret InfoVendorValueID#Cust ID#Expiry Hash (e.g., MD5) Vendor symmetric keys Generating 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) scripRequest Generating a request signature

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