Research project proposal ProVal: Proof of Programs

Transcription

1 October 9, 2006 Research project proposal ProVal: Proof of Programs Theme Sym A Symbolic systems: Reliability and safety of software Common research project PCRI (INRIA Futurs, LIX, LRI) UR Futurs Saclay

2 Contents 1 Summary 4 2 Team members on January Project Overview Motivations and Topics Background Research Program Models and methods for proving programs Higher-order Functional programs Programs with pointers Quantitative Analysis Modeling high-level specifications Architecture of environments for proving programs Tools development Specification languages Assistant for writing specifications Automated deduction Decision Procedures for proving programs Proofs of termination Applications Telecommunications Aeronautics Banking applications Software development Why KRAKATOA CADUCEUS Links with other project/teams Related INRIA research teams Related international research teams Java/JML Proofs of C programs Automated deduction Collaborations and industrial contracts Contracts and Grants with industry France Telecom ECVAES CIFRE, Axalto CIFRE, Dassault National Contracts

3 7.2.1 AVERROES, RNTL ( ) Geccoo, ACI sécurité ( ) European initiatives TYPES VerifiCard International actions Bilateral action C.N.R.S./U.I.U.C. ( ) Collaborations Team publications since International Journal and edited book International conferences with selection French conferences with selection Conferences/Workshops without selection Software Research reports DEA and Thesis Submitted papers

4 1 Summary The goal of the ProVal project is to propose methods and tools which are integrated in the software development cycle and which allow to produce provably correct code with respect to an expected behavior. Critical software applications in the domain of transportation, telecommunication or electronic transactions are put on the market within very short delays. In order to guarantee a dependable behavior, it is mandatory for a large part of the validation of the system to be done in a mechanical way. This project, formed after the LogiCal project, uses the Type Theory formalism which gives a clear semantics for representing on a computer both computation and deduction. The project develops a general-purpose tool for program verification, called WHY, which generates proof obligations which are then delegated to interactive or automatic provers. Upon this tool, we have built dedicated environments for the specification and proof of programs written in C (CADUCEUS) or Java (KRAKATOA) and annotated with formulas describing their expected behavior. Our research goes along the following themes. Models and methods for proving programs We are developing models for programming and specification languages which fulfill needs of critical applications and are suitable for interactive or automatic proving. We are interested in particular in the high-level modeling of abstract constructions, the manipulation of pointers and the translation of high-level specification diagrams. Architecture of environments for proof of programs The use of our methods in concrete applications is raising problems of efficiency of the proof obligations generation, the methodology of annotations generation, expressiveness of specification languages and assistance in the development of specifications. Automated proving Proof of programs requires to adapt and specialize general theorem-proving tools. Our project studies specifically proofs of termination and combination of decision procedures. We emphasize the need of certification for automatically generated proofs. Applications Techniques developed in the project have applications in domains where critical applications are involved, which require certification procedures. This is the case for banking applications, aeronautics and telecommunications. We address the problems of verification of embedded C or Java code as well as the certification of tools generating critical code. 4

5 2 Team members on January 2005 Permanent members Christine Paulin, Professor, Paris XI University (Scientific leader) Claude Marché, Maître de Conférences, Paris XI University (Vice leader) Jean-Christophe Filliâtre, Chargé de Recherche, C.N.R.S. Sylvain Conchon, Maître de Conférences, Paris XI University. Temporary members Weiwen Xu, post-doc ( ) École Polytechnique Phd students Doctoral school of Computer Science at Paris XI University. June Andronick, CIFRE (LRI-Axalto). Thierry Hubert, CIFRE (LRI-Dassault). Nicolas Rousset, CIFRE (LRI-Axalto). Julien Signoles, MENSR. Interns Nicolas Ayache, Master M2 MPRI, March-Sept Julien Roussel, EPITA, January-July Matthieu Sozeau, Master M2 MPRI, March-Sept Associated members Evelyne Contejean, Chargée de Recherche C.N.R.S., member of the LogiCal project is associated with the ProVal project for her work on automated theorem proving. Jean-Pierre Jouannaud, professor at University Paris XI, member of the LogiCal project is associated with the ProVal project for his work on program complexity analysis. Jean Duprat, Maître de conférences at É.N.S. Lyon, contributes to the work on specification and proof of Java programs in the COQ proof assistant. Pierre Corbineau, PhD student, member of the LogiCal project, is working on automated deduction in COQ providing proof terms. His advisor is Claude Marché. Nicolas Oury, PhD student, member of the LogiCal project, is working on consistent extensions of the Calculus of Constructions with rewriting rules. His advisor is Christine Paulin. 5

