Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation

Madalina G. Ciobanu

, Fausto Fasano

, Fabio Martinelli

, Francesco Mercaldo

1,2

and Antonella Santone

Department of Biosciences and Territory, University of Molise, Pesche (IS), Italy

Istituto di Informatica e Telematica, Consiglio Nazionale delle Ricerche, Pisa, Italy

{fabio.martinelli, francesco.mercaldo}@iit.cnr.it

Keywords:

Android, Security, Model Checking, Formal Methods, Privacy.

Abstract:

Our mobile devices, if compared to their desktop counterpart, store a lot of sensitive and private information.

Considering how easily permissions to sensitive and critical resources in the mobile environment are released,

for example in Android, sometimes the developer unwittingly causes the leakage of sensitive information,

endangering the privacy of users. Starting from these considerations, in this paper we propose a method aimed

to automatically localise the code where there is the possibility of information leak. In a nutshell, we discuss

a method aimed to check whether a sensitive information is processed in a way that violates speciﬁc rules.

We employ code instrumentation to annotate sensitive data exploiting model checking technique. To show the

effectiveness of the proposed method a case study is presented.

1 INTRODUCTION

Mobile applications are widely used in different sec-

tors with billions of smartphone owners using mobile

apps daily. The evolution of mobile software requires

more attention, appropriate skills, and a better com-

prehension for the development, maintenance, and en-

gineering of applications phases.

Nowadays, mobile apps need to seamlessly inter-

act with back-end servers, which can be accomplished

with numerous alterations and adjustments during the

development phase (Harleen K. Flora, 2014). Smart-

phones, more than desktop and laptop computers,

have lots of sensors that could increment usability but,

there again, increment the overall complexity of the

apps. With such sensors, indeed, it is possible to ﬁnd

position, rumor level, light, usage angle, movement

and so on. Many of such sensors and peripherals pro-

duce sensitive data that must be managed following

speciﬁc regulations. The GDPR

introduces penalties

including important administrative ﬁnes

that can be

imposed for any infringement of the Regulation, such

The General Data Protection Regulation (GDPR) (EU)

2016/679 is a regulation in EU law on data protection and

privacy.

Fines can be up to 20 million euros, or 4% of the

ﬁrm’s worldwide annual revenue from the preceding ﬁnan-

cial year, whichever amount is higher. https://gdpr.eu/ﬁnes

as in case of personal data processing without user

consent or transferring personal data to a non GDPR-

compliant recipient. It is worth noting that such regu-

lation applies to any subject that collects, uses and/or

processes European citizen’s personal data, regardless

of whether the processing takes place in the Union or

not.

To this aim, a growing attention is paid to the

way apps collect, process, and transfer personal data

to back-end servers. Most of this attention concerns

malware detection (Fasano et al., 2019; Martinelli

et al., 2017a; Martinelli et al., 2017b; Ciobanu et al.,

2019a; Ciobanu et al., 2019b). However, even in

case of a trusted app, whose behaviour is legitimate,

the risk of an accidental sensitive data leak remains,

as software developers are in charge of assessing the

Regulation compliance. As an example scenario, a

software house may decide to avoid its app to re-

quest write permission to shared internal storage in

case of sensitive information, as well as to read card

data or to mount local ﬁle systems when process-

ing particular information, unless the user is aware of

how the data is being processed. On the other hand,

the same permissions may be legitimate when pro-

cessing other non-sensitive entities or when storing

aggregated data. Since the permission to read/write

from providers/external storage as well as to send data

through the internet is independent of the informa-

Ciobanu, M., Fasano, F., Martinelli, F., Mercaldo, F. and Santone, A.

Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation.

DOI: 10.5220/0009380608250834

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 825-834

ISBN: 978-989-758-399-5; ISSN: 2184-4356

825

tion itself, there is no ready-to-use solution to check

whether an app is accidentally leaking sensitive infor-

mation by unsafely saving it to the device memory of

sending it to the back-end, without the explicit con-

sent of the user. Despite code inspection can be very

effective to identify such situation, several developers

underrate it in favor of testing (Scanniello et al., 2013)

even when the former technique would be more ade-

quate.

In this paper, we propose a method to formally

check whether a sensitive information is processed

in a way that violates speciﬁc rules. The proposed

method uses code instrumentation to annotate sen-

