Nikhil Swamy http://research.microsoft.com/fine Joint work with Juan Chen and Ravi Chugh

1. Fine and DCIL Secure programming on .NET Nikhil Swamyhttp://research.microsoft.com/fine Joint work with Juan Chen and Ravi Chugh

2. Secure distributed programming • Users download code to browser, phone, etc. • Also upload programs to cloud • JavaScript, Flash, Silverlight, Java, .NET, Python, … • Mostly memory-safe languages • But, memory safety is not enough for security • Browser+extensions still enforces Same-Origin Policy? • Is entire cloud-hosted DB visible to a user program? • Want automated security verification

3. Security-typed programming • Language support for security verification • Prove software secure by construction 15+ years of research producing MANY • Models of secure computation • Policy languages • Typing disciplines Which model, policy language and type system to pick for secure cloud computing?

4. What’s your favorite flavor?

5. Flavors of security • Information flow • Label model? Atomic, decentralized, role-based, … • Explicit flows + implicit flows? Explicit only? • Termination (in)sensitive? • Plus declassification • Many dimensions, many flavors in each dimension … • Access control • But which authorization logic? • XACML,SecPAL, DKAL, DCC, SD3, Binder, Ponder, RT, … • Stateless, history-based, ... • Auditing • Cryptographic evidence? Explicit proof terms?

7. Which flavors to bake into a language? • The answer in Fine: None Instead • A few general purpose constructs • Flexible enough to capture many security idioms

8. What is Fine? A subset of F# with a type system designed around • Value-indexed types secretString: labeled<string, High> • Dependent refinement types getEmail: p:plugin -> {e:email| CanReadp e } -> string • Affine (use-at-most-once) types • Useful for modeling state

9. Why Fine? Why not Coq, Agda, …?

10. DCIL: Type system for .NET bytecode • The target language for the Fine compiler • Fine to DCIL translation is type-preserving • DCIL backwards compatible with CIL • Fine’s type system carefully designed to match what is possible TODAY on the .NET VM • Coq, Agda, even Haskell, can’t be compiled to .NET (with high fidelity)

11. Example applications • Lookout: A model of a plugin-based email client • Verify that .NET DLLs for plugins: • Respect user’s authorization policy • Never leak email from one contact to another • HealthWeb: A model health-record mgmt. website on Windows Azure • Web interface in ASP.NET and C# • Data tier in F#/SQL Server • Reference monitor for data tier verified using in Fine • Currently underway • Secure browser extensions for IE • Secure program marshaling • Crypto protocol verification

12. Plan • A brief primer on Fine, the structure of our compiler, and experiments • A more in-depth look at • Information flow • Stateful authorization • Demo: Fine + DCIL on Azure • Wrap up

13. Current practice Specifying and enforcing XACML policies XACML Policy <Resource> <ResourceMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <ResourceAttributeDesignatorAttributeId="resource:datastream:id“ DataType=“…/XMLSchema#string"/> <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">PatientRecord</AttributeValue> </ResourceMatch> </Resource> <Action> <ActionMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">action:getData</AttributeValue> </Action> <Subject> <SubjectMatchMatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">Doctor</AttributeValue> </SubjectMatch> </Subject> <RuleRuleId="1" Effect="Deny"> <Target> … </Target>  <Condition> ... </Condition> </Rule>   <RuleRuleId=“2" Effect=“Permit"> <Target> … </Target>  <Condition> ... </Condition> </Rule> • Resources: patient-records • Actions: getData, … • Subjects: Doctors, … • Rules: Grant, Deny, … • Does this code properly enforce the policy? • Complete mediation? Is this the right query with right parameters? public Data GetData (string subjectName, string recId) { Record rec = DB.GetRecord (subjectName, recId); List queryParams = new {subjectName, rec.datastreamId}; if (XACML.GetAuthCtxt(subjectName).query(“CanGetData”, queryParams)) { return rec.data; } return null; } C# code that mediates access to patient records

14. Fine: Specify and enforce security policies valreadRecord: p:prin -> cred<p> -> {r:record | HasPerm<p, CanRead r>} -> string A reference monitor written in Fine assumeRule_docCanRead: forall p:prin, r:record. (InRole<p,Doctor> && Treating<p, r.patient>) => HasPerm<p, CanRead r> assume … Policy specified using logical formulas in a header file • Types mention security constraints from policy Type checker ensures authenticity, complete mediation, information hiding The type of a function to read data from a protected record

15. Security verification by type checking moduleRequestMgr let rechdlreq () = matchnext_request () with | p, cred, GetRecordContents r -> let test = checkRole p Doctor && checkTreating p r.patientin if test then letrecord_data = HealthDB.readRecord p cred rin respond record_data; hdlreq () else respond (Denied “Sorry, insufficient privilege”); evtloop () • Query the policy • Read records only if test succeeds Type error RequestMgr.fine (9.10) – (9.43): Expected {r:record | HasPerm <p, CanRead r>} Got record

