1   MOTIVATION FOR ELECTRONIC PAYMENT

 

1.1 Evolution of Money and Payment Systems

Each stage of money came into existence in order to cater to certain needs during transaction. Each came not only with their advantages but also with limitations and drawbacks. As societies developed and became more complex, a way around these problems was needed, which led to the further evolution. Here we try to show the electronic payment system as a logical extension of the same evolutionary process.
   

The earliest human societies did not need money. Instead, goods were bartered or swapped. In other words, if you grew some corn, but wanted a new shear, you could exchange some of your corn for a new shear from the blacksmith. You would have to haggle over the value of the shear to you, as would the blacksmith. Bartering is primitive, but it only works if both parties want the goods on offer for exchange. What if the blacksmith didn't want your corn, but your cow? Could you afford to lose the animal? What if you needed the shear now but couldn't part with the corn or the cow until the next summer?

The oldest written records of money are from Ancient Mesopotamia (now in southern Iraq) about 4,500 years ago. About 3,500 years ago tiny Cowrie shells from the Indian Ocean were used in China as a means of exchange. Even the Chinese symbols for buying, bartering and selling incorporate the symbol for the Cowrie shell. The shells were still being used as currency in parts of Africa as late as the 19th Century. Ancient Mesopotamian inscriptions describe payments being made with weighed amounts of silver. Since then, weighed amounts of metal have been used as money in many parts of the world, and this practice led to the invention of coins. Then came intrinsic value need not be equal to the face value. Coins are just pieces of metal marked with a special design that indicates its use as money. Unlike precious metals, however, coins do not need to have any value in themselves. They only represent value. True coinage developed in Asia Minor during the 7th century BC in what is now Turkey. Weighed lumps of ‘electrum’ (a mixture of gold and silver) were used by the Lydians as money, and were stamped with pictures, a practice known as minting, as a guarantee of their purity. These irregular lumps were eventually standardized in shape and weight. The same idea was developed elsewhere to standardize other forms of metal money: copper lumps in southern USSR and Italy, bronze tools and shells in China, silver rings in Thailand, and gold and silver bars in Japan.  As soon as coins were commonplace, however, people realised their limitations - chiefly their weight and bulk, and a new type of money was needed which made larger transactions easier.
 

During the 10th century, the Chinese started to leave their heavy iron coins with merchants and to use hand written receipts instead. The government, who issued the coins, adopted this idea in the early 11th century, when receipts were printed which were given fixed values. This practice evolved and spread, with gold and silver being deposited in exchange for receipts (often with Goldsmiths), as well as coins. The goldsmiths profited from the gold and silver by charging interest on new loans, and eventually Banks emerged which assured the value of their notes and people no longer exchanged them for the original cash deposit. The notes became currency.

The first official printed notes were issued in 1661 - by the Swedish Stockholm Bank. The exchanges of notes for coins and precious metal took place on benches, hence the term "Bank", from "banco" - the Italian for bench.

Forgery, and the frequency of issuers going out of business, led to governments often taking over the issue of notes and coins, storing the gold or silver reserves to back them up in places such as the Tower of London, in England. Even banknotes had their limits. Although you may have money in the bank, to get to it requires your having banknotes to hand. This is expensive (money has to be printed and circulated), as well as risky (the money could be stolen or forged). Banks sought a way of exchanging their customers money without the medium of notes. Cheques, printed by Banks, allowed their customers to write "exchange" notes to their other customers, or customers of other banks. Money could then change hands without involving any notes or coins.

1.2 Characteristics Of Current Payment Systems

Over the past twenty years, with the advent of computers, the majority of money has come to be stored as bits and bytes in Bank computers, and exchanged digitally - through telephone or satellite links - rather than physically. Today, the majority of the world's cash does not exist in notes and coins at all. Plastic cards holding personal data on magnetic strips were developed to give people access to their money stored electronically. Cheque, debit and credit cards now enable nearly every kind of payment, through the users' bank account. As with every other stage in the evolution of money, however, even these cards have their limitations. For example, the cost of using them means that coins and notes are still the most suitable means of making small payments. Cards also have to be signed for when used, slowing down the transaction process when compared to cash. Money is now evolving to the next stage - the creation of electronic cash, such as Mondex, as an alternative to notes and coins.

Despite the popularity of credit and debit cards, the vast majority of all transactions worldwide are still carried out with cash. Cash remains the only universally acceptable form of payment - even when a retailer doesn't accept a particular credit card, cash will be taken. When it is, the exchange of value is immediate. No clearing or processing is needed, no signatures and no electronic transfers. Smart cards have been used as cash substitutes for a decade, in phone cards, vending cards and transit cards. However, the value stored on these cards has already been paid, and cannot usually be exchanged for other goods and services. A true cash alternative, replicating the core features of notes and coins, would have to be universally recognised and acceptable. Like cash, transactions would have to offer immediate transfers of value. Finally, like hard cash, electronic cash has to enable easy person to person payments. Electronic cash also has to be able to work in different currencies. And it would have to be secure from forgery.
 

1.3 Emergence of the Internet

Internet has till date growth achieved through the sharing and transferring of information. It is now a backbone connecting 20 million people - still growing @ 10% a month and is the first broadcast advertising  medium which is also a point of sale. The Internet is in the makings of  the ultimate marketplace - it has the potential to catalyze sale of goods & services , but is surprisingly without a medium of exchange of it’s own. The present conventional instruments present bottlenecks in clearing and  settlement of funds to be transferred. Hence newer electronic payment systems compatible with the Internet are a need of the hour.
 

1.4  Desirable features of an Electronic Payment System

An electronic payment system designed for the future should be :

1. Secure
· ensure positive identity of customer
· safeguard against breaches of personal privacy
· data not altered as it is sent

2. Scaleable
· number of users rapidly rising

3. Allow anonymity
· untraceable i.e. who spends - how much -where

4. Incur low transaction costs

5. Compatible and interchangeable

6. Reliable and accurate accountability
 
 

2  INTRODUCTION TO CRYPTOGRAPHY

 

2.1 Preface

People mean different things when they talk about cryptography. Children play with toy ciphers and secret languages. However, these have nothing to do with real security and strong encryption. Strong encryption is the kind of encryption that can be used to protect information of real value against organized criminals, multinational corporations, and major governments. Strong encryption used to be only military business; however, in the information society it has become one of the central tools for maintaining privacy and confidentiality.

As we move into an information society, the technological means for global surveillance of millions of individual people are becoming available to major governments. Cryptography has become one of the main tools for privacy, trust, access control, electronic payments, corporate security, and countless other fields.  Cryptography is no longer a military thing that should not be messed with. It is time to demystify cryptography and make full use of the advantages it provides for the modern society. Widespread cryptography is also one of the few defenses people have against suddenly finding themselves in a totalitarian surveillance society that can monitor and control everything they do.
 

2.2 Basic Terminology

Suppose that someone wants to send a message to a receiver, and wants to be sure that no-one else can read the message. However, there is the possibility that someone else opens the letter or hears the electronic communication.  In cryptographic terminology, the message is called plaintext or cleartext. Encoding the contents of the message in such a way that hides its contents from outsiders is called encryption. The encrypted message is
called the ciphertext. The process of retrieving the plaintext from the ciphertext is called decryption. Encryption and decryption usually make use of a key, and the coding method is such that decryption can be performed only by knowing the proper key.

Cryptography is the art or science of keeping messages secret. Cryptanalysis is the art of breaking ciphers, i.e. retrieving the plaintext without knowing the proper key. People who do cryptography are cryptographers, and practitioners of cryptanalysis are cryptanalysts.

Cryptography deals with all aspects of secure messaging, authentication, digital signatures, electronic money, and other applications. Cryptology is the branch of mathematics that studies the mathematical foundations of cryptographic methods.
 
 
 
 

2.3 Basic Cryptographic Algorithms

A method of encryption and decryption is called a cipher. Some cryptographic methods rely on the secrecy of the algorithms; such algorithms are only of historical interest and are not adequate for real-world needs. All modern algorithms use a key to control encryption and decryption; a message can be decrypted only if the key matches the encryption key. The key used for decryption can be different from the encryption key, but for most algorithms they are the same.  There are two classes of key-based algorithms, symmetric (or secret-key) and asymmetric (or public-key) algorithms. The difference is that symmetric algorithms use the same key for encryption and decryption (or the decryption key is easily derived from the encryption key), whereas asymmetric algorithms
use a different key for encryption and decryption, and the decryption key cannot be derived from the encryption key. Symmetric algorithms can be divided into stream ciphers and block ciphers. Stream ciphers can encrypt a single bit of plaintext at a time, whereas block ciphers take a number of bits (typically 64 bits in modern ciphers), and encrypt them as a single unit. Many symmetric ciphers are described on the algorithms page. Asymmetric ciphers (also called public-key algorithms or generally public-key cryptography) permit the encryption key to be public (it can even be published in a newspaper), allowing anyone to encrypt with the key, whereas only the proper recipient (who knows the decryption key) can decrypt the message. The encryption key is also called the public key and the decryption key the private key or secret key.