sitive data and is based on model checking tech-

nique using temporal logic formulae to check whether

the sensible data processing can break some deﬁned

rules. Moreover, the approach assists the software en-

gineer in the identiﬁcation of the reason why the rule

is not satisﬁed, providing relative traces from the sim-

ulation environment.

The rest of the paper proceeds as follows: In Sec-

tion 2 background notions about model checking are

provided and the proposed method to detect sensitive

information leakage in Android environment is pre-

sented. In Section 3 a case study that illustrates the

proposed method applied to the real scenario is pre-

sented. Related work is discussed in Section 4, while

conclusion and future work are discussed in Section 5.

2 PROPOSED METHOD

In this section we brieﬂy introduce background no-

tions about model checking, in the next we describe

the proposed method to detect sensitive data leakage

in Android environment.

2.1 Model Checking and Mu-calculus

Logic

Model checking is a formal method for determining

if a model of a system satisﬁes a correctness speci-

ﬁcation (Clarke et al., 2001; Ceccarelli et al., 2014;

Santone, 2002; Santone, 2011; Barbuti et al., 2005;

Gradara et al., 2005). A model of a system consists of

a Labelled Transition System (LTS). A speciﬁcation

or property is a logical formula. A model checker

then accepts two inputs, an LTS and a temporal for-

mula, and returns true if the system satisﬁes the for-

mula and false otherwise.

An LTS comprises some number of states, with

arcs between them labelled by activities of the system.

An LTS is speciﬁed by:

• a set S of states;

• a set L of labels or actions;

• a set of transitions T ⊆ S × L × S.

Transitions are given as triples (start,label, end).

With the aim to express proprieties of the system

we consider the modal mu-calculus (Stirling, 1989)

which is one of the most important logics in model

checking.

The syntax of the mu-calculus is the following,

where K ranges over sets of actions (i.e., K ⊆ L) and

Z ranges over variables:

ϕ ::= tt | ff |Z | ϕ ∧ ϕ | ϕ ∨ ϕ | [K]ϕ |

hKiϕ | νZ.ϕ | µZ.ϕ

A ﬁxpoint formula may be either µZ.ϕ or νZ.ϕ

where µZ and νZ binds free occurrences of Z in ϕ. An

occurrence of Z is free if it is not within the scope of

a binder µZ (resp. νZ). A formula is closed if it con-

tains no free variables. µZ.ϕ is the least ﬁxpoint of the

recursive equation Z = ϕ, while νZ.ϕ is the greatest

one. From now on we consider only closed formulae.

Scopes of ﬁxpoint variables, free and bound vari-

ables, can be deﬁned in the mu-calculus in analogy

with variables of ﬁrst order logic.

The satisfaction of a formula ϕ by a state s of a

transition system is deﬁned as follows:

• each state satisﬁes tt and no state satisﬁes ff;

• a state satisﬁes ϕ

∨ ϕ

(ϕ

∧ ϕ

) if it satisﬁes ϕ

or (and) ϕ

. [K] ϕ is satisﬁed by a state which,

for every execution of an action in K, evolves to a

state obeying ϕ. hKi ϕ is satisﬁed by a state which

can evolve to a state obeying ϕ by performing an

action in K.

For example, hai ϕ denotes that there is an a-

successor in which ϕ holds, while [a] ϕ denotes that

for all a-successors ϕ holds.

The precise deﬁnition of the satisfaction of a

closed formula ϕ by a state s (written s |= ϕ) is given

in Table 1.

We consider the CWB-NC

(Concurrency Work-

Bench of the New Century) as formal veriﬁcation en-

vironment. It is one of the most popular environments

for verifying systems. In the CWB-NC the veriﬁ-

cation of temporal logic formulae is based on model

checking (Clarke et al., 2001).

2.2 Information Leakage Detection

In this section, we describe our approach aimed to de-

tect possible sensitive information leakage in Android

https://www3.cs.stonybrook.edu/

∼

cwb/

ForSE 2020 - 4th International Workshop on FORmal methods for Security Engineering

826

Table 1: Satisfaction of a closed formula by a state.

p 6|= ff

p |= tt

p |= ϕ ∧ ψ iff p |= ϕ and p |= ψ

p |= ϕ ∨ ψ iff p |= ϕ or p |= ψ

