University of Manchester. Manchester M13 9PL. Abstract. Authentication protocols are known to be error prone. In this paper we

Transcription

1 To Decrypt or not to Decrypt? That is the Question Wenbo Mao Colin Boyd Communications Research Laboratory Department of Electrical Engineering University of Manchester Manchester M13 9PL UK wenbo@comms.ee.man.ac.uk colin@comms.ee.man.ac.uk Abstract Authentication protocols are known to be error prone. In this paper we identify non-methodical use of decryption as a typical design feature which is found in many published authentication protocols and is responsible for various problems in these protocols. We reason that authentication protocols can be greatly strengthened by the methodical use of decryption. 1 Introduction Protocols to allow entity authentication and exchange of secrets are an essential element in the provision of cryptographic services which allows secure distributed computations in a hostile environment. In such an environment, methods of attacks available to an adversary are numerous; therefore a protocol designer has to consider a wide variety of issues. Some of the obvious ones concern how many message exchanges are necessary, what data should be included and concealed in messages, how data should be linked to one another and in what order messages This work is funded by the UK Science and Engineering Research Council under research grant GR/G19787.

2 must be passed. These issues have been extensively studied in the literature. (See e.g. [4, 3, 2, 21, 7, 8].) In this paper we will further consider an issue that has seemingly not been suciently studied by the previous work. It is about the usage of decryption. We will conclude that the use of decryption in authentication protocols deserves careful consideration. In Section 2 we briey survey usual authentication mechanisms. The survey shows a widely applied technique is to conceal essentially non-secret data into ciphers for the purpose of being retrieved by the intended recipient through decryption. Several current protocol development projects, e.g. [12, 11, 10], apply this technique. Then, in Section 3 we will point out that this commonly applied technique is not a methodical one. Often the technique does not suce to provide the required security. Furthermore, in terms of data quantity owing on the network and handled by the node computers, the technique in question will be shown as inecient. We will reason that a better way to realise authentication is to employ the one-way service of cryptographic systems rather than that of the secret concealment. In Section 4 we look at the issue from a cryptanalyst's point of view. The non-methodical use of decryption will be shown as tending to form corresponding pairs of plaintext and ciphertext on the network. In most cases an attacker is able to force the system to generate a surprisingly large (unlimited in fact) amount of pairs. These pairs form an eective means for a cryptanalyst to analyse secret keys. It will be clear that due to the incorrect use of decryption, running a protocol to distribute session keys becomes a conceptually wrong idea. Our investigation will result in some insight of how to properly use decryption in authentication protocols. In Section 5, we will demonstrate an example of methodical design of the use of decryption by presenting a new protocol which not only overcomes the various problems to be revealed in this paper, but also self-evidently claries the concept of entity authentication. Below we give two very simple examples to illustrate the idea of this paper: authentication using decryption is not a good technique. 1.1 To decrypt or not to decrypt? Two simple examples In order to make clear the ideas in this paper we now give two simple examples: using and not using decryption to achieve entity authentication. Consider authentication at login on a shared computer (or ATM, etc). Assume that user Alice wants to login. Below is an imaginary protocol with which the host authenticates the genuineness of the user Alice. 1. Alice sends the computer her password as requested. 2

