Prosecco

Programming Securely with Cryptography

A Project-Team Proposal

Karthikeyan Bhargavan

INRIA Paris-Rocquencourt

Bruno Blanchet

INRIA Paris-Rocquencourt

Graham Steel

INRIA Saclay

1

Summary

The current state of the Internet is characterized by heterogeneous distributed software appli-cations (running on smartphones, browsers, cloud-based servers) that cooperate to exchangeand store security-critical information. To protect the integrity and confidentiality of this infor-mation, applications use a variety of cryptographic mechanisms, such as encrypted databases,tamper-proof hardware, and cryptographic network protocols. But cryptographic mechanismsare notoriously complex and difficult to get right, even for security experts. Can we be sure thatapplication programmers implement and use them correctly?

Research on provably secure cryptographic mechanisms and protocols (e.g. in CASCADEand SECSI) has made great advances in recent years, resulting in proofs of security for carefullywritten protocol implementations (e.g. in MOSCOVA and MSR-INRIA). Research on programverification (e.g. in ABSTRACTION, and PROVAL) is also advancing quickly and has resultedin tools that can now find bugs in large programs. Yet, the current state of software securityresearch remains inadequate to formally prove the security of a realistic distributed application,partly because cryptographic security is an inherently hard problem, and partly because programverification tools are not tailored for security analysis. To take just the example of TLS, awidely-deployed and well-studied cryptographic protocol designed, implemented, and verified bysecurity experts, the lack of a formal proof about all its details has regularly led to the discoveryof major attacks (in 2003, 2008, 2009, and 2011) on both the protocol and its implementationsafter many years of unsuspecting use. Still, new protocols like OAuth (the protocol underlyingFacebook Connect) continue to be designed and deployed across millions of websites withoutformal proofs of security. Even commercial security solutions, such as hardware security modulesand browser-based password managers, are constantly plagued by security vulnerabilities.

We believe this is an opportune moment for a new project that focuses on building andverifying programs that use cryptography. Our goal is to design programming language abstrac-tions, cryptographic models, verification tools, and verified security libraries that can be usedto build provably secure distributed applications. Our target applications include cryptographicprotocol implementations, hardware-based security APIs, smartphone- and browser-based webapplications, and cloud-based web services. Our analysis techniques include dependent type sys-tems (e.g. F7, F*), symbolic and computational cryptographic protocol verifiers (e.g. ProVerif,CryptoVerif), general-purpose theorem provers (e.g. Coq, Z3), formal testing frameworks (e.g.Tookan), and run-time analysis tools (e.g. for JavaScript).

Our team has a strong background in developing cryptographic models and using them tobuild analysis tools that can verify real-world security applications. We share a willingness to gobeyond theory and try to build tools that are widely applicable and accessible to programmers.Our individual research themes, as exemplified by Bhargavans ERC-funded project CRYSP,Blanchets ANR-funded project ProSe, and Steels CSATT-funded project Tookan, align wellwith the team goals outlined here. Our approaches are complementary, and the formation of thisteam opens up promising new directions for fruitful collaboration. This proposal outlines ourindividual and joint research plans. Working together, we hope to make significant contributionsto software security research.

2

Contents

1 Overview 41.1 Team composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Programming securely with cryptography . . . . . . . . . . . . . . . . . . . . . . 41.3 Scientific goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Symbolic verification of cryptographic applications 82.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Proposed research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Computational verification of cryptographic applications 153.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Proposed research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Provably secure web applications 204.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Proposed research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 National and international positioning 235.1 INRIA teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Other teams in France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 International teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

A Biographies of team members 26

B Collaborations and grants 27B.1 Research collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27B.2 Grants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

C Software and transfer objectives 28

D Recent publications of the team (2006-2011) 31

E Other references 35

3

1 Overview

1.1 Team composition

Karthikeyan Bhargavan (chef), CR1 (MOSCOVA), INRIA Paris-Rocquencourt,Ecole Polytechnique, MSR-INRIA.

Bruno Blanchet, DR2 (CASCADE), INRIA Paris-Rocquencourt, ENS Ulm Graham Steel, CR1 (SECSI), INRIA Saclay, ENS Cachan Post-docs: Alfredo Pironti (MOSCOVA), Gergei Bana (MSR-INRIA) Engineer : Romain Bardou (SECSI) PhD students: Evmorfia-Iro Bartzia (MOSCOVA), Robert Kunnemann (SECSI),

David Cade and Miriam Paiola (CASCADE)

1.2 Programming securely with cryptography

Over the past decade, an increasing amount of sensitive data is being generated, manipulated,and accessed online, from bank accounts to health records. Both national security and individualprivacy have come to rely on the security of web-based software applications. But even a singledesign flaw or implementation bug in an application may be exploited by a malicious criminalto steal, modify, or forge the private records of innocent users. Such attacks are becomingincreasingly common and now affect millions of users every year1.

The risks of deploying insecure software are too great to tolerate anything less than mathe-matical proof, but applications have become too large for security experts to examine by hand,and automated verification tools do not scale. Today, there is not a single widely-used webapplication for which we can give a proof of security, even against a small class of attacks. Infact, design and implementation flaws are still found in widely-distributed and thoroughly-vettedsecurity libraries designed and implemented by experts2.

Software security is in crisis. A focused research effort is needed if security programming andanalysis techniques are to keep up with the rapid development and deployment of security-criticaldistributed applications based on new cryptographic protocols and secure hardware devices. Wepropose to build a new team that draws upon our individual expertise in security and programverification to make decisive contributions in this direction.

Motivating example

As a motivating example, consider a typical online banking application, as depicted in Figure 1.The server side of the application resides on a secure server at the banks headquarters. On theclient side, the application can be accessed at any branch of the bank by an employee who haslogged in using his smartcard and PIN code. The branch has a secure connection to the bankserver using a cryptographic protocol (IPsec). In addition, any bank customer can access heraccounts over the web by entering a username and password in her browser. Her interactionswith the bank server are kept confidential using another cryptographic protocol (HTTPS).

The server application consists of a web service that receives and authorizes transactionsfrom employees and customers, a database that contains bank records, and a hardware security

1http://www.soe.com/securityupdate/pressrelease.vm2http://openssl.org/news/secadv_20090107.txt

4

Figure 1: An example online banking application

module that manages passwords, PIN codes, and cryptographic keys. The security goal of theapplication is to mediate access to the database using an access control policy, that is, a set ofrules governing who can read or modify each record. The problem is to ensure this security goaleven when some employees may be malicious, some customers computers may have viruses, andan unknown adversary may control the network connections of honest employees and customers.What makes this security goal so hard to guarantee, or even reason about? The short answer isthat it is not enough to prevent the attacks that have been discovered, the application must beprotected against all potential attacks, some that have not even been discovered yet. The long-recommended practice is to get a security expert to examine an application and, if possible, toproduce a mathematical proof of security [151]. However, for a large-scale application, the rangeof possible attacks and the size of code to review becomes prohibitive to analyze by hand. Hence,it becomes essential to develop automated tools that can at least verify the security-critical partsof the application.

Security-critical components

The core security-critical components of a typical web application can be arranged in severallayers, as depicted in Figure 2.

The security of the application ultimately relies on fundamental cryptographic algorithms,such as those for encrypting data for confidentiality (e.g. AES), which are typically implementedin software libraries (e.g. Bouncy Castle) or in cryptographic hardware (e.g. smartcards). Thesealgorithms are developed by mathematicians, specifically cryptographers, and their correctnessrelies on complex results in number theory well beyond the knowledge base of the typical pro-grammer. However, to use these algorithms, it suffices to treat them as primitive and understandthe security guarantees they provide. These guarantees are usually framed, by cryptographers,in terms of games between an honest principal wielding a cryptographic primitive and a prob-abilistic polynomial-time adversary who tries to subvert the primitive (but succeeds only withnegligible probability). In this project, we propose to study and use these guarantees, but notto build or verify cryptographic algorithms ourselves.

At the next higher layer, cryptographic algorithms are composed into software libraries thatprovide simpler programming abstractions. Some cryptographic protocols, such as TLS andIPsec, simply provide secure channels over insecure networks and are implemented within op-erating system networking stacks (e.g. Linux IPsec). Other protocols, such as OAuth, performmulti-party web authentication and their implementations are built into browser-based applica-

5

Figure 2: Security-critical components of a web application

tions (e.g. Facebook Connect). Finally, cryptographic hardware devices, such as smartcards andhardware security modules, provide security APIs, such as the PKCS#11 Smartcard interface,implemented as low-level software embedded either in the devices themselves or in their drivers.

