Pretense: A New Threat to Electronic Settlement Systems
Shinsuke MIWA <firstname.lastname@example.org>
This paper proposes that a new threat to electronic settlement systems has developed. 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 made correctly, these systems must communicate correct information about the payment to correct peers. However, on open network systems, the correct peer may not always be designated. That is, when a peer is being designated, 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 cannot 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.
Various Electronic Settlement Systems (ESS) have been proposed and implemented, and various experiments of the ESS in 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 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 correctly communicate 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.
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.
Transactions of the electronic cash system can be divided into the following three steps:
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.
As described above, ESS are systems which correctly communicate the 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, 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.
With two-way authentication technology together with cryptography and electronic signature technology, ESS can prevent existing threats to their 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.
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).
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.
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.
"Pretense" is different from this "Impersonation." The steps to perform "Pretense" are as follows (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.
"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 made 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 is 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.
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 paid. 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.
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.
Generally, the legal basis for demanding a refund is breach of contract. We will consider, for example, the case of a mail order in which 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) (Fig. 5):
With this contract, if the merchant doesn't deliver the ordered goods (5), even if the customer pays (4), the customer can demand a refund for nonfulfillment of the contract.
Contracts on existing ESS differ from this contract. The following steps describe the contract (the payment contract) in transactions on the ESS (Fig. 6):
If "Pretense" were 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 nonfulfillment 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" were 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.
The third point to be discussed is "Pretense" as an imposture. "Pretense" is clearly an imposture. However, 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 occurred 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 in the case that the system administrator of the network system recorded all of the 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 a big economic damage from this threat.
With existing ESS, unless the payee notifies the information to designate the payee to the payer, with the secure network system, "Pretense" cannot be resisted, even if the ESS is designed to be secure. In this chapter, we propose two improvements for ESS to resist "Pretense."
An immediate and intuitive solution for pretense resistance 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":
We shall discuss these improvements in detail below.
First, we shall consider providing traceability of the user in the ESS. In this scheme, if "Pretense" were 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, over the past few years, a considerable number of studies have been made on the ESS which provide anonymity and have mechanisms to cancel the protection of privacy. With such methods, if any injustice were to take place, the user who carries out the injustice can be identified; in other words, these ESS provide traceability.
Therefore, we can conclude that these ESS provide traceability. With this traceability, the pretended payee can be identified.
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 the payee but don't manage that the payer gets 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:
In the first step, the payer concludes the sales contract with the payee. And in the second step, the payer pays the payee according to this contract. In this scheme, the information acquired 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 deferred 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" were to take place.
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 we 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.