6 3 Project Overview The general goal of the ProVal project is to promote computer-assisted proof into the development cycle of critical software applications. 3.1 Motivations and Topics Research activities of the ProVal project belong to the area of safety and reliability of software. These last years, the importance of software in critical systems grew significantly. Twenty years ago, such critical softwares were developed for aeronautics, railroads, banks, etc. by specialized programming teams. Insurance in the quality of code was relying mainly on following rigorous development rules and schemes and intensive test of systems, which are long and expensive activities. Now, software spreads a lot into transportation and telecommunications for a large public. Many such applications are deployed in cars, mobile phones, etc. Proposed features are becoming very complex, must should be made available quickly, and evolve permanently. Programming errors may have severe economic and human consequences. Moreover, software development is now often sub-contracted and delocalized, the company distributing the final product must have ways to control quality of the software integrated in its products. The same problem arises for an end-user who want to download an application. The increase of power of computers, and the need for more structure, portability and maintainability of software, lead to a need of more and more high-level languages. Static typing of high-level languages guarantees at compile-time absence of some classes of errors, it is the case for ML-like programming languages and also object-oriented languages like Java. There are now millions of smart cards integrating a Java virtual machine in mobile phones, and techniques like byte code verification or firewalls integrate control of safety in the language, statically and/or dynamically. Nevertheless, static typing of programming languages can only prevent from a limited class of errors. Other kinds of program analysis must be used to guarantee more advanced properties. Abstract interpretation allows to approximate a program in order to detect potential errors. This approach requires expensive computations over complex domains. If the approximation is too loose, the answer will be undetermined, and would need to be interpreted by the user to decide whether it is really an error, a limitation of the approximation, or if more information on the context of use of the program is needed. Model-checking is also a widely spread approach of program analysis. Execution of a program is modeled as a graph whose vertices correspond to machine states, and arcs to execution steps. Exploration of the graph allows to check properties of the program. This approach is particularly useful for non-deterministic programs. Nevertheless, the possible large size of the graph can be a strong limitation of these techniques, the graph may even be infinite in presence of complex data structures, requiring either a symbolic representation of states, or the use of abstractions allowing to check properties on smaller graphs. To guarantee that the result of a deterministic program satisfies some property, it is not mandatory to build the whole graph of executions, other semantics may do it. For example, Hoare logic allows to build, from a logical formula expressing the property to 6

7 establish, another logical formula whose validity implies the soundness of the program. Nevertheless, this formula reflects the complexity of the program, it is often necessary to manually introduce additional annotations (typically loop invariants) to obtain satisfactory results. Techniques described above mainly focus on establishing behavioral properties of programs such as no runtime errors, termination, or properties of computed results. Other quantitative properties are important, such as estimation of the program complexity (in terms of time, memory or even power consumption). Programs may also be executed under contexts which are not necessarily deterministic, but may be modeled with probabilities. One may want to evaluate the probability of occurrence of some behavior. All methods of program analysis rely on a mathematical model of programs, a language to express the expected properties, and algorithmic methods for checking those properties. The ProVal project studies methods where programs are essentially modeled functionally (i.e. outputs are functions of the inputs, as opposed to imperative programs or transition systems), and the properties are expressed in a general mathematical language. Verification is then undecidable in general, hence the algorithmic of verification consists in the generation of sufficient conditions for soundness of the program. Afterwards validity of those proof obligations must be established and mechanically verified, using proof tools which may sometime run fully automatically (automated theorem provers) or require some user interaction (proof assistants). 3.2 Background The foundation step of the project is the PhD thesis of Jean-Christophe Filliâtre, defended in 1999 at Paris 11 University, which proposes to establish soundness of a program with imperative features (assignments, while loops, but also exceptions and exception handlers) by use of a translation into an equivalent purely functional program with logical annotations. Such an annotated functional program is very-well suited to be expressed in the language of the COQ [28] system, the proof assistant traditionally developed in the INRIA project LogiCal. This approach allowed then for the first time to prove imperative programs with COQ. Following this thesis, a new tool called WHY was developed. It takes as input an imperative program and a specification that this program is expected to fulfill. It produces on one hand a set of logical formulas which have to be proved in the COQ system and on the other hand a COQ-term which contains a functional translation of the imperative program and a proof of correctness of this program based on the proof obligations. It was early remarked that this tool was independent of COQ, because the proof obligations can be validated in other interactive tools, such as PVS developed at SRI, or with automatic provers such as SIMPLIFY, developed in the Compaq-HP SRC laboratory, or HARVEY developed in the Cassis project at INRIA. This multi-prover architecture is a powerful feature of Why: it spreads this technology well beyond the COQ community. From 2001, INRIA participation (LogiCal and Lemme projects) to the European IST project VerifiCard gave a new impulse to the research on proofs of programs. We focused on Java program (or Java Card for embedded programs on smart cards). Thanks to the extra manpower given by X. Urbain s post-doc contract and C. Marché temporary position at INRIA, we elaborated a method for proving Java programs starting from the source code annotated with JML (Java Modeling Language). This method was implemented in a new tool called KRAKATOA. 7

8 The approach uses a translation from annotated Java programs into the specific language of WHY, we then can reuse Why s proof obligations generation mechanism and choose between different provers for establishing this obligations. This approach for proving Java programs by translation into the language of WHY and then into a functional language is original and contrasts with other approaches where the denotational or operational semantics of Java is directly translated into a proof assistant (which is in general not very efficient for dealing with real programs) or approaches generating directly proof obligations with Hoare s logic rules specific to Java (which is less flexible). From 2003, we followed the approach of KRAKATOA for programs written in ANSI C, in collaboration with Axalto (formerly SchlumbergerSema) and Dassault Aviation and started the development of a tool called CADUCEUS. These activities are developed enough in order to justify the creation of a new project which not only will continue the study and development of tools for proofs of programs but also will take into account the problematic of proofs in the process of software development. In particular we study refinement strategies, or develop environment for helping users developing specifications (in order to transform security policies into logical properties). Our work deals with formal models of programming and specification languages which are adapted to the verification process. We are interested by different paradigms: we started the study of probabilistic programs and we also have been working on timed automata interpreted as transition systems. 4 Research Program 4.1 Models and methods for proving programs Program verification requires modeling of both programs and specification. Many programming languages features involve complex notions: advanced constructions such as higher-order functions, polymorphism and inheritance or low-level operations involving pointers or conversion between representations. An analogous problem exists for defining description languages suitable for the expression of user requirements in term of security and safety and which can be translated into sufficient conditions to be verified by the code Higher-order Functional programs Functional strongly typed languages such as Objective Caml help to improve the quality of software development. Static typing automatically detects possible execution errors. Higherorder functions, polymorphism, modules and functors are powerful tools for the development of generic reusable libraries. One of our goals is to enrich such a software environment with a language of annotations, which can express logical properties of programs and the possibility to automatically and interactively develop proofs of correctness of the programs. In order to reach this goal, we are exploring different directions. The Calculus of Inductive Constructions (CCI) underlying the COQ system is a purely functional language corresponding for the computational point of view to a subset of 8

9 Ocaml but with a richer type system integrating dependent types. Arbitrary logical conditions can be integrated to the types and associated to functions. For instance, it is possible to build a type of sorted lists, or of lists of length n. Programs can integrate proof parts in order to ensure the adequation between the program and its type representing the specification. However, for this approach to become useful for the programmer, one needs to develop a high-level language which will be compiled into CCI. Specific problems we plan to address are pattern-matching with dependent types (we expect pattern-matching on a list of size n > 0 to be complete without considering the empty list case) general recursive functions: CCI language only considers recursive functions associated to an inductive type which decreases according to a structural order, it is also possible to use a noetherian order but it introduces non-natural complications (reduction, extra proof terms... ). in general dependent types give precise specification but writing terms becomes complicated. This work is a natural continuation of Pierre Letouzey s thesis on program extraction from proofs. The input language of the WHY system corresponds to a subset of Ocaml. It integrates references and exceptions, but the static computation of effects does not adapt very well to polymorphic functionals. One possibility is to extend or modify the current technology, possibly taking inspiration from the purely functional framework. The memory model for mutable objects should also take advantage of the strong typing of the Ocaml language. Another way to extend Ocaml programs with specifications and proofs is to develop refinement techniques. In his thesis supervised by J.-C. Filliâtre, J. Signoles introduces an extension of the Ocaml language with non-deterministic constructions. A type is considered to be an ordinary program construction representing an arbitrary value of this type, which can be inserted in any sub-expression. The type language can integrate dependent types to make more precise the expected logical properties of values. The classical typing relation between a program and its type becomes a particular case of refinement between two programs Programs with pointers When designing the KRAKATOA tool [21] for proving Java programs, the main challenge was the design of a suitable model for the Java memory heap. Even if Java programs do not manipulate pointers explicitly, objects are passed around through pointer, generating possible aliases (two different variables representing the same memory location). Indeed, the Why tool does not handle aliases by itself: its effect analysis checks that different variables correspond to different memory locations such that changes to one variable do not affect the other values. One possible solution is to represent the heap as one variable corresponding to a big array mapping addresses to values. But we have chosen a more elaborated representation. The KRAKATOA and the CADUCEUS models are inspired by the component-as-array representation due to Bornat, following an old idea from Burstall, and recently used by several researchers to verify 9

