Privacy-Preserving Messaging Formal Verification

Privacy-Preserving Messaging Formal Verification

NEXt generation Techno-social Legal Encryption Access and Privacy nextleap.eu Grant No. 688722. Project started 2016-01-01. Duration 36 months. DELIVERABLE D4.3 PRIVACY PRESERVING MESSAGING FORMAL MODELLING Karthikeyan Bhargavan, Bruno Blanchet, Iness Ben Guirat, Harry Halpin, Benjamin Lipp, Nadim Kobeissi (INRIA) Beneficiaries: INRIA (lead) Workpackage:4 Description: Models of messaging protocols from WP2 with respect to a number of possible primitives for properties related to decentralization,privacy, security, and anonymity. Version: 1.0 Nature: Report (R) Dissemination level: Public (PU) Pages: 107 Date: 2018-12-31 Project co-funded by the European Commission within the Horizon 2020 Programme. D4.2 NEXTLEAP Grant No. 688722 Contents Executive Summary 3 1 Introduction 4 2 W3C Web Authentication (Authentication) 5 3 Signal Protocol (Synchronous Messaging) 22 4 Noise (Network-level Encryption) 58 5 Wireguard (VPN) 83 2 D4.2 NEXTLEAP Grant No. 688722 Executive Summary In this deliverable, we present the results of formally verifying various protocols relevant to privacy-preserving messaging. In general, we verify their security properties, although consideration is taken if possible on privacy and anonymity although these two latter properties are hard to verify with the current toolset. We focus on ProVerif, veriying under the Dolev-Yao symbolic model in order to discover if a protocol is secure, and we also present some new work using CryptoVerif, which creates computational proofs. We detail the verificaton of the W3C Web Authentication API, the Signal Protocol, the Noise Protocol Framework, and the Wireguard VPN. 3 D4.2 NEXTLEAP Grant No. 688722 1 Introduction NEXTLEAP has four main technical components: federated identity, e-mail (originally entitled “asynchronous messaging” although used by Delta.chat for instant messaging), secure messaging (originally entitled “syn- chronous messaging” although secure messaging protocols like Signal and MLS now handle messages in the synchronous setting, just not backwards compatible with e-mail), and privacy-enhancing analytics. The formal verification of federated identity project ClaimChain was already given in D4.1 via its specification in F. The initial ProVerif model of PGP was given D2.3, detecting the authentication attacks that are inherited in Autocrypt. The Message Layer Security Protocol) was described as well in D2.3, and work on its formal specification is still ongoing in F as the standard matures. Due to the statistical nature of the “wisdom of the crowds” analytics, it cannot be formally verified with current tools. Therefore, this deliverable focuses on the completed formal verification work on security (and if possible, privacy, and anonymity) properties done during NEXTLEAP on the fundamental building blocks of secure messaging: Secure authentication, the Signal Protocol, network-level encryption, and VPN primitives (which in our case are a subset of network level encryption. These components, which are vital parts of messaging and will be likely deployed in conjunction with the IETF MLS standard and Autocrypt. These components and their relationship to various protocols are detailed below: W3C Web Authentication (Authentication): One component that is vital for all authentication systems is • to identify the user. However, this act of authentication is typically done via passwords, and is out of scope of the Autocrypt and MLS work. Of course, the possession of a key is assumed to be part of the federated identity system of Claimchain, as well as in Autocrypt and MLS. However, how key material is used to authenticate to an actual messaging system is left undefined. A new standard, W3C Web Authentication, defines a new protocol for using key material, such as those stored in smart cards, to authenticate. This protocol was modelled for security and privacy with considerations on using DAA (Direct Anonymous Authentication) in the Masters thesis of Iness Ben Guirat at Inria, under the supervision of Harry Halpin. We found the handshake to be secure, but there to be possible violations of privacy due to the re-use of device-specific key material by the user. Signal Protocol (Synchronous Messaging): The entire NEXTLEAP project is inspired by the rise of • end-to-end encryption, but the actual popular Signal protocol for messaging was not formally specified. This protocol, which inspired the work on MLS and the modernization of encrypted email of Autocrypt, was formally verified in Proverif by Nadim Kobeissi as part of his Ph.D. dissertation at Inria under the supervision of Bruno Blanchet and Karthik Bhargavan. This work revealed an unknown key share attack. Noise (Network-level Encryption): Most websites and e-mail based protocols like PGP-based Autocrypt • use TLS, but for point to point communication, there are much simpler and less complex Diffie-Hellman handshake-based protocols that can be used. The Noise protocol specifies a framework for specifying these protocols, and WhatsApp uses one of the Noise Protocol frameworks. Never before verified, the security of most of the Noise Protocol framework was formally verified in Proverif by Nadim Kobeissi at Inria under the supervision of Karthik Bhargavan. Wireguard (VPN): One of the Noise protocol handshakes for network-level encryption forms the basis • of Wireguard, a new VPN protocol. This VPN protocol is compatible with any network traffic, including Autocrypt, MLS, and more. This was formally verified in the Masters thesis of Benjamin Lipp at Inria under the supervision of Bruno Blanchet, Karthik Bhargavan, and Harry Halpin. 4 D4.2 NEXTLEAP Grant No. 688722 2 W3C Web Authentication (Authentication) 5 Deliverable D4.2 NEXTLEAP Grant No. 688722 1 Introduction For security to be a science, methodologies that can scientifically guarantee security and privacy properties such as formal verification need to be applied consistently to security issues. One of the largest problems damaging the security of modern information systems is the inability of users to generate and consistently use unique high-entropy passwords per domain. Fundamentally the entire idea of a password as symmetric secret for authentication is in need of replacement by asymmetric cryptography. In this paper, a proposed standard for public-key authentication, W3C Web Authentication, is analyzed using the formal verification. After describing the state of the art of formal verification in Section 2, we describe the background of the issue of authentication and the development of the W3C Web Authentication protocol in Section 3. In Section 4, each step of the W3C Web Authentication protocol is informally described. Using the formal verification tool ProVerif described in Section 5, we automatically formally verify the security properties of W3C Web Authentication in Section 6 and prove that the claimed privacy properties of W3C Web Authentication can be violated. A range of fixes outlined but not mandatory in the specification, such as the use of Direct Anonymous Authentication, are described in Section 7 and next steps for the scientific application of formal verification in terms of future protocols in Section 8. 2 The Science of Security and Formal Verification Security has far too long been viewed as a black art based more on intuition than science, with protocols and cryptographic primitives often judged due to the reputation of their creator.1 In contrast, by definition a science of security would place the security properties of techno-social systems on a scientific basis, including cryptographic primitives, the composition of those primitives into cryptographic protocols, and the embedding of these protocols into user behavior and the wider social world. This is a demanding task, and formal approaches have allowed tremendous amount of progress in the formal definition and verification of security properties [1]. Formalized game-hopping proofs have put the field of cryptography on a sound basis and can work over protocols of considerable complexity, but there exists still much work to be done to put this methodology into production for protocols. Although manual proofs for protocols do exist, even if specified in formal detail, complex protocols have large state spaces where a move in the protocol that was not foreseen by the designers may lead to the security properties of the entire protocol being violated. The classic example is that of the Needham-Shroeder protocol [2], whose security flaws were only discovered more than twenty years afterwards using formal methods [3]. A science demands a methodology and the methodology of formal verification tools provides a promising path for the verification of the security properties, and even privacy properties, of cryptographic primitives and protocols. Formal verification is the creation and checking of the properties of a cryptographic protocol or primitive not via proofs constructed by hand, but by proofs constructed in a fully mechanized manner. This is necessary as often the manual construction of proofs may, by sheer human accident, miss either seemingly routine aspects of the protocols that may violate their security and privacy properties, or that the level of complexity of the protocol is so such that the number of states that need to be inspected by hand are far greater than are possible within a reasonable amount of time. In modern protocols like TLS 1.2, it is precisely these kinds of obscure errors, such as the “triple handshake” renegotiation attack caused by complexity that were discovered via formal analysis [4]. While

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    107 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us