Bring Your Own Device, Securely∗

Alessandro ArmandoFondazione Bruno Kessler

Trento, Italyarmando@fbk.eu

Gabriele CostaLuca Verderame

Università degli Studi diGenova

Genova, Italyname.surname@unige.it

Alessio MerloUniversità E-Campus

Novedrate, Italyalessio.merlo@uniecampus.it

ABSTRACTModern mobile devices offer users powerful computational capa-bilities and complete customization. As a matter of fact, todaysmartphones and tablets have remarkable hardware profiles and acornucopia of applications. Yet, the security mechanisms offeredby most popular mobile operating systems offer only limited pro-tection to the threats posed by malicious applications that may beinadvertently installed by the users and therefore they do not meetthe security standards required in corporate environments. In thispaper we propose a security framework for mobile devices that en-sures that only applications complying with the organization secu-rity policy can be installed. This is done by inferring behavioralmodels from applications and by validating them against the secu-rity policy. We also present BYODroid, a prototype implementa-tion of our proposed security framework for the Android OS.

Categories and Subject DescriptorsD.2.4 [Operating Systems]: Software/Program Verification; D.4.6[Operating Systems]: Security and Protection—Information flowcontrols; K.4.3 [Computer and Society]: Organizational Impacts—Employment

General TermsProgramming Framework, Type and Effect System, Policy Man-agement and Verification

KeywordsAndroid Security, BYOD, History Expression, BYODroid

1. INTRODUCTION∗This paper is an extended version of the paper A. Armando, G.Costa, A. Merlo, L. Verderame, Bring Your Own Device, Se-curely. to appear in Proc. of the 28th ACM Symposium onApplied Computing, Security Track (SAC 2013), March 18-22,2013, Coimbra, Portugal, Vol 2, pp. 1852–1859. Please cite thispaper as previously indicated.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’13 March 18-22, 2013, Coimbra, Portugal.Copyright 2013 ACM 978-1-4503-1656-9/13/03 ...$10.00.

The diffusion of smartphones and tablet PCs is leading to a para-digm shift in the way terminal devices are used and administeredin organizations. There is a growing pressure to let devices ownedby the individual users to get access to the corporate network andthus to the definition and enforcement of so-called “Bring YourOwn Device” (BYOD) policies.1 On the one hand, BYOD policiesmust let the users customize their devices to their specific needs andpreferences by downloading and installing applications from appli-cation stores. On the other hand, they must also counter the threatposed by malicious applications inadvertently installed by the userssince they could jeopardize the confidentiality and/or the integrityof corporate data. The security mechanisms offered by the mostpopular mobile operating systems (e.g. sandboxing) offer only lim-ited protection to this kind of threats and do not support the levelof sophistication needed in corporate environments. To illustrate,consider the scenario where the devices must satisfy a security pol-icy stating that “devices cannot access the network after using localfile system in the same session”. When a user, willing to complywith this policy, installs a new application, he checks the policy de-clared by the application (e.g. the application manifest in Android)and refrains from installing applications that declare both activities(although he cannot be sure if they are indeed unsafe). However, hecannot possibly take a decision about applications that only requireone of the two permissions since no information about possible in-teractions between the new application and those already installedcan be drawn from the manifest. As a consequence, the user canonly decide to avoid suspicious applications (i.e., those using thefile system or the network) or take the risk to install some of them(which could lead to violation of the security policy of the organi-zation).

In this paper we describe a security framework, previously intro-duced in [3], for mobile devices that ensures that only applicationsthat comply with the organization security policy are installed onthe registered devices. The framework consists of:

• a security policy manager that mediates access to the appli-cations stores by (i) keeping track of the security state of theregistered devices and (ii) determining whether an applica-tion can be safely added to a device, and

• an installer application that tells the user which applicationscan be safely installed, which need further scrutiny by the se-curity policy manager, and finally which are known to violatethe security policy.

The security state of a device is represented by a customized se-curity policy P ′ obtained by simplifying P w.r.t. the applications1http://www.cmswire.com/cms/information-management/gartner-enterprises-must-develop-bringyourowndevice-byod-policies-017148.php

currently installed on it. The simplification is carried out by partialmodel checking [2]. Checking whether an application can be in-stalled on a device (whose current security state is represented bya policy P ′) is done by (i) inspecting the code of the applicationand computing an expression (called history expression) represent-ing an overapproximation of the execution traces of the applica-tion and then by (ii) determining whether all execution traces in theoverapproximation satisfy P ′.

The paper is structured as follows. In the next section we de-scribe the programming framework. In Section 3 we present atype and effect system which allows us to infer history expressionsfrom application implementations. In Section 4 we define a pol-icy specification language for security verification and managementand show how history expressions can be validated against policiesspecifications. In Section 5 we present BOYDroid, a prototype im-plementation of the proposed security framework. In Section 6 wediscuss the related works and we conclude in Section 7 with somefinal remarks.

2. PROGRAMMING FRAMEWORKIn this section we present an extension of Featherweight Java

(FJ) [12]. In particular, we enrich the original language with fa-cilities for defining native Android application-to-application com-munications. Also, by providing a minimal core calculus for Javaapplications, FJ allows to reason in a pure framework and focus onsecurity relevant aspects without neglecting the core features of theprogramming language.

The syntax of the language is given in Table 1.

Table 1: Syntax of applications and componentsL ::= class C extends C′ {D f; K M} ClassK ::= C(D x){super(x) ; this.f := x ; } ConstructorM ::= C m(D x){returnE; } MethodE ::= null | u | x | new C(E) | E.f | Expressions

E.m(E′) | systemσ E | E;E′ | (C)E |if (E = E′){Ett} else {Eff } | thread {E} in {E′} |Iα(E) | icastE | ecast CE | E.data

A class C, possibly extending C′, declaration contains a list oftyped (D) fields f, a constructor K and a set of methods M. A con-structor K consists of its class C, a list of typed parameters x anda body. The body of the constructor contains an invocation to theconstructor of the superclass super and a sequence of assignmentsof the parameters to the class fields. Methods declarations have asignature and a body. The signature identifies the method by meansof its return type C (we write void when no object is returned), itsname m and its typed parameters x. Instead, the method body con-tains an expression E whose computation provides the return value.Finally, expressions can be either the void value null, a systemresource u2, a variable x, an object creation new C(E), a field ac-cess E.f, a method invocation E.m(E′), a system call systemσ E,a sequence of two expressions E;E′, a type cast (C)E, a condi-tional branch if (E = E′){Ett} else {Eff } or a thread creationthread {E} in {E′}. Android-specific expressions are defined,namely the intent creation Iα(E), implicit or explicit intent prop-agation (icastE and ecast CE, respectively), an intent contentreading E.data. Intents correspond to messages that applicationsexchange in order to communicate.

2Resources belong to the class Uri and we can use spe-cially formatted strings, e.g., ”http : //site.com” or”file : //dir/file.txt”, to uniquely identify them.

