A review of Proverif as an automatic security protocol verifier

A review of ProVerif as an automatic security
protocol verifier
M. Peters and P. Rogaar
Radboud University, The Netherlands
{mgppeters, p.rogaar}@student.ru.nl
Abstract. In this paper we are interested in the main reasons to use
ProVerif, an automatic verifier for security protocols. We are interested in
how successful it is used in the analyses of real-world protocols. We first
formulate what it means for a verifier to be successful. We then describe
some limitations of ProVerif found in the currently available literature,
which include the use of algebraic properties, like the Diffie-Hellman
key exchange and the eXclusive OR (XOR) operator, in the specification
of security protocols. ProVerif is used to verify security protocols
in some major fields, such as Bluetooth security and electronic voting.
By examining these practical examples we show how researchers have
used ProVerif to verify security properties and we describe the results
obtained. We study comparisons made between ProVerif and Scyther,
YAPA and the AVISPA toolkit on the subjects of efficiency, specificity
and usability.
Keywords: ProVerif, Verifier Comparison, Automatic Verification, Security
Protocols
1 Introduction
“Securing a computer system has traditionally been a battle of wits:
the penetrator tries to find holes, and the designer tries to close them”
– M. Gosser 1
Automatic verification of security protocols is a relatively new field where software
applications (verifiers) are used to prove security properties of protocols.
Verifiers help solve the problem of manually finding flaws in security protocols.
Different verifiers have been designed/developed in the last decades ( e.g. [3] [5]
[17] [33] [35] [37] [39] ). In this paper we review ProVerif, a Prolog-based verifier
[7]. ProVerif claims to use little memory and to implement an efficient algorithm
for proving security properties, like authentication and secrecy [7]. In the face of
these claims we want to know how successful ProVerif is as an automatic verifier
for security protocols. We begin to answer this question by looking at practical
examples of applications of ProVerif to verify real-world protocols. The results
1 Cited from Sharif Network Security Center website - http://nsc.sharif.edu/NSC/

obtained from these practical examples tell us how ProVerif is used in the field
and what problems researchers encountered using the tool. But what about the
limitations of ProVerif itself? What are protocols or parts or properties of protocols
which we might want to model in ProVerif, but are unable to? For instance,
it is difficult to model algebraic properties like XOR [28] and Diffie-Hellman key
exchange [29] in ProVerif. We compare ProVerif to Scyther[17], YAPA[5] and
the AVISPA[3] toolkit, primarily focusing on the efficiency of the verification of
protocols. ProVerif uses a technique called unification to prune the state space
of the protocol. Unification allows ProVerif to assert that some property holds
for a larger part of the state space without examining all the states, effectively
reducing the state space. We think that our review will lead to a better understanding
of the reasons that motivate the use of ProVerif for verifying security
protocols.
Organisation of the paper. In Section 2 we formulate what it means for ProVerif
to be successful. With this definition in mind, we look at practical examples
where ProVerif is used as the verifier in Section 3, to determine the role it plays
in the actual verification of protocols. Section 4 describes limitations found by
other researchers and how these can be resolved. Section 5 summarizes literature
that describes how ProVerif compares to other automatic verifiers. We provide
a conclusion to this paper in Section 6.
2 Description of ProVerif
The protocol verifier ProVerif was developed by Bruno Blanchet [7]. Because
other protocol verifiers already existed before ProVerif 2 , the author claims that
it distinguishes itself from the competition in three ways[7]:
– ProVerif models attacks that an attacker can perform. Such an attack might
consist of multiple concurrent executions of the protocol. ProVerif does not
limit the number of concurrent protocol runs that a modelled attacker may
execute. It therefore is able to find attacks that require any number of concurrent
protocol runs.
– It is fully automatic, i.e. after starting the verifier, it does not need any user
input to complete its task.
– It does not significantly suffer from state space explosion.
Security protocol researchers define protocols with the arrow notation as described
in [1]. When a user wishes to employ any protocol verifier, he takes this
protocol definition in arrow notation and translates it into instructions that are
readable for his verifier. This set of instructions is called the protocol specification.
Afterwards, the user provides the verifier with the specification, and after
some calculations, the verifier announces whether certain assertions about the
protocol were valid.
2 For example NRL ([33]) and Isabelle ([37])

