Combined CPV-TLV Security Protocol Verifier

Combined CPV-TLV Security Protocol Verifier by Ariel Cohen Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Computer Science Courant Institute of Mathematical Sciences New York University January 2004

Acknowledgments I would like to express my deep appreciation to my thesis advisors Professor Amir Pnueli and Professor Lenore Zuck for suggesting the subject of this thesis and for their guidance and encouragement in performing it. II

Abstract Several security protocol verifiers were created in order to verify the secrecy and authenticity of security protocols. A recent one created by Bruno Blanchet - Cryptographic Protocol Verifier (CPV), uses Horn clauses. CPV has some important advantages such as being able to determine that a protocol is secure, the ability to handle an unbounded number of sessions of the protocol, and it being reasonably fast. Some of its weaker points are that in some cases a false attack could be identified as truly existing, and that the description of a detected attack is provided as a proof consisting of combinations of Horn clauses and rules which are quite cumbersome. Temporal Logic Verifier (TLV), which provides a flexible environment for the verification of finite state systems, is used as well to verify various properties of security protocols. One of the advantages of TLV with regard to security protocols is that if one knows the nature of a possible attack, TLV can be used to determine easily if this attack indeed exists, and if it does it presents the attack in a detailed finite state description. The system presented here, Combined CPV-TLV, is developed as a security protocol verifier that joins CPV with TLV, thus gaining the advantages of these two while reducing some of their weaknesses. In the combined system CPV is used to III

determine that a protocol is secure, and TLV is used to validate or reject attacks which may have been detected by CPV. Therefore, Combined CPV-TLV provides additional and accurate information on the secrecy and authenticity of the protocol under test, over and beyond what CPV and TLV can offer when used separately. As an input, the system accepts a simple description of a protocol and checks it, following Dolev Yao model. IV

Contents Acknowledgments... II Abstract...III 1 Introduction...1 2 Background...4 2.1 Security protocols...4 2.2 Security Properties...8 2.3 Verification of security protocols...9 2.4 TLV...10 2.5 CPV...12 3 Combined CPV-TLV...16 4 The Input Language...22 4.1 General Assumptions...22 4.2 Overview - sections of the input file...23 4.2.1 Private variables...23 4.2.2 Global variables...23 V

4.2.3 Functions...24 4.2.4 Protocol Description...24 4.2.5 Secrets...27 4.3 Some general rules...27 4.4 Interpretation of the input...28 4.5 Special features and limitations...30 5 Output of Combined CPV-TLV...33 5.1 Attack detected...33 5.1.1 Attack on Secrecy and Syntax description...34 5.1.2 Attack on Authenticity and Syntax description...35 5.2 No Attacks detected the protocol is secure...36 5.3 No Attacks detected - protocol may be secure...36 6 Comparison to other Verification Systems...38 7 Results, Conclusions, Future improvements...42 7.1 Results and Conclusions...42 7.2 Future improvements of Combined CPV-TLV...44 Appendix A - CPV Activation...46 A.1 Converting the Input into a syntax suitable for CPV...46 A.1.1 Private variables...46 A.1.2 Global variables...47 A.1.3 Global functions...47 VI

A.1.4 Functions...48 A.1.5 Secrets...49 A.1.6 Protocol description...49 A.2 Function and message identifiers...51 A.3 Use of CPV feature - begin...52 Appendix B - The Intermediate Output...53 B.1 Handling CPV s output... 53 Appendix C - TLV Activation...55 C.1 Converting the original and the intermediate outputs into TLV... 55 Appendix D - Input Language Syntax...58 D.1 Private variables...58 D.2 Global variables...58 D.3 Functions...59 D.4 Protocol Description...60 D.5 Secrets...62 D.6 Global definitions...62 D.7 Reserved words and their purposes...63 D.8 General Comments...64 Appendix E - Test Examples...65 E.1 Needham-Schroeder public key protocol...65 VII

E.1.1 Original protocol description...65 E.1.2 Input to the system...66 E.1.3 Analysis of the input...67 E.1.4 Output of the system...68 E.1.5 Analysis of the output...70 E.1.5.1 Secrecy Attack...70 E.1.5.2 Authenticity Attack...71 E.2 OtwayRees protocol...73 E.2.1 Original protocol description...73 E.2.2 Input to the system...74 E.2.3 Analysis of the input...75 E.2.4 Output of the system...79 E.2.5 Analysis of the attack...80 E.2.5.1 Attack on Authenticity...80 E.3 Yahalom protocol...85 E.3.1 Original protocol description...85 E.3.2 Input to the system...85 E.3.3 Analysis of the input...87 E.3.4 Output of the system...89 E.4 An Investigative protocol...90 E.4.1 Original protocol description...91 E.4.2 Input to the system...91 VIII

