A review of Proverif as an automatic security protocol verifier

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].