Towards semi automated equivalence checking of spi calculus

` degli Studi di Udine Universita ` di Scienze Matematiche Fisiche e Naturali Facolta Corso di Laurea Specialistica in Informatica

Master Thesis

Towards semi automated equivalence checking of spi calculus processes

Candidate:

Supervisor:

Temesghen Kahsai

Prof. Marino Miculan

Academic Year 2005-2006 Universit` a degli Studi di Udine Via delle Scienze, 206 33100 Udine Italia

to my beloved family

Summary I protocolli di sicurezza vengono usati oggigiorno per proteggere i sistemi di comunicazioni e le transazioni in rete da attacchi maligni. La progettazione di tali protocolli risulta abbastanza difficile. Molto spesso, protocolli apparentemente sicuri si sono rivelati in un secondo tempo non del tutto affidabili. Diversi attacchi a questi sistemi hanno testimoniato la necessità di adoperare dei metodi automatici, per poter verificare la correttezza di tali protocolli. In generale vi sono due modi per poter verificare la correttezza di questi sistemi: uno basato sul Model Checking e l’altro basato sul Theorem Proving. I due meccanismi di verifica si differenziano dal grado di automazione ed espressività. Nel progetto descritto in questa tesi ci siamo occupati dello sviluppo di un ambiente semi-automatizzato per la formalizzazione e verifica di protocolli di sicurezza. In questo lavoro ci siamo proposti di analizzare i protocolli di comunicazione, utilizzando lo spi-calcolo come modello astratto [AG99]. Lo spi-calcolo estende un particolare modello per la connessione dei sistemi interattivi (il π-calcolo) al quale vengono aggiunti delle primitive utili alla crittografia. L’approccio che seguiremo per la verifica di correttezza si basa sull’ equivalenza comportamentale fra processi; in generale la nozione di bisimulazione tra processi può essere usata per verificare l’autenticazione e la segretezza. Abbiamo formalizzato la sintassi e la semantica dello spi-calcolo nella logica del theorem prover Isabelle HOL [NP92], con l’aggiunta della Nominal logic [UT05]. Abbiamo usato le definizione di framed bisimulation, per poter testare l’equivalenza di due processi [AG98]. Sviluppi ulteriori a questa definizione sono stati apportati da H.H¨ uttel [Hut02], che considerando lo spi calcolo finito, ha sviluppato un algoritmo per poter decidere la framed bisimilarità di due processi. In questa tesi, abbiamo utilizzato l’ idea generale di tale algoritmo, e abbiamo apportato delle ottimizazzioni alla definizione di d-framed bisimulation. Tali ottimizazzioni sono mirate ad “aiutare” le tattiche

già implementate di Isabelle nel processo di verfica. Infine abbiamo proposto degli sviluppi futuri, quali: (1 ) una possibile integrazione con un model checker; a questo proposito nella parte finale della tesi verrà riportato una possibile tecnica. (2 ) lo sviluppo di una tattica ad hoc in Isabelle per la verifica della framed bisimulazione fra processi; infine (3 ) la formalizzazione, della bisimulazione simbolica, utilizzando le stesse tecniche adoperate in questa tesi.

Abstract Security protocols based on cryptographic primitives are used today to protect computer systems and network transactions from malicious attacks. These protocols have been known to be notoriously hard to design due to their complexity. Many subtle attacks have been shown that are difficult to catch by manual analysis alone. There is therefore a need for formal automated tools to assist in the design of security protocols. Many researchers in the last years applied automated and semi-automated (or manual) tools to analyze security protocols. These techniques can be divided in two classes: those based on Theorem Proving and those based on Model Checking. These tools differ in the degree of automation and expressiveness; also the assumptions made in modeling protocols make some tools better suited than others in catching certain classes of errors. In this thesis we will focus on the development of a semi-automatized environment for the full formalization of correctness proofs of security protocols. The correctness proofs of security protocol can be expressed as statements of behavioral equivalence. Generally speaking bisimulation can be used for proving authenticity and secrecy properties of protocols, and also for justifying certain protocol optimizations. The setting of this work is the spi calculus, an extension of the π-calculus with cryptographic primitives [AG99]. As a theorem prover we use Isabelle/HOL with the newly developed environment of Nominal Logic [UT05]. We use the definition of bisimulation for cryptographic protocols introduced by M.Abadi and A.D.Gordon, which is the Framed Bisimulation [AG98]. This definition is specifically designed for cryptographic protocols, and it also includes a precise model of the knowledge of the environment which a protocol may interact with. Basically using bisimulation techniques it is possible to prove that two evaluators with non-deterministic evaluation orders

define the same evaluation relation. Further refinement to the definition of framed bisimulation has been made by H. H¨ uttel [Hut02], by considering a finite-fragment of the spi calculus. For this fragment an algorithm for deciding bisimulation has been provided. The late algorithm has been integrated in the proof environment in order to automatize the deciding procedure of bisimulation between two processes.

Acknowledgments Any significant milestone in my life is made possible by the contributions of many others along the way. My extream appreciation and thanks goes to my supervisor Prof. Marino Miculan, for his constant encouragement, guidance, motivation and support. I am very grateful to Dr. Kidane Yemane, who has always been there to support and encourage me all along the way from the first day that I met him in Uppsala. I acknowledge Ministry of Education in Eritrea for giving me the chance to study abroad, and the Italian foreign ministry (D.G.P.C.C ), for the financial support during my entire time in Udine and outside. My deepest appreciation goes to all my teachers at the department of Computer Science, and a special thanks in general to the University of Udine, for giving me the opportunity to study in different countries as an exchange student. Out side school, I would like to thank all my friends for the fun times. Fiorello and Nadia, Temesghen, Meron, Ernest and Paolo are all thanked making Udine not only a place to learn, but also a place to have fun. My final words are reserved to my family: my mom Abrehet, my sisters Yordanos, Selamawit, Lydia and my brother Efrem. Thank you all for the love and support. Temesghen Kahsai

Contents 1 Introduction

1

1.1

Process Calculi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Theorem Proving . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3.1

Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3.2

Isabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.3.3

PVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.3.4

Agda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.4

Previous work of Integration . . . . . . . . . . . . . . . . . . . . . . .

9

1.5

The project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2 Spi Calculus

13

2.1

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2

Formal semantics of spi calculus

. . . . . . . . . . . . . . . . . . . .

18

2.3

Testing equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.4

Framed Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.5

Decidability of Framed Bisimulation . . . . . . . . . . . . . . . . . .

26

3 The proof assistant Isabelle

33

3.1

Basic Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.2

Proof Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.3

Isabelle/Isar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.4

Nominal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3.4.1

Nominal datatype package . . . . . . . . . . . . . . . . . . . .

44

Proof General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

3.5

4 Modelling spi calculus in Isabelle/HOL-Nominal 4.1

Spi-calculus syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 49

ii

Contents

4.2

Substitution in Terms and Processes . . . . . . . . . . . . . . . . . .

53

4.3

Formal Operational Semantics . . . . . . . . . . . . . . . . . . . . . .

56

4.3.1

Framed Bisimulation . . . . . . . . . . . . . . . . . . . . . . .

59

Formal proofs of properties and examples . . . . . . . . . . . . . . .

65

4.4.1

Properties about names and variables . . . . . . . . . . . . .

66

4.4.2

Example of framed bisimilarity . . . . . . . . . . . . . . . . .

68

D-Framed Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . .

70

4.4

4.5

Conclusions

77

C.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

C.1.1 Further improvements . . . . . . . . . . . . . . . . . . . . . .

77

C.1.2 Symbolic Bisimulation in Isabelle-Spi . . . . . . . . . . . . . .

77

C.1.3 Integration with a model checker . . . . . . . . . . . . . . . .

79

A Appendix Bibliography

81 85

List of Figures 2.1

Commitment relation . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.2

Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.3

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.4

EQ Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.5

EQ Abstraction and Concretion . . . . . . . . . . . . . . . . . . . . .

23

2.6

Algorithm for checking bisimilarity [Hut02] . . . . . . . . . . . . . .

32

3.1

Inductive definition example . . . . . . . . . . . . . . . . . . . . . . .

38

3.2

Coinductive definition of lazy lists . . . . . . . . . . . . . . . . . . .

38

C.1 Possible integration with a model checker . . . . . . . . . . . . . . .

79

iv

List of Figures

1 Introduction “Manual verification is at least as likely to be wrong as the program itself.” - Pierre Wolper, in [P.W] The distribution of applications across the computer network is nowadays more and more important in our lifes. Not only the communication, but also the functionality of computers itself is very important in this new digital era. In many cases computers are granted critical tasks. For instance, airplanes are controlled by automatic pilots, basically all the money transaction are made through the use of computers. Therefore it is essential that these complex systems behind the computers behave as intended. These computer systems tend to be large, distributed and intricate, and most of the time it is not possible to test these systems in the real environment because this would be expensive and sometime time-consuming [Gri00]. One way to make sure that these systems behave correctly is to use Formal Methods to enhance confidence in these systems. Basically formal methods use mathematical languages to specify the systems and the intended properties, consequently it is possible to prove that the system has these properties. The field of formal Methods is very large; out of the many different areas, this MSc thesis will focus on the use of formal methods for the verification of security protocols. The two main approaches to the formal verification of security protocols are based, respectively, on Model Checking which basically is algorithmic verification, and Theorem Proving which is deductive verification. These two approaches have complementary strengths and weaknesses, and their combination promises to enhance the capabilities of each. As is often the case, the combinations can be classified according to how tightly the different components are integrated, their range of application, and their degree of automation.

2

1. Introduction

Model checking algorithms can automatically decide if a temporal property holds for a finite-state system. Furthermore, they can produce a counterexample computation when the property does not hold, which can be very valuable in determining the corresponding error in the system being verified or in its specification. However, model checking suffers from the state explosion problem, where the number of states to be explored grows exponentially in the size of the system description, particularly as the number of concurrent processes grows [Uri00]. Theorem proving is a tool that can be used to reason formally many aspects of a system. Deductive verification, based on general-purpose theorem proving, applies to a wide class of finite and infinite - state systems. It provides relatively complete proof systems, which can prove any temporal property that indeed holds over the given system, provided the theorem proving tools used are expressive and powerful enough. Unfortunately, if the property fails to hold, deductive methods normally do not give much useful feedback, and the user must try to determine whether the fault lies with the system and property being verified or with the failed proof [Uri00]. Given their complementary nature, of both model checking and theorem proving, it seems natural to combine the two methods in such a way that the desirable features of each are retained, while minimizing their shortcomings. The expressiveness and the power of the theorem provers logic can be used to accumulate a variety of program modeling and verification paradigms, so infinite state and parametrised designs can be verified. However, using a theorem prover usually is not transparent and require a fair amount of expertise and a sophisticated insight and guidance by the user. On the other side, model checking is transparent and is effective for verifying finite state automata, but it suffers from the state explosion problem. A combination of the two techniques can therefore alleviate the problems inherent to each of them when used in isolation.

1.1

Process Calculi

Process calculi are a diverse family of related approaches to formally model concurrent systems. Process calculi provide a tool for the high-level description of interactions, communications, and synchronizations between a collection of independent agents or processes. They also provide algebraic laws that allow process descriptions to be manipulated and analyzed, and permit formal reasoning about equivalences between processes, for instance using bisimulation.

1.2. Model Checking

3

Leading examples of process calculi include CSP, CCS, ACP, π-calculus, ambient calculus, fusion calculus and the spi calculus. This project will focus on the spi calculus [AG99]. The spi calculus is an extension of the π-calculus with addition of cryptographic primitives. The π-calculus is a small but extremely expressive programming language[SW01], intended to be as a foundation for concurrent computation, in the same way in which the λ-calculus is a foundation for sequential computation. The π-calculus primitives for channels are simple and powerful. Communication channels can be created and passed, for example from authentication servers to clients. In this case, the π-calculus through it’s scoping rules, guarantee that a malicious attacker cannot access a channel that it is not explicitly given; consequently we can assert that scoping is the basis of security. π-calculus is a suitable calculus of protocols for secure communication, but it does not express the cryptographic operations that are widely used for the implementation of channels in distributed systems. Specifically it does not include any constructor for encryption and decryption. Cryptographic operations and communication through channels are the main ingredients of the spi calculus. Spi calculus is designed in order to enable the study of cryptographic issues in more detail, and to describe and analyze security protocols, such as those for authentication and for e-commerce. These protocols are based on cryptography and on communication channels with properties like authenticity and privacy [AG99]. The process of checking this properties are reduced to the verification of the bisimulation between processes. In general, bisimulation can be used for proving authenticity and secrecy properties of protocols, and also for justifying certain protocol optimizations [AG98]. More details are reported in chapter 2.

1.2

Model Checking

Model checking is an algorithmic technique to determine whether a temporal property holds of a program. Perhaps the most useful property of the model checking algorithm is that it can generate a counterexample computation if a linear time property fails to hold of the program. The counterexample details why the model doesn’t satisfy the specification. By studying the counterexample, we can pinpoint the source of the error in the model, correct the model, and try again. The idea is that by ensuring that the model satisfies enough system properties, we increase our confidence in the correctness of the model [CGL94].

4

1. Introduction

This computation acts as a “certificate” of failure, as it can be checked easily and efficiently by a method independent of model checking - i.e., by simulating the program to determine whether it can generate the computation. On the other hand, if it is determined that a property holds, model checkers produce only the answer “yes” ! Much of the success of model checking is due to the fact that is a fully automatic verification method. Interactive methods are more general but harder to use; automatic methods have a limited range but are more likely to be accepted [CGL94]. In interactive verification, the user provides the overall proof strategy; the machine augments this by checking the correctness of each step, maintaining a list of assumptions and subgoals, applying the rules and substitutions which the user indicates, searching for applicable transformation rules and assumptions.

Formally, the problem can be stated as follows: given a desired property, expressed as a temporal logic formula p, and a model M with initial state s, decide if M,s p. From a logical viewpoint, the system is described by a semantical (Kripke-)model. Arguing about system correctness, therefore, amounts to determining the truth of formulas in model. With the completely automatic approach it may be necessary for the model checking algorithm to traverse all reachable states of the system. This is only possible if the state space is finite. Whereas other automated deduction methods may be able to handle some infinite-state problems, model checking tools face a combinatorial blow up of the state-space, commonly known as the state explosion problem, that must be addressed to solve most real-world problems. There are several approaches to combat this problem. One way is to use Symbolic algorithms that avoid ever building the graph for the finite state machine. Instead they represent the graph implicitly using a formula in propositional logic. Then, they use binary decision diagrams or SAT solvers, to perform the graph search. Another way is to use the Partial order reduction on explicitly represented graphs, to reduce the number of independent interleavings of concurrent processes that need to be considered.

1.3. Theorem Proving

1.3

5

Theorem Proving

Automated theorem proving is the proving of mathematical theorems by a computer program. Depending on the underlying logic, the problem of deciding the validity of a theorem varies from trivial to impossible. Despite some theoretical limits, due to the complexity of some systems, practical theorem provers can solve many hard problems in these logics. Interactive theorem provers require a human user to give hints to the system. Depending on the degree of automation, the prover can essentially be reduced to a proof checker, with the user providing the proof in a formal way, or significant proof tasks can be performed automatically. Interactive provers are used for a variety of tasks, but even fully automatic systems have by now proven a number of interesting and hard theorems, including some that have eluded human mathematicians for a long time. However, these successes are sporadic, and work on hard problems usually requires a proficient user. Some of the most used interactive proof assistants are the following: Coq, Isabelle, Agda and PVS.

1.3.1

Coq

Coq is a proof assistant for higher-order logic, allowing the development of computer programs consistent with their formal specification. It is the result of about twenty years of research of the Coq project [BB96]. The three main aspects of Coq proof assistant are: the logical language in which is wrote the axiomatizations and specifications, the proof assistant which allows the development of verified mathematical proofs, and the program extractor which synthesizes computer programs obeying their formal specifications, written as logical assertions in the language. The logical language used by Coq is a variety of type theory, called the Calculus of Inductive Constructions (CIC). The underlying pure Calculus of Constructions is the most powerful system in Barendregt’s λ-cube. It combines polymorphic, higher order and dependent types. The additional inductive types provide a powerful and natural mechanism for the definition of data types, specifications and predicates as well as for proofs by structural induction. Formally, CIC is a typed λ-calculus. Its natural deduction style proof rules are used to derive judgments of the form Γ ` t : T meaning that in context Γ, term t has type T.

6

1. Introduction

The latest development of Coq includes the following feature: a mechanism for automatic generation of certified programs from proofs of

their specifications a graphical user interface based on gtk (CoqIde) a documentation tool (coqdoc) dependency and makefile generation tools for Coq (coq makefile and coqdep)

The current stable version is the 8.1, and is available for different platforms: Unix, Windows and Mac OS X.

1.3.2

Isabelle

Isabelle is a generic theorem prover developed in Cambridge(UK) and in Munich [NP92] [Pfe]. The first version of the system was made available in 1986. Isabelle uses several ideas of the LCF prover [Pau87]: formulae are ML values, theorems are part of an abstract data type and backward proving is supported by tactics and tacticals. The aim of the designers of Isabelle was to develop generic proof checker, supporting a variety of logics, with a high level of automation. Isabelle is written in ML, and it is used in a broad range of applications: formalizing mathematics(including semantics), logical investigations, program development, specification languages, and verification of programs or systems. Isabelle has a meta-logic, which is a fragment of higher-order logic. Formulae V in the meta-logic are build using implication ⇒, universal quantification and equality ≡. All the other logics(the object logics) are presented in this meta-logic. Isabelle support reasoning in several object-logics, such as first order logic, higher order logic, Zermelo-Fraenkel logic, etc.. It provides a powerful generic framework for rapid prototyping of deductive systems. In this thesis we will restrict attention to typed higher-order logic (HOL). HOL uses the polymorphic type system of the meta-logic. The specification language of Isabelle is inspired by functional programming languages (especially ML). In Isabelle, every goal consists of a list of assumptions and one conclusion. One should read the goal [A1 ; ...; An ] ⇒ B as A1 ⇒ (A2 ⇒ ...(An ⇒ B)). The basic proof method of Isabelle is resolution.

1.3. Theorem Proving

7

Isabelle supports both forward and backward proving, although its emphasis lies on backward proving by supplying many useful tactics for it. A tactic transforms the proof goal into several subgoals and gives a justification for this transformation. Isabelle does not give elaborate proof support. The user has to keep track of everything. A good improvement of the Isabelle system as been made through the introduction of the Isar framework [Wen99]. Isabelle/Isar is a generic framework for human-readable formal proof documents, based on higher-order natural deduction. The Isar proof language provides general principles that may be instantiated to particular object-logics and applications. An important package for this project is the nominal datatype package [UT05]. The nominal datatype package implements an infrastructure in Isabelle/HOL for defining languages involving binders and for reasoning conveniently about α-equivalence classes. The work is based on the nominal logic work by Pitts et al [Pit03]. The main technical novelty introduced by Urban et al [UT05] is the explicit construction for α-equated lambda terms is compatible with the axiom of choice. Therefore the result is implemented in Isabelle/HOL. More details about the Isabelle theorem prover and the nominal datatype package is reported in chapter 3.

1.3.3

PVS

The PVS Verification System is being developed at SRI International Computer Science Laboratory [SOR93]. Work on PVS started in 1990 and the first version was made available in 1993. PVS is written in Lisp and it is strongly integrated with (GNU and X) Emacs. PVS has been applied to several serious problems. For example to specify and design fault-tolerant flight control systems. References to more applications of PVS can be found in [SOR93]. It implements classical typed higher-order logic, extended with predicate subtypes and dependent types. PVS has many buil-in types, such as booleans, lists, reals and integers; standard complex types e.g function types, product types, records and recursively defined abstract data types. The specification language of PVS is rich, containing many different type constructors, predicate subtypes and dependent types. PVS has a parametrized module system; this mean that the specification is divided in several theories and each theory

8

1. Introduction

can be parametrized with both types and values. A theory can start with so-called assuming clause, where one can states assumptions, usually about the parameters of the theory. It also allows non-unfiorm overloading, meaning that different functions can have the same name as long as they have different types. PVS represent theorems using the sequent calculus. Every subgoal consists of a list of assumptions A1 ...An and a list of conclusions B1 ...Bn . And it is read as: the conjuction of the assumptions implies the disjucntion of the conclusions i.e. A1 ∧ .. ∧ An → B1 ∨ .. ∨ Bn . PVS has limited proof strategy lanuguage, containing contstructs for sequencing, backtracking, branching, let-binding and recursion. When one whishes to go beyond this; for example to write a strategy which inspects the goal, this is done in Lisp. In order to have a rich specification language and a fast prover with a high degree of automation, it has been added some powerful decision procedure to PVS. However, these decision procedures cause soundness problems, thus the procedures can be considered to be part of the kernel, which make the kernel large and complex. All proofs in PVS are done in a special proof mode. The tool manages which subgoals still have to be proven and which stpes are taken to construct a proof.

1.3.4

Agda

Agda is an interactive system for developing constructive proofs in a variant of Martin L¨ of ’s type theory. It can be seen as a functional language with dependent types. Agda is based on the idea of direct manipulation of proof-term and not on tactics. The proof is a term and not a script. The language has ordinary programming contructs such as dataypes and case expressions, signatures and records, let expressions and modules. Agda has two user interfaces; one is a text-based inteface based on the editor GNU Emacs, and another is a graphical user interface Alfa. It is implemented in Haskell and it consists of a type checker and a termination checker. The result of type-checking is a set of typing constraints and equality constarints of yes and no answer when type-checking terms with meta-variables.