E.4.3 Analysis of the input...92 E.4.4 Output of CPV...93 E.4.5 Formal description of the attack...96 E.4.6 Output of the system...97 E.5 ISO Candidate protocol...98 E.5.1 Original protocol description...98 E.5.2 Simple declaration input...98 E.5.2.1 Input to the system...99 E.5.2.2 Output of the System...100 E.5.3 Multi agent declaration input...100 E.5.3.1 Input to the system...100 E.5.3.2 Output of the System...102 Bibliography...103 IX

1. Introduction Several security protocol verifiers were created in order to verify the secrecy and authenticity of security protocols. In general, the major goal of security protocol verifiers has been to develop a system which, when given a protocol to verify - runs automatically and determines that the protocol is secure or provides possible attacks. The system presented here - Combined CPV-TLV, is developed as a security protocol verifier that combines the power of Logic Programming [22] and Model Checking [6] by joining Cryptographic Protocol Verifier (CPV) [1,2,3,5] and Temporal Logic Verifier (TLV) [23], thus gaining the advantages of these two while reducing some of their weaknesses. The system checks protocols following Dolev Yao model [9]. Combined CPV-TLV accepts as an input a simply described protocol. It then translates it into a form appropriate for CPV (i.e. extension of Π calculus syntax [1]) and runs it through CPV. If CPV determines that the protocol is secure, than Combined CPV-TLV states so as well. 1

However, if CPV detects an attack and provides its description, that description combined together with the original input file, are translated automatically into both TLV s proper input language (SMV [15]) which provides a description of the system to verify, and into a file written in TLV-Basic [23] which contains the assertions to check. TLV is then activated using the SMV input, and the TLV-Basic file. At that point, if an attack is indeed identified by TLV, Combined CPV-TLV states that the protocol is not secure and displays the attack to the user. On the other hand, if the attack is not identified as such by TLV, Combined CPV-TLV states that a decision concerning the security of the protocol could not be made. It should be pointed out that CPV displays only one representative of a group of attacks that it finds. Thus, CPV displayed attack can be false but other attacks can be valid, and a decision at this stage is not possible. Combined CPV-TLV was tested using representative protocols that provide for different scenarios. The important case of a protocol that results in the detection of a false attack by CPV which is subsequently rejected by TLV is provided in Appendix E.4. General Overview: Section 2 provides a background on security protocols and their properties, on the verification of security protocols, and provides a description of TLV and CPV. Section 3 describes Combined CPV-TLV s course of action. Section 4 provides an explanation of the system input. Section 5 presents a description of 2

Combined CPV-TLV s output. In section 6, there is an overview of some other existing verification systems and a comparison with some of them. Section 7 shows the results obtained when running different protocols through the system, it provides conclusions and proposes some possible future improvements for the system. 3

2. Background 2.1 Security protocols Security protocols are in essence sets of formal rules specifying how to conduct the exchange of messages between a few parties in order to provide security services across hostile and insecure communication networks of distributed systems. Usually they are very simple and easy to express but they are error-prone and their security is difficult to evaluate. These protocols often make use of cryptographic mechanisms such as symmetric and asymmetric encryptions, and are therefore protected against passive intruders, who only listen to the exchange of messages, copy those messages and try to decipher them. However, entirely different situations arise when the hostile intruders are active and able to impersonate authorized parties, to initiate communications with other users, to intercept, alter and replay messages, etc. In such instances, by performing manipulations that relate to the high level structure of the protocol even though without 4

being dependent on, or compromising the specific cryptosystem in use, the intruder could break the security of the protocol. There are several examples of protocols which were considered to be secure and in which flaws were found after many years of use. A well known example is the Needham-Schroeder public key protocol [18] that was published in 1978 for the establishment of authenticated interactive communication between two parties on different machines: Message 1: A -> B : {A,Na}PK B Message 2: B -> A : {Na,Nb}PK A Message 1: A -> B : {Nb}PK B In the first message A sends B her name together with a nonce Na all encrypted with B s public-key PK b. B receives that message and decrypts it using his private-key. Then he sends A a new message that contains the nonce Na that he just received together with a new nonce Nb, all encrypted with A s public-key PK A. A receives that message and decrypts it using her private-key. Then she sends B a new message that contains the nonce Nb that she had just received encrypted with B s public-key PK B. 5

At the end of this run A and B may assume that they had communicated with each other, that they both agree on the values of Na and Nb and that they are the only ones who know those values. The following flaw [12] was found by G. Lowe 17 years after the protocol was first published (P is the intruder; in parenthesis is the number of relevant message in the protocol.): Message 1(1): A -> P : {A,Na}PK P Message 2(1): P -> B : {A,Na}PK B Message 3(2): B -> P : {Na,Nb}PK A Message 4(2): P -> A : {Na,Nb}PK A Message 5(3): A -> P : {Nb}PK P Message 6(3): P -> B : {Nb}PK B In the first message A sends P her name together with a nonce Na encrypted with P s public-key PK P. P decrypts the message, encrypts it with B s public-key PK B and forwards it to B. B receives that message and decrypts it using his private-key. He then sends P a new message that contains the nonce Na that he just received together with a new nonce Nb, all encrypted with A s public-key PK A. P receives that message and 6