10 pointers programs. The key idea is to separate the heap according to objects fields, since it is statically known that two different fields can not be aliased. The only values manipulated in the model are numerical values or object values (the null pointer or an address). The distinction between the two kinds of values can be done statically. Each field declaration f in a Java class introduces a global variable M f in the model which is an array indexed by addresses, containing values (either numerical or object pointers). The field f of an object o corresponds to the value at index a o in the array M f where a o is the address of o. The same idea was reused in order to design the memory model for the C programming language in the CADUCEUS tool. The memory model had to be refined in order to handle pointer arithmetic [12]. However, the C programming language allows conversion between structures, as in the union types. Other techniques need to be designed in order to handle properly these extra constructions while exploiting as much as possible the separation between different parts of the memory. One difficulty with programs handling pointers is to specify side-effects of a function manipulating linked structures. The JML language offers the assignable clause in specification in order to delimitate the part of memory which is modified by the function. CADUCEUS annotations offers a similar construction [20, 12] but which is not completely satisfactory when complex side-effects are involved. We plan to investigate other methods such as Reynolds separation logic [27] in order to simplify specification and proofs of preservation of states. This is one of the main task of the thesis of T. Hubert which just started in collaboration with Dassault Aviation Quantitative Analysis The methods described above handle naturally the specification and proof of behavioral properties of programs: which properties are satisfied by the result of the program. But other techniques must be designed for non-behavioral properties. Global properties We can use the validation term of WHY in order to define a model of each function, then express and prove properties of functions composition. Such an approach is currently investigated by J. Andronick in the framework of proofs of security properties on smart cards [1]. Resources It is also useful to be able to estimate quantitative information on programs like a bound on execution time or on the amount of allocated memory. Such informations are especially relevant for embedded systems for which there are only limited resources and where power consumption is restricted. Adapting programming languages in order to perform such analyses is an active domain of research. During her post-doc, Weiwen Xu is studying for the COQ system techniques of complexity analysis for extracted programs developed by R. Benzinger for the Nuprl system [3, 4]. Probabilistic programs Another interesting subject is the analysis of probabilistic programs. These programs offer interesting approximated solutions for solving hard problems. Probabilistic behavior are also introduced in distributed systems in order to avoid dead-lock or to model the environment. Probabilistic programs are non-deterministic systems where the set of possible results are following a distribution and we want to measure the probability that 10

11 a certain property holds for the result or to estimate the mean of a certain quantity. Proving probabilistic systems can rely on model-checking (see for instance the PRISM project [18]) or on an extension of Hoare s logic to probabilistic constructions [24]. Proof systems using higher-order logic are especially well-suited for mechanizing proofs on probabilistic systems, Joe Hurd [14] proposed a representation of probabilistic programs in the system HOL using an infinite sequence of booleans as an additional argument which represents independent runs. We are studying another approach where probabilistic programs are directly interpreted as transformers of probability measures Modeling high-level specifications Security properties required on critical programs are often expressed in high-level languages. One possibility is to use UML diagrams. However, our approach only considers annotations written in first-order logic. There is a gap between the two levels of specification. We plan to work on this subject in the context of the Geccoo project (Section 7.2.2) which deals with security properties in an object-oriented approach and also in the ECVAES (Section 7.1.2) project where security properties can be useful both at the level of C and Java Card code on smart cards. We need to identify a class of high-level specifications (for instance a subset of UML diagrams, OCL specifications) which is suitable for our applications. Then the main problem will be to find an appropriate model for these specifications in JML or the CADUCEUS specification language. We are in particular interested by the specification of temporal properties. They can be translated in term of pre and post conditions in the code (see [29] for an example using JML and model variables) an alternative approach will be to use a global model at the COQ level [1]. Dealing with concurrent aspects of computations is also an interesting extension even if it is not expected that next generations of Java Card will make an extensive use of such a feature. We are also interested by using our multi-language approach in order to formally validate the combination of code written in C and in Java Card with respect to a common security objective. 4.2 Architecture of environments for proving programs This part of our work deals with the practical aspects of theoretical studies presented in section 4.1. We want to address with our tools and methods significant examples which are relevant for industrial applications. In general, applications are useful for revealing pitfall in the approach such as efficiency of proof obligations generation or the difficulty to manually write annotations or the lack of automation for certain proofs. These problems can generally be solved by improving the implementation or may lead to new theoretical studies such as the design of a more appropriate specification language or the automation of annotations insertion or of proofs Tools development A significant part of our activity is to develop tools. 11

