Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Model Checking Lecture 1.
Model Checking Lecture 2. Three important decisions when choosing system properties: 1automata vs. logic 2branching vs. linear time 3safety vs. liveness.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
1 How to transform an analyzer into a verifier. 2 OUTLINE OF THE LECTURE a verification technique which combines abstract interpretation and Park’s fixpoint.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
January 7, 2015CS21 Lecture 21 CS21 Decidability and Tractability Lecture 2 January 7, 2015.
August Moscow meeting1August Moscow meeting1August Moscow meeting11 Deductive tools in insertion modeling verification A.Letichevsky.
Lecture 4 1 Expressing Security Properties in CSP Security properties: the goals that a protocol is meant to satisfy, relatively to specific kinds and.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
1 Flexible Subtyping Relations for Component- Oriented Formalisms and their Verification David Hurzeler PhD Examination, 9/11/2004.
A Semantic Characterization of Unbounded-Nondeterministic Abstract State Machines Andreas Glausch and Wolfgang Reisig 1.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 1 Temporal Logic Formal Specifications CS Shmuel Katz The Technion.
1 Basic abstract interpretation theory. 2 The general idea §a semantics l any definition style, from a denotational definition to a detailed interpreter.
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Embedded Systems Laboratory Department of Computer and Information Science Linköping University Sweden Formal Verification and Model Checking Traian Pop.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
Abstract Verification is traditionally done by determining the truth of a temporal formula (the specification) with respect to a timed transition system.
Verification technique on SA applications using Incremental Model Checking 컴퓨터학과 신영주.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
1 Unit 1: Automata Theory and Formal Languages Readings 1, 2.2, 2.3.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
Introduction to CS Theory Lecture 3 – Regular Languages Piotr Faliszewski
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
Sequences – Page 1CSCI 1900 – Discrete Structures CSCI 1900 Discrete Structures Sequences Reading: Kolman, Section 1.3.
Reactive systems – general
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
A Quick Math Overview (not the last one!) Section 1.4, you should it read carefully! Reading the corresponding material from the book is strongly encouraged.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
CS6133 Software Specification and Verification
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CSCI1600: Embedded and Real Time Software Lecture 28: Verification I Steven Reiss, Fall 2015.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
Model Checking Lecture 1: Specification Tom Henzinger.
IS 2620: Developing Secure Systems Formal Verification/Methods Lecture 9 March 15, 2012.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
Model Checking Lecture 2 Tom Henzinger. Model-Checking Problem I |= S System modelSystem property.
Introduction to Formal Methods
ISA 763 Security Protocol Verification
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
CSCI1600: Embedded and Real Time Software
IS 2935: Developing Secure Systems
Protocol Verification by the Inductive Method
Formal Methods in software development
Formal Methods in software development
CSCI1600: Embedded and Real Time Software
CS21 Decidability and Tractability
Formal Methods in software development
Translating Linear Temporal Logic into Büchi Automata
Introduction to verification
Protocol Verification by the Inductive Method
COP4020 Programming Languages
Presentation transcript:

Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving Safe simplifying transformations

Lecture 5 2 The Casper interface Casper is essentially a compiler protocol CSP code Casper Language similar to the one used to describe the protocols seen so far intruder system Written in the functional Programming language Haskell

Lecture 5 3 Refinement checking and FDR Specification Implementation Refinement Specification An abstract description of the protocol, where properties are easy to check Refinement A transformation preserving the properties Usually this means that the implementation must be less nondeterministic than the specification. Question: why? Implementation A formal description of the real system and its components Answer: the properties usually are universal: they must be valid in all runs

Lecture 5 4 Refinement checking and FDR The notion of refinement The implementation should be a refinement of the specification, in the sense of preserving its properties. Hence, less nondeterministic Refinement checking: checking that the implementation is indeed a refinement of the specification Obviously, the notion of refinement depends on the intended semantic. In CSP traditionally we consider 3 kinds of semantics: Traces Failures Failures and Divergences

Lecture 5 5 Refinement checking and FDR Traces The set of the sequences of visible actions in all possible runs Example: A = a -> b -> c -> Stop [] b -> c -> a -> Stop Tr(A) = { a.b.c, b.c.a } B = a -> Stop ||| b -> c -> Stop Tr(A) = { a.b.c, b.a.c, b.c.a } Note that A is less nondeterministic than B: A represents only a subset of the possible runs of B

Lecture 5 6 Refinement checking and FDR We want to define formally the notion of refinement wrt trace semantics, in such a way that it captures the concept of “less nondeterministic”. Question: what should be the formal definition of “A is a refinement of B” in terms of their traces? Answer: Tr(A) is a subset of Tr(B) B A Refinement Tr(A) Tr(B)

Lecture 5 7 Refinement checking and FDR Limits of trace semantics: It is not compositional. Namely, trace refinement is not preserved under contexts. This means that the analysis based on traces cannot be performed modularly: it must be performed on the whole system at once. Example A = a -> (b -> Stop [] c -> Stop) B = a -> Stop [] a -> c -> Stop a c b aa bc Tr(A) = Tr(B) = { a.b, a.c} Context C = a -> b -> Stop Tr(C || A) = {a.b} =/= Tr(C || B) = {a.b, a} AB

Lecture 5 8 Stronger, compositional semantics Failures: this semantics encodes the brancing structure of a process by representing, after each partial trace, the set of actions that are not allowed Example: The notion of refinement is defined in such a way that A is a refinement of B, but not vice versa This notion of refinement is preserved under closure on possible contexts Refinement checking and FDR a c b aa bc F(A) = {, … } =/= F(B) = {,, … } AB

Lecture 5 9 Refinement checking and FDR Stronger, compositional semantics Failures and Divergences: This semantics encodes all the information of Failure semantics, plus additional information about divergences (livelocks). As such, it is suitable also for the analysis of liveness properties (not only safety) Example: It is considered the standard model of CSP FDR means: Failure and Divergences Refinement Automatic refinement check for finite state systems (they can have infinite computations, but the number of states is finite) a  a These two processes Have the same failures but different divergences

Lecture 5 10 Model checking Model checking basics The security property we want to verify is expressed as a temporal logic formula F The protocol is expressed as a system S of processes (the processes involved with the protocol and, possibly, the intruder) S is represented as a labeled transition system T, which is seen as an interpretation of F Model checking consists in showing that T is a model of F, namely that T validates F Always possible with Finite State systems Also possible for some restricted cases of Infinite State systems

Lecture 5 11 Model checking Example A = a -> b -> A B = c -> d -> B S = A ||| B Temporal operators: F : forever E : eventually Some formulae F E (a or c) F E a E F (a or c) A = a -> A1 A1 = b -> A B = c -> B1 B1 = d -> B S = A ||| B S1 = A ||| B1 S2 = A1 ||| B S3 = A1 ||| B1 S S2 S1 S3 c c a a d b b d True False

Lecture 5 12 Theorem proving Based on a set of inference rules that model a satisfiability relation S sat P Example: parallel rule Forall i. (S i sat (R precedes T)) (||| i S i ) sat (R precedes T) Properties of the inference system: Semiautomatic (invariant needed for recursive definitions) Sound and relatively complete All the properties of the Yahalom protocol seen in previous lecture can be easily verified using this system (see proofs in the book of Ryan and Schneider)