forwards it to A. A receives the message and decrypts it using her private-key. Then she sends P a new message that contains the nonce Nb that she just received encrypted with P s public-key PK P. P decrypts the message, encrypts it with B s public-key PK B and forwards it to B. At the end of this attack two of the protocol s goals are not met. A thinks she communicates with P, but in fact she communicates with B. B think he speaks with A but rather he speaks with P. P obtains the values of Na and Nb. In this attack P misleads both A and B. The example above shows that a protocol can be compromised by performing some complex manipulation, and without breaking the cryptosystem. 7

2.2 Security Properties Security protocols are meant to achieve specific security properties depending on the system they are running on and the surrounding environment along with its threats. The following describes two of the more important properties of security protocols - secrecy and authentication: Secrecy There are several possible levels for secrecy and therefore quite a few options for defining it. The strongest characterization would be for the intruder not to be able to deduce anything about the session activity. However, this is usually too strict and often an adequate requirement would be to prevent the intruder from obtaining certain data that appears in some of the messages. In other words, the objective would be to assure that a certain data remain secret at the end of a protocol run. Authentication [20] The authentication of a party concerns the verification of the party s claimed identity. In general, authentication of A to B means that B can be sure that he had communicated with A. There are three specific types of authentication: In the simplest one agent B only requires that agent A is alive and has not failed. In the second type B requires that A participated in a run where A took B to be the other participant. The third type goes further beyond the second type and requires that A and B agree on additional information specific to a particular run. 8

2.3 Verification of security protocols Verification of a security protocol means proving that its goals are met and that there are no flaws in the protocol relative to those goals and to the security properties it intends to keep. In other words, an attack is legitimate only if it violates some property that the protocol intends to achieve. Therefore, before trying to prove the security of a protocol it is important to determine precisely its goals. As shown before, a protocol can be compromised by performing some high level manipulation and therefore it is necessary to have a formal model where security issues can be verified in a logically precise manner. D. Dolev and A. Yao suggested their so-called Dolev-Yao model in 1981 [9]. This model separates the cryptographic issues from the structural issues, which allows for the finding of flaws that are not dependent on the cryptography. It suggests several assumptions on the behavior of the system to be checked: The public key system is perfect: the Encryption/Decryption functions that are used are unbreakable, the public directory is fully secured, everyone knows all the encryption functions and only the user knows his own decryption function. The same protocol format is used by every entity wishing to communicate. 9

The intruder is active and can do almost anything to break the security of the protocol. He is a legitimate user of the network and thus can be an initiator or a responder. He can obtain messages passing through the network and can intercept, create and fake messages. The verification of security protocols was proved to be an undecidable problem [23] and therefore it has to be restricted or approximated. Methods that restrict the problem are more suitable for finding attacks on protocols, while methods that approximate it tend to be used for proving that a protocol is secure. 2.4 TLV Temporal Logic Verifier (TLV) [23] is a flexible environment for verification of finite state systems. It accepts programs written in SMV [15] or SPL [23], translates them to Ordered Binary Decision Diagrams (OBDD) [23] and then enters an interactive mode where the transitions of the systems can be accessed and manipulated using TLV-Basic [23]. All of TLV s proofs are done interactively. SMV is an expressive language used when checking finite states systems against specifications in temporal logic CTL [15]. SMV allows a description of finite state 10

systems, provides operations on high level types and supplies tools to describe nondeterministic choices. SMV programs consist of several modules which may receive several parameters and may also have their own local variables including instances of other modules in order to create structural hierarchy. Modules can be reused as many times as necessary inside a model. After TLV loads the system described in SMV, it translates it into OBDDs which are a canonical form representation for boolean functions. It then enters an interactive mode and is ready to run procedures written in TLV-Basic. The TLV-Basic language is used to program rules, model-checking algorithms, and compute assertions. The main (and only) data structure is a function with boolean arguments and integer range. As such, it can represent integers, booleans (a function with range {0, 1}), assertions, transitions, state valuations and sets of variables which are represented as boolean functions. The underlying implementation is an OBDD, which is manipulated using the SMV OBDD library. Expressions in the language are constructed out of integer constants and variables to which we apply integer operations, integer comparisons, and all the boolean and quantifying operators available in the SMV language. [23]. TLV checks the assertions in the TLV-Basic rules and if they are all true it states so. Otherwise, a counter example, for which one of the assertions fails, is provided. 11

In what directly concerns security protocols, TLV is not able to provide a sound and complete answer on the secrecy and authenticity of a protocol. Since it performs verification of finite state systems, TLV must restrict the problem by defining several limits - for example the number of protocol s runs. Those bounding limits may prevent TLV from detecting attacks which perhaps exist. Therefore, even if it does not find an attack, TLV could not state that a protocol is secure because there might be attacks that it did not detect. The important advantage of TLV with regard to security protocols is that if one knows the nature of a possible attack, TLV can be used to determine easily if this attack indeed exists. An attack can be described as a finite set of messages and therefore can be described in terms of finite states. This important feature is specifically used by the system presented here, in order to validate or reject attacks. 2.5 CPV Recently a new security protocol verifier was created by Bruno Blanchet - Cryptographic Protocol Verifier (CPV) [1,2,3,5], using Horn clauses. This verifier abstracts the verification problem and allows modeling of an unbounded number of protocol s runs. This leads to an important advantage of being able to determine that a 12

protocol is secure (sound). In contrast, it is not complete in the sense that spurious attacks may be detected. In CPV s input, the protocol is represented using an extension of Π calculus syntax [1] with cryptographic primitives that are defined by reduction relations. Two different kinds of primitives are used: constructors and destructors. Constructors are used for creating new terms, such as encryption: encrypt ( message, key). Destructors are used to manipulate terms and are defined by reduction relations, for example: decrypt( encrypt( message, key), key) message. The input is automatically translated into a set of Horn clauses. The more important part when using Horn clauses is the representation of the intruder. The intruder is able to obtain all messages and then apply constructors and destructors in order to manipulate, create and send new messages. Intruder(data) means that Intruder knows data. Further more, when applying the constructors and the destructors it is possible to obtain, for example: Intruder( message) Intruder( key) Intruder( encrypt( message, key)) Intruder( encrypt( message, key)) Intruder( key) Intruder( message) The messages exchanged by the participants are also represented by similar clauses and considered as knowledge that the intruder can obtain and make use of. 13

When using this representation, secrecy can be inferred from non-derivability. Hence, if Intruder(data) is not derivable then data is secret. The value of a fresh variable (such as a nonce) is considered as a function on all previous messages that were received by the participant who creates the variable. Therefore, different values are created for different previous messages, and hence fresh variables will have different values at each session. The above representation uses two approximations: Horn clauses can be repeated any number of times while the real protocol repeats each step only once per session, and freshness is modeled by functions on previous received messages. These approximations are proved [2] to be at the safe direction and therefore abstract the undecidability problem allowing verification without bounding the number of sessions. This abstraction leads to soundness in the sense that when it determines that a security property is true, then it is indeed so. However, it is not complete in the sense that false attacks, that do not correspond to a protocol run, could be found. There are three possible causes for CPV to detect false attacks. The first type of attack is due to the use of Horn clause model - Horn clauses can be repeated any number of times and they do not model the state of the protocol participants. Therefore, a protocol that first keeps some part of the data secret, and then reveals it at the end of the session may lead to the discovery of a false attack. The protocol can be secure, 14

but the verifier detects an "attack" against it because the verifier assumes that the secret can be reused at the beginning of the session in order to break the protocol. A false attack may be detected as well when the protocol makes use of private communications channels. The third type of event that may lead to the identification of a false attack occurs when checking authenticity for injective agreements. When performing the check with regard to variables which are not being revalued after the first session, the values may change after a few session are executed, and the system then states that an agreement does not hold. The occurrence of this type of false attack can be prevented if use of this type of variables for the authenticity check is avoided. A problem that arises from the use of Horn clauses is that the solving algorithm makes infinite loops due to the rules that represent the intruder. Therefore, a special algorithm was designed to reduce that problem details about it can be found at [2]. In addition, B. Blanchet and A. Podelski have also shown in [5] that this algorithm always terminates on tagged protocols. They suggest that tagging messages that involve encryption make the protocol more secure. However, it is important to note that the security of a tagged protocol does not impose the security of its untagged version. 15

3. Combined CPV-TLV The system presented here - Combined CPV-TLV, is developed as a security protocol verifier that joins CPV with TLV, thus gaining the advantages of these two while reducing some of their weaknesses. The system checks protocols following Dolev Yao model. Combined CPV-TLV accepts as an input a file containing an abstract description of the protocol. This description is provided in a language that was specially designed for the combined system in such a way that most of the protocols descriptions will be relatively short and self-explanatory (most protocols descriptions can be written on less than one page). A more detailed overview of the input language can be found in section 4. After parsing the input, Combined CPV-TLV automatically translates it into a form appropriate for CPV (i.e. extension of Π calculus syntax [1]). For each agent that appears in the protocol, there is a unique process that is created in Π calculus syntax that describes the agent s course of action. For each message in the protocol there is a related code which is created both in sender s and receiver s sections. The declarations 16

of variables and functions in essence remain the same and only the syntax is changed. A more detailed explanation concerning the translation of the input file can be found in Appendix A. CPV is activated using the new input, and it then checks the security of the protocol, and provides an output which is relatively cumbersome. The output contains a display of the protocol in Horn clauses together with a list of rules used by the system to prove the secrecy assumptions or to form the attacks and a display of the exchanged messages content. If CPV determines that the protocol is secure, then Combined CPV- TLV states so as well. In case that an attack is detected, Combined CPV-TLV uses this output to outline a simple attack description. A more detailed explanation concerning the activation of CPV and the handling of its output can be found in Appendix B. In case that an attack is detected by CPV, Combined CPV-TLV automatically creates an SMV [23] file containing a description of a unique system that follows the specific protocol and attack. All appropriate limits for that system are obtained from the attack itself, such that if the attack indeed exists the system would validate it. The SMV file contains modules regarding the intruder and modules regarding the agents participating in the protocol. The strategy for creating the agents modules is obtained from the original input regardless of the attack that was found. Only the number of instances for each module is obtained from the attack itself. The intruder s 17

