Provable Fair Document Exchange Protocol with Transaction Privacy for E-commerce

Transaction privacy has attracted a lot of attention in the e-commerce. This study proposes an efficient and provable fair document exchange protocol with transaction privacy. Using the proposed protocol, any untrusted parties can fairly exchange documents without the assistance of online, trusted third parties. Moreover, a notary only notarizes each document once. The authorized document owner can exchange a notarized document with different parties repeatedly without disclosing the origin of the document or the identities of transaction participants. Security and performance analyses indicate that the proposed protocol not only provides strong fairness, non-repudiation of origin, non-repudiation of receipt, and message confidentiality, but also enhances forward secrecy, transaction privacy, and authorized exchange. The proposed protocol is more efficient than other works.


Introduction
Parties involved in Internet-based e-commerce usually do not fully trust each other. This mutual distrust is a major motivator for the fair exchange of documents between parties. For example, many consumers desire to fairly purchase products such as digital film, video, or music from online merchants using OPEN ACCESS electronic cash [1,2]. A fair document exchange protocol should provide the following basic security features [3,4] to enhance the security of e-commerce: (1) Strong fairness: Each party obtains the expected document from the other party at the end of the protocol. Neither party has any advantage if one party misbehaves or prematurely aborts. (2) Non-repudiation of origin (NOO): The sender of the document generates irrefutable origin evidence for the receiver that can be presented to a third party, who can determine if the sender is the authorized owner of a given document. (3) Non-repudiation of receipt (NOR): The designated receiver generates irrefutable receipt evidence for the sender of the document that can be presented to a third party, who can determine if the designated receiver has received a given document. (4) Message confidentiality: Only designated receivers can disclose the delivered document.
Previous researchers have proposed several fair exchange protocols. Fair exchange protocols can be classified into different groups based on the type of content exchanged: (i) fair document exchange protocols [4][5][6][7][8][9][10]; (ii) optimistic fair exchange protocols of digital signature [11][12][13][14][15]; (iii) electronic contract signing protocols [16][17][18][19][20][21][22]; and (iv) certified e-mail/e-goods delivery protocols [23][24][25][26][27][28][29][30]. Optimistic fair exchange protocols of digital signature and contract signing protocols exchange digital signatures fairly. The fair exchange protocols of digital signature that incorporate an offline trusted third party (TTP) are called optimistic [11]. In the optimistic fair exchange protocol of digital signature, the sender transmits the digital signature of origin to fairly obtain irrefutable evidence of receipt. In the contract signing protocol, the sender, and the receiver fairly exchanging their respective digital signatures for the same digital contract, which is already known by both parties. The concurrent signature scheme [31] is another mechanism for fairly exchanging signatures. After concurrent signature exchange, each signer believes that he himself will obtain the correct signature of the opposing party fairly. Upon release of the keystone, both signatures will bind to their true signer. Unfortunately, digital signatures limit the format and content of the message to be exchanged. However, it is not possible to implement fair document exchange protocol by modifying the optimistic fair exchange protocols of digital signature and the contract signing protocols or adopting concurrent signature mechanisms. In certified e-mail/e-goods delivery protocols, the sender can only fairly exchange a digital document based on the irrefutable receipt (i.e., the digital signature) of the designated receiver. Because of the specific characteristics of receipt in certified e-mail/e-goods delivery protocols, it is not possible to implement the fair document exchange protocol by altering certified e-mail/e-goods delivery protocols. A fair document exchange protocol enables the fair exchange of any type of digital document between mutually distrusting parties. Any type of digital document means that the message format and content are not restricted. For example, the document may be a piece of a password, business report, purchase order, a movie, electronic letter, digital content, or digital cash.
Digital rights management (DRM) [32,33] protects the document against unauthorized exchange, and further prevents the unauthorized party from re-exchanging the received notarized document in e-commerce. However, DRM cannot guarantee that irrelevant documents are fairly exchanged. In other words, DRM cannot ensure fairness. Therefore, both parties may obtain different advantages by unexpectedly aborting or misbehaving in the DRM system.
The involvement of a trusted third party (TTP) between mistrusting parties is necessary to ensure fairness in the fair document exchange protocol. Fair document exchange protocols can be classified into two types: (1) online TTP model, in which the TTP is actively involved in each exchanging transaction; (2) offline TTP model, in which the TTP is not involved in each exchanging transaction. The offline TTP only notarizes exchanged documents and intervenes in case of dispute between exchanging parties.
A fair document exchange protocol that adopts an online and centered trusted third party (TTP) could be expensive to maintain and may cause the communication bottleneck problem. Involving the online TTP in each transaction of the fair document exchange protocol remarkably decreases performance, especially in a multi-receiver context. Therefore, researchers have proposed several fair document exchange protocols with offline TTP [4,[6][7][8][9][10]. The main idea of these studies is that the sender first sends the ciphertext of his/her own document before obtaining the expect document from the opposite party. Both parties will then fairly exchange the decryption keys of the ciphertext. A fair document exchange protocol includes two important functions, verifiability and recoverability, which are essential to ensuring strong fairness. Verifiability means that the legal receiver can verify the accuracy of the received ciphertext before obtaining the real document. Recoverability allows the legal receiver to recover the document with assistance of the offline TTP when the opposing party misbehaves or prematurely aborts the exchange.
There are two main strategies to ensure the verifiability and recoverability of exchanged messages in offline TTP models. In the first strategy [6][7][8][9][10], the offline TTP helps the sender encrypt the document, and then generates its certified commitment. However, the sender may attempt to fairly exchange the same document with many participants. This compromises transaction privacy because each participant gets the same certified commitment and ciphertext decryption key. For example, a vendor may fairly exchange the same product with many buyers in a multi-receiver e-commerce environment. This allows one buyer to identify other buyers buying the same product. Although the sender can require the offline TTP to re-generate a new certified commitment during each transaction to maintain the transaction privacy, the offline TTP must be online. This online model has some drawbacks. Therefore, fair document exchange protocols [6][7][8][9][10] based on this first strategy are not practical for multi-receiver e-commerce environments, which require transaction privacy.
In the second strategy, the offline TTP issues a certified commitment for each document using the public key-based verifiable encryption method [4]. This verifiable encryption method ensures that the designated receiver can verify the relationship between the received ciphertext and the expected document before obtaining the real document. However, the verifiable encryption method ensures that the bit length of the exchanged document is limited for each transaction in the fair document protocol. The sender must perform fair document exchange protocols many times for large exchanged documents, such as films. Thus, a fair document exchange protocol based on this second strategy is inefficient and unpractical. In addition, the transaction privacy of the fair document exchange protocol based on the verifiable encryption method [4] must be enhanced.
This paper proposes an efficient and provable fair document exchange protocol that differs from both of these strategies. The proposed protocol integrates encryption and digital signature by inspiring from the concept of extractable commitment technology. It not only ensures strong fairness, non-repudiation of origin, non-repudiation of receipt, and message confidentiality, but also provides the following security functions to enhance the security of fair document exchange: (1) Backward and forward secrecy: Nobody except the designated receiver can obtain the session key in the previous or next transaction, even if an adversary compromises the current session key.
(2) Transaction privacy: Each transaction keeps the identity of the participants and the exchanging documents secret. In this case, a legal receiver who has obtained a document still cannot learn the behavior of the other transactions for the same document. (3) Authorized exchange: The receiver can verify the ownership of the notarized document to prevent unauthorized exchange. The proposed protocol prevents an unauthorized party from re-exchanging or re-distributing previously received documents. (4) Resisting the replay attack: No one can replay previous eavesdropped messages to impersonate legal participants or exchange documents with other participants.
In the proposed protocol, the notary notarizes each document only once and gives the recovery certificate to the authorized party. Verifiable documents, such as digital signatures or e-cash, do not need to be notarized in the proposed protocol. After notarization, the authorized party can use its recovery certificate to exchange the document with several different parties without adversely affecting transaction privacy. The offline notary does not need to store any messages or maintain any public catalog after notarizing the documents. These features make the proposed protocol practical and cost-effective for multi-receiver e-commerce environments.
The remainder of the paper is organized as follows. Section 2 defines some notations. Section 3 describes the proposed fair document exchange protocol. Section 4 demonstrates the security definitions and analyses. Section 5 discusses functionalities and performance. Finally, Section 6 provides some brief conclusions.

Preliminaries
In the fair document exchange, the notary T is an offline third party trusted by both participants. Thus, the notary T should not conspire with any participants. All parties have access to the public description information descA of MA and public description information descB of MB. For instance, the title, movie length, and film director are the public description information descA of a popular movie MA. Moreover, all public keys are certified by Certificate Authority (CA) and known by all participants. This paper uses the following notations:

Fair Document Exchange Protocol
The proposed fair document exchange protocol consists of three phases: notarization phase, fair exchange phase, and arbitration phase. The notary T notarizes the documents in the notarization phase. In the fair exchange phase, Alice A uses the notarized document MA to fairly exchange the notarized document MB with Bob B without notary involvement. If a dispute occurs, the offline notary helps both participants retrieve their documents in the arbitration phase. The proposed protocol integrates encryption and digital signature by the extractable commitment technology. The extractable commitment technology integrates encryption and digital signature via special padding process. The padding processes of the proposed protocol show in Steps N2 and N3 of the notarization phase, and Steps F1 and F2 of the fair exchange phase.

Notarization Phase
Without loss of generality, consider the following example to explain the procedures of the notarization phase. Alice A performs Steps (N1) to (N3) to obtain the recovery certificate CertA = {WA, vA, CA, descA, σA} and secret key KA for MA. Bob B runs the same procedure to obtain the recovery certificate CertB = {WB, vB, CB, descB, σB} and secret key KB for MB. The notary has to make sure the ownership of exchange document. The verifying ownership process is out of the scope of this paper. The step (N1) of the notarization phase should include the out-of-band method. Figure 1 shows a diagram of this phase.  Figure 1. The diagram of notarization phase.
Step (N1): Alice A sends the document MA and its description information descA to the notary T via the out-of-band method.
Step Step (N3): Alice A runs the following sub-steps to obtain secret key KA and the recovery certificate CertA of MA: Step (N3-1): Recovers the value wA from πA by computing V(PUT, D(PRA, πA)).

Fair Exchange Phase
Without loss of generality, consider the following example to explain the procedures of this phase. Alice A wants to obtain the document MB from Bob B in a fair way, and Bob B wants to obtain the document MA from Alice A in a fair way. Figure 2 shows the diagram of this phase, and the following subsection describes the steps in detail. Step (F1): Alice A performs the following sub-steps to send the session information {π2, v2} and the ciphertext Π2 to Bob B: Step (F1-1): Generates the request information req_info = (A||B||T||descA||descB||Tstamp), where Tstamp is time stamp.
Step Step (F3): Alice A performs the following sub-steps to get MB and send the ciphertext {δA} back to Bob B: Step

Arbitration Phase
Any participants may prematurely abort the fair exchange phase. All possible arbitration cases are as follows: Step (A6): Sends the document MB to Alice A and the document MA to Bob B via the out-of-band method or the secure channel, simultaneously.

Security Analysis
This section demonstrates the security functions of the proposed protocol. The proposed protocol enhances the security of our draft protocol [37]. The draft protocol [37] only includes partial idea of the proposed protocol in this paper. This paper completely details our fair document exchange protocol and demonstrates its security by formal method. Specifically, Section 4.1 uses the random oracle technique [38] to prove message confidentiality. Next, Section 4.2 demonstrates backward and forward secrecy, and Section 4.3 proves transaction privacy. Section 4.4 proves non-repudiation of origin and receipt. Section 4.5 describes the authorized exchanging property. Section 4.6 proves the strong fairness of this approach. Finally, Section 4.7 discusses the replay attack.

Message Confidentiality
Message confidentiality means that the adversary cannot learn any information from the communication transcripts {π2, v2, Π2, δA, δB} of the proposed fair exchange phase. In the fair exchange phase, the session information {π2, v2} of Step (F1) is the most important ciphertext for protecting the session key K2. This session key K2 encrypts other ciphertexts {Π2, δA, δB} using a symmetric encryption algorithm such as AES-128 [35]. The session key K2 of the proposed protocol is random and independent for each transaction. To demonstrate the advantage probability on the adversary learning any information of the session key K2, Definition 1 defines an interactive game based on random oracle technique [38]. Based on Definition 1, Theorem 1 proves the advantage probability of an adversary that learns any information of the session key K2 from the session information {π2, v2}. By Theorem 1, Theorem 2 demonstrates the advantage probability of an adversary learning any information of the exchanged documents MA and MB. Finally, Theorem 3 proves that the proposed protocol provides the message confidentiality.

Definition 1 (Message confidentiality of the session information): The session information {π, v} of
Step (F1) achieves the message confidentiality against adaptive chosen-ciphertext attacks (IND-CCA2) [39], if no probabilistic polynomial time (PPT) adversary V has a non-negligible advantage in the following interactive game: Suppose Ψ is given a ciphertext C* and the public key PUB of the RSA problem, Ψ runs V as a subroutine to find the plaintext M* such that C* = E(PUB, M*). The term Ψ simulates the environment of interactive game in Definition 1 as follows: Ψ maintains three lookup tables {τH, τG, τα} to simulate the H hash oracle, encryption oracle and decryption oracle. All oracles of the interactive game are defined as follows: In Stage 3 of Definition 1, Ψ generates the challenge ciphertext {π*, v*} to V such that π* = C* and the value v* is a random number, where |v*| = β.
Analysis. The running time of Ψ is in polynomial of V's running time. The simulated game is computationally indistinguishable from the real game. Note that this study perfectly simulates the H oracle and encryption oracle. Except in special cases, the decryption oracle queries are perfectly carried out too. The special case includes two sub-cases: the decryption oracle rejects the valid session information {π, v} or the decryption oracle accepts the invalid session information {π, v}.
Next, assess Ψ's probability of success. Let E be the event that Algorithm Ψ solves the RSA problem by running V as subroutine. As long as the simulated game is perfectly simulated as a real game, the probability of E happening is the same as in a real attack. (i.e., an attack in which V interacts with real oracles.) In a real attack, we have

Pr[λ' = λ] ≤ Pr[λ' = λ|¬E] × Pr[¬E] + Pr[E] = (1/2) + (1/2)Pr[E]
(1) Rewriting Equation (1)  The probability that the simulated game is not perfect must be assessed. Except for a special cases, decryption oracle queries are carried out perfectly too. These special cases include two sub-cases: the decryption oracle rejects the valid session information {π, v} or the decryption oracle accepts the invalid session information {π, v}. However, each sub-case may be happen when τα has defined the corresponding tuple (v, α) by the encryption oracle or the decryption oracle with v. The occurrence probability for each sub-case is (qE + qD)/2 β . Hence, the total probability for these sub-cases is not greater than 2 × (qE + qD)/2 β . By eliminating the probability that the decryption oracle of the simulated game is not perfectly simulated as a real game, the probability of Ψ solving the RSA problem should be modified as β should be larger than 128 bits such as AES-128, because β is a security parameter. The probability 2 × (qE + qD)/2 β is negligible. Pr[E] is non-negligible if εkey is non-negligible. The probability of Ψ solving the RSA problem is non-negligible, if εkey is non-negligible and β is security parameter. Q.E.D. V can obtain the session key K if he gets the private keys {PRA, PRB} from Alice A and Bob B by breaking the RSA asymmetric encryption algorithm. The probability of this case is at most εRSA.

Theorem 3. The proposed protocol provides message confidentiality.
Proof. In the AES-128 [35] symmetric encryption algorithm adopted in the proposed protocol, the bit length of the session key K is 128 bits (i.e., β = 128 bits). According to Theorem 2, the success probability of an adversary learning any information of the exchanged documents {MA, MB} is at most εmsg, and εmsg ≤ Maximum{((1/2)εRSA + (qE + qD)/2 β ), εRSA, εAES} Equation (3) is reduced to εmsg ≤ Maximum{εRSA, εAES}, because β = 128 bits and the probability (qE + qD)/2 β is negligible when using AES-128. According to the National Institute of Standards and Technology (NIST) [41], the probability εRSA is negligible when the modulus of the RSA encryption algorithm is sufficiently large. The National Bureau of Standards [35] and NIST [41] further indicate that the probability εAES is also negligible for AES-128 symmetric encryption. The success probability of an adversary obtaining MA and MB is negligible. In other words, the proposed protocol provides sufficient message confidentiality. Q.E.D.

Backward and Forward Secrecy
The initiator, Alice A, randomly selects a session key K2 for each transaction in the fair exchange phase. The session key K2 is fully independent for different transactions. Even if adversaries obtain the current session key K2, they cannot derive the previous and subsequent session keys. The proposed protocol achieves backward and forward secrecy.

Transaction Privacy
Theorem 3 of Section 4.1 demonstrates the message confidentiality of the proposed protocol. Nobody except Alice A and Bob B can obtain the exact transaction information during the fair exchange phase. The session key K2 protects the exchanged document and its recovery certificate. Section 4.2 shows that the session key K2 for each transaction is random and independent. Even when someone exchanges the same document and its recovery certificate with different parties, transaction privacy remains intact.

Non-Repudiation of Origin and Non-Repudiation of Receipt
The initiator, Alice A, generates the ciphertexts {π, v, Π} to initiate the exchange session in Step (F1) of the fair exchange phase. Definition 2 defines the message unforgeability of the session information {π, v}. Theorem 4 proves that the success probability of Forger F forging the session information {π, v} is negligible. Theorem 5 proves that the success probability of Forger F forging {π, v, Π} the fair exchange phase is negligible.

Definition 2 (Message unforgeability of the session information): The session information {π, v} in
Step (F1) of the fair exchange phase is existentially unforgeability against chosen-message attack (EUF-CMA) [42] if no probabilistic polynomial time (PPT) Forger F has a non-negligible advantage in the following game: (1) The challenger generates a key pair {PUU, PRU}. The private key PRU is kept secret while the public key PUU is given to Forger F.
(2) Forger F adaptively makes a number of queries to H hash oracle, G hash oracle, the encryption oracle and the decryption oracle.  Proof. Assume that Forger F who wins the interactive game given in Definition 2 of Section 4.4 with a non-negligible advantage. Algorithm Γ runs F as a subroutine to solve the RSA problem with non-negligible advantage. Suppose Γ is given a ciphertext C* and the public key PUA of the RSA problem, Γ runs F as a subroutine to find the plaintext M* such that C* = E(PUA, M*). Γ sets up a simulated environment of interactive game of Definition 2 as follows: Γ maintains three lookup tables {τH, τG, τα} for simulating H hash oracle, G hash oracle, decryption oracle, and encryption oracle. F performs adaptive queries to the following oracles:

H oracle:
this oracle is simulated as in the proof of Theorem 1.

G oracle:
To query G(c) of F, the G oracle replies the defined value, if G(c) is defined in τG. Otherwise, the oracle randomly selects a challenging session key K(=(x||y)) and performs the following steps to return the value G(c): According to the restriction of Stage (3) in Definition 2, the forged ciphertext {π*, v*} of F cannot be the response of the encryption oracle. The encryption oracle does not define the tuple (v*, α*) of τα, which is related to K*. There are only two cases in which Γ can obtain the key K', and K' is equal to K* on querying the decryption oracle with {π*, v*} of F. The first case is that τα has stored the corresponding tuple (v*, α*) of {π*, v*}. In the second case, the decryption oracle selects the proper value α* in Step (D2) of the decryption oracle such that α* can pass the verification π* = E(PUB, (PUA||α*)) of Step (D3).
Because the G oracle defines the challenging session key K* when making G queries, the corresponding tuple (v*, α*) of {π*, v*} is defined at this time. If the decryption oracle can derive K' from {π*, v*} of F and K' = K*, Γ retrieves the corresponding value α* according to the index value v* from τα in Step (D2) of the decryption oracle. Moreover, Γ uses the corresponding value α* and Sender A's public key PUA to generate the value (||w) by running the RSA-based message recovery procedure in Step (D4) (i.e., (||w) = V(PUA, α*)). If the decryption oracle returns the key K' and K' = K* during the decryption query ({π*, v*}), the value (||w) of Step (D4) and its extended parameters pass the verification of Step (D8). In other words, α* is the signature of the value (||w). Because the RSA-based message recovery algorithm is identical to RSA-based asymmetric encryption algorithm, the procedure in Step (D4) can also perform the RSA-based encryption procedure to get the ciphertext (||w) by encrypting the value α* with Sender A's public key PUA. However, the G oracle assigns the value (||w) = C* in Step (G4) and K* is defined at the same time when making G queries. If K' = K*, α* is the plaintext M* of C*. Hence, the value α* which Γ obtained is the plaintext M* of C* when K' = K*. In other words, Γ solves the RSA problem in the first case.
In the second case, the value α* is the correct value selected by Step (D2) of the decryption oracle such that α* passes the verification π* = E(PUB, (PUA||α*)) of Step (D3) and τα does not define the corresponding tuple (v*, α*) of {π*, v*}. K* provided by Γ is derived through the query of the G oracle and the procedures of the query define one tuple (v*, α*) in τα. In other words, τα must define the tuple (v*, α*) for each K*. In the second case, if K' = K* and Step (D2) of the decryption oracle does not define any corresponding tuple (v*, *), it the forged ciphertext {π*, v*} of F is not the correct ciphertext of K*. The second case is a special case in which the decryption oracle accepts the invalid ciphertext, and the decryption oracle cannot perfectly reflect a real game. Γ cannot obtain M* of C* in this special case. The following assessment of the success probability on Γ solving the RSA problem precludes this special case.
This theorem assumes that when F successfully forges the ciphertext {π*, v*} for K* (i.e., F wins the interactive game), Γ can find out a tuple (v*, α*) from τα such that π* = E(PUB, (PUA||α*)). Because α* is the plaintext M* of C*, as demonstrated above, Γ can solve the RSA problem. Hence, these are a non-negligible probability of Γ solving the RSA problem if there is a non-negligible probability of F winning the interactive game.
Analysis. The running time of Γ is in polynomial of F's running time. To see that the simulated game is computationally indistinguishable from the real game, note that the H oracle and G oracle can be simulated perfectly as a real game. When the encryption oracle performs Step (C8) and returns "failure", the encryption oracle cannot be perfectly simulated as a real game. If Step (C8) does not return "failure", the encryption oracle perfectly simulates a real game. The decryption oracle perfectly simulates the real game except for a special case. This special case includes two sub-cases: the decryption oracle rejects the valid session information {π, v} or the decryption oracle accepts the invalid session information {π, v}.
Next, assess Γ's probability of success. If the encryption oracle returns "failure" or the decryption oracle makes an erroneous judgment while F queries the ciphertext, the simulated game does not perfectly reflect a real game. The success probability of Γ solving the RSA problem should preclude these two cases.
(1) The first case occurs in the encryption query. During each encryption query, Γ attempts to define G(c) in Step (C8) of the encryption oracle. However, when the G oracle has defined G(c) in τG, the encryption oracle will return "failure". The game makes at most qG queries to the G oracle. τG defines at most qG records, which are defined by G oracle. Moreover, the game makes at most qE queries to the encryption oracle. The probability that this case will happen is at most (qE × qG/2 β ). In other words, the probability that Γ does not fail during simulating the encryption oracle is at least (2) The second case occurs in the decryption query, and includes two sub-cases: the decryption oracle rejects the valid session information {π, v} or the decryption oracle accepts the invalid session information {π, v}. After querying the encryption oracle and the decryption oracle, τα defines the corresponding tuple (v, α). The corresponding tuple (v, α) may cause the decryption oracle to reject the valid session information {π, v}. The probability of this sub-case is at most (qE + qD)/2 β . The decryption oracle may accept the invalid session information {π, v} when τα does not define the corresponding tuple (v, α) and the randomly selected value α at Step (D2) passes the verification of Step (D3). The probability of this sub-case is at most (1 − (qE + qD)/2 β )/2 |α| . The total probability for these sub-cases is not greater than (qE + qD)/2 β + (1 − (qE + qD)/2 β )/2 |α| . In other words, the probability of the decryption oracle making an accurate judgment while F queries the decryption oracle is at least If Γ perfectly simulates the real game and F wins the game, Γ can solve the RSA problem. The probability of F winning the game is at most εforge. According to Equations (4) and (5), Pr[F wins the game and Γ perfectly simulates the real game] ≥ (1 − qE × qG/2 β ) × (1 − ((qE + qD)/2 β + (1 − (qE + qD)/2 β )/2 |α| )) × εforge. In other words, the probability that Γ solves the RSA problem is at least (1 − qE × qG/2 β ) × (1 − ((qE + qD)/2 β + (1 − (qE + qD)/2 β )/2 |α| )) × εforge. Q.E.D.

Authorized Exchanging
In the proposed protocol, the notary notarizes each document only once and generates its recovery certificate. The recovery certificate includes the notary's signature on the public key of the document owner. Bob B authenticates the ownership of MA in Step (F2-6) of the fair exchange phase using the recovery certificate of MA. Similarly, Alice A authenticates the ownership of MB in Step (F3-2) of the fair exchange phase based on the recovery certificate of MB. The sender should provide his or her signature of the document and its recovery certificate. This approach prevents the receiver from impersonating the authorized owner and re-distributing the received document to other parties using this protocol.

Strong Fairness
Any participants may prematurely abort the fair exchange phase. All possible arbitration cases are as follows.

Discussions
This section analyzes the performance of the proposed approach and compares it with previous methods [4,[6][7][8][9][10]. Alaraj's method [5] assumes that initiator party has known the hash value of the encrypted exchange data of the responder party before performing the exchange protocol. It also assumes that the responder party has known the encryption of the initiator's encryption key for this transaction before performing the exchange protocol. These two assumptions are not practical in the e-commerce via Internet. Besides, Alaraj's method [5] includes many techniques of Zhang et al.'s method [10]. The computational cost of Alaraj's method [5] is as well as Zhang et al.'s method [10]. The following comparisons do not include Alaraj's method [5]. Section 5.1 compares functionalities. Section 5.2 makes comparisons based on computation and communication costs. Table 1 compares the functionalities of previous methods [4,[6][7][8][9][10] with the proposed protocol. As  Table 2 shows the computational time of public key operations under the same security level [43]. The  notations TRSA-SIG-DEC, TRSA-VFY-ENC, TPAIR, and TECSM in Table 2 represent one RSA signing/decryption with a 1024-bit modulus, one RSA verification/encryption with a 1024-bit modulus, one admissible bilinear pairing, and one elliptic curve-based scalar multiplication as suggested by IEEE Standard P1363.3 [44], respectively. The public operations in Table 2 are implemented by the standard cryptographic library, MIRACL (Multiprecision Integer and Rational Arithmetic C/C++ Library) [45]. The implementation platform consists of a 32-bit Intel Pentium IV processor at 3 GHz.  Table 3 compares the main computational costs of the fair exchange phase for the proposed protocol and previous studies [4,[6][7][8][9][10]. The fair exchange phase of the propose protocol only requires six RSA-based verification/encryption operations and four RSA-based signing/decryption operations, and is therefore more efficient than previous RSA-based fair document exchange protocols [6][7][8][9][10]. Because it adopts a bilinear pairing function, Liang et al.'s fair document exchange protocol [4] has much higher computational cost than the proposed protocol under the same security level. The acceleration ratio in Table 3 shows that the proposed protocol is 123% to 435% faster than previous studies [4,[6][7][8][9][10]. The acceleration ratio is the computational cost of the compared protocol divides by the computational cost of our protocol. Clearly, the proposed protocol is more efficient than previous studies. Table 3. Comparisons for computational cost.

Conclusions
This paper proposes an efficient and provable fair document exchange protocol that ensures transaction privacy in a multi-receiver e-commerce environment. In this approach, the offline notary notarizes each document only once. Authorized owners repeat fair exchanges with different parties without endangering participant privacy. Though the notary is offline, the proposed protocol still ensures transaction privacy in the multi-receiver e-commerce environment where other methods lose transaction privacy. This study demonstrates that the proposed protocol not only meets principal security requirements, but also enhances forward secrecy, transaction privacy, and authorized exchange. Moreover, the proposed protocol is more efficient than other fair document exchange methods in multi-receiver e-commerce.