CS5232 Formal Specification and Design Techniques. Using PAT to verify the Needham-Schroeder Public Key Protocol

Transcription

1 CS5232 Formal Specification and Design Techniques Using PAT to verify the Needham-Schroeder Public Key Protocol Semester 2, AY 2008/2009 1/37

2 Table of Contents 1. Project Introduction 3 2. Building the PAT model Variables and Channels Initiator Responder Intruder The System Analysis of the System The Corrected Protocol Building the Corrected Protocol Model Analyzing the Corrected Protocol Model 28 5 Bugs Found in PAT Crash # Crash # UI Bug 35 6 PAT Suggestions User Interface Suggestions Functionality Suggestions 36 Annex A Original Version of Needham-Schroeder Public Key Protocol Annex B Fixed Version of Needham-Schroeder Public Key Protocol 2/37

3 1. Project Introduction In this project, we used PAT to model the Needham-Schroeder Public Key Protocol. The aim of the protocol is to make that the two parties can be assured of each other s identity they should become sure that they really are talking to each other, rather than an intruder impersonating the another party. The protocol, by itself, is simple as it requires only 3 messages in order to establish a session between 2 authenticated parties as seen below: However, the situation becomes more complicated when there is an intruder who is able to listen to the communication between 2 parties and try to impersonate the initiator. Thus, by modeling the protocol, we hope to check the states of all possible situations that can arise and expose any possible weaknesses that can be exploited should an intruder be able to interpret and make use of the messages sent between the initiator and the receiver. 2. Building the PAT model We assume that the details of the Needham-Schroeder protocol are known. If not, the description of the protocol and its details can be found in (Paolo & Riccardo, 2002), (Lowe, 1996), (Needham & Schroeder, 1978). In order to model the Needham-Schroeder protocol, we follow the modeling approach of the Promela model as described in (Paolo & Riccardo, 2002). Thus, we will describe how we translate the Promela model to the PAT model and yet preserve the same logic and modeling details of the protocol. We will also touch on the limitations of PAT compared to Promela and how we work around such limitations, and the advantages of PAT over Promela. 3/37

4 Our protocol involves 2 agents and an Intruder. A plays the role of the initiator, B plays the role of the responder (ie. the party which A is wants to establish authentication with), and, I, the intruder, plays the role of the intruder. We model each agent taking part in the protocol as CSP processes. We also model the most general intruder who can interact with the protocol: the intruder can observe and intercept all messages, and so learn information such as the values of nonces and then use this information to introduce fake messages into the system. We use PAT to test whether the protocol correctly achieves authentication, and discover an attack upon the protocol which allows the intruder to imitate an agent A in the run of the protocol with another agent, B. This attack was previously reported by Lowe in (Lowe, 1996). Following which, we also implemented the fixed version of the protocol that has the identity of the responder within the encrypted message. With the new protocol, we were able to obtain an execution trace where the responder correctly commits to a session with the initiator. With the new protocol, we were also to show that it is secure and the intruder was unable to imitate another party. Thus, we will show that our system is secure for the case of a single initiator and a single responder. Lowe [3] proved that if this protocol is secure for a small system, then it implies that it would be secure for a system of arbitrary size. All messages sent by party A to either B or another any party (I) will be stored in a channel from which the intruder, I, is able to intercept, get useful information from it, and try to impersonate A. 4/37

5 2.1 Variables and Channels PAT: PROMELA: 5/37

6 Promela is a strongly typed language. Thus, we need to define the data types for the parties and its nonce as a type, mtype. However, PAT is weakly-typed. Thus, there is actually no need to define the types of A, B, I, Na, Nb and gd. They will be dynamically typed on their first use of the variables. However, to properly identify them, and use them for channel blocking later, we have to define them as constants. As such, we define them as integer constants from 1 to 6 respectively. A, B, and I play the role of the initiator, responder and Intruder respectively. Na and Nb represent the nonce used by role A and B respectively. In the real world, the nonce will always be different for each session. However, the purpose of the model is to detect possible security flaws in the protocol and not the flaws in the cryptosystem used by the protocol. Thus, since we are only interested in establishing authentication for one session, we assume that the nonce used by A and B to be a constant (in the session). gd is simply the symbolic representation of a generic data used by the intruder. Note also that due an advantage in PAT features, there is no need to for a service constant, R, as used in the Promela model. For channel initialization, as Promela is strongly typed, it requires the data types to be declared in the definition of the channels and only the defined types is able to be passed through the channels. However, for PAT, we simply define the channel and make sure that the input and output have exactly the same number of items. The variables used to store the input of the channel will be automatically typed based on the messages stored in the channel. There is no need to define the type as the type will be dynamically typed based on what is in the channel itself. For both PAT and Promela, there is support for synchronous channels, that is, channels without buffer. Thus, for the channels, we initialize them with buffer of size 0. The global variables are essentially the same. Promela uses bit to type it, while PAT uses var to define a generic variable and dynamically type using the value false. 6/37