module and the modules that provide it with the ability to fake and spy on messages are determined completely from the attack. A more detailed explanation concerning the TLV activation and creation of the SMV file can be found in Appendix C. In addition to the SMV file, Combined CPV-TLV creates a TLV-Basic [23] file with assertions regarding the attack to verify. Combined CPV-TLV then activates TLV using the SMV input file, uploads the TLV-Basic file and checks the assertions. At that point, if an attack is indeed identified by TLV Combined CPV-TLV states that the protocol is not secure and displays the attack to the user. On the other hand, if the attack is not identified as such by TLV, Combined CPV-TLV states that a decision concerning the security of the protocol could not be made. Figure 3.1 provides a detailed outline of the system s procedure. It should be pointed out that CPV displays only one representative of a group of attacks that it finds. Thus, CPV displayed attack can be false but other attacks (not displayed by CPV) can be valid, and a decision at this stage is not possible. Figure 3.2 shows a sketch of the various attack alternatives. As described previously in paragraph 2.5, there are three causes for CPV to detect false attacks. The only one which is relevant here is due to the use of the Horn clause model, 18

Input Combined CPV-TLV Translator to CPV CPV Attack Translator to TLV TLV Protocol is secure Attack Protocol may be secure Figure 3.1: An outline of the system s procedure 19

F - Family of attacks x T - Attacks TLV checks for R - Real attacks Let x be the attack that CPV outputs. If F is the family of attacks that contains x, and R are real attacks such R F, Then x R x F \ R. TLV is activated to find a real attack t from a potential family of attacks T, such that x T. If TLV finds a real attack t T then the protocol is not secure. However, if it does not find such an attack, there could still be an attack x' such that x' R x' T and hence the protocol is not secure. Figure 3.2: A sketch of attack alternatives since Horn clauses can be repeated any number of times and they do not model the state of the protocol participants. Therefore, protocols that first keep some part of the 20

data secret, and then reveal it at the end of the protocol session may lead to the discovery of a false attack. The protocol can be secure, but the verifier detects an "attack" against it because the verifier assumes that the secret can be reused at the beginning of the session in order to break the protocol. The false attacks that may be detected by CPV when the protocol makes use of private communications channels or when the system checks authenticity for injective agreements are not relevant here because currently Combined CPV-TLV does not make use of these CPV features. Combined CPV-TLV was tested using representative protocols that provide for different scenarios. The results can be found in Section 7. The important case of a protocol that results in the detection of a false attack by CPV which is subsequently rejected by TLV, is fully described in Appendix E.4. 21

4. The Input Language 4.1 General Assumptions When defining the syntax of Combined CPV-TLV s input some general design decisions had to be made. The most important was to keep the input as simple as possible, to make it short, and to design it in such a way that it will be self explanatory. Another important requirement was to design the system such that all of CPV s features and advantages remain available and operational. All examples provided further on are derived from Needham-Schroeder public key protocol, which is also fully described in Appendix E.1. 22

4.2 Overview - sections of the input file 4.2.1 Private variables #Private Variables privatekeya, privatekeyb; Private variables are variables which are known to all of the protocol s participants but should not be known to the Intruder at any step of the protocol. For example: predefined private keys. 4.2.2 Global variables #Global Variables A,B,publicKey(privateKeyA), publickey(privatekeyb); Global variables are variables or functions which are known to all of the protocol s participants including the Intruder. For example: predefined public keys. Global functions can be formed only from global or private variables (identifiers). 23

4.2.3 Functions #Functions fun encrypt/2; reduc decrypt(encrypt(x,y), y) = x; Functions are known both to the protocol s participants and to the Intruder. To define a function the user needs only to state the function s name and the number of parameters that it requires. It is optional to define an inverse-function which will be used by the receiver to resolve the function that he receives. The first parameter of the inversefunction must be the original function itself. The other parameters of the inversefunction, including the parameters of the result, can be of any type (including functions and vectors of variables) and they are used only to define the inverse-function procedure. 4.2.4 Protocol Description #Protocol Description Message 1: -> A : publickey(keyb) Message 2: A -> B : encrypt((na[], A), publickey(keyb)) 24