1.4. Previous work of Integration

1.4

9

Previous work of Integration

Various model checkers have already been integrated in theorem proving environments, some of them are described in: “An integration of model checking with automated proof checking” by S.Rajan,

N.Shankar and M.K.Srivas [RSS95]. “Combining model checking and deduction for I/O-automata” by O. M¨ uller

and T. Nipkow [MN95]. “Model checking for infinite state systems using data abstraction, assumption-

commitment style reasoning and theorem proving” by J. Dingel and T. Filkorn [DF95]. “A verified model checker for the modal µ-calculus in Coq” by Christoph

Sprenger [Spr98]. Common to all the first three cases is that the model checker is an external program that is invoked as needed and whose results are trusted. The question of the correctness of the model checker itself is rarely posed. Especially in the first two papers, the underlying idea is to reduce an infinite state system to a finite one using abstraction techniques. The finite state system is verified by a model checker, whereas the reduction is verified using the theorem prover. In the last case, a formalisation and correctness proof of a model checker for the modal µ-calculus in Coq’s constructive type theory. Consequently using Coq’s extraction mechanism is obtained an executable Caml program, which is added as a safe decision procedure to the system. Christoph Sprenger proposed two possibilities for an integration of a model checker with a theorem prover: (1) implementation of the model checker as an external program that generates the necessary proof object, and add this proofs as a tactic to the system or (2) to prove the model checker itself formally correct and then consider it as a trusted decision procedure. Another work done by R.Bharadwaj, A.Felty and F.Stomp in “Formalizing Inductive Proofs of Network Algorithms” [BFS95], aims to provide a strategy for carrying out formal correctness proofs of distributed network algorithms. And more important, they integrate theorem proving and model checking to increase the class of algorithms for which mechanical verification is practical. In this work, they use theorem prover Coq, and the model checker Spin to verify a broadcasting protocol.

10

1. Introduction

1.5

The project

This thesis will address some issues towards the development of a semi-automated prover for the verification of security protocols. The objectives that we are going to achieve in this project are the following: 1. Formalization of the spi calculus in Isabelle/HOL-Nominal: syntax and semantics 2. Formalization of Framed Bisimulation. 3. Formalization of D-Framed bisimulation. 4. Partial optimization of D-Framed bisimulation. 5. Give advice of how a possible integration with a model checker can be made. The approach we will present in this thesis has been designed to mainly achieve a semi-automatic environment to decide the equivalence of two processes formalized in the spi calculus logic. In brief, the idea is to formalize the spi calculus [AG99] in the logic of the theorem prover Isabelle/HOL extended with the package of Nominal Logic developed by C. Urban and C.Tasson [UT05], and to develop a proof environment for testing the equivalence of spi calculus processes based on the notion of framed bisimulation [AG98]. The use of the techniques from nominal datatypes package leads to a smooth and easy formalisation, in particular we are provided with a powerful induction rules for the semantics that can be used to prove fundamental theorems, and examples of framed bisimilarity of processes. By using this logic, agents are identified up to α-equivalence; this mean that there is no need for arguments about their bound names. This strategy is normal in the manual proof, but this kind of hand waving has previously been impossible to incorporate in a smooth way in Isabelle/HOL. In fact one of the the aim of this project is to develop a proof environment that correspond as closely as possible to the traditional manual proofs present in the literature. This means that for a person who completed these proofs manually, shouldn’t be a problem to do so also using an interactive theorem prover like Isabelle. In the 4th point, we will automatize the proof of two process being framed bisimilar. Instead of implementing directly the algorithm developed by Huttel in [Hut02], we follow the general idea and we formalize the definition of d-framed

1.5. The project

11

bisimulation by adding some optimaization, in order to “help” the proof serach tactics already implemented in Isabelle. D-framed bisimulation is a variant of framed bisimulation that only requires input transitions to be matched for transmitted message terms up to a certain depth. Moreover in the last part of the project we will give some hints and practical advice, of how a possible integration with a model checker can be done.

Outline This thesis is organised as follows. In the next Chapter we will present the spi calculus, its syntax and semantics. We will also illustrate the approach used by Huttel for deciding the framed bisimilarity of spi processes [Hut02]. Chapter 3 contains a description of the theorem prover Isabelle. A special attention will be given to the tools relevant to this project, such as : the inductive and the coinductive definition, the Isabelle/Isar system and the nominal datatype package. Chapter 4 contains the actual modelling part of the syntax and semantics of spi calculus in Isabelle/HOL-Nominal, it will also contain the definition of framed bisimulation and d-framed bisimulation. The conclusion and future work of this project will be reported in Chapter 4.

12

1. Introduction

2 Spi Calculus The spi calculus is an extension of the π-calculus with addition of cryptographic primitives [AG99]. The π-calculus is a small but extremely expressive programming language [MPW92]. It is an important result of search for a calculus that could serve as a foundation for concurrent computation, in the same way in which the λcalculus is a foundation for sequential computation. π-calculus programs are systems of independent, parallel processes that synchronize via message-passing handshakes on named channels. Channels can be restricted, so that only certain processes may communicate on them. In this respect the π-calculus is similar to earlier process calculus such as CSP and CCS. The difference is that in π-calculus the scope of a restriction - the program text in which a channel may be used - may change during computation. When a process sends a restricted channel as a message to a process outside the scope of the restriction, the scope is said to extrude, that is, it enlarges to embrace the process receiving the channel. Processes in the pi calculus are mobile in the sense that their communication possibilities may change over time; they may learn the names of the new channels via scope extrusion. Thus, a channel is a transferable capability for communication. π-calculus is a suitable calculus of protocols for secure communication, but it does not express the cryptographic operations that are widely used for the implementation of channels in distributed systems. Specifically it does not include any constructor for encryption and decryption. In fact the central idea of the spi calculus, is to use the restriction operator and scope extrusion from the π-calculus as a formal model of the possession and communication of secrets, such as cryptographic keys. Spi calculus is designed in order to enable the study of cryptographic issues in more detail, and to describe and analyze security protocols, such as those for authentication and for e-commerce. These protocols are based on cryptography and

14

2. Spi Calculus

on communication channels with properties like authenticity and privacy. Spi calculus is a middle ground: it is directly executable and it has a precise semantics. Due to the intelligibility of its semantics, spi calculus provides a setting for analyzing protocols. Specifically, security guarantees can be expressed as equivalences between spi calculus processes. For example, it is said that a protocol keeps secret a piece of information X by stating that the protocol with X is equivalent to the protocol with X’, for any X’. The equivalence in this case means equivalence in the eyes of an arbitrary environment. The environment can interact with the protocol, for instance by attempting to create confusion between different messages or sessions. This first definition of equivalence, although makes reference to the environment, it is not needed to give an explicit model of the environment. In the next chapter we will illustrate the version of spi calculus that uses an explicit definition and model of the environment. Writing the model for the environment can be tedious and can lead to new arbitrariness and error. In particular, it is always difficult to express that the environment can invent random numbers but is not lucky enough to guess the random secrets on which a protocol depends. Therefore in the first definition of spi calculus, this conflict is resolved by letting the environment be an arbitrary spi calculus process. This formalism has some similarities with other approaches for reasoning about protocols; like works based on temporal logics or process algebras. But spi calculus builds on a standard concurrency formalism; this means that is less intuitive than some other based on ad hoc formalism. In sum, the features of the spi calculus approach are its reliance on the powerful scoping constructs of the π-calculus; the radical definition of the environment as an arbitrary spi calculus process, and the representation of security properties, both integrity and secrecy, as equivalences. The model of protocols in spi calculus is simpler, but poorer, than some models developed for informal mathematical arguments because spi calculus does not include any notion of probability or complexity.

2.1

Syntax

It is assumed an infinite set of names and an infinite set of variables. Let c, m,n, p, q and r range over names, and let w, x, y and z range over variables. When they represent keys, k and K range over names too. The set of terms is defined by the following grammar:

2.1. Syntax

15

L, M, N ::= n (M, N ) 0 suc(M ) MN x

terms name pair zero successor shared − key encryption variable

MN represents the cipher-text obtained by encrypting the term M under the key N using a shared-key cryptosystem such as DES. For instance, 1 can be written as a shorthand for the term suc(0). The set of processes is defined by the following grammar:

P, Q, R ::= M hN i.P M (x).P P |Q (νn)P !P M is N P 0 let (x, y) = M in P case M of 0 : P suc(x) : Q case L of xN in P

processes output input composition restriction replication match nil pairsplitting integercase decryption

The scopes of bounds variables and names has to be interpreted as follows: (νn) P: the name n is bound in P. M(x).P: the variable x is bound in P. let (x,y) = M in P: the variable x and y are bound in P. case M of 0 : P suc(x) : Q; the variable x is bound in the second branch, Q.

P [M/x] indicates the outcome of replacing each free occurrence of x in process P with the term M, and identify processes up to renaming of bound variables and names. The abbreviation M hN i means M hN i.0

The constructs of the spi calculus have the following meanings:

16

2. Spi Calculus

The basic computational step and synchronization mechanism in the spi calcu-

lus is interaction, in which a term N is communicated from an output process to an input process via a named channel, m. – An output process M hN i.P is ready to output on channel M. If an interaction occurs, term N is communicated on M and then process P runs. – An input process M(x).P is ready to input from channel M. If an interaction occurs in which N is communicated on M, then process P [N/x] runs. A composition P|Q behaves as processes P and Q running in parallel. Each

may interact with the other on channels known to both, or with other independent processes. A restriction (νn)P is a process that makes a new, private name n, and then

behaves as P . A replication !P behaves as an infinite number of copies of P running in

parallel. A match [M is N ]P behaves as P provided that terms M and N are the same;

otherwise it is stuck, that is, it does nothing. The nil process 0 does nothing. A pair splitting process let (x,y) = M in P behaves as P [N/x][L/y] , if term

M is the pair (N, L). Otherwise, the process is stuck. An integer case process case M of 0 : P suc(x) : Q behaves as P if term M is

0 , as Q[N/x] if M is suc(N). Otherwise, the process is stuck. The decryption process case L of xN in P attempts to decrypt L with the key

N. If L has the from MN , then the process behaves as P [M/x]. Otherwise the process is stuck. For instance, P = m(x). case x of yK in m h 0y i is a process that is ready to receive a message x on the channel m. When the message is a cipher-text of the form yK , process P sends 0 encrypted under y on the channel m. This process may be put in parallel with a process Q = mhK 0 K i which sends the name K’ encrypted under K on the channel m. In order to restrict the use of K to P and Q, it is possible to use the restriction process, (νn)(P | Q). By doing this, the environment of the

2.1. Syntax

17

above process will not be able to construct any message of the form yK , since K is bound. Thus, the component P of (νn)(P | Q) may output 0K 0 , but not 0z for any z different from K’. Alternatively, the component P of (νn)(P | Q) may output 0K 0 may produce no output: for example, were it receive 0 on the channel m, it would get stuck. Next we will show, how are expressed some abstract security protocols in the spi calculus. In security protocols, it is common to find channels on which only a given set of principals is allowed to send data or to listen. The set of principals may expand in the course of a protocol run, for example as the result of channel establishment. Remarkably, it is easy to model this property of channels in the spi calculus, via the restriction operation; the expansion of the set of principals that can access a channel corresponds to scope extrusion. Consider two principals A and B that share a key KAB ; in addition, is assumed there is a public channel cAB that A and B can use for communication. The aim of the protocol is that A sends a message M under KAB to B, on cAB . Using the spi calculus syntax this is written as follows: A(M ) = cAB hMKAB i B = cAB (x).case x of yKAB in F (y) Inst(M ) = (νKAB )(A(M ) | B) P ' Q means that the behaviors of the processes P and Q are indistinguishable. I will give more details about the notion of indistinguishability in one of the next section. The properties of authenticity and secrecy can be written as follows: Authenticity : Inst(M) ' Instspec (M), for any M Secrecy : Inst(M) ' Inst(M’) if F(M) ' F(M’), for any M, M’ Instspec (M) is the specification of Inst(M). Each of these equivalences means that two processes being equated are indistinguishable, even when an active attacker is their environment. Neither of these equivalences would hold without the restriction of channel cAB . Intuitively, authenticity holds even if the key KAB is somehow compromised after its use. This can be caused, for instance by the incompetence on the part of protocol participants, and malice and brute force on the part of attackers. It is impossible to model all these factors, so it is preferred to model deliberate key publication, which is in a sense the most extreme of them. It suffices to make a small change in the

18

2. Spi Calculus

definitions of B so that they send KAB on a public channel after receiving MKAB . This change preserves the authentication property, but not the secrecy one. The above example shows that spi calculus is a natural language for describing some security protocols. In particular, the restriction operator and scope extrusion allow convenient representations for the possession and communication of channels. However there are some other example of protocols that uses relatively complicated techniques for protection against replay attacks, that shows writing a protocol in the spi calculus is a little harder than writing it in the informal notations common in the literature. But using the spi calculus the description of protocols are more detailed, and they make clear not only what messages are sent but also how the messages are generated and how they are checked. Consequently the spi calculus descriptions add complexity, but they enable finer analysis. Writing a protocol in the spi calculus is essentially similar to writing it in any programming language with suitable communication and encryption libraries. The main advantage of the spi calculus is its formal precision.

2.2

Formal semantics of spi calculus

Some syntactic conventions: fn(M) and fn(P) indicates the sets of names free in term M and process P respectively. Similarly, fv(M) and fv(P) indicates the sets of variables free in M and P respectively. A term or process is said to be closed to mean that it has no free variables. A process, in order to communicate with external world must have free names. The set Proc = {P | fv (P)} is the set of closed processes. An abstraction is an expression of the form (x)P, where x is a bound variable and P is a process. The meaning of (x)P is like a process p(x).P minus the name p. A concretion is an expression of the form νm1 , ...., mk hM iP , where M is a term, P is a process, k ≥ 0, and the names m1 ,....,mk are bound in M and P. The meaning of (νm1 , ...., mk )hM iP is like the process (νm1 , ...., mk )phM iP minus the name p, provided p is not one of m1 ,....., mk . Usually concretions are written → → as (ν − m)hM iP where − m = m , ....., m or simply (ν)hM iP . 1

k

An agent is an abstraction, a process, or a concretion. It is used the metavariables A and B that stand for arbitrary agents, and fv(A) and fn(A) stands for the sets of free variables and names of an agent A, respectively. Consequently, the definition of restriction and composition are extended to ar-

2.2. Formal semantics of spi calculus

19

bitrary agents as follows: for the abstraction (x)P, assuming that x ∈ / fv(R), is the set : (νn)(x)P , (x)(νn)P R |(x)P , (x)R |P → while concretion (ν − n )hM iP is the set: → → (νm)(ν − n )hM iP , (νm, ν − n )hM iP , if m ∈ fn(M) → − → (νm)(ν n )hM iP , (ν − n )hM i(νm)P → → (R | (νm)(ν − n )hM iP ) , (νm)(ν − m)hM i(R | Q) − assuming that m ∈ / fv(R) and that → n ∩ fn(R) = 0. → → If F is the abstraction (x)P and C is the concretion (ν − n )hM iP , and − n ∩ fn(P) = 0, the relations interaction are defined as follows: → F @ C , (ν − n )(P [M/x] | Q) → C @ F , (ν − n )(Q | P [M/x]) Intuitively the above processes are the possible immediate results of the encounter → of F andC. Given a common name p, F is like p(x).P and C is like (ν − n )phM iP , so → an interaction of F and C is a process obtained when p(x).P and(ν − n )phM iP works in parallel and communicate using p. Definition 2.2.1 The following is the definition of the reduction relation > on closed processes:

(RedRepl) (RedM atch) (RedLet) (RedZero) (RedSuc) (RedDecrypt)

!P [M is M ]P let (x, y) = M in P case 0 of 0 : P suc(x) : Q case suc(M ) of 0 : P suc(x) : Q case MN of xN in P

> !P | P > P > P [M/x][N/y] > P > Q[M/x] > P [M/x]

Definition 2.2.2 An action (or barb) is a name m, a co-name m, or the distinα

guished silent action τ . The commitment relation written as P − → A, where P is a closed process, α is an action, and A is a closed agent. This relation is defined inductively, by the rules in figure 2.1.

20

2. Spi Calculus

(Comm In) m m(x).P −→ (x)P (Comm Inter 1)

(Comm Out)

m

m

m

mhM i.P −→ (ν)hM i.P (Comm Inter 2) m

m

P −→ F Q −→ C P −→ C Q −→ F τ τ P |Q− → F @C P |Q− → C@F (Comm Par 1) (Comm Par 2) α α Q− →A P − →A α α P |Q− →A|Q P |Q− →P |A (Comm Res) (Comm Red) α α P − →A α∈ / m, m P >Q Q− →A α α (νm)P − → (νm)A P − →A Figure 2.1: Commitment relation (Barb In) m(x)P ↓ m

(Barb Out) (m)hM i.P ↓ m Figure 2.2: Axioms

Intuitively, (Comm In) says that an abstraction is the residue of an input commitment; (Comm Out) says that a concretion is the residue of an output commitment; and (Comm Inter 1) and (Comm Inter 2) say that the combination of an abstraction and a concretion gives an interaction. Thus, the commitment relation has a straightforward structural definition; that is its main appeal.

2.3

Testing equivalence

Before defining the notion of testing equivalence, let’s first look at the following definition. Definition 2.3.1 Let P be a closed process, the predicate P exhibits barb β, written as P ↓ β is defined by the following axioms and rules in figure 2.2 and 2.3: P ↓ β holds just if P is a closed process that may input or output immediately on barb β. The convergence predicate P ⇓ β holds if P is a closed process that exhibits β after some reactions: A test consist of any closed process R and any barb β . A closed process P passes the test if and only if (P | R) ↓ β. Therefore (Barb Par) P ↓β P |Q↓β

(Barb Res) P ↓ ββ ∈ / m, m (νm)P ↓ β

(Barb Struct) P ≡ QQ ↓ β P ↓β Figure 2.3: Rules

2.4. Framed Bisimulation

(Conv Barb) P ↓β P ⇓β

21

(Conv React) P → βP ⇓ β P ⇓β

testing equivalence is defined as follows: P v Q , for any test (R, β), if (P | R) ↓ β then (Q | R) ↓ β P ' Q , P v Q and Q v P The main idea oftesting equivalence comes from the work of De Nicola and Hennessy [NH84]. In that work, there are present two type of testing: the may-testing corresponds to partial correctness , while must-testing corresponds to total correctness. The definition of testing equivalence ' corresponds to the may-testing equivalence of De Nicola and Hennessy. One of the advantages of testing equivalence as the basis of the specifications of authenticity and secrecy is its simple definition in terms of the convergence predicate. According to the definitions, two closed processes P and Q are testing equivalent if their respective parallel compositions with a third process R behave similarly. It follows that P and Q can be used interchangeably in any context (not just in parallel with R). For example the following two processes are testing equivalent:

(νK)mh{0}K i (νK)mh{1}K i This mean that the (νK)mh{x}K i does not reveal to its environment whether x is 0 or 1.

2.4

Framed Bisimulation

In this section we will describe some of the equivalences on processes that approximate testing equivalence. In particular we will describe the notion of framed bisimulation. We will first recall the definition of strong bisimulation [AG98]. If R is a relation on closed processes, the relation R on closed agents: P R Q iff P R Q (x)P R (x)Q iff P[M / x] R Q[M / x] for all closed M − → → → → (ν n )hM iP R (ν − m)hM iP iff − m is a permutation of − n and P R Q

22

2. Spi Calculus

A strong simulation is a binary relation S ⊆ Proc × Proc such that if P S Q and P → A and there exists B with Q → B and A S B. A relation S is a strong bisimulation if and only if both S and S −1 are strong simulations. Strong bisimilarity, written ∼s , is the greatest strong bisimulation. Strong bisimilarity is a rather fine-grained equivalence for the spi calculus. One way of weakening strong bisimilarity is to ignore what messages are sent on what channels, and to record only what channels are used. This idea leads to the definition of barbed equivalence. Barbed simulation is a binary relation S ⊆ Proc × Proc implies: 1. for each barb β, if P ↓ β then Q ↓ β, and 2. if P → P’ then there exists Q’ such thatQ → Q’ and P’ ≡ S ≡ Q. where P’ ≡ S ≡ Q means that there exists P” and Q” such that P’ ≡ P”, P” S Q” and Q” ≡ Q’. A barbed bisimulation is a relation S such that both S and S−1 are barbed simulation. Barbed equivalence, is the greatest barbed bisimulation. Now let’s look at the definition of the bisimulation used in the development of this project. The bisimulation in question is called framed bisimulation, and is based on the notion of frames and theory. A bisimulation does not simply relate two processes P and Q, but instead relates two processes P and Q in the context of a frame and a theory. The frame and the theory represent the knowledge of the environment of P and Q. Frame: is a finite set of names. (fr : range over frames) Theory: is a finite set of terms.(th : range over theories)

Intuitively, a frame is a set of names available to the environment of the processes P and Q, while a theory includes a pair (M,N) indicates that the environment cannot distinguish M coming from P and N coming from Q. The definition (f r, th) ` M ↔ N , which is defined by induction by a set of rules, means that the environment cannot distinguish M coming from P and N coming from Q and the environment has M in interaction with P and N in interaction with Q. The induction rules are reported in figure 2.4.


(Eq Frame) n ∈ fr (f r, th) ` n ↔ n (Eq Variable) (f r, th) ` x ↔ x (Eq Zero) (f r, th) ` 0 ↔ 0

