Trust and Authorization via Provenance and Integrity in Distributed Objects

1. Trust and Authorization via Provenance and Integrity in Distributed Objects Andy Cirillo James Riely Radha Jagadeesan Corin Pitcher School of CTI, DePaul University. Chicago.

2. An Example: Content Aggregation Owner adds Aggregator to Account(s) Owner asks Aggregator for summary of balances Aggregator requests balance from Account(s) Aggregator returns aggregate balance • Security Concerns: • Trust & Authorization • Privacy • Delegation • Audits for accountability • Content Aggregators • Financial Services, e.g. Mint, Yodlee • Mashups, Web Services } Provenance A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

3. Our language-based approach to security • Distributed Objects  • De-perimeterization [ Jericho Forum ] • Object programming idioms: flexible composition constrained by interfaces (vs. “Info Flow” style) • Focus on semantic attacks on trust and authorization (vs. “Network is the Opponent”) A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

4. Outline of approach • A calculus of distributed objects [Gordon/Hankin + provenance & integrity primitives …] • Type-and-effect system, object-centric effects [Object creation has obligations, possession gives benefits …] • Type system provides robust safety against attackers A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

5. Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff Full paper: http://www.teasp.org/tapido

6. Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff

7. Calculus: Key ingredients • Concurrent Object Calculus [Gordon/Hankin 98] • Heap objects as processes • Asymmetric, partially commutative concurrent composition • Right-most term is return value; cf. imperative-style concurrency • Explicit identities [Abadi, Burrows, Lampson, Plotkin,Wobber, etc.] • People/machines/processes/keys • Objects “located” at identities • Integrity assumptions on method invocation • Integrity: know the sender A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

8. Calculus: Located Objects • Objects located at site of creation • Object reference preserves provenance of creator A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

9. Calculus: Integrity via opsem Method executes under authority of object. The special variable caller is bound to calling principal. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

10. Is required Integrity realizable? • See, for example: • Proxy Based Systems [RMI, Jini etc ] • Security goals [Li, Mitchell and D. Tong; B. Scheifler; Gordon and Pucella] • Implementation using Signing + SSL/TLS A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

11. Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff

12. Provenance in Security • Provenance (noun ) 1 :origin, source 2 : the history of ownership of a valued object or work of art or literature • In security, the source of a message • Immediate provenance (who created it?/who sent it?) • Full history (who touched it?) • User-defined provenance: keep only what you need A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

13. Provenance in Security • Stack Inspection • An a posteriori look at the stack • Criticism – limited expressiveness [Fournet/Gordon 2001] • Security-Passing Style – suitable for distribution • History-Based Access Control [Abadi/Fournet] • Adds expressiveness • Sweet Spot: Programming Provenance • Expressive and programmable A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

14. Type-and-Effect System • Language of effects : First-order logic fragments • Decidable entailment: i.e. does ? • Monotonic • Authorization Logics (i.e. has a “says” modality). (e.g.) Binder, SecPAL, … • Object-centric effects refer to immutable fields of objects (e.g.) if the object is an authorization token, effect can record the rights associated with these object (vs. method-centric effects) A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

15. Object-centric effects A proposition P communicated from sender to receiver, e.g., "Access permitted for …" P known Sender Receiver Pnot known ... send object ... ... receive object ... P known P known Issue: Inconsistency of local states Need worlds / contexts INSIDE logic (Sender says P) known A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

16. Object-centric effects: Creation • Effects must be validated at instantiation (i.e. global policy must logically entail the effect on class, with substitutions for fields) class C{final S foo, final T bar}[pred(foo,bar)] • When typing, effects bounded by the context; e.g., in order to type… a[new C(bam,bash)] … the policy must entail “a says pred(bam,bash)”. • For typing, an attacker is a principal who can “say anything”(e.g. if a is an attacker then “a says false”) A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

17. Object-centric effects: Creation • Examples • This class can NEVER be instantiated (except by an attacker)class C{}[false] • This one, sometimesclass C{finalint x, finalint y}[x < y]i.e. new C{w,z} typechecks only if there’s a proof of w < z • Ex. Use effect polymorphism to encode an “expect” construct[cf. Gordon/Fournet/Maffeis]class Proof<α:Pred>{}[α]expectθ = new Proof<θ>() A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

18. Object-centric effects: Transmission • Possession of an object reference releases effects • Get built-in Prov(src,tgt,data) effect automatically class C{final T fld1}[isFunny(fld1)] class D{ UnitdoSomething(C obj) { expectProv(caller,this.loc,obj) & obj.loc says isFunny(obj.fld1) } } • For example, A creates and sends C; B gets to use effect B[d:D{}] | A[d.doSomething(new C(foo))] *… | B[expect Prov(A,B,obj) & A says isFunny(foo)] A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

19. Object-centric effects: Subtyping • Inheritance conjoins effects; e.g. suppose… class D{}[α] class C extends D{}[β] … then the actual effect of C is “β˄α” • Subtyping involves entailment of effects, e.g. C<α> <: C<β> only ifα| β - A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

20. Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff

21. Policy design for content aggregation Use case: OWNER adds AGGR to ACCT. OWNER requests a summary of its balances from AGGR. AGGR requests the balance from ACCT. ACCT requests authorization from MONITOR. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

22. Example: Aggregator's Policy Aggregator's request rewriting behaviour Owner Owner's VPN Aggr's VPN Aggregator Owner's VPN Aggr's VPN Owner Owner's VPN Request Request Owner Aggregator

23. p Effects tgt: AggrVPN src: OwnerVPN payload: q AggrVPN q tgt: OwnerVPN src: Owner payload: r OwnerVPN r data: Owner Owner Policies

24. class Account{…} [ApproveBal(X) :- MONITOR says ApproveBal(X)] Policy design for content aggregation class Owner{…} [… ˄ (SubmitBal(X) :- X.data=X.loc=OWNER)] RespgetBalance(Req<SubmitBal>){ monitor.checkBalance(req, this); this.result } Unit grant(Req<ApproveBal> req){ if (req.loc == MONITOR) then expect ApproveBal(X); this.result = newResp(balance) } aggr.getAllBalances(newReq<SubmitBal>(OWNER)) Unit checkBalance(Req<SubmitBal> req, Account acct){ if (/* see paper for details */) then acct.grant(new Req<ApproveBal>(req.data)) elseacct.deny()} RespgetAllBalances(Req<SubmitBal> req){ acct.getBalance(new Req<SubmitBal>(req.data)) } class Monitor{…} [ApproveBal(X) :- OWNER says SubmitAggr(Y), ApproveAggr(Y), Y says SubmitBal(X), X.data=OWNER] classAggr{…} [SubmitBal(X) :- OWNER says SubmitBal(Y), Y.data=X.data=OWNER] A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

25. Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff

26. An attacker is any process located at the principal 1. • Attackers are free to lie about effects; thus, are completely free to construct any new objects. • Well-typed trustworthy programs are safe when combined with arbitrary (typed but untrustworthy) opponents. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects

27. Questions? SEE http://www.teasp.org/tapido for paper with full proofs. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects