A review of Proverif as an automatic security protocol verifier

Recommendations

Info

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.
Page 1 and 2: A review of ProVerif as an automati
Page 3 and 4: ProVerif uses the concept of a Horn
Page 5: 3 Practical applications The verifi
Page 9 and 10: have also published a tool, XOR-Pro
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

Create successful ePaper yourself

Delete template?

Save as template?