Secure Information Flow by Self-Composition

Similar documents
Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Shared Variables and Interference

Shared Variables and Interference

Reasoning About Imperative Programs. COS 441 Slides 10

Warm-Up Problem. 1. What is the definition of a Hoare triple satisfying partial correctness? 2. Recall the rule for assignment: x (assignment)

An Annotated Language

The Rule of Constancy(Derived Frame Rule)

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Z Notation. June 21, 2018

A New Type System for Secure Information Flow

Induction and Semantics in Dafny

3.7 Denotational Semantics

Verification Condition Generation

Formal Semantics of Programming Languages

Proof Carrying Code(PCC)

CS 242. Fundamentals. Reading: See last slide

Compositional Cutpoint Verification

Lecture 13: Subtyping

Programming Languages Third Edition

6. Hoare Logic and Weakest Preconditions

CS152: Programming Languages. Lecture 2 Syntax. Dan Grossman Spring 2011

A CRASH COURSE IN SEMANTICS

COMP 507: Computer-Aided Program Design

Logic and Computation Lecture 20 CSU 290 Spring 2009 (Pucella) Thursday, Mar 12, 2009

Getting Started with AutoCorres

Recall our recursive multiply algorithm:

Lecture Notes: Hoare Logic

CMSC 336: Type Systems for Programming Languages Lecture 5: Simply Typed Lambda Calculus Acar & Ahmed January 24, 2008

CS558 Programming Languages

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness?

Lectures 20, 21: Axiomatic Semantics

1 Introduction. 3 Syntax

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

Reasoning about programs

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Lecture 5 - Axiomatic semantics

Formal Semantics of Programming Languages

COMP 382: Reasoning about algorithms

Introduction to Axiomatic Semantics

Observable Behaviour Observable behaviour can be defined in terms of experimentation.

Programming with Math and Logic

To be or not programmable Dimitri Papadimitriou, Bernard Sales Alcatel-Lucent April 2013 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

A Hoare Logic Contract Theory: An Exercise in Denotational Semantics

Distributed Algorithms 6.046J, Spring, 2015 Part 2. Nancy Lynch

Lecture 7: Primitive Recursion is Turing Computable. Michael Beeson

Computing Fundamentals 2 Introduction to CafeOBJ

CITS5501 Software Testing and Quality Assurance Formal methods

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

From OCL to Propositional and First-order Logic: Part I

Warm-Up Problem. Let be a set of well-formed Predicate logic formulas. Let be well-formed Predicate logic formulas. Prove or disprove the following.

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

Termination Analysis of the Transformation UML to CSP

Programming Languages

The Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England

Formal Syntax and Semantics of Programming Languages

Lecture 1: Overview

Information Security CS526

Hoare logic. WHILE p, a language with pointers. Introduction. Syntax of WHILE p. Lecture 5: Introduction to separation logic

Hoare logic. Lecture 5: Introduction to separation logic. Jean Pichon-Pharabod University of Cambridge. CST Part II 2017/18

CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011

Formal Syntax and Semantics of Programming Languages

Noninterference Through Secure Multi-Execution

CS590U Access Control: Theory and Practice. Lecture 5 (January 24) Noninterference and Nondeducibility

Chapter 3 (part 3) Describing Syntax and Semantics

Formal Methods of Software Design, Eric Hehner, segment 24 page 1 out of 5

CS2 Language Processing note 3

/633 Introduction to Algorithms Lecturer: Michael Dinitz Topic: Sorting lower bound and Linear-time sorting Date: 9/19/17

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Hoare logic. A proof system for separation logic. Introduction. Separation logic

CS5371 Theory of Computation. Lecture 8: Automata Theory VI (PDA, PDA = CFG)

Distributed Algorithms 6.046J, Spring, Nancy Lynch

Lambda Calculus. Type Systems, Lectures 3. Jevgeni Kabanov Tartu,

REQUIREMENTS ANALYSIS. What versus how

Qualifying Exam Languages

ALGOL 48 AND ALGOL 50 ALGOLIC LANGUAGES IN MATHE- MATICS

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

Hoare Logic: Proving Programs Correct

How invariants help writing loops Author: Sander Kooijmans Document version: 1.0

Quicksort. Alternative Strategies for Dividing Lists. Fundamentals of Computer Science I (CS F)

A Theory of Parallel Computation The π-calculus

1 Achieving IND-CPA security

Functional Languages. Hwansoo Han

Operational semantics questions and answers

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011

This is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS

Lecture 11 Lecture 11 Nov 5, 2014

PROGRAM ANALYSIS & SYNTHESIS

Abstract Interpretation

Foundations. Yu Zhang. Acknowledgement: modified from Stanford CS242

February 2017 (1/20) 2 Piecewise Polynomial Interpolation 2.2 (Natural) Cubic Splines. MA378/531 Numerical Analysis II ( NA2 )

Symmetry in Type Theory

Lambda Calculus: Implementation Techniques and a Proof. COS 441 Slides 15

Overview. Probabilistic Programming. Dijkstra s guarded command language: Syntax. Elementary pgcl ingredients. Lecture #4: Probabilistic GCL

CSC 501 Semantics of Programming Languages