3 2. The host nds the encrypted form of Alice's password stored in the computer and decrypts it. 3. The host compares the result to the value given by Alice. The protocol in step 2 demands the host to perform decryption because in the computer users' passwords must be kept in encrypted form. Storing passwords in plaintext form and using the operation system's le protection mechanism alone to prevent access is not a secure method since, for example, a backup tape can easily be read in another computer. Even with the protective measure specied in step 2 above, this protocol is still not secure. Namely, in order to decrypt passwords the system needs a cryptographic key. Then how to protect this key becomes a problem, indeed, the same as the problem of how to protect passwords stored in plaintext form. Needham of Cambridge University suggested a way to protect passwords, cited in [6]. Needham's idea can be depicted by the following protocol. 1. Alice sends the computer her password as requested. 2. The host encrypts the value given by Alice. 3. The host compares the result to the value stored in the computer. This second protocol does not require the host to perform decryption. The encryption performed in step 2 can simply use a password as a key to encrypt a constant. This is exactly how Morris and Grampp of Bell Laboratories implemented the logging-in procedure for UNIX system ([20] page 46). The second protocol is clearly better than the rst one: there is no secret to be protected; on the contrary, the secrets dealt with by the rst protocol are in fact not protectable. Indeed, as will be seen in the rest of this paper, entity authentication can be achieved better without depending on passing any secret. (Note that secret key distribution is usually a goal, not a means, of running an authentication protocol.) 2 Decryption: a widely applied means for authentication In this section we list published authentication methods and various well-known protocols to demonstrate that the use of decryption for authentication is common in the area of protocol design. First, we list four abstract authentication methods which are due to a survey of Gong [9]. The abstract protocols 3

4 Usage 0 Usage 1 A! B : ft A g K 1. A! B : N A 2. B! A : fn A g K Usage 2 Usage 3 1. A! B : fn A g K 1. A! B : fn A g K 2. B! A : N A 2. B! A : ff(n A )g K In the above protocol presentations, the line A! B : M describes a message communication directed from principal A (Alice) to principal B (Bob) and M is the transmitted message. The notation fmg K denotes a ciphertext generated from a (symmetric) crypto-algorithm which uses M as input data and K as encryption key. Finally, T X is a timestamp and N X, a random number called a nonce; both are generated by principal X. Identiers T X and N X in the above four protocols are called freshness identiers. Intentionally designed messages which contain freshness identiers and are passed between principals form a so-called challenge-response mechanism. A principal sends a message as a challenge to test if the intended recipient is able to respond correctly and promptly. Since a challenge-response communication usually involves performing cryptographic actions, a prompt and correct response provides evidence of possessing the relevant information (e.g. holding the expected cryptographic key) hence proves the personal identity. The four usages listed above are four typical treatments of the freshness identiers. Usages 0, 2 and 3 require Bob, as a recipient of the messages, to perform decryption in order to retrieve the respective freshness identiers. The usage 1 may be interpreted in two ways: Alice may either perform decryption to retrieve the nonce N A, or she may encrypt the nonce, which is in her possession, and then compares the result with the ciphertext received. However, in the real application, often the replied nonce is concatenated with a secret, e.g. session key; therefore the rst interpretation, i.e. the use of decryption, is a usual case. In any case, the two possible interpretations mean that the specication is not complete and not precise, a weakness of the widely applied method for protocol specication. Below we list several concrete protocols in the real world. We will analyse these protocols in the next two sections. Here we only point out that each of these protocols makes use of decryption as a means for authentication. In other words, the treatments of freshness identiers in these protocols fall into the four usages listed above. The Otway-Rees protocol [18] 1: A! B : M; A; B; fn A ; M; A; Bg KAS 2: B! S : M; A; B; fn A ; M; A; Bg KAS ; fn B ; M; A; Bg KBS 3: S! B : M; fn A ; K AB g KAS ; fn B ; K AB g KBS 4

5 4: B! A : M; fn A ; K AB g KAS (1) The Otway-Rees protocol involves two one-way authentications by the two client principals Alice and Bob, respectively, towards the trusted authentication server S. Here nonces N A and N B are treated as though they are secrets; the recipients have to perform decryption to retrieve them. We may regard such a nonce treatment to be usage 3. The Kerberos protocol [15, 12] 1: A! S : A; B 2: S! A : fk AB ; B; T S ; L; fk AB ; A; T S ; L; g KBS g KAS 3: A! B : fk AB ; A; T S ; Lg KBS ; fa; T A g KAB 4: B! A : ft A + 1g KAB (2) This is a slightly simplied specication of the protocol which is sketched from the newest version of the distribution (V5) [12]. Here, L is a lifetime stating the expiration time of the distributed session key K AB. Clearly, the treatment of the timestamp T S in the protocol is usage 0 and that of T A is usage 3. (A timestamp can be thought of as a nonce.) The Yahalom protocol [22] 1: A! B : A; N A 2: B! S : B; N B ; fa; N A g KBS 3: S! A : N B ; fb; K AB ; N A g KAS ; fa; K AB ; N B g KBS 4: A! B : fa; K AB ; N B g KBS ; fn B g KAB (3) The treatment of the nonces in this protocol does not seem to fall into any usage of the abstract protocols. However, the two nonces are sent in plaintext by their respective initiators, who may consider that the nonces are sent out to the server. From this point of view we may regard the treatment of the nonces to be usage 1 where the decryption interpretation applies. A protocol in ISO/IEC CD document The following protocol is a simplied version of \the key estabishment mechanism 6" in ISO/IEC JTC1/SC27 document N832 [10]. The protocol is specied at a lower level: various redundant data are used for providing message integrity. We omit presentation of any optional redundancy such as textelds in the encrypted part of the messages, but keep the important redundancy in the presentation. (See MAC K (), message authentication code, in the following protocol. In Section 4 we will discuss properties of a MAC) 1: A! S : N A ; B 5

6 2: S! A : fn A ; K AB ; Bg KAS ; MAC KAB (fn A ; K AB ; Bg KAS ); ft S ; K AB ; Ag KBS ; MAC KAB (ft S ; K AB ; Ag KBS ) 3: A! B : ft S ; K AB ; Ag KBS ; MAC KAB (ft S ; K AB ; Ag KBS ) 4: B! A : fn B ; Ag KAB (4) This protocol is based on the Needham-Schroeder protocol [17], but makes use of a timestamp to remove an attack due to Denning and Sacco [5]. It is clear that the treatment of the timestamp T S is usage 0 and that of the nonce N A is usage 1. Finally, considering that after the completion of a protocol run, a session communication between Alice and Bob will subsequently take place which assures Bob that Alice has decrypted the message line 4 by using the new session key, therefore the treatment of the nonce N B is essentially usage 2. We have seen that making use of decryption is a widely applied means for achieving entity authentication. In the next two sections we will investigate various disadvantages of such a method. 3 A Basis for Replay Attacks As we have seen in the previous section, freshness identiers in authentication protocols are usually designed such that (1) they are not intended as secrets and (2) they are encrypted in some messages for the purpose of later being retrieved by the recipient(s) through decryption. In this section we reason that protocols with messages designed for allowing retrieval of non-secret data can be vulnerable to various replay attacks. We will look at two attacking scenarios. The rst attacking scenario we look at is called \reection replay". Here a message which cannot be cryptographically handled by an attacker is bounced back to the sender so the latter will do the job for the former. Below we provide an example of a reection-replay attack on the Yahalom protocol (3). This attack is due to Syverson [22]. (In the following presentation, \E X " refers to the attacker, Eve, masquerading as principal X.) An attack on the Yahalom protocol 1: E A! B : A; N A 2: B! S : B; N B ; fa; N A g KBS 1 0 E A! B : A; (N A ; N B ) 3: Omitted 2 0 B! E S : B; N 0 B ; fa; N A; N B g 4: E A! B : fa; N A (= K AB ); N B g KBS ; fn B g KAB This attack begins with the attacker masquerading as Alice and sending an 6

7 initial message to Bob. After the second message, Eve initiates another run of the protocol, again masquerading as Alice. She uses N A concatenated with N B from the rst run as the nonce in message line 1 0 of the second run. Once she has the encrypted message she intercepts from Bob in 2 0, she drops the second run. She then uses this for the rst encrypted chunk in the last message of the rst run. N B was previously sent as plaintext, and K AB is actually N A which also appeared as plaintext. Thus, she can produce the second encrypted chunk of message line 4. At the end of the attack, Eve has masqueraded as Alice to Bob and obtained the distributed session key. This is an interleaving attack which means it relies on messages constructed of message elements from contemporaneous protocols runs. If the second run is not begun during the rst run, Eve cannot successfully complete the attack. The attack also assumes that substituting two concatenated nonces for one will go undetected and be passed along when sent to someone who has no need to check the nonce. The second attacking scenario we will look at does not rely on interleaving protocol runs. We shall refer to it as \cut-and-paste replay". Here, an attacker substitutes fragments of messages with old ones which contain data known to the attacker. Pairs of corresponding plaintext and ciphertext (which are usually generated by protocols allowing retrieval of non-secret data through decryption) are particularly suitable material to be replayed in a cut-and-paste attack. Below we demonstrate such an attack on the ISO/IEC protocol specied in (4). In the attack, we assume that the attacker Eve has the following ciphertext: f ; A; Bg KAS Here, \A" represents a block of plaintext known to Eve, which can be an old session key, or part of address of the principal Alice; \B" represents the address of the principal Bob. Eve can obtain this ciphertext fragment through eavesdropping e.g. a run of the Otway-Rees protocol. An attack on the ISO/IEC protocol 1: A! S : N A ; B 2: S! E A : fn A ; K AB ; Bg KAS ; MAC KAB (fn A ; K AB ; Bg KAS ); 2 0 : E S! A : fn A ; A; Bg KAS ; MAC A (fn A ; A; Bg KAS ); 3: A! E B : 4: E B! A : fn B ; Ag A In this attack, Eve replaces the message fragment \K AB ; Bg KAS " with her recorded material \A; Bg KAS " (see the underlined message parts in the attacking run). The result of this message manipulation is that Alice will obtain \A" as the distributed \session key". Alice cannot detect this manipulation because using 7

8 the bogus session key, Eve can reproduce a bogus MAC to cheat Alice. ISO/IEC CD document stipulates use of cipher block chaining (CBC) algorithm to implement the specied encryption in the protocol [10]. In that case, it is reasonable to assume that the nonce N A occupies a whole data block in usual size (e.g. 64 bits in the case of DES) and that block is followed by the block for the session key K AB. Then the bogus session key will be confounded by the ciphertext block C = fn A g KAS into C A where stands for the bitwise XOR operation (for the CBC calculation, see e.g. [14]). This bogus key is still available to Eve. Perhaps the reader has discovered the real problem of this protocol: the elements for integrity protection, MACs, are keyed by a wrong key (i.e. an uncerti- ed session key). The attack cannot go undetected if, say, the MAC to be checked by Alice is keyed by the key K AS. This is true. Then, since a correctly keyed MAC which encapsulates a freshness identier will suce to prove the timeliness of the message responded from the server, it becomes clear that there is no need to conceal any non-secret data, such as timestamps, nonces and principal names, into messages to be retrieved later through decryption. For instance, message line 2 of the ISO/IEC protocol can be simplied into the following: 2: S! A : fk AB g KAS ; MAC KAS (N A ; fk AB g KAS ; B); fk AB g KBS ; T S ; MAC KBS (T S ; fk AB g KBS ; A) This simplication turns the ISO/IEC protocol into one which makes no use of decryption for authentication. Here, MAC K (M) is a block of checksum of the input data M keyed under the key K. Usually, the input data M is a much longer string compared with the size of the checksum block. To date there exists no known ecient algorithm to invert an encryption transformation like the one which generates a MAC. Also, without knowledge of the encryption key, it is computationally infeasible to form a MAC from a given string. Due to these properties, it is clear that the cut-and-paste replay attack cannot be performed on a MAC. A cryptographic transformation with the properties of a MAC is usually referred to as a one-way transformation. In the rest of this paper, we will use the symbol [M] K to denote a ciphertext obtained from a one-way transformation. Other concrete protocols listed in Section 2 can similarly be simplied to eliminate the unnecessary use of decryption. For instance, a version of the Yahalom protocol without using decryption for authentication can be as below: 1: A! B : A; N A 2: B! S : B; N A ; N B ; [A; N A ] KBS 3: S! A : N B ; fk AB g KAS ; [B; fk AB g KAS ; N A ] KAS ; fk AB g KBS ; [A; fk AB g KBS ; N B ] KBS 4: A! B : fk AB g KBS ; [A; fk AB g KBS ; N B ] KBS ; [N B ] KAB 8

9 This revision can be viewed as a more complete specication of the original version. It clearly species that for any non-secret data cryptographic transformation is one-way encryption; the recipient of a ciphertext message [M] K should perform an encryption by using the non-secret data M to verify the integrity of the received ciphertext message. Elsewhere, the revised protocol preserves the same design structure as the original protocol. Now that no nonce will be retrieved from any message, there is no chance for the attacker to change a nonce into a key. In the next section we will further see that not to use decryption for authentication is also desirable for preventing cryptanalysis. 4 A Basis for Cryptanalysis For each concrete protocol listed in Section 2, it is assumed that between each client principal and the server there exists a secure channel. This channel is established through some expensive method in a higher level of the security hierarchy and because of this, such a channel is intended to use for a long period of time. Let such a channel be referred to as a long-term channel. It must be understood that the security essence of a long-term channel is its narrow bandwidth: its usage must be limited only to establish other channels of wider bandwidth. In other words, authentication protocols in distributed computing are meant to use a secure long-term channel to transmit or to agree a small amount of secrets (usually, a cryptographic key) which may serve as a new secure channel (called a session channel) along which information can be transmitted with a smaller delay. Notice that a channel with a wide bandwidth is vulnerable to temptations in terms of cryptanalysis; it therefore should be limited to have a short lifetime. Whenever needed, communication parties should run an authentication protocol to create a new session channel. It is thus clear that the reason for maintaining the narrow bandwidth of a longterm channel is in order to foil cryptanalysis passively and/or actively targeted on it. Only by taking this into account does the required and assumed long lifetime of a long-term channel make sense. In public-key cryptographic techniques there is also a need for thoughtful use of a long-term channel. For instance, in the case of the RSA algorithm [19], a long-term channel between a pair of principals can be identied with the private keys of each party; such a key is matched to the public key which is certied to the principal. This viewpoint should be considered when the RSA algorithm is used to \bootstrap" a conventional encryption scheme. We shall keep in mind the working principle of entity authentication discussed above while we investigate a further disadvantage of unnecessary use of decryption: a basis for cryptanalysis. 9

10 Recent advances in cryptanalysis [1, 23] have shown that resilience to known plaintext attacks is not so easy to achieve as had been previously thought. It is worth noticing that protocols which use unnecessary decryption can particularly be abused to form a substantial (in fact, unlimited) amount of plaintext/ciphertext pairs. Below we use the Kerberos protocol to reveal this weakness. 4.1 The Kerberos Protocol We nd that the Kerberos protocol (see specication (2) in Section 2) has two design features which will help an adversary to undermine a longer-term channel between a client principal and the server. The rst feature is that a request from a client principal to the server is sent in plaintext. Thus the adversary's action is not only limited to passive monitoring of the normal runs of the protocol on the network trac, which can only allow her to obtain a trivially small amount of plaintext/ciphertext pairs. The opponent can in fact masquerade as Alice and send an unlimited number of plaintext requests to the server, who presumably is a node in the computer network and will prompt the opponent by supplying encrypted messages onto the network. The second feature is that in the encrypted message from the server, known data, i.e. the name and address of Bob, follows a session key which varies in every instance of response returned from the server. Thus in the cases of the usual encryption algorithms (in the case of Kerberos, they are either cipher feedback (CFB) or cipher block chaining (CBC)) the constant known plaintext will be \confounded" by the feedback of the previous ciphertext output and the consequence is: simply repeating a constant request, the opponent will be guaranteed to obtain varied plaintext/ciphertext pairs with which she can build a dictionary. This scenario is obvious in the case of a stream cipher in CFB mode of operation which Kerberos V5 proposes to use [12]. In such a case, the opponent can simply perform addition, bitwise modulo 2, between the known plaintext and the ciphertext; then by dividing the number of feedback bits into that of the resulting ciphertext stream, it is easy to work out plaintext/ciphertext pairs. The smaller the feedback quantum, the more pairs will result from a given amount of ciphertext. This makes it clear that it is a bad practice to encrypt known data with CFB mode of operation, particularly when the feedback quantum is small. Previous versions of Kerberos use CBC mode of operation as the encryption algorithm. We now explain how plaintext/ciphertext pairs are generated in this case. The output of a block cipher using CBC mode is a sequence of n-bit cipher blocks which are chained together in that each cipher block is dependent not only on the current input plaintext block, but also on the previous output cipher block. Let P 1 ; P 2 ; ; P m be plaintext blocks to be input to CBC algorithm 10

11 and C 1 ; C 2 ; ; C m be ciphertext blocks output from the algorithm. Then the encryption procedure to generate a block of ciphertext is as below: C i = ek(p i C i?1 ) where ek() denotes an encryption algorithm keyed by K and denotes the addition, bitwise modulo 2. So P i C i?1 and C i form a plaintext-ciphertext pair. From our analysis so far it is apparent that the Kerberos protocol can be abused by an opponent to obtain an arbitrary amount of plaintext/ciphertext pairs. It is not hard to imagine that by performing the attack in a short period of time, the amount of pairs gathered by the opponent can exceed the quantity of ciphertext of a session where a session key is used. This forms rather a strange situation regarding the working principle of authentication that we discussed in the beginning of this section: a session key which generates a smaller amount of ciphertext-only data is stipulated to have a short lifetime while a key which can generate a larger amount of plaintext/ciphertext pairs is, on the contrary, to be used in a much longer period of time. Considering that cryptographic keys in modern encryption algorithms (such as DES) have a xed format, it cannot be that some keys are unconditionally stronger than others. The stipulated difference in lifetimes of the keys are due to the consideration of dierent types of data to be encrypted. Unfortunately, this reasonable stipulation turns out to be a dangerous practice. It seems there is a simple cure for the problem: the server should record the requests from clients; if repetitions of a constant request are detected within a short period of time, the service should be denied. However, this then allows a denial of service attack with which a malicious person can cheat the server to stop serving innocent clients. Indeed, a denial of service attack of this kind can only be prevented if such an attack is allowed. Other concrete protocols listed in Section 2 similarly suer the same cryptanalytic problem. For instance, in the case of the Otway-Rees protocol (see (1) in Section 2), an opponent can simply repeat a constant rst message line, to which Bob has to prompt the messages in line 2 onto the network. The second encrypted chunk in that line is not a constant because of the prex nonce N B. Therefore a dictionary of pairs can be created by using these messages. In general, we may say that the same cryptanalytic scenario applies to protocols which are designed to prompt onto the network messages from which non-secret data can be retrieved by decryption. This is because the usual encryption algorithms use a random value for initialisation; the constant non-secret data input to such algorithms will result varied plaintext-ciphertext pairs. The foundation of the problem is the use of decryption for non-secret data retrieval. 11

12 5 Methodical Use of Decryption We have revealed various problems in several well-known authentication protocols due to the use of decryption for non-secret data retrieval. In Section 3, we have also demonstrated examples of how to rewrite existing protocols into ones without unnecessary use of decryption. From the rewriting examples it is quite clear that a routine method for protocol design can be concluded. Namely, whenever an element is not intended as a secret, the cryptographic service made on the element should be a one-way transformation which results in a ciphertext not invertible even by its legitimate recipient. The recipient of such a ciphertext should re-encrypted using the non-secret data to verify the integrity of the received messages. In this section we further develop the idea of avoiding using decryption for non-secret data retrieval into one which advocates a methodical use of decryption for properly handling intentionally designed secrets. We illustrate our idea development through improving the Otway-Rees protocol. First of all, we note that in the Otway-Rees protocol (see (1) in Section 2) the two nonces need not be treated as secrets. This point can be made clear in the following revised version of the protocol which does not use unnecessary decryption (recall Section 3 for one-way encryption notation [M] K ): 1: A! B : M; A; B; N A ; [N A ; M; A; B] KAS 2: B! S : M; A; B; N A ; N B ; [N A ; M; A; B] KAS ; [N B ; M; A; B] KBS 3: S! B : M; fk AB g KAS ; [N A ; fk AB g KAS ] KAS ; fk AB g KBS ; [N B ; fk AB g KBS ] KBS 4: B! A : M; fk AB g KAS ; [N A ; fk AB g KAS ] KAS (5) Here, the two nonces, though no longer treated as secrets, still form a correct challenge-response mechanism; namely, they allow the two client principals, Alice and Bob, to verify the timeliness of the messages responded from the server. Now that there is no need for any recipient to perform data retrieval from ciphertext messages denoted by [M] K through decryption, there is no need to send the whole ciphertext which quantitatively corresponds to the plaintext input. Usually, the data size of [M] K is much smaller than that of M. The incomparable data sizes between M and [M] K mean that they do not form a useful plaintext/ciphertext pair for an adversary. In this sense, the revised protocol is clearly an improvement from the original version. Further examining the revised Otway-Rees protocol (5) we nd that there is actually no secret passed along a long-term channel between the server and a client principal. The distributed session key is not a secret to the third party. Lack of a secret transmitted along the long-term channel makes the channel too 12

13 exposed, namely, to the third party. An opponent who has a long-term channel with the server may exploit this feature. Let Eve be such a person. She can replay a constant message line 2 of the protocol (5) as follows: 2: E! S : M; A; E; N A ; N E ; [N A ; M; A; E] KAS ; [N E ; M; A; E] KES To this, the server will repeatedly prompt varied message line 3 to Eve as follows: 3: S! E : M; fk AE g KAS ; [N A ; fk AE g KAS ] KAS ; fk AE g KES ; Since Eve knows the session key K AE, she can build a dictionary of pairs K AE, fk AE g KAS for undermining the long-term channel between Alice and the server. An authentication system called the KryptoKnight which does not make use of decryption for authentication [16] suers a similar problem as this revised Otway-Rees protocol suers (see [13]). The underlying reason is the same: lack of secret passed along the long-term channel makes the channel too exposed. A remedy for this problem is to intentionally design a secret to be passed along a long-term channel. Together with the long-term key, the two secrets will eectively protect each other. A protocol to realise this idea is given below. 1: A! B : M; A; B; fn A g KAS ; [fn A g KAS ; M; A; B] KAS 2: B! S : M; A; B; fn A g KAS ; [fn A g KAS ; M; A; B] KAS ; fn B g KBS ; [fn B g KBS ; M; A; B] KBS 3: S! B : M; fk AB g NA K AS ; [M; B; N A ; fk AB g NA K AS ] KAS ; fk AB g NB K BS ; [M; A; N B ; fk AB g NB K BS ] KBS 4: B! A : M; fk AB g NA K AS ; [M; B; N A ; fk AB g NA K AS ] KAS (6) In terms of functionality of entity authentication and key distribution, this protocol is the same as the two previous versions of the Otway-Rees protocol in (1) and (5). Now, nonces N A, N B become secrets again. However unlike in the original Otway-Rees protocol, here these secrets are purposely designed to protect the long-term channels. In the message replied from the server, the session key is passed through two one-time channels based on one-time keys N A K AS and N B K BS, respectively. As long as the nonces are properly chosen and are new for each run, the breakage of these one-time channels does not break either longterm channels. Finally, we note that this protocol does not create any useful plaintext/ciphertext pairs against the long-term channels. 6 Conclusion A recent result in cryptanalysis [23] has shown that it is not so hard to break the DES encryption box through key search provided that one pair of plaintext/ciphertext is available. This greatly urges the need of a countermeasure. 13

