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.
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.
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.
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.
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.
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.
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.
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
The following notation is used Throughout this paper.
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.
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.
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.
A piece of information, such as a password, that is known only to one person or a limited number of people.
A random number that occurs only once and is used only once.
-T.A.
Comments:
file: /Techref/article/ddj/no292p58.htm, 20KB, , updated: 2015/5/8 16:50, local time: 2024/8/31 20:18,
3.16.203.107:LOG IN
|
©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://techref.massmind.org/Techref/article/ddj/no292p58.htm"> Protocols for E-Commerce</A> |
Did you find what you needed? |
Welcome to massmind.org! |
Ashley Roll has put together a really nice little unit here. Leave off the MAX232 and keep these handy for the few times you need true RS232! |
.