480 likes | 639 Views
Programming Language Methods for Compositional Security III Anupam Datta (CMU) June 2010. Goal: Compositional Security. S 1. How can we prove that S 1 + S 2 is secure based on properties of S 1 and S 2 that are provable separately? Initial focus: security protocols
E N D
Programming Language Methods for Compositional Security IIIAnupam Datta (CMU)June 2010
Goal: Compositional Security S1 • How can we prove that S1+S2 is secure based on properties of S1and S2 that are provable separately? • Initial focus: security protocols • Later lectures: a more general story S2
Goal: Transcend Specific Systems, Attacks • How can we uniformly model systems and adversaries against different classes of systems? • Idea: Interfaces and interface-confined adversaries • Web browser adversary vs. network protocol adversary… Secure System Adversary Malicious Frame & Server Malicious Virtual Machine Network Adversary
Talk Outline • Programming Language for Modeling Systems • Interfaces and Interface-confined adversaries • Logic for Specifying Security Properties • Integrity, confidentiality of data, ordering of actions • Proof System for Compositional Reasoning • Illustrated through a running example of an AFS-like file system (other examples in paper: network protocol Kerberos V5 and a web mashup) Joint work with Deepak Garg, Jason Franklin, DilsunKaynar CMU
Modeling Language Syntax • Syntax, semantics treat actions, a, abstractly – instantiate for specific scenarios (e.g., send, receive, encrypt) • Actions can have side-effects. They are the only way to change state. • e1; e2 abbreviation for let(e1,x.e2) when x not in e2. • Recursion is supported
Modeling Language Semantics A trace is a finite sequence of configuration reductions starting from an initial configuration • Monotonically increasing time points ui are associated with reductions Collection of sequential threads with shared state Threads reduce by executing expressions Configurations reduce by interleaving thread reductions
Example: File System with Modifiable Access Permissions (Interfaces) Lowest-level interfaces called actions, e.g., insert, remove, send, recv Lowest-level interfaces may not be directly accessible to programs Programs can access only secure interfaces, in this case those on the left + {send, recv}. Interface-confined adversaries can call these secure interfaces in any order
Trusted Program Example Trusted programs combine interface calls in known ways
Talk Outline • Programming Language for Modeling Systems • Interface-confined adversaries • Logic for Specifying Security Properties • Integrity, confidentiality of data • Proof System for Compositional Reasoning • Illustrated through a running example of an AFS-like file system CMU
First-Order Hybrid Logic Syntax Trace semantics Formulas are interpreted over timed traces
Specifying Security Properties Only s[n] may update file f[n]
Logic of Programs: Assertions • Partial Correctness Assertion [e] <ub, ue, i, x> • If thread i executes the expression e between time ub and ue producing return value x, then holds in the resulting state …irrespective of concurrent actions by other threads • Invariant Assertion {e} <ub, ue, i> • If thread i executes the expression e between time ub and ueand does not return, then holds in the resulting state …irrespective of concurrent actions by other threads
Example Invariant • Invariant of teacher’s program: Teacher never adds any administrative permissions
Assertions for functions • Partial Correctness Assertion for Function [f] <y, ub, ue, i, x> • If thread i executes the function f with parameter y between time ub and ue producing return value x, then holds in the resulting state …irrespective of concurrent actions by other threads • Invariant Assertion for Function {f} <y, ub, ue, i> • If thread i executes the function f with parameter y between time ub and ueand does not return, then holds in the resulting state …irrespective of concurrent actions by other threads
Examples of Assertions for Functions • F: set of file system interfaces + {send, recv} • Assertion: If thread i adds a permission on file f, then i has administrate (ad) permission on file f
Talk Outline • Programming Language for Modeling Systems • Interface-confined adversaries • Logic for Specifying Security Properties • Integrity, confidentiality of data • Proof System for Compositional Reasoning • Illustrated through a running example of an AFS-like file system CMU
Overview of Reasoning Approach Properties of Model (Axioms) Trusted Programs Trusted Program Invariants Sound Logical Inference Adversary = Fixed set of Interfaces Interface Invariants Proof of Property
Example Compositional Proof Outline • Integrity Property: Only s[n] ever updates f[n] • Trusted-Program Invariant: Teacher never adds any administrate permission • Interface invariant: If thread i adds a permission on file f, then i has administrate (ad) permission on file f • Rely-Guarantee on 1,2: Only teacher has administrate permission ever on any file • … • … • … • … Only s[n] ever updates f[n] Focus on 1-3 in this talk
Rule for Trusted Program Invariants Compare with PCL’s honesty rule • If a thread I executes program e starting at time u and φis an invariant of e, then φ must hold after u. From program(interface) properties to safety properties over traces
Trusted Program Example Trusted programs combine interface calls in known ways
Applying Rule for Trusted Program Invariants (Step 1 of Example) Prove in program logic Explicit Assumptions (HONTH) Teacher never gives any administrate permissions
Rule for Interface Invariants • If a thread I is confined to interfaces (functions) in F and all functions of F have a compositional invariant φthenφalways holds for I. From program(interface) properties to safety properties over traces
Example: File System with Modifiable Access Permissions (Interfaces) Lowest-level interfaces called actions, e.g., insert, remove, send, recv Lowest-level interfaces may not be directly accessible to programs Programs can access only secure interfaces, in this case those on the left + {send, recv}. Interface-confined adversaries can call these secure interfaces in any order
Example of Rule for Interface Invariants (Step 2) F is the set of file system interfaces + {send, recv} Prove in program logic Confinement assumption (RES) Only a thread with administrate permissions can update permissions for a file
Rely-Guarantee Compositional Reasoning • To prove φshow that (A), (B), (C) holds in the presence of interface-confined adversaries:
Applying Rely-Guarantee (Step 3 of Example) (B) Prove separately for each thread assuming holds at earlier time points Proof of (B) requires trusted program invariant for teacher thread and interface invariant for all other (student) threads as described in previous slides
Example: Kerberos V5 Goal: Prove that Akey is known only to Client, KAS, TGS AS-REQ C, n1 Client KAS AS-REP [Akey.C]K_TK, [Akey.n1.T]K_CK TGS-REQ [Akey.C]K_TK, [C]Akey, n2 Client TGS TGS-REP [Skey.C]K_ST, [Skey.n1.T]AKey [Skey.C]K_ST, [C.t]SKey AP-REQ Client Server AP-REP [t]SKey
Form of Analysis • Analysis of behavior of trusted programs in proof of security property may rely on security property having been true in the past. • Protecting a secret in a group • To show: A secret Akey is never leaked outside a group G = {Client, KAS, TGS} of participants during a protocol • Invariant: In all transmissions of Akey potentially leaving G, Akey is encrypted with a set of keys known only to G • Analysis of correctness of P relies on the assumption that invariant holds before P receives the message
Example: Rely-Guarantee for Kerberos • Objective: Prove that a certain key AKey0 in the Kerberos protocol is always protected by a set of keys K0 • Instantiate rely-guarantee framework: All transmissions of AKey0 before time u are protected by K0 Any occurrence of AKey0 in a message sent by i at time u is protected by K0 i is one of Client, KAS, TGS threads
Proving Invariants and Partial Correctness Assertions • Syntax-directed proof rules for invariants and partial correctness assertions • Example invariant
Goals Results • Reduce reasoning about security properties protocols/systems in the presence of adversary to reasoning about programs • Known trusted programs for good guys: invariants over programs (HONTH rule) • Adversary modeled in terms of interfaces (functions) it has access to: interface invariants (RES rule) • Mirror informal arguments of security in formal logical proofs • Catch unsound informal arguments • Illustrated through examples from protocols, access control CMU
Compositional Security: Summary S1 • Programming language methods for compositional security • Interfaces and Interface-confined adversaries • Compositional proofs of safety properties of concurrent systems with adversaries from properties of component programs + interfaces • Compositional reasoning principles (including rely-guarantee) • Applications • Integrity property of an AFS-like file system • Secrecy property of the network protocol Kerberos V5 S2
Further Resources • Look at papers in reading • Problem sheet with homework problems using PCL • Foundations of Security and Privacy course at CMU (linked from summer school page) • Current areas of activity • Combining logic and complexity-theoretic cryptography • Foundations of data privacy • Foundations for web security CMU
Related Work S1 • Rely-guarantee reasoning for system correctness [MC81, J83] • No adversaries • Protocol Composition Logic [DMP01,DDMP03,...] • Specific to network protocols • Modular verification of security protocols by typing [BFG10] • Focus on network protocol implementations, higher order S2
Example Compositional Proof Outline • Integrity Property: Only s[n] ever updates f[n] • Trusted-Program Invariant: Teacher never adds any administrate permission • Interface invariant: If thread i adds a permission on file f, then i has administrate (ad) permission on file f • Rely-Guarantee on 1,2: Only teacher has administrate permission ever on any file • Trusted-Program invariant: Teacher ever gives write permission on f[n] only to s[n] • Combine 1,3,4: Only s[n] has write permission on f[n] • Interface invariant: Thread i updates file f => i has write permission on f • Combine 5, 6: Only s[n] ever updates f[n]. QED Focus on 1-3 in this talk
Modeling Language Semantics Collection of concurrent threads with shared state Threads reduce by executing expressions Configurations reduce by interleaving thread reductions
Traces • Trace = Finite sequence of reductions • Associate time point ui with each reduction • Time points monotonic along trace • Time points help represent order of events in properties
Soundness of Proof System • Composition principles are sound: proofs are sound if axioms about underlying model are sound • Proof of soundness is non-trivial due to recursive functions and interface invariants
Trusted-Program Invariant Example Program invariants hold while a program executes, even if the program never returns (cf. partial correctness) Bank1 only sends messages of the form (parse_balance(v1’), nonce1’) where nonce1’ is received from Aggregator and v1’ is a page received from bank1.com.
Global Interface Invariant Example Invariants derived from interfaces are global properties of the system. They hold irrespective of how the interfaces are used. Sender Authentication If frame i receives a message v, purportedly coming from frame j, then j did indeed send the message to v to i.
Example of Rule for Trusted-Program Invariants Prove in program logic Explicit Assumptions