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.
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).
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:
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.
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.
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.
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.
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.