p |= [K]

ϕ iff ∀p

.∀α ∈ K.p

−→

K∪R

implies p

|= ϕ

p |= hKi

ϕ iff ∃p

.∃α ∈ K.p

−→

K∪R

and p

|= ϕ

p |= νZ.ϕ iff p |= νZ

.ϕ for all n

p |= µZ.ϕ iff p |= µZ

.ϕ for some n

where:

• for each n, νZ

.ϕ and µZ

.ϕ are deﬁned as:

νZ

.ϕ = tt µZ

.ϕ = ff

νZ

n+1

.ϕ = ϕ[νZ

.ϕ/Z] µZ

n+1

.ϕ = ϕ[µZ

.ϕ/Z]

where the notation ϕ[ψ/Z] indicates the substitution of ψ for every free occurrence of the variable Z in ϕ.

applications. It is worth noting that the approach is

not limited to the Android platform, but, in this paper,

we will focus on this platform because of its broad

diffusion, the easiness and multiplicity of ways data

can be shared with other applications, and the avail-

ability of numerous source code repositories to assess

the approach.

The proposed method, on one hand uses code in-

strumentation to provide domain expert knowledge

and, on the other hand, models the Android appli-

cation as a labelled transition system (LTS) captur-

ing the behaviour of the app, and evaluating temporal

properties directly on this LTS. Figure 1 shows the

workﬂow of the proposed method.

The ﬁrst step of the proposed method is the Code

instrumentation, aiming at providing basics for the

Model checking phase. In particular, two kind of an-

notations can be speciﬁed: (i) which data should be

considered sensitive and (ii) where, in the app, the

user is informed about the way her data are stored or

processed. An example of the former instrumented

code is shown in Figure 2. Here, the mData vari-

able stores meta-data of a picture in the device photo

gallery. Amongst the picture meta-data, information

can be found, such as the geolocation, other EXIF

data, user tags, and the picture rating that could be

considered sensitive. As so, in our example, the app

developer decided to annotate the variable, thus in-

forming the veriﬁcation tool that the aforementioned

variable must be checked against the speciﬁed rules.

An example of the latter instrumented code is shown

in Figure 3. In this case, the annotation is used as a

checkpoint to state where the user is informed and de-

termine if she agreed to the sensitive data processing

or not.

The second phase of the method consists in a for-

mal veriﬁcation of a set of rules. We focus here on a

GDPR-compliance rule stating that personal data pro-

cessing without user consent or transferring personal

data to a non GDPR-compliant recipient is forbidden.

In order to describe mobile applications we

adopted the Milner’s Calculus of Communicating

Systems (CCS) (Milner, 1989) language speciﬁcation

and express behavioural properties using mu-calculus

branching temporal logic (Stirling, 1989). Simi-

larly to previous works that adopted such method-

ology (Canfora et al., 2018), we developed a tool

aimed to ﬁrst generate a model in the CCS speciﬁ-

cation starting from the analyzed application source

code where, for each instruction, we deﬁne a trans-

formation function to map source code into CCS pro-

cess speciﬁcations. Afterwards, we specify the set

of properties we want to guarantee. In particular,

codes described as CCS processes are ﬁrst mapped

to labelled transition systems and then veriﬁed with

a model checker, i.e., the Concurrency Workbench

of New Century (CWB-NC) (Cleaveland and Sims,

1996) veriﬁcation environment.

In this work, we formulated logic rules to ver-

ify whether the value of a labelled variable (one

of the annotated variable in the previous step of

the approach) is accessed while saving data to the

shared storage or sending data through the Inter-

net without the explicit consent of the user. In

Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation

827

Figure 1: The proposed method the detect sensible data leakage.

Figure 2: Code snippet showing sensitive data annotation for APhotoManager.

this paper, in order to simplify the rules, we sup-

pose that whenever a variable is accessed before

the use of speciﬁc permission invocation (i.e., the

android.permission.INTERNET request or the an-

droid.permission.WRITE EXTERNAL STORAGE re-

quest) there could be a data leakage. Moreover, the

explicit consent of the user has been identiﬁed by an-

notating the relative code (see. Figure 3). To pass the

CWB-NC model checker, the execution of the code

must precede in time the access to the variable in the

execution stack.

Whether at least one property is not veriﬁed, the