In a well-engineered application, almost all security mechanisms can be confined to a fewstandard cryptographic applications, consisting of both protocols and hardware-based APIs. Thedesign and implementation of cryptographic applications is particularly error-prone because itrequires an understanding of both the underlying mathematics as well as an awareness of real-world threats and constraints. Indeed, there is a long history of attacks on widely-distributedand thoroughly-vetted cryptographic protocols and APIs, often because they failed to accountfor a specific application-level threat, or because they presumed too strong a guarantee from acryptographic primitive. Consequently, the verification of cryptographic applications remainsan active area of research, and will be a central focus of the team.

At the next level up, the application consists of the client and server software that use cryp-tographic applications to enforce their high-level security goals, such as access control policies.The majority of this software is not security-critical; for example, most of the code in a webserver never sees any secret data and can be safely assumed to be under the control of theadversary with no adverse effects on the security of a particular web application. However, westill rely on some client code, such as the JavaScript that receives a password from the user,and on some server code, such as the authentication and access control checking program, andon the security of the backend database. Indeed, well over fifty per cent of the top softwarevulnerabilities3 currently exploited by hackers lie precisely in this kind of client and web appli-cation code. Although standard program verification tools are applicable to the verification ofapplication code, such tools can typically only find simple, generic programming errors, such asthe absence of buffer overflows. We propose to extend these tools and build new tools that aretailored to cryptographic security analysis.

Verification approaches

The security of an application can be reduced to the correctness of its security-critical compo-nents, only some of which are detailed above. Ideally, we would verify all of these components.In practice, not all of their designs and code are available for analysis, and to pragmaticallybound our effort, we will focus our efforts in some directions and not others. For example,

3http://www.sans.org/top25-software-errors, https://www.owasp.org/index.php/Top_10_2010-Main

6

designing or verifying cryptographic algorithms is beyond the scope of our project, and so is theverification of low-level operating system software. However, verifying cryptographic protocolsand their implementations, security APIs, and web application software is well within our goals.

To understand the state-of-the-art in our target research areas, and to better define ourscientific goals, we make the following distinctions:

Cryptographic vs. Web applications Cryptographic protocols and security APIs are typi-cally designed and implemented by security experts and are open to community inspectionas part of open-source libraries written in C and Java. The semantics and desired behaviourof these programs is well understood; the subtlety of verification lies in the underlying cryp-tography and threat model. Consequently, verification tools for these applications tend tobe designed and used only by security experts. Conversely, web applications are writtenby website programmers in JavaScript, PHP, Java, and C# using extensive libraries. Along line of research on program verification has yielded effective verification tools for Javaand C#, and tools for JavaScript and PHP are beginning to appear. However, these toolsfocus on programming errors such as buffer overflows and input sanitization and oftencannot reason about concrete cryptographic guarantees.

Verifying models vs. implementations Cryptographic verification efforts typically focus onabstract models of protocols and APIs as a first step towards verifying their implemen-tations. Models do not account for awkward implementation details, such as messageformats and error handling. Hence, model verification tools can focus on the core designand provide early feedback to an application developer. Extending these tools so that theycan also verify implementations is an open area of research.

Symbolic vs. computational cryptography When verifying a cryptographic application,one must specify the security guarantees provided by the cryptographic primitives usedby the application. Mathematically, these are stated as probabilistic guarantees againsta computational (polynomial-time) adversary. However, this formulation has tradition-ally been considered awkward for automated verification tools to utilize. Instead, a moreabstract symbolic model of cryptography has become quite popular for verifying crypto-graphic protocols. Connecting the two models is an active area of research: computationalsoundness theorems show that, assuming additional hypotheses, security in the symbolicmodel implies security in the computational model. New verification tools that directlyoperate in the computational model have also begun to appear, but are not yet mature.

Verification vs. model-based testing vs. synthesis When both the model and the codefor an application are available, the natural approach is to verify that the code satisfiesthe model. If the code is unavailable, one may still obtain a high-level of assurance throughmodel-based testing, and in particular, one may discover important vulnerabilities. Con-versely, if the code remains to be written, one may synthesize the implementation directlyfrom the model to obtain an application that is secure-by-construction. These three ap-proaches are complementary: when developing a new distributed application, all threesituations are likely to obtain for different parts of the code.

1.3 Scientific goals

The goal of Prosecco is to help developers to program securely with cryptography. Our visionis that, over its lifetime, Prosecco will contribute to making the use of formal techniques whenprogramming with cryptography as natural as the use of an IDE.

7

To this end, our long-term goals are to design and implement programming language abstrac-tions, cryptographic models, verification tools, and verified security libraries that developers canuse to deploy provably secure distributed applications. Our target applications include cryp-tographic protocol implementations, hardware-based security APIs, smartphone- and browser-based web applications, and cloud-based web services. In particular, we aim to verify the fullapplication: both the cryptographic core and the high-level application code. We aim to verifyimplementations, not just models. We aim to account for computational cryptography, not justits symbolic abstraction.

These goals can only be achieved if we combine our individual expertise and research direc-tions into fruitful collaborations. To kick-start this, we identify three key focus areas for ourresearch in the short- to medium term:

Symbolic verification of cryptographic applications Our goal is to develop our own se-curity verification tools for models and implementations of cryptographic protocols andsecurity APIs using symbolic cryptography. Our starting point is the tools we have previ-ously developed: the specialized cryptographic prover ProVerif, the reverse engineering andformal test tool Tookan, and the security type systems F7 and F* for the programminglanguage F#. These tools are already used to verify industrial-strength cryptographicprotocol implementations and commercial cryptographic hardware.

Working as a team gives us the opportunity to bring these approaches together. We intendto combine F7-style typechecking with ProVerif-style automated verification to obtain thebest of both worlds: swift verification of correct code, useful feedback (i.e. attacks) onbuggy code. We will extend Tookan with ProVerif-style abstractions to allow us not justto find attacks on vulnerable APIs but to verify security properties of correct ones.

Computational verification of cryptographic applications We aim to develop our owncryptographic application verification tools that use the computational model of cryptog-raphy. The tools include the computational prover CryptoVerif, and the computationallysound type system Computational F7 for applications written in F#. Working together, weplan to extend these tools to analyze, for the first time, cryptographic protocols, securityAPIs, and their implementations under fully precise cryptographic assumptions.

Provably secure web applications We plan to develop analysis tools and verified librariesto help programmers build provably secure web applications. The tools will include astatic and dynamic verification tool for client-side JavaScript web applications, annotatedJML libraries for verifying the security of Android smartphone applications, and the typesystems F7 and F* for verifying clients and servers written in F#. In addition, we willextend our security API tools to analyse the secure elements and cryptographic roots-of-trust embedded in new-generation smartphones. We plan to combine these tools toanalyze the security of multi-party web applications, consisting of clients on browsers andsmartphones, and servers in the cloud.

2 Symbolic verification of cryptographic applications

2.1 Background

Despite decades of experience, designing and implementing cryptographic applications remainsdangerous error-prone, even for experts. This is partly because cryptographic security is an

8

inherently hard problem, and partly because automated verification tools require carefully-crafted inputs and are not widely applicable. To take just the example of TLS, a widely-deployedand well-studied cryptographic protocol designed, implemented, and verified by security experts,the lack of a formal proof about all its details has regularly led to the discovery of major attacks(in 2003, 2008, 2009, and 2011) on both the protocol and its implementations, after many yearsof unsuspecting use.

As a result, the automated verification for cryptographic applications is an active area ofresearch, with a wide variety of tools being employed for verifying different kinds of applications.

In previous work, the we have developed the following three approaches:

ProVerif: a symbolic prover for cryptographic protocol models Tookan: an attack-finder for PKCS#11 hardware security devices F7: a security typechecker for cryptographic applications written in F#

Verifying cryptographic protocols with ProVerif Given a model of a cryptographic pro-tocol, the problem is to verify that an active attacker, possibly with access to some cryptographickeys but unable to guess other secrets, cannot thwart security goals such as authentication andsecrecy [143]; it has motivated a serious research effort on the formal analysis of cryptographicprotocols, starting with [108] and eventually leading to effective verification tools, such as ourtool ProVerif.

