Hyperproperties Michael Clarkson and Fred B. Schneider Cornell University Ph.D. Seminar Northeastern University October 14, 2010.

Slides:



Advertisements
Similar presentations
Model Checking Lecture 1.
Advertisements

Part 3: Safety and liveness
Program correctness The State-transition model A global state S  s 0 x s 1 x … x s m {s k = local state of process k} S0  S1  S2  … Each state transition.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Verification of Graph Transformation Systems Arman Sheikholeslami
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Hyperproperties Michael Clarkson and Fred B. Schneider Cornell University IEEE Symposium on Computer Security Foundations June 23, 2008 TexPoint fonts.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Possibilistic and probabilistic abstraction-based model checking Michael Huth Computing Imperial College London, United Kingdom.
Ashish Kundu CS590F Purdue 02/12/07 Language-Based Information Flow Security Andrei Sabelfield, Andrew C. Myers Presentation: Ashish Kundu
ISBN Chapter 3 Describing Syntax and Semantics.
Safety and Liveness. Defining Programs Variables with respective domain –State space of the program Program actions –Guarded commands Program computation.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Tele Design of Reactive Systems Summer 2001 Prof. Dr. Stefan Leue Institute for Computer Science Albert-Ludwigs-Universität Freiburg
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
© Katz, 2007CS Formal SpecificationsLecture - Temporal logic 1 Temporal Logic Formal Specifications CS Shmuel Katz The Technion.
Ordering and Consistent Cuts Presented By Biswanath Panda.
Programming Language Semantics Denotational Semantics Chapter 5 Based on a lecture by Martin Abadi.
Information Flow, Security and Programming Languages Steve Steve Zdancewic.
1 Enforcing Confidentiality in Low-level Programs Andrew Myers Cornell University.
CS294, YelickConsensus, p1 CS Consensus
CS 711 Fall 2002 Programming Languages Seminar Andrew Myers 2. Noninterference 4 Sept 2002.
Describing Syntax and Semantics
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Programming Language Semantics Denotational Semantics Chapter 5 Part III Based on a lecture by Martin Abadi.
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
1 September 14, 2006 Lecture 3 IS 2150 / TEL 2810 Introduction to Security.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 3 (26/01/2006) Instructor: Haifeng YU.
On Reducing the Global State Graph for Verification of Distributed Computations Vijay K. Garg, Arindam Chakraborty Parallel and Distributed Systems Laboratory.
Defining Programs, Specifications, fault-tolerance, etc.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Agenda for a Science of Security Fred B. Schneider* Department of Computer Science Cornell University Ithaca, New York U.S.A.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Hyperproperties Michael Clarkson and Fred B. Schneider Cornell University Air Force Office of Scientific Research December 4, 2008 TexPoint fonts used.
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
Recognizing safety and liveness Presented by Qian Huang.
Network Protocols Network Systems Security Mort Anvari.
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
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.
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
Safety and Liveness. Recall Program –State space Program computation –Of the form Consider the set of all program computations.
Hyperproperties Michael Clarkson George Washington University
Chapter 8 Asynchronous System Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
Quantification of Integrity Michael Clarkson and Fred B. Schneider Cornell University IEEE Computer Security Foundations Symposium July 17, 2010.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
CS426Fall 2010/Lecture 211 Computer Security CS 426 Lecture 21 The Bell LaPadula Model.
Model Checking Lecture 1. Model checking, narrowly interpreted: Decision procedures for checking if a given Kripke structure is a model for a given formula.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Quantification of Integrity Michael Clarkson and Fred B. Schneider Cornell University RADICAL May 10, 2010.
Belief in Information Flow Michael Clarkson, Andrew Myers, Fred B. Schneider Cornell University 18 th IEEE Computer Security Foundations Workshop June.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Model Checking Lecture 1: Specification Tom Henzinger.
Agenda  Quick Review  Finish Introduction  Java Threads.
Introduction to distributed systems description relation to practice variables and communication primitives instructions states, actions and programs synchrony.
Model Checking Lecture 2. Model-Checking Problem I |= S System modelSystem property.
1 Jay Ligatti (Princeton University); joint work with: Lujo Bauer (Carnegie Mellon University), David Walker (Princeton University) Enforcing Non-safety.
Opeoluwa Matthews, Jesse Bingham, Daniel Sorin
ISA 763 Security Protocol Verification
Quantification of Integrity
Information Security CS 526
Enforcing Non-safety Security Policies with Program Monitors
ITEC452 Distributed Computing Lecture 5 Program Correctness
Recognizing Safety and Liveness
Information Security CS 526
Linear Time Properties
Information Security CS 526
Carmine Abate Rob Blanco Deepak Garg Cătălin Hrițcu Jérémy Thibault
Presentation transcript:

Hyperproperties Michael Clarkson and Fred B. Schneider Cornell University Ph.D. Seminar Northeastern University October 14, 2010

2 Security Policies Today  Confidentiality “Protection of assets from unauthorized disclosure”  Integrity “Protection of assets from unauthorized modification”  Availability “Protection of assets from loss of use” Formalize and verify any security policy? 