proposed framework will mark the relative variable

by appending a warning code to the corresponding

annotation. Moreover, a Trace Log will be created

A Photo Manager App available on F-Droid repos-

itory at https://f-droid.org/en/packages/de.k3b.android.

androFotoFinder/

ForSE 2020 - 4th International Workshop on FORmal methods for Security Engineering

828

Figure 3: Code snippet showing user awareness enforcement.

that contains details about the rule that was not ver-

iﬁed and detailed information about the reason why

the compliance is not guaranteed (e.g., the trace that

leads to a sensitive data leakage). In case all the rules

are veriﬁed, there is no action to take.

Note that, apart from the code instrumentation,

that is responsibility of the app developer, the rest of

the process is automatic. In particular, the construc-

tion of the LTS is completely automatic. Furthermore,

the model checker tool can be automated to contin-

uously verify, e.g., in the background, the speciﬁed

logic formulae on the formal model, and interact with

the development environment when a rule cannot be

veriﬁed because of changes to the source code of the

application.

3 THE CASE STUDY

In this section, we present the temporal logic formulae

aimed to assist the developer notifying the users about

possible sensitive data leaks.

As case study, we consider the A Photo Manager

app, an Android application to manage local photos

Below we show three code snippet belonging to the A

Photo Manager app.

In detail, we show three code snippets implement-

ing behaviours that can conduct to leakage of sensi-

tive information. We show the Java code snippets ex-

tracted by exploiting the Bytecode Viewer tool

Figure 4 shows a code snippet related to the

equals method of the GeoLocation belonging to the

com.draw.lang package. This snippet accesses the

current latitude and longitude (as evidenced by rows

9 and 11 in the Figure 4 snippet).

Figure 5 shows a code snippet related to the

getCacheDirectory method of the StorageUtils class

in the com.nostra13.universalimageloader.utils pack-

age. The snippet shown in Figure 5 is checking

whether it is possible to access to the external stor-

age (by invoking the hasExternalStoragePermission

method). It can be of interest to highlight that on the

Android external storage once a ﬁle is stored, all the

installed application can read and write the resource

without explicit consent to the user (Canfora et al.,

2018).

The code snippet shown in Figure 6 is related

to the NetworkAvailablityCheck class constructor

belonging to the org.osmdroid.titleprovider.modules

package. This snippet requires the permission

to access to the network exploiting the an-

droid.permission.ACCESS NETWORK STATE

permission: basically this permission allows applica-

tions to access information about networks, for this

reason this request can be considered as a potential

https://github.com/Konloch/bytecode-viewer

Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation

829

Figure 4: Code snippet accessing device latitude and longitude.

Figure 5: Code snippet accessing external storage.

information leak.

Table 2 shows the temporal logic formulae to

detect whether the mobile developer previously in-

formed the user before using a sensitive resources.

The temporal logic formulae are related to the de-

tection of the following behaviours:

• with respect to the ϕ formula, related to the snip-

pet in Figure 4, the formula is satisﬁed whether

a log is invoked (with the aim to advise the user)

before using the information about the current de-

vice localisation;

• with respect to the χ formula, related to the snip-

pet shown in Figure 5, this formula is true whether

an instance of the log is invoked before asking for

external storage usage;

• with respect to the ψ formula, related to the snip-

pet shown in Figure 6, the ψ temporal logic prop-

erty is satisﬁed whether a log instance is required

before the device is using information related to

the network state.

ForSE 2020 - 4th International Workshop on FORmal methods for Security Engineering

830

Table 2: Temporal logic formulae for mobile secure programming veriﬁcation.

= νX .[checkcastcomdrewlangGeoLocatio] ff ∧ [−checkcastcomdrewlangGeoLocation, pushlog] X

= νX .[store] ff ∧ [−store, pushlog] X

= νX .[load] ff ∧ [−load, pushlog] X

ϕ = ϕ

∧ ϕ

= νX .[push] ff ∧ [−push, pushlog] X

= νX .[invokegetCacheDirectory] ff ∧ [−invokegetCacheDirectory, pushlog] X

= νX .[invokegetExternalStorageState] ff ∧ [−invokegetExternalStorageState, pushlog] X

= νX .[pushmounted] ff ∧ [−pushmounted, pushlog] X