ProVerif uses the concept of a Horn clause 3 as the unit of its specification
language. In this context, a Horn clause is an inference rule about knowledge
of the adversary. An example of such a Horn clause might be “If one has a
ciphertext and the corresponding key, one might also know the plaintext”. A set
of Horn clauses is called a Horn theory. Therefore, one could say that protocol
specifications in ProVerif are Horn theories. The developers of ProVerif created
the possibility to specify the protocol in an alternative language, the applied pi
calculus 4 , which is convenient for people already familiar with this specification
framework.
When a user translates a protocol definition to a ProVerif protocol specification,
he specifies the possible ways an attacker can gather more knowledge. In
ProVerif, this amounts to three different types of declaration:
– The user models initial knowledge of the attacker as a tautology, a logical
statement without conditions. An example of such a clause would be initial
knowledge of the public keys of all participants of the protocol.
– Computational capabilities are modelled in separate clauses. For example, if
the attacker has posession of a (decryption) key and a ciphertext, he may
use it to decrypt the ciphertext if it is encrypted with that key.
– A protocol definition that is written in the arrow notation contains a list of
protocol steps which necessesarily occur in that order. The user adds rules
that describe these steps - one for each step in the protocol definition. To
ensure the proper order of messages is preserved, the application of such a
rule may only occur if the previous steps have already occurred.
The first and the third step in the translation of the protocol definition are
straightforward. Each element in the protocol definition corresponds with a rule
in the protocol specification. However, the second step might require some additional
work, especially if mathematical properties are directly related to the
functionality of the protocol. Examples of such constructs are Diffie-Hellman key
exchange and the use of the XOR-operator. The difficulties and limitations of
the implementation of such constructs is discussed at length in 4.
The user formulates an assertion about the knowledge of the attacker, such as
‘The attacker knows the secret s’. Now, ProVerif will try to construct a sequence
of steps for the attacker to achieve the fact that is stated in the assertion. The
idea behind the algorithm at the heart of ProVerif is that it applies the rules
stated in the protocol specification in an efficient way. However, for the algorithm
to terminate when no attack exists, it is necessary to apply some unification, i.e.
to recognize when two states of protocol execution are effectively ‘the same’. If
we merge two such effectively identical states, we could limit the space we need
to search. The intermediate representation of the states of the protocol run in
ProVerif are simple enough to enable it to effectively unify such states [7].
3
Horn clauses are a concept from Prolog programming and are introduced at length
in [13].
4
Fournet and Abadi describe the applied pi calculus in [23].

The exact capabilities of the attacker are modelled according to the threat
model as proposed by Dolev and Yao, which is known as the Dolev-Yao threat
model [21]. In short, this amounts to the following three assumptions:
– Encryption schemes are perfect - no keys leak from the key infrastructure,
the encrypted messages are unretrievable without the key, everybody has
access to all public keys.
– The parties in the network can perform the encryption and decryption operations
themselves - they do not require an external party to perform these
tasks for them.
– The attacker assumes the role of an ‘active adversary’. More precisely, he
can intercept and read any message that is sent on the network and inject
any message that contains information he knows through previous actions.
When studying the accuracy of a tool for assessing security properties, it is
common to discuss the specificity and the sensitivity 5 of the tool. The specificity
is the extent to which the tool is able to declare that no attacks exist for a
protocol that indeed does not allow attacks, i.e. to prevent false positives. The
sensitivity is the ability of the tool to correctly recognize insecure protocols. In a
security context, it is clear that a high sensitivity is more important than a high
specificity. After all, we would rather have a hundred false positives reported
on our protocol than one potential attack that goes unnoticed. However, the
usability of the tool greatly depends on both the sensitivity and the specificity.
If a tool always reports that an attack exists, it would be prudent, yet not very
useful. In ProVerif, certain assumptions and abstractions are introduced. All of
these, however, only give more power to the attacker, thereby at most raising the
number of false positives, yet never missing an attack that is indeed legitimate.
For a discussion of approximations in ProVerif, see subsection 4.1.
The algorithm behind ProVerif always terminates. This is not guaranteed automatically,
but measures have been taken to assure its termination. The most
notable of these measures is the limitation to the depth of the nesting of terms
in protocol messages. If a message exceeds this limit, the message is replaced by
a new variable. Like the other approximations, this does lessen the sensitivity,
since any attack that exists in the non-limited case still exists in the depthlimited
case.
ProVerif is released under the GNU GPL 6 , which means that the source code
of the program is freely available on the web. Works derived from the source
of ProVerif must also be licensed under the GNU GPL. For such a program,
this can be a great incentive for potential new users, since they can check the
validity of the implementation. Second, it becomes possible to write additions
and extensions for ProVerif.
5
These terms are frequently used in the medical world. A further explanation in that
context can be found at [31].
6
GNU General Public License version 2, see for more details http://www.gnu.org/
licenses/gpl-2.0.html.

3 Practical applications
The verification of protocols with ProVerif is the subject of an extensive set
of literature (e.g.: [2] [4] [8] [9] [11] [25] [36]). ProVerif is used in many different
fields, such as secure file sharing, electronic voting and Bluetooth security. For
each of these fields we will give a summary of how the authors used ProVerif
in their research and try to find their reason to choose ProVerif. The list of
practical examples is not exhaustive but does give an impression of where and
how ProVerif is used. The fields that we discuss in more detail are selected
because of their diversity and the wide impact of the verified protocols in the
modern world.
3.1 Secure file sharing on unstrusted storage
Private personal data, such as family documents and financial data, is stored
in various ways, for example: on a laptop, USB-drives and shared mediums. It
is important to secure this data because of the possibility that an attacker will
use the data for other, possibly malicious, purposes.
Plutus is a file system based on a storage design that does not rely on storage
servers to provide strong secrecy and integrity guarantees [8]. Blanchet and
Chaudhuri have used ProVerif to prove that secrecy is preserved by Plutus. They
were not able to prove this for the integrity property. In this case, violating the
integrity property of the protocol means that an attacker can store data in an
older version while the honest readers think only newer versions are corrupted
by an attacker [8]. The researchers used the analysis of ProVerif to construct a
fix using server-verified writes, which were not present in the original protocol.
Using ProVerif the authors proved the integrity property for the protocol after
the fix and was also able to prove a strong integrity property, which stated that
data read from the server was not only written by an authorized party, but also
of the required freshness.
The attacks found by ProVerif were not present in the fixed version of the
authors, thereby preserving secrecy and restoring integrity in Plutus. We couldn’t
find explicit reasons for choosing ProVerif to verify Plutus, but the authors did
state that using the Dolev-Yao threat model allowed them to automate the proofs
more easily than using the computational model, which they report to be more
concrete [8].
3.2 Electronic voting
Electronic voting is a suitable alternative for regular paper-based voting [10]. It
enables citizens in a democracy to elect their representatives by voting electronically.
Verifying the protocols used by electronic voting machines is important,
because the integrity of the election process is fundamental to the integrity of
democracy itself [26]. The influence of attackers that are able to significantly