Message 3: B -> A : encrypt((na, Nb[]), publickey(keya)) Message 4: A -> B : encrypt(nb, publickey(keyb)) Authenticity_run 1: A(Na, Nb) Authenticity_commit 1: B(Na, Nb) This section provides a description of the protocol among several agents. The protocol is expressed as a sequence of message exchange between the agents. Each message is uniquely numbered, and appears in the order it is sent. There are three types of messages: messages from an agent to an agent, messages from the environment to an agent and messages from an agent to the environment. When [] is attached to the right of a variable it means that the variable is newly generated by the agent who sends the message. Therefore, in different sessions different values are generated. One of the important uses of this feature is when sending a fresh nonce. In addition to the above, it is possible to declare in this section an Authenticity check. The user must declare both Authenticity_run and Authenticity_commit for each check that he wants the system to perform. The system will check that if the event Authenticity_commit has been executed, than the event Authenticity_run was executed before that. Authenticity_run and Authenticity_commit for the same authenticity check must have the same 25

serial number and the same number of environmental parameters placed in the same order. In accordance with the relevant authenticity language rule, the first identifier after the colon is the agent on which to perform the check. For example: Message 3: B -> A : encrypt((na, Nb[]), publickey(keya)) Authenticity_run 1: A(Na, Nb) Message 4: A -> B : encrypt(nb, publickey(keyb)) Authenticity_commit 1: B(Na, Nb) The above means that when B receives message number 4, the system will check whether A had previously received message number 2. In addition, the system will check if A and B agree on the values of Na and Nb. When the user creates an input for the system, he must define the authenticity properties that are to be checked. Wrong placing of authenticity checking can lead to the identification of attacks which have no significant meaning for the security of the protocol. 26

4.2.5 Secrets #Secrets --secrets to check keyab, secret; In this section, the user declares the secrets that the protocol is not to reveal to Intruder. A secret can be a variable or a function operation. A secret is an element that the Intruder does not initially know, and therefore it must be a variable that is newly created by one of the agents, or a function on private/newly-created variables. The secret can not be a private variable. It is important to note that if a secret element has more than one value, the protocol should not reveal any of the values. For example: if the secret is a newly created variable that is freshly generated with a different value at every session, then the Intruder shell not obtain any of its values. 4.3 Some general rules A variable can not be both Global and Private. A newly created variable, which is declared at the protocol description section, should not be also declared as a Global or as a Private variable. 27

A function name can not be the same as a variable name. When a function is used in the protocol description section (or anywhere else), it must have the same type of inner parameters as in the declaration of that function and of its inverse function. Comments begin with -- and proceed until the end of the line. They can start at the beginning of a line or after a command. An authenticity check can be formed only over variables that both agents know their values at the stage of the authenticity check declarations. 4.4 Interpretation of the input When interpreting the input, the following assumptions are made regarding the transmitting and receiving of variables inside of messages: If an agent receives a message that contains a variable that he should had either previously created in the same session, or that was previously received by it in the same session, then the message will be accepted only if the value of the variable inside the message matches the value of the old variable. For example: 28

Message 2: A -> B : encrypt((na[], A), publickey(keyb)) Message 3: B -> A : encrypt((na, Nb[]), publickey(keya)) In this example A creates a value for the nonce Na and sends it to B. Afterwards A expects to receive a message that contains Na, but that message will be accepted only if the values of the two Na nonces are identical. When an agent receives a variable which he should not be familiar with its value (i.e. he did not create or receive it before), then he stores its value in a local location and uses it when ever needed in the future. For example: #Global Variables B, A, S; Message 2: A -> B : encrypt((na[], A), publickey(keyb)) Message 3: B -> A : encrypt((na, Nb[]), publickey(keya)) In this example B receives Na in message number 2, and afterwards sends it in message number 3. When receiving message 2, B locally stores the value of Na and uses that value later on when sending it in message number 3. 29

The user of the system must define the secrets and the authenticity properties that are to be checked. Wrong placement of the authenticity check can lead to the identification of attacks which have no significant meaning for the security of the protocol (For more details see section 4.2.4). 4.5 Special features and limitations Combined CPV-TLV has some important features that are expressed in the input and which usually are not available in systems used for the verification of security protocols. Some of those features are: The ability of agents to forward encrypted messages without being able to decrypt them. There is no need to define the number of sessions to run this is rather derived from CPV. The possibility to have fresh variables, which allows the system to declare a new value for a nonce each time that a certain stage of the protocol is reached. Use of functions which improve flexibility: 30

o Allows the encryption and decryption to be declared as functions. An immediate benefit is the ability to declare a different type of encryption/decryption for Symmetric-Key Cryptography and Asymmetric Cryptography. A future benefit will be that the encryption could be based on more than one key. For example: encrypt(message, key1, key2). o Messages can be declared as functions which allows to establish special instruction on of how to retrieve the message using the inverse function declaration. The protocol itself is declared using a very simple syntax similar to a pseudo code syntax, such that messages are declared and not the participants course of action for sending them. Some of the limitations of the input language are: All agents, including the intruder, can use any of the functions, and there is no way to declare that a specific function can only be used by a specific agent. Regular agents know all the variables which are declared as private or as global. The only distinction is between the intruder and the other agents, where the intruder does not know the private variables. 31