14 We have illustrated that through a methodical use of decryption it is possible to design a protocol which does not create any plaintext/ciphertext pair. However, our technique illustrated in the protocol specication (6) will achieve the intended goal only if there is no other protocol which creates plaintext/ciphertext pairs running over the same long-term channel used by our protocol. References [1] E. Biham and A. Shamir. Dierential Cryptanalysis of the Data Encryption Standard. Springer Verlag, [2] R. Bird, I. Gopal, A. Herzberg, P. Janson, S. Kutten, R. Molva, and M. Yung. Systematic design of two-party authentication protocols. In Crypto '91, LNCS, [3] C Boyd. Hidden assumptions in cryptographic protocols. IEE Proceedings, Part E, 137(6):433{436, November [4] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. Technical Report SRC Technical Report 39, Digital Equipment Corporation, February [5] D.E. Denning and G.M. Sacco. Timestamps in key distribution protocols. Communications of the ACM, 24(8):533{536, August [6] W. Die and M.E. Hellman. New directions in cryptography. IEEE Trans. Info. Theory, IT-22(6):644{654, [7] D. Gollmann. Proving authentication protocols - what do authentication protocols prove? In IMA Conference on the Mathematics of Dependable Systems, [8] L. Gong. Lower bounds on messages and rounds for network authentication protocols. In 1st ACM Conferece on Computer and Communications Security, Fairfax, Virginia, [9] L. Gong. Variations on the themes of message freshness and replay. In Computer Security Foundations Workshop VI, Franconia, New Hampshire, pages 131{136, June [10] ISO/IEC. CD : Key management, part 2: Key management mechanisms using symmetric techniques, [11] ISO/IEC , information technology - security techniques - entity authentication mechanisms - part 2: Entity authentication using symmetric techniques,

15 [12] Kohl J. and C. Neuman. The Kerberos network authentication service (v5). Internet Archive RFC 1510, September [13] W. Mao and C. Boyd. On strengthening authentication protocols to foil cryptanalysis. submitted to ESORICS'94. [14] W. Mao and C. Boyd. Development of authentication protocols: Some misconceptions and a new approach. In Computer Security Foundations Workshop VII. IEEE Computer Society Press, [15] S.P. Miller, C. Neuman, J.I. Schiller, and J.H. Saltzer. Kerberos authentication and authorization system. Project Athena Technical Plan Section E.2.1, [16] R. Molva, G. Tsudik, E. van Herreweghen, and S. Zatti. Kryptoknight authentication and key distribution system. In ESORICS '92, LNCS 648, pages 155{174, [17] R.M. Needham and M.D. Schroeder. Using encryption for authentication in large networks of computers. CACM, 21(12):993{999, [18] D. Otway and O. Rees. Ecient and timely mutual authentication. Operating Systems Review, Vol 21(1):8{10, [19] R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21:120{126, [20] C. Stoll. Cuckoo's Egg, Tracking a Spy through the Maze of Computer Espionage. Pan Books, London, Sydney, Auckland, [21] S.G. Stubblebine and V.D. Gligor. On message integrity in cryptographic protocols. In 1992 IEEE Symposium on Security and Privacy, pages 85{104. IEEE Computer Society Press, [22] P. Syverson. A taxonomy of replay attacks. In Computer Security Foundations Workshop VII. IEEE Computer Society Press, [23] M Wiener. Ecient des key search. In Workshop on Selected Areas in Cryptography (SAC'94). Kingston, Ontario, May