23

(Eq Theory) (M, N ) ∈ th (f r, th) ` M ↔ N (Eq Pair) (f r, th) ` M ↔ M 0 (f r, th) ` N ↔ N 0 (f r, th) ` (M, N ) ↔ (M 0 , N 0 ) (Eq Suc) (f r, th) ` M ↔ M 0 (f r, th) ` suc(M ) ↔ suc(M 0 )

(Eq Encrypt) (f r, th) ` M ↔ M 0 (f r, th) ` N ↔ N 0 (f r, th) ` MN ↔ M 0 0N Figure 2.4: EQ Terms (Eq Abstraction) (f r, th) ` P ↔ P 0 (f r, th) ` (x)P ↔ (x)P 0

→ (Eq Abstraction)(where {− n } ∩ (f r ∪ f n(th)) = 0) → − → (f r ∪ { n }, th) ` M ↔ M 0 (f r ∪ {− n }, th) ` P ↔ P 0 → − → − 0 (f r, th) ` (ν n )hM iP ↔ (ν n )hM iP 0

Figure 2.5: EQ Abstraction and Concretion For instance, if fr = n and th = (0K ,nK ), where n and K are distinct names, then we have (f r, th) ` n ↔ n and (f r, th) ` 0K ↔ nK , and also (f r, th) ` (n, 0K ) ↔ (n, nK ), but also we have neither(f r, th) ` K ↔ K nor (f r, th) ` nK ↔ 0K . The definition of the relation ↔ is also extended to processes; the predicate (f r, th) ` P ↔ Q is defined by induction. In figure 2.5 we report the two rules for abstractions and concretions. A pair (fr, th) is ok, written (f r, th) ` ok, if the following two conditions holds: 1. whenever (M,N) ∈ th: M is closed and there are terms M1 and M2 such that M = M1M2 and

there is no N2 such that (f r, th) ` M2 ↔ N2 ; N is closed and there are terms N1 and N2 such that N = N1N2 and

there is no M2 such that (f r, th) ` M2 ↔ N2 ; 2. whenever (M,N) ∈ th and (M’,N’) ∈ th, M = M’ if and only if N = N’ The first condition requires that each term in a pair (M,N) in a theory be formed by ciphertexts that the environment cannot decrypt. While the second condition is important because the environment can compare ciphertexts even when it cannot decrypt them.

24

2. Spi Calculus

Another important notion is the ordering frame-theory pairs. (fr,th) ≤ (fr’,th’) if and only if for all M and N, (f r, th) ` M ↔ N implies (f r0 , th0 ) ` M ↔ N . This relation is reflexive and transitive. Proposition 2.4.1 Suppose (fr,’th’) ` ok. Then (fr,th) ≤ (fr’,th’) if and only if fr ⊆ fr’ and for all (f r0 , th0 ) ` M ↔ N for each (M, N) ∈ th. Proof. To show this right-to-left, suppose that fr ⊆ fr’ and (f r0 , th0 ) ` M ↔ N for each (M, N) ∈ th. Consider anyM and N such that (f r, th) ` M ↔ N . An induction on the derivation of (f r, th) ` M ↔ N shows that (f r0 , th0 ) ` M ↔ N . Thus (fr,th) ≤ (fr’,th’). For the left-right direction, suppose that (fr,th) ≤ (fr’,th’). By (Eq theory), (f r, th) ` M ↔ N for any (M,N) ∈ th. So (fr,th) ≤ (fr’,th’) implies (f r0 , th0 ) ` M ↔ N . Consider any n ∈ fr, by applying Eq Frame we get (f r, th) ` n ↔ n and then (fr,th) ≤ (fr’,th’) implies (f r0 , th0 ) ` n ↔ n. The latter judgment can only be derived from Eq Frame, since (fr’,th’) ` ok. Through the above proposition, assuming that (fr’,th’) ` ok, the relation (fr,th) ≤ (fr’,th’) means that the environment may go from the knowledge represented in (fr,th) to the knowledge represented by (fr’,th’). The definition of (fr,th) ≤ (fr’,th’) implies that any indistinguishable pair of terms remains indistinguishable after the transition, and also that the set of names and terms that the environment has grown in this transition. Finally let’s look at the definition of framed relations and bisimulations. Let S fn(th) = f n(M ) ∪ f n(N )|(M, N ) ∈ th, and also let π1 (th) = M |(M, N ) ∈ th and π2 (th) = N |(M, N ) ∈ th, and write f n(π1 (th)) and f n(π2 (th)) for the sets of names S S f n(M )|M ∈ π1 (th) and f n(N )|N ∈ π2 (th) respectively. A framed process pair is a quadruple (fr,th,P,Q) such that P and Q are closed processes, fr is a frame, and th is a theory. When R is a set of framed process pairs, is written (f r, th) ` PRQ to indicate that (fr,th,P,Q) ∈ R. A framed relation is a set R of framed process pairs such that (f r, th) ` ok whenever (f r, th) ` PRQ. A framed simulation is a framed relation S such that, whenever (fr,th) ` PSQ, the following three conditions hold: τ

If P − → P’ τ

then there is a process Q’ such that Q − → Q’ and (fr,th) ` P’ S Q’.


25

c

If P − → (x)P’ and c ∈ fr τ → then there is an abstraction (x)Q’ such that Q − → (x)Q’ and for all sets − n → − disjoint from fn(P) ∪ fn(Q) ∪ fr ∪ fn(th) and for closed M and N, if (fr∪ n th) `

→ M ↔ N then (fr ∪ − n th) ` P’[M/x]SQ’[N/x]. c → − → (ν − m)hM iP’, c ∈ fr and the set → m is disjoint from fn(P) ∪ fn(π1 (th)) If P −

∪ fr c → → → (ν − n )hN iQ’ and the set then there is a concretion (ν − n )hN iQ’ such that Q − → − n is disjoint from fn(Q) ∪ fnπ (th) and there is a frame theory pair (fr’,th’) 2

such that (fr,th) ≤ (fr’,th’), (f r0 , th0 ) ` M ↔ N and (f r0 , th0 ) ` P’SQ’. The first condition requires that if P can take τ step then Q can match this step. The second condition deals with the input steps where the channel c on which the input happens is in fr, this mean that the input is known to the environment. In this case, it should be considered all the possible inputs M from the environment → to (x)P 0 . The names − n are fresh names, means that this names are generated by the environment. Similarly, it is considered also all the possible inputs N for (x)Q0 , for an appropriate (x)Q0 obtained from Q0 . Consequently it is required that given the inputs to (x)P 0 and (x)Q0 , respectively yields related processes P 0 [M/x] and Q0 [N/x]. It should be noticed that the choice of (x)Q0 is independent of the choices of M and N. The last condition is concerned about the output steps where the channel c on which the output happens is in fr. In this case, P outputs the term M while → creating the names − m. This condition requires that Q can output a corresponding → term N while creating − n . The requirement that (f r0 , th0 ) ` P’ ↔ Q’ means that the environment obtains M in interaction with P and N in interaction with Q, and that it should not be able to distinguish them from one another. Due to the non minimal requirement on (f r0 , th0 ), this pair may attribute “too much” knowledge to the environment. For example, f r0 may contain names that are neither in fr nor in M or N, so intuitively the environment would not be expected to know these names. On the other side, the omission of a minimality requirement results in simpler definitions, and does not compromise soundness. A framed bisimulation is a framed relation S such that both S and S −1 are framed simulations. Framed bisimilarity, written ∼f , is the greatest framed bisimulation. By the Knaster - Tarski fixpoint theorem, since the set of framed relations ordered by subset inclusion forms a complete lattice, framed bisimilarity exists, and equals the union of all framed bisimulations.

26

2. Spi Calculus

The problem with this definition, as pointed out in [AG99], is that the presence of the universal quantifiers is an obstacle to the development of an algorithm for constructing framed bisimulations. In particular, the condition for input steps concerns all possible inputs M and N ; these inputs are of unbounded size, and may contain an arbitrary number of fresh names. Theorem 2.4.2 Consider any closed processes P and Q, and any name n ∈ / fn(P) ∪ fn(Q). Suppose that fn(P) ∪ fn(Q) ∪ n, 0 ` P ∼f Q. Then P ' Q. The meaning of the above theorem is that if we want to prove that two processes are testing equivalent, then we may construct a framed bisimulation S such that fn(P) ∪ fn(Q) ∪ n, 0 ` P ∼f Q where n is a single, arbitrary new name. The core of the proof depends on a relation S, defined so that P S Q if and only if there is a frame fr, a theory th, and processes P1 , P2 , Q1 , Q2 , such that:

→ → P = (ν − p )(P1 | P2 ) Q = (ν − q )(Q1 | Q2 ) → and (fr,th) ` ok, (fr,th) ` P1 ∼f Q1 and (fr,th) ` P2 ∼f Q2 , where − p = (fn(P1 ) → ∪ fn(π (th))) − fr and − q = (fn(Q ) ∪ fn(π (th))) − fr. The construction of S yields 1

1

2

that framed bisimilarity is a sufficient condition for a strong equivalence called barbed congruence. The completeness of the theorem does not hold. This is due to the fact that framed bisimilarity is a sufficient condition for barbed congruence, which is sensitive to τ steps and to branching structure, while testing equivalence is not. However the incompleteness of the theorem, even though may be somewhat unfortunate but it seems to be compatible.

2.5

Decidability of Framed Bisimulation

In this section we report the work done by H.H¨ uttel [Hut02]; that shows, by considering the finite-control fragment of spi calculus, to be Turing powerful. He shows also the decidability of framed bisimulation of the finite version of spi calculus. As we mentioned before the main idea mentioned in [AG98] was to define a notion of behavioral equivalence which has a useful proof technique and is decidable.

2.5. Decidability of Framed Bisimulation

27

H¨ uttel’s paper, instead examine to which extent the decidability is the case. His focus was on the finite spi calculus processes and to show that framed bisimilarity is decidable in this fragment. The finite control spi calculus is an extension of the finite control π calculus introduced by Lin [Lin98]. A finite control process consists of a fixed number of sequential processes running in parallel. The goal of H¨ uttel’s work is to establish a straightforward way of checking bisimilarity. And this is done by showing that in the case of finite processes it is enough to consider finitely many terms when matching input transitions, and it is also enough to consider finitely many possible frame extensions when matching input transitions, as well as it is enough to consider finitely many frame and theory extensions when matching output transitions. Taken together these observations, a simple decision procedure for framed bisimilarity can be achieved. Assuming that we are trying to determine whether (fr,th) ` P ∼f Q; we have c

an input commitment P − → (x)P’, have a candidate for a matching commitment, c

Q− → (x)Q’ and need to determine whether P’ ∼f Q’. Assuming that the maximal number of successive term destructors in P and Q is m, and that the maximal number of term constructors of any term in th is d. The observation made by H¨ uttel is to consider only the finitely many terms of depth ≤ m + d constructed from (fr,th) and a bounded number of new names in order to determine if (fr,th) ` P’ ∼f Q’. The maximal constructor depth of a term counts the level of encryption and the level of pairing. Definition 2.5.1 The maximal constructor depth d(M) of a term M is defined inductively by the clauses: d(n) = 0 d(x) = 0 d(Suc(N)) = d(N) + 1 d(MN ) = d(M) + 1 d((M,N)) = max (d(M),d(N)) + 1 1

1

We realize that the definition of maximal constructor depth of a pair term was not complete; we adjust it by adding 1. We also introduce the definition of the maximal constructor depth for the successor.

28

2. Spi Calculus

Definition 2.5.2 The maximal constructor depth of the pair (fr,th) d((fr,th)), where fr = (M1 , N1 ), ...., (Mk , Nk ) is defined as follows: d((fr,th)) = max{max(d(Mi ),d(Ni )) | 1 ≤ i ≤ k} The maximal destructor depth of a process P is the maximal number of encryptions and pairing operators that can ever removed along the process P. Definition 2.5.3 Let P be a finite process. The maximal destructor depth of P (mdd(P)); is defined inductively by the clauses: mdd(0) = 0 mdd((νn) P) = mdd(P) mdd(M hN i.P ) = mdd(P) mdd(M(x).P) = mdd(P) mdd( P | Q) = mdd(P) + mdd(Q) mdd([M = N]P) = mdd(P) mdd( let (x,y) = M in P) = mdd(P) +1 mdd( case L of xN ) = mdd(P) +1 D-framed bisimilarity is a variant of framed bisimilarity that only requires input transitions to be matched for transmitted message terms up to a certain depth. Definition 2.5.4 Let k be a nonnegative integer and let e be the pair of frame and theory, such that e ` ok. Is written e ` M ↔k N and max(d(M),d(N)) = k, and it is said that M and N are k-indistinguishable in e. The following lemma express the fact that it is enough to consider terms up to a certain depth. Lemma 2.5.5 Let (fr,th) be a frame-theory pair and it is assumed that max(d(M),d(N)) → → = k. If there is a (fr ∪ − n ,th) such that (fr ∪ − n ,th) ` M ↔k N, then it is possible − − − to choose a → n where → n ≤ 2k that satisfies (fr ∪ → n ,th) ` M ↔k N. The above lemma leads to the following definition. Definition 2.5.6 For any nonnegative integer d, a d-framed simulation is a framed relation S such that, whenever (fr,th) ` P S Q, the following three conditions hold:


29

τ

If P − → P’ τ