= νX .[invokehasExternalStoragePermission] ff ∧ [−invokehasExternalStoragePermission, pushlog] X

= νX .[invokegetExternalCacheDir] ff ∧ [−invokegetExternalCacheDir, pushlog] X

= νX .[invokegetCacheDir] ff ∧ [−invokegetCacheDir, pushlog] X

χ = χ

∧ χ

= νX .[invokegetSystemService] ff ∧ [−invokegetSystemService, pushlog] X

= νX .[checkcastandroidnetConnectivityManager] ff ∧

[−checkcastandroidnetConnectivityManager, pushlog] X

= νX .[invokegetPackageManager] ff ∧ [−invokegetPackageManager, pushlog] X

= νX .[pushandroid permissionACCESSNETWORKSTAT E] ff ∧

[−pushandroid permissionACCESSNETW ORKSTAT E, pushlog] X

= νX .[invokegetPackageName] ff ∧ [−invokegetPackageName, pushlog] X

= νX .[invokecheckPermission] ff ∧ [−invokecheckPermission, pushlog] X

ψ = ψ

∧ ψ

Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation

831

Figure 6: Code snippet requiring the network access.

Clearly in the code snippet shown in Figures 4, 5

and 6 these formulae are not satisﬁed: as a matter of

fact there is no log invocation before the usage of the

sensitive instructions, symptomatic that the user is not

advised.

With the aim to help the developer to understand

the reason why a certain formula is not satisﬁed, we

show in Figure 7 the trace generated from the CWB-

NC simulation environment. In detail, we are con-

sidering the model generated starting from the code

snippet in Figure 4.

In this case the ϕ formula is not satisﬁed be-

cause it never happens that before a checkcastcom-

drewlangGeoLocation, a store and a load action there

is a log action: in fact, as shown from Figure 7, the

pushlog action is not present, while the checkcast-

comdrewlangGeoLocation, the store and the load are

present (in Figure 7 are highlighted). The ϕ formula

is satisﬁed whether a pushlog action is present be-

fore the highlighted actions. In this way the developer

is able to localise the exact point in the source code

where to invoke the log action (i.e., the exact point

where the user should be notiﬁed).

4 RELATED WORK

Several studies in current state of the art literature are

mainly focused on mobile malware detection (Chen

et al., 2016; Suarez-Tangil et al., 2017; Duc and

Giang, 2018). These works are mainly exploiting

machine learning techniques by extracting distinc-

tive features from samples under analysis to discrimi-

nate between malicious applications and trusted ones.

Contrarily, in this paper we investigate an automatised

method aimed to detect possible sensitive information

leakage by providing an useful tool for the developer

to inform the user.

Shan et al. in (Shan et al., 2018) investigate about

self-hiding behaviours (SHB), e.g. hiding the app,

hiding app resources, blocking calls, deleting call

records, or blocking and deleting text messages. First

of all the authors provide an in-deep characterization

of SHB, then they present a suite of static analyses

to detect such behaviour. They deﬁne a set of detec-

tion rules able to catch SHB. They test their approach

against more than 9,000 Android applications.

Dynamic taint analysis is a method to analyze ex-

ecutable ﬁles by tracing information ﬂow (Kim et al.,

2014; Dalton et al., 2010). This approach has been

applied to detect sensitive information leaking of net-

work servers (Li et al., 2014). Differently from us,

besides being focused on network servers attacked by

malwares or hackers, sensitive data tagging is auto-

matic, thus not using the domain expert knowledge.

Taint analysis is also considered by FlowDroid

(Arzt et al., 2014), a tool focused on the Android

application life-cycle and callback methods designed

with the aim to reduce missed leaks and false pos-

itives. Authors provide also an Android-speciﬁc

benchmark suite i.e., DROIDBENCH, to evaluate

taint analysis tools focused on Android information

leakage. Also the Leakminer tool (Yang and Yang,

2012) considers taint analysis for detecting sensitive

information exﬁltration in Android.

All of the aforementioned approaches are mainly

focused on the identiﬁcation of data leaking from

the user perspective. In fact, as emerging from the

current state-of-the-art discussion, the following pro-

posal represents the ﬁrst attempt to provide a tool for

the developer to avoid the (unaware) usage of sensi-

tive resource without notifying the user.

ForSE 2020 - 4th International Workshop on FORmal methods for Security Engineering

