Patent Application
20090327142
In commercial transactions, fairness needs to be guaranteed in any acceptable model. This is difficult in an electronic world because receiving the goods from a merchant and getting the payment in exchange cannot occur simultaneously in a distributed system; any protocol used in a network is asynchronous by nature.
This leads to a number of attacks, which have been well researched, and generally conclude that a trusted third party is required to achieve fairness. Simple fair exchange protocols need an active trusted third party (trusted third party) which gets involved in every message exchange. More sophisticated types of protocols are referred to as optimistic protocols, in which a trusted third party is not involved unless there is a dispute, which occurs infrequently. In the above optimistic protocols, a buyer exchanges his signature instead of virtual money. After the exchange, the merchant can use the signature to get money from a bank. As a result of the trusted third party only being occasionally involved, that is, when there is a dispute, optimistic protocols are more efficient. However, note that such optimistic protocols do not protect the buyer's privacy.
In order to solve this problem, there is described the use of e-coins for payment instead of a buyer's signature, where e-coins comprise an untraceable fair payment protocol with an off-line trusted third party. The protocol uses an untraceable offline e-coin and a new primitive referred to as a restrictive confirmation signature scheme (RCSS), in which a signature is confirmed by a designated confirmer, and can be verified only by some specified verifiers.
However, a dishonest merchant may collude with a conspirator to obtain the digital money without delivering the goods to a buyer, essentially taking advantage of the lack of a link between the RCSS-signed order agreement and the buyer's e-coins. To this end, the merchant can send his conspirator's RCSS-signed order agreement and the buyer's pseudo-e-coins in the dispute stage, whereby the trusted third party sends the e-goods to the conspirator, and the real e-coins to the merchant, but nothing to the buyer.
Although there is a proposed solution to the above collusion attack, that improved solution as well as the original solution suffer from a new type of attack, referred to herein as an unconscious double-spending (UDS) attack. More particularly, by exploiting the fact that e-coins can be duplicated unlimited times but are allowed to be spent only once, an unconscious double-spending attack can make an innocent buyer unconsciously spend the same money twice.
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which an optimistic fair payment protocol provides fair payment while resisting an unconscious double spending attack and other attacks. In one aspect, a buyer receives encrypted e-goods from a merchant as part of a transaction, and sends payment to the merchant. If decryption information is not received from the merchant in exchange for the payment, the buyer launches a dispute with a third party dispute resolution service in response, which can provide other decryption information or a refund.
If the decryption information is received, the buyer uses the decryption information to determine whether the encrypted e-goods received from the merchant are useable with that decryption information. If not useable, the buyer launches a dispute with the third party dispute resolution service which can provide other decryption information or a refund.
If the decryption information is received and is useable, the buyer determines whether the e-goods received from the merchant are valid, according to a description of those e-goods. If not valid, the buyer launches a dispute with the third party dispute resolution service including providing the goods (a copy) with a description of those goods. The third party uses the description to evaluate the validity of the goods; if valid, payment is released to the merchant, while if not valid, a refund is returned to the buyer.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards an optimistic fair payment protocol built on top of standard symmetric and asymmetric encryption primitives, signature, and e-coin schemes. The protocol resists the unconscious double spending attack and other attacks. In general, fairness is provided in that the buyer receives electronic goods (e-goods) if and only if the merchant gets the electronic coins (e-coins), and vice versa. The protocol is optimistic in that a trusted (or semi-trusted, as described below) third party is involved only when there is a dispute. Further, the buyer's privacy is protected.
While many of the examples described herein are provided for purposes of explanation, it is understood that these are only examples. For example, various encryption primitives, signature and e-coin schemes are described, but other such schemes may be used; indeed, each component can be replaced by an equivalent component without affecting the protocol. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing are electronic commerce in general.
In e-business applications, an e-coin can be spent only once by a buyer. Indeed, the unconscious double-spending attack exploits this property to attack other fair payment protocols. E-goods, such as software, on the other hand, may be sold multiple times. Such a multi-use property of e-goods is exploited in the optimistic fair payment protocol described herein, e.g., the trusted third party can provide a key to decrypt the e-goods, the actual e-goods can be verified against a description thereof, and so forth.
Turning to
Upon receiving this data (block 102) from the merchant M, the buyer U first checks the validity of the signatures. If the checking passes, the user U sends the pre-agreed amount of e-coins to the merchant M, represented in
In one implementation of the protocol, the merchant M receives the e-cash before delivering the purchased e-goods. Thus, no buyer can obtain e-goods from a merchant without payment. If the merchant practices fraud after having received the e-cash by refusing to deliver the corresponding e-goods or delivering wrong e-goods, the buyer U can resort to the trusted third party TTP to deliver the correct e-goods or obtain a refund (certificate) to get the paid e-cash back through the merchant's bank.
The transaction process is like a face-to-face transaction, e.g., a buyer obtains the encrypted goods (and a receipt from a merchant (as in the above-described payment stage) at the time when the buyer pays money (e-coins) to the merchant (Step 2 of the payment stage). When the buyer attempts to use the goods (as in the next stage) and detects some problems with the goods, the buyer resolves the issue with the merchant or goes to an arbitrator and shows both the goods and the receipt to settle the issue with the merchant (the disputes stage).
Each stage of the framework is described in further detail below. For simplicity in description, the following notation will be used to present one example fair payment protocol:
Further, the following assumptions for the exemplified fair payment protocol are made:
A setup stage (block 202 of
In a payment stage, generally represented in (k∥h), R=εkM(r), σ1=SignM(OA, k′, R), and σ2=SignM(OA,c,k′, R), and sends (OA,c,k′, R, σ1, σ2) to U. The key k is used in the symmetric encryption of the e-goods, k′ is an encrypted version of the key k, and R is a ciphertext of r. The functionality of R is described below with reference to the dispute stage.
Upon receiving the data (OA,c,k′, R, σ1, σ2), the buyer U first validates the agreement, goods, key and ciphertext (OA,c,k′, and R) with the signatures σ1 and σ2. If the validation passes, the buyer U executes the payment stage of the underlying e-coin scheme with the merchant M by taking hash (OA∥k′∥R) as a transaction ID. The e-coins payment scheme assures that the transaction ID cannot be replaced. Otherwise, the buyer U aborts the transaction. On receiving valid e-coins from the buyer U, the merchant M sends the randomly generated numbers and the hash (r,k,h) to the buyer U.
If at step 208 the buyer does not receive the aforementioned data or receives unusable data, the buyer will launch a dispute (step 211), of a type referred to herein as a Case 1 dispute. More particularly, in one example, to determine whether the data is useable, upon receiving (r,k,h), the buyer U checks whether k′ (k∥h), and h
hash (k∥OA). If any equation does not hold, the buyer U at step 211 launches the dispute resolution stage (case 1).
Otherwise, at step 210 the buyer checks the validity of the goods, that is, whether the goods match their description. To this end, the buyer U computes Ge-goods=Dk(c), and checks whether the e-goods Ge-goods are consistent with the previously received description De-goods of the e-goods. If they disagree, at step 212 the buyer U launches a second type of dispute, referred to herein as a case 2 dispute resolution stage (case 2).
To summarize, if the buyer does not receive (r, k, h), or the received (r, k, h) do not satisfy k′= (k∥h) or h=hash (k∥OA), the buyer U and the merchant M perform the following steps, as generally represented by block 211 and further detailed in
In this case 1 type of dispute, the buyer U sends (OA,k′,R,(σ1), the e-coins and the proof of payment for the e-goods to the trusted third party TTP. The trusted third party checks the validity of the signature σ1; this check ordinarily will pass since the buyer has already validated the merchant's signature 1 in the payment stage, and the communications between the buyer and the trusted third party are assumed to be reliable.
The trusted third party then checks the proof of payment to make sure that the buyer has paid for the e-goods with the e-coins. It terminates if the buyer has not paid. The trusted third party then computes (k∥h)= (k′), and checks whether h=hash(k∥OA), in order to prevent colluding attacks by the buyer and a conspiring merchant. If the equation does not hold, the trusted third party TTP sends a certificate 130 of e-coins revocation and a transcript of the transaction to the buyer U, and terminates the dispute stage. The buyer can use the certificate to get back the deposited money and asks for a punishment on the merchant.
As an alternative to the certificate, or before sending the certificate, the trusted third party TTP may send k to the buyer U, and send the e-coins to the merchant M. The e-coins may be ignored if the merchant M has already received the e-coins from the buyer U; they cannot be spent again.
Upon receiving k from the trusted third party at Step 2 of this stage, the buyer U computes Ge-goods=Dk(c), and checks whether the decrypted e-goods Ge-goods agrees with the description De-goods. Essentially the buyer has returned to step 210 of
To this end, if the buyer U receives invalid e-goods, the buyer U performs the steps with the trusted third party that are further detailed in
The trusted third party then checks the proof of payment to make sure that the buyer has paid for the e-goods. It terminates if it determines that the buyer has not paid for the e-goods. It then computes (k∥h)=(k′) and checks whether h=hash (k∥OA), and computes Ge-goods=Dk(c) and checks whether the decrypted e-goods Ge-goods are consistent with the description De-goods. If either of the checks fails, the trusted third party sends the buyer U a certificate which shows that an e-coins payment can be cancelled back from the merchant M to the buyer U, and a transcript of the transaction. The buyer U uses this certificate to claim back the e-cash with the merchant's bank 150, and to ask for a punishment on the merchant M.
Alternatively, if both checks pass, the trusted third party concludes that the e-goods matched the description and sends the e-coins to the merchant M.
Note that access to the e-goods a buyer buys are restricted to those who have to access, such as the merchant and the buyer, since e-goods are easily duplicated. A dispute resolution service (e.g., the trusted third party) is involved only if one of the parties in a transaction behaves maliciously (including intentionally or erroneously) or the transaction is interrupted due to communication failure or the like. Indeed, the third party does not access the e-goods in arbitrating a dispute unless and until it has to verify the e-goods with the description as part of the arbitration. Thus, another model in fair payment is directed towards a semi-trusted trusted third party who cannot access the e-goods in arbitrating a dispute unless the dispute is one such that that the e-goods mismatch the e-goods description. Furthermore, in the event that the trusted third party launches an active attack, e.g., the semi-trusted third party unnecessarily requests the buyer to sends the e-goods to it for verifying the validity of the e-goods, such an attack is detectable, whereby the semi-trusted third party is subject to punishment by an external judge.
In the event that the semi-trusted third party attempts to cheat the buyer (to perform case 2) to get the e-goods, since the semi-trusted third party observes the protocols, the buyer would receive a certificate which is used to get back the e-coins. The merchant however needs to prove his innocence with an external judge by providing r from R. By validating the value of r, the external judge can conclude that the semi-trusted third party has behaved maliciously and is to be punished.
There is thus described an electronic commerce protocol which resists various attaches including an unconscious double-spending attack. Further, described is an exchanges and dispute resolution environment in which the dispute resolver is only semi-trusted. At the same time, the privacy of the buyer is protected.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
