information leakage analysis in mobile ambients chiara braghin, agostino cortesi, riccardo focardi...

Information Leakage Analysis in Mobile Ambients

Chiara Braghin, Agostino Cortesi, Riccardo Focardi

Dipartimento di Informatica

Università Ca’ Foscari

Venezia, Italy

Information Leakage in Mobile Ambients 2/38

Motivations

• Background:– Static Analysis Techniques (abstract interpretation,

abstract domains manipulation, LP, CLP,...)– Modelling Security Properties on Process Algebras based

Calculi• Main Issue:

– What is the impact of Static Analysis Techniques on Security Issues?

– In particular, is it possible to detect direct and indirect information leakage of a process by adopting an inference approach (eg. CFA) instead of a prescriptive one (eg. type systems)?


Outline of the Talk

1. A quick review of Mobile Ambient Calculus

2. Modeling Information Flow in a Multilevel Security Policy (the notion of Security Boundary);

3. Facing direct information leakage:• verifying information leakage by post-processing a

suitable nesting analysis • inferring security policies

4. Facing indirect information leakage:• overapproximating the perturbation set of confidential

data

5. Conclusions and Related Works.


Mobile Ambients

• Mobile Ambients (MA) [Cardelli-Gordon]

– the aim: explicitly model mobile computing (moving devices) and mobile computation (moving data and processes)

– the idea: ambient = a place where a computation may occur

– ambients are arbitrarily nested domains which can move around through suitable capabilities

– moves consume capabilities and change the nestings

– moves are subjectives (I move, but I can’t make you move)


Reduction rules: the out capability

• Consider process n [ k [ out n.P | Q ] | R ] :

P | Q

k

n

R out n.P | Q

k

n

R out n.

• The effect is to move ambient k out of n

P | Q

k

n

R

• The process becomes k [ P | Q ] | n [ R ] .


Reduction rules: the open capability

• Consider process k [ open n.P | n [Q ] ] :

Q

n

k

open n.P

• The effect is to dissolve the boundary of ambient n

Q

k

P |

• The process becomes k [ P | Q ] .


Example

venice montreal

send

out venice.in montreal

num

open send

venice [send [out venice. in montreal. num[] ] ] | montreal [open send]


Example

venice montreal

send

in montreal

num

open send

venice [] | send [in montreal. num[] ] | montreal [open send]


Example

venice montreal

send

num

open send

venice [] | montreal [open send | send [num[] ]]


next step






data



Modeling Multilevel Security

bn

ConfidentialData

b2

ConfidentialData

b1

ConfidentialData

………...

UntrustedEnvironment

bn

ConfidentialData

b2

ConfidentialData

b1

ConfidentialData

………...


• Direct Information leakage: possibility for a confidential ambient/data to be exposed to an untrusted environment.


Security Boundaries

• The intuition: classify ambients that are responsible of containing confidential data (boundaries)

– Direct information leakage may arise only through a boundary crossing by confidential data

– Direct information leakage can be detected by postprocessing a suitable nesting analysis



bn

ConfidentialData

b2

ConfidentialData

b1

ConfidentialData

………...


bn

ConfidentialData

b2

ConfidentialData

b1

ConfidentialData

………...


• Information leakage: possibility for a confidential ambient/data to move outside a security boundary.

bn

ConfidentialData

b2

ConfidentialData

b1

ConfidentialData

………...


• Information leakage: possibility for a confidential ambient/data to move outside a security boundary.

• Note: The opposite flow is allowed!



• Partition the set of ambient labels into three disjoint sets LabH, LabL and LabB, (high, low and boundary);

• Definition: P does not (directly) leak confidential data iff in every Q s.t. P * Q , every high level ambient (LabH) is always nested in a boundary ambient (LabB).


Communication among boundaries

• Reconsider the first example:– two security boundaries venice and montreal:– venice sends a credit card number to montreal:

venice [ send [ out venice. in montreal | num []] ]| montreal [ open send ]

| Q


example (ctd.)

venice montreal

send


num

open send

• Good if send is a security boundary as well!

venice montreal

send

in montreal

num

open sendvenice montreal

send

num

open sendvenice montreal

num


next step






data



Verifying Information Leakage

• The starting point: the control flow analysis by Nielson & al. aimed at modeling the ambient nesting at run- time ;

• It is defined as a set of constraints on pairs (I,H), where:– if an ambient labeled la contains a capability or

an ambient labelled l , then (la, l) belongs to I;– if ambient n is labeled la, then (la, n) belongs to

H.


Constraints of the CFA

• the constraint for capability in nℓt.P is

