This paper is organized as follows: in Section 2, we describe the notation used ... PRI[H(X)] â the digital signature of party I on X (which is first hashed with H) ...
An Attack on a Protocol for Certified Delivery Jos´e R.M. Monteiro1,2 and Ricardo Dahab1 1 Institute of Computing, University of Campinas Caixa Postal 6176, CEP 13084-971, Campinas – SP – BRASIL {monteiro,rdahab}@ic.unicamp.br 2 ´ Cepesc/DT/ABIN, SPS – Area 5, Quadra 1, Bloco V CEP 70610-200, Bras´ılia, DF – BRASIL
Abstract. We show that the protocol for certified mail delivery of Ferrer-Gomila and others [2] may exhibit contradictory behavior when the recipient is not well behaved. As a consequence, properties such as non-repudiation of reception and fairness may not hold. We also present a solution for this weakness which has minimal cost.
1
Introduction
Fair exchange protocols provide communicating parties with assurances regarding the outcome of the exchange: each party receives the item it expects if and only if the other party also gets his or hers. Exchanges are typical of distributed system environments, where negotiations are carried over insecure channels, between mutually trusting parties (except, perhaps, for byzantine-like agreements). We are interested, however, in those exchanges which occur over the Internet between non-trusting parties, usually unknown to each other. More specifically, we are concerned with optimistic fair exchange protocols, with the participation of a trusted third party (TTP). The role of a TTP in an optimistic protocol is restricted to resolving conflicts between the parties, as opposed to being involved in every communication between them, thus reducing the occurrence of bottlenecks involving the TTP. In an environment of mostly well-behaved parties, this approach results in much greater efficiency. We refer to conflicts between the parties as exceptions. Such exceptions may arise either from misbehavior by one of the parties, or from interference by a third party, or from faults in the communication channel. Whatever the cause, it may be unknown to the parties, who may have the TTP as their last resort for settling a dispute. A protocol possesses the timeliness property if the parties are guaranteed to complete their exchange in a finite amount of time, even in the presence of exceptions. Optimistic fair exchange protocols, proposed by Asokan [1] in 1998, implement timeliness through the use of local timeouts and a TTP to resolve disputes. In Asokan’s proposal, a TTP may have two options in such a situation: either deliver the expected item to the requesting party or replace it with another, A.H. Chan and V. Gligor (Eds.): ISC 2002, LNCS 2433, pp. 428–436, 2002. c Springer-Verlag Berlin Heidelberg 2002
An Attack on a Protocol for Certified Delivery
429
previously agreed, item. This second strategy is used by Asokan in [1] to implement his Certified Delivery Protocol. In 2000, Ferrer-Gomila, Payeras-Capell`a and Huguet i Rotger [2] presented a new version of Asokan’s protocol, and analyzed it under the following criteria: (i) effectiveness–i.e. the protocol actually exchanges a message for a receipt; (ii) fairness, as defined above; (iii) timeliness; (iv) non-repudiation of the actions of each party–i.e., the sender and the recipient; and (v) verifiability of the TTP–i.e., the actions of a TTP, may be checked and audited by independent sources. Our work here points to problems in items (ii) and (iv) above. As we shall see, it is possible for one of the parties, the recipient, to induce the TTP to issue two contradictory tokens, one signaling that the exchange has been resolved and another aborted. This paper is organized as follows: in Section 2, we describe the notation used in the remaining sections; in Section 3 we present the main protocol of FerrerGomila and others in [2] and their exception handling subprotocols; Section 4 describes our attack and its impact on the protocol’s dispute settling mechanisms; a solution for the described weaknesses is presented in Section 5; the last section contains the conclusions.
2
Notation
Throughout the rest of this paper, we use the same conventions adopted in [2], which we list below for completeness. Moreover, we shall refer to the protocol in [2] as the FPH protocol. i.
A and B are the parties in the exchange and T is the TTP;
ii.
X, Y – concatenation of messages X and Y ;
iii.
H(X) – application of collision-resistant hash function to message X;
iv.
P RI [H(X)] – the digital signature of party I on X (which is first hashed with H), generated with I’s private key P RI ; here I may be one of A, B, T ;
v.
M – message from A to be certifiably delivered to B;
vi.
K – a symmetric encryption key;
vii. “s” denotes the string s; viii. c = EK (M ) – encryption of M using a symmetric algorithm E with secret key K producing ciphertext c; decryption of c is performed with DK (c); ix.
kT = P UT (K) – key K encrypted with the TTP’s public-key P UT ;
x.
hA = P RA [H(H(c), kT )] – part of the evidence of non-repudiation of origin of message M for B;
430
xi.
J.R.M. Monteiro and R. Dahab
hB = P RB [H(H(c), kT )] – part of the evidence of non-repudiation of reception of message M for A;
xii. kA = P RA [“key=”, K] - second part of the evidence of non-repudiation of origin for B; xiii. kT = P RT [“key=”, K] - an alternative second part of the evidence of nonrepudiation of origin for B; xiv. hAT = P RA [H(H(c), kT , hA )] – an evidence that A has requested the TTP’s intervention; xv. hBT = P RB [H(H(c), kT , hA , hB )] – an evidence that B has requested the TTP’s intervention; xvi. hB = P RT [H(hB )] – the TTP’s signature on hB which proves its intervention.
3
The FPH Protocol
The FPH protocol is an optimistic protocol for certified mail delivery. Its outcome is the exchange of a message M and a receipt for it between two parties, A and B. In case of an exception, the TTP issues a certificate with the same value of a receipt or the message, whichever is necessary. The main protocol and its exception handling protocols are described in Figures 1 and 2. Our description is not exactly the same as that in [2]; some steps have been included for clarity but they do not alter the essence of the protocol.
3.1
Dispute Handling
Upon completion of the protocol, it may be necessary to handle the following abnormal completion claims: – Repudiation of origin. B claims to have received M from A but A denies having sent it. – Repudiation of reception. A claims to have sent M to B but B denies having received it. An external adjudicator J should handle these claims as follows: – Repudiation of origin. J requests M, c, kT , hA and kA from B and verifies the signatures in hA , kA , kT and whether DK (c) = M . If all these checks are positive, then J rules in favor of B; otherwise J dismisses B’s claim. Moreover, if B’s evidence is correct and if A is able to provide J with the token P RT [H(“cancelled ”, hA )], then J rules that the TTP has acted incorrectly.
An Attack on a Protocol for Certified Delivery
431
Protocol 1 - FPH Protocol for Certified Delivery. Step Action 1 2 3 4 5 6
A → B : c, kT , hA If exception, B stops B → A : hB If exception, A runs the Cancel protocol A → B : kA If exception, B runs the Finish protocol
Subprotocol 1 - Cancel Step Action 1 2
3
A → T : H(c), kT , hA , hAT T performs: if f inished then T recovers hB m := hB , hB ; else cancelled := V ; m := P RT [H(“cancelled ”, hA )]; end if T → A : m.
Fig. 1. The FPH Protocol and Cancel Subprotocol
– Repudiation of reception. J requests M, c, kT , hB and K from A and verifies the signatures in hA , kA , kT and whether DK (c) = M . If any of these checks is not verified, then J dismisses A’s claim. However, their correct verification is not enough to decide the question in A’s favor. The adjudicator should now require from B a token P RT [H(“cancelled ”, hB )]; if B is able to provide it, this is evidence of cheating on A’s part and thus the question is resolved in B’s favor; otherwise, if B cannot provide that token and, indeed, DK (c) = M , then J rules in A’s favor; if DK (c) = M , then J dismisses A’s claim. Finally, if A has provided correct evidence and B is able to provide a token P RT [H(“cancelled ”, hB )], then the conclusion is that the TTP has acted improperly.
432
J.R.M. Monteiro and R. Dahab Subprotocol 2 - Finish Step Action 1 2
3
B → T : H(c), kT , hA , hB , hBT T performs: if cancelled then m := P RT [H(“cancelled ”, hB )]; else f inished := V ; m := kT ; end if T → B : m.
Fig. 2. The Finish Subprotocol
4
Our Attack on the FPH Protocol
Before stating our attack, we note that: 1. Tokens hA = P RA [H(H(c), kT )] and hB = P RB [H(H(c), kT )] are very similar, differing only on the signing agent. 2. The Finish subprotocol, described above, returns one of the following messages: (i) P RT [H(“cancelled ”, hB )]; or (ii) kT . 3. Party B always knows ciphertext c, since it is part of the first message sent by A. 4. Ciphertext c has nothing in itself that shows it was originated by A. 4.1
Description of the Attack
After receiving the first message from A, party B initiates an execution of the Cancel subprotocol with the TTP. The result of the request follows. Attack 1 - B requests cancellation of exchange (1) Step Action 1 2 3 4
B → T : H(c), kT , hB , hBT Since f inished = V, then B gets: T → B : P RT [H(“cancelled ”, hB )] T sets cancelled = V
An Attack on a Protocol for Certified Delivery
433
where hBT = P RB [H(H(c), kT , hB )]. This provides B with cancellation token P RT [H(“cancelled ”, hB )]. Proceeding with the attack, B now initiates subprotocol Finish with the TTP, for a different exchange, say number 2. Attack 2 - B requests finalization of exchange (2) Step Action 1 2 3 4
B → T : H(c), kT , hA , hB , hBT Since cancelled = V : T → B : kT T sets f inished = V
This provides B with token kT , amounting to a well resolved exchange. Finally, B sends the second message, hB , to A, A replies with kA and the protocol terminates. There is another possibility for B. If B decides not to answer to A, then A calls the TTP to get a cancellation token. But B has executed the subprotocol Finish first, thus she gets the hB , hB from the TTP. In any case, A gets hB . As a result of these two interactions, B has obtained from the TTP two certificates which are contradictory. This situation was made possible because: (i) the messages sent in each case to the TTP do not identify their initiator; (ii) the messages returned by the TTP do not identify uniquely an exchange; and (iii) ciphertext c has no evidence of its originator. In a dispute with A, B can now deny having received a message from A by exhibiting token P RT [H(“cancelled ”, hB )]. The dispute will be handled by J as follows. 4.2
Dispute Resolution
Even presenting all the correct information, A will not be able to convince J of its (correct) claim that it has not received a receipt for a delivered message to B. Upon obtaining from B token P RT [H(“cancelled ”, hB )], J will rule (see Section 3.1), that A has acted maliciously. Another possibility is the ruling that the TTP has acted incorrectly, which can also be verified not to be true, since it acted according to its subprotocols. Thus B succeeds in cheating A.
5
Strengthening the Protocol
The perceived weakness in the FPH protocol can be circumvented by redefining hB as hB , where hB = P RB [H(H(c), kT , hA )], and substituting hB for hB in
434
J.R.M. Monteiro and R. Dahab
the description of the FPH protocol. The resulting tokens hBT and hB are also relabelled hBT , hB This results in the following subprotocols: Subprotocol 3 - Finish2 Step Action 1 2
3
B → T : H(c), kT , hA , hB , hBT T performs: if cancelled then m := P RT [H(“cancelled ”, hB )]; else f inished := V ; m := kT ; end if T → B : m.
Subprotocol 4 - Cancel2 Step Action 1 2
3
6
A → T : H(c), kT , hA , hAT T performs: if f inished then T recovers hB m := hB , hB ; else cancelled := V ; m := P RT [H(“cancelled ”, hA )]; end if T → A : m.
Analysis of the Strengthening
Given that A uses a different key K to encrypt each message m, then kT is expected to be different for each exchange, and, consequently, hA is also expected to be different. If no exceptions occur, message sets from different exchanges are expected to be different. In case of exception, since hB depends on the value of hA , it identifies the originator of exchange 2 above. Thus, the cancellation tokens returned by the TTP in the two instantiations of the protocol are different. For exchange 1, it will remain unchanged, i.e., P RT [H(“cancelled ”, hB )], and for exchange 2 it will be P RT [H(“cancelled ”, hB )]. Now, the token returned to B
An Attack on a Protocol for Certified Delivery
435
by the TTP upon a cancellation request depends on hA , which is unique for each exchange. The proposed changes do not alter timeliness or efectiveness properties of the FPH protocol, but they do have an effect on non-repudiation and fairness. We discuss these effects on the following theorems. Theorem 1 The proposed changes on the FPH protocol provide fairness. Proof: We assume that the TTP’s state variables, cancelled and finished are initially set to False. If no exceptions occur, then, since the protocol is effective, fairness is granted. Otherwise, an exception will trigger the initiation of one of the two subprotocols1 . There are two cases to consider: Cancel2 is called. The TTP knows that A initiated the exchange, since it has received hA . If variable finished is True, then variable cancelled will not be altered and the TTP will issue party A a certificate of successful resolution, i.e., hB , hB . If, otherwise, variable finished is False, then cancelled is set to True and A gets a certificate P RT [H(“cancelled ”, hA )], indicating that the exchange has been cancelled. In any case, both A and B receive noncontradictory certificates. Finish2 is called. The TTP knows that it is a request from B, in response to the initiation of an exchange by A, since it has received hB , which is a function of hA . If variable cancelled is True, then variable finished will not be altered and the TTP will issue party B a certificate indicating that the transaction has been cancelled. If, otherwise, variable cancelled is False, then variable finished is set to True and B gets from the TTP a certificate kT , indicating that the exchange has been resolved successfully. Again, A and B get non-contradictory certificates. The proof is complete. Theorem 2 The proposed changes on the FPH protocol provide non-repudiation of both origin and reception. Proof: Let us examine each case in turn, after completion of the protocol, whichever it is. Non-repudiation of origin. Suppose B claims to have received M from A but denies having sent M to B. If the protocol ends without exception, then B gets c, kA and hA , which proves that A initiated the transaction, since A s signature on c is present. Likewise, A cannot deny having sent K since kA contains A s signature. If an exception occurs, then B gets kT , which contains the key K signed by the TTP. 1
Exceptions which do not cause the execution of one of the subprotocols are considered as having no consequence to the parties.
436
J.R.M. Monteiro and R. Dahab
Non-repudiation of reception. Suppose now that A claims to have sent M to B but B denies the reception of M . If the protocol ends without exception, then A receives hB , which proves that message M , sent to B in an exchange initiated by A, was accepted by B. If an exception occurs, then A receives hB , which proves that B received key K from the TTP, relative to the exchange initiated by A, having B as recipient. This concludes the proof. We note that resolving a dispute follows the same outline of Section 3.1.
7
Conclusions
The use of symmetric messages in a protocol always brings the possibility of attacks. Specifically, in the case of the FPH protocol, messages derived from different instantiations of the protocol can be brought together to produce contradictory outcomes. This illustrates the tricky features of cryptographic protocols and the difficulty of achieving thoroughness in their analysis. The solution presented to correct FPH’s weakness is simple and the impact on the performance is minimal.
References 1. N. Asokan, Fairness in Electronic Commerce, University of Waterloo, 1998. 2. Ferrer-Gomila, J. L. and Payeras-Capell` a, M. and Rotger, L.H., “An Efficient Protocol for Certified Electronic Mail”, Third International Workshop – ISW 2000 (Berlin) Lecture Notes in Computer Science, vol. 1975, Springer-Verlag 2000, pp. 237–248.