7 2.2 Initiator PAT: PROMELA: 7/37

8 The PIni process represents the role of the Initiator, A. The process is simple. A sends a message {Na, A} using the public key of the intended party, starting the run of the protocol with the party. This is step 1 in the diagram above and represented by ca!a.na.a.party. It then waits for a reply that is encrypted using his own (A s) public key. A is then able to decrypt the message using his secret key and if B is really B as he claims, then he should be able to encrypt A s nonce in the message. This is step 2 in the diagram above and is represented by ca?a.na.g1.a. Finally, A decrypts the message {Na, g1} and sends the message {g1} (supposedly the nonce of B) back to the intended party using the intended party s public key. If A is able to decrypt B s nonce using A s own secret key, this means that agent who sent the message is indeed agent A. In the original Promela code, the process has 3 parameters in order to represent the sequence of message exchanges prescribed by the protocol. This is needed in Promela because the parameters are needed to make sure that the channel s message is the same as the parameters. However, we simplify this in PAT as we felt that two of the parameters are actually constants and are redundant. Moreover, this simplification is required as PAT is only able to block parameters if they are constant value, unlike that of Promela, which blocks based on the variable s content. Thus, the only parameter that PAT requires is the party since the initiator, A, can choose to initiate sessions with different parties. The parameter self and nonce is redundant as they basically constants. That is, they always represent the same item and the only parameter that will be passed in for PIni s self is A and PIni s nonce is the nonce of the A. Thus, we only retain parameter of party as this is the only parameter that changes. 8/37

9 As PAT is weakly-typed, we also do not need to initialize the type of the variable (g1) passed in by the channel. Instead, in PAT, the data type of the variable in g1 will be dynamically typed based on what is in the channel itself. In Promela, the IniRunning macro and the channel sending are casted as an atomic operation. This is to reduce the amount of allowed interleaving and thus reduce the complexity of the model from the verification point of view. However, in the current PAT, each channel sending/receiving is one atomic operation and there is no way to perform another operation together with channel sending/receiving in one atomic operation. In our communication with Sun Jun, he mentioned that this could lead to data corruption. In the context of this protocol, since the variables sent into the channels are not changed, the results will be the same even if they are allowed to interleave as separate events or operations. It will only lead to an increase in the amount of interleaving. Since PAT does not allow macros, we use events and statement blocks to represent the operations to be performed. In the Promela model, the eval operator was used to block the channel from being read until the requirements of the message in the channel are met. For example, in the Promela model, the channel ca will only accept messages where the first message on the channel is equivalent to the variable parameter self, otherwise, the channel receiving will be blocked until the evaluation becomes true. However, PAT does not support channel blocking based on variables. Fortunately, PAT does support channel blocking based on constants. Thus, we exploit the fact that PIni s self and nonce are always the constant A and Na respectively. Thus, using PAT, we are also able to block the channel receiving. We only allow the channel to receive using the constants A and Na, if the message of the channel is of the following form: A.Na.g1.A, where g1 can be any message. Lastly, we note that the process stops once it is able to decrypt the party s nonce and send the party s nonce back to the party. This indicates that the session has been established and the parties have been authenticated. That is, A is able to communicate with its intended party knowing that he really is communicating with his intended party. Thus, the process does not repeat itself, terminates and stops. This is represented by the PAT command Skip. 9/37

10 2.3 Responder PAT: PROMELA: 10/37

