Authentication by Witness Functions
Jaouhar Fattahi, Mohamed Mejri, Emil Pricop

TL;DR
This paper extends witness functions from proving secrecy to verifying authentication in cryptographic protocols, demonstrating their safe application and analyzing a modified Woo-Lam protocol for authentication correctness.
Contribution
It introduces the use of witness functions for authentication and provides a method to analyze protocols for authentication correctness.
Findings
The modified Woo-Lam protocol is correct with respect to authentication.
Witness functions can be safely extended from secrecy to authentication.
The paper offers a new approach to protocol analysis for authentication.
Abstract
Witness functions have recently been introduced in cryptographic protocols' literature as a new powerful way to prove protocol correctness with respect to secrecy. In this paper, we extend them to the property of authentication. We show how to use them safely and we run an analysis on a modified version of the Woo-Lam protocol. We show that it is correct with respect to authentication.
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Authentication by Witness Functions
Jaouhar Fattahi1 and Mohamed Mejri1 and Emil Pricop2
1Department of Computer Science and Software Engineering. Université Laval. Québec. Canada.
{[email protected] [email protected]}
2Automatic Control, Computers and Electronics Department. Petroleum-Gas University of Ploiesti. Romania.
Abstract
Witness functions have recently been introduced in cryptographic protocols’ literature as a new powerful way to prove protocol correctness with respect to secrecy. In this paper, we extend them to the property of authentication. We show how to use them safely and we run an analysis on a modified version of the Woo-Lam protocol. We show that it is correct with respect to authentication.
Index Terms:
Analysis, authentication, proof, protocols, witness functions, Woo-Lam protocol modified version.
Notice
© 2016 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
I Introduction
Cryptographic protocols are distributed programs used everywhere. They are designed to provide security assurances in communications by using cryptographic primitives. Traditional assurances include secrecy, integrity and authentication, and more recently, anonymity, atomicity, verifiability, coercion-resistance, etc. It has been clear for a long time that cryptographic protocols are prone to serious design drifts. Therefore, several formalisms [1] have been proposed to check protocols against flaws and vulnerabilities. In this paper, we focus on authentication. Authentication is the property that should be satisfied by a protocol to be secure against acceptance of a fraudulent agent by ensuring that one party is who he claims to be. A protocol can reach authentication by means of secrecy when it succeeds to provide evidence to one party that the second party manages to present a piece of data that could only have been generated by him (e.g. response to a challenge). This implies, very often, that some data can be unequivocally traced back to its origin. In some scenarios, authentication involves more than two parties where a trusted server could be used to introduce one party to another party and is assured that is trusted by the server in the required protocol semantics. It is worth mentioning that, of course, protocols can reach authentication with no need to secrecy, however, these protocols are not our target in this paper.
II Methodology
Our way to prove that a protocol is correct with respect to authentication consists in reaching two intermediate purposes:
we prove that the secret used for authentication is never disclosed to avoid any bad use of this latter by an opponent; 2. 2.
we make sure that the link between the authenticatee identity and the secret is never untied. This is to guarantee that the secret emanates from the right origin.
For that, we use the theory of witness functions [2, 3, 4, 5]. Witness functions adequately estimate the level of security of each atomic message. Before this paper, we used to use them to prove secrecy in a protocol by showing that it is increasing. That is to say, to show that the level of security of every single atomic message exchanged in the protocol is always growing and never goes down between any two consecutive steps of receiving and sending. Our contribution here is the extension of witness functions for the authentication property. For that, we give sufficient conditions for authentication based on the two mighty bounds of a witness function such, if met, the protocol is automatically declared correct with respect to authentication.
- •
in Sections III and IV, we’ll give a brief summary of the proof of correctness of increasing protocols when analyzed with safe functions and we give a guideline to build these functions;
- •
in Section V, we’ll give a short overview on witness functions and we bring out their powerful bounds;
- •
in Section VI, we’ll give sufficient conditions to ensure protocols’ correctness with respect to authentication based on witness functions;
- •
in Section VII, we’ll analyze a modified version of the Woo-Lam protocol;
- •
finally, we’ll compare our approach with similar ones and conclude.
Please notice that all the notations we will use in this paper are given in the appendix. The reader is kindly requested to see them before moving forward.
III On the correctness of increasing protocols
Hereafter, we remind an important result: ”A protocol keeps its secret inputs when analyzed with a safe function and shown increasing”.
III-A Safe functions
Definition 1
*(Well-formed Function)
Let be a function and be a context of verification. is -well-formed iff:
[TABLE]
A well-formed function must return the infimum to an atom that appears clear in to say that any participant knows it from . It returns to an atom in the union of two sets, the minimum of the two values calculated in each set separately. It returns the supremum to any atom that does not appear in to say that nobody could get it from .
Definition 2
*(Full-Invariant-by-Opponent Function)
Let be a function and be a context of verification. is full-invariant-by-Opponent iff: :
A full-invariant-by-opponent function is such, when it affects a security level to an atom in a set of messages , the opponent cannot deduce from this set some message in which this level decreases (i.e. ), unless he is expressly entitled to know it (i.e. ).
A function is s said to be safe if it is well-formed and full-invariant-by-Opponent.
Definition 3
*(-Increasing Protocol)
Let be a function and be a context of verification and be a protocol.
is -increasing iff: *
An -increasing protocol must produce traces with atomic messages having always a security level, returned by , higher when sending (i.e. in ) than when receiving (i.e. in ) or than its level set in the context (i.e. ), if known.
Theorem 1
*(Sececy in Increasing Protocols)
Let be a safe function and be an -increasing protocol.*
* keeps its secret inputs.*
Theorem 1 states that a protocol keeps its secret inputs when it is analyzed by a safe function and is shown increasing. This result is quite intuitive. In fact, if the opponent succeeds to obtain a secret (clear) from the protocol then its security level given by is the infimum since is well-formed. That cannot be due to the rules of the protocol since this latter is . That could not arise neither when the opponent uses his capabilities since is full-invariant-by-opponent. So, the secret is kept forever. The detailed proof is available in [5].
IV Guideline for Building Safe Functions
In [4] we propose a class of safe selections: . Any selection in must return to an atom in a message :
if is encrypted by a key such that is the outer key that satisfies the condition (we refer to it by the external protective key), a subset among and the neighbors of under the same protection by ; 2. 2.
for two messages linked by a function in other than an encryption by a protective key (e.g. pair), the union of two subselections in these two messages. 3. 3.
if does not have a protective key in , the infimum (all atoms); 4. 4.
if does not appear in , the supremum (the empty set);
Among the selections of , we spotlight three practical ones:
the selection it returns to an atom in a message encrypted by the external protective key , all the principal identities inside the same protection by , in addition to ; 2. 2.
the selection it returns to an atom in a message encrypted by the external protective key , the key ; 3. 3.
the selection it returns to an atom in a message encrypted by the key external protective key , all the principal identities inside the same protection by ;
Any selection in when composed to a adequate homomorphism returns a safe function . We choose the homomorphism that returns for:
an agent, its identity; 2. 2.
the key , if selected, the set of agent identities that are authorized to know it.
We denote by and respectively the functions resulting from the compositions and . We prove [4] that these functions are safe. In fact, since the selection for any atom is performed in an invariant section protected by the external protective key , then, to alter this section (to decrease the security level of ), the opponent must have priorly obtained the atomic key . At this point of the proof, his knowledge must satisfy: . Since the key satisfies: then the knowledge of the opponent must satisfy too seeing that the comparator ”” is transitive. This is simply the definition of a full-invariant-by-opponent function. These functions are well-formed by construction, too.
Example 1
*Context: ; ; ; . We have:
and .*
V Witness functions to eliminate the effect of variables
The functions we have defined so far are not useful in practice since they operate on ground terms only. However, a static analysis should be run over messages of the generalized roles resulting from writing the protocol in a role-based specification [18]. These messages contain variables that denote a content that an agent ignores and on which he cannot perform any verification. We give here a safe way to deal with variables. But now, let us introduce derivation in Definition 4.
Definition 4
[Derivation]
[TABLE]
Derivation simply eliminates variables from a message except a variable under evaluation. The expression denotes a message after removing all variables in. The aim of derivation is to deprive variables from playing any role when evaluating an atom in a message. The idea is hence to apply on the derivative message instead of the message itself. Besides, any variable is evaluated as a block with no regard to its content (i.e quantified). In fact, the reason why we do not care about the content of a variable is that if a variable, globally evaluated, is shown increasing that means that it cannot be discovered by any unauthorized party, and consequently any content inside cannot be discovered by an unauthorized party, too. If it is not increasing, then the protocol will not satisfy our sufficient conditions and hence no decision with respect to secrecy is made on, thus, with respect to authentication, too. This way of treating variables allows us to give any content of a variable (dynamically known) the same value of the variable itself (statically calculable). The way we evaluate an atom from within a derivative message is described by Definition 5.
Definition 5
*Let , and be a valid trace.
For all , , we denote by:*
[TABLE]
Since the expression does not depend on substitution (i.e the run ), we denote it simply by . Although the derivative function allows us to neutralize variables, which is as such an important intermediate result, using it as is to analyze protocols is not safe because it is not even a function in the protocol. In fact, when we want to evaluate the security level of in the trace for example, we must return to the generalized roles to see from which message (with variables) this trace is generated and we may realize that more than one message are able to generate it. For instance, the messages and are both candidates to generate the trace (i.e. possible sources of it). If we refer to the first source (i.e. to ), the security level of returned by (with ) is:
[TABLE]
Whereas, if we refer to the second source (i.e. to ), its security level is:
[TABLE]
Therefore, we cannot rely on to analyze a protocol. To overcome this insufficiency, we define the witness functions. A witness function looks for all the sources of a ground term in the finite set , applies to all of them, and returns the minimum. This minimum must satisfy both existence and uniqueness in the security lattice. Since a secret is always evaluated under the protection of a protective key, the research of the sources of a closed message in is then restricted to encryption patterns. We denote by the set of all encryption patterns generated by the protocol (renamed).
Definition 6
[witness function] Let , and be a valid trace. Let be a protocol and be a safe function. We define a witness function for all , , as follows:
[TABLE]
Using a witness function as is to analyze a protocol is a very tedious process since we cannot enumerate all the valid traces and their sources statically. For that we bind it into two bounds that do not depend on substitution (i.e on ). The upper bound of a witness function returns a minimum set of confirmed principal identities for any in whereas the lower bound returns the set of all principal identities from all the possible sources of (that are unifiable with it) including the odd ones. The lower bound hunts so any odd principal identity and interprets it as an attack. The proof is simple since we have always in the security lattice whatever . This is expressed by Proposition 1.
Proposition 1
[binding a witness function] Let . Let be a witness function. For all we have:
[TABLE]
VI Sufficient conditions for authentication (Contribution)
The Lemma 1 declares a decision criterion for secrecy based on the bounds of a witness function. The upper bound returns the set of original and trusted identities only from the received message. The lower bound returns the set of all the identities including those that could be inserted by a masquerader by substituting a regular message when sent. The criterion makes sure that no odd identity could be inserted in the evaluation neighborhood of a given atom in the sent message. The proof of Lemma 1 results directly from Proposition 1 and Theorem 1.
Lemma 1
[Decision for Secrecy] Let be a protocol. Let be a witness function. is correct with respect to secrecy if: we have:
[TABLE]
Theorem 2 forwards two conditions such, if met, a protocol is automatically declared correct for authentication. The first one ensures that the protocol does not disclose its secret inputs. An immediate outcome of this first result is that the message the verifier last receives for authentication is in a safe state and had not been subverted by a masquerader. The second one makes sure that the binding between the challenge and the identity of the identifier is not broken. Therefore, we call once again the upper bound of the witness function to confirm the originality of the claimer identity by evaluating the challenge in the message that should authenticate the claimer to the verifier. The second clause of the second condition is trivial and introduced just to make sure that the challenge is not received in a public state.
Theorem 2
[Decision for Authentication] Let be a protocol. Let be a witness function. is correct with respect to authentication if:
Lemma 1 is satisfied; 2. 2.
Let be the challenge in a message received by a verifier to authenticate an agent . We have:
[TABLE]
It is worth mentioning that:
- •
the conditions set by Theorem 2 can be verified statically as they use the two bounds of a witness function only and both of them are statically determinable;
- •
their verification is linear under the assumption of perfect encryption since the most costly operation is unification in the lower bound of a witness function which is linear under that assumption. However, under nonempty equational theories, it will vary from one to another. In a future work, we will give new results related to this question.
VII Analysis of a modified version of the Woo-Lam Protocol with a witness function for authentication (Contribution)
The original version of the Woo-Lam protocol has been proven incorrect by several means [6, 7, 8]. Hereafter, we analyze an modified version of this protocol with a witness function and we prove that it is correct with respect to authentication. This version is denoted by in Table I.
The role-based specification of is , where the generalized roles , of are as follows:
[TABLE]
The generalized roles , , of are as follows:
[TABLE]
The generalized role of is as follows:
[TABLE]
Let us have a context of verification such that:
; ; ;
; .
Let ; ;
We denote by the lower bound of the witness function .
The set of messages generated by is
The variables are denoted by and ;
After eliminating duplicates in and the messages that are not encryption patterns, we have:
VII-A Analysis of the Generalized Roles of
According to the generalized role of , an agent may take part in some session in which he receives an unkown message and sends the message . This is described by the following rule:
[TABLE]
-Analysis of the messages exchanged in :
1- For :
a- Receiving step: (when receiving, we use the upper bound)
[TABLE]
b- Sending step: *(when sending , we use the lower bound)
such that:
[TABLE]
Then, we have:
[TABLE]
2- Conformity with Lemma 1:
From (1) and (2) and since in the context, we have:
[TABLE]
Then, the generalized role of respects Lemma 1. (I)
VII-B Analysis of the generalized roles of
According to the generalized role of , an agent may take part in two subsequent sessions: and such that . In the first session , the agent receives the identity and sends the nonce . In the second one , he receives an unknown message and he sends the message . This is described by the following rules:
[TABLE]
B.1- Analysis of the messages exchanged in :
1- For :
Since is set public in the context (i.e. ), then, we have directly:
[TABLE]
B.2- Analysis of the messages exchanged in :
1- For :
Since is set public in the context (i.e. ), then, we have directly:
[TABLE]
2- :
Since when receiving, we have:
[TABLE]
Then, we have directly:
[TABLE]
3- Conformity with Lemma 1:
From (4), (5) and (6), we have: the generalized role of respects Lemma 1. (II)
VII-C Analysis of the generalized roles of
According to the generalized role of , an agent may take part in some session in which he receives the message and sends the message . This is described by the following rule:
[TABLE]
1- :
a- Receiving step: (when receiving, we use the upper bound)
[TABLE]
b- Sending step: *(when sending , we use the lower bound)
such that:
[TABLE]
Then, we have:
[TABLE]
2- :
a- Receiving step: *(when receiving, we use the upper bound)
[TABLE]
=\left\{\begin{array}[]{ll}\{A,B,S\}&\mbox{if }k_{as}\mbox{ is the external protective key }\mbox{of }V\mbox{ in}\\ &~{}~{}\mbox{ the received message }\{A.\{{\color[rgb]{1,0,1}B}.V\}_{k_{{\color[rgb]{1,0,1}as}}}\}_{k_{bs}}\\ \\ \{A,B,S\}&\mbox{if }k_{bs}\mbox{ is the external protective key }\mbox{of }V\mbox{ in}\\ &~{}~{}\mbox{ the received message }\{{\color[rgb]{1,0,1}A}.\{{\color[rgb]{1,0,1}B}.V\}_{k_{as}}\}_{k_{{\color[rgb]{1,0,1}bs}}}\end{array}\right.
Then, we have:
[TABLE]
b- Sending step: *(when sending , we use the lower bound)
such that:
[TABLE]
[TABLE]
[TABLE]
[TABLE]
[TABLE]
[TABLE]
[TABLE]
Then, we have:
[TABLE]
3- Conformity with Lemma 1:
[TABLE]
[TABLE]
From (11) and (12), we have: the generalized role of respects Lemma 1. (III)
From (I) and (II) and (III), we conclude that: respects Lemma 1. (IV)
Now that the first condition of Theorem 2 is satisfied (i.e. the protocol is proven increasing, so correct for secrecy), let us examine the second one. Indeed, the message received by the authenticator to authenticatee is . The challenge to be verified by is the nonce . We have:
\!\!\!F(N_{b}^{i},\partial[\overline{N_{b}^{i}}]\{N_{b}^{i}.\{{\color[rgb]{1,0,1}A}.Z\}_{k_{bs}}\}_{k_{bs}}
\!\!\!F(N_{b}^{i},\{N_{b}^{i}.\{{\color[rgb]{1,0,1}A}\}_{k_{bs}}\}_{k_{bs}})
\!\!\!\{{\color[rgb]{1,0,1}A},B,S\}
Then, we can easily see that:
[TABLE]
[TABLE]
[TABLE]
From (IV) and (V) and Theorem 2, we can declare now, and only now, that: The modified version of the Woo-Lam protocol is correct with respect to authentication.
VIII Comparison with similar works
In the witness functions logic, to prove authentication, a protocol must be verified for secrecy first. For that, the upper bound of a witness function bases its calculation on safe identities collected from a piece of message that is fully invariant by opponent in order to deprives this latter from using his capabilities to forge these identities. Besides, in every single sending step of the protocol, the lower bound makes sure that the protocol does not endow the opponent of new rules that could mislead a regular agent by using suspicious messages that ’’look like” a regular one but, in fact, have been gathered from previous sessions. To do so, this bound considers all encryption patterns that might be sources of a final trace and verifies whether or not a suspicious identity could be inseminated in some variable when the protocol is running. If this is the case, the analysis is immediately aborted and no result for the protocol correctness is given with respect to secrecy. This way we treat secrecy leads to an interesting observation: ”If a protocol is correct for secrecy, then any atomic messages arrives to its destination in a safe state”. That means that its evaluation environment, based on a protective key and all the identities beyond, does not contain any suspicious identity. All of them are reliable. It turns out that the authenticator has just to make sure that the identity of the authenticatee is present, witnessing finally the origin of the authenticating message. This is made available by the upper bound that is called, once again, to provide this authentication service, too. In literature, we can point out an interesting work which is similar in some aspects to ours. It is the work of Houmani published in [9, 10, 11, 12]. In this work, she defined two functions to estimate the level of security of atoms in messages called respectively DEK and DEKAN. The DEK function is based on the direct key only whereas DEKAN is based on the direct key and neighbors. The DEK function is very limited in practice. However, the main drawback of the DEKAN function is that it is not variable free. For instance, , where is a variable having an unknown level of security in the context. The fact that a function has outputs with variables sets up a real barrier when comparing two security levels, especially when we have more than one variable in the same message. As a result, very few protocols have been shown correct with respect to secrecy and, as far as we know, no further researches have been published with respect to authentication, very likely because of variables in output. With witness functions, we do not have this problem owing to derivation used in the witness functions’ bounds that eliminate variables in output. Hence, the comparison between security levels is made possible and easier. Several tools have been proposed in the state-of-the-art of cryptographic protocols to verify authentication in security protocols. Among them, we can cite an interesting one: the AVISPA tool [13]. This tool consists of an aggregation of three model checkers and a tree automata verifier. These four components are:
- •
the Constraint-Logic-based Attack Searcher: applies constraint solving to run both protocol falsification and verification for bounded sessions;
- •
the On-the-fly Model-Checker: it carries out a protocol verification by exploring the transition system. It considers both typed and untyped protocol models;
- •
the SAT-based Model-Checker: it uses typed protocols and carries out bounded session verification by calling a SAT solvers to reduce problem input;
- •
the TA4SP: is a tree automata that carries out unbounded protocol verification by estimating the opponent knowledge using rewriting techniques.
The AVISPA tool was successful in finding new attacks, for instance, on the ISO-PK3 protocol and the IKEv2 protocol with digital signatures (a man-in-the-middle attack). However, the main drawback of model checkers remains the state explosion problem that we do not face using our approach. Another interesting tool is the ProVerif one [14, 15]. This latter uses an abstract representation of a protocol by Horn clauses and supports several cryptographic primitives described by rewrite rules or equations. The main limitation of this kind of verifiers is the halting problem where a program could never end. That is why binding sessions becomes usually a must. In our approach, we are not concerned about this problem since our approach is fully static.
IX Conclusion and future work
In this paper, we strongly believe that we are giving a new analytic direction for protocols’ verification against authentication flaws by using our recent finding: the witness functions. In a future work, we will experiment our approach on more protocols in order to know how wide is the range of protocols that could be analyzed with it and how reasonable is the rate of false negatives. A special attention will be paid to protocols that do not run in isolation in order to prevent multi-protocol attacks [16, 17]. Finally, anonymity is one of our immediate targets. In fact, this property seems to be the opposite of authentication in the sense that the link between the sender identity and the secret must be shown broken during the communication to make sure that an opponent cannot reconstruct it. This is a major concern in e-voting protocols, for example. In theory, witness functions should be useful to prove this property by setting sufficient conditions for anonymity.
Appendix: Notations
We denote by the context of verification containing the parameters that affect the analysis of a protocol:
: is a set of messages built from the algebraic signature , where is a set of atomic names (nonces, keys, principals, etc.) and is a set of functions (:: encryption, :: decryption, :: concatenation (denoted by ”.” ), etc.). i.e. . We use to denote the set of all substitution from . We denote by all atomic messages (atoms) in by the set of atomic messages in and by the set of principals including the opponent . We denote by the reverse form of a key and we assume that .
: is the theory that describes the algebraic properties of the functions in by equations (e.g. ).
: is the inference system of the opponent under the theory. Let be a set of messages and a message. means that the opponent can infer from using his capabilities. We extend this notation to traces as follows: means that the opponent can infer from the trace .
: is a function from to , that assigns to any principal a set of atomic messages describing his initial knowledge. We denote by the initial knowledge of the opponent, or simply where the context of verification is obvious.
: is the security lattice used to assign security values to messages. A concrete example of a lattice is that will be used in this paper.
: is a partial function that assigns a value of security (type) to a message in . Let be a set of messages and a single message. We write when
- +
Let be a protocol, we denote by the set of the generalized roles extracted from . A generalized role is an abstraction of the protocol where the emphasis is put on a specific principal and all the unknown messages are replaced by variables. More details about the role-based specification could be found in [18]. We denote by the set of messages generated by , by the set of closed messages (ground terms) generated by substitution in terms in . We denote by (respectively ) the set of received messages (respectively sent messages) by a principal in the role . Conventionally, we use uppercases for sets or sequences and lowercases for single elements. For example denotes a set of messages, a message, a role composed of sequence of steps, a step and the role ending by the step . A valid trace is a ground term obtained by substitution in the generalized roles. We assume that the opponent has the full-control of the net and is able to defeat any operation in except encryption if he does not have the decryption key, as described in the Dolev-Yao model [19].
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] V. Cortier and S. Kremer, “Formal models and techniques for analyzing security protocols: A tutorial,” Foundations and Trends in Programming Languages , vol. 1, no. 3, pp. 151–267, 2014.
- 2[2] J. Fattahi, Analyse des Protocoles Cryptographiques par les Fonctions Témoins . Ph D thesis, Université Laval. Québec. Canada, February 2016.
- 3[3] J. Fattahi, M. Mejri, and E. Pricop, “The theory of witness functions,” in Recent Advances in Systems Safety and Security (E. Pricop and G. Stamatescu, eds.), ch. 1, pp. 1–20, Switzerland: Springer International Publishing (in press), June 2016.
- 4[4] J. Fattahi, M. Mejri, and H. Houmani, “Secrecy by witness functions,” in the 5th Proceedings of the Formal Methods for Security FMS’2014 Workshop co-located with the Petri Nets-2014 Conference, Tunis, Tunisia (V. Cortier and R. Robbana, eds.), pp. 34–52, CEUR, June 2014.
- 5[5] J. Fattahi, M. Mejri, and H. Houmani, “Relaxed Conditions for Secrecy in a Role-Based Specification,” International Journal of Information Security , vol. 1, pp. 33–36, July 2014.
- 6[6] M. Mejri, “Chaotic protocols,” in Computational Science and Its Applications - ICCSA 2004, International Conference, Assisi, Italy, May 14-17, 2004, Proceedings, Part I , pp. 938–948, 2004.
- 7[7] S. A. Shaikh and V. J. Bush, “Analysing the woo-lam protocol using csp and rank functions,” in WOSIS , pp. 3–12, 2005.
- 8[8] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, P.-C. Heám, J. Mantovani, S. Mödersheim, D. von Oheimb, M. Rusinowitch, J. Santiago, M. Turuani, L. Viganò, and L. Vigneron, “The AVISPA Tool for the Automated Validation of Internet Security Protocols and Applications,” in Proceedings of the 17th International Conference on Computer Aided Verification (CAV’05) (K. Etessami and S. K. Rajamani, eds.), vol. 3576 of LNCS , Springer, 2005. Avai
