Security analysis of Micropayment system

By | January 1, 2016

 What is a Micropayment system?     

Micropayment system provides a means of transferring small monetary amounts and serve as a convenient alternative to traditional payment arrangements. Micropayments refer to low value electronic transactions.

           MicroPayment Systems(MPS)  have been developed in the past decade, but for various reasons, have not yet penetrated the market deeply. The critical mass of users will probably be reached very soon in some industrial countries where Internet has a deep penetration. This has an effect in the fragile balance between the defenders and the offenders of computing systems. There is a need to analyze this new player  and understand the new issues that arise by the introduction of MPSs to our everyday life.

1. Introduction

The electronic payment mechanisms of today have been designed for handling payments of value over five dollars. It, however, seems that these systems cannot manage a large amount of payment transactions below that value level in parallel very well. Together with the envisioned new opportunities in e-commerce, the difficulties have lead to the development of completely new electronic payment mechanisms such as micropayments that have been envisioned to bring solutions to these problems. To meet sufficient security for all participants in electronic commerce, a micropayment system makes it possible to make small payment through electronic communication networks.

The micropayments have special characteristics and requirements, distinct from those set for electronic payment systems in general. Micropayment system provides a means of transferring small monetary amounts and serve as a convenient alternative to traditional payment arrangements. Micropayments refer to low value electronic transactions. They provide an alternative revenue source for content providers beyond advertising and subscriptions (W3C). They may also provide revenue streams for service providers. The new micropayment system is developed using a tamper-resistant device (i.e., smart card), an efficient Message Authentication Code (MAC) technique, and the concept of overall network security.

Micro-payment system involves:

  • A buyer / client
  • A vendor / data editor
  • One or more brokers / intermediates / billing servers

A micro-payment system has buyers, sellers, and a broker. The buyers establish accounts with the broker and provide payment information allowing the broker to invoice the buyers. The sellers establish accounts with the brokers and specify terms for accessing items, including electronic content, available from the sellers. The sellers also provide payment information that allows the broker to credit the sellers for sales of the items. The broker aggregates the buyers’ micro-payment purchases and invoices the buyers. The broker also aggregates the sellers’ micro-payment sales and credits the sellers.

There are two fundamental ways of managing Micropayment systems:

  • on-line payments – in which the seller verifies the payment sent by the buyer with a bank before serving the buyer.

Eg:  NetBill, NetCash, MiniPay, MilliCent use on-line or semi-online type of payment validation, which is costly in general.

  • off-line payment – in which the double spending is prevented by some previously executed operation, therefore no on-line connection to the bank is required.

Eg: Millicent transactions are not anonymous and mostly off-line. PayWord is an off-line, extremely efficient, credit-based micro-payment scheme

The basic architecture of a micro-payment system consist of:

On the client side:

  • A browser,
  • A module which is communicating with the micro-payment server
  • One or more electronic wallets

On the vendor side:

  • An HTTP server

E-Commerce covers a broad spectrum of transactions varying from macro-transactions to micro transactions. In macro-transactions, while the value of each transaction is very high, the challenge lies in providing a higher grade of authentication, payment security, and non-repudiation of transactions. In case of micro-transactions, while the need is to cater to a large volume of transactions of low intrinsic financial value, the challenge is to keep the cost of each transaction to a minimum on an average. Micro-transactions include Internet-enabled services like streaming multi-media, accessing computational power from grids, loadable softwares etc.

minipayments, is used in parallel with the word micropayments. In this case the micropayments refer to sums perhaps under one dollar, while the term minipayments are defined as payments larger than micropayments, but smaller than the traditional payments, e.g. credit card transactions, which are typically the size of 80 dollars in average.

2. LITERATURE  SURVEY

The generation of micropayment systems began around 1994. There are two generations of Micropayment systems. The first one lasted until the end of the 1990s. The second one begins in 2000.