11 The PRes process represents the role of the Responder, B. The process is simple. As seen in the diagram above, B receives the message sent by A.. This is represented by the statement in PAT, ca?b.g2.g3.b. Since the message is encrypted using B s public key, B is able to decrypt it to find A s nonce. It then decrypts the message using its own secret key and send the message back to A with its own nonce encrypted using A s public key. By sending A s nonce back to A, A is able to authenticate that B is really B since only B knows his own secret key. This is represented by the statement ca!b.g2.nb.g3. For B to make sure that A is indeed A, he would have to wait for A to decrypt the message it sent out and send it back its own encrypted nonce. Thus, B waits for its own nonce encrypted with its own public key to be sent back to the channel. This is represented by the statement cb?b.nb.b. Similar to the Initiator process in the previous section, we do not need any parameters. This is because, in the Promela model, the parameters that it accepts are basically constants. In order to call the process PRes, the parameters are self and the nonce of B, which are always B and Nb respectively. Thus, we omit the parameters. Also, similar to the Initiator process in the previous section, we do not need to type g2 and g3. We also block the channel from receiving specific messages by exploiting the use of constants. Using events and statement blocks, we are able to perform the operations needed. Atomic operations are not needed as the end verification results will be the same. Finally, if B receives its nonce, Nb, that was encrypted in the message sent out previously, then it is able to confirm the identity of A and session has been established and parties identities authenticated. B is able to communicate with A knowing that he really is communicating with his A, and vice versa. Thus, the process does not repeat itself and stops. This is represented by the PAT command Skip. 11/37

12 2.4 Intruder PAT: 12/37

13 PROMELA: 13/37

14 Here, we want to model the intruder as a process that can perform any attack that we would expect a real-world intruder to be able to perform. Thus, the intruder should be able to : Overhear and intercept any messages being passed in the system Decrypt messages that are encrypted with its public key, so as to learn new nonces. Introduce new messages into the system using the nonces that he knows. Reply to any messages that he has seen (possibly changing plain-text parts), even if he does not understand the content of the encrypted part. We assume that the intruder is a user of the computer network and so can take part in normal runs of the protocol, and other agents may initiate runs of the protocol with him. We will define the most general intruder who can act as above. Thus, we model the Intruder based on what messages it is able to intercept and what it can learn from the messages that it intercepts to avoid the representation of redundant knowledge that the intruder will never use. For example, the intruder can only decrypt messages that are encrypted with his own public key and store the nonce, otherwise, it stores the message as a whole without decrypting. Also, only sending the message {Nb}PK(B)will be useful as that is the only message that B will accept in order to establish the authenticated session. Other messages such as {Na}PK(B) does not have any effect as it is not accepted by B. All messages sent by party A to either B or another any party (I) will be stored in a channel from which the intruder, I, is able to intercept, get useful information from it, and try to impersonate A. Thus, the role of I is both to act as a middleman between A 14/37

15 and B and as a normal user of the computer network that any A may initiate runs of the protocol with. In both cases, its main aim is to impersonate A if possible. To model the intruder, we have to understand that the intruder behaves as a never ending process that spends all its time sending messages to and receiving messages from the protocol channels (ca and cb). In Promela, this was modeled as an infinite do-while loop. However, this is not possible in PAT as channel sending and receiving can only be modeled as an event and not as an operation. Thus, we are unable to put channel sending and receiving in loops. As such, we model the intruder as a process that always goes back to itself and never stops. To do this, we use a choice operator to signify that the process can choose any operations it wishes to perform as long as the guarded condition is satisfied and always goes back to itself to signify that it is a never ending process. Similar to the Promela model, each branch of the main repetition construct represents an input or output operation on the global channels (ca and cb) In the Promela model, the command :: ca! (kna -> A : R), Na, Na, A is used to represent the intruder sending the message {Na, Na} PK(A) to A on the condition that the intruder knows Na (ie. The value of the variable kna is 1). If the intruder does not know kna, then the message is sent to a non-existing identity R. However, the sending of message to R is actually a redundant step, and this might be due to a Promela restriction. We model a more correct model that does not send the message at all if the intruder does not know Na. To do this, we use the guard condition to block the sending of messages until the guard condition is satisfied. That is, if kna is not known to the intruder, the messages will not be sent at all. This results in a cleaner code that is easier to understand and models the system in a more accurate way. In Promela, while intercepting the channel s data, x1, x2 and x3 are service variables that are reused to record the channel input and always set to 0 before the next operation. However, this is not required in PAT as the variables used to record the channel input are always new variables that are freshly initialized. Macros are also used in Promela to simply the code and result in a cleaner program. However, in PAT, macros are not yet available. Thus, we have to code the logic for the 15/37

