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

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

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 3

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 4

Rest of the Talk Informal introduction to calculus: dynamics Informal introduction to calculus: statics Example Sketch of formal stuff Full paper:

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

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 7

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

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 9

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 10

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

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 12

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 13

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 14

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

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 16

Object-centric effects: Creation Examples This class can NEVER be instantiated (except by an attacker) class C{}[false] This one, sometimes class C{final int x, final int 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 {}[α] expect θ = new Proof () A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 17

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{ Unit doSomething(C obj) { expect Prov(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 18

Object-centric effects: Subtyping A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 19 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 only if α| β -

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

Policy design for content aggregation A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 21 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.

Policy design for content aggregation A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 22 Intent (or meaning) of message expressed through predicates SubmitAggr : Pred(Prin) Indicates that a request to add new aggregator has been made (by the owner) ApproveAggr : Pred(Req ) Indicates that a request has been approved (by the monitor) SubmitBal : Pred(Prin) Indicates that a request for a balance has been made (by owner or aggregator) ApproveBal : Pred(Prin) Indicates that a request for a balance has been approved (by the monitor) CheckedProv : Pred(T) Indicates that the provenance of a message has been checked and approved

Policy design for content aggregation A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 23 Requests made using a request object class Req {final T data, Prin src, tgt}[pred(data,src,tgt)] Decorators used to add effects… Policy class Req1 ► Req {final Prin owner} class Req2 ► Req{final Prin reqester, r1}

24 Example: Aggregator's Policy Aggregator's request rewriting behaviour Aggr's VPNAggregatorOwnerOwner's VPN Request Owner Owner's VPN Aggr's VPN Request Aggregator

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

Policy design for content aggregation A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 26 acct.addAggr(new AggrReq(AGGR)) Unit addAggr(AddAggrReq req){ expect req.loc says SubmitAggr(req.p) /*...*/ } class Owner{…}[SubmitAggr(AGGR)…] class Account{…} [ ApproveAggr(X) :- OWNER says SubmitAggr(X) …]

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

: To indicate a principal has been submitted as an aggregator : The instantiator must be able to submit the aggregator request. The instantiator must be able to submit any balance request that it creates, so long as the data field truthfully records its identity. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 28

tgt: FORWARDER src: FORWARDER payload: r Owner OwnerVPN tgt: AGGREGATOR src: FORWARDER payload: q AggrVPN q p data: Owner r A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 29

A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 30

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

Ingredients: Object Creation A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 32

Concurrent composition via conjoining specifications cf. Gordon, Fournet, Maffeis formalization of correspondence assertions A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 33

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 34

Questions? SEE for paper with full proofs. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 35

So, what have we done? Mashups, Portlets and Web Services Trust & Authorization Privacy Delegation Audits for accountability A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 36

Our language-based approach to security Focus on semantic attacks on trust and authorization Flexible security via language methods.. A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely Trust and Authorization via Provenance and Integrity in Distributed Objects 37