Automated Verification of Security Policies in
              Mobile Code

                     Natasha Sharygina

         ...
Motivation (1)
                           GSM Network


                        9600 bps


                               ...
Motivation (2)

Mobile systems are a special case of multi-threaded distributed
programs.
Differences:
    Threads may run...
Objectives

Expressive formalism for specifying mobile systems:
    explicit specification of the thread location and locat...
Outline of Talk

Part I: Preliminaries
    Existing programming languages for mobile code
    Verification: possible techni...
State of the Art

Programming languages for mobile code:
    Special purpose languages: Telescript, Obliq, Klaim, · · ·
  ...
Software Model Checking

Software verification with model checking:
    fully automated
    diagnostic counter-examples
   ...
CEGAR-based Model Checking (1)




              Automated Verification of Security Policies in Mobile Code – p. 8/25
CEGAR-based Model Checking (2)

Build Abstract Model
    Using predicate abstraction and initial set of predicates P
Model...
Multi-threads - Classical Representation

  T    ::=                                threads
             T1 | T2          ...
Location-aware Threads (1)

 LT   ::=                                location-aware threads
        |   ℓ[ T ]
           ...
Location-aware Threads (2)

Explicit notion of location ( ℓ[ T ] ).
                               [
Ability to capture th...
Location Net - Example

Consider a system with the following set of locations:

                          Loc = {env, ℓ0 ,...
The Computational Model (1)

A location-aware thread is a Labeled Kripke Structure
T = (S, Init, AP, L, Σ, R), with:
    T...
The Computational Model (2)

Inference rules for the labeled transition relation Ri for thread Ti .
                (F ORK...
The Computational Model (3)

     The set of Σ is split into mutually disjoint sets ΣM , ΣS , ΣT , Στ ,
     representing ...
Verification of Security Policies (1)

Mandatory Access Control
    If ℓ is a location/host that contains confidential infor...
Verification of Security Policies (2)

A security policy consists of a set of rules or conditions stating which
actions are...
Verification of Security Policies (3)

A permission entry specifies which actions are denied:

            permission entry ...
Verification of Security Policies (4)

Java sandbox policy: it is responsible for protecting a number of
resources by preve...
Automated Security Verification




Program P ′ is annotated with the security invariants expressed in the
security policy;...
An Efficient Security-driven abstraction

Idea: Remove from the system the behavior not related to the
location-specific pol...
The CEGAR Loop Revisited




          Automated Verification of Security Policies in Mobile Code – p. 23/25
Experiments

    policy          time (s)   # iterations      # predicates         pv?      SATABS: pv?
    1 (sa)        ...
Conclusion

Expressive formalism for specifying mobile systems:
– it explicitly models thread location, location distribut...
Upcoming SlideShare
Loading in …5
×

20080502 software verification_sharygina_lecture03

446 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
446
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

20080502 software verification_sharygina_lecture03

  1. 1. Automated Verification of Security Policies in Mobile Code Natasha Sharygina University of Lugano, Switzerland and Carnegie Mellon University, USA Joint work with Chiara Braghin and Katerina Barone-Adesi Automated Verification of Security Policies in Mobile Code – p. 1/25
  2. 2. Motivation (1) GSM Network 9600 bps Internet GSM Phone WAN Host Base Transceiver Router Public Switched Station Telephone Network (PSTN) PCMCIA Mobile Node Data Adapter Modem Pool Mobile Services LAN Host Switching Center MODEM MODEM Dialup MODEM Server IWF MODEM LAN Formal methods are needed for the specification and verification of mobile distributed systems, focusing on security issues. Automated Verification of Security Policies in Mobile Code – p. 2/25
  3. 3. Motivation (2) Mobile systems are a special case of multi-threaded distributed programs. Differences: Threads may run in different locations (e.g., administrative domains, hosts, physical locations); Threads may migrate from one location to another; Thread communication takes into account geographical distribution: distinction among local and global (remote) communication; remote communication may be restricted by security policies (migration can occur only between directly linked net locations). Automated Verification of Security Policies in Mobile Code – p. 3/25
  4. 4. Objectives Expressive formalism for specifying mobile systems: explicit specification of the thread location and location net formalization of different synchronization and communication mechanisms Formal analysis of mobile systems by model checking of security and safety properties: not restricted to a single security policy abstraction-based approach for efficiency sound modeling of unbounded thread creation. Automated Verification of Security Policies in Mobile Code – p. 4/25
  5. 5. Outline of Talk Part I: Preliminaries Existing programming languages for mobile code Verification: possible techniques Software model checking in a nutshell Part II: Modeling Explicit notion of location Location-aware threads as LKS Part III: Verification A language for specifying different security policies A model-checking framework for verification of mobile programs A location-based efficient abstraction Automated Verification of Security Policies in Mobile Code – p. 5/25
  6. 6. State of the Art Programming languages for mobile code: Special purpose languages: Telescript, Obliq, Klaim, · · · General purpose languages: Java, C, · · · Current validation techniques: Testing and simulation Type system or Abstract Interpretation: on process algebrae (π-calculus, Mobile Ambients, Dpi, etc.) on very small fragments of programming languages Dynamic policy verification (e.g., Java sandbox) Model checking Automated Verification of Security Policies in Mobile Code – p. 6/25
  7. 7. Software Model Checking Software verification with model checking: fully automated diagnostic counter-examples state space explosion problem Different model checking techniques: explicit model checking symbolic model checking bounded model checking CEGAR-based model checking Automated Verification of Security Policies in Mobile Code – p. 7/25
  8. 8. CEGAR-based Model Checking (1) Automated Verification of Security Policies in Mobile Code – p. 8/25
  9. 9. CEGAR-based Model Checking (2) Build Abstract Model Using predicate abstraction and initial set of predicates P Model Check the abstract model Generate reachable states explicitly/symbolically Obtain a counterexample Check if the counterexample is spurious Simulate the counterexample on the concrete model Abstraction Refinement Find new predicates to add to P in order to eliminate the counterexample Use the spurious counterexample to refine the abstraction Automated Verification of Security Policies in Mobile Code – p. 9/25
  10. 10. Multi-threads - Classical Representation T ::= threads T1 | T2 parallel comp. | Instr sequential exec. Instr ::= instructions Instr1 ; Instr2 sequential exec. | x := e assignment | if (Expr != 0) Instr condition | while (Expr != 0) Instr loop | skip skip | m sync. call | fork thread creation Automated Verification of Security Policies in Mobile Code – p. 10/25
  11. 11. Location-aware Threads (1) LT ::= location-aware threads | ℓ[ T ] [ single thread | LT1 LT2 parallel composition T ::= threads T1 | T2 parallel comp. | Instr sequential exec. Instr ::= instructions Instr1 ; Instr2 sequential exec. | x := e assignment | if (Expr != 0) Instr condition | while (Expr != 0) Instr loop | skip skip | m sync. call | fork thread creation | M Instr moving instr, go in(ℓ), go out(ℓ) Automated Verification of Security Policies in Mobile Code – p. 11/25
  12. 12. Location-aware Threads (2) Explicit notion of location ( ℓ[ T ] ). [ Ability to capture the geographical distribution of the Web: location net is used to encapsulates the hierarchical nesting location net: a tree, with nodes labeled by unique location names; mobility: updates of the location net; the structure of the location net can be constrained to formalize various security policies. Ability to locate multi-threaded programs. Automated Verification of Security Policies in Mobile Code – p. 12/25
  13. 13. Location Net - Example Consider a system with the following set of locations: Loc = {env, ℓ0 , ℓ1 , ℓ2 , ℓ3 , ℓ4 }. The location net is: {env.ℓ0 .ℓ1 , env.ℓ2 , env.ℓ3 , env.ℓ4 }, which corresponds to the following tree: Automated Verification of Security Policies in Mobile Code – p. 13/25
  14. 14. The Computational Model (1) A location-aware thread is a Labeled Kripke Structure T = (S, Init, AP, L, Σ, R), with: The set of states S = (Vl , Vg , pc, ϕ, η): Vl evaluation of local variables, Vg evaluation of global variables, pc the program counter, ϕ : Loc → Loc is a partial order function denoting the location net (where Loc is the set of location names), η : N → Loc is a partial function denoting the thread location. R ⊆ S × Σ × S ∪ { S × S } is a total labeled transition relation fork notice that s − − → (s′ , s), with s′ the next state of s, and −− s = Init the initial state of the newly created thread. Automated Verification of Security Policies in Mobile Code – p. 14/25
  15. 15. The Computational Model (2) Inference rules for the labeled transition relation Ri for thread Ti . (F ORK - ACTION ) Instr(s.pc) = fork fork s − − i (s′ , s) [s′ .pc = s.pc + 1; s = Initi ] −→ (in- ACTION ) Instr(s.pc) = go in(ℓ) ∧ (∃ℓ1 s.t.: ℓ1 := s.η(i) ∧ s.ϕ(ℓ1 ) = s.ϕ(ℓ)) go_in(l) s − − − i s′ [s′ .pc = s.pc + 1; s.ϕ ∪ {ℓ → ℓ1 }] −−→ (S YNC - ACTION ) Instr(s.pc) = m m s − i s′ [s′ .pc = s.pc + 1] → Automated Verification of Security Policies in Mobile Code – p. 15/25
  16. 16. The Computational Model (3) The set of Σ is split into mutually disjoint sets ΣM , ΣS , ΣT , Στ , representing moving, synchronization, thread creation, and τ actions. The labeled transition relation for the composition of two threads T1 T2 . (S YNC - ACTION ) 1 a ′1 a ′2 a∈ ΣS 1 ∧s − 1 s ∧a∈ → ΣS 2 →2 ∧ s − 2 s ∧ s1 .η(1) = s2 .η(2) 1 2 a ′1 ′2 (s , s ) − (s , s ) → (L-PAR ) (R-PAR ) a ′1 2 a ′2 a∈ ΣM 1 ∧s− 1s → a∈ ΣM 2 ∧s − 2s → 1 2 a ′1 2 1 2 a 1 ′2 (s , s ) − 1 (s , s ) → (s , s ) − 2 (s , s ) → Automated Verification of Security Policies in Mobile Code – p. 16/25
  17. 17. Verification of Security Policies (1) Mandatory Access Control If ℓ is a location/host that contains confidential information, need to check that the information is not leaked (i.e., no write to remote locations). Information Flow If Ti is a shopping agent searching the best airfare for a flight from Lugano to London and buying it by using the user’s credit card number, need to validate to whom the threads reveals the confidential information (by exploiting the trail of the actions of the thread). “Bad” Traces If Ti is a downloaded applet, need to check for Trojan horses, i.e., sequences of malicious instructions (e.g., installing a backdoor or a keylogger). Automated Verification of Security Policies in Mobile Code – p. 17/25
  18. 18. Verification of Security Policies (2) A security policy consists of a set of rules or conditions stating which actions are prohibited in the system: policy −> { sec_levels | operation_def | deny statement } deny statement − > deny to deny_target [ code base ][ code origin ] { permission entry {, permission entry } } deny_target − > public| entity list The location may play an important role in determining access rights: code base − > codeBase IPv4 addr code origin − > codeOrigin( location | remote) location −> location_id {: location_id } Automated Verification of Security Policies in Mobile Code – p. 18/25
  19. 19. Verification of Security Policies (3) A permission entry specifies which actions are denied: permission entry − > permission action action −> function | operation In case of a function, it is possible to specify (i) formal parameters (variable names), (ii) actual parameters (the value of the arguments passed), (iii) an empty string, denying access to the function regardless of the arguments to it, or (iv) the keyword high (no high variables can be passed as arguments to this function). function − > function function_id parameters parameters −> actual par | formal par | high | ε Automated Verification of Security Policies in Mobile Code – p. 19/25
  20. 20. Verification of Security Policies (4) Java sandbox policy: it is responsible for protecting a number of resources by preventing applets from accessing the local hard disk and the network. operation read_file_system { fread, read, scanf, gets, fgets} deny to public codeOrigin remote { permission function connect_to_location, permission operation read_file_system } A naive multi-level security policy: High={confidential_var, x} deny to public codeOrigin remote { permission function fopen high} Automated Verification of Security Policies in Mobile Code – p. 20/25
  21. 21. Automated Security Verification Program P ′ is annotated with the security invariants expressed in the security policy; A security monitor function is created for each permission statement in the policy; P ′ consists of the product of P with all the monitor functions corresponding to the security policy S. Automated Verification of Security Policies in Mobile Code – p. 21/25
  22. 22. An Efficient Security-driven abstraction Idea: Remove from the system the behavior not related to the location-specific policy: Location Projection, π ↓ ℓ: thread executions for a particular location. Moving Projection, π ↓M i: all moving actions executed by thread Ti . Thread Projection, π ↓ i: all actions executed by thread Ti . Automated Verification of Security Policies in Mobile Code – p. 22/25
  23. 23. The CEGAR Loop Revisited Automated Verification of Security Policies in Mobile Code – p. 23/25
  24. 24. Experiments policy time (s) # iterations # predicates pv? SATABS: pv? 1 (sa) 151.644 7 17 yes yes 2 local (sa) 100.234 5 15 no no 2 remote (sa) 524.866 12 36 yes yes 3 codeBase (sa) 340.011 12 22 yes yes Sample policy (2(sa)): deny to public codeOrigin remote { permission function fopen "/etc/passwd"} Automated Verification of Security Policies in Mobile Code – p. 24/25
  25. 25. Conclusion Expressive formalism for specifying mobile systems: – it explicitly models thread location, location distribution and thread moving operations; – it preserves both data and communication structures of mobile systems. Specification language for specifying security policies of mobile code: – information flow; – access control policies; Integrated model checking framework to support exhaustive analysis of security policies; Location-specific abstractions enable the efficient verification of large mobile code applications. Automated Verification of Security Policies in Mobile Code – p. 25/25

×