16 macros directly into the intruder process (PI) and name in order to identify them in the trace, we named the events as InterceptChanA and InterceptChanB. PAT 2.3 does not support local variables. As such, we move the local variables in the Promela model into global variables. This is able to work since the PI process is the only process that modifies those variables. There are not other processes that modify those variables. Thus, even though the structure of the PAT s intruder process and Promela s model looks rather different, the logic of the 2 processes is the same. They are never-ending processes that spend their time receiving messages to increase its knowledge and sending messages based on its current knowledge. 16/37

17 2.5 The System PAT: PROMELA: The PAT model depicts that the process that the Initiator, A, initiates a protocol run with any other agents (some other party, I, or the intended party B). This is interleaved with the Responder process and the intruder process. This depicts exactly the same logic as in the Promela model, where the 4 processes run together and interleave with one another. 17/37

18 3. Analysis of the System We can use PAT to test whether the protocol correctly authenticates the two agents. This is done using LTL properties. We can also test the reachability of a state or if the system is deadlock-free. We will explore the use of some of these tests to verify the protocol. LTL PROPERTY #1: Formally, this LTL property basically states that ResRunningAB must come true before IniCommitAB. Informally, we use this property to test whether the protocol correctly authenticates the responder. To do so, we ensure that the initiator A commits to a session with B only if B has indeed taken part in a run of the protocol with A. The result of the assertion is that the formula is VALID. That is to say, this LTL formula is true in every execution path of the system. In other words, there are no execution paths in the system in which ResRunningAB does NOT come before IniCommitAB. Thus, in all execution traces, the identity of agent B is always properly authenticated. Verification Result: ***The Assertion (Protocol() = [](([]! inicommitab) (! inicommitab U resrunningab))) is VALID.*** Verification Setting: Method: SCC-based Model Checking Verification Statistics Visited States:3155 Total Transitions:8380 Search Depth:15 Time Used: s Estimated Memory Used: KB 18/37

19 LTL PROPERTY #2: Formally, this property states that IniRunningAB must be true before rescommitab. Informally, we use this property to test whether the protocol correctly authenticates the initiator. To do so, we ensure that the responder B commits to a session with initiator A only if A took part in the protocol run. The result of the assertion is that the formula is NOT VALID. That is to say, there exists an execution path where this LTL formula is not satisfied. As expected, PAT discovers that the Protocol does not satisfy the above property. It finds that after the trace: 19/37

20 Or in the trace state: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> ca > InterceptChanA -> ca > IniCommit_AB -> cb > InterceptChanB -> cb > ResCommit_AB -> deadlock! This is better shown in the diagram below: PIni PI PRes ca!a.{na.a} PK (I) ca?a.{na.a} PK (I) ca!b.{na.a} PK (B) ca?b.{na.a} PK (B) ca?b.{na.nb} PK (A) ca!b.{na.nb} PK (A) ca?a{na.nb} PK (A) ca!a.{na.nb} PK (A) cb!a.{nb} PK (I) cb?a.{nb} PK (I) cb!b.{nb} PK (B) cb?b.{nb} PK (B) Basically, this means the responder B commits to a session with A even though A is not trying to establish a session with B. A is trying to establish a session with I. In other words, A tries to establish a session with I, while the intruder impersonates A to establish a false session with B. This is the same attack that was discovered by Lowe in (Lowe, 1996). In more details, A tries to establish a session with I, sending the nonce Na encrypted with I s key. The intruder then imitates A to start a run of the protocol with B, sending the same nonce, Na. B responds by choosing a new nonce, Nb, and returns the message to A. The intruder cannot decrypt this message to obtain Nb, but instead uses A as an oracle, by replaying this message. A decrypts the message to obtain Nb, and returns this to I. I can then decrypt the message to obtain Nb, which he returns to B, thus completing the protocol. Hence, B believes that he has correctly established an authenticated session with A. Thus, in this execution trace, the identity of agent A is not properly authenticated. 20/37