832

Figure 7: Trace generated from the simulation environment.

5 CONCLUSION AND FUTURE

WORK

In this paper we propose a method to assess security

related properties of Android applications. This is a

current topic, especially in the context of GDPR reg-

ulation compliance. Indeed, the software developer

may be answerable to provide access to sensitive in-

formation without the explicit user consent as well as

for transferring personal data towards a non GDPR-

compliant recipient. In the Android environment, data

can be transferred through several channels, e.g., via

the network connection or by storing them in shared

memory that can be accessed by other applications.

In these cases, there is the possibility to infringe the

regulation and cause data leakage towards unautho-

rized subjects or non compliant recipients. Despite

this could be considered a malicious behaviour typ-

ical from spyware and other similar malwares, there

could be the possibility that the leakage is merely due

to shallowness or bad programming practices, such as

using an unsafe connection or a shared data store.

To overcome this issue and support the soft-

ware engineer during the development and veriﬁca-

tion phases, we propose a semi-automatic method

based on code instrumentation and model checking

techniques. In our approach, the software engineer

is in charge of identifying the sensitive information

her app processes and the methods she deﬁned to in-

form the user about the sensitive data processing or

transfer. This can be done using Java custom annota-

tions or logging instructions. Once the code is instru-

mented, formal methods are applied to check prede-

ﬁned rules aimed at verifying if there exist execution

threads bringing about sensitive information leaks.

We also presented how the proposed method can

be applied to an existing application to identify possi-

ble information leaks and improve the software secu-

rity by ﬁxing the ﬂaw. The proposed method can be

easily extended to other programming language and

platforms provided that the related translator from the

source to the CCS speciﬁcation is available.

As future work, we plan to evaluate the method by

applying it to several open source Android applica-

tions to identify possible sensitive information leaks

and understand how much widespread are similar bad

programming practices. Finally, in case we observe a

broad diffusion of unchecked sensitive data leaks, we

intend to develop a tool that automatically ﬁx some of

the most common regulation infringements by inject-

ing conﬁgurable snippets directly in the application’s

source code. This would provide the developers with

a tool to signiﬁcantly improve their application com-

pliance to speciﬁc regulations, with a limited effort.

ACKNOWLEDGMENTS

This work has been partially supported by MIUR -

SecureOpenNets and EU SPARTA and CyberSANE

projects, the Formal Methods for IT Security Lab

https://dipbioter.unimol.it/ricerca/laboratori/metodi-

formali-per-la-sicurezza-informatica/

Accidental Sensitive Data Leaks Prevention via Formal Veriﬁcation

833

and the MOSAIC Research Center

at the University

of Molise.

REFERENCES

Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A.,

Klein, J., Le Traon, Y., Octeau, D., and McDaniel, P.

(2014). Flowdroid: Precise context, ﬂow, ﬁeld, object-

sensitive and lifecycle-aware taint analysis for android

apps. ACM SIGPLAN Notices, 49(6):259–269.

Barbuti, R., De Francesco, N., Santone, A., and Vaglini, G.

(2005). Reduced models for efﬁcient ccs veriﬁcation.

Formal Methods in System Design, 26(3):319–350.

Canfora, G., Martinelli, F., Mercaldo, F., Nardone, V., San-

tone, A., and Visaggio, C. A. (2018). Leila: formal

tool for identifying mobile malicious behaviour. IEEE

Transactions on Software Engineering.

Ceccarelli, M., Cerulo, L., and Santone, A. (2014). De

novo reconstruction of gene regulatory networks from

time series data, an approach based on formal meth-

ods. Methods, 69(3):298–305. cited By 10.

Chen, S., Xue, M., Tang, Z., Xu, L., and Zhu, H.

(2016). Stormdroid: A streaminglized machine

learning-based system for detecting android malware.

In Proceedings of the 11th ACM on Asia Conference

on Computer and Communications Security, pages

377–388. ACM.

Ciobanu, M. G., Fasano, F., Martinelli, F., Mercaldo, F.,

and Santone, A. (2019a). A data life cycle modeling

proposal by means of formal methods. In Proceedings

of the 2019 ACM Asia Conference on Computer and

Communications Security, pages 670–672.

Ciobanu, M. G., Fasano, F., Martinelli, F., Mercaldo,