3 Program Correctness ca. 1970s  Partial correctness (If program terminates, it produces correct output)  Termination  Total correctness (Program terminates and produces correct output)  Mutual exclusion  Deadlock freedom  Starvation freedom ???

4 Safety and Liveness Properties Intuition [Lamport 1977]: Safety: “Nothing bad happens” Liveness: “Something good happens”  Partial correctness Bad thing: program terminates with incorrect output  Access control Bad thing: subject completes operation without required rights  Termination Good thing: termination  Guaranteed service Good thing: service rendered

5 Properties Trace: Sequence of execution states t = s 0 s 1 … Property: Set of infinite traces Trace t satisfies property P iff t is an element of P  Satisfaction depends on the trace alone System: Also a set of traces System S satisfies property P iff all traces of S satisfy P

6 Properties Property P System S = trace

7 Properties Property P System S S satisfies P = trace

8 Properties Property P System S S does not satisfy P = trace

9 Safety and Liveness Properties Formalized: Safety property [Lamport 1985] Bad thing = trace prefix Liveness property [Alpern and Schneider 1985] Good thing = trace suffix

10 Success! Alpern and Schneider (1985, 1987): Theorem. Every property is the intersection of a safety property and a liveness property. Theorem. Safety proved by invariance. Theorem. Liveness proved by well-foundedness. Theorem. Topological characterization: Safety = closed sets Liveness = dense sets Formalize and verify any property? 

11 Back to Security Policies Formalize and verify any property? Formalize and verify any security policy?   Security policy = Property ?

12 Information Flow is not a Property Secure information flow: Secret inputs are not leaked to public outputs   p := 1; p := s; if (s) then p := 1 else p := 0; if (s) then {consume power} else {don’t};  

13 Information Flow is not a Property Secure information flow: Secret inputs are not leaked to public outputs secret public 

14 Information Flow is not a Property Noninterference [Goguen and Meseguer 1982]: Commands of high security users have no effect on observations of low security users Not safety! Satisfaction depends on pairs of traces …so not a property t1:t1: t2:t2:

15 Service Level Agreements are not Properties Service level agreement: Acceptable performance of system Not liveness! Average response time: Average time, over all executions, to respond to request has given bound Satisfaction depends on all traces of system …not a property Any security policy that stipulates relations among traces is not a property  Need satisfaction to depend on sets of traces

16 Hyperproperties A hyperproperty is a set of properties A system S satisfies a hyperproperty H iff S is an element of H …a hyperproperty specifies exactly the allowed sets of traces

17 Hyperproperties Hyperproperty H System S S does not satisfy H = trace

18 Hyperproperties Hyperproperty H System S S satisfies H = trace

19 Hyperproperties Security policies are hyperproperties! Information flow: Noninterference, relational noninterference, generalized noninterference, observational determinism, self-bisimilarity, probabilistic noninterference, quantitative leakage Service-level agreements: Average response time, time service factor, percentage uptime …

20 Hyperproperties  Safety and liveness?  Verification?

21 Safety Safety proscribes “bad things” A bad thing is finitely observable and irremediable S is a safety property [L85] iff b is a finite trace

22 Safety Safety proscribes “bad things” A bad thing is finitely observable and irremediable S is a safety property [L85] iff b is a finite trace

23 Safety Safety proscribes “bad things” A bad thing is finitely observable and irremediable S is a safety property [L85] iff S is a safety hyperproperty (“hypersafety”) iff B is a finite set of finite traces b is a finite trace

24 Prefix Ordering An observation is a finite set of finite traces Intuition: Observer sees a set of partial executions M ≤ T (M is a prefix of T ) iff: M is an observation, and If observer watched longer, M could become T

25 Safety Hyperproperties Noninterference [Goguen and Meseguer 1982] Bad thing is a pair of traces where removing high commands does change low observations Observational determinism [Roscoe 1995] Bad thing is a pair of traces that cause system to look nondeterministic to low observer …

26 Liveness Liveness prescribes “good things” A good thing is always possible and possibly infinite L is a liveness property [AS85] iff t is a finite trace

27 Liveness Liveness prescribes “good things” A good thing is always possible and possibly infinite L is a liveness property [AS85] iff L is a liveness hyperproperty (“hyperliveness”) iff t is a finite trace T is a finite set of finite traces

28 Liveness Hyperproperties Average response time Good thing is that average time is low enough Possibilistic information flow Class of policies requiring “alternate possible explanations” to exist e.g. generalized noninterference [McCullough 1987] Theorem. All PIF policies are hyperliveness.

29 Can lift property T to hyperproperty [ T ] Satisfaction is equivalent iff [ T ] = powerset( T ) Theorem. S is safety implies [ S ] is hypersafety. Theorem. L is liveness implies [ L ] is hyperliveness. … Verification techniques for safety and liveness now carry forward to hyperproperties Relating Properties and Hyperproperties