12 The WHY tool A first tool play a central role in our research : WHY [11] implements the proof of programs approach proposed by Jean-Christophe Filliâtre [10]. The programs handled by WHY are written in a specific language, they are annotated with pre and post conditions (similar to classical Hoare s logic). WHY generates proof obligations, the validity of which ensures correctness of the program with respect to the original specification. In WHY, these obligations are first-order formula which can be translated into the syntax of different provers (Figure 1): interactive higher-order provers like COQ, PVS, HOL-light or Mizar or automatic provers such as CVC-lite, Simplify or harvey. This multi-prover architecture is clearly a strong advantage of the tool. An original aspect of WHY is the fact that it also produces a validation. This validation is a term for the COQ proof assistant, which corresponds to the functional interpretation of the original program (using the specific monadic transformation of the WHY methodology). This term also uses the dependent type system of COQ in order to ensure that the functional program actually verifies the annotations in the program. The validation depends of course on the existence of proof-terms for the generated obligations. The fact that the validation is typechecked by COQ is a guarantee that the generated proof obligations are sufficient conditions for the program to meet its specification; it plays a role of certificate. Because, it is easy to make a mistake in the semantical interpretation of programs and annotations or in the generation of proof obligations, we think this validation is a very strong factor of confidence in our method. WHY is a tool which is regularly evolving. We integrate aspects which are not necessarily in the theory but which are needed for practical applications. We detail some of these aspects. Tools for Java and C The WHY tool uses its own language, but we are developing also front-end in order to accept programs written in established programming languages. Our approach is based on a translation from source code into an equivalent program written in WHY as shown in figure 2. Indeed, even if WHY does not handle complex data-structures, it is based on a modular design where new sorts, predicates and functions can be specified and used freely in specifications. Programs can also be introduced abstractly by just giving their specifications which includes types, pre and post-conditions, read and written variables as well as possibly raised exceptions. In order to use the proof obligations generation of WHY for programs written in C or Java, it is just necessary to write a model of the memory and data-structures with appropriate annotated programs WHY Coq PVS HOL-light Mizar Simplify harvey CVC-lite Proof obligations Figure 1: Multi-prover approach in WHY 12

13 abstract operations and axioms. The KRAKATOA tool follows this approach and automatically translates a program written in Java annotated using JML (Java Modeling Language [19]) into a WHY program. The CA- DUCEUS tool follows the same line with C programs annotated in a specification language we designed. The core of the difficulty in designing KRAKATOA or CADUCEUS is the representation of the heap (Paragraph 4.1.2). We are trying to extend the class of programs we can handle, our extensions being strongly motivated by the applications Specification languages Specification languages for expressing properties of programs play a central role in our tools. For Java, we chose an existing language (JML) but there was no equivalent proposal for C programs, so we decided to propose a new language which is inspired by JML. However, extensions of these languages are necessary in order to deal naturally with most programs. One first extension is related to the modularity of generation of proof obligations which become necessary in order to handle large program. Indeed, when the control flow becomes complicated, the generation of proof obligations which is based on computation of weakest precondition produces very large formula. The solution we adopted is to write local pre and post-conditions which annotate a statement and are treated as a black box (like a sub-routine invocation). This approach has been proved very useful both in the case of Java Card applet analysis (in the VerifiCard project) or for C code used in aeronautics and analyzed by Dassault Aviation. We sent our suggestions to the JML authors in order to have them integrated in the standard. Another need is related to the overflow problem both in integer or floating point numbers computations. For the moment our tools are not dealing with that problem but we plan to add such a possibility. There are different possibilities for the user, either to forbid any overflow annotated programs Java+JML annotated C KRAKATOA CADUCEUS WHY COQ PVS Simplify harvey CVC-lite Provers Figure 2: Translation from programming languages into WHY 13

14 or to work explicitly with arithmetic rules modulo the capacity or to use an arbitrary precision arithmetic. For floating point numbers, we started to work on the production of proof obligations specific to numbers intervals, the goal is to control the cumulated approximation errors. This work is done in collaboration with Marc Daumas at ENS Lyon (Arenaire project). Finally, there is a strong need of extensions in order to express high-level properties, in particular temporal properties at the level of combination of methods. This aspect is related to the research described in Assistant for writing specifications A drawback of the approach of WHY/KRAKATOA/CADUCEUS is the lack of diagnostic when the proof obligations are finally not provable. In that case, an automatic prover like Simplify produces a counter-example, that is an instance of the proof obligation that it considers as being non valid. We wish to be able to analyze this counter-example and to be able to relate it to the source code in order to suggest a change in the specification or the program, for instance adding a pre-condition. The difficulty is first to simplify the counter-example which is in general too large for readability and then to inverse the logical formula in order to express the condition using the programming constructions of the original annotations. Another need is the automatic generation (or at least suggestion) of annotations required in order to ensure that the program will not do basic illegal instructions such as division by zero, null pointer dereferencing, access outside the bounds of an array... The idea is to directly use the propagation of assertions associated to dangerous operations via the weakest precondition mechanism of WHY. More generally, we plan to study the integration of help for writing annotations in our tools: from higher-level specifications (following idea presented in 4.1.4) or with specific methods for a particular class of problems (like intervals for floating point approximations like explained in 4.2.2). The figure 3 page 15 presents our plans for the global architecture of our tools. 4.3 Automated deduction The preceding section shows that we are intensive users of automatic or interactive proof tools. But we also would like to do research in that area in order to adapt or specialize general tools to the particular theories which are useful for proving programs. Our past and current experiments with the Simplify prover show that a large part (95%) of generated proof obligations are solvable automatically. We think that such kind of tools could be improved, both in term of power and in term of architecture (safety, modularity, generation of proof trace, etc.) Decision Procedures for proving programs We deliberately choose to express properties of programs in a general and expressive logical language, containing at least first-order logic and using arithmetical properties. Consequently the generated proof obligations cannot be in general automatically proved (the underlying logic being undecidable). But the WHY approach works independently of the provers and at the 14

