Presentation is loading. Please wait.

Presentation is loading. Please wait.

Internship at Microsoft Research?

Similar presentations


Presentation on theme: "Internship at Microsoft Research?"— Presentation transcript:

1 Internship at Microsoft Research?
Advertisement Internship at Microsoft Research? 12 week research projects, undertaken at MSR Cambridge, typically by grad students mid-way through their PhD. Goal: complete and publish research project with an MSR researcher: K..Bhargavan, C. Fournet, A. Gordon, and R. Pucella, TulaFale: A security tool for web services, FMCO 2003 C. Fournet, A. Gordon, and S. Maffeis A type discipline for authorization policies, ESOP 2005 Applications for Summer are due by end February 2006 aboutmsr/jobs/internships/cambridge.aspx

2 From Typed Process Calculi to Source-Based Security
Andy Gordon (MSR) Based on joint work with Cédric Fournet (MSR), Alan Jeffrey (DePaul and Bell Labs), and Sergio Maffeis (Imperial) The source-based security problem is to build tools to check security properties of the actual source code of a system, as opposed to some abstract model. Static analysis of C for buffer overruns is one approach. Another is to introduce security types as a programming language feature so that the typechecker proves security properties; for example, languages like Jif and Flow Caml can check noninterference properties of application-level code. Independently, security types have arisen in the setting of process calculi, for checking secrecy and authentication properties of abstract models of low-level cryptographic protocols, for instance. My talk argues that recent developments in security types for process calculi can lead to better source-based security by typing. One development (CONCUR 2005) removes a significant limitation of previous type systems and checks security in spite of the partial compromise of a dynamically-growing population of principals. Another (ESOP 2005) generalizes a type system for authentication to check authorization properties, by augmenting the typechecker with Datalog inference relative to a declarative authorization policy. Both developments rely on the idea of enriching process calculi with inert processes to represent both logical facts arising at runtime and also expected security invariants. SAS 2005, London September 7-9, 2005