alter the results of an election is great, so the protocols used must be as secure
as possible. Many researchers have found problems with currently used protocols
by electronic voting machines (e.g.: [22] [26] [38]).
Automatic protocol verifiers can be used to verify the protocols used in electronic
voting devices. To our knowledge, ProVerif has been used to verify two
electronic voting protocols [4][27]. Ryan and Kremer were able to prove the fairness
and eligibility properties of the FOO 92 [10] protocol. They were unable to
prove the privacy property of the protocol, because ProVerif’s ability to prove
observational equivalence between processes was not complete at the time of
their research 7 [27]. They proved it manually without ProVerif. Their choise of
ProVerif seems to be based on a suggestion from Bruno Blanchet himself [27].
Another group used ProVerif to verify the Juels, Catalano and Jakobsson protocol,
which is the basis for the development of many modern election schemes
for remote voting[4]. They suggest a general approach for verifying voting protocols
and were able to prove the vote-privacy property but they encountered
problems similar to those in [27]: They could not complete the proof without
some human guidance to the verification process.
3.3 Bluetooth security
Bluetooth is becoming increasingly ubiquitous and is currently integrated in
more than one billion devices worldwide 8 . For all these devices to send data
over a secure connection, the Bluetooth 2.0 specification 9 describes a protocol,
called Device Pairing, where two devices have to agree on a symmetrical key. In
2007 the Bluetooth specification was updated to version 2.1 which requires the
Simple Pairing protocol for communication between Bluetooth 2.1 devices, but
is backwards compatible with Device Pairing for older devices. We now look at
how ProVerif is used to analyze these protocols.
Device pairing in Bluetooth. The Device Pairing protocol used in the Bluetooth
2.0 specification has shown to be vulnerable to an attacker that impersonates a
Bluetooth device after eavesdropping on a successful pairing session[24] and was
proven by the use of ProVerif [11]. The weakness of the Device Pairing protocol
is the (guessable) humanly memorable secret key. All that an attacker needs to
know is the secret key to be able to impersonate a device [11]. ProVerif is used
to show that the observational equivalence does not hold for Bluetooth device
pairing [11]. This means an attacker can learn information from the messages
communicated.
7 Blanchet and Fournet have since published [9]. Blanchet added the mentioned func-
tionality to ProVerif.
8 Bluetooth exceeds one billion devices, see http://www.bluetooth.com/Bluetooth/
Press/SIG/BLUETOOTH\ WIRELESS\ TECHNOLOGY\ SURPASSES\ ONE\ BILLION\
DEVICES.htm
9 Bluetooth 2.0 specification, see for more information: http://www.bluetooth.com/
NR/rdonlyres/1F6469BA-6AE7-42B6-B5A1-65148B9DB238/840/Core v200 EDR.zip

Bluetooth 2.1. In Bluetooth 2.1, Simple Pairing has four modes of operation
based on the hardware capabilities of the device: Just Works, Numeric Comparison,
Passkey Entry and Out of Band. Because of a known attack on the Just
Works and Passkey Entry operating modes, Nilsson, Larson and Erland have
developed a protocol which is not vulnerable to the Man In The Middle-attack
anymore[36]. They used ProVerif to prove the new scheme for authentication,
named ACDHEKE, and have shown that the attack is no longer possible for the
Just Works and Passkey Entry operating modes.
For the Numeric Comparison operating mode of Simple Pairing, Chang and
Shmatikov have employed ProVerif to show that strong authentication fails for
the protocol. In strong authentication with Simple Pairing, the user must confirm
the hash, visible on communicating devices A and B, generated from the initial
keys. ProVerif proved that strong authentication does not hold when a device A
is executing multiple sessions with another device B[11]. The hash value that is
shown to the user may not be the hash value of the session the user thinks he is
accepting, thereby accepting the wrong session as successful.
Bluetooth 3.0 In April, 2009 the Bluetooth Special Interest Group adopted the
Bluetooth 3.0 specification. Bluetooth 3.0 remains backwards compatible with
previous versions, so it is susceptible to the same attacks when used to communicate
with devices using older versions of Bluetooth. This means that the
analysis made with ProVerif is still relevant for some time while the market is
adopting Bluetooth 3.0.
We identified two main reasons why Chang and Shmatikov used ProVerif for
their analysis of the Bluetooth. First, ProVerif supports the verification of weak
secrecy (which was useful because of the low-entropy secrets used in Bluetooth)
[11]. Second, they used correspondence assertions for modeling authentication
[11].
4 Limitations of ProVerif
In the previous chapter, we have considered applications of ProVerif, which
brings up the question what the limitations of ProVerif are: what are protocols
or parts or properties of protocols which we might want to model in ProVerif, but
are unable to? About which types of problem is ProVerif unable to yield a (valid)
verdict as to whether the required assertions are satisfied? We will describe
the limitations we have encountered in the literature and discuss whether the
problems can be easily solved, or seem to be inherent to ProVerif.
4.1 Approximations in ProVerif
The developers of ProVerif have made some approximations in their formalization
of security protocols[7]. According to them, these approximations are key
to limiting the number of runs of protocols. Unsurprisingly, these could theoretically
be of influence to the sensitivity and specificity of ProVerif.

