1 / 48

Programming Language Methods for Compositional Security III Anupam Datta (CMU) June 2010

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

artan
Download Presentation

Programming Language Methods for Compositional Security III Anupam Datta (CMU) June 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Programming Language Methods for Compositional Security IIIAnupam Datta (CMU)June 2010

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. Trusted Program Example Trusted programs combine interface calls in known ways

  9. 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

  10. First-Order Hybrid Logic Syntax Trace semantics Formulas are interpreted over timed traces

  11. Specifying Security Properties Only s[n] may update file f[n]

  12. 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

  13. Example Invariant • Invariant of teacher’s program: Teacher never adds any administrative permissions

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. Trusted Program Example Trusted programs combine interface calls in known ways

  21. Applying Rule for Trusted Program Invariants (Step 1 of Example) Prove in program logic Explicit Assumptions (HONTH) Teacher never gives any administrate permissions

  22. 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

  23. 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

  24. 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

  25. Rely-Guarantee Compositional Reasoning • To prove φshow that (A), (B), (C) holds in the presence of interface-confined adversaries:

  26. 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

  27. 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

  28. 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

  29. 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

  30. Proving Invariants and Partial Correctness Assertions • Syntax-directed proof rules for invariants and partial correctness assertions • Example invariant

  31. Partial C. Rules: if and let

  32. Invariant rule for let

  33. Invariant rule for function call

  34. 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

  35. 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

  36. 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

  37. Thanks! Questions? CMU

  38. 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

  39. Additional Technical Slides CMU

  40. Rely-Guarantee in Hybrid Logic

  41. 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

  42. Modeling Language Semantics Collection of concurrent threads with shared state Threads reduce by executing expressions Configurations reduce by interleaving thread reductions

  43. 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

  44. Syntax-Directed Proof Rules

  45. 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

  46. 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.

  47. 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.

  48. Example of Rule for Trusted-Program Invariants Prove in program logic Explicit Assumptions

More Related