A review of Proverif as an automatic security protocol verifier

Recommendations

Info

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
Page 1 and 2: A review of ProVerif as an automati
Page 3 and 4: ProVerif uses the concept of a Horn
Page 5 and 6: 3 Practical applications The verifi
Page 7: Bluetooth 2.1. In Bluetooth 2.1, Si
Page 11 and 12: Most existing protocol verifiers ba
Page 13 and 14: 5.3 Usability To our knowledge, no
Page 15 and 16: References 1. M. Abadi. Security Pr
Page 17: 33. C. Meadows. A Model of Computat

A review of Proverif as an automatic security protocol verifier

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?