The first generation systems, most of them were based on token based system and very few based on account based systems. Token-based systems use tokens or e-coins, which provide buying power. In general, customers buy‚ tokens from a broker to pay the merchants. Afterwards, merchants send the received tokens to the broker that pays‚ the merchants. In account-based systems customers and merchants have accounts at a broker or bank, and customers authorize the broker to transfer money to merchant accounts.

The second generation were based on account based where system is accessible from any computer connected to the Internet and the portability issue is solved on t developers of these systems primarily aimed at the introduction of the electronic form of cash (called e-cash, e-coins, digital cash or tokens) on the Internet. They focused on the generation of e-coins or tokens, secure, anonymous and untraceable exchange of them, validation and fraud avoidance.

           Interoperability between first generation micropayment systems was never provided nor addressed. Token-based systems created their own currencies (e.g., e-coins, scrip, subscrip, payword, coupons, merchant-specific tokens) and did not define exchange rules or rates. Some systems, e.g., SubScrip, needed extensions enabling customers to withdraw their money and exchange them back to US$. Another example is Millicent, requiring customers to buy specific scrips for each merchant they wanted to pay. another example is ECash, positioned as a system offering the possibility to pay anywhere on the Internet. ECash licenses, however, covered only the customers and merchants of a particular bank, so customers could pay only merchants that were affiliated to the same bank.

3. PRESENT THEORY AND PRACTICES

Presently the Micropayment system is  based on the account based technique used for low value products such as online music and videos and the role of micropayment systems for selling such products are expected to grow substantially and the all MPS systems use the online validation. And do not use the heavy security measures but uses transparent security techniques makes the systems easy to maintain.

There are, however, also other actors or groups of actors in the micro-payment world. They are

  • Industry actors are the ones that handle the financial information, like banks, and the ones that develop the hardware and software needed to set up the mechanism.
  • Governments – national and multi-national – control the legal framework in which the micropayment systems can operate.
  • users – consists of both merchants and individual customers purchasing and selling intangible goods.

New efficient and secure micro-payment scheme, named e-coupons, which can provide the users the facility of delegating their spending capability to other users or their own devices like Laptop, PDA, Mobile Phone, and such service access points. The scheme has the promise of becoming an enabler for various Internet-based services involving unit-wise payment. It gives flexibility to the users to manage their spending capability across various access points for a particular service without obtaining an authorization for each and every access point from a facilitating bank. This flexibility which is not present in the existing micro-payment schemes is essential for accessing ubiquitous e-services and other Internet-based applications. e-coupons is based on PayWord, a single-seed one-way hash chain for unit-wise payment, TESLA for payment security and SPKI/SDSI as underlying PKI framework for its unique delegation feature.

Another a new fair micropayment system based on hash chain, which is an offline, prepaid system and supports divisibility of digital coins in a simpler way. hash chain can be used to have transactions with different merchants. Compared with other micropayment schemes, e.g. Pay Word, no public-key operation is required, which improves the efficiency of our system. In addition, restricted anonymous can be provided.

4. MICROPAYMENT SYSTEMS ANALYSIS

Four digital money systems were chosen. These are:

1)       CyberCashs CyberCoin

2)       DigiCashs  eCash

3)      Digitals Millicent

4)       METEORE

These systems have provided leadership, creativity and understanding of the markets micro-payment needs. As it will be seen they provide different solutions to the micropayment transaction problems, hence they were chosen for this analysis. The subsequent sections characterize these schemes using the following criteria:

1. General Concept Description

2. Ease of Use

3. Anonymity & Privacy

4. Security

General Concept

1.CyberCashs CyberCoin:

CyberCash is an electronic credit card scheme CyberCoin services are distributed through banks, which offers online merchants the CyberCoin service and offers consumers co-branded “Wallets.”

To be able to purchase an item, the buyer first sends a payment order to the merchant who forwards it to CyberCash Gateway Server for verifying. Both buyers and merchants have an electronic wallet of their own. The wallets are required for bookkeeping the financial information of the parties.