21 REACHABILITY TEST #1: This reachability test states that when the A initiates a session with I, then a session between A and B will be established. Thus, this is not supposed to be true. However, due to the weakness demonstrated by Lowe and explained in LTL Property #2, a session is still established between A and B although A tries to initiate a session with I. Thus, the witness is the same as the previous one and is illustrated as follows: PIni PI PRes ca!a.{na.a} PK (I) ca?a.{na.a} PK (I) ca!b.{na.a} PK (B) ca?b.{na.a} PK (B) ca?b.{na.nb} PK (A) ca!b.{na.nb} PK (A) ca?a{na.nb} PK (A) ca!a.{na.nb} PK (A) cb!a.{nb} PK (I) cb?a.{nb} PK (I) cb!b.{nb} PK (B) cb?b.{nb} PK (B) Verification Result: ***The Assertion (Protocol_AB() reaches goal) is VALID.*** Execution: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> ca > InterceptChanA -> ca > IniCommit_AB -> cb > InterceptChanB -> cb > ResCommit_AB Verification Setting: Method: DFS Reachability Analysis Verification Statistics Visited States:79 Total Transitions:87 Search Depth:13 Time Used: s Estimated Memory Used: KB 21/37

22 REACHABILITY TEST #2: This reachability test states that when the A initiates a session with B, then a session between A and B will be established. Thus, this has to be true for the protocol to work. Fortunately, this reachability test is reachable. The witness is as follows: PIni PI PRes ca!a.{na.a} PK (B) ca?a.{na.a} PK (B) ca!b.{na.a} PK (B) ca?b.{na.a} PK (B) ca?b.{na.nb} PK (A) ca!b.{na.nb} PK (A) ca?a{na.nb} PK (A) ca!a.{na.nb} PK (A) cb!a.{nb} PK (B) cb?a.{nb} PK (B) cb!b.{nb} PK (B) cb?b.{nb} PK (B) In this execution flow, PI just acts as a true middleman and communicates the message from A to B and vice versa. Thus, when A initiates a session with B, the session is able to be established correctly. Verification Result: ***The Assertion (Protocol_AB() reaches goal) is VALID.*** Execution: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> ca > InterceptChanA -> ca > IniCommit_AB -> cb > InterceptChanB -> cb > ResCommit_AB Verification Statistics Visited States:79 Total Transitions:87 Search Depth:13 Time Used: s Estimated Memory Used: KB 22/37

23 DEADLOCK-FREE Since PI() is a never-ending process, the System can never be deadlock free. If the System is deadlock-free, that means that the connection from A to B will ALWAYS be established no matter what. Obviously, this is not true. Moreover, PI() is a neverending process, and will always be deadlocked after connection has been established. After process PIni() and PRes() has terminated with Skip, PI() will be deadlocked, trying to send messages with no one to receive it. Moreover, there are also other simpler cases which lead to a deadlock: PIni PI PRes ca!a.{na.a} PK (B) ca?a.{na.a} PK (B) ca!b.{gd.a} PK (B) ca?b.{gd.a} PK (B) ca?b.{gd.nb} PK (A) ca!b.{gd.nb} PK (A) ca?a.{na.g1} PK (A) Deadlocked! In this example, instead of forwarding A s message to B, I sends generic data to B, leading to B packaging the generic data using A s public key. However, since I is unable to decrypt the message, I can only forward the message back to A. However, A only accepts messages that is packaged with its nonce and not generic data. Thus, I is unable to send any message that A is able to accept. Thus, a deadlock occurs. 23/37

24 Using a Search Depth of 7, we get the following trace that is same as the one presented above. Verification Result: ***The Assertion is NOT valid.*** Counterexample: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> ca > InterceptChanA Verification Statistics Visited States:631 Total Transitions:1484 Search Depth:7 Time Used: s Estimated Memory Used: KB However, using an infinite search depth, we get a longer Witness trace but with less visited states. This is due to the Depth-first search that was used. The depth-first search shows the witness for the first dead-lock found but does not guarantee that it has the shallowest depth. To do so, we need a Breadth-first search. Verification Result: ***The Assertion is NOT valid.*** Counterexample: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> ca > InterceptChanA -> ca > IniCommit_AB -> cb > InterceptChanB Verification Statistics Visited States:70 Total Transitions:69 Search Depth:11 Time Used: s Estimated Memory Used: KB 24/37

