1. Information Leakage Analysis in Mobile Ambients Chiara Braghin, Agostino Cortesi, Riccardo Focardi Dipartimento di Informatica Università Ca’ Foscari Venezia, Italy

2. 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)?

3. Information Leakage in Mobile Ambients 3/38 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.

4. Information Leakage in Mobile Ambients 4/38 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)

5. Information Leakage in Mobile Ambients 5/38 “Core” Mobile Ambients Syntax of the core Mobile Ambient Calculus: P, Q :: = ( n ) P restriction | 0 inactivity | P | Q composition | ! P replication | n [P] ambient | in n.P capability to enter n | out n.P capability to exit n | open n.P capability to open n P, Q :: = ( n ) P restriction | 0 inactivity | P | Q composition | ! P replication | n la [P] ambient | in lt n.P capability to enter n | out lt n.P capability to exit n | open lt n.P capability to open n Plus labels on ambients/capabilities to “classify” them.

6. Information Leakage in Mobile Ambients 6/38 Reduction rules: the in capability Consider process k [ in n.P | Q ] | n[ R ] : in n.P | Q k n R k n R k n R k n R The effect is to move ambient k inside n in n.P | Q k n R P | Q k n R The effect is to move ambient k inside n The process becomes n[ k [ P | Q ] | R ].

7. Information Leakage in Mobile Ambients 7/38 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 ].

8. Information Leakage in Mobile Ambients 8/38 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 ].

9. Information Leakage in Mobile Ambients 9/38 Example venicemontreal send out venice. in montreal num open send venice [send [out venice. in montreal. num[] ] ] | montreal [open send]

10. Information Leakage in Mobile Ambients 10/38 Example venicemontreal send in montreal num open send venice [] | send [in montreal. num[] ] | montreal [open send]

11. Information Leakage in Mobile Ambients 11/38 Example venicemontreal send num open send venice [] | montreal [open send | send [num[] ]]

12. Information Leakage in Mobile Ambients 12/38 Example venice montreal num venice [send [out venice. in montreal. num[] ] ] | montreal [open send]  venice [] | send [in montreal. num[] ] | montreal [open send]  venice [] | montreal [open send | send [num[] ]]  venice [] | montreal [ num[] ]

13. Information Leakage in Mobile Ambients 13/38 next step 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.

14. Information Leakage in Mobile Ambients 14/38 Modeling Multilevel Security bn Confidential Data b2 Confidential Data b1 Confidential Data ………... Untrusted Environment bn Confidential Data b2 Confidential Data b1 Confidential Data ………... Untrusted Environment Direct Information leakage: possibility for a confidential ambient/data to be exposed to an untrusted environment.

15. Information Leakage in Mobile Ambients 15/38 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

16. Information Leakage in Mobile Ambients 16/38 Modeling Multilevel Security bn Confidential Data b2 Confidential Data b1 Confidential Data ………... Untrusted Environment bn Confidential Data b2 Confidential Data b1 Confidential Data ………... Untrusted Environment Information leakage: possibility for a confidential ambient/data to move outside a security boundary. bn Confidential Data b2 Confidential Data b1 Confidential Data ………... Untrusted Environment Information leakage: possibility for a confidential ambient/data to move outside a security boundary. Note: The opposite flow is allowed!

17. Information Leakage in Mobile Ambients 17/38 Modeling Multilevel Security Partition the set of ambient labels into three disjoint sets Lab H, Lab L and Lab B, (high, low and boundary); Definition: P does not (directly) leak confidential data iff in every Q s.t. P  * Q, every high level ambient (Lab H ) is always nested in a boundary ambient (Lab B ).

18. Information Leakage in Mobile Ambients 18/38 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| Q

19. Information Leakage in Mobile Ambients 19/38 example (ctd.) venicemontreal send out venice. in montreal num open send Good if send is a security boundary as well! venicemontreal send in montreal num open send venicemontreal send num open send venicemontreal num

20. Information Leakage in Mobile Ambients 20/38 next step 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.

21. Information Leakage in Mobile Ambients 21/38 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 l a contains a capability or an ambient labelled l, then (l a, l) belongs to I; –if ambient n is labeled l a, then (l a, n) belongs to H.