Modern cryptographic algorithms cannot really be executed by humans. Strong cryptographic algorithms are designed to be executed by computers or specialized hardware devices. In most applications, cryptography is done in computer software, and numerous cryptographic software packages are available.  Generally, symmetric algorithms are much faster to execute on a computer than asymmetric ones. In practice
they are often used together, so that a public-key algorithm is used to encrypt a randomly generated encryption key, and the random key is used to encrypt the actual message using a symmetric algorithm.  Many good cryptographic algorithms are widely and publicly available in any major bookstore, scientific library, or patent office, and on the Internet. Well-known symmetric functions include DES and IDEA. RSA is probably the best known asymmetric algorithm.
 

2.4 Digital Signatures

Some public-key algorithms can be used to generate digital signatures. A digital signature is a block of data that was created using some secret key, and there is a public key that can be used to verify that the signature was really generated using the corresponding private key. The algorithm used to generate the signature must be such that without knowing the secret key it is not possible to create a signature that would verify as valid.  Digital signatures are used to verify that a message really comes from the claimed sender (assuming only the sender knows the secret key corresponding to his/her public key). They can also be used to timestamp documents: a trusted party signs the document and its timestamp with his/her secret key, thus testifying that the document existed at the stated time.

Digital signatures can also be used to testify (or certify) that a public key belongs to a particular person. This is done by signing the combination of the key and the information about its owner by a trusted key. The reason for trusting that key may again be that it was signed by another trusted key. Eventually some key must be a root of the trust hierarchy (that is, it is not trusted because it was signed by somebody, but because you believe a priori that the key can be trusted). In a centralized key infrastructure there are very few roots in the trust network (e.g., trusted government agencies; such roots are also called  certification authorities). In a distributed infrastructure there need not be any universally accepted roots, and each party may have different trusted roots (such of the party's own key and any keys signed by it). This is the web of trust concept used e.g. in PGP.   A digital signature of an arbitrary document is typically created by computing a message digest from the document, and concatenating it with information about the signer, a timestamp, etc. The resulting string is then encrypted using the private key of the signer using a suitable algorithm. The resulting encrypted block of bits is the signature. It is often distributed together with information about the public key that was used to sign it. To verify a signature, the recipient first determines whether it trusts that the key belongs to the person  it is supposed to belong to (using the web of trust or a priori knowledge), and then decrypts the signature using the public key of the person. If the signature decrypts properly and the information matches that of the message (proper message digest etc.), the signature is accepted as valid.   Several methods for making and verifying digital signatures are freely available. The most widely known algorithm is RSA.
 

2.5 Cryptographic Hash Functions

Cryptographic hash functions are typically used to compute the message digest when making a digital  signature. A hash function compresses the bits of a message to a fixed-size hash value in a way that distributes the possible messages evenly among the possible hash values. A cryptographic hash function does this in a way that makes it extremely difficult to come up with a message that would hash to a particular hash value.  Cryptographic hash functions typically produce hash values of 128 or more bits. This number is vastly larger than the number of different messages likely to ever be exchanged in the world.

Many good cryptographic hash functions are freely available. Well-known ones include MD5 and SHA.
 

2.6 Cryptographic Random Number Generators

Cryptographic random number generators generate random numbers for use in cryptographic applications, such as for keys. Conventional random number generators available in most programming languages or programming environments are not suitable for use in cryptographic applications (they are designed for statistical randomness, not to resist prediction by cryptanalysts).  In the optimal case, random numbers are based on true physical sources of randomness that cannot be predicted. Such sources may include the noise from a semiconductor device, the least significant bits of an audio input, or the intervals between device interrupts or user keystrokes. The noise obtained from a physical source is then "distilled" by a cryptographic hash function to make every bit depend on every other bit. Quite often a large pool (several thousand bits) is used to contain randomness, and every bit of the pool is made to depend on every bit of input noise and every other bit of the pool in a cryptographically strong way.  When true physical randomness is not available, pseudo random numbers must be used. This situation is undesirable, but often arises on general purpose computers. It is always desirable to obtain some environmental noise - even from device latencies, resource utilization statistics, network statistics, keyboard interrupts, or whatever. The point is that the data must be unpredictable for any external observer; to achieve this, the random pool must contain at least 128 bits of true entropy.  Cryptographic pseudo random generators typically have a large pool ("seed value") containing randomness. Bits are returned from this pool by taking data from the pool, optionally running the data through a cryptographic hash function to avoid revealing the contents of the pool. When more bits are needed, the pool is stirred by encrypting its contents by a suitable cipher with a random key (that may be taken from an unreturned part of the pool) in a mode which makes every bit of the pool depend on every other bit of the pool. New environmental noise should be mixed into the pool before stirring to make predicting previous or future values even more impossible.  Even though cryptographically strong random number generators are not very difficult to built if designed properly, they are often overlooked. The importance of the random number generator must thus be emphasized - if done badly, it will easily become the weakest point of the system.
 
 

2.7 Strength of Cryptographic Algorithms

Good cryptographic systems should always be designed so that they are as difficult to break as possible. It is possible to build systems that cannot be broken in practice (though this cannot usually be proved). This does not significantly increase system implementation effort; however, some care and expertise is required. There is no excuse for a system designer to leave the system breakable. Any mechanisms that can be used to circumvent security must be made explicit, documented, and brought into the attention of the end users.   In theory, any cryptographic method with a key can be broken by trying all possible keys in sequence. If using brute force to try all keys is the only option, the required computing power increases exponentially with the length of the key. A 32 bit key takes 2^32 (about 10^9) steps. This is something any amateur can do on his/her home computer. A system with 40 bit keys (e.g. US-exportable version of RC4) takes 2^40 steps - this kind of computing power is available in most universities and even smallish companies. A system with 56 bit keys (such as DES) takes a substantial effort, but is quite easily breakable with special hardware. The cost of the special hardware is substantial but easily within reach of organized criminals, major companies, and governments. Keys with 64 bits are probably breakable now by major governments, and will be within reach of organized criminals, major companies, and lesser governments in a few years. Keys with 80 bits may become breakable in future. Keys with 128 bits will probably remain unbreakable by brute force for the foreseeable future. Even larger keys are possible; in the end we will encounter a limit where the energy consumed by the computation, using the minimum energy of a quantum mechanic operation for the energy of one step, will exceed the energy of the mass of the sun or even of the universe. However, key length is not the only relevant issue. Many ciphers can be broken without trying all possible keys. In general, it is very difficult to design ciphers that could not be broken more effectively using other methods. Designing your own ciphers may be fun, but it is not recommended in real applications unless you are a true expert and know exactly what you are doing.  One should generally be very wary of unpublished or secret algorithms. Quite often the designer is then not sure of the security of the algorithm, or its security depends on the secrecy of the algorithm. Generally, no algorithm that depends on the secrecy of the algorithm is secure. Particularly in software, anyone can hire someone to disassemble and reverse-engineer the algorithm. Experience has shown that a vast majority of secret algorithms that have become public knowledge later have been pitifully weak in reality.  The key lengths used in public-key cryptography are usually much longer than those used in symmetric ciphers. There the problem is not that of guessing the right key, but deriving the matching secret key from the public key. In the case of RSA, this is equivalent to factoring a large integer that has two large prime factors. In the case of some other cryptosystems it is equivalent to computing the discrete logarithm module a large integer (which is believed to be roughly comparable to factoring). Other cryptosystems are based on yet other problems.  To give some idea of the complexity, for the RSA cryptosystem, a 256 bit modulus is easily factored by ordinary people. 384 bit keys can be broken by university research groups or companies. 512 bits is within reach of major governments. Keys with 768 bits are probably not secure in the long term. Keys with 1024 bits and more should be safe for now unless major algorithmic advances are made in factoring; keys of 2048 bits are considered by many to be secure for decades.

It should be emphasized that the strength of a cryptographic system is usually equal to its weakest point. No aspect of the system design should be overlooked, from the choice algorithms to the key distribution and usage policies.
 

2.8 Cryptanalysis and Attacks on Cryptosystems

Cryptanalysis is the art of deciphering encrypted communications without knowing the proper keys. There are many cryptanalytic techniques. Some of the more important ones for a system implementor are described below.

Ciphertext-only attack:

This is the situation where the attacker does not know anything about the contents of the message, and must work from ciphertext only. In practice it is quite often possible to      make guesses about the plaintext, as many types of messages have fixed format headers. Even ordinary letters and documents begin in a very predictable way. It may also be possible to guess that some ciphertext block contains a common word.

Known-plaintext attack:

The attacker knows or can guess the plaintext for some parts of the ciphertext. The task is to decrypt the rest of the ciphertext blocks using this information. This may be      done by determining the key used to encrypt the data, or via some shortcut.

Chosen-plaintext attack:

The attacker is able to have any text he likes encrypted with the unknown key. The task is to determine the key used for encryption. Some encryption methods, particularly  RSA, are extremely vulnerable to chosen-plaintext attacks. When such algorithms are used, extreme  care must be taken to design the entire system so that an attacker can never have chosen plaintext encrypted.

Man-in-the-middle attack:

This attack is relevant for cryptographic communication and key exchange protocols. The idea is that when two parties are exchanging keys for secure  communications (e.g., using Diffie-Hellman), an adversary puts himself between the parties on the communication line. The adversary then performs a separate key exchange with each party. The parties will end up using a different key, each of which is known to the adversary. The adversary will then decrypt any communications with the proper key, and encrypt them with the other key for ending to the other party. The parties will think that they are communicating securely, but in fact the adversary is hearing everything.  One way to prevent man-in-the-middle attacks is that both sides compute a cryptographic hash function of the key exchange (or at least the encryption keys), sign it using a digital signature   algorithm, and send the signature to the other side. The recipient then verifies that the signature came      from the desired other party, and that the hash in the signature matches that computed locally. This method is used e.g. in Photuris.

 Timing Attack:

This very recent attack is based on repeatedly measuring the exact execution times  of modular exponentiation operations. It is relevant to at least RSA.
 

2.9 A Sample Cryptographic Algorithm:

The January 1993 issue of Dr. Dobb's Journal has an article by Peter Smith on a new public-key encryption algorithm called LUC. This algorithm, based on "Lucas sequences", resembles RSA in that it involves modular arithmetic based on N, the product of two  large primes, and a second number, e. A Lucas sequence, V[i](P,Q), is defined as follows.
P is the message to encrypt.  Q is an integer that is always set to 1 for our purposes.

   V[0] = 2
   V[1] = P
   V[n+1] = P*V[n] - Q*V[n-1]

The ciphertext P' = V[e](P,1) mod N.
The plaintext  P  = V[d](P',1) mod N.

The public key component is [N, e].  The secret component is d, which is computed based  on e and the prime factorization of N.  The author, who is also the inventor of the LUC algorithm, claims that it is at least as fast as RSA and is more secure because it is more resistant to adaptive chosen-message forgery.
 

3.CREDIT CARDS

Credit cards is a common mode of payment for real shopping as well as cyber shopping, therefore this mode of Electronic Payment System tends to bring them closer.
 

3.1 How does it work?

When a customer types in their credit card number and requests a service from a merchant, the amount, credit card number, and other information pass through the secure Credit Card Network servers, and are sent to the processors. A confirmation or denial is then sent from the processor, back through the Credit Card Network server, to the customer. There are two ways that a merchant can use the Credit Card Network's services. These are locally and remotely.

•Remote mode - Remote transactions take place on Credit Card Network's servers. The merchant directs customers to a script on the CCN server. The customer processes their card (fills out and submits an order) and then returns to the merchant's web site.

•Local mode - Local transactions take place on the merchant's server. PGP (Pretty Good Privacy) is required. You can get this from http://www.pgp.com. (Note: Credit Card Network will not install it's software e on any server running a non-commercial version of PGP for obvious reasons.) The customer is directed to a script on the merchant's site that connects invisibly and securely via secure sockets to CCN and processes their card. The customer never leaves the merchant's site.
 
 

3.2 Payment Verification/Access Control

The following are the two payment verification/access control methods of implementing Credit Card Subscription Sales:

1) The PIN Code method: Unique username and password  after payment verification. Used where repeated transactions are required (e.g. service based products).

