Prosecco Programming Securely with Cryptography

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 Bhargavan’s ERC-funded project CRYSP,Blanchet’s ANR-funded project ProSe, and Steel’s 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 bank’s 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 device’s 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 protocolsor 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 team’s 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 element’which 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 INRIA’sexperimentation 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


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 maycompromise 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 user’s passwords securely on the web and synchronize them across all ofthe user’s 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.


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 user’s 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/nielsen’s-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, 2011–2014) 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(2010–2014). 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. Cortier’s 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 (2010–2014).

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 Martın 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. Kunnemann’s 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 Mitchell’s 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 early 2012.

Bruno Blanchet Blanchet did his PhD in computer science at INRIA Rocquencourt (2000),on program analysis by abstract interpretation (thesis prize of Ecole Polytechnique). From 2001to 2010, he was CNRS researcher (charge de recherche) at the Computer Science Laboratory ofENS (LIENS). From 2001 to 2004, he was also independent research group leader (Nachwuchs-gruppenleiter) at the Max-Planck Institute from Computer Science (Saarbrucken, Germany). Hegot his habilitation a diriger des recherches in 2008 and became INRIA senior researcher (DR2)at LIENS in 2010. He is the author of over 30 journal and conference publications, and memberof 18 programme committees of major conferences. Blanchet’s recent research mainly focuseson the automatic verification of security protocols. In particular, he designed and implementedtwo protocols verifiers, ProVerif and CryptoVerif.

Graham Steel Steel holds a masters in mathematics from the University of Cambridge (1999)and a PhD in informatics from the University of Edinburgh (2004). He worked on postdocprojects in cryptographic protocol verification at the universities of Karlsruhe (Germany) andGenoa (Italy), before returning to Edinburgh where he studied the analysis of security of APIs forcryptographic modules used in the cash machine network. In 2007 he joined the Specification andVerification Laboratory (LSV) at the ENS-Cachan for a further post-doc studying the analysisof key management APIs. He was ranked first in the INRIA Saclay competitive selection forfull-time researchers (CR2) in 2008, and was promoted to CR1 in 2010. Steel’s current workon cryptographic API verification involves using formal techniques to construct and analyseabstract models of interfaces used on cryptographic devices. It includes the development of theTookan tool for security analysis of RSA PKCS#11 smartcards. Developed in collaboration withFocardi and the University of Venice, licenses for the tool have been granted to Boeing inc andBarclays Bank.

B Collaborations and grants

B.1 Research collaborations

CASCADE We plan to continue the collaboration with EPI CASCADE, on the automationof proofs by sequences of games, that Blanchet started. This collaboration was very helpful fordesigning the tool CryptoVerif and will be helpful for the future developments of the tool.

SECSI, CASSIS, VERIMAG We will collaborate with the EPI SECSI and CASSIS andwith VERIMAG within the ANR project ProSe (VERSO 2010) and ANR project VIP (2011-2014), on the proof of security protocols at three levels: the symbolic model, the computationalmodel, and the implementations.

27

Microsoft Research and MSR-INRIA We plan to continue our collaborations with MartınAbadi, Juan Chen, Cedric Fournet, Andrew Gordon, Prasad Naldurg, and Nikhil Swamy atMicrosoft Research. In particular, we intend to continue the development of our verificationtools F7 and F* with the Microsoft Research laboratories in Cambridge and Redmond. Inaddition, we expect to continue our strong collaborations with the MSR-INRIA Joint Centre,especially with Cedric Fournet and Pierre-Yves Strub.

Riccardo Focardi, Universita Ca’ Foscari, Venice Riccardo Focardi is the co-creator ofthe Tookan tool and continues to participate in its development. He has also worked on typesystems for security APIs. We expect this strong collaboration to continue.

Sergio Maffeis, Imperial College, London In collaboration with Sergio Maffeis, we aredeveloping of verification tools for web applications, particularly those written in JavaScript.We intend to continue this effort and share Ph.D. students and interns working on this topicover the coming years.

Ben Smyth, Toshiba Laboratories, Tokyo We have an on-going collaboration with BenSmyth on extensions of ProVerif to prove a larger class of observational equivalences. Smyth isalso interested in security APIs. We plan to continue this collaboration in the future.

B.2 Grants

• ERC Starting Grant CRYSP (2010-2015). Principal Investigator: Karthikeyan Bhargavan.Total grant: 1.4 MEuros. The CRYSP project proposes to build a new research team moreor less along the lines of Prosecco. Its focus is on the collaborative verification of securityfor cryptographic protocols and web applications that use cryptography. The grant allowsfor the hiring of 2 Post-docs, 4 Ph.D. students and several master’s interns and visitingprofessors. We have already hired a post-doc (Alfredo Pironti), a Ph.D. student (Evmorfia-Iro Bartzia), and several interns under this grant. We anticipate that the formation ofProsecco will prove extremely beneficial to the CRYSP project.

• ANR ProSe (2010-2014), https://crypto.di.ens.fr/projects:prose:main. PrincipalInvestigator: Bruno Blanchet. This is a collaborative project between INRIA Paris-Rocquencourt, LSV (EPI SECSI), INRIA Nancy Grand-Est (EPI CASSIS), VERIMAG(Distributed and Complex Systems team). Total grant: 440 kEuros, 145 kEuros for INRIAParis-Rocquencourt. This project deals with the proof of security protocols at three levels:the symbolic model, the computational model, and the implementations. It is a follow-upto the FormaCrypt project between LIENS (EPI ABSTRACTION and CASCADE), LSV(EPI SECSI), and LORIA (EPI CASSIS).

• INRIA CSATT Technology Transfer Action for Tookan. Following successful technologytransfer projects around the Tookan software with Boeing and Barclays Bank, INRIA haveprovided 12 months of funding for a software engineer (Romain Bardou) and 10 kEuros.

C Software and transfer objectives

ProVerif Symbolic protocol verifier, (C) ENS-CNRS-INRIA-MPII, by Bruno Blanchet, XavierAllamigeon, Ben Smyth.

28