if (ℓ'',ℓ) I, and (ℓ'',ℓ‘)I, and (ℓ,ℓt)I, (ℓ’,n)H,then (ℓ',ℓ)I

Pin n ℓt . Pmℓ nℓ'

pℓ'' pℓ''

nℓ'

mℓ


Example (1)

• Consider again the example (now labelled):

veniceb [ sendb [ outc venice.inc montreal | numh [ ] ] ] | montrealb [ openc send ]

• The least analysis is:

I = { ( env,b ), ( b,b ), ( b,h ), ( b,c ) }H = { ( b,venice ), ( b, send ), ( b,montreal ), ( h, num ) }

• Note: h is always contained inside b: the process is secure!


Example (2)

• Example: high level data is willing to enter some filter process , which could possibly be low level code:veniceb [ sendb [ outc venice.inc montreal

| numh [inc filter ] | openc filter ] | montrealb [ openc send ] | filterm [inc send ]

• the least solution contains ( env,h ) even if there is no execution leading to such a situation !

• the analysis does not capture the fact that h enters m only after it has crossed the boundary.


A more sophisticated domain

• Solution: enhance the Control Flow Analysis for modeling the protected ambient nestings at run-time;

• It works on triplets (IB,IE,H), where:

– if a protected ambient labeled la contains a capability or an ambient labelled l , then (la, l) belongs to IB;

nla

kl

(la, l) IB

– if a capability/ambient labeled l is contained by an ambient labelled la which is not protected , (la, l) belongs to IE;

– if ambient n is labeled la, then (la, n) belongs to H.

• Theorem: if in the result of the analysis IE contains no high level label, then no direct leakage of secret data/ambients out of boundary ambients may arise at run-time.



• The CFA is defined by a representation function CF

and an analysis specification (IB,IE,H) |CF P

• Fixed Point Algorithm:

(i) Apply the representation function to process P to

get the initial triplet (IB,IE,H);

(ii) Validate each constraint in the specification on

such a triplet:– if the constraint is satisfied, continue;

– else, add the “missing” pair either to IB or IE, then go back to (ii).



• Example: the in rule - boundary crossing.

zl

kla

inlt n.P

nlb

IBIEl

la lb…...

all the nestingsbelow la

zl

kla

inlt n.P

nlb

IBIEl

la lb…...


lb

la


COPY


next step





4. Facing indirect information leakage:• extending the language with boundaries



Boundaries Inference

• The issue of direct information leakage may be seen from a different perspective:

given a process in which you know which ambients are confidential, which ambients should be labeled “boundary” in order to guarantee absence of direct information leakage?– We consider a process P where only high level

data are known;


Boundary Inference

• Algorithm:

LLii is a Label Partitioning (LabH, LabiB, Labi

L)

STEP 1: Initial Label Partitioning LL00;

STEP 2:

1.compute the fix point algorithm on LLi i ;

2.during the execution of the algorithm if a high level ambient gets in an unprotected environment:

- If possible, update the labeling and goto 2;

- otherwise, fail.

STEP 3: Refine the solution.


Boundary Inference (3)

• STEP 1: venice is labeled boundary;

• STEP 2: (send,num) and (montreal,num) are introduced into IE;

• STEP 3: there is no need to refine the solution, thus venice, montreal and send must be labeled as boundaries.

venice montreal

send


num

open send

al


last step






data



Indirect Information Leakage

• Consider this process:

containerb [ sendb [inc hdata.outc hdata. outc container ] | openc download ]

• There is no direct information leakage• However, the dependence of the process behaviour on

hdata can be observed from the outside:

sendb shows up only if hdata is present in the context


Contextual equivalence

containerb [ sendb [inc hdata.outc hdata. outc container ] | openc download ]

• Definition: Let P be a process, N a set of names, and CC a set of contexts. P does not leak secrets N to CC iff for all substitution functions N process C(P) exhibits the same ambient names as C(PN).

• Consider the context C = _ | download [inc container | hdatah [] ]

substitutions {hdata}(hdata)=hdata’, {hdata}(hdata)=hdata make C(PN) behave differently.


Indirect Information Leakage

• The Control flow analysis can be enhanced to work on tuples (C,IE,IB,H), where:

– C is the set of ambients conditioned by high level ambients (the perturbation set);

• Consider again processcontainerb [ sendb [inc hdata.outc hdata. outc container ] | openc download ]

– ambient send belongs to the perturbation set C

– ambient send is not protected (it is exposed to the possibly untrusted environment)


Verifying Indirect Information Leakage

• The result (C,IE,IB,H) of the analysis of P is significant for the set of contexts CCP,C P,C , i.e. the ones which

– pass the analysis, with (C’,I’E,I’B,H’)

– the free names shared with P are classified the same way into the perturbation sets C and C’.

• Theorem: let P be a process and consider a tuple (C,IE,IB,H) such that (C,IE,IB,H) |= P and Protected(C,(IE,IB,H)). Then, P does not leak C to CCP,CP,C..


Conclusions

• The BANANA tool (Boundary Ambient Nesting Analysis) is available online [TACAS’03]

• Current and future work:– Investigate different notions of Non-Interference

(compare with [Bugliesi-Castagna-Crafa’02])– further refine the analysis to deal with coactions

[Sangiorgi-Levi ‘01][Degano-Levi-Bodei '00];– compare with type systems approaches to variants

of mobile ambients, e.g. [Cardelli-Gordon '99] [Bugliesi-Castagna-Crafa '01];

– Model cryptographic primitives.


References

• Cortesi-Focardi, Information Flow Security in Mobile Ambients, in Proc. CONCOORD’01, Lipari, ENTCS 54(2001)

• Braghin-Cortesi-Focardi, Security Boundaries in Mobile Ambients, Computer Languages 28 (2002), pp.101-127

• Braghin-Cortesi-Focardi-van Bakel, Boundary Inference for Enforcing Security Properties, Proc. IFIP TCS ‘02, Montreal, pp. 383-395

• Braghin-Cortesi-Filippone-Focardi-Luccio-Piazza, BANANA, a Tool for Boundary Ambient Nesting ANAlysis, Proc. TACAS’03, Varsaw.

• Braghin-Cortesi-Focardi, Information Leakage Detection in Boundary Ambients, Proc. CATS’03, ENTCS 78(2003)

information leakage analysis in mobile ambients chiara braghin, agostino cortesi, riccardo focardi...

Documents