EXAMPLE 1. Consider the following classesclass Browser extends Receiver {Browser() { super(); }void receive(Iwwwi) { return systemconnect i.data; }

}class Game {Game() { super(); }void start() { return systemread ∼ /sav;

if(UsrAct = TouchAD)then {icast Iwww(”http : //ad.com”) }else {/ ∗ ...play... ∗ /systemwrite ∼ /sav; } ;

}}

The class Browser is a receiver for intents www. Method receive,when triggered, connects to the url carried by the incoming in-tent. Class Game implements a stand-alone application (we assumemethod start to act as entry point). Its first step consists in read-ing the content of a file ∼ /sav. Then, its execution can take twodifferent branches (for our purposes the terms in the guard areirrelevant). If users clicks on an in-game advertisement, an www

intent containing a url is fired. Otherwise, the game begins and,eventually, the file ∼ /sav is written.

Operational semanticsThe behavior of programs follows a small step semantics. We re-port some of the semantic rules in Table 2. Rules are of the typeω,E → ω′, E′ where ω, ω′ are sequences of system calls per-formed by the execution, namely execution histories, and E,E′

are expressions. A rule ω,E → ω′, E′ says that a configurationω,E can perform a computation step and reduce to ω′, E′.

Table 2: Semantics of expressions (fragment)

(PAR1)ω,E → ω′, E′′

ω, thread {E} in {E′} → ω′, thread {E′′} in {E′}

(PAR3) ω, thread {v} in {v′} → ω, v′

(SYS2) ω, systemσ u → ω · σ(u), null

(METH3)mbody(m, C) = x,E

ω, (new C(v)).m(v′) → ω,E[v′/x, (new C(v))/this]

(EXPC2)newC(v) ∈ receiver(α)

ω, ecast C Iα(u) → ω, (newC(v)).receive(Iα(u))

(IMPC2)newC(v) ∈ receiver(α)

ω, icast Iα(u) → ω, newC(v).receive(Iα(u))

Intuitively, rule (PAR1) says that the first of two threads E canmake a step and reduce to E′′ extending the shared history ω toω′. Needless to say, rule (PAR2) (not reported here) is symmetric to(PAR1). Rule (PAR3) can be applied when both the threads have re-duced to a value and says that only one of them is returned, i.e., v′.When a system call is performed (rule (SYS2)), the current historyω is extended by appending the symbol σ(u). A method invocationrequires the target object and the actual parameters to be reducedto values, then rule (METH3) can be applied. Briefly, it reduces themethod invocation to the evaluation of the method body E wherethe formal parameters have been replaced by the actual ones (alsoincluding the special variable this). Note that the function mbody,

returning the body and parameters names of a method, also dealswith methods lookup (see [12] for more details). Finally, we haverules for explicit (EXPC2) and implicit (IMPC2) intents propagation.Firing an explicit intent causes the system to check whether thereexists a receiver newC(v) of the specified class, then the config-uration reduces to the execution of the special method receive3.Implicit intents are handled in a similar way. The only difference isthat the receiver’s class C is not fixed by the rule and the system isresponsible for generating it. In both cases, if no suitable receiverexists, the expressions reduce to null.

We informally describe the behavior of the other expressions un-der the rules of our operational semantics. The expression new C(E)accepts reductions for the expressions in E (in the specified order),until they all reduce to values. A field access E.f reduces alongwith E and, when E is an object value, reduces to the correspond-ing field value. Intents Iα(E) can reduce until their data expressionE is a value which can be accessed through E.data. A sequenceE;E′ behaves like E as long as it is not a value (which is dis-charged) and then behaves like E′. Class cast (C)E can reducealong with E and, when E reduces to an object, the cast operatorcan be removed if it is an instance of a subclass of C. Finally, theconditional branch admits reductions for the expressions makingits guard (E before E′) and then reduces to one between Ett , if theequality check succeeds, and Eff , otherwise.

EXAMPLE 2. Consider again the classes of Example 1. Wesimulate the computation of

E.= icast Iwww(”http : //site.org”)

starting from the empty history and assuming the class Browser tobe the only receiver in the system.

·, icast Iwww(”http : //site.org”) →·, systemconnect Iwww(”http : //site.org”).data; → (1)

·, systemconnect ”http : //site.org”; →systemconnect ”http : //site.org”, null (2)

The initial reduction step (1) corresponds to an implicit intentcasting operation. Since Browser is the only valid receiver forwww, the execution reduces to the body of its method receive

(see Example 1) where the formal parameter has been replaced bythe actual one. Finally, in (2) the data carried by the intent is ex-tracted (left side) and used (right side) to fire a new system call, i.e.,connect.

3. TYPE AND EFFECTA type and effect system for FJ has been previously described

in [19]. We extend it with rules for handling Android-specific in-structions, e.g., for intents management.

History expressionsThe type and effect system extracts history expressions from pro-grams. History expressions model computational agents in a pro-cess algebraic fashion in terms of the traces of events they produce.The syntax of history expressions follows.

DEFINITION 1. (Syntax of history expressions)

H,H ′ ::= ε | h | αχ(u) | αCh.H | σ(u) |H ·H ′ | H +H ′ | H ∥ H ′ | µh.H

3We reserve the keyword Iα for the type of the parameter ofmethod receive

Table 3: Semantics of history expressions

σ(u)σ(u)−−−→ ε αχ(u)

αχ(u)−−−−→ ε

Hαχ(u)−−−−→ H′′ H =

∑H′{α?(u)/h} s.t. αCh.H′ ∈ ρ(α) and χ < C

H·−→ H

H′ a−→ H′′

H ∥ H′ a−→ H ∥ H′′

Ha−→ H′′

H ∥ H′ a−→ H′′ ∥ H′

Ha−→ H′′

H · H′ a−→ H′′ · H′

Ha−→ H′′

H + H′ a−→ H′′

H′ a−→ H′′

H + H′ a−→ H′′

H{µh.H/h} a−→ H′

µh.Ha−→ H′

Briefly, they can be empty ε, variables h, h′, intent emissionsαχ(u) (with χ ∈ {C, ?}), intent receptions αCh.H , system ac-cesses σ(u), sequences H ·H ′, choices H+H ′, parallel executionsH ∥ H ′ or recursions µh.H .

The semantics of history expressions is defined through a la-belled transition system (LTS) according to the rules in Table 3.

Roughly, a system access σ(u) (rule system) fires a correspond-ing event and reduces to ε. Similarly, a intent generation αχ(u)(rule intent) causes a event and reduces to ε. Intent exchange re-quires a receiver αCh.H

′ to be compatible with the intent destina-tion χ. Compatibility is checked through the relation · < · (s.t. forall C, C < C and ? < C). The function ρ is analogous to receiverand we will describe how it is structured below. Concurrent agentsH ∥ H ′ admit either a reduction for left or right component (rulesl-parallel, r-parallel). A sequence H · H ′ behaves like H until itreduces to ε and then reduces to H ′ (rule sequence). Instead, thenon deterministic choice H + H ′ can behave like either H or H ′

(rule choice). Finally, recursion µh.H has the same behavior asH where the free instances of h are replaced by µh.H (rule recur-sion). When necessary, we also write H ω−→

∗H ′ as a shorthand for

Ha1−→ . . .

an−−→ H ′ with ω = a1 · · · an.Moreover, we define a partial relation order over history expres-

sions, denoted by ⊑ and defined as: H ⊑ H ′ iff Ha1−→ . . .

an−−→H ′′ implies there exists H s.t. H ′ a1−→ . . .

an−−→ H . Also, we canwrite H ≡ H ′ as a shorthand for H ⊑ H ′ and H ′ ⊑ H (see [6]for more details).

Type and effect systemBefore presenting our type and effect system, we need to introducethe two preliminary definitions of types and type environment.

DEFINITION 2. (Types and type environment)

τ, τ ′ ::= 1 | U | Iα(U) | C Γ,Γ′ ::= ∅ | Γ{τ/x}

Types can be the unit one 1, a set of resources U , a intent typeIα(U) or a class type C. Instead, a type environment is a mappingfrom variables to types.

We can now present the typing rules of our type and effect sys-tem. A typing judgment has the form Γ ⊢ E : τ ◃H and we read it“under environment Γ, the expression E has type τ and effect H”.

Table 4 reports some rules of interest. Implicit intent castinghas type unit and effect H ·

∑u∈U

α?(u) where H is obtained by

typing the intent expression E and∑u∈U

α?(u) is an abbreviation

for α?(u1) + . . . + α?(un) with U = {u1, . . . , un}. The rule forexplicit intents is similar, but it uses the receiver class C instead of

Table 4: Typing rules (fragment)

(T−IMPC)Γ ⊢ E : Iα(U) ◃ H

Γ ⊢ icastE : 1 ◃ H ·∑

u∈Uα?(u)

(T−EXPC)Γ ⊢ E : Iα(U) ◃ H

Γ ⊢ ecast CE : 1 ◃ H ·∑

u∈UαC(u)

(T−METH)Γ ⊢ E : C ◃ H Γ ⊢ E′ : D′ ◃ H′ mbody(m, C) = x, E′′ [C/this, D′/x] ⊢ E′′ : F ′ ◃ H′′ msign(m, C) = D → F D′ → F ′ <:D → F

Γ ⊢ E.m(E′) : F ′ ◃ H · H′ · H′′

(T−SYS)Γ ⊢ E : U ◃ H

Γ ⊢ systemσ E : 1 ◃ H ·∑

u∈Uσ(u)

(T−PAR)Γ ⊢ E : C ◃ H Γ ⊢ E′ : C′ ◃ H′

Γ ⊢ thread {E} in {E′} : C′ ◃ H ∥ H′(T−WKN)

Γ ⊢ E : C ◃ H′ H′ ⊑ H

Γ ⊢ E : C ◃ H

the wild card ? to label the intents.Method invocations, rule (T−METH) require more attention. We

state that the invocation E.m(E′) has type F ′ and effect H ·H ′ ·H ′′

where F ′ is the the type of the return expression E′′, H is theeffect generated by E, H ′ the effect for E′ and H ′′ for E′′. Also,note that E′′ is typed under the environment [C/this, D′/x] andthe function msign(m, C) returns the signature of a method, i.e.,C → D for a method declaring input type C and return type D4

(for the definition of the subtype relation <: see [12]).System calls (T−SYS) have unit type 1 and their effect corre-

spond to effect for their parameter E followed by the choice amongall the valid instantiation of the access event σ. Instead, concurrentexecutions have the same type of the second expression, i.e., E′,and effect equal to the parallel composition of the effects of thetwo sub-processes. Finally, we also reported the rule called weak-ening (T−WKN) which allows for effect generalization. In words,the rule says that, if we can type an expression with an effect H ′,then we can also type it with a more general one H , in symbolsH ′ ⊑ H .

Without showing the corresponding rules, we briefly describe thebehavior of the type and effect system for the other expressions ofour language. Intuitively, null has unit type and empty effect, aresource u has empty effect and type equal to the singleton {u},the type of a variable x is assigned by the type environment Γ, anobject newC(E) has the type of its class C and effect equal to thesequence of the effects produced by the instantiation parameters E.Field access E.f has the type of f and the effect for E while intentcreation Iα(E) has type Iα(U) (where U is the type of E) and theeffect of E. Similarly to field access, intent content reading E.datahas the type of the intent (denoted by E) data and effect equal tothat of E. Finally, the effect of sequences is the sequence of thetwo sub-effects for E and E′ (while the type is that of E′) and theeffect of choices is the sequence of the two effects generated by theexpressions in the guard and an effect generalizing those of the twobranches, i.e., Ett and Eff (while the type is the same of Ett andEff ). More details about these and other similar rules for types andeffects can be found in [19, 18, 6].

As expected, well-typed expressions do not produce erroneouscomputations, i.e., they always return a value or admit further re-ductions.

LEMMA 1. For each closed (i.e., without free variables) ex-pression E, environment Γ, history expression H , type τ and traceω, if Γ ⊢ E : τ ◃H then either E is a value or ω,E → ω′, E′ (forsome ω′, E′).

4For a class C<:Receiver we write msign(receive, C) =Iα → 1

PROOF. (Sketch5) By induction over the structure of E.

Also well-typed expressions generate history expressions whichsafely denote the runtime behavior of expressions. In particular, thefollowing theorem states that typing a (closed) expression E we ob-tain an over-approximation of the set of all the possible executionsof E.

THEOREM 1. For each closed expression E, history expressionH , type τ and trace ω, if ∅ ⊢ E : τ ◃ H and ·, E →∗ ω,E′ then

there exist H ′ and ω′ such that H ω′−→∗H ′, ∅ ⊢ E′ : τ ◃ H ′ and

ω = ω′.

PROOF. (Sketch) We start by proving that the property holdsfor single-step reductions. Then, we proceed by induction on thederivations length.

We extend the type and effect system to method declarations inthe following way. Given a class C and a method m (s.t. m = receive)such that mbody(m, C) = x, E, msign(m, C) = D → F and[C/this, D/x] ⊢ E : F ◃H , we write ⊢ C.m : D

H−→ F and wesay H to be the latent effect of m. Instead, if C<: Receiver and

m = receive we write ⊢ C.m : IααCh.H−−−−→ 1.

Finally, we exploit the typing rules for the generation of the func-tion ρ described above. For each existing receiver, we type the cor-responding receive method and so to obtain

ρ(α) ={αCh.H

∣∣∣∣∣ newC(v) ∈ receiver(α) ∧⊢ C.receive : Iα

αCh.H−−−−→ 1

}4. POLICY VERIFICATION AND MANAGE-

MENTWe now focus on the management of security policies. We start

by introducing the policy language, then we describe how the pol-icy is used to verify and maintain the security state of the devicesjoining an organization.

Policy languageWe use Hennessy-Milner logic (HML) [11] for specifying securitypolicies. In particular, we adopt the HML version with negation andwe use parametric actions in place of simple labels. The resultingsyntax is

φ,φ′ ::= tt | ¬φ | φ ∧ φ′ | ⟨σ(x)⟩.φ5Technical proofs can be found in Appendix.

Roughly, a policy can be the positive truth value tt , a negation ¬φ,a conjunction φ∧φ′ or a formula prefixed by the existential modaloperator, namely diamond, ⟨σ(x)⟩.φ. In modalities, x can be eithera resource u or a variable x. We call concrete diamond the operator⟨σ(u)⟩ and abstract diamond ⟨σ(x)⟩.

The validity of a policy φ is verified against a history expressionH , in symbols H |= φ according to the following rules.H |= tt (true) H |= ¬φ ⇐⇒ H |= φ (negation)

H |= φ ∧ φ′ ⇐⇒ H |= φ and H |= φ′ (conjunction)

H |= ⟨σ(u)⟩.φ ⇐⇒ Hσ(u)−−−→ H ′ and H ′ |= φ (c-diamond)

H |= ⟨σ(x)⟩.φ ⇐⇒ ∃u.H σ(u)−−−→ H ′ and H ′ |= φ{u/x}(a-diamond)

In words, tt is valid for every history expression H (rule true),¬φ is satisfied by the history expressions violating φ (rule nega-tion) and conjunction is satisfied by history expressions valid forboth the sub-clauses (rule conjunction). Modalities referring to aresource u are satisfied if the history expression admits at least onecorresponding transition and the resulting expression satisfies thesub formula φ (rule c-diamond). Similarly, modalities with a vari-able x check whether a valid reduction exists (rule a-diamond).However, in this case the history expression H ′ is checked againsta sub-formula φ where the free instances of x have been replacedby the referred resource u.

Moreover, we introduce some standard abbreviations defined asfollows.

ff , ¬tt φ∨φ′ , ¬(¬φ∧¬φ′) [σ(x)].φ , ¬⟨σ(x)⟩.¬φ

EXAMPLE 3. Consider the history expression

H = read(∼ /sav)·(www?(”http : //ad.com”)+write(∼ /sav))

and the formula φ = ⟨read(x)⟩.⟨connect(y)⟩.ff .Assuming ρ(www) = {wwwBrowserh.connect(”http : //ad.com”)}

we show that H |= φ (we use "HE" to denote the steps using aproperty of history expressions).read(∼ /sav) · (www?(”http : //ad.com”) + write(∼ /sav))|= ⟨read(x)⟩.⟨connect(y)⟩.ff ⇐⇒ (a-diamond)

www?(”http : //ad.com”) + write(∼ /sav) |= ⟨connect(y)⟩.ff=⇒ (HE choice)

www?(”http : //ad.com”) |= ⟨connect(y)⟩.ff =⇒ (HE intent)

connect(”http : //ad.com”) |= ⟨connect(y)⟩.ff ⇐⇒ (a-diamond)

ε |= ff

which is trivially false. Hence, H |= φ.

Partial model checkingIn [2] partial model checking (PMC) is presented as a techniquefor the partial evaluation of a formula against a model. Intuitively,PMC uses reduction rules for transferring information from themodel the formula it must satisfy. Although originally defined forthe equational modal µ-calculus, we can apply PMC to HML by re-defining the equivalence rules. In particular, we show the operator·//· for the partial evaluation against parallel composition.tt//H = tt (¬φ)//H = ¬φ//H (φ ∧ φ′)//H = φ//H ∧ φ′

//H

(⟨σ(u)⟩.φ)//H = ⟨σ(u)⟩.φ//H ∨∨

Hσ(u)−−−→H′

φ//H′

(⟨σ(x)⟩.φ)//H = ⟨σ(x)⟩.φ//H ∨∨

Hσ(u)−−−→H′

φ{u/x}//H′

Intuitively, the tt formula keeps unchanged while for negationand conjunction PMC applies to the sub formulas, recursively. Aformula ⟨σ(u)⟩.φ reduces to the disjunction between (left) the for-mula obtained by recursively applying PMC to φ and (right) thefinite disjunction among the PMC of φ against all the possible his-tory expressions H ′ (obtained after a σ(u) step from H). The rulefor ⟨σ(x)⟩.φ is similar. The main difference is that the right dis-junction also causes the instantiation of x to u in φ.

Policy compliance is granted by the following theorem.

THEOREM 2. H |= φ//H′ =⇒ H ∥ H ′ |= φ

PROOF. (Sketch) By induction on the PMC rules.

Intuitively, this property states that we can prove the complianceof two (or more) concurrent components against a policy if we cancheck the compliance of one of them against a “specialization” ofthe original policy. Clearly, this is particularly useful under ourassumptions in which new applications join a set of previously in-stalled ones.

EXAMPLE 4. Consider the policy

φ = ¬⟨read(x)⟩.⟨connect(y)⟩.tt∧¬⟨write(x)⟩.⟨connect(y)⟩.tt

and the following history expression

(µh1.(www?(u)) · h1)

∥ (read(∼ /sav)·(write(∼ /sav) + www?(”ad.com”)))

∥ (wwwBh3.∑

u connect(u))

H1 ∥ H2 ∥ H3

It consists of (the parallel composition of) the history expres-sion for the Browser receiver (H3), the Game activity (H2) and a(simplified) user interface (H1). Terms H2 and H3 are generatedby typing the methods receive and play of Browser and Game,respectively. Instead, H1 represents the user’s behaviour (for in-stance, we could obtain it by typing the user interface component).Roughly, H1 says that, iteratively, the user can open the browseron the homepage u (www?(u)).

It is easy to verify that both H1 ∥ H2 |= φ and H1 ∥ H3 |=φ. As a matter of fact, φ is only violated by traces containingeither a read or write (both missing in H1 ∥ H3) followed by aconnect (missing in H1 ∥ H3). However, we prove (using PMC)that H1 ∥ H2 ∥ H3 |= φ. We show that the installation of Game isnot allowed by φ on a system running Browser. First we computeφ//H1

= φ (trivial since H1 contains no system actions) and φ′ =φ//H2

.

φ′ =

(¬(⟨read(x)⟩.⟨connect(y)⟩.tt ∨ ⟨connect(y)⟩.tt

)∧

¬(⟨write(x)⟩.⟨connect(y)⟩.tt ∨ ⟨connect(y)⟩.tt

) )

Finally, we just need to verify that H3 |= φ′. Without showingthe proof, we can trivially observe that connect(u) is a trace ofH3 that violates φ′.

5. BYODROIDWe implemented a prototype (BYODroid) using the techniques

described above for guaranteeing organizations against security vi-olations in BYOD scenarios. BYODroid consists of two main com-ponents: the BYODroid Market and the BYODroid Installer. The

Compute

filtered app list

ChompSMS

WhatsAPP

Facebook

. . .

. . .

. . .

BYODroid Secure Marketplace

Security Policy Manager

Get_app_list(δ)

App listδ

App listδ

Get_app_list(δ)

. . .

. . .

δnφn

φ1

φm

Device δ

App listδ

Get_app_list(δ)

Figure 1: The BYODroid marketplace generating an applications list.

BYODroid Installer allows users to access the BYODroid Marketand get new applications respecting the policy of the organization.Once a user requires to register its device to the organization, theBYODroid Installer replaces the native system installer. After in-stallation, the BYODroid installer analyzes the device configura-tion, i.e., the installed applications, and sends it to the BYODroidMarket. If the configuration is a legal one, the registration success-fully completes and the device is connected to the organization.

The BYODroid Market is responsible for holding the securitystate of the devices registered to the organization and for medi-ating the access to other application markets by only allowing aconnected device to install legal applications. Basically, the BYO-Droid Market contains a security policy manager which maintainsa graph of policies dependency, rooted in the organization policy.Each node of the graph contains information about the security con-figuration of registered devices. In detail, a node N is labeled witha policy φN and contains a list of device identifiers and has a finiteset of outgoing edges labeled with application identifiers. When anew device δ successfully registers, its identifier is associated to anode N in the graph such that the path from the root to N is labeledwith the list of δ’s applications (if no such state exists it is createdby using the node creation procedure below). The policy φN is ob-tained through partial evaluation (see Section 4) of the root policyagainst the (model of the) applications installed on δ. In this waywe create the premises for applying Theorem 2.

When the registered device δ (appearing in node N ) accesses themarket service, the BYODroid Market retrieves the list of applica-tions and generates a view for the BYODroid installer. The viewis a list of applications A1, . . . , Am such that if an edge from Nlabeled with Ai exists, then Ai is marked safe. Otherwise, Ai ismarked unchecked. If δ (being in node N ) installs a safe applica-tions As labeling an edge to N ′, its device identifier is moved toN ′. Instead, if δ aims at installing an unchecked application Au,the following procedure is applied: the BYODroid Market down-loads Au and applies the type and effect system in Section 3 to inferHu. Then, it verifies whether Hu |= φN . If so, the installation isblocked and the user alerted. Otherwise, φN//Hu

(see Section 4)is computed. Such value is used to label a fresh node N , addingan edge from N to N , labeled by Au, to the graph. Finally, δ ismoved to N and the installation can proceed.

In general, each node can also store a black list of failed installa-tions, i.e., applications that do not fulfil the node policy. Applica-tions in the black list do not appear in the list of available installa-tions for the registered devices being in the corresponding node.

The prototype structure and behavior are described in Figure 1

which also shows the outputs of our prototype.According to the BYOD paradigm, a user is free to use his per-

sonal device outside the organization. The BYODroid installer sup-ports such situation by allowing the user to install any applicationwhen the device is not connected to the organization. However,each time the user tries to rejoin the organization, the current deviceconfiguration is checked against the organization policy; if this isnot satisfied due to the presence of forbidden applications, the useris prompted with the list of applications to remove in order to getaccess to the organization.

We implemented our prototype BYODroid marketplace as a lo-cal service running on a desktop PC. When a request arrives, theservice uses the procedure described above to produce a web pagethat customers visualize and use to select and install new applica-tions. Also, we used Android simulator to create virtual devicesrunning the BYODroid Installer and connecting to the service.

6. RELATED WORKDue to the high diffusion of smartphones, a substantial part of

the current research in security is turning towards mobile platforms.Most of such research is focused on security aspects of mobile OSs.On this tread, the research is focused on the Android platform, dueto its open source, hardware-independence and general purpose na-ture. In particular, current literature on Android security containsproposals for i) extending the native security policy, ii) enhancingthe Android Security Framework (ASF) with new tools for spe-cific security-related checks, and iii) detecting vulnerabilities andsecurity threats. Regarding the first category, in [16] the (infor-mal) Android security policy is analyzed in terms of efficacy andsome extensions are proposed. Besides, in [13] authors propose anextension to the basic Android permission systems and some newpolicies built on top of the extended permission system. Moreover,in [20] new privacy-related security policies are proposed for ad-dressing security problems related to users’ personal data. Relatedto ASF enhancement, many proposals have been made to extend thenative Android security mechanisms. For instance, [14] proposes amethod for monitoring the Android permissions system by properlycustomizing the Android stack. Malware detection approaches alsoexist, e.g., XManDroid [9]. Besides, other works have successfullydetected vulnerabilities related to DoS attacks [4], and covert chan-nels [15]. The efficacy and soundness of previous approaches havebeen proved through empirical assessments, without any formal ba-sis. Recently, researchers focused on the formal modeling and anal-ysis of the Android platform and its security aspects. In [17] the

authors formalize the permission scheme of Android. Briefly, theirformalization consists of a state-based model representing entities,relations and constraints over them. Also, they show how their for-malism can be used to automatically verify that the permissionsare respected. Unlike our proposal, their language only describespermissions and obligations and does not capture application inter-actions which we infer from actual implementations. In particular,their framework provides no notion of interaction with the plat-form, while we represent it through system calls. Similarly to thepresent work, Chaudhuri [10] proposes a language-based approachto infer security properties from Android applications. Moreover,this work proposes a type system that guarantees that well-typedprograms respect user data access permissions. The type and ef-fect system that we presented here exceeds the proposal of [10] asit also infers/verifies history expressions. History expressions candenote complex interactions/behaviors and they allow for the veri-fication against a rich class of security policies [1]. To the best ofour knowledge, our proposal is the first one to tackle the problemof modeling and validating the behavior of Android applicationsagainst customized security policies in a formal, non-invasive way.

7. CONCLUSIONIn this work we presented a framework for modeling the behav-

ior of Android applications and verifying their compliance w.r.t. asecurity policies. Furthermore, we applied this method to a specificcontext, i.e., securing BYOD-based organizations, and we detailedthe features of a prototype under implementation. The models weproduce are safe in the sense that they correctly represent all thepossible runtime computations of the applications they come from.Moreover, the history expressions representing each single appli-cation can be combined together in order to create a global modelfor a specific Android platform. History expressions, originallyproposed by Bartoletti et al. [8], have been successfully applied tothe security analysis of Java applications [5] and web services [7],and we extended most of their results to the Android framework.Moreover, we introduces a new, PMC-based approach for the par-tial evaluation of security policies which we fruitfully exploited inthe definition of the BYODroid prototype.

8. REFERENCES[1] M. Abadi and C. Fournet. Access control based on execution

history. In Proc. of the 10th annual Network and DistributedSystem Security Symposium, pages 107–121, 2003.

[2] H. R. Andersen. Partial model checking (extended abstract).In Proc. of 10th Annual IEEE Symposium on Logic inComputer Science, pages 398–407. IEEE Computer SocietyPress, 1995.

[3] A. Armando, G. Costa, and A. Merlo. Formal modeling andreasoning about the Android security framework. In Proc. of7th International Symposium on Trustworthy GlobalComputing, 2012. (To appear).

[4] A. Armando, A. Merlo, M. Migliardi, and L. Verderame.Would you mind forking this process? A denial of serviceattack on Android (and some countermeasures). In Proc. ofthe 27th IFIP International Information Security andPrivacy Conference (SEC 2012), pages 13–24.

[5] M. Bartoletti, G. Costa, P. Degano, F. Martinelli, andR. Zunino. Securing Java with Local Policies. Journal ofObject Technology, 8(4):5–32, 2009.

[6] M. Bartoletti, P. Degano, and G. L. Ferrari. History-basedaccess control with local policies. In FoSSaCS, pages316–332, 2005.

[7] M. Bartoletti, P. Degano, and G. L. Ferrari. Planning andverifying service composition. Journal of Computer Security(JCS), 17(5):799–837, 2009.

[8] M. Bartoletti, P. Degano, G. L. Ferrari, and R. Zunino. Typesand effects for resource usage analysis. In Proc. of the 10thInternational Conference on Foundations of SoftwareScience and Computation Structures, pages 32–47, 2007.

[9] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, and A.-R.Sadeghi. Xmandroid: A new android evolution to mitigateprivilege escalation attacks. Technical Report TR-2011-04,Technische Univ. Darmstadt, Apr 2011.

[10] A. Chaudhuri. Language-based security on Android. In Proc.of the ACM SIGPLAN Fourth Workshop on ProgrammingLanguages and Analysis for Security, PLAS ’09, pages 1–7,New York, NY, USA, 2009. ACM.

[11] M. Hennessy and R. Milner. On Observing Nondeterminismand Concurrency. In Proc. of the 7th Colloquium onAutomata, Languages and Programming, pages 299–309,London, UK, 1980. Springer-Verlag.

[12] A. Igarashi, B. C. Pierce, and P. Wadler. Featherweight Java:A Minimal Core Calculus for Java and GJ. In ACMTransactions on Programming Languages and Systems,pages 132–146, 1999.

[13] M. Nauman, S. Khan, and X. Zhang. Apex: extendingandroid permission model and enforcement withuser-defined runtime constraints. In Proc. of the 5th ACMSymposium on Information, Computer and CommunicationsSecurity, ASIACCS ’10, pages 328–332, New York, NY,USA, 2010. ACM.

[14] M. Ongtang, S. Mclaughlin, W. Enck, and P. Mcdaniel.Semantically rich application-centric security in android. InIn ACSAC ’09: Annual Computer Security ApplicationsConference, 2009.

[15] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia, andX. Wang. Soundcomber: A Stealthy and Context-AwareSound Trojan for Smartphones. In Proc. of the 18th AnnualNetwork & Distributed System Security Symposium, 2011.

[16] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, andC. Glezer. Google android: A comprehensive securityassessment. Security Privacy, IEEE, 8:35–44, march 2010.

[17] W. Shin, S. Kiyomoto, K. Fukushima, and T. Tanaka. AFormal Model to Analyze the Permission Authorization andEnforcement in the Android Framework. In Proc. of the 2010IEEE Second International Conference on SocialComputing, SOCIALCOM ’10, pages 944–951, Washington,DC, USA, 2010. IEEE Computer Society.

[18] C. Skalka and S. Smith. History effects and verification. InSecond ASIAN Symposium on Programming Languages andSystems (APLAS), pages 107–128. Springer, 2004.

[19] C. Skalka, S. Smith, and D. Van Horn. A Type and EffectSystem for Flexible Abstract Interpretation of Java.Electronic Notes in Theorical Computer Science,131:111–124, May 2005.

[20] Y. Zhou, X. Zhang, X. Jiang, and V. W. Freeh. Taminginformation-stealing smartphone applications (on android).In Proc. of the 4th international conference on Trust andtrustworthy computing, TRUST’11, pages 93–107, 2011.

(T−NULL) Γ ⊢ null : 1◃ε (T−RES) Γ ⊢ u : {u}◃ε (T−VAR)Γ(x) = τ

Γ ⊢ x : τ ◃ ε(T−INT)

Γ ⊢ E : U ◃ H

Γ ⊢ Iα(E) : Iα(U) ◃ H(T−DATA)

Γ ⊢ E : Iα(U) ◃ H

Γ ⊢ E.data : U ◃ H

(T−FLD)Γ ⊢ E : C ◃ H fields(C) = Df

Γ ⊢ E.fi : Di ◃ H(T−IMPC)

Γ ⊢ E : Iα(U) ◃ H

Γ ⊢ icastE : 1 ◃ H ·∑

u∈Uα?(u)

(T−EXPC)Γ ⊢ E : Iα(U) ◃ H

Γ ⊢ ecast CE : 1 ◃ H ·∑

u∈UαC(u)

(T−SYS)Γ ⊢ E : U ◃ H

Γ ⊢ systemσ E : 1 ◃ H ·∑

u∈Uσ(u)

(T−NEW)Γ ⊢ Ei : τi ◃ Hi

Γ ⊢ new C(E) : C ◃ H1 · · ·Hn

(T−IF)Γ ⊢ E : τ ◃ H Γ ⊢ E′ : τ ′ ◃ H′ Γ ⊢ Ett : τ ◃ H Γ ⊢ Eff : τ ◃ H

Γ ⊢ if(E = E′) then {Ett} else {Eff } : τ ◃ H · H′ · H

(T−METH)Γ ⊢ E : C ◃ H Γ ⊢ E′ : τ ′ ◃ H′ mbody(m, C) = x, E′′ [C/this, τ ′/x] ⊢ E′′ : F ′ ◃ H′′ msign(m, C) = τ ′ → τ ′′ τ ′ → τ ′′ <: τ ′ → τ ′′

Γ ⊢ E.m(E′) : τ ′′ ◃ H · H′ · H′′

(T−SEQ)Γ ⊢ Ei : τi ◃ Hi

Γ ⊢ E1;E2 : τ2 ◃ H1·H2

(T−CAST)Γ ⊢ E : D ◃ H D<:C

Γ ⊢ (C)E : C ◃ H(T−PAR)

Γ ⊢ Ei : τi ◃ Hi

Γ ⊢ thd {E1} in {E2} : τ2 ◃ H1∥H2

(T−WKN)Γ ⊢ E : τ ◃ H′ H′ ⊑ H

Γ ⊢ E : τ ◃ H

Table 5: Typing rules.

APPENDIXTechnical Proof

LEMMA 1. For each closed (i.e., without free variables) ex-pression E, environment Γ, history expression H , type τ and traceω, if Γ ⊢ E : τ ◃H then either E is a value or ω,E → ω′, E′ (forsome ω′, E′).

PROOF. By induction over the structure of E.

• Case null, u, x. Trivial.

• Case new C(E). If each Ei = vi then E is a value and theproperty holds. Otherwise it suffices to apply the inductivehypothesis to the first Ei = v.

• Case E′.f. If E′ = v we apply the inductive hypothesis.Otherwise, by T−FLD we know that E′ = new C(v) and wecan conclude by applying FLD2.

• Case E′.m(E′′). If both E′ = v′ and E′′ = v′′ we assumethe premises of T−METH and we can apply METH3. Insteadif either E′ = v′ or E′′ = v′′ we can directly apply theinductive hypothesis to METH1 and METH2.

• Case systemσ E′. If E′ is not a value, we apply the inductivehypothesis and rule SYS1. Otherwise, by T−SYS we knowthat Γ ⊢ E′ : U ◃ H ′ and the only suitable value for E′ is aresource u. Thus, we conclude by applying SYS2.

• Case icastE′ and ecast CE′. Similar to the previous step.

• Case Iα(E′). If E′ = v then E is also a value. Instead, if

E′ is not a value, we apply the inductive hypothesis and ruleINT.

• Case E′.data. If E′ is a value, by T−DATA it must be E′ =Iα(v). Hence, we conclude by applying rule DATA2. Oth-erwise, we simply apply the inductive hypothesis and ruleDATA1.

• Case if (E′ = E′′) then {Ett} else {Eff }. If one betweenE′ and E′′ is not a value, we conclude by applying the induc-tive hypothesis. Otherwise, we can apply either IF3 or IF4.In both cases, the property holds.

• Case E′;E′′. Here we have two possibilities: either E′ is avalue or not. In both cases, E admits reduction (through SEQ1and SEQ2, respectively).

• Case (C)E′. If E′ is not a value, it suffices to apply the induc-tive hypothesis and rule CAST1. On the other hand, by ruleT−CAST we know that E′ = new D(· · · ) and D<:C. Thus,we can apply CAST2 and conclude.

• Case thread {E′} in {E′′}. Again, if either E′ or E′′ arenot values, we use the inductive hypothesis and rule PAR1 orPAR2. Instead, if E′ = v′ and E′′ = v′′ we conclude byapplying rule PAR3.

DEFINITION 3.JHK = {ω | ∃H ′.Hω−→∗H ′}

LEMMA 2. For each closed expression E, environment Γ, his-tory expression H , type τ and trace ω, if Γ ⊢ E : τ ◃ H andω,E →∗ ω′, E′ then Γ ⊢ E′ : τ ◃ H ′ and for all ω′ ∈ JH ′K thereexists ω ∈ JHK such that ωω = ω′ω′.

PROOF. We first (1) prove the property for single step and then(2) we extend it to arbitrary long derivations.

1. By induction on the structure of E.

• Case null, u, x. Trivial.• Case new C(E). If each Ei = vi then E is a value and

the property holds. Otherwise we type E in this way

Γ ⊢ Ei : τi ◃ Hi

Γ ⊢ new C(E) : τ ◃ ε · · ·Hj · · ·

where Ej is the first non-value in E. Applying Lemma 1we know that ω,Ej → ω′, E′

j . Hence, we apply the

inductive hypothesis obtaining Γ ⊢ E′j : τj ◃ H ′

j and∀ω′

j ∈ JH ′jK.∃ωj ∈ JHjK.ωωj = ω′ω′

j . Then, by in-stantiating rule NEW we have

ω, new C(v, Ej , . . .) → ω′, new C(v, E′j , . . .)

Since A = Jε · · ·Hj · · ·K = {ωjωj+1 · · · | ωj ∈ JHjK∧ωj+1 ∈ JHj+1K ∧ · · · } and B = Jε · · ·H ′

j · · ·K ={ω′

jωj+1 · · · | ω′j ∈ JH ′

jK ∧ ωj+1 ∈ JHj+1K ∧ · · · }(where the · · · parts are equal) we can conclude by ob-serving that ∀ω′ = ω′

j · · · ∈ B we can find a traceω = ωj · · · ∈ B such that ωω = ω′ω′

• Case E′.f. If E′ = v we just apply the inductive hypoth-esis. Otherwise, by T−FLD we know that E′ = new C(v)and by applying FLD2 we obtain ω, new C(v).f → ω, vfwhich trivially satisfies the property.

• Case E′.m(E′′). If either E′ = v′ or E′′ = v′′ weassume the premises of T−METH and we can apply theinductive hypothesis and METH1/METH2. Instead if bothE′ = new C(v) and E′′ = v′ we apply METH3 and wehave

mbody(m, C) = x,Em

ω, (new C(v)).m(v′) → ω,Em[v′/x, (new C(v))/this]

However, typing the two sides of this transition we obtainthe same history expression. Indeed, for each history ex-pression Hm produced by typing the right side, we havefor the left part ε · ε ·Hm which is trivially equivalent.

• Case systemσ E′. If E′ is not a value, we apply the in-ductive hypothesis and rule SYS1. Otherwise, by SYS2 wehave ω, systemσ u → ω · σ(u), null. Also by T−SYS

we have Γ ⊢ E : 1 ◃ σ(u). Since Γ ⊢ null : 1 ◃ ε,we have to show that ∃ω ∈ {σ(u)}.ωσ(u) = ωω whichtrivially holds.

• Case icastE′. Similarly to the previous step, if E′ isnot a value, we can simply apply the inductive hypothe-sis. Otherwise, by T−IMPC we must have E′ = Iα(u)and H = α?(u). Also, by IMPC2 we have

newC(v) ∈ receiver(α)

ω, icast Iα(u) → ω, newC(v).receive(Iα(u))

and we type Γ ⊢ newC(v).receive(Iα(u)) : 1 ◃ H .Hence we must prove that ∀ω′ ∈ JHK.∃ω ∈ Jα?(u)Ksuch that ωω = ωω′. However, by the semantics of his-tory expressions we have

α?(u)α?(u)−−−−→ ε

H =∑

H ′{α?(u)/h} s.t. αCh.H′ ∈ ρ(α) and χ < C

H·−→ H

Then, by definition of ρ, we have that H ⊑ H whichsuffices to conclude.

• Case ecast CE′. Analogous to the previous case.• Case Iα(E

′). If E′ = v then E is also a value. Instead,if E′ is not a value, we apply the inductive hypothesisand rule INT.

• Case E′.data. If E′ is a value, by T−DATA it mustbe E′ = Iα(v). Hence, we conclude by applying ruleDATA2. Otherwise, we simply apply the inductive hy-pothesis and rule DATA1.

• Case if (E′ = E′′) then {Ett} else {Eff }. If either

E′ or E′′ are not values, we conclude by applying the in-ductive hypothesis. Otherwise, we can apply either IF3or IF4 and the inductive hypothesis to Ett and Eff , re-spectively.

• Case E′;E′′. Here we have two possibilities: eitherE′ is a value or not. In both cases, E admits reduc-tion (through SEQ1 and SEQ2, respectively). The propertyholds by the inductive hypothesis.

• Case (C)E′. If E′ is not a value, it suffices to apply theinductive hypothesis and rule CAST1. On the other hand,by rule T−CAST we know that E′ = new D(· · · ) andD<:C. Thus, we can apply CAST2 and conclude.

• Case thread {E′} in {E′′}. If either E′ or E′′ are notvalues, we use the inductive hypothesis and rule PAR1 orPAR2. Instead, if E′ = v′ and E′′ = v′′ we conclude byapplying rule PAR3.

2. By induction on the derivation length.

• Base case. For zero-long derivations the property is triv-ially satisfied by the identity ωω = ωω.

• Induction. We assume the property holds for n-long deriva-tions and we apply (1) to prove that the property is pre-served by a further step.

THEOREM 1. For each closed expression E, history expressionH , type τ and trace ω, if ∅ ⊢ E : τ ◃ H and ·, E →∗ ω,E′ then

there exist H ′ and ω′ such that H ω′−→∗H ′, ∅ ⊢ E′ : τ ◃ H ′ and

ω = ω′.

PROOF. A corollary of Lemma 2.

LEMMA 3.

(A) H |= φ ⇐⇒ H |= ¬φ (B) φ ≡ ¬¬φ

PROOF.

(A) For the right implication H |= φ ⇒ H |= ¬φ. We assumeH |= ¬φ and by negation rule we have the contradictionH |= φ. The other direction is similar.

(B) By applying (A) two times.

THEOREM 2. H |= φ//H′ =⇒ H ∥ H ′ |= φ

PROOF. By induction over the structure of φ.

• Case tt . Trivial.

• Case ¬φ. We have H |= (¬φ)//H′ ⇔ H |= ¬(φ//H′) ⇔H |= φ//H′ . By Lemma 3 and inductive hypothesis we haveH ∥ H ′ |= φ which suffices to conclude.

• Case φ ∧ φ′. From the PMC and conjunction rules we haveH |= φ//H′ and H |= φ′

//H′ . Then we apply the inductivehypothesis and we obtain H ∥ H ′ |= φ and H ∥ H ′ |= φ′

which imply H ∥ H ′ |= φ ∧ φ′.

• Case ⟨σ(u)⟩.φ. The PMC rule says that H |= (⟨σ(u)⟩.φ)//H′

reduces to

H |=

A︷ ︸︸ ︷⟨σ(u)⟩.φ//H′ ∨

B︷ ︸︸ ︷∨H′

σ(u)−−−→H′′

φ//H′′

If A holds then by c-diamond rule both (i) Hσ(u)−−−→ H and

(ii) H |= φ//H′ . Hence, by inductive hypothesis on (ii)

we have that H ∥ H ′ |= φ and by concurrency rule using

(i) premise we have that H ∥ H ′ σ(u)−−−→ H ∥ H ′. Thesetwo facts suffice to conclude that H ∥ H ′ |= ⟨σ(u)⟩.φ. In-stead, if B holds, there must exist at least one H ′′ such that

H ′ σ(u)−−−→ H ′′ and H |= φ//H′′ . The latter implies (by in-ductive hypothesis) that H ∥ H ′′ |= φ, the former implies

H ∥ H ′ σ(u)−−−→ H ∥ H ′′. These two facts imply (c-diamond)H ∥ H ′ |= ⟨σ(u)⟩.φ.

• Case ⟨σ(x)⟩.φ. We proceed similarly to the previous case.Applying the PMC rule to H |= (⟨σ(x)⟩.φ)//H′ we have

H |=

A︷ ︸︸ ︷⟨σ(x)⟩.φ//H′ ∨

B︷ ︸︸ ︷∨H′

σ(u)−−−→H′′

φ{x/u}//H′′

If A holds then by a-diamond rule there exists u such that

(i) Hσ(u)−−−→ H and (ii) H |= φ{x/u}//H′ . Hence, by

inductive hypothesis on (ii) we have that H ∥ H ′ |= φ{x/u}and by concurrency rule using (i) premise we have that H ∥H ′ σ(u)−−−→ H ∥ H ′. These two facts suffice to conclude thatH ∥ H ′ |= ⟨σ(x)⟩.φ. Instead, if B holds, there exist H ′′ and

u such that H ′ σ(u)−−−→ H ′′ and H |= φ{x/u}//H′′ . The latterimplies (by inductive hypothesis) that H ∥ H ′′ |= φ{x/u},

the former implies that H ∥ H ′ σ(u)−−−→ H ∥ H ′′. Applying (a-diamond) to these two facts we obtain H ∥ H ′ |= ⟨σ(u)⟩.φ,that is the thesis.

(NEW)ω,Ei → ω′, E′

i

ω, new C(v, Ei, . . .) → ω′, new C(v, E′i, . . .)

(FLD1)ω,E → ω′, E′

ω,E.f → ω′, E′.f(FLD2)

fields(C) = D f

ω, new C(v).fi → ω′, vi

(SYS1)ω,E → ω′, E′

ω, sysσ E → ω′, sysσ E′(SYS2)ω, sysσ u → ω·σ(u), null

(METH1)ω,E → ω′, E′′

ω, E.m(E′) → ω′, E′′.m(E′)(METH2)

ω,E′ → ω′, E′′

ω, E.m(E′) → ω′, E.m(E′′)

(METH3)mbody(m, C) = x,E

ω, (new C(v)).m(v′) → ω,E[v′/x, (new C(v))/this]

(INT)ω,E → ω′, E′

ω, Iα(E) → ω′, Iα(E′)(IMPC1)

ω,E → ω′, E′

ω, icastE → ω′, icastE′

(IMPC2)newC(v) ∈ receiver(α)

ω, icast Iα(u) → ω, newC(v).receive(Iα(u))

(EXPC1)ω,E → ω′, E′

ω, ecast CE → ω′, ecast CE′

(EXPC2)newC(v) ∈ receiver(α)

ω, ecast C Iα(u) → ω, newC(v).receive(Iα(u))

(DATA1)ω,E → ω′, E′

ω,E.data → ω′, E′.data(DATA2) ω, Iα(v).data → ω, v

(IF1)ω,E → ω′, E′′

ω, if(E = E′) then {Ett} else {Eff } →ω′, if(E′′ = E′) then {Ett} else {Eff }

(IF2)ω,E′ → ω′, E′′

ω, if(v = E′) then {Ett} else {Eff } →ω′, if(v = E′′) then {Ett} else {Eff }

(IF3) ω, if(v = v) then {Ett} else {Eff } → ω,Ett

(IF4)v = v′

ω, if(v = v′) then {Ett} else {Eff } → ω,Eff

(SEQ1)ω,E → ω′, E′′

ω,E;E′ → ω′, E′′;E′(SEQ2) ω, v;E → ω,E

(CAST1)ω,E → ω′, E′

ω, (C)E → ω′, (C)E′(CAST2)

D<:C

ω, (C)new D(v) → ω, new D(v)

(PAR1)ω,E → ω′, E′′

ω, thread {E} in {E′} → ω′, thread {E′′} in {E′}

(PAR2)ω,E′ → ω′, E′′

ω, thread {E} in {E′} → ω′, thread {E} in {E′′}(PAR3) ω, thread {v} in {v′} → ω, v′

Table 6: Semantics of expressions.