3 Background Process calculi are an effective setting for modelling security protocols and specifying their properties Lowe (1995) used CSP to find his famous attack on the Needham-Schroeder public key protocol (1978) The spi calculus (AG97) began a line of work in which many protocols have been expressed and analyzed within pi calculi Security types allow the typechecker to prove various security properties automatically Syntax-driven typing rules can be checked efficiently, with no state space exploration Properties of arbitrarily many sessions and principals proved relative to arbitrary Dolev-Yao opponent Inevitably incomplete as D-Y problem undecidable (DLMS99) Durgin, N.A., Lincoln, P.D., Mitchell, J.C., and Scedrov, A., Undecidability of bounded security protocols, Workshop on Formal Methods and Security Protocols (FMSP'99), Trento, Italy, July 5, Electronic proceedings

4 An Authentication Example
Suppose A and B are principals sharing a symmetric-key KAB The following should ensure B gets a fresh message from A Begin Assertion A begins Sent(A,B,msg) Message 1 B  A: nonce Message 2 A  B: A, {msg,nonce}KAB End Assertion B ends We specify the authentication of the message via assertions: each end is to have distinct, preceding begin with same label Attacks (replays, impersonations) show up as violations of these assertions By assigning KAB the following type, we can check the protocol: // 3-typed.cry // Time-stamp: < :35:57 adg> import library; // // EXACTLY AS BEFORE // Names of hosts public A: Public; public B: Public; // Names of processes, located at hosts public Sender: Public; public Receiver: Public; // NEW TYPES FOR PROTOCOL DATA // Type of nonces certifying that msg has been sent from A to B type MyNonce(msg:Private) = Nonce (end (A sent msg to B)); // The private shared key, known only to A and B private KAB: Key (Struct (msg: Private, resp: MyNonce(msg))); // Now there's enough information to type-check the end-assertions client Sender at A is { establish Receiver at B is (socket: Public); input socket is (chall: Public); // receive message 1 new (msg: Private); begin (A sent msg to B); cast chall is (resp: MyNonce(msg)); // construct nonce certificate output socket is ({msg, resp}KAB); // encrypt and send message 2 } server Receiver at B is (socket: Public) new (chall: Public); output socket is (chall); // send message 1 input socket is ({msg: Private, resp: MyNonce(msg)}KAB); // receive and decrypt message 2 check chall is resp; // check for right nonce end (A sent msg to B); // accept as authentic and fresh Key (msg:T, Nonce [Sent(A,B,msg)] )

5 Authentication; full trust Secrecy; full trust
Applications Type inference Authorization; timing; partial trust Abadi – Secrecy by Typing in Security Protocols (JACM 1999) Abadi/Blanchet – Secrecy types for asymmetric communication (FOSSACS 2001) Gordon/Jeffrey – Typing Correspondence Assertions for Communication Protocols (MFPS 2001) Gordon/Jeffrey – Authenticity by Typing for Security Protocols (CSFW 2001) Abadi/Blanchet – Analyzing Security Protocols with Secrecy Types and Logic Programs (POPL 2002) Gordon/Jeffrey – Types and Effects for Asymmetric Cryptographic Protocols (CSFW 2002) Gordon/Jeffrey – Typing One-to-One and One-to-Many Correspondences in Security Protocols (ISSS 2002) Lashari - A Polymorphic Type and Effect System for An Object-Oriented Language to Typecheck Cryptographic Protocols (Depaul thesis, 2002) Bugliesi/Focardi/Maffei – Compositional Analysis of Authentication Protocols (ESOP 2004) Haack/Jeffrey – Pattern-Matching Spi-Calculus (FAST 2004) Focardi/Maffei/Placella – Inferring authentication tags (WITS 2005) Fournet/Gordon/Maffeis – A Type Discipline for Authorization Policies (ESOP 2005) Gordon/Jeffrey – Secrecy Despite Compromise: Types, Cryptography, and the Pi-Calculus (CONCUR 2005) Haack/Jeffrey – Timed Spi-Calculus with Types for Secrecy and Authenticity (CONCUR 2005) etc Bodei/Degano/Nielson/Nielson – Static Analysis for the pi-calculus with Applications to Security (2001) Other work on security in pi includes: Bodei/Degano/Nielson/Nielson Berger/Honda/Yoshida

6 This Talk Two new developments
Checking authorization (is this request allowed?) as well as authentication (who sent this request?) A type discipline for authorization policies (With C. Fournet and S. Maffeis. ESOP'05) Allowing a realistic threat model in which some trusted hosts become compromised over time Secrecy despite compromise: types, cryptography, and the pi-calculus. (With A. Jeffrey. CONCUR'05) A useful idea in both is the use of inert processes to record events and to express security properties

7 A Type Discipline for Authorization
Joint with C. Fournet and S. Maffeis

8 Motivations Authorization policies prescribe conditions that must be satisfied before performing any privileged action In practice, policies often only formalized in code Hard to extract, hard to reason about, hard to audit Tied to low-level authentication mechanisms Relationship of code to intended policy left informal In principle, Policies can be formalized in high-level languages (e.g. Datalog) separate from the implementation code Policies should be independent of enforcement mechanisms Conformance of an implementation should be verifiable Our initial motivations Difficulty of auditing use of Java-style stack inspection Authorization for web services

9 Our Approach We propose language-based mechanisms to express the intended policy of an implementation, and to verify conformance to the policy We use the authorization policy as a specification As opposed to being directly executed The same policy supports alternative implementations Our implementation language is a spi calculus But the approach would apply to higher-level languages We use types to verify that annotated code correctly implements a given authorization policy

10 Datalog for Authorization
Datalog is a fragment of Prolog without negation, free variables and term constructors Many policy languages for trust or authorization are based on Datalog or related logics (SD3, Binder, Cassandra, SPKI, XrML, …) Realistic policies: Becker’s 375 rule formalization of NHS Electronic Health Record system in Cassandra (CSFW’04) We use Datalog for specificity, but our results hold for any monotonic logic closed under substitutions Resolution terminates in (low) polynomial time

11 Ex: Conference Reviewing
Extensional database: known facts (closed literals) These generalize the events, such as Sent(A,B,msg), used in direct correspondence assertions to specify authentication Rules for deriving new facts Intensional database: facts derived from rules

12 Spi calculus with annotations
Zero-bits, only to keep track of guarantees Security annotations

13 Authorization Properties
Inert processes model events and properties A statement C models part of the authorization policy Specifically, a fact L models an authorization event An expectation expect L models an expected property The structural equivalence PP’ and reduction PP’ relations are much as usual There are no rules for these inert processes

14 Some Basic Examples Process P specifying a policy and two facts:
A robustly safe process : A safe process : … and the robustly safe version :

15 Authorization by Typing
Every ok value must be justified Every binding occurrence may add facts in E

16 Type System: Results Verification is efficient Structural type system
Low complexity of logical resolution

17 Typing the Examples Process P specifying a policy and two facts:
A safe process (by typing) : A robustly safe process (by typing) :

18 In the Full Version Two distributed implementations of a policy for conference management One where each delegation is registered online The other enables offline, signature based delegation with authorization decisions based on certificate chains

19 Summary We used inert processes to annotate programs with expected authorization properties “At this point Report(U,ID,R) will be derivable” Goal: check code annotations against explicit logical policy Extends work to typecheck direct correspondences Woo and Lam’s direct correspondences are derivable Much prior work on logics for authorization Ours is amongst the first to relate such logics to code and to use DY approach to model untrusted parts of system Limitations: Like many systems, no support for revocation Interpreter + typechecker, but no direct implementation Principals completely distrusted or completely trusted...

20 Secrecy Despite Compromise
Joint work with A. Jeffrey

21 Motivation Our opponent model has assumed a fixed partition
Trusted insiders versus distrusted outsiders Real situations are more complex Machines become compromised Trusted users turn out to be untrustworthy How can a type system handle partial compromise of a dynamically changing population of principals? We approach this question from a simpler setting than spi, Odersky’s polarized pi calculus Capabilities a? and a! for channel-based input and output

22 Security Levels Code annotated with security levels (or principals)
Different regions may run on behalf of different levels Level annotation L attached to each output out a! M :: L Level  represents the opponent Security ordering induced by arc processes Arc L1  L2 is itself an (inert) process Active (top-level) arcs in P induce a preorder P  L1  L2 Least and greatest elements  and  Compound level (L1 , L2) has P  (L1 , L2)  Li for each i Security ordering represents compromise Let a level L be compromised iff L   Hence L1  L2 means L1 is at risk of compromise by L2 So (L1, L2) is compromised if either L1 or L2 compromised

23 Security Hierarchies any process any process a  
b (a,b) a   !;new a;(G  a | ;a  ) b ... a1 an an+1 ... an+m a (a,b) G

24 Conditional Secrecy We say M is public if it can be output at level 
We model secrecy invariants as inert processes: An expectation secret M amongst N is justified if every output of M is at a higher security level than N Read as “if M becomes public then N is compromised” The secret message M may include fresh names

25 A Basic Example Consider two processes at level L that exchange a fresh secret s on a private channel k We want a type system that: Checks secrecy of s while k is secret and L uncompromised Eventually allows k and s to be made public once L is compromised – an event modelled by the arc L   A specific formal problem: verify robust safety of

26 Conditional Secrecy by Typing

27

28

29

30 In the Full Version Types ordered via a subtype relation
Main rule: if Public(T) and Tainted(T’) then T <: T’ Secrecy types are special case of (kinded) channels Kinds take the form {?L1,!L2} We can assert secrecy of channels, eg the k channel Type Ok{L1  L2} proves that L1  L2 Allows security orderings to be communicated Type system reflects usage of pair types (split x:T, U) – first element extracted without checking (match x:T, U) – first element matched against known value Full form is (y  x:T, U) where {split,match} and y is an existentially quantified lower bound on x used only in types Using the naive “ciphertexts as processes” encoding we can represent cryptographic protocols within polarized pi.

31 Typing a Crypto Protocol
Note that in this analysis, A knows that sA is kept secret between A and B, but B does not: this is because we have not included nonce types in this language. Abadi and Blanchet~\cite{AB03:SecrecyTypesForAsymmetricCommunication} consider the same protocol, under similar assumptions of compromise, but rely on two separate typing derivations to prove the secrecy of \txt{sA} and~\txt{sB}.

32 Related Work Key or host compromise often modelled using events
Paulson (JCS 98): “oops” events mark key disclosure Bugliesi, Focardi, Maffei (FMSE’04) allow for compromised hosts in a type system for spi, but assume the set is known statically Types to govern data declassification are a Hot Topic Myers and Liskov (TOSEM’00) DLM is one of the first system of security types to consider declassification, though at level of individual expressions, not types Several recent works (CSFW’05) on temporary modifications of a security ordering, akin to our L1  L2 processes Many studies of process calculi with security ordering Our use of an ordering to model runtime compromise is new

33 Summary, Conclusions We introduced a mutable security ordering to model a dynamic, partially compromised set of principals As with our authorization model, we rely on inert processes to describe events and expected properties There remains much promise in the area of process calculi with security types These two systems should combine fairly smoothly They should be applicable to an important open problem; how to check security properties of the actual source code of crypto protocols and the applications built on them

34 The End


Download ppt "Internship at Microsoft Research?"

Similar presentations


Ads by Google