First, they have not built in a source of randomness with which to generate
nonces. Instead they model nonces as a function of the current environment,
i.e. the protocol execution up until the point of nonce generation. Therefore, two
nonces are equal if and only if the entire protocol execution, including adversarial
behaviour, is exactly the same in both cases. This gives the adversary slightly
more power, which only lowers the specificity and not the sensitivity of ProVerif.
Furthermore, no practical cases are known (according to [7]) where this results
in false positives.
Second, ProVerif does not limit repetition of protocol rules. Imagine a protocol
run where a party uses one of the rules in the protocol definition multiple times,
without this being allowed in the definition. Normally, the other party will only
respond to the first instance of the protocol rule as specified. He will not respond
to the other instances because he is no longer awaiting a message that is
formatted thus. ProVerif on the other hand does not implement this behaviour,
and instead allows the parties to use each rule any number of times. However,
like the previous approximation, this can only result in more false positives, but
has no influence on the sensitivity of the protocol.
4.2 XOR
Multiple protocols use the logical XOR-operator, often denoted by ⊕, as a
part of their definition. For example, the one-time pad, a textbook protocol that
can be found in any cryptography textbook such as [34], relies heavily on the
mathematical properties of the XOR-operator. Therefore, it is a requirement of a
general protocol verifier that it can be applied to questions about such protocols.
ProVerif, however, is not concerned with the algebraic structure of the primitives
used in protocols, buth rather with their general structure, thus being unable to
directly answer questions about the protocols that use, for example, the XORoperator.[28]
Küsters and Truderung [28] considered this problem and have described a solution
which requires the user to formulate his protocol in a special form which
they call ⊕-linear. A term in a Horn theory is called ⊕-linear if for every subterm
of the form t ⊕ t ′ it is true that either t or t ′ does not contain variables. A Horn
theory itself is called ⊕-linear if all terms in it are ⊕-linear, with the possible
exception of the rule that enables the intruder to perform the XOR-operation.
The authors of the paper have provided an algorithm with which to rewrite a ⊕linear
Horn theory to a Horn theory that does not contain any XOR operations.
This XOR-free Horn theory can then be presented to ProVerif for verification.
The correctness of the algorithm provided by the authors implies that ProVerif
will find all attacks it would have found in the old specification of the protocol,
combined with possible new attacks that are the result of the algebraic structure
of the XOR operation. The authors do not discuss the complexity of their algorithm
in [28]. However, when they refer to this work in [29], they posit that their
algorithm for XOR rewriting ‘suffers from an exponential blow-up’. The authors

have also published a tool, XOR-ProVerif, to perform the mentioned translation
automatically.
4.3 Diffie-Hellman
Another primitive that is often employed in cryptographic protocols is Diffie-
Hellman key exchange[20]. In its basic form, the method enables two participants
in a protocol run to construct a shared key without any previously shared secret.
This key can be used in subsequent communications between these parties.
However, the nature of the protocol depends on the nature of (discrete) exponentiation.
For example, the method works because exponentiation in a group
is commutative (i.e. a xy = a yx for any a, x and y). A protocol verifier such as
ProVerif does not enable a researcher to explicitly describe the algebraic properties
used in the protocols that he checks. Therefore, as was also described in
section 4.2 for the case of the XOR, it is difficult to directly assert properties of
a protocol that uses such primitives.[29]
However, this problem was resolved recently, as a method was constructed by
Küsters and Truderung in [29] to rewrite protocols using Diffie-Hellman exponentiation
to a protocol definition without such primitives. This definition can
in turn be translated to a specification consisting of Horn clauses. ProVerif will
then be able to analyze this rewritten specification. The method that is discussed
is able to implement both the commutativity of exponentiation and the
calculation of the multiplicative inverse of an element (i.e. exponentiation with
exponent −1). More specifically, a specific class of terms is discussed, called
exponent-ground terms. These terms have a constraint on the nature of the exponents
that occur in them: these may not contain any variables or further
exponentiations. The authors argue that this does not limit the number of protocols
employing Diffie-Hellman that can be analyzed. They proceed by proving
the rewritability of Horn theories that consist of only exponent-ground terms
to Horn theories that contain no exponentiation at all. They also include an
explicit rewriting method and demonstrate it in an example. The authors have
also published a tool, DH-ProVerif, to perform the mentioned translation automatically.
Küsters and Truderung claim that their method is efficient, because
of the polynomial running time of their algorithm. The algorithms presented in
earlier work are sometimes less efficient, and sometimes focus on other algebraic
properties of the Diffie-Hellman exponentiation. For example, the authors of [12]
provide a solution that is not known to have polynomial running time, though
it handles a broader range of algebraic properties.
4.4 Randomness
In most modern-day protocols, some randomness is used in asymmetric encryption.
If no randomness would be used, an attacker could upon receipt of a
ciphertext easily encrypt a message with the corresponding puplic key and then