Verification Condition Generation via Theorem Proving

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

Lecture 10 Design by Contract

Introduction to Denotational Semantics. Class Likes/Dislikes Survey. Dueling Semantics. Denotational Semantics Learning Goals. You re On Jeopardy!

Introduction to Algorithms / Algorithms I Lecturer: Michael Dinitz Topic: Approximation algorithms Date: 11/18/14

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Transcription:

Secure Information Flow by Self-Composition Paper by Gilles Barthe, Pedro R. D Argenio, and Tamara Rezk Slides by Isaac Sheff

Background Noninterference Type Systems new features and policies require extensions to Type System and proof Logical Verification and Proof-Carrying Code Hoare Logic {Precondition} Code {Postcondition}

Program Logic Idea: let s encode Secure Information Flow as a logically provable property Andrews and Reitman extended Hoare Logic Darvas, Hähnle and Sands used dynamic logic Problem: reasoning about only one process Pottier s Pi Calculus work: 2 processes reduced to 1

2-Safety Prove that if you run program P twice, and the starting conditions each time are lowequivalent, then the finishing conditions are low-equivalent. high:7 low:3 P high:2 low:0 =L high:6 low:3 P =L high:1 low:0

Self-Composition From program P, create P just like P, but all new variable names New Program: P;P Need only consider single program high:7 high:2 high:2 low:3 P P low:0 low:0 =L high :6 =L high :1 low :3 low :0

Memory state: μ Notation Read variable foo from memory μ: μ(foo) Program Termination: Configuration: (Program, Memory state) Stick two (non-overlapping) memories together: S, starting with memory μ, doesn t terminate: (S, μ) Get all variable names in a memory: var(μ) Get abstract data structure at variable foo: v(μ, foo) Small Step transition: Any number of steps:

Par nondeterminism! Parallelism!

Implies var(s) is deep.

Definitely not true for all programs (or languages) Pointer logic messes with this

Given These Assumptions... Program S won t change anything not in var(s) Stuff not in var(s) won t affect S s termination Changing a variable name doesn t affect termination S, run on an identical set of values in different memories, has the same termination

More Notation φ : Var Var injective functions from one set of variables to another Indistinguishable variable sets: Indistinguishable memories: things that act like S 1;S2 (including parallelism): S1 S2

Non-Interference, Formalized S1 is termination sensitive (TS) non interferent with program S2 S1 is termination insensitive (TI) non interferent with program S2

Non-Interference, Formalized Different pre-condition and post-condition variable renaming and indistinguishability Extremely flexible Security: a program is non-interferent with itself Maybe indistinguishability is just low-equivalence

Composition If the memory state was indistinguishable from itself to begin with, then after running S1 S2, it remains indistinguishable form itself

The Big One For programs with non-overlapping sets of variables, our non-interference for two programs on different memories is the same as for two composed programs

Proof: TS is commutative, so Since programs don t affect variables not in the program: Therefore And so:

Proof: TI Because variables not in var(s) don t affect the termination of S:

But What if the Programs Share Variables? Let ξ be a function mapping the variables of one program to a new set. Noninterference of two programs is the same as noninterference of those programs, with one of their variables all renamed via ξ.

Theorem 2 Proof? Idea: prove that changing one variable s name does not alter noninterference Induct over all the variables in the program It s not very concise.

The Cool Part Now we can check of a program S is secure, by analyzing single executions of the program S S[ξ].

Analyzing Single Executions This is what verification logics are for Sections 5-9 are characterizations of security with some such logics

A Neat Example (5) xl: public yh: private We can show xl := xl + yh; xl := xl - yh is non-interferent

Deterministic We can actually check the security of a program by analyzing only the I/O (start and finish memories) of a self-composed program, e.g. S;S[ξ].

Deterministic Language While: a version of Par without nondeterminism (if can have only if... else... fi and get rid of parallelism) Consider memory that only stores integers, which is conveniently separable by

Hoare Logic {Precondition} Code {Postcondition}

Indistinguishability Criterion Shorthand µ I(I) i µ I µ (i (v(µ, ~x),v(µ, (~x))) 2 I)

TI Security in Hoare Logic Proof (recall that we re in a deterministic setting, and have a sequential composition operator ; )

Example Proof Original Program: xl := xl + yh; ξ: xl xl, yh yh xl := xl - yh Self-Composed Version: xl := xl + yh; xl := xl - yh; xl := xl + yh ; Indistinguishability: =L Meaning the low (really just xl) values must be the same xl := xl - yh

Example Proof {xl = xl } {xl + yh - yh = xl } xl := xl + yh; {xl - yh = xl } xl := xl - yh; {xl = xl } {xl = xl + yh - yh } xl := xl + yh ; {xl = xl - yh } xl := xl - yh {xl = xl } ((v(μ,xl), v(μ,yh)), (v(μ,xl ), v(μ,yh ))) =L In both the before and after states, since the xl values are equal.

Conclusions General Noninterference Formulation Self-composition for Security Analysis Need only analyze one program Determinism: only I/O analysis Various logics applied Future Work: characterizations for other non-interference notions other security properties prove secure type systems with these logics automation of such proofs in real languages