CyberCashs CyberCoin System

CyberCashs CyberCoin System

The flow of Money of CyberCashs CyberCoin method is shown in the figure(a) above are,

  1. To be able to use CyberCoin system the buyer must have executed an off-line withdrawal of electronic money onto the wallet.
  2. The buyer wishes to initiate a purchase by contacting the merchant.
  3. The merchant receives this request and sends the buyer the electronic merchandise encrypted with DES (Data Encryption Standard – a block cipher developed by IBM in mid 70’s), without the corresponding DES key.
  4. The buyer confirms the purchase and acknowledges that he has received the purchase request data by sending back the notational order which contains the financial information about buyer’s account. This transferred data must be hidden from the viewpoint of the merchant.
  5. The merchant sends this payment order to Cyber Cash for verifying purposes.
  6. Then Cyber Cash sends its approval to the merchant if the payment order is valid. It should be noted that Cyber Cash need not contact the actual bank for this transaction because Cyber Cash maintains the equivalents of the accounts of both the buyer and the merchant. The buyer’s and the merchant’s wallet balances are adjusted according to the payment value of the purchase.
  7. Finally, the merchant can send the DES key to the buyer who can decrypt the previously received encrypted digital goods.

2.DigiCashs eCash:

This system is based on what is called a single user token system. This system often called as in-line System where the authentication of users is done.

The flow of Money of Digicashs   eCash method is shown in the following steps as,

  1. The user generates blinded electronic bank notes and sends them to his bank to be signed with his bank’s public key (PK).
  2. The bank signs the notes, deducts the amount from the user’s account, and sends the signed notes back to the user.
  3. The user removes the blinding factor and uses them to purchase at the shop.
  4. The shop verifies the authenticity of the bank notes using the bank’s corresponding public key and sends them to the bank where they are checked against a list of notes already spent.
  5. The amount is deposited into the shop’s account, the deposit confirmed, and the shop in turn sends out the goods.
  6. All communication over the network is protected by encryption.

The system involves software for both the consumer and the merchant to conduct the transactions. The customer runs a “wallet” program. 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.

3.DECs Millicent:

Millicent is a decentralized micro-payment scheme, which is designed to allow payments as low as 1/10 of a cent. It uses a form of electronic currency, which is called scrip.

Scrip is an electronic manufacturer coupon that has a pre-paid value, just like the conventional cash does. It has an intrinsic value, but it is valid only with a specific vendor. In other words, it can be spent only in the context to which it was originally meant.

DECs, It is designed to make the cost of committing a fraud, more than the value of the actual transaction. It uses symmetric encryption for all data transactions. Millicent transactions are not anonymous and mostly off-line.

Millicent is perhaps the smallest and simplest implementation of the contemporary systems. The mechanism is basically a very simple protocol for two participants which is extended in the realm of systems to cover a multitude of payment situations. It is, however, designed for the handling of a series of inexpensive and casual transactions.

The principal actors of the scheme are the Broker, the Customer and the Vendor. Figure (b) demonstrates the scheme.

Millicent Scheme for micro-payment system

Millicent Scheme

1.The Broker :

The Broker mediates between Vendors and Customers in order to simplify the tasks they perform. He acts like a bank and provides the electronic currency (scrip) for the micro-payments. A Broker, after coming to a deal with the Vendor, can either generate his own valid Vendor-specific scrip, or buy a large amount of scrip, from the Vendor, using a macro-payment system. The Broker is then selling the scrip to the customers via micropayment transactions. During Customer purchases (either from Broker or Vendor), no transactions between the Broker and the Vendors are taking place

2.The Customer:

The Customers buy scrip from the Brokers, using real money, via a macro           payment system. The amount should be sufficient to cover the transaction cost plus to produce financial gain for both the Broker and the Vendor (scrip is Vendor specific). The Customer can then use the scrip to perform micro-payment purchases. No transactions with real money are taking place in any given time between Customers and Vendors.