Note: The two limitations above are mostly apparent when using public key cryptography where all the agents know the private keys of the other agents which is a provision not common as such in reality. However, a proper statement of the protocol can neutralize the consequences of this feature. It should be pointed out that CPV does not have a special declaration allowing for an agent to be declared in such a way that he assumes the role of multiple participants. Therefore, CPV, and consequently this system, can not detect straightforward attacks that occur when an agent can execute the actions of more than one participant. However, if a special multi declaration of the protocol is formed than attacks of this type are detected. For example, the Canadian attack [11] which is shown in the ISO Candidate protocol [11] and described in Appendix E.5. 32

5. Output of Combined CPV-TLV The Combined CPV-TLV has three types of output: Attack detected. No Attacks detected the protocol is secure. No Attacks detected protocol may be secure. 5.1 Attack detected This is the case where CPV detects an attack and TLV confirms its validity. The following expressions appear: (Attack syntax description) 33

5.1.1 Attack on Secrecy and Syntax description Attack on secret Nb Message 1 : Environment -> Intruder : (publickey(keyb_1)) Message 1 : Intruder -> A : (publickey(v201)) Message 2 : A -> Intruder : (encrypt((na_4,a_1),publickey(v201))) Message 2 : Intruder -> B : (encrypt((na_4,v203),publickey(keyb_1))) Message 3 : B -> A : (encrypt((na_4,nb_5),publickey(keya_1))) Message 4 : A -> Intruder : (encrypt(nb_5,publickey(v201))) Syntax description: The first line provides the variable whose secrecy is violated. The other lines describe the messages exchange leading to the violation, in the order they are sent and received. A message number in the attack corresponds to a message number in the protocol description of the original input. 34

The number that follows the name of a variable is used to distinguish between variables that have the same name but different values. For example, if during the run there are two sessions and an agent creates two values for a certain nonce, although the values are for the same nonce, they are created freshly and therefore will not have the same value. Therefore, if both Na_1 and Na_2 appear through an attack description, it means that those are two different values for Na. Variables which have their names composed from the letter v followed by a number were created by Intruder and do not appear in the original protocol. It is important to note that messages that do not include the Intruder as sender/ receiver are also obtained by Intruder, but there is no guarantee that he could have acquired their content, or that he could have even used them. 5.1.2 Attack on Authenticity and Syntax description Attack on Authenticity number 1 Message 1 : Environment -> Intruder : (publickey(keyb_1)) Message 1 : Intruder -> A : (publickey(v206)) Message 2 : A -> Intruder : (encrypt((na_3,a_1),publickey(v206))) 35

Message 2 : Intruder -> B : (encrypt((na_3,v205),publickey(keyb_1))) Message 3 : B -> A : (encrypt((na_3,nb_4),publickey(keya_1))) Message 4 : A -> Intruder : (encrypt(nb_4,publickey(v206))) Message 4 : Intruder -> B : (encrypt(nb_4,publickey(keyb_1))) Syntax description: The first line provides the serial number of the Authenticity check. The syntax of the rest of the lines is identical to the corresponding lines in a secrecy attack. 5.2 No Attacks detected the protocol is secure No attacks were found - the protocol is secure. This expression appears when no attacks, of any type, were identified by CPV. (In that case TLV is not activated). 5.3 No Attacks detected - protocol may be secure 36

No attacks were found - protocol may be secure. This expression appears when attacks were identified by CPV but these same attacks were not identified by TLV, i.e. TLV determines that the attacks are false. As explained before in Chapter 3 and presented in figure 3.2, in this case Combined CPV-TLV can not reach a decision concerning the security of the protocol. That is because CPV produces a representative of a group of attacks that it may find, and while the attack can indeed be false there maybe other which are perfectly valid. It should be pointed out that TLV tests all of the attacks that CPV identifies and displays, however, Combined CPV-TLV displays only validated attacks. See Appendix E.1 for example where at a test performed on the Needham-Schroeder public key protocol two attacks were detected by CPV and then validated by TLV. 37

6. Comparison to other Verification Systems The following is an overview of some of the other existing systems and tools that are used to verify security protocols: FDR/Casper. FDR (Failures-Divergence Refinement) [20] is a model-checking tool designed to establish results about concurrent and reactive systems described using the process algebra CSP [20]. It has the ability to check the determinism of a state machine, and is therefore used primarily for the checking of security properties. Each participant taking part in the protocol is modeled as a CSP process representing the participant s steps preformed in the protocol. Casper [13] is an automatic tool that produces a CSP model from a given more abstract description, thus greatly simplifying the process of modeling and analysis. Its purpose is to make FDR more available for designers and implementers of protocols lacking high-quality skills in CSP. Casper and FDR are used together, where Casper produces CSP descriptions of security protocols and FDR analyzes them. Brutus [7]. An automatic model checking tool designed especially for the verification of cryptographic protocols. It supports a wide class of security protocols and is completely push button in nature. If the protocol under consideration is 38

