Keywords:

Individuals and organizations are increasingly relying on the Web and on userfacing applications for use cases such as online banking, secure messaging, document sharing and electronic voting. To protect the confidentiality and integrity of these communications, these systems depend on authentication and authorization protocols, on application-level cryptographic constructions and on transport-layer cryptographic protocols. However, combining these varied mechanisms to achieve high-level security goals is error-prone and has led to many attacks even on sophisticated and well-studied applications.

This thesis aims to develop methods and techniques for reasoning about, designing and implementing cryptographic protocols and secure application components relevant to some of the most frequently used cryptographic protocols and applications. We investigate and formalize various notions of expected guarantees and evaluate whether some of the most popular secure channel protocols, such as secure messaging protocols and transport protocols often operating at the billion-user scale, are capable of meeting these goals.

In this thesis, we ask: can existing major paradigms for formal protocol verification serve as guidelines for the assessment of existing protocols, the prototyping of protocols being designed, and the conception of entirely new protocols, in a way that is meaningful and reflective of their expected real-world properties? And can we develop novel frameworks for formal verification and more secure implementation based on these foundations?

We propose new formal models in both symbolic and computational formal verification frameworks for these protocols and applications. In some of the presented work, we obtain a verification methodology that starts from the protocol and ends at the implementation code. In other parts of our work, we develop a dynamic framework for generating formal verification models for any secure channel protocol described in a lightweight syntax. Ultimately, this thesis presents formal verification approaches for existing protocols reaching towards their implementation as well as methods for prototyping and formally verifying new protocols as they are being drafted and designed.

of yet another big thesis to read and are even more apprehensive about it after reading this warm, fuzzy essay, I can promise you cookies at the defense.

As for Karthik, what I owe him is beyond evaluation.

1

There is always some madness in love. But there is also always some reason in madness. And those who were seen dancing were thought to be insane by those who could not hear the music. Being able to work on this research at INRIA has been the most essential opportunity that I have been given in my life. Furthermore, no more essential opportunity will ever arise in my life, since my future will undeniably be rooted in what I've been allowed to work on at INRIA, in the researchers of INRIA taking me in and teaching me the posture and adroitness necessary for good research.

Being at INRIA has taught me much more than the proper formal analysis of cryptographic protocols. It taught me just how difficult and uncompromising true scientific rigor can be and the importance of a diligent and forward-looking work ethic. It also taught me patience, helped me expand my perspective with regards to the viewpoints of others and my sense of good faith during teamwork. It helped me mature into someone less sure of his intuition while nevertheless radically strengthening that intuition in the same process. The researchers at INRIA are part of an institution that morally and intellectually is larger than life, where the bottom line, the net product ends up being uncompromising research pushed forward with equal amounts of passion and prudence. I hope that I can carry with me what I've been given at INRIA by imparting the insights of what I've been able to work on and the values that determine how the work is to be done.

Most of the contributions herein that can be considered my own are largely due to my acting as a sort of highly opinionated melting pot for Karthik's decades-long vision for Web security, Antoine's first explaining to me that, in F , "types are proofs", Bruno's unnerving, laser-like focus and rigor -I could go on to cover every member of the PROSECCO research group in words that seem inflated but aren't really. Being at INRIA taught me how to think. Working with these people taught me more than I could have ever learned on my own and made me into more than I could have hoped to become.

I am also deeply grateful for Cedric and Antoine's hosting me at Microsoft Research for the duration of my internship and most of all for actually letting me call my internship project "QuackyDucky", even keeping that name after integrating it into the Project Everest stack well after my departure. I would have never received this opportunity were it not for the trust and good faith that Graham, Harry and Philippe put in me during my first year. Their confidence was pivotal in my being given a chance to learn how to do actual science.

Regarding the thesis committee, who likely already groaned at the prospect

Introduction

End-to-end encryption is increasingly becoming a staple in the security considerations of user-facing services, applications and communications infrastructure. Even during the period in which the work within this thesis was being prepared, things have changed: almost all of the world's most popular instant messengers adopted end-to-end encryption protocols targeting advanced security goals such as forward secrecy. Endpoint authentication for a majority of the secure web adopted a radically different (and for the first time, automated) protocol with the launch of Let's Encrypt. HTTPS, the framework underlying much of the secure Web, went from being based on a relatively hacked-together version of the Transport Layer Security (TLS) standard to upgrading to a protocol that was, for the first time, designed hand in hand with cryptographers and academics since its inception. And, as we have seen, wide-eyed venture capitalists put millions of dollars into programs running on an unverified state machine on top of an experimental blockchain.

A microcosm within this massive shift into ubiquitous, real-world cryptographic systems has been the involvement of formal methods and analysis of the underlying cryptography. When work on this thesis began, Signal, the current de-facto standard for secure messaging, which today encrypts daily communications between more than a billion people worldwide, did not even benefit from a public technical (let alone formal) specification. TLS 1.2, the then-latest production standard for HTTPS connections, continued in the vein of the "code first, verify later" methodology that had underpinned all previous versions of the standard.

Much of this thesis chronicles the involvement of formal verification methods as they apply to cryptographic protocols and implementations: as of 2015, it had become abundantly clear that practical, applied security systems suffered from problems of rigor in both protocol design and implementation that were resulting in all kinds of bugs, from state machine implementation errors and broken cryptographic primitives, all the way up to fundamentally flawed protocol blueprints. Perhaps the most self-contained motivating example for the necessity of practically relevant formal verification came in an increasingly large repertoire 1 of problems with TLS ranging from low-level implementation errors to fundamental protocol design problems, all of which were either detected using, 12 CHAPTER 0. INTRODUCTION or would have been avoided with, formal verification approaches.

New formal approaches present in TLS 1.3 came hot on the heels of multiple analyses of TLS 1.2 and earlier, showing implementation issues as well as protocol-level design flaws. And as we show in this thesis, TLS 1.3 still itself had issues that became apparent with formal verification, even 18 drafts into the standardization process. The silver lining is that we were able to monitor TLS 1.3 for security regressions draft after draft because our formal verification frameworks had become practical enough to be used for formally describing, verifying and thereby prototyping the standard as it evolved, which is likely a milestone in bridging the gap between formal verification and real-world cryptographic systems.

Bridging this gap is ultimately what this thesis is all about. Can existing major paradigms for formal protocol verification serve as guidelines for the assessment of existing protocols, the prototyping of protocols being designed, and the conception of entirely new protocols, in a way that is meaningful and reflective of their expected real-world properties? And can we develop novel frameworks for formal verification and more secure implementation based on these foundations?

As much as I'd like to stay dry and deafen you with the silence of my academicism, I'd rather describe this thesis for what it really is: a The Hobbit-esque journey of a Ph.D. student who started off woefully unprepared, most of all for his own thirst for adventure. This thesis is a diplomatic treaty between protocol engineers and mathematicians focused on formal methods. This thesis started off as a shot in the dark, but by the time the dragon was slain, the treasure taken and home was found again, the work within it became something that could contend as a serious treatise on how formal verification can matter.

So, join me as I recount my adventure! Together, we will wander through the caves, mountains and valleys of my attempts to apply formal verification to every worthwhile cryptographic protocol with real-world implications over the past three years. Starting with the Signal secure messaging protocol, continuing on to TLS, to the Noise Protocol Framework, to Let's Encrypt and then finally to the unexplored new marshes of a new secure collaborative document editing protocol. What strange new JavaScript-based formal verification techniques will we discover along the way? What surprising results await? And, most importantly, which mathematical notation mistake will escape the eyes of all reviewers and make it into the final thesis draft? Who knows? You can!

Cryptographic Protocols and Systems that We Consider

In developing this work, we have tried to focus on real-world use cases as the context that underlies research efforts. We have decided to focus on user-facing protocols and systems with the highest number of users and which we believe are the most fundamental to secure communication on the modern Web.

Secure Messaging

Secure messaging today occupies a central position in real-world cryptography, primarily due to the deployment of secure messaging systems in Apple iMessage, Google Allo, Microsoft Skype, Telegram, WhatsApp [START_REF]WhatsApp encryption overview[END_REF], Wire and many other platforms, ultimately meaning that the majority of instant messaging communication is indeed end-to-end encrypted [START_REF] Unger | SoK: Secure messaging[END_REF]. With the exception of Apple iMessage and Telegram, all of the examples mentioned above use the same foundation for their secure messaging cryptography: the Signal Protocol [START_REF] Perrin | The X3DH key agreement protocol[END_REF][START_REF] Perrin | The double ratchet algorithm[END_REF]. 2 Signal Protocol offered an open source foundation for modern secure messaging with features that, at least in 2015, indicated innovative protocol design with ambitious security guarantees that also addresses new secure messaging corner cases inherent to smartphones, such as initializing a secure session with a party who may be offline at the time the first message is sent (thereby mimicking the SMS use case scenario.) However, secure messaging had been in development for more than a decade prior to Signal Protocol. Perhaps the earliest serious secure messaging effort that produced a robust, well-studied protocol with a usable implementation was the Off-the-Record protocol, or OTR [START_REF] Borisov | Off-the-record communication, or, why not to use PGP[END_REF], introduced in 2004. OTR was designed before the advent of smartphones and therefore was not interested in asynchronous session establishment: establishing an OTR session required one and a half round trips. Key rotation was slow and heavy, requiring messages to be exchanged by both parties. Due to relatively large public keys, message size was also not restricted in any meaningful way.

While OTR came with a technical specification and a research paper justifying its design decisions, a 2006 security analysis by Bonneau and Morison [START_REF] Bonneau | Finite State Security Analysis of OTR Version 2[END_REF] still found serious vulnerabilities in OTR version 2, including a simple attack that could break message authenticity simply by delaying when messages are received.

Future versions of OTR fixed these issues and improved on the protocol more generally. In fact, the first version of the Signal messenger 3 used OTR as its foundation for secure messaging, taking care to use more modern primitives in order to facilitate the exchange of public key information over SMS, but otherwise leaving the protocol more or less intact.

However, OTR's porting over to the SMS use case did not go over smoothly. In regular SMS usage, Alice can send a text to Bob while Bob's phone is off, only for him to receive this message a week later when he finally turns on his 2 Academic study of secure messaging protocols has largely focused on Signal Protocol due to its strong security goals, which include forward secrecy and post-compromise security, its open source implementation and its protocol design with includes a zero-round-trip session establishment. In Chapter 1, we briefly examine (and find attacks) in Telegram's "MTProto" protocol. Other secure messaging protocols have not generally received academic attention. Apple's iMessage protocol was subjected to some scrutiny by Garman et al. [START_REF] Garman | Dancing on the lip of the volcano: Chosen ciphertext attacks on apple imessage[END_REF] but similarly receives little review due to its closed source implementation and lack of any technical specification. 3 Initial versions of Signal were called "TextSecure". However, we will refer to Signal as Signal for the remainder of this work in the interest of simplicity. CHAPTER 0. INTRODUCTION phone. In initial versions of Signal, this was impossible: a round-trip handshake was required in order to establish a secure session, thereby necessitating that both sides be online and able to send and receive SMS messages for a little while before actually being able to maintain a confidential messaging session.

Ultimately, the less-than-ideal nature of SMS as a transport layer forced Signal to adopt multiple changes and compromises to its original implementation of OTR: SMS also has a 140-character limit per message and users may incur variable charges and experience variable rates of reliability and message delivery delays worldwide. Eventually, this led to the development of what would become Signal Protocol, a protocol which focused on the ability to establish secure sessions, and to rotate encryption keys, with the minimum amount of message exchanges necessary. The X3DH authenticated key exchange [START_REF] Perrin | The X3DH key agreement protocol[END_REF] and Double Ratchet [START_REF] Perrin | The double ratchet algorithm[END_REF] 4 that resulted from these use case demands targeted ambitious security guarantees but often were deployed in production prematurely and with little study: Rösler et al [START_REF] Rösler | More is less: On the end-to-end security of group chats in signal, whatsapp, and threema[END_REF] showed that Signal Protocol's group chat deployment was underspecified and exposed to different vulnerabilities across multiple platforms. Signal's desktop application, which was built on top of the Web-based Electron framework, was also the subject of multiple security vulnerabilities [START_REF] Armasu | Signal desktop affected by two similar remote code execution bugs[END_REF][START_REF] Dunn | Serious xss vulnerability discovered in signal[END_REF] largely facilitated by the difficulty inherent to writing secure code for Web applications.

While some of the research cited above occured after we had completed and published our own research on secure messaging, it was that zeitgeist that informed our research approach and our priorities. In this thesis, therefore, we have focused significantly on the formal analysis of secure messaging protocols in different formal models, as well as securely implementing these protocols specifically in the context of high-assurance Web applications.

Transport Layer Security

The Transport Layer Security (TLS) protocol is widely used to establish secure channels on the Internet. It was first proposed under the name SSL [START_REF] Hickman | The SSL protocol[END_REF] in 1994 and has undergone a series of revisions since, leading up to the standardization of TLS 1.2 [START_REF] Dierks | The Transport Layer Security (TLS) Protocol Version 1.2[END_REF] in 2008. Each version adds new features, deprecates obsolete constructions and introduces countermeasures for weaknesses found in previous versions. The behavior of the protocol can be further customized via extensions, some of which are mandatory to prevent known attacks on the protocol.

One may expect that TLS clients and servers would use only the latest version of the protocol with all security-critical extensions enabled. In practice, however, many legacy variants of the protocol continue to be supported for backwards compatibility and the everyday use of TLS depends crucially on clients and servers negotiating the most secure variant that they have in common. Securely composing and implementing the many different versions and features of TLS has proved to be surprisingly hard, leading to the continued discovery of high-profile vulnerabilities in the protocol.

A History of TLS Vulnerabilities

TLS has traditionally suffered from mainly four different types of weaknesses and vulnerabilities:

• Downgrade attacks enable a network adversary to fool a TLS client and server into using a weaker variant of the protocol than they would normally use with each other. In particular, version downgrade attacks were first demonstrated from SSL 3 to SSL 2 [START_REF] Wagner | Analysis of the SSL 3.0 protocol[END_REF] and continue to be exploited in recent attacks like POODLE [START_REF] Möller | This POODLE bites: exploiting the SSL 3.0 fallback[END_REF] and DROWN [START_REF] Aviram | DROWN: breaking TLS using SSLv2[END_REF].

• Cryptographic vulnerabilities rely on weaknesses in the protocol constructions used by TLS. Recent attacks have exploited key biases in RC4 [START_REF] Alfardan | On the security of RC4 in TLS[END_REF][START_REF] Vanhoef | All your biases belong to us: Breaking RC4 in WPA-TKIP and TLS[END_REF], padding oracles in MAC-then-Encrypt [START_REF] Nadhem | Lucky thirteen: Breaking the TLS and DTLS record protocols[END_REF][START_REF] Möller | This POODLE bites: exploiting the SSL 3.0 fallback[END_REF], padding oracles in RSA PKCS#1 v1.5 [START_REF] Aviram | DROWN: breaking TLS using SSLv2[END_REF], weak Diffie-Hellman groups [START_REF] Adrian | Imperfect forward secrecy: How Diffie-Hellman fails in practice[END_REF] and weak hash functions [START_REF] Bhargavan | Transcript collision attacks: Breaking authentication in TLS, IKE, and SSH[END_REF].

• Protocol composition flaws appear when multiple modes of the protocol interact in unexpected ways if enabled in parallel. For example, the renegotiation attack [START_REF] Rescorla | TLS renegotiation indication extension[END_REF] exploits the sequential composition of two TLS handshakes, the Triple Handshake attack [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF] composes three handshakes and cross-protocol attacks [START_REF] Mavrogiannopoulos | A cross-protocol attack on the TLS protocol[END_REF][START_REF] Wagner | Analysis of the SSL 3.0 protocol[END_REF] use one kind of TLS handshake to attack another.

• Implementation bugs contribute to the fourth category of attacks on TLS, and are perhaps the hardest to avoid. They range from memory safety bugs like HeartBleed and coding errors like GotoFail to complex state machine flaws. Such bugs can be exploited to bypass all the security guarantees of TLS and their prevalence, even in widely-vetted code, indicates the challenges of implementing TLS securely.

Security Proofs

Historically, when an attack is found on TLS, practitioners propose a temporary fix that is implemented in all mainstream TLS libraries, then a longer-term countermeasure is incorporated into a protocol extension or in the next version of the protocol. This has led to a attack-patch-attack cycle that does not provide much assurance in any single version of the protocol, let alone its implementations. An attractive alternative would have been to develop security proofs that systematically demonstrated the absence of large classes of attacks in TLS. However, developing proofs for an existing standard that was not designed with security models in mind is exceedingly hard [START_REF] Kenneth | Reactive and proactive standardisation of TLS[END_REF]. After years of effort, the cryptographic community only recently published proofs for the two main components of TLS: the record layer that implements authenticated encryption [START_REF] Maurer | On the soundness of authenticate-thenencrypt: formalizing the malleability of symmetric encryption[END_REF][START_REF] Kenneth G Paterson | Tag size does matter: Attacks and proofs for the TLS record protocol[END_REF] and the handshake layer that composes negotiation and key-exchange [START_REF] Jager | On the security of TLS-DHE in the standard model[END_REF][START_REF] Krawczyk | On the security of the TLS protocol: A systematic analysis[END_REF]. These proofs required new security definitions and custom cryptographic assumptions and even so, they apply only to abstract models of certain modes of the protocol.

CHAPTER 0. INTRODUCTION

For example, the proofs do not account for low-level details of message formats, downgrade attacks, or composition flaws. Since such cryptographic proofs are typically carried out by hand, extending the proofs to cover all these details would require a prohibitive amount of work and the resulting large proofs themselves would need to be carefully checked.

A different approach taken by the protocol verification community is to symbolically analyze cryptographic protocols using simpler, stronger assumptions on the underlying cryptography, commonly referred to as the Dolev-Yao model [START_REF] Dolev | On the security of public key protocols[END_REF]. Such methods are easy to automate and can tackle large protocols like TLS in all their gory detail, and even aspects of TLS implementations [START_REF] Chaki | Aspier: An automated framework for verifying security protocol implementations[END_REF][START_REF] Bhargavan | Verified cryptographic implementations for TLS[END_REF]. Symbolic protocol analyzers are better at finding attacks, but since they treat cryptographic constructions as perfect black boxes, they provide weaker security guarantees than classic cryptographic proofs that account for probabilistic and computational attacks.

The most advanced example of mechanized verification for TLS is the ongoing miTLS project [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF], which uses dependent types to prove both the symbolic and cryptographic security of a TLS implementation that supports TLS 1.0-1.2, multiple key exchanges and encryption modes, session resumption, and renegotiation. Popular Internet protocols such as SSH and TLS use similar cryptographic primitives: symmetric primitives, public key primitives, one-way hash functions and so forth. Protocol stages are also similarly organized, usually beginning with a authenticated key exchange (AKE) stage followed by a messaging stage. And yet, the design methodology, underlying state machine transitions and key derivation logic tend to be entirely different between protocols with nevertheless similar building blocks. The targeted effective security goals tend to be similar, so why can't the same methodology be followed for everything else?

Noise Protocol Framework

Standard protocols such as those mentioned above choose a specific set of key exchange protocols to satisfy some stated use-cases while leaving other elements, such as round trips and (notoriously) cipher suites up to the deployer. Specifications use protocol-specific verbose notation to describe the underlying protocol, to the extent that even extracting the core cryptographic protocol becomes hard, let alone analyzing and comparing different modes for security.

Using completely different methodologies to build protocols that nevertheless often share the same primitives and security goals is not only unnecessary, but provably dangerous. The Triple Handshake attack on TLS published in 2014 [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF] is based on the same logic that made the attack [START_REF] Lowe | An attack on the needham-schroeder public-key authentication protocol[END_REF] on the Needham-Schroeder protocol [START_REF] Roger | Using encryption for authentication in large networks of computers[END_REF] possible almost two decades earlier. The core protocol in TLS 1.2 was also vulnerable to a similar attack, but since the protocol itself is hidden within layers of packet formats and C-like pseudocode, it was difficult for the attack to be detected. However, upon automated symbolic verification [START_REF] Bhargavan | Verified contributive channel bindings for compound authentication[END_REF], the attack quickly appeared not just in TLS, but also in variants of SSH and IPsec. Flaws underlying more recent attacks such as Logjam [START_REF] Adrian | Imperfect forward secrecy: How Diffie-Hellman fails in practice[END_REF] were known for years before they were observed when the vulnerable protocol was analyzed. Had these protocols differed only in terms of network messages while still using a uniform, formalized logic for internal key derivation and state machine transitioning designed based on the state of the art of protocol analysis, these attacks could have been avoided.

The Noise Protocol Framework [START_REF] Perrin | The Noise protocol framework[END_REF], recently introduced by Trevor Perrin, aims to avert this problem by presenting a simple language for describing cryptographic network protocols. In turn, a large number of semantic rules extend this simple protocol description to provide state machine transitions, key derivation logic and so on. The goal is to obtain the strongest possible effective security guarantees for a given protocol based on its description as a series of network messages by deriving its other elements from a uniform, formally specified logic followed by all protocol designs.

In designing a new secure channel protocol using the Noise Protocol Framework, one only provides an input using the simple language shown in Fig. 3.1. As such, from the viewpoint of the protocol designer, Noise protocols can only differ in the number of messages, the types of keys exchanged and the sequence or occurrence of public key transmissions and Diffie-Hellman operations. Despite the markedly non-expressive syntax, however, the occurence and position of the "tokens" in each message pattern can trigger complex state machine evolutions for both parties, which include operations such as key derivation and transcript hash mixing.

Let's examine Fig. 1. Before the AKE begins, the responder shares his static public key. Then in the first protocol message, the initiator sends a fresh ephemeral key, calculates a Diffie-Hellman shared secret between her ephemeral key and the recipient's public static key (es), sends her public static key and finally calculates a Diffie-Hellman shared secret between her static key and the responder's public static key (ss). The responder then answers by generating an ephemeral key pair and sending his ephemeral public key, deriving a Diffie-Hellman shared secret between his ephemeral key and the ephemeral key of the initiator (ee) and another Diffie-Hellman shared secret between his static key and the ephemeral key of the initiator (es). Both of these AKE messages can also contain message payloads, which, depending on the availability of sufficient key material, could be AEAD-encrypted (in this particular Noise Handshake Pattern, this is indeed the case.)

As we can see, quite a few operations have occurred in what would at first glance appear to be simple syntax for a simple protocol. Indeed, underlying CHAPTER 0. INTRODUCTION these operations is a sophisticated state machine logic tasked with mixing all of the derived keys together, determining when it is safe (or possible) to send encrypted payloads and ensuring transcript consistency, among other things. This is the value of the Noise Protocol Framework: allowing the protocol designer to describe what they need their protocol to do fairly effectively using this simple syntax and leaving the rest to a sturdy set of underlying rules.

Automated Domain Name Validation

Since the dawn of HTTPS, being able to secure a public website with SSL or TLS requires obtaining a signature for the website's public certificate from a certificate authority [START_REF] Chokhani | Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework[END_REF] (CA). All major operating system and browser vendors maintain lists of trusted CAs (represented by their root certificates) that can legitimately attest for a reasonable link between a certificate and the identity of the server or domain it claims to represent.

For example, all major operating systems and browsers include and trust Symantec's root certificates, which allows Alice to ask Symantec to attest that the certificate she uses on her website AliceShop.com has indeed been issued to her, rather than to an attacker trying to impersonate her website. After Alice pays Symantec some verification fee, Symantec performs some check to verify that Alice and her web server indeed have the authority over AliceShop.com. If successful, Symantec then signs a certificate intended for that domain. Since the aforementioned operating systems already trust Symantec, this trust now extends towards Alice's certificate being representative of AliceShop.com.

The security of this trust model has always relied on the responsibility and trustworthiness of the CAs themselves, since a single malicious CA can issue arbitrary valid certificates for any website on the Internet. Each certificate authority is free to engineer different user sign-up, domain validation, certificate issuance and certificate renewal protocols of its own design. Since these ad-hoc protocols often operate over weak channels such as HTTP and DNS without strong cryptographic authentication of entities, most of them can be considered secure only under relatively weak threat models, reducing user credentials to a web login and domain validation to an email exchange.

The main guidelines controlling what type of domain validation CAs are allowed to apply are the recommendations in the CA/Browser Forum Baseline Requirements [START_REF]Baseline requirements for the issuance and management of policy-trusted certificates[END_REF]. These requirements, which are adopted by ballot vote between the participating organizations, cover the definition of common notions such as domain common names (CNs), registration authorities (RAs) and differences between regular domain validation (DV) and extended validation (EV).

These guidelines have not proven sufficient for a well-regulated and well specified approach for domain validation: Mozilla was recently forced to remove WoSign [START_REF] Markham | Wosign and startcom[END_REF] (and its subsidiary StartSSL, both major certificate authorities) from the certificate store of Firefox and all other Mozilla products due to a series of documented instances that range from the CA intentionally ignoring security best-practices for certificate issuance, to vulnerabilities allowing attackers to obtain signed certificates for arbitrary unauthorized websites.

The lack of a standardized protocol operating under a well-defined threat model and with clear security goals for certificate issuance has so far prevented a systematic treatment of certificate issuance using well-established formal methods. Instead, academic efforts to improve PKI security focus on measurement studies [START_REF] Olivier Levillain | One year of SSL Internet measurement[END_REF][START_REF] Delignat-Lavaud | Web pki: Closing the gap between guidelines and practices[END_REF] and transparency and public auditability mechanisms [42,[START_REF] Basin | Arpki: Attack resilient public-key infrastructure[END_REF] for already-issued certificates.

In 2015, a consortium of high-profile organizations including Mozilla and the Electronic Frontier Foundation launched "Let's Encrypt" [START_REF]Let's encrypt overview[END_REF], a non-profit effort to specify, standardize and automate certificate issuance between web servers and certificate authorities and to provide certificate issuance itself as a free-of-charge service. Since its launch in April 2016, Let's Encrypt has issued more than 27 million certificates [START_REF]Let's encrypt statistics[END_REF] and has been linked to a general increase in HTTPS adoption across the Internet.

Let's Encrypt also introduces ACME [START_REF] Barnes | Automatic certificate management environment (acme)[END_REF], an automated domain validation and certificate issuance protocol that gives us for the first time a protocol that can act as a credible target for formal verification in the context of domain validation. ACME also removes almost entirely the human element from the process of domain validation: the subsequently automated validation and issuance of millions of certificates further increases the necessity of a formal approach to the protocol involved.

Secure Collaborative Document Editing

Collaborative document editing software such as Google Docs and Microsoft Office365 has become indispensable in today's work environment. In spite of no confidentiality guarantees, large working groups still find themselves depending on these services even for drafting sensitive documents. Peer pressure, a rush to agree on a working solution and the sheer lack of alternatives have created an ecosystem where a majority of sensitive drafting is currently conducted with no end-to-end encryption guarantees whatsoever. Google and Microsoft servers have full access to all documents being collaborated upon and so do any parties with read access to the internal databases used by these services.

And yet, despite what we see as a clear need for more privacy-preserving collaborative editing framework, this problem space seems largely underaddressed. In the concluding chapter of this thesis, we also contribute a formal approach to the secure collaborative document editing for what we believe is the first time.

Our Approach to Formal Verification

Much of this thesis focuses on the formal verification of what are believed to be some of the most important cryptographic protocols governing the modern Web: Signal Protocol5 (Chapter 1), TLS 1. The same formal verification paradigms and automated verification tools are adopted across all four chapters: the symbolic formal verification model, for which we use the ProVerif [START_REF] Cheval | Proving more observational equivalences with ProVerif[END_REF][START_REF] Blanchet | Modeling and verifying security protocols with the applied pi calculus and ProVerif[END_REF] automated verification tool and the computational formal verification model, for which we use the CryptoVerif [START_REF] Blanchet | CryptoVerif: Computationally sound mechanized prover for cryptographic protocols[END_REF] tool. In this introduction, we explain our motivation behind symbolic and computational verification in ProVerif and CryptoVerif and then provide an informal introduction to the tools and paradigms themselves, equipping the reader with the knowledge necessary to appreciate the methodology and results of the upcoming four chapters.

Why Formal Verification?

Every cryptographic system or protocol we consider in this thesis 6 has followed a "code first, specify later" methodology, where the implementation is fully engineered to suit a particular use case, and sometimes even deployed, before any technical specification is written (usually in the shape of an IETF RFC document or similar.) As described in the Introduction, this trend has coincided with a variety of protocol and implementation errors being detected, sometimes years later.

Many of the protocol issues that were detected in these protocols, including those that constitute some of this thesis's findings, were found using automated verification tools. Automated verification tools are computer software developed around a particular methodology for reasoning about cryptographic primitives, cryptographic protocols and network systems, with the purpose of obtaining answers to questions regarding the execution of these protocols in specific contexts.

When employing automated verification tools, the user is forced, through the first step of modeling the protocol, to specify the protocol to some substantial extent in some well-defined syntax or calculus. Then, based on the constructions, functions and processes within this model as well as the paradigms and network models inherent to the verification framework, answers can be obtained for questions such as "does this protocol run satisfy forward secrecy for two principals, Alice and Bob?" or "is this protocol provable to always satisfy confidentiality on the first message against an active attacker and authenticity of both parties with respect to one another after any successful handshake?" Generally, the tools respond with a yes-or-no answer built upon a rigorous foundation: either a formal verification result if we are verifying in the symbolic model, or a game-based proof, similar to those one may find in academic papers with hand proofs, if we are verifying in the computational model. We introduce both verification models in this chapter.

In 1978, Roger Needham and Michael Schroeder published the Needham-Schroeder public-key protocol [START_REF] Roger | Using encryption for authentication in large networks of computers[END_REF], intended for use in network protocols requiring mutual authentication. While the protocol is considered quite simple relative Generates (s, g s ) Generates (a, g a )

Generates (b, g b ) g a g b Request(g b ) Sign(s, (g b , Bob))

Generates N a ENC (g b , (N a , Alice)) Request(g a ) Sign(s, (g a , Alice))

Generates N b ENC (g a , (N a , N b , B)) ENC (g b , N b )
Figure 2: The Needham Schroeder Public-Key Protocol. This simple protocol, first described in 1978, was not broken until 1995 when a man-in-the-middle attack was discovered using automated formal verification in the symbolic model. By adding the component highlighted in red, the vulnerability can be addressed.

to today's standards, it was not until 1995 for a man-in-the-middle attack to be documented against it [START_REF] Lowe | An attack on the needham-schroeder public-key authentication protocol[END_REF][START_REF] Schneider | Using CSP for protocol analysis: the Needham-Schroeder public-key protocol[END_REF]. This attack was discovered using FDR, a thenexperimental automated verification tool. Fixes for the attack were also modeled and confirmed using the same automated verification framework [START_REF] Lowe | Lowe's fixed version of needham-schroder public key[END_REF].

Because automated verification tools can consider an often-unfathomable number of scenarios according to nevertheless rigorous and grounded mathematical notions, they are useful in unearthing protocol scenarios or errors that can contradict the intuitive assumptions one may have developed for a particular protocol. When work on this thesis began, a dearth existed in the amount of existing work on applying formal verification to the Internet's most used secure protocols and our own intutition was such that if this work were to be done, impactful results could be found.

A common criticism of formal methods is that findings in formal models do not translate to the same security guarantees holding in the target implementation code. This criticism was true before the publication of this thesis and remains true after. However, Chapter 5 of this thesis centers on promising new frameworks and techniques for translating formal security guarantees to real-world implementations targeting the general public. These methodologies have already resulted in stronger real-world integration of formal verification technologies, and establish a clear path forward in that domain.

There are two different styles in which protocols have classically been modeled and in this thesis, we employ both of them. Symbolic models were developed by the security protocol verification community for ease of automated analysis. Cryptographers, on the other hand, prefer to use computational models and do their proofs by hand. A full comparison between these styles is beyond the scope of this thesis (see e.g. [START_REF] Blanchet | Security protocol verification: Symbolic and computational models[END_REF]); here we briefly outline their differences in terms of the two tools we will use.

ProVerif analyzes symbolic protocol models, whereas CryptoVerif [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF] verifies computational models. The input languages of both tools are similar. For each protocol role (e.g. client or server) we write a process that can send and receive messages over public channels, trigger security events and store messages in persistent databases.

In ProVerif, messages are modeled as abstract terms. Processes can generate new nonces and keys, which are treated as atomic opaque terms that are fresh and unguessable. Functions map terms to terms. For example, encryption constructs a complex term from its arguments (key and plaintext) that can only be deconstructed by decryption (with the same key). The attacker is an arbitrary ProVerif process running in parallel with the protocol, which can read and write messages on public channels and can manipulate them symbolically.

In CryptoVerif, messages are concrete bitstrings. Freshly generated nonces and keys are randomly sampled bitstrings that the attacker can guess with some probability (depending on their length). Encryption and decryption are functions on bitstrings to which we may associate standard cryptographic assumptions such as IND-CCA. The attacker is a probabilistic polynomial-time Cryp-toVerif process running in parallel.

Authentication goals in both ProVerif and CryptoVerif are written as correspondences between events: for example, if the client triggers a certain event, then the server must have triggered a matching event in the past. Secrecy is treated differently in the two tools; in ProVerif, we typically ask whether the attacker can compute a secret, whereas in CryptoVerif, we ask whether it can distinguish a secret from a random bitstring.

The analysis techniques employed by the two tools are quite different. ProVerif searches for a protocol trace that violates the security goal, whereas CryptoVerif tries to construct a cryptographic proof that the protocol is equivalent (with high probability) to a trivially secure protocol. ProVerif is a push-button tool that may return that the security goal is true in the symbolic model, or that the goal is false with a counterexample, or that it is unable to conclude, or may fail to terminate. CryptoVerif is semi-automated, it can search for proofs but requires human guidance for non-trivial protocols.

We use both ProVerif and CryptoVerif for their complementary strengths. CryptoVerif can prove stronger security properties of the protocol under precise cryptographic assumptions, but the proofs require more work. ProVerif can quickly analyze large protocols to automatically find attacks, but a positive result does not immediately provide a cryptographic proof of security.

Verification in the Symbolic Model with ProVerif

ProVerif is an automatic symbolic protocol verifier. It supports a wide range of cryptographic primitives, defined by rewrite rules or by equations [START_REF] Blanchet | Modeling and verifying security protocols with the applied pi calculus and ProVerif[END_REF]. In ProVerif, protocols are expressed using the applied pi-calculus [START_REF] Abadi | The applied pi calculus: Mobile values, new names, and secure communication[END_REF], a language for modeling security protocols with a syntax inspired by standard ML. Let us examine how each component of a cryptographic protocol ends up being represented in the symbolic model 7 .

In the symbolic model, cryptographic primitives are represented as "perfect black-boxes"; a hash function, for example, cannot be modeled to be vulnerable to a length extension attack (which the hash function SHA-1 is vulnerable to, for example.) Encryption primitives are perfect pseudorandom permutations. Hash functions are perfect one-way maps. It remains possible to build complex primitives such as authenticated encryption with associated data (AEAD) and also to model interesting use cases, such as a Diffie-Hellman exponentiation that obtains a shared secret that is outside of the algebraic group. However, in the latter case, such constructions cannot be based on on an algebra that includes the space of integers commonly considered when modeling these scenarios, since all messages are simply a combination of the core terms used to express primitives.

When describing protocols for symbolic verification in ProVerif, the following constructions frequently come into play:

• Protocol functions. let and letfun declarations allow us to chain state transformations or processes in an interface that resembles functions in standard ML.

• Principals. Unlike other tools such as AVISPA [START_REF] Armando | The avispa tool for the automated validation of internet security protocols and applications[END_REF], protocol principals such as "Alice", "Bob", or a client and server are not modeled explicitly. Principals and their roles are inferred from how the protocol messages get constructed and exchanged on the network: after all of the protocol's constructions and functionalities are defined, a "top-level" process expresses the sequence in which operations occur and messages are broadcasted. Informally, protocol verification in the symbolic model is concerned with modeling every possible execution of the described protocol and ensuring that queries hold in each of the resulting scenarios.

ProVerif

M ::= terms v values a names f (M 1 , . . . , M n ) function application E ::= enriched terms M return value new a : τ ; E new name a of type τ let x = M in E variable definition if M = N then E 1 else E 2 if-then-else P, Q ::= processes 0 null process in(M, x : τ ); P input x from channel M out(M, N ); P output N on channel M let x = M in P variable definition P | Q parallel composition !P replication of P insert a(M 1 , . . . , M n ); P insert into table a get a(=M
; f (M 1 , . . . , M n ) = M destructor equation forall x 1 : τ 1 , . . . , x n : τ n ; M = M equation letfun f (x 1 : τ 1 , . . . , x n : τ n ) = E pure function let p(x 1 : τ 1 , . . . , x n : τ n ) = Pprocess Σ ::= ∆ 1 . . . . ∆ n .process P script
Symbolic verification is useful because it is fully automated whereas verification in the computational model tends to be semi-automated. It analyzes protocol messages as they are exchanged over the network under a simulated active attacker8 which will attempt to look for a contradiction to the query by delaying, dropping and injecting messages. That said, ProVerif does not always terminate. ProVerif may sometimes produce an "I don't know" answer with more elaborate security queries: however, the effect of this is ProVerif finding false positives. ProVerif cannot miss a contradiction to a query should that contradiction exist. Deriving sound cryptographic proofs using symbolic analysis is still an open problem for real-world protocols [START_REF] Cortier | A survey of symbolic methods in computational analysis of cryptographic systems[END_REF].

A ProVerif script Σ is divided into two major parts:

1. ∆ 1 . . . . ∆ n , a sequence of declarations which encapsulates all types, free names, queries, constructors, destructors, equations, pure functions and processes.

Queries define the security properties to prove. Destructors and equations define the properties of cryptographic primitives.

2. P , the top-level process which then effectively employs ∆ 1 . . . . ∆ n as its toolkit for constructing a process flow for the protocol.

In processes, the replication !P represents an unbounded number of copies of P in parallel.

Tables store persistent state: The process insert a(M 1 , . . . , M n ); P inserts the entry (M 1 , . . . , M n ) in table a and runs P . The process get a(=M 1 , x 2 , . . . , x n ) in P looks for an entry (N 1 , . . . , N n ) in table a such that N 1 = M 1 . When such an entry is found, it binds x 2 , . . . , x n to N 2 , . . . , N n respectively and runs P .

Events are used for recording that certain actions happen (e.g. a message was sent or received), in order to use that information for defining security properties.

Phases model a global synchronization: processes initially run in phase 0; then at some point processes of phase 0 stop and processes of phase 1 run and so on. For instance, the protocol may run in phase 0 and some keys may be compromised after the protocol run by giving them to the adversary in phase 1.

More information on ProVerif is available in the ProVerif manual [START_REF] Blanchet | Proverif 1.90: Automatic cryptographic protocol verifier, user manual and tutorial[END_REF].

Verification in the Computational Model using CryptoVerif

Computational model verification produces game-based proofs, while symbolic verification only guarantees that, within the expressed model, no contradiction to a stated security query expressing a specific security goal exists. Given that computational model verification mirrors the style already used by cryptographers for hand proofs, some cryptographers prefer using the computational model protocol verifier CryptoVerif [START_REF] Blanchet | CryptoVerif: Computationally sound mechanized prover for cryptographic protocols[END_REF].

Traditionally, symbolic cryptographic models have been particularly suitable for automated protocol analysis. They ignore attacks with negligible probability and assume that each cryptographic function is a perfect black-box. For example, in such models, hash functions never collide and encryption is a message constructor that can only be reversed by decryption. In the computational model, cryptographic primitives are functions over bitstrings and their security is specified in terms of probabilities. These models are more precise and closer to those used by cryptographers, but usually do not lend themselves to fully automated proofs. Generally, we will use symbolic models when we are trying to find attacks that rely on logical flaws in the protocol and in its use of cryptographic primitives. We will use computational models when we want to build a cryptographic proof of security, starting from standard cryptographic assumptions.

That being said, computational models are still models. They do not fully match reality: an easy example of this is their ignoring side channels, such as timing attacks or power consumption analysis attacks.

Like ProVerif, CryptoVerif also uses the applied pi-calculus as its syntax for describing protocols, albeit with different underlying semantics. Unlike ProVerif, protocol messages are bitstrings and primitives are functions on those bitstrings. Furthermore, the adversary is not restricted only to apply operations based on described primitives, but is rather a probabilistic polynomial-time Turing machine that can manipulate the bitstrings and apply any algorithm, much like a regular computer. This makes it such that computational modeling in CryptoVerif is considered to be more "realistic" than modeling in ProVerif. This also allows for CryptoVerif to specify probabilistic bounds on attacks and makes security parameters9 possible to express.

Processes, contexts, adversaries. CryptoVerif mechanizes proofs by sequences of games, similar to those written on paper by cryptographers [START_REF] Shoup | Sequences of games: a tool for taming complexity in security proofs[END_REF][START_REF] Bellare | The security of triple encryption and a framework for code-based game-playing proofs[END_REF]. It represents protocols and cryptographic games in a probabilistic process calculus. We refer the reader to [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF] for details on this process calculus. We will explain the necessary constructs as they appear.

Even though CryptoVerif can evaluate the probability of success of an attack as a function of the number of sessions and the probability of breaking each primitive (exact security), for simplicity, we consider here the asymptotic framework in which we only show that the probability of success of an attack is negligible as a function of the security parameter η. (A function f is negligible when for all polynomials q, there exists η o ∈ N such that for all η > η 0 , f (η) ≤ 1 q(η) .) All processes run in polynomial time in the security parameter and manipulate bitstrings of polynomially bounded length.

A context C is a process with one or several holes [ ]. We write C[P 1 , . . . , P n ] for the process obtained by replacing the holes of C with P 1 , . . . , P n respectively. An evaluation context is a context with one hole, generated by the following grammar:

C ::= evaluation context [ ] hole newChannel c; C channel restriction Q | C parallel composition C | Q parallel composition
The channel restriction newChannel c; Q restricts the channel name c, so that communications on this channel can occur only inside Q and cannot be received outside Q or sent from outside Q. The parallel composition Q 1 | Q 2 makes simultaneously available the processes defined in Q 1 and Q 2 . We use evaluation contexts to represent adversaries.

Indistinguishability.

A process can execute events, by two constructs: event e(M 1 , . . . , M n ) executes event e with arguments M 1 , . . . , M n and event_abort e executes event e without argument and aborts the game. After finishing execution of a process, the system produces two results: the sequence of executed events E and the information whether the game aborted (a = abort, that is, executed event_abort) or terminated normally (a = 0). These events and result can be used to distinguish games, so we introduce an additional algorithm, a distinguisher D that takes as input the sequence of events E and the result a and returns true or false. Distinguishers must run in time polynomial in the security parameter. We write Pr[Q η D] for the probability that the process Q executes events E and returns a result a such that D(E, a) = true, with security parameter η.

Definition 1 (Indistinguishability). We write Q ≈ V Q when, for all evaluation contexts C acceptable for Q and Q with public variables V and all distinguishers

D, | Pr[C[Q] η D] -Pr[C[Q ] η D]| is a negligible function η.
Intuitively, Q ≈ V Q means that an adversary has a negligible probability of distinguishing Q from Q , when it can read the variables in the set V . When V is empty, we omit it.

The condition that C is acceptable for Q and Q with public variables V is a technical condition that guarantees that C[Q] and C[Q ] are well-formed. The public variables V are the variables of Q and Q that C is allowed to read directly.

The relation

≈ V Q is an equivalence relation and Q ≈ V Q implies C[Q] ≈ V C[Q ]
for all evaluation contexts C acceptable for Q and Q with public variables V and all V ⊆ V ∪ var(C), where var(C) is the set of variables of C.

Security assumptions on cryptographic primitives are given to CryptoVerif as indistinguishability properties that it considers as axioms.

Secrecy. Intuitively, in CryptoVerif, secrecy means that the adversary cannot distinguish between the secrets and independent random values. This definition corresponds to the "real-or-random" definition of security [START_REF] Abdalla | Passwordbased authenticated key exchange in the three-party setting[END_REF]. A formal definition in CryptoVerif can be found in [START_REF] Blanchet | Automatically verified mechanized proof of oneencryption key exchange[END_REF]. [START_REF] Thomas | A semantic model for authentication protocols[END_REF] are properties of executed sequences of events, such as "if some event has been executed, then some other event has been executed". They are typically used for formalizing authentication. Given a correspondence corr, we define a distinguisher D such that D(E, a) = true if CHAPTER 0. INTRODUCTION and only if the sequence of events E satisfies the correspondence corr. We write this distinguisher simply corr and write ¬corr for its negation. Definition 2 (Correspondence). The process Q satisfies the correspondence corr with public variables V if and only if, for all evaluation contexts C acceptable for Q with public variables V that do not contain events used in corr,

Correspondences. Correspondences

Pr[C[Q] η ¬corr] is negligible.
We refer the reader to [START_REF] Blanchet | Computationally sound mechanized proofs of correspondence assertions[END_REF] for more details on the verification of correspondences in CryptoVerif.

Outline, Contributions and Related Work

This thesis was written with the intent of bridging the gap between the formal verification and the real-world secure implementation of cryptographic protocols.

Initial chapters of this thesis deal with formal verification research and results, while later chapters deals with robust real-world cryptographic implementations. While the two parts handle distinct features of this thesis, they both center around shared use cases and protocols: Chapters 1 and 2, for example, discusse formal verification approaches to secure messaging and TLS, with Chapter 5 eventually picking up those same protocols again with a focus on secure Web-based implementations.

Chapter 1: Formal Verification for Secure Messaging

Chapter 1 begins with a study of secure messaging protocols. We present security goals and a threat model for secure messaging protocols. We discuss protocol weaknesses and implementation bugs in the messaging protocol underlying the popular Telegram application, as well as issues with the Off-the-Record secure messaging protocol. We formalize and analyze a variant of Signal Protocol for a series of security goals, including confidentiality, authenticity, forward secrecy and future secrecy, against a classic symbolic adversary. Our analysis uncovers several weaknesses, including previously unreported replay and key compromise impersonation attacks and we propose and implement fixes which we then also verify. We present proofs of message authenticity, secrecy and forward secrecy for SP obtained using the CryptoVerif computational model prover [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF].

Chapter 2: Formal Verification for Transport Layer Security

In Chapter 2, we follow with a similar treatment to Chapter 1 of TLS 1.3. We present work that was completed admist the effort to specify TLS 1.3: after 18 drafts, the protocol was nearing completion, and the working group had appealed to researchers to analyze the protocol before publication. We responded by presenting a comprehensive analysis of the TLS 1.3 Draft-18 protocol. We seek to answer three questions that had not been fully addressed in previous work on TLS 1.3: (1) Does TLS 1.3 prevent well-known attacks on TLS 1.2, such as Logjam or the Triple Handshake, even if it is run in parallel with TLS 1.2? (2) Can we mechanically verify the computational security of TLS 1.3 under standard (strong) assumptions on its cryptographic primitives? (3) How can we extend the guarantees of the TLS 1.3 protocol to the details of its implementations?

To answer these questions, we propose a methodology for developing verified symbolic and computational models of TLS 1.3 hand-in-hand with a highassurance reference implementation of the protocol. We present symbolic ProVerif models for various intermediate versions of TLS 1.3 and evaluate them against a rich class of attacks to reconstruct both known and previously unpublished vulnerabilities that influenced the current design of the protocol. We present a computational CryptoVerif model for TLS 1.3 Draft-18 and prove its security.

In comparison with previous cryptographic proofs of draft versions of TLS 1.3 [START_REF] Dowling | A cryptographic analysis of the TLS 1.3 handshake protocol candidates[END_REF][START_REF] Krawczyk | The OPTLS protocol and TLS 1.3[END_REF][START_REF] Li | Multiple handshakes security of TLS 1.3 candidates[END_REF], our cryptographic assumptions and proof structure is similar. The main difference in this work is that our proof is mechanized, so we can easily adapt and recheck our proofs as the protocol evolves. Shortly after the publication of our work, other analyses of TLS 1.3 in the symbolic model were published [START_REF] Cremers | A comprehensive symbolic analysis of TLS 1.3[END_REF], written using the Tamarin proverif instead of ProVerif.

Our full CryptoVerif development consists of 2270 lines, including new definitions and lemmas for the key schedule (590 lines), a model of the initial handshake (710 lines), a model of PSK-based handshakes (820 lines), and a model of the record protocol (150 lines). For different proofs, we sometimes wrote small variations of these files, and we do not count all those variations here. All proofs completed in about 11 minutes. The total verification effort took about 6 person-weeks for a CryptoVerif expert.

Chapter 3: Formal Verification of Arbitrary Noise Protocols

In Chapter 3, we target the Noise Protocol Framework and present Noise Explorer, an online engine for designing, reasoning about and formally verifying arbitrary Noise Handshake Patterns. Based on our formal treatment of the Noise Protocol Framework, Noise Explorer can validate any Noise Handshake Pattern and then translate it into a model ready for automated verification. We use Noise Explorer to analyze 50 Noise Handshake Patterns. We confirm the stated security goals for 12 fundamental patterns and provide precise properties for the rest. We also analyze unsafe Noise Handshake Patterns and document weaknesses that occur when validity rules are not followed. All of this work is consolidated into a usable online tool that presents a compendium of results and can parse formal verification results to generate detailed-but-pedagogical reports regarding the exact security guarantees of each message of a Noise Handshake Pattern with respect to each party, under an active attacker and including malicious principals. Noise Explorer evolves alongside the standard Noise Protocol Framework, having already contributed new security goal verification results and stronger definitions for pattern validation and security parameters.

This work represents the first comprehensive formal analysis of the Noise CHAPTER 0. INTRODUCTION Protocol Framework. However, substantial tangential work has occured centering on the WireGuard [START_REF] Donenfeld | WireGuard: next generation kernel network tunnel[END_REF] VPN protocol, which employs the IKpsk2 Noise Handshake Pattern: Lipp [START_REF] Lipp | A Mechanised Computational Analysis of the Wire-Guard Virtual Private Network Protocol[END_REF] presented an automated computational proof of WireGuard, Donenfeld et al [START_REF] Donenfeld | Formal verification of the WireGuard protocol[END_REF] presented an automated symbolic verification of WireGuard and Dowling et al [START_REF] Dowling | A cryptographic analysis of the WireGuard protocol[END_REF] presented a hand proof of WireGuard. These analyses' results on the IKpsk2 handshake pattern were in line with those we found in our own symbolic analysis. Other work exists centering on the automated verification of modern protocols [START_REF] Bhargavan | Automated verification for secure messaging protocols and their implementations: A symbolic and computational approach[END_REF][START_REF] Bhargavan | Verified models and reference implementations for the TLS 1.3 standard candidate[END_REF].

Chapter 4: Formal Verification for Automated Domain Name Validation

In Chapter 4, we survey the existing process for issuing domain-validated certificates in major certification authorities. Based on our findings, we build a security model of domain-validated certificate issuance. We then model the ACME protocol in the applied pi-calculus and verify its stated security goals against our security model. We compare the effective security of different domain validation methods and show that ACME can be secure under a stronger threat model than that of traditional CAs. We also uncover weaknesses in some flows of ACME 1.0 and propose verified improvements that have been adopted in the latest protocol draft submitted to the IETF.

Chapter 5: Formally Verified Secure Channel Implementations in Web Applications

Chapter 5 mirrors the findings of Chapters 1 and 2 and extends them towards the obtention of robust real-world cryptographic implementations. We present ProScript, a new language subset of JavaScript geared towards secure protocol implementation and that allows for the automated extraction of protocol models straight from protocol implementation code. Using ProScript, our subset of JavaScript geared towards secure protocol implementation, we are able to implement a variant of Signal Protocol which we then automatically translate to ProVerif and verify against a battery of formalized queries, which include tests for forward secrecy and key compromise impersonation. We similarly implement TLS 1.3 (draft-18) using ProScript and verify the extracted symbolic model against TLS-specific queries. We introduce Cryptocat, the first user-friendly secure messenger to deploy formally verified protocol logic at its core, and RefTLS, an interoperable implementation of TLS 1.0-1.3 and automatically analyze its protocol core by extracting a ProVerif model from its typed JavaScript code. The symbolic security guarantees of RefTLS are weaker than those of computationallyverified implementations like miTLS [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF]. However, unlike miTLS, our analysis is fully automated and it can quickly find attacks. The type-based technique of miTLS requires significant user intervention and is better suited to building proofs than finding attacks.

Our ProScript-to-ProVerif compiler is inspired by previous works on deriving ProVerif models from F# [START_REF] Bhargavan | Verified interoperable implementations of security protocols[END_REF], Java [START_REF] Avalle | The Java SPI framework for security protocol implementation[END_REF], and JavaScript [START_REF] Bhargavan | Language-based defenses against untrusted browser origins[END_REF]. Such translations have been used to symbolically and computationally analyze TLS implementations [START_REF] Bhargavan | Verified cryptographic implementations for TLS[END_REF]. An alternative to model extraction is to synthesize a verified implementation from a verified model; [START_REF] Cadé | Proved generation of implementations from computationally secure protocol specifications[END_REF] shows how to compile CryptoVerif models to OCaml and uses it to derive a verified SSH implementation. The most advanced case studies for verified protocol implementations use dependent type systems, because they scale well to large codebases. Refinement types for F# have been used to prove both symbolic [START_REF] Bhargavan | Modular verification of security protocol code by typing[END_REF] and cryptographic security properties, with applications to TLS [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF]. The F programming language [START_REF] Swamy | Dependent types and multi-monadic effects in F*[END_REF] has been used to verify small protocols and cryptographic libraries [START_REF] Karim Zinzindohoue | A verified extensible library of elliptic curves[END_REF]. Similar techniques have been applied to the cryptographic verification of Java programs [START_REF] Küsters | A framework for the cryptographic verification of Java-like programs[END_REF].

Chapter 6: Formally Verified Secure Collaborative Document Editing

Chapter 6 concludes the thesis by moving towards an unaddressed protocal use case. We present Capsule, the first formalized and formally verified protocol standard that addresses secure collaborative document editing. Capsule provides confidentiality and integrity on encrypted document data, while also guaranteeing the ephemeral identity of collaborators and preventing the server from adding new collaborators to the document. Capsule also, to an extent, prevents the server from serving different versions of the document being collaborated on. We provide a full protocol description of Capsule as well as formal verification results on the Capsule protocol in the symbolic model. Finally, we present a full software implementation of Capsule, which includes a novel formally verified signing primitive implementation.

To the best of our knowledge, the only prior existing work regarding collaborative document encryption is CryptPad [START_REF]CryptPad: Zero Knowledge, Collaborative Real Time Editing[END_REF], an open source web client. Crypt-Pad shares similarities with Capsule especially in that both use a hash chain of encrypted diffs in order to manage document collaboration and to reconstruct the document. However, CryptPad adopts a more relaxed threat model of an "honest but curious cloud server" and does not appear to guard against a server interfering with the document's list of participants or its history. Meanwhile, Capsule explicitly guards against a server injecting false participants by requiring a certain proof from all participants. CryptPad's software implementation is also limited within a web browser and unlike Capsule's, does not employ formally verified cryptographic primitives.

Chapter 1

Formal Verification for Secure Messaging

This work was published in the proceedings for the 3rd IEEE European Symposium on Security and Privacy, 2017. It was completed with co-authors Karthikeyan Bhargavan and Bruno Blanchet.

Designing new cryptographic protocols is highly error-prone; even well-studied protocols, such as Transport Layer Security (TLS), have been shown to contain serious protocol flaws found years after their deployment (see e.g. [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF]). Despite these dangers, modern web applications often embed custom cryptographic protocols that evolve with each release. The design goal of these protocols is typically to protect user data as it is exchanged over the web and synchronised across devices, while optimizing performance for application-specific messaging patterns and deployment constraints. Such custom protocols deserve close scrutiny, but their formal security analysis faces several challenges.

First, web applications often evolve incrementally in an ad hoc manner, so the embedded cryptographic protocol is only ever fully documented in source code. Even when protocol designers or security researchers take the time to create a clear specification or formal model for the protocol, these documents are typically incomplete and quickly go out-of-date. Second, even if the protocol itself is proved to be secure, bugs in its implementation can often bypass the intended security guarantees. Hence, it is not only important to extract a model of the protocol from the source code and analyze its security, it is essential to do so in a way that the model can evolve as the application is modified.

In this chapter, we study the protocol underlying the Signal messaging application developed by Open Whisper Systems. Variants of this protocol have also been deployed within WhatsApp, Facebook Messenger, Viber and many other popular applications, reaching over a billion devices. The protocol has been known by other names in the past, including Axolotl, TextSecure (versions 1, 2, and 3) and it continues to evolve within the Signal application under the name Signal Protocol. Until recently, the main documentation for the protocol 34 CHAPTER 1. SECURE MESSAGING was its source code, but new specifications for key components of the protocol have now been publicly released [START_REF] Perrin | The X3DH key agreement protocol[END_REF][START_REF] Perrin | The double ratchet algorithm[END_REF].

Signal Protocol has ambitious security goals; it enables asynchronous (zero round-trip) authenticated messaging between users with end-to-end confidentiality. Each message is kept secret even if the messaging server is compromised and even if the user's long term keys are compromised, as long as these keys are not used by the attacker before the target message is sent (forward and future secrecy.) To achieve these goals, Signal uses a novel authenticated key exchange protocol (based on mixing multiple Diffie-Hellman shared secrets) and a key refresh mechanism (called double ratcheting). The design of these core mechanisms in TextSecure version 2 was cryptographically analyzed in [START_REF] Frosch | How Secure is TextSecure[END_REF] but the protocol has evolved since then and the security of Signal as it is currently implemented and deployed remains an open question.

Although they all implement the same core protocol, different implementations of the Signal protocol vary in important details, such as how users are identified and authenticated, how messages are synchronised across devices, etc.

We call this variant SP in the rest of this chapter. We develop a detailed model for SP in the applied pi calculus and verify it using the ProVerif protocol analyzer [START_REF] Blanchet | Modeling and verifying security protocols with the applied pi calculus and ProVerif[END_REF] for these security goals against adversaries in a classic Dolev-Yao model [START_REF] Dolev | On the security of public key protocols[END_REF]. We also develop a computational proof for SP using the CryptoVerif prover [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF].

Contributions. We present an outline of our contributions in this chapter:

A Security Model and New Attacks. We present security goals and a threat model for secure messaging. As a motivation for our verification approach, we discuss protocol weaknesses and implementation bugs in the messaging protocol underlying the popular Telegram application, as well as issues with the Off-the-Record secure messaging protocol.

A Symbolic Security Analysis of SP. We formalize and analyze a variant of Signal Protocol for a series of security goals, including confidentiality, authenticity, forward secrecy and future secrecy, against a classic symbolic adversary. Our analysis uncovers several weaknesses, including previously unreported replay and key compromise impersonation attacks and we propose and implement fixes which we then also verify.

A Computational Cryptographic Proof for SP. We present proofs of message authenticity, secrecy and forward secrecy for SP obtained using the Cryp-toVerif computational model prover [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF].

In Chapter 5, we extend these contributions to target robust real-world protocol implementations.

Online materials related to this work are available at this online repository: https://github.com/Inria-Prosecco/proscript-messaging/.

A SECURITY MODEL FOR ENCRYPTED MESSAGING 35

A Security Model for Encrypted Messaging

We consider a simple messaging API as depicted below. An initiator A can start a conversation with B by calling startSession with long-term secrets for A and any identity credentials it has for B. This function returns the initial conversation state T 0 . Thereafter, the initiator can call send with a plaintext message M 1 to obtain the encrypted message E 1 that it needs to send on the network. Or it can call recv with an encrypted message E 2 it received (supposedly from B) to obtain the plaintext message M 2 .

T ab 0 = startSession(secrets A ,identity B )

T ab 1 , E 1 = send(T ab 0 ,M 1 ) T ab 2 , M 2 = recv(T ab 1 ,E 2 )
The responder B uses a similar API to accept sessions and receive and send messages:

T ba 0 = acceptSession(secrets B ,identity A ) T ba 1 , M 1 = recv(T ba 0 ,E 1 ) T ba 2 , E 2 = send(T ba 1 ,M 2 )
We deliberately chose a functional state-passing API with no side-effects in order to focus on cryptographic protocol computations, rather than the concrete details of how these messages are sent over the network.

Threat Model

While threat models vary for different protocols, we consider the following threats in this work:

• Untrusted Network We assume that the attacker controls the network and so can intercept, tamper with and inject network messages (e.g. E 1 , E 2 ). Moreover, if two messaging clients communicate via a server, we typically treat that server as untrusted.

• Malicious Principals The attacker controls a set of valid protocol participants (e.g. M ), for whom it knows the long-term secrets. The attacker may advertise any identity key for its controlled principals; it may even pretend to own someone else's identity keys.

• Long-term Key Compromise The attacker may compromise a particular principal (e.g. A) during or after the protocol, to obtain her long-term secrets.

• Session State Compromise The attacker may compromise a principal to obtain the full session state at some intermediate stage of the protocol (e.g. T ab 1 ).

Security Goals

We state a series of semi-formal security goals in terms of our generic messaging API. We use the phrase "A sends a message M to B" to mean that A calls Send(T, M ) with a session state T that represents a conversation between A and B. Similarly, we say that "B receives a message M from A" to mean that B obtained M as a result of calling Recv(T, E) with a session T with A.

Unless otherwise specified, the following security properties assume that both A and B are honest, that is, their long-term secrets have not been compromised. We begin with several variants of authenticity goals:

• Message Authenticity If B receives a message M from A, then A must have sent M to B.
• No Replays Each message received by B from A corresponds to a unique message sent by A. That is, the attacker must not be able to get a single message sent by A to be accepted twice at B.

• No Key Compromise Impersonation Even if the long-term secrets of B are compromised, message authenticity must hold at B. That is, the attacker must not be able to forge a message from A to B.

Our definition of message authenticity covers integrity as well as sender and recipient authentication. Obtaining message authenticity also helps prevent unknown key share attacks, where B receives a message M from A, but A sent that message to a different intended recipient C. We define four confidentiality goals:

• Secrecy If A sends some secret message M to B, then nobody except A and B can obtain M .

• Indistinguishability If A randomly chooses between two messages M 0 , M 1 (of the same size) and sends one of them to B, the attacker cannot distinguish (within the constraints of the cryptographic model) which message was sent.

• Forward Secrecy If A sends a secret message M to B and if A's and B's longterm secrets are subsequently compromised, the message M remains secret.

• Future Secrecy Suppose A sends M in a session state T , then receives N , then sends M . If the session state T is subsequently compromised, the message M remains secret.

Some protocols satisfy a weaker notion of forward secrecy, sometimes called weak forward secrecy, where an attacker is not allowed to actively tamper with the protocol until they have compromised the long-term keys [START_REF] Krawczyk | HMQV: A High-performance Secure Diffie-Hellman Protocol[END_REF]. Some messaging protocols also seek to satisfy more specific authenticity and confidentiality goals, such as non-repudiation and plausible deniability. We will ignore them in this work.

In the next section, we evaluate two secure messaging applications against these goals, we find that they fail some of these goals due to subtle implementation bugs and protocol flaws. Hence, we advocate the use of automated verification tools to find such attacks and to prevent their occurrence.

Symbolic Verification with ProVerif

Modern messaging and transport protocols share several distinctive features [START_REF] Unger | SoK: Secure messaging[END_REF]: for example, Signal Protocol, SCIMP, QUIC and TLS 1.3 share a strong focus on asynchronous key agreement with a minimum of round trips. Some also guarantee new security goals such as future secrecy. The protocols also assume non-standard (but arguably more user-friendly) authentication infrastructures such as Trust-on-First-Use (TOFU). Modern messaging protocols have several interesting features and properties that set them apart from classic cryptographic protocols and upon which we focus our formal verification efforts: New Messaging Patterns. In contrast to connection-oriented protocols, modern cryptographic protocols are constrained by new communication flows such as zero-round-trip connections and asynchronous messaging, where the peer may not even be present.

Confidentiality Against Strong Adversaries. Web messaging protocols need to be robust against server compromise and device theft and so seek to provide strong and novel forward secrecy guarantees.

Weak Authentication Frameworks. Many of these protocols do not rely on public key infrastructures. Instead they may authenticate peers on a TOFU basis or even let peers remain anonymous, authenticating only the shared connection parameters.

Code First, Specify Later. Unlike Internet protocols, which are designed in committee, these protocols are first deployed in code and hand-tuned for performance on a particular platform. The code often remains the definitive protocol specification.

Before outlining our verification approach for such protocols, we take a closer look at Telegram, a secure messaging application.

Secret Chats in Telegram

We study the "MTProto" [START_REF] Durov | Telegram mtproto protocol[END_REF] secure messaging protocol used in the Telegram messaging application. We focus on the "secret chat" feature that allows two Telegram clients who have already authenticated themselves to the server to start an encrypted conversation with each other. Although all messages pass through the Telegram server, the server is untrusted and should not be able to decrypt these messages. The two clients A and B download Diffie-Hellman parameters from the Telegram server and then generate and send their public values to each other.

CHAPTER 1. SECURE MESSAGING

Client A Server S Client B DHConfig(p, g) DHConfig(p, g) Checks(p, g) Generates (a, g a )
Checks(p, g)

Request(A, B, g a ) Checks g a ∈ {0, 1, -1} Generates (b, g b ) Accept(B, A, g b ) Checks g b ∈ {0, 1, -1} Computes k = kdf(g ab ) Computes k = kdf(g ab ) Does not know g ab , k Confirm(A, B, hash(g ab ))
Confirm(B, A, hash(g ab )) The key exchange is not authenticated with long-term credentials. Instead, the two clients are expected to communicate out-of-band and compare a SHA-1 hash (truncated to 128-bits) of the Diffie-Hellman shared secret. If two users perform this authentication step, the protocol promises that messages between them are authentic, confidential and forward secret, even if the Telegram server is compromised. However this guarantee crucially relies on several cryptographic assumptions, which may be broken either due to implementation bugs or computationally powerful adversaries, as we describe below.

SecretChat(A, B, enc k (m)) SecretChat(B, A, enc k (m ))
Malicious Primes. MTProto relies on clients checking that the Diffie-Hellman configuration (p, g) that they received from the server is suitable for cryptographic use. The specification requires that p be a large safe prime; hence the client must check that it has exactly 2048 bits and that both p and (p -1)/2 are prime, using 15 rounds of the Miller-Rabin primality test. There are several problems with this check. First, the server may be able to carefully craft a nonprime that passes 15 rounds of Miller-Rabin. Second, checking primality is not enough to guarantee that the discrete log problem will be hard. If the prime is chosen such that it has "low weight", the SNFS algorithm applies, making discrete logs significantly more practical [START_REF] Schirokauer | The number field sieve for integers of low weight[END_REF]. Even if we accept that primality checking may be adequate, it is unnecessary for an application like Telegram, which could simply mandate the use of well-known large primes instead [START_REF] Gillmor | Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)[END_REF].

Public Values in Small Subgroups. A man-in-the-middle can send to both A and B public Diffie-Hellman values g b and g a equal to 1 (resp. 0, resp. p -1). Both A and B would then compute the shared secret as g ab = 1 (resp. 0, resp. 1 or -1). Since their key hashes match, A and B think they have a confidential channel. However, the attacker can read and tamper with all of their messages.

More generally, MTProto relies on both peers verifying that the received Diffie-Hellman public values do not fall in small subgroups. This check is adequate to prevent the above attack but could be made unnecessary if the two public values were to be authenticated along with the shared secret in the hash compared by the two peers.

Implementation Bugs in Telegram for Windows. The above two weaknesses, reported for the first time in this work, can result in attacks if the protocol is not implemented correctly. We inspected the source code for Telegram on different platforms; while most versions perform the required checks, we found that the source code for Telegram for Windows Phone did not check the size of the received prime, nor did it validate the received Diffie-Hellman values against 1, 0 or p -1. We reported both bugs to the developers, who acknowledged them and awarded us a bug bounty.

Such bugs and their consequent attacks are due to missed security-relevant checks and they can be found automatically by symbolic analysis. For example, [START_REF] Bhargavan | Verified contributive channel bindings for compound authentication[END_REF] shows how to model unsafe (malicious) primes and invalid public keys in ProVerif and uses this model to find vulnerabilities in several protocols that fail to validate Diffie-Hellman groups or public keys.

Other Cryptographic Weaknesses. MTProto is also known to be vulnerable to an authentication attack if an adversary can compute 2 64 SHA-1 hashes [START_REF] Rad | A 2 64 attack on Telegram, and why a super villain doesn[END_REF] and to chosen-ciphertext attacks on its unusual AES-IGE encryption scheme [START_REF] Jakobsen | On the cca (in)security of mtproto[END_REF]. How can we be sure that there are no other protocol flaws or implementation bugs hiding in MTProto? Any such guarantee would require a systematic security analysis of both the protocol and the source code against both symbolic and computational adversaries.

Towards Automated Verification

The innovative designs and unusual security guarantees of secure messaging protocols demand formal security analysis. Hand-written models with detailed cryptographic proofs can be useful as a reference, but we observe that the most recent analysis of Signal Protocol [START_REF] Frosch | How Secure is TextSecure[END_REF] is already out of date, as the protocols have moved on to new versions. Furthermore, manual cryptographic proofs often leave out details of the protocol for simplicity and some of these details (e.g. client authentication) may lead to new attacks.

In this work, we advocate the use of automated verification tools to enable the analysis of complex protocols as they evolve and incorporate new features. Moreover, we would also like to find protocol implementation bugs (like the ones in previous versions of Telegram) automatically.

Formally Verifying SP CHAPTER 1. SECURE MESSAGING

Alice Bob

Has identity (a3dh, asig), (g a3dh , g asig ) Knows identity (g b3dh , g bsig )

Has identity (b3dh, bsig), (g b3dh , g bsig ) Knows identity (g a3dh , g asig ) Has signed pre-key bs, g bs Has one-time pre-key bo, g bo SIGN(bsig, g bs ), g bo ae ∈ Zp S = c0 | g a3dhbs | g aeb3dh | g aebs | g aebo (rkba, ckba) ⇐ HKDF(S, c1, c2) ae ∈ Zp kshared = g a e bs (rkab, ckab) ⇐ HKDF(kshared, rkba, c2) kenc ⇐ HKDF(HMAC(ckab, c3), c1, c4) g a3dh , g asig , g ae , g a e , E0 = ENC(kenc, M0,

g a3dh | g asig | g b3dh | g bsig | g a e ) S = c0 | g a3dhbs | g aeb3dh | g aebs | g aebo (rkba, ckba) ⇐ HKDF(S, c1, c2) Delete pre-key(bo, g bo ) kshared = g a e bs (rkab, ckab) ⇐ HKDF(kshared, rkba, c2) kenc ⇐ HKDF(HMAC(ckab, c3), c1, c4) M0 ⇐ DEC(kenc, E0, g a3dh | g asig | g b3dh | g bsig | g a e )
be ∈ Zp kshared = g a e be (rkba, ckba) ⇐ HKDF(kshared, rkab, c2) kenc ⇐ HKDF(HMAC(ckba, c3), c1, c4)

g be , E1 = ENC(kenc, M1, g b3dh | g bsig | g a3dh | g asig | g be ) kshared = g a e be (rkba, ckba) ⇐ HKDF(kshared, rkab, c2) kenc ⇐ HKDF(HMAC(ckba, c3), c1, c4) M1 ⇐ DEC(kenc, E1, g b3dh | g bsig | g a3dh | g asig | g be )

Protocol Overview

In SP, as illustrated in Figure 1.2, each client publishes a long-term Diffie-Hellman public key and a set of ephemeral Diffie-Hellman public keys (called "pre-keys"). These keys include both signed pre-keys, which can be reused for some period of time and non-signed, one-time pre-keys, which are fresh at each session. To send a message to Bob, Alice retrieves Bob's long-term keys (g b 3dh , g b sig ), a signed pre-key g bs and a one-time pre-key g bo . She then chooses her own ephemeral g ae . A four-way Diffie-Hellman handshake is accomplished using Alice and Bob's long-term identity keys and their short-term ephemeral keys in order to derive the session secret S. The one-time pre-key is optional: when there remains no available one-time pre-key, the exchange is performed with a triple Diffie-Hellman handshake. An encryption key, k enc , is then derived from S by Hash-Based Key Derivation (HKDF) [START_REF] Krawczyk | Cryptographic extraction and key derivation: The HKDF scheme[END_REF] and the message M 0 is sent encrypted under the authenticated encryption scheme AES-GCM, with public and ephemeral keys as associated data: ENC(k, m, ad) means that m is encrypted with k and both the message m and the associated data ad are authenticated. Subsequent messages in the conversation obtain authentication by chaining to S via a forward-ratcheting construction that also employs HKDF. Each sent message includes its own newly generated ephemeral public key and the protocol's double ratchet key refresh mechanism manages the key state by advancing key chaining with every message.

SP's forward and future secrecy goals are intended to make it so that the compromise of Alice or Bob's long-term keys allows for their impersonation but not for the decryption of their messages. The use of a signed initial ephemeral pre-key results in weaker forward secrecy guarantees for the first flight of messages from A to B: no forward secrecy is provided if both the long-term keys and pre-keys are leaked, although the guarantees for subsequent flights remain strong. If pre-keys are not signed, then the protocol only offers weak forward secrecy with respect to long-term key leakage. We note that the term "forward secrecy" can be confusing in a protocol like Signal, because a number of keys are at stake: long-term keys ((a 3dh , a sig ), (b 3dh , b sig )), signed pre-key b s , one-time pre-key b o , ephemeral keys (a e , a e , b e ), root keys (rk ab , ck ab , rk ba , ck ba ) and message keys (k enc ). Any formal analysis of the protocol must precisely state which of these keys can be compromised and when.

Differences from other versions of Signal

An earlier version of the protocol, TextSecure Version 2, was cryptographically analyzed in previous work [START_REF] Frosch | How Secure is TextSecure[END_REF]. There are two key differences between SP and TextSecure Version 2.

Signed, Time-Based Pre-Keys. Version 2 uses a triple Diffie-Hellman handshake with one of a hundred pre-keys that Bob stores on the server (including a "last-resort" pre-key). TextSecure Version 3 and all subsequent versions of Signal, including SP, use a signed time-based pre-key, used in conjunction with an unsigned one-time pre-key in case it is available. Bob periodically replaces his signed pre-key (for example, once every week), which may be re-used until its replacement and refreshes his collection of unsigned one-time pre-keys. In SP, when one-time pre-keys are exhausted, no "last-resort" pre-key is used.

Stronger Identity Protection. Since Version 3, tag n is expanded to include the long-term identities of the sender and recipient, which is not the case in Version 2. This provides a slightly stronger authentication guarantee in the rare case that the encryption keys for different pairs of users turns out to be the same.

In addition to these differences with Version 2, SP also differs from other variants of Signal in one key aspect. In SP, long-term identities are split into one Diffie-Hellman key pair and one signing key pair. In Signal, the same key pair is used for both operations, by applying an elliptic curve conversion from the Montgomery curve-based Diffie-Hellman key pair to obtain its twisted Edwards curve-based signing key pair equivalent. We choose to use separate keys instead, because in our cryptographic proof, we do not want to add a non-standard cryptographic assumption about the use of the same key in two independent cryptographic operations. In exchange for using standard cryptographic assumptions, we consider the cost of adding an extra 32 byte key to the protocol to be acceptable.

Protocol Verification

We use ProVerif to verify the security goals of our extracted model by defining queries that accurately test the resilience of security properties against an active adversary. Under an active Dolev-Yao adversary, ProVerif was able to verify confidentiality, authenticity, forward secrecy and future secrecy for Alice and Bob initializing a session and exchanging two secret messages, with a compromised participant, Mallory, also being allowed to initialize sessions and exchange nonsecret messages with Alice and Bob. Our analysis revealed two novel attacks: a key compromise impersonation attack and a replay attack, for which we propose a fix. Aside from these attacks, we were also able to model the previously documented Unknown Keyshare Attack [START_REF] Frosch | How Secure is TextSecure[END_REF]. Extracts of our compiled SP implementation are available online [START_REF] Kobeissi | SP code repository[END_REF]. Models begin with type declarations followed by public constant declarations, equational relationships for cryptographic primitives, protocol functions, queries and relevant names and finally the top-level process with its associated queries.

The top-level process queries for security properties such as confidentiality, authenticity and forward secrecy between two roles: an initiator (e.g. Alice) who sends an initial message and thereby initializes an authenticated key exchange and a responder (e.g. Bob) who receives the message and who may send a response. Some models include a third compromised identity, Mallory, who also communicates with Alice and Bob but while leaking her private keys to the 1.3. FORMALLY VERIFYING SP attacker beforehand. In some instances, we also model parallel process executions where each identity (Alice, Bob and optionally Mallory) assumes both the role of the initiator and the responder. We informally call this latter scenario a "two-way role" model.

Secrecy and Indistinguishability.

For every message considered in our protocol model, we define a secret constant M n where M 1 is the initial message in a session. These secret values are then used as the plaintext for the encrypted messages sent by the principals. We show that an active attacker cannot retrieve a message's plaintext M n using the query:

query(attacker(M n )) (1.1)
Similarly, we show indistinguishability using the query query(noninterf(M n )).

Forward and Future Secrecy. We examine forward and future secrecy in Signal Protocol in multiple scenarios: the compromise of long-term keys and the compromise of message keys in two different types of message flights. In these scenarios, we need to model that keys are leaked after sending or receiving certain messages. We rely on ProVerif phases for that: intuitively, t represents a global clock and processes occurring after the declaration of a phase t are active only during this phase. We show that message M 1 remains secret by query (1.1) even if the longterm keys (a 3dh , a sig , b 3dh , b sig ) are leaked after sending M 1 . Furthermore, we can modify our ProVerif model to produce a sanity check: if responder Bob skips the signature check on g as , ProVerif shows that an active attacker becomes capable of violating this forward secrecy property.

Next, we examine two different messaging patterns in the Double Ratchet algorithm and find that they approach forward and future secrecy differently:

• Single-Flight Pattern. In this scenario, Alice sends Bob a number of messages M n and M n+1 where n > 1 and does not receive a response. In this scenario, Bob's lack of response does not allow Alice to obtain a fresh ephemeral key share g be required to establish a new k shared in T ab n+1 to be used for M n+1 , so Alice just updates the key ck ab by hashing it. If Alice's session state T ab n+1 , (which, recall, contains a e n+1 and (rk ab , ck ab ) for M n+1 ), is leaked, then M n remains secret (forward secrecy). Obviously, to take advantage of this property in case of compromise, the keys (rk ab , ck ab ) for M n must have been appropriately deleted, which is delicate when messages are received outof-order: if M n 1 , . . . , M n k (n 1 < . . . < n k ) have been received, the receiver should keep the chaining key ck ab for M n k +1 and the encryption keys k enc for the messages M i not received yet with i < n k . If T ab n is leaked, then M n+1 is not secret, so no future secrecy is obtained.

• Message-Response Pattern. In this scenario, Alice sends Bob a single message M n where n > 1 and receives a response M n+1 before sending M n+2 . Upon receiving M n+1 , Alice will be able to derive a fresh k shared = g ae n+2 be n+1 .

As a result, if T ab n+2 is leaked, then M n remains secret (forward secrecy) and if T ab n is leaked after M n+1 is received, then M n+2 remains secret (future secrecy).

Message Authenticity. Signal Protocol relies on a Trust-on-First-Use (TOFU) authentication model: Alice assumes that Bob's advertised identity key is authenticated and untampered with and employs it as such until an event causes the trust of the key to be put in question, such as a sudden identity key change or an out of band verification failure. We model TOFU by embedding Alice and Bob's identity keys into each other's initial states. We are then free to model for message authenticity: informally, if B receives a message M from A, we want A to have sent M to B. In ProVerif, we can specify two events: Send(A, B, M ), which means that A sends M to B and Recv(A, B, M ), which means that B receives M from A. We can then formalize the correspondence

event(Recv(A, B, M )) =⇒ event(Send(A, B, M )) (1.2)
which checks if for all Recv(A, B, M ) events, it must be the case that a Send(A, B, M ) event has also been executed. ProVerif succeeds in proving correspondence (1.2) using public keys A and B. While this implies the desired property when the relation between the public keys and the identity of the principals is bijective, a limitation of this approach is that the identities of the principals are only expressed in terms of keys and not as a more personally-linked element, such as for example a phone number. Therefore, we cannot formally express stronger identity binding as part of the protocol model. This point leads to the Unknown Key Share Attack first reported for Signal Protocol Version 2 [START_REF] Frosch | How Secure is TextSecure[END_REF]: if an adversary can register the public keys (g b 3dh , g b sig ) of B as public keys of C and A sends a message to C, then C can forward this message to B and B will accept it as coming from A, since B and C have the same public keys.

No Replays. This property is similar to message authenticity, but uses an injective correspondence instead, which means that each execution of Recv(A, B, M ) corresponds to a distinct execution of Send(A, B, M ):

inj-event(Recv(A, B, M )) =⇒ inj-event(Send(A, B, M ))
When a optional one-time pre-key is involved in the initial session handshake, ProVerif shows that the injective correspondence holds for the first message in the conversation. However, when this optional one-time pre-key is not used, a replay attack is detected. Signal Protocol Version 3 will accept a Diffie-Hellman handshake that only employs identity keys and signed pre-keys, both of which are allowed to be reused across sessions. This reuse is what makes a replay attack possible. We propose a fix for this issue by having clients keep a cache of the ephemeral keys used by the sender of received messages, associated with that sender's identity key. We are able to expand our event queries in ProVerif to account for this fix by showing the non-injective correspondence of the Send and Recv events with added ephemeral keys. Coupled with a caching of ephemeral keys, we can ensure that the Recv event is only executed once per ephemeral key. Hence, the injective correspondence is implied by the non-injective correspondence.

Key Compromise Impersonation (KCI).

We present a novel key compromise impersonation attack: to detect KCI, we consider a scenario in which Alice or Bob's keys are compromised and test again for authenticity of messages received by the compromised principal. When Alice or Bob's long-term secret key is compromised, ProVerif shows that message authenticity still holds. However, when Bob's signed pre-key is also compromised, ProVerif finds an attack against message authenticity. This is a novel key compromise impersonation attack: when the adversary has Bob's signed pre-key s, he can choose x and x and compute the session keys using Alice's and Bob' public keys (g a 3dh , g a sig ) and (g b 3dh , g b sig ) and Bob's one time pre-key g o and send his own message in Alice's name. This message is accepted by Bob as if it came from Alice: the event Recv(A, B, M ) is executed without having executed Send(A, B, M ).

Other Protocols: OTR

As a preliminary result, we also analyzed Off-the-Record (OTR) Messaging Version 2, which has been shown to include various vulnerabilities discovered under finite-state analysis by Bonneau and Morrison [START_REF] Bonneau | Finite State Security Analysis of OTR Version 2[END_REF]. OTR [START_REF] Borisov | Off-the-record communication, or, why not to use PGP[END_REF] uses a SIGMA-based key exchange [START_REF] Krawczyk | SIGMA: The 'SIGn-and-MAc' approach to authenticated Diffie-Hellman and its use in the IKE-protocols[END_REF] and a ratcheting scheme in order to achieve confidentiality, authentication, perfect forward secrecy and deniability. During model verification, known vulnerabilities in OTR Version 2 were automatically detected: Version Rollback Attack. Since the communication of which OTR versions are supported by a client was performed before authentication occurred, it is possible to maliciously force users to adopt an outdated version of OTR.

Unknown Key-Share Attack. Since OTR's authenticated key exchange lacks sufficient information identifying Alice's intended recipient, Mallory can forward handshake messages in order to successfully trick Alice into establishing a session with Bob, whereas Alice intended to establish a session with Mallory.

Message Integrity Attack.

If Alice receives a message from Bob where Bob uses new ratchet keys, she will publish her MAC keys for her previous message. This is an intentional feature meant to provide deniability once both parties are certain that a certain step of ratchet keys are obsolete. However, Mallory can simply block this outgoing message, use it to learn the MAC key for Alice's previous message and commit a forgery under those keys. From Bob's perspective, it would appear that he has received a delayed but nevertheless valid message from Alice.

Integrating Symbolic Verification into the

Cryptographic Proofs with CryptoVerif

To complement the results obtained in the symbolic model using ProVerif, we use the tool CryptoVerif [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF] in order to obtain security proofs in the computational model. This model is much more realistic: messages are bitstrings; cryptographic primitives are functions from bitstrings to bitstrings; the adversary is a probabilistic Turing machine. CryptoVerif generates proofs by sequences of games [START_REF] Shoup | Sequences of games: a tool for taming complexity in security proofs[END_REF][START_REF] Bellare | The security of triple encryption and a framework for code-based game-playing proofs[END_REF], like those written manually by cryptographers, automatically or with guidance of the user. The computational model is more realistic, but it also makes it more difficult to mechanize proofs. For this reason, CryptoVerif is less flexible and more difficult to use than ProVerif and our results in the computational model are more limited. We model only one message of the protocol (in addition to the pre-keys), so we do not prove properties of the ratcheting algorithm. Considering several data messages exceeds the current capabilities of CryptoVerif-the games become too big.

Assumptions

We make the following assumptions on the cryptographic primitives:

• The elliptic curve Curve25519 satisfies the gap Diffie-Hellman (GDH) assumption [START_REF] Okamoto | The gap-problems: a new class of problems for the security of cryptographic schemes[END_REF]. This assumption means that given g, g a and g b for random a, b, the adversary has a negligible probability to compute g ab (computational Diffie-Hellman assumption), even when the adversary has access to a decisional Diffie-Hellman oracle, which tells him given G, X, Y, Z whether there exist x, y such that X = G x , Y = G y and Z = G xy . When we consider sessions between a participant and himself, we need the square gap Diffie-Hellman variant, which additionally says that given g and g a for random a, the adversary has a negligible probability to compute g a 2 . This assumption is equivalent to the GDH assumption when the group has prime order [START_REF] Fujioka | Designing efficient authenticated key exchange resilient to leakage of ephemeral secret keys[END_REF], which is true for Ec25519 [START_REF] Daniel | Curve25519: New Diffie-Hellman speed records[END_REF]. We also added that x y = x y implies x = x and that x y = x y implies y = y , which hold when the considered Diffie-Hellman group is of prime order.

• Ed25519 signatures, used for signing pre-keys, are unforgeable under chosenmessage attacks (UF-CMA) [START_REF] Goldwasser | A digital signature scheme secure against adaptive chosen-message attacks[END_REF].

• The functions

x 1 , x 2 , x 3 , x 4 → HKDF(x 1 x 2 x 3 x 4 , c 1 , c 2 ) x 1 , x 2 , x 3 → HKDF(x 1 x 2 x 3 , c 1 , c 2 )
x, y → HKDF(x, y, c 2 )

x → HKDF(x, c 1 , c 4 )
are independent random oracles, where x, y, x 1 , x 2 , x 3 , x 4 and c 1 are 256-bit long. We further justify this assumption in §1.4.2: there, we show that these functions are indifferentiable [START_REF] Coron | Merkle-Damgård revisited: How to construct a hash function[END_REF] from independent random oracles, assuming that the compression function underlying SHA256 is a random oracle. (The considered HKDF function [START_REF] Krawczyk | Cryptographic extraction and key derivation: The HKDF scheme[END_REF] is defined from HMAC-SHA256, which is itself defined from SHA256.)

• HMAC-SHA256 is a pseudo-random function (PRF) [START_REF] Bellare | New proofs for NMAC and HMAC: Security without collision-resistance[END_REF]. This assumption is used for HMAC(ck ab , •) and HMAC(ck ba , •).

• The encryption scheme ENC, which is AES-GCM, is a secure authenticated encryption with associated data (AEAD). More precisely, it is indistinguishable under chosen plaintext attacks (IND-CPA) and satisfies ciphertext integrity (INT-CTXT) [START_REF] Mcgrew | The security and performance of the Galois/Counter Mode (GCM) of operation[END_REF][START_REF] Rogaway | Authenticated-encryption with associated-data[END_REF].

CryptoVerif provides a library that predefines the most common cryptographic assumptions, so that the user does not have to write them for each protocol. In our work, we had to adapt these predefined assumptions to our specific needs: the GDH assumption is predefined, but the square GDH variant is not; unary random oracles are predefined, but we also needed binary, ternary and 4-ary ones; predefined PRFs, SUF-CMA MACs and IND-CPA encryption schemes use a key generation function, while in our schemes the key is a plain random bitstring, without a key generation function. Adapting the definition of primitives did not present any major difficulty. As previously mentioned, we made one minor modification to the original Signal Protocol, for it to be provable in the computational model: we use different keys for the elliptic curve Diffie-Hellman and elliptic curve signatures. It is well-known that using the same keys for several cryptographic primitives is undesirable, as proving security requires a joint security assumption on the two primitives in this case. Therefore, we assume each protocol participant to have two key pairs, one for Diffie-Hellman and one for signatures. This problem remains undetected in a symbolic analysis of the protocol.

Indifferentiability of HKDF

We start from the assumption that the compression function underlying SHA256 is a random oracle and show that the functions

x 1 , x 2 , x 3 , x 4 → HKDF(c 0 x 1 x 2 x 3 x 4 , c 1 , c 2 ) x 1 , x 2 , x 3 → HKDF(c 0 x 1 x 2 x 3 , c 1 , c 2 )
x, y → HKDF(x, y, c 2 )

x → HKDF(x, c 1 , c 4 )
where c 1 = 0 (256-bits), c 2 = "WhisperRatchet", and c 4 = "WhisperMessageKeys", can be considered as independent random oracles; more formally, we show that they are indifferentiable [START_REF] Coron | Merkle-Damgård revisited: How to construct a hash function[END_REF] from independent random oracles.

Definition 3 (Indifferentiability).

A function F with oracle access to a random oracle H is (t D , t S , q, )-indifferentiable from a random oracle H if there exists a simulator S such that for any distinguisher

D | Pr[D F,H = 1] -Pr[D H ,S = 1]| ≤
The simulator S has oracle access to H and runs in time t S . The distinguisher D runs in time t D and makes at most q queries.

In the game G 0 = D F,H , the distinguisher interacts with the real function F and the random oracle H from which F is defined. In the game G 1 = D H ,S , the distinguisher interacts with a random oracle H instead of F , and with a simulator S, which simulates the behavior of the random oracle H using calls to H . Indifferentiability means that these two games are indistinguishable.

Theorem 4.4 in [START_REF] Dodis | To hash or not to hash again? (In)differentiability results for H2 and HMAC[END_REF] shows that HMAC-SHA256 is then indifferentiable from a random oracle, provided the MAC keys are less than the block size of the hash function minus one, which is true here: the block size of SHA256 is 512 bits and the MAC keys are 256-bit long.

In the four calls to HKDF that we consider, we did not make explicit the length of the returned key material. This length is at most 512 bits, so we can consider that HKDF is defined by truncation of the following function HKDF 2 to the desired length:

HKDF 2 (salt, key, info) = K 1 K 2 where prk = HMAC-H salt ((), key) K 1 = HMAC-H prk ((), info 0x00) K 2 = HMAC-H prk ((), K 1 info 0x01) (1.3)
and HKDF(key, salt, info) is a truncation of HKDF 2 (salt, key, info). Much like for HMAC in [START_REF] Dodis | To hash or not to hash again? (In)differentiability results for H2 and HMAC[END_REF], this function is not indifferentiable from a random oracle in general. Intuitively, the problem comes from a confusion between the first and the second (or third) call to HMAC-H , () which makes it possible to generate prk by calling HKDF 2 rather than HMAC-H . () In more detail, let

prk _ = HKDF 2 (s, k, i) salt = HMAC-H s ((), k) x = HMAC-H prk ((), info 0x00) x _ = HKDF 2 (salt, i 0x00, info)
where the notation x 1 x 2 = HKDF 2 (s, k, i) denotes that x 1 consists of the first 256 bits of HKDF 2 (s, k, i) and x 2 its last 256 bits.

When HKDF 2 is defined from HMAC-H a ()s above, we have prk = HMAC-H prk (() , i 0x00) where prk = HMAC-H s ((), k) = salt, so prk = HMAC-H salt ((), i 0x00). Hence, x = HMAC-H prk ((), info 0) = x. However, when HKDF 2 is a random oracle and HMAC-H i ()s defined from HKDF 2 , the simulator that computes HMAC-H s ()ees what seems to be two unrelated calls to HMAC-H . () (It is unable to see that prk is in fact related to the previous call salt = HMAC-H s ((), k): we have prk _ = HKDF 2 (s, k, i) but the simulator does not know which value of i it should use.) Therefore, the simulator can only return fresh random values for salt and x and x = x in general.

We can however recover the indifferentiability of HKDF 2 under the additional assumption that the three calls to HMAC-H u ()se disjoint domains. Let S, K and I be the sets of possible values of salt, key and info respectively and M the set of 256-bit bitstrings, output of HMAC-H . ()

Lemma 1. If K ∩ (I 0x00 ∪ M I 0x01) = ∅
and S consists of bitstrings of 256 bits, then HKDF 2 with domain S × K × I is (t D , t S , q, )-indifferentiable from a random oracle, where = O(q 2 /|M|) and t S = O(q 2 ) and O just hides small constants.

Proof. Consider

• the game G 0 in which HMAC-H i ()s a random oracle and HKDF 2 is defined from HMAC-H b ()y (1.3) and

• the game G 1 in which HKDF 2 is a random oracle and HMAC-H i ()s defined as follows.

CHAPTER 1. SECURE MESSAGING

Let L be a list of pairs ((k, m), r) such that r is the result of a previous call to HMAC-H k ((), m). The list L is initially empty.

HMAC-H k ((), m) = 1. if ((k, m), r) ∈ L for some r, then return r, else 2. if ((k 0 , m 0 ), k) ∈ L for some k 0 ∈ S and m 0 ∈ K and m = info 0x00 for some info ∈ I, then let r _ = HKDF 2 (k 0 , m 0 , info), else 3. if ((k 0 , m 0 ), k) ∈ L for some k 0 ∈ S and m 0 ∈ K and m = k 1 info 0x01 for some k 1 ∈ M and info ∈ I, then let k 1 k 2 = HKDF 2 (k 0 , m 0 , info); if k 1 = k 1 , then r = k 2 ;
4. otherwise, let r be a fresh random element of M;

5. add ((k, m), r) to L;

6. return r.

We name direct oracle calls to HKDF 2 or HMAC-H c ()alls that are done directly by the distinguisher and indirect oracle calls the calls to HMAC-H d ()one from inside HKDF 2 (in G 0 ) and the calls to HKDF 2 done from inside HMAC-H ( ()in G 1 ).

Let us show that these two games are indistinguishable as long as, in G 0 , H1. HMAC-H n ()ever returns the same result for different arguments, HYP2.1 H2. no fresh result of HMAC-H i ()s equal to the first argument of a previous call to HMAC-H , () HYP2.2

H3. the distinguisher never calls HMAC-H k ((), m) where k = HMAC-H salt ((), key) has been called from inside HKDF 2 but not directly by the distinguisher, H4. and HMAC-H prk ((), info 0x00) never returns a fresh k 1 such that HMAC-H prk ((), k 1 info 0x01) has been called (directly or indirectly) before, HYP2.4

and in G 1 , H5. there are no two elements ((k, m), r) and

((k , m ), r) in L with (k, m) = (k , m ),
H6. no returned r is equal to a previous k, H7. if the distinguisher calls HMAC-H prk ((), k 1 info 0x01) with ((salt, key), prk) ∈ L and k 1 _ = HKDF 2 (salt, key, info), then HKDF 2 (salt, key, info) has been called (directly or indirectly at step 2) before the call to HMAC-H prk ((), k 1 info 0x01).

We have the following invariant:

P1. Given salt, key, there is at most one prk such that ((salt, key), prk) ∈ L.

CRYPTOGRAPHIC PROOFS WITH CRYPTOVERIF

51

Indeed, when L contains such an element, calls to HMAC-H salt ((), key) immediately return prk at step 1 and never add another element ((salt, key), prk ) to L. Case 1. Suppose the distinguisher makes a direct oracle call to HKDF 2 or HMAC-H w ()ith the same arguments as a previous direct call to the same oracle. Both G 0 and G 1 return the same result as in the previous call.

Case 2. Suppose the distinguisher makes a direct call to HMAC-H k ((), m) with arguments that do not occur in a previous direct call to HMAC-H . () Case 2.a) In G 0 , this HMAC-H c ()all has already been done as HMAC-H salt ((), key) from inside HKDF 2 . In G 0 , the result is prk = HMAC-H salt ((), key), which is independent from previously returned values, so it looks like a fresh random value to the distinguisher. In G 1 , we cannot have m = info 0x00 nor m = k 1 info 0x01 because m = key ∈ K which is disjoint from I 0x00 and from M I 0x01, so HMAC-H r ()eturns a fresh random value.

Case 2.b) In G 0 , this HMAC-H c ()all has already been done as HMAC-H prk ((), info 0x00) from inside HKDF 2 (salt, key, info). Hence HMAC-H k ((), m) = HMAC-H prk ((), info 0x00) is the first 256 bits of HKDF 2 (salt, key, info) and prk = HMAC-H salt ((), key). Since by H3, the distinguisher never calls HMAC-H k ((), m) where k = HMAC-H salt ((), key) has been called from inside HKDF 2 but not directly by the distinguisher, HMAC-H salt ((), key) has been called directly by the distinguisher. In G 1 , since HMAC-H salt ((), key) has been called, ((salt, key), prk) ∈ L, so HMAC-H k ((), m) = HMAC-H prk ((), info 0x00) returns the first 256 bits of HKDF 2 (salt, key, info) (step 2), as in G 0 .

Case 2.c) In G 0 , this HMAC-H c ()all has already been done as HMAC-H prk ((), K 1 info 0x01) from inside HKDF 2 (salt, key, info). Hence HMAC-H k ((), m) = HMAC-H prk ((), K 1 info 0x01) is the last 256 bits of HKDF 2 (salt, key, info), prk = HMAC-H salt ((), key) and K 1 = HMAC-H prk ((), info 0x00) is the first 256 bits of HKDF 2 (salt, key, info). As above, HMAC-H salt ((), key) has been called directly by the distinguisher. In G 1 , since HMAC-H salt ((), key) has been called, ((salt, key), prk) ∈ L, so, since K 1 is the first 256 bits of HKDF 2 (salt, key, info), HMAC-H k ((), m) = HMAC-H prk ((), K 1 info 0x01) returns the last 256 bits of HKDF 2 (salt, key, info) (step 3), as in G 0 .

Case 2.d) In G 0 , this HMAC-H c ()all has never been done, directly or indirectly. Hence, HMAC-H r ()eturns a fresh random value. In G 1 , if ((salt, key), k) ∈ L, then HMAC-H m ()ay return the first or last 256 bits of HKDF 2 (salt, key, info). However, since HMAC-H k ((), m) has not been called from HKDF 2 in G 0 , HKDF 2 (salt, key, info) has not been called directly by the distinguisher, so the result of HMAC-H a ()lways looks like a fresh random value to the distinguisher. Case 3. Suppose the distinguisher makes a direct call to HKDF 2 (salt, key, info) with arguments that do not occur in a previous direct call to HKDF 2 .

Case 3.a)

In G 1 , this call to HKDF 2 has already been done from HMAC-H . () Hence ((salt, key), prk) ∈ L and HMAC-H prk ((), info 0x00) or HMAC-H prk ((), k 1 info 0x01) has been called. Since ((salt, key), prk) ∈ L, HMAC-H salt ((), key) has been called before the call to HMAC-H prk ((), info 0x00) or HMAC-H prk ((), k 1 info 0x01) and it has returned prk. Case 3.a) i) Suppose that HMAC-H prk ((), info 0x00) has been called and it returned k 1 and HMAC-H prk ((), k 1 info 0x01) has not been called. By step 2 of the definition of HMAC-H i ()n G 1 , since by H5, the only element of L of the form (_, prk) is ((salt, key), prk), of a previous call to HKDF 2 (salt, key, info).

The current call to HKDF 2 (salt, key, info) returns the same result, to its first 256 bits are HMAC-H prk ((), info 0x00). Its last 256 bits are independent from returned random values. Indeed, if a call to HMAC-H r ()eturns the last 256 bits of HKDF 2 (salt, key, info), then this call occurs in step 3 of HMAC-H a ()nd it is HMAC-H prk (() , m) with ((salt, key), prk ) ∈ L, m = k 1 info 0x01 and k 1 is the first 256 bits of HKDF 2 (salt, key, info). By P1, prk = prk. We have

k 1 = k 1 , so HMAC-H prk (() , m) is HMAC-H prk ((), k 1 info 0x01). But HMAC-H prk ((), k 1 info 0x01)
has not been called by hypothesis, so no previous call to HMAC-H r ()eturns the last 256 bits of HKDF 2 (salt, key, info). So the last 256 bits of HKDF 2 (salt, key, info) look like a fresh random value.

In G 0 , the first 256 bits of HKDF 2 (salt, key, info) are also HMAC-H prk ((), info 0x00), where prk = HMAC-H salt ((), key). Furthermore, the last 256 bits of HKDF 2 (salt, key, info) are independent of previously returned values. Indeed, HMAC-H prk ((), k 1 info 0x01) has not been called directly. Furthermore, it has not been called from previous calls to HKDF 2 , because, if HMAC-H prk ((), k 1 info 0x01) had been called from HKDF 2 (salt , key , info ), then by K ∩ (I 0x00 ∪ M I 0x01) = ∅, this call would be the last of the three calls to HMAC-H i ()n HKDF 2 (salt , key , info ), prk = HMAC-H salt (() , key ) and info = info. Since by H1, HMAC-H n ()ever returns the same result for different arguments, salt = salt and key = key, contradicting that HKDF 2 (salt, key, info) has not been called before. Therefore, the last 256 bits of HKDF 2 (salt, key, info) look like a fresh random value.

Case 3.a) ii) Suppose that HMAC-H prk ((), info 0x00) has been called and it returned k 1 and HMAC-H prk ((), k 1 info 0x01) has been called. By definition of HMAC-H i ()n G 1 , HMAC-H prk ((), info 0x00) is the first 256 bits of HKDF 2 (salt, key, info) (step 2) and HMAC-H prk ((), k 1 info 0x01) is its last 256 bits (step 3), so HKDF 2 (salt, key, info) = k 1 k 2 where k 1 = HMAC-H prk ((), info 0x00) and k 2 = HMAC-H prk ((), k 1 info 0x01). In G 0 , we have the same property by definition of HKDF 2 .

Case 3.a) iii) Otherwise, HMAC-H prk ((), info 0x00) has not been called. If HKDF 2 (salt, key, info) had been called from step 2 of HMAC-H , () then we would have called HMAC-H prk (() , m) with ((salt, key), prk ) ∈ L and m = info 0x00. Furthermore, by P1, prk = prk, so we would have called HMAC-H prk ((), info 0x00). Contradiction. So HKDF 2 (salt, key, info) has not been called from step 2 of HMAC-H . () Therefore, HKDF 2 (salt, key, info) has been called from step 3 of HMAC-H . () If HKDF 2 (salt, key, info) had been called at step 3 of HMAC-H a ()nd its last 256 bits were returned, then the distinguisher would have called HMAC-H prk (() , k 1 info 0x01) with ((salt, key), prk ) ∈ L and k 1 _ = HKDF 2 (salt, key, info). By H7, HKDF 2 (salt, key, info) would have been called before, either directly (excluded by hypothesis) or indirectly at step 2. Then the distinguisher would have called HMAC-H prk (() , info 0x00) with ((salt, key), prk ) ∈ L, so by P1, prk = prk, so this is excluded by hypothesis. Therefore, the last 256 bits of HKDF 2 (salt, key, info) were not returned at step 3.

We can then conclude that in G 1 , the value of HKDF 2 (salt, key, info) is independent from previously returned values, so it looks like a fresh random value.

In G 0 , HMAC-H salt ((), key) has been called directly and returned prk, HMAC-H prk ((), info 0x00) has not been called directly. If a previous call to HKDF 2 (salt , key , info ) called HMAC-H prk ((), info 0x00), then we would have info = info and prk = HMAC-H salt (() , key ). By H1, this would imply salt = salt and key = key, so HKDF 2 (salt, key, info) would have been called before, which is excluded by hypothesis. Therefore, HMAC-H prk ((), info 0x00) has not been called before, directly or indirectly. By H4, HMAC-H prk ((), k 1 info 0x01) has not been called before, with k 1 = HMAC-H prk ((), info 0x00). Therefore, HMAC-H prk ((), info 0x00) and HMAC-H prk ((), k 1 info 0x01) have not been called before, so their result is independent from previously returned values. Hence HKDF 2 (salt, key, info) is independent from previously returned values, as in G 1 .

Case 3.b)

In G 1 , this HKDF 2 call has never been done, directly or indirectly. Hence HKDF 2 returns a fresh random value. In G 0 , the result is obtained from calls to HMAC-H . () The distinguisher has not made these calls to HMAC-H d ()irectly calling HMAC-H salt ((), key) first, because otherwise the simulator for HMAC-H i ()n G 1 would have called HKDF 2 (salt, key, info). Furthermore, it cannot call HMAC-H salt ((), key) with result prk after calling HMAC-H prk ((), info 0x00) or HMAC-H prk ((), k 1 info 0x01) by H2. So the result of HKDF 2 is independent of the result of direct HMAC-H c ()alls made by the distinguisher. Moreover, other calls to HKDF 2 did not generate the same last two calls to HMAC-H , () because by H1, the first call to HMAC-H , () HMAC-H salt ((), key), never returns the same result for different arguments. random value to the distinguisher.

The previous proof shows that the games G 0 and G 1 are indistinguishable assuming the hypotheses H1-H7 hold. Let us bound the probability that they do not hold. Suppose that there are at most q (direct or indirect) queries to HMAC-H . () • The probability that H1 does not hold is at most the probability that among q random values in M, two of them collide, so it is at most q 2 /|M|.

• The probability that H2 does not hold is at most the probability that among q random values in M, one of them is equal to one among the q first arguments of HMAC-H q ()ueries, so it is also at most q 2 /|M|.

• When H3 does not hold, the distinguisher calls HMAC-H k ((), m) for a value k that happens to be equal to HMAC-H salt ((), key), which is independent of the values the distinguisher has seen, since HMAC-H salt ((), key) has not been called directly by the distinguisher. There are at most q values HMAC-H salt ((), key) and the distinguisher has q attempts, so the probability that H3 does not hold is at most q 2 /|M|.

• Similarly, when H4 does not hold, the fresh random value HMAC-H prk ((), info 0x00) collides with a previously fixed k 1 . There are at most q values HMAC-H prk ((), info 0x00) CHAPTER 1. SECURE MESSAGING and at most q values k 1 , so the probability that H4 does not hold is at most q 2 /|M|.

• Let us show that, if the random values r chosen at step 4 are all distinct and distinct from first and second halves of HKDF 2 results used in HMAC-H , () then H5 holds. The proof is by induction on the sequence of calls of HMAC-H . () If ((k, m), r) is added to L and r comes from a result of HKDF 2 at step 2 or 3, then k determines k 0 , m 0 uniquely by induction hypothesis and m determines info as well as which half of the result of HKDF 2 is r, hence r is uniquely determined from k, m and distinct from elements chosen at step 4 by hypothesis. If ((k, m), r) is added to L and r is chosen at step 4, then r is always distinct from elements already in L by hypothesis. This concludes the proof of our claim.

From this claim, we can easily see that the probability that H5 does not hold is at most q 2 /|M|.

• When H7 does not hold, the distinguisher calls HMAC-H prk ((), k 1 info 0x01) and k 1 happens to be equal to the first 256 bits of HKDF 2 (salt, key, info) which is independent from values returned to the distinguisher. So the probability that H7 does not hold is at most q 2 /|M|.

Hence, the probability that the distinguisher distinguishes

G 0 from G 1 is at most 6q 2 /|M|.
The hypothesis of Lemma 1 is satisfied in our case because K consists of bitstrings of length 256 bits = 32 bytes or 3 × 32 = 96 bytes, I 0x00 consists of bitstrings of length at most 31 bytes and M I 0x01 consists of bitstrings of length between 33 and 63 bytes.

Lemma 2.

If H is a random oracle, then the functions H 1 , . . . , H n defined as H on disjoint subsets D 1 , . . . , D n of the domain D of H are (t D , t S , q, 0)indifferentiable from independent random oracles, where t S = O(q) assuming one can determine in constant time to which subset D i an element belongs.

Proof. Consider

• the game G 0 in which H is a random oracle and

H i (x) = H(x) for each x ∈ D i and i ≤ n and • the game G 1 in which H 1 , . . . H n are independent random oracles defined on D 1 , . . . , D n respectively and H(x) = H i (x) if x ∈ D i for some i ≤ n and H(x) = H 0 (x) otherwise, where H 0 is a random oracle of domain D \ (D 1 ∪ • • • ∪ D n ).
It is easy to see that these two games are perfectly indistinguishable, which proves indifferentiability.

CRYPTOGRAPHIC PROOFS WITH CRYPTOVERIF

55

By combining Lemmas 1 and 2, we obtain that

x 1 , x 2 , x 3 , x 4 → HKDF 2 (0, c 0 x 1 x 2 x 3 x 4 , c 2 ) x 1 , x 2 , x 3 → HKDF 2 (0, c 0 x 1 x 2 x 3 , c 2 )
x, y → HKDF 2 (x, y, c 2 )

x → HKDF 2 (0, x, c 4 ) are indifferentiable from independent random oracles. The domains are disjoint because different constants c 2 and c 4 are used and furthermore, the three cases that use c 2 differ by the length of their second argument (4×256 = 1024 bits plus the length of c 0 for

x 1 , x 2 , x 3 , x 4 → HKDF 2 (0, c 0 x 1 x 2 x 3 x 4 , c 2 ), 3 × 256 = 768 bits plus the length of c 0 for x 1 , x 2 , x 3 → HKDF 2 (0, c 0 x 1 x 2 x 3 , c 2
) and 256 bits for x, y → HKDF 2 (x, y, c 2 )).

Lemma 3.

If H is a random oracle that returns bitstrings of length l, then the truncation of H to length l < l is (t D , t S , q, 0)-indifferentiable from a random oracle, where t S = O(q).

Proof. Consider

• the game G 0 in which H is a random oracle and H (x) is H(x) truncated to length l and

• the game G 1 in which H is a random oracle that returns bitstrings of length l and

H(x) = H (x) H (x)
where H is a random oracle that returns bitstrings of length l -l .

It is easy to see that these two games are perfectly indistinguishable, which proves indifferentiability.

By combining Lemma 3 with the previous results, we conclude that

x 1 , x 2 , x 3 , x 4 → HKDF(c 0 x 1 x 2 x 3 x 4 , c 1 , c 2 ) x 1 , x 2 , x 3 → HKDF(c 0 x 1 x 2 x 3 , c 1 , c 2 )
x, y → HKDF(x, y, c 2 )

x → HKDF(x, c 1 , c 4 )
are indifferentiable from independent random oracles.

Protocol Model

We model SP as a process in the input language of CryptoVerif, which is similar to the one of ProVerif. We consider simultaneously the protocol of Figure 1.2 and the version without the optional one-time pre-key b o . As mentioned above, we consider only one message in each session. Our threat model includes an untrusted network, malicious principals and long-term key compromise. It does not include session state compromise, which is less useful with a single message.

To make verification easier for CryptoVerif, we specify a lower-level interface. We consider two honest principals Alice and Bob and define separate processes for Alice interacting with Bob, with herself, or with a malicious participant, Bob interacting with Alice and Bob interacting with himself or a malicious participant, as well as similar processes with the roles of Alice and Bob reversed. The adversary can then implement the high-level interface of § 4.2 from this lowerlevel interface: the adversary is supposed to implement the malicious principals (including defining keys for them) and to call the low-level interface processes to run sessions that involve the honest principals Alice and Bob.

We make two separate proofs: In the first one, we prove the security properties for sessions in which Bob generates pre-keys and runs the protocol with Alice. (Other protocol sessions exist in parallel as described above; we do not prove security properties for them. For sessions for which we do not prove security properties, we give to the adversary the ephemeral a e and the key rk ba or rk ba and let the adversary encrypt and MAC the message himself, to reduce the size of our processes.) In the second one, we prove the security properties for sessions in which Alice generates pre-keys and runs the protocol with herself. Bob is included in the adversary in this proof. The security for sessions in which Alice generates pre-keys and runs the protocol with Bob follows from the first proof by symmetry. The security for sessions in which Bob generates pre-keys and runs the protocol with himself follows from the second proof. The other sessions do not satisfy security properties since they involve the adversary. (They must still be modeled, as they could break the protocol if it were badly designed.) Therefore, these two proofs provide all desired security properties.

Security Goals

We consider the following security goals from § 4.2:

Message Authenticity, No Replays and Key Compromise Impersonation (KCI).

These properties are modeled by correspondences as in ProVerif ( § 1.3.2). For key compromise impersonation, we consider the compromise of the long-term Diffie-Hellman and signature keys of Bob and prove again message authenticity. We do not consider the compromise of the signed pre-key since we already know from the symbolic analysis that there is an attack in this case.

Computational Indistinguishability.

If A randomly chooses between two messages M 0 , M 1 of the same length and sends one of them to B, then the adversary has a negligible probability of guessing which of the two messages was sent. In our model, this is formalized by choosing a random bit secb ∈ {0, 1}; then A sends message M b to B and we show that the bit secb remains secret, with the query secret secb.

Forward Secrecy. This is proved exactly like indistinguishability, but with an additional oracle that allows the adversary to obtain the secret keys of the principals, thus compromising them.

We do not consider future secrecy since we have a single message. We do

CONCLUSION AND RELATED WORK

57 not consider secrecy since we directly deal with the stronger property of indistinguishability.

Results

CryptoVerif proves message authenticity, absence of key compromise impersonation attacks (when the long-term keys of Bob are compromised), indistinguishability and forward secrecy, but cannot prove absence of replays. This is due to the replay attack mentioned in § 1.3.2. Since this attack appears only when the optional one-time pre-key is omitted, we separate our property into two: we use events Send(A, B, M ) and Recv(A, B, M ) for the protocol with optional pre-key and events Send3(A, B, M ) and Recv3(A, B, M ) for the protocol without optional pre-key. CryptoVerif then proves

inj-event(Recv(A, B, M )) =⇒ inj-event(Send(A, B, M )) event(Recv3(A, B, M )) =⇒ event(Send3(A, B, M ))
which proves message authenticity and no replays when the one-time pre-key is present and only message authenticity when it is absent. This is the strongest we can hope for the protocol without anti-replay countermeasure.

With our anti-replay countermeasure ( §1.3.2), CryptoVerif can prove the absence of replays, thanks to a recent extension that allows CryptoVerif to take into account the replay cache in the proof of injective correspondences, implemented in CryptoVerif version 1.24. Our CryptoVerif proofs have been obtained with some manual guidance: we indicated the main security assumptions to apply, instructed CryptoVerif to simplify the games or to replace some variables with their values, to make terms such as m a = m b appear. The proofs were similar for all properties.

Conclusion and Related Work

While the ambition of cryptographic protocols found in web applications continues to grow, there remains a large disconnect between implementation and formal guarantees.

Drawing from existing design trends in modern cryptographic web application, we have presented a framework that supports the incremental development of custom cryptographic protocols hand-in-hand with formal security analysis. By leveraging state-of-the-art protocol verification tools and building new tools, we showed how many routine tasks can be automated, allowing the protocol designer to focus on the important task of analyzing her protocol for sophisticated security goals against powerful adversaries.

Unger et al. survey previous work on secure messaging [START_REF] Unger | SoK: Secure messaging[END_REF]. We discuss three recent closely-related works here. Future secrecy was formalized by Cohn-Gordon et al. as "post-compromise security" [START_REF] Cohn-Gordon | On Post-Compromise Security[END_REF]. Our symbolic formulation is slightly different since it relies on the definition of protocol phases in ProVerif.

Cryptographic security theorems and potential unknown key-share attacks on TextSecure Version 2 were presented by Frosch et al. [START_REF] Frosch | How Secure is TextSecure[END_REF]. In comparison to that work, our analysis covers a variant of TextSecure Version 3 called SP. Our analysis is also fully mechanized, and we address implementation details. Our CryptoVerif model only covers a single message, but we consider the whole protocol at once, while they prove pieces of the protocol separately. Like we do, they consider that HKDF is a random oracle. We further justify this assumption by an indifferentiability proof.

In parallel with this work, Cohn-Gordon et al. [START_REF] Cohn-Gordon | A formal security analysis of the signal messaging protocol[END_REF] proved, by hand, that the message encryption keys of Signal are secret in the computational model, in a rich compromise scenario, under assumptions similar to ours. Thereby, they provide a detailed proof of the properties of the double ratcheting mechanism. However, they do not model the signatures of the signed pre-keys, and they do not consider key compromise impersonation attacks or replay attacks or other implementation-level details. In contrast to their work, our computational proof is mechanized, but limited to only one message.

After more recent work outlined serious shortcomings in secure group messaging protocols [START_REF] Rösler | More is less: On the end-to-end security of group chats in signal, whatsapp, and threema[END_REF], largely due to underspecification, efforts have sufaced to standardize group secure messaging as "Message Layer Security" (MLS) through the IETF, in a fashion similar to TLS. Initially, the foundation for MLS's session management algorithm was a new concept by Cohn-Gordon et al called "Asynchronous Ratcheting Trees" [START_REF] Cohn-Gordon | On ends-to-ends encryption: asynchronous group messaging with strong security guarantees[END_REF] (ART). Since then, competing designs for MLS's core session management logic have been proposed, most notably TreeKEM [START_REF] Karthikeyan Bhargavan | Treebased KEM for group key management[END_REF].

Chapter 2

Formal Verification for Transport Layer Security

This work was published in the proceedings for the 38th IEEE Symposium on Security and Privacy, 2017. It was completed with co-authors Karthikeyan Bhargavan and Bruno Blanchet. In this particular work, my role was largely assistive, with Bhargavan and Blanchet leading the way.

In 2014, the TLS working group at the IETF commenced work on TLS 1.3, with the goal of designing a faster protocol inspired by the success of Google's QUIC protocol [START_REF] Hamilton | QUIC: A UDP-based multiplexed and secure transport[END_REF]. Learning from the pitfalls of TLS 1.2, the working group invited the research community to contribute to the design of the protocol and help analyze its security even before the standard is published. A number of researchers, including the authors of this chapter, responded by developing new security models and cryptographic proofs for various draft versions and using their analyses to propose protocol changes. Cryptographic proofs were developed for Draft-5 [START_REF] Dowling | A cryptographic analysis of the TLS 1.3 handshake protocol candidates[END_REF], Draft-9 [START_REF] Krawczyk | The OPTLS protocol and TLS 1.3[END_REF], and Draft-10 [START_REF] Li | Multiple handshakes security of TLS 1.3 candidates[END_REF], which justified the core design of the protocol. A detailed symbolic model in Tamarin was developed for Draft-10 [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF]. Other works studied specific aspects of TLS 1.3, such as key confirmation [START_REF] Fischlin | Key confirmation in key exchange: A formal treatment and implications for TLS 1.3[END_REF], client authentication [START_REF] Krawczyk | A unilateral-to-mutual authentication compiler for key exchange (with applications to client authentication in TLS 1.3)[END_REF] and downgrade resilience [START_REF] Bhargavan | Downgrade resilience in key-exchange protocols[END_REF].

Some of these analyses also found attacks. The Tamarin analysis [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF] uncovered a potential attack on the composition of pre-shared keys and certificatebased authentication and this attack was prevented in Draft-11. A version downgrade attack was found in Draft-12 and its countermeasure in Draft-13 was proved secure [START_REF] Bhargavan | Downgrade resilience in key-exchange protocols[END_REF]. A cross-protocol attack on RSA signatures was described in [START_REF] Jager | On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption[END_REF]. Even in this work, we describe two vulnerabilities in 0-RTT client authentication that we discovered and reported, which influenced the subsequent designs of Draft-7 and -13.

After 18 drafts, TLS 1.3 is entering the final phase of standardization. Although many of its design decisions have now been vetted by multiple security analyses, several unanswered questions remain. First, the protocol has continued to evolve rapidly with every draft version, so many of the cryptographic proofs 60 CHAPTER 2. TRANSPORT LAYER SECURITY cited above are already obsolete and do not apply to Draft-18. Since many of these are manual proofs, it is not easy to update them and check all the proof steps. Second, none of these symbolic or cryptographic analyses, with the exception of [START_REF] Bhargavan | Downgrade resilience in key-exchange protocols[END_REF], consider the composition of TLS 1.3 with legacy versions like TLS 1.2. Hence, they do not account for attacks like [START_REF] Jager | On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption[END_REF] that exploit weak legacy crypto in TLS 1.2 to break the modern cryptographic constructions of TLS 1.3. Third, none of these works addresses TLS 1.3 implementations. In this work, we seek to cover these gaps with a new comprehensive analysis of TLS 1.3 Draft-18.

Our Contributions

We propose a methodology for developing mechanically verified models of TLS 1.3 alongside a high-assurance reference implementation of the protocol.

We present symbolic protocol models for TLS 1.3 written in ProVerif [START_REF] Blanchet | Modeling and verifying security protocols with the applied pi calculus and ProVerif[END_REF]. They incorporate a novel security model (described in §2.1) that accounts for all recent attacks on TLS, including those relying on weak cryptographic algorithms. In §2.2-2.4, we use ProVerif to evaluate various modes and drafts of TLS 1.3 culminating in the first symbolic analysis of Draft-18 and the first composite analysis of TLS 1.3+1.2. Our analyses uncover known and new vulnerabilities that influenced the final design of Draft-18. Some of the features we study no longer appear in the protocol, but our analysis is still useful for posterity, to warn protocol designers and developers who may be tempted to reintroduce these problematic features in the future.

In §2.5, we develop the first machine-checked cryptographic proof for TLS 1.3 using the verification tool CryptoVerif [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF]. Our proof reduces the security of TLS 1.3 Draft-18 to standard cryptographic assumptions over its primitives. In contrast to manual proofs, our CryptoVerif script can be more easily updated from draft-to-draft and as the protocol evolves.

Our ProVerif and CryptoVerif models capture the protocol core of TLS 1.3, but they elide many implementation details such as the protocol API and state machine. To demonstrate that our security results apply to carefully-written implementations of TLS 1.3, we present RefTLS ( §5.3) in Chapter 6 of this thesis, the first reference implementation of TLS 1.0-1.3 whose core protocol code has been formally analyzed for security. RefTLS is written in Flow, a statically typed variant of JavaScript and is structured so that all its protocol code is isolated in a single module that can be automatically translated to ProVerif and symbolically analyzed against our rich threat model.

Our models and code are available at: https://github.com/inria-prosecco/reftls Since a client and server may support different sets of features, they first negotiate a protocol mode that they have in common. In TLS, the client C makes an offer C and the server chooses its preferred mode S , which includes the protocol version, the key exchange protocol, the authenticated encryption scheme, the Diffie-Hellman group (if applicable) and the signature and hash algorithms.

TLS 1.3 1-RTT: Simpler, Faster Handshakes

Then, C and S execute the negotiated authenticated key exchange protocol (e.g. Ephemeral Elliptic-Curve Diffie Hellman), which may use some combination of the long-term keys (e.g. public/private key pairs, symmetric pre-shared keys) known to the client and server. The key exchange ends by computing fresh symmetric keys (k c , k s ) for a new session (with identifier cid) between C and S and potentially a new pre-shared key (psk ) that can be used to authenticate future connections between them.

In TLS, the negotiation and key exchange phases are together called the handshake protocol. Once the handshake is complete, C and S can start exchanging application data, protected by an authenticated encryption scheme (e.g. AES-GCM) with the session keys (k c , k s ). The TLS protocol layer that

ClientHello(n C , offer C [(G, g x ), G ]) RetryRequest(G )
Generates x and computes: es = kdf 0

Generates y and computes:

es = kdf 0 ClientHello(n C , offer C [G , g x ])
Chooses parameters: mode S = (TLS1.3, DHE(G ), hash(), enc())

log 1 log 1 ServerHello(n S , mode S [G , g y ]) Computes: hs = kdf hs (es, g x y ) ms, k h c , k h s , k m c , k m s = kdf ms (hs, log 1 )
Computes:

hs = kdf hs (es, g x y ) ms, k h c , k h s , k m c , k m s = kdf ms (hs, log 1 ) enc k h s (Extensions(. . .)) enc k h s (CertRequest(. . .)) log 2 log 2 enc k h s (Certificate(pk S )) log 3 log 3 enc k h s (CertVerify(sign skS (hash(log 2 )))) log 4 log 4 enc k h s (Finished(mac k m s (hash(log 3 )))) Computes: k c , k s , ems = kdf k (ms, log 4 ) Computes: k c , k s , ems = kdf k (ms, log 4 ) log 5 log 5 enc k h c (Certificate(pk C )) log 6 log 6 enc k h c (CertVerify(sign skC (hash(log 5 )))) log 7 log 7 enc k h c (Finished(mac k m c (hash(log 6 ))))
Computes: psk = kdf psk (ms, log handles authenticated encryption for application data is called the record protocol.

Security Goals for TLS

Each phase of a TLS connection has its own correctness and security goals. For example, during negotiation, the server must choose a mode S that is consistent with the client's offer C ; the key exchange must produce a secret session key and so on. Although these intermediate security goals are important building blocks towards the security of the full TLS protocol, they are less meaningful to applications that typically use TLS via a TCP-socket-like API and are unaware of the protocol's internal structure. Consequently, we state the security goals of TLS from the viewpoint of the application, in terms of messages it sends and receives over a protocol session.

All goals are for messages between honest and authenticated clients and servers, that is, for those whose long-term keys (sk C , sk S , psk) are unknown to the attacker. If only the server is authenticated, then the goals are stated solely from the viewpoint of the client, since the server does not know whether it is talking to an honest client or the attacker.

Secrecy: If an application data message m is sent over a session cid between an honest client C and honest server S, then this message is kept confidential from an attacker who cannot break the cryptographic constructions used in the session cid.

Forward Secrecy: Secrecy (above) holds even if the long-term keys of the client and server (sk C , pk C , psk) are given to the adversary after the session cid has been completed and the session keys k c , k s are deleted by C and S.

Authentication: If an application data message m is received over a session cid from an honest and authenticated peer, then the peer must have sent the same application data m in a matching session (with the same parameters cid, offer C , mode S , pk C , pk S , psk, k c , k s , psk ).

Replay Prevention: Any application data m sent over a session cid may be accepted at most once by the peer.

Unique Channel Identifier: If a client session and a server session have the same identifier cid, then all other parameters in these sessions must match (same cid, offer C , mode S , pk C , pk S , psk, k c , k s , psk ).

These security goals encompass most of the standard security goals for secure channel protocols such as TLS. For example, secrecy for application data implicitly requires that the authenticated key exchange must generate secret keys. Authentication incorporates the requirement that the client and server must have matching sessions and in particular, that they agree on each others' identities as well as the inputs and outputs of negotiation. Hence, it prohibits client and server impersonation and man-in-the-middle downgrade attacks.

The requirement for a unique channel identifier is a bit more unusual, but it allows multiple TLS sessions to be securely composed, for example via session CHAPTER 2. TRANSPORT LAYER SECURITY resumption or renegotiation, without exposing them to credential forwarding attacks like Triple Handshake [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF]. The channel identifier could itself be a session key or a value generated from it, but is more usually a public value that is derived from session data contributed by both the client and server [START_REF] Bhargavan | Verified contributive channel bindings for compound authentication[END_REF].

A Realistic Threat Model for TLS

We seek to analyze TLS 1.3 for the above security goals against a rich threat model that includes both classic protocol adversaries as well as new ones that apply specifically to multi-mode protocols like TLS. In particular, we model recent downgrade attacks on TLS by allowing the use of weak cryptographic algorithms in older versions of TLS. In our analyses, the attacker can use any of the following attack vectors to disrupt the protocol.

• Network Adversary: As usual, we assume that the attacker can intercept, modify and send all messages sent on public network channels.

• Compromised Principals: The attacker can compromise any client or server principal P by asking for its long-term secrets, such as its private key (sk P ) or pre-shared key (psk). We do not restrict which principals can be compromised, but whenever such a compromise occurs, we mark it with a security event: Compromised(pk P ) or CompromisedPSK(psk). If the compromise event occurs after a session is complete, we issue a different security event: PostSessionCompromise(cid, pk P ).

• Weak Long-term Keys: If the client or server has a weak key that the attacker may be able to break with sufficient computation, we treat such keys the same way as compromised keys and we issue a more general event:WeakOrCompromised(pk P ). This conservative model of weak keys is enough to uncover attacks that rely on the use of 512-bit RSA keys by TLS servers.

• RSA Decryption Oracles: TLS versions up to 1.2 use RSA PKCS#1 v1.5 encryption, which is known to be vulnerable to a form of padding oracle attack on decryption originally discovered by Bleichenbacher [START_REF] Bleichenbacher | Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1[END_REF]. Although countermeasures to this attack have been incorporated into TLS, they remains hard to implement securely [START_REF] Meyer | Revisiting SSL/TLS implementations: New Bleichenbacher side channels and attacks[END_REF] resulting in continued attacks such as DROWN [START_REF] Aviram | DROWN: breaking TLS using SSLv2[END_REF]. Furthermore, such padding oracles can sometimes even be converted to signature oracles for the corresponding private key [START_REF] Jager | On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption[END_REF].

We assume that any TLS server (at any version) that enables RSA decryption may potentially be vulnerable to such attacks. We distinguish between two kinds of RSA key exchange: RSA(StrongRSADecryption) and RSA(WeakRSADecryption). In any session, if the server chooses the latter, we provide the attacker with a decryption and signature oracle for that private key.

• Weak Diffie-Hellman Groups: To account for attacks like Logjam [START_REF] Adrian | Imperfect forward secrecy: How Diffie-Hellman fails in practice[END_REF], we allow servers to choose between strong and weak Diffie-Hellman groups (or elliptic curves) and mark the corresponding key exchange mode as DHE(StrongDH) or DHE(WeakDH). We conservatively assume that weak groups have size 1, so all Diffie-Hellman exponentiations in these groups return the same distinguished element BadElement.

Even strong Diffie-Hellman groups typically have small subgroups that should be avoided. We model these subgroups by allowing a weak subgroup (of size 1) even within a strong group. A malicious client or server may choose BadElement as its public value and then all exponentiations with this element as the base will also return BadElement. To avoid generating keys in this subgroup, clients and servers must validate the received public value.

• Weak Hash Functions: TLS uses hash functions for key derivation, HMAC and for signatures. Versions up to TLS 1.2 use various combinations of MD5 and SHA-1, both of which are considered weak today, leading to exploitable attacks on TLS such as SLOTH [START_REF] Bhargavan | Transcript collision attacks: Breaking authentication in TLS, IKE, and SSH[END_REF].

We model both strong and weak hash functions and the client and server get to negotiate which function they will use in signatures. Strong hash functions are treated as one-way functions in our symbolic model, whereas weak hash functions are treated as point functions that map all inputs to a constant value: Collision. Hence, in our model, it is trivial for the attacker to find collisions as well as second preimages for weak hash functions.

• Weak Authenticated Encryption: To model recent attacks on RC4 [START_REF] Alfardan | On the security of RC4 in TLS[END_REF][START_REF] Vanhoef | All your biases belong to us: Breaking RC4 in WPA-TKIP and TLS[END_REF] and TripleDES [START_REF] Bhargavan | On the practical (in-)security of 64-bit block ciphers: Collision attacks on HTTP over TLS and Open-VPN[END_REF], we allow both weak and strong authenticated encryption schemes. For data encrypted with a weak scheme, irrespective of the key, we provide the adversary with a decryption oracle.

A number of attacks on the TLS Record protocol stem from its use of a MAC-Encode-Encrypt construction for CBC-mode ciphersuites. This construction is known to be vulnerable to padding oracle attacks such as POODLE [START_REF] Möller | This POODLE bites: exploiting the SSL 3.0 fallback[END_REF] and Lucky13 [START_REF] Nadhem | Lucky thirteen: Breaking the TLS and DTLS record protocols[END_REF], and countermeasures have proved hard to implement correctly [START_REF] Martin | Lucky microseconds: A timing attack on Amazon's S2N implementation of TLS[END_REF]. We model such attacks using a leaky decryption function. Whenever a client or server decrypts a message with this function, the function returns the right result but also leaks the plaintext to the adversary.

The series of threats described above comprise our conservative threat model for TLS 1.3 and incorporates entire classes of attacks that have been shown to be effective against older versions of the protocol, including Triple Handshake, POODLE, Lucky 13, RC4 NOMORE, FREAK, Logjam, SLOTH, DROWN. In most cases, we assume strictly stronger adversaries than have been demonstrated in practice, but since attacks only get better over time, our model seeks to be defensive against future attacks. It is worth noting that, even though TLS 1.3 does not itself support any weak ciphers, TLS 1.3 clients and servers will need to support legacy protocol versions for backwards compatibility. Our model enables a fine-grained analysis of vulnerabilities: we can ask whether TLS 1.3 connections between a client and a server are secure even if TLS 1.2 connections between them are broken.

Modeling the Threat Model in ProVerif

We encode our threat model as a generic ProVerif crypto library that can be used with any protocol. For each cryptographic primitive, our library contains constructors and destructors, that not only model the ideal behavior of strong cryptographic algorithms but also incorporates the possibility that honest protocol participants may support weak cryptographic algorithms.

Figure 2.3 displays our ProVerif model for Diffie-Hellman. We start by defining a type for groups; for simplicity, we only allow two groups (one strong, one weak). We then define a type for group elements and identify two distinguished elements that occur in every group, a basepoint G and an element BadElement that belongs to a trivial subgroup. The function dh_ideal exponentiates a (public) element with a (secret) scalar; the equation describing its behavior en- code the expected, ideal behaviour of Diffie-Hellman exponentiation. However, our protocol processes do not use dh_ideal; instead they call dh_exp which is parameterized by the group and behaves differently depending on the strength of the group and the validity of the element. If the group is strong and the element is a valid member of the group (that is, it does not belong to a small subgroup), then dh_exp behaves like dh_ideal. In all other cases, the result of dh_exp is the trivial element BadElement; that is, it is known to the attacker. The final letfun in the figure shows how Diffie-Hellman keys are generated. We note that our model of weak groups and bad elements is conservative and simplistic; we aim to verify the security of protocols that use strong groups, even if weak groups are catastrophically broken.

log 1 log 1 KeyExchange(g x , [cert C , sign skS (log 1 )]) Computes: (ms, k) = kdf(g xy , n C n S ) Computes: (ms, k) = kdf(g xy , n C n S ) log 2 log 2 enc k (Finished(mac ms (hash(log 1 )))) enc k (Finished(mac ms (hash(log 2 )))) enc k (Data(m 0 )) enc k (Data(m 1 )) Conversation: anon ↔ S : m 0 , m 1 Conversation: anon ↔ S : m 0 , m 1
Similarly to our model of Diffie-Hellman, we write models for AEAD, hash functions, HMAC, RSA signatures and encryption. Using these primitives, all the cryptographic constructions of TLS 1.2 and 1.3 are built as derived functions. To understand our security theorems, it is important for the analyst to carefully inspect our cryptographic library and agree with its implicit and explicit assumptions.

Modeling and Verifying TLS 1.2 in ProVerif

To evaluate our threat model and in preparation for our analysis of TLS 1.3, we symbolically analyze a model of TLS 1.2 using ProVerif. Our model includes TLS 1.2 clients and servers that support both RSA and Diffie-Hellman key exchanges and are willing to use both weak and strong cryptography. We assume that clients are unauthenticated.

For illustration, Figure 2.4 shows the Diffie-Hellman handshake followed by CHAPTER 2. TRANSPORT LAYER SECURITY the exchange of two application data fragments m 0 , m 1 . The handshake has four flights; the client sends a ClientHello offering a set of algorithms; the server responds with a ServerHello that chooses specific connection parameters and then sends its certificate and (signed) key exchange message. The client responds with its own key exchange message and a Finished message with a MAC of the handshake using the connection master secret ms. The server completes the handshake by sending its own Finished message. These last two messages are meant to guarantee agreement on the keys and the handshake transcript and they already encrypted with the new connection keys k. Once both have verified each others' finished messages, the application on top of TLS can start sending application data in the two directions. We write ProVerif processes for TLS 1.2 clients and servers that exchange messages according to the protocol flow described above and issue a sequence of events-ClientOffers, ServerChooses, ClientFinished, ServerFinished, ClientSends, ServerReceives-indicating their progress through the protocol. We then compose these processes with our threat model and add queries for message authenticity and secrecy.

For example, a secrecy query may ask whether the attacker can learn some application data message (say m 0 ) sent by the client over a particular connection (identified by the client and server random values and the server's public key):

When we run ProVerif for this query, it finds a counter-example: the attacker can learn m if it can compromise server's private key (WeakOrCompromised(pk S )). To check whether this is the only case in which m is leaked, we refine the secrecy query and run ProVerif again. ProVerif again finds a counter-example: the attacker can learn m if the server chooses a weak Diffie-Hellman group (ServerChoosesKex(DHE(WeakDH))). In this way, we keep refining our queries until we obtain the strongest secrecy query that holds for our TLS 1.2 model, that is, until we stop finding attacks: aek:ae_key, g:group, ra:rsa_alg, cb:bitstring, cr':random, sr':random, v:version; attacker(m_0(cr,sr,p)) ==> event(WeakOrCompromisedKey(p)) || event(ServerChoosesAE(cr,sr,p,TLS12,WeakAE)) || event(ServerChoosesKEX(cr,sr,p,TLS12,DHE(WeakDH))) || event(ServerChoosesKEX(cr',sr',p,TLS12,RSA(WeakRSADecryption))) || event(ServerChoosesHash(cr',sr',p,TLS12,WeakHash)) || (event(PostSessionCompromisedKey(p)) && event(ServerChoosesKEX(cr,sr,p,TLS12,RSA(ra)))) || This query is our main symbolic secrecy result for TLS 1.2; we similarly derive our strongest symbolic authenticaiton query. These two goals can be read as follows:

• TLS 1.2 (Forward) Secrecy: A message m sent by an honest client in a session cid to a server S cannot be known to the adversary unless one of the following conditions holds:

(1) the server's public key is weak or compromised, or

(2) the session uses weak authenticated encryption, or (3) the session uses a weak Diffie-Hellman group, or (4) the server uses weak RSA decryption with the same public key (in this or any other session), or (5) the server uses a weak hash function for signing with the same public key (in any session), or (6) the session uses an RSA key exchange and the server's public key was compromised after the session was complete.

• TLS 1.2 Authenticity & Replay Protection: Every message m accepted by an honest client in a session cid with some server S corresponds to a unique message sent by S on a matching session, unless one of the conditions (1)-( 5) above holds.

Both these queries are verified by ProVerif in a few seconds. All the disjuncts (1)-( 6) in these queries are necessary, removing any of them results in a counterexample discovered by ProVerif, corresponding to some well-known attack on badly configured TLS 1.2 connections.

Interestingly, the conditions (2), (3) are session specific, that is, only the sessions where these weak constructions are used are affected. In contrast, ( 4) and [START_REF] Garman | Dancing on the lip of the volcano: Chosen ciphertext attacks on apple imessage[END_REF] indicate that the use of weak RSA decryption or a weak hash function in any session affects all other sessions that use the same server public key. As we shall see, this has an impact on the security of TLS 1.3 when it is composed with TLS 1.2. (6) encodes our forward secrecy goal, which does not hold for connections that use RSA key exchange, but holds for (EC)DHE.

We also verify our TLS 1.2 model for more advanced properties, such as unique channel identifiers; we find that using the connection key cid = k c does not yield a unique identifier. ProVerif finds a variant of the Triple Handshake attack, unless we implement the recommended countermeasure [START_REF] Ray | Transport Layer Security (TLS) session hash and extended master secret extension[END_REF].

Verification Effort

The work of verifying TLS 1.2 can be divided into three tasks. We first modeled the threat model as a 400 line ProVerif library, but this library can now be reused for other protocols, including TLS 1.3. We then modeled the TLS 1.2 protocol in about 200 lines of ProVerif. Finally, we wrote about 50 lines of queries, both to validate our model (e.g. checking that the protocol completes in the absence of an attacker) and to prove our desired security goals. Most of the effort is in formalizing, refining, and discovering the right security queries. Although ProVerif is fully automated, verification gets more expensive as the protocol grows more complex. So, as we extend our models to cover multiple modes of TLS 1.3 composed with TLS 1.2, we sometimes need to simplify or restructure our models to aid verification.

In its simplest form, TLS 1.3 consists of a Diffie-Hellman handshake, typically using an elliptic curve, followed by application data encryption using an AEAD scheme like AES-GCM. The essential structure of 1-RTT has remained stable CHAPTER 2. TRANSPORT LAYER SECURITY Key Derivation Functions:

hkdf-extract(k, s) = HMAC-H k (s) hkdf-expand-label 1 (s, l, h) = HMAC-H s (len hash() "TLS 1.3, " l h 0x01) derive-secret(s, l, m) = hkdf-expand-label 1 (s, l, hash(m))
1-RTT Key Schedule:

kdf 0 = hkdf-extract(0 len hash() , 0 len hash() )
kdf hs (es, e) = hkdf-extract(es, e)

kdf ms (hs, log 1 ) = ms, k h c , k h s , k m c , k m
s where ms = hkdf-extract(hs, 0 len hash() ) hts c = derive-secret(hs, hts c , log 1 ) hts s = derive-secret(hs, hts s , log 1 ) since early drafts of TLS 1.3. It departs from the TLS 1.2 handshake in two ways. First, the key exchange is executed alongside the negotiation protocol so the client can start sending application data along with its second flight of messages (after one round-trip, hence 1-RTT), unlike TLS 1.2 where the client had to wait for two message flights from the server. Second, TLS 1.3 eliminates a number of problematic features in TLS 1.2; it removes RSA key transport, weak encryption schemes (RC4, TripleDES, AES-CBC) and renegotiation; it requires group negotiation with strong standardized Diffie-Hellman groups and it systematically binds session keys to the handshake log to prevent attacks like the Triple Handshake. In this section, we detail the protocol flow, we model it in ProVerif and we analyze it alongside TLS 1.2 in the security model of §2.1.

k h c = hkdf-expand-label(hts c , key, "") k m c = hkdf-expand-label(hts c , finished, "") k h s = hkdf-expand-label(hts s , key, "") k m s = hkdf-expand-label(hts s , finished, "") kdf k (ms, log 4 ) = k c , k s ,

1-RTT Protocol Flow

A typical 1-RTT connection in Draft 18 proceeds as shown in Figure 2.2. The first four messages form the negotiation phase. The client sends a ClientHello message containing a nonce n C and an offer C that lists the versions, groups, hash functions, and authenticated encryption algorithms that it supports. For each group G that the client supports, it may include a Diffie-Hellman key share g x . On receiving this message, the server chooses a mode S that fixes the version, group and all other session parameters. Typically, the server chooses a group G for which the client already provided a public value and so it can send its ServerHello containing a nonce n S , mode S and g y to the client. If none of the client's groups are acceptable, the server may ask the client (via RetryRequest) to resend the client hello with a key share g x for the server's preferred group G . (In this case, the handshake requires two round trips.) Once the client receives the ServerHello, the negotiation is complete and both participants derive handshake encryption keys from g x y , one in each direction (k h c , k h s ), with which they encrypt all subsequent handshake messages. The client and server also generate two MAC keys (k m c , k m s ) for use in the Finished messages described below. The server then sends a flight of up to 5 encrypted messages: Extensions contains any protocol extensions that were not sent in the ServerHello; CertRequest contains an optional request for a client certificate; Certificate contains the server's X.509 public-key certificate; CertVerify contains a signature with server's private key sk S over the log of the transcript so far (log 2 ); Finished contains a MAC with k m s over the current log (log 3 ). Then the server computes the 1-RTT traffic keys k c , k s and may immediately start using k s to encrypt application data to the client.

Upon receiving the server's encrypted handshake flight, the client verifies the certificate, the signature and the MAC and if all verifications succeed, the client sends its own second flight consisting of an optional certificate Certificate and signature CertVerify, followed by a mandatory Finished with a MAC over the full handshake log. Then the client starts sending its own application data encrypted under k c . Once the server receives the client's second flight, we consider the handshake complete and put all the session parameters into the local session databases at both client and server (C, S).

In addition to the traffic keys for the current session, the 1-RTT handshake generates two extra keys: ems is an exporter master secret that may be used by the application to bind authentication credentials to the TLS channel; psk is a resumption master secret that may be used as a pre-shared key in future TLS connections between C and S.

The derivation of keys in the protocol follows a linear key schedule, as depicted on the right of Figure 2.2. The first version of this key schedule was inspired by OPTLS [START_REF] Krawczyk | The OPTLS protocol and TLS 1.3[END_REF] and introduced into TLS 1.3 in Draft-7. The key idea in this design is to accumulate key material and handshake context into the derived keys using a series of HKDF invocations as the protocol progresses. For example, in connections that use pre-shared keys (see §2.4), the key schedule begins by deriving es from psk, but after the ServerHello, we add in g x y to obtain the handshake secret hs. Whenever we extract encryption keys, we mix in the current handshake log, in order to avoid key synchronization attacks like the Triple Handshake.

Since its introduction in Draft-7, the key schedule has undergone many changes, with a significant round of simplifications in Draft-13. Since all previously published analyses of 1-RTT predate Draft-13, this leaves open the question whether the current Draft-18 1-RTT protocol is still secure.

Modeling 1-RTT in ProVerif

We write client and server processes in ProVerif that implement the message sequence and key schedule of Figure 2.2.

Our models are abstract with respect to the message formats, treating each message (e.g. ClientHello(• • • )) as a symbolic constructor, with message parsing modeled as a pattern-match with this constructor. This means that our analysis assumes that message serialization and parsing is correct; it won't find any attacks that rely on parsing ambiguities or bugs. This abstract treatment of protocol messages is typical of symbolic models; the same approach is taken by Tamarin [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF]. In contrast, miTLS [START_REF] Bhargavan | Implementing TLS with verified cryptographic security[END_REF] includes a fully verified parser for TLS messages.

The key schedule is written as a sequence of ProVerif functions built using an HMAC function, hmac(H, m), which takes a hash function H as argument and is assumed to be a one-way function as long as H = StrongHash. All other cryptographic functions are modeled as described in §2.1, with both strong and weak variants.

Persistent state is encoded using tables. To model principals and their longterm keys, we use a global private table that maps principals (A) to their key pairs ((sk A , pk A )). To begin with, the adversary does not know any of the private keys in this table, but it can compromise any principal and obtain her private key. As described in §2.1, this compromise is recorded in ProVerif by an event WeakOrCompromised(pk A ).

As the client and server proceed through the handshake they record security events indicating their progress. We treat the negotiation logic abstractly; the adversary gets to choose offer C and mode S and we record these choices as events (ClientOffers, ServerChooses) at the client and server. When the handshake is complete, the client and server issue events ServerFinished, ClientFinished and store their newly established sessions in two private tables clientSession and serverSession (corresponding to C and S). These tables are used by the record layer to retrieve the traffic keys k c , k s for authenticated encryption. Whenever the client or server sends or receives an application data message, it issues further events (ClientSends, ServerReceives, etc.) We use all these events along with the client and server session tables to state our security goals.

1-RTT Security Goals

We encode our security goals as ProVerif queries as follows:

• Secrecy for a message, such as m 1 , is encoded using an auxiliary process that asks the adversary to guess the value of m 1 ; if the adversary succeeds, the process issues an event MessageLeaked(cid, m 1 ). We then write a query to ask ProVerif whether this event is reachable.

• Forward Secrecy is encoded using the same query, but we explicitly leak the client and server's long-term keys (sk C , sk S ) at the end of the session cid. ProVerif separately analyzes pre-compromise and post-compromise sessions as different phases; the forward secrecy query asks that messages sent in the first phase are kept secret even from attackers who learn the long-term keys in the second phase.

• Authentication for a message m 1 received by the server is written as a query that states that whenever the event ServerReceives(cid, m 1 ) occurs, it must be preceded by three matching events: ServerFinished(cid, . . .), ClientFinished(cid, . . .), and ClientSends(cid, m 1 ), which means that some honest client must have sent m 1 on a matching session. The authentication query for messages received by clients is similar.

• Replay protection is written as a stronger variant of the authentication query that requires injectivity: each ServerReceives event must correspond to a unique, matching, preceding ClientSends event.

• Unique Channel Identifiers are verified using another auxiliary process that looks up sessions from the clientSession and serverSession tables and checks that if the cid in both is the same, then all other parameters match. Otherwise it raises an event and we ask ProVerif to prove that this event is not reachable.

In addition to the above queries, our scripts often include auxiliary queries about session keys and other session variables. We do not detail all our queries here; instead, we only summarize the main verification results. When we first ask

CHAPTER 2. TRANSPORT LAYER SECURITY

ProVerif to verify these queries, it fails and provides counterexamples; for example, client message authentication does not hold if the client is compromised Compromised(pk C ) or unauthenticated in the session. We then refine the query by adding this failure condition as a disjunct and run ProVerif again and repeat the process until the query is proved. Consequently, our final verification results are often stated as a long series of disjuncts listing the cases where the desired security goal does not hold.

Verifying 1-RTT in Isolation

For our model of Draft-18 1-RTT, ProVerif can prove the following secrecy query about all messages (m 0.5 , m 1 , m 2 ):

• 1-RTT (Forward) Secrecy: Messages m sent in a session between C and S are secret as long as the private keys of C and S are not revealed before the end of the session and the server chooses a mode S with a strong Diffie-Hellman group, a strong hash function, and a strong authenticated encryption algorithm.

If we further assume that TLS 1.3 clients and servers only support strong algorithms, we can simplify the above query to show that all messages sent between uncompromised principals are kept secret. In the rest of this chapter, we assume that TLS 1.3 only enables strong algorithms, but that earlier versions of the protocol may continue to support weak algorithms. Messages m 1 from the client to the server enjoy strong authentication and protection from replays:

• 1-RTT Authentication (and Replay Prevention): If a message m is accepted by S over a session with an honest C, then this message corresponds to a unique message sent by the C over a matching session.

However the authentication guarantee for messages m 0.5 , m 1 received by the client is weaker. Since the client does not know whether the server sent this data before or after receiving the client's second flight, the client and server sessions may disagree about the client's identity. Hence, for these messages, we can only verify a weaker property:

• 0.5-RTT Weak Authentication (and Replay Prevention): If a message m is accepted by C over a session with an honest S, then this message corresponds to a unique message sent by S over a server session that matches all values in the client session except (possibly) the client's public key pk C , the resumption master secret psk and the channel identifier cid.

We note that by allowing the server to send 0.5-RTT data, Draft-18 has weakened the authentication guarantees for all data received by an authenticated client. For example, if a client requests personal data from the server over a client-authenticated 1-RTT session, a network attacker could delay the client's second flight (Certificate -Finished) so that when the client receives the server's 0.5-RTT data, it thinks that it contains personal data, but the server actually sent data intended for an anonymous client.

Verifying TLS 1.3 1-RTT composed with TLS 1.2

We combine our model with the TLS 1.2 model described at the end of §2.1 so that each client and server supports both versions. We then ask the same queries as above, but only for sessions where the server chooses TLS 1.3 as the version in mode S . Surprisingly, ProVerif finds two counterexamples.

First, if a server supports WeakRSADecryption with RSA key transport in TLS 1.2, then the attacker can use the RSA decryption oracle to forge TLS 1.3 server signatures and hence break our secrecy and authentication goals. This attack found by ProVerif directly corresponds to the cross-protocol Bleichenbacher attacks described in [START_REF] Jager | On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption[END_REF][START_REF] Aviram | DROWN: breaking TLS using SSLv2[END_REF]. It shows that removing RSA key transport from TLS 1.3 is not enough, one must disable the use of TLS 1.2 RSA mode on any server whose certificate may be accepted by a TLS 1.3 client.

Second, if a client or server supports a weak hash function for signatures in TLS 1.2, then ProVerif shows how the attacker can exploit this weakness to forge a TLS 1.2 signature and establish a TLS 1.2 session in our model, hence breaking our security goals. This attack corresponds to the SLOTH transcript collision attack on TLS 1.3 signatures described in [START_REF] Bhargavan | Transcript collision attacks: Breaking authentication in TLS, IKE, and SSH[END_REF]. To avoid this attack, TLS 1.3 implementations must disable weak hash functions in all supported versions, not just TLS 1.3.

After disabling these weak algorithms in TLS 1.2, we can indeed prove all our expected security goals about Draft-18 1-RTT, even when it is composed with TLS 1.2.

We may also ask whether TLS 1.3 clients and servers can be downgraded to TLS 1.2. If such a version downgrade takes place, we would end up with a TLS 1.2 session, so we need to state the query in terms of sessions where mode S contains TLS 1.2. ProVerif finds a version downgrade attack on a TLS 1.3 session, if the client and server support weak Diffie-Hellman groups in TLS 1.2. This attack closely mirrors the flaw described in [START_REF] Bhargavan | Downgrade resilience in key-exchange protocols[END_REF]. Draft-13 introduced a countermeasure in response to this attack and we verify that by adding it to the model, the downgrade attack disappears.

Although our models of TLS 1.3 and 1.2 are individually verified in a few seconds each, their composition takes several minutes to analyze. As we add more features and modes to the protocol, ProVerif takes longer and requires more memory. Our final composite model for all modes of TLS 1.3+1.2 takes hours on a powerful workstation.

0-RTT with Semi-Static Diffie-Hellman

In earlier versions of TLS, the client would have to wait for two round-trips of handshake messages before sending its request. 1-RTT in TLS 1.3 brings this down to one round trip, but protocols like QUIC use a "zero-round-trip" (0-RTT) mode, by relying on a semi-static (long-term) Diffie-Hellman key. This design was adapted for TLS in the OPTLS proposal [START_REF] Krawczyk | The OPTLS protocol and TLS 1.3[END_REF] and incorporated in Draft-7 (along with a fix we proposed, as described below).

Protocol Flow

The protocol is depicted in Figure 2.6. Each server maintains a Diffie-Hellman key pair (s, g s ) and publishes a signed server configuration containing g s . As usual, a client initiates a connection with a ClientHello containing its ephemeral key g x . If a client has already obtained and cached the server's certificate and signed configuration (in a prior exchange for example), then the client computes a shared secret g xs and uses it to derive an initial set of shared keys which can then immediately be used to send encrypted data. To authenticate its 0-RTT data, the client may optionally send a certificate and a signature over the client's first flight.

The server then responds with a ServerHello message that contains a fresh ephemeral public key g y . Now, the client and server can continue with a regular 1-RTT handshake using the new shared secret g xy in addition to g xs .

The 0-RTT protocol continued to evolve from Draft-7 to Draft-12, but in Draft-13, it was removed in favor of a PSK-based 0-RTT mode. Even though Diffie-Hellman-based 0-RTT no longer exists in Draft-18, we analyze its security in this section, both for posterity and to warn protocol designers about the problems they should watch our for if they decide to reintroduce DH-based 0-RTT in a future version of TLS.

Verification with ProVerif

We modeled the protocol in ProVerif and wrote queries to check whether the 0-RTT data m 0 is (forward) secret and authentic. ProVerif is able to prove secrecy but finds that m 0 is not forward secret if the semi-static key s is compromised once the session is over. ProVerif also finds a Key Compromise Impersonation attack on authentication: if g s is compromised, then an attacker can forge 0-RTT messages from C to S. Furthermore, the 0-RTT flight can be replayed by an attacker and the server will process it multiple times, thinking that the client has initiated a new connection each time. In addition to these three concerns, which were documented in Draft-7, ProVerif also finds a new attack, explained below, that breaks 0-RTT authentication if the server's certificate is not included in the 0-RTT client signature.

Unknown Key Share Attack on DH-based 0-RTT in QUIC, OPTLS, and TLS 1.3

We observe that in the 0-RTT protocol, the client starts using g s without having any proof that the server knows s. So a dishonest server M can claim to have the same semi-static key as S by signing g s under its own key sk M . Now, suppose a Certificate(pk S ) sign sk S (hash(ServerConfig(g s )))

Generates x log 1 log 1 ClientHello(n C , offer C [G, g x ]) Computes: k 0 h , k 0 m , k 0 c = kdf ss (g xs , log 1 )
Computes:

k 0 h , k 0 m , k 0 c = kdf ss (g xs , log 1 ) log 2 log 2 enc k 0 h (Certificate(pk C )) log 3 log 3 enc k 0 h (CertVerify(sign sk C (hash(log 2 )))) log 4 log 4 enc k 0 h (Finished(mac k 0 m (hash(log 3 )))) enc k 0 c (Data(m 0 )) ServerHello(n S , mode S [G, g y ]) (Continue 1-RTT Exchange)
New client session:

C = C cid → (offer C , mode S , pk C , pk S , psk, k c , k s , psk )
New server session: client connects to M and sends its client hello and 0-RTT data; M can simply forward this whole flight to S, which may accept it, because the semi-static keys match. This is an unknown key share (UKS) attack where C thinks it is talking to M but it is, in fact, connected to S.

S = S cid → (offer C , mode S , pk C , pk S , psk, k c , k s ,
In itself, the UKS attack is difficult to exploit, since M does not know g xs and hence cannot decrypt or tamper with messages between C and S. However, if the client authenticates its 0-RTT flight with a certificate, then M can forward C's certificate (and C's signature) to S, resulting in a credential forwarding attack, which is much more serious. Suppose C is a browser that has a page open at website M ; from this page M can trigger any authenticated 0-RTT HTTPS request m 0 to its own server, which then uses the credential forwarding attack to forward the request to S, who will process m 0 as if it came from C. For example, M may send a POST request that modifies C's account details at S.

log 1 log 1 mac k b (ClientHello(n C , offer C [G, g x , enc kt (psk)])) Computes: k 0 c = kdf 0RTT (es, log 1 )
Generates y, decrypts psk and computes:

es, k b = kdf es (psk) k 0 c = kdf 0RTT (es, log 1 )
enc k 0 c (Data(m 0 )) ServerHello(n S , mode S [G, g y ]) (Continue 1-RTT Exchange)
New client session:

C = C cid → (offer C , mode S , pk C , pk S , psk, k c , k s , psk )
New server session:

S = S cid → (offer C , mode S , pk C , pk S , psk, k c , k s , psk ) enc kc (Data(m 1 )) enc ks (Data(m 2 ))
Application Data Stream: The unknown key share attack described above applies to both QUIC and OPTLS, but remained undiscovered despite several security analyses of these protocols [START_REF] Fischlin | Multi-stage key exchange and the case of Google's QUIC protocol[END_REF][START_REF] Lychev | How secure and quick is QUIC? provable security and performance analyses[END_REF][START_REF] Krawczyk | The OPTLS protocol and TLS 1.3[END_REF], because these works did not consider client authentication and hence did not formulate an authentication goal that exposed the flaw. We informed the authors of QUIC and they acknowledged our attack. They now recommend that users who need client authentication should not use QUIC and should instead move over to TLS 1.3. We also informed the authors of the TLS 1.3 standard and on our suggestion, Draft-7 of TLS 1.3 included a countermeasure for this attack: the client signature and 0-RTT key derivation include not just the handshake log but also the cached server certificate. With this countermeasure in place, ProVerif proves authentication for 0-RTT data.

C cid ←→ S : m 0 , m 1 , m 2 , . . . Application Data Stream: C cid ←→ S : m 0 , m 1 , m 2 , . . .

Pre-Shared Keys for Resumption and 0-RTT

Aside from the number of round-trips, the main cryptographic cost of a TLS handshake is the use of public-key algorithms for signatures and Diffie-Hellman, which are still significantly slower than symmetric encryption and MACs. So, once a session has already been established between a client and server, it is tempting to reuse the symmetric session key established in this session as a pre-shared symmetric key in new connections. This mechanism is called session resumption in TLS 1.2 and is widely used in HTTPS where a single browser typically has many parallel and sequential connections to the same website. In TLS 1.2, pre-shared keys (PSKs) are also used instead of certificates by resourceconstrained devices that cannot afford public-key encryption. TLS 1.3 combines both these use-cases in a single PSK-based handshake mode that combines resumption, PSK-only handshakes and 0-RTT.

Protocol Flow

Figure 2.7 shows how this mode extends the regular 1-RTT handshake; in our analysis, we only consider PSKs that are established within TLS handshakes, but similar arguments apply to PSKs that are shared out-of-band. We assume that the client and server have established a pre-shared key psk in some earlier session. The client has cached psk, but in order to remain state-less, the server has given the client a ticket containing psk encrypted under an encryption key k t . As usual, the client sends a ClientHello with its ephemeral key share g x and indicates that it prefers to use the shared PSK psk. To prove its knowledge of psk and to avoid certain attacks (described below), it also MACs the ClientHello with a binder key k b derived from the psk. The client can then use psk to already derive an encryption key for 0-RTT data m 0 and start sending data without waiting for the server's response. When the server receives the client's flight, it can choose to accept or reject the offered psk. Even if it accepts the psk, the server may choose to reject the 0-RTT data, it may choose to skip certificate-based authentication and (if it does not care about forward secrecy) it may choose to skip the Diffie-Hellman exchange altogether. The recommended mode is PSK-DHE, where psk and g xy are both mixed into the session keys. The server then sends back a ServerHello with its choice and the protocol proceeds with the appropriate 1-RTT handshake and completes the session.

Verifying PSK-based Resumption

We first model the PSK-DHE 1-RTT handshake (without certificate authentication) and verify that it still meets our usual security goals:

• PSK-DHE 1-RTT (Forward) Secrecy Any message m sent over a PSK-DHE session in 1-RTT is secret as long as the PSK psk and the ticket encryption key k t are not compromised until the end of the session.

• PSK-DHE 1-RTT Authentication and Replay Protection Any message m received over a PSK-DHE session in 1-RTT corresponds to a unique message sent by a peer over a matching session (notably with the same psk) unless psk or k t are compromised during the session.

• PSK-DHE 1-RTT Unique Channel Identifier The values psk , ems, and hash(log 7 ) generated in a DHE or PSK-DHE session are all unique channel identifiers.

CHAPTER 2. TRANSPORT LAYER SECURITY

Notably, data sent over PSK-DHE is forward secret even if the server's long term ticket encryption key k t is compromised after the session. In contrast, pure PSK handshakes do not provide this forward secrecy.

The authentication guarantee requires that the client and server must agree on the value of the PSK psk and if this PSK was established in a prior session, then the unique channel identifier property says that the client and server must transitively agree on the prior session as well. An earlier analysis of Draft-10 in Tamarin [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF] found a violation of the authentication goal because the 1-RTT client signature in Draft-10 did not include the server's Finished or any other value that was bound to the PSK. This flaw was fixed in Draft-11 and hence we are able to prove authentication for Draft-18.

Verifying PSK-based 0-RTT. We extend our model with the 0-RTT exchange and verify that m 0 is authentic and secret. The strongest queries that ProVerif can prove are the following:

• PSK-based 0-RTT (Forward) Secrecy A message m 0 sent from C to S in a 0-RTT flight is secret as long as psk and k t are never compromised.

• PSK-based 0-RTT Authentication A message m 0 received by S from C in a 0-RTT flight corresponds to some message sent by C with a matching ClientHello and matching psk, unless the psk or k t are compromised.

In other words, PSK-based 0-RTT data is not forward secret and is vulnerable to replay attacks. As can be expected, it provides a symmetric authentication property: since both C and S know the psk, if either of them is compromised, the attacker can forge 0-RTT messages.

An Attack on 0-RTT Client Authentication

Up to Draft-12, the client could authenticate its 0-RTT data with a client certificate in addition to the PSK. This served the following use case: suppose a client and server establish an initial 1-RTT session (that outputs psk ) where the client is unauthenticated. Some time later, the server asks the client to authenticate itself and so they perform a PSK-DHE handshake (using psk ) with client authentication. The use of psk ensures continuity between the two sessions. In the new session, the client wants to start sending messages immediately, and so it would like to use client authentication in 0-RTT.

To be consistent with Draft-12, suppose we remove the outer binder MAC (using k b ) on the ClientHello in Figure 2.7 and we allow client authentication in 0-RTT. Then, if we model this protocol in ProVerif and ask the 0-RTT authentication query again, ProVerif finds a credential forwarding attack, explained next.

Suppose a client C shares psk with a malicious server M and M shares a different psk with an honest server S. If C sends an authenticated 0-RTT flight (certificate, signature, data m 0 ) to M , M can decrypt this flight using psk, reencrypt it using psk and forward the flight to S. S will accept the authenticated data m 0 from C as intended for itself, whereas C intended to send it only to M . In many HTTPS scenarios, as discussed in §2.3, M may be able to control the contents of this data, so this attack allows M to send arbitrary requests authenticated by C to S.

This attack was not discovered in previous analyses of TLS 1.3 since many of them did not consider client authentication; the prior Tamarin analysis [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF] found a similar attack on 1-RTT client authentication but did not consider 0-RTT client authentication. The attacks described here and in [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF] belong to a general class of compound authentication vulnerabilities that appear in protocols that compose multiple authentication credentials [START_REF] Bhargavan | Verified contributive channel bindings for compound authentication[END_REF]. In this case, the composition of interest is between PSK and certificate-based authentication. We found a similar attack on 1-RTT server authentication in pure PSK handshakes.

In response to our attack, Draft-13 included a resumption_context value derived from the psk in the handshake hash, to ensure that the client's signature over the hash cannot be forwarded on another connection (with a different psk ). This countermeasure has since evolved to the MAC-based design showed in Figure 2.7, which has now been verified in this work.

The Impact of Replay on 0-RTT and 0.5-RTT

It is now widely accepted that asynchronous messaging protocols like 0-RTT cannot be easily protected from replay, since the recipient has no chance to provide a random nonce that can ensure freshness. QUIC attempted to standardize a replay-prevention mechanism but it has since abandoned this mechanism, since it cannot prevent attackers from forcing the client to resend 0-RTT data over 1-RTT [START_REF] Rescorla | 0-RTT and Anti-Replay[END_REF].

Instead of preventing replays, TLS 1.3 Draft-18 advises applications that they should only send non-forward-secret and idempotent data over 0-RTT. This recommendation is hard to systematically enforce in flexible protocols like HTTPS, where all requests have secret cookies attached and even GET requests routinely change state.

We argue that replays offer an important attack vector for 0-RTT and 0.5-RTT data. If the client authenticates its 0-RTT flight, then an attacker can replay the entire flight to mount authenticated replay attacks. Suppose the (clientauthenticated) 0-RTT data asks the server to send a client's bank statement and the server sends this data in a 0.5-RTT response. An attacker who observes the 0-RTT request once, can replay it any number of times to the server from anywhere in the world and the server will send it the user's (encrypted) bank statement. Although the attacker cannot complete the 1-RTT handshake or read this 0.5-RTT response, it may be able to learn a lot from this exchange, such as the length of the bank statement and whether the client is logged in.

In response to these concerns, client authentication has now been removed from 0-RTT. However, we note that similar replay attacks apply to 0-RTT data that contains an authentication cookie or OAuth token. We highly recommend that TLS 1.3 servers should implement a replay cache (based on the client nonce n C and the ticket age) to detect and reject replayed 0-RTT data. This is less practical in server farms, where time-based replay mitigation may be the only alternative.

Computational Analysis of TLS 1.3 Draft-18

Our ProVerif analysis of TLS 1.3 Draft-18 identifies the necessary conditions under which the symbolic security guarantees of the protocol hold. We now use the tool CryptoVerif [START_REF] Blanchet | A computationally sound mechanized prover for security protocols[END_REF] to see whether these conditions are sufficient to obtain cryptographic security proofs for the protocol in a more precise computational model. In particular, under the assumption that the algorithms used in TLS 1.3 Draft-18 satisfy certain strong cryptographic assumptions, we prove that the protocol meets our security goals.

Proofs in the computational model are hard to mechanize and CryptoVerif offers less flexibility and automation than ProVerif. To obtain manageable proofs, we focus only on TLS 1.3 (we do not consider TLS 1.2) and we ignore downgrade attacks. Moreover, we proceed modularly: we first prove some lemmas on primitives and we split the protocol into three pieces and prove them separately using CryptoVerif, before composing them manually to obtain a proof for the full protocol.

Cryptographic Assumptions

We make the following assumptions about the cryptographic algorithms supported by TLS 1.3 clients and servers.

Diffie-Hellman. We assume that the Diffie-Hellman groups used in TLS 1.3 satisfy the gap Diffie-Hellman (GDH) assumption [START_REF] Okamoto | The gap-problems: a new class of problems for the security of cryptographic schemes[END_REF]. This assumption means that given g, g a and g b for random a, b, the adversary has a negligible probability to compute g ab , even when the adversary has access to a decisional Diffie-Hellman oracle, which tells him given G, X, Y, Z whether there exist x, y such that X = G x , Y = G y , and Z = G xy .

In our proof, we require GDH rather than the weaker decisional Diffie-Hellman (DDH) assumption, in order to prove secrecy of keys on the server side as soon as the server sends its Finished message: at this point, if the adversary controls a certificate accepted by the client, he can send its own key share y to the client to learn information on g x y and that would be forbidden under DDH. We also require that x y = x y implies x = x and that x y = x y implies y = y , which holds when the considered Diffie-Hellman group is of prime order. This is true for all groups currently specified in TLS 1. 3 [122, 97, 123, 124] and our proof requires it for all groups included in the future.

We also assume that all Diffie-Hellman group elements have a binary representation different from 0 len hash() . This assumption simplifies the proof by avoiding a possible confusion between handshakes with and without Diffie-Hellman exchange. Curve25519 does have a 32-byte zero element, but excluding zero Diffie-Hellman shared values is already recommended to avoid points of small order [START_REF] Langley | Elliptic curves for security[END_REF].

Finally, we assume that all Diffie-Hellman group elements have a binary representation different from len hash() "TLS 1.3, " l h 0x01. This helps ease our proofs by avoiding a collision between hkdf-extract(es, e) and derive-secret(es, pbk, "") or derive-secret(es, ets c , log 1 ). This assumption holds with the currently specified groups and labels, since group elements have a different length than the bitstring above. The technical problem identified by our assumption was independently discovered and discussed on the TLS mailing list [126] and has led to a change in Draft-19 which makes this assumption unnecessary: in the key schedule, hkdf-extract is applied to the result of derive-secret(es, ds, "") instead of applying it to es.

Signatures. We assume that the function sign is unforgeable under chosenmessage attacks (UF-CMA) [START_REF] Goldwasser | A digital signature scheme secure against adaptive chosen-message attacks[END_REF]. This means that an adversary with access to a signature oracle has a negligible probability of forging a signature for a message not signed by the signature oracle. Only the oracle has access to the signing key; the adversary has the public key.

Hash Functions. We assume that the function H is collision-resistant [START_REF] Bjerre | A design principle for hash functions[END_REF]: the adversary has a negligible probability of finding two different messages with the same hash.

HMAC. We need two assumptions on HMAC-H:

We require that the functions x → HMAC-H 0 len hash() (x) and x → HMAC-H kdf 0 (x) are independent random oracles, in order to justify the use of HMAC-H as a randomness extractor in the HKDF construct. This assumption can itself be justified as follows. Assuming that the compression function underlying the hash function is a random oracle, Theorem 4.4 in [START_REF] Dodis | To hash or not to hash again? (In)differentiability results for H2 and HMAC[END_REF] shows that HMAC is indifferentiable [START_REF] Coron | Merkle-Damgård revisited: How to construct a hash function[END_REF] from a random oracle, provided the MAC keys are less than the block size of the hash function minus one, which is true for HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. It is then easy to show that x → HMAC-H 0 len hash() (x) and x → HMAC-H kdf 0 (x) are indifferentiable from independent random oracles in this case.

We assume that HMAC-H is a pseudo-random function (PRF) [START_REF] Bellare | New proofs for NMAC and HMAC: Security without collision-resistance[END_REF], that is, HMAC-H is indistinguishable from a random function provided its key is random and used only in HMAC-H, when the key is different from 0 len hash() and kdf 0 . We avoid these two keys to avoid confusion with the two random oracles above. Since keys are chosen randomly with uniform probability from a set key (with cardinality |key|), the only consequence of avoiding these keys is that 2 |key| is added to the probability of breaking the PRF assumption.

Authenticated Encryption. The authenticated encryption scheme is IND-CPA (indistinguishable under chosen plaintext attacks) and INT-CTXT (ciphertext integrity) [START_REF] Bellare | Authenticated encryption: Relations among notions and analysis of the generic composition paradigm[END_REF], provided the same nonce is never used twice with the same key. IND-CPA means that the adversary has a negligible probability of distinguishing encryptions of two distinct messages of the same length that it has chosen. INT-CTXT means that an adversary with access to encryption and decryption oracles has a negligible probability of forging a ciphertext that decrypts successfully and has not been returned by the encryption oracle.

Lemmas on Primitives and on the Key Schedule

We show the following properties:

• mac k H (m) = mac k (hash(m)
) is an SUF-CMA (strongly unforgeable under chosen message attacks) MAC. Indeed, since mac = HMAC-H is a PRF, it is an SUF-CMA MAC as shown in [START_REF] Bellare | The security of the cipher block chaining message authentication code[END_REF] and this property is preserved by composition with a collision-resistant hash function.

• sign sk H (m) = sign sk (hash(m)) is an UF-CMA signature. Indeed, sign is an UF-CMA signature and this property is preserved by composition with a collision-resistant hash function.

We also prove several lemmas on the key schedule of TLS 1.3, using CryptoVerif.

• When es is a fresh random value, e → hkdf-extract(es, e) and log 1 → derive-secret(es, ets c , log 1 ) are indistinguishable from independent random functions and k b = derive-secret(es, pbk, "") and hkdf-extract(es, 0 len hash() ) are indistinguishable from independent fresh random values independent from these random functions.

• When hs is a fresh random value, log 1 → derive-secret(hs, hts c , log 1 ) derive-secret(hs, hts s , log 1 ) is indistinguishable from a random function and hkdf-extract(hs, 0 len hash() ) is indistinguishable from a fresh random value independent from this random function.

• When ms is a fresh random value, log 4 → derive-secret(ms, ats c , log 4 ) derive-secret(ms, ats s , log 4 ) derive-secret(ms, ems, log 4 ) and log 7 → derive-secret(ms, rms, log 7 ) are indistinguishable from independent random functions.

• When l 1 , l 2 , l 3 are pairwise distinct labels and s is a fresh random value, we have that the keys hkdf-expand-label(s, l i , "") for i = 1, 2, 3 are indistinguishable from independent fresh random values.

All random values considered above are uniformly distributed. We use these properties as assumptions in our proof of the protocol. This modular approach considerably reduces the complexity of the games that CryptoVerif has to consider.

These results suggest that the key schedule could be simplified by replacing groups of calls to derive-secret that use the same key and log with a single call to derive-secret that would output the concatenation of several keys. The same remark also holds for calls to hkdf-expand-label that use the same key. This approach corresponds to the usage of expansion recommended in the formalization of HKDF [START_REF] Krawczyk | Cryptographic extraction and key derivation: The HKDF scheme[END_REF] and would simplify the proof: some lemmas above would no longer be needed. We would also recommend replacing ms = hkdf-extract(hs, 0 len hash() ) with ms = derive-secret(hs, ms, ""): that would be more natural since we use the PRF property of HMAC-H for this computation and not the randomness extraction. If the argument 0 len hash() may change in the future, then we would support the recommendation of applying hkdf-extract to the result of derive-secret(hs, ms, ""), discussed on the TLS mailing list [126] and implemented in Draft-19.

Verifying 1-RTT Handshakes without Pre-Shared Keys

To prove the security of TLS 1.3 in CryptoVerif, we split the protocol into three parts, as shown in Figure 2.8 and verify them in sequence, before composing them by hand into a proof for the full protocol. This modular hybrid approach allows us to have proofs of manageable complexity and to obtain results even when keys are reused many times, such as when several PSK-based resumptions are performed, which would otherwise be out of scope of CryptoVerif.

We first consider the initial 1-RTT handshake shown in Figure 2.2, until the new client and server session boxes. We model a honest client and a honest server, which are willing to interact with each other, but also with dishonest clients and servers included in the adversary. We do not consider details of the negotiation (or the RetryRequest message). We give the handshake keys (k h c and k h s ) to the adversary, and let it encrypt and decrypt the handshake messages, so our security proof does not rely on the encryption of the handshake.

We assume that the server is always authenticated and consider both the handshake with and without client authentication. The honest client and server may be compromised at any time: the secret key of the compromised participant is then sent to the adversary and the compromise is recorded by defining a variable corruptedClient or corruptedServer.

The outputs of this protocol are the application traffic secrets ats c and ats s (the derivation of the keys k c and k s from these secrets is left for the record protocol), the exporter master secret ems and the resumption master secret psk (later used as pre-shared key). This protocol is modeled in CryptoVerif as shown in Figure 2.9. The context C h first chooses randomly a key hk that models the choice of the random oracle HKDF_extract_zero_salt, that is, x → HMAC-H 0 len hash() (x). Then, it provides the process Q h , which allows the adversary to query this random oracle by sending its query on channel c h3 [i h ] and receiving the result on channel c h4 [i h ]. This random oracle is actually not used in the initial handshake; adding it simplifies the composition with the handshake with pre-shared keys which uses it. The context C generates keys, defines the random oracle x → HMAC-H kdf 0 (x) in the same style as C h , deals with key compromise, and runs client and server processes. We omit the details of this context to focus on the way we specify security properties.

CHAPTER 2. TRANSPORT LAYER SECURITY

Q IH = C h [C[P ClientFinal , P Server0.5-RTT ]] C h = c h1 (); new hk : T hk ; c h2 ; ([ ] | Q h ) Q h = ! i h ≤n h c h3 [i h ](x : T h ); c h4 [i h ] HKDF_extract_zero_salt(hk,
At the end of the client code, the context C runs the process P ClientFinal . This process executes event ClientTerm1 with three arguments: the messages until the server Finished message (log 4 ), the messages after the server Finished message until the client Finished message (messages in log 7 but not in log 4 ) and the session keys. This event means that the client terminates. It is used for the unique channel identifier property. Next, the process distinguishes two cases, depending on whether the client is in a honest session or not. We say that the client is in a honest session when the certificate it received is the one of the honest server and either this server is not corrupted or the messages received by the client come from the honest server. Intuitively, the client is in a honest session when it talks to the honest server. In this case, the client executes event ClientTerm with arguments the messages until the server Finished message (log 4 ) and the session keys (psk excluded). It also executes event ClientAccept with arguments all messages (log 7 ), all session keys and the replication index of the client i C . These events are used for key authentication. It stores the keys ats c (that is, cats), ems, psk (that is, resumption_secret) in variables c_cats, c_ems, c_resumption_secret respectively. We shall prove the secrecy of these variables. Finally, it outputs the final message (client Certificate, CertVerify, Finished). When the client is not in a honest session, it just outputs the final message and the keys ats c , ats s , ems, psk , so that the adversary can continue the protocol. No security property is proved in this case.

On the server side, the context C runs the server until it is ready to send the server Finished message and 0.5-RTT data. Then it executes the process P Server0.5-RTT . This process distinguishes two cases, depending on whether the Diffie-Hellman key share g x received by the server comes from the honest client. If it does, it executes the event ServerAccept with arguments the messages until the server Finished message (log 4 ), the session keys (psk excluded) and the replication index of the server i S . It stores the key ats s (that is, sats) in s_sats. We shall prove secrecy of this key. Finally, it outputs the server CertVerify and Finished messages. When the Diffie-Hellman key share received by the server does not come from the honest client, the server outputs the CertVerify and Finished messages and the key ats s so that the adversary can send 0.5-RTT data by himself. We do not prove security of 0.5-RTT data in this case.

After that, the server continues with Q ServerAfter0.5-RTT1 or Q ServerAfter0.5-RTT2 . The process Q ServerAfter0.5-RTT1 executes event ServerTerm1 with three arguments: the messages until the server Finished message (log 4 ), the messages after the server Finished message until the client Finished message (mes-sages in log 7 but not in log 4 ) and the session keys. Next, the process distinguishes two cases, depending on whether the server is in a honest session or not. We say that the server is in a honest session when • if the client is authenticated, the certificate received by the server is the one of the honest client and either this client is not corrupted or the messages received by the server come from the honest client;

• if the client is not authenticated, the Diffie-Hellman key share g x received by the server comes from the honest client.

Intuitively, the server is in a honest session when it talks to the honest client.

In this case, the server executes event ServerTerm with arguments all messages (log 7 ) and all session keys and finally outputs an empty message to return control to the adversary. When the server is not in a honest session, it outputs the keys (psk , ats c , ats s , ems), so that the adversary can continue the protocol. No security property is proved in this case.

The process Q ServerAfter0.5-RTT2 is similar to Q ServerAfter0.5-RTT1 , but with renamed channels (so that all channels are distinct) and variables: s_resumption_secret1 , s_cats1 , s_ems1 Renamed into: s_resumption_secret2 , s_cats2 , s_ems2 . This renaming is necessary because, when we prove secrecy of a variable, CryptoVerif requires that it is defined at a single location of a game.

Let us define V in = {c_cats, c_sats, c_ems, c_resumption_secret, s_cats1 , s_cats2 , s_sats, s_ems1 , s_ems2 , s_resumption_secret1 , s_resumption_secret2 } the set of variables containing the keys ats c , ats s , ems, psk in honest sessions, on the client and server sides.

CryptoVerif proves the following properties:

• Key Authentication: If the client terminates and is in a honest session, then the server has accepted a session with the honest client and they share the same parameters: the keys ats c , ats s and ems and all messages sent in the protocol until the server Finished message. (We can make no claim on the client Finished message because it has not been received by the server at this point, nor on psk because it depends on the client Finished message.) Formally, CryptoVerif proves the correspondence inj-event(ClientTerm(log 4 , keys)) =⇒ inj-event(ServerAccept(log 4 , keys, i))

(2.1) with public variables V in , which means that, with overwhelming probability, each execution of event ClientTerm corresponds to a distinct execution of event ServerAccept with the same messages until server Finished and the same keys including ats c , ats s and ems. Event ClientTerm is executed when the client terminates and is in a honest session, event ServerAccept is executed when the server accepts a session with the client.

Conversely, if a server terminates and is in a honest session, then the client has accepted a session with the honest server and they agree on the established keys and on all messages sent in the protocol. Formally, CryptoVerif proves the correspondence inj-event(ServerTerm(log 7 , keys)) =⇒ inj-event(ClientAccept(log 7 , keys, i))

(2.2) with public variables V in , which means that, with overwhelming probability, each execution of event ServerTerm corresponds to a distinct execution of event ClientAccept with the same messages and keys.

• Replay Prevention: The authentication properties stated above are already injective (because of the presence of inj-event), that is, they guarantee that each session of the client (resp. server) corresponds to a distinct session of the server (resp. client), and consequently, they forbid replay attacks.

• (Forward) Secrecy of Keys: The keys ats c , ats s , ems, and psk exchanged in several protocol sessions are indistinguishable from independent fresh random values. This property means for instance that the keys ats s remains secret (indistinguishable from independent fresh random values) even if ats c , ems, psk are given to the adversary and similarly for the other keys.

We prove secrecy of ats s on the server side when the key share g x comes from the client as soon as the server sends its Finished message. This property allows us to prove security of 0.5-RTT messages by composition with the record protocol. Secrecy holds on the client side as well, when the client is in a honest session, because the client uses the same key as the server by key authentication. Formally, CryptoVerif proves that the protocol preserves the secrecy of s_sats with public variables V in \ {c_sats, s_sats}.

As noted in Section 2.2, the authentication for 0.5-RTT messages is weak: the client is not authenticated yet, so in the proof of secrecy of ats s , we require that the key share g x comes from the client. That weakens the authentication guarantees for all data received by an authenticated client.

We have also written an alternative model without 0.5-RTT messages, in which we prove secrecy of ats s on the client side when the client is in a honest session.

Similarly, we prove secrecy of ats c , ems and psk on the client side when the client is in a honest session. Secrecy holds on the server side as well, when the server is in a honest session, because the server uses the same key as the client by key authentication. Formally, CryptoVerif proves that the protocol preserves the secrecy of c_cats with public variables V in \ {c_cats, s_cats1 , s_cats2 }, of c_ems with public variables V in \ {c_ems, CHAPTER 2. TRANSPORT LAYER SECURITY s_ems1 , s_ems2 } and of c_resumption_secret with public variables V in \ {c_resumption_secret, s_resumption_secret1 , s_resumption_secret2 }.

• Unique Accept: The server never accepts twice with the honest client and the same messages until the server Finished message. Formally, CryptoVerif proves the correspondence event(ServerAccept(log 4 , s_keys, i))∧event(ServerAccept(log 4 , s_keys , i

)) =⇒ i = i (2.
3) with public variables V in : two ServerAccept events with the same messages must have the same replication index, so they are in fact a single event.

Similarly, the client never accepts twice with the honest server and the same messages until the client Finished message. Formally, CryptoVerif proves the correspondence event(ClientAccept(log 7 , c_keys, i))∧event(ClientAccept(log 7 , c_keys , i )) =⇒ i = i

(2.4) with public variables V in .

The correspondences (2.1) and (2.3) imply the correspondence event(ClientTerm(log 4 , c_keys))∧event(ServerAccept(log 4 , s_keys, i)) =⇒ c_keys = s_keys Indeed, if ClientTerm(log 4 , c_keys) and ServerAccept(log 4 , s_keys, i) are executed, then by (2.1), ServerAccept(log 4 , c_keys, i ) is executed, so by (2.3), i = i , so ServerAccept(log 4 , s_keys, i) and ServerAccept(log 4 , c_keys, i ) are in fact the same event, hence c_keys = s_keys. This correspondence means that, if the client terminates and is in a honest session and the server accepts a session with the honest client and with the same messages until the server Finished message, then the client and server have the same keys ats c , ats s and ems. We name this property "same keys".

Similarly, the correspondences (2.2) and (2.4) imply event(ServerTerm(log 7 , s_keys))∧event(ClientAccept(log 7 , c_keys, i)) =⇒ s_keys = c_keys If the server terminates and is in a honest session and the client accepts a session with the honest server and with the same messages until the client Finished message, then the client and server have the same keys ats c , ats s , ems and psk .

The three properties key authentication with replay prevention, secrecy of keys, and same keys are standard security properties for a key exchange protocol [START_REF] Blanchet | Computationally sound mechanized proofs of correspondence assertions[END_REF]. CryptoVerif could also prove "same keys" directly, but we need (2.3) and (2.4) for composition.

• Unique Channel Identifier: When cid is psk or hash(log 7 ), we do not use CryptoVerif as the result is immediate: if a client session and a server session have the same cid, then these sessions have the same log 7 by collision-resistance of H (which implies collision-resistance of HMAC-H), so all their parameters are equal.

When cid is ems, collision-resistance just yields that the client and server sessions have the same log 4 . CryptoVerif proves that, if a client session and a server session both terminate successfully with the same log 4 , then they have the same log 7 and the same keys, so all their parameters are equal. Formally, CryptoVerif proves the correspondence event(ClientTerm1(sfl, c_cfl, c_keys)) ∧ event(ServerTerm1(sfl, s_cfl, s_keys))

=⇒ c_cfl = s_cfl ∧ c_keys = s_keys (2.5)
We need to guide CryptoVerif in order to prove these properties, with the following main steps. We first apply the security of the signature under the server key sk S . We introduce tests to distinguish cases, depending on whether the Diffie-Hellman share received by the server is a share g x from the client and whether the Diffie-Hellman share received by the client is the share g y generated by the server upon receipt of g x . Then we apply the random oracle assumption on x → HMAC-H kdf 0 (x), replace variables that contain g x y with their values to make equality tests m = g x y appear and apply the gap Diffie-Hellman assumption. At this point, the handshake secret hs is a fresh random value. We use the properties on the key schedule established in Section 2.5.2 to show that the other keys are fresh random values and apply the security of the MAC and of the signature under the client key sk C .

Verifying Handshakes with Pre-Shared Keys

We now analyze the handshake protocol in Figure 2.7, up until the new client and server sessions are established. The protocol begins with 0-RTT and continues on to 1-RTT. We consider both variants of PSK-based 1-RTT, with and without Diffie-Hellman exchange. We ignore the ticket enc kt (psk) and consider a honest client and a honest server that initially share the pre-shared key psk. Dishonest clients and servers may be included in the adversary. As in the previous section, we give the handshake keys (k h c and k h s ) to the adversary and ignore handshake encryption. Certificates for the client and server are optional, since they are already authenticated via the psk; we do not rely on authentication in our proofs and consider that the adversary performs the signature and verification operations on certificates if they occur.

The outputs of this protocol are the client early traffic secret ets c (the derivation of the key k c from ets c is left for the record protocol), the application traffic secrets ats c and ats s , the exporter master secret ems and the resumption master secret psk .

This protocol is modeled in CryptoVerif as shown in Figure B.1, after moving some random number generations and assignments. The process first defines the random oracle x → HMAC-H 0 len hash() (x) using the context C h as in Figure 2.9. Then it chooses a fresh pre-shared key psk. (The input and output just allow the adversary to schedule this choice.) Finally, it launches processes for the client and the server, for the handshakes with and without Diffie-Hellman exchange.

The process Q PSKOnlyClient represents the client for a handshake with preshared key and without Diffie-Hellman exchange. The context C PSKOnlyClient builds the ClientHello message and computes the early traffic secret ets c . Then the process inserts the ClientHello message (nonce c_cr, binder c_binder and other elements varc_log1, c_log1 ) in the table c_table. Tables are lists of tuples shared between all honest participants of the protocol. They can be read by the get construct: get T bl(x 1 , . . . , x l ) suchthat M in P else P tries to retrieve an element (x 1 , . . . , x l ) in the table T bl such that M is true. When such an element is found, it executes P with x 1 , . . . , x l bound to that element. When no such element is found, P is executed. Equality tests = M i are also allowed instead of variables x i ; in this case, the table element must contain the value of M i at the i-th position. Then, the process executes the event ClientEarlyAccept1 with arguments the ClientHello message, ets c (that is, cets) and the replication index of the client i C and stores cets in c_cets. These operations are useful to establish security of 0-RTT data. Then it outputs the ClientHello message and continues the protocol until the client Finished message. It executes the event ClientTerm1 with three arguments: the messages until the server Finished message, the messages after the server Finished message until the client Finished message and the session keys. This event means that the client terminates. It is used for the unique channel identifier property. Next, the process stores ats s into c_sats. It executes event ClientTerm with arguments the messages until the server Finished message and the session keys (psk excluded). It also executes event ClientAccept with arguments all messages (log 7 ), all session keys, and the replication index of the client i C . These events are used for key authentication. It stores the keys ats c (that is, cats), ems, psk (that is, resumption_secret) in variables c_cats, c_ems, c_resumption_secret respectively. We shall prove the secrecy of these variables. Finally, it outputs the final message (client Certificate, CertVerify, Finished).

The process Q PSKOnlyServer represents the server for a handshake with preshared key and without Diffie-Hellman exchange. The context C PSKOnlyServer receives the ClientHello message and runs two holes in parallel. The first hole deals with the reception of 0-RTT data. It distinguishes several cases. When the received ClientHello comes unaltered from the honest client (it is in the table c_table), it stores the early traffic secret in s_cets2 , executes event ServerEarlyTerm1 with arguments the ClientHello message and s_cets2 and returns control to the adversary. In this case, we are going to show that 0-RTT data is secure: it is authenticated and confidential, but may be replayed. Otherwise, it stores the early traffic secret in s_cets3 , executes event ServerEarlyTerm2 with arguments the ClientHello message and s_cets2 and further distinguishes two cases: either the received ClientHello message has already been received before, and we are going to reuse the previous early traffic secret, or it is a new ClientHello message and we store the early traffic secret in s_cets1 . We shall prove that this variable is secret and that, when the server receives an altered ClientHello message, it cannot receive 0-RTT data. The second hole deals with the rest of the protocol. It first executes event ServerAccept with arguments the messages until the server Finished message, the session keys (psk excluded) and the replication index of the server i S . It stores the key ats s in s_sats. We shall prove secrecy of this key, used for 0.5-RTT data. Finally, it outputs the server CertVerify and Finished messages. Then the server receives the client Finished message, executes event ServerTerm1 with three arguments: the messages until the server Finished message, the messages after the server Finished message until the client Finished message and the session keys. It stores the keys ats c , ems, psk (that is, resumption_secret) in variables s_cats, s_ems, s_resumption_secret respectively. It executes event ServerTerm with arguments all messages and all session keys and finally outputs an empty message.

The processes for the handshake with Diffie-Hellman exchange are similar. Obviously, they additionally perform the Diffie-Hellman exchange. The events ClientEarlyAccept1, ClientTerm, ClientAccept, ServerEarlyTerm1, ServerEarlyTerm2, ServerAccept, and ServerTerm have an additional suffix DHE. The variables and tables have prefix cdhe_ instead of c_ and sdhe_ instead of s_.

The set of variables V psk contains all variables with prefixes c_, s_, cdhe_ and sdhe_.

We run CryptoVerif on our model to obtain the following verification results:

• Key Authentication, Replay Prevention, Secrecy of Keys, Unique Accept: CryptoVerif shows the same properties as for the handshake without pre-shared key, with similar queries. The differences are as follows: the key psk is never compromised, so the client and server are always in a honest session; the queries are duplicated for the handshake with and without Diffie-Hellman exchange; the variables are not duplicated for the distinction whether the Diffie-Hellman key share received by the server comes from the client or not in 0.5-RTT, but are duplicated for the handshake with and without Diffie-Hellman exchange.

• 0-RTT data: CryptoVerif cannot prove authentication of ets c . While the binder mac k b (•) authenticates most of the client ClientHello message, the client may offer several pre-shared keys and send a binder for each of these keys. Only the binder for the pre-shared key selected by the server is checked. Hence the adversary may alter another of the proposed binders, yielding a different log 1 and a different ets c on the server side. This is not a serious attack, as the record protocol will fail if ets c does not match on the client and server sides.

CryptoVerif cannot prove replay protection for the 0-RTT session key ets c , and indeed the client ClientHello message can be replayed, yielding the

CHAPTER 2. TRANSPORT LAYER SECURITY

same key ets c for several sessions of the server even though there is a single session of the client.

Secrecy of ets c holds on the client side; on the server side, each key ets c is indistinguishable from random, but the keys ets c are not independent of each other since an adversary may force the server to accept several times the same key ets c by replaying the client ClientHello message.

CryptoVerif shows that, if the server receives the ClientHello message unaltered, then the client sent it (obviously!) and the client and server share the same early traffic secret ets c . Formally, event(ServerEarlyTerm1(log1 , cets)) =⇒ event(ClientEarlyAccept1(log1 , cets, i))

(2.6) with public variables V psk . It shows that the client never sends twice the same ClientHello message. Formally, event(ClientEarlyAccept1(log1 , cets, i))∧event(ClientEarlyAccept1(log1 , cets , i )) =⇒ i = i

(2.7) with public variables V psk . It shows that ets c is secret on the client side. Formally, it shows the secrecy of c_cets with public variables V psk \ {c_cets, s_cets2 }. These three properties provide security for a key exchange with one-way non-injective authentication. (The correspondences (2.6) and (2.7) imply a "same key" property: event(ClientEarlyAccept1(log1 , cets, i))∧event(ServerEarlyTerm1(log1 , cets )) =⇒ cets = cets as in the initial handshake.)

CryptoVerif also shows that, if the server receives twice the same altered ClientHello message, then it computes the same early traffic secret ets c . Formally, event(ServerEarlyTerm2(log1 , cets))∧event(ServerEarlyTerm2(log1 , cets )) =⇒ cets = cets (2.8) with public variables V psk . Finally, it shows the secrecy of s_cets1 with public variables V psk \ {s_cets1 , s_cets3 }. These two properties deal with the case in which the ClientHello message is altered. They show that in this case, ets c is fresh secret random value when that ClientHello is received for the first time and that it is the same as the previous ets c when ClientHello is replayed. By composition with the record protocol, they imply that the server fails to receive 0-RTT data in this case.

CryptoVerif shows the same properties for the handshake with Diffie-Hellman exchange.

• Forward Secrecy: CryptoVerif is unable to prove secrecy of the keys when psk is compromised after the end of the session, even assuming that hkdf-extract is a random oracle. Secrecy obviously does not hold in this case for the handshake without Diffie-Hellman exchange. We believe that it still holds for the handshake with Diffie-Hellman exchange; our failure to prove it in this case is due to the current limitations of CryptoVerif.

• Unique Channel Identifier: We proceed as in the handshake without pre-shared key. We additionally notice that, if a client session and a server session have the same log 7 , then they have the same psk. Indeed, by collision-resistance of mac = HMAC-H, they have the same k b , so the same es, so the same psk.

Verifying the Record Protocol

The third component of TLS 1.3 is the record protocol that encrypts and decrypts messages after the new client and server sessions have been established in Figures 2.2 and 2.7.

In our model, we assume that the client and server share a fresh random traffic secret. We generate an encryption key and an initialization vector (IV), and send and receive encrypted messages using those key and IV and a counter that is distinct for each message. (Our model is more detailed than the symbolic presentation given in the figures as we consider the IV and the counter.) We also generate a new traffic secret as specified in the key update mechanism of TLS 1.3 Draft-18 (Section 7.2).

More formally, after moving some assignments, our model of the record protocol in CryptoVerif is of the following form Rec = c 1 (); new b : bool; new ts : key; let ts upd : key = HKDF_expand_upd_label(ts) in c 2 ;

(

Q send (b) | Q recv )
It chooses a random bit b (false = 0 or true = 1) and a random traffic secret ts. It computes the updated traffic secret ts upd and then provides two processes Q send (b) and Q recv . The process Q send (b) receives two clear messages msg 0 and msg 1 and a counter count. Provided the counter has not been used for sending a previous message and the messages msg 0 and msg 1 have the same padded length, it executes the event sent 0 (count, msg b ) and sends the message msg b encrypted using keys derived from the traffic secret ts. The process Q recv receives an encrypted message and a counter count. Provided the counter has not been used for receiving a previous message, it decrypts the message using keys derived from the traffic secret ts and executes event received 0 (count, msg) where msg is the clear message. Both the emission and reception can be executed several times. CryptoVerif proves the following properties automatically:

• Key Secrecy: CryptoVerif proves that the updated traffic secret is indistinguishable from a fresh random value. Formally, CryptoVerif proves that ts upd is secret with public variable b.

• Message Secrecy: CryptoVerif proves that, when the adversary provides two sets of plaintexts m i and m i of the same padded length, it is unable to determine which of the two sets is encrypted, even when the updated traffic secret is leaked. Formally, CryptoVerif proves that b is secret with public variable ts upd .

• Message Authentication: CryptoVerif proves that, if a message msg is decrypted by the receiver with a counter count, then the message msg has been encrypted and sent by an honest sender with the same counter count. Formally, CryptoVerif proves the correspondence event(received 0 (count, msg)) =⇒ event(sent 0 (count, msg))

with public variables b, ts upd .

• Replay Prevention: CryptoVerif shows that any sent application data may be accepted at most once by the receiver. Formally, CryptoVerif proves the correspondence inj-event(received 0 (count, msg)) =⇒ inj-event(sent 0 (count, msg))

with public variables b, ts upd , which means that each execution of event received 0 (count, msg) corresponds to a distinct execution of sent 0 (count, msg). This correspondence implies message authentication.

We consider two other variants of the record protocol, used for 0-RTT. In the first variant, Rec 0-RTT , the receiver process is replicated once more, so that several sessions may have the same traffic secret, thus the receiver accepts messages with the same counter in different sessions with the same traffic secret. It models that the server may receive several times the same ClientHello message, yielding the same traffic secret. In this model, CryptoVerif proves key and message secrecy and message authentication but not replay prevention. In the second variant, Rec 0-RTT,Bad , the sender process is additionally removed. This model corresponds to the situation in which the ClientHello message is altered and thus the server obtains a traffic secret that is not used by any client. In this model, CryptoVerif proves key secrecy and that the received 0 event has a negligible probability of being executed: event(received 0 (count, msg)) =⇒ false with public variable ts upd .

A Composite Proof for TLS 1.3 Draft-18

We compose these results using a hybrid argument (as in [START_REF] Dowling | A cryptographic analysis of the TLS 1.3 handshake protocol candidates[END_REF]). Figure 2.8 summarizes the structure of the composition. We provide only a brief sketch of the composition. A more detailed proof [START_REF] Blanchet | Composition theorems for CryptoVerif and application to TLS 1.3[END_REF] has since been published independently of this thesis. First, we compose the record protocol Rec with itself recursively, using the secrecy of the updated traffic secret, to show that the security properties of the record protocol are preserved by key updates. We also perform similar compositions for the two variants Rec 0-RTT and Rec 0-RTT,Bad of the record protocol for 0-RTT. We obtain processes Rec m , Rec 0-RTT m and Rec 0-RTT,Bad m that perform at most m key updates, for any m.

Second, we compose the handshakes with pre-shared key with the record protocol:

• using the secret key c_cats as traffic secret in the process Rec m for 1-RTT client-to-server messages: the sender side is plugged after event ClientAccept at line 3: and the receiver side is plugged after event ServerTerm at line 7: in Figure B.1;

• using the secret key s_sats as traffic secret in the process Rec m for 0.5-RTT and 1-RTT server-to-client messages: the sender side is plugged after event ServerAccept at line 6: and the receiver side is plugged after event ClientTerm at line 2: in Figure B.1;

• using the secret key c_cets as traffic secret in the process Rec 0-RTT m for 0-RTT messages when the ClientHello message has not been altered: the sender side is plugged after event ClientEarlyAccept1 at line 1: and the receiver side is plugged after event ServerEarlyTerm1 at line 4: in (There is no sender process in this case.)

We perform similar compositions in the handshake with pre-shared key and Diffie-Hellman key agreement. We also compose the obtained process with itself recursively, using the resumption secret c_resumption_secret as pre-shared key in the next handshake: the client side is plugged after event ClientAccept at line 3: and the server side is plugged after event ServerTerm at line 7: in Figure B.1. We perform a similar composition with secret cdhe_resumption_secret.

For these compositions, we rely the properties of key secrecy, key authentication with replay prevention and unique accept. We use the key secrecy property to replace session keys with independent fresh random values. We rely on authentication with replay prevention and unique accept to show that the same replacement is performed in matching sessions of the client and server. For 0-RTT, the authentication is weaker (we do not have replay prevention), so we need to adapt our composition theorems to this case. The composed protocol inherits security properties from the components we compose. In particular, we obtain secrecy, authentication and replay prevention for 0.5-RTT and 1-RTT application messages in both directions. For 0-RTT messages, since the handshake does not prevent replays for this key, the composition will not prevent replays for messages sent under this key. These compositions yield processes Q l,m PSKH that perform at most l successive handshakes with pre-shared key and m key updates.

CHAPTER 2. TRANSPORT LAYER SECURITY

Third, we compose the initial handshake with the record protocol • using the secret key c_cats as traffic secret in the process Rec m for 1-RTT client-to-server messages: the sender side is plugged after event ClientAccept at line 2: and the receiver side is plugged after event ServerTerm at line 6: in Figure 2.9 and in the process Q ServerAfter0.5-RTT2 ;

• using the secret key s_sats as traffic secret in the process Rec m for 0.5-RTT and 1-RTT server-to-client messages: the sender side is plugged after event ServerAccept at line 4: and the receiver side is plugged after event ClientTerm at line 1: in Figure 2.9.

We also compose the initial handshake with the process Q l,m PSKH,s that runs handshakes with pre-shared key, using the secret key c_resumption_secret as preshared key: the client side is plugged after event ClientAccept at line 2: and the server side is plugged after event ServerTerm at line 6: in Figure 2.9 and in the process Q ServerAfter0.5-RTT2 . (The forward secrecy property of the initial handshake allows us to leak the keys sk S and sk C , so that the adversary can indeed perform the signature operations related to certificates, as we assumed in our model of handshakes with pre-shared keys.)

Finally, we compose the obtained process with a process that runs the rest of the TLS protocol without any event or security claim, at lines 3:, 5:, 7: of Figure 2.9 and at a line similar to 7: in the process Q ServerAfter0.5-RTT2 .

These compositions allow us to infer security properties of the TLS protocol from properties of the handshakes and the record protocol. In particular, we obtain secrecy, forward secrecy (with respect to the compromise of sk S and sk C ), authentication and replay prevention for 0.5-RTT and 1-RTT application messages in both directions. For 0-RTT messages, we do not obtain replay prevention, but still obtain secrecy, forward secrecy (with respect to the compromise of sk S and sk C ) and authentication.

Conclusion

Symbolic Analysis of TLS 1.3. We symbolically analyzed a composite model of TLS 1.3 Draft-18 with optional client authentication, PSK-based resumption, and PSK-based 0-RTT, running alongside TLS 1.2 against a rich threat model and we established a series of security goals. In summary, 1-RTT provides forward secrecy, authentication and unique channel identifiers, 0.5-RTT offers weaker authentication and 0-RTT lacks forward secrecy and replay protection.

We discovered potential vulnerabilities in 0-RTT client authentication in earlier draft versions. These attacks were presented at the TLS Ready-Or-Not (TRON) workshop and contributed to the removal of certificate-based 0-RTT client authentication from TLS 1.3. The current design of PSK binders in Draft-18 is also partly inspired by these kinds of authentication attacks. TLS 1.3 has been symbolically analyzed before, using the Tamarin prover [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF]. ProVerif and Tamarin are both state-of-the-art protocol analyzers with different strengths. Tamarin can verify arbitrary compositions of protocols by relying on user-provided lemmas, whereas ProVerif is less expressive but offers more automation. In terms of protocol features, the Tamarin analysis covered PSK and ECDHE handshakes for 0-RTT and 1-RTT in Draft-10, but did not consider 0-RTT client certificate authentication or 0.5-RTT data. On the other hand, they do consider delayed (post-handshake) authentication, which we did not consider here.

The main qualitative improvement in our verification results over theirs is that we consider a richer threat model that allows for downgrade attacks and that we analyze TLS 1.3 in composition with previous versions of the protocol, whereas they verify TLS 1.3 in isolation.

Our full ProVerif development consists of 1030 lines of ProVerif; including a generic library incorporating our threat model (400 lines), processes for TLS 1.2 (200 lines) and TLS 1.3 (250 lines) and security queries for TLS 1.2 (50 lines) and TLS 1.3 (180 lines). All proofs complete in about 70 minutes on a powerful workstation. In terms of manual effort, these models took about 3 person-weeks for a ProVerif expert.

Computational Proofs for TLS 1.3. We presented the first mechanicallychecked cryptographic proof for TLS 1.3, developed using the CryptoVerif prover. We prove secrecy, forward secrecy with respect to the compromise of long-term keys, authentication, replay prevention (except for 0-RTT data) and existence of a unique channel identifier for TLS 1.3 draft-18. Our analysis considers PSK modes with and without DHE key exchange, with and without client authentication. It includes 0-RTT and 0.5-RTT data, as well as key updates, but not post-handshake authentication.

Unlike the ProVerif analysis, our CryptoVerif model does not consider compositions of client certificates and pre-shared keys in the same handshake. It also does not account for version or ciphersuite negotiation; instead, we assume that the client and server only support TLS 1.3 with strong cryptographic algorithms. The reason we limit the model in this way is to make the proofs more tractable, since CryptoVerif is not fully automated and requires significant input from the user. With future improvements in the tool, we may be able to remove some of these restrictions.

CryptoVerif is better suited to proofs than finding attacks. In case of attack, the proof fails, but proof failure may also come from other reasons: limitations of the tool, assumptions too weak, inappropriate guidance from the user. Therefore, we only consider in CryptoVerif properties for which ProVerif did not find attacks. Sometimes, proof failures in CryptoVerif might lead us towards computational attacks that do not appear at the symbolic level, for instance attacks that allow an adversary to distinguish between two different data messages but do not allow it to compute these messages, or attacks that rely on the algorithms of cryptographic primitives. However, we did not find such attacks in our model of TLS 1.3. We failed to prove forward secrecy for handshakes that use both pre-shared keys and Diffie-Hellman, but this failure is due to limitations in our tool, not due to an attack. Our proofs required some unusual assumptions on public values in Diffie-Hellman groups to avoid confusions between different key exchange modes; these ambiguities are inherent in Draft-18 but have been fixed in Draft-19, making some of our assumptions unnecessary.

Verifying TLS Implementations. Specifications for protocols like TLS are primarily focused on interoperability; the RFC standard precisely defines message formats, cryptographic computations and expected message sequences. However, it says little about what state machine these protocol implementations should use, or what APIs they should offer to their applications. This specification ambiguity is arguably the culprit for many implementation bugs and protocol flaws [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF] in TLS.

In the absence of a more explicit specification, we advocate the need for verified reference implementations of TLS that can provide exemplary code and design patterns on how to deploy the protocol securely. We proposed one such implementation, RefTLS, for use in JavaScript applications. The core protocol code in RefTLS implements both TLS 1.2 and 1.3 and has been verified using ProVerif. However, RefTLS is a work-in-progress and many of its trusted components remain to verified. For example, we did not verify our message parsing code or cryptographic libraries and our verification results rely on the correctness of the unverified ProScript-to-ProVerif compiler [START_REF] Bhargavan | Automated verification for secure messaging protocols and their implementations: A symbolic and computational approach[END_REF].

Other Verification Approaches. In addition to ProVerif and CryptoVerif, there are many symbolic and computational analysis tools that have been used to verify cryptographic protocols like TLS. As discussed above, Tamarin [START_REF] Schmidt | Automated analysis of Diffie-Hellman protocols and advanced security properties[END_REF] was used to symbolically analyze TLS 1.3 Draft-10 [START_REF] Cremers | Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[END_REF]. EasyCrypt [START_REF] Barthe | EasyCrypt: A tutorial[END_REF] has been used to develop cryptographic proofs for various components used in TLS, including the MAC-Encode-Encrypt construction used in the record layer [START_REF] Almeida | Verifiable Side-Channel Security of Cryptographic Implementations: Constant-Time MEE-CBC[END_REF].

Chapter 3

Formal Verification of Arbitrary Noise Protocols

This work was completed very shortly before the final draft of this thesis was submitted and is currently under peer review. It was completed with the assistance of Karthikeyan Bhargavan and would not have been possible without the assistance of Bruno Blanchet. I am also grateful towards Trevor Perrin, the author of the Noise Protocol, for his feedback, engagement and encouragement.

Popular Internet protocols such as SSH and TLS use similar cryptographic primitives: symmetric primitives, public key primitives, one-way hash functions and so forth. Protocol stages are also similarly organized, usually beginning with an authenticated key exchange (AKE) stage followed by a messaging stage. And yet, the design methodology, underlying state machine transitions and key derivation logic tend to be entirely different between protocols with nevertheless similar building blocks. The targeted effective security goals tend to be similar, so why can't the same methodology be followed for everything else?

Standard protocols such as those mentioned above choose a specific set of key exchange protocols to satisfy some stated use-cases while leaving other elements, such as round trips and (notoriously) cipher suites up to the deployer. Specifications use protocol-specific verbose notation to describe the underlying protocol, to the extent that even extracting the core cryptographic protocol becomes hard, let alone analyzing and comparing different modes for security.

Using completely different methodologies to build protocols that nevertheless often share the same primitives and security goals is not only unnecessary, but provably dangerous. The Triple Handshake attack on TLS published in 2014 [START_REF] Bhargavan | Triple handshakes and cookie cutters: Breaking and fixing authentication over TLS[END_REF] is based on the same logic that made the attack [START_REF] Lowe | An attack on the needham-schroeder public-key authentication protocol[END_REF] on the Needham-Schroeder protocol [START_REF] Roger | Using encryption for authentication in large networks of computers[END_REF] possible almost two decades earlier.

The core protocol in TLS 1.2 was also vulnerable to a similar attack, but since the protocol itself is hidden within layers of packet formats and C-like pseudocode, it was difficult for the attack to be detected. However, upon automated symbolic verification [START_REF] Bhargavan | Verified contributive channel bindings for compound authentication[END_REF][START_REF] Cremers | A comprehensive symbolic analysis of TLS 1.3[END_REF], the attack quickly appeared not just in 102 CHAPTER 3. NOISE PROTOCOL FRAMEWORK TLS, but also in variants of SSH and IPsec. Flaws underlying more recent attacks such as Logjam [START_REF] Adrian | Imperfect forward secrecy: How Diffie-Hellman fails in practice[END_REF] were known for years before they were observed when the vulnerable protocol was analyzed. Had these protocols differed only in terms of network messages while still using a uniform, formalized logic for internal key derivation and state machine transitioning designed based on the state of the art of protocol analysis, these attacks could have been avoided. The Noise Protocol Framework [START_REF] Perrin | The Noise protocol framework[END_REF], recently introduced by Trevor Perrin, aims to avert this problem by presenting a simple language for describing cryptographic network protocols. In turn, a large number of semantic rules extend this simple protocol description to provide state machine transitions, key derivation logic and so on. The goal is to obtain the strongest possible effective security guarantees for a given protocol based on its description as a series of network messages by deriving its other elements from a uniform, formally specified logic followed by all protocol designs.

The Noise Protocol Framework

In designing a new secure channel protocol using the Noise Protocol Framework, one only provides an input using the simple language shown in Fig. 3.1. As such, from the viewpoint of the protocol designer, Noise protocols can only differ in the number of messages, the types of keys exchanged and the sequence or occurrence of public key transmissions and Diffie-Hellman operations. Despite the markedly non-expressive syntax, however, the occurence and position of the "tokens" in each message pattern can trigger complex state machine evolutions for both parties, which include operations such as key derivation and transcript hash mixing.

Let's examine Fig. 3.1. Before the AKE begins, the responder shares his static public key. Then in the first protocol message, the initiator sends a fresh ephemeral key, calculates a Diffie-Hellman shared secret between her ephemeral key and the recipient's public static key, sends her public static key and finally calculates a Diffie-Hellman shared secret between her static key and the responder's public static key. The responder then answers by generating an ephemeral key pair and sending his ephemeral public key, deriving a Diffie-Hellman shared secret between his ephemeral key and the ephemeral key of the initiator and another Diffie-Hellman shared secret between his static key and the ephemeral key of the initiator. Both of these AKE messages can also contain message payloads, which, depending on the availability of sufficient key material, could be AEAD-encrypted (in this particular Noise Handshake Pattern, this is indeed the case).

As we can see, quite a few operations have occured in what would at first glance appear to be simple syntax for a simple protocol. Indeed, underlying these operations is a sophisticated state machine logic tasked with mixing all of the derived keys together, determining when it is safe (or possible) to send encrypted payloads and ensuring transcript consistency, among other things. This is the value of the Noise Protocol Framework: allowing the protocol designer to describe what they need their protocol to do fairly effectively using this simple syntax, and leaving the rest to a sturdy set of underlying rules. Noise Explorer, the central contribution of this work, capitalizes on the strengths of the Noise Protocol Framework in order to allow for automated protocol verification to no longer be limited only to monolithic, pre-defined protocols with their own notation. In this work, we formalize Noise's syntax, semantics, state transitions and Noise Handshake Pattern validity rules. We then present translation logic to go from Noise Handshake Patterns directly into full symbolic models ready for automated verification using the ProVerif [START_REF] Cheval | Proving more observational equivalences with ProVerif[END_REF][START_REF] Blanchet | Modeling and verifying security protocols with the applied pi calculus and ProVerif[END_REF] automatic protocol verifier.

Formal Verification for any Noise Handshake Pattern

This allows us to then construct Noise Explorer, an online engine that allows for designing, validating and subsequently generating cryptographic models for the automated formal verification of any arbitrary Noise Handshake Pattern. Models generated using Noise Explorer allow for the verification of Noise-based secure channel protocols against a battery of comprehensive ProVerif queries. Noise Explorer also comes with the first compendium of formal verification results for Noise Handshake Patterns, browsable online using an interactive web application that presents dynamically generated diagrams indicating every cryptographic operation and security guarantee relevant to every message within the Noise Handshake Pattern.

Contributions

Formal semantics and validity rules for Noise Handshake Patterns. §3.1 introduces formal verification in the symbolic model using ProVerif, setting the stage for §3.2.

Translations from Noise Patterns to processes in the applied pi-calculus.

§3.2 discusses automated translations from valid Noise Handshake Patterns into a representation in the applied pi-calculus [START_REF] Abadi | The applied pi calculus: Mobile values, new names, and secure communication[END_REF] which includes cryptographic primitives, state machine transitions, message passing and a top-level process illustrating live protocol execution. We present the first formal semantics and validity rules (illustrated as typing inference rules) for Noise Handshake Patterns. This allows Noise Explorer to validate and separate sane Noise Handshake Patterns from invalid ones based on arbitrary input, and is the foundation of further CHAPTER 3. NOISE PROTOCOL FRAMEWORK contributions described below.

Noise Handshake Pattern security goals expressed as ProVerif queries.

In §3.3, we model all five "confidentiality" security goals from the Noise Protocol Framework specification in the applied pi-calculus and extend the two "authentication" goals to four.

Formal verification results for 50 Noise Handshake Patterns in the

Noise Protocol Framework specification. §3.4 sees all of the previous contributions come together to provide formal verification results for 50 Noise Handshake Patterns. 1 We find that while most of the results match those predicted by the specification authors, our extended model for "authentication" queries allows for more nuanced results. Furthermore, in §3.5, we analyze unsafe Noise Handshake Patterns and discover a potential for forgery attacks should Noise Handshake Patterns not be followed properly.

Formal Verification in the Symbolic Model

The main goal of this work is to use the ProVerif automated protocol verifier to obtain answers to our formal verification queries. In this section, we describe the parts of ProVerif that are relevant to our analysis.

ProVerif uses the applied pi-calculus, a language geared towards the description of network protocols, as its input language. It analyzes described protocols under a Dolev-Yao model, which effectively mimics an active network attacker. ProVerif models are comprised of a section in which cryptographic protocol primitives and operations are described as funs or letfuns and a "top-level process" section in which the execution of the protocol on the network is outlined.

In ProVerif, messages are modeled as abstract terms. Processes can generate new nonces and keys, which are treated as atomic opaque terms that are fresh and unguessable. Functions map terms to terms. For example, encryption constructs a complex term from its arguments (key and plaintext) that can only be deconstructed by decryption (with the same key). The attacker is an arbitrary ProVerif process running in parallel with the protocol, which can read and write messages on public channels and can manipulate them symbolically. Parallel and unbounded numbers of executions of different parts of the protocol are supported.

In the symbolic model, cryptographic primitives are represented as "perfect black-boxes"; a hash function, for example, cannot be modeled to be vulnerable to a length extension attack (which the hash function SHA-1 is vulnerable to, for example.) Encryption primitives are perfect pseudorandom permutations. Hash functions are perfect one-way maps. It remains possible to build complex primitives such as authenticated encryption with associated data (AEAD) and also to model interesting use cases, such as a Diffie-Hellman exponentiation that obtains a shared secret that is outside of the algebraic group. However, in the

FORMAL VERIFICATION IN THE SYMBOLIC MODEL

105

latter case, such constructions cannot be based on on an algebra that includes the space of integers commonly considered when modeling these scenarios, since all messages are simply a combination of the core terms used to express primitives.

Verification Context

All generated models execute the protocol in comprehensive formal verification context: a typical run includes a process in which Alice initiates a session with Bob, a process in which Alice initiates a session with Charlie, a process in which Bob acts a responder to Alice and a process in which Bob acts as a responder to Charlie. Charlie is a compromised participant whose entire state is controlled by the attacker. Each process in the top-level process are executed in parallel. The top-level process is executed in an unbounded number of sessions. Within the processes, transport messages are again executed in an unbounded number of sessions in both directions. Fresh key material is provided for each ephemeral generated in each session within the unbounded number of sessions: no ephemeral key reuse occurs between the sessions modeled.

Cryptographic Primitives

Noise Handshake Patterns make use of cryptographic primitives which in this work we will treat as constructions in the symbolic model. We consider the following cryptographic primitives:

• KP(): Generates a new Diffie-Hellman key pair consisting of a private key

x and a public key g x .

• DH(x ← KP(), y): Derives a Diffie-Hellman shared secret between the private key within the key pair x and the public key y.

• E(k, n, ad, p): Encrypts and generates an authentication tag for plaintext p using key k and nonce n, optionally extending the authentication tag to cover associated data ad. The output is considered to be Authenticated Encryption with Associated Data (AEAD) [START_REF] Rogaway | Authenticated-encryption with associated-data[END_REF].

• D(k, n, ad, c): Decrypts and authenticates ciphertext c using key k and nonce n. Associated data ad must also be included if it was defined during the encryption step for authentication to pass on both c and ad.

• R(k): Returns a new key by applying a pseudorandom function on k.

• H(d):

A one-way hash function on data d.

• HKDF(ck, ik): A Hash-Based Key Derivation function [START_REF] Krawczyk | Cryptographic extraction and key derivation: The HKDF scheme[END_REF] that takes keys (ck, ik) and outputs a triple of keys. In some instances, the third key output is discarded and not used. The function is similar to the original HKDF definition but with ck acting as the salt and with a zero-length "info" variable.

CHAPTER 3. NOISE PROTOCOL FRAMEWORK

In ProVerif, Diffie-Hellman is implemented as a letfun that takes two keytype values (representing points on the Curve25519 [START_REF] Daniel | Curve25519: New Diffie-Hellman speed records[END_REF] elliptic curve) along with an equation that essentially illustrates the Diffie-Hellman relationship g ab = g ba in the symbolic model. Encryption is implemented as a function that produces a bitstring (representing the ciphertext) parametrized by a key, nonce, associated data and plaintext. Decryption is a reduction function that produces the correct plaintext only when the appropriate parameters are given, otherwise the process ends: Finally, H and HMAC are implemented as one-way functions parametrized by two bitstrings (for ease of use in modeling in the case of H, and for a keyed hash representation in the case of HMAC) while HKDF is constructed on top of them.

ProVerif Model Components

In the ProVerif model of a Noise Handshake Pattern, there are nine components:

1. ProVerif parameters. This includes whether to reconstruct a trace and whether the attacker is active or passive. 8. Events and queries. Here, the protocol events and security queries relevant to a particular Noise Handshake Pattern are defined. This includes the four authentication queries and five confidentiality queries discussed in §3.3.

9.

Protocol processes and top-level process. This includes the WriteMessage and ReadMessage function for each handshake and transport message, followed by the top-level process illustrating the live execution of the protocol on the network.

Representing Noise in the Applied Pi-Calculus

The Noise Protocol Framework [START_REF] Perrin | The Noise protocol framework[END_REF] is restricted only to describing messages between two parties (initiator and responder), the public keys communicated and any Diffie-Hellman operations conducted. Messages are called Noise "Message Patterns". They make up authenticated key exchanges, which are called Noise "Handshake Patterns". Noise supports authenticated encryption with associated data (AEAD) and Diffie-Hellman key agreement. The Noise Protocol Framework does not currently support any signing operations.

The full description of a Noise-based secure channel protocol is contained within its description of a Noise Handshake Pattern, such as the one seen in Fig. 3.1. The initial messages within a Noise Handshake Pattern, which contain tokens representing public keys or Diffie-Hellman operations are called handshake messages. After handshake messages, transport messages may occur carrying encrypted payloads. Here is an overview of the tokens that may appear in a handshake message:

• e, s. The sender is communicating their ephemeral or static public key, respectively.

• ee, es, se, ss. The sender has locally calculated a new shared secret. The first letter of the token indicates the initiator's key share while the second indicates the responder's key share. As such, this token remains the same irrespective of who is sending the particular handshake message in which it occurs. ←-h i pre-messages, then handshake • psk. The sender is mixing a pre-shared key into their local state and the recipient is assumed to do the same.

Optionally, certain key materials can be communicated before a protocol session is initiated. A practical example of how this is useful could be secure messaging protocols, where prior knowledge of an ephemeral key pair could help a party initiate a session using a zero-round-trip protocol, which allows them to send an encrypted payload without the responder needing to be online.

These pre-message patterns are represented by a series of messages occuring before handshake messages. The end of the pre-message stage is indicated by a ". . . " sign. For example, in Fig. 3.1, we see a pre-message pattern indicating that the initiator has prior knowledge of the responder's public static key before initiating a protocol session.

Validating Noise Handshake Pattern Syntax

Noise Handshake Patterns come with certain validity rules:

• Alternating message directions. Message direction within a Noise

REPRESENTING NOISE IN THE APPLIED PI-CALCULUS 109

Handshake Pattern must alternate (initiator → responder, initiator ← responder), with the first message being sent by the initiator.

• Performing Diffie-Hellman key agreement more than once. Principals must not perform the same Diffie-Hellman key agreement more than once per handshake.

• Sending keys more than once. Principals must not send their static public key or ephemeral public key more than once per handshake.

• Transport messages after handshake messages. Noise Handshake Patterns can only contain transport handshake messages at the very bottom of the pattern.

• Appropriate key share communication. Principals cannot perform a Diffie-Hellman operation with a key share that was not communicated to them prior.

• Unused key shares. Noise Handshake Patterns should not contain key shares that are not subsequently used in any Diffie-Hellman operation.

• Transport messages. Noise Handshake Patterns cannot consist purely of transport messages.

The Noise Handshake Pattern syntax is more formally described in Fig. 3.3, while validity rules are formalized in Fig. 3.4.

Local State

Each principal in a Noise protocol handshake keeps three local state elements: CipherState, SymmetricState and HandshakeState. These states contain each other in a fashion similar to a Russian Matryoshka doll, with HandshakeState being the largest element, containing SymmetricState which in turn contains CipherState.

• CipherState contains k (a symmetric key) and n (a nonce), used to encrypt and decrypt ciphertexts.

• SymmetricState contains a CipherState tuple (k, n), an additional key ck and a hash function output h.

• HandshakeState contains a SymmetricState along with additional local public keys (s, e) and remote public keys (rs, re).

Each state element comes with its own set of state transformation functions. These functions are triggered by the occurence and position of tokens within a Noise Handshake Pattern. We present a description of the state transition functions as seen in the Noise Protocol Framework specification, but restricted to a representation that follows implementing Noise Handshake Patterns in the symbolic model. • HasKey(): Returns true if k is non-empty, false otherwise.

k d ∈ Γ Γ ∪ {k d } d p Γ d k, p Message Validity: Γ d m MsgEmpty ss ∈ Γ ⇒ se ∈ Γ se ∈ Γ ⇒ ee ∈ Γ psk ∈ Γ ⇒ e ∈ Γ Γ MsgEmpty ss ∈ Γ ⇒ es ∈ Γ es ∈ Γ ⇒ ee ∈ Γ psk ∈ Γ ⇒ e ∈ Γ Γ MsgKey k d ∈ Γ Γ ∪ {k d } d m Γ d k, m MsgDH k 1 ∈ Γ k 2 ∈ Γ k 1 k 2 ∈ Γ Γ ∪ {k 1 k 2 } d m Γ d k 1 k 2 , m MsgPSK psk ∈ Γ Γ ∪ {psk} d m Γ d psk, m Handshake Validity: Γ h i HSEmpty Γ HSMessageI Γ m Γ ∪ tokens(m) h r Γ m -→ h r HSMessageR Γ m Γ ∪ tokens(m) h i Γ m ← -h i Noise Pattern Validity: n NoiseValid {} p 1 {} p 2 tokens(p 1 ) ∪ tokens(p 2 ) h i p 1 -→ p 2 ← -h i
• SetNonce(nonce): Sets n = nonce.

• EncryptWithAd(ad, p): If k is non-empty returns E(k, n, ad, p) then increments n. Otherwise returns p.

• DecryptWithAd(ad, c): If k is non-empty returns D(k, n, ad, c) then increments n. Otherwise returns c. n is not incremented if authenticated decryption fails.

• Rekey(): Sets k = R(k).

REPRESENTING NOISE IN THE APPLIED PI-CALCULUS 111

In ProVerif, InitializeKey simply returns a cipherstate-type value packed with the input key and a starting nonce. hasKey unpacks an input cipherstate and checks whether the key is defined. The rest of the functions are based on similarly evident constructions:

SymmetricState

A SymmetricState comes with the following state transition functions:

• InitializeSymmetric(name): Sets ck = h = H(name).

• MixKey(ik): Sets (ck, tk) = HKDF(ck, ik) and calls InitializeKey(tk).

• MixHash(data): Sets h = H(h data). 4• MixKeyAndHash(ik): Sets (ck, th, tk) = HKDF(ck, ik), then calls MixHash(th) and InitializeKey(tk).

• GetHandshakeHash(): Returns h.

• EncryptAndHash(p): Sets c = EncryptWithAd(h, p). Calls MixHash(c) and returns c.

• DecryptAndHash(c): Sets p = DecryptWithAd(h, c). Calls MixHash(c) and returns c and returns p.

• Split(): Sets (tk 1 , tk 2 ) = HKDF(ck, zero). Creates two CipherStates (c 1 , c 2 ). Calls c 1 .InitializeKey(tk 1 ) and c 2 .InitializeKey(tk 2 ). Returns (c 1 , c 2 ), a pair of CipherStates for encrypting transport messages. 5In ProVerif, these functions are implemented based on letfun declarations that combine previously declared funs and letfuns:

HandshakeState

A HandshakeState comes with the following state transition functions:

• Initialize(hp, i, s, e, rs, re): hp denotes a valid Noise Handshake Pattern. i is a boolean which denotes whether the local state belongs to the initiator. Public keys (s, e, rs, re) may be left empty or may be preinitialized in the event that any of them appeared in a pre-message. Calls InitializeSymmetric(hp.name). Calls MixHash() once for each public key listed in the pre-messages within hp.

• WriteMessage(p): Depending on the tokens present in the current

REPRESENTING NOISE IN THE APPLIED PI-CALCULUS

113 handshake message, different operations occur:

e: Sets e ← KP(). Appends g e to the return buffer. Calls MixHash(g e ).

s: Appends EncryptAndHash(g s ) to the buffer.

ee: Calls MixKey(DH(e, re)).

es: Calls MixKey(DH(e, rs)) if initiator, MixKey(DH(s, re)) if responder.

se: Calls MixKey(DH(s, re)) if initiator, MixKey(DH(e, rs)) if responder.

ss: Calls MixKey(DH(s, rs)).

Then, EncryptAndHash(p) is appended to the return buffer. If there are no more handshake messages, two new CipherStates are returned by calling Split().

• ReadMessage(m): Depending on the tokens present in the current handshake message, different operations occur:

e: Sets re to the public ephemeral key retrieved from m.

s: Sets temp to the encrypted public static key retrieved from m. Sets rs to the result of DecryptAndHash(temp), failing on authenticated decryption error.

ee: Calls MixKey(DH(e, re)).

es: Calls MixKey(DH(e, rs)) if initiator, MixKey(DH(s, re)) if responder.

se: Calls MixKey(DH(s, re)) if initiator, MixKey(DH(e, rs)) if responder.

ss: Calls MixKey(DH(s, rs)).

Then, DecryptAndHash is called on the message payload extracted from m. If there are no more handshake messages, two new CipherStates are returned by calling Split().

Dynamically Generating ReadMessage and WriteMessage Functions in the Applied Pi-Calculus

In Noise Explorer (our analysis framework for Noise Handshake Patterns), cryptographic primitives and state transition functions are included from a preexisting set of Noise Protocol Framework ProVerif headers written as a part of this work and are not automatically generated according to a set of rules. Events, queries, protocol processes and the top-level process, however, are fully generated using translation rules that make them unique for each Noise Handshake Pattern.

In our generated ProVerif models, each handshake message and transport message is given its own WriteMessage and ReadMessage construction represented as letfuns. state transition functions depending on the tokens included in the message pattern being translated. An example generated translation can be see in Fig. 3.5, which concerns the first message in IK (Fig. 3.1): → e, es, s, ss.

The state transition rules described in Noise Protocol Framework specifi-cation are implicated by the tokens within the message pattern. By following these rules, Noise Explorer generates a symbolic model that implements the state transitions relevant to this particular message pattern. From the initiator's side:

• e: Signals that the initiator is sending a fresh ephemeral key share as part of this message. This token adds one state transformation to writeMessage_a: mixHash, which hashes the new key into the session hash.

• es: Signals that the initiator is calculating a Diffie-Hellman shared secret derived from the initiator's ephemeral key and the responder's static key as part of this message. This token adds one state transformation to writeMessage_a: mixKey, which calls the HKDF using as input the existing SymmetricState key and DH(e, rs), the Diffie-Hellman share calculated from the initiator's ephemeral key and the responder's static key.

• s: Signals that the initiator is sending a static key share as part of this message. This token adds one state transformation to writeMessage_a: encryptAndHash is called on the static public key. If any prior Diffie-Hellman shared secret was established between the sender and the recipient, this allows the initiator to communicate their long-term identity with some degree of confidentiality.

• ss: Signals that the initiator is calculating a Diffie-Hellman shared secret derived from the initiator's static key and the responder's static key as part of this message. This token adds one state transformation to writeMessage_a: mixKey, which calls the HKDF function using, as input, the existing SymmetricState key, and DH(s, rs), the Diffie-Hellman share calculated from the initiator's static key and the responder's static key.

Message A's payload, which is modeled as the output of the function msg_a(initiatorIdentity, responderIdentity, sessionId), is encrypted as ciphertext2. This invokes encryptAndHash, which performs AEAD encryption on the payload, with the session hash as the associated data (encryptWithAd) and mixHash, which hashes the encrypted payload into the next session hash.

On the receiver end:

• e: Signals that the responder is receiving a fresh ephemeral key share as part of this message. This token adds one state transformation to readMessage_a: mixHash, which hashes the new key into the session hash.

• es: Signals that the responder is calculating a Diffie-Hellman shared secret derived from the initiator's ephemeral key and the responder's static key as part of this message. This token adds one state transformation to readMessage_a: mixKey, which calls the HKDF function using, as input, the existing SymmetricState key, and DH(s, re), the Diffie-Hellman share calculated from the initiator's ephemeral key and the responder's static key.

• s: Signals that the responder is receiving a static key share as part of this message. This token adds one state transformation to readMessage_a: decryptAndHash is called on the static public key. If any prior Diffie-Hellman shared secret was established between the sender and the recipient, this allows the initiator to communicate their long-term identity with some degree of confidentiality.

• ss: Signals that the responder is calculating a Diffie-Hellman shared secret derived from the initiator's static key and the responder's static key as part of this message. This token adds one state transformation to readMessage_a: mixKey, which calls HKDF function using, as input, the existing SymmetricState key and DH(s, rs), the Diffie-Hellman share calculated from the initiator's static key and the responder's static key.

Message A's payload invokes the following operation: decryptAndHash, which performs AEAD decryption on the payload, with the session hash as the associated data (decryptWithAd) and mixHash, which hashes the encrypted payload into the next session hash. The full Noise Protocol Framework specification extends somewhat beyond the description given as part of this work, including features such as "identity hiding" and "dummy keys." Some of these features are potentially valuable and slated as future work.

Other Specification Features

Modeling Security Goals in the Symbolic Model

Since our goal is to evaluate the security guarantees achieved by arbitrary Noise Handshake Patterns, it is crucial to have a set of well-defined security goals on which to base our analysis. We want to formulate these "security grades" in ProVerif as event-based queries. This implies specifying a number of events triggered at specific points in the protocol flow as well as queries predicated on these events.

A set of the queries for the security goals described in this section is generated for each handshake and transport message within a Noise Handshake Pattern, allowing for verification to occur in the comprehensive context described in §3.1.

The Noise Protocol Framework specification defines different Noise Handshake Patterns to suit different scenarios. These patterns come with different security properties depending on which keys and shared secrets are employed and when. Two types of security grades are defined: "authentication" grades dealing with the authentication of a message to a particular sender (and optionally, receiver) and "confidentiality" grades dealing with a message's ability to resist the obtention of plaintext by an unauthorized party.

For example, the Noise Handshake Pattern illustrated in Fig. 3.1 is described in the original specification as claiming to reach strong security goals: handshake and transport message are attributed authentication grades of 1, 2, 2 and 2 respectively, and confidentiality grades of 2, 4, 5 and 5. Other Noise Handshake Patterns, such as the one described in Fig. 3.2, sacrifice security properties to deal away with the need to share public keys beforehand or to conduct additional key derivation steps (authentication: 0, 0, 2, 0 and confidentiality: 0, 3, 1 5.)

In our analysis, we leave the confidentiality grades intact. However, we introduce two new additional security grades, 3 and 4, which provide more nuance for the existing authentication grades 1 and 2. In our analysis, authentication grades 1 and 2 hold even if the authentication of the message can be forged towards the recipient if the sender carries out a separate session with a separate, compromised recipient. Authentication grades 3 and 4 do not hold in this case. This nuance does not exist in the authentication grades defined in the latest Noise Protocol Framework specification.

In all examples below, Bob is the sender and Alice is the recipient. The message in question is message D, i.e. the fourth message pattern within the Noise Handshake Pattern. In the event of a non-existent static key for either Alice or Bob, or of a non-existent PSK, the relevant LeakS or LeakPsk event is removed from the query. A principal c refers to any arbitrary principal on the network, which includes compromised principal Charlie.

Events

The following events appear in generated ProVerif models:

• SendMsg(principal, principal, stage, bitstring) takes in the identifier of the message sender, the identifier of the recipient, a "stage" value and the plaintext of the message payload. The "stage" value is the output of a function parametrized by the session ID, a unique value generated for each execution of the protocol using ProVerif's new keyword, and an identifier of which message this is within the Noise Handshake Pattern (first message, second message, etc.)

• RecvMsg(principal, principal, stage, bitstring) is a mirror event of the above, with the first principal referring to the recipient and the second referring to the sender.

• LeakS(phasen, principal) indicates the leakage of the long-term secret key of the principal. phasen refers to which "phase" the leak occured: in generated ProVerif models, phase 0 encompasses protocol executions that occur while the session is under way, while phase 1 is strictly limited to events that occur after the session has completed and has been closed.

• LeakPsk(phasen, principal, principal) indicates the leakage of the pre-shared key (PSK) of the session between an initiator (specified as the first principal) and a responder in the specified phase.

Authentication Grades

Grade 0 indicates no authentication: the payload may have been sent by any party, including an active attacker.

Sender authentication

In this query, we test for sender authentication and message integrity. If Alice receives a valid message from Bob, then Bob must have sent that message to someone, or Bob had their static key compromised before the session began, or Alice had their static key compromised before the session began:

RecvM sg(alice, bob, stage(d, sid), m) -→ SendM sg(bob, c, stage(d, sid), m) ∨ (LeakS(phase 0 , bob) ∧ LeakP sk(phase 0 , alice, bob)) ∨ (LeakS(phase 0 , alice) ∧ LeakP sk(phase 0 , alice, bob))

Sender authentication and key compromise impersonation resistance

In this query, we test for sender authentication and Key Compromise Impersonation resistance. If Alice receives a valid message from Bob, then Bob must have sent that message to someone, or Bob had their static key compromised before the session began.

RecvM sg(alice, bob, stage(d, sid), m) -→

SendM sg(bob, c, stage(d, sid), m) ∨ LeakS(phase 0 , bob)

Sender and received authentication and message integrity

If Alice receives a valid message from Bob, then Bob must have sent that message to Alice specifically, or Bob had their static key compromised before the session began, or Alice had their static key compromised before the session began. This query is not present in the original Noise Protocol Framework specification and is contributed by this work.

RecvM sg(alice, bob, stage(d, sid), m) -→

SendM sg(bob, alice, stage(d, sid), m) ∨ (LeakS(phase 0 , bob) ∧ LeakP sk(phase 0 , alice, bob)) ∨ (LeakS(phase 0 , alice) ∧ LeakP sk(phase 0 , alice, bob))

Sender and receiver authentication and key compromise impersonation resistance

If Alice receives a valid message from Bob, then Bob must have sent that message to Alice specifically, or Bob had their static key compromised before the session began. This query is not present in the original Noise Protocol Framework specification and is contributed by this work.

RecvM sg(alice, bob, stage(d, sid), m) -→

SendM sg(bob, alice, stage(d, sid), m) ∨ LeakS(phase 0 , bob)

Confidentiality Grades

Grade 0 indicates no confidentiality: the payload is sent in cleartext.

Encryption to an ephemeral recipient

In these queries, we test for message secrecy by checking if a passive attacker or active attacker is able to retrieve the payload plaintext only by compromising Alice's static key either before or after the protocol session. Passing this query under a passive attacker achieves confidentiality grade 1, while doing so under an active attacker achieves confidentiality grade 2 (encryption to a known recipient, forward secrecy for sender compromise only, vulnerable to replay.)

attacker p1 (msg d (bob, alice, sid)) -→ (LeakS(phase 0 , alice) ∨ LeakS(phase 1 , alice)) ∧ (LeakP sk(phase 0 , alice, bob) ∨ LeakP sk(phase 1 , alice, bob))
In the above, attacker p1 indicates that the attacker obtains the message in phase 1 of the protocol execution.

Encryption to a known recipient, weak forward secrecy

In this query, we test for forward secrecy by checking if a passive attacker is able to retrieve the payload plaintext only by compromising Alice's static key before the protocol session, or after the protocol session along with Bob's static public key (at any time.) Passing this query under a passive attacker achieves confidentiality grade 3, while doing so under an active attacker achieves confidentiality grade 4 (encryption to a known recipient, weak forward secrecy only if the sender's private key has been compromised.)

attacker p1 (msg d (bob, alice, sid)) -→ (LeakS(phase 0 , alice) ∧ LeakP sk(phase 0 , alice, bob)) ∨ (LeakS(p x , alice) ∧ LeakP sk(p y , alice, bob) ∧ LeakS(p z , bob))
In the above, p x , p y , p z refer to any arbitrary phases.

Encryption to a known recipient, strong forward secrecy

In this query, we test for strong forward secrecy by checking if an active attacker is able to retrieve the payload plaintext only by compromising Alice's static key before the protocol session. Passing this query achieves confidentiality grade 5. attacker p1 (msg d (bob, alice, sid)) -→ (LeakS(phase 0 , alice) ∧ LeakP sk(phase 0 , alice, bob))

Limitations on Modeling Security Grades

Our analysis of authentication grades comes with an important limitation: When Noise Explorer generates the authentication queries below, it uses two different values, sid a and sid b , to refer to the session ID as registered in the trigger events by Alice and Bob. This differs from, and is in fact less accurate than the queries described previously, which use the same session ID, sid, for both Alice and Bob. We are forced to adopt this approach due to performance limitations in our models during verification should we choose to use a single sid value for both Alice and Bob. However, we argue that since processes with differing sid values cause decryption operations that use shared secrets derived from ephemeral keys to fail, and therefore for those processes to halt, we still obtain essentially the same verification scenarios that these queries target.

Additionally, with regards to our confidentiality grades, whenever a pattern contains a PSK and LeakPSK events start to get involved, we ideally account for cases where one long-term secret is compromised but not the other. This indicates that we may need a richer notion of authenticity and confidentiality grades than the 1-5 markers that the Noise specification provides. For consistency, we are still using the old grades, but to truly understand and differentiate the security provided in many cases, we recommend that the user view the detailed queries and results as generated by Noise Explorer and available in its detailed rendering of the verification results.

VERIFYING ARBITRARY NOISE HANDSHAKE PATTERNS

Patt. Auth. Conf. N 0 2 K 1 2 X 1 2 NN 0 0 0 0 1 1 NK 0 2 0 2 1 5 NX 0 2 0 0 1 5 XN 0 0 2 0 0 1 1 5 XK 0 2

Verifying Arbitrary Noise Handshake Patterns

A central motivation to this work is the obtention of a general framework for designing, reasoning about, formally verifying and comparing any arbitrary Noise Handshake Pattern. Noise Explorer is a web framework that implements all of the formalisms and ProVerif translation logic described so far in this work in order to provide these features. Noise Explorer is ready for use by the general public today at https:// noiseexplorer.com. Here are Noise Explorer's main functionalities: Designing and validating Noise Handshake Patterns. This allows protocol designers to immediately obtain validity checks that verify if the protocol conforms to the latest Noise Protocol Framework specification. 6Generating cryptographic models for formal verification using automated verification tools. Noise Explorer can compile any Noise Handshake Pattern to a full representation in the applied pi-calculus including cryptographic primitives, state machine transitions, message passing and a top-level process illustrating live protocol execution. Using ProVerif, we can then test against sophisticated security queries starting at basic confidentiality and authentication and extending towards forward secrecy and resistance to key compromise impersonation.

Exploring the first compendium of formal verification results for Noise Handshake Patterns. Since formal verification for complex Noise Handshake Patterns can take time and require fast CPU hardware, Noise Explorer comes with a compendium detailing the full results of all Noise Handshake Patterns described in the latest revision of the original Noise Protocol Framework specification. These results are presented with a security model that is more comprehensive than the original specification, as described in §3.3.

Accessible High Assurance Verification for Noise-Based Protocols

Noise Explorer users are free to specify any arbitrary Noise Handshake Pattern of their own design. Once this input is validated, formal verification models are generated. The ProVerif verification output can then be fed right back into Noise Explorer, which will then generate detailed interactive pages describing the analysis results.

The initial view of the results includes a pedagogical plain-English paragraph for each message summarizing its achieved security goals. For example, the following paragraph is generated for message D (i.e. the fourth message pattern) of IK:

"Message D, sent by the responder, benefits from sender and receiver authentication and is resistant to Key Compromise Impersonation. Assuming the corresponding private keys are secure, this authentication cannot be forged. Message contents benefit from message secrecy and strong forward secrecy: if the ephemeral private keys are secure and the initiator is not being actively impersonated by an active attacker, message contents cannot be decrypted by an adversary."

Furthermore, each message comes with a detailed analysis view that allows the user to immediately access a dynamically generated representation of the state transition functions for this particular message as modeled in ProVerif and a more detailed individual writeup of which security goals are met and why. We believe that this "pedagogy-in-depth" that is provided by the Noise Explorer web framework will allow for useful, push-button analysis of any constructed protocol within the Noise Protocol Framework that is comprehensive. Noise Explorer's development was done in tandem with discussions with the Noise Protocol Framework author: pre-release versions were built around revision 33 of the Noise Protocol Framework and an update to support revision 34 of the framework was released in tandem with the specification revision draft. Revision 34 also included security grade results for deferred patterns that were obtained directly via Noise Explorer's compendium of formal analysis results. We plan to continue collaborating with the Noise Protocol Framework author indefinitely to support future revisions of the Noise Protocol Framework.

MODELING FOR FORGERY ATTACKS

Noise Explorer Verification Results

Noise Explorer was used to generate ProVerif models for more than 50 Noise Handshake Patterns, all of which were subsequently verified with the results shown in Fig. 3.7. We found that all of the Noise Handshake Patterns evaluated met the security goals postulated in the original Noise Protocol Framework Specification. Verification times varied between less than 30 minutes for simpler (and less secure) patterns (such as NN) to more than 24 hours for some of the more ambitious patterns, such as IK. All of the results are accessible publicly using Noise Explorer's compendium interface 7 and the official Noise Protocol Framework specification has updated in order to take our results into account.

Modeling for Forgery Attacks

Using ProVerif, we were able to test for the necessity of certain Noise Handshake Patterns and to document a forgery attack within certain Noise Handshake Patterns that becomes possible when these rules are not followed appropriately. Essentially, we can compose well-known attack vectors (invalid Diffie-Hellman key shares, repeated AEAD nonces) to attack patterns that rely only on staticstatic key derivation (ss) for authentication.

Consider the pattern KXS below:

KXS : → s . . . → e ← e,

ee, s, ss

This is a variation of the Noise Handshake Pattern KX that uses ss instead of se, and es, so it is a little more efficient while satisfying the same confidentiality and authentication goals. In particular, the responder can start sending messages immediately after the second message.

However, there is an attack if the responder does not validate ephemeral public values. Suppose a malicious initiator were to send an invalid ephemeral public key e, say e = 0. Then, because of how Diffie-Hellman operations work on X25519, the responder would compute ee = 0 and the resulting key would depend only on the static key ss. Note that while the responder could detect and reject the invalid public key, the Noise specification explicitly discourages this behavior.

Since the responder will encrypt messages with a key determined only by ss (with a nonce set to 0), the malicious initiator can cause it to encrypt two 124 CHAPTER 3. NOISE PROTOCOL FRAMEWORK messages with the same key and nonce, which allows for forgery attacks. A concrete man-in-the-middle attack on this pattern is as follows: 8In the pre-message phase, A sends a public static key share s A to B. In the first session:

1. A malicious C initiates a session with B where he pretends to be A. C sends e = Z such that Z x would evaluate to Z for any x. This effectively allows us to model for forcing an X25519 zero-value key share in the symbolic model.

2.

B receives e = Z and accepts a new session with:

• h B0 = H(pattern_name)

• ck B1 = h B0 • h B1 = H(h B0 , s A , e = Z)
3. B generates re 1 , computes ee = Z and sends back (re 1 , ee = Z, s B , ss AB , msg a ) where s B is encrypted with ck B2 = H(ck B1 , ee = Z) as the key, 0 as the nonce and h B2 = H(h B1 , re 1 , ee = Z) as associated data.

4. msg a is encrypted with ck B3 = H(ck B2 , ss AB ) as the key, 0 as the nonce and h B3 = H(h B2 , s B ) as associated data.

5. C discards this session but remembers the encrypted message.

In a second session:

1. A initiates a session with B by sending e. So, at A:

• h A0 = H(pattern_name) • ck A1 = h A0 • h A1 = H(h A0 , s A , e)
2. C intercepts this message and replaces it with the invalid public key Z = 0.

B receives e = Z and accepts a new session with:

• h B0 = H(pattern_name)

• ck B1 = h B0 • h B1 = H(h B0 , s A , e = Z)
4. B generates re 2 , computes ee = Z and sends back (re 2 , ee = Z, s B , ss AB , msg b ) where s B is encrypted with ck B2 = H(ck B1 , ee = Z) as the key, 0 as the nonce and h B2 = H(h B1 , re) as associated data.

5. msg b is encrypted with ck B3 = H(ck B2 , ss AB ) as the key, 0 as the nonce and h B3 = H(h B2 , s B ) as associated data.

6. C intercepts this response.

Notably, the encryption keys (ck B3 ) and the nonces (0) used for msg a in session 1 and msg b in session 2 are the same. Hence, if the underlying AEAD scheme is vulnerable to the repeated nonces attack, C can compute the AEAD authentication key for ck B3 and tamper with msg a and msg b to produce a new message msg c that is validly encrypted under this key. Importantly, C can also tamper with the associated data h B3 to make it match any other hash value.

C replaces the message with (re = Z, ee = Z, s B , ss AB , msg c ) and sends it to A, where s B is re-encrypted by C using ck B2 which it knows and msg c is forged by C using the AEAD authentication key for ck B3 . A receives the message (re = Z, ee = Z, s B , ss AB , msg c ) and computes ck A2 = H(ck A1 , ee = Z) and h A2 = H(h A1 , ee = Z). A then decrypts s B . A then computes ck A3 = H(ck A2 , ss AB ) and h A3 = H(h A2 , s AB ) and decrypts msg c . This decryption succeeds since ck A3 = ck B3 . The attacker C therefore has successfully forged the message and the associated data.

At a high level, the above analysis can be read as indicating one of three shortcomings:

1. Using ss in Noise Handshake Patterns must be done carefully. A Noise Handshake Pattern validation rule could be introduced to disallow the usage of ss in a handshake unless it is accompanied by se or es in the same handshake pattern.

2. Diffie-Hellman key shares must be validated. Implementations must validate incoming Diffie-Hellman public values to check that they are not one of the twelve known integers [START_REF] Daniel | Curve25519: New Diffie-Hellman speed records[END_REF] which can cause a scalar multiplication on the X25519 curve to produce an output of 0.

3. Independent sessions must be checked for AEAD key reuse. Ephemeral and static public key values are mixed into the encryption key derivation step.

As a result of this analysis, revision 34 of the Noise Protocol Framework specification included clearer wording of the validity rule which would render the KXS pattern invalid:

After calculating a Diffie-Hellman shared secret between a remote public key (either static or ephemeral) and the local static key, the local party must not perform any encryptions unless it has also calculated a Diffie-Hellman key share between its local ephemeral key and the remote public key. In particular, this means that:

• After an se or ss token, the initiator must not send a payload unless there has also been an ee or es token respectively.

• After an es or ss token, the responder must not send a payload unless there has also been an ee or se token respectively.

Conclusion and Future Work

In this work, we have provided the first formal treatment of the Noise Protocol Framework. We translate our formalisms into the applied pi-calculus and use this as the basis for automatically generating models for the automated formal verification of arbitrary Noise Handshake Patterns. We coalesce our results into Noise Explorer, an online framework for pedagogically designing, validating, verifying and reasoning about arbitrary Noise Handshake Patterns. Noise Explorer has already had an impact as the first automated formal analysis targeting any and all Noise Handshake Patterns. Verification results obtained from Noise Explorer were integrated into the original specification and refinements were made to the validation rules and security goals as a result of the scrutiny inherent to our analysis.

Ultimately, it is not up to us to comment on whether the Noise Protocol Framework presents a "good" framework, per se. However, we present confident results that its approach to protocol design allows us to cross a new bridge for not only designing and implementing more robust custom secure channel protocols, but also applying existing automated verification methodologies in new and more ambitious ways.

Future work could include the automated generation of computational models to be verified using CryptoVerif and of verified implementations of Noise Handshake Patterns. The scope of our formalisms could also be extended to include elements of the Noise Protocol Framework specification, such as queries to test for identity hiding. • Formally specifying and verifying ACME: in §4.3, we formally specify the ACME protocol within a symbolic model in the applied π-calculus that encodes the adversarial capabilities described in §4.2. We verify the main security goals of ACME using ProVerif. Although ACME is shown to be more resistant to attacks than ad-hoc CAs, we also discover weaknesses in ACME's domain validation and account recovery and propose countermeasures.

Current State of Domain Validation

A goal of this chapter is to establish a relationship between current domain validation practices in the real world and a more formal threat model on which we base our security results. We begin by taking a closer look into the network infrastructure, user authentication and domain validation protocols currently in use by traditional CAs. Our panel of surveyed CA is selected from the data set of Delignat-Lavaud et al. [START_REF] Delignat-Lavaud | Web pki: Closing the gap between guidelines and practices[END_REF], which uses machine learning to classify certificates issued by domain validation. Our CA panel covers about 85% of the collected domain validated certificates from 2014, which is consistent with the January 2015 market share data from the Netcraft SSL survey 1 . For each CA, we obtain a regular one year, single-domain certificate signature for a domain name that we own. §3.2.2.4 of the CA/Browser Forum's Baseline Requirements allow for domain validation to occur in ten different ways, including over postal mail. Of these methods, only three are in popular use: validation via email, the setting of an arbitrary DNS record, or serving some HTTP value on the target domain.

Domain Validation Mechanisms

With ad-hoc CAs, user C authenticates its identity C pk to CA A as a simple username/password web login, with an option for account recovery via email. C can then request that A validate some domain C w ⊂ C , where C w is the set of all domain names that C controls. A's flow with the various domain validation channels proceeds thus:

• HTTP Identifier A sends to C a nonce A N C via an HTTPS channel that C must then advertise at some agreed-upon location under C w . A then accesses C w using an unauthenticated, unencrypted HTTP connection to ensure that it can retrieve A N C . This identifier depends both on honest In practice, we find that CAs that allow HTTP identifiers require the nonce to be written on a text file with a long random name in the root of the validated domain. An attacker able to respond to HTTP requests for such names may get a certificate without access to the domain's DNS records.

• DNS identifier A sends to C a nonce A DN S C via an HTTPS channel that C must then advertise at some agreed-upon TXT record under the DNS records of C w . A then queries C w 's name servers using to ensure that it can retrieve A DN S C . This identifier is dependent on honest resolution of the TXT record.

None of the CAs we surveyed advertises DNSSEC support to ensure this DNS resolution is indeed authentic. As an experiment, we set up a DNSSECenabled domain and configured our nameserver to send an invalid RRSig for the TXT record of the domain validation nonce for Comodo. The validation ultimately completed, indicating that the use of DNSSEC does not currently prevent attacks against DNS-based domain validation by current CAs.

• Email identifier A sends to C a URI A U RI C via an email to an address E C that A presumes to belong to C. Accessing this URI causes A to issue the certificate for C w . This identifier is dependent on the confidential transport of the email (which may be routed through third party SMTP servers that are not guaranteed to use TLS encryption) and honest DNS resolution of the validated domain's MX records.

In practice, we observe that CAs use dangerous heuristics to generate a list of possible E C that C can pick from: first, they presume that any email addresses that appear in the WHOIS records of C w is controlled by C.

A large majority of registrars provide WHOIS privacy services to defend against spam. Such services can easily obtain certificates for any of their customers' domains as validation email transit through their mail servers. Second, CAs' heuristics include generic names such as postmaster, webmaster, or admin. If the validated domain provides an email service for which users may chose their username, an attacker may register under one of those generic names and obtain a unauthorized certificate. Such attacks have been carried successfully in the past against public email services such as Hotmail.

Once one of the above identifiers succeeds in validating C's ownership of C w to A, A issues the certificate and the protocol ends. None of CAs we surveyed offers a login mechanism that is completely independent of email. An exception almost occurs with StartSSL, which supports browser-generated X.509 client certificates for web login, but this exception is negated by the email-based account recovery in case of a lost certificate private key. Reliance on the security of the email channel can in many cases be even more serious: in many surveyed CAs, simply being able to complete a web lo-

User Authentication and Domain Validation

A SECURITY MODEL FOR DOMAIN VALIDATION

131

gin enables user to re-issue certificates for domains they had already validated before, without further validation.

A scan of the DNS MX and NS records of the web's top 10,000 websites (according to Alexa.com) [START_REF][END_REF] showed that roughly 45% of surveyed domain names used only six DNS providers, of which CloudFlare alone had a 18% share. 2A similar centralization of authority exists with email, where the top six providers serve more than 55% of domain names surveyed, with Google alone holding roughly 27% market share ( These results suggest that the number of actors of which the compromise could affect traditional domain validation is significantly small. This is relevant given how top CAs allow for account recovery, certificate re-issuance and more with simple email-based validation.

A Security Model for Domain Validation

The protocols considered in this chapter operate between a party C claiming to serve and represent one or more domain names C w (for which it wants certificates) and it is incumbent upon a certificate issuer A to verify that all domains in C w are indeed controlled and managed by C. User C authenticates itself to the certificate authority A using a public key C pk corresponding to the private signing key C k . C can then link identifiers under C k that prove that it manages and controls domains in C w .

This and following sections are largely based on our full symbolic model 3 of ACME and ad-hoc CA protocol and network flow, which is written in the applied pi calculus and verified using ProVerif. Excerpts of this model are inlined throughout. The network topology, channels and actors are essentially the same for both ACME and ad-hoc CAs. However, the manner in which these actors communicate over the channels is different and leads to different attempts to establish the same security guarantees.

Security Goals and Threat Model

Channels

Intuitively, the channels we want encapsulate the following properties:

• HTTPS Channel Intuitively a regular web channel, we treat it as a Aauthenticated duplex channel whereupon anyone can send a request to A, only A can read this request and respond, and only the sender can read this response.

• Strong Identifier Channels These channels must be assumed to be writable only by C. They are therefore relevant for HTTP and DNS Identifiers.

• Weak Identifier Channel Anyone can write to this channel, but only C can read from it. This makes it relevant for domain validation via email identifiers.

A shared consideration between ACME and ad-hoc CAs involves the critical importance of DNS resolution: if the attacker can simply produce false DNS responses for A resolving a domain request for any domain in C w , it becomes impossible to safely carry out domain validation under any circumstances. As a sidenote, this allows us to argue that since the DNS channel must be trusted, it could also be considered as the safest channel on which to carry out domain validation using DNS Identifiers since that would allow C to avoid needlessly involving other channels. In formally describing our network model in ProVerif, we simulate simultaneous requests from Alice, Bob and Mallory as independent clients C. Alice and Bob both act as honest clients, while Mallory acts as a compromised participant client. All three follow the same protocol top-level process. We also simulate two independent ACME CAs, which interchangeably assume the role of A. For each C, we specify a triple of distinct channels:

(C HT T P , C EM AIL , C DN ST XT )
Each channel represents access to a different domain validation mechanism. While C is given complete access over these channels, C EM AIL is only handed to A after being applied through a "write transformation" which returns a variant of the channel that is effectively write-only:

w(channel) → channel
Similarly, a "read transformation" r(channel) → channel is applied to C HT T P and C DN ST XT .

A routing proxy is then specified in order to model the transportation across these channels by executing the following unbounded processes in parallel 4 : in(w(C EM AIL ), x); out(r(C EM AIL ), x) in(pub, x); out(r(C EM AIL ), x) in(w(C HT T P ), x); out(pub, x); out(r(C HT T P ), x) in(w(C DN ST XT ), x); out(pub, x); out(r(C DN ST XT ), x)

Threat Model

We assume that the adversary controls parts of the network and so can intercept, tamper with and inject network messages. As such, an attacker could make requests for domains they do not own, intercept and delay legitimate certificate requests and so on. Our adversary has full access to pub, w(C EM AIL ), r(C HT T P ) and r(C DN ST XT ). We also publish Mallory's channels and C k over pub. As such, the attacker controls a set of valid participants (e.g. M ) with their own valid identities (e.g. M k , M pk ). The attacker may advertise any identity for its controlled principals, including false identities and may attempt to obtain a certificate for domains not legitimately under M w .

The adversary also has at his disposal certain special functions: 134 CHAPTER 4. AUTOMATED DOMAIN NAME VALIDATION

• PoisonDnsARecord, which takes in a domain C w and allows the attacker to poison its DNS records to redirect to a server owned by M . Calling this function triggers the ActiveDnsAttack(C w ) event.

• ManInTheMiddleHttp, which allows the attacker to write arbitrary HTTP requests as if they were emitting from C HT T P by disclosing C HT T P to the attacker. Calling this function triggers the ActiveHttpAttack(C w ) event.

ProVerif Events and Queries

Under ProVerif, queries under our symbolic model are constructed from sequences of the following events, each callable by a particular type of actor: • Adversary As noted above, the adversary may trigger the events ActiveDnsAttack(C w ) and ActiveHttpAttack(C w ). In addition, the adversary is allowed to masquerade as M in order assert that they own some domain by triggering the event Owner(M pk , C w ).

Queries

Queries encode the security properties that we expect our model to satisfy. For example, informally, we expect a CertIssued event may only occur following an HttpAuth or DnsAuth event for the same domain, expressing the fact that ACME should not issue a certificate for an non-validated domain under any circumstance. Running ProVerif on the query can result in three outcomes: either it diverges (in which case the model or query needs to be simplified), or it proves that the model satisfies the query, or it finds a counter-example and outputs its trace (which can be turned into an attack).

Validation with DNS Identifiers

We assert that if DNS validation succeeded, then A must have been able to successfully carry out DNS validation according to spec, or an adversary was able to instantiate an active DNS poisoning attack (with no third possible scenario). In ProVerif, this can be expressed using injective event queries:

DnsAuth(C pk , C w ) =⇒ (Owner(C k , C w ) ∨ DnsAttack(C w )) CHAPTER 4. AUTOMATED DOMAIN NAME VALIDATION C w Web Server C Domain Owner A ACME Server Knows C k , C rk , C pk , C prk , C c C w ⊂ C Knows A k Sign(C k , (newreg, C c , C pk , C prk ))
Creates account for C under C pk Generates recovery key pair (A rk AC , A prk AC )

C recovery A = KDF (C Z A , C H A , recovery) A prk AC C recovery A = KDF (C Z A , C H A , recovery) Sign(C k , newauthz) authz(A N C ) (C pk , A N C ) (C pk , A N C ) Sign(C k , newcert(C wcsr ))
Generates C wcert based on C wcsr Sign(A k , C wcert ) record management depends on a series of ad-hoc protocols of its own between C and DNS service providers, it is not used by ACME.

Out-of-Band Validation

The ACME standard draft supports an out-of-band validation mechanism, which can be used to implement legacy validation methods, including email-based validation. However, since this method is underspecified, we do not cover it in our models and advise against using any out-of-bound validation unless it is analyzed under a specific model.

ACME Protocol Functionality

In this chapter we focus on draft-1 of the IETF specification for the ACME protocol, which is as of October 2016 also the draft specification deployed in official Let's Encrypt client and server implementations. In part due to the issues we discuss in the work and have communicated with the ACME team, draft-3 (and subsequently draft-4) does away with some features, most notably Account Recovery and generally is resistant to the issues discussed here.

Preliminaries In some parts of ACME's protocol flow, C and A will need to establish a number of shared secrets, each bound to a strict protocol context, over their public keys. In ACME, this is accomplished using ANSI-X9.63-KDF:

1. C and A agree on a ECDH shared secret C Z A using their respective key pairs (C k , C pk ) and (A k , A pk ). A verifies that the public key of the key pair signing the request matches the public key in the certificate and that the key pair signing the request is an account key and the corresponding account is authorized to act for all of the identifier(s) in the certificate.

A hashing function C H

Given this description of the ACME protocol and the threat model defined in §4.2, we modeled ACME using the automated verification tool ProVerif [START_REF] Truderung | Using ProVerif to analyze protocols with Diffie-Hellman exponentiation[END_REF]. In our model, we involve three different candidates for C: Alice, Bob and Mallory and two CA candidates as A.

In our automated verification process, we consider an active attacker over the three channels specified in §4.2. As a result, we were able to find the issues discussed in §4.5. The first two are relatively minor; however, the third could lead to account compromise in the case of contact-based account recovery and potentially to the issuance of false certificate signatures if email-based domain validation were to be implemented in ACME. Furthermore, this third issue is also generalizable to affect traditional certificate authorities, as described in §4.1.

Model Processes

Using the modeling conventions we established in §4.2 which include channels, adversaries, actors and events, we instantiate in our ProVerif model of ACME a top-level process that executes the following processes in parallel:

• ClientAuth Run simultaneously by Alice, Bob and Mallory assuming the role of C (with a compromised Mallory), this process registers a new account with A and sends the queries illustrated in Figure 4.4. The events Owner and CertReceived are triggered as part of this process.

• ServerAuth Run simultaneously by two independent CAs assuming the role of A, this process accepts registrations from C and follows the protocol The processes RoutingP roxy, P oisonDnsARecord and M anInT heM iddleHttp, all described in §4.2, are also run in parallel with the above. Traditional CA dependence on weak channels gives us a threat model where real-world attacks can have a small cost and come with severe consequences.

Weaknesses in Traditional CAs

C Domain Owner V Attacker W CA Website E Mail Server CertRequest(C w , C pk ) CertRequest(C w , M pk ) EmailChallenge(C w , n) ReadEmail(C w , n) V alidate(C w , n) Cert(W, C w , M pk ) Install Cert(W, C w , M pk ) Read(Cert(W, C w , M pk ))

Email Validation

In ad-hoc CAs, C is generally simply sent an email containing a URI to their email inbox, which they're supposed to click in order to validate for their chosen domain. Figure 4.5 shows an attack rendered possible by this mechanism. A could instead, upon a validation request, redirect C's browser to a secret, nonce-based URI A U RI C served to C over the HTTPS channel and independently mail C the value HM AC(A hk , A U RI C ) for some secret A hk held by A. C would need to retrieve this second value and enter it inside the page at A U RI C . This approach would largely negate the weakness discussed in §4.5, since an attacker-induced validation email would result in an email that does not include a value matching the URI given by A to C at the beginning of the validation process.

Usage of Nonces

Traditional CAs use random nonces with no special cryptographic properties as the values that they then verify over HTTP, email or DNS. In addition to this helping caused the attack described above, another more general attack on nonces is shown in Figure 4.6 in the case of an active attacker. For example, this attack can be used by a compromised CA website to get certificates issued for domain C w by another (more reputable) CA, hence amplifying the compromise across CAs. None of these attacks would be effective if nonces were tied to some cryptographic properties, such as MACs or even just by deriving them from a hash of the certificate request's public key.

In order to avoid a similar attack, ACME draft-3 and draft-4 require that HTTP identifiers be validated by broadcasting

Sign(C k , A N C ) via the web server instead of ACME draft-1's (C pk , A N C ). D Secure DNS Server W CA Website V Attacker E Mail Server CertRequest(C w , C pk ) QueryM X(C w ) M ailServer(C w , M ) EmailChallenge(C w , n) V alidate(C w , n) Cert(W, C w , C pk

Weaknesses in ACME

Cross-CA Attacks on Certificate Issuance Suppose an ACME client C requests a certificate from A but A is malicious or the secure channel between A and C is compromised. Now, an attacker can intercept authorization and certificate requests from C to A, and instead forward them to another ACME server A . If A requests domain validation with a token T , the attacker forwards the token to the client, who will dutifully place its account key K and token T on its validation channel. A will check this token and accept the authorization and issue a certificate that the attacker can forward to C. This means that C asked for a certificate from A, but instead received a certificate from A . Moreover, it may have paid A for the service, but A might have done it for free. This issue, while not critical, can be prevented if C checks the certificate it gets to make sure it was issued by the expected CA. An alternative and possibly stronger, mitigation would be for ACME to extend the Key Authorization string to include the CAs identifier.

More generally, this issue reveals that ACME does not provide channel binding, and this appears as soon as we model the ACME HTTPS Channel. We would have expected to model this as a mutually-authenticated channel since the client always signs its messages with the account key. However, although the clients signature is tunnelled inside HTTPS, the signature itself is not bound to the HTTPS channel. This means that a message from an ACME client C to A can be forwarded by A to a different A (as long as C supports both A and A ). This kind of credential forwarding attack can be easily mitigated by channel binding. For example, ACME could rely on the Token Binding specifications to securely bind the client signature to the underlying channel. Alternatively, ACME could extend the signed request format to always include the servers name or certificate-hash, to ensure that the message cannot be forwarded to other servers.

Contact-Based Recovery Hijacking

While the use of sender-authenticated channels in ACME seems to be relatively secure, more attention needs to be paid to the receiver-authenticated channels. For example, if the ACME server uses the website administrator's email address to send the domain validation token, a naïve implementation of this kind of challenge would be vulnerable to attack.

In the current specification, the contact channel (typically email) is used for account recovery when the ACME client has forgotten its account key. We show how the careless use of this channel can be vulnerable to attack and propose a countermeasure. Suppose an ACME client C issues an account recovery request for an account under C pk with a new key C k to the ACME server A. A network attacker M blocks this request and instead sends his own account recovery request for the account under C pk (pretending to be C) with his own key M k . A will then send C an email asking to click on a link. C will think this is a request in response to its own account recovery request and will click on it. Similarly to the (slightly different) flow described in Figure 4.5, A will think that C has confirmed account recovery and will transfer the account under C pk to the attackers key M k . In the above attack, the attacker did not need to compromise the contact channel (or for that matter, the ACME channel).

The key observation here is that on receiver-authenticated channels (e.g. email) the receiver does not get to bind the token provided by A with its own account key. Consequently, we need to add a further check. The email sent from A to C should contain a fresh token in addition to Cs new account key. Instead of clicking on the link (out-of-band), C should cut and paste the token into the ACME client which can first check that the account key provided by A matches the one in the ACME client and only then does it send the token back to A, or alternatively that the email recipient at C visually confirms that the account key (thumbprint) provided by A matches the one displayed in the ACME client.

The attack described here is on account recovery, but a similar attack appears if we allow email-based domain validation. A malicious ACME server or manin-the-middle can then get certificate issued for C's domains with its own public key, without compromising the contact/validation channel. The mitigation for that attack would be very similar to the one proposed above.

Conclusion

In this work, we have provided the results of an empirical case study that allowed us to describe a real-world threat model governing both traditional certificate authorities and ACME in terms of user authentication and domain validation. We formally modeled these protocols and provided the results of security queries under our threat model, using automated verification. As a result of our disclosures to the ACME team, the latest ACME protocol version (draft-4) has been designed to avoid the pitfalls that make these attacks possible.

Given the weak threat model that traditional CAs are assuming for their domain validation process, we are not surprised by the regular occurrences of unauthorized certificate issuance (e.g. StartCom in 2008, Comodo and DigiNotar in 2011, WoSign in 2016). We advocate the CA/Browser forum to eventually mandate the use of ACME (or some other well-defined domain validation protocol that can be formally analyzed) to all certification authorities, as a long-term solution to reduce unauthorized certificate issuance. Until the issuance process for the whole PKI is unified, techniques to improve the validation of certificates such as certificate transparency [42] remain necessary to detect issuance failures and technologies such as DNSSEC [START_REF] Ateniese | A new approach to dns security (dnssec)[END_REF], DANE [START_REF] Hoffman | The dns-based authentication of named entities (dane) transport layer security (TLS) protocol: TLSA[END_REF], or SMTPS may help strengthen the channels involved in legacy domain validation.

Chapter 5

Formally Verified Secure Channel Implementations in Web Applications

The work in this chapter continues the research described in Chapters 1 and 2 and was published in the same proceedings as those previous chapters. It was completed with co-authors Karthikeyan Bhargavan and Bruno Blanchet, and would not have been possible without the gracious assistance of Antoine Delignat-Lavaud.

In Chapter 1, we employed automated formal verification in both the symbolic and computational models against popular secure messaging protocols. The same approach was followed in Chapter 2, where it was applied towards prototyping and formally verifying drafts of TLS 1.3 as the nascent protocol evolved. In this chapter, we present work that aims to extend our formal verification results from formal models and onto real-world implementations. We then want to produce a link between these implementations onto their basis in formal models. Our hope is that in doing so, we will be able to rule out common protocol implementation flaws such as nonce mismanagement or fundamental omissions such as missing message signatures or authentication codes.

Signal has been implemented in various programming languages, but most desktop implementations of Signal, including Cryptocat, are written in JavaScript. Although JavaScript is convenient for widespread deployability, it is not an ideal language for writing security-critical applications. Its permissive, loose typing allows for dangerous implementation bugs and provides little isolation between verified cryptographic protocol code and unverified third-party components. Rather than trying to verify general JavaScript programs, we advocate that security-critical components like SP should be written in a well-behaved subset that enables formal analysis.

We introduce ProScript (short for "Protocol Script"), a programming and verification framework tailored specifically for the implementation of crypto- graphic protocols. ProScript extends Defensive JavaScript (DJS) [START_REF] Bhargavan | Language-based defenses against untrusted browser origins[END_REF][START_REF] Bhargavan | Defensive JavaScript -building and verifying secure web components[END_REF], a static type system for JavaScript that was originally developed to protect security-critical code against untrusted code running in the same origin. Pro-Script is syntactically a subset of JavaScript, but it imposes a strong coding discipline that ensures that the resulting code is amenable to formal analysis. ProScript programs are mostly self-contained; they cannot call arbitrary third-party libraries, but are given access to carefully implemented (well-typed) libraries such as the ProScript cryptographic library (PSCL). Protocols written in ProScript can be type-checked and then automatically translated into an applied pi calculus [START_REF] Abadi | Mobile values, new names, and secure communication[END_REF] model using the ProScript compiler. The resulting model can be analyzed directly through ProVerif and can be adapted and extended to a proof in CryptoVerif. As the code evolves, this model can be automatically refreshed to enable new analyses and proofs, if necessary.

We advocate the verification approach depicted in Figure 5.1: A ProVerif model is automatically extracted from ProScript protocol code and analyzed for its security goals against a symbolic attacker. The model is then edited by hand and extended with cryptographic assumptions to build a computational proof that is verified by CryptoVerif. The messaging application is written in JavaScript and is broken down into a cryptographic protocol core and untrusted application code that interact through a small well-typed API that hides all protocol secrets within the protocol core and only offers a simple send/receive functionality to the application. Notably, the protocol core is written in a domain-specific language and does not rely on any external libraries except for a well-vetted cryptographic library. The protocol code can be translated to an applied pi calculus model and symbolically analyzed in ProVerif to find protocol flaws and attacks. The model can also be used as the starting point for a cryptographic proof for the protocol developed using CryptoVerif.

Contributions. This chapter builds upon the contributions of Chapter 1, which centered around formal verification, to extend them into contributions targeting robust real-world protocol implementations: To demonstrate that our security results apply to carefully-written implementations of TLS 1.3, we present RefTLS, the first reference implementation of TLS 1.0-1.3 whose core protocol code has been formally analyzed for security. RefTLS is written in Flow, a statically typed variant of JavaScript, and is structured so that all its protocol code is isolated in a single module that can be automatically translated to ProVerif and symbolically analyzed against our rich threat model.

ProScript: Prototyping Protocols with Formal Translations

ProScript aims to be an ideal language for reliably implementing cryptographic protocols for web applications. Using ProScript, a protocol designer or implementer can implement a protocol, automatically extract a formal model from the code, verify the model using ProVerif and then run the protocol code within a JavaScript web application. The ProScript framework does not target general JavaScript code, however existing applications can be adapted to use ProScript for their security-critical protocol components.

Our goal is to allow the developer to go back and forth between their protocol implementation and the ProVerif model, in order to help understand the behavior being illustrated, the properties being verified and how detected attacks, if any, relate to their source code. For these reasons, we pay special attention to generating models that are optimized both for verifiability as well as readability. This increases their utility to a human examiner who may wish to independently expand the model to include more specific process flows or to explore variations of the protocol against a manually defined adversary.

CHAPTER 5. SECURE CHANNEL PROTOCOL IMPLEMENTATIONS

Syntactically, ProScript is a subset of JavaScript that can be naturally translated to the applied pi calculus. This restriction produces casualties, including recursion, for loops and extensible objects. A closer look at the ProScript syntax shows JavaScript employed in a particular style to bring out useful features: Isolation. ProScript is based on Defensive JavaScript (DJS) [START_REF] Bhargavan | Language-based defenses against untrusted browser origins[END_REF][START_REF] Bhargavan | Defensive JavaScript -building and verifying secure web components[END_REF], a typed subset of JavaScript which focuses on protecting security-critical components from malicious JavaScript code running in the same environment. DJS imposes a strict typing discipline in order to eliminate language-based attacks like prototype poisoning. In particular, it forbids the use of unknown external libraries as well as calls to tamperable object methods such as .toString(). It also forbids extensible objects and arrays and prevents any access to object prototypes. These restrictions result in protocol implementations that are more robust and less influenced by the runtime environment. The ProScript typechecker builds on and extends DJS and hence, inherits both its language restrictions and isolation guarantees.

Type Declarations and Inference. ProScript requires all variables and functions to be declared before they are used, hence imposing a strict scoping discipline. For example, an expression v.x is well-typed if and only if v has been defined, as a local or global variable, to be an object with a property x. As an extension to the builtin types of DJS, ProScript allows type declarations for commonly used protocol data structures. For example, an array of 32 hexadecimal integers can be declared as a key type. The ProScript compiler recognizes such type declarations and uses them to translate the code into more concise and informative ProVerif models. Moreover, the typechecker can automatically infer fine-grained sub-types. For example, ProScript differentiates between numbers declared using decimal literals (eg. 128) and hexadecimal literals (eg. 0x80). Numbers defined using hexadecimal are sub-typed as bytes. This feature allows us to track how numerical values are employed in the protocol and prevents type coercion bugs similar to an actual bug that we describe in §5.2, where a significant loss of entropy was caused by a byte being coerced into a decimal value.

State-Passing Functional Style. ProScript's syntax takes advantage of JavaScript's functional programming features in order to encourage and facilitate purely functional protocol descriptions, which the compiler can translate into symbolically verifiable, human-readable models in the applied pi calculus. The functional style encourages the construction of state-passing functions, leaving state modification up to the unverified application outside of the ProScript code. The majority of a ProScript implementation tends to be a series of pure function declarations. A small subset of these functions is exposed to a global namespace for access by the verified application while most remain hidden as utility functions for purposes such as key derivation, decryption and so on. This state-passing style is in contrast to DJS that allows direct modification of heap data structures. The functional style of ProScript allows protocol data structures, including objects and arrays, to be translated to simple terms in ProVerif built using construc-

PROSCRIPT: PROTOTYPING PROTOCOLS WITH FORMAL TRANSLATIONS147

tors and destructors, hence avoiding the state-space explosion inherent in the heap-based approach that is needed to translate DJS to ProVerif [START_REF] Bhargavan | Defensive JavaScript -building and verifying secure web components[END_REF].

Protocol Implementation

To implement SP in ProScript, we must first deconstruct it into various protocol components: structures for managing keys and user states, messaging functions, APIs and top-level processes. ProScript is well-equipped to handle these protocol components in a way that lends itself to model extraction and verification. We break down our ProScript SP implementation into:

Types for State and Key Management. ProScript's type declaration syntax can be used to declare types for individual elements such as encryption keys but also for collections of elements such as a conversation party's state. These declarations allow for the construction of common data structures used in the protocol and also makes their management and modification easier in the extracted ProVerif models.

Messaging Interface. The ProScript implementation exposes the generic messaging API in a single global object. All interface access provides purely statepassing functionality.

Long-Term and Session States. Protocol functions take long-term and session states (S a , T ab n ) as input and return T ab n+1 . S a contains long-term values such identity keys, while T includes more session-dependent values such as ephemerals, containing the current ephemeral and chaining keys for the session context and status, indicating whether the application layer should perform a state update.

Internal Functions. Utility functionality, such as key derivation, can also be described as a series of pure functions that are not included in the globally accessible interface.

Top-Level Process.

A top-level process can serve as a harness for testing the proper functioning of the protocol in the application layer. Afterwards, when this top-level process is described in the extracted ProVerif model, the implementer will be able to use it to define which events and security properties to query for.

Inferred Types in ProScript. ProScript type declarations allow for the easier maintenance of a type-checkable protocol implementation, while also allowing the ProScript compiler to translate declared types into the extracted ProVerif model. Defining a key as an array of 32 bytes will allow the ProScript compiler to detect all 32 byte arrays in the implementation as keys and type their usage accordingly. Figure 5.4 shows the compiled output of the key derivation function implemented in the ProScript code. The compiler infers its input and output types through its usage elsewhere in the code and assigns a proper type in case one is declared. If no type is declared, the compiler will formalize constructors and destructors to deal with the values being passed.

Trusted Libraries for ProScript

Protocol implementations in ProScript rely on a few trusted libraries, in particular, for cryptographic primitives and for encoding and decoding protocol messages.

When deployed in Node.js or within a browser, the protocol code may have access to native cryptographic APIs. However, these APIs do not typically provide all modern cryptographic primitives; for example, the W3C Web Cryptography API does not support Curve25519, which is needed in Signal. Consequently, implementations like Signal Messenger end up compiling cryptographic primitives from C to JavaScript. Even if the desired primitives were available in the underlying platform, accessing them in a hostile environment is unsafe, since an attacker may have redefined them. Consequently, we developed our own libraries for cryptography and message encoding.

The ProScript Cryptography Library (PSCL) is a trusted cryptographic library implementing a variety of modern cryptographic primitives such as X25519, AES-CCM and BLAKE2. All of its primitives are fully type-checked without this affecting speed: in the majority of our benchmarks, PSCL is as fast as or faster than popular JavaScript cryptographic libraries like SJCL and MSR JavaScript Crypto, which do not even benefit from defensive type checking (Figure 5.2).

More crucially, PSCL functions used in ProScript code are detected by the

A VERIFIED PROTOCOL CORE FOR CRYPTOCAT 153

ProScript compiler as it produces the applied pi model of the implementation, giving it the ability to convert each call to a cryptographic primitive to a call to the corresponding symbolic function in ProVerif. For example, if the ProScript compiler sees a call to PSCL's X25519 implementation, it will automatically translate it to a standard Diffie-Hellman construction in ProVerif.

A Verified Protocol Core for Cryptocat

We now describe how we can rewrite Cryptocat to incorporate our ProScript implementation of SP. We deconstruct the Cryptocat JavaScript code into the following components, as advocated in Figure 5.1.

Cryptocat is a secure messaging application that is written in JavaScript and deployed as a desktop web application. Earlier versions of Cryptocat implement a variant of the OTR (Off-The-Record) messaging protocol [START_REF] Borisov | Off-the-record communication, or, why not to use PGP[END_REF] which suffers from several shortcomings. It does not support asynchronous messaging, so both peers have to be online to be able to message each other. It does not support multiple devices or encrypted file transfer. OTR also uses legacy cryptographic constructions like DSA signatures and prime-field Diffie-Hellman, which are slower and less secure than more modern alternatives based on elliptic curves. Furthermore, Cryptocat peers did not have long-term identities and so the authentication guarantees are weak. Early version of Cryptocat suffered from many high-profile implementation bugs, including the reuse of initialization vectors for file encryption [START_REF] Wilcox | Report of Security Audit of Cryptocat[END_REF], bad random number generation, and a classic JavaScript type flaw that resulted in a private key of 255 bits being coerced into a string that held only 55 bits. Some of these implementation flaws would have been found using a static type checker, others required deeper analysis.

Cryptocat was recently rewritten from scratch to upgrade both its messaging protocol and its implementation. The goal of this redesign was to isolate its protocol core and replace it with a verified messaging protocol written in a statically typed subset of JavaScript.

1. Unverified JavaScript Application This component, which comprises the majority of the code, manages the user's state, settings, notifications, graphical interface and so on. It is connected to the protocol only via the ability to call exposed protocol functions (as documented in § 1.1.1). We adopt certain assumptions regarding the unverified JavaScript application, for example that it will not modify the protocol state outside of passing it through the protocol implementation interface.

Verified Protocol Implementation

This component is written in Pro-Script and resides in a separate namespace, functioning in a purely statepassing fashion. Namely, it does not store any internal state or make direct network calls. This implementation is type-checked, and automatically verified every time it is modified.

Language-Based Isolation. Since ProScript is a subset of Defensive JavaScript, ProScript protocol code is isolated at the language level from other JavaScript code running within the same process, even if this code uses dangerous JavaScript features such as prototype access and modification. To ensure this isolation, Pro-Script code must not call any external (untyped) libraries.

Process Thread Isolation. We exploit features of Electron in order to isolate components of our application in different CPU threads as seen in Figure 5.3. When a message arrives on the network (1), the main network thread can only communicate with our Protocol TCB using a restrictive inter-process communication API. The TCB then uses its internal verified protocol functionality and state management to return a decryption of the message (3), which is then forwarded again via IPC to the chat window (4), a third separate CPU thread which handles message rendering. Furthermore, the TCB process is disallowed from loading any Node.js modules.

In particular, the network process is isolated from the chat media rendering process; neither ever obtain access to the key state or protocol functionality, which are all isolated in the ProScript protocol process. When Bob responds, a similar IPC chain of calls occurs in order to send his reply back to Alice [START_REF] Garman | Dancing on the lip of the volcano: Chosen ciphertext attacks on apple imessage[END_REF][START_REF] Borisov | Off-the-record communication, or, why not to use PGP[END_REF][START_REF] Bonneau | Finite State Security Analysis of OTR Version 2[END_REF][START_REF] Rösler | More is less: On the end-to-end security of group chats in signal, whatsapp, and threema[END_REF]. Even if an error in the rendering code or in the XML parser escalated into a remote takeover of the entire web renderer, the calls to the protocol TCB would be restricted to those exposed by the IPC API. However, these isolation techniques only protect the ProScript code within our application when executed within a correct runtime framework. None of these techniques can guard against bugs in V8, Node.js, or Electron, or against malicious or buggy Node.js or Electron modules loaded by the application.

Performance and Limitations

Although we have verified the core protocol code in Cryptocat and tried to isolate this code from unverified code, the following limitations still apply: we have not formally verified the soundness of the cryptographic primitives themselves, although writing them in Defensive JavaScript does provide type safety. We have also not formally verified the Electron framework's isolation code. Similarly, we do not claim any formal verification results on the V8 JavaScript runtime or on the Node.js runtime. Therefore, we rely on a number of basic assumptions regarding the soundness of these underlying components. Cryptocat's successful deployment provides a general guideline for building, formally verifying and isolating cryptographic protocol logic from the rest of the desktop runtime. Designing better methods for implementing and isolating security-critical components within Electron apps with a minimal TCB remains an open problem.

Despite the strong programming constraints imposed by our verification architecture, we find that Cryptocat is able to perform similarly to mainstream desktop messaging applications that do not offer end-to-end encryption, such as Skype. In order to benefit from automatic model translation of our Pro-Script protocol implementation (as described in §5.1.5), we use PSCL as our cryptography library, which allows us to easily handle even large file encryptions (200+MB) for Cryptocat's file sharing feature. Our application is available for Windows, Linux and Mac and currently serves over 20,000 users weekly. It is capable of handling multi-device provisioning for users with soft device revocation and device authentication. We also support video messaging, file sharing and similar usability features, which all exploit the isolation and formal verification methods described in this chapter.

RefTLS: a TLS 1.3 Implementation with a Verified Protocol Core

In today's web ecosystem, TLS is used by wide variety of client and server applications to establish secure channels across the Internet. For example, Node.js servers are written in JavaScript and can accept HTTPS connections using a Node's builtin https module that calls OpenSSL. Popular desktop applications, such as WhatsApp messenger, are also written in JavaScript using the Electron framework (which combines Node.js with the Chromium rendering engine); they connect to servers using the same https module.

Our goal is to develop a high-assurance reference implementation of TLS 1.3, called RefTLS, that can be seamlessly used by Electron apps and Node.js servers. We want our implementation to be small, easy to read and analyze and effective as an early experimental version of TLS 1.3 that real-world applications can use to help them transition to TLS 1.3, before it becomes available in mainstream libraries like OpenSSL. Crucially, we want to be able to verify the security of the core protocol code in RefTLS and show that it avoids both protocol-level attacks as well as implementation bugs in its protocol state machine.

In this section, we describe RefTLS and evaluate its progress towards these goals. RefTLS has been used as a prototype implementation of TLS Draft-13 to Draft-18, interoperating with other early TLS 1.3 libraries. Its protocol core has been symbolically analyzed with ProVerif and it has been successfully integrated into Electron applications.

Flow and ProScript

RefTLS is written in Flow [START_REF] Chaudhuri | Flow: Abstract interpretation of javascript for type checking and beyond[END_REF], a typed variant of JavaScript. Static typing in Flow guarantees the absence of a large class of classic JavaScript bugs, such as reading a missing field in an object. Consequently, our code looks very much like a program in a typed functional language like OCaml or F#. We would like to verify the security of all our Flow code, but since Flow is a fully-fledged programming language, it has loops, mutable state and many other features that are hard to automatically verify.

Earlier, we developed a typed subset of JavaScript called ProScript [START_REF] Bhargavan | Automated verification for secure messaging protocols and their implementations: A symbolic and computational approach[END_REF] that was designed for writing cryptographic protocol code that could be compiled automatically to ProVerif. ProScript is also a subset of Flow and so we can code in RefTLS, if we write it carefully.

For ease of analysis, ProScript disallows loops, recursion and only allows access mutable state through a well defined table interface. These are significant restrictions, but as we show, the resulting language is still expressive enough to write the core composite protocol code for TLS 1.0-1.3.

Implementation Structure

Figure 5.6 depicts the architecture of RefTLS and shows how it can be safely integrated into larger, unverified and untrusted applications. The library is written in Flow, a typed subset of JavaScript. The protocol core is verified by translation to ProVerif. The cryptographic library, message formatting and parsing and the runtime framework are trusted. The application and parts of the RefTLS library are untrusted (assumed to be adversarial in our model). At the top, we have Node.js and Electron applications written in JavaScript. RefTLS exposes an interface to these applications that exactly matches that of the default Node.js https module (which uses OpenSSL), allowing these applications to transparently use RefTLS instead of OpenSSL.

The RefTLS code itself is divided into untrusted Flow code that handles network connections and implements the API, a verified protocol module, written in ProScript and some trusted but unverified Flow code for parsing and serializing TLS messages. All this code is statically typechecked in Flow. The core protocol module, called RefTLS-CORE, implements all the cryptographic operations of the protocol. It exposes an interface that allows RefTLS to drive the protocol, but hides all keying material and sensitive session state within the core module. This isolation is currently implemented via the Node module system; but we can also exploit Electron's multi-threading feature in order to provide thread-based isolation to the RefTLS-CORE module, allowing it to only be accessed through a pre-defined RPC interface. Strong isolation for RefTLS-CORE allows us to verify it without relying on the correctness of the rest of the RefTLS codebase.

However, RefTLS still relies on the security and correctness of the crypto library and the underlying Electron, Node.js and JavaScript runtimes. In the future, we may be able to reduce this trusted computing base by relying on verified crypto [START_REF] Karim Zinzindohoue | A verified extensible library of elliptic curves[END_REF], verified JavaScript interpreters [START_REF] Bodin | A trusted mechanised javascript specification[END_REF] and least-privilege architectures, such as ESpectro [START_REF] Stefan | Espectro project description[END_REF], which can control access to dangerous libraries from JavaScript.

A Verified Protocol Core

In RefTLS-CORE, we develop, implement and verify (for the first time) a composite state machine for TLS 1.2 and 1.3. Each state transition is implemented by a ProScript function that processes a flight of incoming messages, changes the session state and produces a flight of outgoing messages. For TLS 1. [START_REF] Perrin | The X3DH key agreement protocol[END_REF] fore, even if the source syntax is the same, we may need to adapt our compiler to generate different models for ProVerif and CryptoVerif.

SentClientHello(k 0 c ) ReceivedServerHello(modeS[v, kex], k h c , k h s ) (TLS 1.

RefTLS Protocol State Machines

Client. The RefTLS client implements the composite state machine shown in Figure 5.8 for TLS 1.3 and TLS 1.2. Each state represents a point in the protocol where the client is either waiting for a flight of handshake messages from the server, or it has new session keys that it wishes to communicate to the record layer. Each arrow is annotated with the name of the function in RefTLS-CORE API that implements the corresponding state transition. Each transition may involve processing a flight of incoming messages, changing the session state and producing a flight of outgoing messages. Server. The RefTLS server implements a dual state machine for TLS 1.3 and TLS 1.2, as depicted in Figure 5.9. The server decides which protocol version and key exchange the handshake will use, and triggers the appropriate branch in the state machine by sending a ServerHello. Like the client, each of its state transition functions corresponds either to a flight of messages or to a change of keys. The full RefTLS codebase consists of about 6500 lines of Flow code, including 3000 lines of trusted libraries (mostly message parsing), 2500 lines of untrusted application code and 1000 lines of verified protocol core. From the core, we extracted an 800 line protocol model in ProVerif and composed it with our generic library from §2.1. Verifying this model took several hours on a powerful workstation.

RefTLS implements TLS 1.0-1.3 and interoperates with all major TLS libraries for TLS 1.0-1.2. Fewer libraries currently implement TLS 1.3, but RefTLS participated in the IETF Hackathon and achieved interoperability with other implementations of Draft-14. It now interoperates with NSS (Firefox) and BoringSSL (Chrome) for Draft-18.

By implementing Node's https interface, we are able to naturally integrate RefTLS within any Node or Electron application. We demonstrate the utility of this approach by integrating RefTLS into the Brave web browser, which is written in Electron. We are able to intercept all of Brave's HTTPS requests and reliably fulfill them through RefTLS.

We benchmarked RefTLS against Node.js's default OpenSSL-based HTTPS stack when run against an OpenSSL peer over TLS 1.2. Our results are shown in Figure 5.7. In terms of computational overhead, RefTLS is two times slower than Node's native library, which is not surprising since RefTLS is written in JavaScript, whereas OpenSSL is written in C. In exchange for speed, RefTLS offers an early implementation of TLS 1.3 and a verified protocol core. Furthermore, in many application scenarios, network latency dominates over crypto, so the performance penalty of RefTLS may not be that noticeable.

Conclusion and Related Work

There have been previous attempts [START_REF] Avalle | The Java SPI framework for security protocol implementation[END_REF] to extract ProVerif models from typed JavaScript, such as DJS2PV [START_REF] Bhargavan | Defensive JavaScript -building and verifying secure web components[END_REF]. However, DJS2PV was only tested on small code examples: attempting to translate a complete implementation such as Sig-

CONCLUSION AND RELATED WORK

163

nal Protocol resulted in a 3,800 line model that attempts to precisely account for the heap, but could not verify due to an exploding state space. Previous efforts such as FS2PV [START_REF] Bhargavan | Verified interoperable implementations of security protocols[END_REF] avoided this problem by choosing a purely functional source language that translated to simpler pi calculus scripts. We adopt their approach in ProScript to generate briefer, more readable models.

TypeScript [START_REF] Bierman | Understanding Type-Script[END_REF], Flow [START_REF] Chaudhuri | Flow: Abstract interpretation of javascript for type checking and beyond[END_REF], Defensive JavaScript and TS* [START_REF] Fournet | Fully abstract compilation to JavaScript[END_REF] all define type systems that can improve the security of JavaScript programs. The type system in ProScript primarily serves to isolate protocol code from untrusted application and to identify a subset of JavaScript that can be translated to verifiable models. More recently, ESVerify2 provides a subset of JavaScript that allows for implementing program verification logic within the syntax itself, which is then separately parsed with an SMT solver but avoids trigger heuristics and thereby (most) timeouts and other unpredictable results by requiring manual instantiation.

Tools like WebSpi [START_REF] Bansal | Discovering concrete attacks on website authorization by formal analysis[END_REF] and AuthScan [START_REF] Bai | AUTHSCAN: automatic extraction of web authentication protocols from implementations[END_REF] have been used to verify the security of web security protocols such as OAuth. An expressive web security model has also been used to build manual proofs for cryptographic web protocols such as BrowserID [START_REF] Fett | An expressive model for the web infrastructure: Definition and application to the browser id sso system[END_REF]. These works are orthogonal to ProScript and their ideas can potentially be used to improve our target ProVerif models.

We plan to continue to develop and refine ProScript by evaluating how it is used by protocol designers, in the spirit of an open source project. All the code and models presented as part of this work are available online [START_REF] Kobeissi | SP code repository[END_REF]. Proving the soundness of translation from ProScript to ProVerif, by relating the source JavaScript semantics to the applied pi calculus, remains future work. The process of transforming the compiled model to a verified CryptoVerif script remains a manual task, but we hope to automate this step further, based on new and upcoming developments in CryptoVerif.

Finally, a word of caution: a protocol written in ProScript and verified with ProVerif or CryptoVerif does not immediately benefit from assurance against all possible attacks. Programming in ProScript imposes a strict discipline by requiring defensive self-contained code that is statically typed and can be translated to a verifiable model and subsequent verification can be used to eliminate certain well-defined classes of attacks. We believe these checks can add confidence to the correctness of a web application, but they do not imply the absence of security bugs, since we still have a large trusted computing base. Consequently, improving the robustness and security guarantees of runtime frameworks such as Electron, Node.js and Chromium, remains an important area of future research.

Chapter 6

Formally Verified Secure Collaborative Document Editing

This work was completed shortly before the submission of the final draft of this thesis and is currently under peer review. It has received feedback from various sources, most notably the Security and Privacy Engineering Lab and the Decentralized and Distributed Systems Lab at the École Polytechnique Fédérale de Lausanne, who were gracious enough to invite me to present it in 2018.

Collaborative document editing software such as Google Docs and Microsoft Office365 has become indispensable in today's work environment. In spite of no confidentiality guarantees, large working groups still find themselves depending on these services even for drafting sensitive documents. Peer pressure, a rush to agree on a working solution and the sheer lack of alternatives have created an ecosystem where a majority of sensitive drafting is currently conducted with no end-to-end encryption guarantees whatsoever. Google and Microsoft servers have full access to all documents being collaborated upon and so do any parties with read access to the internal databases used by these services.

Capsule aims to solve this problem by being the first formally specified and formally verified protocol for secure collaborative document editing. Capsule comes with security goals that are validated in the symbolic model using the ProVerif [START_REF] Cheval | Proving more observational equivalences with ProVerif[END_REF] automated protocol verifier. It is also presented with a full client and server implementation, published as open source software.

We note that Capsule does not target the much simpler problem of encrypting cloud documents that are at rest, such as files stored on Google Drive on Microsoft OneDrive. Rather, the Capsule Protocol targets files being actively, collaboratively edited in real time.

Capsule's more involved use case scenario is responsible for providing a class of security guarantees vaguely resembling that of group secure messaging but without a need for forward secrecy. Another element that Capsule has to deal 166 CHAPTER 6. SECURE COLLABORATIVE DOCUMENT EDITING with is allowing the management of a document's incremental history with a server that cannot read the document's contents. This is accomplished by storing the document as an authenticated hash chain of encrypted, signed diffs: when a new participant joins a Capsule document, they pull the entire document hash chain, decrypting and parsing every diff until the entire document is reconstructed. Once within the document, each participant pushes and pulls encrypted diff blocks into this hash chain. Utilizing a hash chain also makes it more difficult for the server to provide differing document histories to participants, without forking the hash chain entirely and with little payoff.

Capsule uses symmetric encryption to guarantee document confidentiality and integrity. Cryptographic signatures are used for authentication, although we employ only ephemeral authentication since identities are valid for the lifetime of the document. Symmetric primitives are also used for generating a proof value that disallows the server from adding non-existent participants to the document, in spite of these fake participants already being unable to access any document plaintext.

To the best of our knowledge, the only prior existing work regarding collaborative document encryption is CryptPad [START_REF]CryptPad: Zero Knowledge, Collaborative Real Time Editing[END_REF], an open source web client. Crypt-Pad shares similarities with Capsule especially in that both use a hash chain of encrypted diffs in order to manage document collaboration and to reconstruct the document. However, CryptPad adopts a more relaxed threat model of an "honest but curious cloud server" and does not appear to guard against a server interfering with the document's list of participants or its history. Meanwhile, Capsule explicitly guards against a server injecting false participants by requiring a certain proof from all participants. CryptPad's software implementation is also limited within a web browser and unlike Capsule's, does not employ formally verified cryptographic primitives.

Security Goals and Threat Model

Capsule aims to guarantee the following security goals. In the following, a valid participant is any entity with access to the Capsule collaborative document's shared master secret. This master secret is generated upon document creation and is shared manually by the document creator in order to allow access to the document.

• Participant List Integrity. Only participants with access to the Capsule collaborative document's shared master secret may appear as valid entries on the participant list. Illegitimate entries injected by the server or any other parties must be detectable by valid participants.

• Confidentiality. Any changes made to a collaborative document may only be viewed by valid participants.

• Integrity. Encrypted diffs that are appended to the Capsule document's hash chain by a particular author cannot be tampered with by any other 6.2. PRIMITIVES 167 party.

• Transcript Consistency. A malicious server cannot selectively omit changes to the collaborative document short of entirely forking the hash chain. Furthermore, in no scenario may a malicious server maliciously append changes to the collaborative document.

Capsule assumes the following threat model, which is fairly standard for protocols aiming to provide end-to-end security:

• Untrusted Network. We assume that an attacker controls the network and so can intercept, tamper with and inject network messages.

• Malicious Server. We assume that a Capsule server may be potentially interested in misleading users with regards to the document's history and in the apparent list of identities participating in a collaborative document editing session.

Primitives

In designing the Capsule protocol, we wanted to focus on obtaining the smallest attack surface possible on an architectural cryptographic level. This is why our low-level cryptographic operations comprise of a restricted subset that is simple to illustrate. The practical details of which cipher suites are chosen to satisfy the security goals of these primitives is discussed in §6.5.2.

• Hashing. HASH(x) -→ y. A standard one-way cryptographic hash function.

• Hash-Based Key Derivation. HKDF(k, salt) -→ (k 0 , k 1 , k 2 , k 3 ). HKDF functions [START_REF] Krawczyk | Cryptographic extraction and key derivation: The HKDF scheme[END_REF] are proven to be pseudorandom functions under a random oracle model, which is useful for aspects of Capsule's protocol design.

• Encryption and Decryption.

-Encryption. BENC(ek, mk, p) -→ (ENC p , n). Where ek is an encryption key and mk is an authentication key. An authentication tag is generated, as is typical with authenticated symmetric ciphers.

-Decryption. BDEC(ek, mk, ENC p , n) -→ {p, ⊥} depending on whether decryption can be authenticated.

• Signatures.

-Key Generation. EDGEN(sk) -→ pk.

-Signing. EDSIGN(sk, x) -→ SIG x .

-Signature Verification. EDVERIF(pk, x, sig x ) -→ { , ⊥} depending on whether signature verification succeeds.

ready for use in this kind of real-world system, the other clear potential solution seemed to be an encrypted, append-only authenticated log of diff information. We construct such a data structure and call it DiffChain. Pulling a DiffChain to reconstruct a collaborative document upon joining it is very similar to pulling the Bitcoin blockchain and parsing it in order to reconstruct the currency's current value and activity by going through all transactions since the original block. A DiffChain block contains the following data:

• Sender's Identity and Public Keys.

• Encrypted Diff. Alice generates this encrypted diff using BENC(V ek , V mk , diff).

• Hash of Previous Block. This is a standard element in hash chain constructions.

• ID of Current Block. This is conventionally a UNIX timestamp. It is appended by the server.

• ID of Previous Block. This allows for faster lookups.

• Signature. All of the above fields are included in a single signature, with the exception of the ID of the current block since it is appended by the server.

Responsible pushing and pulling. As a rule, clients should not push any new blocks before obtaining confirmation from the server that their local diff state is current. This will help avoid merge conflicts.

Diffing algorithm. The Capsule library comes equipped with an efficient diff generation algorithm that features a JSON-compatible syntax for compatibility. Independent implementations are free to adapt their own diff payload representations, as this does not strictly affect the security or operation of the cryptographic protocol itself.

Protocol Variant: Unauthenticated Encryption

We observe that if all participants accept ciphertexts signed only by identities with a valid XV pv value for any participant X, then the authentication component of the ENC becomes redundant. This observation allows potentially replacing ENC with a unauthenticated encryption cipher, which could lead to improved performance.

Here is our argument for this: we assume that all clients are honest. We assume that HMAC is a one-way keyed hash function, that V k is secret and that AV pk is authenticated as a public signing identity belonging to A:

• If value AV pv is validated, this proves that generator A must possess V sp .

• Given that V k is secret, ownership of V sp in turn proves that A must possess V k .

• At no point in a correct execution of the protocol are the values (V ek , V mk , V sp ) leaked by any participant.

• V k maps into (V ek , V mk , V sp , V id ). Therefore, proving ownership of V sp under a secret V k is equivalent to proving ownership of (V ek , V mk , V sp , V id ). This satisfies the original purpose of validating the proof of participation value.

• A cannot produce AV pv without also being able to produce (V ek , V mk ). Since signature verification disallows tampering, any unauthenticated ciphertext encrypted under V ek and signed by A is equivalent to a ciphertext encrypted under V ek , authenticated using V mk and signed by A.

Symbolic Verification with ProVerif

We describe Capsule using the applied pi-calculus and, using the ProVerif symbolic protocol verifier, verify that the Capsule protocol meets its security goals under its proposed threat model. In the symbolic model, cryptographic primitives are logically perfect black boxes: hash functions are one-way mappings, encryption functions are permutations, random values are unique and perfectly indistinguishable. Processes can then be executed in parallel. In this setting, a Dolev-Yao [START_REF] Syverson | Dolev-Yao is no better than machiavelli[END_REF] active attacker exists and attempts to reconstruct inputs and outputs in such a way as to reach goals defined by queries and events.

Capsule Processes in ProVerif

In ProVerif, we describe a single public channel, pub, intending to represent regular Internet network exchanges. Then, two types of client processes are described. We illustrate them here in an abbreviated format. 3 ediff0, ediff0sig

) ))).

Attacker and Top-level Processes

Before declaring the top-level process, we must declare a process where the attacker attempts to obtain the plaintext for any diff: let attackerTryingToObtainPlaintext() = in(pub, x:plaintext); if (issecretdiff(x) = true) then ( event PlaintextObtainedByAttacker(x) ). Now, we can finally declare the top-level process. We model an unbounded number of sessions, each with a new V k and its own unbounded instantiations of reader and writer principals with their own unique signing key pairs.

Security Goals in the Symbolic Model

We apply ourselves on the security goals described in §6.1 in order to model and verify participant list integrity, confidentiality, integrity and ephemeral authentication in ProVerif. 4of operations. In effect, this ensures that secret-manipulating code is branchfree and cannot access memory using a secret index. This helps rule out classic timing and cache attacks.

Once verified, Low* programs can be compiled to low-level targets using the Kremlin [START_REF] Wang | Extracting from F* to C: a progress report[END_REF] compiler, which currently supports C and WASM as backends. Compared to Emscripten, the Kremlin compiler offers a much smaller trusted computing base, smaller resulting WASM files and almost no dependencies on untrusted code, such as a libc implementation.

Conclusion

In this chapter, we have presented Capsule, the first formally verified protocol for secure collaborative document editing. We believe Capsule will address an important need in the space of privacy enhancing technologies. We have provided a full description of the Capsule protocol and symbolic verification results for its security goals under the specified threat model.

Finally, we also provide Capsulib, a reference implementation of Capsule based on modern web technologies. While Capsulib is built for web use, it is also the first software project to employ the HACL* formally verified cryptographic library by translating it into WASM. By adopting such technologies, Capsule protocol is able to be presented complete with a practical implementation that follows best practices and achieves sound practical security in deployment.

Conclusion

Instead of repeating the research conclusions of the preceding chapters in a rote dry and useless way that assuredly nobody will read or enjoy reading, it is likely more useful to conclude this thesis with the broad lessons that I as a student have been able to glean during the time I've spent working on this thesis.

On the bright side, the repeated conventional notion that formal methods are too isolated to have any real meaning to contribute to real world protocols being used by millions of people on smartphones is, apparently, proven wrong by the work presented in this thesis. We have been able to show, repeatedly, that modeling the most ambitious, widely deployed and important secure channel protocols can be done methodically and predictably with existing symbolic and computational verification tools.

In the case of the Noise Protocol Framework, we were able to go beyond that and even allow end-users access to an easy-to-use web interface where they can type out their own Noise Protocol Handshake designs and immediately obtain validation and formal model generation for the protocol they've just described. Then, we showed that the results of that formal model's analysis can be viewed and examined in an equally accessible and easy to understand way. This is why Noise Explorer was my favorite project in this thesis, since I was able to implement my initial vision for the sort of result I wanted in this type of research ever since I began my thesis.

Work of the sort that was done for Noise Explorer may very well be superseded by more rigorous computational models simulating game-based proofs. F implementations of TLS have already been under way for years and will very obviously be followed with similar implementations for Signal, the Noise Protocol Framework and everything else under the sun.

If frameworks such as F are to indeed be the uncontested future, however, they must overcome current ease of use, accessibility and stability hurdles that preclude their usefulness to the average cryptography engineer and protocol designer. As of the date that this thesis was submitted, F faces considerable usability barriers likely to be encountered by everyone except its co-creators and a small number of specialists. This is due to a constantly evolving toolchain as well as constantly changing fundamental types, data structures and language syntax, without an underlying namespacing convention to tie everything together. Luckily, these are all limitations that can easily be addressed with enough time and doubtlessly will be. The underlying result, at that stage, is likely to be a huge 180 CHAPTER 6. CONCLUSION leap in how safe programs are written and how safe protocols are deployed.

In that sense, this thesis has nothing to offer in the way of leaps and bounds. It is more appropriately seen as a bridge for testing, and in most cases justifying, the reaches of formal verification into real-world cryptography. Its impact can be measured more romantically by it resulting in the first full-featured secure messenger client with a formally verified protocol core. More practically, however, the fact that we were able to automatically verify TLS 1.3 drafts as they were being released is a much larger impact. This was followed by a framework where any arbitrary protocol described in a certain style (i.e. the Noise Protocol Framework) could equally be prototyped and verified. Our results on this latter front led to a more rigorous approach to the design of the Noise Protocol Framework as a whole and to the evaluation of all the secure channel protocols that are coming out of it.

This thesis ends with chapter describing a novel protocol targeting an underserved use case. We present that protocol immediately with formal models that both illustrate the design and justify its soundness under the simulation of a real-world network attacker. The sentence that this final chapter punctuates is: "Can existing major paradigms for formal protocol verification serve as guidelines for the assessment of existing protocols, the prototyping of protocols being designed, and the conception of entirely new protocols, in a way that is meaningful and reflective of their expected real-world properties? And can we develop novel frameworks for formal verification and more secure implementation based on these foundations?" While no multi-chaptered body of research can responsibly end with a definitive answer, my belief is that this thesis has managed to constitute perhaps the most resounding "yes" yet, and that it will serve as motivation and encouragement for a fount of future work to bring verification and implementation ever closer together. True(E) E / ∈ {0, "", null, undefined}

False(E) E ∈ {0, "", null, undefined} obj(l, l ) (l, @proto) → l fun(F, Closure, V ar, Body, P roto)

A.1. PROSCRIPT OPERATIONAL SEMANTICS 197 (F, @scope) → Closure * (F, @body) → λV ar.Body * (F, prototype) → P roto * (F, @proto) act(l, x, v, e, l ) l → {x : v, @this : l , @proto : null} * defs(x, l, e)

Local Variable Definition.

  Figure 1: An example Noise Handshake Pattern, IK.

3 (

 3 Chapter 2), the Noise Protocol 20 CHAPTER 0. INTRODUCTION Framework (Chapter 3) and ACME (Chapter 4).

Figure 3 :

 3 Figure 3: ProVerif's structure, as described by a 2016 technical report on ProVerif [48].

Figure 4 :

 4 Figure 4: ProVerif syntax, based on the applied pi-calculus.

Figure 1 . 1 :

 11 Figure 1.1: Telegram's MTProto Protocol for Secret Chats.

Figure 1 . 2 :

 12 Figure 1.2: SP, a variant of Signal with minor differences. Alice requests a signed pre-key from Bob (via the server) and sends an initial message M 0 . Bob accomplishes his side of the key exchange and obtains M 0 . Bob later sends his reply M 1 , illustrating the Axolotl ratchet post-AKE. We ignore the hash-based ratchet that occurs when two consecutive messages are sent in the same direction. c i refers to various constants found throughout the protocol.

Figure 1 . 3 :

 13 Figure 1.3: Verification times for SP ProVerif models.

CHAPTER 2 .

 2 TRANSPORT LAYER SECURITY Client C Server S Long-term Keys: (sk C , pk C ) Long-term Keys: (sk S , pk S )

  7 ) cid = ems or psk or hash(log 7 ) Computes: psk = kdf psk (ms, log 7 ) cid = ems or psk or hash(log 7 ) New client session: C = C cid → (offer C , mode S , pk C , pk S , k c , k s , ems, psk ) New server session: S = S cid → (offer C , mode S , pk C , pk S , k c , k s , ems, psk ) enc kc (Data(m 1 )) enc ks (Data(m 2 )) Application Data Stream: C cid ←→ S : m 1 , m 2 , . . . Application Data Stream: C cid ←→ S : m 1 , m 2 , . . .

Figure 2 . 2 :

 22 Figure 2.2: TLS 1.3 Draft-18 1-RTT Protocol. The protocol uses an (EC)DHE key exchange with server certificate authentication: client authentication and the RetryRequest negotiation steps are optional.

Figure 2 . 3 :

 23 Figure 2.3: A Model of Diffie-Hellman in ProVerif that allows the weak groups and allows elements in small subgroups.

Figure 2 . 4 :

 24 Figure 2.4: TLS 1.2 (EC)DHE handshake, no client authentication.

Figure 2 . 5 :

 25 Figure 2.5: TLS 1.3 Draft-18 Key Schedule. The hash function hash() is typically SHA-256, which has length len hash() = 32 bytes.

2. 3

 3 . 0-RTT WITH SEMI-STATIC DIFFIE-HELLMAN 77 C S Knows (sk C , pk S ) Knows (sk S , pk S ), (s, g s )

  psk ) enc kc (Data(m 1 )) Application Data Stream: C cid ←→ S : m 0 , m 1 , . . . Application Data Stream: C cid ←→ S : m 0 , m 1 , . . .

Figure 2 . 6 :

 26 Figure 2.6: DH-based 0-RTT in TLS 1.3 Draft-12, inspired by QUIC and OPTLS.

CHAPTER 2 .

 2 TRANSPORT LAYER SECURITY Client C Server S Knows (sk C , pk C ), (psk, enc kt (psk)) Knows (sk S , pk S ), k t Generates x and computes: es, k b = kdf es (psk)

Figure 2 . 7 :

 27 Figure 2.7: TLS 1.3 Draft-18 PSK-based Resumption and 0-RTT.

CHAPTER 2 .ats c ats s psk ats c ats s ets c psk updated ts Figure 2 . 8 :

 2ts28 Figure 2.8: Structure of the CryptoVerif proof

Figure 2 . 9 :

 29 Figure 2.9: Model of the initial 1-RTT handshake

Figure B. 1 ;

 1 • using the secret key s_cets3 as traffic secret in the process Rec 0-RTT,Bad m for 0-RTT when the ClientHello message has been altered: the receiver process is plugged after event ServerEarlyTerm2 at line 5: in Figure B.1.

Figure 3

 3 Figure 3.1: An example Noise Handshake Pattern, IK.

  Figure 3.2: An example Noise Handshake Pattern, IN.

2

 2 DH and KP (implemented as generate_keypair) are then implemented as letfuns on top of that construction: 3 fun dhexp(key, key):key. equation forall a:key, b:key; dhexp(b, dhexp(a, g)) = dhexp(a, dhexp(b, g)).

  fun encrypt(key, nonce, bitstring, bitstring):bitstring. fun decrypt(key, nonce, bitstring, bitstring):aead reduc forall k:key, n:nonce, ad:bitstring, plaintext:bitstring; decrypt(k, n, ad, encrypt(k, n, ad, plaintext)) = aeadpack(true, ad, plaintext ).

Figure 3 . 3 :

 33 Figure 3.3: Noise Handshake Pattern Syntax.

CHAPTER 3 .

 3 NOISE PROTOCOL FRAMEWORK Validity Rules d ::=| direction t ::= k d | k 1 k 2 | psk tokens w. DH keys Γ ::= { t0 , . . . , tn } context tokens d (m) {k d | k ∈ m ∩ {e, s}} ∪ (m \ {e, s}) Pre-Message Validity: Γ d p PreEmpty Γ d PreKey

Figure 3 . 4 :A

 34 Figure 3.4: Noise Pattern Validity Rules

  letfun encryptWithAd(cs:cipherstate, ad:bitstring, plaintext:bitstring) = let (k:key, n:nonce) = cipherstateunpack(cs) in let e = encrypt(k, n, ad, plaintext) in let csi = setNonce(cs, increment_nonce(n)) in (csi, e). letfun decryptWithAd(cs:cipherstate, ad:bitstring, ciphertext:bitstring) = let (k:key, n:nonce) = cipherstateunpack(cs) in let d = decrypt(k, n, ad, ciphertext) in let (valid:bool, adi:bitstring, plaintext:bitstring) = aeadunpack(d) in let csi = setNonce(cs, increment_nonce(n)) in (csi, plaintext, valid). letfun reKey(cs:cipherstate) = let (k:key, n:nonce) = cipherstateunpack(cs) in let ki = encrypt(k, maxnonce, empty, zero) in cipherstatepack(bit2key(ki), n).

Figure 3 . 5 :

 35 Figure 3.5: The WriteMessage and ReadMessage letfun constructions for the first message in IK (Fig. 3.1), generated according to translation rules from Noise Handshake Pattern to ProVerif. The appropriate state transition functions are invoked in accordance with the occurence and ordering of tokens in the message pattern.

1 .

 1 Figure 3.6: An example Noise Handshake Pattern, I1K. This is a deferred pattern based on IK, shown in Fig. 3.1. The Noise Protocol Framework specification defines 15 "fundamental patterns", 23 "deferred patterns" and 21 "PSK patterns". IK (Fig. 3.1) and IN (Fig. 3.2) are two fundamental patterns. Deferred patterns are essentially modified fundamental patterns where the communication of public keys or the occurence of Diffie-Hellman operations is intentionally delayed. PSK pattterns are patterns in which a pre-shared key token appears. Fig. 3.6 illustrates a deferred pattern based on the fundamental pattern shown in Fig. 3.1.

Figure 3 . 7 :

 37 Figure 3.7: Verification results for 50 Noise Handshake Patterns. The numbers in the Authentication and Confidentiality column represent the obtained score for each message, starting from the first message in the Handshake Pattern concerned.

123

 123

1

  https://www.netcraft.com/internet-data-mining/ssl-survey/ 4.1. CURRENT STATE OF DOMAIN VALIDATION 129 DNS resolution of the validated domain's A/A6 records and an untampered HTTP connection to the domain.

Figure 4

 4

Figure 4 . 2 :

 42 Figure 4.2: Provider repartition among the Alexa Top 10,000 global sites, as of October 2016. Notably, CloudFlare and Akamai also provide CDN services to domains under their name servers, allowing them stronger control over HTTP traffic.

Figure 4 . 3 :

 43 Figure 4.3: Channels overview.

Figure 4 . 4 :

 44 Figure 4.4: ACME draft-1 protocol functionality for C account registration, recovery key generation, and validation with certificate issuance for C w . This chart demonstrates validation via an HTTP identifier. In draft-3 and above, the HTTP challenge (C pk , A N C ) is replaced with Sign(C k , (C pk , A N C )).

4. 4 .

 4 WEAKNESSES IN TRADITIONAL CAS 139 illustrated in Figure 4.4. The events HttpAuthenticated and CertIssued are triggered as part of this process.

Figure 4 . 5 :

 45 Figure 4.5: Attack on Email Validation: Concurrent Request by Active Adversary.

Figure 4 . 6 :

 46 Figure 4.6: Active attack on DNS/HTTP/Email Validation when using just nonces.

Figure 4 . 7 :

 47 Figure 4.7: Attack on Email Validation: Passive Adversary on Email Channel

Figure 5 . 1 :

 51 Figure 5.1: Verification Approach.

Figure 5 . 2 :

 52 Figure 5.2: ProScript Crypto Library (PSCL) benchmarked against leading JavaScript cryptographic libraries: Stanford JavaScript Crypto Library (SJCL) and Microsoft Research Crypto Library (MSRCrypto). Each SHA256 iteration hashes 16 blocks.

Figure 5 . 8 :

 58 Figure 5.8: Client state machine

Figure 5 . 9 :

 59 Figure 5.9: Server state machine

Figure 6 . 1 :

 61 Figure 6.1: Capsule protocol session network messages. Here, A initiates a session with S and then communicates session key V k and her own fingerprint AV f p to B out of band. After B joins and all checks pass, A commits an example encrypted diff, diff 0 and B follows up with an example diff diff 1 . More involved sessions can include clients C, D, etc. with a non-deterministic diff commit schedule.

  π(H, l, x) l (l, x) / ∈ dom(H) H(l, @proto) = l π(H, l, x) π(H, l , x)Dereferencing Values: γ(H, r). r = l•x γ(H, r) r π(H, l, x) = null l = null γ(H, l•x) undefined π(H, l, x) = l l = null γ(H, l•x) H(l , x)Auxiliary Predicates.

1 

 1 x = y defs(x, l, var y) (l, y) → undefined defs(x, l, e1 = e2) defs(x, l, e1)defs(x, l, e1;e2) defs(x, l, e1) ∪ defs(x, l, e2) defs(x, l, if(e1){e2}{e3}) defs(x, l, e2) ∪ defs(x, l, e3)otherwise defs(x, l, e) emp Syntax of Terms: v, e. :e 1 ...x n :e n } e[e]  Operational Semantics: H, L, e -→ H , r. Definition H, L, (varconst) x -→ H, undefined Value H, L, v -→ H, v MemberAccess H, L, e -→ H , l γ(H , l •x) = v H, L, e.x -→ H , v Variable σ(H, L, x) = l γ(H, l •x) = v H, L, x -→ H, vObject H 0 = H * obj(l , l op ) ∀i ∈ 1..

log 4 log 4 Figure B. 2 :Figure B. 3 :

 423 Figure B.2: Unknown Key Share (UKS) Attack in QUIC, OPTLS and on TLS 1.3 Draft-12 if the server's certificate is not added to log 1 . The figure shows how a man-in-the-middle can exploit the UKS to mount a credential forwarding attack on 0-RTT client authentication. This attack led to the inclusion of Certificate and ServerConfig in the 0-RTT handshake hash in Draft-7.

Development Cycle. Human

	Goals	Parties	Running Time
	Forward Secrecy A, B, M 3 min. 58 sec.
	Forward Secrecy A, M	7 min. 04 sec.
	KCI	A, B, M 3 min. 15 sec.
	Others	A, B, M 4 min. 15 sec.
	Others	A, M	3 min. 35 sec.
			-
	readability of the automatically compiled ProVerif model is key to our verifica-
	tion methodology. In the case of a query failure, users can opt to modify their
	implementation and recompile into a new model, or they can immediately modify

Figure 1.4: Verification times for SP CryptoVerif models, without anti-replay countermeasure. The runtimes with the anti-replay coun- termeasure are of the same order of magnitude. Tested using Cryp- toVerif 1.24.

	the model itself and re-test for security queries within reasonable model verifi-
	cation times. For example, if an implementer wants to test the robustness of
	a passing forward secrecy query, they can disable the signature verification of
	signed pre-keys by changing a single line in the model, causing the client to
	accept any pre-key signature.

  Knows (sk C , pk C ), psk Knows (sk S , pk S ), psk Negotiation (offer C , mode S )Authenticated Key Exchange (cid, k c , k s , psk ) New client session: C = C cid → (offer C , mode S , pk C , pk S , psk, k c , k s , psk )New server session:S = S cid → (offer C , mode S , pk C , pk S , psk, k c , k s , psk )Authenticated Encryption (enc kc (m 0 ), enc ks (m 1 ), . . .)

	2.2. TLS 1.3 1-RTT: SIMPLER, FASTER HANDSHAKES	61
	Client	Server
	C	S
	Application Data Stream:	Application Data Stream:
	C	C
	2.1 A Security Model for TLS
	Figure 2.1 depicts the progression of a typical TLS connection: negotiation, then
	Authenticated Key Exchange (AKE), then Authenticated Encryption (AE) for

cid ←→ S : m 0 , m 1 , . . . cid ←→ S : m 0 , m 1 , . . .

Figure 2.1: TLS Protocol Structure. application data streams. The server chooses mode S , including the protocol version, the AKE mode and the AE algorithm. In TLS 1.2, the AKE may use RSA, (EC)DHE, PSK, etc. and AE may use AES-CBC MAC-Encode-Encrypt, RC4, or AES-GCM. In TLS 1.3, the AKE may use (EC)-DHE, PSK, or PSK-(EC)DHE and AE may use AES-GCM, AES-CCM, or ChaCha20-Poly1305. The use of one or more of (pk C , pk S , psk) in the session depends on the AKE mode.

  Diffie-Hellman group, HKDF constants such as zero and the names of principals (Alice, indicating the initiator, Bob, indicating the recipient, and Charlie, indicating a compromised principal controlled by the attacker) are all declared as constants.

	in the Noise Protocol Framework's WriteMessage and ReadMessage
	functions.
	5. Cryptographic primitives. DH, KP, E, D, H and HKDF are modeled as
	cryptographic primitives in the symbolic model.
	6. State transition functions. All functions defined for CipherState,
	SymmetricState and HandshakeState are implemented in the ap-
	plied pi-calculus.
	7. Channels. Only a single channel is declared, pub, representing the public
	Internet.
	4. Bitstring concatenation. Functions are declared for bitstring concate-
	nation, useful for constructing and destructing the message buffers involved

2. Types. Cryptographic elements, such as keys and nonces, are given types. Noise Handshake Message state elements such as CipherStates, SymmetricStates and HandshakeStates (see §3.2) are given types as well as constructors and reductors. 3. Constants. The generator of the g

  These functions are constructed to invoke the appropriate

	CHAPTER 3. NOISE PROTOCOL FRAMEWORK
		1	letfun readMessage_a(me:
	letfun writeMessage_a(me: principal, them:principal , hs:handshakestate, payload:bitstring, sid: sessionid) = let (ss:symmetricstate, s: keypair, e:keypair, rs: key, re:key, psk:key, initiator:bool) = handshakestateunpack(hs) in let (ne:bitstring, ciphertext1:bitstring, ciphertext2:bitstring) = (empty, empty, empty) in let e = generate_keypair( key_e(me, them, sid)) in let ne = key2bit(getpublickey (e)) in let ss = mixHash(ss, ne) in ( * No PSK, so skipping mixKey * ) let ss = mixKey(ss, dh(e, rs) ) in let s = generate_keypair( key_s(me)) in let (ss:symmetricstate, ciphertext1:bitstring) = encryptAndHash(ss, key2bit(getpublickey(s))) in let ss = mixKey(ss, dh(s, rs) ) in let (ss:symmetricstate, ciphertext2:bitstring) = encryptAndHash(ss, payload) in let hs = handshakestatepack( ss, s, e, rs, re, psk, initiator) in let message_buffer = concat3( ne, ciphertext1, ciphertext2) in (hs, message_buffer).	2 3 4 5 6 7 8 9 10 11 12 13 14 15	principal, them:principal , hs:handshakestate, message:bitstring, sid: sessionid) = let (ss:symmetricstate, s: keypair, e:keypair, rs: key, re:key, psk:key, initiator:bool) = handshakestateunpack(hs) in let (ne:bitstring, ciphertext1:bitstring, ciphertext2:bitstring) = deconcat3(message) in let valid1 = true in let re = bit2key(ne) in let ss = mixHash(ss, key2bit( re)) in ( * No PSK, so skipping mixKey * ) let ss = mixKey(ss, dh(s, re) ) in let (ss:symmetricstate, plaintext1:bitstring, valid1:bool) = decryptAndHash(ss, ciphertext1) in let rs = bit2key(plaintext1) in let ss = mixKey(ss, dh(s, rs) ) in let (ss:symmetricstate, plaintext2:bitstring, valid2:bool) = decryptAndHash(ss, ciphertext2) in if ((valid1 && valid2) && (rs = getpublickey( generate_keypair(key_s( them))))) then ( let hs = handshakestatepack( ss, s, e, rs, re, psk, initiator) in (hs, plaintext2, true))
			.

128

  CHAPTER 4. AUTOMATED DOMAIN NAME VALIDATION threat model for certificate issuance based on domain validation, which applies to both traditional CAs and ACME. We relate this threat model to the various domain control validation methods surveyed in §4.1. In §4.3, we demonstrate that ACME resists a stronger threat model than other CAs.

1: Popular CAs, their validation methods, whether they per- mit account recovery via email, whether they allow login via a public- key based approach (such as client certificates) and whether domain validation is carried out once for every certificate request, even for already-validated domain names. that

  these statements are not always accurate or complete (for instance, they typically provision for validation methods that are not offered in practice; the address heuristics for email-based validation is rarely listed exhaustively). Most ad-hoc CAs in our study favor email-based validation. Unlike HTTP and DNS identifiers, email identifiers effectively rely on a read capability challenge instead write access proof for C. In §4.2, we discuss how email identifiers are the weakest available form of identification given our threat model. In §4.3, we elaborate on a weakness in ACME affecting both account recovery and domain validation. While this weakness is also generalizable to traditional certificate authorities, ACME offers an opportunity for a stronger fix.

			Yes	No	N/A
	StartCom	Email	Yes	Yes	No
	StartSSL
	Figure 4.
	While CAs are required to document their certificate issuance policies in Cer-
	tificate Practice Statements [134, 135, 136, 137, 138, 139, 140, 141], we find

  Our security goals are straightforward: for any domain C w ∈ C, A must not sign a certificate asserting C's ownership of C w for that domain unless C can validate C pk as representing the identity that owns and manages this domain. ACME allows C to validate C w with respect to C pk by using the secret value C k in order to demonstrate either read or write capabilities on certain pre-defined network channels, each with its own security model. A domain name C w is considered validated under C w if C k can be used to complete a verification challenge on one of the network channels offered by the ACME protocol between C and A that in consequence asserts a relationship between C pk and C w .

•

  Client The client is allowed to assert that they own some domain by triggering the event Owner(C, C w ). Once C receives a certificate C wcert for C w from A, they also trigger CertReceived(C w , C wcert , C pk , A pk ) • Server The server (ACME instance or CA) triggers the event HttpAuth(C pk , C w ), DnsAuth(C pk , C w ) and EmailAuth(C pk , C w ) depending on the type of domain validation used. Once A issues a certificate C wcert for C w to C, they also trigger CertIssued(C w , C wcert , C pk , A pk )

  A is chosen according to the elliptic curve used to calculate C Z A : SHA256 for P 256, SHA384 for P 384 and SHA512 for P 521.3. C label A = KDF (C Z A , C H A , label), with label indicating the chosen contextfor this particular key's usage.As a protocol, ACME provides the following six certificate management functionalities (illustrated in Figure4.4) between web server C and certificate management authority A: • Account Key Registration In this step, C specifies her contact information (email address, phone number, etc.) as C c and generates a random private signing key C k with (over a safe elliptic curve) a public key C pk . A POST request is sent to A containing Sign(C k , (newreg, C c , C pk )). The newreg header indicates to A that this is an account registration request. If A has no prior record of C pk being used for an account and if the message's signature is valid under C pk , A creates a new account for C using C pk as the identifier and responds with a success message. • MAC-Based Account Recovery C may choose to identify an account recovery secret with A. In order to do this, C generates an account recovery key pair (C rk , C prk ) and simply includes C prk in an optional recoverykey field in its initial newreg message to A. A generates the complementary (A rk AC , A prk AC ) and both parties calculate C recovery A using their recovery key pairs. A communicates A prk AC in its response to C. Later, if C loses C k , she can ask A to re-assign her account to a new identity (C k , C pk ) by using C recovery A as a key to generate a MAC of some value chosen by A. • Contact-Based Account Recovery C can request that A send a verification token to one of the contact methods previously specified in C c . For example, this could be a URI sent to an email in C c . If C successfully opens this URI, she becomes free to replace C pk with a C pk for some arbitrary C k at A. • Identifier Authorization C can validate its ownership of a domain C w in C w by providing one of the identifiers discussed in §4.2 to A. C must first request authorization for C w by sending a newauthz message. A then responds with the types of identifiers it is willing to accept in a authz message. C is then free to use any one of the permitted identifiers to validate its ownership of C w and allow A to sign certificates for it issued to C and tied to the identity C pk . • Certificate Issuance and Renewal After C ties an identifier to C w under C pk , it may request that a certificate be issued for C w simply by requesting one from A. Generally, A will send the signed certificate with no further steps required. The renewal procedure is similarly straightforward. • Certificate Revocation C may ask A to revoke the certificate for C w by sending a POST message containing the certificate in question, signed under either C pk or the key pair for the certificate itself. C may choose which key to use for this signature.

  5.1. PROSCRIPT: PROTOTYPING PROTOCOLS WITH FORMAL TRANSLATIONS145• Automated Model Extraction from JavaScript We present the Pro-Script compiler, which allows for the compilation from a subset of JavaScript into a readable protocol model in the applied pi calculus. Model extraction enables formal verification to keep up with rapidly changing source code.Readable models allow the protocol analyst to experiment with different threat models and security goals and to test new features before including them in the implementation.• A Verified Protocol Core for Cryptocat We integrate our verified protocol code into the latest version of Cryptocat 1 ( §5.2), a popular open source messaging client with thousands of users that was originally developed by the author of this thesis. We show how the new architecture of Cryptocat serves to protect the verified protocol code from bugs in the rest of the application. Our ProVerif and CryptoVerif models capture the protocol core of TLS 1.3, but they elide many implementation details such as the protocol API and state machine.

• A Verified Reference Implementation of TLS 1.

[START_REF] Perrin | The X3DH key agreement protocol[END_REF]

In the first benchmark, RefTLS and Node.js's HTTPS module perform handshakes against OpenSSL. In the second and third benchmarks, we test RefTLS against itself. In the fourth bench- mark, the clients attempt to fetch 100MB of data from OpenSSL over TLS 1.2.

  clients, these functions are get_client_hello, put_server_hello, and put_-server_finished; servers use the functions put_client_hello, get_-

	Benchmark	RefTLS	Node.js	RefTLS	Node.js
		Client	Client	Server	Server
	TLS 1.2 Handshake	16ms	7ms	8ms	6ms
	TLS 1.2 Handshake	36ms		59ms
	TLS 1.3 Handshake	34ms		28ms
	Fetch 100MB	1163ms	730ms
	Figure 5.7:

Idle(skC, psk)

  Generates (AV sk , V k ) (V ek , V mk , V sp , V id ) ←-HKDF(V k , CAPSULECORP) AV pk ←-EDGEN(AV sk ) AV pv ←-PVCALC(V sp , V id , A, AV pk ) AV f p ←-HMAC(AV pk , A) Generates BV sk BV pk ←-EDGEN(BV sk ) V id , AV pk , AV pv V k , AV f p (V ek , V mk , V sp , V id ) ←-HKDF(V k , CAPSULECORP) BV pv ←-PVCALC(V sp , V id , B, BV pk ) BV f p ←-HMAC(BV pk , B) V id , BV pk , BV pv V id , AV pk , AV pv Checks if AV pv = PVCALC(V sp , V id , A, AV pk ) Checks if AV f p = HMAC(AV pk , A) BV f p V id , BV pk , BV pv Checks if BV pv = PVCALC(V sp , V id , B, BV pk ) Checks if BV f p = HMAC(BV pk , B) ENC diff0 ←-BENC(V ek , V mk , diff 0 ) SIG A ENCdiff 0 Vid ←-EDSIGN (AV sk , (A ENC diff0 V id )) ENC diff0 , SIG A ENCdiff 0 Vid ENC diff0 , SIG A ENCdiff 0 Vid ENC diff1 ←-BENC(V ek , V mk , diff 1 ) SIG B ENCdiff 1 Vid ←-EDSIGN (BV sk , (B ENC diff1 V id )) ENC diff1 , SIG B ENCdiff 1 Vid ENC diff1 , SIG B ENCdiff 1 Vid

	Client	Server	Client
	A	S	B

1: Model of the handshakes with pre-shared key 201

  n. H i-1 , L, e i -→ H i , v i H i = H i [(l , x i ) → v i ] PSKH = C h [io22(); new psk : key; io23 ; (C PSKClient [Q PSKOnlyClient | Q PSKDHEClient ] | C PSKServer [Q PSKOnlyServer | Q PSKDHEServer ])] Q PSKOnlyClient = C PSKOnlyClient [ insert c_table(c_cr,c_log1 , c_binder, c_log1 ); 1: event ClientEarlyAccept1((c_cr, c_log1 , c_binder, c_log1 ), cets, i C ); let c_cets : key = cets in io2[i C ] ClientHelloOut(c_cr, c_binder) ; C PSKOnlyClient [ event ClientTerm1((c_cr, c_log1 , c_binder, c_log1 , sr, log2 , log3 , m), (log4 , cfin), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, cats, sats, ems, resumption_secret)); let c_sats : key = sats in 2: event ClientTerm((c_cr, c_log1 , c_binder, c_log1 , sr, log2 , log3 , m), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, cats, c_sats, ems)); 3: event ClientAccept((c_cr, c_log1 , c_binder, c_log1 , sr, log2 , log3 , m, log4 , cfin), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, cats, c_sats, ems, resumption_secret), i C ); let c_cats : key = cats in let c_ems : key = ems in let c_resumption_secret : key = resumption_secret in io6[i C ] ClientFinishedOut(cfin) ]] Q PSKOnlyServer = C PSKOnlyServer [ io11 [i S ] , 6: event ServerAccept((s_cr, s_log1 , s_binder, s_log1 , sr, log2 , log3 , m), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, cats, sats, ems), i S ); let s_sats : key = sats in io18[i S ] ServerFinishedOut(m) ; C PSKOnlyServer [ event ServerTerm1((s_cr, s_log1 , s_binder, s_log1 , sr, log2 , log3 , m), (log4 , cfin), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, cats, sats, ems, resumption_secret)); let s_cats : key = cats in let s_ems : key = ems in let s_resumption_secret : key = resumption_secret in 7: event ServerTerm((s_cr, s_log1 , s_binder, s_log1 , sr, log2 , log3 , m, log4 , cfin), (client_hk, server_hk, client_hiv, server_hiv, cfk, sfk, s_cats, sats, s_ems, s_resumption_secret)); io30[i S ] ]] Knows (sk C , pk S ) Knows (sk S , pk S ), (s, g s ) Knows (sk M , pk M ) Certificate(pk S ) Certificate(pk M ) sign skS (hash(ServerConfig(g s ))) sign skM (hash(ServerConfig(g s ))) ClientHello(n C , offer C [G, g x ])

	Generates x Computes: m , k 0 log 1 h , k 0 k 0 c = kdf ss (g xs , log 1 ) Figure B.C log 2 log 3	M h (Certificate(pk C )) enc k 0 h (CertVerify(sign skC (hash(log 2 )))) enc k 0	S Computes: m , k 0 h , k 0 k 0 c = kdf ss (g xs , log 1 ) log 1 log 2 log 3

H, L, {x 1 :e 1 ,...,x n :e n } -→ H n , l Q S ](); get c_table(= s_cr, = s_log1 , = s_binder, = s_log1 ) in let s_cets2 : key = get_client_ets(cets_eems) in 4: event ServerEarlyTerm1((s_cr, s_log1 , s_binder, s_log1 ), s_cets2 ); io12 [i S ] else let s_cets3 : key = get_client_ets(cets_eems) in 5: event ServerEarlyTerm2((s_cr, s_log1 , s_binder, s_log1 ), s_cets3 ); find us ≤ N S suchthat defined(s_cr[us], s_log1 [us], s_binder[us], s_log1 [us], s_cets1 [us]) ∧ s_cr[us] = s_cr ∧ s_log1 [us] = s_log1 ∧ s_binder[us] = s_binder ∧ s_log1 [us] = s_log1 then io13 [i S ] else let s_cets1 : key = s_cets3 in io14 [i

https://mitls.org

Signal Protocol's Double Ratchet was previously known as the "Axolotl" ratchet.

Other secure messaging protocols, such as OTR and Telegram, are also briefly examined.

With the exception of only the latest version of TLS, TLS 1.3 (Chapter 2) and of our own novel secure collaborative document editing protocol (Chapter 6)

Also referred to as the Dolev-Yao model[START_REF] Syverson | Dolev-Yao is no better than machiavelli[END_REF].

ProVerif also supports restricting evaluation to a passive attacker, which can be crucial for testing for security goals such as secrecy and authenticity, as shown in Chapter 3.

e.g. "128-bit security", which could be based on a cipher with a key space of 2[START_REF] Bellare | Authenticated encryption: Relations among notions and analysis of the generic composition paradigm[END_REF] and no known weaknesses.

We describe SP, a variant of Signal Protocol that closely follows TextSecure version 3. We show how we implement and verify this protocol in our framework.

Anyone can use Noise Explorer to increase this number by designing, validating then automatically verifying their own Noise Handshake Pattern.

Recall that, in the symbolic model, any arithmetic property such as additivity is not a given and must be modeled specifically.

keypairpack and keypairunpack are a fun and reduc pair that allow compressing and decompressing a tuple of key values into a keypair-type value for easy handling throughout the model. Whenever the suffixes pack and unpack appear from now on, it is safe to assume that they function in a similar pattern.

denotes bitstring concatenation.

zero is meant to denote a null bitstring.

As of writing, Revision 34 is the latest draft of the Noise Protocol Framework. Noise Explorer is continuously updated in collaboration with the authors of the Noise Protocol Framework specification.

https://noiseexplorer.com/patterns/

For simplicity, here we use H to represent the more complex key derivation and mixing functions.

CloudFlare incidentally also operates Let's Encrypt's infrastructure, rendering it a centralized point of failure for ACME and ad-hoc CAs alike. While ACME is a centralization-agnostic protocol, Let's Encrypt operates with a fully centralized infrastructure.

[START_REF] Perrin | The X3DH key agreement protocol[END_REF] Full model available at https://github.com/Inria-Prosecco/acme-model

We also specify a fully public channel named pub.

https://crypto.cat

https://esverify.org/

Transport layer protections for this and other communications listed below are beyond the scope of this protocol. For simplicity, we assume they are protected with a transport layer security model equivalent to a regular TLS 1.3 deployment.

Capsule models and reference implementations are available at https://symbolic. software/capsule/.

Transcript consistency, while not explicitly modeled in ProVerif, is obtained through the hash chain structure of DiffChains, as described in §6.3.3.

Acknowledgments

Chapter 4

Formal Verification for Automated Domain Name Validation

This work was published in the proceedings for the 21st International Conference on Financial Cryptography and Data Security, 2017. It was completed with coauthors Karthikeyan Bhargavan and Antoine Delignat-Lavaud.

In this chapter, we formally specify, model and verify ACME using ProVerif. Against a classic symbolic protocol adversary, ACME achieves most of its stated security goals. Notably, we show that ACME's design allows it to resist a substantially stronger threat model than the ad-hoc protocols of traditional CAs that rely on bearer tokens (passwords, cookies, authorization strings) for authentication and domain validation, thanks to its stronger cryptographic credentials and to the binding between the clients identity and the validated domain.

Nevertheless, we still discover issues and weaknesses in ACME's domain validation and account recovery features, potentially amounting to user account compromise. We attempt to address in this chapter what seem to be open questions regarding ACME: how does ACME compare to the existing security model of the actual top real-world certificate authorities? How can we most fruitfully illustrate and formally verify its security properties and what can we prove about them?

Contributions Our contributions in this chapter consist of:

• A survey of the domain validation practices of current CAs: in §4.1, we survey the issuance process and infrastructure of 10 of the most popular certificate authorities. We observe that traditional CAs support multiple methods for assessing domain control, that rely on different security assumptions.

• A threat model for domain validation: in §4.2, we specify a high-level

Validation with HTTP Identifiers We explicitly show that HTTP authentication is weaker than DNS authentication, since an attack is possible under both cases of DNS poisoning and an HTTP man-in-the-middle attack:

Predictable Certificate Issuance We attempt to verify that all received certificates were issued by the expected CA. This query fails to verify and leads us to the attack we discuss in §4.5:

Specifying and Formally Verifying ACME

In this section we provide a formal description of the ACME protocol functionality and identify three issues that affect ACME's security. We also discuss details of how we describe the ACME protocol flow in the applied pi calculus, so that we can verify for certain queries using ProVerif.

ACME Network Flow

Unlike ad-hoc CAs which are limited to a web login, ACME's authentication depends on C generating a private signing key C k with a corresponding public verification key C pk , which are used to generate automated client signatures throughout the protocol.

HTTP Identifier

A sends to C a nonce A N C via the HTTPS channel. C must then advertise, at an agreed-upon location under C w , the value (C pk , A N C ). A then accesses C w using an unauthenticated, unencrypted HTTP connection to ensure that it can retrieve the intended value. ACME also supports a very similar validation mode that operates at the level of the TLS handshake rather than at the HTTP level (using the SNI extension and a specially crafted certificate in place of the HTTP request and response). We believe this mode is intended for TLS termination software and hardware, and despite its apparent complexity, it is semantically equivalent to the HTTP identifier method. Since the details of the formatting of payloads is abstracted in our symbolic model we model both TLS-SNI and HTTP validation under the same framework in our model.

DNS Identifier

A sends to C a nonce A nonce C via the HTTPS channel. C advertises this nonce in the form of a DNS record served by C w 's name servers, thereby proving ownership of C w . A can then query its DNS server to verify that the nonce has been set. While this behavior is specified in ACME, it is not used in any implementation of Let's Encrypt: since ACME is designed to take advantage of domain validation methods that can be automated and since DNS

ProScript Syntax

A ProScript implementation consists of a series of modules, each containing a sequence of type declarations (containing constructors, assertion utilities and type converters), constant declarations and function declarations.

Type Declarations. Types are declared as object constants with the name Type_x where x is the name of the type (e.g. key). Type declaration objects include various properties:

1. construct, a function which returns the shape of the object and which is used to both define the type to the compiler and to instantiate new variables of this type throughout the code.

2. assert, a function allowing the ProScript compiler to infer that a function's input parameter is of type x.

3. toBitstring, f romBitstring, conversion functions from type x to a regular string. These are detected by the ProScript compiler and represented as ProVerif type conversion functions in the extracted model.

clone, a function for cloning a variable of type x.

Constant Declarations. In ProScript, we prefer the use of constant declarations to variable declarations due to their decreased malleability. We also prohibit the reassignment of object properties because of the pointer-like behavior of JavaScript object variables rendering this difficult to model efficiently in ProVerif. Scoping is also enforced: ProScript only allows for the declaration of variables at the top of a module or function, preceding all function declarations or calls. Further, for an object v, we say that v.x is well-formed if and only if v has been declared, either as a type or scoped variable, to have a property x.

Function Declarations. The majority of a ProScript implementation tends to be a series of pure function declarations. A small subset of these functions is exposed to a global namespace for access by the verified application while most remain hidden as utility functions for purposes such as key derivation, decryption and so on. All ProScript functions are pure and state-passing, allowing them to be modeled into ProVerif functions, declared with the keyword letfun (See the Introduction of this thesis). All ProScript functions are typed and the ProScript compiler will enforce that they are used with the same input types and return the same output type throughout the implementation. Top-level object declarations often contain function declarations. We assume for simplicity that these object declarations are flattened into top-level function declarations. In order to enforce type safety, ProScript objects and arrays are also non-extensible: JavaScript prototype functions such as Array.push cannot be employed and object accessors such as v[x] are disallowed. Note that we will use the defined Lib.l notation to access the ProScript Cryptography Library.

Operational Semantics. ProScript's operational semantics is a subset of JavaScript and both run on JavaScript interpreters. It is tooled based on the formal semantics of Maffeis et al. [START_REF] Philippa | Towards a program logic for JavaScript[END_REF] and is superficially adapted for our language subset.

Translation

ProScript functions are translated into ProVerif pure functions. Type declarations are translated into ProVerif type declarations. Individual values, such as strings and numbers, are declared as global constants at the top-level scope of the ProVerif model with identifiers that are then employed throughout the model when appropriate. Objects and Arrays are instantiated in the model using functions, with destructors automatically generated in order to act as getters.

Translation Rules

Fγ → ∆ Types and Functions to Declarations

A Symbolic Model for PSCL

Besides being type-checked, the ProScript Cryptography Library is unique in that the ProScript compiler is able to detect its usage in ProScript code and model the equational relationships of cryptographic primitives automatically in the extracted model, as seen in Figure 5.4 (lines 9-18). For instance:

1. Diffie-Hellman operations have the relationship (g a ) b = (g b ) a = g ab modeled for a base point g using ProVerif equations.

PROSCRIPT: PROTOTYPING PROTOCOLS WITH FORMAL TRANSLATIONS151

2. Symmetric Encryption operations have their decryption functions related to the ciphertext with the use of destructors, enforcing the relationship Dec(k, Enc(k, m)) = m.

3. HMAC checking functions are similarly modeled with destructors in order to illustrate the relationship checkHM AC(k, m, HM AC(k, m)) = true.

More creatively, destructors can also be provided for the attacker to detect instances of nonce re-use in stream ciphers (such as AES-CTR) by modeling:

Translation Soundness. We currently do not formally prove translation soundness, so proofs of the resulting ProVerif model do not necessarily imply proof of the source code. Instead, we use model translation as a pragmatic tool to automatically generate readable protocol models faithful to the implementation and to find bugs in the implementation. We have experimented with multiple protocols written in ProScript, including OTR, SP, and TLS 1.3 and by carefully inspecting the source code and target models, we find that the compiler is quite reliable and that it generates models that are not so far from what one would want to write directly in ProVerif. In future work, we plan to prove the soundness of this translation to get stronger positive guarantees from the verification. To this end, we observe that our source language is a simply-typed functional programming language and hence we should be able to closely follow the methodology of [START_REF] Bhargavan | Verified interoperable implementations of security protocols[END_REF].

State Tables Interface. We use ProVerif tables in order to manage persistent state parameters between parallel protocol executions. This necessitates the introduction of a key-value syntax in ProScript: tables are declared as global constants. Their access is summarized in this simple example: return ProScript.state.insert('usernames', 'myUsername', password), ProScript.state.get('usernames', 'myUsername', password) translate to insert usernames(myUsername, password), get tableName(=myUsername, password). Generating Top-Level Processes. We are also able to automatically generate top-level ProVerif processes. Aiming to implement this in a way that allows us to easily integrate ProScript code into existing codebases, we decided to describe top-level functions inside module.exports, the export namespace used by modules for Node.js [START_REF]and the Linux Foundation[END_REF], a popular client/server run-time for JavaScript applications (based on the V8 engine). This makes intuitive sense: module.exports is used specifically in order to define the functions of a Node.js module that should be available to the external namespace once that module is loaded and executing all this functionality in parallel can give us a reasonable model of a potential attacker process. Therefore, functions declared in this namespace will be translated into top-level processes executed in parallel. We use ProVerif tables in order to manage persistent state between these parallel processes: each process fetches the current state from a table, runs a top-level function in that state, and stores the updated state returned by the

Trusted Library This component provides cryptographic functionality. A

goal is to include modern cryptographic primitives (X25519, AES-CCM) and provide type-checking assurances without affecting speed or performance.

This layered architecture is essential for our verification methodology, but is quite different from other messaging applications. For example, the Signal Desktop application is a Chrome browser application also written in JavaScript [START_REF]Signal for the browser[END_REF]. Parts of the protocol library are compiled from C using Emscripten, presumably for performance, parts are taken from third-party libraries and other protocolspecific code is written in JavaScript. The resulting code (1.5MB, 39Kloc) is quite hard to separate into components, let alone verify for security. We hope that our layered approach can lead to verified security guarantees without sacrificing performance or maintainability.

Isolating Verified Code

We build Cryptocat using Electron [152], a framework for JavaScript desktop applications. Electron is built on top of the Node.js JavaScript runtime and the Chromium web renderer. Electron has recently gained strong adoption: popular applications such as Visual Studio Code, Atom, Slack, WordPress and WhatsApp Desktop are all built on top of Electron.

By default, Electron allows applications to load any Node.js low-level module, which can in turn perform dangerous operations like accessing the file system and exfiltrate data over the network. Since all Node.js modules in a single process run within the same JavaScript environment, malicious or buggy modules can tamper with other modules via prototype poisoning or other known JavaScript attack vectors. Consequently, all Electron apps, including other desktop Signal implementations like WhatsApp and Signal messenger effectively include all of Electron and Node.js into their trusted computing base (TCB).

We propose a two-pronged approach to reduce this TCB. reuse its ProVerif compiler to extract symbolic models from the core protocol 158 CHAPTER 5. SECURE CHANNEL PROTOCOL IMPLEMENTATIONS const Type_key = { construct: function() { return [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00] }, assert: function(a) { var i = 0; for (i = 0; i < server_finished, and put_client_finished.

We then use the ProScript compiler to translate this module into a ProVerif script that looks much like the protocol models described in earlier sections of this chapter. Each pure function in ProScript translates to a ProVerif function; functions that modify mutable state are translated to ProVerif processes that read and write from tables. The interface of the module is compiled to a toplevel process that exposes a subset of the protocol functions to the adversary over a public channel.

The adversary can call these functions in any order and any number of times, to initiate connections in parallel, to provide incoming flights of messages, and to obtain outgoing flights of messages. The ProVerif model uses internal tables, not accessible to the attacker, to manage state updates between flights and preserve state invariants through the protocol execution.

Our approach allows us to quickly obtain verifiable ProVerif models from running RefTLS code. For example, we were able to rapidly prototype changes to the TLS 1.3 specification between Draft-13 and Draft-18, while testing for interoperability and analyzing the core protocol at the same time. In particular, we extracted a model from our Draft-18 implementation, and verified our security goals from §2.2 and §2.4 with ProVerif.

We engineered the ProScript compiler to generate readable ProVerif models that can be modified by a protocol analyst to experiment with different threat models. It is possible to extend the same automated translation approach towards CryptoVerif models. Recently, CryptoVerif syntax became similar to that of ProVerif. However, the kind of models that are easy to verify using Cryp-toVerif differ from the models that ProVerif can automatically verify and the assumptions on cryptographic primitives will always remain different. There-

REFTLS CHAPTER 6. SECURE COLLABORATIVE DOCUMENT EDITING

Protocol Description

During the lifetime of a Capsule collaborative document, there are only two subprotocols that a participant has to follow. The first is the key generation subprotocol which produces the necessary key material to conduct the session. The second is the hash chain [START_REF] Lamport | Password authentication with insecure communication[END_REF] protocol, which we call DiffChain. By pushing and pulling encrypted diffs to the diff chain, participants can reconstruct the document upon joining the session and then begin exchanging modifications.

Key Material

The following key material is necessary for all participants.

Client Key Materials

A client A owns the following key material in relationship to collaborative document V : 128 , a randomly generated master secret, selected by the document creator or otherwise obtained from the document creator. Acts as the lifetime token for legitimately joining a collaborative document.

subkeys used for encryption, message authentication, proof of being a legitimate participants and to derive the document ID used by the server for bookkeeping.

• AV sk R ←-{0, 1} 256 , a signing private key.

• AV pk ←-EDGEN(AV sk ).

•

In the above, PVCALC is simply a shorthand function for the HMAC construction following it.

Among the above values, AV pv is called a proof of participation value: Since the server does not know V sp , it cannot generate a xV pv for any possible participant x. Validating this value, therefore, protects the collaborative document editing session from containing illegitimate participants who were not given access to V k .

Server Key Materials

A server S obtains access to the following key materials in relationship to collaborative document V :

• V id , used as the server-side identifier for the document.

1 CAPSULECORP represents a salt encoded as a string.

PROTOCOL DESCRIPTION

169

• AV pk as Alice's ephemeral identity. Optionally, the server can also use this to validate DiffChain blocks sent in by Alice for commitment.

• AV pv , used by Alice to prove that her identity is being served as a legitimate participant to the collaborative document.

Session Setup

Suppose Alice (A) wants to create a new collaborative document. She generates the keys mentioned in §6.3.1 and then communicates the following key material to server 2 S:

The server creates the new document identified server-side as V id and stores the triple (A, AV pk , AV pv ) as the first participant to the document.

Session setup is now complete. In order to invite a fellow collaborator into the document, Alice simply shares V k . Alice can choose to encode V k as a string or QR code to make sharing easier. Once Bob obtains V k , he too can immediately generate all necessary key material to join the document, encrypt and authenticate diff information and prove to the rest of the participants that his participation is legitimate.

When Bob (B) joins the document, the following occurs (the last message is repeated for every existing participant:) ---------S At this stage, Bob may carry out several validation operations:

• Verifying that V k maps to V id .

• Depending on mutual authentication requirements, verifying that AV pk is expected for some known identity for Alice.

• Verifying that HMAC(V sp , A V id AV pk ) = AV pv .

Managing Collaborative Document History with DiffChain

As a protocol, Capsule needs to provide a fast, efficient method to allow for the continuous update of a document by an unbounded number of participants and for the constant synchronization of this document between the participants. Aside from homomorphic encryption, which currently does not appear to be

Writer Client Processes

The writer process running under identity W joins a document V using a preshared V k . It calculates W V pk , emits a ProofSent event and sends (V id , W, W V pk , W V pv ) over the network. What follows next is an unbounded execution of the writeBlock process, with unbounded newly instantiated plaintext diff. Note that for modeling purposes, we "tag" the plaintext diff using the construction secretdiff which takes in a value of type plaintext and produces a value of type plaintext. This constructor is paired with a reductor, issecretdiff, that simply reveals whether its input value was constructed using secretdiff.

Reader Client Processes

The reader process running under participant identity R comes equipped with a value U V f p ←-HMAC(U V pk , U ) that serves as a fingerprint for authenticating public identities and their public signing keys out of band.

Mirroring the writer processes above, the reader process begins by similarly generating the requisite values and communicating them over the network. Then, an unbounded execution of the readBlock process occurs. The readBlock process receives over the network a triple of candidate values for (U, U V pk U V pv ) with a header matching the V id value that the reader was able to obtain using the V k the process was initialized with. Then, the internal U V f p and U V pv are checked against the candidate values received over the network. If the check succeeds, a ProofVerified event is emitted. Then, an encrypted diff along with its signature is received over the network with a header matching (V id , U, U V pk ). Once signature and authenticated encryption checks pass, the P ulled event is emitted.

Participant List Integrity

We assert that if a proof of participation value XV pv is verified by participant Y , then there must exist an identity X which has issued XV pv . As shown in §6.3.1, this means that whoever asserts identity X must also possess V sp :

event ProofVerified(X, Y, XV pv ) =⇒ event ProofIssued(X, XV pv )

Confidentiality

We simply query for whether the attacker can trigger the plaintext obtention event described above for any plaintext-type bitstring m:

Integrity and Ephemeral Authentication

We assert that if a DiffChain block (ENC diff , SIG X ENC diff V id ) was received by Y as part of document V , then this block will successfully authenticate and decrypt as originating from identity X if and only if it was pushed by X for document V .

Results Under a Dolev-Yao Attacker

All queries mentioned above complete successfully. By tweaking the model, we are also able to quickly test for the event where an ephemeral identity is not verified out-of-band by the other participants. Since all encryption is symmetric and no asymmetric key agreement ever occurs in the Capsule protocol, the outcome of this is minor and does not result in the compromise of confidential information.

Software Implementation

Capsule is provided with a client/server reference implementation called Capsulib. It is meant to allow for quick deployment and testing of the Capsule protocol in production.

Capsulib: a Capsule Client/Server Implementation

Capsulib Server is a Node.js application that uses Redis as a database backend but is otherwise self-contained. It achieves low latency by communicating over WebSockets. Its main purpose is to hold a DiffChain record for every document and to facilitate the exchange of encrypted blocks.

SOFTWARE IMPLEMENTATION 177

Capsulib Client is meant to be executed within an Electron runtime. It provides a user interface, the Capsulib cryptographic library and the full Capsule client protocol implementation.

Cryptographic Cipher Suite

We expose the following cryptographic functions:

• Hashing. HASH(x) -→ y. BLAKE2s is used as the hash function.

• Hash-Based Key Derivation.

is also used for key derivation, producing four 16-byte outputs.

• Encryption and Decryption. BLAKE2 is used for encryption and decryption. We hash the encryption key over a counter and a nonce to generate a keystream. BLAKE2 is then used as a keyed hash with a MAC key to generate an HMAC value over the ciphertext.

-Encryption. BENC(ek, mk, p) -→ (ENC p , n).

-Decryption. BDEC(ek, mk, ENC p , n) -→ p.

• Signatures. Ed25519 is chosen due to its speed and minimal input validation requirements.

-Key Generation. EDGEN(sk) -→ pk.

-Signing. EDSIGN(sk, x) -→ SIG x .

-Signature Verification. EDVERIF(pk, x, sig x ) -→ { , ⊥}.

Formally Verified Cryptographic Primitives in WebAssembly

While Capsulib is written in JavaScript, much of the Capsulib cryptographic primitives library is automatically generated as WebAssembly (WASM) [162] code. We use a toolchain that provides strong verification guarantees, hence ruling out potentially catastrophic bugs in the cryptographic layer. Ed25519 is specified in F [START_REF] Protzenko | Verified low-level programming embedded in F[END_REF], an ML-like programming language with support for program verification via the use of a dependent type system, effect annotations and SMT-based automation. Our specifications are executable, which allows us to run them against the RFC test vectors to ensure their correctness.

The cryptographic algorithms themselves are written in Low*, a subset of F that enjoys an optimized compilation scheme to low-level targets. The Low* implementation of our algorithms is shown to match the original F specification, which ensures functional correctness and memory safety.

Based on this, we rule out both incorrect math and memory errors such as buffer overflows. In addition to function correctness and memory safety, we enforce basic side-channel resistance, by restricting secrets to a very limited set Appendix A

ProScript Definitions

A.1 ProScript Operational Semantics

Notation: Sorts and Constants.

x ∈ X U User variable names.

{@proto, @this, @scope, @body} ∈ X I Internal variables.

x ∈ X X I * X U Variable names.

l op Object.prototype.

l g Global object.

L ∈ C L * Scope chains.

n ∈ N Numbers.

s ∈ S Strings.

undefined ∈ U Undefined.

e ∈ E Expressions.

λx•e ∈ F Function code. ServerConfiguration(sign sk B (cid, g y , expiry 0 ))

Generates sid, x

Computes info 0 = (0, sid, g x , cid, g y , A, B) ms 0 = kdf(g xy , info 0 ) ctx 0 = kdf(ms 0 , "context0 ) hk 0 = kdf(ms 0 , "handshake0 ) dk 0 = kdf(ms 0 , "data0 ) psk 0 = kdf(ms 0 , "presharedkey0 ) ak 0 = kdf(ms 0 , "ack0 ) Hello(sid, g x , cid, authenc(hk 0 , A, sign sk A (ctx 0 )))

Knows sid → (B, 0, g y , psk 0 , ak 0 , expiry 0 ) sid → (B, 0, dk 0 , expiry 0 )

Computes info 0 , ctx 0 , hk 0 , dk 0 , psk 0 , ak 0 Verifiesmessages Generates y Ack0 (mac ak0 (sid, g y , expiry))

Knows sid → (B, 0, g y , psk 0 , ak 0 , expiry) Knows sid → (A, 0, y , psk 0 , ak 0 , expiry) sid → (A, 0, dk 0 , expiry)

ABSTRACT

Individuals and organizations are increasingly relying on the Web and on user-facing applications for use cases such as online banking, secure messaging, document sharing and electronic voting. To protect the confidentiality and integrity of these communications, these systems depend on authentication and authorization protocols, on application-level cryptographic constructions and on transport-layer cryptographic protocols. However, combining these varied mechanisms to achieve high-level security goals is error-prone and has led to many attacks even on sophisticated and well-studied applications. This thesis aims to develop methods and techniques for reasoning about, designing and implementing cryptographic protocols and secure application components relevant to some of the most frequently used cryptographic protocols and applications. We investigate and formalize various notions of expected guarantees and evaluate whether some of the most popular secure channel protocols, such as secure messaging protocols and transport protocols often operating at the billion-user scale, are capable of meeting these goals.

In this thesis, we ask: can existing major paradigms for formal protocol verification serve as guidelines for the assessment of existing protocols, the prototyping of protocols being designed, and the conception of entirely new protocols, in a way that is meaningful and reflective of their expected real-world properties? And can we develop novel frameworks for formal verification and more secure implementation based on these foundations?

We propose new formal models in both symbolic and computational formal verification frameworks for these protocols and applications. In some of the presented work, we obtain a verification methodology that starts from the protocol and ends at the implementation code. In other parts of our work, we develop a dynamic framework for generating formal verification models for any secure channel protocol described in a lightweight syntax. Ultimately, this thesis presents formal verification approaches for existing protocols reaching towards their implementation as well as methods for prototyping and formally verifying new protocols as they are being drafted and designed.

KEYWORDS formal verification, cryptographic protocols