3. The Vendor :

The Vendor is the data bank. He supplies customers with data, services or both. He accepts his specific scrip as the only method of payment. The scrip was either generated by him (the Vendor) or by a licensed broker. After that the Vendor can transmit the requested data back to the Customer, using a given encryption algorithm for avoiding fraudulent use.

One purchase scenario in Millicent could go like this:

1. The customer sends a request to the broker for specific vendor scrip along with the broker scrip bought previously.

2. The broker sends the vendor scrip back along with the possible change in the form of a new broker scrip.

3. The customer sends the scrip to the vendor.

4. The vendor accepts the scrip, delivers the service and sends back the possible change in the form of a new vendor scrip.

5. The customer sends the possible vendor scrip to the broker.

6. The broker changes it back to a broker scrip and sends it back to the customer.

4. METEORE :

METEORE is a unified Internet/mobile payment solution for contents and services, to be used in the so-called “Mobility Portals”. A mobility portal is defined as Web/WAP information based system, which provides information or services related to mobility:

– Information’s related to a geographical position (which can be the position of the consumer or the one specified by him) or movement (how to go from a point to another one)

– Services like ticketing (entertainment, reservation, parking, etc.)

– Emergency services: reception of SMS signaling events (strikes or delays for travels, stock    exchange conditions, etc.)

– Advertisement and advantages related to position or interest profile of the end-user.

A mobility portal has the major characteristics to address multiple terminals: fixed terminals like PC’s or mobile terminals like mobile phones or PDA’s. It also addresses multiple payment modes: aggregated and single payment.

The following figure(c) illustrates the high level architecture of the METEORE system.

  1. The client can access the sites of on-line sellers to buy coupons, which are stored in the CPS.
  2. The client can then buy e/m contents using these coupons, which the CPS authenticate with an intermediary bank.
  3. Alternatively the client can pre-pay the bank and create an account with Micro-COMM.
  4.  The client can then use the CPS to buy e/m contents from online sellers, without dealing with the bank at all.

The core system architecture combines an authentication layer at the core payment system that connects to an aggregation engine and a single payment gateway that interfaces to an external payment system in charge of authorization and money transfers.

Other important functional blocks are:

Web back-offices: merchant back-office, consumer front-office, system/application back-office, that are all implemented as https portals.

The Core Payment System offers both aggregated and single payment mode, the authentication depending from the terminal capability. The METEORE model does not specify how the back-offices and front-offices work but only state their existence. Each implementation will use its specific interfaces.

METEORE - Micropayment system

METEORE system

Ease Of Use

This section examines the actions/steps a customer has to undertake in order to use the system. Usability is often described as the ability to use certain system smoothly and easily, without considerable familiarizing with the user interface of the system.

Ease of use or convenience relates to both subscription to and usage of a system for both new and experienced users, and typically relates to underlying hardware and software systems.

The actions/steps a customer has to undertake in order to use the system, and how complex these steps are. The section was summarized in table 1

Systems

 

Cybercoin

 

 

 Ecash

 

 

 Millicent

 

 METEORE

 

 Relationship

 

Customer and merchant needs to establish a relationship with a bank that supports the CyberCash Wallet and the CyberCash system respectively.

 

Customer needs to establish a relationship with a bank that supports the Digicash system.Vendor needs to establish relationship with the Digicash system. 

Client enter into long-term relationships with brokers. Brokers buy and sell vendor scrip as a service to Clients and vendors. 

Client has to register with a bank that is using the system. Vendors have to register with system and bank.

Anonymity & Privacy

micro-payment systems have to provide amongst other things anonymity and privacy for every single      transaction. They are considered to be two of the most important features of any system making transactions.

Anonymity concerns the amount of knowledge other parties have of others (see Parameter secrecy). Merchants or banks usually have no anonymity, while customers may have at least partial anonymity.