incorrect or flawed, the tool generates a counterexample or an attack demonstrating the flaw. It uses as an input a special-purpose expressive language for specifying protocols properties. Murphi [8,18]: Murphi is a finite-state verification tool with its own input language. It accepts as an input a description of the protocol and of the intruder in Murphi language and generates a C++ program, which is compiled together with the code of the verifier. It searches for all reachable states and then checks whether the security properties are always fulfilled. In case that a flaw is found it prints a trace of states from the start state to the state exhibiting the problem. It can not guarantee the correctness of a protocol. Athena [21]: Athena is an automatic checking tool for the analysis of security protocols. It incorporates a logic that can express security properties including authentication, secrecy and properties related to electronic commerce. For a wellformed formula, if the evaluation procedure terminates, it will generate a counterexample if the formula is false, or provide a proof if the formula is true. However, in order to guarantee termination sometimes the number of sessions must be limited. NRL Protocol Analyzer [16]: NRL (US Naval Research Laboratory) Protocol Analyzer is a verification tool, written in Prolog, that has been developed for the 39

analysis of cryptographic protocols. It uses model checking to model the protocol as an interaction between a set of state machines and attempts to locate security flaws by working backwards from an insecure state. It can be used to prove security properties of cryptographic protocols as well as locate security flaws. The following table compares a few of the features of Combined CPV-TLV with those of some of the tools described above: General aspects Can prove that a protocol is secure Detects only real attacks Able to execute an infinite number of Sessions in parallel Real use of fresh nonce Automatic operation Combined CPV-TLV TLV [23] CPV [1,2,3,5] Casper/FDR [14] Brutus [7] Murphi [17,18] Yes No Yes No No No Yes Yes No* Yes Yes Yes Yes No Yes No No No Yes No Yes No No No Yes Yes Yes Partial** Yes Yes 40

Input features Input language / description Input is self explanatory An agent can be easily declared as multiple participants Link of variables to a certain agent Link of functions to a certain agent Ability to use agent as deliverer of message without reading it abstract description SMV extension of Π calculus syntax abstract description expres sive logic Murphi languag e Yes No No Yes Yes No No Yes No Yes Yes Yes No Yes No Yes Yes No No NA No Yes NA NA Yes Yes Yes Yes No Yes * In a few cases CPV may detect false attacks as if truly existing. * * FDR should be activated manually after Casper produces the CSP description of the security protocol. 41

7. Results, Conclusions, Future improvements 7.1 Results and Conclusions The major goal for the development of Combined CPV-TLV was to create an automatic verification system that combines the power of logic programming and model checking by joining CPV and TLV, such that CPV is used to determine that a protocol is secure and TLV is used to validate or reject attacks which may have been detected by CPV. Various tests were performed in order to test the validity of the system as presented here. See Appendices B1 - B5. Examples: In Needham-Schroeder public key protocol [20] two attacks were detected by CPV and then validated by TLV. Both attacks match the type of attacks that appear in the literature regarding this protocol. 42

In OtwayRees protocol [20], an authenticity attack for non-injective agreement was detected by CPV and validated by TLV. The attack matches the type of attack that appears in the literature regarding this protocol. Yahalom protocol [20] was found to be secure and indeed no attack for that protocol appears in the literature. Two versions of ISO Candidate protocol [19,11]were tested. In the first version each of the participants was required to execute only his role in the protocol. In the second version both participants were required to execute both roles simultaneously. The authenticity attack (Canadian attack [19,11]) that appears in the literature was detected only in the second test. A special protocol was created in order to test the ability of the system to deal with false attacks detected by CPV. CPV indeed detected an attack for this protocol and TLV determined that it is false see Appendix E.4. The simplicity of use of both input and output syntax is clearly demonstrated by the examples provided in Appendix E. The main part of the input is the Protocol description section which looks very similar to a pseudo code syntax. The output is also very similar to a pseudo code syntax and is constructed from a trace of messages 43

that form an attack in the order that they were sent (in case that an attack is found). In case that an attack is not detected a suitable message is being displayed. Conclusions: Combined CPV-TLV provides additional and accurate information on the secrecy and authenticity of the protocol under test, over and beyond what CPV and TLV can offer when used separately. The various tests performed with different and representative security protocols show that the system performs as required. 7.2 Future improvements of Combined CPV-TLV Some possible future improvements of Combined CPV-TLV system are: When an attack is detected by CPV, the family type of that attack should be checked by TLV and not only the specific attack itself that is displayed by CPV. This important feature, if and when implemented, will enable Combined CPV- TLV to provide a clear and unambiguous answer on the security of the protocol 44

under test (thus effectively eliminating Combined CPV-TLV s statement of a maybe secure protocol). It could be useful to create a new verification system based on Logic Programming that will replace the CPV and will produce a full description including all possible attacks. Support authenticity for injective agreements. Provide a separation between different variables known to participants, in addition to the separation between variables known to Intruder and those known to all of the participants. Provide a separation between different functions known to participants, in addition to the separation between functions known to Intruder and those known to all of the participants. Develop a special input editor with an easy to handle user interface. 45