F., and Santone, A. (2019b). Model checking for

data anomaly detection. Procedia Computer Science,

159:1277–1286.

Clarke, E. M., Grumberg, O., and Peled, D. (2001). Model

checking. MIT Press.

Cleaveland, R. and Sims, S. (1996). The ncsu concurrency

workbench. In Alur, R. and Henzinger, T. A., editors,

CAV, volume 1102 of Lecture Notes in Computer Sci-

ence, pages 394–397. Springer.

Dalton, M., Kannan, H., and Kozyrakis, C. (2010). Taint-

ing is not pointless. ACM SIGOPS Operating Systems

Review, 44(2):88–92.

Duc, N. V. and Giang, P. T. (2018). Nadm: Neural network

for android detection malware. In Proceedings of the

Ninth International Symposium on Information and

Communication Technology, pages 449–455. ACM.

Fasano, F., Martinelli, F., Mercaldo, F., and Santone, A.

(2019). Cascade learning for mobile malware fami-

lies detection through quality and android metrics. In

International Joint Conference on Neural Networks,

IJCNN 2019 Budapest, Hungary, July 14-19, 2019,

pages 1–10.

https://dipbioter.unimol.it/ricerca/laboratori/centro-di-

ricerca-mosaic/

Gradara, S., Santone, A., and Villani, M. L. (2005). Using

heuristic search for ﬁnding deadlocks in concurrent

systems. Information and Computation, 202(2):191–

226.

Harleen K. Flora, Xiaofeng Wang, S. C. (2014). Adopting

an agile approach for the development of mobile ap-

plications. Journal of Computer Applications, 94:43–

50.

Kim, J., Kim, T., and Im, E. G. (2014). Survey of dynamic

taint analysis. In 2014 4th IEEE International Confer-

ence on Network Infrastructure and Digital Content,

pages 269–272.

Li, W., Yan, Y., Tu, H., and Xu, J. (2014). A dynamic taint

tracking based method to detect sensitive information

leaking. In The 16th Asia-Paciﬁc Network Operations

and Management Symposium, pages 1–4.

Martinelli, F., Marulli, F., and Mercaldo, F. (2017a). Eval-

uating convolutional neural network for effective mo-

bile malware detection. Procedia computer science,

112:2372–2381.

Martinelli, F., Mercaldo, F., and Saracino, A. (2017b).

Bridemaid: An hybrid tool for accurate detection of

android malware. In Proceedings of the 2017 ACM on

Asia Conference on Computer and Communications

Security, pages 899–901. ACM.

Milner, R. (1989). Communication and concurrency. PHI

Series in computer science. Prentice Hall.

Santone, A. (2002). Automatic veriﬁcation of concur-

rent systems using a formula-based compositional ap-

proach. Acta Informatica, 38(8):531–564.

Santone, A. (2011). Clone detection through process alge-

bras and java bytecode. In IWSC, pages 73–74. Cite-

seer.

Scanniello, G., Fasano, F., Lucia, A. D., and Tortora, G.

(2013). Does software error/defect identiﬁcation mat-

ter in the italian industry? IET Software, 7(2).

Shan, Z., Neamtiu, I., and Samuel, R. (2018). Self-hiding

behavior in android apps: detection and characteriza-

tion. In Proceedings of the 40th International Confer-

ence on Software Engineering, ICSE 2018, Gothen-

burg, Sweden, May 27 - June 03, 2018, pages 728–

739.

Stirling, C. (1989). An introduction to modal and temporal

logics for ccs. In Yonezawa, A. and Ito, T., editors,

Concurrency: Theory, Language, And Architecture,

volume 491 of LNCS, pages 2–20. Springer.

Suarez-Tangil, G., Dash, S. K., Ahmadi, M., Kinder, J., Gi-

acinto, G., and Cavallaro, L. (2017). Droidsieve: Fast

and accurate classiﬁcation of obfuscated android mal-

ware. In Proceedings of the Seventh ACM on Confer-

ence on Data and Application Security and Privacy,

pages 309–320. ACM.

Yang, Z. and Yang, M. (2012). Leakminer: Detect informa-

tion leakage on android with static taint analysis. In

2012 Third World Congress on Software Engineering,

pages 101–104. IEEE.

ForSE 2020 - 4th International Workshop on FORmal methods for Security Engineering

834