then there is a process Q’ such that Q − → Q’ and (fr,th) ` P’ S Q’. c

If P − → (x)P’ and c ∈ fr → then there is an abstraction (x)Q’ such that Q − → (x)Q’ and for all sets − n → − disjoint from fn(P) ∪ fn(Q) ∪ fr ∪ fn(th) such that | n | ≤ 2d and all closed → → terms M and N, if (fr ∪ − n th) ` M ↔i N and 0 ≤ i ≤ d then (fr ∪ − n th) ` τ

P’[M / x]SQ’[N / x]. c → − → (ν − m)hM iP’, c ∈ fr and the set → m is disjoint from fn(P) ∪ fn(π1 (th)) If P −

∪ fr → → then there is a concretion (ν − n )hN iQ’ such that Q− c (ν − n )hN iQ’ and the set → → − n is disjoint from fn(Q) ∪ fnπ (th) and there is a frame theory pair (fr’,th’) 2

such that (fr,th) ≤ (fr’,th’), (f r0 , th0 ) ` M ↔ N and (f r0 , th0 ) ` P’SQ’. Definition 2.5.7 A d-framed bisimulation is a framed relation S such that S and S −1 are d-framed simulations. Definition 2.5.8 d-framed bisimilarity is the greatest d-framed bisimulation, written as ∼df The main purpose of H¨ uttel’s work, at this point is to show that, given two finite processes P and Q is to test whether or not the two processes are d-framed bisimilar where d is the critical depth. The critical depth of (fr,th,P,Q) is the maximal depth of terms that must be considered as inputs when determining the framed bisimilarity of P and Q under the environment of (fr,th). And is defined as follows:

cd(f r, th, P, Q) = d(f r, th) + max(mdd(P ), mdd(Q)) Moreover is defined the notion of d-pruning. The main idea is that, if two terms are indistinguishable, their subterms appearing at depth d can be replaced by fresh names for any d such that the resulting terms will still be indistinguishable. The pruning of a pair of terms (M,N) at depth d generates a pair of pruned terms (M’,N’); M’ and N’ are constructed by replacing subterms appearing at levels greater than d by encryptions of arbitary fresh names by the same fresh names. The fresh names are then added to the frame.

30

2. Spi Calculus

Definition 2.5.9 Let M and N be closed terms and let (f r, th) ` ok. Is also assumed that fr,th ` M ↔ N; the d-pruning of (fr,th,M,N) (prd ((f r, th, M, N )))is defined inductively by the following clauses: prd (((f r, th), n, n)) = ((fr, th), n, n) pr0 (((f r, th), M, N )) = ((fr, th), M, N) if (M,N) ∈ th pr0 (((f r, th), M, N )) = (fr∪a, th), aa , aa ) if (M,N) ∈ / th and a is fresh pr0 (((f r, th), M1k , N1k )) = ((fr’, th’) M 0 k , N 0 k ) where ((fr’,th’), M’,N’) = prd ((f r, th, ), M1 , N1 )) prd (((f r, th), M )) = ((fr,th), M) if M is an open term. Lemma 2.5.10 if fr,th ` M ↔ N, d = max(d(M),d(N)) and prd (((f r, th), M, N )) = ((fr’,th’), M’,N’) then fr’,th’ ` M’ ↔d N’. The proof is a straightforward induction in d. − → → Lemma 2.5.11 Let P be a process such that P = A[M /− x ] and let d = cd((fr,th),P). → − − − → P > A if and only if P1 > A1 n where P1 = A[ N /→ x ] and prd (((f r, th), M )) = → − → → − ((f r0 , th0 ), N ) where A1 = A[ N /− x ]. The proof is made by observing that both implications are seen to hold by an inspection of the clauses in the definition of the reduction relation. − → → Lemma 2.5.12 Let P = A[M /− x ] and let d = cd((fr,th),P). P − α A0 if and only if → → → − − → → − P10 − α A01 where P1 = A[ N /− x ] and prd (((f r, th), M )) = ((f r0 , th0 ), N ) where A01 = → → → 0 − − → → B[ N /− x ] A = B[M /− x ] for some B. The proof in the case of both implications proceed by transition induction. Lemma 2.5.13 Let P and Q be a finite spi processes and let d = cd((fr,th),P,Q) where (f r, th) ` ok. We have that (f r, th) ` P ∼f Q if and only if (f r, th) ` P ∼df Q. Lemma 2.5.14 Let (f r, th) ` ok. It is decidable whether there is an e ≤ e0 such that (f r, th) ` M ↔ N , where M and N are terms. (fr’,th’) is constructed such that (f r0 , th0 ) ` M ↔ N , and it is only need to add pairs of the form (M1 , N1 ) where max(d(M1 ),d(N1 )) ≤ max(d(M),d(N)). Only finetly many such candidate pairs exist.


31

Theorem 2.5.15 Let P and Q be a finite spi processes and let d = cd((fr,th),P,Q) where (f r, th) ` ok. For any d ≥ 0 it is decidable whether (f r, th) ` P ∼df Q. Corollary 2.5.16 Let P and Q be a finite spi processes and let d = cd((fr,th),P,Q), where (f r, th) ` ok. For any d ≥ 0 it is decidable whether (f r, th) ` P ∼f Q. In [Hut02], H¨ uttel also demonstrate that the finite-control spi calculus is Turingpowerful by presenting an enconding of Minsky’s two counter machines into the finite-control calculus. A two-counter machine is a simple imperative program consisting of a sequence of labbeled instructions that can modify the values of two nonnegative integer counters. Theorem 2.5.17 Any two-counter machine can be simulated in the finite-control spi calculus. A similar work has been done by Amadio and Lugiez in [AL00] by considering a finite spi calculus similar to the one considered by Huttel, and they show that its associated reachability problem is decidable (albeit NP-hard).

32

2. Spi Calculus

Bd ((e, (0, 0))) = t Bd ((e, (P0 , P1 ))) = for each i ∈ {0, 1} let(fr,th) = e in a

→ (x)Pi0 where a ∈ fr for each Pi − a

0 → (y)Pi−1 select Pi−1 − 0 if no such Pi+1 exists

then fail else − − → for each → n where | → n |≤ 2d, − n ∩ (f n(Pi ) ∪ f n(Pi−1 ) ∪ f n(th)) = 0 → − for each ((f r ∪ { n }), th) ` M ↔d N ) → 0 [N/y])) Bd ((f r ∪ {− n , th), (Pi0 [M/x], Pi−1 a → for each P − → (ν − m)hN iP 0 where a ∈ fr i

select Pi−1

i

− 0 − → (ν → m)hN iPi−1 a

0 if no such Pi−1 exists

then fail else select e0 such that (e ≤ e0 ) ∧ (e0 ` M ↔ N ) 0 )) Bd (e0 , (Pi0 , Pi+1 τ

for each Pi − → Pi0 τ

0 select Pi+1 − → Pi−1 0 if no such Pi−1 exists

then fail else 0 )) Bd (e, (Pi0 , Pi−1

Figure 2.6: Algorithm for checking bisimilarity [Hut02] .

3 The proof assistant Isabelle Isabelle is a generic theorem prover that implements logical formalisims [NP92] [Pfe]. It has been instantiated to support reasoning in several object-logics: first-order logic, constructive and classical versions higher-order logic, similar to that of Gordon’s HOL [Jon95] Zermelo-Fraenkel set theory an extensional version of Martin L¨ of ’s Type Theory the classical first-order sequent calculus, Lk the modal logics T , S4, and S43 the Logic for Computable Functions

A logic’s syntax and inference rules are specified declaratively; this allows singlestep proof construction. Isabelle provides control structures for expressing search procedures. It also provides several generic tools, such as simplifiers and classical theorem provers, which can be applied to object-logics. Isabelle is a large system written in ML. The first distribution was made in 1986. The 1987 version introduced a higher-order meta-logic with an improved treatment of quantifiers. The 1988 version added limited polymorphism and support for natural deduction. The 1989 version included a parser and pretty printer generator. The 1992 version introduced type classes, to support many-sorted and higher-order logics. The 1994 version introduced greater support for theories. The most important change in the Isabelle system has been made through the introduction of the Isar proof language, thanks to M. Wenzel [Wen99]. The Isar proof language will be discussed in section 3.3.

34

3. The proof assistant Isabelle

Most Isabelle users write proof scripts using the Isar language, and debug them through the Proof General user interface [Asp00]. In Isabelle formulae are ML values; theorems belong to an abstract type; tactics and tacticals support backward proof. Proofs are conducted by applying certain ML functions, which update a stored proof state. All syntax can be expressed using plain ASCII characters, but Isabelle can support alternative syntaxes, for example using mathematical symbols from a special screen font. The meta-logic and main object-logics already provide such fancy output as an option. In this chapter we give an overview of the general aspects of the Isabelle/HOL system, and we concentrate in some of the aspects which are relevant in the development of this project. For a more detailed description the reader is referred to [NP92] [Pfe].

3.1

Basic Concept

In this thesis we will concentrate on Isabelle/HOL, which is the specialization of Isabelle for the Higher-Order Logic. Higher Order Logic is a version of predicate calculus with three main extensions: Variables can range over functions and predicates (hence higher order ). The logic is typed. There is no separate syntactic category of formulae (terms of type bool fulfill

their role). HOL is a combination of functional programming and logic. HOL can express most mathematical concepts, and functional programming is just one particularly simple and ubiquitous instance. The implementation of Isabelle has influenced some of Isabelle/HOL’s concrete syntax. In table 3.1 is summarized the notation used in HOL logic. Terms of the HOL logic are represented in ML by an abstract type called term. Terms can be manipulated by various built-in ML functions. The formalization of HOL in Isabelle relies heavily on the meta-logic. HOL uses the polymorphic type system of the meta-logic. Together with some appropriate axioms, these form the basis for the higher-order logic theory. All the other definitions, theorems and axioms are formulated in terms of these basic constructs.

3.1. Basic Concept

# Kind of Term Truth Falsity Negation Disjunction Conjunction Implication Equality ∀−quantification ∃− quantification ε−term Conditional

35

Table 3.1: HOL Notation HOL Notation Description T True F False t Not t t1 ∨ t2 t1 ort2 t1 ∧ t2 t1 andt2 t1 → t 2 t1 impliest2 t1 = t2 t1 equalst2 !x.t for all x : t ?x.t for some x : t @x.t an x such that: t if t then t1 else t2 if t then t1 else t2

Working with Isabelle means creating theories. A theory is a named collection of types, functions, and theorems, much like a module in a programming language or a specification in a specification language. In fact, theories in HOL can be either. The general format of a theory T is : theory T i m p o r t s B1 . . . Bn begin d e c l a r a t i o n s , d e f i n i t i o n s , and p r o o f s end where B1...Bn are the names of existing theories that T is based on and declarations, definitions, and proofs represents the newly introduced concepts (types, functions etc.) and proofs about them. The Bi are the direct parent theories of T. Everything defined in the parent theories (and their parents, recursively) is automatically visible. Each theory T reside in a theory file named T.thy. HOL contains a theory Main, which is the union of all the basic predefined theories like arithmetic, lists, sets, etc. Embedded in a theory are the types, terms and formulae of HOL. HOL is a typed logic whose type system resembles that of functional programming languages like ML or Haskell. Thus there are, base types like bool, type constructors (e.g. list) , function types and type variables. Types are extremely important because they prevent us from writing nonsense. In Isabelle all terms and formulae must be well-typed. To reduce the amount of explicit type information that needs to be provided by the user, Isabelle infers the

36


type of all variables automatically (this is called type inference) and keeps quiet about it. Terms are formed as in functional programming by applying functions to arguments, while Formulae are terms of type bool. Isabelle distinguishes free and bound variables. Bound variables are automatically renamed to avoid clashes with free variables. In addition, Isabelle has a third kind of variable, called a schematic variable, which has ? as its first character. Logically, an unknown variable is a free variable, but it may be instantiated by another term during the proof process. There are two kinds of commands used during a proof in Isabelle: the actual proof commands and auxiliary commands for examining the proof state and controlling the display. Simple proof commands are of the form apply(method ), where method is typically induct tac or auto. Unless stated otherwise, it is assumed that a method attacks merely the first subgoal. An exception is auto, which tries to solve all subgoals. The general HOL datatype definition is of the form: datatype(α1 , ..., αn )t = C1 τ1 ...τk | ... | Cm τ1 ...τk where αi are distinct type variables (the parameters), Ci are distinct constructor names and τj are types.

3.2

Proof Checking

In Isabelle, proofs are constructed using inference rules. The most familiar inference rule is probably modus ponens: P →QP Q Isabelle rules involve schematic variables, which begin with a question mark and act as place-holders for terms. Unification is one of the important part in the proof construction in Isabelle. Next simplest is pattern-matching, which replaces variables in only one of the terms. The rule method typically matches the rules conclusion against the current subgoal. The assumption method matches the current subgoal’s conclusion against each of its assumptions. Unification can instantiate variables in both terms; the rule method can do this if the goal itself contains

3.2. Proof Checking

37

schematic variables. Other occurrences of the variables in the rule or proof state are updated at the same time. Isabelle’s classical reasoner is a family of tools that perform proof automatically by searching among different ways of proving subgoals. The most important of those is blast. There are two kinds of rules in the classical reasoners: a safe rule is the one that can be applied backwards without losing information, while an unsafe rule loses information, perhaps transforming the subgoal into one that cannot be proved. The safe/unsafe distinction affects the proof search: if a proof attempt fails, the classical reasoner backtracks to the most recent unsafe rule application and makes another choice. Here is a summary of the other classical reasoning methods: clarify and clarsimp perform obvious steps without splitting the goal; safe even

splits goals force uses classical reasoning and simplification to prove a goal; auto is similar

but leaves what it cannot prove fast and best are legacy methods that work well with rules involving unusual

features In the development of proofs there are two ways to construct the actual proof: Forward proof : means deriving new facts from old ones. Backward proof works from goals to subgoals, it is helpful in finding a difficult proof; but it is not always the best way of presenting the proof thus found. Forward proof is particularly good for reasoning from the general to the specific. The methods drule, frule, drule tac, etc., reason forward from a subgoal. One of the important definition for this thesis is the notion of inductive and coinductive definition [Pau00]. The definition is applicable to any logic in which the Knaster-Tarski theorem can be proved. For an inductive definition, the package returns an induction rule derived directly from the properties of least fixed points, as well as a modified rule for mutual recursion. While for a coinductive definition, the package returns a basic coinduction rule. The basic rule of the induction rule, is called induct; and is appropriate in most situations. Induction is invoked by induct tac, it works for any datatype. In some

38


consts even :: “nat set” inductive even intros zero [intro !] : “0 ∈ even” step [intro !] : “n ∈ even” ⇐ (Suc (Suc n)) ∈ even Figure 3.1: Inductive definition example LN il ∈ llist(A) LCons(a, l) ∈ llist(A)

a ∈ A l ∈ llist(A)

Figure 3.2: Coinductive definition of lazy lists

cases, induction is overkill and a case distinction over all constructors of the datatype suffices. This is performed by case tac . In figure 3.1 is reported an example of an inductive definition. Using consts is declared the constants even to be a set of natural numbers. The inductive declaration gives it the desired properties. An inductive definition consists of introduction rules. The first one in the example states that 0 is even; the second states that if n is even, then so is n + 2. Given this declaration, Isabelle generates a fixed point definition for even and proves theorems about it. These theorems include the introduction rules specified in the declaration, an elimination rule for case analysis and an induction rule. These theorems are referred by automatically-generated names. even zero and even step are the introduction rules for the above example. even induct is the induction rule generated by Isabelle.

Coinductive definition is the dual of the induction ones, it specifies the greatest set R consistent with given rules. Every element of R can be seen as arising by applying a rule to the elements of R. Important examples include using bisimulation relations to formalize equivalence of processes or lazy functional programs. A coinductive definition yields a primitive coinduction rule, with no refinement such those for the induction rules. In 3.2 is reported an example of a coinductive definition of lazy lists, which are defined as the greatest set consisting of with two rules. For every coinductive definition the package derives an unfold theorem, then it proves the theorem coinduct, which express that the llist(A) is the greatest solution.

3.3. Isabelle/Isar

3.3

39

Isabelle/Isar

Isar is an extension of Isabelle with structured proofs in a stylized languages of mathematics. These proofs are readable for both a human and a machine [Wen99]. Isar (Intelligible semi-automated reasoning) provides an interpreted language environment of its own, which has been specifically tailored for the needs of theory and proof development. Compared to raw ML, the Isabelle/Isar top-level provides a more robust and comfortable development platform, with proper support for theory development graphs, single-step transactions with unlimited undo, etc. Drawing from both the traditions of informal mathematical proofs texts and high-level programming languages, Isar offers a versatile environment for structured formal proof documents. Despite its grand design of structured proof texts, Isar is able to assimilate the traditional style as an “improper” sub-language. This provides an easy upgrade path for existing tactic scripts, as well as additional means for interactive experimentation and debugging of structured proofs. Isabelle/Isar is based on the existing logical framework of Isabelle/Pure, which provides a generic platform for higher-order natural deduction. The generic approach of Pure inference systems is extended by Isar towards actual proof texts. Isabelle/Isar offers the following main improvements over the classic Isabelle. A new theory format, that supports interactive development and unlimited

undo operation. a formal proof document language designed to support intelligible semi-automated

reasoning. Instead of putting together unreadable tactic scripts, we are enabled to express the reasoning in way that is close to usual mathematical practice. The old tactical style has been assimilated as “improper” language elements. A simple document preparation system, for typesetting formal developments

together with informal text. The resulting hyper-linked PDF documents are equally well suited for WWW presentation and as printed copies. The Isar proof language is embedded into the new theory format as a proper sub-language. Proof mode is entered by stating some theorem or lemma at the theory level, and left again with the final conclusion (e.g. via qed). The proof language offers various common principles that are parameterized by entities of the object-logic and application context, including plug-in proof methods.

40


New-style theory files may still be associated with separate ML files consisting of plain old tactic scripts. The migration between classic Isabelle and Isabelle/Isar is relatively easy. The rather generic framework of Isabelle/Isar syntax emerges from three main syntactic categories: commands of the top-level Isar engine (covering theory and proof elements), methods for general goal refinements (analogous to traditional “tactics”), and attributes for operations on facts (within a certain context). More details on the syntax primitives can be found in [Wen99]. Proof methods in Isabelle/Isar are either basic ones, or expressions composed of methods via “,” (sequential composition), “|” (alternative choices), “?” (try), “+” (repeat at least one), “[n]” (restriction to first n sub-goals). The most basic proof method is called rule and refers to a generic natural deduction step of the underlying framework. Proper Isar proof methods do not admit arbitrary goal addressing, but refer either to the first sub-goal or all sub-goals uniformly. The goal restriction operator “[n ]” evaluates a method expression within a sandbox consisting of the first n sub-goals. For example, simp all [3] simplifies the first three sub-goals, while (rule foo, simp all )[] simplifies all new goals that emerge from applying rule foo to the originally first one. Isar commands may be either proper document constructors, or improper commands. Improper Isar language elements, are often helpful when developing proof documents. Typical examples are diagnostic commands that print terms or theorems according to the current context; other commands emulate old-style tactical theorem proving. Let’s look at some simplified grammar for Isar proofs. Parentheses are used for grouping and

?

indicates an optional item:

proof ::= proof method? statement∗ qed | by method statement ::= fix variables | assume propositions | (from facts)? (show | have)propositions proof proposition ::= label:? string | by method fact ::= label

3.3. Isabelle/Isar

41

A proof can be either compound (proof - qed) or atomic (by). A method is a proof method (tactic) offered by the underlying theorem prover. A typical proof skeleton is reported below: proof assume ” the−assm ” have ” . . . ” . . have ” . . . ” show ” the−c o n c l ” qed

− intermediate result

− intermediate result

It proves the-assm =⇒ the-concl. The intermediate haves are only to bridge the gap between the assumption and do not contribute to the theorem being proved. In contrast, show establishes the conclusion of the theorem. One of the important proof method used in the project of this thesis is the induct proof method. The induct proof method of Isar is a sophisticated wrapper for the basic rule method. Let’s give a look at the internal operations performed by this method. Assuming that only one goal and one induction rule is involved; the induct method performs operations on the proof context, rule, and goal as follows [Wen99]: 1. context: declare local defs for any defined induction variables x = a 2. rule: apply insts according to the positions in the inductive predicate P x1 ...xn 3. rule: expand defs in major premises (accommodate the original statement, which mentions the expanded expressions) 4. rule: consume a prefix of facts according to the number of major premises (the remainder is a pure induction rule cases = =⇒ P x1 ...xn ) 5. goal: strengthen by inserting the remaining facts, and all defs 6. goal: strengthen by fixing vars, using rule ( 7. goal: internalize

V

V

x.Bx) =⇒ B a of the framework

/ =⇒ into the object-logic, using (

V

x.T r(B x)) ≡ Tr (∀x.Bx)

and (TrA =⇒ TrB) ≡ Tr (A −→ B) of the framework 8. rule: unify conclusion against goal (absorb any internalized auxiliary structure, including defs; result is a fully-instantiated induction rule)

42


9. rule: carefully recover internalized

V

/ =⇒ structure in the inductive cases,

using the above rules backwards 10. context: extract inductive cases from rule (enable case abbreviations in the proof body; cases consist of elements stemming from both the rule and the goal) 11. context: discharge defs 12. goal: apply the fully instantiated rule Simultaneous induction may involve both multiple goals and multiple rules. Isar supports simultaneous goal statements (show A and B). The induct method is able to pass this structure through the inductive process, using the local version of Pure conjunction A&B. For a full documentation of the Isabelle/Isar system the reader is referred to [Wen99].

3.4

Nominal Logic

In the formalization of proofs that involves binders in terms, there is a problem of how to represent this terms. The “low-level” representations use a concrete names for binders or use de-Bruijn indices. Both representations make formal proofs rather strenuous in places that are only loosely concerned with the proof at hand. The main aim of the Isabelle/HOL-Nominal package by Urban et al [UT05] was to give a representation for α-equated lambda terms that is based on names, is inductive and comes with a structural induction principle where the lambda-case to be proved for only fresh binders. The work is based on the nominal logic work by Pitts et al [Pit03]. The main technical novelty introduced by Urban et al [UT05] is the explicit construction for α-equated lambda terms is compatible with the axiom choice. Therefore the result is implemented in Isabelle/HOL. Let’s look at the α-equivalence cast in terms of the nominal logic work. The set of lambda terms is inductively defined by the grammar: Λ : t ::= a | t t | λa.t where a is an atom drawn from a countable infinite set.

3.4. Nominal Logic

43

The notion of α-equivalence for Λ is often defined as the least congruence of the equation λa.t =α λb.t[a := b] involving a renaming substitution and a side-condition, namely that b does not occur freely in t. In the nominal logic package, atoms are manipulated not by renaming substitutions but by permutations - bijective mappings from atoms to atoms. While permutations have some technical advantages, for example they preserve α-equivalence which substitutions do not, their primary reason in the nominal logic package is that one can use them to define the notion of support. This notion generalises what is meant by the set of free atoms of an object, which is usually clear in case the object is an abstract syntax tree, but less so if the object is a function. The operation of permutation acting on a lambda term has been implemented in Isabelle/HOL by representing the permutations as finite lists whose elements are swappings (i.e, pairs of atoms). The permutation action, written π • (−), is defined on lambda terms as: []• = a

  π • a = a2 (a1 a2 ) :: a1   π•a

if π • a = a1 if π • a = a2 otherwise

π • (t1 t2 ) = (π • t1 )(π • t2 )

π • (λa.t) = λ(π • a)(π • t) where (a b) :: π is the composition of a permutation followed by the swapping (a b). Permutation are matematically well behaved. They very rarely change the properties of a term. Most impotantly, α-equivalence is preserved by permutations. The property of being preserved by permutations is called equivariance. Definition 3.4.1 (Equivariance) eqvt R ≡ ∀p T U. (T, U ) ∈ R −→ (p • T, p • U ) ∈ R

44


Another important notion introduced in the nominal logic package is the notion of Freshness. Definition 3.4.2 (Freshness) a]T ≡ a ∈ / supp T

3.4.1

Nominal datatype package

The most important constants introduced by the theory Nominal.thy are reported in table 3.4.1. Name permutation operation freshness support abstractions

XSymbol • ] supp [ ].

Ascii < bullet > < sharp >

They are all polymorphic and therefore often need explicit type-annotations to be meaningful. The lack of explici type-annotations is usually causes rules not being applicable. The first argument of the permutation operation is a list of pairs of atoms, all of which need to have the same type. [(a, b)] • x The above notation indicates, a swapping of two atoms applied to x. Once a nominal datatype is declared, a number of lemmas are automatically provided. For example, lets consider the following datatype of lambda calculus. n o m i n a l d a t a t y p e lam = Var ” v a r s ” | App ”lam” ”lam” | Lam ”lam” the lam.supp, which is the support lemma, contains the equations that characterise the support for each constructor. supp (Var x) = supp x supp (App t1 t2) = supp t1 ∪ supp t2 supp (Lam x t) = supp ([x].t)

3.4. Nominal Logic

45

The support of the last clause can then be further analysed using the rules calculating the support of abstractions. The lemma lam.fresh can be used to simplify freshness constraints involving nominal datatypes. a ] Var x = x = y a ] App t1 t2 = a ] t1 ∧ t1 a ] t2 a ] Lam x t = a ] [x].t In contrast to the constructors of standard datatypes, the term-constructor of nominal datatypes are in general not injective; however the following Injection lemma is proved under the name lam.inject Var x = Var y ≡ x = y App t1 t2 = App s1 s2 ≡ t1 = s2 ∧ t2 = s2 Lam x t = Lam y s ≡ [x]. t = [y].s The abstarction functions in the last clause can then further analysed by the lemma alpha which can be states: ([x].t = [y].s) = ((x = y ∧ t = s) ∨ (x 6= y ∧ t = [(x, y)] • s ∧ x 6= s)) or by alpha’ which states: c 6= x ∧ c 6= y c]s ⇒ ([x].t = [y].s) = ([(x, c)] • t = [(y, c)] • c) The nominal datatype package provides for every nominal datatype a weak induction principle (nominal datatype.induct weak), and also generates a strong induction principles called nominal datatype.induct. It also provides a method called nominal induct, which applies a strong induction rule and helps to instantiate the freshness context. The syntax looks like this: nominal induct x1 ...xn fixing: y1 ...yn avoiding: z1 ...zn rule : rule name where xi describe the variables over which the induction is done; yi describe the variables that are fixed during the induction and zi describe the freshness context of the nominal induction. In the nominal logic package there are three tactics that are useful to solve some of frequently occurring proof obligations.

46


perm simp : simplifies permutations by pushing permutations inside a term.

The simplification also analyses occurrences of π • (π −1 • x) = x and a number of other relative obvious simplifications. supports simp: analyses goals of the form S supports x : first it unfold the

definition of supports and then tries to solve the resulting proof goal. finite guess analyses goal of the form finite(supp x ): it first calculates the free

variables of x and then tries to solve the two goals: finite(supp FV (x)) (supp FV (x)) supports x All the above three tactics can have the optional arguments: add and del; where lists of theorems can be given. This theorems are added to or deleted from the simplifier during the tactic execution.

3.5

Proof General

Proof General is a generic Emacs interface for interactive proof assistants, developed at the LFCS in the University of Edinburgh. It works best under (X)Emacs, but can also be used with GNU Emacs [Asp00]. The interface is designed to be very easy to use, and it is possible to develop proof scripts in-place rather than line-by-line and later reassembling the pieces. Proof General keeps track of which proof steps have been processed by the prover, and prevents you editing them accidently. It is possible to undo steps as usual. The aim of Proof General is to provide a powerful and configurable interface for numerous interactive proof assistants. The target of Proof General is mainly to intermediate or expert users, so that the interface should be useful for large proof developments. Depending on the extension of the file (.v for Coq, .thy for Isabelle), Proof General starts a proof assistant automatically inside Emacs as an ”inferior” process. Some of the feautures included in Proof General are the following: Simplified interaction Proof General is designed for proof assistants which

have a command-line shell interpreter. When using Proof General, the proof assistant’s shell is hidden from the user. Communication takes place via three buffers (Emacs text widgets). Communication takes place via three buffers. The script buffer holds input, the commands to construct a proof. The goals buffer displays the current list of subgoals to be solved.

3.5. Proof General

47

Script management : Proof General colours proof script regions blue when

they have been processed by the prover, and colours regions red when the prover is currently processing them. The appearance of Emacs buffers always matches the proof assistant’s state. Script editing mode : Proof General provides useful facilities for editing proof

scripts, including syntax hilighting and a menu to jump to particular goals, definitions, or declarations. Toolbar and menus: A script buffer has a toolbar with navigation buttons for

processing parts of the proof. Proof by pointing: Proof General has support for proof-by-pointing and similar

features. Proof by pointing allows you to click on a subterm of a goal to be proved, and automatically apply an appropriate proof rule or tactic.

48


4 Modelling spi calculus in Isabelle/HOL-Nominal

In this chapter we will illustrate the actual modelling part of the spi calculus and the notion of framed bisimulation and d-framed bisimulation. We follow the general structure used in the formalization of the π-calculus in the Nominal logic developed in [Ben]. This chapter has been prepared as an Isabelle/Isar theory document through the usage of a tool provided by Isar for document preparation [Wen99]. This means that the proofs and proof outlines encountered here have been checked by the system. The first section contains the formalization of the spi calculus syntax and operational semantics. Next, we formalize the definition of framed bisimulation and d-framed bisimulation. Formal proofs of important properties as well as an example of framed bisimilarity, are listed in the last part of this chapter.

4.1

Spi-calculus syntax

Since we are going to use the Nominal Logic [UT05], we import the object-logic in the first part of the file, as stated below. theory Spi imports Nominal begin

Nominal datatypes in contrast with the datatypes provided by Isabelle/HOL represent α-equivalence classes. Before using the datatype constructor provided by the nominal logic, the nominal package needs to know which atom types are used.

50

4. Modelling spi calculus in Isabelle/HOL-Nominal

In the nominal logic developed by Pitts et al the different kind of atoms are separated by sort-constraints, while in this nominal datatype package, atoms have their own type. The atom declaration is a global declaration and therefore must contain all the atom types that ever used in our theory. In our case, we have two atoms that must be declared globally: var and name. Using this new notion of atom declaration has the advantage that one cannot write down illegal formed (or typed) permutation. But it also has the disadvantage that one cannot collect arbitrary atoms in a single permutation, moreover supp x will, according to its type, pick out only one kind of atoms of the support of x. Atom types are declared as follows: atom-decl name var

The following are the definition of terms, processes, barb, abstraction, concretion and agents, which are defined as nominal datatype. Definition 4.1.1 (Terms) nominal-datatype trm = Var var | Name name | Zero (0) | Suc trm (( -) [100 ]100 ) | Sk-enc trm trm (-{|-|} [110 , 110 ] 110 ) | TPair trm trm ((-o n-) [110 , 110 ] 110 )

The nominal datatype trm introduces six constructors, Var, Name, 0, trm.Suc, TPair and Sk-enc. Because this notation quickly becomes unwieldy, the datatype declaration is annotated with an alternative syntax. In fact, this alternative syntax is the familiar one. The constructor Sk-enc, which is the shared-key encryption, is treated as a constructor with two arguments: both of them of type trm. In the first version of Isabelle/HOL-Nominal used for the development of this project, there was some restriction in declaring nominal datatypes: Inside

only one atom type is allowed

no type variables are allowed no nested types are allowed; they need to be unfolded manually and defined as mutual recursive datatype no function types can be used. In general it is not ensured that they have finite support.

On the other hand, in the latest version (version 0.05 released on 18 August 2006), new improvements has been made in the package. In this late version, the nominal datatype package supports the declaration of more than one atom type and allows term-constructors to have more than one binder. Most of the theorem provers generates in automatic induction rules for a defined datatypes. The nominal logic package, not only generates induction rules for the

4.1. Spi-calculus syntax

51

nominal datatypes but it also have the following characteristic: bound names (or variables) which occur in the inductive cases can be assumed to be disjoint from any finite set of names. This means that it is possible to avoid automatically name clashing and the proofs follow quite nicely. Before invoking the induction rules it is possible to make sure that any bound names (or variables) which might appear in the inductive steps are different from any names and fresh for processes under consideration. Another characteristic of the nominal datatype, is that functions over nominal datatypes they may not depend on the bound names in their arguments. Since nominal types are equal up to α-equivalence two equal terms may have different bound names. Definition 4.1.2 (Processes) nominal-datatype Proc = Pnil | out-barb trm trm Proc | in-barb trm var Proc | par Proc Proc | res name Proc | bang Proc | match trm trm Proc | letp trm var var Proc 110 ] 110 ) | nat-case trm Proc var Proc [100 , 100 , 100 , 100 ]100 ) | sk-dec trm trm var Proc 100 , 120 ]120 )

(PNil ) (-.- [120 , 120 , 110 ] 110 ) (-(-).- [120 , 120 , 110 ] 110 ) (infixr k 85 ) (hν-i- [100 , 100 ] 100 ) (!- [110 ] 110 ) ([-_-]- [120 , 120 , 110 ] 110 ) (split - as 0(-o n- 0) inn - [110 , 110 , 110 , (caseint - of 0 ⇒ - | 0( - 0) ⇒ (casedec - ofdec -{|-|} ⇒ - [120 , 100 ,

Using the nominal package, we are allowed to state which names appear bound in the datatype declaration. In our case the following processes need a bound atom: Input, Restriction, Pair splitting, Integer case and Decryption. The nominal package provide also new lemmas that can be used for reasoning the α-equivalence between processes. Those lemmas will be reported in section 4.4. The nominal datatype package provides for every nominal datatype a weak induction principle (name: nominal datatype induct weak). We give an example in the case of Proc nominal datatype: V [[?P V PNil ; trm1 trm2 Proc. ?P Proc =⇒ ?P (trm1 .Proc); Vtrm var Proc. ?P Proc =⇒ ?P (trmvar .Proc); k Proc2 ); VProc1 Proc2 . [[?P Proc1 ; ?P Proc2 ]] =⇒ ?P (Proc1 V name Proc. ?P Proc =⇒ ?P (hνnameiProc); Proc. ?P Proc =⇒ ?P (!Proc); V trm1 trm2 Proc. ?P Proc =⇒ ?P ([trm1 _trm2 ]Proc); V nvar2 ) inn Proc); Vtrm var1 var2 Proc. ?P Proc =⇒ ?P (split trm as (var1 o trm Proc1 var Proc2 . V [[?P Proc1 ; ?P Proc2 ]] =⇒ ?P (Proc.nat-case trm Proc1 var Proc2 ); trm1 trm2 var Proc. ?P Proc =⇒ ?P (casedec trm1 ofdec trm2 {|var |} ⇒ Proc)]] =⇒ ?P ?Proc

The induction principle is “weak”, because one has to prove the datatype-case for all possibilities of bound symbols (see e.g., the case of res). This means one has

52


to often find suitable renaming to get this through. In order to reduce the amount of work in inductions, the nominal datatype package generates also the principles for strong induction (nominal datatype.induct). In the case of the Proc datatype it looks like this: V [[V z . ?P z PNil ; V Vtrm1 trm2 Proc z . ( z . ?P z Proc) =⇒ V ?P z (trm1 .Proc); trm var Proc z . [[var ] z ; var ] trm; V V V z . ?P z Proc]] =⇒ ?P z (trmvar .Proc); Proc1 Proc2 z . [[ z . ?P z Proc1 ; z . ?P z Proc2 ]] =⇒ ?P z (Proc1 k Proc2 ); V V name Proc z . [[name ] z ; z . ?P z Proc]] =⇒ ?P z (hνnameiProc); V V Proc z . ( z . ?P z Proc) =⇒ ?P z (!Proc); V V Vtrm1 trm2 Proc z . ( z . ?P z Proc) =⇒ ?P z ([trm1 _trm2 ]Proc); trm var1 var2 Proc z . V [[var1 ] z ; var2 ] z ; var2 6= var1 ; var1 ] trm; var2 ] trm; z . ?P z Proc]] nvar2 ) inn Proc); V =⇒ ?P z (split trm as (var1 o trm Proc1 var Proc2 z . V V [[var ] z ; var ] trm; var ] Proc1 ; z . ?P z Proc1 ; z . ?P z Proc2 ]] V =⇒ ?P z (Proc.nat-case trm Proc1 var Proc2 ); trm1 trm2 var Proc z . V [[var ] z ; var ] trm1 ; var ] trm2 ; z . ?P z Proc]] =⇒ ?P z (casedec trm1 ofdec trm2 {|var |} ⇒ Proc)]] =⇒ ?P ?z ?Proc

where z stands for the freshness context of the induction. The precondition name ] z implies that one has to prove the datatype-case for only those binders name that are fresh w.r.t. this context. This usually makes the binder cases as simple as the non-binding case; in essence it is a formal justification of the usual variable convention that is employed in informal proofs. Definition 4.1.3 nominal-datatype Barb = Btau (τ ) | Inbarb name (barb(-) [100 ]100 ) | Cobarb name (cobarb(-)[100 ]100 )

nominal-datatype Abs = abs

var Proc

nominal-datatype Conc = conc-par trm Proc | conc-res name Conc ((-) [100 , 100 ] 100 )

consts ConcChain :: name list ⇒ trm ⇒ Proc ⇒ Conc primrec conc-base: ConcChain [] m P = (conc-par m P ) conc-step: ConcChain (x #xs) m P = (ConcChain xs m P )

nominal-datatype Agent = procAgent Proc | concAgent Conc | absAgent var Proc

4.2. Substitution in Terms and Processes

53

| parAgent Agent Agent | resAgent name Agent

In the case of chained restriction in the concretion process, we need the definition ConcChain, which is defined as a recursive function. Basically this function takes a list of type trm and a process, and it gives a concretion process. The keyword primrec indicates that the recursion is of a particularly primitive kind where each recursive calls peels off a datatype constructor from one of the arguments. In this first section we declare also some theories that will be useful in the proof of some lemmas. The first lemma states that the names are two names are fresh w.r.t (∀a, b :: name.a • b ⇔ a 6= b) each other if and only if they are different. lemmas name-fresh[simp] = at-fresh[OF at-name-inst]

The keyword lemmas introduce a new theorem which in this case is derived from an existing one, provided by the nominal package. We adapt this lemma to our needs using the attribute OF, this attribute applies a rule to a list of theorems. Definition 4.1.4 (Closed Terms) consts closedtrm :: (trm)set syntax closedtrm-judge :: trm ⇒ bool ( 0(♣- 0) [100 ] 100 ) translations (♣ T ) (T ) ∈ closedtrm inductive closedtrm intros closedName[intro]: (♣ (Name N )) closedZero[intro]: (♣ 0 ) closedSuc[intro]: [[(♣ N )]] =⇒ (♣ ( N )) closedSk-enc[intro]: [[(♣ N ); (♣ M )]] =⇒ (♣ (M {|N |})) closedTpair [intro]: [[(♣ N ); (♣ M )]] =⇒ (♣ (N o nM ))

Definition 4.1.4 defines the notion of closed terms- terms without free variables, they are defined by induction. The datatype induction rule generated here is of the form V V [[(♣xa); N . P (Name N ); P 0; N . [[(♣N ); P N ]] =⇒ P (trm.Suc N ); V VM N . [[(♣N ); P N ; (♣M ); P M ]] =⇒ P (M {|N |}); M N . [[(♣N ); P N ; (♣M ); P M ]] =⇒ P (N o nM )]] =⇒ P xa

4.2

Substitution in Terms and Processes

In this section we report the definition of substitution in terms and processes. In the first version of this project the definition of the substitution was made by induction.

54


Afterwards, when the 0.05 version of the package was released, the definition was developed using the recursion combinator. In earlier versions of the nominal datatype package one could define functions on a case-by-case basis, but this involved some rather non-trivial reasoning- there was no uniform method for defining functions over the structure of nominal datatypes. The recursion combinator allows us to define functions over the structure of the type trm (or any type declared as nominal datatype). Before defining the substitution in terms, we define the substitution of names as a recursive function. Definition 4.2.1 (Substitution of names) consts subst-name :: name × name × name ⇒ name recdef subst-name {} subst-name(a, b, c) = (if (a = c) then b else c)

Using recdef we can define arbitrary total recursive functions. It is possible to use a full pattern matching, recursion need not involve datatypes, and termination is proved by showing that the arguments of all recursive calls are smaller in a suitable sense. Lemma 4.2.2 lemma perm-subst-name: fixes perm :: name prm and a :: name and b :: name and c :: name shows perm · (subst-name(a, b, c)) = subst-name((perm · a), (perm · b), (perm · c)) by(auto simp add : at-bij [OF at-name-inst])

In the above lemma we prove that the permutation in the substitution function works properly. The proof is made through the use of the proof method auto, by adding a simplified lemma (at bij), which is defined in the nominal package. Basically, as explained in chapter 3, auto tries to simplify all the subgoals. Simplification is one of the central theorem proving in Isabelle and many other systems. It is also known as term rewriting. The simplifier proves arithmetic goals by simplifying the expression through the biult-in procedures that go beyond mere rewrite rules. Nearly any theorem can become a simplification rule. The simplifies will try to transform in into an equation. For example, the theorem ¬ P is turned into P = F alse. The general format of the simplification method is: simp list of modifiers

4.2. Substitution in Terms and Processes

55

the list of modifiers fine tunes the behavior and may be empty. It is possible to modify the set of simplification rules used in a simplification step by adding rules to it and/or deleting rules from it. The possible modifiers are: add list of theorem names del list of theorem names only list of theorem names using the modifier only, we can specify a list of theorems and omit all others. Definition 4.2.3 (Substitution in terms) constdefs subst-Var :: var ⇒ trm ⇒ var ⇒ trm subst-Var x m ≡ λa. (if a=x then m else (Var a)) subst-Name :: var ⇒ trm ⇒ name ⇒ trm subst-Name x m ≡ λa. (Name a) subst-Zero :: var ⇒ trm ⇒ trm subst-Zero x m ≡ 0 subst-Succ :: var ⇒ trm ⇒ trm ⇒ trm ⇒ trm subst-Succ x m ≡ λ- t1 . ( t1 ) subst-Enc :: var ⇒ trm ⇒ trm ⇒ trm ⇒ trm ⇒ trm ⇒ trm subst-Enc x m ≡ λ- - t1 t2 . (t1 {|t2 |}) subst-Pair :: var ⇒ trm ⇒ trm ⇒ trm ⇒ trm ⇒ trm ⇒ trm subst-Pair x m ≡ λ- - t1 t2 . (t1 o n t2 ) substTrm :: var ⇒ trm ⇒ trm ⇒ trm substTrm x m ≡ trm-rec (subst-Var x m) (subst-Name x m) (subst-Zero x m) (subst-Succ x m) (subst-Enc x m) (subst-Pair x m) syntax substTrm-syntax :: var ⇒ trm ⇒ trm ⇒ trm (-[-::=-] [100 ,100 ,100 ] 100 ) translations t1 [y::=t2 ] substTrm y t2 t1

We give a special syntax annotations for the definition of the substitution of terms and processes. This kind of mixfix annotations merely decorate particular constant application forms with concrete syntax; in our case by replacing substT rm y t2 t1 with t1[y ::= t2]. The substitution of terms can be read as t1 with y for t2, is the substitution of all occurances of t2 in t1 with y. Mixfix annotations specify concrete inner syntax of Isabelle types and terms. Using the command syntax we introduce uninterpreted notational elements, after we use the command translations to relate the input forms to complex logical expressions. This technique provide a simple mechanism for syntactic macros.

56


Definition 4.2.4 (Substitution in processes) constdefs subst-nil :: var ⇒ trm ⇒ Proc subst-nil x t ≡ PNil subst-out-barb :: var ⇒ trm ⇒ trm ⇒ trm ⇒ Proc ⇒ Proc ⇒ Proc subst-out-barb x t ≡ λt1 t2 - p1 . ((t1 [x ::=t]).p1 ) subst-in-barb :: var ⇒ trm ⇒ trm ⇒ var ⇒ Proc ⇒ Proc ⇒ Proc subst-in-barb x t ≡ λt1 y - p1 . ((t1 [x ::=t])(y).p1 ) subst-par :: var ⇒ trm ⇒ Proc ⇒ Proc ⇒ Proc ⇒ Proc ⇒ Proc subst-par x t ≡ λ- - p1 p2 . (p1 kp2 ) subst-res :: var ⇒ trm ⇒ name ⇒ Proc ⇒ Proc ⇒ Proc subst-res x t ≡ λn - p1 . (hνnip1 ) subst-bang :: var ⇒ trm ⇒ Proc ⇒ Proc ⇒ Proc subst-bang x t ≡ λ- p1 .(!p1 ) subst-match :: var ⇒ trm ⇒ trm ⇒ trm ⇒ Proc ⇒ Proc ⇒ Proc subst-match x t ≡ λt1 t2 - p1 . ([(t1 [x ::=t])_(t2 [x ::=t])]p1 ) subst-letp :: var ⇒ trm ⇒ trm ⇒ var ⇒ var ⇒ Proc ⇒ Proc ⇒ Proc subst-letp x t ≡ λt1 y z - p1 .(split (t1 [x ::=t]) as (yo nz ) inn p1 ) subst-nat-case :: var ⇒ trm ⇒ trm ⇒ Proc ⇒ var ⇒ Proc ⇒ Proc ⇒ Proc ⇒ Proc subst-nat-case x t ≡ λt1 - y - p1 p2 . (caseint (t1 [x ::=t]) of 0 ⇒ p1 | ( y) ⇒ p2 ) subst-sk-dec :: var ⇒ trm ⇒ trm ⇒ trm ⇒ var ⇒ Proc ⇒ Proc ⇒ Proc subst-sk-dec x t ≡ λt1 t2 y - p1 . (casedec (t1 [x ::=t]) ofdec (t2 [x ::=t]){|y|} ⇒ p1 )

substProc :: var ⇒ trm ⇒ Proc ⇒ Proc substProc x t ≡ Proc-rec (subst-nil x t) (subst-out-barb x t) (subst-in-barb x t) (subst-par x t) (subst-res x t) (subst-bang x t) (subst-match x t) (subst-letp x t) (subst-nat-case x t) (subst-sk-dec x t)

syntax substProc-syntax :: var ⇒ trm ⇒ Proc ⇒ Proc (-[-:::=-] [100 ,100 ,100 ] 100 ) translations p[x :::=t] substProc x t p

4.3

Formal Operational Semantics

In this section we formalize the formal operational semantics of the spi calculus. Definition 4.3.1 constdefs AbsApply-abs :: trm ⇒ var ⇒ Proc ⇒ Proc

4.3. Formal Operational Semantics

57

AbsApply-abs t ≡ λx P . (P [x :::=t]) AbsApply :: trm ⇒ Abs ⇒ Proc AbsApply t ≡ Abs-rec (AbsApply-abs t)

Interaction right and left are defined using the recursion combinator of Conc process; which is declared as nominal datatype. The recursion rules generated by the nominal datatype in the case of Conc looks like this: V [[finite (supp f1 ); finite (supp f2 ); x1 x2 . P (f1 x1 x2 ); V Vx1 x2 y1 . P y1 =⇒ P (f2 x1 x2 y1 ); x1 x2 y1 . [[x1 ] f2 ; P (f2 x1 x2 y1 )]] =⇒ x1 ] f2 x1 x2 y1 ]] =⇒ Conc-rec f1 f2 (conc-par trm Proc) = f1 trm Proc V [[finite (supp f1 ); finite (supp f2 ); x1 x2 . P (f1 x1 x2 ); V x1 x2 y1 . P y1 =⇒ P (f2 x1 x2 y1 ); V x1 x2 y1 . [[x1 ] f2 ; P (f2 x1 x2 y1 )]] =⇒ x1 ] f2 x1 x2 y1 ; name ] f1 ; name ] f2 ]] =⇒ Conc-rec f1 f2 (Conc) = f2 name Conc (Conc-rec f1 f2 Conc)

Definition 4.3.2 (Interaction Right) constdefs InteractionR-base :: Abs ⇒ trm ⇒ Proc ⇒ Proc InteractionR-base F ≡ λt Q. (Q k (AbsApply t F )) InteractionR-step :: Abs ⇒ name ⇒ Conc ⇒ Proc ⇒ Proc InteractionR-step F ≡ λa - P . (hνaiP ) InteractionRight :: Abs ⇒ Conc ⇒ Proc InteractionRight F ≡ Conc-rec (InteractionR-base F ) (InteractionR-step F ) syntax InteractionRight-syntax :: Abs⇒ Conc ⇒ Proc (Right 0(-@- 0) [80 , 80 ] 80 ) translations Right(A @ C ) InteractionRight A C Definition 4.3.3 (Interaction Left) constdefs InteractionL-base :: Abs ⇒ trm ⇒ Proc ⇒ Proc InteractionL-base F ≡ λt Q. ((AbsApply t F ) k Q) InteractionL-step :: Abs ⇒ name ⇒ Conc ⇒ Proc ⇒ Proc InteractionL-step F ≡ λa - P . (hνaiP ) InteractionLeft :: Conc ⇒ Abs ⇒ Proc InteractionLeft ≡ λC F .(Conc-rec (InteractionL-base F ) (InteractionL-step F ) C ) syntax InteractionLeft-syntax :: Conc ⇒ Abs ⇒ Proc (Left 0(-@- 0) [80 , 80 ] 80 ) translations Left(F @ C ) (F ,C ) ∈ InteractionLeft

58


Definition 4.3.4 (Reduction) consts Reduction :: (Proc × Proc) set syntax Reduction-judge :: Proc ⇒ Proc ⇒ bool (- B - [80 , 80 ] 80 ) translations P B Q (P , Q) ∈ Reduction inductive Reduction intros red-repl [intro]: !P B P k !P red-match[intro]: [M _M ]P B P red-let[intro]: split (M o nN ) as (x o ny) inn P B (P [x :::=M ])[y:::=N ] red-zero[intro]: caseint 0 of 0 ⇒ P | ( x ) ⇒ Q B P red-suc[intro]: caseint ( M ) of 0 ⇒ P | ( x ) ⇒ Q B Q[x :::=M ] red-decrypt[intro]: casedec (N {|M |}) ofdec N {|x |} ⇒ P B (P [x :::=M ]) inductive-cases inductive-cases inductive-cases inductive-cases B P0 inductive-cases ⇒ Q B P0 inductive-cases ⇒ P B P0

RedRepcases[simplified Proc.distinct]: !P B P k P 0 RedMatchcases[simplified Proc.distinct]: [M _M ]P B P 0 RedLetcases[simplified Proc.distinct]: split (M o nN ) as (x o ny) inn P B P 0 RedZerocases[simplified Proc.distinct]: caseint 0 of 0 ⇒ P | ( x ) ⇒ Q RedSuccases[simplified Proc.distinct]: caseint ( M ) of 0 ⇒ P | ( x ) RedDecryptcases[simplified Proc.distinct]: casedec (N {|M |}) ofdec N {|x |}

Definition 4.3.4 defines the notion of reduction. For an inductive definition, the package returns an induction rule derived directly from the properties of least fixedpoints. The way induction rule works in Isabelle is described in chapter 3. The datatype induction rule generated by this definition is of the form: V V [[xb V B xa; P . Pa (!P ) (P k !P ); M P . Pa ([M _M ]P ) P ; nN as (x o ny) inn P ) (P [x :::=M ][y:::=N ]); VM N P x y. Pa (split M o P Q x . Pa (Proc.nat-case 0 P x Q) P; V M P Q x . Pa (Proc.nat-case (trm.Suc M ) P x Q) (Q[x :::=M ]); V M N P x . Pa (casedec (N {|M |}) ofdec N {|x |} ⇒ P ) (P [x :::=M ])]] =⇒ Pa xb xa

Case analysis on an inductive definition is called rule inversion. It is frequently used in proofs about operational semantics. It can be highly effective when it is applied automatically. The indicative cases command generates an instance of the cases rule for the supplied pattern and gives the supplied name. Every inductive definition produces a cases rule. Within a proof, we can use the ind cases method to apply an instance of the cases rule. The notion of commitment is defined in definition 4.3.5. As it can be noticed the syntax sugar used is different from the traditional one. The syntax used is m P − m → Q instead of P −→ Q. Definition 4.3.5 (Commitment)


59

consts Commitment :: (Proc × Barb × Agent) set syntax Commitment-judge :: Proc ⇒ trm ⇒ Agent ⇒ bool (- − - 7−→ - [80 , 80 , 80 ] 80 ) translations P − m 7−→ R (P ,m,R) ∈ Commitment inductive Commitment intros comm-in[intro]: (Name(m))(x ).P − barb(m) 7−→ (absAgent x P ) comm-out[intro]: (Name(m)).P − cobarb(m) 7−→ (resAgent (name(M )) (Agent P )) comm-inter1 [intro]: [[P − barb(m)7−→ F ; Q − cobarb(m) 7−→ (concAgent C )]] =⇒(P k Q) − τ 7−→ (procAgent (InteractionLeft C (Abs F ))) comm-inter2 [intro]: [[P − cobarb(m)7−→ (concAgent C ); Q − barb(m) 7−→ F ]] =⇒ (P k Q) − τ 7−→ (procAgent (InteractionRight (Abs F ) C )) comm-red [intro]: [[P B Q; Q − α 7−→ A]] =⇒ P − α 7−→ A comm-par1 [intro]: [[P − α 7−→ A ]] =⇒ (P k Q)− α 7−→ (parAgent A (procAgent(Q))) comm-par2 [intro]: [[Q − α 7−→ Q 0]] =⇒ (P k Q) − α 7−→ (parAgent (procAgent(P )) Q 0) comm-res[intro]: [[m ] α; P − α 7−→ P 0]] =⇒ hν(name(m))i(P ) − barb(m)7−→(resAgent (name(m)) P 0)

4.3.1

Framed Bisimulation

In this section we report the definition of Framed Bisimulation. We start by defining the notion of frame and theory. Definition 4.3.6 types frame = name set theory = (trm × trm) set

Type synonyms are similar to those found in ML. They are created by the command types. Internally all synonyms are fully expanded. As a consequence Isabelle output never contains synonyms. Their main purpose is to improve the readability of theories. Synonyms are used just like any other type. frame is defined as a set of names, while theory is a set of pairs of type trm. Next we define the predicate (f r, th) ` M ↔ N inductively, by a set of rules. Intuitively, this predicate means that the environment cannot distinguish M coming from P and N coming from Q, and that the environment has (or can construct) M in interaction with P and N in interaction with Q. Definition 4.3.7 (Eq in terms) consts EqTerm :: (frame × theory × trm × trm) set syntax EqTerm-judge :: frame ⇒ theory ⇒ trm ⇒ trm ⇒ bool ( 0(-,- 0) ` 0(-↔- 0) [80 , 80 , 80 , 80 ] 80 ) translations (F ,T )`(N ↔ M ) (F ,T ,N ,M ) ∈ EqTerm

inductive EqTerm intros EqTermFr : [[n ∈ frame]] =⇒ (fr ,th)`(n↔n) EqTermTr : [[(m,n) ∈ theory]] =⇒ (fr ,th)`(m↔n) EqTermVar : (fr ,th)` ((Var x )↔(Var x ))

60

EqTermPair : EqTermZero: EqTermSuc: EqTermEnc:


[[(fr ,th)`(m↔p); (fr ,th)`(n↔l )]] =⇒ (fr ,th)` ((mo nn)↔(po nl )) (fr ,th)`(0↔0) [[(fr ,th)`(m↔p)]] =⇒ (fr ,th)`((m)↔( p)) [[(fr ,th)`(M ↔P ); (fr ,th)`(n↔l )]] =⇒ (fr ,th)` ((n{|M |})↔(l {|P |}))

declare EqTerm.intros [intro]

Definition 4.3.8 defines the notion of the predicate (f r, th) ` ok. The definition is made by first stating the two conditions OK1 and OK2. We say that the pair (fr,th) is ok, if the two conditions holds. Definition 4.3.8 ((fr ,th)` ok ) constdefs Ok1 :: frame ⇒ theory ⇒ bool Ok1 F T ≡ (∀ M N .(M ,N ) ∈ T −→(♣ M ) ∧ (♣ N ) ∧ (∃ M1 M2 . (M =M1 {|M2 |}) ∧ (∀ N2 .(F ,T ,M2 ,N2 ) ∈ / EqTerm)) ∧ (∃ N1 N2 . (N =N1 {|N2 |}) ∧ (∀ M2 .(F ,T ,M2 ,N2 ) ∈ / EqTerm))) Ok2 :: frame ⇒ theory ⇒ bool Ok2 F T ≡ (∀ M N M 0 N 0.(M ,N ) ∈ T −→ (M 0,N 0)∈ T −→((M =M 0)−→(N =N 0)) ∧ ((N =N 0)−→(M =M 0))) Ok :: frame ⇒ theory ⇒ bool ( 0(-, - 0) ` OK [80 , 80 ] 80 ) Ok F T ≡ (Ok2 F T ) ∧ (Ok1 F T )

A constdefs command combines the effects of consts and defs. defs and const is used to define constants. The symbol ≡ is a special form of equality that must be used in constant definitions. In contrast to many functional programming languages, in Isabelle all functions must explicitly declared. Apart from the declaration-before-use restriction, the order of items in a theory file is un-constrained. Next we extend the definition of EqTerm to the processes, we define the notion of the predicate (f r, th) ` P ↔ Q, where P and Q are processes. Definition 4.3.9 (Eq in processes) consts EqProc :: (frame × theory × Proc × Proc) set syntax EqProc-judge :: frame ⇒ theory ⇒ Proc ⇒ Proc ⇒ bool ( 0(-,- 0) → 0(-↔- 0) [80 , 80 , 80 , 80 ] 80 ) translations (F ,T )→(N ↔ M ) (F ,T ,N ,M ) ∈ EqProc inductive EqProc intros EqProcIn: [[(fr ,th)`(M ↔M 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→((M (x ).P )↔(M 0(x ).P 0)) EqProcOut: [[(fr ,th)`(M ↔M 0); (fr ,th)`(N ↔N 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→ ((M .P )↔(M 0.P 0)) EqProcPar : [[(fr ,th)→(Q↔Q 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→((P kQ)↔(P 0kQ 0)) EqProcRes: [[((fr ∪(name N )),th)→(P ↔P 0); N ] (fr ,th)]] =⇒ (fr ,th)→ ((hνN iP )↔(hνN iP 0)) EqProcBang: [[(fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→ ((!P )↔(!P 0)) EqProcMatch: [[(fr ,th)`(M ↔M 0); (fr ,th)`(N ↔N 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→


61

(([M _N ]P )↔([M 0_N 0]P 0)) EqProcLetp: [[(fr ,th)`(M ↔M 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→((split M as (x o ny) inn P ) ↔(split M 0 as(x o nY ) inn P 0)) EqProcNatCase: [[(fr ,th)`(M ↔M 0); (fr ,th)→(Q↔Q 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→ ((caseint M of 0 ⇒ P |( x ) ⇒ Q)↔(caseint M 0 of 0 ⇒ P 0 | ( x ) ⇒ Q 0)) EqProcSkCase: [[(fr ,th)`(M ↔M 0); (fr ,th)`(N ↔N 0); (fr ,th)→(P ↔P 0)]] =⇒ (fr ,th)→ ((casedec M ofdec N {|x |} ⇒ P )↔(casedec M 0 ofdec N 0{|x |} ⇒ P 0)) declare EqProc.intros [intro]

In definition 4.3.10 we define the notion of ordering pair. This define the ordering between pairs of frames and theories. Definition 4.3.10 ((fr ,th) ≤ (fr 0,th 0)) constdefs OrderPair :: frame ⇒ theory ⇒ frame ⇒ theory ⇒ bool ( 0(-,- 0) . 0(-,- 0) [80 , 80 , 80 , 80 ] 80 ) (F ,T ) . (F 0,T 0) ≡ ∀ M N .(F ,T )`(M ↔N ) −→ (F 0,T 0)`(M ↔N )

Next we formalize the proof of the following proposition: Proposition 4.3.11 Suppose (f r0 , th0 ) ` ok. Then (f r, th) ≤ (f r0 , th0 ) ⇐⇒ f r ⊆ f r0 and (f r0 , th0 ) ` M ↔ N for each (M, N ) ∈ th. In lemma 4.3.13 we prove the ⇒ . To show this direction we assume that f r ⊆ f r0 and (f r0 , th0 ) ` M ↔ N for each (M, N ) ∈ th. We consider any M and N such that (f r, th) ` M ↔ N . An induction on the derivation of (f r, th) ` M ↔ N shows that (f r0 , th0 ) ` M ↔ N . Therefore (f r, th) ≤ (f r0 , th0 ). Lemma 4.3.12 lemma OrderPair-I : V assumes M N .(F ,T )`(M ↔N ) =⇒ (F 0,T 0)`(M ↔N ) and Fr ⊆ Fr 0 shows (F ,T ) . (F 0,T 0) unfolding OrderPair-def using prems by blast Lemma 4.3.13 lemma prop1Right: assumes A1V : (Fr 0, Th 0) ` OK and A2 : M N .(M ,N ) ∈ Th =⇒ ((Fr 0,Th 0)` (M ↔N )) and A3 : Fr ⊆ Fr 0 shows (Fr ,Th) . (Fr 0,Th 0) proof (rule OrderPair-I ) show Fr ⊆ Fr 0 by assumption fix M N assume ((Fr ,Th)` (M ↔N ))

62


then show ((Fr 0,Th 0)` (M ↔N )) proof induct case (EqTermFr Fr frame n Th) show ?case by(auto intro: EqTerm.EqTermFr ) next case (EqTermTr Fr m n Th theory) show ?case by(auto intro: EqTerm.EqTermTr ) next case (EqTermVar Fr Th x ) show ?case by(auto intro:EqTerm.EqTermVar ) next case (EqTermPair Fr l m n p Th) show ?case by(auto intro: EqTerm.EqTermPair ) next case (EqTermZero Fr Th) show ?case by(auto intro: EqTerm.EqTermZero) next case (EqTermSuc Fr m p Th) show ?case by(auto intro: EqTerm.EqTermSuc) next case (EqTermEnc M P Fr l n Th) show ?case by(auto intro:EqTerm.EqTermEnc) qed qed

The proof of 4.3.13 is made by using the induct proof method. The induct proof method of Isabelle/Isar is a sophisticated wrapper for the basic rule method. Arguments provided in the proof text are interpreted as directions for local modifications of the proof context, induction rule, and goal, culminating in the actual logic refinement step. The resulting proof body contain several subgoals corresponding to the indicative cases of the instantiated rule after refinement, together with named cases to enable abbrivations e.g case EqTermFr Fr frame n Th show ? in the induction step, instead of explicit fix x1 ...xn assume A1 ...An show B. The general method invocation looks like this: facts (induct insts fixing:vars rule: rule) facts refers to the implicit facts being passed to any Isar method accoriding to the proof structure, and is indicated by then or using; insts is a list of instantiations; vars refers to a list of fixed variables; rule refers to the underlying induction principle. These arguments are optional. In lemma 4.3.14 we prove the other direction (⇐=). Lemma 4.3.14 lemma prop1Left: fixes Fr :: frame and Th :: theory and Fr 0 :: frame


and

63

Th 0 :: theory

assumes A1 : (Fr 0, Th 0) ` OK and A2 : (M ,N ) ∈ Th and A3 : ((Fr ,Th). (Fr 0,Th 0)) shows A4 : ∀ M N .(Fr 0,Th 0)` (M ↔N ) proof − from A2 have (Fr ,Th)`(M ↔N ) by(auto intro: EqTerm.EqTermFr ) then show ?thesis by(auto simp add : OrderPair-def ) qed

Lemma 4.3.12 is an auxilary lemma, that we use to proof lemma 4.3.13. This lemma simply unfold the definition of the ordering pair. At last we formalize the definition of Framed Bisimilarity through the definition 4.3.15. Framed bisimilarity is defined as coinductive function. The way coinductive definition works in Isabelle is reported in chapter 3. Definition 4.3.15 (Framed Bisimulation) consts FramedBisim :: (frame × theory × Proc × Proc) set coinductive FramedBisim intros FramedBisim-Def : [[∀ P 0.(P − τ 7−→ (procAgent P 0)) −→ (∃ Q 0.(Q − τ 7−→ (procAgent Q 0)) ∧ (F ,T ,P 0,Q 0) ∈ FramedBisim); ∀ Q 0.(Q − τ 7−→ (procAgent Q 0)) −→ (∃ P 0.(P − τ 7−→ (procAgent P 0)) ∧ (F ,T ,P 0,Q 0) ∈ FramedBisim); ∀ P 0 C x . (C ∈ F ) −→ (P − barb(C ) 7−→ (absAgent x P 0)) −→ (∃ Q 0. (Q − barb(C ) 7−→ (absAgent x Q 0)) ∧ (∀ M N n.((♣ M ) ∧ (♣ N ) ∧ (n ] (F ,T ,P ,Q)))−→ ((F ∪n),T )`(M ↔N ) −→ (((F ∪n), T ,(P 0[x :::=M ]), (Q 0[x :::=N ])) ∈ FramedBisim))); ∀ Q 0 C x . (C ∈ F ) −→ (Q − barb(C ) 7−→ (absAgent x Q 0)) −→ (∃ P 0. (P − barb(C ) 7−→ (absAgent x P 0)) ∧ (∀ M N n.((♣ M ) ∧ (♣ N ) ∧ (n ] (F ,T ,P ,Q)))−→ ((F ∪n),T )`(M ↔N ) −→ (((F ∪n), T ,(P 0[x :::=M ]), (Q 0[x :::=N ])) ∈ FramedBisim))); ∀ P 0 (m::name list) M C . (C ∈ F ) −→ (m ] (F ,T ,P )) −→ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) −→ (∃ Q 0 n N .(n ] (F ,T ,Q)) ∧ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) ∧ (∃ F 0 T 0.(((F ,T ). (F 0,T 0)) ∧ (F ,T )`(M ↔N ))∧ (F 0, T 0 ,P 0, Q 0) ∈ FramedBisim)); ∀ Q 0 (n:: name list) N C . (C ∈ F ) −→ (n ] (F ,T ,Q)) −→ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) −→ (∃ P 0 m M .(m ] (F ,T ,P )) ∧ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) ∧ (∃ F 0 T 0.(((F ,T ). (F 0,T 0)) ∧ (F ,T )`(M ↔N ))∧ (F 0, T 0 ,P 0, Q 0) ∈ FramedBisim)) ]] =⇒ (F ,T ,P ,Q) ∈ FramedBisim declare FramedBisim.intros [intro]

For a coinductive definition, the package returns a basic coinductive rules. For

64


the definition of Framed Bisimulation the package returns the following coinductive rule: [[?a V ∈ ?X ; z . z ∈ ?X =⇒ ∃F P Q T. z = (F , T , P , Q) ∧ (∀ P 0. P − τ 7−→ procAgent P 0 −→ (∃ Q 0. Q − τ 7−→ procAgent Q 0 ∧ (F , T , P 0, Q 0) ∈ ?X ∪ FramedBisim)) ∧ 0 (∀ Q . Q − τ 7−→ procAgent Q 0 −→ (∃ P 0. P − τ 7−→ procAgent P 0 ∧ (F , T , P 0, Q 0) ∈ ?X ∪ FramedBisim)) ∧ 0 (∀ P C x . C ∈ F −→ P − barbC 7−→ absAgent x P 0 −→ (∃ Q 0. Q − barbC 7−→ absAgent x Q 0 ∧ (∀ M N n. (♣M ) ∧ (♣N ) ∧ n ] (F , T , P , Q) −→ ((F ∪ n),T ) ` (M ↔N ) −→ (F ∪ n, T , P 0[x :::=M ], Q 0[x :::=N ]) ∈ ?X ∪ FramedBisim))) ∧ (∀ Q 0 C x . C ∈ F −→ Q − barbC 7−→ absAgent x Q 0 −→ (∃ P 0. P − barbC 7−→ absAgent x P 0 ∧ (∀ M N n. (♣M ) ∧ (♣N ) ∧ n ] (F , T , P , Q) −→ ((F ∪ n),T ) ` (M ↔N ) −→ (F ∪ n, T , P 0[x :::=M ], Q 0[x :::=N ]) ∈ ?X ∪ FramedBisim))) ∧ (∀ P 0 m M C . C ∈ F −→ m ] (F , T , P ) −→ P − cobarbC 7−→ concAgent (ConcChain m M P 0) −→ (∃ Q 0 n N . n ] (F , T , Q) ∧ Q − cobarbC 7−→ concAgent (ConcChain n N Q 0) ∧ (∃ F 0 T 0. ((F ,T ) . (F 0,T 0) ∧ (F ,T ) ` (M ↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ ?X ∪ FramedBisim))) ∧ 0 (∀ Q n N C . C ∈ F −→ n ] (F , T , Q) −→ Q − cobarbC 7−→ concAgent (ConcChain n N Q 0) −→ (∃ P 0 m M . m ] (F , T , P ) ∧ P − cobarbC 7−→ concAgent (ConcChain m M P 0) ∧ (∃ F 0 T 0. ((F ,T ) . (F 0,T 0) ∧ (F ,T ) ` (M ↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ ?X ∪ FramedBisim)))]] =⇒ ?a ∈ FramedBisim

4.4. Formal proofs of properties and examples

65

It also returns the following introduction rule: [[∀ P 0. ?P − τ 7−→ procAgent P 0 −→ (∃ Q 0. ?Q − τ 7−→ procAgent Q 0 ∧ (?F , ?T , P 0, Q 0) ∈ FramedBisim); 0 ∀ Q . ?Q − τ 7−→ procAgent Q 0 −→ (∃ P 0. ?P − τ 7−→ procAgent P 0 ∧ (?F , ?T , P 0, Q 0) ∈ FramedBisim); 0 ∀ P C x. C ∈ ?F −→ ?P − barbC 7−→ absAgent x P 0 −→ (∃ Q 0. ?Q − barbC 7−→ absAgent x Q 0 ∧ (∀ M N n. (♣M ) ∧ (♣N ) ∧ n ] (?F , ?T , ?P , ?Q) −→ ((?F ∪ n),?T ) ` (M ↔N ) −→ (?F ∪ n, ?T , P 0[x :::=M ], Q 0[x :::=N ]) ∈ FramedBisim)); 0 ∀ Q C x. C ∈ ?F −→ ?Q − barbC 7−→ absAgent x Q 0 −→ (∃ P 0. ?P − barbC 7−→ absAgent x P 0 ∧ (∀ M N n. (♣M ) ∧ (♣N ) ∧ n ] (?F , ?T , ?P , ?Q) −→ ((?F ∪ n),?T ) ` (M ↔N ) −→ (?F ∪ n, ?T , P 0[x :::=M ], Q 0[x :::=N ]) ∈ FramedBisim)); 0 ∀P m M C. C ∈ ?F −→ m ] (?F , ?T , ?P ) −→ ?P − cobarbC 7−→ concAgent (ConcChain m M P 0) −→ (∃ Q 0 n N . n ] (?F , ?T , ?Q) ∧ ?Q − cobarbC 7−→ concAgent (ConcChain n N Q 0) ∧ (∃ F 0 T 0. ((?F ,?T ) . (F 0,T 0) ∧ (?F ,?T ) ` (M ↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ FramedBisim)); 0 ∀Q n N C. C ∈ ?F −→ n ] (?F , ?T , ?Q) −→ ?Q − cobarbC 7−→ concAgent (ConcChain n N Q 0) −→ (∃ P 0 m M . m ] (?F , ?T , ?P ) ∧ ?P − cobarbC 7−→ concAgent (ConcChain m M P 0) ∧ (∃ F 0 T 0. ((?F ,?T ) . (F 0,T 0) ∧ (?F ,?T ) ` (M ↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ FramedBisim))]] =⇒ (?F , ?T , ?P , ?Q) ∈ FramedBisim

4.4

Formal proofs of properties and examples

In this section we report some basic lemmas that proves some of the important properties introduced in the nominal logic package. Specially the notion of support and freshness. We also report an example of framed bismularity between two processes.

66

4.4.1


Properties about names and variables

In definition 4.4.1 is reported the notion of equivariance, which basically state the property of being preserved by permutations. Definition 4.4.1 eqvt R ≡ ∀ p T U.(T, U ) ∈ R −→ (p • T, p • U ) ∈ R In general, the definition of supp T of a term T is the set of names which can affect T in permutations. In other words, if p is a permutation only involving names outside the support of T then p • T = T . α-equivalent terms are identified, therefore the support corresponds to the free names. The support of a term is finite, thus for any term it is always possible to find a name outside its support. Definition 4.4.2 a]T ≡ a ∈ / supp(T ) a ] T is read: “a fresh for T” As said earlier, the nominal package also generates lemmas for reasoning about α-equivalence. Lemma 4.4.3 proves that the notion of freshness works properly in ConcChain (definition 4.1.3). lemmas name-fresh-abs = fresh-abs-fun-iff [OF pt-name-inst, OF at-name-inst, OF fs-name1 ] Lemma 4.4.3 lemma ConcChainFresh: fixes a :: name and lst :: name list and T :: trm and P :: Proc assumes a ] (lst, T , P ) shows a ] (ConcChain lst T P ) using prems apply(induct-tac lst) apply(simp add : fresh-prod ) by(simp add : fresh-prod name-fresh-abs)

