Validating the Use of BAN LOGIC José M. Sierra, Julio C. Hernández, Almudena Alcaide, and Joaquín Torres Carlos III University of Madrid Avda. Universidad 30, 28911, Leganés, Madrid, Spain
[email protected]
Abstract. Most attacks against security protocols are due to their vulnerable designs. These type of protocols are usually the base which many other protocols and applications are built upon, so proving the correctness of such protocols has become a very important issue in recent years. At the same time, the complexity of security protocols has increased considerably, making it harder to perform an exhaustive analysis of the different situations they are able to deal with. BAN logic was created to assist in the validation of authentication protocols. Although there are other validation logics, we have chosen BAN because we believe its formal process is very simple and robust and therefore facilitates its application to validate old protocols such as Otway-Rees and more complex new ones such as IKE (standard Internet Key Exchange protocol). This paper is based on BAN logic. We will give a brief description of validating procedures and we will demonstrate the validity of BAN foundations, refuting some weaknesses detected by other authors.
1
Introduction
Nowadays, security protocols are widely used, providing security services in different distributed systems. Deficiencies in the design of these protocols could have negative consequences over the system they are supposed to protect. In fact, most protocol attacks try to exploit those design defects instead of attempting against their cryptography elements, which are generally stronger. However, the design of security protocols is not always considered an important task and very often, malicious modifications of protocol messages are not evaluated to ensure that the protocol is still secure. For many years, different authors have been pointing out these type of errors on security protocol designs. Nowadays, there is quite a heterogeneous set of security protocols differing in the number of participants, the role that each of them plays in the authentication process, the different relationships between them and how these relations develop, etc. For that reason there is the need to create a logical structure to set the bases for the validation of any type of security protocol that could assist in their understanding and avoid potential vulnerabilities. Burrows, Abadi and Needham made one of the most significant efforts in 1990 defining a logic for the analysis of security protocols [2]. BAN Logic is based on the authentication of entities and how their relationships evolve during the run of a protocol. Furthermore this logic can be used to describe the message exchanging
A. Laganà et al. (Eds.): ICCSA 2004, LNCS 3043, pp. 851–858, 2004. © Springer-Verlag Berlin Heidelberg 2004
852
J.M. Sierra et al.
routines without ambiguity, explaining explicitly what assumptions are needed and what information should be considered for the authentication of the participants. Intentionally, BAN Logic does not consider all aspects of security protocols. This logic operates at an abstract level and therefore does not consider implementation errors or inappropriate use of cryptosystems. The simplicity of BAN Logic is one of the reasons for its wide use. However, this simplicity means that BAN is not powerful enough to analyse existing security protocols which have features not considered by BAN. Many researchers have tried to solve this problem by redefining BAN. In this way, Needham (one the authors of BAN), Gong and Yahalom, in 1990 introduced a new logic, GNY Logic [5], and a year later, Abadi and Tuttle created [1]. Other authors like Boyd and Mao have reviewed BAN [3] and have created complementary extensions to it such as [4]. Given that Diffie-Hellman protocols underlay most of the modern authenticated-keydistribution protocols, much effort has gone into trying to validate such protocols. Paul van Oorschot´s VO logic [8], and also [6] and [7] were designed primarily to add this capability while retaining various of the BAN foundations. As shown above, many publications tried to complete and improve BAN logic’s features. The majority of these logics were oriented to give a global solution to the validation of security protocols. However, after all these attempts, it seems obvious that the diversity of security protocols make it very difficult to find one single logic which can be used to validate any given security protocol. Consequently, the use of specific extensions of BAN will be a more adaptable solution for the validation of current or future security protocols.
2
What Are BAN Logic Foundations?
BAN logic is a logic of beliefs. The intended use of BAN is to analyse authentication protocols by deriving the beliefs that honest principals correctly executing a protocol can come to, as a result of the protocol execution. Any authentication protocol is based on the exchanging of messages between participants. To validate a protocol using BAN logic we must establish the participants and their beliefs at the beginning of such protocol. Also we must be able to express those beliefs using BAN specific notation (see [2] for BAN notation). Each of the messages exchanged during the run of a protocol is then idealized (this is called the idealization process), i.e., each message is represented by a logical formula using BAN symbols and notation. These formulae are accompanied by a set of assertions, also represented in BAN notation. The assertions express conclusions reached after sending the message. Roughly, the validating process can be understood in these terms: [initial beliefs and assumptions] S1 [assertion 1] S2 [assertion 2] ...
Validating the Use of BAN LOGIC
853
Sn [conclusions] where Si are statements sent amongst participants. Step by step we can follow the evolution from the original assumptions to the conclusions, i.e., from the original beliefs to the final ones. The goals of authentication vary from one protocol to another. Very often authentication is seeking the distribution of a shared key between participants. In that case authentication is completed between participants A and B, when each of them receives the shared key Kab , which they need to communicate to each other. In a similar way, using BAN logic terminology, the process of validating a protocol is completed when, from initial beliefs and assumptions, using the assertions given in the process and the inference rules defined in BAN, we can reach the conclusions that principal A has received a key Kab and A believes that Kab is a safe key to communicate with B and, vice versa, principal B has received key Kab and B believes that Kab is a safe key to communicate with A. Furthermore, BAN establishes some other general assumptions from which we highlight the following ones: • Each encrypted message contains sufficient redundancy to allow a principal who decrypts it to verify that he has used the right key. • A message cannot be understood by a principal who does not know the key. • The idealized protocols do not include cleartext message parts. This is because its contribution to an authentication protocol is mostly providing hints as to what might be placed in encrypted messages. They do not contribute to the beliefs of the recipient, although this does not mean that cleartext could be removed from the real messages. • The interpretation of the messages is only possible because we know how the information that they contain should be understood.
3
Are BAN Logic Foundations Valid?
Various reviews of BAN logic have tried to demonstrate unsoundness in BAN logic foundations. To illustrate some of these papers, we will work on Boyd and Mao paper [3]. In [3] authors start from protocols proved secure by BAN and establish that they might be vulnerable. The paper begins with the idealization of the Otway-Rees protocol, explicitly described in BAN [2]. Otway and Rees proposed a shared-key authentication protocol which involves two principals and an authentication server. A and B represent the two principals, Kas and Kbs their private keys and S the authentication server. The principals A and B generate the nonces1 Na, Nb and M; the server S generates Kab which becomes the session key between A and B. The message sequence is represented in the diagram below (figure 1). 1
Nonces are expressions generated for the purpose of being fresh. They have never been used before the current run of the protocol.
854
J.M. Sierra et al.
A passes to B some encrypted material useful only to the server, together with enough information for B to make up a similar encrypted message. B forwards both to the server, who decrypts and checks whether the components M, A and B match in the encrypted messages. If so, S generates Kab and embeds it in two encrypted messages, one for each participant, accompanied by the appropriate nonces.
A 1: M, A, B, {Na, M, A, B}Kas
4: {Na, Kab }Kas
3: M, {Na, Kab }Kas, {Nb, Kab }Kbs
B
S 2: M, A, B, {Na, M, A, B}Kas, {Nb, M, A, B}Kbs Fig. 1. Otaway-Rees Protocol
In order to use BAN logic rules to validate this protocol, we transform the protocol into its idealized version. The nonce Nc corresponds to M, A, B in the protocol description above. Idealized version of the Otway-Rees protocol: Message 1: A → B: {Na, Nc }Kas Message 2: B \title{N3: A Geometrical Approach for Network Intrusion Detection S: {Na, Nc }Kas, {Nb, Nc }Kbs Kab
Kab
Message 3:
S → B: {Na, A↔B), (B |~ Nc)}Kas, {Nb, A↔B, (A |~ Nc)}Kbs
Message 4:
B → A: {Na, A↔B), (B |~ Nc)}Kas
Kab
The statements (A |~ Nc) and (B |~ Nc) represent the fact that S has performed the appropriate checks to confirm that Nc matched in each of the encrypted messages. Had this checking not been successful, S would not have issued message 3. Once the protocol has been idealized, the rest of the procedure consists merely of applying the postulates of the logic and the inference rules to the formulae available. The proof may be briefly outlined as follows: Initial beliefs and assumptions: Kas
A │≡ A↔S, Kbs
B │≡ B↔S, Kab
Kas
S │≡ A↔S, Kbs
S │≡ B↔S,
Kab
A │≡ (S => A↔B), Kab
B │≡ (S => A↔B),
A │≡ (S => B |~ X), B │≡ (S => A |~ X),
Validating the Use of BAN LOGIC
855
S │≡ A↔B A │≡ #(Na),
A │≡ #(Nc),
B │≡ #(Nb),
After message 1 has been sent, B sees the message but does not understand it: B ◄ {Na, Nc }Kas B is able to generate a message of the same form and to pass it on to S along with A´s message. On receiving message 2, S decrypts each encrypted message and checks that the nonce Nc matches in both. Using BAN postulates the following formulae can be inferred prior message 3 is sent: S │≡ A |~ Na, S │≡ A |~ Nc , S │≡ B |~ Nb and S │≡ B |~ Nc S emits a message containing two encrypted parts, one for B containing Kab and Nb, the other one, containing the key Kab and Na, is intended for A, so B has to pass it on. At this point, both A and B have received a message from the server containing a new encryption key and the nonce they generated in the request messages. Then the following final beliefs emerge: Kab
A │≡ A↔B, Kab
B │≡ A↔B,
A │≡ B |~ Nc B │≡ A |~ Nc
According to the Boyd and Mao document [3], another entity T could impersonate B and send the following message 2’to S; S would then respond to T creating the following situation: Message 2’: Message 3’: Message 4’:
T → S: M, A, T, {Na, M, A, B }Kas, {Nt, M, A, B }Kts S → T: {Na, Kat}Kas, {Nt, Kat)}Kts T → A: {Na, Kat}Kas
The attack intends to confuse S including an encrypted message using Kts when T is not one of the original participants. If the attack is successful then A would believe that the key it receives is a shared key to communicate with B, when in fact is a key it shares with the attacker T. It is true that in [2] the authors do not explicitly say that the server S must check if the shared keys belong to the initial participants of the communication. However, BAN notation does implicitly indicate that this check is performed and the following belief is inferred from that action: S │≡ B |~ Nc So, in our opinion, this is not a vulnerability of BAN formal process but only a reasonable assumption which BAN´s authors do not explicitly mention.
856
J.M. Sierra et al.
Moreover, in the same paper [3], Boyd and Mao describe a different attack carried out on a simplified version of the Otway-Rees protocol. In [2], the authors conclude that the protocol created by Otway and Rees is valid but with various forms of redundancy so they propose a simplified version to it: “Two nonces are generated by A; however the verification using Na could just as well have been done using Nc. Therefore, Na can be eliminated, so reducing the amount of encryption in the protocol. Moreover, it is clear from the analysis that Nb need not be encrypted in the second message. As these possibilities are explored, we rapidly move towards an improved protocol of different structure” [2]. In our opinion, after the changes introduced to simplify the protocol, the logical analysis of it, is obviously different from the logical analysis to validate the original one. We will now demonstrate how by adding the necessary assumptions to the set of initial beliefs, BAN logic is able to validate the simplified protocol and the attack described by Boyd and Mao is actually detected by the participants. According to BAN authors, the new protocol is the same as the Otway-Rees protocol but the messages 1 and 2 are now as follows: Message 1: Message 2:
A → B: M, A, B, { Nc }Kas B → S: M, A, B, { Nc }Kas, Nb, { Nc }Kbs
The idealized form of the simplified protocol is: Message 1: A → B: { Nc }Kas Message 2: B → S: { Nc }Kas, { Nc }Kbs Kab
Kab
Message 3:
S → B: {Nc, A↔B), (B |~ Nc)}Kas, {Nb, A↔B, (A |~ Nc)}Kbs
Message 4:
B → A: {Nc, A↔B), (B |~ Nc)}Kas
Kab
To validate this new protocol using BAN, we must add the appropriate assertions after each message is sent. After message 1 is sent, the following BAN logic formula can be added to the validating process: B ◄{Nc }Kas After message 2 is sent, S has to perform the required checks. If S succeeds, then we can derive the following beliefs, applying BAN inference rules: S │≡ A |~ Nc and S │≡ B |~ Nc However, we cannot conclude that S │≡ B |~ Nb. Therefore, new assumptions are needed to complete the authentication process of the participant B. Different solutions can be applied to solve the problem. We briefly describe two of them. • S checks that Nc does not correspond to any previous run of the protocol. If this is the case, the formula S │ ≡ # Nc could be added, after message 2, to the validating process. • S checks that Kab has not been requested for any of the participants before this run of the protocol. In this case the formula added to the process should be S │ ≡# Kab , this is, S has never said Kab before the current run of this protocol.
Validating the Use of BAN LOGIC
857
According to Boyd and Mao [3], in the new attack, the attacker T masquerades as A in the protocol and is also assumed to be in control of communications between B and the server S. The essence of the attack is that T can change the names presented to S while using the nonce that B associates with Kab. It is also assumed that T has possession of a message fragment {M,T,B,}Kbs, which was formed by B during a previous legitimate run of the protocol between T and B. The attack proceeds as follows, with B and S acting exactly as in a normal run. Messages 2 and 3, which B and S intend for each other respectively, are captures by T: Message 1: Message 2: Message 2’: Message 3: Message 3’: Message 4:
T → B: B → T: T → S: S → T: T → B: B → T:
M’, A, B, { M, T, B }Kts M’, A, B, { M, T, B }Kts, Nb, { M’, A, B }Kbs M, T, B, { M, T, B }Kts, Nb, { M, T, B }Kbs {M, Ktb }Kts, { Nb, Ktb}Kbs {M, Ktb }Kts, { Nb, Ktb}Kbs {M, Ktb }Kts
At the end of this attack, B believes he shares the key Ktb with A whereas in fact, it shares it with attacker T. We can see that any of the solutions given to perform BAN logic validation of this new protocol, could detect such attack. Both solutions ensure that messages from previous runs cannot be used in future ones. With the first solution, S can detect the attack when realising that Nc = M, T, B is not fresh, i.e., it has already been used in some previous instance of the protocol. Also, the assumption added in the second solution ensures that if the encrypted message { M, T, B }Kbs had already been created by B, during a previous legitimate run of the protocol between T and B, then the key Ktb would have been issued once already, so such key is not fresh and S can then detect the attack.
4
Conclusions
We believe BAN logic foundations are valid. BAN logic represents a simple but sound and powerful tool to describe and validate authentication protocols. However we are also aware of the limitations of BAN’s initial versions. In these early versions the idealization process is strongly based upon the previous understanding of the content of each message exchanged and there are difficulties trying to idealize DiffieHellman and other more modern and complex protocols. A well known example is that BAN logic is unable to evaluate protocols where the value of the postulates changes during the run of the protocol (i.e. many e-commerce protocols). It is vital to validate security protocols to protect communication over open environments such as the Internet. Lack of attention to mutual authentication, freshness of the message exchange, privacy of classified information or impersonation of entities are the main problems associated with these protocols. Although there are other methods to detect vulnerabilities in these types of protocol, formal validation has become one of the most convenient solutions. In this paper we have proved the validity of BAN foundations refuting some weaknesses detected by other authors.
858
J.M. Sierra et al.
Our specific project is to now build dedicated logical structures based on BAN, to be used as ‘scaffolding’ to validate new security protocols on different new platforms.
References [1] [2] [3] [4] [5] [6] [7] [8]
Martín Abadi and Mark R. Tuttle. A semantic for a logic of authentication. Proceedings of the Tenth Annual ACM Symposium on Principles of Distributed Computing, pages 201-216. ACM Press, August 1991. Michael Burrows, Martín Abadi and Roger Needham. A logic of authentication. ACM Transactions on Computer Systems, 8(1):18-36, Feb 1990. Colin Boyd and Wenbo Mao. On a limitation of BAN logic. Eurocrypt’93. Protocols I:240-247, May 1993. Colin Boyd. A Framework for Design of Key Establishment Protocols. Information Security and Privacy, LNCS 1172, pp.146-157, Springer-Verlag, 1996. Li Gong, Roger Needham and Raphael Yahalom. Reasoning about Belief in Cryptographic Protocols. Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, pages 234-248. IEEE Computer Society Press, 1990. Paul F. Syverson and Paul C. van Oorschot. On unifying some cryptographic protocols. Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, pages 14-28. IEEE CS Press, May 1994. Paul F. Syverson and Paul C. van Oorschot. A Unified Cryptographic Protocol Logic. NRL Publication 5540-227, Naval Research Lab, 1996. Paul C. van Oorschot. Extending Cryptographic logics of belief to key agreement st protocols. In Proceedings of the 1 ACM Conference on Computer and Communications Security, pages 233-243. ACM Press, November 1993.