16. Structure of our compiler Fine • Type-checked using Z3 (SMT solver) • Simplifies programming • Extract typeable proof terms from Z3 • Proofs flexible for a variety of logics • Type-checker • + Compiler Z3 DCIL • DCIL • Type-Checker • DCIL: Type system for functional core of .NET bytecode • Purely syntactic verification (solver not in TCB) • Verification is fast • Executable on stock .NET VM C#, F#,… DCIL .NET Virtual Machine Fine: Functional language with refinement types getEmail: p:plugin -> {e:Email | CanRead<p,e> } -> string

17. Reference monitors for example programs A module implementing a lattice-based information flow policy An interpreter for (a fragment of) the DKAL authorization logic -- Refinements ensure that substitutions of quantified assumptions are correct A reference monitor for a filesystem that tracks and rules out illegal information flows between files An automaton based policy for access control on files -- similar to typestatetracking

18. Reference monitors for example programs An auto-generated library of commonly used proofs and lemmas -- verified by pure type checking alone, no use of Z3 A model of the Continue conference management server -- Stateful authorization policy structured into 9 phases, 12 kinds of actions Reference monitors are compact. No need to write your whole application in Fine. A model of HealthVault, a website for managing a database of a health records Web interface in ASP.NET and C# Back end in F# and a SQL Server database Lookout: A plugin-based email client -- plugins subject to a stateful authorization and information flow tracking policy Too many proof terms to write by hand. Automation via Z3 is key.

19. Translating to DCIL Verifying DCIL programs is fast. Syntax directed verification of programs and proofs Compilation times are still high. Includes time spent in Z3, and extracting and verifying proof terms Increase in code size 2x – 50x Z3 often produces very verbose proofs Preliminary experiments with SS a custom proof-producing first-order prover yield 25x improvement Increase in code size with Z3 proof: 50x Increase in code size with SS proof: 2x

20. Benefits of compiling with proofs • Security verification for mobile code • Translation validation for Fine compiler • Proof-carrying and code-carrying authorization (Appel& Felten; Maffeis et al.) • Verifiable audit trails(Zdancewicet al.) • Log proof terms in support of post-hoc reconstruction of authorization decisions • Secure marshaling • DCIL as a verifiable serialization format

21. Plan • A brief primer on Fine, the structure of our compiler, and experiments • A more in-depth look at • Simple access control • Information flow • Stateful authorization • Demo: Fine + DCIL on Azure • Wrap up

22. Fine: Simple access control on files • Develop a reference monitor for a file system • Enforces a simple access control policy • Main idea: Give privileged operations refined types to capture their pre- and post-conditions • Type check reference monitor to ensure that every call of fread is protected by a suitable check Principal p authenticated by this credential valfread: p:prin -> credential<p> -> {f:file | CanRead<p,f> } -> string The type of file handles f for which the (CanRead<p, f>) proposition is valid

23. Fine: Simple access control on files credential<p> is a value-indexed type credential<Alice> is the type of a credential authenticating Alice. Types ensure that this cannot be confused as a credential for Bob. typefile typeprin= Alice | Bob | Admin typecredential<prin> val login: p:prin -> pw:string -> option<credential<p>> type CanRead<prin,file> assume AdminCR: forall(f:file). CanRead<Admin, f> assume AliceCR: … valfread: p:prin -> credential<p> -> {f:file| CanRead<p,f> } -> string login has a dependent function type Constructs a credential for p if the password check succeeds The CanRead predicate is a binary type constructor A policy is specified using a series of first-order logic assumptions

24. Simple access control on files moduleFileSystemRM typeCanRead<prin, file> typeCanWrite<prin, file> valfread: p:prin -> cred<p> -> {f:file | CanRead<p,f> } -> string valfwrite: p:prin -> cred<p> -> {f:file| CanWrite<p,f> } -> string -> unit But, this API does not prevent a privileged client from copying data from a secret file into a publically visible file

25. Tracking information flows between files type label = File: file -> label | Join: label -> label -> label type tracked<‘a, label> typeCanFlow<label,label> assumeAtomic_flow: forall f:file, g:file. (forall p:prin. CanRead<p,g> => CanRead<p,f>) => CanFlow<File f, File g> assumeLattice: … valfread: p:prin -> cred<p> -> f:{x:file | CanRead<p,x>} -> tracked<string, File f> valfwrite: p:prin -> cred<p> -> f:{x:file | CanWrite<p,x>} -> l:{x:label | CanFlow<x, File f>} -> data:tracked<string, l> -> unit tracked<t, q> data of type t originated from files in q Returned data tagged with label f Data allowed to flow to f

