Pretense: A New Threat to Electronic Settlement Systems

Shinsuke Miwa (s-miwa@jaist.ac.jp)
School of Information Science
Japan Advanced Institute of Science and Technology

Yoichi Shinoda (shinoda@jaist.ac.jp)
School of Information Science
Japan Advanced Institute of Science and Technology


Abstract
This paper proposes a new threat to Electronic Settlement Systems. Various Electronic Settlement Systems such as secure credit card payment systems, electronic caches and electronic checks do exist, and in order for a payment to be done correctly, these systems must communicate correct information about the payment with correct peers. However, on open network systems, the correct peer may not always be designated. That is, when designating a peer, before two-way authentication can take place, a malicious entity can give false information that can designate the entity as a payee. Notice that because the misdesignation occurs even before the two-way authentication is to take place, the existing Electronic Settlement Systems can not prevent this situation. This new type of threat to Electronic Settlement Systems is named "Pretense" in this paper. Characteristics of Pretense are explored, and two improvements for Electronic Settlement Systems to resist this threat are proposed.

Table of Contents

1. Introduction

Various Electronic Settlement Systems (ESS) has been proposed and implemented, and various experiments of the ESS on the real world have begun in the last few years. Some of these ESS will come into practical use soon. In addition, ESS for open network systems like the Internet are proposed and implemented, and experiments on ESS in the real world have also been undertaken. Some of these may come into practical use in the near future.

To settle, an ESS must correctly communicate the following information regarding "who", "whom" and "how much" about a payment among a payer, a payee and a settlement institution. Because ESS on open network systems are exposed to various security threats (i.e. eavesdropping, interpolation and impersonation), two-way authentication technology which can specify a correct peer is an important technology for the ESS to communicate correctly information about a payment.

Two-way authentication technology assumes that a user can designate a correct peer, and authenticate the correct peer according to this designation. However, on open network systems, this technology cannot always authenticate the correct peer, because the user cannot always designate the correct peer. Therefore, there is a possibility of a new threat that is called "Pretense". In this paper, we point out the drawbacks of existing ESS, and propose two improvements to ESS to resist this threat.

2. Electronic Settlement Systems Overview

Let us summarize the mechanism of the ESS. The mechanism of existing ESS varies from system to system, but they are systems which communicate information regarding "who", "whom" and "how much" about a payment to a finalizing institution.

2.1. Outline of Electronic Cash

Take the mechanism of the electronic cash system (Fig.1)[1][3][6][7][10][12][13][16] for example.

fig1.gif
Fig.1. The outline of Electronic Cash

Transactions of the electronic cash system can be divided into the following three steps.

  1. A user request to issue electronic cash to an issuing institution. The user signs and sends information to the institution: "who" and "how much". According to this request of the user, the institution returns an electronic cash which is signed information about "how much" by the institution. When communicating this information, the user and the issuing institution mutually authenticate each other with two-way authentication technology.
  2. The user (payer) pays the other user (payee) by transferring the electronic cash. The payer sends the electronic cash which is signed "how much" by the issuing institution to the payee. When communicating the electronic cash, the payer and the payee mutually authenticate each other.
  3. The payee request the finalizing institution (called the issuing institution above) to exchange the electronic cash for cash. The payee signs and sends information to the institution: "whom" and "how much" which is signed. According to this request of the payee, the institution verifies the correctness of the electronic cash, and exchanges it for cash. When communicating this information, the payee and the finalizing institution also mutually authenticate each other.
In actual electronic cash systems, transactions are more complicated than described above, in order to provide anonymity and to add the division function. Nevertheless, the essential property of electronic cash systems is that the information of "how much" is passed among the participants, from the payer to the issuing institution, to the payer, to the payee and to the finalizing institution, using two-way authentication to authenticate the correct peer.

2.2. Two-way authentication technology

As described above ESS are systems which correctly communicate the following information about a payment regarding "who", "whom" and "how much", to the correct peer using mutual authentication. Therefore, two-way authentication technology used to specify the correct peer is an essential technology for ESS on open network systems.

In closed network systems like a value added network(VAN) and the electronic marketplace on open network systems[11][18], in which the network system and the marketplace can be given the function of two-way authentication, two-way authentication technology isn't very important to ESS.

