MilliCent protocol: small-amount Internet payments

The payment systems that we have considered in the previous lecture can be thought of as digital analogs of checks (virtual PIN, CyberCash/CyberCoin, PayPal) and of cash (DigiCash). MilliCent protocol is a system for small amount payments which is similar to prepaid calling cards.

This is the official MilliCent web site, and this is the paper describing the details. You are responsible only for the material on this page, but you might want to use the links to understand the material better. Note that the material here skips over some of the details given in the paper.

Motivation for a system for small amount payments

Recently people get more and more of their everyday information on the Internet. One can easily imagine that instead of reading newspapers, more and more people will be reading their daily news on the Internet. Getting driving directions, bus and train schedules, weather reports, horoscopes, searching an archive of a mailing list are all online services that people use every day. Most of these services are free, but more and more web sites that provide such services try to collect money by making all or a part of their web site accessible for a membership fee. While they are making some money, this is not an ideal solution, because they are loosing customers who are interested in their services, but don't use them frequently enough to make it worth a membership fee.

A better way of making money on such services would have been to charge a customer on a service-per-service basis: every time the customer accesses a service, they pay a small fee. Such fees would be very small, possibly less than a cent for a one-time access to a service. However, there are reasons why such fees are very difficult to implement.

Many existing payment systems are linked to credit card accounts or bank accounts. However, credit card transactions require the merchant to pay fee. Even if a fee is a few cents, it makes transactions of amounts less than a dollar to be non-profitable for the merchant. A withdrawal from a checking account may result in a fee for a customer. It may also be cumbersome for the bank to process many small-amount transactions.

Another possible solution is to use digital coins, along the lines of DigiCash. However, the only way to check for double-spending of digital coins (whether blind, or not) is to check with the issuing bank. Such a verification takes time, which makes it inconvenient to use digital coins.

MilliCent protocol is a scheme for secure and convenient small-amount payments. "Small" means that each transaction is within $10 (and possibly as small as fractions of a cent).

Main ideas behind MilliCent protocol

There are three participants in the protocol: In this model there are many customers and vendors, but just a few brokers.

MilliCent money is called scrip. The main difference between MilliCent and other digital money protocol is that each vendor issues their own scrip, and a particular scrip token can be spent only at the vendor who has issued it. In this sense scrip is similar to a prepaid calling card.

A scrip token consists of the following information:

  1. Vendor: the name of the vendor who accepts the scrip.
  2. Value: the monetary value of the scrip token.
  3. ID number: a unique ID of the scrip token. All scrip tokens of the same vendor have different ID numbers.
  4. Customer ID: the ID of the customer.
  5. Expiration date: similarly to a prepaid calling card, scrip is valid only within a few months from the date of issue.
  6. Properties: any other information about the customer that the vendor needs, such as age (in case when some product may be sold only to those older than a certain age) or discount information (if a customer is eligible for a discount).
  7. Certificate: a "signature" which verifies the scrip.
Expiration date is used to prevent customers from accumulating large amounts of scrip and to make it easier for the vendor to check for double-spending (the less valid scrip there is, the shorter are the lists that the vendor has to check). If a scrip token is about to expire, the vendor or a broker can exchange it for a new one.

Issuing scrip

Scrip may be issued by a vendor or a broker. A broker has a contract with a vendor for issuing scrip. The broker "buys" the right to produce scrip for a certain amount, the vendor tells the broker the information needed to produce this scrip (i.e. the range of scrip ID numbers and the master secrets needed to compute the certificates for these ranges, see below). For the broker to make profit, the vendor sells the scrip to the broker at a discount, compared to the price of scrip for the customer.

A customer opens an account with a broker, deposits some money into this account, and gets an equivalent amount of broker's scrip. This transaction requires some means of payment other than MilliCent (with a credit card or another form of digital money) and means of encryption and authentication which are stronger than those used in MilliCent. Such transactions will be performed rarely, only when the customer first opens the account or moves money to the account.

The customer then uses broker's scrip to buy (as needed) scrip for the vendors that he/she uses.