Privacy relates to the protection of personal and payment information. A payment system provides privacy protection depending on the type of information. Pre-paid or post-paid determines how customers use a payment system. Pre-paid systems require customers to transfer money to the system before they can initiate micropayments. Post-paid systems authorizes customers to initiate micropayments up front and pay later.  For example,The contemporary systems – like credit card and cheque based payment systems – have usually compromised the security by giving full anonymity only to the merchants, while the user has been offered only partial anonymity . The degradation of anonymity enhances the traceability(The traceability of payment systems is a useful feature and basically a must for merchants, since any criminal or abnormal action should be noted as quickly as possible)of the transactions .

                                          Anonymity                                                   Privacy

CyberCoin                                No                                                           Yes

Ecash                                        Yes                                                           Yes

METEORE                               Yes                                                           Yes

Millicent                                   Depends on Protocals

  1. CyberCoin: The Client always has a record of his or her transactions and can prove them, but the Vendor will not know the Clients identity unless the Client reveals it.
  2. ECash: unlike paper cash, is unconditionally untraceable. The computations carried out by the Clients PC makes it impossible for anyone to link the payment to payer. Clients can prove that they did or did not make a payment, without revealing anything more. This level of privacy limits exposure to future data-privacy legislation and reduces record-keeping costs.
  3. Millicent: three distinct protocols enable different levels of privacy (and security) according to customer’s needs.

  • Scrip in the clear: No network security is provided. The scrip is not getting encrypted. The purchased data are not getting encrypted either.
  • Encrypted connection: The scrip is getting encrypted using a symmetric algorithm. The encryption key uniquely identifies the Customer and the transaction. Data are getting encrypted as well.
  • Request signatures: Digital signatures are being used for uniquely identifying the transaction and the customer. Faster than the previous protocol because no encryption is taking place.

 Security:

Security prevents and detects attacks on a payment systems and fraud attempts, and protects sensible payment information. It is needed because attacks and attempts for misusing a payment system to commit fraud on the Internet are common.   Security is to a certain extent a subjective concept, and felt differently by each user. Users often interpret security as an equivalent for guarantee customers feel secure if they receive the paid products, while merchants feel secure if they get the money for the delivered products.

The main security concerns are the non-repudiation, authentication and authorization, data integrity, and confidentiality. The security of micropayment system depends on the underlying trust and security models applied.

Cyber Coin: the financial information is encrypted and digitally signed, but the message itself is not.

eCash: provides the highest security possible by applying public key digital signature techniques. who could make payments without merchants and ECash banks being able to find out the identity of the customers. Additional security features include the protection of eCash withdrawals from the Clients account with a password that is only known to him  not even to his bank.

Millicent: Each transaction requires that the customer know 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.

METEORE : All transactions are done in XML, are digitally signed using a PKI, and are using an encrypted (128bit key) SSL carrier. The network itself is secured with firewalls and NIDSs, following a‚ no-man ‚architecture. The administration is done remotely using SSL and X509 certificates, and the integrity is achieved using mirroring and backup techniques.

5. MICRO-PAYMENT TRANSACTIONS

 The Transactions consist of  commonly 2 entities i.e A Customer and  A Merchant.

  • The broker is the party that provides and/or holds the electronic currency.
  • The vendor is the party that provides the e/m contents.

The following general transaction categories are taking place in the above MPS:

1. Broker & Vendor:

Must trust each other. The Vendor should provide what the Broker has promised to the Client. The Broker must pay the Vendor for the used scrip2. Both parties must have the same security procedures and patterns, as a chain is as secure as its weakest link.

 2. Client & Broker:

The Broker must comply with standards as he is holding personal information. Data   security is of the essence as the client trust is what keeps Brokers in business. The transactions between these two players are macro-payment transactions. Broker has to apply relevant security solutions to the following problems: Privacy infringement, Authentication, Repudiation, Integrity, Denial of service, The Broker must provide the Client with valid scrip.

 3. Client & Vendor :