Evaluation acccording to the Criteria for Software Self-Assessment (https://intranet.inria.fr/dg/vie/instances/ce/fichiers/SoftwareCriteria-V2-CE.pdf):

• A-3, SO-4, SM-3, EM-3, SDL-4, OC: DA-4, CD-4, MS-4, TPM-4.

• URL: http://www.proverif.ens.fr/

• Objective: Automatic verification of security protocols in the symbolic model. Autonomoussoftware, released under GNU GPL.

• Users: mainly researchers; mailing list [email protected]; 66 subscribers.

• Impact: ProVerif is one of the leading security protocol verifiers, at least in the researchcommunity. It has been used in more than 30 research papers by other authors and istaught in courses (references at http://www.proverif.ens.fr/proverif-users.html).

• State of the art: there exist many other security protocol verifiers (AVISPA, Maude-NPA,FDR, . . . ). The main distinguishing features of ProVerif are that it can prove protocols foran unbounded number of sessions, and that it can prove some process equivalences (i.e.,that an adversary cannot distinguish between two protocols).

• Approximately 25k NCLOC. Language: Ocaml. Development team: the project leader(Bruno Blanchet), sometimes with a student (Xavier Allamigeon, Ben Smyth, on-goingwork with Vincent Cheval). Development effort: about 42 man.months. No patent. Pub-lications: [3, 8, 9, 16, 19, 33, 55, 56, 80, 81, 82, 83, 59], plus 6 other conference papers forwhich we have listed journal versions.

CryptoVerif Cryptographic protocol verifier, (C) ENS-CNRS-INRIA, by Bruno Blanchet.Evaluation:

• A-3, SO-4, SM-2up, EM-3, SDL-4, OC: DA-4, CD-4, MS-4, TPM-4.

• URL: http://www.cryptoverif.ens.fr/

• Objective: Automatic verification of security protocols in the computational model. Au-tonomous software, released under CeCILL-B license.

• Users: researchers; mailing list [email protected]; 43 subscribers.

• Impact: CryptoVerif starts being used by others (see references at http://www.cryptoverif.ens.fr/cryptoverif-users.html), but it still needs to make progress before being widelyusable.

• State of the art: CryptoVerif was the first automatic protocol verifier in the computationalmodel. Other tools and approaches have appeared since then, for instance the verifier byLaud and Tsahhirov [157, 133], which uses a similar approach with a different represen-tation of cryptographic games, and the CertiCrypt/EasyCrypt framework which providesmachine-checked proofs [76, 74, 88, 78, 73, 75].

• Approximately 26k NCLOC. Language: Ocaml. Development team: the project leader(Bruno Blanchet), sometimes with a student (David Cade will be a co-author of the nextrelease). Development effort: about 36 man.months. No patent. Publications: [10, 31, 30,32, 34, 19].

29

Tookan PKCS#11 Compatible Security API analysis tool, (C) INRIA and Riccardo FocardiEvaluation:

• A-4, SO-4, SM-2up, EM-3, SDL-3, OC: DA-4, CD-4, MS-4, TPM-4.

• URL: www.tookan.gforge.inria.fr

• Objective: Reverse engineering of cryptographic devices, formal analysis of the resultingmodel, execution of suspected attacks on the device

• Users: Boeing, Barclays

• Impact: very positive feedback from our current users, demands for a copy from USCybersecurity Agency and GCHQ, object of a current INRIA CSATT Technology TransferAction.

• Tookan 1.0 is approximately 15k NCLOC of Java. Tookan 2.0 is being implemented inOCaml.

F7 Refinement types for F#, (C) Microsoft Research, by Karthikeyan Bhargavan, CedricFournet, and Andrew D. Gordon.

Evaluation:

• A-4, SO-4, SM-3up, EM-3, SDL-4, OC: DA-4, CD-4, MS-4, TPM-4

• URL: research.microsoft.com/f7

• Objective: Security verification of F# programs by refinement typing. Typechecker soft-ware released under Microsoft Research license.

• Users: researchers and students. Microsoft Research download, over 100 downloads. Usedas course software in MPRI, Dagstuhl, IIT Delhi.

• Impact: the type system underlying F7 has inspired extensions such as F5, Fine, and F*.F7 has been used to verify a variety of cryptographic protocols and protocol compilers. Itis the most scalable verification technique for cryptographic protocol implementations todate.

• Approximately 7k NCLOC. Language: F#. Version 1.0 was released in 2008, version2.0 has been released in 2011. Development team: Karthikeyan Bhargavan (lead), withcontributions from Cedric Fournet, Andrew D. Gordon, Jesper Bengtson.

Software under development In addition to the above software, which continue to evolve,we are actively developing new software packages as part of our research:

• A verified TLS library: A computationally verified implementation of TLS in computa-tional F7, (C) INRIA and Microsoft Research, by Alfredo Pironti, Karthikeyan Bhargavan,and Cedric Fournet, under development, 6k NCLOC. To be released under open sourcelicense. Evaluation: A-3, SO-3, SM-2, EM-2, SDL-4, OC: DA-4, CD-3, MS-3, TPM-3

• JavaScript analyzer: Static and dynamic contract checker for JavaScript, (C) INRIAand Sergio Maffeis, under development, 3k NCLOC. To be released under open sourcelicense. Evaluation: A-4, SO-4, SM-3, EM-3, SDL-4, OC: DA-4, CD-4, MS-4, TPM-4

30

• Android crypto verifier: A verification framework for Android cryptographic applica-tions, (C) INRIA, Karthikeyan Bhargavan and Quentin Lefebvre, under development. Tobe released under open source license. Evaluation: A-4, SO-4, SM-3, EM-2, SDL-4, OC:DA-4, CD-3, MS-3, TPM-3

Both the JavaScript analyzer and the Android crypto verifier are being developed under theERC Starting Grant CRYSP. Hence, they qualify for the ERC “Proof of Concept” funds whichare mean to help technology transfer. When one of these projects reaches maturity, we intendto apply for these funds, and use them to make our tools more widely applicable.

D Recent publications of the team (2006-2011)

Theses

[1] Bruno Blanchet. Verification automatique de protocoles cryptographiques : modele formel etmodele calculatoire. Automatic verification of security protocols: formal model and compu-tational model. Memoire d’habilitation a diriger des recherches, Universite Paris-Dauphine,November 2008.

[2] Graham Steel. Formal Analysis of Security APIs. Memoire d’habilitation a diriger desrecherches, Ecole Normale Superieure de Cachan, France, March 2011.

International journal papers with peer review

[3] Martın Abadi, Bruno Blanchet, and Cedric Fournet. Just fast keying in the pi calculus.ACM Transactions on Information and System Security (TISSEC), 10(3):1–59, July 2007.

[4] Jesper Bengtson, Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and SergioMaffeis. Refinement types for secure implementations. ACM Trans. Program. Lang. Syst.,33(2):8, 2011.

[5] Karthikeyan Bhargavan, Ricardo Corin, Cedric Fournet, and Andrew D. Gordon. Securesessions for web services. ACM Transactions on Information and System Security, 10(2),2007.

[6] Karthikeyan Bhargavan, Cedric Fournet, and Andrew D. Gordon. Verifying policy-basedweb services security. ACM Transactions on Programming Languages and Systems, 30(6),2008.

[7] Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and Stephen Tse. Verifiedinteroperable implementations of security protocols. ACM Transactions on ProgrammingLanguages and Systems, 31(1), 2008.

[8] Bruno Blanchet, Martın Abadi, and Cedric Fournet. Automated verification of selectedequivalences for security protocols. Journal of Logic and Algebraic Programming, 75(1):3–51, February–March 2008.

[9] Bruno Blanchet. Automatic verification of correspondences for security protocols. Journalof Computer Security, 17(4):363–434, July 2009.

31

[10] Bruno Blanchet. A computationally sound mechanized prover for security protocols. IEEETransactions on Dependable and Secure Computing, 5(4):193–207, October–December 2008.

[11] Ricardo Corin, Pierre-Malo Denielou, Cedric Fournet, Karthikeyan Bhargavan, andJames J. Leifer. A secure compiler for session abstractions. Journal of Computer Secu-rity, 16(5):573–636, 2008.

[12] Stephanie Delaune, Steve Kremer, and Graham Steel. Formal analysis of PKCS#11 andproprietary extensions. Journal of Computer Security, 18(6):1211–1245, November 2010.

[13] Graham Steel and Alan Bundy. Attacking group protocols by refuting incorrect inductiveconjectures. Journal of Automated Reasoning, 36(1-2):149–176, January 2006.

[14] Graham Steel. Formal analysis of PIN block attacks. Theoretical Computer Science, 367(1-2):257–270, November 2006.

Book

[15] Fabrizio Luccio, Linda Pagli, and Graham Steel. Mathematical and Algorithmic Founda-tions of the Internet CRC Press, July 2011.

Book chapters

[16] Bruno Blanchet. Using Horn clauses for analyzing security protocols. In Veronique Cortierand Steve Kremer, editors, Formal Models and Techniques for Analyzing Security Protocols,volume 5 of Cryptology and Information Security Series, pages 86–111. IOS Press, March2011.

[17] Riccardo Focardi, Flaminia L. Luccio and Graham Steel. An Introduction to Security APIAnalysis. In Foundations of Security Analysis and Design VI (FOSAD’10), volume 6858 ofLecture Notes on Computer Science, pages 35-65. Springer, 2011.

[18] Cedric Fournet, Karthikeyan Bhargavan, and Andrew D. Gordon. Cryptographic verifica-tion by typing for a sample protocol implementation. In Foundations of Security Analysisand Design VI (FOSAD’10), volume 6858 of Lecture Notes on Computer Science, pages66–100, 2011.

Invited conference publications

[19] Martın Abadi (invited speaker), Bruno Blanchet, and Hubert Comon-Lundh. Models andproofs of protocol security: A progress report. In Ahmed Bouajjani and Oded Maler,editors, 21st International Conference on Computer Aided Verification (CAV’09), volume5643 of Lecture Notes on Computer Science, pages 35–49, Grenoble, France, June 2009.Springer Verlag.

32

International conferences with peer review

[20] Jesper Bengtson, Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and SergioMaffeis. Refinement types for secure implementations. In 21st IEEE Computer SecurityFoundations Symposium (CSF-21), pages 17–32, 2008.

[21] Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and Stephen Tse. Verifiedinteroperable implementations of security protocols. In 19th IEEE Computer Security Foun-dations Workshop (CSFW’06), pages 139–152, July 2006.

[22] Karthikeyan Bhargavan, Cedric Fournet, and Andrew D. Gordon. Verified reference im-plementations of ws-security protocols. In Third International Workshop on Web Servicesand Formal Methods, pages 88–106, 2006.

[23] Karthikeyan Bhargavan, Andrew D. Gordon, and Iman Narasamdya. Service combina-tors for farming virtual machines. In Third Symposium on Trustworthy Global Computing(TGC), page 22, 2007.

[24] Karthikeyan Bhargavan, Andrew D. Gordon, and Iman Narasamdya. Service combinatorsfor farming virtual machines. In 10th International Conference on Coordination Models andLanguages, pages 33–49, 2008.

[25] Karthikeyan Bhargavan, Cedric Fournet, Andrew D. Gordon, and Nikhil Swamy. Verifiedimplementations of the information card federated identity-management protocol. In ACMSymposium on Information, Computer and Communications Security (ASIACCS), pages123–135, 2008.

[26] Karthikeyan Bhargavan, Cedric Fournet, Ricardo Corin, and Eugen Zalinescu. Crypto-graphically verified implementations for TLS. In ACM Conference on Computer and Com-munications Security (CCS), pages 459–468, 2008.

[27] Karthikeyan Bhargavan, Ricardo Corin, Pierre-Malo Denielou, Cedric Fournet, andJames J. Leifer. Cryptographic protocol synthesis and verification for multiparty sessions.In 22nd IEEE Computer Security Foundations Symposium (CSF-22), pages 124–140, 2009.

[28] Karthikeyan Bhargavan, Cedric Fournet, and Andrew D. Gordon. Modular verificationof security protocol code by typing. In 37th ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages (POPL’10), pages 445–456, 2010.

[29] Karthikeyan Bhargavan, Cedric Fournet, and Nataliya Guts. Typechecking higher-ordersecurity libraries. In 8th Asian Symposium on Programming Languages and Systems, pages47–62, 2010.

[30] Bruno Blanchet and David Pointcheval. Automated security proofs with sequences of games.In Cynthia Dwork, editor, CRYPTO’06, volume 4117 of Lecture Notes on Computer Sci-ence, pages 537–554, Santa Barbara, CA, August 2006. Springer Verlag.

[31] Bruno Blanchet. A computationally sound mechanized prover for security protocols. InIEEE Symposium on Security and Privacy, pages 140–154, Oakland, California, May 2006.

[32] Bruno Blanchet. Computationally sound mechanized proofs of correspondence assertions.In 20th IEEE Computer Security Foundations Symposium (CSF’07), pages 97–111, Venice,Italy, July 2007. IEEE.

33

[33] Bruno Blanchet and Avik Chaudhuri. Automated formal analysis of a protocol for securefile sharing on untrusted storage. In IEEE Symposium on Security and Privacy, pages417–431, Oakland, CA, May 2008. IEEE.

[34] Bruno Blanchet, Aaron D. Jaggard, Andre Scedrov, and Joe-Kai Tsay. Computationallysound mechanized proofs for basic and public-key Kerberos. In ACM Symposium on In-formation, Computer and Communications Security (ASIACCS’08), pages 87–99, Tokyo,Japan, March 2008. ACM.

[35] Johannes Borgstrom, Karthikeyan Bhargavan, and Andrew D. Gordon. A compositionaltheory for STM haskell. In 2nd ACM SIGPLAN Symposium on Haskell, pages 69–80, 2009.

[36] Matteo Bortolozzo, Matteo Centenaro, Riccardo Focardi, and Graham Steel. Attacking andfixing PKCS#11 security tokens. In Proceedings of the 17th ACM Conference on Computerand Communications Security (CCS’10), pages 260–269, Chicago, Illinois, USA, October2010. ACM Press.

[37] Matteo Centenaro, Riccardo Focardi, Flaminia L. Luccio, and Graham Steel. Type-basedanalysis of PIN processing APIs. In Michael Backes and Peng Ning, editors, Proceedings ofthe 14th European Symposium on Research in Computer Security (ESORICS’09), volume5789 of Lecture Notes in Computer Science, pages 53–68, Saint Malo, France, September2009. Springer.

[38] Veronique Cortier, Stephanie Delaune, and Graham Steel. A formal theory of key conjuring.In Proceedings of the 20th IEEE Computer Security Foundations Symposium (CSF’07),pages 79–93, Venice, Italy, July 2007. IEEE Computer Society Press.

[39] Veronique Cortier, Gavin Keighren, and Graham Steel. Automatic analysis of the securityof XOR-based key management schemes. In Orna Grumberg and Michael Huth, editors,Proceedings of the 13th International Conference on Tools and Algorithms for Constructionand Analysis of Systems (TACAS’07), volume 4424 of Lecture Notes in Computer Science,pages 538–552, Braga, Portugal, March 2007. Springer.

[40] Veronique Cortier and Graham Steel. A generic security API for symmetric key manage-ment on cryptographic devices. In Michael Backes and Peng Ning, editors, Proceedings ofthe 14th European Symposium on Research in Computer Security (ESORICS’09), volume5789 of Lecture Notes in Computer Science, pages 605–620, Saint Malo, France, September2009. Springer.

[41] Morten Dahl, Stephanie Delaune, and Graham Steel. Formal analysis of privacy for vehicu-lar mix-zones. In Dimitris Gritzalis and Bart Preneel, editors, Proceedings of the 15th Euro-pean Symposium on Research in Computer Security (ESORICS’10), volume 6345 of LectureNotes in Computer Science, pages 55–70, Athens, Greece, September 2010. Springer.

[42] Morten Dahl, Stephanie Delaune, and Graham Steel. Formal analysis of privacy for anony-mous location based services. In Proceedings of the Workshop on Theory of Security andApplications (TOSCA’11), Saarbrucken, Germany, March-April 2011. To appear.

[43] Stephanie Delaune, Steve Kremer, and Graham Steel. Formal analysis of PKCS#11. InProceedings of the 21st IEEE Computer Security Foundations Symposium (CSF’08), pages331–344, Pittsburgh, PA, USA, June 2008. IEEE Computer Society Press.

34

[44] Stephanie Delaune, Steve Kremer, Mark D. Ryan, and Graham Steel. A formal analysisof authentication in the TPM. In Pierpaolo Degano, Sandro Etalle, and Joshua Guttman,editors, Revised Selected Papers of the 7th International Workshop on Formal Aspects inSecurity and Trust (FAST’10), volume 6561 of Lecture Notes in Computer Science, pages111–125, Pisa, Italy, September 2010. Springer.

[45] Stephanie Delaune, Steve Kremer, Mark D. Ryan, and Graham Steel. Formal analysis ofprotocols based on TPM state registers. In Proceedings of the 24th IEEE Computer SecurityFoundations Symposium (CSF’11), pages 66–82, Cernay-la-Ville, France, June 2011. IEEEComputer Society Press.

[46] Riccardo Focardi, Flaminia L. Luccio, and Graham Steel. Blunting differential attackson PIN processing APIs. In Audun Jøsang, Torleiv Maseng, and Svein Johan Knapskog,editors, Proceedings of the 14th Nordic Workshop on Secure IT Systems (NordSec’09),volume 5838 of Lecture Notes in Computer Science, pages 88–103, Oslo, Norway, October2009. Springer.

[47] Sibylle Froschle and Graham Steel. Analysing PKCS#11 key management APIs with un-bounded fresh data. In Pierpaolo Degano and Luca Vigano, editors, Revised Selected Papersof the Joint Workshop on Automated Reasoning for Security Protocol Analysis and Issuesin the Theory of Security (ARSPA-WITS’09), volume 5511 of Lecture Notes in ComputerScience, pages 92–106, York, UK, August 2009. Springer.

[48] Gavin Keighren, David Aspinall, and Graham Steel. Towards a type system for securityAPIs. In Pierpaolo Degano and Luca Vigano, editors, Revised Selected Papers of the JointWorkshop on Automated Reasoning for Security Protocol Analysis and Issues in the Theoryof Security (ARSPA-WITS’09), volume 5511 of Lecture Notes in Computer Science, pages173–192, York, UK, August 2009. Springer.

[49] Steve Kremer, Graham Steel, and Bogdan Warinschi. Security for key management in-terfaces. In Proceedings of the 24th IEEE Computer Security Foundations Symposium(CSF’11), pages 266–280, Cernay-la-Ville, France, June 2011. IEEE Computer SocietyPress.

[50] Miriam Paiola and Bruno Blanchet. Verification of security protocols with lists: fromlength one to unbounded length. In First Conference on Principles of Security and Trust(POST’12), March 2012. To appear.

[51] G. Steel. Deduction with XOR constraints in security API modelling. In R. Nieuwenhuis,editor, Proceedings of the 20th Conference on Automated Deduction (CADE 20), number3632 in Lecture Notes in Artificial Intelligence, pages 322–336, Tallinn, Estonia, July 2005.Springer-Verlag Heidelberg.

[52] Nikhil Swamy, Juan Chen, Cedric Fournet, Pierre-Yves Strub, Karthikeyan Bhargavan, andJean Yang. Secure distributed programming with value-dependent types. In 16th ACMSIGPLAN international conference on Functional Programming, pages 266–278, 2011.

E Other references

[53] M. Abadi. Secrecy by typing in security protocols. Journal of the ACM, 46(5):749–786,Sept. 1999.

35

[54] M. Abadi and B. Blanchet. Secrecy types for asymmetric communication. TheoreticalComputer Science, 298(3):387–415, Apr. 2003. Special issue FoSSaCS’01.

[55] M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logicprograms. Journal of the ACM, 52(1):102–146, Jan. 2005.

[56] M. Abadi and B. Blanchet. Computer-assisted verification of a protocol for certified email.Science of Computer Programming, 58(1–2):3–27, Oct. 2005.

[57] M. Abadi. Access control in a core calculus of dependency. In Computation, Meaning,and Logic: Articles dedicated to Gordon Plotkin, pages 5–31. Elsevier, 2007. Volume 172 ofENTCS.

[58] R. Affeldt, D. Nowak, and K. Yamada. Certifying assembly with formal cryptographicproofs: the case of BBS. In 9th International Workshop on Automated Verification ofCritical Systems (AVoCS’09), volume 23 of Electronic Communications of the EASST.EASST, Sept. 2009.

[59] X. Allamigeon and B. Blanchet. Reconstruction of attacks against cryptographic protocols.In 18th IEEE Computer Security Foundations Workshop (CSFW-18), pages 140–154, Aix-en-Provence, France, June 2005. IEEE.

[60] R. Anderson. The correctness of crypto transaction sets. In 8th International Work-shop on Security Protocols, April 2000. http://www.cl.cam.ac.uk/ftp/users/rja14/protocols00.pdf.

[61] M. Arapinis, E. Ritter, and M. D. Ryan. Statverif: Verification of stateful processes. In24th Computer Security Foundations Symposium (CSF’11), pages 33–47, Cernay-la-Ville,France, June 2011. IEEE.

[62] A. Armando, L. Compagna, and P. Ganty. SAT-based model-checking of security protocolsusing planning graph analysis. In K. Araki, S. Gnesi, and D. Mandrioli, editors, FME2003: Formal Methods, International Symposium of Formal Methods Europe, volume 2805of Lecture Notes on Computer Science, pages 875–893, Pisa, Italy, Sept. 2003. Springer.

[63] A. Askarov, D. Hedin, and A. Sabelfeld. Cryptographically-masked flows. In Static AnalysisSymposium, volume 4134 of LNCS, pages 353–369. Springer, 2006.

[64] A. Askarov and A. Sabelfeld. Security-typed languages for implementation of cryptographicprotocols: A case study. In European Symposium on Research in Computer Security (ES-ORICS’05), volume 3679 of LNCS, pages 197–221. Springer, 2005.

[65] M. Backes and P. Laud. Computationally sound secrecy proofs by mechanized flow anal-ysis. In Proceedings of 13th ACM Conference on Computer and Communications Security(CCS’06), pages 370–379, Alexandria, VA, Nov. 2006. ACM.

[66] M. Backes, M. Grochulla, C. Hritcu, and M. Maffei. Achieving security despite compromiseusing zero-knowledge. In 22nd IEEE Computer Security Foundations Symposium (CSF’09),pages 308–323. IEEE Computer Society, 2009.

[67] M. Backes, C. Hritcu, and M. Maffei. Union and intersection types for secure protocolimplementations. Unpublished draft, 2010.

36

[68] M. Backes, M. Maffei, and D. Unruh. Computational sound verification of source code. InACM Conference on Computer and Communications Security, 2010.

[69] M. Backes, B. Pfitzmann, and M. Waidner. A composable cryptographic library with nestedoperations. In 10th ACM conference on Computer and communication security (CCS’03),pages 220–230, Washington D.C., Oct. 2003. ACM.

[70] I. Baltopoulos and A. D. Gordon. Secure compilation of a multi-tier web language. In ACMSIGPLAN Workshop on Types in Language Design and Implementation (TLDI 2009), pages27–38, 2009.

[71] G. Barthe, T. Rezk, and D. Naumann. Deriving an information flow checker and certifyingcompiler for java. In Proceedings of the 2006 IEEE Symposium on Security and Privacy,pages 230–242, Washington, DC, USA, 2006. IEEE Computer Society.

[72] G. Barthe, M. Daubignard, B. Kapron, and Y. Lakhnech. Computational indistinguishabil-ity logic. In 17th ACM Conference on Computer and Communications Security (CCS’10),pages 375–386, Chicago, IL, USA, Oct. 2010. ACM Press.

[73] G. Barthe, B. Gregoire, S. Z. Beguelin, and Y. Lakhnech. Beyond provable security. Veri-fiable IND-CCA security of OAEP. In A. Kiayias, editor, Topics in Cryptology - CT-RSA2011, volume 6558 of Lecture Notes on Computer Science, pages 180–196, San Francisco,CA, USA, Feb. 2011. Springer.

[74] G. Barthe, B. Gregoire, S. Heraud, and S. Z. Beguelin. Formal certification of ElGamalencryption. A gentle introduction to CertiCrypt. In P. Degano, J. Guttman, and F. Mar-tinelli, editors, 5th International Workshop on Formal Aspects in Security and Trust, FAST2008, volume 5491 of Lecture Notes on Computer Science, pages 1–19, Malaga, Spain, 2009.Springer.

[75] G. Barthe, B. Gregoire, S. Heraud, and S. Z. Beguelin. Computer-aided security proofs forthe working cryptographer. In Advances in Cryptology – CRYPTO 2011, Santa Barbara,CA, USA, Aug. 2011. To appear.

[76] G. Barthe, B. Gregoire, and S. Zanella. Formal certification of code-based cryptographicproofs. In 36th ACM SIGPLAN - SIGACT Symposium on Principles of ProgrammingLanguages (POPL’09), pages 90–101, Savannah, Georgia, Jan. 2009. ACM.

[77] D. Basin, S. Modersheim, and L. Vigano. An on-the-fly model-checker for security protocolanalysis. In E. Snekkenes and D. Gollman, editors, Computer Security – ESORICS 2003,8th European Symposium on Research in Computer Security, volume 2808 of Lecture Noteson Computer Science, pages 253–270, Gjøvik, Norway, Oct. 2003. Springer.

[78] S. Z. Beguelin, G. Barthe, S. Heraud, B. Gregoire, and D. Hedin. A machine-checked formal-ization of sigma-protocols. In 23rd Computer Security Foundations Symposium (CSF’10),pages 246–260, Edinburgh, UK, July 2010. IEEE.

[79] M. Bellare and P. Rogaway. The security of triple encryption and a framework for code-based game-playing proofs. In S. Vaudenay, editor, Advances in Cryptology – Eurocrypt2006 Proceedings, volume 4004 of Lecture Notes on Computer Science, pages 409–426, SaintPetersburg, Russia, May 2006. Springer. Extended version available at http://eprint.iacr.org/2004/331.

37

[80] B. Blanchet. An efficient cryptographic protocol verifier based on Prolog rules. In 14thIEEE Computer Security Foundations Workshop (CSFW-14), pages 82–96, Cape Breton,Nova Scotia, Canada, June 2001. IEEE Computer Society.

[81] B. Blanchet. Automatic proof of strong secrecy for security protocols. In IEEE Symposiumon Security and Privacy, pages 86–100, Oakland, California, May 2004.

[82] B. Blanchet and A. Podelski. Verification of cryptographic protocols: Tagging enforcestermination. Theoretical Computer Science, 333(1-2):67–90, Mar. 2005. Special issue FoS-SaCS’03.

[83] B. Blanchet. Security protocols: From linear to classical logic by abstract interpretation.Information Processing Letters, 95(5):473–479, Sept. 2005.

[84] Y. Boichut, N. Kosmatov, and L. Vigneron. Validation of prouve protocols using theautomatic tool TA4SP. In Proceedings of the Third Taiwanese-French Conference on In-formation Technology (TFIT 2006), pages 467–480, Nancy, France, Mar. 2006.

[85] M. Bond. Attacks on cryptoprocessor transaction sets. In Proceedings of the 3rd Interna-tional Workshop on Cryptographic Hardware and Embedded Systems (CHES’01), volume2162 of LNCS, pages 220–234, Paris, France, 2001. Springer.

[86] M. Bugliesi, R. Focardi, and M. Maffei. Dynamic types for authentication. Journal ofComputer Security, 15(6):563–617, 2007.

[87] M. Burrows, M. Abadi, and R. Needham. A logic of authentication. Proceedings of theRoyal Society of London A, 426(1871):233–271, dec 1989. A preliminary version appearedas Digital Equipment Corporation Systems Research Center report No. 39, February 1989.

[88] S. Z. Beguelin, B. Gregoire, G. Barthe, and F. Olmedo. Formally certifying the security ofdigital signature schemes. In 30th IEEE Symposium on Security and Privacy, S&P 2009,pages 237–250, Oakland, CA, May 2009. IEEE.

[89] C. Cachin and N. Chandran. A secure cryptographic token interface. In Computer SecurityFoundations (CSF-22), pages 141–153, Long Island, New York, 2009. IEEE ComputerSociety Press.

[90] S. Chaki and A. Datta. ASPIER: An automated framework for verifying security protocolimplementations. In IEEE Computer Security Foundations Symposium, pages 172–185,2009.

[91] A. Chaudhuri. Language-based security on android. In Proceedings of the ACM SIGPLANFourth Workshop on Programming Languages and Analysis for Security, PLAS ’09, pages1–7, New York, NY, USA, 2009. ACM.

[92] Y. Chevalier and L. Vigneron. A tool for lazy verification of security protocols. In 16th IEEEInternational Conference on Automated Software Engineering (ASE 2001), pages 373–376,Coronado Island, San Diego, CA, Nov. 2001. IEEE Computer Society.

[93] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner. Analyzing inter-application communi-cation in android. pages 239–252, 2011.

38

[94] J. Clulow. On the security of PKCS#11. In Proceedings of CHES 2003, pages 411–425,2003.

[95] H. Comon-Lundh and V. Cortier. Computational soundness of observational equivalence.In Proceedings of the 15th ACM conference on Computer and communications security(CCS’08), pages 109–118, Alexandria, Virginia, USA, Oct. 2008. ACM.

[96] V. Cortier, H. Hordegen, and B. Warinschi. Explicit randomness is not necessary whenmodeling probabilistic encryption. In C. Dima, M. Minea, and F. Tiplea, editors, Workshopon Information and Computer Security (ICS 2006), volume 186 of Electronic Notes inTheoretical Computer Science, pages 49–65, Timisoara, Romania, Sept. 2006. Elsevier.

[97] V. Cortier and E. Zalinescu. Deciding key cycles for security protocols. In M. Hermann andA. Voronkov, editors, Logic for Programming, Articifial Intelligence, and Reasoning, 13thInternational Conference, LPAR 2006, volume 4246 of Lecture Notes on Computer Science,pages 317–331, Phnom Penh, Cambodia, Nov. 2006. Springer.

[98] J. Courant, M. Daubignard, C. Ene, P. Lafourcade, and Y. Lakhnech. Towards automatedproofs for asymmetric encryption schemes in the random oracle model. In Proceedings of the15th ACM conference on Computer and communications security (CCS’08), pages 371–380,Alexandria, Virginia, USA, Oct. 2008. ACM.

[99] J. Courant, M. Daubignard, C. Ene, P. Lafourcade, and Y. Lakhnech. Automated proofs forasymmetric encryption. In D. Dams, U. Hannemann, and M. Steffen, editors, Concurrency,Compositionality, and Correctness, volume 5930 of Lecture Notes on Computer Science,pages 300–321. Springer, 2010.

[100] J. Courant, C. Ene, and Y. Lakhnech. Computationally sound typing for non-interference:The case of deterministic encryption. In V. Arvind and S. Prasad, editors, 27th Conferenceon Foundations of Software Technology and Theoretical Computer Science (FSTTCS’07),volume 4855 of Lecture Notes on Computer Science, pages 364–375, New Delhi, India, Dec.2007. Springer.

[101] J. Courant and J.-F. Monin. Defending the bank with a proof assistant. In Proceedings ofthe 6th International Workshop on Issues in the Theory of Security (WITS’06), pages 87 –98, Vienna, Austria, March 2006.

[102] C. J. F. Cremers. Scyther - Semantics and Verification of Security Protocols. Ph.D.dissertation, Eindhoven University of Technology, Nov. 2006.

[103] A. Datta, A. Derek, J. C. Mitchell, and D. Pavlovic. A derivation system and compositionallogic for security protocols. Journal of Computer Security, 13(3):423–482, 2005.

[104] A. Datta, A. Derek, J. C. Mitchell, V. Shmatikov, and M. Turuani. Probabilisticpolynomial-time semantics for a protocol security logic. In L. Caires and L. Monteiro,editors, ICALP 2005: the 32nd International Colloquium on Automata, Languages andProgramming, volume 3580 of Lecture Notes on Computer Science, pages 16–29, Lisboa,Portugal, July 2005. Springer.

[105] A. Datta, A. Derek, J. C. Mitchell, and B. Warinschi. Computationally sound composi-tional logic for key exchange protocols. In Proceedings of 19th IEEE Computer SecurityFoundations Workshop (CSFW’06), pages 321–334, Venice, Italy, July 2006. IEEE Com-puter Society.

39

[106] S. Delaune, M. Ryan, and B. Smyth. Automatic verification of privacy properties inthe applied pi calculus. In Y. Karabulut, J. Mitchell, P. Herrmann, and C. D. Jensen,editors, Proceedings of the second Joint iTrust and PST Conferences on Privacy, TrustManagement and Security (IFIPTM’08), volume 263 of IFIP Advances in Information andCommunication Technology, pages 263–278, Trondheim, Norway, June 2008. Springer.

[107] G. Denker, J. Meseguer, and C. Talcott. Protocol specification and analysis in Maude.In N. Heintze and J. Wing, editors, Workshop on Formal Methods and Security Protocols,Indianapolis, Indiana, 25 June 1998.

[108] D. Dolev and A. C. Yao. On the security of public key protocols. IEEE Transactions onInformation Theory, IT-29(12):198–208, Mar. 1983.

[109] F. Dupressoir, A. D. Gordon, J. Jurjens, and D. A. Naumann. Guiding a general-purposec verifier to prove cryptographic protocols. In Proceedings of the 24th IEEE ComputerSecurity Foundations Symposium (CSF’11), 2011. To appear.

[110] N. Durgin, P. Lincoln, J. C. Mitchell, and A. Scedrov. Multiset rewriting and the com-plexity of bounded security protocols. Journal of Computer Security, 12(2):247–311, 2004.

[111] N. Durgin, J. C. Mitchell, and D. Pavlovic. A compositional logic for proving securityproperties of protocols. Journal of Computer Security, 11(4):677–721, 2003.

[112] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth.TaintDroid: an information-flow tracking system for realtime privacy monitoring on smart-phones. In Proceedings of OSDI 2010, Oct. 2010.

[113] W. Enck, D. Octeau, P. McDaniel, and S. Chaudhuri. A study of Android applicationsecurity. In Proceedings of the 20th USENIX Security Symposium, Aug. 2011.

[114] F. J. T. Fabrega, J. C. Herzog, and J. D. Guttman. Strand spaces: Proving securityprotocols correct. Journal of Computer Security, 7(2/3):191–230, 1999.

[115] C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, and R. Stata. Extendedstatic checking for java. SIGPLAN Notices, 37:234–245, May 2002.

[116] C. Fournet, M. Kohlweiss and P.-Y. Strub. Modular code-based cryptographic verification.In ACM Conference on Computer and Communications Security, 2011.

[117] C. Fournet and T. Rezk. Cryptographically sound implementations for typed information-flow security. In 35th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Pro-gramming Languages (POPL’08), pages 323–335, Jan. 2008.

[118] T. Genet and F. Klay. Rewriting for cryptographic protocol verification. In D. McAllester,editor, 17th International Conference on Automated Deduction (CADE-17), volume 1831 ofLecture Notes on Computer Science, pages 271–290, Pittsburgh, PA, June 2000. Springer.

[119] A. Gordon and A. Jeffrey. Typing one-to-one and one-to-many correspondences in securityprotocols. In M. Okada, B. Pierce, A. Scedriv, H. Tokuda, and A. Yonezawa, editors,Software Security – Theories and Systems, Mext-NSF-JSPS International Symposium, ISSS2002, volume 2609 of Lecture Notes on Computer Science, pages 263–282, Tokyo, Japan,Nov. 2002. Springer.

40

[120] A. Gordon and A. Jeffrey. Authenticity by typing for security protocols. Journal ofComputer Security, 11(4):451–521, 2003.

[121] A. Gordon and A. Jeffrey. Types and effects for asymmetric cryptographic protocols.Journal of Computer Security, 12(3/4):435–484, 2004.

[122] J. Goubault-Larrecq. A method for automatic cryptographic protocol verification (ex-tended abstract), invited paper. In J. Rolim et al., editors, Fifth International Workshopon Formal Methods for Parallel Programming: Theory and Applications (FMPPTA’2000),volume 1800 of Lecture Notes on Computer Science, pages 977–984, Cancun, Mexique, May2000. Springer.

[123] J. Goubault-Larrecq. Deciding H1 by resolution. Information Processing Letters,95(3):401–408, Aug. 2005.

[124] J. Goubault-Larrecq and F. Parrennes. Cryptographic protocol analysis on real C code.In VMCAI, volume 3385 of LNCS, pages 363–379. Springer, 2005.

[125] A. Guha, M. Fredrikson, B. Livshits, and N. Swamy. Verified security for browser exten-sions. In IEEE Symposium on Security and Privacy, pages 115–130, 2011.

[126] N. Guts, C. Fournet, and F. Zappa Nardelli. Reliable evidence: Auditability by typing. In14th European Symposium on Research in Computer Security (ESORICS’09), LNCS, pages168–183. Springer, 2009.

[127] S. Halevi. A plausible approach to computer-aided cryptographic proofs. Cryptology ePrintArchive, Report 2005/181, June 2005. Available at http://eprint.iacr.org/2005/181.

[128] J. Herzog. Applying protocol analysis to security device interfaces. IEEE Security &Privacy Magazine, 4(4):84–87, July-Aug 2006.

[129] L. Jia, J. Vaughan, K. Mazurak, J. Zhao, L. Zarko, J. Schorr, and S. Zdancewic. Aura: aprogramming language for authorization and audit. In International Conference on Func-tional Programming (ICFP’08), pages 27–38. ACM, 2008.

[130] P. Laud. Handling encryption in an analysis for secure information flow. In P. Degano,editor, Programming Languages and Systems, 12th European Symposium on Programming,ESOP’03, volume 2618 of Lecture Notes on Computer Science, pages 159–173, Warsaw,Poland, Apr. 2003. Springer.

[131] P. Laud. Symmetric encryption in automatic analyses for confidentiality against active ad-versaries. In IEEE Symposium on Security and Privacy, pages 71–85, Oakland, California,May 2004.

[132] P. Laud. Secrecy types for a simulatable cryptographic library. In 12th ACM Conferenceon Computer and Communications Security (CCS’05), pages 26–35, Alexandria, VA, Nov.2005. ACM.

[133] P. Laud and I. Tsahhirov. A user interface for a game-based protocol verification tool.In P. Degano and J. Guttman, editors, 6th International Workshop on Formal Aspects inSecurity and Trust (FAST2009), volume 5983 of Lecture Notes on Computer Science, pages263–278, Eindhoven, Netherlands, Nov. 2009. Springer.

41

[134] P. Laud and V. Vene. A type system for computationally secure information flow. InM. Liskiewicz and R. Reischuk, editors, 15th International Symposium on Fundamentals ofComputation Theory (FCT’05), volume 3623 of Lecture Notes on Computer Science, pages365–377, Lubeck, Germany, Aug. 2005. Springer.

[135] P. Li and S. Zdancewic. Encoding information flow in Haskell. In IEEE Computer SecurityFoundations Workshop (CSFW’06), pages 16–27, 2006.

[136] D. Longley and S. Rigby. An automatic search for security flaws in key managementschemes. Computers and Security, 11(1):75–89, March 1992.

[137] G. Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. InTools and Algorithms for the Construction and Analysis of Systems, volume 1055 of LectureNotes on Computer Science, pages 147–166. Springer, 1996.

[138] S. Maffeis, J. C. Mitchell, and A. Taly. An operational semantics for javascript. In APLAS,pages 307–325, 2008.

[139] J. C. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocolsusing Murϕ. In 1997 IEEE Symposium on Security and Privacy, pages 141–151, 1997.

[140] S. Modersheim. Abstraction by set-membership: Verifying security protocols and webservices with databases. In Proceedings of the 17th ACM Conference on Computer andCommunications Security (CCS 2010), pages 351–360, Chicago, IL, USA, Oct. 2010. ACM.

[141] D. Monniaux. Abstracting cryptographic protocols with tree automata. Science of Com-puter Programming, 47(2–3):177–202, 2003.

[142] A. C. Myers. JFlow: Practical mostly-static information flow control. In 26th ACMSymposium on Principles of Programming Languages, pages 228–241, Jan. 1999.

[143] R. M. Needham and M. D. Schroeder. Using encryption for authentication in large net-works of computers. Commun. ACM, 21(12):993–999, Dec. 1978.

[144] D. Nowak. A framework for game-based security proofs. In Information and Communi-cations Security, 9th International Conference, ICICS 2007, volume 4861 of Lecture Noteson Computer Science, pages 319–333, Zhengzhou, China, Dec. 2007. Springer.

[145] D. Nowak. On formal verification of arithmetic-based cryptographic primitives. In Infor-mation Security and Cryptology - ICISC 2008, 11th International Conference, volume 5461of Lecture Notes on Computer Science, pages 368–382, Seoul, Korea, Dec. 2008. Springer.

[146] L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal ofComputer Security, 6(1–2):85–128, 1998.

[147] A. Pironti and R. Sisto. Provably correct Java implementations of Spi Calculus securityprotocols specifications. Computers & Security, 29:302–314, 2010.

[148] F. Pottier and V. Simonet. Information flow inference for ML. ACM Transactions onProgramming Languages and Systems, 25(1):117–158, Jan. 2003

[149] P. Rondon, M. Kawaguchi, and R. Jhala. Liquid types. In Programming Language Designand Implementation (PLDI’08), pages 159–169. ACM, 2008.

42

[150] M. Rusinowitch and M. Turuani. Protocol insecurity with finite number of sessions isNP-complete. Theoretical Computer Science, 299(1–3):451–475, Apr. 2003.

[151] B. Schneier. Security pitfalls in cryptographic design. Inf. Manag. Comput. Security,6(3):133–137, 1998.

[152] V. Shoup. Sequences of games: a tool for taming complexity in security proofs. CryptologyePrint Archive, Report 2004/332, Nov. 2004. Available at http://eprint.iacr.org/2004/332.

[153] G. Smith and R. Alpızar. Secure information flow with random assignment and encryption.In 4th ACM Workshop on Formal Methods in Security Engineering (FMSE’06), pages 33–43, Alexandria, Virginia, Nov. 2006.

[154] P-Y. Strub, N. Swamy, C. Fournet and J. Chen. Self-Certification: Bootstrapping CertifiedTypecheckers in F* with Coq. In 39th Annual ACM SIGPLAN-SIGACT Symposium onPrinciples of Programming Languages (POPL’12), to appear, Jan. 2012.

[155] N. Swamy, B. J. Corcoran, and M. Hicks. Fable: A language for enforcing user-definedsecurity policies. In IEEE Symposium on Security and Privacy, pages 96–110, 2008.

[156] A. Taly, U. Erlingsson, J. C. Mitchell, M. S. Miller, and J. Nagra. Automated analysisof security-critical javascript APIs. In IEEE Symposium on Security and Privacy, pages363–378, 2011.

[157] I. Tsahhirov and P. Laud. Application of dependency graphs to security protocol analysis.In G. Barthe and C. Fournet, editors, 3rd Symposium on Trustworthy Global Computing(TGC’07), volume 4912 of Lecture Notes on Computer Science, pages 294–311, Sophia-Antipolis, France, Nov. 2007. Springer.

[158] J. A. Vaughan, L. Jia, K. Mazurak, and S. Zdancewic. Evidence-Based Audit. In 21stIEEE Computer Security Foundations Symposium (CSF’08), pages 177–191, 2008.

[159] J. A. Vaughan and S. Zdancewic. A cryptographic decentralized label model. In IEEESymposium on Security and Privacy, pages 192–206, Washington, DC, USA, 2007.

[160] C. Weidenbach. Towards an automatic analysis of security protocols in first-order logic. InH. Ganzinger, editor, 16th International Conference on Automated Deduction (CADE-16),volume 1632 of Lecture Notes in Artificial Intelligence, pages 314–328, Trento, Italy, July1999. Springer.

[161] P. Youn, B. Adida, M. Bond, J. Clulow, J. Herzog, A. Lin, R. Rivest, and R. Anderson.Robbing the bank with a theorem prover. Technical Report UCAM-CL-TR-644, Universityof Cambridge, August 2005.

43

Prosecco Programming Securely with Cryptography

Documents

Transcript of Prosecco Programming Securely with Cryptography