We assume that a broker has contracts with many vendors and that many customers have accounts with the same broker.

Checking validity of scrip

The vendor or the broker who produces a scrip token creates a certificate for it. The certificate is computed as follows: the vendor has a table of master secrets: strings of digits known only to the vendor and to the broker (the broker might actually know only some of the master secrets). There is a simple procedure to choose a master secret in the table for each scrip ID number (for instance, one master secret may correspond to a range of scrip ID, such as all IDs greater than 10000, but less than 20000).

The certificate for a scrip token is computed as follows: the master secret is appended to the text of scrip (the text includes the vendor ID, the value, the ID number, the customer ID, the expiration date, and the properties). Then the certificate is the value of a hash function (such as MD5) of the result.

For instance, if the scrip text is x, the master secret for x is M, and the vendor uses MD5 as the hash function, then the certificate of x is MD5(x,M), where x,M is x followed by M. When a customer buys scrip, he/she gets x and the certificate of x. The customer does not know M, and therefore cannot change x without invalidating the certificate.

When the customer pays with scrip, he/she sends both x and the certificate of x to the vendor. The vendor checks the expiration date of the scrip, and if the scrip is still valid, recomputes the certificate (takes the master secret which corresponds to the scrip ID number, appends it to the scrip, and computes the value of the hash function). If the certificate matches to the one sent with the scrip, then the scrip is valid.

Even if the scrip token is valid, the vendor still needs to check if the scrip with this ID has not been spent yet. Since scrip is vendor-specific, it is easy for the vendor to check the list of spent scrip IDs. Scrip is not valid after its expiration date, so the vendor can discard records about scrip IDs that have expired.

Three protocols for using scrip

There are three protocols for making a purchase using scrip:
  1. Scrip in the clear. The customer sends a request for a product, a scrip token as a payment, and the certificate for the scrip. The merchant sends back the product (if any) and the change (another scrip token). All of this information is sent unencrypted.

    This protocol doesn't provide customer's privacy (all information is sent in the clear). It is also vulnerable to theft: the scrip token sent back as a change can be copied by an eavesdropper and used before the real owner spends the original scrip token. Then the original will not be accepted, since it will be considered to be double-spent.

  2. Private and secure. The next two protocols make use of a customer secret: a number which is different for each customer and is sent (securely) to the customer when their account is created. A customer secret can be recomputed by the vendor based on the customer's ID. This computation requires the knowledge of a master secret known only to the vendor (and possibly to the broker).

    The customer secret can be used as a key for symmetric encryption. In this protocol, the customer uses their customer ID to encrypt parts of the scrip which they would like to keep private (they cannot encrypt the customer ID, since it's needed for the vendor to determine the customer secret, i.e. the encryption key) and the request. The vendor computes the customer secret, decrypts the request and the encrypted parts of the scrip, and sends back the product and the change encrypted with the customer's secret.

    Symmetric encryption is used in this protocol to avoid long and expensive computations of public key cryptography.

  3. Secure without encryption. Even though the above protocol uses symmetric encryption, it still may be slower and more expensive than needed for the kinds of applications MilliCent is proposed for. This protocol uses customer secret (just as the protocol Private and secure), but instead of encryption, this secret is used for message verification:

    To make a purchase, the customer sends to the vendor three pieces of information: the request, the scrip (with the scrip certificate), and the request signature, which is computed by putting together the request, the scrip, and the customer secret, and computing the value of the hash function (such as MD5) of the resulting string.

    The vendor checks the customer's signature by performing the same computations as the customer did to compute the signature, and if the signature matches, then the merchant proceeds to verify the scrip as usual. If the scrip is valid, the product and the change are sent back in the clear, but since in this protocol every request requires a digital signature of the customer, an eavesdropper cannot create a valid request (even if they copy the scrip), since they don't know the customer's secret.

    The protocol doesn't provide customer's privacy (all requests and products are sent in the clear). However, it's faster and less expensive than the Private and secure protocol.


This page has been created and is maintained by Elena Machkasova
Comments and suggestions are welcome at emachkas@wellesley.edu

Spring Semester 2002