Certified Electronic Mail Protocol Resistant to a Minority of Malicious Third Parties

Transcription

1 Certified Electronic Mail Protocol Resistant to a Minority of Malicious Third Parties Macia Mut Puigserver, Josep Lluis Ferrer Gomila and Lloreq Huguet i Rotger Department de Cikncies Matemitiques i Informhtica Universitat de les Illes Balears Carretera de Valldemossa km 7.5,07071 Palma, Spain dmimmp4@ps.uib.es. AbstractlWe.. present the design of a protocol for certified e- mail. Some proposed certified protocols involve a third party in order to guarantee a fair exchange. Users, therefore, have to deposit a great amount of trust in a remote third party. In addition to that, the third party can become a communication bottleneck. We propose a protocol that involves an organisation of third parties, but only in case of exception. It reduces the amount of trust deposited in the third parties, because a minority of malicious third parties cannot compromise the fairness of the exchange, since all the third parties made a decision voted on by members. I. INTRODUCTION Certified is a TJalue added to an system. It must be a fair exchange: at the end of the exchange, it must be guaranteed that either each party has received what it expects to receive or neither party has received anything useful. On the one hand, in order to achieve fairness the sender of the has to be able to prove that the recipient has received it. On the other hand, the recipient has to be able to prove that the sender was the really originator of the message. Then, we are going to use non-repudiation services. Some non-repudiation services are defined in the IS0 documents [lo, 11, 121. We are interested in: - Non-repudiation of origin (NRO): this service is intended to protect (the recipient) against the originator s false denial of having approved the content of a message and of having sent a message; and - Non-repudiation of receipt (NRR): this service is intended to protect (the originator) against a recipient s false denial of having received a message. It s difficult to oblige the involved parties to send a nonrepudiation token. Thus, some protocols for certified use a third party to ensure fairness. Sometimes these third parties are actively involved in the protocol [6, 4, 5, 181. In others solutions, third parties are only used in case of exception [l, 9,7]. Another kind of protocols for certified e- mail tries to achieve fairness by the gradual release of secrets In this document, token represents one or more items that have some property or concrete meaning. over many rounds [16, 4, 21. These protocols need no third party, but they are not practical due the high communication overhead. Besides this obstacle, fairness is based on the assumption that the parties involved in the exchange have a similar computational power, and this assumption is unrealistic [3]. The protocols, which use a third party in every protocol run, present a drawback: the third party could become a communication bottleneck. Furthermore, the malicious behaviour of the third party can compromise the security of the exchange. Some protocols solve this problem by replicating the third party such that a minority of malicious and colluding third parties cannot compromise the security of the exchange [8]. These protocols use the expensive threshold cryptography. We propose a certified protocol in which the third parties are only involved in case of exception and can tolerate (i.e. the fairness is not compromise) malicious behaviour of a minority of third parties without using a threshold scheme. The sender and the recipient of the certified message must agree on a deadline. We assume that before this deadline the originator or the recipient can contact a third party if they believe the fairness hes been compromised. 11. PRELIMINARIES In this section, we review some primitives used in next sections. Our protocol uses symmetric and public-key cryptosystems. Computationally secure cryptosystems can of course be found [14, 151. Use of one-way hash functions is central to public-key cryptography [14, 151. Thus, we sometimes take the output of a one-way hash function as input of a public-key cryptosystem. The recipient of an encrypted message can reliably obtain the originator s public key by means a X.509 certificate [17]. The following notation is used: X + Y: m, n Originator X sends messages m and n to recipient Y. X 4 Y: m= [a, b,...i Message m is sent to Y. This message contains items a, b, /00/$10.00 (c) 2000 IEEE 1401 IEEE INFOCOM 2000

2 X 4 "PI... TP,: m Message m is multicasted by X to recipients TpI, TP2... TP, "Pi + X: mi (1<= i <= n) Originators TPl, TP2... TP, send to X messages ml, m2... m,, respectively. PRXb) Encryption of message m with the private key of user X. In this encryption, all the computations are done in a system with the same features of RSA system [ 131 h(m) Output of the one-way hash function h taking message m as input string. m = X,=l..n mi Message m is formed by the items ml, m2... m,,. In. THE CERTIFTED PROTOCOL The certified protocol consists of the exchange of a message and probably with a non-repudiation of origin token against a non-repudiation of receipt token. In our protocol a user, who wishes to send a certified , must have a contract with a third party. When an exception occurs in the certified protocol, any party involved in it should contact this third party, in order to solve the exception. The third party is a member of an organisation of third parties that made a decision about a protocol exception case voted on by members. This decision is made in accordance with the protocol for exception case specified below. This means that either a sender or a recipient of a certified message trusts in the organisation and they need not trust with only one third party. The protocol is resistant to a minority of malicious and colluding third parties, because the decision is made directly or indirectly by the organisation of third parties. The third parties are involved in the certified protocol only when an exception occurs (e.g., one of the two parties involved in the protocol does not receive the appropriate message in accordance with the protocol). When sender has a contract signed with a third party, during the time of this contract she can send any number of certified messages. Of course, before is sent it's necessary that recipients accept the third parties' mediation in case of exception. A. Protocol Description In this section, we more carefully describe our certified e- mail protocol. First, a user who wish to send a certified e- mail message has to run the Contract Protocol. Then she can send an by running the protocol called Basic Protocol. After this, if no exception has occurred, the recipient will have the with a proof of non-repudiation of origin, and the sender will have a proof of non-repudiation of receipt. 1. The Contract Protocol Remember that a user (whom we will call Alice) must have a contract with a third party in order to send certified e- mail. She therefore has to contact with a third party in an association of third parties. In the first protocol step, Alice sends her credentials (e.g. an identification ZdA) and a deadline ta to this third party, WO. The deadline ta is the time limit before which TPo (or its organisation) holds the exceptions that occurs when Alice sends a certified . In the second step, if TPo accepts this request, it notifies to the others third parties that the user has requested the intervention of the third parties in exception case. Finally, after all third parties have accepted the user's request, "Po sends to Alice the contract of support in case of exception (indicated as CA). The Contract Protocol is as follows: CA~ is the set of messages each TPi (i=l..a) sends to WO in order to accept the user's request. If one or more third parties decline the request then the organisation won't intervene in the protocol. The CA token is formed by the set of CAi items and the item by which TPo accepts the user's request. Observe that in CA there are the signature of all the third parties linked to the user's name, the deadline ta and the number of third parties (n+l). Of course, the third parties organisation is operative until t~ at least. Otherwise TPo could suggest another covering time. 2. The Basic Protocol The Basic Protocol is divided in two subprotocols. The first subprotocol is the transmission set up, in which the originator, Alice, sends to the recipient, Bob, the parameters of the certified transmission. If Bob accepts these parameters, then the second subprotocol, can start: transmission of the certified message. The Transmission Set Up Subprotocol is as follows: 1. Alice + Bob: p = [h, t '~, CA, I, ml, SA = PRA(h@)) 2. Bob +Alice: sb = PRB(h(p)) message p contains the parameters: /00/$10.00 (c) 2000 IEEE 1402 IEEE INFOCOM 2000

3 * t A m is an estimated deadline before which the sender or the recipient have to contact with the TPo in case of exception in order to solve it. ta is of course greater than tk. is a number less than n+l and greater than (n+ 1)/2; representing the minimum number of third parties that must act in accordance with the protocol (i.e. third parties that must not be malicious). * I is a number that identifies the transaction. The message sb is the parameters acceptance of the recipient Bob. When Alice receives sb, she can generate a key K of a symmetric cryptosystem, and she encrypts the e- mail message M and it starts the transmission. If Bob doesn t accept the parameter, then he doesn t send SB and the protocols ends. The Transmission Subprotocol is as follows: 1. Alice + Bob: c = EK(M), ha = PRA(h(c, I>) 2. Bob -+ Alice: hb = PRB(h(c, I>) 3. Alice + Bob: k~ = PRA(K, I) 4. Bob -+ Alice: kb = PRB(K, Z) where c is the encrypted message using the key K. When Bob receives ha, he sends hb. The hb item is the recipient s commitment to receive the message. Next Bob receives K, signed by Alice, and he can decrypt c. Items ha and ka are the non-repudiation of origin token. Finally, Bob sends kg. Items hb and kb are the nonrepudiation of receipt token. We have described the last subprotocols separately, because they have a different objective. However, in order to make the Basic Protocol more efficient, we can group the subprotocols as it follows: 1. Alice -+ Bob: p, C, h~ 2. Bob 3 Alice: sg, hg 3. Alice 4 Bob: ka 4. Bob 3 Alice: kb B. The Protocol when an Exception Occurs When the sender or the recipient does not receive the appropriate item in accordance with the protocol, the affected party has to contact with Po. In any exception, TPo attempts to contact the party that supposedly not fulfilling the Basic Protocol. If this part replies as the Basic protocol specifies, then it s completed as described above. But if it isn t possible to complete the Basic Protocol, then third parties will act as we describe bellow providing that these third parties aren t malicious. I. No reception of the kb item When Alice claims, before the deadline t A, that she has not received the kb item, then she should run the following protocol: 1. Mice 4 P o : p, Sg, C, ha, he, ka 2. P o 4... TPn: p, ka 3. TP,... TP, + TPo: ACK = PRTpi ( ok, Z) [min. m] 4. TPo 4 Alice: kt = PRm(h(c, I, ACK)), ACK In this protocol, Alice sends to TPo the information that she has about the transaction. Then TPo can verify that Bob wishes to receive the certified message (WO checks hb). Next TPo notifies it to the others third parties. When WO receives the approval (the encryption with the private key of the ok text and the transaction identification) from at least m third parties (designated above, in the third step, as [min. m]), then TPo sends kt, that has the same effect as kb item. However, the possibility exists that Alice will be unable to contact TPo before t A. In this case, between the deadlines tfa and ta, if Alice wishes to complete the non-repudiation of receipt token, she has to contact all third parties following these steps: 1. Nice 3 TPo... wn: p, Sg, C, ha, hg, ka 2. WO... TP, + Alice: kn = PRTpi(c, 0 [min. m] where an amount of m kn items has the same effect as kb item. There is another special case: If Bob runs the protocol specified in the next section, he can obtain a cancellation of the transaction. Since Bob claims, before t A, that Alice doesn t fulfil the Basic Protocol. In this case, the second step, specified above, must be: 2. TPo... TP,, Alice: klti = PRTpi(c, Z, cancellation- alert ) In these messages, third parties signs the text cancellation- alert in order to notify to Alice that Bob has cancelled the transaction. 2. No reception of the ka item When Bob claims3, before the deadline t A, that he has not received ka, then he should have to run the following protocol: Observe that Alice claims for that, but this claim has not been proved. Observe that Bob claims for that, but this claim has not been proved /00/$10.00 (c) 2000 IEEE 1403 IEEE INFOCOM 2000

4 2. TPo j Bob: ST = PRTpo(h(p>) 3, TPo + TPI... TP,: p, PRTPO(sT, cancellation ) 4. (when t,)tp0 j Bob: ctp PRTPO(h( cancellation, c, 0) In this protocol Bob sends to TPo the information that he has about the transaction. In the second step TPo sends ST to Bob in order to admit the request. Next TPo can verify that Alice started the communication, and TPo attempts to contact her. If Alice doesn t reply, TPo sends Bob the cancellation of the transaction (cto item) at the time tja. TPo notifies the Bob s request to the others third parties sending to them the transaction parameters and the text: cancellation. If before or during the running of this protocol, the user Alice runs the protocol specified in the section 3.2.1, then the last step of the protocol of this section must be: Bob may be unable to contact T P O before t A. In this case, between the deadlines tk and ta, if Bob claims that he does not receive the ka item, then he has to contact with all third parties of the organisation, following these steps: where an amount of m cti items has the same effect as C T ~ item. However, if Alice has run any protocol of section then the second step must be: IV. DISCUSSION We will now explain why our protocol meets the requirements for certified listed in the first section. When the Basic Protocol ends successfully, then the fairness of the exchange is of course assured: the sender has a nonrepudiation of receipt token (the set of hb and kb items) and the recipient has the message and a non-repudiation of origin token (the set of ha and ka items). In case of exception, if at this moment the time t is less than t A, then the protocol achieves fairness for the sender and the recipient. The third parties can generate a replacement item for a non-repudiation of origin token or for a nonrepudiation of receipt token when the sender or the recipient contact WO. If at least m third parties act in accordance with the protocol, they can: - Generate a replacement item for the sender (the kt item) - Revoke the hb item sent by Bob (the CTO item). - Generate a replacement item for the recipient Bob (the kat0 item). If Bob contacts with the third parties after the time tia and he claims that he has not received the ka item, then he can receive from the third parties one of these two tokens: i) At least m cti items, which are the cancellation token of his commitment to complete the protocol (the hb item). ii) At least one kan item, where Bob can achieve the ka item that complete the token of the non-repudiation of origin promised by the sender. Therefore the protocol also provides fairness for the recipient in this case. Fairness of the exchange for Alice, when she contacts with the third parties after tla, follows from the fact that if she did not receive kb, then she receives from the third parties the set of kn tokens that are equivalent to the kb item. However, in the special case that the recipient Bob has a cancellation of the exchange, the third parties can t send Alice a nonrepudiation of receipt token. Thus, they can only alert to Alice that although she says that she has sent ka, Bob has said that he does not receive it. Therefore the third parties can only issue the k Ti items attesting to what happened during the exchange. Alice can use the set of kjtitems in an external dispute resolution system to achieve fairness. Note that in this last special case, when Bob has already achieved fairness thanks to the cancellation token, then third parties can t send Alice the equivalent of a proof of nonrepudiation of receipt because the third parties can t degrade the fairness achieved by any user. We have defined t A as an estimated deadline within which the sender or the recipient has to contact WO in case of exception. t A should be close to the current time t (the time at the moment of setting up the protocol) in order to solve the exception as soon as possible. Moreover, the distance between t and t A must be sufficient to complete the Basic Protocol and in case of exception to contact TPo even if the network connections between TPo and the users are unreliable. However, if an exception occurs, the user can contact the third parties after the deadline t A, but fairness is not guaranteed in this case. The third parties will not generate replacement tokens in the name of a correctly behaving party but can do so in the name of an incorrectly behaving party. Thus, when a third party is invoked by the sender or the recipient of a certified e- mail, first it checks the correctness of the messages, in order to see if the user invoking the third party has received a /00/$10.00 (c) 2000 IEEE 1404 IEEE INFOCOM 2000

5 commitment message from the other party. Next the third party tries to contact the party that supposedly has not fulfilled the protocol and finally the third party generates a replacement item only if it receives no response from this party. One importantaspect is that it isn t necessary for the users to deposit unconditional trust in the third parties. A replacement item issued by the third parties has the right meaning only if at least m third parties agree with it. Then, [I] the protocol guaranties fairness if only m third parties of the organisation act correctly. The rest of third parties (n-m third parties) can be malicious (for instance, they can deny the [21 service for a user s petition) and the protocol guarantees fairness. Note that the fairness is guaranteed even TPo is one of these malicious third parties. Thus, in the worst case: when TPo is a corrupted third party and a network partition occurs as Alice is sending ka. Alice believes the message got through and asks the corrupt TPo for confirmation. TPo follows the protocol and returns Alice a valid kt. Meanwhile Bob asks for cancellation and at t * the corrupt WO sends a ct0 token. Therefore, Alice has a non-repudiation of receipt token and Bob has a valid cancellation token. Alice and Bob have both acted in good faith, and it seems that TPo has broken the system. However, if afterwards Alice or Bob feels damaged by the malfunction of the malicious TPo, he or she can go to an external dispute resolution system (like a court) to achieve fairness. Then it will be clear that TP, has signed two tokens with opposite meaning and therefore WO didn t fulfil the protocol. Then TPo must take the consequences of applying the law and the third parties organisation s policy. With this protocol, users therefore doesn t have unconditional trust in a third party; they only expects that m [I2] of the n third parties act in accordance with the protocol in case of exception. This protocol characteristic is achieved [131 without using a threshold cryptographic scheme. V. Conclusions We have presented the design of a practical protocol for certified . The originator of the has a support contract with an organisation of third parties. When the protocol has concluded, if no exception has occurred, the recipient has the message with a proof of nonrepudiation of origin, and the sender has a proof of nonrepudiation of receipt. Third parties are only involved in the protocol in case of exception. They guarantee fairness when an exception occurs; even if a minority of them are malicious. The design is based on symmetric and public-key cryptographic primitives. We have therefore presented a protocol that guarantees fairness without requiring the intervention of a third party in many rounds (only in exception case) and is resistant to the malicious behaviour of a minority of third parties. It thus reduces the amount of trust the users must deposit with a third party. The protocol achieves these features without using the expensive threshold cryptography. PI U51 [I61 [I71 t181 REFERENCES N. Asokan, Matthias Schunter i Michael Waidner: Optimistic protocols for fair exchange, 4th ACM Conference on Computer and Communications Security, Zurich, M. Blum: How to exchange (secret) keys, Proceedings of STOC 83, pp , Tambe a ACM Trans. Comp. System, 1 (1983), pp , May 1983 Michael Ben-Or, Oded Goldreich, Silvio Micali i Ronald L. Rivest: A fair protocol for signing contracts, IEEE Transactions on Information Theory, Vol. 36, No. 1, pp , January Alireza Bahreman i J.D. Tygar: Certified electronic mail, Proceedings of Symposium on Network and Distributed Systems Security, Internet Society, San Diego, CA, pp. 3-19, February Robert H. Deng, Li Gong, Aurel A. Lazar, Weiguo Wang: Practical protocols for certified electronic mail, Journal on Network and Systems Management, Vol. 4 no. 3, pp , September Warwick Ford: Computer Communications Security - Principles, Standard Protocols and Techniques; PTR Prentice Hall, Englewood Cliffs, New Jersey, Josep L. Ferrer, LlorenG Huguet and Macih Mut: Protocolo de correo electrdnico certificado, Proceedings of V Reuni6n Espaiiola de Criptologia, MAlaga, M.K. Franklin i M.K. Reiter: The design and implementation of a secure auction service, Proceedings of 1995 IEEE Symposium on Security and Privacy, pp. 2-14, Oakland, California, May Josep L. Ferrer, Angel Rotger and LlorenG Huguet: Firma electrdnica de contratos, Proceedings of I11 Reunidn Espaiiola de Criptologia, Barcelona (Spain), ISODEC DIS : Information technology - Security techniques - Non-repudiation - Part 1 : General, ISODEC JTCUSC27 N1503, October ISODEC DIS : Information technology - Security techniques - Non-repudiation - Part 3: Using asymmetric techniques, ISOLlEC JTCllSC27 N1507, October ISODEC DIS : Information technology - Security techniques - Non-repudiation - Part 2: Mechanisms using symmetric techniques, ISOflEC JTCVSC27 N1679, April R. Rivest, A. Shamir i L. adleman: A method for obtaining digital signatures and public key cryptosystems, Communications of the ACM, 21, pp , [I41 Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and Source Code in C; Second Edition, Ed. John Wiley & Sons, Inc, William Stallings: Network and internetwork security: principles and practice; Prentice Hall, Englewood Cliffs, New Jersey 07632, IEEE Press, TEDIS 11: Security in open environtments, TEDIS 11, B7, ver 15, July ITU-T: Recommendation X.509: Information technology - Open Systems Interconnection - The directory: Authentication framework; November Jianying Zhou i Dieter Gollmann: A fair non-repudiation protocol, Proceedings of the 1996 IEEE Symposium on Research in Security and Privacy, IEEE Computer Society Press, Oakland, CA, pp , May /00/$10.00 (c) 2000 IEEE 1405 IEEE INFOCOM 2000