15 moment seven different provers can be used (Figure 1, page 12). Consequently, it is possible to first try an automatic prover such as Simplify and continue with an interactive prover such as COQ for obligations which cannot be proved automatically. But this is not satisfactory. If the obligation is solved automatically, we have to trust the prover. Automatic prover are complex programs, often finely tuned for efficiency, but which can sometimes give wrong answers (this is the case of Simplify for instance). Interactive theorem provers, on the other side, are often based on a safe kernel and offer better guarantee of correctness of results. A first objective is to ask the automatic theorem prover to produce a trace that could be checked afterwards in a systematic way. Checking the trace with COQ will give a very safe chain of validation: program proof obligations script COQ for proving obligations (generated by hand or automatically) certificate (WHY validation) checked by COQ. In order to produce traces, it is necessary to adapt the prover. This will be part of the work of Nicolas Ayache during his MPRI internship, both using harvey and CVC-lite. For his PhD thesis, Pierre Corbineau is developing a powerful mechanism for interpreting proof traces within COQ, and we plan to use this mechanism for that purpose. A second objective is the definition of strategies of proofs adapted to the predicates used in our specifications. For instance, if the annotations are coming from high-level specifications as described in paragraph 4.1.4, then it will be necessary to produce corresponding dedicated theories associated with specialized strategies. For the moment, we developed for simple cases, specialized tactics for the COQ system but they need to be generalized and to be more systematic. Such a tool already exists for controlling approximation in floating point numbers computations (as mentioned in paragraph 4.2.2) a COQ script is produced, which proves formally that the result of a computation is in a particular real interval. High level specification (UML... ) annotated programs (Java+JML/C/Caml/... ) KRAKATOA/CADUCEUS/... feedback WHY COQ proof trace success Automatic prover failure Figure 3: Future architecture 15

16 4.3.2 Proofs of termination For programs with while loops or with recursive functions, an important property is termination which has to be proved for each execution. We have an important expertise in this domain both from the theoretical point of view [22, 30, 31, 23] and in practice: CiME [8] provides automatic procedures for proving termination of rewriting systems, and TALP [25] proves termination of Prolog programs. We have been working on checking automatically generated proofs of termination. In his DEA [13], T. Hubert introduced a way to check the proofs obtained by the modular technique of dependency pairs [22, 2]. It allows CiME to generate a COQ proof that the termination of a simple set of dependency pairs is a sufficient condition for proving termination of a complex system. The automatic tool (in that case CiME) uses powerful techniques in order to compute the dependency pairs, but the validity of the result can be safely checked by COQ. It is necessary to establish a link between termination of programs written in C or Java (or even the specific language of WHY) and the termination of rewriting systems. The approach using a translation was successful for logic programs [25] and we plan to adapt it for purely functional programs à la ML. Finally, we have a collaboration with University of Illinois at Urbana-Champaign (José Meseguer) on the proof of termination of Maude programs [9] which are conditional equational programs with set-constraints and strategies. 4.4 Applications The techniques we are developing can be naturally applied in domains which require to develop critical software for which there is a high need of certification. The KRAKATOA tool was successfully used for the formal verification of a commercial smart card applet [16] proposed by Axalto company, this case study have been conducted in collaboration with B. Jacobs group at University of Nijmegen and N. Rauch at University of Kaiserslautern. The KRAKATOA tool is currently under evaluation at Axalto for verification of other applets. We have a project of collaboration with the National Institute of Aerospace (avionics systems) for checking Java programs used for plane collision avoidance, for which we need to improve the PVS output Telecommunications Applications in telecommunications are about specification and proof of protocols and also about the analysis and proof of embedded software like Java applets. Our main partner in the telecommunications area is France Telecom R & D in Lannion (Cuihtlauac Alvarado, Pierre Crégut). Proofs of protocols In the framework of the project CALIFE (RNRT) followed by AVER- ROES (RNTL), we collaborated to the definition of a model of parameterized timed automata. In the simplest cases, these automata can be manipulated automatically by model-checking tools. In general, a model of the automata as a transition relation can be translated in COQ, then parametric proofs can be done interactively. The CALIFE platform developed by B. Tavernier from CRIL technology offers the possibility to specify a protocol by drawing an automata introducing states and transitions. The 16