26. Tracking flows in client programs • View tracked<‘a,label> as a lattice of monads (or applicative functors) • Abadi et al. in DCC bind: l:label -> tracked<(‘a -> ‘b), l> -> m:label -> tracked<‘a, m> -> tracked<‘b, Join l m> • More effort: programmers use bind explicitly Result at least as secret as both Apply a labeled function To a labeled argument

27. Plan • A brief primer on Fine and the structure of our compiler • A more in-depth look at • Simple access control • Information flow • Stateful authorization in ConfWeb • Demo: Fine + DCIL on Azure

28. ConfWeb: A conference mgmt. tool • Based on Continue: Krishnamurthi et al. • A conference management server in PLT Scheme • Privileges granted by the policy evolve over time • Policy structured into 9 phases, 12 kinds of permissions, ~ 50 rules in policy • “Almost all interesting bugs in Continue have related to access control in some form”--- Krishnamurthi et al. IJCAR 2006

29. Structure of ConfWeb Implemented in Fine • Chair Authentication modules Untrusted application code (in F#) • Reviewer Security Policy Reference monitor provides authorized access to database Database of papers, reviews, … • Author

30. A model of stateful authorization assumecanReview: forall u:prin, p:paper, s:authstate. (In (Role u Reviewer) s && In (AssignedPaper p u) s)=> GrantedIn(Permit u (Review p)) s … Policies specify an unchanging set of inference rules to derive authorization facts from the current authorization state Authorization policies are defined over an evolving set of relations (authorization attributes) State transition on event CloseSubmissions State transition on event AssignPaper paper17 Bob AuthState s0 AuthState s1 AuthState s2 (Role (U “Andy”) Chair) (Phase PaperAssignment) (AssignedPaper paper17 (U “Bob”)) (Role (U “Andy”) Chair) (Phase Submission) (Role (U “Andy”) Chair) (Phase PaperAssignment)

31. Stateful authorization in ConfWeb(1) A simple data model for ConfWeb moduleConfWeb type paper = {id:int; authors:listprin; contents:string; … } type review = {paperid:int; reviewid:int; author:prin; …} type db = list<paper> * list<review> * authstate * …

32. Stateful authorization in ConfWeb(2) A vocabulary for a security policy type role = Author | Reviewer | Chair | … typephase = Submission | Assignment | Meeting | … typeattr = Role: prin -> role -> attr | Assigned: prin -> paper -> attr | Phase : phase -> attr typeauthstate = list<attr> typeaction = Submit: paper -> action | Review: paper -> action | ReadScore: paper -> action | CloseSub: action typepermission = Permit: prin -> action -> permission prop In<attr, authstate> propGrantedIn<permission, authstate> Authorization state is a list of authorization attributes Role memberships, paper assignments, conference phase … Permit Alice (Submit p) GrantedIn <q, s> says that permission q is derivable from the authstate s

33. Stateful authorization in ConfWeb(3) A security policy assumecanSubmit: forall u:prin, p:paper, s:authstate. (In<Role u Author, s> && In<Phase Submission, s>) => GrantedIn<Permit u (Submit p), s> assumecanCloseSubmissions: forallu:prin, s:authstate. (In<Role u Chair, s> && In<Phase Submission, s>) => GrantedIn<Permit u (CloseSub), s> assumecanReview: forall u:prin, p:paper, s:authstate. (In<Role u Reviewer, s> && In<Assigned u p, s>) => GrantedIn<Permit u (Review p), s> … Security policies are stated using assumptions in the form of first-order logic formulas

34. Stateful authorization in ConfWeb(4) Connecting policy to code using types valsubmit_paper: u:prin -> credential<u> -> p:paper -> {s:authstate | GrantedIn<Permit u (Submit p), s>} -> unit Calling principal u authenticated using this credential Prove that u has the Submit p permission in the authstate s

35. Stateful authorization in ConfWeb(4) Connecting policy to code using types valsubmit_paper: u:prin -> credential<u> -> p:paper -> {s:authstate | GrantedIn<Permit u (Submit p), s>} -> unit valclose_submissions: u:prin -> credential<u> -> {s:authstate | GrantedIn<Permit u CloseSub, s> } -> {s’:authstate | In<Phase Assignment, s’> } Post-condition: (Phase Assignment) is in the post-state s’ Pre-condition: u must have the CloseSub permission in the pre-state s

36. Stateful authorization in ConfWeb(5) Modeling state changes with affine types valsubmit_paper: u:prin -> credential<u> -> p:paper -> {s:authstate | GrantedIn<Permit u (Submit p), s>} -> unit valclose_submissions: u:prin -> credential<u> -> {s:authstate | GrantedIn<Permit u CloseSub, s> } -> {s’:authstate | In<Phase Assignment, s’> } s is a stale state. Want to ensure that facts derived from s are unusable in subsequent authorization decisions.

37. Stateful authorization in ConfWeb(5) Modeling state changes with affine types type StateIs :: authstate=> A valsubmit_paper: u:prin -> credential<u> -> p:paper -> {s:authstate | GrantedIn<Permit u (Submit p), s>} -> unit valclose_submissions: u:prin -> credential<u> -> {s:authstate | GrantedIn<Permit u CloseSub, s> } -> {s’:authstate | In<Phase Assignment, s’> } A is the kind of affine types StateIs constructs an affine type from an authstate value

38. Stateful authorization in ConfWeb(5) Modeling state changes with affine types type StateIs :: authstate=> A valsubmit_paper: u:prin -> cred u -> p:paper -> s:{s:authstate | GrantedIn<Permit u (Submit p), s>} -> StateIs<s> -> StateIs<s> valclose_submissions: u:prin -> credential<u> -> {s:authstate | GrantedIn<Permit u CloseSub, s> } -> {s’:authstate | In<Phase Assignment, s’> } A is the kind of affine types StateIs<s> is the type of a token asserting s is the current state Leaves the state unchanged

39. Stateful authorization in ConfWeb(5) Modeling state changes with affine types type StateIs :: authstate=> A valsubmit_paper: u:prin -> cred u -> p:paper -> s:{s:authstate | GrantedIn (Permit u (Submit p)) s} -> StateIs<s> -> StateIs<s> valclose_submissions: u:prin -> cred u -> s:{s:authstate | GrantedIn<Permit u CloseSub, s> } -> StateIs<s> -> (s’: {s’:authstate | In<Phase Assignment, s’>} * StateIs<s’>) A is the kind of affine types StateIs<s> is the type of a token asserting s is the current state Leaves the state unchanged Consumes a (StateIs s) token. Produces a (StateIs s’) token.

40. Stateful authorization in ConfWeb(5) Modeling state changes with affine types type StateIs :: authstate=> A valsubmit_paper: u:prin -> cred u -> p:paper -> s:{s:authstate | GrantedIn (Permit u (Submit p)) s} -> StateIs s -> StateIs s valclose_submissions: u:prin -> cred u -> s:{s:authstate | GrantedIn (Permit u CloseSub) s} -> StateIs s -> (s’:{s’:authstate | In (Phase Assignment) s’} * StateIs s’) A is the kind of affine types StateIs<s> is the type of a token asserting s is the current state Kinding rules forbid affine values from appearing in formulas. I.e, in t => A, the type t has to be non-affine

41. Stateful authorization in ConfWeb(6) Handling application requests contains: a:attr -> s:authstate -> {b:bool | b=true <=> In a s} let recevtloop(s, sTok) = matchnext_request () with | u, cred, SubmitPaper p -> let test = contains (Role u Author) s && contains (Phase Submission) s in if test then letsTok = submit_paper u cred p s sTokin respond (“Submission received”); evtloop (s, sTok) else respond (“Request denied”); evtloop (s, sTok) | u, cred, CloseSubmissions -> lettest = contains (Role u Chair) s && contains (Phase Submission) s in … Type error RequestMgr.fine (6.10) – (6.43): Expected {s:authstate | GrantedIn <Permit u (Submit p), s> } Got authstate

42. Plan • A brief primer on Fine and the structure of our compiler • A more in-depth look at • Simple access control • Information flow • Stateful authorization in ConfWeb • Demo: Fine + DCIL on Azure

43. Demo: HealthWeb on Azure Type of enforcement code Logical rules for security policy p InRole Doctor AND p IsTreatingr.patient => p CanRead r Security Policy • Doctor search read • Patient SQL Azure GetRecords DB_select consent read • Insurance provider Fine F# ASP.NET/C# search • Reference monitor • O/R Mapping Application (Azure Web Role) Database (SQL Azure) Client (Web browser) GetRecords: p: prin -> List< {r:record| CanRead <p,r>} >

44. http://fine-healthweb.cloudapp.net

45. Summary Fine • Many different flavors of security-typed programming • Using a few general-purpose primitives DCIL • Security verification at the bytecode level • Secure distributed computing • Clients and the cloud

46. In progress • FX: Hoare triples for programming with affinity • A higher-level surface language for Fine • Secure browser extensions using Fine and DCIL • IE and the RiSE Cloud Computing Client (C3) • Combining cryptographic proofs with proof-carrying code • Fine + F7 (MSR Cambridge) With Juan Chen, Karthik Bhargavan , Johannes Borgstroem, Cedric Fournet, Arjun Guha, Ben Livshits, Alok Rai, Jean Yang

47. Try it out fine-0.3-alpha: Compiler sources, example programs http://research.microsoft.com/fine