2) The Hardcode method: Used generally for one time transactions. Generic username & password.
 
 

3.3 A typical Credit Card transaction on the net (ibill example)

1)    User visits the site and decides to make a purchase.
2)    He/she selects the mode of payment
3)    End-user is presented with ibill's Processing Page
4)    Relevant information is filled up and submitted by the user
5a)  Credit card verified as good: The end-user taken to a Webgoodpage.
5b)  Credit card verified as bad: The end-user taken to a Webbadpage.
 

3.4 The benefits of Credit Cards as a mode of payment in the EPS

· On-line real-time credit card authorizations.
· Money in your checking account in 48 hours
· Automatic Email receipt  (both for the merchant and the customer)
· Daily transaction report for each merchant
· Automatic updation of accounts as well  (therefore a/c clearance is more frequent)
· CyberCash not required    (also more close to real transaction)
 
 

3.5 Magnetic Stripe Cards

They are very similar to the credit cards. But unlike the credit cards they don’t need any verification as they carry information on the outside of the card in a magnetic tape (something very similar to what we have in the metro railway tickets). The advantage is offcourse doing away with the hassles of verification etc. But the major disadvantage is the vulnerability of the information as it is carried outside the card therefore it can be easily copied or tampered with. This disadvantage led to development of the next type of cards - The Smart Cards.
 
 

3.6 The Smart Cards

It is very similar to a magnetic stripe card but the fact that it stores information on an integrated microprocessor chip located within it.

There are two basic kinds of smart cards.

Intelligent Smart Card.    An "intelligent" smart card contains a central processing unit that actually has the ability to store and secure information, and "make decisions," as required by the card issuer’s specific applications needs. Because intelligent cards offer a "read/write" capability, new information can be added and processed. For example, monetary value can be added and decremented as a particular application might require.

Memory Card.     The second type of card is often called a memory card. Memory cards are primarily information storage cards that contain stored value which the user can "spend" in a pay phone, retail, vending or related transaction.

The intelligence of the integrated circuit chip in both types of cards allows them to protect the information being stored from damage or theft. For this reason, smart cards are much more secure than magnetic stripe cards, which carry information on the outside of the card and can be easily copied. Smart cards are an effective way of ensuring secure access to open interactive systems, such as encryption key mobility, secure single signatures and     electronic digital signatures.

While it is anticipated that smart card technology applications in North America will continue to grow quickly, and in the not too distant future approach European acceptance levels there are two key issues that must be addressed. Before wide-scale, public usage is possible, the public and private sectors must reach a consensus on creating a     technological standard that can be adopted for use by consumers and merchants everywhere. Second, industry and government players face the challenge of charting a technology migration path that will allow smart card technology to co-exist with established technology investments, such as magnetic stripe technology.

Hybrid Cards.   In fact, card technology experts from the Smart Card Forum, a multi-industry group formed to explore the use of smart cards in various applications, predict the development of so-called hybrid cards. Such cards may contain not only an embedded microprocessor chip or memory module, but also a mag stripe and bar coding. Thus, a single card can access different hardware systems, such as merchant card readers, ATM machines and bar code applications. Adding the card-holder's photograph, printed name and signature would further enhance the hybrid card's already significant security features.
 

4. ELECTRONIC CASH PAYMENT SYSTEMS

 
Ecash is a form- application which offers digital cash/ elctronic cash.

4.1 Introduction

Ecash is designed for secure payments from any personal computer to any other workstation, over Email or Internet. Ecash has the privacy of paper cash, while achieving the high security required for electronic network environments exclusively through innovations in public key cryptography. In the past DigiCash has pioneered such cash for chip cards and electronic wallets, always with a tamper-resistant chip for storing the   value. Now we present the first software only solution: ecash. With ecash one can pay for access to a database, buy software or a newsletter by Email, play a computer game over the net, receive $5 owed by a friend, or just order a pizza. The possibilities are truly unlimited.
 
 

4.2 The ecash concept

With the ecash client software (short: client) a customer withdraws ecash (a form of digital money) from a bank and stores it on his local computer. The user can spend the digital money at any shop accepting ecash, without the trouble of having to open an account there first, or having to transmit credit card numbers. Because the received ecash is the value involved with the transaction, shops can instantly provide the goods or services requested.  Person to person payments can also be performed with ecash.

Ecash and security

When using ecash, your cash flows to its destination over the Internet (or any other computer network). The open architecture of the Internet requires security measures to be taken against attempts by unfriendly third parties to intercept the digital money. Ecash provides the highest security possible by applying public key digital signature techniques.
Additional security features of ecash include the protection of ecash withdrawals from your account with a password that is only known to you; not even to your bank.

Ecash and privacy

One of the unique features of ecash is payer anonymity. When paying with ecash the identity of the payer is not revealed automatically. This way the payer stays in control of information about himself. During a payment a payer can of course identify himself, but only when he chooses so.  Ecash offers one-sided anonymity; when clearing a transaction the payee is identified by the bank.

Ecash and crime