Next we report the proof of the support notion in the case of the trm nominal datatype. In fact one of the most interesting feature of the nominal logic package is that as soon as a permutation action for a type is fixed, it is possible to fix also the support of this type and their set of free atoms. The support of x, written supp(x ), is the set of atoms defined as: supp(x) ≡ {a | inf inite {b | (ab) • x 6= x }}


67

This definition has the advantage that it generalises the notion of free variables to functions. Lemma 4.4.4 lemma supports-subst-Var : shows ((supp (x ,t))::name set) supports (subst-Var x t) apply(supports-simp add : subst-Var-def ) apply(rule impI ) apply(drule pt-bij1 [OF pt-name-inst, OF at-name-inst]) apply(perm-simp) done Lemma 4.4.5 lemma supports-subst-Name: shows ((supp (x ,t))::name set) supports (subst-Name x t) by (supports-simp add : subst-Name-def ) lemma supports-subst-Zero: shows ((supp (x ,t))::name set) supports (subst-Zero x t) by (supports-simp add : subst-Zero-def ) lemma supports-subst-Succ: shows ((supp (x ,t))::name set) supports (subst-Succ x t) by (supports-simp add : subst-Succ-def ) lemma supports-subst-Enc: shows ((supp (x ,t))::name set) supports (subst-Enc x t) by (supports-simp add : subst-Enc-def ) lemma supports-subst-Pair : shows ((supp (x ,t))::name set) supports (subst-Pair x t) by (supports-simp add : subst-Pair-def )