check for equality of the ciphertexts to infer equality of the plaintexts. This potential
problem is easily solved by appending a fixed-length random string at the
end of the plaintext before encryption. After decryption, the recipient removes
the appended random bytes and has the original plaintext. When studying protocols
that employ such techniques, some form of labeling is used to explicitly
denote the randomness used in the encryption - for example, when encrypting
plaintext m together with randomness l using key k, we could denote this with
the label in a superscript:
{m} l k.
However, according to Cortier et al. ([15]), none of the currently popular tools 10
offer capabilities for reasoning in protocol models using labels. Instead of extending
the underlying framework of a tool to encompass labels, they proceed
to formulate a theorem that makes such extensions unnecessary. For a large
class of protocols, validity of the protocol without the labels (which is verifiable
in an automatic verifier), implies validity of the protocol with the labels (i.e.
with randomness). This large class of protocols includes protocols using currently
standard formulations for secrecy and authenticity. Moreover, they have
constructed a module for AVISPA that checks whether a protocol that uses randomness
fulfills the requirements of the theorem, and proceeds to perform the
translation to a nonlabelled protocol which can in turn be verified using the
original AVISPA mechanisms. Such a module might also be constructable for
ProVerif, which would resolve this limitation in the protocol verification model.
5 Comparison with other verifiers
ProVerif is a state-of-the-art automatic protocol verifier, but is not the only verifier
dedicated to security protocols. Other verifiers include Athena[39], AVISPA[3],
Casper [32], Isabelle[37], NRL[33], Scyther[17] and YAPA[5]. These verifiers are
all based on the Dolev-Yao threat model [21].
Our main goal is to find proof for the efficiency claims made in the original
version of ProVerif. We briefly compare the soundness of the verifiers by looking
at the attack traces they provide to the user. Attack traces are detailed traces
of how the verifier constructed the attack.
ProVerif uses Prolog rules and implements a solving algorithm that is efficient
because of overapproximations [7]. Other verifiers like Interrogator[35] and NRL
have implemented similar formalisms. Relative to these verifiers, ProVerif uses a
more abstract representation of protocols. For example, it forgets the number of
times a message appears and only remembers that it has appeared. This enables
a faster and simpler analysis of a protocol [7].
10 They mention ProVerif, Casper[32], Athena[39] and AVISPA[3].

Most existing protocol verifiers based on model checking suffer from the problem
of state space explosion [7]. The solution generally implemented is limiting the
number of runs of the protocol. The problem is that when an attack exists,
which need more runs of the protocol to be discovered, it will not be found by
these verifiers [7]. ProVerif solves the state space explosion by using unification
techniques [7] (see Section 2).
5.1 Efficiency
We have found a few studies that compare verifiers based on efficiency, but
little research has been done on this subject. Cremers and Lafourcade compared
the efficiency of AVISPA (which consists of the verifiers CL-Atse, OFMC, Sat-
MC and TA4SP), Scyther and ProVerif. They found that, in general, ProVerif
shows the best time performance due to the abstract representation of nonces
and that it quickly provides the user with an analysis for an unbounded number
of runs [18]. The second fastest verifier Scyther is interesting, because it doesn’t
use approximation methods like ProVerif to achieve a fast full verification of the
security protocol. Scyther and ProVerif both achieved a full verification within
0.001 seconds for the Needham-Schroeder and Needham-Schroeder-Lowe protocols
[18]. In the case of Needham-Schroeder, ProVerif found three real attacks
on the protocol in the same time that Scyther only found two attacks.
Proving secrecy . When comparing the results for various verifiers that are presented
in [18], we note that for proving secrecy, Scyther, TA4SP and ProVerif
provide near-zero timings. The verifiers Sat-MC, OFMC and CL-Atse follow an
exponential curve relative to the number of runs. For more complex protocols
like TLS[19] and EKE[6] the results differ slightly. Scyther also follows an exponential
time curve for this particular protocol but is still much faster then
Sat-MC, OFMC and CL-Atse [18]. ProVerif is constant in time (around 0.5 seconds
per run). Another protocol that is used for the comparison is TLS. Here,
ProVerif, Scyther and TA4SP show to be relatively constant and differ less than
0.1 seconds from each other per run.
Proving authentication . Where ProVerif was the fastest tool for proving secrecy
properties of protocols, the results differ slightly for the authentication properties.
In general, ProVerif and Scyther are again the fastest verifiers for the
Needham-Schroeder and TLS protocols. For the EKE protocol, ProVerif was
the slowest of the verifiers considered [18]. The authors state that this is because
ProVerif doesn’t support equational theories very well (like XOR, discussed in
Section 4.2) [18].
Static equivalences . Another study compares the efficiency of YAPA to ProVerif.
YAPA is a verifier which provides a generic procedure for deducibility and static
equivalences. Deducibility is the notion that some piece of data is retrievable
from a finite set of messages. If the attacker cannot distinguish between two
sequences of messages, the messages are said to be statically equivalent [14].