25 4. The Corrected Protocol PAT showed us a trace in which I was able to impersonate A to establish connection with B even though A did not establish any connection with B. To fix the protocol, we follow the idea by (Lowe, 1996) to include the identity of the responder within the encrypted part of the message. Thus, we change the protocol from: to the following: A {Na, A} PK (B) B {Na, Nb, B} PK (A) {Nb} PK (B) This prevents the previous weakness because the intruder cannot successfully replay the message {Na, Nb, B} PK (A) as A is expecting a message containing I s identity. We adapt out PAT representation of this protocol and the intruder. PAT then fails to find any attacks on the protocol. 25/37

26 4.1 Building the Corrected Protocol Model We will highlight the difference between original protocol and the fixed version in terms of modeling. We will NOT highlight the difference in logic as this is a straight-forward transition from the Promela model. PAT: PROMELA: 26/37

27 The only difference in terms of modeling is the Initiator Process, PIni. In the original protocol, we were able to parameterize PIni() in order to take in the party to whom we want to establish a connection with. However, this is not possible in the fixed protocol because we need to block the channel based on the parameter party. This is because, unlike Promela, PAT does not allow blocking channels backed on variables, and only allow channel blocking backed on Constants. Thus, to work around this, we have to code 2 separate processes to handle the channel that deals with party B and party I separately. For the process that deals with party B, we can safely set IniCommit to true since it would have to be true as the channel waits for a message encrypted with party B. 27/37

28 4.2 Analyzing the Corrected Protocol Model LTL PROPERTY #1: Formally, this LTL property basically states that ResRunningAB must come true before IniCommitAB. Informally, we use this property to test whether the protocol correctly authenticates the responder. To do so, we ensure that the initiator A commits to a session with B only if B has indeed taken part in a run of the protocol with A. Similar to the original protocol, the result of the assertion is that the formula is VALID. That is to say, this LTL formula is true in every execution path of the system. In other words, there are no execution paths in the system in which ResRunningAB does NOT come before IniCommitAB. Thus, in all execution traces, the identity of agent B is always properly authenticated. Verification Result: ***The Assertion (Protocol() = [](([]! inicommitab) (! inicommitab U resrunningab))) is VALID.*** Verification Statistics Visited States:2091 Total Transitions:5528 Search Depth:14 Time Used: s Estimated Memory Used: KB 28/37

29 LTL PROPERTY #2: Formally, this property states that IniRunningAB must be true before rescommitab. Informally, we use this property to test whether the protocol correctly authenticates the initiator. To do so, we ensure that the responder B commits to a session with initiator A only if A took part in the protocol run. The result of the assertion is that the formula is VALID. That is to say, this LTL formula is true in every execution path of the system. In other words, there are no execution paths in the system in which IniRunningAB does not come before rescommitab. This is different from the original protocol where a weakness of the protocol is found. In this fixed protocol, even when A tried to establish a session with I, the intruder is unable to impersonate A to establish a false session with B. Thus, in all execution traces, the identity of agent A is always properly authenticated. Verification Result: ***The Assertion (Protocol() = [](([]! rescommitab) (! rescommitab U inirunningab))) is VALID.*** Verification Statistics Visited States:2143 Total Transitions:5872 Search Depth:14 Time Used: s Estimated Memory Used: KB 29/37

30 REACHABILITY TEST #1: This reachability test states that when the A initiates a session with I, then a session between A and B will be established. Obviously, this is not supposed to be true. In the original protocol, this is true due to the weakness in the protocol. However, in the fixed version, the assertion is not true, which verifies that the protocol is correct. Verification Result: ***The Assertion is NOT valid.*** Verification Statistics Visited States:627 Total Transitions:1204 Search Depth:11 Time Used: s Estimated Memory Used: KB 30/37