Another important property is the “finitely supported permutation types”: a permutatation type α is said to be finitely supported, if every element of α has finite support. If x of permutation type has finite support, then there exists an atom a with a]x. The result of this definition is that, whenever we need to choose a fresh atom for an x of permutation type, we have to make sure that x has finite support. In the next lemma we prove that in the substitution of terms(substTrm), the permutation types has finite support. Lemma 4.4.6 lemma fin-supp-subst: shows finite ((supp (subst-Var x t,subst-Name x t,subst-Zero x t,subst-Succ x t,subst-Enc x t, subst-Pair x t))::name set) apply(auto simp add : supp-prod ) apply(rule supports-finite) apply(rule supports-subst-Var ) apply(simp add : fs-name1 )

68


apply(rule supports-finite) apply(rule supports-subst-Name) apply(simp add : fs-name1 ) apply(rule supports-finite) apply(rule supports-subst-Zero) apply(simp add : fs-name1 ) apply(rule supports-finite) apply(rule supports-subst-Succ) apply(simp add : fs-name1 ) apply(rule supports-finite) apply(rule supports-subst-Enc) apply(simp add : fs-name1 ) apply(rule supports-finite) apply(rule supports-subst-Pair ) apply(simp add : fs-name1 ) done

In lemma 4.4.7 we prove the freshness condition for binders (FCB) in the case of res. FCB must be generalised for all atom types in binding position. Lemma 4.4.7 lemma fresh-subst-res: assumes fr : a](subst-res x t) shows a](subst-res x t) a t1 r by (simp add : subst-res-def abs-fresh)