When static equivalence holds for some sequence of messages then it is not
possible for the attacker to find an underlying pattern. For example, guessing
attacks are possible if the attacker can detect some pattern in the data.
The study, comparing YAPA to ProVerif, concludes that YAPA is one or two
orders of magnitude faster than ProVerif in checking static equivalences[5]. This
can be explained by the fact that YAPA is dedicated to proving static equivalences
and that it is no surprise that the more general tool ProVerif is slower[5].
The authors state that the more complex preprocessing of the rewrite system in
ProVerif is one of the reasons why it is slower than YAPA [5].
A comparison between the efficiency of Athena and other verifiers was not
possible due to fact that Athena is not publicly available 11 . Scyther improves on
Athena [17]. We believe that Athena’s performance is not faster than the results
from Scyther but we can’t know for sure without concrete experimental results.
Efficiency of ProVerif with extensions . In Section 4 we have described how
ProVerif was extended to be able to transform a protocol specification using
XOR and Diffie-Hellman to an input file for analysis with ProVerif.
To compare ProVerif with CL-Atse and OFMC, [30] used XOR-ProVerif[28]
and DH-ProVerif[29] to translate the input files, with XOR or Diffie-Hellman, to
the applied pi calculus input files for ProVerif. They concluded that in general
the same attacks were found using OFMC, CL-Atse or ProVerif (XOR-ProVerif
or DH-ProVerif). For most of the protocols, ProVerif completed the verification
within one second but the AVISPA tools did so within less than 0.01 seconds.
ProVerif was slower because of the translation of the input files [30]. The time
required for translation depends on the protocol being verified, but often it is
a small part of the total running time (e.g. Salary sum protocol: 1 second for
translation + 11 seconds for the running time, Bull’s authentication protocol: 5
seconds for translation + 12 seconds for the running time).
5.2 Specificity
Attack traces provide feedback to the user of a verifier and they enable the user
to manually check the attack. This feedback can help the user fix the security
flaw in the protocol being verified. Both ProVerif and Scyther show attack traces
when an attack is found [18]. Because of its use of approximations, it is possible
that ProVerif shows an false attack, but this is rare for current widely used
security protocols [7]. Because Scyther uses no approximations, it follows that
attacks that are found with Scyther are actual attacks on the protocol[17]. For
the verifier TA4SP (part of the AVISPA toolkit) there is no way to determine
if an attack is true or false. Like ProVerif, TA4SP uses approximations, but the
user cannot manually verify the attack because TA4SP doesn’t generate traces
of an attack [18].
11 This statement is made in [18] and in [16]. However, the software seems to be available
at http://www.ece.cmu.edu/ ∼ dawnsong/athena/.

5.3 Usability
To our knowledge, no comparative study has been done in the area of the
usability of automatic security protocol verifiers. We decided to compare the
documentation (user manuals, example code) provided by the authors on the
website. With good documentation available, users can start using the verifier
more easily by exploring the examples and manuals provided.
ProVerif (v1.82) 12 provides a folder containing examples for both input languages
(Horn clauses and pi calculus). There is also an folder containing a manual
describing the input and output formats and a manual on how to upgrade
from an older version of ProVerif.
The website 13 of the AVISPA project provides a lot of input examples of existing
protocols for the HLPSL language in the form of the AVISPA Library. They also
provide a list of user-contributed protocol specifications. The authors provide
installation manuals for each of the tools in the toolkit, a general user manual
and a beginners guide to the HLPSL language.
Scyther (1.0-beta7) 14 . Scyther is relatively new and not much documentation
is available besides a short installation file. The author does provide an exercise
set for students with six exercises in it.
We could not find much information on the process of modeling the protocol
into the input language of a verifier. We did find remarks of researchers who had
difficulty modeling protocols in ProVerif, relative to five other verifiers, even
though they had good knowledge of the protocols [18].
Because ProVerif provides the essential information, such as: an installation
guide, a description of input formats and protocol examples, we think that
ProVerif has good documentation. The lack of information for Scyther makes
it difficult for a beginner to start using the automatic security protocol verifier.
We think that the use of user-contributed protocol specifications, like the
AVISPA Project, can get more people to use ProVerif. For example, beginners
can learn from the examples and comments given by others.
6 Conclusion
In this paper, we have performed an analysis of some factors that might influence
the usefulness and popularity of the automatic protocol verifier ProVerif.
After discussing the particular aspects of ProVerif, we looked at some practical
applications of ProVerif for protocol verification. We have surveyed the literature
on limitations on ProVerif, and we briefly summarized some of the work on
comparison of protocol verifiers.
12 ProVerif v.1.82. Download: http://www.proverif.ens.fr
13 AVISPA Project. Download: http://www.avispa-project.org
14 Scyther 1.0-beta7. Download: http://people.inf.ethz.ch/cremersc/scyther/
index.html