17 graphical description is automatically translated into inputs for different provers. This framework has been used in order to develop and prove the ABR algorithm which realizes a conformity control in ATM network. A version of the CSMA/CA protocol for collision avoidance in the Ethernet protocol has also be defined. A finite version has been automatically proved using model-checker as a back-end while a parametric version using an arbitrary number of senders has been interactively proved using COQ. The current development in the AVERROES project concerns the improvement of proof automation and the design of methods and tools in order to model and analyze probabilistic protocols. A typical example is CSMA/CD for collision detection in Ethernet protocols where the waiting time before trying to resend a message after a collision is computed randomly. Proofs of applets Mobile phones architecture are largely based on a Java Virtual machine (either on the smart card or in the terminal). The phone can download new applications. These programs can be developed by many different people, so it is necessary to have good techniques in order to guarantee that the application would not perform unwanted operations Aeronautics Aeronautics is also an area where safety constraints are high. There are different kind of applications that needs to be analyzed and proved. It can be algorithms expressed in high-level languages. This is the case for compilers and code generation tools which are used for producing embedded code. We already collaborated with Dassault Aviation and EADS in the Genie project on the proof of the Scade compiler which produces C code from a high-level description using the reactive synchronous language Lustre. Algorithms computing trajectories, for instance in air traffic control require to reason using real numbers which can be done naturally in the COQ system. We are collaborating in this area with the team of César A. Muñoz at National Institute of Aerospace (NASA, Hampton): the algorithms are written in Java and proved using PVS, KRAKATOA is under experimentation for the generation of proof obligations. Finally, there are needs of specifications and proofs directly on the C code which is loaded in the embedded systems. Emmanuel Ledinot at Dassault Aviation is currently experimenting the new CADUCEUS system Banking applications Banking area is an obvious domain of applications. The main problem is to prove security properties. France has an important industrial activity in the domain of smart cards. The code embedded on smart cards can be written in a high-level language such as Java Card for applets, or can be written in C for instance for the operating system, the virtual Java machines or the native methods for cryptography. Tools like KRAKATOA and CADUCEUS find natural applications in this domain. The multilanguage approach of WHY should allow to consider systems where we can mix code written in C and Java in the same model. Banking applications are concerned with security problems which can be the confidentiality and protection of datas, authentication... The translation of such specifications into assertions in the source code of the program is an essential problem. We have been working on a applet for an electronic purse Demoney [7] developed by the company Trusted Logic for experimental 17

18 purpose. We are also collaborating with Axalto on the proof of part of the smart card operating system. 5 Software development 5.1 Why The Why tool produces verification conditions from annotated programs given as input. It differs from other systems in that it outputs conditions for several existing provers (including COQ but also PVS, HOL-light, Mizar, Simplify, harvey and CVC-lite). Why has been used by external researchers in published verifications of non-trivial algorithms (Efficient square root used in GMP, Knuth s algorithm for prime numbers). Why is also aimed at being used as a back-end for other tools dealing with real programming languages, like for KRAKATOA and CADUCEUS presented below. WHY is approximately lines of Objective Caml code. It is distributed as open source since July 2002, under the GPL licence, at URL KRAKATOA KRAKATOA is a prototype verification tool for Java programs, using Why as a back-end. It contains approximately lines of Objective Caml code and is distributed as open source since March 2003, at URL It is currently under experimentation at Axalto company, at National Institute of Aerospace (NIA). 5.3 CADUCEUS CADUCEUS is a prototype verification tool for C programs, using Why as a back-end. It contains approximately 9000 lines of Objective Caml code and is distributed since 2004 as open source, under the GPL licence, at URL It is currently under experimentation at Axalto company and at Dassault Aviation company. 6 Links with other project/teams 6.1 Related INRIA research teams Other INRIA projects are sharing objectives with this project. We have strong collaborations with them. LogiCal INRIA Futurs. We are collaborating regularly with the LogiCal project, where we come from and we shall continue to work closely together. J.-C. Filliâtre and C. Paulin still participate to the COQ assistant development team, in particular in the discussions regarding evolutions. The LogiCal project is working on applications of proof techniques in the domain of mathematics. However, developments in mathematics and proof of programs are closely related (mathematics involve solving problems using computations, and proof of programs requires mathematical properties). So the results obtained in one 18

