Protocols for E-Commerce

Dr. Dobb's Journal December 1998

Paving the way for electronic business

By Taimur Aslam

We are accustomed to conducting business transactions using cash and credit cards, but these do not match the requirements of online services. Electronic transaction systems must be secure, have low overhead, and may need to protect user privacy.

The financial and technological community has created several payment models and protocols to address these issues. In this article, I'll discuss four different ecommerce techniques. Each was chosen to be representative of a class of transaction and payment models. For instance, iKP provides a model for secure credit card transactions, Millicent exemplifies a method for micropayments, and Netcash and Digicash present a model for anonymous transactions.

iKP

The iKP protocols were designed at IBM-Zürich to provide secure credit card payments over an insecure network like the Internet. These protocols use the existing credit card infrastructure for clearing financial transactions. iKP formed the basis of the Secure Electronic Payment Protocol (SEPP), which was endorsed by Visa for secure credit payments. Ideas from SEPP and Secure Transaction Technology (STT) formed the basis for the Secure Electronic Transaction (SET) system developed by Visa and Mastercard. The SET protocol is emerging as the next-generation standard for smart cards and credit card payments.

The 1KP, 2KP, and 3KP protocols (together known as "iKP") use a trust model with five parties. The first of these is the Certification Authority (CA). The certification authority is a trusted entity who holds a public and secret key pair (PKCA, SKCA) and can sign other peoples' public keys as "(X, PKX)SKCA." For more information, see the accompanying text box entitled "Cryptographic Basics."

The acquirer (A) is a financial institution like a credit card company responsible for clearing and handling financial requests. The acquirer holds a public and secret key pair (PKA, SKA) in all iKP protocols and all merchants know PKA.

The issuer (usually a bank) is responsible for issuing credit cards to customers. The issuer receives transaction records from the acquirer to clear the transactions. The issuer and acquirer trust each other, and a secure infrastructure is in place between them.

The last two parties in iKP are the merchant (M) who provides goods or services and the customer (C) who purchases those goods and holds a valid credit or debit card from the issuer. In 2KP, merchants have their own signed key; in 3KP, merchants and customers each have signed keys.

The iKP protocols were designed to meet several requirements. The acquirer must have unforgetable proof that the payment was requested by a given merchant and authorized by the owner of the credit card. The merchant needs unforgeable proof that the customer has requested payment and the acquirer has authorized the payment. The customer needs unforgetable proof that the merchant is accredited by the acquirer, the acquirer has authorized the transaction, and the merchant has received payment. It must no be possible to charge something without proper approval from the customer.

Before the protocol starts, each entity already possesses certain information: The customer knows the certification authority's public key {PKCA}, the acquirer holds a signed public key and a secret key {CERTA, SKA}, and the merchant knows the acquirer's public key and has a certificate from the certification authority {CERTA} that attests to the validity of that key.

The protocol begins after the customer has chosen particular goods and has agreed on a price with the merchant.

