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
25
Embed
Software Verification, весна 2008: Automated verification of security policies in mobile code
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Automated Verification of Security Policies inMobile 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
Motivation (1)
GSMPhone
Mobile Node DataAdapter
PCMCIA
GSM Network
Modem Pool
LAN
LAN Host
9600 bps
MODEM
MODEM
DialupServer
Router
WAN Host
BaseTransceiverStation
Mobile ServicesSwitching Center
IWF MODEM
MODEM
Public Switched Telephone Network (PSTN)
Internet
Formal methods are needed for the specification and verification ofmobile distributed systems, focusing onsecurity issues.
Automated Verification of Security Policies in Mobile Code – p. 2/25
Motivation (2)
Mobile systems are aspecial case of multi-threaded distributedprograms.
Differences:Threads may run in different locations (e.g., administrativedomains, hosts, physical locations);Threads may migrate from one location to another;Thread communication takes into account geographicaldistribution:
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
Objectives
Expressive formalism for specifying mobile systems:explicit specification of thethread locationandlocation netformalization of different synchronization and communicationmechanisms
Formal analysis of mobile systems by model checking of security andsafety properties:
not restricted to a single security policyabstraction-based approach for efficiencysound modeling of unbounded thread creation.
Automated Verification of Security Policies in Mobile Code – p. 4/25
Outline of Talk
Part I: PreliminariesExisting programming languages for mobile codeVerification: possible techniquesSoftware model checking in a nutshell
Part II:ModelingExplicit notion of locationLocation-aware threads as LKS
Part III: VerificationA language for specifying different security policiesA model-checking framework for verification of mobile programsA location-based efficient abstraction
Automated Verification of Security Policies in Mobile Code – p. 5/25
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
Location-aware Threads (2)
Explicit notion oflocation( ℓ[[T ]] ).
Ability to capture the geographical distribution of the Web:location netis used to encapsulates the hierarchical nesting
location net: a tree, with nodes labeled by unique locationnames;mobility: updates of the location net;
the structure of the location net can be constrained to formalizevarious security policies.
Ability to locate multi-threaded programs.
Automated Verification of Security Policies in Mobile Code – p. 12/25
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
The Computational Model (1)
A location-aware thread is a Labeled Kripke StructureT = (S, Init, AP,L,Σ,R), with:
The set of statesS = (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 thelocationnet (whereLoc is the set of location names),η : N → Loc is a partial function denoting thethread location.
R ⊆ S × Σ × S ∪ { S × S } is a totallabeledtransition relation
notice thatsfork−−−−→ (s′, s), with s′ the next state ofs, and
s = Init the initial state of the newly created thread.
Automated Verification of Security Policies in Mobile Code – p. 14/25
The Computational Model (2)
Inference rules for the labeled transition relationRi for threadTi.
Automated Verification of Security Policies in Mobile Code – p. 15/25
The Computational Model (3)
The set ofΣ is split into mutually disjoint setsΣM , ΣS, ΣT , Στ ,representingmoving, synchronization, thread creation, andτ actions.
The labeled transition relation for the composition of two threadsT1 ‖ T2.
(SYNC-ACTION)
a ∈ ΣS1 ∧ s1 a
−→ 1 s′1∧ a ∈ ΣS
2 ∧ s2 a−→ 2 s
′2∧ s1.η(1) = s2.η(2)
(s1, s2)a−→ (s
′1, s
′2)
(L-PAR)
a ∈ ΣM1 ∧ s
a−→ 1 s
′1
(s1, s2)a
−→ 1 (s′1, s2)
(R-PAR)
a ∈ ΣM2 ∧ s2 a
−→ 2 s′2
(s1, s2)a
−→ 2 (s1, s′2
)
Automated Verification of Security Policies in Mobile Code – p. 16/25
Verification of Security Policies (1)
Mandatory Access ControlIf ℓ is a location/host that contains confidential information,need tocheck that the information is not leaked (i.e., no write to remotelocations).
Information FlowIf Ti is a shopping agent searching the best airfare for a flight fromLugano to London and buying it by using the user’s credit cardnumber, need to validate to whom the threads reveals theconfidential information (by exploiting the trail of the actions of thethread).
“Bad” TracesIf Ti is a downloaded applet, need to check for Trojan horses, i.e.,sequences of malicious instructions (e.g., installing a backdoor or akeylogger).
Automated Verification of Security Policies in Mobile Code – p. 17/25
Verification of Security Policies (2)
A security policy consists of a set of rules or conditions stating whichactions are prohibited in the system:
〈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
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 argumentspassed),(iii) an empty string, denying access to the function regardlessof the arguments to it, or(iv) the keywordhigh (no high variables canbe passed as arguments to this function).
〈function〉 − > function 〈function_id〉 〈parameters〉
Automated Verification of Security Policies in Mobile Code – p. 20/25
Automated Security Verification
ProgramP ′ is annotated with the security invariants expressed in thesecurity policy;
A security monitor function is created for each permission statement inthe policy;
P ′ consists of the product ofP with all the monitor functionscorresponding to the security policyS.
Automated Verification of Security Policies in Mobile Code – p. 21/25
An Efficient Security-driven abstraction
Idea: Remove from the system the behavior not related to thelocation-specific policy:
Location Projection, π ↓ ℓ: thread executions for a particularlocation.Moving Projection, π ↓M i: all movingactions executed by threadTi.Thread Projection, π ↓ i: all actions executed by threadTi.
Automated Verification of Security Policies in Mobile Code – p. 22/25
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) 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
Conclusion
Expressive formalism for specifying mobile systems:– it explicitly models thread location, location distribution and threadmoving operations;– it preserves both data and communication structures of mobilesystems.
Specification language for specifying security policies ofmobile code:– information flow;– access control policies;
Integrated model checking framework to support exhaustiveanalysis ofsecurity policies;
Location-specific abstractions enable the efficient verification of largemobile code applications.
Automated Verification of Security Policies in Mobile Code – p. 25/25