Trust and Authorization via Provenance
and Integrity in Distributed Objects
Andy Cirillo
James Riely
Radha Jagadeesan
Corin Pitcher
School of CTI, DePaul University. Chicago.
An Example: Content Aggregation
Security
Concerns:
1.
Owner
adds Aggregator to Account(s)
•Content
Aggregators
•2.Trust
& Authorization
Owner
asks Aggregator
for summary
of balances
•Financial
Services,
e.g.
Mint,
Yodlee
• Privacy
Provenance
3.
Aggregator
requests
balance
from
Account(s)
• Delegation
•Mashups, Web Services
4.
Aggregator
returns aggregate balance
• Audits
for accountability
}
2
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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”)
3
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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
4
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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
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
7
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Calculus: Located Objects
 Objects located at site of creation
 Object reference preserves provenance of creator
8
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Calculus: Integrity via opsem
Method executes under authority of object.
The special variable caller is bound to calling principal.
9
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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
10
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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
12
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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
13
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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)
14
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Object-centric effects
A proposition P communicated from sender to receiver, e.g., "Access
permitted for …"
P known
Sender
Receiver
...
...
send object
receive object
...
...
P known
Issue: Inconsistency of local states
Need worlds / contexts INSIDE logic
15
P not known
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
P known
(Sender says P) known
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”)
16
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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<α:Pred>{}[α]
expect θ = new Proof<θ>()
17
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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)]
18
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
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<α>
19
<:
C<β> only if α|- β
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Rest of the Talk
Informal introduction to calculus: dynamics
Informal introduction to calculus: statics
Example
Sketch of formal stuff
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.
21
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Example: Aggregator's Policy
Aggregator's request rewriting behaviour
Owner
Owner's VPN
24
Owner's VPN
Aggr's VPN
Aggregator
Aggr's VPN
Owner
Owner's VPN
Request
Owner
Request
Aggregator
p
tgt: AggrVPN
src: OwnerVPN
payload: q
Effects
AggrVPN
q
tgt: OwnerVPN
src: Owner
payload: r
OwnerVPN
r
data: Owner
Owner
Policies
25
class Account{…}
[ApproveBal(X) :- MONITOR says ApproveBal(X)]
class Owner{…}
Unit
req){
[… ˄ grant(Req<ApproveBal>
(SubmitBal(X) :- X.data=X.loc=OWNER)]
Resp
getBalance(Req<SubmitBal>){
if
(req.loc == MONITOR) then
monitor.checkBalance(req,
this); this.result
expect ApproveBal(X);
}
aggr.getAllBalances(new
Req<SubmitBal>(OWNER))
this.result = new Resp(balance)
}
Policy design for content aggregation
Unit checkBalance(Req<SubmitBal> req, Account acct){
if (/*
see paper for details */) then
Resp
getAllBalances(Req<SubmitBal>
req){
acct.grant(new
Req<ApproveBal>(req.data))
acct.getBalance(new Req<SubmitBal>(req.data))
} else acct.deny()}
27
class Monitor{…}
class
Aggr{…}
[ApproveBal(X)
:- and
OWNER
A. Cirillo,
R. Jagadeesan, C. Pitcher
J. Riely says SubmitAggr(Y), ApproveAggr(Y),
[SubmitBal(X)
:- OWNER
says
Y.data=X.data=OWNER]
Trust
and Authorization via Provenance
Integrity
inSubmitBal(Y),
Distributed Objects X.data=OWNER]
Y and
says
SubmitBal(X),
Rest of the Talk
Informal introduction to calculus: dynamics
Informal introduction to calculus: statics
Example
Sketch of formal stuff
•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.
34
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects
Questions?
SEE
http://www.teasp.org/tapido
for paper with full proofs.
35
A. Cirillo, R. Jagadeesan, C. Pitcher and J. Riely
Trust and Authorization via Provenance and Integrity in Distributed Objects