19 domain can have important impact on the other. Also the domain of the integration of automatic deduction and type theory is really a challenge for both projects. The interest of the ProVal project is first to have convenient tools for proving proof obligations, while the LogiCal project focuses for the moment on designing powerful frameworks which combine type theory and automated deduction. Everest INRIA Sophia-Antipolis. The Everest project was created from the Lemme project with which we are collaborating for many years on the development of proof systems, interfaces and environments for proofs and programs. The Everest project is working more specifically on the use of formal methods in the development of trusted personal devices, in particular smart cards, operating systems and mobile and embedded applications. The Everest project has used the COQ system in order to model the architecture of a Java Card, in particular typing and byte-code execution. These are very large developments and the project developed specific languages and methods in order to get a natural description of the different abstract machines and their transformation. Everest and LogiCal were partners of the IST project VERIFICARD. In parallel to this project, the Gemplus company developed JACK an environment for the specification and proof of Java programs annotated with JML specification. The proof obligations were first derived in a model of Java programs written in the B language. INRIA signed a arrangement with Gemplus in order to continue the development of the JACK in the Everest project. JACK and KRAKATOA are tools with similar functionalities. However they are developed in different perspectives. JACK has been designed for being used in an industrial environment, it benefits from an advanced interface. KRAKATOA is an open source project with an architecture which is safe and the possibility to integrate programs in different languages. Lemme INRIA Sophia-Antipolis. The Lemme project develops formal methods for the construction of safe software in the domain of scientific computing software (computer algebra, computer arithmetics) and software for smart cards. The project develops methods and tools to help in producing correct programs from mathematical descriptions of data, algorithms, programming languages, their properties and the proofs of these properties. This project is a privileged user of the COQ system. It is contributing to this system by the development of interfaces, libraries and proof tactics. Protheo LORIA. The Protheo project aims at designing and implementing tools for program specification and verification. It is working on an environment for prototyping such tools, on theorem provers specialized in proofs by induction and equational first-order proofs, on proof techniques involving constraints and rewrite rules. We are collaborating with the Protheo project in particular in the RNTL project AVER- ROES. We share a common objective to build certified libraries in COQ for manipulating rewriting systems. Cassis The aim of the Cassis project is the design and the development of tools for checking the safety of systems with an infinite number of states. These tools are based on automated proofs, symbolic exploration of models, and tests generation. The main techniques is reduction to constraints solving. The applications are embedded softwares on smart cards, for example, security protocols and distributed systems. 19

20 The Cassis project is developing the HaRVey tool for automated deduction. We are collaborating with Silvio Ranise, in particular in the ACI Geccoo in order to integrate HaR- Vey as one of the automated prover used by WHY, KRAKATOA and CADUCEUS. 6.2 Related international research teams Java/JML The Java Modeling Language (JML) [17] is a specification language which can be used to describe the behavior of Java modules in the spirit of Eiffel s design by contract approach. It has been designed initially by G. Leavens team at Iowa State University and is now supported by a cooperative effort. The formula of this language are based on simple Java expressions (without side-effect) extended with logical quantifiers. The specification language contains annotation for pre and postconditions, class invariants, loop invariants, exceptional behavior and abstract specification. On top of this specification language, different tools (see [5] for an overview) have been designed which automatically produce documentation (jmldoc), generate equivalent code with runtime checks (jmlc), or unit tests (jmlunit). These tools are developed in a sourceforge project. All these tools are based on a parser and a typechecker for Java+JML programs. One of our current work is to reuse these general analysis tools as a front-end of our KRAKATOA tool. We are also following the JML mailing list in order to discuss extensions that could be useful for our purposes. Static analysis There are also tools doing static analysis of Java programs annotated with JML specification. The tool ESC/Java, originally developed at Compaq research was intended to automatically check basic properties of Java code, possibly using user annotations. ESC/Java is based on the Simplify theorem prover. An important aspect of ESC/Java is that it is neither sound nor complete. The development of this tool stopped and a new version ESC/Java2 which is fully compatible with JML is under development coordinated by Nijmegen university. ESC/Java2 does more verification but still remains unsound and incomplete. The Nijmegen university developed also the LOOP tool which uses PVS for representing the Java programs and prove their properties. We collaborated on this subject during the VerifiCard project. However, LOOP was very complicated to use and was never officially released. The Nijmegen university, together with INRIA Sophia-Antipolis is now supporting the development of the Jack tool initiated by Gemplus (see section 6.1-Everest for discussion of links between Jack and KRAKATOA). The general effort on JML is a very good opportunity for enhancing the use of formal methods in industrial applications. Environments for sound and complete proofs of correctness will be useful for the development of critical applications by experts. At the moment, the KRAKA- TOA tool appears to be the only publically available tool for doing such a strong analysis. Our approach is based on a multi-language and multi-prover architecture which allows rapid prototyping of new functionalities. The architecture we have proposed is both efficient (direct generation of independant proof obligations) and safe, due to the construction of the validation which is the semantical representation of the program in our model. 20