When studying ProVerif, we have found that the verifier has several desirable
properties for protocol verification. First, it can handle an unbounded number
of protocol runs. Second, it uses a fairly extensive threat model, the Dolev-Yao
model, which means it gives a lot of power to the attacker. The translation from
a protocol definition to a protocol specification seems to be difficult at times
but mostly straightforward, and two distinct languages, the applied pi calculus
and Horn clauses, are provided as specification languages. When analyzing the
protocol specification, several assumptions are made which might lead to finding
false attacks. However, all these assumptions do not influence the ability to find
attacks in unsafe protocols (i.e. the sensitivity), therefore, if an attack exists,
ProVerif will find one.
The application of Proverif to real-life protocols is very common in academic
environments, as testified by the extensive collection of literature in which is
it used. In using the verifier, researchers note that they have more difficulty
modeling some properties and requirements of protocols in ProVerif compared
to other protocol verifiers. ProVerif seems to be otherwise successful in finding
new attacks, and even sometimes finds attacks in protocols that have already
been analyzed with other protocol verifiers.
Currently, one of the major challenges for any protocol verifier is succesfully
modelling the algebraic properties of cryptographic primitives such as Diffie-
Hellman encryption or the XOR operation. At first glance, ProVerif has difficulties
to effectively represent protocols that contain such primitives. However,
we found literature that describes techniques for rewriting protocol specifications
so that they can represent the algebraic properties involved as well. Tools
have been developed and included with the ProVerif distribution package that
perform such rewriting tasks automatically. Since ProVerif is open source and
licensed under the GNU GPL, such tools could also be merged with ProVerif
itself, though performance considerations might dictate otherwise.
The developers of ProVerif have made several claims about the verifier, such
as its speed and memory usage. Studies that compare ProVerif to other verifiers
indeed show that ProVerif performs quite well in these aspects. No conclusive
studies that compare the usability for researchers of such tools, but the remarks
by researchers about the translation of protocol definitions to specifications seem
to indicate that ProVerif is somewhat lacking in this direction.
Summing up, ProVerif seems to be a widely applicable tool with a good track
record. On the other side, some other verifiers seem to surpass ProVerif on certain
points. However, if you require a tool that can quickly verify a protocol in one
of the more general threat models, ProVerif is still a very good choice.

References
1. M. Abadi. Security Protocols and their Properties. In Foundations of Secure
Computation, NATO Science Series, pages 39–60. IOS Press, 2000.
2. M. Abadi, B. Blanchet, and C. Fournet. Just fast keying in the pi calculus. ACM
Transactions on Information and System Security, 10(3):9, 2007.
3. A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, Hankes
P. Drielsma, P. C. Heám, O. Kouchnarenko, 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. Computer Aided Verification, pages 281–285, 2005.
4. M. Backes, C. Hritcu, and M. Maffei. Automated Verification of Remote Electronic
Voting Protocols in the Applied Pi-Calculus. In CSF ’08: Proceedings of
the 2008 21st IEEE Computer Security Foundations Symposium, pages 195–209,
Washington, 2008. IEEE.
5. M. Baudet, V. Cortier, and S. Delaune. YAPA: A generic tool for computing
intruder knowledge. In Rewriting Techniques and Applications, volume 5595 of
Lecture Notes in Computer Science, pages 148–163. Springer Berlin / Heidelberg,
2009.
6. S. M. Bellovin and M. Merritt. Encrypted Key Exchange: Password-Based Protocols
Secure Against Dictionary Attacks. In IEEE Symposium on Security and
Privacy, pages 72–84, 1992.
7. B. Blanchet. An Efficient Cryptographic Protocol Verifier Based on Prolog Rules.
In CSFW ’01: Proceedings of the 14th IEEE workshop on Computer Security Foundations,
page 82, Washington, 2001. IEEE.
8. B. Blanchet and A. Chaudhuri. Automated Formal Analysis of a Protocol for
Secure File Sharing on Untrusted Storage. In Proceedings of the 29th IEEE Symposium
on Security and Privacy (S&P’08), pages 417–431. IEEE, 2008.
9. B. Blanchet and C. Fournet. Automated Verification of Selected Equivalences for
Security Protocols. In LICS ’05: Proceedings of the 20th Annual IEEE Symposium
on Logic in Computer Science, pages 331–340, Washington, 2005. IEEE.
10. O. Cetinkaya and A. Doganaksoy. A Practical Verifiable e-Voting Protocol for
Large Scale Elections over a Network. In ARES ’07: Proceedings of the The Second
International Conference on Availability, Reliability and Security, pages 432–442,
Washington, 2007. IEEE.
11. R. Chang and V. Shmatikov. Formal Analysis of Authentication in Bluetooth
Device Pairing. In 1st International Symposium on Leveraging Applications of
Formal Methods (ISOLA04), 2007.
12. Y. Chevalier, R. Küsters, M. Rusinowitch, and M. Turuani. Deciding the Security of
Protocols with Diffie-Hellman Exponentiation and Products in Exponents. In FST
TCS 2003: Foundations of Software Technology and Theoretical Computer Science,
volume 2914 of Lecture Notes in Computer Science, pages 124–135. Springer Berlin
/ Heidelberg, 2003.
13. W. F. Clocksin and C. S. Mellish. Programming in Prolog. Springer-Verlag, New
York, NY, USA, 1987.
14. H. Comon-Lundh and V. Cortier. Computational soundness of observational equivalence.
In CCS ’08: Proceedings of the 15th ACM conference on Computer and
communications security, pages 109–118, New York, 2008. ACM.
15. V. Cortier, H. Hördegen, and B. Warinschi. Explicit randomness is not necessary
when modeling probabilistic encryption. Electronic Notes in Theoretical Computer