22. Information Leakage in Mobile Ambients 22/38 Constraints of the CFA the constraint for capability in n ℓ t. P is if (ℓ'',ℓ)  I, and (ℓ'',ℓ‘)  I, and (ℓ,ℓ t )  I, (ℓ’,n)  H, then (ℓ',ℓ)  I P in n ℓ t. P mℓmℓ n ℓ' p ℓ'' n ℓ' mℓmℓ

23. Information Leakage in Mobile Ambients 23/38 Example (1) Consider again the example (now labelled): venice b [ send b [ out c venice.in c montreal | num h [ ] ] ] | montreal b [ open c 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!

24. Information Leakage in Mobile Ambients 24/38 Example (2) Example: high level data is willing to enter some filter process, which could possibly be low level code: venice b [ send b [ out c venice.in c montreal | num h [in c filter ] | open c filter ] | montreal b [ open c send ] | filter m [in c 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.

25. Information Leakage in Mobile Ambients 25/38 A more sophisticated domain Solution: enhance the Control Flow Analysis for modeling the protected ambient nestings at run-time; It works on triplets (I B,I E,H), where: –if a protected ambient labeled l a contains a capability or an ambient labelled l, then (l a, l) belongs to I B ; n la klkl (l a, l)  I B –if a capability/ambient labeled l is contained by an ambient labelled l a which is not protected, (l a, l) belongs to I E ; –if ambient n is labeled l a, then (l a, n) belongs to H. Theorem: if in the result of the analysis I E contains no high level label, then no direct leakage of secret data/ambients out of boundary ambients may arise at run-time.

26. Information Leakage in Mobile Ambients 26/38 Verifying Information Leakage The CFA is defined by a representation function  CF and an analysis specification (I B,I E,H) |  CF P Fixed Point Algorithm: (i) Apply the representation function to process P to get the initial triplet (I B,I E,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 I B or I E, then go back to (ii).

27. Information Leakage in Mobile Ambients 27/38 Verifying Information Leakage Example: the in rule - boundary crossing. zlzl k la in lt n.P n lb IBIB IEIE l lalb …... all the nestings below la zlzl k la in lt n.P n lb IBIB IEIE l lalb …... all the nestings below la lb la all the nestings below la COPY

28. Information Leakage in Mobile Ambients 28/38 next step 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: extending the language with boundaries 5.Conclusions and Related Works.

29. Information Leakage in Mobile Ambients 29/38 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;

30. Information Leakage in Mobile Ambients 30/38 Boundary Inference Algorithm: L i L i is a Label Partitioning (Lab H, Lab i B, Lab i L ) L 0 STEP 1: Initial Label Partitioning L 0 ; STEP 2: L i 1.compute the fix point algorithm on L 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.

31. Information Leakage in Mobile Ambients 31/38 Boundary Inference (3) STEP 1: venice is labeled boundary; STEP 2: ( send, num ) and ( montreal, num ) are introduced into I E ; STEP 3: there is no need to refine the solution, thus venice, montreal and send must be labeled as boundaries. venicemontreal send out venice. in montreal num open send al

32. Information Leakage in Mobile Ambients 32/38 last step 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.

33. Information Leakage in Mobile Ambients 33/38 Indirect Information Leakage Consider this process: container b [ send b [in c hdata.out c hdata. out c container ] | open c download ] There is no direct information leakage However, the dependence of the process behaviour on hdata can be observed from the outside: send b shows up only if hdata is present in the context

34. Information Leakage in Mobile Ambients 34/38 Contextual equivalence container b [ send b [in c hdata.out c hdata. out c container ] | open c download ] C CDefinition: Let P be a process, N a set of names, and C a set of contexts. P does not leak secrets N to C iff for all substitution functions  N process C (P) exhibits the same ambient names as C (P  N ). Consider the context C = _ | download [in c container | hdata h [] ] substitutions  {hdata} (hdata)=hdata’,  {hdata} (hdata)=hdata make C (P  N ) behave differently.

35. Information Leakage in Mobile Ambients 35/38 Indirect Information Leakage The Control flow analysis can be enhanced to work on tuples (C,I E,I B,H), where: –C is the set of ambients conditioned by high level ambients (the perturbation set); Consider again process container b [ send b [in c hdata.out c hdata. out c container ] | open c download ] –ambient send belongs to the perturbation set C –ambient send is not protected (it is exposed to the possibly untrusted environment)

36. Information Leakage in Mobile Ambients 36/38 Verifying Indirect Information Leakage C P,CThe result (C,I E,I B,H) of the analysis of P is significant for the set of contexts 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’. C P,C.Theorem: let P be a process and consider a tuple (C,I E,I B,H) such that (C,I E,I B,H) |= P and Protected(C,(I E,I B,H)). Then, P does not leak C to C P,C.

37. Information Leakage in Mobile Ambients 37/38 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.

38. Information Leakage in Mobile Ambients 38/38 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)