1. The customer generates two random numbers {R0, SALT0} and forms a customer ID=H(R0, customer account number), where the customer account number is information that identifies a customer (such as a credit card number). The customer sends SALT0, customer ID, and any optional information to the merchant. This completes the initiate phase.
2. The merchant uses a timestamp (DATE) and a nonce, NONCEM, to unambiguously identify this transaction. The merchant then chooses a transaction ID (merchant's transaction ID), computes H(transaction description, SALT0), constructs Common={price, merchant's ID, merchant's transaction ID, DATE, NONCEM, customer ID, H(transaction description, SALT0)}, and computes H(Common). The merchant sends {H(Common), merchant's ID, merchant's transaction ID, DATE, NONCEM} to the customer, thus completing the invoice stage of iKP.
3. Upon receiving the invoice from the merchant, the customer begins the payment mechanism. He forms CLEAR as: {merchant's ID, merchant's transaction ID, DATE, NONCEM, H(Common)}; recomputes H(Common), and compares it to the value sent by the merchant. The customer then creates SLIP={price, H(Common), customer account number, RC}, encrypts it using the acquirer's public key as (SLIP)PKA, and sends it to the merchant.
4. The merchant sends an authorization request to the acquirer and forwards (SLIP)PKA, CLEAR, and H(transaction description, SALT0) to the acquirer.
5. The acquirer decrypts SLIP and compares H(Common) in SLIP to H(Common) in CLEAR. The acquirer also reforms Common, computes H(Common), and compares this to the other two H(Common) values. Finally, it submits an authorization request to an existing infrastructure such as a credit card issuer. On receiving a yes/no response, it encrypts the response and H(Common) with the acquirer's secret key, and sends the encrypted response to the merchant.
6. On receiving the signature from the acquirer, the merchant decrypts the received message using the acquirer's public key, retrieves the acquirer's response, and checks for a valid acquirer signature. It then forwards the response to the customer along with the acquirer's signature. This completes the confirm phase of the protocol.

Millicent

Millicent was designed by Digital Equipment's Systems Research Center at Palo Alto, California, to provide a mechanism for secure micropayments. Typical electronic transactions amount to a few dollars, but for transactions that cost a few cents or a fraction of a cent, the cost of the protocol outweighs the cost of the transaction. Millicent addresses this problem by providing lightweight secure transactions that are suitable for micropayment transactions.

The trust model in Millicent defines three roles -- vendors, customers, and brokers. Brokers act as intermediaries between vendors and customers. A customer enters into a long-term relationship to buy digital money (scrip) from brokers, who are assumed to be large entities such as banks or credit card issuers. Brokers are most trusted in this model; customers are least trusted.

Millicent's security model requires that all transactions be protected and that fraud be detectable and traceable. However, fraud is not considered a major concern because Millicent is used for inexpensive transactions.

In Millicent, digital money is represented by scrip. Like cash, scrip has a defined value and can be used to purchase merchandise. However, scrip differs from typical cash in several respects. It has value only at a specific vendor, and can only be spent by the customer who obtained it from the broker. Each scrip is uniquely identified by a serial number and can only be spent once. Furthermore, scrip contains an expiration date and a digital signature that attests to its value and authenticity.

There are three secrets involved in producing, validating, and spending scrip. The customer is sent a customer_secret to prove ownership of the scrip he holds. The vendor uses the master_customer_scrip to derive the customer_secret from the customer's information sent to him. The third secret is the master_scrip_secret, which is used by vendors to prevent tampering and counterfeiting of digital money.

The following terminology is defined in Millicent.

• id_material={vendor_id, {master_scrip_secretid , id_sequence},{master_customer_secret,customer_id_sequence}}.
• cert_material={properties, value, expiration_date}.
• scrip_body={id_material, cert_material}.
• cert=H(scrip_body, master_scrip_secret).
• scrip={scrip_body, cert}.
• SessionId is a string that contains N (a session number), and is unique to the session. The vendor computes secret X(N) and keeps it as long as the session lasts. The session key k is H(SessionId # X(N)), where "#" denotes concatenation.

The information that flows between a vendor and a customer is denoted as Info. Both parties can choose to encrypt all or portions of Info using k, the session key.

Coins for scrip are minted as follows. A Coin consists of a serial number and a string that denotes its value. A signature that attests to the value of the string is computed as: H(SessionID # Info # Coin # X(N)). Coins minted by a broker should have the property that X(N)=X(Z) if and only if N=Z.

In the following transaction scenarios, assume that a customer already has established an account with a broker, and purchased scrip.

Insecure Transactions

1. A customer sends scrip along with a transaction request to a vendor. Upon receiving the scrip, the vendor computes the certificate as: H(scrip_body, master_scrip_secret) and compares it to the certificate of the scrip. Any mismatch will indicate that the scrip has been tampered with, and the vendor can refuse to honor it. The vendor then checks for double spending by searching his database for the scrip's serial number. If the number is not found, the transaction is approved and the vendor records the scrip's serial number in his database to prevent customers from double spending in the future.

2. During the second phase of the transaction, the vendor returns a brand new scrip to the customer. The new scrip has a value that is the difference of the original and the cost of the transaction. The new scrip, however, contains the same customer_id. Along with the new scrip, a response is also sent to the customer and may optionally be signed by the vendor to prove authenticity.

Authentic and Private

1. The customer sends {vendor_id, customer_id, (scrip, request)customer_secret} to the vendor. The scrip and request are encrypted using the customer_secret. The vendor calculates the customer_secret using the customer_id, and performs all the steps described in the first step of the insecure transaction.
2. The vendor returns {vendor_id, customer_id, (scrip', cert, reply)customer_secret} to the customer. The returned scrip' is a brand new scrip and contains the new value of the scrip. Upon receipt of the vendor's response, the customer can retrieve scrip', cert, and reply using customer_secret.

Authentic Only

1. The customer sends {scrip, request, H(scrip, request, customer_secret)} to a vendor. The message is sent in clear, but is protected by the customer_secret in the hash function. Upon receiving the request, the vendor calculates the hash function using a preselected message digest function. Other actions are similar to the first step of the insecure version.
2. The vendor returns {scrip', reply, H(scrip', cert, reply, customer_secret)}. Upon receiving this information, the customer can compute the message digest to ensure authenticity.

Digicash

Digicash is unique in its implementation of electronic cash because it has attempted to preserve the anonymity and untraceability associated with cash transactions. At the heart of the anonymous transaction scheme is the idea of blind signatures.

The Digicash protocol requires two new components: A representative is a smart-card size computer containing memory and microprocessor. It can communicate with the outside world via card readers or terminals and is enclosed in a tamper-resistant package. An observer is issued by a certified authority that certifies the behavior of the representative in which it is embedded.

After a user acquires an observer, he places it in his smart-card representative and gets it validated by a trusted authority. The observer then generates a pair of public and private keys, blinds them by a random factor, and signs the result with a special secret key. The blinded keys and the signature are sent to the trusted authority who then signs the blinded keys. These signed keys serve as the user's pseudonym for future transactions.

The Digicash protocol is based on the interaction of the observer and representatives.

Suppose customer A wants to pay for some goods bought from B. Customer A withdraws money from a bank by connecting his representative to the bank's terminal. The observer witnesses this transaction and records which notes were withdrawn.

To spend the money, A sends the bank notes and his pseudonyms to B. The bank notes are signed by A's observer using a secret key which states that these notes will only be spent at B's shop at a particular time and date. This prevents A from double spending because the observer is programmed to sign any given note only once.

In addition to being used for financial transactions, observers and representatives can also be used for user authentication, proof of credentials, and other purposes.

Netcash

The Netcash protocol can also support anonymous transactions. Electronic currency in Netcash is denoted by coins that can be purchased using paper money or check.

The Netcash protocol assumes the existence of currency servers that can mint coins, and a Federal Insurance Corporation (FIC) that authenticates those servers. The currency servers also check for double spending, exchange of coins among customers, and exchange of electronic coins for physical cash.

When a server is commissioned, it must register with an FIC and get an insurance certificate to produce and manage electronic currency. To register, the server creates a pair of public and secret keys denoted by PKCS and SKCS, respectively. It sends the public key to an FIC, which returns a certificate of insurance encrypted under the FIC's secret key as: {Certificate_Id, CS_name, PKCS, issue_date, expiration_date}SKFIC. The currency server can now mint coins as: {CS_name, server_Internet_address, expiry_date, serial_number, coin_value} SKCS, Certificate_Id.

A customer buys coins by sending {payment/check, secret_key, transaction} PKCS. The currency server returns the coins in the amount enclosed as {coins} secret_key. The customer can now proceed to make payments in the Netcash protocol. To preserve the anonymity of a customer and to prevent vendors from cheating, coins can be customized so that they can only be used by a particular individual during a given period of time. For instance, a principal A can obtain a coin tuple <CB, CA, CX>, where CB and CA are intended for B and A, respectively, while CX is a generic coin that can be spent at any location. Coin CB contains B's encrypted public key, and B must provide his secret key SKB before he can use it.

The Netcash protocol facilitates anonymity, prevents double spending, and keeps vendors from cheating.

1. Suppose that customer A, wants to trade with B. To obtain the currency, A sends {coins, Secret_key1, public key of B, expiration dateB, dateA, amount} PKCS to the currency server. In this transaction, dateB and dateA denote A's and B's windows of operation.
2. The currency server mints a triple <CB, CA, CX> as described earlier and sends {<CB, CA, CX>, , CX>} Secret_key. In this transaction, <,, CX> denotes the change returned.
3. To purchase goods from B, customer A sends {CB, secret_key2, session_key, service_required} PKB. B keeps track of the coin CB until it expires to prevent A from double spending it. This also prevents B from cheating, and if B did not issue a receipt, A can query the currency server to find whether B spent the coin. If B did spend the coin, the currency server will issue a receipt and return B's public key. Otherwise, A can request a refund for the amount of CB before CA's expiration because CA was minted to be used by A.
4. Finally, B returns {{amount, transaction id, date} SKB} secret_key2, and the transaction is complete.

Conclusion

iKP provides secure transactions for credit card payments using the existing financial infrastructure for approvals and clearing. Millicent is a lightweight protocol suitable for micropayments. Netcash provides a real-time electronic payment scheme with provisions for secure anonymous exchanges over an insecure network. Digicash provides anonymous transactions using smart cards and blind signatures.

As the Internet continues to become more popular, e-commerce techniques will evolve to meet the challenges of online financial transactions. It is not yet clear whether a particular payment model will emerge as a de facto standard. It is quite likely that multiple standards will continue to coexist much as the different paper currencies coexist. However, as electronic commerce gains popularity, some potential challenges will have to be addressed. Prevention of money laundering and fraud is still an open issue, despite the security mechanisms of the protocols. The authentication infrastructure will have to be put in place to prevent fraudulent activities and boost consumer confidence. It is also not clear if and how online transactions can be taxed, since there are no geographical boundaries on the Internet.

References

Ballare, M. et al. iKP: A Family of Secure Electronic Payment Protocols. http://www .zurich.ibm.com/technology/security/extern/ecommerce/ikp_references.html.

Chaum, David. "Achieving Electronic Privacy." Scientific American, August 1992.

Glassman, Steve et al. "The Millicent Protocol for Inexpensive Electronic Commerce." World Wide Web Journal, 4th WWW Conference Proceedings, p 603-618, December 1995. http://www.research.digital.com/SRC/staff/msm/bib.html.

Manasse, Mark S. The Millicent Protocols for Electronic Commerce. http://www .millicent.org/html/papers/mcentny.htm.

Medvinsky, G., and B.C. Neuman. "Netcash: A Design for Practical Electronic Currency on the Internet." Proceedings of the First ACM Conference on Computer and Communications Security. ACM Press, 1993.

Schneier, Bruce. Applied Cryptography. Second Edition. John Wiley & Sons, 1996.

DDJ