31 REACHABILITY TEST #2: This reachability test states that when the A initiates a session with B, then a session between A and B will be established. Thus, this has to be true for the protocol to work. Fortunately, this reachability test is reachable. In the original protocol, this also holds true. The witness is as follows: PIni PI PRes ca!a.{na.a} PK (B) ca?a.{na.a} PK (B) ca!b.{na.a} PK (B) ca?b.{na.a} PK (B) ca?b.{na.nb, B} PK (A) ca!b.{na.nb,b} PK (A) ca?a{na.nb, B} PK (A) ca!a.{na.nb, B} PK (A) cb!a.{nb} PK (B) cb?a.{nb} PK (B) cb!b.{nb} PK (B) cb?b.{nb} PK (B) In this execution flow, PI just acts as a true middleman and communicates the message from A to B and vice versa. Thus, when A initiates a session with B, the session is able to be established correctly. Verification Result: ***The Assertion (Protocol_AB() reaches goal) is VALID.*** Execution: ***init -> IniRunning_AB -> ca > InterceptChanA -> ca > ResRunning_AB -> cc > InterceptChanC -> cc > IniCommit_AB -> cb > InterceptChanB -> cb > ResCommit_AB 31/37

32 DEADLOCK-FREE Since PI() is a never-ending process, the System can never be deadlock free. If the System is deadlock-free, that means that the connection from A to B will ALWAYS be established no matter what. Obviously, this is not true. Moreover, PI() is a neverending process, and will always be deadlocked after connection has been established. Similar to the original protocol, a deadlock-free situation can never occur. Thus, this also verifies the model. Verification Result: ***The Assertion is NOT valid.*** Counterexample: ***init -> ca > InterceptChanA -> ca > ResRunning_AB -> cc > InterceptChanC -> cc > cb > InterceptChanB Verification Setting: Method: DFS Reachability Analysis Partial order reduction: True Fairness: Not Applicable System abstraction: False Verification Statistics Visited States:56 Total Transitions:55 Search Depth:9 Time Used: s Estimated Memory Used: KB 32/37

33 5. Bugs Found in PAT While playing with PAT, we also found some bugs in PAT. 5.1 Crash #1 We found a crash while using Process Level Weak Fairness during Verification on the Original Protocol. With the normal code shown above, the verification went fine as seen below: However, as soon as we add another choice [] Skip; - to the PI() process, a crash occurred. This is shown in the screen capture below: 33/37

34 34/37

35 5.2 Crash #2 When closing multiple tables quickly, we obtained the following Crash! 5.3 UI Bug DOES NOT WORK When having multiple tabs open, the scroll bar on top does not work. 35/37

36 6. PAT Suggestions 6.1 User-Interface Suggestions 1. Support for Ctrl Tab to switch between Tabs in a LRU (last recently used) order. This should be similar to the order used by Windows Task Manager when pressing Ctrl-Tab 2. Support for Dragging a File into PAT (like dragging a file into Notepad) 3. Ability to adjust Tool-Tip timing in the Graph generated. This is because sometimes the process is very long and much time is needed to read the Tool-tip when doing a Mouseover over one of the graph nodes. 4. Ability to double-click or something on a Node in the Graph and goto that state so that the Data Store Pane can be updated. Now, in order to update the Data Store Pane, we have to find the Node Number under the Event Trace in order to goto that State and update the Data Pane. However, updating the Data Pane instantly while double clicking on a node would be more user-friendly. 6.2 Functionality Suggestions 1. Ability to generate other counter-examples if an Assertion fail. This allows someone verifying the protocol to see if there are other counter-examples and may help to better find the weaknesses in the system. Currently, PAT only shows the first witness trace. 2. Support for Functions or Macros like that of Promela. This would help to write shorter and cleaner code. 3. Support for Channel Blocking based on variables, similar to Promela. 36/37

37 4. Currently, PAT only supports this Syntax: D = a -> b -> if (.. ) {c -> abc -> abc -> D } else { d-> abc -> abc -> D} However, this leads to redundant code as abc -> abc -> D is being repeated twice. We may refactor abc -> abc -> D into another process, but this might not be natural. Thus, perharps PAT can support a syntax in which it might not end with a process but ultimately will end with a process as like below: D = a -> b -> { if (.. ) {c} else {d} } -> abc -> abc -> D This will lead to cleaner code that allows for better refactoring. 37/37