A review of Proverif as an automatic security protocol verifier
A review of Proverif as an automatic security protocol verifier
A review of Proverif as an automatic security protocol verifier
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
A <strong>review</strong> <strong>of</strong> ProVerif <strong>as</strong> <strong>an</strong> <strong>automatic</strong> <strong>security</strong><br />
<strong>protocol</strong> <strong>verifier</strong><br />
M. Peters <strong>an</strong>d P. Rogaar<br />
Radboud University, The Netherl<strong>an</strong>ds<br />
{mgppeters, p.rogaar}@student.ru.nl<br />
Abstract. In this paper we are interested in the main re<strong>as</strong>ons to use<br />
ProVerif, <strong>an</strong> <strong>automatic</strong> <strong>verifier</strong> for <strong>security</strong> <strong>protocol</strong>s. We are interested in<br />
how successful it is used in the <strong>an</strong>alyses <strong>of</strong> real-world <strong>protocol</strong>s. We first<br />
formulate what it me<strong>an</strong>s for a <strong>verifier</strong> to be successful. We then describe<br />
some limitations <strong>of</strong> ProVerif found in the currently available literature,<br />
which include the use <strong>of</strong> algebraic properties, like the Diffie-Hellm<strong>an</strong><br />
key exch<strong>an</strong>ge <strong>an</strong>d the eXclusive OR (XOR) operator, in the specification<br />
<strong>of</strong> <strong>security</strong> <strong>protocol</strong>s. ProVerif is used to verify <strong>security</strong> <strong>protocol</strong>s<br />
in some major fields, such <strong>as</strong> Bluetooth <strong>security</strong> <strong>an</strong>d electronic voting.<br />
By examining these practical examples we show how researchers have<br />
used ProVerif to verify <strong>security</strong> properties <strong>an</strong>d we describe the results<br />
obtained. We study comparisons made between ProVerif <strong>an</strong>d Scyther,<br />
YAPA <strong>an</strong>d the AVISPA toolkit on the subjects <strong>of</strong> efficiency, specificity<br />
<strong>an</strong>d usability.<br />
Keywords: ProVerif, Verifier Comparison, Automatic Verification, Security<br />
Protocols<br />
1 Introduction<br />
“Securing a computer system h<strong>as</strong> traditionally been a battle <strong>of</strong> wits:<br />
the penetrator tries to find holes, <strong>an</strong>d the designer tries to close them”<br />
– M. Gosser 1<br />
Automatic verification <strong>of</strong> <strong>security</strong> <strong>protocol</strong>s is a relatively new field where s<strong>of</strong>tware<br />
applications (<strong>verifier</strong>s) are used to prove <strong>security</strong> properties <strong>of</strong> <strong>protocol</strong>s.<br />
Verifiers help solve the problem <strong>of</strong> m<strong>an</strong>ually finding flaws in <strong>security</strong> <strong>protocol</strong>s.<br />
Different <strong>verifier</strong>s have been designed/developed in the l<strong>as</strong>t decades ( e.g. [3] [5]<br />
[17] [33] [35] [37] [39] ). In this paper we <strong>review</strong> ProVerif, a Prolog-b<strong>as</strong>ed <strong>verifier</strong><br />
[7]. ProVerif claims to use little memory <strong>an</strong>d to implement <strong>an</strong> efficient algorithm<br />
for proving <strong>security</strong> properties, like authentication <strong>an</strong>d secrecy [7]. In the face <strong>of</strong><br />
these claims we w<strong>an</strong>t to know how successful ProVerif is <strong>as</strong> <strong>an</strong> <strong>automatic</strong> <strong>verifier</strong><br />
for <strong>security</strong> <strong>protocol</strong>s. We begin to <strong>an</strong>swer this question by looking at practical<br />
examples <strong>of</strong> applications <strong>of</strong> ProVerif to verify real-world <strong>protocol</strong>s. The results<br />
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<br />
<strong>an</strong>d what problems researchers encountered using the tool. But what about the<br />
limitations <strong>of</strong> ProVerif itself? What are <strong>protocol</strong>s or parts or properties <strong>of</strong> <strong>protocol</strong>s<br />
which we might w<strong>an</strong>t to model in ProVerif, but are unable to? For inst<strong>an</strong>ce,<br />
it is difficult to model algebraic properties like XOR [28] <strong>an</strong>d Diffie-Hellm<strong>an</strong> key<br />
exch<strong>an</strong>ge [29] in ProVerif. We compare ProVerif to Scyther[17], YAPA[5] <strong>an</strong>d<br />
the AVISPA[3] toolkit, primarily focusing on the efficiency <strong>of</strong> the verification <strong>of</strong><br />
<strong>protocol</strong>s. ProVerif uses a technique called unification to prune the state space<br />
<strong>of</strong> the <strong>protocol</strong>. Unification allows ProVerif to <strong>as</strong>sert that some property holds<br />
for a larger part <strong>of</strong> the state space without examining all the states, effectively<br />
reducing the state space. We think that our <strong>review</strong> will lead to a better underst<strong>an</strong>ding<br />
<strong>of</strong> the re<strong>as</strong>ons that motivate the use <strong>of</strong> ProVerif for verifying <strong>security</strong><br />
<strong>protocol</strong>s.<br />
Org<strong>an</strong>isation <strong>of</strong> the paper. In Section 2 we formulate what it me<strong>an</strong>s for ProVerif<br />
to be successful. With this definition in mind, we look at practical examples<br />
where ProVerif is used <strong>as</strong> the <strong>verifier</strong> in Section 3, to determine the role it plays<br />
in the actual verification <strong>of</strong> <strong>protocol</strong>s. Section 4 describes limitations found by<br />
other researchers <strong>an</strong>d how these c<strong>an</strong> be resolved. Section 5 summarizes literature<br />
that describes how ProVerif compares to other <strong>automatic</strong> <strong>verifier</strong>s. We provide<br />
a conclusion to this paper in Section 6.<br />
2 Description <strong>of</strong> ProVerif<br />
The <strong>protocol</strong> <strong>verifier</strong> ProVerif w<strong>as</strong> developed by Bruno Bl<strong>an</strong>chet [7]. Because<br />
other <strong>protocol</strong> <strong>verifier</strong>s already existed before ProVerif 2 , the author claims that<br />
it distinguishes itself from the competition in three ways[7]:<br />
– ProVerif models attacks that <strong>an</strong> attacker c<strong>an</strong> perform. Such <strong>an</strong> attack might<br />
consist <strong>of</strong> multiple concurrent executions <strong>of</strong> the <strong>protocol</strong>. ProVerif does not<br />
limit the number <strong>of</strong> concurrent <strong>protocol</strong> runs that a modelled attacker may<br />
execute. It therefore is able to find attacks that require <strong>an</strong>y number <strong>of</strong> concurrent<br />
<strong>protocol</strong> runs.<br />
– It is fully <strong>automatic</strong>, i.e. after starting the <strong>verifier</strong>, it does not need <strong>an</strong>y user<br />
input to complete its t<strong>as</strong>k.<br />
– It does not signific<strong>an</strong>tly suffer from state space explosion.<br />
Security <strong>protocol</strong> researchers define <strong>protocol</strong>s with the arrow notation <strong>as</strong> described<br />
in [1]. When a user wishes to employ <strong>an</strong>y <strong>protocol</strong> <strong>verifier</strong>, he takes this<br />
<strong>protocol</strong> definition in arrow notation <strong>an</strong>d tr<strong>an</strong>slates it into instructions that are<br />
readable for his <strong>verifier</strong>. This set <strong>of</strong> instructions is called the <strong>protocol</strong> specification.<br />
Afterwards, the user provides the <strong>verifier</strong> with the specification, <strong>an</strong>d after<br />
some calculations, the <strong>verifier</strong> <strong>an</strong>nounces whether certain <strong>as</strong>sertions about the<br />
<strong>protocol</strong> were valid.<br />
2 For example NRL ([33]) <strong>an</strong>d Isabelle ([37])
ProVerif uses the concept <strong>of</strong> a Horn clause 3 <strong>as</strong> the unit <strong>of</strong> its specification<br />
l<strong>an</strong>guage. In this context, a Horn clause is <strong>an</strong> inference rule about knowledge<br />
<strong>of</strong> the adversary. An example <strong>of</strong> such a Horn clause might be “If one h<strong>as</strong> a<br />
ciphertext <strong>an</strong>d the corresponding key, one might also know the plaintext”. A set<br />
<strong>of</strong> Horn clauses is called a Horn theory. Therefore, one could say that <strong>protocol</strong><br />
specifications in ProVerif are Horn theories. The developers <strong>of</strong> ProVerif created<br />
the possibility to specify the <strong>protocol</strong> in <strong>an</strong> alternative l<strong>an</strong>guage, the applied pi<br />
calculus 4 , which is convenient for people already familiar with this specification<br />
framework.<br />
When a user tr<strong>an</strong>slates a <strong>protocol</strong> definition to a ProVerif <strong>protocol</strong> specification,<br />
he specifies the possible ways <strong>an</strong> attacker c<strong>an</strong> gather more knowledge. In<br />
ProVerif, this amounts to three different types <strong>of</strong> declaration:<br />
– The user models initial knowledge <strong>of</strong> the attacker <strong>as</strong> a tautology, a logical<br />
statement without conditions. An example <strong>of</strong> such a clause would be initial<br />
knowledge <strong>of</strong> the public keys <strong>of</strong> all particip<strong>an</strong>ts <strong>of</strong> the <strong>protocol</strong>.<br />
– Computational capabilities are modelled in separate clauses. For example, if<br />
the attacker h<strong>as</strong> posession <strong>of</strong> a (decryption) key <strong>an</strong>d a ciphertext, he may<br />
use it to decrypt the ciphertext if it is encrypted with that key.<br />
– A <strong>protocol</strong> definition that is written in the arrow notation contains a list <strong>of</strong><br />
<strong>protocol</strong> steps which necessesarily occur in that order. The user adds rules<br />
that describe these steps - one for each step in the <strong>protocol</strong> definition. To<br />
ensure the proper order <strong>of</strong> messages is preserved, the application <strong>of</strong> such a<br />
rule may only occur if the previous steps have already occurred.<br />
The first <strong>an</strong>d the third step in the tr<strong>an</strong>slation <strong>of</strong> the <strong>protocol</strong> definition are<br />
straightforward. Each element in the <strong>protocol</strong> definition corresponds with a rule<br />
in the <strong>protocol</strong> specification. However, the second step might require some additional<br />
work, especially if mathematical properties are directly related to the<br />
functionality <strong>of</strong> the <strong>protocol</strong>. Examples <strong>of</strong> such constructs are Diffie-Hellm<strong>an</strong> key<br />
exch<strong>an</strong>ge <strong>an</strong>d the use <strong>of</strong> the XOR-operator. The difficulties <strong>an</strong>d limitations <strong>of</strong><br />
the implementation <strong>of</strong> such constructs is discussed at length in 4.<br />
The user formulates <strong>an</strong> <strong>as</strong>sertion about the knowledge <strong>of</strong> the attacker, such <strong>as</strong><br />
‘The attacker knows the secret s’. Now, ProVerif will try to construct a sequence<br />
<strong>of</strong> steps for the attacker to achieve the fact that is stated in the <strong>as</strong>sertion. The<br />
idea behind the algorithm at the heart <strong>of</strong> ProVerif is that it applies the rules<br />
stated in the <strong>protocol</strong> specification in <strong>an</strong> efficient way. However, for the algorithm<br />
to terminate when no attack exists, it is necessary to apply some unification, i.e.<br />
to recognize when two states <strong>of</strong> <strong>protocol</strong> execution are effectively ‘the same’. If<br />
we merge two such effectively identical states, we could limit the space we need<br />
to search. The intermediate representation <strong>of</strong> the states <strong>of</strong> the <strong>protocol</strong> run in<br />
ProVerif are simple enough to enable it to effectively unify such states [7].<br />
3<br />
Horn clauses are a concept from Prolog programming <strong>an</strong>d are introduced at length<br />
in [13].<br />
4<br />
Fournet <strong>an</strong>d Abadi describe the applied pi calculus in [23].
The exact capabilities <strong>of</strong> the attacker are modelled according to the threat<br />
model <strong>as</strong> proposed by Dolev <strong>an</strong>d Yao, which is known <strong>as</strong> the Dolev-Yao threat<br />
model [21]. In short, this amounts to the following three <strong>as</strong>sumptions:<br />
– Encryption schemes are perfect - no keys leak from the key infr<strong>as</strong>tructure,<br />
the encrypted messages are unretrievable without the key, everybody h<strong>as</strong><br />
access to all public keys.<br />
– The parties in the network c<strong>an</strong> perform the encryption <strong>an</strong>d decryption operations<br />
themselves - they do not require <strong>an</strong> external party to perform these<br />
t<strong>as</strong>ks for them.<br />
– The attacker <strong>as</strong>sumes the role <strong>of</strong> <strong>an</strong> ‘active adversary’. More precisely, he<br />
c<strong>an</strong> intercept <strong>an</strong>d read <strong>an</strong>y message that is sent on the network <strong>an</strong>d inject<br />
<strong>an</strong>y message that contains information he knows through previous actions.<br />
When studying the accuracy <strong>of</strong> a tool for <strong>as</strong>sessing <strong>security</strong> properties, it is<br />
common to discuss the specificity <strong>an</strong>d the sensitivity 5 <strong>of</strong> the tool. The specificity<br />
is the extent to which the tool is able to declare that no attacks exist for a<br />
<strong>protocol</strong> that indeed does not allow attacks, i.e. to prevent false positives. The<br />
sensitivity is the ability <strong>of</strong> the tool to correctly recognize insecure <strong>protocol</strong>s. In a<br />
<strong>security</strong> context, it is clear that a high sensitivity is more import<strong>an</strong>t th<strong>an</strong> a high<br />
specificity. After all, we would rather have a hundred false positives reported<br />
on our <strong>protocol</strong> th<strong>an</strong> one potential attack that goes unnoticed. However, the<br />
usability <strong>of</strong> the tool greatly depends on both the sensitivity <strong>an</strong>d the specificity.<br />
If a tool always reports that <strong>an</strong> attack exists, it would be prudent, yet not very<br />
useful. In ProVerif, certain <strong>as</strong>sumptions <strong>an</strong>d abstractions are introduced. All <strong>of</strong><br />
these, however, only give more power to the attacker, thereby at most raising the<br />
number <strong>of</strong> false positives, yet never missing <strong>an</strong> attack that is indeed legitimate.<br />
For a discussion <strong>of</strong> approximations in ProVerif, see subsection 4.1.<br />
The algorithm behind ProVerif always terminates. This is not guar<strong>an</strong>teed <strong>automatic</strong>ally,<br />
but me<strong>as</strong>ures have been taken to <strong>as</strong>sure its termination. The most<br />
notable <strong>of</strong> these me<strong>as</strong>ures is the limitation to the depth <strong>of</strong> the nesting <strong>of</strong> terms<br />
in <strong>protocol</strong> messages. If a message exceeds this limit, the message is replaced by<br />
a new variable. Like the other approximations, this does lessen the sensitivity,<br />
since <strong>an</strong>y attack that exists in the non-limited c<strong>as</strong>e still exists in the depthlimited<br />
c<strong>as</strong>e.<br />
ProVerif is rele<strong>as</strong>ed under the GNU GPL 6 , which me<strong>an</strong>s that the source code<br />
<strong>of</strong> the program is freely available on the web. Works derived from the source<br />
<strong>of</strong> ProVerif must also be licensed under the GNU GPL. For such a program,<br />
this c<strong>an</strong> be a great incentive for potential new users, since they c<strong>an</strong> check the<br />
validity <strong>of</strong> the implementation. Second, it becomes possible to write additions<br />
<strong>an</strong>d extensions for ProVerif.<br />
5<br />
These terms are frequently used in the medical world. A further expl<strong>an</strong>ation in that<br />
context c<strong>an</strong> be found at [31].<br />
6<br />
GNU General Public License version 2, see for more details http://www.gnu.org/<br />
licenses/gpl-2.0.html.
3 Practical applications<br />
The verification <strong>of</strong> <strong>protocol</strong>s with ProVerif is the subject <strong>of</strong> <strong>an</strong> extensive set<br />
<strong>of</strong> literature (e.g.: [2] [4] [8] [9] [11] [25] [36]). ProVerif is used in m<strong>an</strong>y different<br />
fields, such <strong>as</strong> secure file sharing, electronic voting <strong>an</strong>d Bluetooth <strong>security</strong>. For<br />
each <strong>of</strong> these fields we will give a summary <strong>of</strong> how the authors used ProVerif<br />
in their research <strong>an</strong>d try to find their re<strong>as</strong>on to choose ProVerif. The list <strong>of</strong><br />
practical examples is not exhaustive but does give <strong>an</strong> impression <strong>of</strong> where <strong>an</strong>d<br />
how ProVerif is used. The fields that we discuss in more detail are selected<br />
because <strong>of</strong> their diversity <strong>an</strong>d the wide impact <strong>of</strong> the verified <strong>protocol</strong>s in the<br />
modern world.<br />
3.1 Secure file sharing on unstrusted storage<br />
Private personal data, such <strong>as</strong> family documents <strong>an</strong>d fin<strong>an</strong>cial data, is stored<br />
in various ways, for example: on a laptop, USB-drives <strong>an</strong>d shared mediums. It<br />
is import<strong>an</strong>t to secure this data because <strong>of</strong> the possibility that <strong>an</strong> attacker will<br />
use the data for other, possibly malicious, purposes.<br />
Plutus is a file system b<strong>as</strong>ed on a storage design that does not rely on storage<br />
servers to provide strong secrecy <strong>an</strong>d integrity guar<strong>an</strong>tees [8]. Bl<strong>an</strong>chet <strong>an</strong>d<br />
Chaudhuri have used ProVerif to prove that secrecy is preserved by Plutus. They<br />
were not able to prove this for the integrity property. In this c<strong>as</strong>e, violating the<br />
integrity property <strong>of</strong> the <strong>protocol</strong> me<strong>an</strong>s that <strong>an</strong> attacker c<strong>an</strong> store data in <strong>an</strong><br />
older version while the honest readers think only newer versions are corrupted<br />
by <strong>an</strong> attacker [8]. The researchers used the <strong>an</strong>alysis <strong>of</strong> ProVerif to construct a<br />
fix using server-verified writes, which were not present in the original <strong>protocol</strong>.<br />
Using ProVerif the authors proved the integrity property for the <strong>protocol</strong> after<br />
the fix <strong>an</strong>d w<strong>as</strong> also able to prove a strong integrity property, which stated that<br />
data read from the server w<strong>as</strong> not only written by <strong>an</strong> authorized party, but also<br />
<strong>of</strong> the required freshness.<br />
The attacks found by ProVerif were not present in the fixed version <strong>of</strong> the<br />
authors, thereby preserving secrecy <strong>an</strong>d restoring integrity in Plutus. We couldn’t<br />
find explicit re<strong>as</strong>ons for choosing ProVerif to verify Plutus, but the authors did<br />
state that using the Dolev-Yao threat model allowed them to automate the pro<strong>of</strong>s<br />
more e<strong>as</strong>ily th<strong>an</strong> using the computational model, which they report to be more<br />
concrete [8].<br />
3.2 Electronic voting<br />
Electronic voting is a suitable alternative for regular paper-b<strong>as</strong>ed voting [10]. It<br />
enables citizens in a democracy to elect their representatives by voting electronically.<br />
Verifying the <strong>protocol</strong>s used by electronic voting machines is import<strong>an</strong>t,<br />
because the integrity <strong>of</strong> the election process is fundamental to the integrity <strong>of</strong><br />
democracy itself [26]. The influence <strong>of</strong> attackers that are able to signific<strong>an</strong>tly
alter the results <strong>of</strong> <strong>an</strong> election is great, so the <strong>protocol</strong>s used must be <strong>as</strong> secure<br />
<strong>as</strong> possible. M<strong>an</strong>y researchers have found problems with currently used <strong>protocol</strong>s<br />
by electronic voting machines (e.g.: [22] [26] [38]).<br />
Automatic <strong>protocol</strong> <strong>verifier</strong>s c<strong>an</strong> be used to verify the <strong>protocol</strong>s used in electronic<br />
voting devices. To our knowledge, ProVerif h<strong>as</strong> been used to verify two<br />
electronic voting <strong>protocol</strong>s [4][27]. Ry<strong>an</strong> <strong>an</strong>d Kremer were able to prove the fairness<br />
<strong>an</strong>d eligibility properties <strong>of</strong> the FOO 92 [10] <strong>protocol</strong>. They were unable to<br />
prove the privacy property <strong>of</strong> the <strong>protocol</strong>, because ProVerif’s ability to prove<br />
observational equivalence between processes w<strong>as</strong> not complete at the time <strong>of</strong><br />
their research 7 [27]. They proved it m<strong>an</strong>ually without ProVerif. Their choise <strong>of</strong><br />
ProVerif seems to be b<strong>as</strong>ed on a suggestion from Bruno Bl<strong>an</strong>chet himself [27].<br />
Another group used ProVerif to verify the Juels, Catal<strong>an</strong>o <strong>an</strong>d Jakobsson <strong>protocol</strong>,<br />
which is the b<strong>as</strong>is for the development <strong>of</strong> m<strong>an</strong>y modern election schemes<br />
for remote voting[4]. They suggest a general approach for verifying voting <strong>protocol</strong>s<br />
<strong>an</strong>d were able to prove the vote-privacy property but they encountered<br />
problems similar to those in [27]: They could not complete the pro<strong>of</strong> without<br />
some hum<strong>an</strong> guid<strong>an</strong>ce to the verification process.<br />
3.3 Bluetooth <strong>security</strong><br />
Bluetooth is becoming incre<strong>as</strong>ingly ubiquitous <strong>an</strong>d is currently integrated in<br />
more th<strong>an</strong> one billion devices worldwide 8 . For all these devices to send data<br />
over a secure connection, the Bluetooth 2.0 specification 9 describes a <strong>protocol</strong>,<br />
called Device Pairing, where two devices have to agree on a symmetrical key. In<br />
2007 the Bluetooth specification w<strong>as</strong> updated to version 2.1 which requires the<br />
Simple Pairing <strong>protocol</strong> for communication between Bluetooth 2.1 devices, but<br />
is backwards compatible with Device Pairing for older devices. We now look at<br />
how ProVerif is used to <strong>an</strong>alyze these <strong>protocol</strong>s.<br />
Device pairing in Bluetooth. The Device Pairing <strong>protocol</strong> used in the Bluetooth<br />
2.0 specification h<strong>as</strong> shown to be vulnerable to <strong>an</strong> attacker that impersonates a<br />
Bluetooth device after eavesdropping on a successful pairing session[24] <strong>an</strong>d w<strong>as</strong><br />
proven by the use <strong>of</strong> ProVerif [11]. The weakness <strong>of</strong> the Device Pairing <strong>protocol</strong><br />
is the (guessable) hum<strong>an</strong>ly memorable secret key. All that <strong>an</strong> attacker needs to<br />
know is the secret key to be able to impersonate a device [11]. ProVerif is used<br />
to show that the observational equivalence does not hold for Bluetooth device<br />
pairing [11]. This me<strong>an</strong>s <strong>an</strong> attacker c<strong>an</strong> learn information from the messages<br />
communicated.<br />
7 Bl<strong>an</strong>chet <strong>an</strong>d Fournet have since published [9]. Bl<strong>an</strong>chet added the mentioned func-<br />
tionality to ProVerif.<br />
8 Bluetooth exceeds one billion devices, see http://www.bluetooth.com/Bluetooth/<br />
Press/SIG/BLUETOOTH\ WIRELESS\ TECHNOLOGY\ SURPASSES\ ONE\ BILLION\<br />
DEVICES.htm<br />
9 Bluetooth 2.0 specification, see for more information: http://www.bluetooth.com/<br />
NR/rdonlyres/1F6469BA-6AE7-42B6-B5A1-65148B9DB238/840/Core v200 EDR.zip
Bluetooth 2.1. In Bluetooth 2.1, Simple Pairing h<strong>as</strong> four modes <strong>of</strong> operation<br />
b<strong>as</strong>ed on the hardware capabilities <strong>of</strong> the device: Just Works, Numeric Comparison,<br />
P<strong>as</strong>skey Entry <strong>an</strong>d Out <strong>of</strong> B<strong>an</strong>d. Because <strong>of</strong> a known attack on the Just<br />
Works <strong>an</strong>d P<strong>as</strong>skey Entry operating modes, Nilsson, Larson <strong>an</strong>d Erl<strong>an</strong>d have<br />
developed a <strong>protocol</strong> which is not vulnerable to the M<strong>an</strong> In The Middle-attack<br />
<strong>an</strong>ymore[36]. They used ProVerif to prove the new scheme for authentication,<br />
named ACDHEKE, <strong>an</strong>d have shown that the attack is no longer possible for the<br />
Just Works <strong>an</strong>d P<strong>as</strong>skey Entry operating modes.<br />
For the Numeric Comparison operating mode <strong>of</strong> Simple Pairing, Ch<strong>an</strong>g <strong>an</strong>d<br />
Shmatikov have employed ProVerif to show that strong authentication fails for<br />
the <strong>protocol</strong>. In strong authentication with Simple Pairing, the user must confirm<br />
the h<strong>as</strong>h, visible on communicating devices A <strong>an</strong>d B, generated from the initial<br />
keys. ProVerif proved that strong authentication does not hold when a device A<br />
is executing multiple sessions with <strong>an</strong>other device B[11]. The h<strong>as</strong>h value that is<br />
shown to the user may not be the h<strong>as</strong>h value <strong>of</strong> the session the user thinks he is<br />
accepting, thereby accepting the wrong session <strong>as</strong> successful.<br />
Bluetooth 3.0 In April, 2009 the Bluetooth Special Interest Group adopted the<br />
Bluetooth 3.0 specification. Bluetooth 3.0 remains backwards compatible with<br />
previous versions, so it is susceptible to the same attacks when used to communicate<br />
with devices using older versions <strong>of</strong> Bluetooth. This me<strong>an</strong>s that the<br />
<strong>an</strong>alysis made with ProVerif is still relev<strong>an</strong>t for some time while the market is<br />
adopting Bluetooth 3.0.<br />
We identified two main re<strong>as</strong>ons why Ch<strong>an</strong>g <strong>an</strong>d Shmatikov used ProVerif for<br />
their <strong>an</strong>alysis <strong>of</strong> the Bluetooth. First, ProVerif supports the verification <strong>of</strong> weak<br />
secrecy (which w<strong>as</strong> useful because <strong>of</strong> the low-entropy secrets used in Bluetooth)<br />
[11]. Second, they used correspondence <strong>as</strong>sertions for modeling authentication<br />
[11].<br />
4 Limitations <strong>of</strong> ProVerif<br />
In the previous chapter, we have considered applications <strong>of</strong> ProVerif, which<br />
brings up the question what the limitations <strong>of</strong> ProVerif are: what are <strong>protocol</strong>s<br />
or parts or properties <strong>of</strong> <strong>protocol</strong>s which we might w<strong>an</strong>t to model in ProVerif, but<br />
are unable to? About which types <strong>of</strong> problem is ProVerif unable to yield a (valid)<br />
verdict <strong>as</strong> to whether the required <strong>as</strong>sertions are satisfied? We will describe<br />
the limitations we have encountered in the literature <strong>an</strong>d discuss whether the<br />
problems c<strong>an</strong> be e<strong>as</strong>ily solved, or seem to be inherent to ProVerif.<br />
4.1 Approximations in ProVerif<br />
The developers <strong>of</strong> ProVerif have made some approximations in their formalization<br />
<strong>of</strong> <strong>security</strong> <strong>protocol</strong>s[7]. According to them, these approximations are key<br />
to limiting the number <strong>of</strong> runs <strong>of</strong> <strong>protocol</strong>s. Unsurprisingly, these could theoretically<br />
be <strong>of</strong> influence to the sensitivity <strong>an</strong>d specificity <strong>of</strong> ProVerif.
First, they have not built in a source <strong>of</strong> r<strong>an</strong>domness with which to generate<br />
nonces. Instead they model nonces <strong>as</strong> a function <strong>of</strong> the current environment,<br />
i.e. the <strong>protocol</strong> execution up until the point <strong>of</strong> nonce generation. Therefore, two<br />
nonces are equal if <strong>an</strong>d only if the entire <strong>protocol</strong> execution, including adversarial<br />
behaviour, is exactly the same in both c<strong>as</strong>es. This gives the adversary slightly<br />
more power, which only lowers the specificity <strong>an</strong>d not the sensitivity <strong>of</strong> ProVerif.<br />
Furthermore, no practical c<strong>as</strong>es are known (according to [7]) where this results<br />
in false positives.<br />
Second, ProVerif does not limit repetition <strong>of</strong> <strong>protocol</strong> rules. Imagine a <strong>protocol</strong><br />
run where a party uses one <strong>of</strong> the rules in the <strong>protocol</strong> definition multiple times,<br />
without this being allowed in the definition. Normally, the other party will only<br />
respond to the first inst<strong>an</strong>ce <strong>of</strong> the <strong>protocol</strong> rule <strong>as</strong> specified. He will not respond<br />
to the other inst<strong>an</strong>ces because he is no longer awaiting a message that is<br />
formatted thus. ProVerif on the other h<strong>an</strong>d does not implement this behaviour,<br />
<strong>an</strong>d instead allows the parties to use each rule <strong>an</strong>y number <strong>of</strong> times. However,<br />
like the previous approximation, this c<strong>an</strong> only result in more false positives, but<br />
h<strong>as</strong> no influence on the sensitivity <strong>of</strong> the <strong>protocol</strong>.<br />
4.2 XOR<br />
Multiple <strong>protocol</strong>s use the logical XOR-operator, <strong>of</strong>ten denoted by ⊕, <strong>as</strong> a<br />
part <strong>of</strong> their definition. For example, the one-time pad, a textbook <strong>protocol</strong> that<br />
c<strong>an</strong> be found in <strong>an</strong>y cryptography textbook such <strong>as</strong> [34], relies heavily on the<br />
mathematical properties <strong>of</strong> the XOR-operator. Therefore, it is a requirement <strong>of</strong> a<br />
general <strong>protocol</strong> <strong>verifier</strong> that it c<strong>an</strong> be applied to questions about such <strong>protocol</strong>s.<br />
ProVerif, however, is not concerned with the algebraic structure <strong>of</strong> the primitives<br />
used in <strong>protocol</strong>s, buth rather with their general structure, thus being unable to<br />
directly <strong>an</strong>swer questions about the <strong>protocol</strong>s that use, for example, the XORoperator.[28]<br />
Küsters <strong>an</strong>d Truderung [28] considered this problem <strong>an</strong>d have described a solution<br />
which requires the user to formulate his <strong>protocol</strong> in a special form which<br />
they call ⊕-linear. A term in a Horn theory is called ⊕-linear if for every subterm<br />
<strong>of</strong> the form t ⊕ t ′ it is true that either t or t ′ does not contain variables. A Horn<br />
theory itself is called ⊕-linear if all terms in it are ⊕-linear, with the possible<br />
exception <strong>of</strong> the rule that enables the intruder to perform the XOR-operation.<br />
The authors <strong>of</strong> the paper have provided <strong>an</strong> algorithm with which to rewrite a ⊕linear<br />
Horn theory to a Horn theory that does not contain <strong>an</strong>y XOR operations.<br />
This XOR-free Horn theory c<strong>an</strong> then be presented to ProVerif for verification.<br />
The correctness <strong>of</strong> the algorithm provided by the authors implies that ProVerif<br />
will find all attacks it would have found in the old specification <strong>of</strong> the <strong>protocol</strong>,<br />
combined with possible new attacks that are the result <strong>of</strong> the algebraic structure<br />
<strong>of</strong> the XOR operation. The authors do not discuss the complexity <strong>of</strong> their algorithm<br />
in [28]. However, when they refer to this work in [29], they posit that their<br />
algorithm for XOR rewriting ‘suffers from <strong>an</strong> exponential blow-up’. The authors
have also published a tool, XOR-ProVerif, to perform the mentioned tr<strong>an</strong>slation<br />
<strong>automatic</strong>ally.<br />
4.3 Diffie-Hellm<strong>an</strong><br />
Another primitive that is <strong>of</strong>ten employed in cryptographic <strong>protocol</strong>s is Diffie-<br />
Hellm<strong>an</strong> key exch<strong>an</strong>ge[20]. In its b<strong>as</strong>ic form, the method enables two particip<strong>an</strong>ts<br />
in a <strong>protocol</strong> run to construct a shared key without <strong>an</strong>y previously shared secret.<br />
This key c<strong>an</strong> be used in subsequent communications between these parties.<br />
However, the nature <strong>of</strong> the <strong>protocol</strong> depends on the nature <strong>of</strong> (discrete) exponentiation.<br />
For example, the method works because exponentiation in a group<br />
is commutative (i.e. a xy = a yx for <strong>an</strong>y a, x <strong>an</strong>d y). A <strong>protocol</strong> <strong>verifier</strong> such <strong>as</strong><br />
ProVerif does not enable a researcher to explicitly describe the algebraic properties<br />
used in the <strong>protocol</strong>s that he checks. Therefore, <strong>as</strong> w<strong>as</strong> also described in<br />
section 4.2 for the c<strong>as</strong>e <strong>of</strong> the XOR, it is difficult to directly <strong>as</strong>sert properties <strong>of</strong><br />
a <strong>protocol</strong> that uses such primitives.[29]<br />
However, this problem w<strong>as</strong> resolved recently, <strong>as</strong> a method w<strong>as</strong> constructed by<br />
Küsters <strong>an</strong>d Truderung in [29] to rewrite <strong>protocol</strong>s using Diffie-Hellm<strong>an</strong> exponentiation<br />
to a <strong>protocol</strong> definition without such primitives. This definition c<strong>an</strong><br />
in turn be tr<strong>an</strong>slated to a specification consisting <strong>of</strong> Horn clauses. ProVerif will<br />
then be able to <strong>an</strong>alyze this rewritten specification. The method that is discussed<br />
is able to implement both the commutativity <strong>of</strong> exponentiation <strong>an</strong>d the<br />
calculation <strong>of</strong> the multiplicative inverse <strong>of</strong> <strong>an</strong> element (i.e. exponentiation with<br />
exponent −1). More specifically, a specific cl<strong>as</strong>s <strong>of</strong> terms is discussed, called<br />
exponent-ground terms. These terms have a constraint on the nature <strong>of</strong> the exponents<br />
that occur in them: these may not contain <strong>an</strong>y variables or further<br />
exponentiations. The authors argue that this does not limit the number <strong>of</strong> <strong>protocol</strong>s<br />
employing Diffie-Hellm<strong>an</strong> that c<strong>an</strong> be <strong>an</strong>alyzed. They proceed by proving<br />
the rewritability <strong>of</strong> Horn theories that consist <strong>of</strong> only exponent-ground terms<br />
to Horn theories that contain no exponentiation at all. They also include <strong>an</strong><br />
explicit rewriting method <strong>an</strong>d demonstrate it in <strong>an</strong> example. The authors have<br />
also published a tool, DH-ProVerif, to perform the mentioned tr<strong>an</strong>slation <strong>automatic</strong>ally.<br />
Küsters <strong>an</strong>d Truderung claim that their method is efficient, because<br />
<strong>of</strong> the polynomial running time <strong>of</strong> their algorithm. The algorithms presented in<br />
earlier work are sometimes less efficient, <strong>an</strong>d sometimes focus on other algebraic<br />
properties <strong>of</strong> the Diffie-Hellm<strong>an</strong> exponentiation. For example, the authors <strong>of</strong> [12]<br />
provide a solution that is not known to have polynomial running time, though<br />
it h<strong>an</strong>dles a broader r<strong>an</strong>ge <strong>of</strong> algebraic properties.<br />
4.4 R<strong>an</strong>domness<br />
In most modern-day <strong>protocol</strong>s, some r<strong>an</strong>domness is used in <strong>as</strong>ymmetric encryption.<br />
If no r<strong>an</strong>domness would be used, <strong>an</strong> attacker could upon receipt <strong>of</strong> a<br />
ciphertext e<strong>as</strong>ily encrypt a message with the corresponding puplic key <strong>an</strong>d then
check for equality <strong>of</strong> the ciphertexts to infer equality <strong>of</strong> the plaintexts. This potential<br />
problem is e<strong>as</strong>ily solved by appending a fixed-length r<strong>an</strong>dom string at the<br />
end <strong>of</strong> the plaintext before encryption. After decryption, the recipient removes<br />
the appended r<strong>an</strong>dom bytes <strong>an</strong>d h<strong>as</strong> the original plaintext. When studying <strong>protocol</strong>s<br />
that employ such techniques, some form <strong>of</strong> labeling is used to explicitly<br />
denote the r<strong>an</strong>domness used in the encryption - for example, when encrypting<br />
plaintext m together with r<strong>an</strong>domness l using key k, we could denote this with<br />
the label in a superscript:<br />
{m} l k.<br />
However, according to Cortier et al. ([15]), none <strong>of</strong> the currently popular tools 10<br />
<strong>of</strong>fer capabilities for re<strong>as</strong>oning in <strong>protocol</strong> models using labels. Instead <strong>of</strong> extending<br />
the underlying framework <strong>of</strong> a tool to encomp<strong>as</strong>s labels, they proceed<br />
to formulate a theorem that makes such extensions unnecessary. For a large<br />
cl<strong>as</strong>s <strong>of</strong> <strong>protocol</strong>s, validity <strong>of</strong> the <strong>protocol</strong> without the labels (which is verifiable<br />
in <strong>an</strong> <strong>automatic</strong> <strong>verifier</strong>), implies validity <strong>of</strong> the <strong>protocol</strong> with the labels (i.e.<br />
with r<strong>an</strong>domness). This large cl<strong>as</strong>s <strong>of</strong> <strong>protocol</strong>s includes <strong>protocol</strong>s using currently<br />
st<strong>an</strong>dard formulations for secrecy <strong>an</strong>d authenticity. Moreover, they have<br />
constructed a module for AVISPA that checks whether a <strong>protocol</strong> that uses r<strong>an</strong>domness<br />
fulfills the requirements <strong>of</strong> the theorem, <strong>an</strong>d proceeds to perform the<br />
tr<strong>an</strong>slation to a nonlabelled <strong>protocol</strong> which c<strong>an</strong> in turn be verified using the<br />
original AVISPA mech<strong>an</strong>isms. Such a module might also be constructable for<br />
ProVerif, which would resolve this limitation in the <strong>protocol</strong> verification model.<br />
5 Comparison with other <strong>verifier</strong>s<br />
ProVerif is a state-<strong>of</strong>-the-art <strong>automatic</strong> <strong>protocol</strong> <strong>verifier</strong>, but is not the only <strong>verifier</strong><br />
dedicated to <strong>security</strong> <strong>protocol</strong>s. Other <strong>verifier</strong>s include Athena[39], AVISPA[3],<br />
C<strong>as</strong>per [32], Isabelle[37], NRL[33], Scyther[17] <strong>an</strong>d YAPA[5]. These <strong>verifier</strong>s are<br />
all b<strong>as</strong>ed on the Dolev-Yao threat model [21].<br />
Our main goal is to find pro<strong>of</strong> for the efficiency claims made in the original<br />
version <strong>of</strong> ProVerif. We briefly compare the soundness <strong>of</strong> the <strong>verifier</strong>s by looking<br />
at the attack traces they provide to the user. Attack traces are detailed traces<br />
<strong>of</strong> how the <strong>verifier</strong> constructed the attack.<br />
ProVerif uses Prolog rules <strong>an</strong>d implements a solving algorithm that is efficient<br />
because <strong>of</strong> overapproximations [7]. Other <strong>verifier</strong>s like Interrogator[35] <strong>an</strong>d NRL<br />
have implemented similar formalisms. Relative to these <strong>verifier</strong>s, ProVerif uses a<br />
more abstract representation <strong>of</strong> <strong>protocol</strong>s. For example, it forgets the number <strong>of</strong><br />
times a message appears <strong>an</strong>d only remembers that it h<strong>as</strong> appeared. This enables<br />
a f<strong>as</strong>ter <strong>an</strong>d simpler <strong>an</strong>alysis <strong>of</strong> a <strong>protocol</strong> [7].<br />
10 They mention ProVerif, C<strong>as</strong>per[32], Athena[39] <strong>an</strong>d AVISPA[3].
Most existing <strong>protocol</strong> <strong>verifier</strong>s b<strong>as</strong>ed on model checking suffer from the problem<br />
<strong>of</strong> state space explosion [7]. The solution generally implemented is limiting the<br />
number <strong>of</strong> runs <strong>of</strong> the <strong>protocol</strong>. The problem is that when <strong>an</strong> attack exists,<br />
which need more runs <strong>of</strong> the <strong>protocol</strong> to be discovered, it will not be found by<br />
these <strong>verifier</strong>s [7]. ProVerif solves the state space explosion by using unification<br />
techniques [7] (see Section 2).<br />
5.1 Efficiency<br />
We have found a few studies that compare <strong>verifier</strong>s b<strong>as</strong>ed on efficiency, but<br />
little research h<strong>as</strong> been done on this subject. Cremers <strong>an</strong>d Lafourcade compared<br />
the efficiency <strong>of</strong> AVISPA (which consists <strong>of</strong> the <strong>verifier</strong>s CL-Atse, OFMC, Sat-<br />
MC <strong>an</strong>d TA4SP), Scyther <strong>an</strong>d ProVerif. They found that, in general, ProVerif<br />
shows the best time perform<strong>an</strong>ce due to the abstract representation <strong>of</strong> nonces<br />
<strong>an</strong>d that it quickly provides the user with <strong>an</strong> <strong>an</strong>alysis for <strong>an</strong> unbounded number<br />
<strong>of</strong> runs [18]. The second f<strong>as</strong>test <strong>verifier</strong> Scyther is interesting, because it doesn’t<br />
use approximation methods like ProVerif to achieve a f<strong>as</strong>t full verification <strong>of</strong> the<br />
<strong>security</strong> <strong>protocol</strong>. Scyther <strong>an</strong>d ProVerif both achieved a full verification within<br />
0.001 seconds for the Needham-Schroeder <strong>an</strong>d Needham-Schroeder-Lowe <strong>protocol</strong>s<br />
[18]. In the c<strong>as</strong>e <strong>of</strong> Needham-Schroeder, ProVerif found three real attacks<br />
on the <strong>protocol</strong> in the same time that Scyther only found two attacks.<br />
Proving secrecy . When comparing the results for various <strong>verifier</strong>s that are presented<br />
in [18], we note that for proving secrecy, Scyther, TA4SP <strong>an</strong>d ProVerif<br />
provide near-zero timings. The <strong>verifier</strong>s Sat-MC, OFMC <strong>an</strong>d CL-Atse follow <strong>an</strong><br />
exponential curve relative to the number <strong>of</strong> runs. For more complex <strong>protocol</strong>s<br />
like TLS[19] <strong>an</strong>d EKE[6] the results differ slightly. Scyther also follows <strong>an</strong> exponential<br />
time curve for this particular <strong>protocol</strong> but is still much f<strong>as</strong>ter then<br />
Sat-MC, OFMC <strong>an</strong>d CL-Atse [18]. ProVerif is const<strong>an</strong>t in time (around 0.5 seconds<br />
per run). Another <strong>protocol</strong> that is used for the comparison is TLS. Here,<br />
ProVerif, Scyther <strong>an</strong>d TA4SP show to be relatively const<strong>an</strong>t <strong>an</strong>d differ less th<strong>an</strong><br />
0.1 seconds from each other per run.<br />
Proving authentication . Where ProVerif w<strong>as</strong> the f<strong>as</strong>test tool for proving secrecy<br />
properties <strong>of</strong> <strong>protocol</strong>s, the results differ slightly for the authentication properties.<br />
In general, ProVerif <strong>an</strong>d Scyther are again the f<strong>as</strong>test <strong>verifier</strong>s for the<br />
Needham-Schroeder <strong>an</strong>d TLS <strong>protocol</strong>s. For the EKE <strong>protocol</strong>, ProVerif w<strong>as</strong><br />
the slowest <strong>of</strong> the <strong>verifier</strong>s considered [18]. The authors state that this is because<br />
ProVerif doesn’t support equational theories very well (like XOR, discussed in<br />
Section 4.2) [18].<br />
Static equivalences . Another study compares the efficiency <strong>of</strong> YAPA to ProVerif.<br />
YAPA is a <strong>verifier</strong> which provides a generic procedure for deducibility <strong>an</strong>d static<br />
equivalences. Deducibility is the notion that some piece <strong>of</strong> data is retrievable<br />
from a finite set <strong>of</strong> messages. If the attacker c<strong>an</strong>not distinguish between two<br />
sequences <strong>of</strong> messages, the messages are said to be statically equivalent [14].
When static equivalence holds for some sequence <strong>of</strong> messages then it is not<br />
possible for the attacker to find <strong>an</strong> underlying pattern. For example, guessing<br />
attacks are possible if the attacker c<strong>an</strong> detect some pattern in the data.<br />
The study, comparing YAPA to ProVerif, concludes that YAPA is one or two<br />
orders <strong>of</strong> magnitude f<strong>as</strong>ter th<strong>an</strong> ProVerif in checking static equivalences[5]. This<br />
c<strong>an</strong> be explained by the fact that YAPA is dedicated to proving static equivalences<br />
<strong>an</strong>d that it is no surprise that the more general tool ProVerif is slower[5].<br />
The authors state that the more complex preprocessing <strong>of</strong> the rewrite system in<br />
ProVerif is one <strong>of</strong> the re<strong>as</strong>ons why it is slower th<strong>an</strong> YAPA [5].<br />
A comparison between the efficiency <strong>of</strong> Athena <strong>an</strong>d other <strong>verifier</strong>s w<strong>as</strong> not<br />
possible due to fact that Athena is not publicly available 11 . Scyther improves on<br />
Athena [17]. We believe that Athena’s perform<strong>an</strong>ce is not f<strong>as</strong>ter th<strong>an</strong> the results<br />
from Scyther but we c<strong>an</strong>’t know for sure without concrete experimental results.<br />
Efficiency <strong>of</strong> ProVerif with extensions . In Section 4 we have described how<br />
ProVerif w<strong>as</strong> extended to be able to tr<strong>an</strong>sform a <strong>protocol</strong> specification using<br />
XOR <strong>an</strong>d Diffie-Hellm<strong>an</strong> to <strong>an</strong> input file for <strong>an</strong>alysis with ProVerif.<br />
To compare ProVerif with CL-Atse <strong>an</strong>d OFMC, [30] used XOR-ProVerif[28]<br />
<strong>an</strong>d DH-ProVerif[29] to tr<strong>an</strong>slate the input files, with XOR or Diffie-Hellm<strong>an</strong>, to<br />
the applied pi calculus input files for ProVerif. They concluded that in general<br />
the same attacks were found using OFMC, CL-Atse or ProVerif (XOR-ProVerif<br />
or DH-ProVerif). For most <strong>of</strong> the <strong>protocol</strong>s, ProVerif completed the verification<br />
within one second but the AVISPA tools did so within less th<strong>an</strong> 0.01 seconds.<br />
ProVerif w<strong>as</strong> slower because <strong>of</strong> the tr<strong>an</strong>slation <strong>of</strong> the input files [30]. The time<br />
required for tr<strong>an</strong>slation depends on the <strong>protocol</strong> being verified, but <strong>of</strong>ten it is<br />
a small part <strong>of</strong> the total running time (e.g. Salary sum <strong>protocol</strong>: 1 second for<br />
tr<strong>an</strong>slation + 11 seconds for the running time, Bull’s authentication <strong>protocol</strong>: 5<br />
seconds for tr<strong>an</strong>slation + 12 seconds for the running time).<br />
5.2 Specificity<br />
Attack traces provide feedback to the user <strong>of</strong> a <strong>verifier</strong> <strong>an</strong>d they enable the user<br />
to m<strong>an</strong>ually check the attack. This feedback c<strong>an</strong> help the user fix the <strong>security</strong><br />
flaw in the <strong>protocol</strong> being verified. Both ProVerif <strong>an</strong>d Scyther show attack traces<br />
when <strong>an</strong> attack is found [18]. Because <strong>of</strong> its use <strong>of</strong> approximations, it is possible<br />
that ProVerif shows <strong>an</strong> false attack, but this is rare for current widely used<br />
<strong>security</strong> <strong>protocol</strong>s [7]. Because Scyther uses no approximations, it follows that<br />
attacks that are found with Scyther are actual attacks on the <strong>protocol</strong>[17]. For<br />
the <strong>verifier</strong> TA4SP (part <strong>of</strong> the AVISPA toolkit) there is no way to determine<br />
if <strong>an</strong> attack is true or false. Like ProVerif, TA4SP uses approximations, but the<br />
user c<strong>an</strong>not m<strong>an</strong>ually verify the attack because TA4SP doesn’t generate traces<br />
<strong>of</strong> <strong>an</strong> attack [18].<br />
11 This statement is made in [18] <strong>an</strong>d in [16]. However, the s<strong>of</strong>tware seems to be available<br />
at http://www.ece.cmu.edu/ ∼ dawnsong/athena/.
5.3 Usability<br />
To our knowledge, no comparative study h<strong>as</strong> been done in the area <strong>of</strong> the<br />
usability <strong>of</strong> <strong>automatic</strong> <strong>security</strong> <strong>protocol</strong> <strong>verifier</strong>s. We decided to compare the<br />
documentation (user m<strong>an</strong>uals, example code) provided by the authors on the<br />
website. With good documentation available, users c<strong>an</strong> start using the <strong>verifier</strong><br />
more e<strong>as</strong>ily by exploring the examples <strong>an</strong>d m<strong>an</strong>uals provided.<br />
ProVerif (v1.82) 12 provides a folder containing examples for both input l<strong>an</strong>guages<br />
(Horn clauses <strong>an</strong>d pi calculus). There is also <strong>an</strong> folder containing a m<strong>an</strong>ual<br />
describing the input <strong>an</strong>d output formats <strong>an</strong>d a m<strong>an</strong>ual on how to upgrade<br />
from <strong>an</strong> older version <strong>of</strong> ProVerif.<br />
The website 13 <strong>of</strong> the AVISPA project provides a lot <strong>of</strong> input examples <strong>of</strong> existing<br />
<strong>protocol</strong>s for the HLPSL l<strong>an</strong>guage in the form <strong>of</strong> the AVISPA Library. They also<br />
provide a list <strong>of</strong> user-contributed <strong>protocol</strong> specifications. The authors provide<br />
installation m<strong>an</strong>uals for each <strong>of</strong> the tools in the toolkit, a general user m<strong>an</strong>ual<br />
<strong>an</strong>d a beginners guide to the HLPSL l<strong>an</strong>guage.<br />
Scyther (1.0-beta7) 14 . Scyther is relatively new <strong>an</strong>d not much documentation<br />
is available besides a short installation file. The author does provide <strong>an</strong> exercise<br />
set for students with six exercises in it.<br />
We could not find much information on the process <strong>of</strong> modeling the <strong>protocol</strong><br />
into the input l<strong>an</strong>guage <strong>of</strong> a <strong>verifier</strong>. We did find remarks <strong>of</strong> researchers who had<br />
difficulty modeling <strong>protocol</strong>s in ProVerif, relative to five other <strong>verifier</strong>s, even<br />
though they had good knowledge <strong>of</strong> the <strong>protocol</strong>s [18].<br />
Because ProVerif provides the essential information, such <strong>as</strong>: <strong>an</strong> installation<br />
guide, a description <strong>of</strong> input formats <strong>an</strong>d <strong>protocol</strong> examples, we think that<br />
ProVerif h<strong>as</strong> good documentation. The lack <strong>of</strong> information for Scyther makes<br />
it difficult for a beginner to start using the <strong>automatic</strong> <strong>security</strong> <strong>protocol</strong> <strong>verifier</strong>.<br />
We think that the use <strong>of</strong> user-contributed <strong>protocol</strong> specifications, like the<br />
AVISPA Project, c<strong>an</strong> get more people to use ProVerif. For example, beginners<br />
c<strong>an</strong> learn from the examples <strong>an</strong>d comments given by others.<br />
6 Conclusion<br />
In this paper, we have performed <strong>an</strong> <strong>an</strong>alysis <strong>of</strong> some factors that might influence<br />
the usefulness <strong>an</strong>d popularity <strong>of</strong> the <strong>automatic</strong> <strong>protocol</strong> <strong>verifier</strong> ProVerif.<br />
After discussing the particular <strong>as</strong>pects <strong>of</strong> ProVerif, we looked at some practical<br />
applications <strong>of</strong> ProVerif for <strong>protocol</strong> verification. We have surveyed the literature<br />
on limitations on ProVerif, <strong>an</strong>d we briefly summarized some <strong>of</strong> the work on<br />
comparison <strong>of</strong> <strong>protocol</strong> <strong>verifier</strong>s.<br />
12 ProVerif v.1.82. Download: http://www.proverif.ens.fr<br />
13 AVISPA Project. Download: http://www.avispa-project.org<br />
14 Scyther 1.0-beta7. Download: http://people.inf.ethz.ch/cremersc/scyther/<br />
index.html
When studying ProVerif, we have found that the <strong>verifier</strong> h<strong>as</strong> several desirable<br />
properties for <strong>protocol</strong> verification. First, it c<strong>an</strong> h<strong>an</strong>dle <strong>an</strong> unbounded number<br />
<strong>of</strong> <strong>protocol</strong> runs. Second, it uses a fairly extensive threat model, the Dolev-Yao<br />
model, which me<strong>an</strong>s it gives a lot <strong>of</strong> power to the attacker. The tr<strong>an</strong>slation from<br />
a <strong>protocol</strong> definition to a <strong>protocol</strong> specification seems to be difficult at times<br />
but mostly straightforward, <strong>an</strong>d two distinct l<strong>an</strong>guages, the applied pi calculus<br />
<strong>an</strong>d Horn clauses, are provided <strong>as</strong> specification l<strong>an</strong>guages. When <strong>an</strong>alyzing the<br />
<strong>protocol</strong> specification, several <strong>as</strong>sumptions are made which might lead to finding<br />
false attacks. However, all these <strong>as</strong>sumptions do not influence the ability to find<br />
attacks in unsafe <strong>protocol</strong>s (i.e. the sensitivity), therefore, if <strong>an</strong> attack exists,<br />
ProVerif will find one.<br />
The application <strong>of</strong> <strong>Proverif</strong> to real-life <strong>protocol</strong>s is very common in academic<br />
environments, <strong>as</strong> testified by the extensive collection <strong>of</strong> literature in which is<br />
it used. In using the <strong>verifier</strong>, researchers note that they have more difficulty<br />
modeling some properties <strong>an</strong>d requirements <strong>of</strong> <strong>protocol</strong>s in ProVerif compared<br />
to other <strong>protocol</strong> <strong>verifier</strong>s. ProVerif seems to be otherwise successful in finding<br />
new attacks, <strong>an</strong>d even sometimes finds attacks in <strong>protocol</strong>s that have already<br />
been <strong>an</strong>alyzed with other <strong>protocol</strong> <strong>verifier</strong>s.<br />
Currently, one <strong>of</strong> the major challenges for <strong>an</strong>y <strong>protocol</strong> <strong>verifier</strong> is succesfully<br />
modelling the algebraic properties <strong>of</strong> cryptographic primitives such <strong>as</strong> Diffie-<br />
Hellm<strong>an</strong> encryption or the XOR operation. At first gl<strong>an</strong>ce, ProVerif h<strong>as</strong> difficulties<br />
to effectively represent <strong>protocol</strong>s that contain such primitives. However,<br />
we found literature that describes techniques for rewriting <strong>protocol</strong> specifications<br />
so that they c<strong>an</strong> represent the algebraic properties involved <strong>as</strong> well. Tools<br />
have been developed <strong>an</strong>d included with the ProVerif distribution package that<br />
perform such rewriting t<strong>as</strong>ks <strong>automatic</strong>ally. Since ProVerif is open source <strong>an</strong>d<br />
licensed under the GNU GPL, such tools could also be merged with ProVerif<br />
itself, though perform<strong>an</strong>ce considerations might dictate otherwise.<br />
The developers <strong>of</strong> ProVerif have made several claims about the <strong>verifier</strong>, such<br />
<strong>as</strong> its speed <strong>an</strong>d memory usage. Studies that compare ProVerif to other <strong>verifier</strong>s<br />
indeed show that ProVerif performs quite well in these <strong>as</strong>pects. No conclusive<br />
studies that compare the usability for researchers <strong>of</strong> such tools, but the remarks<br />
by researchers about the tr<strong>an</strong>slation <strong>of</strong> <strong>protocol</strong> definitions to specifications seem<br />
to indicate that ProVerif is somewhat lacking in this direction.<br />
Summing up, ProVerif seems to be a widely applicable tool with a good track<br />
record. On the other side, some other <strong>verifier</strong>s seem to surp<strong>as</strong>s ProVerif on certain<br />
points. However, if you require a tool that c<strong>an</strong> quickly verify a <strong>protocol</strong> in one<br />
<strong>of</strong> the more general threat models, ProVerif is still a very good choice.
References<br />
1. M. Abadi. Security Protocols <strong>an</strong>d their Properties. In Foundations <strong>of</strong> Secure<br />
Computation, NATO Science Series, pages 39–60. IOS Press, 2000.<br />
2. M. Abadi, B. Bl<strong>an</strong>chet, <strong>an</strong>d C. Fournet. Just f<strong>as</strong>t keying in the pi calculus. ACM<br />
Tr<strong>an</strong>sactions on Information <strong>an</strong>d System Security, 10(3):9, 2007.<br />
3. A. Arm<strong>an</strong>do, D. B<strong>as</strong>in, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuellar, H<strong>an</strong>kes<br />
P. Drielsma, P. C. Heám, O. Kouchnarenko, J. M<strong>an</strong>tov<strong>an</strong>i, S. Mödersheim,<br />
D. von Oheimb, M. Rusinowitch, J. S<strong>an</strong>tiago, M. Turu<strong>an</strong>i, L. Vig<strong>an</strong>ò, <strong>an</strong>d L. Vigneron.<br />
The AVISPA Tool for the Automated Validation <strong>of</strong> Internet Security<br />
Protocols <strong>an</strong>d Applications. Computer Aided Verification, pages 281–285, 2005.<br />
4. M. Backes, C. Hritcu, <strong>an</strong>d M. Maffei. Automated Verification <strong>of</strong> Remote Electronic<br />
Voting Protocols in the Applied Pi-Calculus. In CSF ’08: Proceedings <strong>of</strong><br />
the 2008 21st IEEE Computer Security Foundations Symposium, pages 195–209,<br />
W<strong>as</strong>hington, 2008. IEEE.<br />
5. M. Baudet, V. Cortier, <strong>an</strong>d S. Delaune. YAPA: A generic tool for computing<br />
intruder knowledge. In Rewriting Techniques <strong>an</strong>d Applications, volume 5595 <strong>of</strong><br />
Lecture Notes in Computer Science, pages 148–163. Springer Berlin / Heidelberg,<br />
2009.<br />
6. S. M. Bellovin <strong>an</strong>d M. Merritt. Encrypted Key Exch<strong>an</strong>ge: P<strong>as</strong>sword-B<strong>as</strong>ed Protocols<br />
Secure Against Dictionary Attacks. In IEEE Symposium on Security <strong>an</strong>d<br />
Privacy, pages 72–84, 1992.<br />
7. B. Bl<strong>an</strong>chet. An Efficient Cryptographic Protocol Verifier B<strong>as</strong>ed on Prolog Rules.<br />
In CSFW ’01: Proceedings <strong>of</strong> the 14th IEEE workshop on Computer Security Foundations,<br />
page 82, W<strong>as</strong>hington, 2001. IEEE.<br />
8. B. Bl<strong>an</strong>chet <strong>an</strong>d A. Chaudhuri. Automated Formal Analysis <strong>of</strong> a Protocol for<br />
Secure File Sharing on Untrusted Storage. In Proceedings <strong>of</strong> the 29th IEEE Symposium<br />
on Security <strong>an</strong>d Privacy (S&P’08), pages 417–431. IEEE, 2008.<br />
9. B. Bl<strong>an</strong>chet <strong>an</strong>d C. Fournet. Automated Verification <strong>of</strong> Selected Equivalences for<br />
Security Protocols. In LICS ’05: Proceedings <strong>of</strong> the 20th Annual IEEE Symposium<br />
on Logic in Computer Science, pages 331–340, W<strong>as</strong>hington, 2005. IEEE.<br />
10. O. Cetinkaya <strong>an</strong>d A. Dog<strong>an</strong>aksoy. A Practical Verifiable e-Voting Protocol for<br />
Large Scale Elections over a Network. In ARES ’07: Proceedings <strong>of</strong> the The Second<br />
International Conference on Availability, Reliability <strong>an</strong>d Security, pages 432–442,<br />
W<strong>as</strong>hington, 2007. IEEE.<br />
11. R. Ch<strong>an</strong>g <strong>an</strong>d V. Shmatikov. Formal Analysis <strong>of</strong> Authentication in Bluetooth<br />
Device Pairing. In 1st International Symposium on Leveraging Applications <strong>of</strong><br />
Formal Methods (ISOLA04), 2007.<br />
12. Y. Chevalier, R. Küsters, M. Rusinowitch, <strong>an</strong>d M. Turu<strong>an</strong>i. Deciding the Security <strong>of</strong><br />
Protocols with Diffie-Hellm<strong>an</strong> Exponentiation <strong>an</strong>d Products in Exponents. In FST<br />
TCS 2003: Foundations <strong>of</strong> S<strong>of</strong>tware Technology <strong>an</strong>d Theoretical Computer Science,<br />
volume 2914 <strong>of</strong> Lecture Notes in Computer Science, pages 124–135. Springer Berlin<br />
/ Heidelberg, 2003.<br />
13. W. F. Clocksin <strong>an</strong>d C. S. Mellish. Programming in Prolog. Springer-Verlag, New<br />
York, NY, USA, 1987.<br />
14. H. Comon-Lundh <strong>an</strong>d V. Cortier. Computational soundness <strong>of</strong> observational equivalence.<br />
In CCS ’08: Proceedings <strong>of</strong> the 15th ACM conference on Computer <strong>an</strong>d<br />
communications <strong>security</strong>, pages 109–118, New York, 2008. ACM.<br />
15. V. Cortier, H. Hördegen, <strong>an</strong>d B. Warinschi. Explicit r<strong>an</strong>domness is not necessary<br />
when modeling probabilistic encryption. Electronic Notes in Theoretical Computer
Science, 186:49 – 65, 2007. Proceedings <strong>of</strong> the First Workshop in Information <strong>an</strong>d<br />
Computer Security (ICS 2006).<br />
16. C.J.F. Cremers. Scyther: Sem<strong>an</strong>tics <strong>an</strong>d Verification <strong>of</strong> Security Protocols. PhD<br />
thesis, Technische Universiteit Eindhoven, 2006.<br />
17. C.J.F. Cremers. The Scyther Tool: Verification, Falsification, <strong>an</strong>d Analysis <strong>of</strong> Security<br />
Protocols. In Computer Aided Verification, 20th International Conference,<br />
CAV 2008, Princeton, USA, Proc., volume 5123/2008 <strong>of</strong> Lecture Notes in Computer<br />
Science, pages 414–418. Springer, 2008.<br />
18. C.J.F. Cremers, P. Lafourcade, <strong>an</strong>d P. Nadeau. Comparing State Spaces in Automatic<br />
Protocol Analysis. In Formal to Practical Security, volume 5458/2009 <strong>of</strong><br />
Lecture Notes in Computer Science, pages 70–94. Springer Berlin / Heidelberg,<br />
2009.<br />
19. T. Dierks <strong>an</strong>d E. Rescorla. The Tr<strong>an</strong>sport Layer Security (TLS) Protocol Version<br />
1.2. RFC 5246 (Proposed St<strong>an</strong>dard), August 2008.<br />
20. W. Diffie <strong>an</strong>d M. E. Hellm<strong>an</strong>. New directions in cryptography. IEEE Tr<strong>an</strong>sactions<br />
on Information Theory, 22(6):644–654, 1976.<br />
21. D. Dolev <strong>an</strong>d A. C. Yao. On the <strong>security</strong> <strong>of</strong> public key <strong>protocol</strong>s. Foundations <strong>of</strong><br />
Computer Science, Annual IEEE Symposium on, 0:350–357, 1981.<br />
22. A. J. Feldm<strong>an</strong>, J. A. Halderm<strong>an</strong>, <strong>an</strong>d E. W. Felten. Security <strong>an</strong>alysis <strong>of</strong> the diebold<br />
AccuVote-TS voting machine. In EVT’07: Proceedings <strong>of</strong> the USENIX Workshop<br />
on Accurate Electronic Voting Technology, page 2, Berkeley, 2007. USENIX Association.<br />
23. C. Fournet <strong>an</strong>d M. Abadi. Hiding names: Private authentication in the applied<br />
pi calculus. In S<strong>of</strong>tware Security - Theories <strong>an</strong>d Systems, volume 2609 <strong>of</strong> Lecture<br />
Notes in Computer Science, pages 317–338. Springer-Verlag, 2003.<br />
24. M. Jakobsson <strong>an</strong>d S. Wetzel. Security Weaknesses in Bluetooth. In CT-RSA<br />
2001: Proceedings <strong>of</strong> the 2001 Conference on Topics in Cryptology, pages 176–191,<br />
London, 2001. Springer-Verlag.<br />
25. H. Khur<strong>an</strong>a <strong>an</strong>d H. Hahm. Certified mailing lists. In ASIACCS ’06: Proceedings <strong>of</strong><br />
the 2006 ACM Symposium on Information, computer <strong>an</strong>d communications <strong>security</strong>,<br />
pages 46–58, New York, 2006. ACM.<br />
26. T. Kohno <strong>an</strong>d A. Stubblefield. Analysis <strong>of</strong> <strong>an</strong> electronic voting system. In IEEE<br />
Symposium on Security <strong>an</strong>d Privacy, pages 27–40, 2004.<br />
27. S. Kremer <strong>an</strong>d M. Ry<strong>an</strong>. Analysis <strong>of</strong> <strong>an</strong> Electronic Voting Protocol in the Applied<br />
Pi Calculus. In In Proc. 14th Europe<strong>an</strong> Symposium On Programming (ESOP05),<br />
volume 3444 <strong>of</strong> LNCS, pages 186–200. Springer, 2005.<br />
28. R. Küsters <strong>an</strong>d T. Truderung. Reducing <strong>protocol</strong> <strong>an</strong>alysis with XOR to the XORfree<br />
c<strong>as</strong>e in the Horn theory b<strong>as</strong>ed approach. In CCS ’08: Proceedings <strong>of</strong> the 15th<br />
ACM conference on Computer <strong>an</strong>d communications <strong>security</strong>, pages 129–138, New<br />
York, 2008. ACM.<br />
29. R. Küsters <strong>an</strong>d T. Truderung. Using ProVerif to Analyze Protocols with Diffie-<br />
Hellm<strong>an</strong> Exponentiation. Computer Security Foundations Symposium, IEEE,<br />
0:157–171, 2009.<br />
30. P. Lafourcade, V. Terrade, <strong>an</strong>d S. Vigier. Comparison <strong>of</strong> cryptographic verification<br />
tools dealing with algebraic properties. In Pierpaolo Deg<strong>an</strong>o Joshua Guttm<strong>an</strong>,<br />
editor, 6th International Workshop on Formal Aspects in Security <strong>an</strong>d Trust,<br />
(FAST’09), Eindhoven, nov 2009.<br />
31. T. Loong. Underst<strong>an</strong>ding sensitivity <strong>an</strong>d specificity with the right side <strong>of</strong> the brain.<br />
BMJ, 327(7417):716–719, 2003. http://www.bmj.com.<br />
32. G. Lowe. C<strong>as</strong>per: a compiler for the <strong>an</strong>alysis <strong>of</strong> <strong>security</strong> <strong>protocol</strong>s. J. Comput.<br />
Secur., 6(1-2):53–84, 1998.
33. C. Meadows. A Model <strong>of</strong> Computation for the NRL Protocol Analyzer. In Proceedings<br />
<strong>of</strong> the 7th Computer Security Foundations Workshop, pages 84–89, Los<br />
Alamitos, 1994. IEEE.<br />
34. A. J. Menezes, S. A. V<strong>an</strong>stone, <strong>an</strong>d P. C. V<strong>an</strong> Oorschot. H<strong>an</strong>dbook <strong>of</strong> Applied<br />
Cryptography. CRC Press, Inc., Boca Raton, 1996.<br />
35. J. K. Millen, S. C. Clark, <strong>an</strong>d S. B. Freedm<strong>an</strong>. The Interrogator: Protocol Security<br />
Analysis. IEEE Tr<strong>an</strong>s. S<strong>of</strong>tware Eng., 13(2):274–288, 1987.<br />
36. D. K. Nilsson, U. E. Larson, <strong>an</strong>d E. Jonsson. Auxiliary ch<strong>an</strong>nel Diffie-Hellm<strong>an</strong><br />
encrypted key-exch<strong>an</strong>ge authentication. In QShine ’08: Proceedings <strong>of</strong> the 5th International<br />
ICST Conference on Heterogeneous Networking for Quality, Reliability,<br />
Security <strong>an</strong>d Robustness, pages 1–8, Brussel, 2008. ICST.<br />
37. L. C. Paulson. The inductive approach to verifying cryptographic <strong>protocol</strong>s. Journal<br />
<strong>of</strong> computer <strong>security</strong>, 6(1-2):85–128, 1998.<br />
38. A. D. Rubin. Security considerations for remote electronic voting. Commun. ACM,<br />
45(12):39–44, 2002.<br />
39. D. Song. Athena: a New Efficient Automatic Checker for Security Protocol Analysis.<br />
Computer Security Foundations Workshop, IEEE, 0:192, 1999.