30 Safety and Liveness is a Basis (still) Theorem. Every hyperproperty is the intersection of a safety hyperproperty and a liveness hyperproperty. A fundamental basis…

31 Topology Open set: Can always “wiggle” from point and stay in set Closed set: “Wiggle” might move outside set Dense set: Can always “wiggle” to get into set open closed dense

32 Topology of Hyperproperties For Plotkin topology on properties [AS85]: Safety = closed sets Liveness = dense sets Theorem. Hypersafety = closed sets. Theorem. Hyperliveness = dense sets. Theorem. Our topology on hyperproperties is equivalent to the lower Vietoris construction applied to the Plotkin topology.

33 Stepping Back…  Safety and liveness?  Verification? 

34 Verification of 2-Safety 2-safety [Terauchi and Aiken 2005]: “Property that can be refuted by observing two finite traces” Methodology: Transform system with self-composition construction [Barthe, D’Argenio, and Rezk 2004] Verify safety property of transformed system  Implies 2-safety property of original system …Reduction from hyperproperty to property

35 A k-safety hyperproperty is a safety hyperproperty in which the bad thing never has more than k traces Examples: 1-hypersafety: the lifted safety properties 2-hypersafety: Terauchi and Aiken’s 2-safety properties k-hypersafety: SEC ( k ) = “System can’t, across all runs, output all shares of a k -secret sharing” Not k-hypersafety for any k: SEC =  k SEC ( k ) k-Safety Hyperproperties

36 Verifying k-Hypersafety Theorem. Any k-safety hyperproperty of S is equivalent to a safety property of S k.  Yields methodology for k -hypersafety Incomplete for hypersafety Hyperliveness? In general?

37 Logic and Verification Polices are predicates …but in what logic? Second-order logic suffices, first-order logic does not. Verify second-order logic? Can’t! (effectively and completely) Can for fragments …might suffice for security policies

38 Refinement Revisited Stepwise refinement: Development methodology for properties  Start with specification and high-level (abstract) program  Repeatedly refine program to lower-level (concrete) program Techniques for refinement well-developed Long-known those techniques don’t work for security policies—i.e., hyperproperties Develop new techniques? Reuse known techniques?

39 Refinement Revisited Theorem. Known techniques work with all hyperproperties that are subset-closed. Theorem. All safety hyperproperties are subset- closed.  Stepwise refinement applicable with hypersafety Hyperliveness? In general?

40 Beyond Hyperproperties?  Security policies are predicates on systems  Hyperproperties are the extensions of those predicates  Hyperproperties are expressively complete (for predicates, systems, and trace semantics)

Other System Models  Relational semantics  Labeled transition systems  State machines  Probabilistic systems …can define hyperproperties for all these 41

42 Probabilistic Hyperproperties To incorporate probability: Assume probability on state transitions Construct probability measure on traces [Halpern 2003] Use measure to express hyperproperties We’ve expressed: Probabilistic noninterference [Gray and Syverson 1998] Quantitative leakage Channel capacity

43 Summary We developed a theory of hyperproperties Parallels theory of properties  Safety, liveness (basis, topological characterization)  Verification (for k -hypersafety)  Stepwise refinement (hypersafety) Expressive completeness Enables classification of security policies…

44 Charting the landscape…

45 All hyperproperties ( HP ) HP

46 HP SHPLHP Safety hyperproperties ( SHP ) Liveness hyperproperties ( LHP )

47 HP SHPLHP [SP][LP] Lifted safety properties [SP] Lifted liveness properties [LP]

48 HP SHPLHP [SP][LP] ACGS Access control ( AC ) is safety Guaranteed service ( GS ) is liveness

49 HP SHPLHP [SP][LP] ACGS GMNI Goguen and Meseguer’s noninterference ( GMNI ) is hypersafety

50 HP SHPLHP [LP] GS 2-safety hyperproperties ( 2SHP ) [SP] AC 2SHP GMNI

51 HP SHPLHP [SP][LP] ACGS GMNI SEC Secret sharing ( SEC ) is not k -hypersafety for any k 2SHP

52 HP SHPLHP [SP][LP] ACGS GMNI OD PNI GNI Observational determinism ( OD ) is 2-hypersafety Generalized noninterference ( GNI ) is hyperliveness Probabilistic noninterference ( PNI ) is neither 2SHP SEC

53 HP SHPLHP [SP][LP] ACGS GMNI OD PNI GNI PIF 2SHP Possibilistic information flow ( PIF ) is hyperliveness SEC

54 Revisiting the CIA Landscape  Confidentiality Information flow is not a property Is a hyperproperty (HS: OD ; HL: GNI )  Integrity Safety property? Dual to confidentiality, thus hyperproperty?  Availability Sometimes a property (max. response time) Sometimes a hyperproperty (HS: % uptime, HL: avg. resp. time)  CIA seems orthogonal to hyperproperties

Hyperproperties Michael Clarkson and Fred B. Schneider Cornell University Ph. D. Seminar Northeastern University October 14, 2010