Protocols for E-Commerce

Paving the way for electronic business

                                                by Taimur Aslam, Dr. Dobb's Journal, Dec. 1998

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 e-commerce 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 micro-payments, and Netcash and Digicash prsent a model for anonymous transactions.

iKP

The iKP protocols were designed at IBM-Zurich to provide secure credit card payments over an insecure network line the Internet. These protocols use the existing credit card infrastructure for clearing financial institutions. iKP formed the basis of the Secure Electronic Payment Protocol (SEPP), which was endorsed by Visa for secure credit card payments. Ideas from SEPP and Secure Transaction Technology (STT) formed the basis fir 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 issueing 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 and 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 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 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 {RO, SALTO} and forms a customer ID=H(RO, customer account number), where the customer account number), where the customer account number is information that identifies a customer (such as a credit card number). The customer sends SALTO, 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, SALTO), constructs Common={price, merchant's ID, merchant's transaction ID, DATE, NONCEM, customer ID, H(transaction description, SALTO)}, and computes H(Common). The merchant sends {H(Common), merchant's ID, merchant's transcation 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, SALTO) 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. Finallly, it submits an authorization request to an existing infrastructure such as a credit card issuer. On receiving a yes/no responce, it encrypts the responce and H(Common) with the acquirer's secret key, and sends the encrypted responce 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 responce, and checks for a valid 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 intermedaires 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 hr 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 provent tampering and counterfeiting of digital money.

The following terminology is defined in Millicent.

• id_material={vendor_id,{master_scrip_secreted, id_sequence},{master_customer_secret, customer_id_sequencel}}.
• 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 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 is computed as: H(SessionID # Info # Coin # X(N)). Coins minted by the 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 a 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 mis-match 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. 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 srve 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_lnternet_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 on-line 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 Securev 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. TheMillicent 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

Dr. Dobb's Journal, December 1998

Cryptographic Basics

The following notation is used Throughout this paper.

• Secret key for X=SKX.
• Public key for X=PKX.
• (M)PKX=Message M is encrypted using X's public key.
• (M)SKX=Message M s encrypted using X's secret key.
• H(M)=Message digest of M.

Message Digest

Message digest hash functions produce a fixed-length output regardless of the size of the input. The probability of collision in the output space is very small.

Public Key Cryptography

Also known as "asymmetric encryption," this class of encryption algoriths requires that every user has a secret key and public key in his/her possession. The public keys are advertised, and anyone can retrieve them. If Alice wants to send a secret message to Bob, she encrypts the message using Bob's public key. Upon receiving the message, Bob can decrypt the message using his secret key. As only Bob knows his secret key, it will be difficult for an eavesdropper to decipher the message.

Digital Signature

To sign a message, Alice computes a one way hash function of the message, encrypts it with her secret key, and sends it with the plain text message. When Bob receives the message, he decrypts the signed message using Alice's public key, computes a hash output, and compares it to the plain text message. Any mismatch indicates that the plain text message has been tampered with.

Secret

A piece of information, such as a password, that is known only to one person or a limited number of people.

Nonce

A random number that occurs only once and is used only once.

-T.A.

Comments:

• this was good but kinda confusing+

  .