To use ProVerif, one encodes a protocol model in a formal language, called the applied pi-calculus, and ProVerif abstracts it to a set of generalized Horn clauses. This abstraction is asmall approximation: it just ignores the number of repetitions of each action [83], so ProVerifis still very precise, more precise than, say, tree automata-based techniques. The price to payfor this precision is that ProVerif does not always terminate; however, it terminates in mostcases in practice, and it always terminates on the interesting class of tagged protocols [82].ProVerif also distinguishes itself from other tools by the variety of cryptographic primitives itcan handle, defined by rewrite rules or by some equations, and the variety of security propertiesit can prove: secrecy [80, 55], correspondences (including authentication) [9], and observationalequivalences [81, 8]. Observational equivalence means that an adversary cannot distinguish twoprocesses (protocols); equivalences can be used to formalize a wide range of properties, but theyare particularly difficult to prove. Even if the class of equivalences that ProVerif can proveis limited to equivalences between processes that differ only by the terms they contain, theseequivalences are useful in practice and ProVerif is the only tool that proves equivalences for anunbounded number of sessions.

Using ProVerif, it is now possible to verify large parts of industrial-strength protocols such asTLS [26], JFK [3], and Web Services Security [25], against powerful adversaries that can run anunlimited number of protocol sessions, for strong security properties expressed as correspondencequeries or equivalence assertions. ProVerif is used by many teams at the international level, andhas been used in more 30 research papers (references available at http://www.proverif.ens.fr/proverif-users.html).

Verifying security APIs using Tookan Security application programming interfaces (APIs)are interfaces that provide access to functionality while also enforcing a security policy, so thateven if a malicious program makes calls to the interface, certain security properties will continueto hold. They are used, for example, by cryptographic devices such as smartcards and HardwareSecurity Modules (HSMs) to manage keys and provide access to cryptographic functions whilst

9

keeping the keys secure. Like security protocols, their design is security critical and very difficultto get right. Hence formal techniques have been adapted from security protocols to securityAPIs.

The most widely used standard for cryptographic APIs is RSA PKCS#11, ubiquitous indevices from smartcards to HSMs. A 2003 paper highlighted possible flaws in PKCS#11 [94],results which were extended by formal analysis work using a Dolev-Yao style model of thestandard [12]. However at this point it was not clear to what extent these flaws affected realcommercial devices, since the standard is underspecified and can be implemented in many dif-ferent ways. The Tookan tool, developed by Steel in collaboration with Bortolozzo, Centenaroand Focardi, was designed to address this problem. Tookan can reverse engineer the particularconfiguration of PKCS#11 used by a device under test by sending a carefully designed seriesof PKCS#11 commands and observing the return codes. These codes are used to instantiate aDolev-Yao model of the devices API. This model can then be searched using a security protocolmodel checking tool to find attacks. If an attack is found, Tookan converts the trace from themodel checker into the sequence of PKCS#11 queries needed to make the attack and executesthe commands directly on the device. Results obtained by Tookan are remarkable: of 18 com-mercially available PKCS#11 devices tested, 10 were found to be susceptible to at least oneattack.

Verifying cryptographic applications using F7 Verifying the implementation of a pro-tocol has traditionally been considered much harder than verifying its model. This is mainlybecause implementations have to consider real-world details of the protocol, such as messageformats, that models typically ignore. This leads to a situation that a protocol may have beenproved secure in theory, but its implementation may be buggy and insecure. However, withrecent advances in both program verification and symbolic protocol verification tools, it hasbecome possible to verify fully functional protocol implementations in the symbolic model.

One approach is to extract a symbolic protocol model from an implementation and thenverify the model, say, using ProVerif. This approach has been quite successful, yielding averified implementation of TLS in F# [26]. However, the generated models are typically quitelarge and whole-program symbolic verification does not scale very well.

An alternate approach is to develop a verification method directly for implementation code,using well-known program verification techniques such as typechecking. F7 [4] is a refinementtypechecker for F#, developed jointly at Microsoft Research Cambridge and INRIA. It imple-ments a dependent type-system that allows us to specify security assumptions and goals asfirst-order logic annotations directly inside the program. It has been used for the modular ver-ification of large web services security protocol implementations [28]. F* [52] is an extensionof F7 with higher-order kinds and a certifying typechecker. Both F7 and F* have a growinguser community. The cryptographic protocol implementations verified using F7 and F* alreadyrepresent the largest verified cryptographic applications to our knowledge.

2.2 Related work

Protocol verification tools There exist many different protocol verification tools in thesymbolic model. We mention the main approaches here; a more complete survey can be foundfor instance in [1, Section 1.4].

For a bounded number of sessions and a bounded message space, one can explore the full statespace by model checking, for instance using CASPER/FDR [137]4, Mur [139], Maude [107],

4http://web.comlab.ox.ac.uk/people/Gavin.Lowe/Security/Casper/

10

or SATMC [62] which is integrated in AVISPA5. If the number of sessions is bounded but notthe message space, the problem of verifying protocol security is still decidable [150] and can behandled by constraint solving (CL-AtSe [92]) or by extensions of model checking (OFMC [77]),both integrated in AVISPA. These techniques allow one to find attacks, but not to prove thesecurity of protocols, since an attack may appear in an unexplored part of the state space dueto the the bounded sessions assumption.

In the case of an unbounded number of sessions, the problem is undecidable [110]. One ofthe first approaches to protocol verification was the specialized logic BAN [87]; a more recentand rigorous logic is PCL [111, 103]. One can also prove protocols using interactive theoremprovers such as Isabelle [146], which require much user effort. Scyther [102] relies on strandspaces [114] and uses trace patterns to analyze a group of traces simultaneously; it sometimeslimits the number of sessions to guarantee termination. Alternatively, one can use abstractions,for example by tree automata [141, 122, 118] as in TA4SP [84] integrated in AVISPA, by Hornclauses in the class H1 [123] as in ISpi6, or by general Horn clauses [160] which is the methodused in ProVerif.

Security API analyses The first flaws in security APIs were found by Longley and Rigby [136],who used Prolog to investigate a Dolev-Yao style model of a key management API of an HSM.Later Anderson [60], Bond [85], and Clulow [94] discovered more such attacks by manual anal-ysis and by constructing ad-hoc formal tools. A first effort to apply more general formal tools,specifically the automatic first-order theorem prover Otter, was not especially successful, [161].The researchers lacked experience with the tools, and one member of the team later remarkedthat It ended up being more about how to use the tools than about analyzing the device.[128]. Later formal work by Steel [51], Cortier, Keighren and Steel [39], and Cortier, Delauneand Steel [38] was more fruitful, yielding decidability results for fragments of the Dolev-Yaomodel useful for modelling relevant examples such as the IBM CCA API, the discovery of newattacks by automated analysis of these models, and proofs of security in the abstract model forfixed version of the API. Courant and Monin used Coq to verify another proposed fix for theIBM design [101].

Verified cryptographic protocol implementations CSur was the first tool to analyzethe source code of cryptographic protocols [124]; it can verify protocol code in C annotatedwith logical assertions, by generating proof obligations for an external first-order-logic theorem-prover. ASPIER [90] has been applied to verify code of the central loop of OpenSSL. ASPIERis based on software model-checking techniques, and proves properties of OpenSSL assumingbounded numbers of active sessions.

Typing [53, 54, 55, 86] has long been used as a proof technique for cryptographic protocols. Inparticular, the Cryptic tool [120, 121, 119] was influential in developing a security type system forcryptographic models. F7 is the first typechecker to use refinement types for cryptography. Itsunderlying type system has been influential in a number of other projects and has been extendedand implemented as part of the typecheckers F5, Fine, and F*, and applied to zero-knowledgeprotocols, multi-tier web languages, and multi-party secure sessions [66, 67, 70, 27, 126].

Types for information flow and authorization Type systems for information flow havebeen developed for code written in many languages, including Java [142], ML [148], and Haskell [135].

5http://www.avispa-project.org6http://www.lsv.ens-cachan.fr/~goubault/ISpi/

11

Further works extend them with support for cryptographic mechanisms [64, 63, 159, 117]. Thesesystems seek to guarantee non-interference properties for programs annotated with confidential-ity and integrity levels. In contrast, typical verifications in F7 only seek to guarantee assertion-based security properties, commonly used in authorization policies and cryptographic protocolspecifications, and disregard implicit flows of information.

The AURA programming language has a type system [158, 129] that enforces authorizationby relying on value-dependent types, but it takes advantage of the Curry-Howard isomorphismfor a particular intuitionistic logic [57]; hence, proofs are manipulated at run time, and may bestored for later auditing; in contrast, F7 erases all formulas and discards proofs after typecheck-ing. Fable [155] is a core formalism for expressing security policies; its type system does not initself guarantee security properties, but additional proofs can build on type safety to establishproperties including access control, information flow, and provenance.

2.3 Proposed research

We propose to continue to pursue the scientific goal of automatic verification of security protocolsand their implementations, in particular by exploiting synergies between the tools we developedin previous groups to open up new research directions. We will address the following scientificchallenges, amongst others:

Reasoning with models with mutable state shared across protocol sessions Reasoning with unbounded data structures such as are used in XML based protocols

or group protocols

Proving equivalence properties that can be used to express strong notions of securityand privacy

Verifying implementations of protocols and APIs, where there remains much to be done

Models with mutable state The tool ProVerif that we have developed is essentially reachingmaturity. However, it currently handles the internal state of the protocol in a very approximateway: modeling the state as a message sent on a private channel, ProVerif just remembers theset of messages sent on that channel, but not their order or number of repetitions. We wouldlike to provide a more precise treatment of state in ProVerif, which would be useful in particularfor verifying security APIs: one of the properties of APIs that distinguish them from protocolsis their use of global mutable state to vary execution. Some works have already tackled thisproblem: [140] handles sets in which one can remove elements; [61] handles a state that consistsof a finite number of global memory cells. Froschle and Steel proposed ProVerif-like abstractionsfor fresh material generated by APIs [47], and Delaune et al. gave safe reductions for ProVerifmodels when dealing with particular state registers in the TPM [45]. A first step would be tointegrate this work inside ProVerif, but we will also look for extensions in order to support moregeneral stateful protocols, such as those using monotonic counters. This will allow us to treatAPIs such as that of the Trusted Platform Module (TPM) as well as designs for networked keymanagement servers such as that recently proposed by Cachin and Chandran at IBM [89]. Itcould also allow us to use ProVerif as a backend to Tookan instead of the current bounded modelchecker, allowing the possibility of direct verifications with unbounded numbers of commandcalls. Robert Kunnemann will start this work as part of his PhD, and hence we expect to seesome results in the short term, though full implementation of state abstraction in ProVerif is amedium term objective.

12

Unbounded data structures ProVerif currently handles only fixed-size data structures. Weplan to extend it to variable-size data structures, such as unbounded lists, which are used inXML protocols or in some group protocols. This extension introduces an additional cause ofundecidability, since the size of data structures is not bounded. Hence, it requires an extension ofthe resolution algorithm used by ProVerif with additional approximations so that the algorithmterminates. We will design, prove correct, and implement this extension. This extension willalso be a starting point to verifying group protocols with unbounded numbers of sessions andparticipants. Miriam Paiola is working on this topic as her PhD, hence this is a short termobjective.

Equivalence Properties We aim to propose security API models that capture stronger secu-rity properties based on equivalence notions such as strong secrecy and indistinguishability. Thislatter property provides a natural way to model privacy: roughly speaking, if an attacker cannottell two executions apart that are carried out by different principals, then they have preservedtheir privacy. Privacy properties arise in APIs used, for example, in RFID transport tokens,on-vehicle toll collection devices, and smart utility meters: scenarios in which we want to achieveauthenticity properties (the right person pays for the right service) at the same time as privacy(users cannot be tracked, individual electricity usage patterns are not revealed). ProVerif can al-ready treat such notions to some extent in the protocol world. However, the class of observationalequivalences that ProVerif can prove is currently limited. We plan to study extensions of thisclass. In particular, in the short term, in collaboration with Ben Smyth, we plan to formally jus-tify the extension that allows swapping of terms inside processes that he has implemented [106].This extension is useful in practice for proving privacy properties of some e-voting protocols.Transferring this work to APIs presents some particular challenges, in semantics, because of theinteraction between global state and executions observable to the attacker, and in algorithms,because the size of the set of messages available that will require much more efficient algorithmsfor deducing equivalence. This is a medium term objective that will be the subject of a collab-oration under a recently funded ANR JCJC project run by Stephanie Delaune (INRIA SECSI)of which Steel is a named participant http://www.lsv.ens-cachan.fr/Projects/anr-vip/.

Implementations So far, our main efforts in verifiying protocol implementations is a symbolicmodel centre on F7, a typechecker which takes code written in F# and security specificationswritten as refinement type annotations and verifies that the program satisfies its specificationby generating first-order logic proof obligations that can be solved by an SMT solver. In partic-ular, for cryptographic protocol implementations written in F#, typechecking can prove typicalauthenticity and secrecy goals under the usual symbolic model of cryptography. Currently,however, the typechecker only accepts a subset of F# and cannot handle common high-levelprogramming features such as mutable state, objects, and classes.

Typechecking is modular, which means that we can verify each module of the code (and eveneach function) separately. Hence, verification time with F7 increases roughly linearly in the sizeof the code. On the other hand, this scalability comes at the cost of full automation. Whenusing tools such as ProVerif, the user needs to provide little or no input beyond the protocolmodel. To use typechecking, the user must annotate each function and each cryptographic keywith its detailed security specification. In some cases, this annotation burden can amount to alarge percentage of the coding effort.

In the short term, we propose to improve F7 (and in due course, F*) in the following ways:

Extend the back-end of the typechecker to generate proof obligations for Why, rather than

13

for a single SMT solver. Why is capable of driving several SMT solvers in parallel canalso generate proof goals in Coq. Moreover, it provides a nice user interface for debuggingverification failures which would significantly improve the F7 user experience.

Design and implement a local type inference algorithm for F7 to reduce the annotationburden on the programmer. Existing refinement type inference algorithms, such as LiQuidTypes [149], are not able to infer the complex security types required by cryptographicapplications. We propose to implement a new type inference algorithm that combines localtype inference with user annotations to obtain precise yet compact type specifications.

In the medium term, we plan to investigate the following extensions:

Extend the input language of F7 to accept mutable state, objects, and classes. This willrequire new theoretical developments to prove that the extended type system is sound.Moreover, the extension may well result in more complex proof obligations for the SMTsolver, and hence require careful engineering to manage this complexity.

Combine type-based analyses with ProVerif-style verification. In earlier work, we imple-mented a translation from F# programs to ProVerif models [26]. The advantage of usingProVerif is that it is able to discover attacks and counterexamples very efficiently. Con-versely, typechecking is better for scalable proofs of security. We would like to combinethese approaches to obtain the best of both worlds.

Beyond protocol implementations, a major criticism of existing research on security APIs isthat it only treats abstract models of APIs and not the real code implementing the functionalitybehind the interface. In many ways the situation is similar to that in security protocols five orsix years ago, but while much progress has been made on verifying implementations of protocols,work on APIs is still some way behind. A major aim of our new project is to bring techniquesfrom verification of cryptographic protocol implementations to bear on security API problems.The specificities of APIs again provide some new challenges here: the code written to run onthe embedded devices whose APIs interest us tends to be written in low level languages like C,which requires a treatment of explicit pointers and other low-level features not required in thelanguages like F# or OCaml typically employed for producing verified protocol implementations.There are existing works looking at C implementation of protocols however [124], and these willprovide a starting point: in particular, existing well-established links with Andrew Gordon(MSR Cambridge and University of Edinburgh) will be exploited - his teams recent work on Cimplementations represents perhaps the state of the art in the area [109].

In the medium term, we also aim to extend the approach to tackle security APIs thatemerge directly from code, where no other documentation is available. Examples include theAPIs offered for interprocess communication by smartphone apps: in the Android platform,each application is installed with specific rights to access sensitive data and resources (e.g. thetelephone functionality, address book), but may also offer functionality to other applications.Clearly the API must be designed to enforce certain security properties on this interface. Arecent trend in mobile devices is to include a specific hardware security chip or secure elementwhich provides a security API similar to those we have already examined. Investigating theformal verification of applications interacting which each other and also the API of the securitychip promises to be a fascinating avenue of research in the medium term.

Cryptographic Soundness In the medium term, we also plan to provide support for compu-tational cryptographic soundness results in ProVerif, so that ProVerif automatically verifies both

14

the security protocol in the symbolic model and the assumptions of a computational soundnesstheorem, in order to prove security in the computational model. This idea was already imple-mented in a module for AVISPA for a bounded number of sessions [96]. However, ProVerif is aparticularly well-suited tool for this goal, since it can prove security in the symbolic model for anunbounded number of sessions, so that, by computational soundness, one can obtain security inthe computational model also for an unbounded number of sessions (polynomial in the securityparameter). ProVerif can also verify observational equivalences in the symbolic model, whichcan formalize a notion of secrecy closer to the computational notion of secrecy, and is supportedby some computational soundness results [95]. A common assumption of computational sound-ness theorems is the absence of key cycles (such as a key encrypted under itself), so a first stepfor this goal would be to extend ProVerif so that it can verify the absence of key cycles for anunbounded number of sessions (current results can prove the absence of key cycles only for abounded number of sessions [97].)

Development of tools We see tool development as fundamental to the Prosecco strategy,both as a a driver for new scientific results and a vehicle for dissemination. In the context ofverification in symbolic models, we foresee the following strategy.

ProVerif can be seen as a tool reaching maturity. One of our main objectives will be tofacilitate its wider adoption by improving its interface and developing associated tools such asa protocol simulator, to help users verify that they have correctly specified the protocol theywant to verify. In order to reach this goal, we plan to employ a part-time engineer from INRIAsexperimentation and development service (SED).

Tookan is already the subject of a technology transfer action by the CSATT (comite desuivi des actions de transfert technologique), who have provided cash funding and a softwareengineer for 12 months. The immediate aim is to produce a mature version of the prototypetool with a better user interface and better performance. In the medium term, transfer of theIP to a start-up or an existing SME is planned.

For the F7 line of work, ultimately our goal is to build a verification framework that pro-grammers can easily use to build and verify their cryptographic applications. In the short term,our framework is based on the F7 typechecker for F# programs, using an SMT solver Z3 at theback-end. In due course, we aim to support other programming languages and back-end solvers.

3 Computational verification of cryptographic applications

3.1 Background

Proofs done by cryptographers in the computational model are mostly manual. Our goal isto provide computer support to build or verify these proofs. In order to reach this goal, wehave already designed the automatic tool CryptoVerif, which generates proofs by sequences ofgames. Much work is still needed in order to develop this approach, so that it is applicable tomore protocols. We also plan to design and implement techniques for proving implementationsof protocols secure in the computational model, by generating them from CryptoVerif specifi-cations that have been proved secure, or by automatically extracting CryptoVerif models fromimplementations.

An alternative approach is to directly verify cryptographic applications in the computationalmodel by typing. A recent work [116] shows how to use refinement typechecking in F7 to provecomputational security for protocol implementations. In this method, henceforth referred to ascomputational F7, typechecking is used as the main step to justify a classic game-hopping proof

15

of computational security. The correctness of this method is based on a probabilistic semanticsof F# programs and crucially relies on uses of type abstraction and parametricity to establishstrong security properties, such as indistinguishability.

In principle, the two approaches, typechecking and game-based proofs, are complementary.Understanding how to combine these approaches remains an open and active topic of research.

3.2 Related work

Computational proofs made by cryptographers are typically presented as sequences of games [152,79]: the initial game represents the protocol to prove; the goal is to show that the probability ofbreaking a certain security property is negligible in this game; intermediate games are obtainedeach from the previous one by transformations such that the difference of probability betweenconsecutive games is negligible; the final game is such that the desired probability is obviouslynegligible from the form of the game. The desired probability is then negligible in the initialgame. Halevi [127] suggested to use tools for mechanizing these proofs, and several techniqueshave been used for reaching this goal.

CryptoVerif [10, 30, 32, 34] is such a tool. It generates proofs by sequences of games au-tomatically or with little user interaction. The games are formalized in a probabilistic processcalculus. CryptoVerif provides a generic method for specifying security properties of many cryp-tographic primitives. It proves secrecy and authentication properties. It also provides a boundon the probability of success of an attack. It considerably extends early works by Laud [130, 131]which were limited either to passive adversaries or to a single session of the protocol. More re-cently, Tsahhirov and Laud [157, 133] developed a tool similar to CryptoVerif but that representsgames by dependency graphs; it handles only public-key and shared-key encryption and provessecrecy properties.

The tool CertiCrypt [76, 74, 88, 78, 73] enables the machine-checked construction and ver-ification of cryptographic proofs by sequences of games. It relies on the general-purpose proofassistant Coq, which is widely believed to be correct. EasyCrypt [75] generates CertiCryptproofs from proof sketches that formally represent the sequence of games, which makes the tooleasier to use. Nowak et al. [144, 145, 58] follow a similar idea by providing Coq proofs for severalbasic cryptographic primitives.

Proofs in the computational model can also be obtained through symbolic proofs and com-putational soundness results, as already outlined in Section 2, or by adapting techniques initiallydesigned for proving protocols in the computational model. For instance, Datta, Derek, Mitchell,Shmatikov, and Turuani [104, 105] have adapted the logic PCL (Protocol Composition Logic),first designed for proving protocols in the Dolev-Yao model, to the computational model. Othercomputationally sound logics include CIL (Computational Indistinguishability Logic) [72] anda specialized Hoare logic designed for proving asymmetric encryption schemes in the randomoracle model [98, 99].

Type systems [132, 134, 153, 100] can provide computational security guarantees. For in-stance, [132] handles shared-key and public-key encryption, with an unbounded number ofsessions. This system relies on the Backes-Pfitzmann-Waidner library [69]. A type inferencealgorithm is given in [65]. More recent work [68] establishes a computational soundness resultfor the symbolic model of cryptography as used by F7. Hence, if the underlying cryptographicalgorithms used for encryption and signatures are strong enough, any protocol implementationproved secure (symbolically) using F7 will also be secure in the computational model. Thisresult and the work on computational F7 [116] give us reason to be optimistic that modulartype-based computational verification of large protocol implementations may be within reach.

16

3.3 Proposed research

We have the following objectives:

Pursue mechanized cryptographic proofs in the computational model. Provide for certification of the correctness of these proofs. Tackle mutable global state and dynamic corruption models, where the attacker may

compromise cryptographic material during the lifetime of the system.

Prove security properties of implementations in the computational model.

Mechanized cryptographic proofs Our main vehicle for this research is the tool Cryp-toVerif. Finding a good trade-off between the powerful but time-consuming manually guidedproofs and the easy-to-use but more limited automatic proofs is an important challenge forimproving this tool. In the short term, we will improve the simplification of games, to allowmanual guidance from the user in order to prove facts (for instance, equalities between terms)that currently cannot be proved by the automatic proof strategy. We will also allow proofs thatrequire case distinctions, in particular depending on the order in which the various oracles ofare called, a feature that appears to be needed in a fair number of examples. We also plan toimprove the proof strategy so that CryptoVerif can guess more accurately the suitable gametransformations.

In the medium term, we will also apply CryptoVerif to new case studies: standards such asTLS (a very small part of this protocol was already proved using CryptoVerif [26]) or IKEv2; pro-tocols with weak secrets (passwords); group protocols, possibly with passwords; cryptographicschemes such as OAEP and its variants; e-voting, e-cash, and contract signing protocols, whichwill require support for new security properties. This will require CryptoVerif to handle morecryptographic primitives, in particular exclusive or, which is now partly supported because someequations that it satisfies (associativity) are not supported by CryptoVerif. Other extensionswill no doubt be required.

Certification Tools such as CryptoVerif do not provide an absolute security guarantee: anerror in the tool can lead to wrong proofs. Therefore, in the longer term, we also plan to studythe possibility of certifying CryptoVerif or its output, using a theorem prover such as Coq. Itwould also be interesting to study the interaction between CertiCrypt [76, 74] and CryptoVerif.For instance, it would be interesting to use CryptoVerif in order to generate a sequence of gamesthat would then be certified by CertiCrypt; however, this would probably require importantchanges in both tools, as they do not use exactly the same language for representing games.

Certification is also an important goal for typecheckers such as F7 and F*. In recent work,Strub et al. show how to verify the correctness of F* programs by using a typechecker to gener-ating certificates that can be independently checked by Coq. Hence, the programmer no longerneeds to trust that the typechecker has been implemented correctly. In the medium term, weplan to use this work to generate Coq certificates from cryptographic protocol implementationsthat can be linked to cryptographic definitions and theorems provided by the CertiCrypt library.Hence, automated proofs by typechecking in F* will be mapped down to proofs of correctnessin CertiCrypt, without the need to write these proofs by hand in Coq.

17

Mutable global state and dynamic corruption When dealing with security APIs thatuse cryptography, one would also like to prove security properties in the computational model.At present, there are very few results of this kind: Cachin and Chandran gave a manual proofof security for a key management interface in the computational model [89], though the securityproperty and proof were closely linked to the design of the interface and not a general approach.Kremer, Warinschi and Steel recently gave a general model for key management interfaces givinga notion of security that can be proved in the symbolic or computational model, but again onlymanual proofs on some simple examples [49]. There are two major obstacles to more satisfactoryresults that, if resolved, would also lead to new results on security protocol verification in general:handling global mutable state and dynamic corruption.

We plan to investigate support for global mutable state in CryptoVerif. In particular, weplan to support primitives with mutable state. This will be difficult, because the presence ofan internal state prevents syntactic transformations that duplicate, reorder, or remove callsto these primitives. We will also consider the case in which the API or protocol containsloops that update mutable state. Supporting mutable state will require extending the languagethat represents games, adapting the game transformations to this new language, and perhapsdesigning new game transformations and analyses. This is therefore a medium term objective.

A particular challenge for cryptographic verification of APIs is to deal with corruption:the occasional loss of keys must be modeled in a realistic analysis of an enterprise-wide keymanagement system, but corruption models pose significant theoretical challenges. To modelthem in CryptoVerif, we will improve the handling of the ordering of executed actions, sothat revealing a long-term key does not break the proof for sessions executed before the keyis revealed. We will also investigate how compositional notions of cryptographic security suchas simulatability might be applied to key management APIs. Here dynamic corruption posesfurther problems, (e.g. the so-called key commitment problem). Solving these problems is amedium term objective, that would also enable us to address problems in protocol verificationsuch as the verification of forward secrecy properties, in the presence of dynamic corruption.

Provably secure implementations We plan to consider two complementary approaches forthis goal: generating secure implementations from proved specifications as well as analyzingimplementations using computational F7. Both approaches are worth investigating; each ap-proach has its advantages and drawbacks, and depending on the desired application, a differentapproach may be more suitable. Over the medium term, we will compare these approaches andstudy their potential interactions and combinations.

Following the first approach, we will implement and prove a specialized compiler that trans-lates a CryptoVerif specification of the protocol into an OCaml implementation. Only theprotocol itself will be coded in CryptoVerif. The cryptographic primitives will be implementeddirectly in OCaml. (There already exists a cryptographic library for OCaml.) The CryptoVerifspecification makes it clear which security assumptions are made on each primitive. The codefor interacting with the network will also be written directly in OCaml; no security assumptionneeds to be made on this code: it can be considered as part of the adversary. An importantadvantage of OCaml as a target language is that it is memory safe, so we do not need to verifythe absence of buffer overflows in the manually written code. A preliminary prototype is beingimplemented by David Cade, but there is still much work to do before getting practical results.

In the short term, we will apply the compiler to basic protocol examples and to prove itscorrectness. Indeed, our goal is to obtain a proved implementation. CryptoVerif can beused to prove security properties of the specification, but we need to prove that our com-

18

piler faithfully translates that specification. This proof essentially consists in establishinga correspondence between the semantics of the CryptoVerif specification and the seman-tics of the generated OCaml programs. These semantics are fairly complex: protocols areprobabilistic; furthermore, since we consider several OCaml programs running in parallelon several machines (for example, a client and a server), the semantics of the implemen-tation includes non-determinism that we have to resolve, for instance by introducing anexplicit scheduler.

In the medium term, we plan to extend the input language to make it more expressive.First, we would like to separate the protocol itself from the set of assumptions on howthe protocol is used: the model. Currently, the protocol and the model are mixed in theinput language, and separating them would help clarify the specification. Adding privatechannels could be a way to do that. It could also help separate implementation details fromthe protocol itself. Second, we will add constructs to code more general loops, which arecurrently limited to loops without internal state, exploiting the corresponding extension ofCryptoVerif mentioned in the previous section. These points will require both extensionsof the compiler and extensions of CryptoVerif. We also plan to design a common inputlanguage for ProVerif, CryptoVerif, and our compiler. Therefore, we will be able, from asingle protocol specification, to verify it in the symbolic model and in the computationalmodel, and to generate a proved implementation from it. We will obtain a completeplatform for the design and verification of protocol specifications and for the generationof protocol implementations.

In the longer term, our goal is to obtain a tool powerful enough to apply it to complexpractical case studies, such as Kerberos or TLS. These case studies may require furtherextensions of the theory and of the tool, which we will design and implement.

The second approach involves extending the F7 typechecker for computational verificationof implementations. There are two main short-term tasks here:

With our post-doc Alfredo Pironti and collaborator Cedric Fournet, we are in the processof verifying a fully-featured implementation of TLS using computational F7. Our proofcovers features of the protocol never covered in previous analyses, such as padding, frag-mentation, alert messages, multiple protocol versions, multiple ciphersuites, and sessionrenegotiation. Hence, our implementation exposes many of the most recent attacks onTLS protocol implementations, and still we hope to be able to prove security under aprecise computational model of cryptography by typing. This work requires extensionsto F7 to precisely handle concrete bitstrings (and their lengths) and new computationallysound libraries for authenticated encryption. Our goal is to obtain the first computationalsecurity proof for a fully-featured cryptographic protocol implementation.

With our PhD student Evmorfia-Iro Bartzia, and collaborators Cedric Fournet, Pierre-Yves Strub, Benjamin Gregoire, and Gilles Barthe, we are extending Computational F7to allow relational logic specifications in the style used by the CertiCrypt project. Thiswill enable us to build computational proofs by typing that rely directly on the certifiedlibrary of cryptographic primitives in CertiCrypt. Bartzia will work on developing themeta-theory in Coq of our new type system Relational RCF (RRF), and on connecting itto the CertiCrypt libraries. In parallel, we plan to implement the new type system in F7and use it to verify cryptographic protocol implementations.

19

4 Provably secure web applications

4.1 Background

Web applications are fast becoming the dominant programming platform for new software,probably because they offer a quick and easy way for developers to deploy and sell their appsto a large number of customers. Third-party web-based apps for Facebook, Apple, and Google,already number in the hundreds of thousands and are likely to grow in number. Many of theseapplications store and manage private user data, such as health information, credit card data,and GPS locations. To protect this data, applications tend to use an ad hoc combination ofcryptographic primitives and protocols. Since designing cryptographic applications is easy toget wrong even for experts, we believe this is an opportune moment to develop security librariesand verification techniques to help web application programmers.

As a typical example, consider commercial password managers, such as LastPass, RoboForm,and 1Password7. They are implemented as browser-based web applications that, for a monthlyfee, offer to store a users passwords securely on the web and synchronize them across all ofthe users computers and smartphones. The passwords are encrypted using a master password(known only to the user) and stored in the cloud. Hence, no-one except the user should ever beable to read her passwords. When the user visits a web page that has a login form, the passwordmanager asks the user to decrypt her password for this website and automatically fills in thelogin form. Hence, the user no longer has to remember passwords (except her master password)and all her passwords are available on every computer she uses.

Password managers are available as browser extensions for mainstream browsers such asFirefox, Chrome, and Internet Explorer, and as downloadable apps for Android and Applephones. So, seen as a distributed application, each password manager application consists of aweb service (written in PHP or Java), some number of browser extensions (written in JavaScript),and some smartphone apps (written in Java or Objective C). Each of these components usesa different cryptographic library to encrypt and decrypt password data. How do we verify thecorrectness of all these components?

We propose three approaches. For client-side web applications and browser extensions writ-ten in JavaScript, we propose to build a static and dynamic program analysis framework toverify security invariants. For Android smartphone apps and web services written in Java, wepropose to develop annotated JML cryptography libraries that can be used with static analysistools like ESC/Java to verify the security of application code. For clients and web serviceswritten in F# for the .NET platform, we propose to use F7 to verify their correctness.

4.2 Related work

The analysis of JavaScript programs, APIs, and browser extensions is an extremely active areaof research, and we omit a full survey of related work. Recent publications in this domain rangefrom formal semantics [138], to automated analyses [156], to verified compilers [125]. However,verifying the correctness of a JavaScript-based web application remains an open problem. More-over, to our knowledge, previous work in this area does not account for the use of cryptographyto protect client-server interactions.

Java programs have been previously been analyzed for information flow [142, 71], but theseanalyses typically do not typically account for cryptography. Spi2Java generates provably correctJava code from cryptographic protocol models written in the spi-calculus [147] and a companion

7http://www.lastpass.com, http://www.roboform.com, http://www.1password.com

20

tool can extract ProVerif models from carefully-written Java code. However, verifying Javaprograms using ProVerif amounts to a whole program analysis that, although often effective,seldom scales well. Our approach using JML annotations is modular, so we can verify one classat a time. Still, there may be a balance to strike in terms of ProVerif-style automation andJML-style modularity.

Recent analyses of Android applications [113] have uncovered various vulnerabilities andresulted in new theory [91], new runtime analysis tools [112], as well as static analysis tools [93].These tools focus on finding bugs and vulnerabilities, and are not yet suitable for developingproved implementations. Moreover, they do not consider cryptographic libraries.

4.3 Proposed research

Scientific objectives We have two main scientific objectives towards building provably secureweb applications:

Writing and inferring security contracts for platform libraries and APIs such asthe Java Cryptography Architecture and the Android API

Static and dynamic security verification for dynamic scripting languages suchas JavaScript

Security Contracts for Android Libraries and APIs Applications written for the An-droid phone operating system are typically written in Java on top of a large library providedby the Android Software Development Kit. This library includes a complete implementation ofthe Java Cryptography Architecture/Java Cryptography Extension and a number of Androidspecific security libraries, such as those for managing permissions and for interacting with thephone user. Android users are free to install arbitrary applications on their phone; indeed atypical phone may have dozens of apps installed8 and some of these may contain malware thatattempts to steal the phone users private data9. In this partially-trusted environment, applica-tion developers increasingly turn to cryptography to protect their application data from otherapplications on the same phone.

In the short- to medium term, we propose to extend existing static verification tools for Javato be able to verify the security of Android applications that use cryptography. To this end,in the short-term, we propose to build fully annotated JML interfaces for all security-relevantlibrary classes in the Android SDK. In a style inspired by our cryptographic libraries in F7, theannotations for the Java cryptographic interfaces encode security guarantees provided by thesymbolic model of cryptography. Hence, an application developer using these libraries couldverify his application use a standard JML-based static analysis tool, such as ESC/Java [115]. Ina preliminary study with an intern, Quentin Lefebvre, we wrote and verified one such applicationby annotating a small set of libraries. The next step is to generalize the method so that it isapplicable to a wider range of Android applications.

In addition, we plan to investigate the formal verification of emerging applications (e.g.Google Wallet) that use secure elements, security chips embedded in smartphones that offersecurity APIs similar to smartcards. At present these devices are typically closely coupled to theNFC transmitters for wireless payment applications. Often the chip can only be accessed whenthe OS of the smartphone is in some secure execution mode, facilitated by the CPU. Howeverthere is a strong drive to open up the functionality of the secure element in order to permit more

8http://blog.nielsen.com/nielsenwire/consumer/nielsens-new-app-playbook-debunks-mobile-app-store-myth/9http://www.informationweek.com/news/security/mobile/231300257

21

applications to make use of it, e.g. as a transport payment token or an ID card. We intend toleverage our expertise in security API analysis and application verification to together developnew techniques for verifying such applications. This is a longer term objective, as it will requiredevelopment of our analysis of cryptographic applications in Java as well as attention to OSlevel details in our API analysis.

Static and dynamic security verification for JavaScript JavaScript is a popular scriptinglanguage for web applications. It is used extensively to program websites such as GMail, third-party APIs such as Facebook Connect, and browser extensions such as LastPass. JavaScript isa dynamic programming language, in the sense that variables may be reassigned to values of adifferent type, object fields may be added or deleted at any time, and code may be downloadedor computed and evaluated at runtime. As a result, a purely static verification approach isunlikely to be successful for JavaScript programs.

We propose to build a general verification framework based on a mixture of static and dy-namic analysis. We begin with a purely dynamic approach that attempts to monitor JavaScriptprograms without interfering in their execution, and over time, we propose to use static analysesmore aggressively in order to catch errors as early as possible. Our framework consists of thefollowing components:

A contracts library for JavaScript that enables script writers to annotate their programswith logical security specifications, written as pre- and post- conditions of functions andobject invariants. Hence, cryptographic functions can be annotated with the appropri-ate security guarantees and sensitive browser operations can be protected by demandingcontracts. This is a short-term goal, already under development.

A browser extension (also written in JavaScript) that takes a contract-annotated JavaScriptprogram and injects a monitor that looks for contract violations at runtime. This extensiongenerates logical proof obligations that are sent to an SMT solver. If the SMT solver failsto prove a goal, we assume that a contract may have failed. The weakness of this approachis that the monitored JavaScript may try to evade the contract checking extension by dis-abling the checking code. This is a typical example where the flexibility of JavaScript canturned against its verification tools. This is a short-term goal, already under development.

A static type system for JavaScript that can be used to aggressively verify some propertiesof the program before execution, leaving other properties to the run-time monitor. Inparticular, the static type system will look for unintended information flows and incorrectuses of cryptography before executing potentially malicious code downloaded from theInternet. This is medium-term goal.

The target applications for our JavaScript tools are browser extensions and website scriptsthat handle sensitive data and perform cryptographic operations. Our first case study con-sists of a series of password manager browser extensions. Our second case study consists ofimplementations of the OAuth 2.0 protocol in a variety of Facebook Connect websites.

Towards end-to-end security verification of web applications In the medium- to long-term, we propose to build a verified open-source library to help developers build secure webapplications, including, for example, JavaSript and Smartphone applications as clients and .NETweb services as servers. The library will have three components:

22

A suite of cryptographic protocols implemented in F# and verified using the F7 type-checker. We already have verified implementations of TLS and Web Services Security andwe propose to extend these to cover implementations of SSH, IPsec, and Kerberos.

Verified F# libraries for manipulating XML (and XHTML) documents through the Docu-ment Object Model. The core of any website is a program that manipulates web pages anddatabases. It is essential to verify that this program does not unwittingly leak sensitiveinformation, through error messages for example. We propose to build a verified librarythat provides such guarantees.

Verified F# libraries for secure key and password management. Managing cryptographicsecrets is one of the most difficult tasks for a web server. We propose to build verifiedlibraries for this task, potentially using security APIs, as formalized in previous analysisby Steel and the Tookan team.

Our library will be open-source and usable from any .NET language, including C#, F#, andVisual Basic. web services written in F# on top of our library can in turn be verified using F7.As a case study, we plan to validate our approach by building a provably secure web service thatmanages sensitive health information and is hosted in the Azure cloud.

5 National and international positioning

5.1 INRIA teams

SECSI The SECSI project is concerned with using logic to reason about security of systems,in particular security protocols and intrusion detection. A particular theme in recent work hasbeen the use of equivalences in term algebra models to model privacy properties of protocols fore.g. electronic voting and anonymous location-based services. An ANR Young Researcher grantawarded to Delaune includes Steel as a collaborator (ANR VIP, 20112014) and this work willprovide the basis for ongoing collaboration. Comon-Lundh works on computational soundness ofsymbolic models, and we will continue to collaborate on this theme via the ANR ProSe project(20102014). Outside of this work, the precise future direction of SECSI and its successor projectremain in flux since in addition to the departure of Steel to form the Prosecco project, Kremerhas left to join CASSIS. Whatever their future plans we will continue to pursue collaboration.

CASSIS The EPI CASSIS is also concerned with using abstract models to reason about se-curity of systems such as protocols. Rusinowitch, Turuani, and Vigneron work on protocolverification, recently in particular looking at decidability and complexity problems for modelsin non-free algebras (for example modelling XML trees, XOR, Diffie-Hellman etc.), and imple-mentation of the symbolic protocol analysis tool CL-AtSe.

Cortier holds an ERC Starting Grant ProSecure which addresses related topics to Pros-ecco. Cortiers team works primarily on developing decidability, compositionality and compu-tational soundness results for abstract models, work which is complementary to the use of toolssuch as ProVerif as we explain in section 2.3. Steel also collaborates with Cortier on certaintopics in security APIs, currently notions of security for key revocation and update. This col-laboration will continue (Steel is a named visiting researcher on the ProSecure grant). The maindifference between Prosecco and ProSecure is that we in Prosecco are concerned with realimplementations, not just abstract models, and we aim to construct analysis tools, which is notan aim of ProSecure.

23

MOSCOVA The former project of Bhargavan, EPI MOSCOVA will cease to exist in 2012.MOSCOVA was a wide ranging project covering several themes in semantics, concurrency, ab-stract process calculi, security, and verification. The future projects of the ex-MOSCOVA re-searchers in those areas not directly concerned with security are unclear, but it is safe to say wewill maintain close links, in particular with Jean-Jacques Levy and James Leifer.

CASCADE Our work is related to EPI CASCADE in that we both deal with security proofsof cryptographic protocols in the computational models. However, we consider different ap-proaches: we focus on developing tools for performing these proofs, while CASCADE focuseson manual security proofs and on other aspects of cryptography, including the design of newcryptographic schemes and cryptanalysis. Blanchet collaborates with other members of theCASCADE team, in particular with David Pointcheval whose explanations of computationalsecurity proofs were key to the design of CryptoVerif. We do plan to continue this collaboration.

COMETE The EPI COMETE is concerned with concurrent stochastic systems, in particularresearching design and applications of process calculi to such systems. This work touches nat-urally on security, in particular on quantitative notions of information flow and anonymity andprivacy in distributed systems. There is natural potential for collaboration here; indeed, an ap-plication for EU funding for a project researching formal analysis of privacy issues in distributedlocation-aware devices is currently in preparation, with Steel and Palamidessi (COMETE projecthead) named as co-ordinators.

ABSTRACTION EPI ABSTRACTION deals with program analysis by abstract interpre-tation. This is related to our work, especially to the verification of implementations of cryp-tographic applications and of distributed software. However, our team and ABSTRACTIONfocus on different targets: we focus on programs that use cryptography, including web andsmartphone applications, while ABSTRACTION focuses on programs that do not use cryptog-raphy, especially critical software, such as avionics software. They have a recent security-relatedproject of proving non-interference for avionics software, which does not overlap with our goalbut could be an opportunity for collaboration. We would also be very happy to collaborate withABSTRACTION on aspects of our project related to program analysis.

CELTIQUE EPI CELTIQUE deals with security as we do, but focuses on the productionof certificates that attest the well-behavedness of software, following the proof-carrying codeapproach. Therefore, CELTIQUE tackles a different and complementary problem to the one wewill consider.

INDES EPI INDES is concerned with models and languages for diffuse computing, and inparticular with the security of Web 2.0 applications. Historically, many researchers at INDEShave shared our interests on type systems for security. In particular, our proposal has strongconnections with the research of Tamara Rezk, who has worked on cryptographic compilers,information flow type systems, and on analysis tools for JavaScript. We hope to develop astrong collaboration with her through our project.

MARELLE EPI MARELLE focuses on the use of theorem provers to verify the correctness ofsoftware, especially software for scientific computation. Our project proposal is mainly relatedto the CertiCrypt and EasyCrypt projects of Benjamin Gregoire, which seek to build verified

24

libraries of cryptographic algorithms in Coq (and ease their proof using an SMT solver). Weare currently working on linking the F7 typechecker with the CertiCrypt framework, and lookforward to constructive collaborations with Benjamin on these topics.

Others: GALLIUM, PROVAL, SECRET, CARAMEL, SALSA, TANC The ProvalEPI is concerned with producing practical program verification tools. We already have severallinks with this group: their main tool platform, Why, has been used in recent (as yet unpublished)work and one of their ex-PhD students, Romain Bardou, has just taken up the position ofengineer on the Tookan project. We expect these links to be developed further.

The Gallium EPI focuses on the design, formalization, and implementation of programminglanguages and systems. The CompCert project of Xavier Leroy aims to develop a fully formalized(and verified) compiler for the OCaml language, using Coq as the proof environment. Since anumber of our proof techniques verify security only at the level of ML programs, we would liketo leverage CompCert to carry over these security proofs to the compiled code. In addition,Francois Pottier and Dana Xu share our interests in the use of dependent types and contractsfor verifying ML programs. We look forward to collaborating with them on these topics.

Several INRIA project-teams deal with cryptography and related topics. In particular, SE-CRET deals with symmetric key cryptography and codes, CARAMEL, SALSA, and TANCdeal with number theory. While they are related to cryptography, these teams are very differentfrom ours: they deal with the design and cryptanalysis of primitives, while we aim at provingcryptographic applications from assumptions on the primitives.

5.2 Other teams in France

Distributed and Complex Systems (VERIMAG) The Distributed and Complex Systemsgroup deals in particular with formal methods for computer security. They have worked onthe formal proof of protocols in the symbolic model and they have established computationalsoundness results. They have also designed frameworks and tools for proving security protocolsin the computational model, such as the logic CIL and tools for proving the security of encryptionmodes, and they participate to the CertiCrypt project. Their work is complementary to ours,and we collaborate within the ANR ProSe project (20102014).

INRIA-Microsoft Research Joint Centre and Microsoft Research The INRIA-MicrosoftResearch Joint Centre is a forum that enables researchers from Microsoft and INRIA to collab-orate on joint research projects. Pragmatically, the centre provides funds for Ph.D. studentsand Post-docs, and provides offices in Orsay for visiting Microsoft researchers. Bhargavan andBlanchet are part of the Secure Distributed Systems group headed by Cedric Fournet (MicrosoftResearch, Cambridge) and have co-authored several papers with members of this group and withother Microsoft researchers. Our new project will continue to be affiliated to the Joint Centreto benefit from such collaborations.

5.3 International teams

Microsoft Research: Redmond, Silicon Valley, Cambridge, Bangalore In addition tocollaborations at the INRIA-Microsoft Research Joint Centre, we have strong connections toresearchers at Microsoft Research in Redmond, Silicon Valley, Cambridge, and Bangalore. Inparticular, we have collaborated with Martn Abadi, Juan Chen, Cedric Fournet, Andrew Gor-don, Prasad Naldurg, and Nikhil Swamy, and we expect to continue these fruitful collaborations.

25

These researchers work on topics close to ours, and their groups, especially the ones in Redmondand Cambridge, can be considered as strong competitors to Prosecco.

University of Saarland, MPI-SWS, Saarbruecken The security group at the Universityof Saarland, chaired by Michael Backes, is concerned with many of the same problems as us:abstract formal models for cryptography, programming languages and verification for securitycritical software. One major difference is that their models of cryptographic security are de-veloped from the so-called Universal Composability or simulatability security notion, whereasours are based on the more traditional game-based semantics. At a very high level of abstrac-tion, one can think of the simulatability model giving security notions which are in some sensestronger but more restrictive than those of the game based model. Kunnemanns PhD projectaims to investigate how security notions for APIs may be recast in the simulatability model,which may help to clarify the differences between the models. In general, Backes group can beseen as a competitor to Prosecco.

Tartu Peeter Laud (Tartu University) is a pioneer of the idea of automating game-basedsecurity proofs. With his team, he implemented a tool similar to CryptoVerif, but using adifferent game representation based on dependency graphs; he also designed and implementeda computationally-sound type system. He tackles problems similar to us, with complementarytechniques.

Stanford John Mitchells group at Stanford University is without doubt one of the worldleading security and formal methods research groups. Their recent focus has been on provingformal security guarantees for subsets of Javascript. The group also carries out a lot of practicalwork evaluating commercial systems etc., but in their formal work they are in more or less directcompetition with Prosecco.

IMDEA Boris Kopf works on quantitative models for information flow. These models arepotentially useful for quantifying information leakage from security APIs, and we have alreadystarted a collaboration on this topic which we will continue. Gilles Barthe has worked on theformalisation of computational models for security protocols in the Coq proof assistant. Theuse of Coq means the proofs give strong assurance of security, though they require considerableuser effort. This can be seen as an alternative approach to an automated tool like CryptoVerif.

Chalmers, Cornell, UPenn There is a large international community working on languagebased security with semantic notions based on non-interference, a 30 year old idea that is stillthe subject of much research. In particular the most important groups are at Chalmers Uni-versity (Sweden), Cornell University and the University of Pennsylvania (USA). Although non-interference is not a core subject of research for the proposed Prosecco group it is sufficientlycentral to notions of language based security that ideas from the theory will frequently touchon our research, hence these groups can be seen as complementary.

A Biographies of team members

Karthikeyan Bhargavan Bhargavan has a degree in computer engineering from the IndianInstitute of Technology Delhi (1997) and a PhD in computer science from the University ofPennsylvania (2003). In 2002, he moved to Microsoft Research in Cambridge as a post-doc, and

26

continued there as a full-time researcher till 2009. His post-doctoral research focused on theformal specification and verification of cryptographic protocols for the web, including TLS andXML Web Services. In 2009, he stood first in the CR1 selection of INRIA Paris-Rocquencourtand joined project MOSCOVA. He was also selected as a part-time lecturer in computer scienceat Ecole Polytechnique, and continues to teach short courses at the Indian Institutes of Technol-ogy. In 2010, he was awarded a five-year ERC Starting Grant CRYSP whose goal was to createa new project more or less along the lines of Prosecco. He is authorized to supervise a PhDstudent at Ecole Polytechnique and expects to defend his HDR at ENS in ea