4.4.2

Example of framed bisimilarity

This section shows how framed bismulation can be exploited in proofs. We report an example to show that the definition 4.3.15 of framed bisimilarity works as intended. In example 4.4.8 we prove the framed bisimulation of the processes Pnil and (Pnil kPnil ), thus they are testing equivalent. This example although trivial, is useful to check that the definition of FramedBisim is correct; and can be used as a proof outline for mmore complex examples. Basically the proof is done by using mostly forward reasoning, through the coinduct proof method. As can be noticed from the example, we first use the definition of commitment, then we analyze the subgoals and if it is case we use the reduction relation to prove the goals. Lemma 4.4.8 lemma aus: assumes z ∈ {({}, {}, PNil , (PNil k PNil ))} shows z = ({}, {}, PNil , (PNil k PNil )) proof − from prems show ?thesis by blast qed

Example 4.4.9 lemma ({},{},PNil ,PNil kPNil ) ∈ FramedBisim (is ?x ∈ -)


69

proof − have ?x : {?x } by blast then show ?thesis proof coinduct case (FramedBisim x ) have ?FramedBisim-Def proof − from FramedBisim have x = ?x by simp moreover { fix P 0 assume PNil − τ 7−→ (procAgent P 0) then have ∃ Q 0. (PNil kPNil ) − τ 7−→ (procAgent Q 0) ∧ (P 0 = PNil ∧ Q 0 = (PNil kPNil ) ∨ ({}, {}, P 0, Q 0) ∈ FramedBisim) apply cases apply auto apply (ind-cases PNil B Q) done } moreover { fix Q 0 assume Pnil k Pnil − Btau 7−→ procAgent Q 0 then have ∃ P 0. Proc.Pnil − Barb.Btau 7−→ Agent.procAgent P 0 ∧ (P 0 = Proc.Pnil ∧ Q 0 = Proc.par Proc.Pnil Proc.Pnil ∨ ({}, {}, P 0, Q 0) ∈ FramedBisim) apply cases apply auto apply(simp add : Proc.inject) apply(ind-cases Proc.Pnil − Barb.Inbarb m 7−→ F ) apply(ind-cases Proc.Pnil − Barb.Cobarb m 7−→ Agent.concAgent C ) apply(ind-cases Proc.Pnil B Qb) apply(simp add : Proc.inject) apply(ind-cases Proc.Pnil − Barb.Cobarb m 7−→ Agent.concAgent C ) apply(ind-cases Proc.Pnil B Qa) apply(ind-cases Proc.par Proc.Pnil Proc.Pnil B Q) done } ultimately show ?thesis by simp qed then show ?case by blast qed qed

A complete example, about the “perfect encryption” is reported in the appendix A; this example had been taken from [AG98]. The example shows that the processes: (ν k)ch{M }k i and (ν k)ch{M 0 }k i are in framed bismulation, so they are testing equivalent. This means that these processes do not reveal M and M’, rispectively. In the proof we show that ({c, n}, {}) ` (ν k)ch{M }k i S (ν k)ch{M 0 }k i and S is a framed bisimulation.

70

4.5


D-Framed Bisimulation

In this section we report the formalization of D-Framed Bisimulation defined in [Hut02]. As said in chapter 2, d-framed bisimilarity is a variant of framed bisimilarity that only requires input transitions to be matched for transmitted message terms up to a certain depth. We define the maximal constructor depth. This function counts the level of encryption and the level of pairing. It is defined in Isabelle/HOL-Nominal using the recursion combinator of the trm nominal datatype. Definition 4.5.1 (Maximal construtor depth) constdefs Mcd-Var :: var ⇒ nat Mcd-Var ≡ λ-. 0 Mcd-Name :: name ⇒ nat Mcd-Name ≡ λ-.0 Mcd-zero :: nat Mcd-zero ≡ 0 Mcd-Suc :: trm ⇒ nat ⇒ nat Mcd-Suc ≡ λ- n. (n + 1 ) Mcd-pair :: trm ⇒ trm ⇒ nat ⇒ nat ⇒ nat Mcd-pair ≡ λ- - n1 n2 .((max n1 n2 ) + 1 ) Mcd-enc :: trm ⇒ trm ⇒ nat ⇒ nat ⇒ nat Mcd-enc ≡ λ- - - n. n+1 Mcd :: trm ⇒ nat Mcd ≡ trm-rec Mcd-Var Mcd-Name Mcd-zero Mcd-Suc Mcd-pair Mcd-enc

Next we report some lemmas to check that the definition of the maximal constructor depth works properly. We check the notion of support, and finetely support permutation. Lemma 4.5.2 lemma supp-d-Var : shows ((supp Mcd-Var )::name set)={} apply(simp add : Mcd-Var-def ) apply(simp add : supp-def ) apply(simp add : perm-fun-def ) apply(simp add : perm-nat-def ) done lemma supp-d-Name: shows ((supp Mcd-Name)::name set)={} apply(simp add : Mcd-Name-def )

4.5. D-Framed Bisimulation

71

apply(simp add : supp-def ) apply(simp add : perm-fun-def ) apply(simp add : perm-nat-def ) done

lemma supp-d-zero: shows ((supp Mcd-zero)::name set)={} apply(simp add : Mcd-zero-def ) apply(simp add : supp-def ) apply(simp add : perm-nat-def ) done lemma supp-Mcd-Suc: shows ((supp Mcd-Suc)::name set)={} apply(simp add : Mcd-Suc-def ) apply(simp add : supp-def ) apply(simp add : perm-fun-def ) apply(simp add : perm-nat-def ) done lemma supp-d-pair : shows ((supp Mcd-pair )::name set)={} apply(simp add : Mcd-pair-def ) apply(simp add : supp-def ) apply(simp add : perm-fun-def ) apply(simp add : perm-nat-def ) done

lemma supp-d-enc: shows ((supp Mcd-enc)::name set)={} apply(simp add : Mcd-enc-def ) apply(simp add : supp-def ) apply(simp add : perm-fun-def ) apply(simp add : perm-nat-def ) done Lemma 4.5.3 lemma fin-supp-d : shows finite ((supp (Mcd-Var ,Mcd-Name,Mcd-zero,Mcd-Suc, Mcd-enc))::name set) by (finite-guess add : Mcd-Var-def Mcd-Name-def Mcd-zero-def Mcd-Suc-def Mcd-pair-def Mcd-enc-def perm-nat-def fs-name1 )

Definition 4.5.4 defines the maximal constructor depth of the environment, namely the (theory,frame) pair. Definition 4.5.4 consts MaxDepthEnv :: (frame × theory × nat) set inductive MaxDepthEnv intros MaxDepth-env [intro]: [[(M ,N )∈ T ]] =⇒ (F ,T ,(max (Mcd M ) (Mcd N ))) ∈ MaxDepthEnv

72


The maximal destructor depth of a process P is the maximal number of encryptions and pairing operators that can ever be removed along the process P. The next definition is the formalization of this definition. Definition 4.5.5 (Maximal destructor depth) constdefs MDD-nil :: nat MDD-nil ≡ 0 MDD-out-barb :: trm ⇒ trm ⇒ Proc ⇒ nat ⇒ nat MDD-out-barb ≡ λ- - - n. n MDD-in-barb :: trm ⇒ var ⇒ Proc ⇒ nat ⇒ nat MDD-in-barb ≡ λ- - - n. n MDD-par :: Proc ⇒ Proc ⇒ nat ⇒ nat ⇒ nat MDD-par ≡ λ- - n m. n+m MDD-res :: name ⇒ Proc ⇒ nat ⇒ nat MDD-res ≡ λ- - n. n MDD-bang :: Proc ⇒ nat ⇒ nat MDD-bang ≡ λ- n. n MDD-match :: trm ⇒ trm ⇒ Proc ⇒ nat ⇒ nat MDD-match ≡ λ- - - n. n MDD-letp :: trm ⇒ var ⇒ var ⇒ Proc ⇒ nat ⇒ nat MDD-letp ≡ λ- - - - n. n+1 MDD-nat-case:: trm ⇒ Proc ⇒ var ⇒ Proc ⇒ nat ⇒ nat ⇒ nat MDD-nat-case ≡ λ- - - - n m. ((max n m) + 1 ) MDD-sk-dec:: trm ⇒ trm ⇒ var ⇒ Proc ⇒ nat ⇒ nat MDD-sk-dec ≡ λ- - - - n. (n + 1 ) MDD:: Proc ⇒ nat MDD ≡ Proc-rec MDD-nil MDD-out-barb MDD-in-barb MDD-par MDD-res MDD-bang MDD-match MDD-letp MDD-nat-case MDD-sk-dec

Definition 4.5.6 defines the notion of K-indistinguishable in the environment. Definition 4.5.6 constdefs K −Indist :: nat ⇒ frame ⇒ theory ⇒ trm ⇒ trm ⇒ bool ( 0(-,-,- 0) ` 0(- ↔ - 0) [80 , 80 , 80 , 80 , 80 ] 80 ) (k ,F ,T ) ` (M ↔N ) ≡ (F ,T ) ` (M ↔N ) ∧ ((max (Mcd M ) (Mcd N )) = k )

Our aim is to automatize the proof of two process being framed bisimilar. Instead of implementing directly the algorithm developed by H¨ uttel, we follow the general


73

idea of the algorithm and we formalize the definition of the d-framed bisimulation by adding some optimization, in order to “help” the proof methods already implemented in Isabelle in the process of the proof search. We first report the orginal version of d-framed bisimilar ; this version follow the idea of H¨ uttel. Definition 4.5.7 (D-framed bisimulation-original version) consts DFramedBisimO :: nat ⇒(frame × theory × Proc × Proc) set coinductive DFramedBisimO d intros DFramedBisimO-Def : [[∀ P 0.(P − τ 7−→ (procAgent P 0)) −→ (∃ Q 0.(Q − τ 7−→ (procAgent Q 0)) ∧ (F ,T ,P 0,Q 0) ∈ DFramedBisimO d ); ∀ Q 0.(Q − τ 7−→ (procAgent Q 0)) −→ (∃ P 0.(P − τ 7−→ (procAgent P 0)) ∧ (F ,T ,P 0,Q 0) ∈ DFramedBisimO d );

∀ P 0 C x . (C ∈ F ) −→ (P − barb(C ) 7−→ (absAgent x P 0)) −→ (∃ Q 0. (Q − barb(C ) 7−→ (absAgent x Q 0)) ∧ (∀ M N .(♣ M ) ∧ (♣ N ) ∧ (∀ n. ((n ∈ Finites) ∧ (n ] (F ,T ,P ,Q)) ∧ ((card n) < (2 ∗ d ))) −→ (∀ i .((i ≥ 0 ) ∧ (i ≤ d ) ∧ (i ,(F ∪n),T )`(M ↔N )) −→ ((F ∪n), T ,(P 0[x :::=M ]),( Q 0[x :::=N ])) ∈ DFramedBisimO d )))); ∀ Q 0 C x . (C ∈ F ) −→ (Q − barb(C ) 7−→ (absAgent x Q 0)) −→ (∃ P 0. (P − barb(C ) 7−→ (absAgent x P 0)) ∧ (∀ M N .(♣ M ) ∧ (♣ N ) ∧ (∀ n. ((n ∈ Finites) ∧ (n ] (F ,T ,P ,Q)) ∧ ((card n) < (2 ∗ d ))) −→ (∀ i .((i ≥ 0 ) ∧ (i ≤ d ) ∧ (i ,(F ∪n),T )`(M ↔N )) −→ ((F ∪n), T ,(P 0[x :::=M ]),( Q 0[x :::=N ])) ∈ DFramedBisimO d )))); ∀ P 0 (m::name list) M C . (C ∈ F ) −→ (m ] (F ,T ,P )) −→ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) −→ (∃ Q 0 n N .(n ] (F ,T ,Q)) ∧ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) ∧ (∃ F 0 T 0.(((F ,T ). (F 0,T 0)) ∧ (F ,T )`(M ↔N ))∧ (F 0, T 0 ,P 0, Q 0) ∈ DFramedBisimO d )); ∀ Q 0 (n:: name list) N C . (C ∈ F ) −→ (n ] (F ,T ,Q)) −→ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) −→ (∃ P 0 m M .(m ] (F ,T ,P )) ∧ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) ∧ (∃ F 0 T 0.(((F ,T ). (F 0,T 0)) ∧ (F ,T )`(M ↔N ))∧ (F 0, T 0 ,P 0, Q 0) ∈ DFramedBisimO d )) ]] =⇒ (F ,T ,P ,Q) ∈ DFramedBisimO d

As reported before, frame and theory are defined as a set of names and a set of pairs of type trm rispectively. In defining the notion of D-framed bisimulation we want to use a finite set for both frame and theory, in order to limit the range of the terms. Since there is no separate type constructor for finite sets, like in definition 4.3.6, we will just use explicit set/predicate constraints by putting as a precondition of the definition of D-framed bisimulation. In order to add some optimization in the definition of DFramedBisimO, we dislocate some of the functions they were inside the coinductive definition by putting them in an indipendent definition. Since we only consider finitely many terms when matching input transitions, we define a function that gives in output finetely closed terms of height n. We call this function Tsearch, which is defined by induction.

74


Dsearch is the function that takes a frame a theory and a nat, and gives in output a finite set of pair terms; where each terms has been constructed by TSearch. Definition 4.5.8 consts TSearch :: (trm × frame × nat )set inductive TSearch intros TSearch-zero : (0,F ,0 ) ∈ TSearch TSearch-name : [[n ∈ frame]] =⇒ (n,F ,0 ) ∈ TSearch TSearch-suc : [[(M ,F ,(Mcd M ))∈ TSearch ]] =⇒ (suc(M ),F ,((Mcd M )+1 )) ∈ TSearch TSearch-pair : [[(M ,F ,(Mcd M )) ∈ TSearch; (N ,F ,(Mcd N )) ∈ TSearch]] =⇒ ((M o nN ),F ,((max (Mcd M ) (Mcd N ))+1 )) ∈ TSearch TSearch-enc : [[(M ,F ,(Mcd M )) ∈ TSearch]] =⇒ ((N {|M |}),F ,((Mcd M ) + 1 )) ∈ TSearch declare TSearch.intros [intro] Definition 4.5.9 consts DSearch :: frame ⇒ theory ⇒ nat ⇒ (trm × trm)set inductive DSearch F T n intros DSearch-rule : [[(M ,F ,(Mcd M )) ∈ TSearch; (N ,F ,(Mcd N )) ∈ TSearch; (n,F ,T ) ` (M ↔N ); (Mcd M )≤ n; (Mcd N )≤ n ]] =⇒ ((M ,N ) ∈ (DSearch F T n)) declare DSearch.intros[intro]

We also need to consider only finitely many frame-theory extensions when matching output transitons. For this reason we create a function that gives us finetely frame-theory extensions of height n. Definition 4.5.10 consts Ext :: nat ⇒ frame ⇒ (theory set) inductive Ext m F intros Ext-rule : [[(F ,T )` OK; ∀ (M ,N )∈ T .(M ,F ,m) ∈ TSearch ∧ (N ,F ,m) ∈ TSearch]] =⇒ T ∈ (Ext m F ) declare Ext.intros[intro]

Before definig the optimized definition of D-Framed bisimulation, we prove separately the monotonicity in the following lemma. Usually the monotonicity is proved in automatic when definig an (co)inductive definition. Isabelle’s definition of monotone is overloaded over all orderings: mono f ⊆ ∀ A B.A ⊆ B −→ f A ⊆ f B

Lemma 4.5.11 (Proving monotonicity) lemma DFramedBisim-mono: A ⊆ B =⇒ (∀ (M ,N ) ∈ (DSearch F T d ). (F , T , P 0[xa:::=M ], Q 0[xa:::=N ]) ∈ A) −→ (∀ (M ,N )∈ (DSearch F T d ). (F , T , P 0[xa:::=M ], Q 0[xa:::=N ]) ∈ B) apply clarify by auto


75