It may seem that the privacy offered by ecash can be misused by criminal elements. However, because the privacy is only one-sided and a set of regulatory measures can be taken, ecash is not the ideal tool for criminals. The ecash client software Ecash works on all major platforms (MS Windows, Macintosh and UNIX). The graphic user interface in cash. A text mode version is available for people without a graphical operating systems.
If an on-line ecash accepting shop requires payment, depending on user settings, the client will handle the transaction completely by itself, or prompt the user for authorization.  For the current version of ecash a network connection is required, but a version that will work through Email will be available in the near future.

Accepting ecash

Part of the ecash concept is a very low threshold for shops to start accepting ecash. In our view the Internet is the ideal infrastructure for big players as well as numerous small shops offering a wide variety of specialized goods and services. In fact, any user can accept ecash payments sent on- or off-line.
 
 

4.3 Ecash today

The Cyberbucks trial

Today, almost 30.000 people are using ecash in our world wide trial. The digital money used in the trial, the Cyberbuck, can not be exchanged for real money, but valuable goods and services can be purchased in more than one hundred shops that have joined the trial and accept ecash cyberbucks. The trial, which started in October 1994 and was closed for new testers a year later, introduced cash in cyberspace and created an enormous amount of interest from users, shops and banks as well as the media. The ecash trial shop software is available for free, and full support is given to new on-line shops. With the introduction of the remote shop server, starting a shop has become even easier.

Although DigiCash is running an ecash bank in the trial, it  does not intend to start an exchange between Cyberbucks and other currencies. A growing number of banks, financial institutions and other organizations are very interested in issuing ecash, and we have sold several ecash licenses. DigiCash currently follows a non-exclusive licensing policy, allowing multiple parties to issue ecash with their own, competitive, pricing structure.
 
 
 

4.4 The Ease of Using ecash

This is a cross-platform summary of the basic user functions. The user functions of ecash are the same for all platforms (Windows, Macintosh and UNIX) although the screens may appear slightly different to those shown below.

Overview

Ecash has been designed to be easy to use. Consumers are given a simple 'point-and-click' graphical user interface that is simpler to use than many bank ATMs. To demonstrate  how easy you will find it to use ecash, various transactions involving two ecash Account-holders, Alice and Bob, are explained below.

Startup and Background Operation

Once Alice starts her ecash program, it runs on her PC in the background, much like a memory monitor or clock program.
 

While ecash is running, a small window is displayed that shows her the amount of ecash coins which are stored on her hard disk and are available to be spent. The optional toolbar allows her to access various functions.

Withdrawing ecash from the account

In order to use ecash to purchase goods or services, ecash must first be available on the Alice's hard drive, in the same way that cash is needed in your wallet before you can pay for goods or services in the physical world. Withdrawing ecash is as simple as withdrawing regular cash from an ATM.

The screen below shows the actual dialog box used to withdraw ecash (Version 2.1 of the actual MS Windows ecash client is shown throughout). This window appears when the Mint icon has been clicked on the toolbar. Alice simply enters the amount to be withdrawn from her account and clicks the 'OK' button. This amount of ecash is then downloaded from her ecash account at the Mint to her hard disk.
 

Making a Payment

There are two ways to spend ecash. Alice can decide to send a payment herself, or she can answer a request for payment.

Responding to a Payment Request