Science, 186:49 – 65, 2007. Proceedings of the First Workshop in Information and
Computer Security (ICS 2006).
16. C.J.F. Cremers. Scyther: Semantics and Verification of Security Protocols. PhD
thesis, Technische Universiteit Eindhoven, 2006.
17. C.J.F. Cremers. The Scyther Tool: Verification, Falsification, and Analysis of Security
Protocols. In Computer Aided Verification, 20th International Conference,
CAV 2008, Princeton, USA, Proc., volume 5123/2008 of Lecture Notes in Computer
Science, pages 414–418. Springer, 2008.
18. C.J.F. Cremers, P. Lafourcade, and P. Nadeau. Comparing State Spaces in Automatic
Protocol Analysis. In Formal to Practical Security, volume 5458/2009 of
Lecture Notes in Computer Science, pages 70–94. Springer Berlin / Heidelberg,
2009.
19. T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version
1.2. RFC 5246 (Proposed Standard), August 2008.
20. W. Diffie and M. E. Hellman. New directions in cryptography. IEEE Transactions
on Information Theory, 22(6):644–654, 1976.
21. D. Dolev and A. C. Yao. On the security of public key protocols. Foundations of
Computer Science, Annual IEEE Symposium on, 0:350–357, 1981.
22. A. J. Feldman, J. A. Halderman, and E. W. Felten. Security analysis of the diebold
AccuVote-TS voting machine. In EVT’07: Proceedings of the USENIX Workshop
on Accurate Electronic Voting Technology, page 2, Berkeley, 2007. USENIX Association.
23. C. Fournet and M. Abadi. Hiding names: Private authentication in the applied
pi calculus. In Software Security - Theories and Systems, volume 2609 of Lecture
Notes in Computer Science, pages 317–338. Springer-Verlag, 2003.
24. M. Jakobsson and S. Wetzel. Security Weaknesses in Bluetooth. In CT-RSA
2001: Proceedings of the 2001 Conference on Topics in Cryptology, pages 176–191,
London, 2001. Springer-Verlag.
25. H. Khurana and H. Hahm. Certified mailing lists. In ASIACCS ’06: Proceedings of
the 2006 ACM Symposium on Information, computer and communications security,
pages 46–58, New York, 2006. ACM.
26. T. Kohno and A. Stubblefield. Analysis of an electronic voting system. In IEEE
Symposium on Security and Privacy, pages 27–40, 2004.
27. S. Kremer and M. Ryan. Analysis of an Electronic Voting Protocol in the Applied
Pi Calculus. In In Proc. 14th European Symposium On Programming (ESOP05),
volume 3444 of LNCS, pages 186–200. Springer, 2005.
28. R. Küsters and T. Truderung. Reducing protocol analysis with XOR to the XORfree
case in the Horn theory based approach. In CCS ’08: Proceedings of the 15th
ACM conference on Computer and communications security, pages 129–138, New
York, 2008. ACM.
29. R. Küsters and T. Truderung. Using ProVerif to Analyze Protocols with Diffie-
Hellman Exponentiation. Computer Security Foundations Symposium, IEEE,
0:157–171, 2009.
30. P. Lafourcade, V. Terrade, and S. Vigier. Comparison of cryptographic verification
tools dealing with algebraic properties. In Pierpaolo Degano Joshua Guttman,
editor, 6th International Workshop on Formal Aspects in Security and Trust,
(FAST’09), Eindhoven, nov 2009.
31. T. Loong. Understanding sensitivity and specificity with the right side of the brain.
BMJ, 327(7417):716–719, 2003. http://www.bmj.com.
32. G. Lowe. Casper: a compiler for the analysis of security protocols. J. Comput.
Secur., 6(1-2):53–84, 1998.

33. C. Meadows. A Model of Computation for the NRL Protocol Analyzer. In Proceedings
of the 7th Computer Security Foundations Workshop, pages 84–89, Los
Alamitos, 1994. IEEE.
34. A. J. Menezes, S. A. Vanstone, and P. C. Van Oorschot. Handbook of Applied
Cryptography. CRC Press, Inc., Boca Raton, 1996.
35. J. K. Millen, S. C. Clark, and S. B. Freedman. The Interrogator: Protocol Security
Analysis. IEEE Trans. Software Eng., 13(2):274–288, 1987.
36. D. K. Nilsson, U. E. Larson, and E. Jonsson. Auxiliary channel Diffie-Hellman
encrypted key-exchange authentication. In QShine ’08: Proceedings of the 5th International
ICST Conference on Heterogeneous Networking for Quality, Reliability,
Security and Robustness, pages 1–8, Brussel, 2008. ICST.
37. L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal
of computer security, 6(1-2):85–128, 1998.
38. A. D. Rubin. Security considerations for remote electronic voting. Commun. ACM,
45(12):39–44, 2002.
39. D. Song. Athena: a New Efficient Automatic Checker for Security Protocol Analysis.
Computer Security Foundations Workshop, IEEE, 0:192, 1999.