Finally we report the definition of the optimized D-Framed Bisimulation. Definition 4.5.12 consts DFramedBisim :: nat ⇒(frame × theory × Proc × Proc) set coinductive DFramedBisim d intros DFramedBisim-Def : [[F ∈ Finites; T ∈ Finites; ∀ P 0.(P − τ 7−→ (procAgent P 0)) −→ (∃ Q 0.(Q − τ 7−→ (procAgent Q 0)) ∧ (F ,T ,P 0,Q 0) ∈ DFramedBisim d ); ∀ Q 0.(Q − τ 7−→ (procAgent Q 0)) −→ (∃ P 0.(P − τ 7−→ (procAgent P 0)) ∧ (F ,T ,P 0,Q 0) ∈ DFramedBisim d );

∀ P 0 C x . (C ∈ F ) −→ (P − barb(C ) 7−→ (absAgent x P 0)) −→ (∃ Q 0. (Q − barb(C ) 7−→ (absAgent x Q 0)) ∧ (∀ n ∈ Finites. (((card n) ≤ (2 ∗ d )) ∧ (n ] (F ,T ,P ,Q)))−→ (∀ (M ,N ) ∈ (DSearch (F ∪n) T d ). ((F ∪n), T , (P 0[x :::=M ]), (Q 0[x :::=N ])) ∈ DFramedBisim d ))); ∀ Q 0 C x . (C ∈ F ) −→ (Q − barb(C ) 7−→ (absAgent x Q 0)) −→ (∃ P 0. (P − barb(C ) 7−→ (absAgent x P 0)) ∧ (∀ n ∈ Finites. (((card n) ≤ (2 ∗ d )) ∧ (n ] (F ,T ,P ,Q))) −→ (∀ (M ,N ) ∈ (DSearch (F ∪n) T d ).((F ∪n), T ,(P 0[x :::=M ]),( Q 0[x :::=N ])) ∈ DFramedBisim d ))); ∀ P 0 (m::name list) M C . (C ∈ F ) −→ (m ] (F ,T ,P )) −→ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) −→ (∃ Q 0 n N .(n ] (F ,T ,Q)) ∧ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) ∧ (∃ T 0∈ (Ext (max (Mcd M )(Mcd N )) F ).(F ,(T ∪T 0))`(M ↔N )) ∧ (F 0, (T ∪T 0),P 0, Q 0) ∈ DFramedBisim d ); ∀ Q 0 (n:: name list) N C . (C ∈ F ) −→ (n ] (F ,T ,Q)) −→ (Q − cobarb(C ) 7−→ (concAgent (ConcChain n N Q 0))) −→ (∃ P 0 m M .(m ] (F ,T ,P )) ∧ (P − cobarb(C ) 7−→ (concAgent (ConcChain m M P 0))) ∧ (∃ T 0∈ (Ext (max (Mcd M ) (Mcd N )) F ). (F ,(T ∪T 0))`(M ↔N ))∧ (F 0,(T ∪T 0),P 0,Q 0) ∈ DFramedBisim d ) ]] =⇒ (F ,T ,P ,Q) ∈ DFramedBisim d monos DFramedBisim-mono

76


Conclusions In this thesis we have developed a semi automatized environment to check the equivalence of processes. In order to achieve this goal we have formalized the spi calculus (syntax and semantics) in the logic of Isabelle/HOL extended with the nominal datatype package, and we have developed a proof environment for testing the equivalence of spi calculus processes based on the notion of framed bisimulation. The use of the nominal datatype package, gives us a smooth and easy formalization, and the developed proof environment is quite close to the traditional manual proofs present in the literature. Moreover with the release of the version 0.05 of the nominal package, we are able to define functions using the recursive combinator of the nominal datatypes. We have given some optimizations in the procedure of proving bisimilarities, by adopting in Isabelle some techniques from the algorithm developed by H.H¨ uttel in [Hut02]. The introduced optimizations are aimed to “help” the proof search of the already implemented tactics in Isabelle.

C.1

Future Work

In this section we list some of the work that can be done in the future.

C.1.1

Further improvements

In our work we have made some optimization in the definition of d-framed bisimulation. A good improvement can be achieved by developing a new tactic that implements the definition that we provided in our work for the d-framed bisimulation. Thus, the tactic can be used to check, whenever necessary the equivalence of spi calculus processes.

C.1.2

Symbolic Bisimulation in Isabelle-Spi

The interest in bisimulation notions for the spi calculus follows the fact that bisimilarity is sound, although not complete, approximation to the may-testing equivalence. Environment sensitive bisimulation has been developed for the spi calculus, in various styles [BN02]. In this thesis we have used the notion of framed bisimulation

78

Conclusions

due to its relative simplicity comparing to other definition of bisimulation, and also because a concrete algorithm is provided; albeit not efficient. Experiments showed that the algorithm developed in [Hut02] for the decidability of bisimilarity is not practically implementable; for example it generates 22

20

branches for each input of the Wide-mouthed Frog protocol. Other notion of bisimulation proposed for spi calculus are: Boreale et al. (1999) introduced a notion under the generic name of environment-

sensitive bisimulation. Here, each of the processes in a bisimulation pair is accompanied by an environment, which (roughly) lists the messages received from the process in the past. To express the identification of nondistinguishable data items, an explicit condition of equivalence on the environments is imposed. Elkjær et al. (1999) introduced fenced bisimulation, an approximation to

framed bisimulation by getting rid of one of its infinitary quantifications. Borgstr¨ om et al.(2002) introduced hedged bisimulation; the basic idea of hedges

is to mimic the lack of correspondence in frame-theory pairs by droppoing the separate frame component, but to include corresponding names as part of the theory [BN02]. All the above notions of bisimulations are, assuming that the observing environments know all free names of the related processes, sound approximations of may-testing equivalence. Another notion of bisimulation was proposed in [BBN04], which is symbolic bisimulation. Here, the elements of a bisimulation consist of a process pair and an environment; the latter captures the knowledge that an attacker has acquired in previous interactions with the process pair. For this definition, hedged bisimulation is a good starting point since it offers a compact and clear knowledge representation. Symbolic bisimulation is intended to enable automatic verification, while still being sufficiently complete with respect to the concrete bisimulation for the purpose of verifying security protocols. A symbolic environment contains a hedge to hold the initial knowledge of an environment and the knowledge derived from messages recivied form the processes. In a second hedge, is stored the input variables that we come across when performing process inputs. Also, all the transitions constraints accumulated by the processes are recorded. Finally, to know whether an input was

Future Work

79

performed before or after the environment learned a given message (e.g., the key of an encrypted message) the knowledge and the input variables are augumented with timing information. In [BBN04], the authors conclude with the project of implementing an algorithm for the symbolic bisimilarity, that has a mechanizable (efficiently computable) ways to perform equivalence checking. A future work can be done by formalizing the symbolic bisimulation in Isabelle, using the same techniques adopted in this thesis.

C.1.3

Integration with a model checker

Our idea of integrating the Isabelle-spi calculus environment with a model checker, is to follow the work done in [Nam01] and in [YL97]. The possible way of integrating our model with a model checker, is described in Figure. As we said in the introduction of this work, model checkers produce only the answer “yes”!, if it is determined that a property holds. This does not insipire the same confidence as a counterexample, produced when the property does not hold.

Figure C.1: Possible integration with a model checker It seems obvious to provide a mechanism that generates certficates for either outcome of the model checking process. These certificates can be then checked by Isabelle. Therefore, the key idea is to have a certifying model checker that produce a proof script of property f upon success and a proof script for ¬f on failure [Nam01]. Both types of proofs offer insight on why the property succeeds (or fails) to hold of the program. Inspecting success proofs closely may help uncover vacuous justifications or lack of appropriate coverage. The inspection part, can be done by importing the “certificate” given by the model checker, to Isabelle. In case of failure, the generated proof ¬f is a compact representation of all counterexample computations. This proof can be “unfolded” interactively using

80

Conclusions

Isabelle, and this provide a better understanding of the flaws in the program. We can follow the method used in [Nam01], to make a given model checker to produce a deductive proof. The idea is to make some extra book-keeping, and this is done by storing and anlyzing sets of states that are generated by the fixpoint computations performed during model checking run. The produced deductive proof, in order to be inspected by Isabelle; should be a “script” modeled in the logic of Isabelle (in C.1 we call it Isabelle script). Moreover a tecnique shuold be adpoted to transform the usual bisimulation checking formulae (w.r.t P ≈ Q), into a syntax understandable by the model checker (M, s p).

A Appendix In proposition A.0.1 we prove that ({c, n}, ) ` OK.

Proposition A.0.1 lemma proposition2 : fixes c :: name and l :: name shows ({c,l },{})` OK proof − show ?thesis by(simp add :Ok-def Ok1-def Ok2-def ) qed

Example A.0.2 lemma example1 : fixes M :: trm and M 0 :: trm and K :: name and c :: name and P :: Proc and Q :: Proc and l :: name and F :: frame and F 0 :: frame and T :: theory and T 0 :: theory assumes A1 : (♣ M ) and A2 : (♣ M 0) and A3 : ({c,l },{}) ` OK

shows ({c,l },{},(hν(K )i((Name c).PNil )), (hν(K )i((Name c).PNil ))) ∈ FramedBisim (is ?x ∈ -)

82

A. Appendix

proof − have ?x : {?x } by blast then show ?thesis proof coinduct case (FramedBisim x ) have ?FramedBisim-Def proof − from FramedBisim have x = ?x by simp moreover { fix P 0 assume (hν(K )i((Name c).PNil )) − τ 7−→ (procAgent P 0) then have ∃ Q 0. (hν(K )i((Name c).PNil )) − τ 7−→ (procAgent 0 Q)∧ (P 0= (hν(K )i((Name c).PNil )) ∧ Q 0 = (hν(K )i((Name c).PNil )) ∨ ({c, l }, {}, P 0, Q 0) ∈ FramedBisim) apply cases apply auto apply(ind-cases (hν(K )i((Name c).PNil )) B Qa ) done } moreover { fix Q 0 assume (hν(K )i((Name c).PNil )) − τ 7−→ (procAgent Q 0) then have ∃ P 0. (hν(K )i((Name c).PNil )) − τ 7−→ (procAgent 0 P)∧ (P 0= (hν(K )i((Name c).PNil )) ∧ Q 0 = (hν(K )i((Name c).PNil )) ∨ ({c, l }, {}, P 0, Q 0) ∈ FramedBisim) apply cases apply auto apply(ind-cases (hν(K )i((Name c).PNil )) B Qa ) done } moreover { fix P 0 C x assume (C ∈ F ) ∧ (hν(K )i((Name c).PNil )) − barb(C ) 7−→ (absAgent x P 0) then have (∃ Q 0. Q − barbC 7−→ absAgent x Q 0 ∧ (∀ Ma N n. (♣Ma) ∧ (♣N ) ∧ n ] (F , T , P , Q) −→ ((F ∪ n),T ) ` (Ma↔N ) −→ (F ∪ n, T , P 0[x :::=Ma], Q 0[x :::=N ]) ∈ {({c, l }, {}, hνK iName c.PNil , hνK iName c.PNil )} ∪ FramedBisim)) apply cases apply auto apply(ind-cases Proc.res K (Proc.out-barb (trm.Name v ) (trm.Sk-enc (trm.Name K ) M 0) Proc.Pnil ) − Barb.Inbarb C 7−→ Agent.absAgent xa Q) apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M ) Proc.Pnil ) B Q) done } moreover { fix Q 0 C x assume (C ∈ F ) ∧ (hν(K )i((Name c).PNil )) − barb(C ) 7−→

83

(absAgent x Q 0) then have

(∃ P 0. P − barbC 7−→ absAgent x P 0 ∧ (∀ Ma N n. (♣Ma) ∧ (♣N ) ∧ n ] (F , T , P , Q) −→ ((F ∪ n),T ) ` (Ma↔N ) −→ (F ∪ n, T , P 0[x :::=Ma], Q 0[x :::=N ]) ∈ {({c, l }, {}, hνK iName c.PNil , hνK iName c.PNil )} ∪ FramedBisim)) apply cases apply auto apply(ind-cases Proc.res K (Proc.out-barb (trm.Name v ) (trm.Sk-enc (trm.Name K ) M ) Proc.Pnil ) − Barb.Inbarb C 7−→ Agent.absAgent xa P 0) apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M 0) Proc.Pnil ) B P ) done } moreover { fix P 0 C m Ma assume (C ∈ F ) ∧ (m ] (F , T , P )) ∧ (hν(K )i((Name c).PNil )) − cobarb(C ) 7−→ concAgent (ConcChain m Ma P 0) then have (∃ Q 0 n N . n ] (F , T , Q) ∧ Q − cobarbC 7−→ concAgent (ConcChain n N Q 0) ∧ (∃ F 0 T 0. ((F ,T ) . (F 0,T 0) ∧ (F ,T ) ` (Ma↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ {({c, l }, {}, hνK iName c.PNil , hνK iName c.PNil )} ∪ FramedBisim)) apply cases apply auto apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M 0) Proc.Pnil ) − Barb.Cobarb C 7−→ Agent.concAgent (ConcChain n N Q 0)) apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M ) Proc.Pnil ) B Qa) done } moreover { fix Q 0 C n N assume (C ∈ F ) ∧ (n ] (F , T , Q)) ∧ (hν(K )i((Name c).PNil )) − cobarb(C ) 7−→ concAgent (ConcChain n N Q 0) then have (∃ P 0 m Ma. m ] (F , T , P ) ∧ P − cobarbC 7−→ concAgent (ConcChain m Ma P 0) ∧ (∃ F 0 T 0. ((F ,T ) . (F 0,T 0) ∧ (F ,T ) ` (Ma↔N ) ) ∧ (F 0, T 0, P 0, Q 0) ∈ {({c, l }, {}, hνK iName c.PNil , hνK iName c.PNil )} ∪ FramedBisim)) apply cases apply auto apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M ) Proc.Pnil ) − Barb.Cobarb C 7−→ Agent.concAgent (ConcChain m Ma P 0) ) apply(ind-cases Proc.res K (Proc.out-barb (trm.Name c) (trm.Sk-enc (trm.Name K ) M 0) Proc.Pnil ) B Qa) done } ultimately show ?thesis by simp qed

84

then show ?case by blast qed qed

A. Appendix

Bibliography [AG98]

Mart´ın Abadi and Andrew D. Gordon. A bisimulation method for cryptographic protocols. Nord. J. Comput., 5(4):267–, 1998. 3, 5, 10, 21, 26, 69

[AG99]

Mart´ın Abadi and Andrew D. Gordon. A calculus for cryptographic protocols: The spi calculus. Inf. Comput., 148(1):1–70, 1999. 3, 5, 10, 13, 26

[AL00]

Roberto M. Amadio and Denis Lugiez. On the reachability problem in cryptographic protocols. Lecture Notes in Computer Science, 1877:380+, 2000. 31

[Asp00]

David Aspinall. Proof general: A generic tool for proof development http://proofgeneral.inf.ed.ac.uk/, 2000. 34, 46

[BB96]

Janet Bertot and Yves Bertot. CtCoq: A system presentation. In Michael McRobbie and John Slaney, editors, Automatic Deduction, CADE-13, volume 1104 of LNAI, pages 231–234. Springer-Verlag, 1996. 5

[BBN04] Johannes Borgström, Sébastien Briais, and Uwe Nestmann. Symbolic bisimulation in the spi calculus. In CONCUR, pages 161–176, 2004. 78, 79 [Ben]

Jesper Bengtson. Modelling the pi-calculus in isabelle using nominal logic. http://www.it.uu.se/katalog/jesperb/pi.html. 49

[BFS95]

Ramesh Bharadwaj, Amy P. Felty, and Frank A. Stomp. Formalizing inductive proofs of network algorithms. In ASIAN, pages 335–349, 1995. 9

[BN02]

J. Borgstrom and U. Nestmann. On bisimulation in the spi calculus, 2002. 77, 78

[CGL94] Edmund M. Clarke, Orna Grumberg, and David E. Long. Model checking and abstraction. ACM Transactions on Programming Languages and Systems, 16(5):1512–1542, September 1994. 3, 4

86

[DF95]

Bibliography

J¨ urgen Dingel and Thomas Filkorn. Model checking for infinite state systems using data abstraction, assumption-commitment style reasoning and theorem proving. In CAV, pages 54–69, 1995. 9

[Gri00]

W. O. D. Griffioen. Studies in Computer Aided Verification of Protocols. PhD thesis, 2000. 1

[Hut02]

H. Huttel. Deciding framed bisimilarity, 2002. 3, 6, iii, 10, 11, 26, 31, 32, 70, 77, 78

[Jon95]

Cliff B. Jones. Recent books on formal methods. Technical report, Department of Computer Science, 1995. 33

[Lin98]

H. Lin. Complete proof systems for observation congruences in finitecontrol π-calculus. Lecture Notes in Computer Science, 1443:443+, 1998. 27

[MN95]

Olaf M¨ uller and Tobias Nipkow. Combining model checking and deduction for i/o-automata. In TACAS, pages 1–16, 1995. 9

[MPW92] Robin Milner, Joachim Parrow, and David Walker. A calculus of mobile processes. Inform. and Comput., 100(1):1–77, 1992. 13 [Nam01]

Kedar S. Namjoshi. Certifying model checkers. Lecture Notes in Computer Science, 2102:2–??, 2001. 79, 80

[NH84]

Rocco De Nicola and Matthew Hennessy. Testing equivalences for processes. Theor. Comput. Sci., 34:83–133, 1984. 21

[NP92]

Tobias Nipkow and Lawrence C. Paulson. Isabelle-91. In D. Kapur, editor, Proc. of the 11th CADE, volume 607 of Lecture Notes in Computer Science, pages 673–676, Saratoga Springs, NY, 1992. Springer-Verlag. System abstract. 3, 6, 33, 34

[Pau87]

Lawrence C. Paulson. Logic and Computation: interactive proof with Cambridge LCF. Cambridge University Press, 1987. 6

[Pau00]

Lawrence C. Paulson.

A fixedpoint approach to (co)inductive and

(co)datatype definitions. In Gordon Plotkin, Colin Stirling, and Mads Tofte, editors, Proof, Language, and Interaction: Essays in Honour of Robin Milner, pages 187–211. MIT Press, 2000. 37

Bibliography

[Pfe]

Frank

87

Pfenning.

Isabelle

bibliography:

http://www.cl.cam.ac.uk/research/hvg/isabelle/biblio.html.

6,

33,

34 [Pit03]

Andrew M. Pitts. Nominal logic, a first order theory of names and binding. Inf. Comput., 186(2):165–193, 2003. 7, 42

[P.W]

P.Wolper. The algorithmic verification of reactive systems. 1

[RSS95]

S. Rajan, N. Shankar, and M.K. Srivas. An integration of model-checking with automated proof checking. In Pierre Wolper, editor, Computer-Aided Verification, CAV ’95, volume 939 of Lecture Notes in Computer Science, pages 84–97, Liege, Belgium, 1995. Springer-Verlag. 9

[SOR93]

N. Shankar, S. Owre, and J. M. Rushby. PVS Tutorial. Computer Science Laboratory, SRI International, Menlo Park, CA, February 1993. Also appears in Tutorial Notes, Formal Methods Europe ’93: Industrial-Strength Formal Methods, pages 357–406, Odense, Denmark, April 1993. 7

[Spr98]

Christoph Sprenger. A verified model checker for the modal -calculus in coq. In TACAS, pages 167–183, 1998. 9

[SW01]

Davide Sangiorgi and David Walker. The π-calculus: a Theory of Mobile Processes. Cambridge Universtity Press, 2001. 3

[Uri00]

Tomas E. Uribe. Combinations of model checking and theorem proving. In Frontiers of Combining Systems, pages 151–170, 2000. 2

[UT05]

Christian Urban and Christine Tasson.

Nominal techniques in is-

abelle/hol. In CADE, pages 38–53, 2005. 3, 5, 7, 10, 42, 49 [Wen99]

Markus Wenzel. Isar - a generic interpretative approach to readable formal proof documents. In Theorem Proving in Higher Order Logics, pages 167–184, 1999. 7, 33, 39, 40, 41, 42, 49

[YL97]

Shenwei Yu and Zhaohui Luo. Implementing a model checker for LEGO. In John Fitzgerald, Cliff B. Jones, and Peter Lucas, editors, FME’97: Industrial Applications and Strengthened Foundations of Formal Methods (Proc. 4th Intl. Symposium of Formal Methods Europe, Graz, Austria, September 1997), volume 1313, pages 442–458. Springer-Verlag, 1997. 79

Towards semi automated equivalence checking of spi calculus

Towards semi automated equivalence checking of spi calculus

Suggest Documents

Towards the semi-automated extraction of ...

Towards automated requirements checking throughout development ...

Towards automated software model checking using graph

Implementing Spi Calculus Using Nominal

Semi-automated fact-checking of nucleotide sequence ... - PLOS

Towards Semi-Automated Annotation for Prepositional Phrase

Towards Equivalence Checking Between TLM and ... - ePrints Soton

Towards Automated Bounded Model Checking of API Implementations.

Towards Automated Bounded Model Checking of API Implementations.

Equivalence Checking of Combinational Circuits using Boolean

On Equivalence Checking of Nondeterministic Finite Automata

Checking Semantics Equivalence of MDA ... - Semantic Scholar

Equivalence Checking of Reversible Circuits - informatik.uni-bremen.de

A Calculus for Cryptographic Protocols The Spi Calculus

PATH BASED EQUIVALENCE CHECKING OF PETRI ...

Equivalence Checking of Partial Designs Using Dependency

Applying Spi-calculus for PayWord - Semantic Scholar

Checking Equivalence for Reo Networks www.researchgate.net › publication › fulltext › Checking-

SPI™ SPI™

Topological elementary equivalence of closed semi ... - CiteSeerX

Equivalence Checking for Compiler Transformations in Behavioral

Equivalence Checking for Behaviorally Synthesized Pipelines

Distributed On-the-Fly Equivalence Checking

Fast Equivalence-checking for Quantum Circuits