On the other hand, in an open network system like the Internet, because communication paths are exposed to various attacks (i.e. eavesdropping, interpolation and impersonation) by malicious entities, ESS are naturally exposed to these attacks. The "impersonation" must especially be prevented in ESS, because economic damage can be exerted on the user. Therefore, two-way authentication technology to prevent "impersonation" is vital in this environment. There are additional requirements for two-way authentication for ESS. One such requirement is anonymity support. Because two-way authentication can expose privacy regarding the settlement of the user, some technology to protect privacy is necessary. To solve this problem, the technologies listed below are applied on existing ESS.

Another requirement is to restrain the use of ESS for crimes and money laundering. Newer ESS have complicated mechanisms to cancel the protection of privacy when injustices are detected.

3. A new threat to Electronic Settlement Systems: "Pretense"

With two-way authentication technology together with cryptography and electronic signature technology, ESS can prevent existing threats to there security, such as eavesdropping, interpolation and impersonation. However, on the open network system, a new threat to ESS that we name "Pretense" does exist. In this section, we will discuss "Pretense" in detail.

3.1. Designation of the correct payee

In the ESS on open network systems, a payer pays a payee as follows: the payer designates the payee, authenticates mutually and communicates information about the payment. In other words, the ESS on open network systems are composed of "designation", "authentication" and "communication" (Fig.2).

fig2.gif
Fig.2. The communication of payment on the ESS

The question now arises in the "designation"; on the open network system, the payer cannot always designate the correct payee. If the payer already knows the correct payee, the payer never designates the wrong payee. Although, if the payer doesn't know the correct payee, it is difficult for that payer to designate the correct payee, because the payer cannot always specify who is the correct payee.

For example, let us consider the case that the payer designates the payee with a payee ID. If the payer receives the ID of the correct payee, the problem doesn't occur. However, if the ID of the correct payee is altered, the payer then receives the wrong ID. With this scheme, if a malicious entity can alter the correct ID to its ID, the entity can receive the payment as a correct payee.

3.2. Difference between "Impersonation" and "Pretense"

The malicious entity, as mentioned above, can alter information that designates the correct payee. This injustice should be distinguished from "Impersonation", and we call it "Pretense". Now we shall focus on difference between "Impersonation" and "Pretense".

Figure 3 illustrates how impersonation is done. In this figure, "Impersonation" is done as follows:

Until the payer or the correct payee suffers any economic damage, this injustice cannot be detected. If the payer correctly authenticates the payee, this injustice can be prevented.

fig3.gif
Fig.3. Impersonation

fig4.gif
Fig.4. "Pretense"

"Pretense" is different from this "Impersonation". The Steps to perform "Pretense" are as follow(Fig.4):

If the payer has knowledge of the correct payee, the payer knows that the pretending payee is the wrong payee. Notice that even if the payer correctly authenticates the payee, this injustice cannot be prevented.

3.3. Threat arising from "Pretense"

"Pretense" on ESS is an injustice in which the pretending payee is paid unjustly as the correct payee. Existing ESS only guarantee that the right payment is done to the payee who is designated by the payer, and it does not distinguish whether or not the payer designates the correct payee. In other words, on the ESS, anyone who was designated by the payer is the correct payee. Hence, if a "Pretense" was to take place and the payer designated the pretending payee, the pretending payee can be paid the right payment. We can conclude that existing ESS cannot prevent "Pretense".

Now, let us examine the case that the payer notices that the pretended payee was not the correct payee after paying, will the demand for a refund by the payer be impossible? In this section, we shall discuss this problem in detail.

3.3.1. Identify the pretended payee

The first point to be discussed is to identify the payee. When the payer notices that the pretended payee is not the correct payee, the payer must identify "whom" the payer payed. On an ESS which does not provide anonymity, the payer may be able to identify the pretended payee by negotiating with its system administrator for provision of information about the payee.

However, because most of existing ESS provide anonymity to protect the privacy of settlements, even if the payer negotiates with the system administrator for provision of information about the payee, the payer cannot identify the pretended payee. Because the payer cannot get the necessary information, the payer naturally cannot demand a refund from the pretended payee.

On newer ESS[1][10][12][13], if any crime was to take place, the privacy of settlements of criminals can be exposed. With this scheme, the payer can identify the pretended payee.

3.3.2. The legal basis of a refund