Bob has sent a payment request to Alice because she has asked to buy something from him. (The merchants' Purse software will generate and send such requests). For example, in the dialog box below, Alice is being asked to make a payment of $14.95 to buy a CD. If she agrees to make the payment, she just clicks on the 'Yes' button. Similarly, clicking the 'No' button will refuse the payment.


Figure 3 - Alice gets an incoming payment request

According to her preferences, Alice may also instruct her system to respond automatically to similar  payment requests in the future.  When the Policy button is clicked (see window above), the dialog box is extended downwards (see window below). Alice can now set the policy under which payment requests are to be answered automatically. These extra settings can be used to simplify certain repetitive payments.

Initiating a Payment

To make an unsolicited payment directly, Alice brings up the payment dialog box from the toolbar and fills in the blanks, much like writing a personal check.

Receiving ecash

When Alice has sent ecash to John in return for a lunch, , he may want to deposit it in his ecash account or have ecash coins returned to his hard drive for future use. The dialog box shown below will appear on Bob's screen.


 


 

                         Figure 4 - John gets an incoming payment

Just as Alice could set a policy for payment requests, John can also set a simple policy which automatically accepts subsequent incoming payments.

Depositing ecash in/ from a Mint account

Ecash can, of course, be deposited in the user's ecash account. Again a simple dialog box is used. (Actually this is done with the same box used for withdrawals; see Figure 2 above).

 
Figure 5 - Alice deposits some ecash from mint to bank  account

Receipts and Records

Ecash tracks withdrawals, payments, receipts, and deposits, and can provide Alice with various statements of her account.


 

Figure 6 - Alice's digital statement

Cancel Payment

If the Merchant has not deposited the payment yet, (i.e. the status is not marked 'OK' in the payment log) then it is still possible to cancel the payment by clicking on the 'Cancel Payment' button.

Recovery

If the Purse-Holder's computer crashes and stored ecash coins are lost (along with records of recent transactions), then execution of the recovery procedure (using the special Recovery Key) will restore the account to its correct state using the Mint's records from the Transaction Log.
 

How ecash Works Inside

Overview

Like banknotes, ecash can be withdrawn from and deposited to transaction demand deposit accounts. And like banknotes, one person can transfer possession of a given amount of ecash to another person. But unlike cash, when a customer pays another customer an electronic bank will play an unobtrusive but essential role.

To show how it all works we'll explain how a withdrawal works, then follow the ecash in a payment to a merchant. Combining these two transactions, we can then understand why the customer perceives that ecash is paid from person to person without involving any bank. Finally the withdrawal is explained in greater detail to illustrate the 'blind signature' concept, which is the foundation of the privacy feature, and explain why the bank cannot trace it's own money!

Simple Withdrawal of ecash

Figure 7 shows the two participants in the withdrawal transaction: the bank and customer, Alice. The digital coins that have been withdrawn from Alice's account at the bank are on their way to her PC. When they arrive, they will be stored along with some coins she already has on her hard disk.


 
                  Figure 7 - Alice withdraws ecash from her bank account

No physical coins are involved in the actual system of course, but the messages include strings of digits, and each string corresponds to a different digital coin. Each coin has a denomination, or value, so that a purse of digital coins is managed automatically by Alice's ecash software. It decides which denominations to withdraw and which to spend in particular payments. (The ecash software keeps plenty of 'small change', but will prompt the user to contact the bank in the rare event that more change is needed before the next payment, to restructure its purse of coin denominations.)

An ecash Purchase

Now that Alice has some ecash on her hard drive, she can buy things from Bob's shop (as shown below).  Having received a payment request from Bob, she agrees by ticking the 'Yes' box. Her ecash software chooses coins with the desired total value from the purse on her hard disk. Then it removes these coins and sends them over the network to Bob's shop. When it receives the coins, Bob's software automatically sends them on to the bank and waits for acceptance before sending the goods to Alice along with a receipt.


 
Figure 8 - Alice buys something from Bob

To ensure that each coin is used only once, the bank records the serial number of each coin in its spent coin database. If the coin serial number is already recorded, the bank has detected someone trying to spend the coin more than once and informs Bob   that it is a worthless copy. If, as will be the usual case, no such serial number has been recorded, the bank stores it at that position and informs Bob that the coin is valid and the deposit is accepted.

Person-to-Person Cash

When a consumer receives a payment, the process could be the same. But some people may prefer that when they receive money, it be made available on their hard disk immediately, ready for spending; just like when someone hands them a five dollar bill. This user preference can be realized as depicted in Figure 9

The only difference between this payment from Alice to another consumer, Cindy, and the one Alice paid to Bob's shop in Figure 8, is what happens after the bank accepts the cash. In Figure 9, Cindy has configured her software to request the bank to withdraw the ecash she has just deposited and send it back to her PC as soon as the coins are accepted. (Actually Cindy's bank will check with Alice's bank to make sure that the coins deposited are good.) Now when Alice sends Cindy five dollars, new coins are immediately available to spend from Cindy's PC.
 
 

 
Figure 9 - person-to-person payment

How Privacy Is Protected

In the simple withdrawal of Figure 7, the bank created unique blank digital coins, validated them with its special digital stamp, and supplied them to Alice. This would normally allow the bank (at least in principle) to recognize the particular coins when they are later accepted in a payment. And this would tell the bank exactly which payments were made by Alice.

By using 'blind signatures, a feature unique to ecash, the bank can be prevented from recognizing the coins as having come from a particular account. The idea is shown in Figure 10. Instead of the bank creating a blank coin, Alice's computer creates the coin itself at random. Then it hides the coin in a special digital envelope and sends it off to the bank. The bank withdraws one dollar from Alice's account and makes its special 'worth-one-dollar' digital validation like an embossed stamp on the envelope before returning it to Alice's computer.
 

 
                  Figure 10 - Alice sends her coin for signature by the bank

Like an emboss, the blind signature mechanism lets the validating signature be applied through the envelope. When Alice's computer removes the envelope, it has obtained a coin of its own choice, validated by the bank's stamp. When she spends the coin, the bank must honor it and accept it as a valid payment because of the stamp. But because the bank is unable to recognize the coin, since it was hidden in the envelope when it was stamped, the bank cannot tell who made the payment. The bank which signed can verify that it made the signature, but it cannot link it back to a particular object or owner.

How It All Works with Numbers

When Alice's computer creates a blank coin it chooses a random number. The bank's validating stamp on the coin is a public key digital signature encoded by the bank with the random coin number serving as the message to be coded. Checking the validity of a coin involves the verification of the digital signature using the bank's corresponding public key. The blinding operation is a special kind of encryption designed so that it can only be removed by the party who placed it there. It can be reversed using the public key digital
signature process, and can thus be removed without disturbing the signature.
 
 
 

How Funds Flow

Although ecash works just like cash in the hands of a consumer, for a bank its properties are somewhat different.

The first step in each case occurs when value comes out of a customer's account. In an ATM transaction, the cash given to the consumer constitutes a reduction in vault cash. In an ecash withdrawal, however, the value is moved within the bank and becomes an ecash liability that will be reversed when the ecash is presented for deposit.

The second step is the spending of the value, where cash and ecash are very similar. In each case the merchant (or other party receiving it) can choose to be issued with new cash coins or can make a deposit to an ecash account.  When the merchant takes the final step and deposits the traditional cash, it constitutes an increase in vault cash, whereas deposit of ecash reduces the ecash liability and increases deposit liability. While the main difference is invisible to the consumer, it is vitally necessary to protect the integrity of ecash. When a digital coin is received as payment it must be surrendered to the bank who will exchange it for an account credit or for freshly minted ecash.
 
 
 

5.MICRO PAYMENTS

5.1 Background

As content providers move from the physical world of atoms to the virtual world of bits, the cost of doing business and the business opportunity itself will change. It is estimated that 75% of the purchase price of goods goes to support the underlying cost of physically packaging, distributing, wholesaling and retailing of the product. The Internet, of course, allows content providers to bypass physical distribution channels and directly deliver products on-line to consumers at considerable savings. In addition, the shift from atoms to bits changes the incremental cost of goods sold. With bits, the cost to create or manufacture an exact duplicate is very small. With adequate Internet bandwidth, the cost to deliver one more copy of the product is also very small.
 As this shift towards Internet-based manufacturing and distribution occurs, content providers are also redefining what they sell. The Internet of today does not have the bandwidth to deliver 60 minutes of stereo quality audio into the home. But it does have adequate bandwidth todeliver FM quality songs one at a time. When decomposed into the smallest logical components that can be delivered over the Internet, the price of content is in the pennies. Dividing a single issue of a national weekly magazine into on-line content means the price of a simple, one-page article is about two cents. A longer feature article is worth about a quarter. Political cartoons are worth less than a penny. With content manufacturing and delivery costs falling into the pennies, the billing cost needs to be reduced several orders of magnitude below that to be economic. This is the essence of the microcommerce.
 
 

5.2 What are Micro Payments

 Payments can be broadly divided into two categories.
· Macro Payments
· Micro Payments
 
Payment
Minimum Transaction Value
Typical Transaction Value
Maximum Value
Macro
$5.00 
$50.00 
$500.00 
Micro 
 $0.001
$0.01 
 $5.0
 
 
 

5.3 Problems with existing options for Electronic Payments

There are a number of existing and proposed protocols for electronic commerce, such as those from DigiCash, Open Market, CyberCash, First Virtual, and NetBill. They are all appropriate for medium to large transactions, $5 or $10 and up, because the costs per transaction are typically several cents plus a percentage. When these costs are applied to inexpensive transactions, 50 cents and less, the transaction costs become a significant or even dominant component of the total purchase price, thereby effectively creating a minimum price for goods and services purchased using one of these protocols. Forcing on-line charges to be above some threshold reduces the options for service providers. On-line services providing newspapers, magazines, reference works, and stock prices all have individual items that could be inexpensive if sold separately. The ability to purchase inexpensive individual items would make these services more attractive to casual users on the Internet. In addition, secure low-priced transactions support grass-roots electronic publishing. A user who is not likely to open a ten-dollar account with an unknown publisher may be willing to spend a few cents to buy an interesting-looking article.

There are mainly four Internet options
· Accounts,
· Aggregation
· Credit Cards
· Digital Cash

 Why these are not suitable for micro payments are described below:

 Accounts

     The simplest model for electronic commerce is for customers to establish accounts with vendors. When a customer wants to perform a transaction with the vendor, the customer identifies himself (securely) and the vendor adds the cost of the transaction to the customer's account. Vendors maintain the account information and bill the customers periodically. With accounts, transaction costs and prices can be fairly low, but there is a fair amount of overhead. An account may need to be established ahead of time and maintained over an extended period. This makes sense only when assuming a relatively long-standing relationship between a customer and a vendor. There is often a minimum monthly charge associated with each account. The customer has separate accounts for each vendor, and the vendor needs to maintain     accounts for every customer. All this overhead discourages casual users from making spur-of-the-moment purchases.

 Aggregation

     Aggregation amortizes billing charges over a sequence of less expensive transactions by accumulating transactions at the vendor until they exceed some threshold. Aggregation is another form of accounts and shares some of the problems of accounts. Although account setup is somewhat simplified, the vendor still has the problem of maintaining the accounts,     accumulating enough transactions for a reasonable sized charge, and keeping transaction records for dispute resolution. Also, the customer must deal with separate charges from each vendor, minimum account charges, and the difficulty of contesting fraudulent charges.

 Credit cards

     Another simple model for electronic commerce is to use a credit card to pay for the purchase. Customers have credit cards; vendors register with credit card companies; customers give their credit card number to vendors; vendors contact their credit card companies for payment; the credit card companies handle the accounting and billing. There are established methods (like Netscape's SSL based on RSA's public key encryption) for ensuring secure transmission of the client's credit card number to the vendor. Unfortunately, credit card transactions are (relatively) expensive since every purchase involves communication to a centralized credit card transaction service. In addition, credit card companies offer various features like individual item accounting, insurance, and fraud protection that add to the cost and aren't needed when purchasing inexpensive items.
     Finally, customers may be unwilling to provide a credit card number to a vendor they don't know well. Although the  credit card company insures the customer against any loss, there is still the inconvenience of clearing up any problems.
 
Digital cash

     Digital cash is normally issued by a central trusted entity (like a bank). The integrity of digital cash is guaranteed by the digital signature of the issuer, so that counterfeiting digital cash is extremely hard. However, it is trivial to duplicate the bit pattern of the digital cash to produce and spend identical (and equally authentic) cash. In an on-line digital cash scheme, when a vendor receives digital cash, he must contact the issuer to see if it is valid and  not already spent. This extra communication makes the central site a bottleneck and adds cost to the transaction.
     In an off-line scheme (like one proposed by DigiCash), the vendor authenticates the digital cash during the  transaction and then later transmits it to the issuer to check for double spending. This scheme adds computational costs  to the vendor for authenticating the digital cash, and adds messages and encryption to the protocol for pinpointing the source of the double spending.
 

5.4 Protocols for Micro Payments

Last few years have seen emergence of many MicroPayment protocols.Some of the popular ones are listed below:
 

Of all these protocols Millicent is the most popular protocol and most of other protocols are inspired from it.
 
 
 

5.5 Millicent Protocol

Mark Manasse of the Systems Research Center in Palo Alto has designed an innovative approach to this opportunity of Micro Payment System which he calls Millicent. The design looks to many in the industry as a completely new way to buy and sell content over the Internet. The Millicent system supports fine-grain transactions as small as 1/10th of a cent or up to about $5.00 in value. Microcommerce transactions in this range are important to on-line publishers that want to sell newspapers by the article, cartoons by the strip, or music by the song. Software providers targeting the Network Computer (NC) market can use the Millicent system to sell Java applets and host-based applications on a per-use basis. In an Intranet setting, Millicent software acts as a Web-aware accountant that meters access to information systems and to services inside the enterprise.
Goal for Millicent is to allow for transactions that are inexpensive yet secure. This is  achieved  by using accounts based on scrip and brokers to sell scrip. A piece of scrip represents an account the customer has established with a vendor. At any given time, a vendor has outstanding scrip (open accounts) with the recently active customers. The balance of the account is kept as the value of the scrip. When the customer makes a purchase with scrip, the cost of the purchase is deducted from the scrip's value and new scrip (with the new value/account balance) is returned as change. When the customer has completed a series of transactions, he can "cash in" the remaining value of the scrip (close the account).
Brokers serve as accounting intermediaries between customers and vendors. Customers enter into long-term relationships with brokers, in much the same way as they would enter into an agreement with a bank, credit card company, or Internet service provider. Brokers buy and sell vendor scrip as a service to customers and vendors. Broker scrip serves as a common currency for customers to use when buying vendor scrip, and for vendors to give as a refund for unspent scrip.
 

Millicent reduces the overhead of accounts in a number of ways:

· Communication costs are reduced by verifying the scrip locally at the vendor's site; there are almost no Millicent-specific communication costs during a normal transaction. There is also no need for a centralized server or an expensive  transaction-processing protocol.

· In a centralized scheme, the central site is a bottleneck; the provider must have sufficient computing power to handle the  peak transaction rate. In Millicent, there is no central server; there can be many brokers, a broker is only involved in a  fraction of the transactions between a customer and a vendor, and the transactions involving a broker are lightweight.
· Cryptographic costs are reduced to keep them in line with the scale of transactions; we don't need strong or expensive  cryptographic schemes because the value of the scrip is relatively low. We need only make the cost of breaking the  protocol greater than the value of the scrip itself.
· Accounting costs are reduced by using brokers to handle accounts and billing. The customer establishes an account with a broker; the broker establishes its own accounts with the vendors. Using brokers allows us to split a customer-vendor account into two accounts: one between the customer and broker, and another between the broker and the vendor. This reduces the total number of accounts. Instead of many separate accounts for every customer-vendor combination, each customer has only one account with a broker (or, at most, a couple of brokers); and each vendor has long-standing accounts with just a few brokers.
· In most account-based schemes, the vendor maintains the account balance. In Millicent, the customer maintains the  account balance -- it is encoded in the scrip held by the customer. There is no risk for the vendor because a digital signature prevents the customer from modifying the scrip's value. Since the scrip contains the account balance and a proof of correctness for that value, the vendor does not need to look up the customer's balance, saving disk activity.

     The minimum monthly charges are not as much of a problem because they are amortized over more activity. The single customer-broker account supports transactions with all vendors and so it is likely to have enough activity to cover a  minimum charge. By pre-paying the broker, even the monthly accumulation of charges can be avoided.

Millicent is best suited for a series of inexpensive, casual transactions. We will rely on other protocols for initial account establishment between brokers and customers, and brokers and vendors. Other higher-value protocols are also used for the funds transfers that occur when accounts are periodically settled.
 

5.5.1 Security and Trust

The security model for Millicent is based on the assumption that scrip is used for small amounts. People and businesses treat coins differently than they treat bills, and treat small bills differently than large bills. In Millicent, we imagine people treating scrip as they would treat change in their pocket.
Since people don't need a receipt when buying candy from a vending machine, they don't need a receipt when buying an item using scrip. If they don't get what they paid for, they complain and get a refund. If they lose a coin every now and then, they aren't too upset. We expect users to have a few dollars of scrip at a time. We don't expect them to have hundreds, or even tens, of dollars of scrip. As a result, scrip is not worth stealing unless you can steal lots of it; and if you steal lots, you will get caught.

Trust model

Millicent assumes asymmetric trust relationships among the three entities - customers, brokers, and vendors. Brokers are assumed to be the most trustworthy, then vendors, and, finally, customers. The only time customers need to be trusted is when they complain about service problems.
It is  believed that brokers will tend to be large, well-known, and reputable financial institutions (like Visa, MasterCard, and banks) or major Internet or on-line service providers (like CompuServe, NETCOM, or AOL). We expect there to be many vendors covering a full spectrum of size and trustworthiness, as in the real world. Finally, there will be large number of customers who are as trustworthy as people are in general. Three factors make broker fraud unprofitable. First, customer and vendor software can independently check the scrip and maintain account balances, so any fraud by the broker can be detected. Second, customers do not hold much scrip at any one time, so a broker would have to commit many fraudulent transactions to make much of a gain and this makes them likelier to be caught. Finally, the reputation of a broker is important for attracting customers and a broker would quickly lose its reputation if customers have troubles with the broker. The repeat business of active customers is more valuable to a broker than the scrip that it could steal. Vendor fraud consists of not providing goods for valid scrip. If this happens, customers will complain to their broker, and brokers will drop vendors who cause too many complaints. This acts as an effective policing mechanism, because vendors need a broker to easily conduct business in Millicent. As a result, the Millicent protocol is skewed to prevent customer fraud (forgery and double spending) while providing indirect detection of broker and vendor fraud.
 
 

Security

     The security of Millicent transactions comes from several aspects.

· All transactions are protected

· Every Millicent transaction requires that the customer knows the secret associated with the scrip. The protocol never sends the secret in the clear, so there is no risk due to eavesdropping.
 
· No piece of scrip can be reused, so a replay attack will fail. Each request is signed with the secret, so there is no way to intercept scrip and use the scrip to make a different request.

· Inexpensive transactions limit the value of fraud
 
· Inexpensive transactions can rely on inexpensive security: it's not worth using expensive computer resources to steal inexpensive scrip. In addition, it would take many illegal uses of scrip to acquire much money, and that raises the  probability of getting caught.
 
· Fraud is detectable and eventually traceable

· Fraud is detected when the customer doesn't obtain the desired goods from the vendor, or when the balance returned to the customer doesn't match the balance due. If the customer is cheating, then the vendor's only loss is the cost of detecting the bad scrip and denying service. If the vendor is cheating, the customer will report a problem to the broker.
 
· When a broker notices a pattern of complaints from many customers against a vendor, it can pinpoint the fraud and cut off all dealings with the vendor. If a broker is cheating, the vendor will notice bad scrip coming from many customers, all originating from a single broker. The vendor can then publicize its complaint in an appropriate venue.
 

5.5.2 Scrip

The main properties of scrip are:

· It has value at a specific vendor.
 
· It can be spent only once.
 
 It is tamper resistant and hard to counterfeit.
· It can be spent only by its rightful owner.
 
· It can be efficiently produced and validated.
 
The next sections give more detail about scrip and its use, but the basic techniques to achieve these properties are outlined here:

· The text of the scrip gives its value and identifies the vendor.
 
· The scrip has a serial number to prevent double spending.
 
· There is a digital signature to prevent tampering and counterfeiting.
 
· The customer signs each use of scrip with a secret that is associated with the scrip.
 
· The signatures can be efficiently created and checked using a fast one-way hash function (like MD5 or SHA).

Scrip structure

There are three secrets involved in producing, validating, and spending scrip. The customer is sent one secret, the customer_secret, to prove ownership of the scrip. The vendor uses one secret, the master_customer_secret, to derive the customer_secret from customer information in the scrip. The third secret, the master_scrip_secret, is used by the vendor to prevent tampering and counterfeiting.
The secrets are all used in a way that shows knowledge of the secret without revealing the secret. To attest to a message, the secret is appended to the message, and the result is hashed to produce a signature. The message (without the secret) and the signature prove - due to the one-way nature of the hash function - knowledge of the secret, because the correct signature can only be derived if you know the secret.

Scrip has the following fields:

· Vendor identifies the vendor for the scrip. Value gives the value of the scrip.
· ID# is the unique identifier of the scrip. Some portion of it is used to select the master_scrip_secret used for the certificate.
 Cust_ID# is used to produce the customer secret. A portion of Cust_ID# is used to select the master_customer_secret which is also used in producing the customer secret.
· Expires is the expiration time for the scrip.
· Props are extra data describing customer properties (age, state of residence, etc.) to the vendor.
· Certificate is the signature of the scrip.
 

5.5.3 Validation and expiration

Scrip is validated in two steps. First, the certificate is recomputed and checked against the certificate sent with the scrip. If the scrip has been tampered with, then the two certificates will not match. Second, there is a unique identifier (ID#) included in the scrip body and the vendor can check for double spending by seeing if it has recorded that identifier as already spent. Generating and validating scrip each require a little text manipulation and one hash operation. Unless the secret is known, scrip cannot be counterfeited or altered.
 
 The received scrip is validated by regenerating the certificate and comparing it to the transmitted one. If  they are identical, the scrip is valid. The vendor records the unique identifier of every piece of scrip that is spent, so that is cannot be fraudulently re-spent. To save the vendor from maintaining this record forever, each piece of scrip is given an expiration time. Once the scrip expires, the vendor no longer has to worry about it being re-spent and can erase its record of the scrip.

Customers are responsible for renewing or cashing in scrip before it expires. The old scrip is submitted to the vendor, who returns new scrip with a later expiration time (and a new serial number). Vendors may choose to charge a small fee for this service, discouraging users from obtaining more scrip than they will need in the near future.
 

5.5.4 Properties

Scrip also has fields for storing properties, which are inserted by the vendor or broker when the scrip is produced. The exact property fields and their values will depend on an agreement between the brokers and vendors. The brokers will get the information from customers when they create their account and enforce some set of rules when selling vendor scrip. Vendors, of course, are free to include whatever properties they desire in scrip they produce themselves.
Information such as the state of residence, or age of the consumer assists the vendor in making sales decisions. Adult material could only be bought if the scrip shows the customer is old enough. State sales tax charges can depend on a property included in the scrip.
 
 
 
 

5.5.5  Various Millicent Protocols

Scrip is the basis of a family of Millicent protocols. We will describe three of them and compare their simplicity, secrecy, and security.The first, "scrip in the clear", is the simplest and most efficient protocol. It is the basis for the other two protocols, but it may not be useful in practice because it is too insecure. The second, "private and secure", is secure and offers good privacy, but it is more expensive. The third, "secure without encryption", is also secure, but trades privacy for greater efficiency.
 

Scrip in the clear

In the simplest possible Millicent protocol, the customer just sends an unspent piece of scrip in the clear (i.e., not encrypted or protected in any way) along with each request to the vendor. The vendor returns the desired result along with a new piece of  scrip (also in the clear) as change.
This protocol offers almost no security: an eavesdropping third party can intercept the scrip being returned as change and use it himself. When the rightful owner later attempted to spend the scrip, the vendor would have a record of it being previously spent, and would refuse the request.

Private and secure

To add security and privacy to the Millicent protocol, we establish a shared secret between the two parties and then use the secret to set up a secure communications channel using an efficient, symmetric encryption method (such as DES, RC4, or IDEA). In Millicent, scrip can be used to establish this shared key. When a customer buys an initial piece of scrip for a vendor, a secret is generated based on the customer identifier, and returned securely with the scrip. This requires either that the transaction be performed using some secure non-Millicent protocol, or that the scrip be purchased using a secure Millicent transaction.

The vendor does not directly record the secret associated with the piece of scrip. Instead, the customer identifier (Cust_ID#) field of the scrip allows rapid recalculation of the secret. The customer identifier must be unique whenever scrip is transmitted to a new customer, but it need not have any connection to the identity of the customer. When the vendor receives the request, he derives the customer secret from the customer identifier in the scrip, derives the message key from the customer secret, and uses the message key to decrypt the request. The change scrip can be returned in the clear, while the response and any new secrets are returned to the customer encrypted by the message key.

In this protocol the request and the response are kept totally private; unless an eavesdropper knows the customer secret, he can't decrypt the messages. In addition, an eavesdropper can't steal the scrip because it can't be spent without knowing the customer secret. The customer secret is generated by hashing the customer identifier with a secret. The secret is selected using a portion of the customer identifier.

Secure without encryption

The previous section describes how the secret shared by the customer and vendor can be exploited to achieve security and privacy. But a full-blown encrypted channel may be overkill for some Millicent applications. In this, our third variant of the protocol, we give up the privacy of the request and response to eliminate the use of encryption.

As in the previous protocol, the customer securely gets an initial piece of scrip and customer secret. To make a purchase, the customer sends the request, scrip, and a "signature" of the request to the vendor. The signature is produced in the same way that the certificate of the scrip is produced. The scrip and request are concatenated with the customer secret. The customer runs an efficient cryptographic one-way hash function over this string and sends the resulting hash as the signature.

When the vendor receives the request, he derives the customer secret from the scrip and regenerates the signature for the request. If the scrip or request have been tampered with in any way, the signature will not match.The request is validated by re-generating the request signature and comparing to the transmitted signature. If they match, the request is valid. The vendor now handles the request and returns a fresh piece of scrip as change. The change scrip shares the same customer identifier as the scrip submitted with the request, so that the original customer secret can be used to spend the change. There is no need to encrypt any of the response; an eavesdropper can't steal the scrip because the signature of the request can't be made without knowing the customer secret. The vendor may sign the response with the customer secret in order to prove authenticity to the customer. Thus, with only a few hashes, Millicent provides a lightweight and secure protocol.
 

5.5.6 Brokers

Brokers maintain the accounts of customers and vendors, and they handle all real-money transactions. The customer establishes an account with a broker by using some other method (like a credit card, or a higher-security electronic commerce system) to buy some broker scrip. The customer then uses the broker scrip to buy vendor scrip. The vendor and the broker have a long-term business relationship. The broker sells vendor scrip to customers and pays the vendor. There can be different business models for the way the broker gets vendor scrip, for example, pay in advance, consignment sale, or licensed production. In all models, the broker can make a profit selling scrip because he pays the vendor (at a discount) for scrip in bulk and sells individual pieces to customers.

When a customer wants to make a purchase, the customer contacts the broker to obtain the necessary vendor scrip. The customer uses his broker scrip to pay for the vendor scrip using the Millicent protocol. The broker returns the new vendor scrip along with change in broker scrip.

We will examine three ways in which the broker gets the vendor scrip. The "scrip warehouse" model assumes a casual relationship between the broker and vendor. The "licensed scrip producer" model assumes a substantial and long-lasting relationship between the broker and vendor. The "multiple broker" model assumes a relationship between brokers, but requires no relationship between the vendor and broker.
 
 
 

5.5.7 Scrip warehouse

When the broker is acting as a scrip warehouse, the broker buys multiple pieces of scrip from a vendor. The broker stores the scrip and sells the pieces one at a time to customers .

This model assumes no special relationship between the vendor and broker. It works best when the broker's customers have a light to moderate demand for that vendor's scrip. The broker uses the Millicent protocol to buy the scrip from the vendor in the same way a customer would. Selling scrip in large blocks is more efficient for the vendor since the communication and financial transaction costs are amortized over all the pieces of scrip. We presume that the vendor offers some sort of volume discount to encourage brokers to buy large blocks of scrip. The broker makes a profit when it resells the scrip to customers at full price. The vendor depends on the broker to ensure any customer properties encoded in the scrip.
 

5.5.8 Licensed scrip production

If a broker's customers buy a lot of scrip for a specific vendor, it may be desirable for a vendor to "license" the broker to produce vendor scrip. This means that the broker generates scrip that the vendor can validate and accept. The vendor sells the broker the right to generate scrip using a given master_scrip_secret, series of scrip ID#'s, master_customer_secret, and series of customer identifiers. The vendor can validate the licensed scrip because the master_scrip_secret is known from the series of the scrip ID# and the master_customer_secret is known from the series of the customer identifier.
Brokers produce the scrip and collect money from customers; vendors record the total value of scrip originating from a particular broker. When all the scrip produced under a particular contract has expired, brokers and vendors can settle up. The broker presumably takes some commission for producing the scrip.

A license covers a specific series (unique range of identifiers - ID#'s) of scrip for a given period of time, and the secrets shared  between the broker and vendor only apply to that series. A vendor can issue licenses to different brokers by giving out different series and secrets to each one. Of course, a vendor can produce its own scrip using its own private series and secrets. Licensing scrip production is more efficient for the vendor and broker than the scrip warehouse model. There is less communication because the license is smaller to transmit than a few pieces of scrip. The vendor does less computation since it does not have to generate the scrip itself. The broker does not have to store large blocks of scrip, since it can generate the scrip on demand. Additionally, it allows the broker to encode specific user properties into each piece of scrip it generates.
 

5.5.9 Multiple brokers

In an environment where there are multiple brokers, a customer of one broker may want to make a purchase from a vendor associated with another broker. If the vendor only wants to have an account with its own broker (perhaps to simplify accounting), the customer will have to go through the vendor's broker to buy vendor scrip.

The idea of licensed scrip production can be extended so that brokers can generate broker scrip for other brokers.
 
 

5.5.10 Customer, Broker, and Vendor Interactions

  Transaction between customers, Broker and Vendor can be explained using following diagram.
 

 
 

5.6 Present Status of Millicent

Initial implementation of Millicent consisting of a set of libraries, and a vendor and broker written using the libraries for Millicent transactions across a network using TCP/IP has been produced. Measurements show that the Millicent protocol is efficient enough for sub-cent purchases. Untuned vendor implementation can validate about 1000 Millicent requests per second (on a Digital AlphaStation 400 4/233) and, of that, most of the time goes into the TCP connection handling.
Using zero-cost transactions, Millicent scrip can be used as a distributed capability. Using this aspect of scrip, first application of Millicent is in a Kerberos-like authentication suite for network firewall services. A SOCKs based TCP relay, rlogin daemon, FTP daemon, and rlogin, telnet, and FTP clients to use Millicent scrip to convey authentication information has been modified. A user does one cryptokey (cryptographic challenge/response) authentication to get scrip from an authentication broker. Then, for the rest of the day, the user can use the authentication scrip to buy scrip for particular firewall services.

Work is also being done on Millicent-based world wide web (WWW) services. A local pseudo-proxy that intercepts all requests from the client's WWW browser and modifies the HTTP header to add scrip as necessary has been developed. The WWW server checks the HTTP request for sufficient scrip to buy the page and returns the page with change in the HTTP response. The pseudo-proxy extracts the change before forwarding the response to the browser. When Millicent becomes popular, the functionality of the pseudo-proxy can be integrated in with the browser.
 

5.7 Other Protocols

   Apart from Millicent there are other protocols as well , but most of these are inspired from Millicent only.
 

    5.7.1 IBM’s iKP

  IBM's iKP "The IBM Research Division has developed a family of secure payment protocols, called iKP, that circumvent ..." "The iKP technology is designed to allow customers to order goods, services, or information over the Internet, while relying on existing secure financial networks to implement the necessary payments."
 iKP   has following features:

Digital Signature
· Not only the card holder, but also the shop and the acquirer are identified with digital Signature.

 Public Key Cryptography
· Credit Card number is encrypted with the acquirer's public key. Shops and traffic monitor can not see the plain credit card number.

 Hash
· The acquirer receives the hash of purchase order both from the cardholder and the shop. He/She just know only that the cardholder and the shop agree what they are paying. There is no way that the acquirer know about the purchase order itself.
 

5.7.2 MPTP

Micro Payment Transfer Protocol (MPTP) Version 0.1 "W3C Working Draft 22-Nov.-95" "A protocol for transfer of payments through the services of a common broker is described. The processing demands of the protocol make it practical for small payment amounts. The latency makes it practical for use in interactive applications. The scheme thus satisfies the two key criteria for a micropayments scheme. MPTP implements a variation of the Pay-Word proposal of Rivest and Shamir [RivestSh95]. It is also inspired by the Millicent proposal by Manasse [Manasse95] and the iKP proposal by Bellare et. al. [BellareEt95]. A proposal similar to the PayWord scheme by Torben Pedersen [Pedersen9?] was reported after this draft was begun."
 

5.7.3 NetBill

Netbill is also a billing server protocol intended for use in processing micropayments -- charges ranging from pennies to a few dollars. Customers set up pre-paid accounts with Netbill, and authorize Netbill to make payments to merchants (through the merchants' banks). The role of Netbill is to provide authentication, billing, account management, and reporting.
Netbill is a private protocol. Transactions are encrypted against third-party snooping, but the identity of the buyer is known to both the Netbill server and to the merchant. Netbill is a transaction-atomic protocol. Since the server has control of both accounts to be changed, it can ensure that changes happen all-or-nothing. Furthermore, since it is intended for purchase of information, it uses cryptographic methods to ensure that payment is received if and only if the information is received.
As with other billing server implementations, this protocol does not provide a destructible or stealable form of money (although, as always, unauthorized payments are possible if a person can steal a password). It is also on-line, and requires no special hardware.

The fact that the protocol is transaction-atomic means it is also non-repudiable, since the protocol makes it impossible for payment to be received unless the merchandise is delivered, and vice versa. The cost of a Netbill transaction is very low. It varies with purchase amount, but is optimized to have a cost on the order of 1 cent on transactions on the order of 10 cents. Much of the cost savings is gained by ensuring that both the payer and payee of a transaction have accounts with Netbill, so the internal workings of a payment are all local to the server.

The potential for Netbill is based on the growth of pay-per-use systems, in which instead of buying a blanket subscription to a service, articles are bought on an individual basis for a low price. Few merchants use this system now, primarily out of unfamiliarity, but should be a booming method of payment in the future.
 
 
 
 
 

 6.  EPS - PROSPECTS FOR THE FUTURE

The rapid growth of the Internet over the past several years has been fueled mainly by the sharing and transferring of vast amounts of information. Much of the future growth, however, will come from the increased use of the Internet for commercial business transactions. Before these types of transactions become commonplace, several problems must be resolved. These problems include; data security and integrity, economical systems for accounting of a large number of small value transaction, establishing an accepted standard and compatibility between different payment systems, and several policy and regulatory  issues.
 

6.1 Security

At present there are several problems confronting Internet customers that must be resolved before Internet electronic commerce can become as ubiquitous and worry free as many people predict. First and foremost among these is the problem of ensuring data security and integrity. The major challenge is to address the security issue without sacrificing any of the benefits that the Internet provides by its open architecture.

At present most payment schemes operate in a closed-loop system, and are geared towards large payments. Most of these systems are operated by large banks or multinational corporations. It is probably not feasible to expand these networks into multipurpose systems since almost all are incompatible with each other, and each has been designed solely around the needs of its owner.

Most business transactions are concerned with three types of security. First, they wish to ensure the positive identity of the customer, and that all transactions are sent to the right customer. Second, they want to protect sensitive customer information, such as credit card numbers, bank account numbers, or other personal and  financial data. And third, they want to make sure that the data is not altered or changed as it is transmitted across the Internet.
 
 

6.2 Accounting for Large Number of Small Transactions

Another problem that needs to be overcome is that all current electronic payment systems are designed  around relatively small numbers of high value transactions. For example, many large banks and the Federal Reserve use electronic payment systems to transfer money and provide settlement among themselves. This requires a relatively few number of transactions, but moves a large value of money. In the future, a large percentage of transactions on the Internet are likely to be high volume, but with a small dollar value per transaction.The range of potential applications for MicroPayments is quite broad. With current technology, MicroPayments is appropriate for transactions from a few dollars to as little as one-tenth of a cent. The upper bound comes from the trust model for brokers and the availability of alternative protocols appropriate for transactions above a few dollars, while the lower bound comes from a conservative estimate based on the computational costs of a broker. This price range covers most print and information services that will be available in an on-line format - magazines, newspapers, encyclopedias, indices, newsletters, and databases.

MacKie-Mason and Varian argue that as the Internet develops there will be increasing pressure for usage-based charges. Current free Internet services like e-mail, file transfers, the Internet telephone, and teleconferencing will have to be paid for. At the lowest level, they estimate that the cost of transmitting one packet on the Internet backbone is one six-hundredth of a cent.
.

6.3 Standardization and Compatibility

One more problem that must be addressed is ensuring that all future electronic payment systems follow the same standard and are compatible with each other. Imagine if you needed different sets of currency for each store you went into!

Since many people still fear or simply don't understand technology, any new payment systems must be easy to use and understand. In order for the Internet to become the universal form of business and communication that many people envision, it must be accepted by everyone. Today, despite its tremendous growth, only about one third of all U.S. households have Internet access. A recent Business Week article, estimates that only 11% of U.S. households now access the Internet directly or through on-line services. To get those people to use and accept the new technology, designers and programmers must work to make the technology as simply to use as possible.

All the new electronic payment systems being designed or proposed must also be compatible with each other. Consumers will not put up with the hassle and inconvenience of keeping track of which stores will accept which type of payment. The market will probably only support a few different networks, similar to VISA, Discover, and American Express in the credit card market today.
 
 

6.4 Policy and Regulatory Issues

The increasing use of electronic payment systems over the Internet also presents many policy and regulatory problems that must be resolved. The use of the Internet should increase the pace and scope of the globalization of business as smaller transactions between countries become feasible. Several people predict that eventually there would no longer be national currencies, but rather just 'cybercurrencies'. First Union bank has even registered "Cyberbank" as a trademark. There is also the question of whether some governments might ban e-cash because of concerns over control and loss of national identity.

Another debate is taking place as to whether the availability of electronic payment systems, especially anonymous ones, would make money laundering easier or harder. Since most money laundering currently involves transfers of cash, a strong argument can be made that the increased amount of information available with electronic payments would make laundering harder.
These, as well as other issues such as protection of copyrights and trademarks, must be addressed and resolved shortly so that uncertainties can be removed and development pushed forward.
 
 

6.5 Desired Features

The most desirable, in fact indispensable, feature that any electronic payment system must have is the complete security and integrity of data. If people don't feel confident that their data is safe and secure they will be hesitant to use the Internet for anything other that gathering information.

Customers will also demand that any payment system be easy to use. People are reluctant to try something they don't or can't understand, so simplicity is paramount to any electronic payment system hoping for wide spread acceptance.

Commercial business will also demand that transaction costs be low. The value of individual transactions will continue to decline as it becomes economical to transact for specific articles. Companies will only conduct this business if they have a reasonable chance of making profits. Different MicroPayment protocols like Millicent, Netbill etc. have been introduced but still a lot more is desired in this field.
As more and more business is transacted over the Internet, the reliability and accuracy of payment systems is also important. Companies will become more vulnerable to system outages as a larger percentage of their revenues, and in some cases all, come from Internet transactions.