The Vendor must be able to authenticate and validate the scrip. The Vendor must always be able to provide data (denial of service, interception problem).

As with all systems we thrive for confidentiality, integrity availability, and non-repudiation. These concepts constitute three of the four goals of information security

  • Confidentiality: Assets must be accessible by authorized parties, hence

 Clients private data must remain private in Brokers database (database security, transaction security).Clients scrip should not be stolen by third parties (transaction security, encryption issues).

Scrip: electronic currency or other feature that is used as electronic currency from the MPS.

  • Integrity: Assets can be modified by authorized parties and in authorized ways, hence:

   Brokers must issue valid scrip (trust, forgery issues).Scrip can only be generated by valid Brokers (authentication, repudiation).Vendors data cannot be modified by third parties (database security, transaction security, encryption issues).

  • Availability: Assets must always be accessible to authorized parties, hence:

 Broker must always be able to generate and supply scrip to clients (denial of service issues, software & hardware protection issues) Vendor must always be able to supply data to valid clients (denial of service issues)

The summary table of the micro-payment systems of today.

System /
Characteristic
CyberCoin MilliCent eCash
Independence No, PC is the only solution. Limited by the regulation in the U.S. where it can only be used. Interacts with the actual banking network. No, PC is the only solution. No, PC is the only solution.
Wallet: Windows 95/98/NT
Design Centralized notational Centralized token Single user

Distributed token

Security High, CyberCash performs checking, clearing and recording of transactions, thus offering strong security. Medium, based on light encryption issuer specification. Small values make light encryption secure enough to prevent infringement. Very High, eCash  provides the security by applying public key digital signature techniques. who could make payments without merchants
Privacy Low, neither anonymous nor private. CyberCash records identities, exchanged amount and time of a transaction. Buyer’s information is hidden to the merchant. Purchased item is not necessarily known by CyberCash. Medium, the broker knows who and where but not what. The vendors know what but not who. High, Clients can prove that they did or did not make a payment, without revealing anything more. This level of privacy limits exposure to future data-privacy legislation and reduces record-keeping costs and anonymity is supported
Trust None Buyer trusts broker and merchant None
Transferability Low, no way to move money to someone else’s account. Payment orders are related to a specific merchant only. Medium, scrip can be transferred freely but only used at specific sites. High, not transferable between customers. Designers are planning to support peer-to-peer transactions.
Divisibility High, since it is a notational system, the cash is fully divisible. Transactions between $.25 and $10.00. High, micropayment from a fraction of cent even near infinite towards the lower bound and at above $1000 at the upper bound. Very low transaction costs. Very high, The value of the transaction is given as text and can thus be infinitely large or very small. Accuracy according to the lowest denomination of real currency used.
Multi currency No, only one currency $. No, must match with scrip. No.
Ease of use Medium, easy to use. The ease of installation not known. Medium, complicated to set up, easy to use. Medium, easy to use.
On-line/off-line On-line, only. The merchant must contact CyberCash for checking within every purchase. Some time On-line, and some time off-line. On-line, is partly possible within recommended offline limit

 6. CONCLUSION

The above discussion mainly deals with the key characteristics of micropayment systems the actors of the MPSs. These systems have supported an efficient, secure and anonymous micro-payment system. The different transaction money systems are helps in providing the well advanced security to the system. These systems have provided leadership, creativity and understanding of the markets micro-payment needs. The analysis shows that these above systems have provided a better chance for success of worthy security and these systems become the bases for the further generation of the Micropayment systems. Even these  models lack some essential features and have disadvantages considering an ideal micropayment system. Therefore perhaps a successful micropayment system should have features from all of these systems.

Please Share: Tweet about this on TwitterShare on FacebookShare on Google+Share on RedditPin on PinterestShare on LinkedInDigg thisShare on StumbleUponShare on TumblrBuffer this pageShare on VKEmail this to someone

Leave a Reply

Your email address will not be published. Required fields are marked *