The next point to be discussed is the legal basis of the refund. Assuming that the payer can identify the pretended payee, the payer must demand a refund from the pretended payee based on the fact that the payer paid the wrong payee. However, the question is whether or not the legal basis of this refund does exist.

fig5.gif
Fig.5. The contract of generic mail-order

Generally, the legal basis for demanding a refund is breach of contract. We will consider, for exampe, the case of a mail-order that the bill is paid but the ordered goods were not delivered from the mail-order house. On the mail-order, there is generally a contract (a sales contract) that is described in the following (Fig.5).

  1. Presentation of the goods (Merchant presents a intention of contract)
  2. Order (Customer confirms Merchant's intention of contract, and presents a intention of contract)
  3. Receipt of the goods (Merchant confirms Customer's contract will)
  4. Payment (Customer fulfills the contract)
  5. Delivery of the goods (Merchant fulfills the contract)
With this contract, if the merchant doesn't deliver the orderd goods (5) even if the customer pays (4), the customer can demand a refund for non fulfillment of the contract.

fig6.gif
Fig.6. The contract of the ESS

Contracts on existing ESS differ from this contract. The following steps describe the contract (the payment contract) in transactions on the ESS (Fig.6).

  1. Presentation of the payment will (Payer presents a intention of contract)
  2. Presentation of the receipt will (Payee confirms Payer's intention of contract, and presents a intention of contract)
  3. Payment (Payer fulfills the contract)
  4. Receipt (Payee fulfills the contract)
If "Pretense" was to take place, the pretending payee receives the payment (4). In this scheme, because the pretended payee fulfills this contract even if the payee doesn't deliver the ordered goods, the payer cannot demand a refund for non fulfillment of the contract.

There is a case against this scheme: "There is no sales contract on the ESS. However, before the payer pays with the ESS, the sales contract should have been made". However, unless the payer can prove the link between the payment and the sales contract, the payer cannot prove breach of contract. The conclusion of this argument is that because the existing ESS is the payment system without the sales contract, the refund cannot be demanded on breach of contract.

Therefore, if "Pretense" was to take place on ESS, because the payer cannot be refunded, the payer suffers from some economic damage and the pretended payee makes some profit.

3.3.3. "Pretense" as an imposture

The third point to be discussed is "Pretense" as an imposture. "Pretense" is clearly an imposture. Although, to establish the "Pretense" as an imposture, the fact that the "Pretense" actually took place must be proved.

Because existing ESS are systems which correctly communicate information about the payment regarding "who", "whom" and "how much" to the correct peer (see Section 2), the ESS cannot prove that the payment except for "who", "whom" and "how much". In other words, the ESS cannot prove that the "Pretense" took place. In the case that the payer recorded all about the payment with the evidence, or the case that the system administrator of the network system recorded all of communications, "Pretense" may be able to be proved. However, ESS can do nothing in these cases.

As a consequence of the argument presented in this section, we can conclude that existing ESS can do nothing against "Pretense". However, ESS must resist "Pretense", because users may suffer from a big economic damage from this threat.

4. Improvements to ESS to resist pretense

With existing ESS, unless the payee notifies the information that to designate the payee to the payer, with the secure network system, "Pretense" cannot be resisted, even if the ESS is designed secure. In this chapter, we propose two improvements for ESS to resist "Pretense".

An immidiate and intuitive solution for pretense resistancy would be to incorporate characteristics of ESS on a closed network system as listed below.

However, in open network systems, unless the payee is specified, pretense cannot be prevented completely. We propose the following two improvements for ESS that help this function to resist "Pretense".
  1. Provide traceability.
  2. Provide the contract function.

We shall discuss these improvements in detail below.

4.1. Providing traceability

First, we shall consider providing traceability of the user in the ESS. In this scheme, if "Pretense" was to take place, because the payer can identify the payee, the refund can be demanded on a legal basis based on the contract if there is one.

The electronic check and secure credit card payment systems don't provide anonymity, so they are already providing traceability. In addition, considerable number of studies have been made on the ESS over the past few years which provide anonymity and have mechanisms to cancel the protection of privacy[10][12][13]. With such methods, if any injustice was to take place, the user who carries out the injustice can be identified, namely, these ESS provide traceability.

Therefore, we can conclude that these ESS provide traceability. With this traceability, the pretended payee can be identified.

4.2. Providing the contract function

Even if ESS provide traceability, the refund cannot be demanded if there is no contract. Hence, the next point to be discussed is the provision of the contract function.

The contract function is a function to make the legal basis of the refund clear. We can consider that the settlement is not only payment, but additionally includes the sales contract. This is because, if the payer pays the payee, the payee must pay in consideration of the payment to the payer in the settlement. This is a primitive sales contract without a written contract.

The problem here is that existing ESS manage only the payment. In other words, ESS manage that the payer pays to the payee but don't manage that the payer get the corresponding value. To resist "Pretense" the sales contract which is the legal basis of the refund is necessary as mentioned in Section 3. Therefore, we shall consider the ESS which can manage the sales contract.

The transaction on the ESS which is improved to be able to manage the sales contract may be divided into the following two steps.

  1. Conclude the sales contract.
  2. Payment.
In the first step, the payer concludes the sales contract with the payee. And in the second step, the payer pays to the payee according to this contract. In this scheme, the information aquired in the first step must be included in the communication in the second step. The reason is that if "Pretense" is to take place, the payer must prove the link between the sales contract and the payment.

With this scheme, because steps 1 and 2 can be separated, the deffered payment can be realized like the settlement with cash. In addition, because the payer can prove the link between the sales contract and the payment, the payer can demand the refund if "Pretense" was to take place.

Notice that the ESS which is improved to provide the traceability and the contract function cannot prevent "Pretense" but it can resist it.

5. Conclusion and Future work

This paper pointed out a new threat to ESS on open network systems that we named "Pretense" (section 3). By examining both technical and legal aspects of "Pretense", we have concluded that the existing ESS cannot resist "Pretense" (section 3.3), and have proposed two improvements; traceability (section 4.1) and contract function (section 4.2). With these improvements, the ESS can be made "Pretense Resistant".

Because open network systems cannot always guarantee the delivery of contract information, we are confronted by a difficulty which is called "the confirmation of the reaching". Therefore, how to implement an actual contract on open network systems is a question which we must consider. We are currently working on this problem.

References

  1. J. Camenish, J.M. Piveteau, and M. Stadler, An Efficient Fair Payment System, In Proceedings of 3rd ACM Conference on Computer Communications Security, 1996.
  2. D. Chaum, B. Boer, E. Heyst, S. Mjolsnes, and A. Steenbeek, Efficient off-line checks, In Proceedings of Eurocrypt '89, 1989.
  3. D. Chaum, A. Fiat, and N. Naor, Untraceable electronic cash, In Proceedings of Crypto '88, 1988.
  4. W. J. Clinton and A. Gore, Jr, A Framework For Global Electronic Commerce (http://www.iitf.nist.gov/eleccomm/ecomm.htm).
  5. CyberCash, Inc., CyberCash Home Page (http://www.cybercash.com/).
  6. DigiCash, Inc.,DigiCash home page (http://www.digicash.com/).
  7. S. Even, O. Goldreich, and Y. Yacobi, Electronic Wallet, In Proceedings of Crypto '83, 1983.
  8. First Virtual Holdings, Inc., First Virtual Homepage (http://www.firstvirtual.com/).
  9. FSTC, FSTC Electronic Check Project (http://www.fstc.org/projects/echeck/index.html).
  10. E. Fujiaki, and T. Okamoto, Practical Escrow Cash Systems, ISEC 95-46, March 1996.
  11. Open Market, Inc., Open Market Software Products (http://openmarket.com/products/).
  12. S. Miwa, The endorsable electronic bank note -- A currency on the Internet --, In thesis for master's degree, Japan Advance Institute of Science and Technology, 1997.
  13. S. Miwa and Y. Shinoda, The Negotiable Electronic Currency System on the Internet, Internet Workshop ' 98(IWS'98), in proceedings of The International Workshop on Asia-Pacific area advanced research information sharing technology, 1998.3
  14. Mondex International Limited, Mondex International (http://www.mondex.com/).
  15. USC/ISI's GOST group, The NetCheque network payment system (http://nii-server.isi.edu/info/NetCheque/).
  16. T. Okamoto and K. Ohta, Universal electronic cash, In Proceedings of Crypto '91, 1991.
  17. VISA, MasterCard, Secure Electronic Transaction (SET) Specification Ver.1, May 1997.
  18. Open Trading Protocol Consortium, Open Trading Protocol